16 bits ZBuffer + native aniso?

This forum is for general developer support questions.
User avatar
Daytona675x
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 34
Joined: Wed Jan 22, 2014 5:18 pm
Location: Cologne, Germany
Contact:

Re: 16 bits ZBuffer + native aniso?

Post by Daytona675x »

@Crisot
I've seen in last Warp3D update there is a support for 16 bits ZBuffering with R200 driver. But I don't know how to enable it. I tryed with W3D_Hint(), but the precision is allways the same. Looks like I allways have 32 bits ZBuffer, but I'd like to try 16 bits to gain some speed where excellent precision isn't needed.
There were serious issues with 16bit z-buffer support on r200 and r100.

Yes, you are correct:
you can use W3D_Hint to switch between 24bit (+8bit stencil) and 16bit depth buffer on r100 / r200.
At least that's the effect that hint has on those devices, or the effect it is supposed to have.

The fact that you did not see any precision difference is simply because the 16bit support was broken.
While the driver allocated only a half-sized z-buffer internally, it forgot to notify the GPU of this fact. So the GPU still thought it was in the default 24+8 state...

Now, if you were lucky then the z-buffer's VRAM area was far away from your texture data and the color-buffer etc., so that you only experienced no change at all.
If you had bad luck then you would experience trashed textures / garbage in the color-buffer or even freezes.

Moreover the read/write Z pixel/span functions did not consider the 16bit mode. So the addresses were calculated for a 24+8 z-buffer always (that 24+8 address calculation was broken itself too btw., so all those functions didn't work at all).

This has all been fixed for the next driver releases.

Regarding anisotropic filtering:
There was a bug that could cause the internal texture format value to become corupt, essentially containing wrong data for the anisotropy parameter. This has been fixed too.

However:
I tried your universe-thetrip demo and it is pretty broken. From what I can see I strongly doubt that this is due to Warp3D. To me it looks like you're doing something fundamentally wrong, like for example destroying your original texture data etc.
It would be great if you would let me peek into your sources to rule out (or rule in ;-) ) W3D specific issues.
Warp3D driver code-basher and bug-smasher - btw.: driver writing is nothing mysterious
Post Reply