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 <jfons...@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 <mar...@gmail.com> >>> Sent: 16 November 2014 15:51 >>> To: Jose Fonseca >>> Cc: Ilia Mirkin; mesa-dev@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 <jfons...@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@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= > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
