Saturday, February 25, 2006

 

nVidia 3D status update

High-time for a status update I'd say. A lot has happened.

Resizing outputwindows and another BeOS bug
This function is implemented and working reliably now. However, that took some time: there turns out to be another BeOS (R5 and dano) bug here: when you enable Window resizing events in the constructor of the BGLview, the corresponding routines are called: but the new size given to the resize routine is NOT the new one! Instead the one before the latest one is given.. Needles to say it took a lot of testing and trying to recognize this bug. By the time I knew what was going wrong, I saw a workaround in Be's teapot code: not using the given size, but asking for it itself.
After I added this workaround to the driver as well, resizing worked correctly. But not before I added LockLooper()/UnlockLooper() calls to the routines LockGL() and UnlockGL(): this was the trouble I saw about resizing being asynchronous to rendering. So not a Mesa problem, but 'my' problem: syncing threads. Fortunately this solution was already there in current Mesa, so I just copied it over to my driver.

Resizing sometimes still temporary distorts the rendered output, but that's not very important. Although it could look better of course. The driver is not calling Mesa GLviewport or resize_buffer functions, that's a task for the application programmer (as can be seen in various code examples outthere). The driver only takes care of programming the card right. It's nice to see a very large Teapot spin around, and to recognize the speed effects of resizing it. :-)

Trilineair filtering: 'random' engine crashes
As usual (so I can say these days :-) BeOS Mr.X is 'betatesting' the driver for me. As he has a lot of knowledge about the Quake series of games and the console commands you can give them, he finds bugs rather easy compared to myself. One of the problems he encountered was that using GL_LINEAR_MIPMAP_LINEAR texture rendering in Quake2 hung the driver. After two days of searching I discovered what was wrong: the original UtahGLX driver I based my work on contained an error: the rendering quality setting was increased 'by one step' when rendering switched from textured rendering to non-textured rendering. Of course the driver meant to set a basic 'level 1' as textures aren't actually used then.

The driver crashed the acceleration engine because it was fed with an illegal setup: a non-existing filtering mode.
So: alpha 4 will have this problem fixed. And the really funny part is that I didn't even know the driver supported filtering in this area... But it does: you can choose no filtering, bilinear filtering, and trilinear filtering: all just a setting fed into the engine. Checkout the gl_texturemode console command for Quake1 and Quake2 if you are interested.

Quake1 touching keyboard hangs game.
Another interesting thing to have a look at. Since the sources of GLquake are outthere, I made it compile on R5 and dano. That turned out to be a relatively easy thing todo. After having the game run, I could now go on a bughunt for this error. It turns out that the keyboard routine is protected by a semaphore, which is also grabbed when a new frame is rendered. This is a bad situation apparantly, as rendering stops completely when the keyboard was touched. I could fix it anyway by modifying the game executable a bit: acquiring/releaseing the semaphore as close to actual rendering as can be (inside the LockGL()/UnlockGL() part instead of outside of it.) Still you see the keyboard lagging on high-res modes however. Anyway: it has to do. Unless someone else is going to have a better look ofcourse. (Enable the networking support someone?).

With Be's software GL the game did not hang, but then, this renders rather slowly. I could prevent hanging in the accelerated driver by adding a snooze(100000)...
If someone knows of a driver-way to overcome this problem I am interested in knowing: after all R4.5's accelerated GL did not suffer from this symptom.

Quake1 rendering faults.
While I was playing around with Q1, I decided to try to find the reason for the wrongly rendered game scores at the mid-bottom of Quake1's screen. I found it after another day or two: yet another 'original' UtahGLX driver bug. It forgot to send the active texture's colorspace to the engine when a new one was activated...
Oh, doing a timerefresh in Q1 console was strange to see as well: it rendered in the foreground buffer. As the nVidia driver doesn't support that yet, I modified this command to use the backbuffer so it's accelerated: it's nasty to have to wait for 128 frames when rendering a single one cost about a second or so.

Anyway: it makes more sense as well to have it render in the backbuffer as otherwise we would always see the 'distortions' of the engine building up the frames in plain sight.

Next up..
So: all in all all rendering faults for both Quake1 and Quake2 have been solved. I guess I should release an updated version of Quake1 to bebits (including source) so this game can be played using openGL once more on BeOS. It would be nice if someone could take it from there to update it for networking and such I'd say.

OK, back to work. I want to have a look at switching resolutions inside Quake2 (wich only works partly for some reason), and then comes the 'real' swapbuffer thing. Apart from these items the driver seems ready for a new release.

Talk to you later!

Comments:
What GLQuake have you used?
Have found some spinnoffs and the old GLQuake..

wonder if http://www.quakeforge.net/ would work? :)
 
I used:
http://www.aixplosive.de/projects.html

That site you're pointing at does look tempting, doesn't it? ;-)

The version I used BTW is far from perfect, lots of console commands 'crash' the game (divide by zero errors and such).

Would be cool if someone could 'port' the latest and greatest versions of Q1 and Q2 (both GL) to BeOS so we have 'it all' :-)
 
I didn't do any specific benchmarking before, but I'd assume now I'm at the theoretical performance limit of the driver with this shiny (albeit slightly used) GF4 MX460. Best of all it's got a DVI port so it can live on the KVM with the other machines now!

Rudolph, once you release this new driver revision, I'll get to work releasing this little game engine demo :)
 
Hi PS,

Ah, a 460. Would be cool if I could find one in my neighbourhood to see what it does compared to the 440 I have here. And another one: the PCX4300, a NV18 for PCI-express!

Anyway, I hope you'll like it. I can tell you this: I solved a number of driver faults once more since this blog-entry. Although the speed maxes at about the same (or a bit more) as it was with Alpha 3.5, the quality of the driver has massively improved. And I still have a few items I want to check-out. :-)

Mesa 3.4.2 itself sofar showed just one fault over here (some time ago with AA/nonAA selection).

Apart from that just faults I 'introduced' while porting, faults existing in the original UtahGLX driver, and faults existing in the Mesa 3.4.2 software BGLview driver.
 
Wow, I had heard about the PCX 4300 but when actually looking for it... seems that's an even more elusive beast than the MX460! Regardless I'll keep an eye open for it.
 
As promised, or possibly even threatened. Here's my demo...

Demo Screenshot

Only a screenshot for now (I've got an issued with perspective resizing) but it's built with most all the code intact on Zeta now. Just need to route the keyboard presses, and it's up to speed with the Win32 and OSX ports.
 
Hi P.S.!

Sorry for replying so late.. :-/
Anyhow, it's cool to see you work on 3D stuff! Loving it.. 8-)

Hope the alpha 4 driver is to your liking.

Good luck!

Rudolf.
 
Post a Comment



<< Home

This page is powered by Blogger. Isn't yours?