[Mesa-dev] sampler types in tgsi

[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=