Adding "DCL SVIEW[0], 2D, UINT" would be precisely what I need. I just wanted to clarify that what Marek is talking about is way more complex than what my immediate needs are. However ARB_shader_image_load_store is "around the corner", so probably should start thinking about it.
I had already implemented the shader key by the time that I saw your suggestion though. I might rework it later to do the more generic thing. On Sat, Nov 29, 2014 at 1:28 PM, Jose Fonseca <jfons...@vmware.com> wrote: > Why can't you just get the type information from the t#0's declaration in > this case too, as I was suggesting? > > Jose > > > ________________________________________ > From: ibmir...@gmail.com [ibmir...@gmail.com] on behalf of Ilia Mirkin > [imir...@alum.mit.edu] > Sent: 29 November 2014 18:05 > To: Marek Olšák > Cc: Jose Fonseca; Roland Scheidegger; mesa-dev@lists.freedesktop.org > Subject: Re: [Mesa-dev] sampler types in tgsi > > This is the next level of sophistication... to be clear I was talking > about distinguishing sampler2D from isampler2D in glsl (and, if > possible usampler2D, but I'm pretty sure that wouldn't actually > matter). The issue is that the instructions are like > > sam (f32)(xyzw)r0.x, r0.z, s#0, t#0 > > vs > > sam (u32)(xyzw)r0.x, r0.z, s#0, t#0 > > I think that the gpu samples the value in some internal > representation, and then spits it out as either f32 or u32 as > requested. Since TGSI values are typeless, I can't tell how I'm > supposed to be returning it. > > For now I've just added a shader key. > > -ilia > > On Sat, Nov 29, 2014 at 7:42 AM, Marek Olšák <mar...@gmail.com> wrote: >> GLSL allows specifying sampler formats in shaders too, but it only >> appears to be allowed for GL_ARB_shader_image_load_store and it must >> match the sample view format, so that drivers can ignore it if they >> want. The format specification is complete except for component >> ordering. e.g. a shader can declare "rgba16_snorm", but it cannot >> declare "bgra16_snorm". >> >> Marek >> >> On Sat, Nov 29, 2014 at 8:43 AM, Jose Fonseca <jfons...@vmware.com> wrote: >>> On 29/11/14 06:07, Roland Scheidegger wrote: >>>> >>>> Am 29.11.2014 um 06:12 schrieb Ilia Mirkin: >>>>> >>>>> Hello, >>>>> >>>>> It appears that the A3XX ISA (freedreno) requires the texture >>>>> instruction to properly specify its output type (or at least f32 vs >>>>> u32). Now I could stick this into a driver-local shader key, but it >>>>> seems unfortunate since in glsl, it knows whether it's an int or float >>>>> sampler. >>>>> >>>>> Would there be any objections to being able to specify an int property >>>>> on the SAMP declaration? Or some alternate approach? >>>>> >>>> >>>> Hmm I guess the return type of the sampler_view decl was intended for >>>> something along these lines (it's a d3d10-ism but not really used right >>>> now, and it is per channel too). >>> >>> >>> Right -- >>> https://urldefense.proofpoint.com/v2/url?u=http-3A__msdn.microsoft.com_en-2Dus_library_windows_desktop_bb943976.aspx&d=AAIFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=nXlt_5vGi1RctORgwiMYVQlxu0sDao9j7V3TqLQDVdE&s=4JWo8Lk3FskpTEtiOhE2_H_3l3E1dBDlx9_3RtP-GTk&e= >>> >>>> If you make some return type in sampler >>>> this is thus not very nice as now you've got it both in sampler and >>>> sampler_view. Not sure what a good solution of that would be... >>> >>> >>> I think a good compromise would be to force separate declarations of >>> sampler_view and sampler, like we need to do for D3D10 sample opcodes >>> >>> >>> DCL SVIEW[0], 2D, UINT >>> DCL SAMP[0] >>> TEX OUT[1], IN[1], SAMP[0] >>> >>> at least for the UINT resources. >>> >>> >>> I also think that eventually we should have TGSI to drop the opcodes that >>> take combined sampler and sampler_views, have only the D3D10 like opcodes >>> with seperate operands for sampler and sampler_view, and have a >>> PIPE_CAP_SEPARATE just for those drivers that can handle the combination. >>> But this can wait. >>> >>> >>> Jose >>> >>> >>> _______________________________________________ >>> 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=AAIFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=nXlt_5vGi1RctORgwiMYVQlxu0sDao9j7V3TqLQDVdE&s=2F-pljeLmd65m_fud1zmCAXidHYZUbuOcIVbJTaIodQ&e= _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
