On 01/04/2016 09:25 PM, Ilia Mirkin wrote:
On Mon, Jan 4, 2016 at 3:13 PM, Samuel Pitoiset
<samuel.pitoi...@gmail.com> wrote:
On 01/03/2016 05:37 AM, Ilia Mirkin wrote:
Signed-off-by: Ilia Mirkin <imir...@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.)
We discussed about that on IRC and the plan is to update compute.c once
the interface will be more suitable (when BUFFER/IMAGE will be
implemented) because this RES thing is weird and need to be removed.
This patch is :
Acked-by: Samuel Pitoiset <samuel.pitoi...@gmail.com>
Thanks!
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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
