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-tune
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 however. A
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. It
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
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
founded,
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 forgotten
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 to perform
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 been
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 to
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 for tile
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 rendering
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?
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 in
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
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 are
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
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
bandwidth.
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
latency,
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 process
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
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 single
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.
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 fix it?
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 + some
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
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 small test
program which calls the relevant functi
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. The
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
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 fast
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
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: [Mesa3d-dev] Re: [Dri-devel] Mesa software blending
31 matches
Mail list logo
