View Full Version : 9700 Pro 16-bit AA enabled in leaked drivers!
And to think I've had these drivers installed for days and didn't even notice! :lol:
http://benchmarksims.com/benchmarksims/images/shots/snap3.jpg
In fact, the drivers force the application to 32-bit mode. This can be seen for example in smoke, fog and explosions, as there is no dithering despite application being originally 16-bit only.
In fact, the drivers force the application to 32-bit mode.
And this is bad because?...
This reminds me of the option in the 3dfx voodoo5 drivers of forcing 32bit color in GLIDE applications. This is a very good surprise indeed.
Bloody hell that looks nice!
TheMightyPuck
31-Dec-2002, 23:11
i'm putting gpl back in. what drivers are these?
In fact, the drivers force the application to 32-bit mode.
And this is bad because?...
Did I say it was bad? I think it's great news to those who play older games (like me).
These drivers are the 6275's (9081 for Win 9x) aka 7.83's aka Catalyst 3.1's, and they are still BETA.
Bambers
01-Jan-2003, 11:12
yep the BETA needs to be stressed a bit.
I tried these on my 8500 and got odd corruption in morrowind.
It seemed to be an overlclocking error and showed up as verticies of polygons being 'tied' to the center of the screen.
This worried me slightly as I thought I'd b0rked my card so I put clocks to default, got artefacts, checked the ram voltage and used a bit of pencil to bumb it back to 3.9v (the pencil seems to disappear after a while) and still got artefacting. Put the clocks to 275/275 and got more artefacting, at 250/250 the was a snow effect too. :lol:
I eventually had the core at 320 and the mem at 340 (:shock:) to get rid of the polygon sticking to the center problem only to get blue dots on textures and permenatly distorted polys appearing due to the memory giving the normal kind of too overclocked errors. On other driver versions I would start getting these at 325 mem. :)
OpenGL guy
01-Jan-2003, 11:26
These drivers are the 6275's (9081 for Win 9x) aka 7.83's aka Catalyst 3.1's, and they are still BETA.
Grr... I'd love to know who leaked them.:evil: Anyone find bugs with 16-bit AA on the 9700?
Vacation ends Thursday so I'd like to know what I can expect when I get back... ;)
OpenGL guy
01-Jan-2003, 11:28
In fact, the drivers force the application to 32-bit mode.
Not quite. :D
In fact, the drivers force the application to 32-bit mode.
Not quite. :D
Interesting. Could you then explain these pictures:
http://www.indiana.claranet.de/Driver_16Bit_AA.jpg
http://www.indiana.claranet.de/Driver_16Bit_NoAA.jpg
(taken from a thread at Rage3D)
Look at the smoke coming from the exhaust pipe.
Also the road seems to have some ugly color banding with AA enabled.
CarstenS
01-Jan-2003, 12:56
The smoke does not look like suffering from 16Bit Dithering, instead, i'd rather contribute this to the z- or framebuffer-compression.
Similiar things could be observed in Quake-I with the Tenebrae-mod (http://home.arcor.de/quasat/Tenebrae%20-%20Smoke%20-%20wrong%20-%20R300.jpg) right in the "skill select" hall.
Some forms of fog/transparency apparently are still a little glitchy.
In fact, the drivers force the application to 32-bit mode.
Not quite. :D
Interesting. Could you then explain these pictures:
http://www.indiana.claranet.de/Driver_16Bit_AA.jpg
http://www.indiana.claranet.de/Driver_16Bit_NoAA.jpg
(taken from a thread at Rage3D)
Look at the smoke coming from the exhaust pipe.
Appearently you haven't see 16bit AA shots before on any card. ;)
Think of AA as rendering in a larger resolution than scaling down the picture.
Scaling down evens out the of the dither pattern.
The smoke does not look like suffering from 16Bit Dithering, instead, i'd rather contribute this to the z- or framebuffer-compression.
It does look like 16Bit dithering...
Trust me. ;)
Similiar things could be observed in Quake-I with the Tenebrae-mod (http://home.arcor.de/quasat/Tenebrae%20-%20Smoke%20-%20wrong%20-%20R300.jpg) right in the "skill select" hall.
Some forms of fog/transparency apparently are still a little glitchy.
This is not even closely similar.
It looks like some serius bug.
The suspicious thing is that the left of the image is shifted downwards a few pixels.
You can see it on the message as well as the gun.
Eighter a driver bug or you have some hw problem.
I wouldn't call it "glitch" :)
CarstenS
01-Jan-2003, 13:54
Hi there :)
Dithering atrifacts as i know them do not come in pixel blocks similarly sized to certain Hyper-Z patterns, but it's just my guess ;)
^^ Forget this. Now the pic from Driver looks a whole lot different than before. I guess, my IE played a trick on me, the artifacts look differently, if you just look at them in an IE-window at different sizes.... :(
I agree, it looks (now at least) like 16Bit dithering)!
The other picture from Tenebrae is actually badly pasted together from two different screenshots, to show the difference. Sorry, i should have mentioned this.
Appearently you haven't see 16bit AA shots before on any card. ;)
Think of AA as rendering in a larger resolution than scaling down the picture.
Scaling down evens out the of the dither pattern.
That's true for supersampling. R9700 however uses multisampling.
Unless.. look at white lines on the road. They are part of the road texture, right? To me, they look like antialiased as well. Now, multisampling shouldn't AA textures. Maybe these drivers enable supersampling with 16-bit applications?
Look closely snk. You will see that the textures are sharper in the non AA'd picture, that would explain why the lines seems to have AA applied.
Maybe these drivers enable supersampling with 16-bit applications?
Well the 2D element (map) got blurrier.
Multisampling alone cannot cause this.
It's either supersampling or multisampling with a post filter (like quincunx).
Unfortunately I'm not near the machine with the R9700Pro so I can't test it.
Can someone measure the fillrate impact of AA in 16 bit?
OpenGL guy
01-Jan-2003, 20:25
Interesting. Could you then explain these pictures:
http://www.indiana.claranet.de/Driver_16Bit_AA.jpg
http://www.indiana.claranet.de/Driver_16Bit_NoAA.jpg
(taken from a thread at Rage3D)
Look at the smoke coming from the exhaust pipe.
Also the road seems to have some ugly color banding with AA enabled.
Of course I can explain it. A better question is will I? :D
As far as the application knows, everything is done in 16-bit. Thus, a lock on the backbuffer would still provide 16-bit data. However, all the AA calculations are done in 32-bit, thus you see improvements in dithering quality because less dithering is done.
Since no one responded to my other question about bugs with 16-bit AA, I guess it's working pretty well :D
K.I.L.E.R
02-Jan-2003, 03:30
Yes it is working well, OpenGL guy. :)
Seriously, how do the drivers get leaked without anyone being able to point the finger and finding out who the person was?
Colourless
02-Jan-2003, 07:41
Something that will not know that the option in the 3dfx Voodoo 4/5 drivers to force 32 Bit rendering in 16 bit Glide/OpenGL games wasn't actually supposed to be used by end users. It was actually pretty buggy.
There were 3 problems with it.
1: Depth Buffer precision changes caused Depth Bias settings to break. Depth Bias settings needed to be multiplied by 256 to act as expected.
2: Doing a read lock on the buffer would return 32 bit data, not 16 bit as expected. Note, strictly speaking this shouldn't matter as Glide did return the locked format, but apps always ignored it, or couldn't handle the return value. Locking the frame buffer for reading though was pretty much frowned upon since it didn't work with V1/V2 SLI systems. Fixing this isn't hard, but you'll get a non trivial speed penalty. When writing to a locked buffer though there isn't a problem as the write format is specified by the programmer and you don't actually have direct access to the frame buffer (LFB writing actually goes through the 3d pipeline).
3: The grLfbReadRegion() function will read 32 bit data instead of the expected 16 bit data. Since applications assume they are reading 16 bit data they only supply a buffer large enough for 16 bit data. Concequently, when reading the final line of the region, the buffer will be overrun. This is a VERY SERIOUS problem.
None of these were ever addressed in drivers released by 3dfx.
-Colourless
K.I.L.E.R
02-Jan-2003, 07:54
Those errors don't appear on the Radeon based cards AFAIK. :)
Played: FF8 and Blood 2.
The only game that I have tried to play in which I had problems with FSAA was NHL2003. It definitely has FSAA now, but some of the textures seem to be of worse quality than before (banding), specially in the pre-game cutscenes. It also has some major stuttering now.
I reverted back to the Cat's 3.
EasyRaider
11-Jan-2003, 16:59
Anyone tried System Shock 2?
A Sapphire 9700 (PRO) just got even more tempting.
Yep, looks better than ever at 6x AA.
Nagorak
12-Jan-2003, 00:18
Honestly, AA doesn't do much for that car game...I'm sorry to say...
horvendile
12-Jan-2003, 09:10
Those errors don't appear on the Radeon based cards
Played: FF8
Wohoo! Very good news indeed!
Looks like the second last obstacle for me buying an R300 is going away!
(The last one being money.)
Has anyone tested Gabriel Knight 3? I never got that to work with AA on my brother's 8500LE.
vBulletin® v3.8.6, Copyright ©2000-2013, Jelsoft Enterprises Ltd.