On 30 July 2015 at 12:00, Stefan Dösinger stefan@codeweavers.com wrote:
if (depth->format_flags & WINED3DFMT_FLAG_FLOAT)
scale = gl_info->float_polyoffset_scale;
else
scale = gl_info->fixed_polyoffset_scale;
Ideally this would be a format property. In practice it probably works because we only use 24 and 32 bit depth formats, and the hardware probably either only distinguishes between 16 and 24/32, or just doesn't support 32.
- while(1)
I would have preferred that as "for (;;)"
- return powf(2, cur);
It seems the compiler is smart enough to work it out, but strictly speaking powf() takes floating point arguments.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2015-07-30 um 13:56 schrieb Henri Verbeet:
Ideally this would be a format property. In practice it probably works because we only use 24 and 32 bit depth formats, and the hardware probably either only distinguishes between 16 and 24/32, or just doesn't support 32.
I'm actually quite happy that we don't have to run this test for every format, mostly due to startup performance concerns...
Some Mesa drivers (r300g if I remember right) have some 16 vs 24 bit code in glPolygonOffset, but in practise it didn't matter. I haven't really debugged the driver to find out what's going wrong. (r200 has a suspiciously commented out offset *= 2, which is probably why it ends up wanting 2^24 instead of 2^23 like all the other drivers)
One suspicion I checked is that the driver looks at the GLX format instead of the FBO format, but changing the GLX format we request didn't influence the outcome.