I've got no problem with that if somebody wants to do it. Marek
On Mon, Dec 1, 2014 at 1:18 PM, Roland Scheidegger <srol...@vmware.com> wrote: > IIRC there were some brief plans to actually deprecate the tex opcodes > at some point and just use the sample ones, which would clean up tgsi a > bit (having both isn't terribly nice, you can't actually mix them in the > same shader etc.). But I think that idea was quickly dropped and not > really seriously considered (too much work, too disruptive, might even > need new opcode for expressing TXP for old hardware etc.). But if you > had sampler view dcls that would go in that direction... > > Roland > > Am 29.11.2014 um 19:50 schrieb Ilia Mirkin: >> 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
