[Mesa-dev] DEFAULT_SOFTWARE_DEPTH_BITS=31

[burlen]

On 11/07/2013 08:45 AM, burlen wrote:
> On 11/07/2013 08:14 AM, Brian Paul wrote:
>> On 11/07/2013 09:09 AM, burlen wrote:
>>> On 11/07/2013 06:42 AM, Brian Paul wrote:
>>>> On 11/06/2013 04:59 PM, burlen wrote:
>>>>> On 11/06/2013 12:58 PM, Brian Paul wrote:
>>>>>> On 11/06/2013 12:34 PM, burlen wrote:
>>>>>>> When I build osmesa with --with-osmesa-bits=32 I notice that I 
>>>>>>> get 31
>>>>>>> bits by way of the compile line define
>>>>>>> -DDEFAULT_SOFTWARE_DEPTH_BITS=31.
>>>>>>> What's the story with the number 31? Is 31 bits really better 
>>>>>>> than 32?
>>>>>>
>>>>>> IIRC, 32 bit Z never worked properly because of float->int 
>>>>>> conversion
>>>>>> problems and such.  I think I found that 31 bits worked though.  
>>>>>> It's
>>>>>> been a long time...
>>>>>>
>>>>>
>>>>> I'm using OSMesa with VTK for rendering on systems that do not have
>>>>> graphics hardware. I need higher than default depth buffer with 
>>>>> OSMesa
>>>>> to prevent z-buffer fighting artifacts in some cases when 
>>>>> rendering in
>>>>> parallel. I found that --with-osmesa-bits=32 does the trick. however
>>>>> when building osmesa with 32 bits, most line rendering fails. Here 
>>>>> is a
>>>>> representative image diff from our regression suite that shows an
>>>>> example of the bug
>>>>> https://urldefense.proofpoint.com/v1/url?u=http://open.cdash.org/testDetails.php?test%3D216532438%26build%3D3087854&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0A&m=%2BYxiKNKy6tM2b9uufQKWyLEbSfkSZWpC8Kv9gQu9jJs%3D%0A&s=0f54945a95ef4530f46e70322823ee22159a9400fe3fae6b9c4a324a93ee3c00 
>>>>>
>>>>>
>>>>> <https://urldefense.proofpoint.com/v1/url?u=http://open.cdash.org/testDetails.php?test%3D216532438%26build%3D3087854&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0A&m=RSWC%2F0O7rDfFjJWLpUVeoSImwj8RMeWUaKnhSM%2Fx2Nk%3D%0A&s=11a634d8629f9a7fc613440fd0337a158f6951974892d2427bae4b5f570ad641> 
>>>>>
>>>>>
>>>>> , there are 80 other failed tests, the ones I examined were all the
>>>>> same.
>>>>>
>>>>> Experimenting with --with-osmesa-bits options, I've found that 
>>>>> using 32
>>>>> causes the issue, while using 8 , 16 or not using it all doesn't. 
>>>>> Do you
>>>>> have any idea about this?
>>>>
>>>> I set DEFAULT_SOFTWARE_DEPTH_BITS=32 and tried a few demo programs and
>>>> they look OK so far.
>>>>
>>>> Could you possibly create an apitrace of one of the failing cases?
>>>>
>>> did you set DEFAULT_SOFTWARE_DEPTH_BITS=32 or --with-osmesa-bits=32?
>>> --with-osmesa-bits=16 also sets depth bits to 31, and that case doesn't
>>> have the problem. so seems that it's something other than the depth 
>>> bits
>>> about the --with-osmesa-bits=32 build.
>>
>> I did -DDEFAULT_SOFTWARE_DEPTH_BITS=32
>>
>>
>>> I'll see about the apitrace
>>
>> I'm not actually sure what it'll do with OSMesa.  But if you can get 
>> anything and I can make a text dump of the GL calls that'll help.
>>
> apitrace crashes hard with OSMesa. Works fine when I use my ATI 
> drivers though. Not sure what the deal is, but looks like that may be 
> a dead end.
>
>
I learned from the apitrace mailing list apitrace is currently 
incompatible with OSMesa. -DDEFAULT_SOFTWARE_DEPTH_BITS=32, doesn't 
trigger the issue, you'll need --with-osmesa-bits=32. I filed an 
official bug report so it doesn't get lost.

Thanks
Burlen