[Mesa-dev] [PATCH 1/8] tgsi: add ureg support for image decls

[Ilia Mirkin]

On Mon, Jan 4, 2016 at 3:13 PM, Samuel Pitoiset
<samuel.pitoiset at gmail.com> wrote:
> On 01/03/2016 05:37 AM, Ilia Mirkin wrote:
>> Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>
>> diff --git a/src/gallium/auxiliary/tgsi/tgsi_strings.c
>> b/src/gallium/auxiliary/tgsi/tgsi_strings.c
>> index fd926b3..ae30399 100644
>> --- a/src/gallium/auxiliary/tgsi/tgsi_strings.c
>> +++ b/src/gallium/auxiliary/tgsi/tgsi_strings.c
>> @@ -54,8 +54,8 @@ static const char *tgsi_file_names[] =
>>      "IMM",
>>      "PRED",
>>      "SV",
>> -   "RES",
>> -   "SVIEW"
>> +   "IMAGE",
>> +   "SVIEW",
>>   };
>
>
> You forgot to update src/gallium/tests/trivial/compute.c, and so you did
> break all of those compute tests. Please don't break them because they are
> useful for people which work on compute. :-)

Can I update it by deleting it? Like I was saying, all that stuff
needs to be reworked... since compute.c doesn't *actually* work with
anything, and actively conflicts with plans for OpenGL things, I see
no problem with just invalidating the interfaces it was using. (This
is also why I was discouraging people from trying to do TGSI with
compute without considering these things first.)

>> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
>> b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
>> index beb67fe..87c5dc1 100644
>> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
>> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
>> @@ -348,7 +348,7 @@ static nv50_ir::DataFile translateFile(uint file)
>>      case TGSI_FILE_PREDICATE:       return nv50_ir::FILE_PREDICATE;
>>      case TGSI_FILE_IMMEDIATE:       return nv50_ir::FILE_IMMEDIATE;
>>      case TGSI_FILE_SYSTEM_VALUE:    return nv50_ir::FILE_SYSTEM_VALUE;
>> -   case TGSI_FILE_RESOURCE:        return nv50_ir::FILE_MEMORY_GLOBAL;
>> +   //case TGSI_FILE_RESOURCE:        return nv50_ir::FILE_MEMORY_GLOBAL;
>
>
> You definitely break global ressources here. What is your plan for that? Are
> you going to fix them in upcoming patches?

What are global resources needed for? Anyways, if it's *actually*
necessary for anything (and I've yet to see what that might be), one
could have a GLOBAL bit on a BUFFER declaration, much like the ATOMIC
flag (and I plan on also having a SHARED flag you can set for
compute). The previous thing with fixed large indices was a pretty big
hack anyways.

  -ilia