[Mesa-dev] sampler types in tgsi

[Jose Fonseca]

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: ibmirkin at gmail.com [ibmirkin at gmail.com] on behalf of Ilia Mirkin [imirkin at alum.mit.edu]
Sent: 29 November 2014 18:05
To: Marek Olšák
Cc: Jose Fonseca; Roland Scheidegger; mesa-dev at 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 <maraeo at 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 <jfonseca at 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 at 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=