[Mesa-dev] mesa state tracker geometry shader bits

Roland Scheidegger sroland at vmware.com
Wed Oct 16 15:33:43 CEST 2013

Pretty sure though we only implement half of it, as we should clamp
incoming depth values at depth buffer time (either coming from
interpolated depth or fragment shader output) to the near and far depth
range. So we only implement the part affecting the clipping, but don't
consider the consequences this has on depth values later per-fragment.
If tests don't detect this, I guess they just aren't sufficient...
But we could just say it is supported, and consider this a bug.


Am 16.10.2013 03:14, schrieb Jose Fonseca:
> Yep, as Marek said, llvmpipe passes all piglit's ARB_depth_clamp tests if PIPE_CAP_DEPTH_CLIP_DISABLE to 1.  So I'll push this change soon.
> softpipe passes depth_clamp, but fails depth-clamp-range. No idea why.
> Jose
> ----- Original Message -----
>> I'm pretty sure that depth clip disable is implemted too
>> (pipe_rasterizer_state::depth_clip, in draw_context.c update_clip_flag() ).
>> We merely forgot to advertise PIPE_CAP_DEPTH_CLIP_DISABLE flag on
>> llvmpipe/softpipe/any-draw-based-driver.
>> Roland started working on seamless cubemaps, so it's only a matter of time.
>> MSAA is the only thing for which there is no plan to do anything about in the
>> foreseeable future.
>> Jose
>> ----- Original Message -----
>>> GL_ARB_depth_clamp seems to be implemented in Draw and llvmpipe even
>>> passes the tests.
>>> Marek
>>> On Tue, Oct 15, 2013 at 9:15 PM, Dave Airlie <airlied at gmail.com> wrote:
>>>> On Tue, Oct 15, 2013 at 7:58 PM, Jose Fonseca <jfonseca at vmware.com>
>>>> wrote:
>>>>> ----- Original Message -----
>>>>>> Hi,
>>>>>> I pulled Brian's patches and then hacked llvmpipe locally to claim GL
>>>>>> 3.2,
>>>>>> and ran piglit, fixed some of the obviously missing pieces and crashes.
>>>>>> These aren't immediately going to expose any new functionality, but it
>>>>>> might help if someone doing r600g or nouveau support can concentrate on
>>>>>> their
>>>>>> driver.
>>>>>> Any objections to pushing them?
>>>>> Sounds great to me.  The more testing llvmpipe gets the better.  Thanks
>>>>> for doing this.
>>>> It seems to pass nearly as many as Paul reported for Ivybridge, the
>>>> fails seems to be in the generic code anyways.
>>>>> Actually, if things are not too broken, I'd really would like to get
>>>>> llvmpipe to advertise 3.2 out of the box.  It would imply lying about
>>>>> MSAA of course, but I think that that would be acceptable (and even
>>>>> preferable) for a SW renderer.
>>>> If people agree I'd like to do that as well, anyone got any objections
>>>> to initially lying about softpipe and llvmpipe? for 3.2 depth clip
>>>> disable and seamless cube map would be needed on top of the two
>>>> multisample extensions.
>>>> Dave.
>>>> _______________________________________________
>>>> mesa-dev mailing list
>>>> mesa-dev at lists.freedesktop.org
>>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev

More information about the mesa-dev mailing list