[Mesa-stable] [Mesa-dev] [PATCH] st/mesa: add a fallback for clear_with_quad when no vs_layer

[Ilia Mirkin]

Well, nvidia hw (pre-GM204; it seems like it's supported there now)
doesn't support setting gl_Layer from VS, so it's just not an option
there. However I do believe that the HW has enough support to handle
color masking as well as scissors, so I might try to add a PIPE_CAP
which indicates that pipe->clear can do it all. [First I'd have to
double-check that the nvidia hw really can support all this stuff
properly.]

On the subject of strings -- yeah, parameterizing strings is annoying.
When parameters are involved, using ureg_* seems like the better way
to go. However for static shaders like this, it'll be hard to beat the
readability of a plain string. Either way, I was just copying the way
that the existing (gl_Layer-using) vertex shader was implemented.

Perhaps the decision of whether to do it one way or another can be
arrived at separately from this change?

  -ilia

On Mon, Nov 17, 2014 at 8:20 AM, Jose Fonseca <jfonseca at vmware.com> wrote:
> Hi Marek,
>
>> First of all, sorry for breaking Draw yesterday.
>
> No problem. draw_llvm.c was really obfuscating the fact that it relied on the layout of the pipe_viewport_state.
>
>> There's also the OpenGL extension AMD_vertex_shader_layer which is
>> supported by all GS-capable Mesa drivers except for nouveau and
>> llvmpipe I think.
>
> I see. It sounds we should try to support these things from vs then.
>
>> tgsi_parse is something else. Did you mean tgsi_text_translate?
>
> Yes, I meant tgsi_text_translate.
>
>> I
>> don't like using ureg for helper shaders unless I have to. Shaders
>> written with ureg are harder to read and the code is longer. I've been
>> thinking of rewriting all simple shaders to text.
>
> I don't think that's a good idea.
>
> Besides all the reasons I said before, string constants are not convenient to parameterize.  One needs to have multiple versions of the text file, or use snprintf. either way quite ugly.
>
> Regarding readability, if one has a comment before the code is just as readable. This is not what's done in u_simple_shaders.c, but we use this approach elsewhere and it works quite nicely:
>
>    [...]
>
>    /* DP3 TEMP.w, SRC, SRC */
>    ureg_DP3(tbi->prog, temp_dst_w, src, src);
>
>    /* RSQ TEMP.w, TEMP.w */
>    ureg_RSQ(tbi->prog, temp_dst_w, temp_src_w);
>
>    [...]
>
>
> If people feel strongly about writing helper TGSI shaders in plain text, then we should create a simple off-line compilation tool that compiles the TGSI and creates *.h files (similar like DirectX HLSL tools).
>
>
> Jose
>
> PS: Apologies for quoting only parts of the email. I'm sort of limited to using Outlook Web Access for email when working from home, and need to manually quote...
>
> ________________________________________
> From: Marek Olšák <maraeo at gmail.com>
> Sent: 16 November 2014 15:51
> To: Jose Fonseca
> Cc: Ilia Mirkin; mesa-dev at lists.freedesktop.org; 10.3 10.4
> Subject: Re: [Mesa-dev] [PATCH] st/mesa: add a fallback for clear_with_quad when no vs_layer
>
> Hi Jose,
>
> First of all, sorry for breaking Draw yesterday.
>
> On Sun, Nov 16, 2014 at 2:57 PM, Jose Fonseca <jfonseca at vmware.com> wrote:
>>> Fun fact -- llvmpipe also needs this.
>>
>> I think this is because this functionality was developed with D3D10 in mind, and
>>
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__msdn.microsoft.com_en-2Dgb_library_windows_desktop_bb509647.aspx&d=AAIBaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=W_WiVknXaiEWMUhwH9NoKnxZ7SZQGp1B1VyLSBhv0rU&s=hwsRL-R8OHz5lpkwIvnmSRlHe-ijQAReKLFMkeVDWHM&e=
>>
>> states that SV_RenderTargetArrayIndex "an be written from the geometry shader and read by the pixel shader."
>
> There's also the OpenGL extension AMD_vertex_shader_layer which is
> supported by all GS-capable Mesa drivers except for nouveau and
> llvmpipe I think.
>
>>
>>
>> BTW, coding these helper shaders as text is not a great idea IMO:
>>
>> - The tgsi_parse thing was written for debugging purposes mainly.
>>
>> - Whenever there are TGSI interface changes, any breakage with ureg will cause compile errors, where as it will only be detected at runtime with TGSI
>>
>> - ureg module makes it really easy to write shaders.  It's not really much more work.
>
> tgsi_parse is something else. Did you mean tgsi_text_translate? I
> don't like using ureg for helper shaders unless I have to. Shaders
> written with ureg are harder to read and the code is longer. I've been
> thinking of rewriting all simple shaders to text.
>
> Marek