[Mesa-dev] mesa state tracker geometry shader bits

[Jose Fonseca]

----- Original Message -----
> 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. 

We kind of already do that, src/gallium/drivers/llvmpipe/lp_bld_interp.c:

           if ((attrib == 0) && (chan == 2)){
               /* FIXME: Depth values can exceed 1.0, due to the fact that
                * setup interpolation coefficients refer to (0,0) which causes
                * precision loss. So we must clamp to 1.0 here to avoid artifacts
                */
               a = lp_build_min(coeff_bld, a, coeff_bld->one);
            }

I suppose we just need to update the comment to say that, in addition to the precision problem, there is also the potential for near/far clipping being disabled. 

And we should also clamp against zero, though, but only when near/far clipping is disabled, as there is no loss of precision near zero.

Jose

> 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.
> 
> Roland
> 
> 
> 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
> >>>
>