[Mesa-dev] [PATCH 0/8] gl_FragCoord and gl_FrontFacing as system values

Ilia Mirkin imirkin at alum.mit.edu
Fri Jan 8 15:17:49 PST 2016


On Fri, Jan 8, 2016 at 6:13 PM, Rob Clark <robdclark at gmail.com> wrote:
> On Fri, Jan 8, 2016 at 5:59 PM, Ian Romanick <idr at freedesktop.org> wrote:
>> On 01/08/2016 07:39 AM, Brian Paul wrote:
>>> On 01/07/2016 06:29 PM, Marek Olšák wrote:
>>>> Hi,
>>>>
>>>> This series adds the possibility for drivers to get gl_FragCoord and
>>>> gl_FrontFacing as system values. When FACE is a system value, it also
>>>> changes its type to integer from floating-point.
>>>>
>>>> Each variable has its own Const flag / Gallium CAP, so drivers can
>>>> choose whether they want this for each variable.
>>>>
>>>> This simplifies input handling in the radeonsi driver. With this, TGSI
>>>> INPUT[i] becomes fragment shader input[i] in the hardware, so the
>>>> driver doesn't have to do any translation of locations.
>>>>
>>>> Please review.
>>>
>>> Looks good overall.  I probably should have made fragcoord and
>>> frontfacing system values from day one.  We could probably migrate all
>>> the drivers to that convention over time.
>>
>> We can probably migrate frontfacing, but I don't think we can / should
>> for fragcoord.  On some hardware it's not a system value, and that
>> changes how we have to count the resource usage.
>
> although if hw treats it as a normal input, it is easier to append an
> input at the end, than reshuffle to remove an input..
>
> at any rate, at least for frontface, I think this would make it
> slightly easier for tgsi_to_nir to spit out NIR that is more similar
> to glsl_to_nir..  I don't remember, maybe I had to fixup fragcoord too
> on my mesa/st glsl_to_nir branch..

The frontfacing bit of this is definitely a no-brainer. I've already
pushed out a patch that makes use of it on nv50/nvc0. (Doesn't really
make sense on nv30 though, where there are no native integers.)

I'm a bit more hesitant about position -- I'd have to double-check the
details on nv50, but I think it might count against the fp input max.
(But I might be confusing it with vp position output...)

However this is all à la carte, so... not a problem -- get the driver
to do what's most convenient.

  -ilia


More information about the mesa-dev mailing list