[Mesa-dev] sampler types in tgsi

[Marek Olšák]

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 <sroland at 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 <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=
>