[Mesa-dev] ARB_fragment_layer_viewport in gallium

[Roland Scheidegger]

Am 18.09.2014 00:37, schrieb Ilia Mirkin:
> On Wed, Sep 17, 2014 at 6:28 PM, Roland Scheidegger <sroland at vmware.com> wrote:
>> ARB_fragment_layer_viewport is enabled unconditionally if geometry
>> shaders / multiple viewports are also enabled. This seems reasonable,
> 
> I avoided adding a cap when adding the feature. Another option was
> adding it... but it seemed to work on all the drivers, and not like an
> unreasonable ask for any future driver supporting viewports (radeonsi,
> softpipe).
> 
>> though I noticed at least it won't work for llvmpipe - entirely due to
>> the requirement of the viewport/layer value being zero if it wasn't
>> output by the gs (or if no gs is present).
>> I couldn't actually figure out if that would be required for d3d10
>> (which has this functionality as well) too, though tests don't seem to
>> require it (or we otherwise get lucky).
>> I'm wondering if other drivers have a problem with that as well? I
> 
> nv50/nvc0/r600 all pass the relevant piglits. on nv50/r600, the
> layer/viewport are passed around as explicit varyings to the FS, which
> I guess tend to be 0's when not actually supplied, on nvc0 they're
> built-in, but I guess reflect the draw state. I was sure it worked on
> llvmpipe as well, but perhaps I only checked early in the piglit test
> development stage...
They are explicit varyings in llvmpipe as well. The problem is we don't
have default values anywhere for non-existing varyings (and we can't
have them in the fs as we'd be required to recompile the fs depending on
the gs in this case which we want to avoid). So these inputs get
essentially set up as a copy of whatever was at output zero (usually
position). Maybe there's a clever way to fix this but I don't really see
it...



> 
>> thought it would be trivial to fix but not so actually for llvmpipe.
>> (Essentially would need to note if fs reads layer/vp_index when scanning
>> the shader, then inject some appropriate zero output in draw somewhere,
>> probably draw_prepare_shader_outputs(). At this point the extension
>> doesn't seem worth it anymore at least if d3d10 would not require that
>> behavior neither since it isn't in any GL core version.)
>> But I guess if it's just draw having a problem with that it's not worth
>> a cap bit neither...
>>
>> Roland
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0A&m=2DZb3NiITQGfcv4HMSXOuLYyUVJroypoLE6chHffpJ0%3D%0A&s=9bd3d48917b8f0ef64c38cedaf80c5bf766ad15452416874619f68c14bdc2d80