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

[Roland Scheidegger]

Am 17.11.2014 um 16:21 schrieb Jose Fonseca:
> 
> On 17/11/14 13:32, Ilia Mirkin wrote:
>> 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.]
> 
> I forgot to say it explicitely, but I meant supporting this on llvmpipe
> (or more accurately, in draw module.)
I am not entirely sure it doesn't just work. At least for layer no draw
interaction should be needed, and the corresponding gs or vs output
should be used automatically.
For viewports, I think this won't quite work without changes, since in
draw it is assumed only gs can write this (see
draw_current_shader_viewport_index_output /
draw_current_shader_uses_viewport_index and it looks like the tgsi
shader info writes_viewport_index would also only be set for gs and not
vs. Actually for the latter it seems writes_layer would also only be set
for gs but it seems it's not actually used...). I might give it a try
and see if that makes things working.

Roland


> 
>> 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?
> Sure. I don't have any objection this going in as is, as it is
> consistent with what was done in there already.  It  was more a remark
> for future code.
> 
> Jose
> 
>>
>>    -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
> 
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=AAIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=ulL6l0yQCPQu7dXZYTJVwEbLgWp51tMjs20RmUyUjv4&s=jcnwhYY6bP_393RBg5P-97x4xOWeHWSP8F14grDeECw&e=
>