already enabled. This, coupled with
the above bug, may be caused some pretty bad performance penalties. I would
be interested in seeing some benchmarks from before and after.
-Raystonn
___
Dri-devel mailing list
[EMAIL PROTECTED]
https
.
The chips may (or may not, I have not double checked) be somewhat
programmable, but the arrangement of the chips in the pipeline are not.
Thus, the implementation of whatever algorithm they use can be tweaked
somewhat, but the algorithm is pretty much hard-coded.
-Raystonn
__
der algorithm. Algorithms are at least an
order of magnitude more important than the implementation itself.
-Raystonn
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Odd, I sent a few emails to the list and I have
received none of them. An hour after that I sent one more and I just got
it from the list. This leaves me wondering of my other emails have sunken
into a black hole somewhere...
Has anyone else had these troubles on this
list?
-Raystonn
sed on scene-capturing and some algorithms I have
created. Of course I will ensure it passes conformance tests in the end.
What good is an OpenGL implementation if it does not work as advertised. ;)
-Raystonn
___
Dri-devel mailing list
[EMAIL PROTECTED]
http
have access to the kinds of
memory bandwidth that a 3D card does. I believe a software implementation
of a scene-capture tile-renderer would have much better results. This is a
more computationally expensive, less bandwidth-intensive algorithm which is
more suited to a CP
re
waiting for the results of the read in order to perform another operation.
What good is pushing something into the background when you must wait for
that operation to complete? These slow transfers and all the waiting makes
this an extremely slow process. It is not recomme
doubt that the immediate mode rendering algorithm has extremely
optimized implementations in today's 3D cards. However, a poorly optimized
more efficient algorithm is preferred over a highly optimized inefficient
algorithm. There is always room for optimizing the implementation. The
algorithm itself is of utmost importance.
-Raystonn
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
in a prior debate.
The top paragraph was not intended to support any argument regarding
software rendering.
-Raystonn
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
tions are always extremely slow.
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.
-Raystonn
were not performed under any operating system
other
> > than that which was on the floppy).
>
> Eh, you don't measure latency in Mb/s.
>
> I have to give Mr. Raystonn his due, he is persistent and determined, but
I
> think it may now be time for this thread to die?
ars old.
It is no wonder you got such low results. Now compare your EDO ram results,
from about 5 years ago, to my current results:
Pentium 4 2.4GHz, 400MHz FSB, i850 chipset with RDRAM: L1 cache:
19730MB/s, L2 cache: 16833MB/s, Memory: 1425MB/s
My results are 19 times better than your results
200Mhz 286. :)
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.
-Raystonn
cards will also have a 100x
> RAM bandwidth speedup - so the relative performances will remain.
Unlikely. It is more likely that the main CPU will catch up to the memory
technology used by video cards. nVidia *just* introduced a video card with
4 DDR SDRAM channels for 10.4GB/s of memory bandwidth. Before that they
were using dual-channels. The Pentium 4 will have access to about 4.3GB/s
of memory bandwidth next month. We hardly need a 100x memory bandwidth
speedup. It is closer to about 2.5x.
-Raystonn
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
> Hey Raystonn,
>
> Oh my godness, who fed that trolls. ;-)
Please refrain from calling me a troll. A troll is really someone who
flames others. He is someone who attempts to attack the messenger rather
than address the message. Thusfar the only one to do this is you.
> Lets
t; with
> graphics cards - and no logical reason why they ever will.
I will have to disagree here. Indications are that the video card
manufacturers are looking more and more into 'programmable' features such as
the pixel shaders. If this is the case it would be relatively easy for the
main processor to 'catch up'. Programmability is its specialty.
At any rate, we will probably just have to agree to disagree here. ;)
-Raystonn
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
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
e"renderer much like that used in Kyro could perform
as well as the latestvideo cards in a year or two. This is what I am
dabbling with at themoment.-Raystonn- Original
Message -From: "Brian Paul" <[EMAIL PROTECTED]>To:
<[EMAIL PROTECTED]>Cc:
<[EMAIL PROTE
18 matches
Mail list logo
