[Mesa-dev] sampler types in tgsi

[Roland Scheidegger]

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 <jfonseca at 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: 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=