brianp at vmware.com
Thu Nov 7 08:14:10 PST 2013
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
>>>>> 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
>>> , there are 80 other failed tests, the ones I examined were all the
>>> 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.
More information about the mesa-dev