> > You know what they found out with all of the hundreds of millions of
> dollars
> > they spent? Dedicated hardware still does it faster and cheaper. Period.
> > It's just like writing a custom routine to sort an array will pretty much
> > always be faster than using the generic qsort. When y
> > Here you are comparing different algorithms. A custom sort algorithm
will
> > perform much better than a standard qsort. I agree. Implementing
something
> > in hardware does not mean it uses a more efficient algorithm however. A
> > hardware implementation is just that, an implementation.
On Thu, 11 Apr 2002 00:26:17 -0700
"Raystonn" <[EMAIL PROTECTED]> wrote:
> Here you are comparing different algorithms. A custom sort algorithm will
> perform much better than a standard qsort. I agree. Implementing something
> in hardware does not mean it uses a more efficient algorithm howev
> You know what they found out with all of the hundreds of millions of
dollars
> they spent? Dedicated hardware still does it faster and cheaper. Period.
> It's just like writing a custom routine to sort an array will pretty much
> always be faster than using the generic qsort. When you hand-tu
On Tue, Apr 09, 2002 at 06:29:54PM -0700, Raystonn wrote:
> First off, current market leaders began their hardware designs back when the
> main CPU was much much slower. They have an investment in this technology
> and likely do not want to throw it away. Back when these companies were
> founde
> > If you want to get back to the topic of software rendering, I would be
more
> > than happy to oblige.
>
> Better yet, if you are serious - how about furthering your argument with
> patches to optimise and improve Mesa's software paths?
Patches will not do the job. My ideas include a change i
On Tue, 9 Apr 2002, Raystonn wrote:
> If you want to get back to the topic of software rendering, I would be more
> than happy to oblige.
Better yet, if you are serious - how about furthering your argument with
patches to optimise and improve Mesa's software paths?
___
> I agree. You may want to take a look at the following article:
>
> http://www.tech-report.com/reviews/2001q2/tnl/index.x?pg=1
>
> It shows, among other things, a 400MHz PII with a 3dfx Voodoo2 (hardware
> rasterization) getting almost double the framerate of a 1.4GHz Athlon
> doing software ren
> > With the rest I disagree. The Kyro, for example, has some high-speed
local
> > memory (cache) it uses to hold the pixels for a tile. It can antialias
and
> > render translucent scenes without ever blitting the cache to the
framebuffer
> > more than once.
>
> It can't have infinite storage fo
> > I agree with the "you have to read pixels back from the frame
> > buffer and
> > then continue rendering polygons." For a hardware
> > implementation I might
> > agree with the "you need to draw more polygons than your
> > hardware has room
> > to store", but only if the hardware implementati
Stephen J Baker wrote:
>
Everything starts out in hardware and eventually moves to software.
>>>
>>>That's odd - I see the reverse happening. First we had software
>>
>>The move from hardware to software is an industry-wide pattern for all
>>technology. It saves money. 3D video cards have
> I agree with the "you have to read pixels back from the frame
> buffer and
> then continue rendering polygons." For a hardware
> implementation I might
> agree with the "you need to draw more polygons than your
> hardware has room
> to store", but only if the hardware implementation decides
> > I still maintain that immediate mode renderering is an inefficient
algorithm
> > designed to favor the use of memory over computations. A better
algorithm
> > will always win out given enough time to overtake the optimized versions
of
> > the more inefficient algorithms.
>
> Perhaps you've fo
On Mon, Apr 08, 2002 at 06:17:59PM -0700, Raystonn wrote:
> I still maintain that immediate mode renderering is an inefficient algorithm
> designed to favor the use of memory over computations. A better algorithm
> will always win out given enough time to overtake the optimized versions of
> the
On Mon, Apr 08, 2002 at 06:17:59PM -0700, Raystonn wrote:
| As far as the reading of pixels from the framebuffer, this is a highly
| inefficient thing to do, no matter the hardware.
It doesn't have to be; that's just a tradeoff made by the hardware
designers depending on the applications for whic
> > The games perform overdraw, sure. But I am talking about at the pixel
> > level. A scene-capture algorithm performs 0 overdraw, regardless of
what
> > the game sends it.
>
> That's not true. I've designed and built machines like this and I know.
>
> You still need overdraw when:
>
> * you
On Thu, 4 Apr 2002, Raystonn wrote:
> The games perform overdraw, sure. But I am talking about at the pixel
> level. A scene-capture algorithm performs 0 overdraw, regardless of what
> the game sends it.
That's not true. I've designed and built machines like this and I know.
You still need o
> > Yes, some details were left out of CPU performance increases. The same
was
> > done for memory performance increases though. We have been discussing
> > memory bandwidth as memory performance, completely leaving out memory
> > latency, which has also improved tremendously.
>
> Pardon me, but
On Fri, 5 Apr 2002 17:11:26 -0800
"Raystonn" <[EMAIL PROTECTED]> wrote:
> Yes, some details were left out of CPU performance increases. The same was
> done for memory performance increases though. We have been discussing
> memory bandwidth as memory performance, completely leaving out memory
> l
> > > OK - so a factor 70 in CPU growth and a factor of 16 in RAM speed.
> >
> > No, in this 5 year period, processor clockspeed has moved from
approximately
> > 200MHz to over 2GHz. This is a factor of 10 in CPU growth and 16 in
memory
> > bandwidth. Memory bandwidth is growing more quickly tha
On Thu, Apr 04, 2002 at 09:30:39PM -0800, Raystonn wrote:
> > OK - so a factor 70 in CPU growth and a factor of 16 in RAM speed.
>
> No, in this 5 year period, processor clockspeed has moved from approximately
> 200MHz to over 2GHz. This is a factor of 10 in CPU growth and 16 in memory
> bandwi
> Yes - and yet they still have horrible problems every time you have
> a conditional branch instruction. That's because they are trying
Not really. The Pentium 4 has a very efficient branch prediction unit.
Most of the time it guesses the correct branch to take. When the actual
branch is comp
On Tue, 2 Apr 2002, Raystonn wrote:
> > That is far from the truth - they have internal pipelining
> > and parallelism. Their use of silicon can be optimised to balance
> > the performance of just one single algorithm. You can never do that
> > for a machine that also has to run an OS, word pro
> > Does 4 do pixel-based fog?
> yep.
So in some cases it is much slower than 3, isn't it?
> It's because they are quite similar operations so they use the same chip
> logic. In fact you have a bit to choose wether you want alpha or fog. It's
> was design option.
So they did not want to have tw
On 2002.04.04 09:44 Sergey V. Udaltsov wrote:
> > But the OpenGL spec says that the fog color is calculated on a _pixel_
> > basis and not on a _vertex_ basis. Indeed the result is different,
> > especially in long polygons that span from the front way to the back.
> Does 4 do pixel-based fog?
>
On 2002.04.04 09:08 Keith Whitwell wrote:
> On Thu, 4 Apr 2002 01:56:22 +0100
> José Fonseca <[EMAIL PROTECTED]> wrote:
>
> > ...
>
> > the further away is the vertex more its color is nearer to the fog
> > background color. Since the colors are interpolated in the triangle
> this
> > gave the i
> But the OpenGL spec says that the fog color is calculated on a _pixel_
> basis and not on a _vertex_ basis. Indeed the result is different,
> especially in long polygons that span from the front way to the back.
Does 4 do pixel-based fog?
> Mach64 is able to do the fog properly, i.e., on a pi
On Thu, 4 Apr 2002 01:56:22 +0100
José Fonseca <[EMAIL PROTECTED]> wrote:
> On 2002.04.03 23:50 Sergey V. Udaltsov wrote:
> > > He!He!.. you missed!! It's a mix of variant 1 and 2..! :)
> > Cool. At least 1+2 is the answer (call it 5). Thanks.
> >
> > > As Leif previously said is his reply, it c
On 2002.04.03 23:50 Sergey V. Udaltsov wrote:
> > He!He!.. you missed!! It's a mix of variant 1 and 2..! :)
> Cool. At least 1+2 is the answer (call it 5). Thanks.
>
> > As Leif previously said is his reply, it can be done in hardware by
> > messing the colors of the vertex to incorporate the fog
> He!He!.. you missed!! It's a mix of variant 1 and 2..! :)
Cool. At least 1+2 is the answer (call it 5). Thanks.
> As Leif previously said is his reply, it can be done in hardware by
> messing the colors of the vertex to incorporate the fog (as software Mesa
> used to do in 3.x) but it's non-c
On 2002.04.03 14:43 Sergey V. Udaltsov wrote:
> After all these interesting and informative discussions, everyone has
> forgotten the start of the thread:) Basically, there should one answer
> to the question whether and how "blending+fog" can be implemented .
> Possible variants:
> 1. Yes, it ca
After all these interesting and informative discussions, everyone has
forgotten the start of the thread:) Basically, there should one answer
to the question whether and how "blending+fog" can be implemented .
Possible variants:
1. Yes, it can be done with hardware acceleration. DRI team knows how.
> > The only thing video
> > cards have today that is really better than the main processor is
massive
> > amounts of memory bandwidth.
>
> That is far from the truth - they have internal pipelining
> and parallelism. Their use of silicon can be optimised to balance
> the performance of just one
ell as the latest
video cards in a year or two. This is what I am dabbling with at the
moment.
-Raystonn
- Original Message -
From: "Brian Paul" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, April 01, 2002 6:36 AM
Subject: [Mes
> There is no sign whatever that CPU's are "catching up" with
> graphics cards - and no logical reason why they ever will.
It could however be argued that CPUs are "catching up" with the needs of a
certain level of user. Not the hardcore gamer, but quite possibly the
hobbyist 3D artist or 3D f
Gack! I'm *so* sick of hearing this argument...
On Tue, 2 Apr 2002, Raystonn wrote:
> I am definately all for increasing the performance of the software renderer.
Yes.
> Eventually the main system processor will be fast enough to perform all of
> this without the need for a third party graph
19:45
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [Mesa3d-dev] Re: [Dri-devel] Mesa software blending
[Resending, fell into last night's black hole it seems.]
I am definately all for increasing the performance of the software renderer.
Eventually the main system processor will be
> > > I don't think so. I haven't noticed a problem with fog
> in the tunnel demo.
> > So it works for you, doesn't it? Envious.
> > For me, the fog effect does not work. Some time ago, someone (Jose?)
> > even explained that is should not work on mach64 (alpha
> blending + some
> > other effec
> Raystonn wrote:
>
> [Resending, fell into last night's black hole it seems.]
>
> I am definately all for increasing the performance of the software renderer.
> Eventually the main system processor will be fast enough to perform all of
> this without the need for a third party graphics card. T
CTED]>Sent:
Monday, April 01, 2002 6:36 AMSubject: [Mesa3d-dev] Re: [Dri-devel] Mesa
software blending"José Fonseca" wrote:>> In these last
few days I have been working on the Mesa software blending> and the
existing MMX bug. I've made some progress.>> I made a
On 2 Apr 2002, Sergey V. Udaltsov wrote:
> > I don't think so. I haven't noticed a problem with fog in the tunnel demo.
> So it works for you, doesn't it? Envious.
> For me, the fog effect does not work. Some time ago, someone (Jose?)
> even explained that is should not work on mach64 (alpha ble
"Sergey V. Udaltsov" wrote:
>
> > I don't think so. I haven't noticed a problem with fog in the tunnel demo.
> So it works for you, doesn't it? Envious.
> For me, the fog effect does not work. Some time ago, someone (Jose?)
> even explained that is should not work on mach64 (alpha blending + som
> I don't think so. I haven't noticed a problem with fog in the tunnel demo.
So it works for you, doesn't it? Envious.
For me, the fog effect does not work. Some time ago, someone (Jose?)
even explained that is should not work on mach64 (alpha blending + some
other effect?) So my question was whe
"Sergey V. Udaltsov" wrote:
>
> > In these last few days I have been working on the Mesa software blending
> > and the existing MMX bug. I've made some progress.
> Sorry for my ignorance, does this blending have anything to do with the
> incorrect fog handling in the tunnel app? Will this patch f
> In these last few days I have been working on the Mesa software blending
> and the existing MMX bug. I've made some progress.
Sorry for my ignorance, does this blending have anything to do with the
incorrect fog handling in the tunnel app? Will this patch fix it?
Sergey
__
"José Fonseca" wrote:
>
> In these last few days I have been working on the Mesa software blending
> and the existing MMX bug. I've made some progress.
>
> I made a small test program which calls the relevant functions directly as
> Alex suggested. In the process I added comments to the assembly
In these last few days I have been working on the Mesa software blending
and the existing MMX bug. I've made some progress.
I made a small test program which calls the relevant functions directly as
Alex suggested. In the process I added comments to the assembly code
(which had none). The erro
47 matches
Mail list logo
