Comments on behold: Rudolf's corner: 3D add-on Alpha 4 released..

Hey,Your site is looking Pretty good. I like it.I ...

2006-04-14T22:40:00.000+02:00

Hey,

Your site is looking Pretty good. I like it.

I have a new site that focuses on Tech Reviews, RMA Reviews, and more.

You should check it out.

##Link## Reviews

Ciao,

Ravi

A small update (still working on it):I was able to...

2006-03-31T09:03:00.000+02:00

A small update (still working on it):

I was able to increase GeForce2Ti rendering speed with some 21%, and GeForce2MX with some 44%.

GF2Ti:
640x480x16 Q2tdemo1 = 140fps
1024x768x32 28.3fps (was 23.3)

GF2MX:
640x480x16 = 109fps (was 60-70)
1024x768x32 = 18.9fps (was 13.1)

Others are unchanged.

GF4MX440 is still at:
640x480x16 = 125fps
1024x768x32 = 26.3fps

So, GeForce2Ti has taken the lead.
I have a feeling this is max I can do for now, because the relative comparison between cards seems OK now (if you take ROPS and RAM-bandwith both into account).

I'll probably do some calculations about that, and, as said, I'll keep fiddling around a bit more.

I'm glad I got this going at least :-)

Thanks Euan,Interesting read. After writing this a...

2006-03-30T11:51:00.000+02:00

Thanks Euan,

Interesting read. After writing this article I remembered that the crossbar controller was 'invented' after GF2, so that's also not why my driver performs relatively slow.

So, thinking further, I am now looking into parallel ROP's, which all cards the driver currently supports have: all cards have two of them, except the pro line of GF2: these have 4.

This is interesting to look at. I was pointed in this direction by an alternate explanation I found about what ROP means.
Mostly, this is explained as Raster OPerations. But, another version is Raster OutPut. (or something like that).

I am now briefly testing for a solution in that very direction today. Hold on, I'll keep you posted. :-)

Further reading cut and pasted from Anandtech:Ligh...

2006-03-29T01:19:00.000+02:00

Further reading cut and pasted from Anandtech:

Lightspeed Memory Architecture

The GeForce3's memory controller is actually drastically changed from the GeForce2 Ultra. Instead of having a 128-bit interface to memory, there are actually four fully independent memory controllers that are present within the GPU in what NVIDIA likes to call their Crossbar based memory controller.

These four memory controllers are each 32-bits in width that are essentially interleaved, meaning that they all add up to the 128-bit memory controller we're used to, and they do all support DDR SDRAM. The crossbar memory architecture dictates that these four independent memory controllers are also load balancing in reference to the bandwidth they share with the rest of the GPU.

The point of having four independent, load balanced memory controllers is for increased parallelism in the GPU (is anyone else picking up on the fact that this is starting to sound like a real CPU?). The four narrower memory controllers come quite in handy when dealing with a lot of small datasets. If the GPU is requesting 64-bits of data, the GeForce2 Ultra uses a total of 256-bits of bandwidth (128-bit DDR) in order to fetch it from the local memory. This results in quite a bit of wasted bandwidth. However in the case of the GeForce3, if the GPU requests 64-bits of data, that request can be handled in 32-bit chunks, leaving much less bandwidth unused. Didn't your mother ever tell you that it's bad to leave food wasted? It looks like NVIDIA is finally listening to their mother.

Source:

http://www.anandtech.com/printarticle.aspx?i=1426

Hi,I guess it can be made to work with Xorg, the d...

2006-03-27T21:08:00.000+02:00

Hi,

I guess it can be made to work with Xorg, the driver has been ported before. Although the driver needs to be rewritten for current Mesa, something I need to do as well.

Copyright: I now named it BSD/MIT, since after talking to Haiku's openGL kit lead person, all of the parts of this stuff should be compatible with that. I did not remove copyright stuff, nor did I add stuff for that in the files. You'll find nVidia's own messages still there for example, as they should be.

Anyway, I am no copyright/licence expert, so I gladly leave discussions about that to other people.

And: I kind of even hope some linux group picks up again, since it seems like a waste this driver was never further developed before. Currently I work on this alone. The switch to current Mesa seems like very difficult to me: I can't do it ATM: first I need to port some other DRI driver to BeOS to learn more about the current Mesa driver-interface.

But I am convinced this driver will speed up while lowering the software overhead at the same time, once it's on current Mesa.

How portable is this? Would it be easy to make it ...

2006-03-27T05:06:00.000+02:00

How portable is this? Would it be easy to make it work with xorg? Are you in contact with anyone interested in porting your work to xorg? What is the copyright status of your 3D work? I heard it was derived from utah-glx, is everything koser - you left the copyright info intact and the licence the same?