Re: [Mesa-dev] [PATCH] glsl: properly setting var-data.binding if explicit_binding is true
Timothy Arceri wrote
On Sun, 2015-04-26 at 15:23 +0200, Alejandro Piñeiro wrote:
On 26/04/15 00:08, Timothy Arceri wrote:
On Sat, 2015-04-25 at 18:46 +0200, Alejandro Piñeiro wrote:
There was a typo on commit c0cd5b, doing it when explicit_binding
was false. This prevented to use any binding point different to 0.
---
Taking into account the explanation on the header about the
variable binding (ast.h:553)
/**
* Binding specified via GL_ARB_shading_language_420pack's
binding keyword.
*
* \note
* This field is only valid if \c explicit_binding is set.
*/
int binding;
The binding is correct (and should be updated) if explicit_binding
is true.
But the current behaviour was updating it if it was false.
This was not detected by piglit because all the calls to
glBindBufferBase(GL_ATOMIC_COUNTER_BUFFER are using 0.
I tested this patch by running all piglit on my system, and I
didn't
detect regression. I also runned make check without issues.
https://bugs.freedesktop.org/show_bug.cgi?id=90175
You should probably convert your test program to a piglit test also
so
this bug can be detected if it happens again in the future.
There are several piglit tests at spec/arb_shader_atomic_counters
testing that you get what you expect while using atomic counters.
Probably it would be enough to just modify some of the already
existing
tests, using a non-zero binding point (for example at semantics.c).
But I don't have too much experience tweaking/creating piglit tests.
What option would be preferred for this case? A new test or just
modify
a little one of the already available?
Take a look at buffer-binding.c it would probably make sense to add your
subtest to this test.
Your test would probably look something like this:
static bool
run_test_explicit_binding(test params here)
{
/* test code */
if (explict_binding_set_incorrectly)
return false;
return true;
}
And you would add something like this to piglit_init()*/
if (piglit_is_extension_supported(GL_ARB_shading_language_420pack))
My bad you don't need the above if.
atomic_counters_subtest(status, GL_NONE,
Atomic buffer explicit binding
run_test_explicit_binding,
}
You would also need to update the comment at the top of the file.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/7] i965: use _mesa_geometry_width/height/layers/samples for programming geometry of framebuffer to GEN
Why make it two separate patches even? Seems silly (not to mention more work really). I guess the issue is the commit message portion saying for framebuffer_no_attachements.. perhaps I just change the commit to use new geometry function to indicate want geometry not buffer thingies. -Kevin -Original Message- From: Pohjolainen, Topi Sent: Monday, April 27, 2015 10:43 AM To: Rogovin, Kevin Cc: mesa-...@freedesktop.org Subject: Re: [Mesa-dev] [PATCH 5/7] i965: use _mesa_geometry_width/height/layers/samples for programming geometry of framebuffer to GEN On Fri, Apr 24, 2015 at 11:36:27PM +0300, Rogovin, Kevin wrote: I want to add one more comment on why to replace with the _mesa_geometry_ functions, which I had thought was so obvious I neglected to mention it: With this series the meaning of gl_framebuffer::Width, Height, and so on have a different meaning. They give the intersection of the backing stores of the render targets. In contrast, the _mesa_geometry_* functions give the geometry to feed a rasterizer/windower. By using _mesa_geometry_* functions the code communicates clearly it wants the geometry to feed windower/rasterizer and not the geometry of the intersection of the (potentially empty) set of backing stores. Moreover, it is better to be consistent as well, as later someone will likely wonder: why in Gen7 and higher are those _mesa_geometry functions used but not before? That question has no good answer because it does not make sense to not use those functions when programming the rasterizer/windower thingies. Could we split the patch in two? One part dealing with the necessary needed for gen7 and higher to support no_attachments and then another just making older gens consistent. -Kevin -Original Message- From: Rogovin, Kevin Sent: Friday, April 24, 2015 7:43 PM To: Pohjolainen, Topi Cc: mesa-...@freedesktop.org Subject: RE: [Mesa-dev] [PATCH 5/7] i965: use _mesa_geometry_width/height/layers/samples for programming geometry of framebuffer to GEN My point specifically was that you are also updating atoms that _are not_ re-used. And as those changes are not really needed, I wouldn't take the risk of changing something in vain. I would introduce them only when you have patches to really enable older generations. My take is the following: 1. Tracking (and guaranteeing) that those function left unchanged as is are exactly just those for before Gen7 is a pain. Much easier, and more reliable to hit them all instead. A significant number of functions in i965 are not emit functions of any atom but emit functions of atoms map to them. Again, more reliable and -safer- to change them all, then just the bare minimum. 2. The change is benign. If _HasAttachments is true, then the function substitution gives the same value. For Gens not supporting the extension there is no effect. 3. Lastly, as stated: for later it leaves the option to enable it for Gen6 and below, it is just trivial change, but it needs testing on hardware. When I writing this work, I originally had it for all Gens, but changed to support only Gen7and higher because that is all on which I can test it. -Kevin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GLSL versions that don't match GL versions
It sounds good. Marek On Mon, Apr 27, 2015 at 2:58 AM, Ilia Mirkin imir...@alum.mit.edu wrote: Hello, Right now a driver has to be very careful about the GLSL version it exposes, since it's computed separately from the GL version. The main/version.c:compute_version code uses the consts-GLSLVersion as an input, would there be any downside to having it also fix up the GLSL version as well? For example, if I advertise a GLSLVersion 400, but I'm missing, e.g., tess, or subroutines, or whatever, and the GL version goes down to 3.3, is there any harm in fixing it up to be 330? Among other things, _mesa_get_version does this for compat contexts, so I guess it should be OK? -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC 6/9] nir: Add an entirely C-based linked list implementation
On Mon, Apr 27, 2015 at 11:12 AM, Connor Abbott cwabbo...@gmail.com wrote: On Mon, Apr 27, 2015 at 1:36 PM, Eric Anholt e...@anholt.net wrote: Jason Ekstrand ja...@jlekstrand.net writes: This commit adds a C-based linked list implementation for NIR. Unlike exec_list in glsl/list.h, there is no C++ API. Also, this list is based on wl_list (from the Wayland project) which is, in turn, based on the kernel list. As such, it should be fairly familiar to people who have done anything in kernel space. Doesn't exec_list already have a C api? Yes, it does. However, exec_list has C++ constructors for exec_list and exec_node. In the patches that follow, I use linked lists for use/def sets for registers and SSA values. In order to do so, I have to be able to place lists and links inside of unions. Since exec_list and exec_node have constructors, doing so causes any C++ code that includes nir.h to die in a fire. Therefore, we can't just use exec_list. What about simple_list? Why re-create it? I thought about that too. However, the simple_list is badly named and the API isn't that great. Making it usable as a first-class datastructure would have taken as much work as adding nir_list. Also, simple_list isn't really a standard as it's only ever used in errors.c and the vc4 driver. Why a kernel list; why not keep the symantics of exec_list? The short version: I like it better. Also, while exec_list is familiar to people who have worked inside the mesa GLSL compiler, I think that the kernel list will be more familiar to people in the open-source graphics community in general. For whatever it's worth, I explicitly designed it with separate nir_list and nir_link structures so that we can switch from kernel list to exec_list symantics if we want to. Why put this in NIR and not in util? At the moment, NIR is the only user. I do expect that Eric may want to use it in vc4 over simple_list. However, vc4 is already using NIR anyway, so it's not really that polluting. It has also been suggested by Ken that we just pull the C bits out of exec_list and keep one underlying implementation for both C and C++ only with different names. While I think that this is definitely doable and may be the best long-term solution, I didn't want to do that refactoring prior to getting this series up-and-going and adding a list was easier. I'm ok with doing that instead of adding a list. Yes, please! I have never liked exec_list, and being gratuitously different from the other projects that we work on (linux, X) is really frustrating. I'd like us to use the same actual names as the kernel does if possible, but I understand if for now we want to have namespaced names for the functions because we might need to interact with two different types of lists. FWIW, if we want to go through with this (which it seems like a pretty big performance win and it gives us a lot more determinism, so why not?) then the consensus is that we should take gallium's u_double_list.h and move it to src/util/list.h. We'd need to clean up a few things, like s/INLINE/inline/ and perhaps make the iterators not ALL_CAPS, and we'd need to add C99-style iterators for NIR, but otherwise it's basically the same as the kernel list. Right. I think I'll take Rob's suggestion to make lower_case iterators for C99 and leave the UPPER_CASE ones for non-c99. the s/INLINE/inline should be easy and I'll get it moved to util/list.h --Jason ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl: fix packing support for arrays of doubles
Broke in commit f00c5f85b82efe9535b18dbf97c4591fb28aeae6 when adding support for multidimensional arrays --- src/glsl/lower_packed_varyings.cpp | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/glsl/lower_packed_varyings.cpp b/src/glsl/lower_packed_varyings.cpp index f8e79bd..d8bebb5 100644 --- a/src/glsl/lower_packed_varyings.cpp +++ b/src/glsl/lower_packed_varyings.cpp @@ -645,8 +645,8 @@ lower_packed_varyings_visitor::needs_lowering(ir_variable *var) if (var-data.explicit_location) return false; - if (var-type-without_array()-vector_elements == 4 - !var-type-is_double()) + const glsl_type *type = var-type-without_array(); + if (type-vector_elements == 4 !type-is_double()) return false; return true; } -- 2.1.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] r600g, radeonsi: add driver queries for GPU temperature and shader+memory clocks
On Mon, Apr 27, 2015 at 9:46 AM, Marek Olšák mar...@gmail.com wrote:
From: Marek Olšák marek.ol...@amd.com
---
src/gallium/drivers/radeon/r600_pipe_common.c | 13 +++--
src/gallium/drivers/radeon/r600_pipe_common.h | 3 +++
src/gallium/drivers/radeon/r600_query.c | 21
+
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 19 +++
src/gallium/winsys/radeon/drm/radeon_winsys.h | 5 -
5 files changed, 58 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c
b/src/gallium/drivers/radeon/r600_pipe_common.c
index c6d7918..97eed13 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.c
+++ b/src/gallium/drivers/radeon/r600_pipe_common.c
@@ -665,12 +665,21 @@ static int r600_get_driver_query_info(struct
pipe_screen *screen,
{num-bytes-moved, R600_QUERY_NUM_BYTES_MOVED, 0, TRUE},
{VRAM-usage, R600_QUERY_VRAM_USAGE,
rscreen-info.vram_size, TRUE},
{GTT-usage, R600_QUERY_GTT_USAGE,
rscreen-info.gart_size, TRUE},
+ {temperature, R600_QUERY_GPU_TEMPERATURE, 100, FALSE},
+ {shader-clock, R600_QUERY_CURRENT_GPU_SCLK, 0, FALSE},
+ {memory-clock, R600_QUERY_CURRENT_GPU_MCLK, 0, FALSE}
};
+ unsigned num_queries;
+
+ if (rscreen-info.drm_major == 2 rscreen-info.drm_minor = 42)
+ num_queries = Elements(list);
Would it makes sense to future-proof this a bit and allow for drm_major of
2?
e.g.
if (rscreen-0info.drm_major 2 || (rscreen-info.drm_major == 2
rscreen-info.drm_minor = 42))
--Aaron
+ else
+ num_queries = 8;
if (!info)
- return Elements(list);
+ return num_queries;
- if (index = Elements(list))
+ if (index = num_queries)
return 0;
*info = list[index];
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.h
b/src/gallium/drivers/radeon/r600_pipe_common.h
index 384a9a6..c23072c 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.h
+++ b/src/gallium/drivers/radeon/r600_pipe_common.h
@@ -55,6 +55,9 @@
#define R600_QUERY_NUM_BYTES_MOVED (PIPE_QUERY_DRIVER_SPECIFIC + 5)
#define R600_QUERY_VRAM_USAGE (PIPE_QUERY_DRIVER_SPECIFIC + 6)
#define R600_QUERY_GTT_USAGE (PIPE_QUERY_DRIVER_SPECIFIC + 7)
+#define R600_QUERY_GPU_TEMPERATURE (PIPE_QUERY_DRIVER_SPECIFIC + 8)
+#define R600_QUERY_CURRENT_GPU_SCLK(PIPE_QUERY_DRIVER_SPECIFIC + 9)
+#define R600_QUERY_CURRENT_GPU_MCLK(PIPE_QUERY_DRIVER_SPECIFIC + 10)
#define R600_CONTEXT_STREAMOUT_FLUSH (1u 0)
#define R600_CONTEXT_PRIVATE_FLAG (1u 1)
diff --git a/src/gallium/drivers/radeon/r600_query.c
b/src/gallium/drivers/radeon/r600_query.c
index 6a35ab8..758064a 100644
--- a/src/gallium/drivers/radeon/r600_query.c
+++ b/src/gallium/drivers/radeon/r600_query.c
@@ -86,6 +86,9 @@ static struct r600_resource
*r600_new_query_buffer(struct r600_common_context *c
case R600_QUERY_NUM_BYTES_MOVED:
case R600_QUERY_VRAM_USAGE:
case R600_QUERY_GTT_USAGE:
+ case R600_QUERY_GPU_TEMPERATURE:
+ case R600_QUERY_CURRENT_GPU_SCLK:
+ case R600_QUERY_CURRENT_GPU_MCLK:
return NULL;
}
@@ -382,6 +385,9 @@ static struct pipe_query *r600_create_query(struct
pipe_context *ctx, unsigned q
case R600_QUERY_NUM_BYTES_MOVED:
case R600_QUERY_VRAM_USAGE:
case R600_QUERY_GTT_USAGE:
+ case R600_QUERY_GPU_TEMPERATURE:
+ case R600_QUERY_CURRENT_GPU_SCLK:
+ case R600_QUERY_CURRENT_GPU_MCLK:
skip_allocation = true;
break;
default:
@@ -439,6 +445,9 @@ static void r600_begin_query(struct pipe_context *ctx,
struct pipe_query *query)
case R600_QUERY_REQUESTED_GTT:
case R600_QUERY_VRAM_USAGE:
case R600_QUERY_GTT_USAGE:
+ case R600_QUERY_GPU_TEMPERATURE:
+ case R600_QUERY_CURRENT_GPU_SCLK:
+ case R600_QUERY_CURRENT_GPU_MCLK:
rquery-begin_result = 0;
return;
case R600_QUERY_BUFFER_WAIT_TIME:
@@ -513,6 +522,15 @@ static void r600_end_query(struct pipe_context *ctx,
struct pipe_query *query)
case R600_QUERY_GTT_USAGE:
rquery-end_result = rctx-ws-query_value(rctx-ws,
RADEON_GTT_USAGE);
return;
+ case R600_QUERY_GPU_TEMPERATURE:
+ rquery-end_result = rctx-ws-query_value(rctx-ws,
RADEON_GPU_TEMPERATURE) / 1000;
+ return;
+ case R600_QUERY_CURRENT_GPU_SCLK:
+ rquery-end_result = rctx-ws-query_value(rctx-ws,
RADEON_CURRENT_SCLK) * 100;
+ return;
+ case R600_QUERY_CURRENT_GPU_MCLK:
+ rquery-end_result = rctx-ws-query_value(rctx-ws,
RADEON_CURRENT_MCLK) * 100;
+
Re: [Mesa-dev] [RFC 7/9] nir/nir: Use a linked list instead of a has set for use/def sets
On Mon, Apr 27, 2015 at 5:25 PM, Jason Ekstrand ja...@jlekstrand.net wrote:
On Mon, Apr 27, 2015 at 1:35 PM, Connor Abbott cwabbo...@gmail.com wrote:
On Fri, Apr 24, 2015 at 7:32 PM, Jason Ekstrand ja...@jlekstrand.net wrote:
+struct nir_if;
+
typedef struct nir_src {
union {
+ nir_instr *parent_instr;
+ struct nir_if *parent_if;
+ };
There's something I'm not quite understanding about this... how are we
supposed to know which of parent_instr and parent_if are valid? If I
walk over all the sources for a given SSA def or register, how am I
supposed to know if it's part of an if-condition or an instruction? I
would think that you would need a boolean here or have parent_instr
and parent_if not be in a union.
We do the same thing we did with the sets before. We have separate
uses and if_uses sets. If it's in if_uses, you use the if. If it's
in uses, it's an instr. We could put something in the source but that
seems like it'll make for even more mess.
--Jason
D'oh... right. That makes sense.
Connor
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] mesa: fix up GLSL version when computing GL version
On Mon, Apr 27, 2015 at 3:53 PM, Brian Paul bri...@vmware.com wrote:
On 04/27/2015 12:11 PM, Ilia Mirkin wrote:
In some situations it is convenient for a driver to expose a higher GLSL
version while some extensions are still incomplete. However in that
situation, it would report a GLSL version that was higher than the GL
version. Avoid that situation by limiting the GLSL version to the GL
version.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
v1 - v2:
do work in _mesa_compute_version, not in compute_version
only fix up core profile (easier and this situation doesn't come up for
compat)
src/mesa/main/version.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index da255b2..6024dc8 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/version.c
@@ -483,6 +483,17 @@ _mesa_compute_version(struct gl_context *ctx)
ctx-Version = _mesa_get_version(ctx-Extensions, ctx-Const,
ctx-API);
+ /* Make sure that the GLSL version lines up with the GL version. In
some
+* cases it can be too high, e.g. if an extension is missing.
+*/
+ if (ctx-API == API_OPENGL_CORE) {
+ switch (ctx-Version) {
+ case 31: ctx-Const.GLSLVersion = 140; break;
+ case 32: ctx-Const.GLSLVersion = 150; break;
+ default: ctx-Const.GLSLVersion = ctx-Version * 10; break;
+ }
Would you mind formatting this like other switch/cases:
Sure, done. I thought it was acceptable to do it this way for short statements.
case 31:
ctx-Const.GLSLVersion = 140;
break;
+ }
+
switch (ctx-API) {
case API_OPENGL_COMPAT:
case API_OPENGL_CORE:
Looks OK otherwise.
Reviewed-by: Brian Paul bri...@vmware.com
Thanks. Pushed with the above reformatting.
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC 7/9] nir/nir: Use a linked list instead of a has set for use/def sets
On Mon, Apr 27, 2015 at 1:35 PM, Connor Abbott cwabbo...@gmail.com wrote:
On Fri, Apr 24, 2015 at 7:32 PM, Jason Ekstrand ja...@jlekstrand.net wrote:
+struct nir_if;
+
typedef struct nir_src {
union {
+ nir_instr *parent_instr;
+ struct nir_if *parent_if;
+ };
There's something I'm not quite understanding about this... how are we
supposed to know which of parent_instr and parent_if are valid? If I
walk over all the sources for a given SSA def or register, how am I
supposed to know if it's part of an if-condition or an instruction? I
would think that you would need a boolean here or have parent_instr
and parent_if not be in a union.
We do the same thing we did with the sets before. We have separate
uses and if_uses sets. If it's in if_uses, you use the if. If it's
in uses, it's an instr. We could put something in the source but that
seems like it'll make for even more mess.
--Jason
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965: Unhardcode a few more stage names and abbreviations.
The stage_abbrev and stage_name fields in backend_visitor provide what
we need without any additional effort. It also means we'll get the
right names for compute shaders, SIMD8 geometry shaders, and both kinds
of tessellation shaders.
This does unfortunately change the capitalization of the stage
abbreviation in the INTEL_DEBUG=optimizer output filenames. It doesn't
seem worth adding code to handle, though.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 10 +++---
src/mesa/drivers/dri/i965/brw_vec4.cpp | 6 ++
2 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 61ee056..4e4f646 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -3763,8 +3763,6 @@ fs_visitor::calculate_register_pressure()
void
fs_visitor::optimize()
{
- const char *stage_name = stage == MESA_SHADER_VERTEX ? vs : fs;
-
split_virtual_grfs();
move_uniform_array_access_to_pull_constants();
@@ -3778,7 +3776,7 @@ fs_visitor::optimize()
if (unlikely(INTEL_DEBUG DEBUG_OPTIMIZER) this_progress) { \
char filename[64]; \
snprintf(filename, 64, %s%d-%04d-%02d-%02d- #pass, \
- stage_name, dispatch_width, shader_prog ? shader_prog-Name
: 0, iteration, pass_num); \
+ stage_abbrev, dispatch_width, shader_prog ?
shader_prog-Name : 0, iteration, pass_num); \
\
backend_visitor::dump_instructions(filename); \
} \
@@ -3790,7 +3788,8 @@ fs_visitor::optimize()
if (unlikely(INTEL_DEBUG DEBUG_OPTIMIZER)) {
char filename[64];
snprintf(filename, 64, %s%d-%04d-00-start,
- stage_name, dispatch_width, shader_prog ? shader_prog-Name :
0);
+ stage_abbrev, dispatch_width,
+ shader_prog ? shader_prog-Name : 0);
backend_visitor::dump_instructions(filename);
}
@@ -3882,9 +3881,6 @@ fs_visitor::allocate_registers()
}
if (!allocated_without_spills) {
- const char *stage_name = stage == MESA_SHADER_VERTEX ?
- Vertex : Fragment;
-
/* We assume that any spilling is worse than just dropping back to
* SIMD8. There's probably actually some intermediate point where
* SIMD16 with a couple of spills is still better.
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp
b/src/mesa/drivers/dri/i965/brw_vec4.cpp
index 8ce07637..57b507d 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
@@ -1700,8 +1700,6 @@ vec4_visitor::run()
move_push_constants_to_pull_constants();
split_virtual_grfs();
- const char *stage_name = stage == MESA_SHADER_GEOMETRY ? gs : vs;
-
#define OPT(pass, args...) ({ \
pass_num++; \
bool this_progress = pass(args); \
@@ -1709,7 +1707,7 @@ vec4_visitor::run()
if (unlikely(INTEL_DEBUG DEBUG_OPTIMIZER) this_progress) { \
char filename[64];\
snprintf(filename, 64, %s-%04d-%02d-%02d- #pass,\
- stage_name, shader_prog ? shader_prog-Name : 0, iteration,
pass_num); \
+ stage_abbrev, shader_prog ? shader_prog-Name : 0,
iteration, pass_num); \
\
backend_visitor::dump_instructions(filename); \
}\
@@ -1722,7 +1720,7 @@ vec4_visitor::run()
if (unlikely(INTEL_DEBUG DEBUG_OPTIMIZER)) {
char filename[64];
snprintf(filename, 64, %s-%04d-00-start,
- stage_name, shader_prog ? shader_prog-Name : 0);
+ stage_abbrev, shader_prog ? shader_prog-Name : 0);
backend_visitor::dump_instructions(filename);
}
--
2.3.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] mesa: fix up GLSL version when computing GL version
On 04/27/2015 12:11 PM, Ilia Mirkin wrote:
In some situations it is convenient for a driver to expose a higher GLSL
version while some extensions are still incomplete. However in that
situation, it would report a GLSL version that was higher than the GL
version. Avoid that situation by limiting the GLSL version to the GL
version.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
v1 - v2:
do work in _mesa_compute_version, not in compute_version
only fix up core profile (easier and this situation doesn't come up for
compat)
src/mesa/main/version.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index da255b2..6024dc8 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/version.c
@@ -483,6 +483,17 @@ _mesa_compute_version(struct gl_context *ctx)
ctx-Version = _mesa_get_version(ctx-Extensions, ctx-Const, ctx-API);
+ /* Make sure that the GLSL version lines up with the GL version. In some
+* cases it can be too high, e.g. if an extension is missing.
+*/
+ if (ctx-API == API_OPENGL_CORE) {
+ switch (ctx-Version) {
+ case 31: ctx-Const.GLSLVersion = 140; break;
+ case 32: ctx-Const.GLSLVersion = 150; break;
+ default: ctx-Const.GLSLVersion = ctx-Version * 10; break;
+ }
Would you mind formatting this like other switch/cases:
case 31:
ctx-Const.GLSLVersion = 140;
break;
+ }
+
switch (ctx-API) {
case API_OPENGL_COMPAT:
case API_OPENGL_CORE:
Looks OK otherwise.
Reviewed-by: Brian Paul bri...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] r600g, radeonsi: add driver queries for GPU temperature and shader+memory clocks
DRM 3.0.0 (amdgpu) doesn't support all of these queries yet. I think
it could only do the GPU load query if it was hooked up.
Radeon will always be 2.x.x.
Marek
On Mon, Apr 27, 2015 at 10:53 PM, Aaron Watry awa...@gmail.com wrote:
On Mon, Apr 27, 2015 at 9:46 AM, Marek Olšák mar...@gmail.com wrote:
From: Marek Olšák marek.ol...@amd.com
---
src/gallium/drivers/radeon/r600_pipe_common.c | 13 +++--
src/gallium/drivers/radeon/r600_pipe_common.h | 3 +++
src/gallium/drivers/radeon/r600_query.c | 21
+
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 19
+++
src/gallium/winsys/radeon/drm/radeon_winsys.h | 5 -
5 files changed, 58 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c
b/src/gallium/drivers/radeon/r600_pipe_common.c
index c6d7918..97eed13 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.c
+++ b/src/gallium/drivers/radeon/r600_pipe_common.c
@@ -665,12 +665,21 @@ static int r600_get_driver_query_info(struct
pipe_screen *screen,
{num-bytes-moved, R600_QUERY_NUM_BYTES_MOVED, 0, TRUE},
{VRAM-usage, R600_QUERY_VRAM_USAGE,
rscreen-info.vram_size, TRUE},
{GTT-usage, R600_QUERY_GTT_USAGE,
rscreen-info.gart_size, TRUE},
+ {temperature, R600_QUERY_GPU_TEMPERATURE, 100, FALSE},
+ {shader-clock, R600_QUERY_CURRENT_GPU_SCLK, 0, FALSE},
+ {memory-clock, R600_QUERY_CURRENT_GPU_MCLK, 0, FALSE}
};
+ unsigned num_queries;
+
+ if (rscreen-info.drm_major == 2 rscreen-info.drm_minor = 42)
+ num_queries = Elements(list);
Would it makes sense to future-proof this a bit and allow for drm_major of
2?
e.g.
if (rscreen-0info.drm_major 2 || (rscreen-info.drm_major == 2
rscreen-info.drm_minor = 42))
--Aaron
+ else
+ num_queries = 8;
if (!info)
- return Elements(list);
+ return num_queries;
- if (index = Elements(list))
+ if (index = num_queries)
return 0;
*info = list[index];
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.h
b/src/gallium/drivers/radeon/r600_pipe_common.h
index 384a9a6..c23072c 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.h
+++ b/src/gallium/drivers/radeon/r600_pipe_common.h
@@ -55,6 +55,9 @@
#define R600_QUERY_NUM_BYTES_MOVED (PIPE_QUERY_DRIVER_SPECIFIC + 5)
#define R600_QUERY_VRAM_USAGE (PIPE_QUERY_DRIVER_SPECIFIC + 6)
#define R600_QUERY_GTT_USAGE (PIPE_QUERY_DRIVER_SPECIFIC + 7)
+#define R600_QUERY_GPU_TEMPERATURE (PIPE_QUERY_DRIVER_SPECIFIC + 8)
+#define R600_QUERY_CURRENT_GPU_SCLK(PIPE_QUERY_DRIVER_SPECIFIC + 9)
+#define R600_QUERY_CURRENT_GPU_MCLK(PIPE_QUERY_DRIVER_SPECIFIC + 10)
#define R600_CONTEXT_STREAMOUT_FLUSH (1u 0)
#define R600_CONTEXT_PRIVATE_FLAG (1u 1)
diff --git a/src/gallium/drivers/radeon/r600_query.c
b/src/gallium/drivers/radeon/r600_query.c
index 6a35ab8..758064a 100644
--- a/src/gallium/drivers/radeon/r600_query.c
+++ b/src/gallium/drivers/radeon/r600_query.c
@@ -86,6 +86,9 @@ static struct r600_resource
*r600_new_query_buffer(struct r600_common_context *c
case R600_QUERY_NUM_BYTES_MOVED:
case R600_QUERY_VRAM_USAGE:
case R600_QUERY_GTT_USAGE:
+ case R600_QUERY_GPU_TEMPERATURE:
+ case R600_QUERY_CURRENT_GPU_SCLK:
+ case R600_QUERY_CURRENT_GPU_MCLK:
return NULL;
}
@@ -382,6 +385,9 @@ static struct pipe_query *r600_create_query(struct
pipe_context *ctx, unsigned q
case R600_QUERY_NUM_BYTES_MOVED:
case R600_QUERY_VRAM_USAGE:
case R600_QUERY_GTT_USAGE:
+ case R600_QUERY_GPU_TEMPERATURE:
+ case R600_QUERY_CURRENT_GPU_SCLK:
+ case R600_QUERY_CURRENT_GPU_MCLK:
skip_allocation = true;
break;
default:
@@ -439,6 +445,9 @@ static void r600_begin_query(struct pipe_context *ctx,
struct pipe_query *query)
case R600_QUERY_REQUESTED_GTT:
case R600_QUERY_VRAM_USAGE:
case R600_QUERY_GTT_USAGE:
+ case R600_QUERY_GPU_TEMPERATURE:
+ case R600_QUERY_CURRENT_GPU_SCLK:
+ case R600_QUERY_CURRENT_GPU_MCLK:
rquery-begin_result = 0;
return;
case R600_QUERY_BUFFER_WAIT_TIME:
@@ -513,6 +522,15 @@ static void r600_end_query(struct pipe_context *ctx,
struct pipe_query *query)
case R600_QUERY_GTT_USAGE:
rquery-end_result = rctx-ws-query_value(rctx-ws,
RADEON_GTT_USAGE);
return;
+ case R600_QUERY_GPU_TEMPERATURE:
+ rquery-end_result = rctx-ws-query_value(rctx-ws,
RADEON_GPU_TEMPERATURE) / 1000;
+ return;
+ case R600_QUERY_CURRENT_GPU_SCLK:
+ rquery-end_result =
Re: [Mesa-dev] [RFC 7/9] nir/nir: Use a linked list instead of a has set for use/def sets
On Fri, Apr 24, 2015 at 7:32 PM, Jason Ekstrand ja...@jlekstrand.net wrote:
This commit switches us from the current setup of using hash sets for
use/def sets to using linked lists. Doing so should save us quite a bit of
memory because we aren't carrying around 3 hash sets per register and 2 per
SSA value. It should also save us CPU time because adding/removing things
from use/def sets is 4 pointer manipulations instead of a hash lookup.
On the code complexity side of things, some things are now much easier and
others are a bit harder. One of the operations we perform constantly in
optimization passes is to replace one source with another. Due to the fact
that an instruction can use the same SSA value multiple times, we had to
iterate through the sources of the instruction and determine if the use we
were replacing was the only one before removing it from the set of uses.
With this patch, uses are per-source not per-instruction so we can just
remove it safely. On the other hand, trying to iterate over all of the
instructions that use a given value is more difficult. Fortunately, the
two places we do that are the ffma peephole where it doesn't matter and GCM
where we already gracefully handle duplicates visits to an instruction.
Another aspect here is that using linked lists in this way can be tricky to
get right. With sets, things were quite forgiving and the worst that
happened if you didn't properly remove a use was that it would get caught
in the validator. With linked lists, it can lead to linked list corruption
which can be harder to track. However, we do just as much validation of
the linked lists as we did of the sets so the validator should still catch
these problems. While working on this series, the vast majority of the
bugs I had to fix were caught by assertions. I don't think the lists are
going to be that much worse than the sets.
---
src/glsl/nir/nir.c | 232
src/glsl/nir/nir.h | 27 --
src/glsl/nir/nir_validate.c | 158 +++---
3 files changed, 182 insertions(+), 235 deletions(-)
diff --git a/src/glsl/nir/nir.c b/src/glsl/nir/nir.c
index b8f5dd4..283b861 100644
--- a/src/glsl/nir/nir.c
+++ b/src/glsl/nir/nir.c
@@ -58,12 +58,9 @@ reg_create(void *mem_ctx, struct exec_list *list)
nir_register *reg = ralloc(mem_ctx, nir_register);
reg-parent_instr = NULL;
- reg-uses = _mesa_set_create(reg, _mesa_hash_pointer,
-_mesa_key_pointer_equal);
- reg-defs = _mesa_set_create(reg, _mesa_hash_pointer,
-_mesa_key_pointer_equal);
- reg-if_uses = _mesa_set_create(reg, _mesa_hash_pointer,
- _mesa_key_pointer_equal);
+ nir_list_init(reg-uses);
+ nir_list_init(reg-defs);
+ nir_list_init(reg-if_uses);
reg-num_components = 0;
reg-num_array_elems = 0;
@@ -1070,11 +1067,14 @@ update_if_uses(nir_cf_node *node)
nir_if *if_stmt = nir_cf_node_as_if(node);
- struct set *if_uses_set = if_stmt-condition.is_ssa ?
- if_stmt-condition.ssa-if_uses :
- if_stmt-condition.reg.reg-uses;
-
- _mesa_set_add(if_uses_set, if_stmt);
+ if_stmt-condition.parent_if = if_stmt;
+ if (if_stmt-condition.is_ssa) {
+ nir_list_push_tail(if_stmt-condition.ssa-if_uses,
+ if_stmt-condition.use_link);
+ } else {
+ nir_list_push_tail(if_stmt-condition.reg.reg-if_uses,
+ if_stmt-condition.use_link);
+ }
}
void
@@ -1227,16 +1227,7 @@ cleanup_cf_node(nir_cf_node *node)
foreach_list_typed(nir_cf_node, child, node, if_stmt-else_list)
cleanup_cf_node(child);
- struct set *if_uses;
- if (if_stmt-condition.is_ssa) {
- if_uses = if_stmt-condition.ssa-if_uses;
- } else {
- if_uses = if_stmt-condition.reg.reg-if_uses;
- }
-
- struct set_entry *entry = _mesa_set_search(if_uses, if_stmt);
- assert(entry);
- _mesa_set_remove(if_uses, entry);
+ nir_link_remove(if_stmt-condition.use_link);
break;
}
@@ -1293,9 +1284,10 @@ add_use_cb(nir_src *src, void *state)
{
nir_instr *instr = state;
- struct set *uses_set = src-is_ssa ? src-ssa-uses : src-reg.reg-uses;
-
- _mesa_set_add(uses_set, instr);
+ src-parent_instr = instr;
+ nir_link_init(src-use_link);
+ nir_list *uses_list = src-is_ssa ? src-ssa-uses : src-reg.reg-uses;
+ nir_list_push_tail(uses_list, src-use_link);
return true;
}
@@ -1320,8 +1312,11 @@ add_reg_def_cb(nir_dest *dest, void *state)
{
nir_instr *instr = state;
- if (!dest-is_ssa)
- _mesa_set_add(dest-reg.reg-defs, instr);
+ if (!dest-is_ssa) {
+ dest-reg.parent_instr = instr;
+ nir_link_init(dest-reg.def_link);
+ nir_list_push_tail(dest-reg.reg-defs,
Re: [Mesa-dev] [PATCH] glsl: fix packing support for arrays of doubles
Reviewed-by: Ilia Mirkin imir...@alum.mit.edu (for the little that's worth... I didn't spot this in the original commit. Oh well.) On Mon, Apr 27, 2015 at 5:35 PM, Timothy Arceri t_arc...@yahoo.com.au wrote: Broke in commit f00c5f85b82efe9535b18dbf97c4591fb28aeae6 when adding support for multidimensional arrays --- src/glsl/lower_packed_varyings.cpp | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/glsl/lower_packed_varyings.cpp b/src/glsl/lower_packed_varyings.cpp index f8e79bd..d8bebb5 100644 --- a/src/glsl/lower_packed_varyings.cpp +++ b/src/glsl/lower_packed_varyings.cpp @@ -645,8 +645,8 @@ lower_packed_varyings_visitor::needs_lowering(ir_variable *var) if (var-data.explicit_location) return false; - if (var-type-without_array()-vector_elements == 4 - !var-type-is_double()) + const glsl_type *type = var-type-without_array(); + if (type-vector_elements == 4 !type-is_double()) return false; return true; } -- 2.1.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH] i965: Add XRGB8888 format to intel_screen_make_configs
On Thu, 16 Apr 2015 21:06:27 +0100
Daniel Stone dan...@fooishbar.org wrote:
Hi,
On 9 April 2015 at 17:20, Kristian Høgsberg k...@bitplanet.net wrote:
On Wed, Apr 8, 2015 at 11:37 AM, Emil Velikov emil.l.veli...@gmail.com
wrote:
Hi all,
Can we get a pair of eyes on this patch please ?
Reviewed-by: Kristian Høgsberg k...@bitplanet.net
Thanks for the reminder.
Mind you, this does break 75b7e1df13, which explicitly removes them in
order to 'fix' (scare quotes in original) a conformance test. That
commit also made our lives harder with
https://bugs.freedesktop.org/show_bug.cgi?id=67676 for which the
suggested fix was a separate EGL_XXX_transparent_alpha extension, but
between the two of these, it does seem like a more nuanced fix might
be in order.
Not being able to choose between XRGB and ARGB formats in the GBM
backend does actually impair our ability to hoist ARGB content to
planes, so at the very least, we'd need to duplicate ARGB
driver_configs in the EGLConfig list: one for an ARGB native visual
ID, and one for XRGB.
Any thoughts?
Dear Intel developers,
humble ping? Any advice on what the proper course of action is?
To me it seems like the issue still exists; not being able to run
Weston/DRM on Intel would be a bit awkward.
Thanks,
pq
Boyan
For the future can you please include the CC mesa-stable line in the
commit message. It will make things a bit more obvious as I'm pursing
through the list :-)
Thanks
Emil
On 25 March 2015 at 11:36, Boyan Ding boyan.j.d...@gmail.com wrote:
Some application, such as drm backend of weston, uses XRGB config as
default. i965 doesn't provide this format, but before commit 65c8965d,
the drm platform of EGL takes ARGB as XRGB. Now that commit
65c8965d makes EGL recognize format correctly so weston won't start
because it can't find XRGB. Add XRGB format to i965 just as
other drivers do.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89689
Signed-off-by: Boyan Ding boyan.j.d...@gmail.com
---
src/mesa/drivers/dri/i965/intel_screen.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
b/src/mesa/drivers/dri/i965/intel_screen.c
index 3640b67..2b82c33 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -1126,7 +1126,8 @@ intel_screen_make_configs(__DRIscreen *dri_screen)
{
static const mesa_format formats[] = {
MESA_FORMAT_B5G6R5_UNORM,
- MESA_FORMAT_B8G8R8A8_UNORM
+ MESA_FORMAT_B8G8R8A8_UNORM,
+ MESA_FORMAT_B8G8R8X8_UNORM
};
/* GLX_SWAP_COPY_OML is not supported due to page flipping. */
--
2.3.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: properly setting var-data.binding if explicit_binding is true
On Sun, 2015-04-26 at 15:23 +0200, Alejandro Piñeiro wrote:
On 26/04/15 00:08, Timothy Arceri wrote:
On Sat, 2015-04-25 at 18:46 +0200, Alejandro Piñeiro wrote:
There was a typo on commit c0cd5b, doing it when explicit_binding
was false. This prevented to use any binding point different to 0.
---
Taking into account the explanation on the header about the
variable binding (ast.h:553)
/**
* Binding specified via GL_ARB_shading_language_420pack's
binding keyword.
*
* \note
* This field is only valid if \c explicit_binding is set.
*/
int binding;
The binding is correct (and should be updated) if explicit_binding
is true.
But the current behaviour was updating it if it was false.
This was not detected by piglit because all the calls to
glBindBufferBase(GL_ATOMIC_COUNTER_BUFFER are using 0.
I tested this patch by running all piglit on my system, and I
didn't
detect regression. I also runned make check without issues.
https://bugs.freedesktop.org/show_bug.cgi?id=90175
You should probably convert your test program to a piglit test also
so
this bug can be detected if it happens again in the future.
There are several piglit tests at spec/arb_shader_atomic_counters
testing that you get what you expect while using atomic counters.
Probably it would be enough to just modify some of the already
existing
tests, using a non-zero binding point (for example at semantics.c).
But I don't have too much experience tweaking/creating piglit tests.
What option would be preferred for this case? A new test or just
modify
a little one of the already available?
Take a look at buffer-binding.c it would probably make sense to add your
subtest to this test.
Your test would probably look something like this:
static bool
run_test_explicit_binding(test params here)
{
/* test code */
if (explict_binding_set_incorrectly)
return false;
return true;
}
And you would add something like this to piglit_init()*/
if (piglit_is_extension_supported(GL_ARB_shading_language_420pack))
atomic_counters_subtest(status, GL_NONE,
Atomic buffer explicit binding
run_test_explicit_binding,
}
You would also need to update the comment at the top of the file.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/7] i965: use _mesa_geometry_width/height/layers/samples for programming geometry of framebuffer to GEN
On Fri, Apr 24, 2015 at 11:36:27PM +0300, Rogovin, Kevin wrote: I want to add one more comment on why to replace with the _mesa_geometry_ functions, which I had thought was so obvious I neglected to mention it: With this series the meaning of gl_framebuffer::Width, Height, and so on have a different meaning. They give the intersection of the backing stores of the render targets. In contrast, the _mesa_geometry_* functions give the geometry to feed a rasterizer/windower. By using _mesa_geometry_* functions the code communicates clearly it wants the geometry to feed windower/rasterizer and not the geometry of the intersection of the (potentially empty) set of backing stores. Moreover, it is better to be consistent as well, as later someone will likely wonder: why in Gen7 and higher are those _mesa_geometry functions used but not before? That question has no good answer because it does not make sense to not use those functions when programming the rasterizer/windower thingies. Could we split the patch in two? One part dealing with the necessary needed for gen7 and higher to support no_attachments and then another just making older gens consistent. -Kevin -Original Message- From: Rogovin, Kevin Sent: Friday, April 24, 2015 7:43 PM To: Pohjolainen, Topi Cc: mesa-...@freedesktop.org Subject: RE: [Mesa-dev] [PATCH 5/7] i965: use _mesa_geometry_width/height/layers/samples for programming geometry of framebuffer to GEN My point specifically was that you are also updating atoms that _are not_ re-used. And as those changes are not really needed, I wouldn't take the risk of changing something in vain. I would introduce them only when you have patches to really enable older generations. My take is the following: 1. Tracking (and guaranteeing) that those function left unchanged as is are exactly just those for before Gen7 is a pain. Much easier, and more reliable to hit them all instead. A significant number of functions in i965 are not emit functions of any atom but emit functions of atoms map to them. Again, more reliable and -safer- to change them all, then just the bare minimum. 2. The change is benign. If _HasAttachments is true, then the function substitution gives the same value. For Gens not supporting the extension there is no effect. 3. Lastly, as stated: for later it leaves the option to enable it for Gen6 and below, it is just trivial change, but it needs testing on hardware. When I writing this work, I originally had it for all Gens, but changed to support only Gen7and higher because that is all on which I can test it. -Kevin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 6/7] i965: ensure execution of fragment shader when fragment shader has atomic buffer access
On Fri, Apr 24, 2015 at 07:45:29PM +0300, Rogovin, Kevin wrote: I'll check with Jordan and others. I have a faint recollection that compute shaders have similar needs. I think your change is fine though, I just want to understand the bigger picture first. I do not think compute shaders have similar needs. These flags are for making sure the rasterizer-wm thingy in Gen spawns the fragment shader threads. Compute kernels are not (I believe) spawned by the raster-wm thing, as they do not actually use the pipeline (rather they use L3, samplers and EU's only essentially). Yes, you are correct, cs has its own state packets entirely. I realized that when reading Jordan's series. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] st/mesa: allow glsl version up to 410, enable ARB_shader_precision
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu --- src/mesa/state_tracker/st_extensions.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/mesa/state_tracker/st_extensions.c b/src/mesa/state_tracker/st_extensions.c index 25932dd..82e4a30 100644 --- a/src/mesa/state_tracker/st_extensions.c +++ b/src/mesa/state_tracker/st_extensions.c @@ -657,8 +657,8 @@ void st_init_extensions(struct pipe_screen *screen, glsl_feature_level = screen-get_param(screen, PIPE_CAP_GLSL_FEATURE_LEVEL); consts-GLSLVersion = glsl_feature_level; - if (glsl_feature_level = 330) - consts-GLSLVersion = 330; + if (glsl_feature_level = 410) + consts-GLSLVersion = 410; _mesa_override_glsl_version(consts); @@ -669,6 +669,8 @@ void st_init_extensions(struct pipe_screen *screen, if (glsl_feature_level = 400) extensions-ARB_gpu_shader5 = GL_TRUE; + if (glsl_feature_level = 410) + extensions-ARB_shader_precision = GL_TRUE; /* This extension needs full OpenGL 3.2, but we don't know if that's * supported at this point. Only check the GLSL version. */ -- 2.0.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] mesa: fix up GLSL version when computing GL version
Some required extension might be missing, and we may expose a GLSL
version that does not match up with the GL version. Fix that up when
computing the GL version.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
src/mesa/main/version.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index a65ace0..bf0a1cf 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/version.c
@@ -207,7 +207,7 @@ _mesa_override_glsl_version(struct gl_constants *consts)
*/
static GLuint
compute_version(const struct gl_extensions *extensions,
-const struct gl_constants *consts, gl_api api)
+struct gl_constants *consts, gl_api api)
{
GLuint major, minor, version;
@@ -330,38 +330,47 @@ compute_version(const struct gl_extensions *extensions,
if (ver_4_2) {
major = 4;
minor = 2;
+ consts-GLSLVersion = 420;
}
else if (ver_4_1) {
major = 4;
minor = 1;
+ consts-GLSLVersion = 410;
}
else if (ver_4_0) {
major = 4;
minor = 0;
+ consts-GLSLVersion = 400;
}
else if (ver_3_3) {
major = 3;
minor = 3;
+ consts-GLSLVersion = 330;
}
else if (ver_3_2) {
major = 3;
minor = 2;
+ consts-GLSLVersion = 150;
}
else if (ver_3_1) {
major = 3;
minor = 1;
+ consts-GLSLVersion = 140;
}
else if (ver_3_0) {
major = 3;
minor = 0;
+ consts-GLSLVersion = 130;
}
else if (ver_2_1) {
major = 2;
minor = 1;
+ consts-GLSLVersion = 120;
}
else if (ver_2_0) {
major = 2;
minor = 0;
+ consts-GLSLVersion = 110;
}
else if (ver_1_5) {
major = 1;
--
2.0.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 09/10] gallium, clover: add OpenCL interoperability support for CL events
Marek Olšák mar...@gmail.com writes:
On Tue, Apr 21, 2015 at 3:50 PM, Francisco Jerez curroje...@riseup.net
wrote:
Marek Olšák mar...@gmail.com writes:
From: Marek Olšák marek.ol...@amd.com
Hi Marek, looks mostly OK to me, a few nits inline,
---
src/gallium/include/state_tracker/opencl_interop.h | 42 ++
src/gallium/state_trackers/clover/Makefile.sources | 1 +
src/gallium/state_trackers/clover/core/event.hpp | 4 ++
src/gallium/state_trackers/clover/core/interop.cpp | 66
++
src/gallium/targets/opencl/opencl.sym | 1 +
5 files changed, 114 insertions(+)
create mode 100644 src/gallium/include/state_tracker/opencl_interop.h
create mode 100644 src/gallium/state_trackers/clover/core/interop.cpp
diff --git a/src/gallium/include/state_tracker/opencl_interop.h
b/src/gallium/include/state_tracker/opencl_interop.h
new file mode 100644
index 000..31a3bd3
--- /dev/null
+++ b/src/gallium/include/state_tracker/opencl_interop.h
@@ -0,0 +1,42 @@
+/**
+ *
+ * Copyright 2015 Advanced Micro Devices, Inc.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * Software), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
+ * IN NO EVENT SHALL THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR
+ * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
+ * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
+ * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+
**/
+
+#ifndef OPENCL_INTEROP_H
+#define OPENCL_INTEROP_H
+
+/* dlsym these without the _t suffix. You should get the correct symbols
+ * if the OpenCL driver is loaded.
+ *
+ * All functions return non-zero on success.
+ */
+
+typedef int (*opencl_dri_event_add_ref_t)(intptr_t cl_event);
+typedef int (*opencl_dri_event_release_t)(intptr_t cl_event);
+typedef int (*opencl_dri_event_wait_t)(intptr_t cl_event, uint64_t
timeout);
+typedef struct pipe_fence_handle *(*opencl_dri_event_get_fence_t)(intptr_t
cl_event);
+
Just curious, is there any reason you use intptr_t here and elsewhere
rather than cl_event or void *? The former is an typedef of an opaque
pointer anyway. Using CL types would likely avoid some ugly casts
later on. And maybe bool as return type?
I'll change intptr_t to void*. I don't trust that bool is the same in
both C and C++ and int seems to be a safe choice for an ABI.
Any sensible ABI [the same thing that guarantees that C's and C++'s
int are the same type ;)] that as far as I'm aware clover has ever
been compiled for should give identical representations to C's _Bool and
C++'s bool. Not sure what your concern is?
+#endif /* OPENCL_INTEROP_H */
diff --git a/src/gallium/state_trackers/clover/Makefile.sources
b/src/gallium/state_trackers/clover/Makefile.sources
index 5b3344c..4c2d0f3 100644
--- a/src/gallium/state_trackers/clover/Makefile.sources
+++ b/src/gallium/state_trackers/clover/Makefile.sources
@@ -22,6 +22,7 @@ CPP_SOURCES := \
core/event.hpp \
core/format.cpp \
core/format.hpp \
+ core/interop.cpp \
core/kernel.cpp \
core/kernel.hpp \
core/memory.cpp \
diff --git a/src/gallium/state_trackers/clover/core/event.hpp
b/src/gallium/state_trackers/clover/core/event.hpp
index 0e1359a..28f510f 100644
--- a/src/gallium/state_trackers/clover/core/event.hpp
+++ b/src/gallium/state_trackers/clover/core/event.hpp
@@ -116,6 +116,10 @@ namespace clover {
friend class command_queue;
+ struct pipe_fence_handle *get_fence() const {
The convention in the surrounding code is to name such accessors as the
object they access, how about pipe_fence_handle *fence() const?
OK.
+ return _fence;
+ }
+
private:
virtual void fence(pipe_fence_handle *fence);
action profile(command_queue q, const action action) const;
diff --git a/src/gallium/state_trackers/clover/core/interop.cpp
b/src/gallium/state_trackers/clover/core/interop.cpp
new file mode 100644
index
Re: [Mesa-dev] [PATCH 1/2] mesa: fix up GLSL version when computing GL version
On 04/27/2015 07:23 AM, Ilia Mirkin wrote:
Some required extension might be missing, and we may expose a GLSL
version that does not match up with the GL version. Fix that up when
computing the GL version.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
src/mesa/main/version.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index a65ace0..bf0a1cf 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/version.c
@@ -207,7 +207,7 @@ _mesa_override_glsl_version(struct gl_constants *consts)
*/
static GLuint
compute_version(const struct gl_extensions *extensions,
-const struct gl_constants *consts, gl_api api)
+struct gl_constants *consts, gl_api api)
{
GLuint major, minor, version;
@@ -330,38 +330,47 @@ compute_version(const struct gl_extensions *extensions,
if (ver_4_2) {
major = 4;
minor = 2;
+ consts-GLSLVersion = 420;
}
else if (ver_4_1) {
major = 4;
minor = 1;
+ consts-GLSLVersion = 410;
}
else if (ver_4_0) {
major = 4;
minor = 0;
+ consts-GLSLVersion = 400;
}
else if (ver_3_3) {
major = 3;
minor = 3;
+ consts-GLSLVersion = 330;
}
else if (ver_3_2) {
major = 3;
minor = 2;
+ consts-GLSLVersion = 150;
}
else if (ver_3_1) {
major = 3;
minor = 1;
+ consts-GLSLVersion = 140;
}
else if (ver_3_0) {
major = 3;
minor = 0;
+ consts-GLSLVersion = 130;
}
else if (ver_2_1) {
major = 2;
minor = 1;
+ consts-GLSLVersion = 120;
}
else if (ver_2_0) {
major = 2;
minor = 0;
+ consts-GLSLVersion = 110;
}
else if (ver_1_5) {
major = 1;
This looks OK, but another approach might be to have a new function
which returns the GLSL version for a given GL version (could be encoded
in a small table). Then, use that function to clamp/set
consts-GLSLVersion. That way we can keep the nice const-ness of the
compute_version() parameters.
Otherwise, we should at least update the comments to indicate that the
gl_constants can change.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] mesa: fix up GLSL version when computing GL version
On 04/27/2015 07:39 AM, Ilia Mirkin wrote:
On Mon, Apr 27, 2015 at 9:38 AM, Brian Paul bri...@vmware.com wrote:
On 04/27/2015 07:23 AM, Ilia Mirkin wrote:
Some required extension might be missing, and we may expose a GLSL
version that does not match up with the GL version. Fix that up when
computing the GL version.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
src/mesa/main/version.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index a65ace0..bf0a1cf 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/version.c
@@ -207,7 +207,7 @@ _mesa_override_glsl_version(struct gl_constants
*consts)
*/
static GLuint
compute_version(const struct gl_extensions *extensions,
-const struct gl_constants *consts, gl_api api)
+struct gl_constants *consts, gl_api api)
{
GLuint major, minor, version;
@@ -330,38 +330,47 @@ compute_version(const struct gl_extensions
*extensions,
if (ver_4_2) {
major = 4;
minor = 2;
+ consts-GLSLVersion = 420;
}
else if (ver_4_1) {
major = 4;
minor = 1;
+ consts-GLSLVersion = 410;
}
else if (ver_4_0) {
major = 4;
minor = 0;
+ consts-GLSLVersion = 400;
}
else if (ver_3_3) {
major = 3;
minor = 3;
+ consts-GLSLVersion = 330;
}
else if (ver_3_2) {
major = 3;
minor = 2;
+ consts-GLSLVersion = 150;
}
else if (ver_3_1) {
major = 3;
minor = 1;
+ consts-GLSLVersion = 140;
}
else if (ver_3_0) {
major = 3;
minor = 0;
+ consts-GLSLVersion = 130;
}
else if (ver_2_1) {
major = 2;
minor = 1;
+ consts-GLSLVersion = 120;
}
else if (ver_2_0) {
major = 2;
minor = 0;
+ consts-GLSLVersion = 110;
}
else if (ver_1_5) {
major = 1;
This looks OK, but another approach might be to have a new function which
returns the GLSL version for a given GL version (could be encoded in a small
table). Then, use that function to clamp/set consts-GLSLVersion. That way
we can keep the nice const-ness of the compute_version() parameters.
Where do you envision the clamping be done?
How about _mesa_compute_version()?
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] mesa: fix up GLSL version when computing GL version
On Mon, Apr 27, 2015 at 9:58 AM, Brian Paul bri...@vmware.com wrote:
On 04/27/2015 07:39 AM, Ilia Mirkin wrote:
On Mon, Apr 27, 2015 at 9:38 AM, Brian Paul bri...@vmware.com wrote:
On 04/27/2015 07:23 AM, Ilia Mirkin wrote:
Some required extension might be missing, and we may expose a GLSL
version that does not match up with the GL version. Fix that up when
computing the GL version.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
src/mesa/main/version.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index a65ace0..bf0a1cf 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/version.c
@@ -207,7 +207,7 @@ _mesa_override_glsl_version(struct gl_constants
*consts)
*/
static GLuint
compute_version(const struct gl_extensions *extensions,
-const struct gl_constants *consts, gl_api api)
+struct gl_constants *consts, gl_api api)
{
GLuint major, minor, version;
@@ -330,38 +330,47 @@ compute_version(const struct gl_extensions
*extensions,
if (ver_4_2) {
major = 4;
minor = 2;
+ consts-GLSLVersion = 420;
}
else if (ver_4_1) {
major = 4;
minor = 1;
+ consts-GLSLVersion = 410;
}
else if (ver_4_0) {
major = 4;
minor = 0;
+ consts-GLSLVersion = 400;
}
else if (ver_3_3) {
major = 3;
minor = 3;
+ consts-GLSLVersion = 330;
}
else if (ver_3_2) {
major = 3;
minor = 2;
+ consts-GLSLVersion = 150;
}
else if (ver_3_1) {
major = 3;
minor = 1;
+ consts-GLSLVersion = 140;
}
else if (ver_3_0) {
major = 3;
minor = 0;
+ consts-GLSLVersion = 130;
}
else if (ver_2_1) {
major = 2;
minor = 1;
+ consts-GLSLVersion = 120;
}
else if (ver_2_0) {
major = 2;
minor = 0;
+ consts-GLSLVersion = 110;
}
else if (ver_1_5) {
major = 1;
This looks OK, but another approach might be to have a new function which
returns the GLSL version for a given GL version (could be encoded in a
small
table). Then, use that function to clamp/set consts-GLSLVersion. That
way
we can keep the nice const-ness of the compute_version() parameters.
Where do you envision the clamping be done?
How about _mesa_compute_version()?
... which is the only caller of compute_version(). You just want it
split up into a separate switch statement or something?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] r600g, radeonsi: add driver queries for GPU temperature and shader+memory clocks
From: Marek Olšák marek.ol...@amd.com
---
src/gallium/drivers/radeon/r600_pipe_common.c | 13 +++--
src/gallium/drivers/radeon/r600_pipe_common.h | 3 +++
src/gallium/drivers/radeon/r600_query.c | 21 +
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 19 +++
src/gallium/winsys/radeon/drm/radeon_winsys.h | 5 -
5 files changed, 58 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c
b/src/gallium/drivers/radeon/r600_pipe_common.c
index c6d7918..97eed13 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.c
+++ b/src/gallium/drivers/radeon/r600_pipe_common.c
@@ -665,12 +665,21 @@ static int r600_get_driver_query_info(struct pipe_screen
*screen,
{num-bytes-moved, R600_QUERY_NUM_BYTES_MOVED, 0, TRUE},
{VRAM-usage, R600_QUERY_VRAM_USAGE, rscreen-info.vram_size,
TRUE},
{GTT-usage, R600_QUERY_GTT_USAGE, rscreen-info.gart_size,
TRUE},
+ {temperature, R600_QUERY_GPU_TEMPERATURE, 100, FALSE},
+ {shader-clock, R600_QUERY_CURRENT_GPU_SCLK, 0, FALSE},
+ {memory-clock, R600_QUERY_CURRENT_GPU_MCLK, 0, FALSE}
};
+ unsigned num_queries;
+
+ if (rscreen-info.drm_major == 2 rscreen-info.drm_minor = 42)
+ num_queries = Elements(list);
+ else
+ num_queries = 8;
if (!info)
- return Elements(list);
+ return num_queries;
- if (index = Elements(list))
+ if (index = num_queries)
return 0;
*info = list[index];
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.h
b/src/gallium/drivers/radeon/r600_pipe_common.h
index 384a9a6..c23072c 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.h
+++ b/src/gallium/drivers/radeon/r600_pipe_common.h
@@ -55,6 +55,9 @@
#define R600_QUERY_NUM_BYTES_MOVED (PIPE_QUERY_DRIVER_SPECIFIC + 5)
#define R600_QUERY_VRAM_USAGE (PIPE_QUERY_DRIVER_SPECIFIC + 6)
#define R600_QUERY_GTT_USAGE (PIPE_QUERY_DRIVER_SPECIFIC + 7)
+#define R600_QUERY_GPU_TEMPERATURE (PIPE_QUERY_DRIVER_SPECIFIC + 8)
+#define R600_QUERY_CURRENT_GPU_SCLK(PIPE_QUERY_DRIVER_SPECIFIC + 9)
+#define R600_QUERY_CURRENT_GPU_MCLK(PIPE_QUERY_DRIVER_SPECIFIC + 10)
#define R600_CONTEXT_STREAMOUT_FLUSH (1u 0)
#define R600_CONTEXT_PRIVATE_FLAG (1u 1)
diff --git a/src/gallium/drivers/radeon/r600_query.c
b/src/gallium/drivers/radeon/r600_query.c
index 6a35ab8..758064a 100644
--- a/src/gallium/drivers/radeon/r600_query.c
+++ b/src/gallium/drivers/radeon/r600_query.c
@@ -86,6 +86,9 @@ static struct r600_resource *r600_new_query_buffer(struct
r600_common_context *c
case R600_QUERY_NUM_BYTES_MOVED:
case R600_QUERY_VRAM_USAGE:
case R600_QUERY_GTT_USAGE:
+ case R600_QUERY_GPU_TEMPERATURE:
+ case R600_QUERY_CURRENT_GPU_SCLK:
+ case R600_QUERY_CURRENT_GPU_MCLK:
return NULL;
}
@@ -382,6 +385,9 @@ static struct pipe_query *r600_create_query(struct
pipe_context *ctx, unsigned q
case R600_QUERY_NUM_BYTES_MOVED:
case R600_QUERY_VRAM_USAGE:
case R600_QUERY_GTT_USAGE:
+ case R600_QUERY_GPU_TEMPERATURE:
+ case R600_QUERY_CURRENT_GPU_SCLK:
+ case R600_QUERY_CURRENT_GPU_MCLK:
skip_allocation = true;
break;
default:
@@ -439,6 +445,9 @@ static void r600_begin_query(struct pipe_context *ctx,
struct pipe_query *query)
case R600_QUERY_REQUESTED_GTT:
case R600_QUERY_VRAM_USAGE:
case R600_QUERY_GTT_USAGE:
+ case R600_QUERY_GPU_TEMPERATURE:
+ case R600_QUERY_CURRENT_GPU_SCLK:
+ case R600_QUERY_CURRENT_GPU_MCLK:
rquery-begin_result = 0;
return;
case R600_QUERY_BUFFER_WAIT_TIME:
@@ -513,6 +522,15 @@ static void r600_end_query(struct pipe_context *ctx,
struct pipe_query *query)
case R600_QUERY_GTT_USAGE:
rquery-end_result = rctx-ws-query_value(rctx-ws,
RADEON_GTT_USAGE);
return;
+ case R600_QUERY_GPU_TEMPERATURE:
+ rquery-end_result = rctx-ws-query_value(rctx-ws,
RADEON_GPU_TEMPERATURE) / 1000;
+ return;
+ case R600_QUERY_CURRENT_GPU_SCLK:
+ rquery-end_result = rctx-ws-query_value(rctx-ws,
RADEON_CURRENT_SCLK) * 100;
+ return;
+ case R600_QUERY_CURRENT_GPU_MCLK:
+ rquery-end_result = rctx-ws-query_value(rctx-ws,
RADEON_CURRENT_MCLK) * 100;
+ return;
}
r600_emit_query_end(rctx, rquery);
@@ -570,6 +588,9 @@ static boolean r600_get_query_buffer_result(struct
r600_common_context *ctx,
case R600_QUERY_NUM_BYTES_MOVED:
case R600_QUERY_VRAM_USAGE:
case R600_QUERY_GTT_USAGE:
+ case R600_QUERY_GPU_TEMPERATURE:
+ case
Re: [Mesa-dev] [RFC PATCH 03/12] glsl: support packing of arrays of arrays
I know I gave a R-b on this, but I only noticed this when you pushed it out:
On Sat, Mar 21, 2015 at 5:49 AM, Timothy Arceri t_arc...@yahoo.com.au wrote:
---
src/glsl/lower_packed_varyings.cpp | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/src/glsl/lower_packed_varyings.cpp
b/src/glsl/lower_packed_varyings.cpp
index 2c9a1c4..f8e79bd 100644
--- a/src/glsl/lower_packed_varyings.cpp
+++ b/src/glsl/lower_packed_varyings.cpp
@@ -645,14 +645,8 @@
lower_packed_varyings_visitor::needs_lowering(ir_variable *var)
if (var-data.explicit_location)
return false;
- const glsl_type *type = var-type;
- if (this-gs_input_vertices != 0) {
- assert(type-is_array());
- type = type-element_type();
- }
- if (type-is_array())
- type = type-fields.array;
- if (type-vector_elements == 4 !type-is_double())
+ if (var-type-without_array()-vector_elements == 4
+ !var-type-is_double())
This should be
type = var-type-without_array();
if (type-...)
Otherwise the var-type-is_double() check may fail.
return false;
return true;
}
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 09/10] gallium, clover: add OpenCL interoperability support for CL events
From: Marek Olšák marek.ol...@amd.com
v2: - move interop.cpp to clover/api
- change intptr_t to void* in the interface
- add a virtual function fence() to simplify some code
v3: - use bool in the interface
---
src/gallium/include/state_tracker/opencl_interop.h | 40 +++
src/gallium/state_trackers/clover/Makefile.sources | 1 +
src/gallium/state_trackers/clover/api/interop.cpp | 60 ++
src/gallium/state_trackers/clover/core/event.hpp | 8 +++
src/gallium/targets/opencl/opencl.sym | 1 +
5 files changed, 110 insertions(+)
create mode 100644 src/gallium/include/state_tracker/opencl_interop.h
create mode 100644 src/gallium/state_trackers/clover/api/interop.cpp
diff --git a/src/gallium/include/state_tracker/opencl_interop.h
b/src/gallium/include/state_tracker/opencl_interop.h
new file mode 100644
index 000..4983644
--- /dev/null
+++ b/src/gallium/include/state_tracker/opencl_interop.h
@@ -0,0 +1,40 @@
+/**
+ *
+ * Copyright 2015 Advanced Micro Devices, Inc.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * Software), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
+ * IN NO EVENT SHALL THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR
+ * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
+ * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
+ * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ **/
+
+#ifndef OPENCL_INTEROP_H
+#define OPENCL_INTEROP_H
+
+/* dlsym these without the _t suffix. You should get the correct symbols
+ * if the OpenCL driver is loaded.
+ */
+
+typedef bool (*opencl_dri_event_add_ref_t)(void *cl_event);
+typedef bool (*opencl_dri_event_release_t)(void *cl_event);
+typedef bool (*opencl_dri_event_wait_t)(void *cl_event, uint64_t timeout);
+typedef struct pipe_fence_handle *(*opencl_dri_event_get_fence_t)(void
*cl_event);
+
+#endif /* OPENCL_INTEROP_H */
diff --git a/src/gallium/state_trackers/clover/Makefile.sources
b/src/gallium/state_trackers/clover/Makefile.sources
index 5b3344c..9e30c69 100644
--- a/src/gallium/state_trackers/clover/Makefile.sources
+++ b/src/gallium/state_trackers/clover/Makefile.sources
@@ -4,6 +4,7 @@ CPP_SOURCES := \
api/dispatch.cpp \
api/dispatch.hpp \
api/event.cpp \
+ api/interop.cpp \
api/kernel.cpp \
api/memory.cpp \
api/platform.cpp \
diff --git a/src/gallium/state_trackers/clover/api/interop.cpp
b/src/gallium/state_trackers/clover/api/interop.cpp
new file mode 100644
index 000..8d18200
--- /dev/null
+++ b/src/gallium/state_trackers/clover/api/interop.cpp
@@ -0,0 +1,60 @@
+//
+// Copyright 2015 Advanced Micro Devices, Inc.
+// All Rights Reserved.
+//
+// Permission is hereby granted, free of charge, to any person obtaining a
+// copy of this software and associated documentation files (the Software),
+// to deal in the Software without restriction, including without limitation
+// the rights to use, copy, modify, merge, publish, distribute, sublicense,
+// and/or sell copies of the Software, and to permit persons to whom the
+// Software is furnished to do so, subject to the following conditions:
+//
+// The above copyright notice and this permission notice shall be included in
+// all copies or substantial portions of the Software.
+//
+// THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+// IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+// FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+// THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
+// OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+// ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+// OTHER DEALINGS IN THE SOFTWARE.
+//
+
+#include core/event.hpp
+#include api/util.hpp
+
+using namespace clover;
+
+extern C {
+
+PUBLIC bool
+opencl_dri_event_add_ref(cl_event event)
+{
+ return clRetainEvent(event) == CL_SUCCESS;
+}
+
+PUBLIC bool
+opencl_dri_event_release(cl_event event)
+{
+
Re: [Mesa-dev] [PATCH 1/2] util/macros: Move DIV_ROUND_UP to util/macros.h
On 04/26/2015 03:23 PM, Axel Davy wrote:
Move DIV_ROUND_UP to a shared location accessible everywhere
Signed-off-by: Axel Davy axel.d...@ens.fr
---
I want to use DIV_ROUND_UP in a galliumm nine patch
src/gallium/auxiliary/util/u_math.h | 1 -
src/gallium/drivers/svga/include/svga3d_surfacedefs.h | 3 +--
src/mesa/main/macros.h| 5 +
src/util/macros.h | 2 ++
4 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_math.h
b/src/gallium/auxiliary/util/u_math.h
index 3d27a59..a2a2d4b 100644
--- a/src/gallium/auxiliary/util/u_math.h
+++ b/src/gallium/auxiliary/util/u_math.h
@@ -796,7 +796,6 @@ void
util_fpstate_set(unsigned fpstate);
-
#ifdef __cplusplus
}
#endif
diff --git a/src/gallium/drivers/svga/include/svga3d_surfacedefs.h
b/src/gallium/drivers/svga/include/svga3d_surfacedefs.h
index 8763cdf..1592fec 100644
--- a/src/gallium/drivers/svga/include/svga3d_surfacedefs.h
+++ b/src/gallium/drivers/svga/include/svga3d_surfacedefs.h
@@ -30,13 +30,12 @@
*/
#include svga3d_reg.h
+#include util/macros.h
Actually, it looks like this #include may not be needed.
We get ARRAY_SIZE via including svga3d_reg.h, which includes
svga_types.h, which includes p_compiler.h which includes util/macros.h
Otherwise, for both:
Reviewed-by: Brian Paul bri...@vmware.com
#ifndef ARRAY_SIZE
#define ARRAY_SIZE(A) (sizeof(A) / sizeof(A[0]))
#endif
-#define DIV_ROUND_UP(x, y) (((x) + (y) - 1) / (y))
-
#define max_t(type, x, y) ((x) (y) ? (x) : (y))
/*
diff --git a/src/mesa/main/macros.h b/src/mesa/main/macros.h
index 3344ec8..0608650 100644
--- a/src/mesa/main/macros.h
+++ b/src/mesa/main/macros.h
@@ -31,6 +31,7 @@
#ifndef MACROS_H
#define MACROS_H
+#include util/macros.h
#include util/u_math.h
#include imports.h
@@ -800,10 +801,6 @@ DIFFERENT_SIGNS(GLfloat x, GLfloat y)
}
-/** Compute ceiling of integer quotient of A divided by B. */
-#define DIV_ROUND_UP( A, B ) ( (A) % (B) == 0 ? (A)/(B) : (A)/(B)+1 )
-
-
/** casts to silence warnings with some compilers */
#define ENUM_TO_INT(E) ((GLint)(E))
#define ENUM_TO_FLOAT(E) ((GLfloat)(GLint)(E))
diff --git a/src/util/macros.h b/src/util/macros.h
index 6c7bda7..3b708ed 100644
--- a/src/util/macros.h
+++ b/src/util/macros.h
@@ -182,5 +182,7 @@ do { \
#define UNUSED
#endif
+/** Compute ceiling of integer quotient of A divided by B. */
+#define DIV_ROUND_UP( A, B ) ( (A) % (B) == 0 ? (A)/(B) : (A)/(B)+1 )
#endif /* UTIL_MACROS_H */
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] scons : Support LLVM 3.5 and 3.6 on windows.
From: Olivier Pena op...@isagri.fr
llvm/Config/llvm-config.h is parsed instead of llvm/Config/config.h for
detecting LLVM version
(http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-June/073707.html)
---
scons/llvm.py | 33 ++---
1 file changed, 26 insertions(+), 7 deletions(-)
diff --git a/scons/llvm.py b/scons/llvm.py
index be7df9f..6c6b733 100644
--- a/scons/llvm.py
+++ b/scons/llvm.py
@@ -72,18 +72,25 @@ def generate(env):
return
# Try to determine the LLVM version from llvm/Config/config.h
-llvm_config = os.path.join(llvm_dir, 'include/llvm/Config/config.h')
+llvm_config = os.path.join(llvm_dir,
'include/llvm/Config/llvm-config.h')
if not os.path.exists(llvm_config):
print 'scons: could not find %s' % llvm_config
return
-llvm_version_re = re.compile(r'^#define PACKAGE_VERSION ([^]*)')
+llvm_version_major_re = re.compile(r'^#define LLVM_VERSION_MAJOR
([0-9]+)')
+llvm_version_minor_re = re.compile(r'^#define LLVM_VERSION_MINOR
([0-9]+)')
llvm_version = None
+llvm_version_major = None
+llvm_version_minor = None
for line in open(llvm_config, 'rt'):
-mo = llvm_version_re.match(line)
+mo = llvm_version_major_re.match(line)
if mo:
-llvm_version = mo.group(1)
-llvm_version = distutils.version.LooseVersion(llvm_version)
-break
+llvm_version_major = mo.group(1)
+mo = llvm_version_minor_re.match(line)
+if mo:
+llvm_version_minor = mo.group(1)
+if (llvm_version_major is not None) and (llvm_version_minor is not
None):
+llvm_version =
distutils.version.LooseVersion('{0}.{1}'.format(llvm_version_major,
llvm_version_minor))
+
if llvm_version is None:
print 'scons: could not determine the LLVM version from %s' %
llvm_config
return
@@ -99,7 +106,19 @@ def generate(env):
])
env.Prepend(LIBPATH = [os.path.join(llvm_dir, 'lib')])
# LIBS should match the output of `llvm-config --libs engine mcjit
bitwriter x86asmprinter`
-if llvm_version = distutils.version.LooseVersion('3.5'):
+if llvm_version = distutils.version.LooseVersion('3.6'):
+env.Prepend(LIBS = [
+'LLVMBitWriter', 'LLVMX86Disassembler', 'LLVMX86AsmParser',
+'LLVMX86CodeGen', 'LLVMSelectionDAG', 'LLVMAsmPrinter',
+'LLVMCodeGen', 'LLVMScalarOpts', 'LLVMProfileData',
+'LLVMInstCombine', 'LLVMTransformUtils', 'LLVMipa',
+'LLVMAnalysis', 'LLVMX86Desc', 'LLVMMCDisassembler',
+'LLVMX86Info', 'LLVMX86AsmPrinter', 'LLVMX86Utils',
+'LLVMMCJIT', 'LLVMTarget', 'LLVMExecutionEngine',
+'LLVMRuntimeDyld', 'LLVMObject', 'LLVMMCParser',
+'LLVMBitReader', 'LLVMMC', 'LLVMCore', 'LLVMSupport'
+])
+elif llvm_version = distutils.version.LooseVersion('3.5'):
env.Prepend(LIBS = [
'LLVMBitWriter', 'LLVMMCJIT', 'LLVMRuntimeDyld',
'LLVMX86Disassembler', 'LLVMX86AsmParser', 'LLVMX86CodeGen',
--
1.9.4.msysgit.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: the function name appears to have a gl prefix already
On 04/24/2015 05:36 PM, Ilia Mirkin wrote:
Currently we're producing errors like
User error: GL_INVALID_OPERATION in glglDeleteProgramsARB(invalid call)
And noop_warn appears to be called with the full function name. Don't
prepend a gl prefix.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
src/mesa/main/context.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index adf6497..6047cdf 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
@@ -894,14 +894,14 @@ update_default_objects(struct gl_context *ctx)
* If there's no current OpenGL context for the calling thread, we can
* print a message to stderr.
*
- * \param name the name of the OpenGL function, without the gl prefix
+ * \param name the name of the OpenGL function
*/
static void
nop_handler(const char *name)
{
GET_CURRENT_CONTEXT(ctx);
if (ctx) {
- _mesa_error(ctx, GL_INVALID_OPERATION, gl%s(invalid call), name);
+ _mesa_error(ctx, GL_INVALID_OPERATION, %s(invalid call), name);
}
#if defined(DEBUG)
else if (getenv(MESA_DEBUG) || getenv(LIBGL_DEBUG)) {
Reviewed-by: Brian Paul bri...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] scons : Support LLVM 3.5 and 3.6 on windows.
On 27/04/15 11:23, olivier.pena...@gmail.com wrote:
From: Olivier Pena op...@isagri.fr
llvm/Config/llvm-config.h is parsed instead of llvm/Config/config.h for
detecting LLVM version
(http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-June/073707.html)
---
scons/llvm.py | 33 ++---
1 file changed, 26 insertions(+), 7 deletions(-)
diff --git a/scons/llvm.py b/scons/llvm.py
index be7df9f..6c6b733 100644
--- a/scons/llvm.py
+++ b/scons/llvm.py
@@ -72,18 +72,25 @@ def generate(env):
return
# Try to determine the LLVM version from llvm/Config/config.h
-llvm_config = os.path.join(llvm_dir, 'include/llvm/Config/config.h')
+llvm_config = os.path.join(llvm_dir,
'include/llvm/Config/llvm-config.h')
if not os.path.exists(llvm_config):
We must keep supporting down to LLVM version 3.3, so the patch needs to
be updated re-try with config.h (and the old regular expressions) when
llvm-config.h does not exist.
print 'scons: could not find %s' % llvm_config
return
-llvm_version_re = re.compile(r'^#define PACKAGE_VERSION ([^]*)')
+llvm_version_major_re = re.compile(r'^#define LLVM_VERSION_MAJOR
([0-9]+)')
+llvm_version_minor_re = re.compile(r'^#define LLVM_VERSION_MINOR
([0-9]+)')
llvm_version = None
+llvm_version_major = None
+llvm_version_minor = None
for line in open(llvm_config, 'rt'):
-mo = llvm_version_re.match(line)
+mo = llvm_version_major_re.match(line)
if mo:
-llvm_version = mo.group(1)
-llvm_version = distutils.version.LooseVersion(llvm_version)
-break
+llvm_version_major = mo.group(1)
+mo = llvm_version_minor_re.match(line)
+if mo:
+llvm_version_minor = mo.group(1)
+if (llvm_version_major is not None) and (llvm_version_minor is not
None):
+llvm_version =
distutils.version.LooseVersion('{0}.{1}'.format(llvm_version_major,
llvm_version_minor))
+
if llvm_version is None:
print 'scons: could not determine the LLVM version from %s' %
llvm_config
return
@@ -99,7 +106,19 @@ def generate(env):
])
env.Prepend(LIBPATH = [os.path.join(llvm_dir, 'lib')])
# LIBS should match the output of `llvm-config --libs engine mcjit
bitwriter x86asmprinter`
-if llvm_version = distutils.version.LooseVersion('3.5'):
+if llvm_version = distutils.version.LooseVersion('3.6'):
+env.Prepend(LIBS = [
+'LLVMBitWriter', 'LLVMX86Disassembler', 'LLVMX86AsmParser',
+'LLVMX86CodeGen', 'LLVMSelectionDAG', 'LLVMAsmPrinter',
+'LLVMCodeGen', 'LLVMScalarOpts', 'LLVMProfileData',
+'LLVMInstCombine', 'LLVMTransformUtils', 'LLVMipa',
+'LLVMAnalysis', 'LLVMX86Desc', 'LLVMMCDisassembler',
+'LLVMX86Info', 'LLVMX86AsmPrinter', 'LLVMX86Utils',
+'LLVMMCJIT', 'LLVMTarget', 'LLVMExecutionEngine',
+'LLVMRuntimeDyld', 'LLVMObject', 'LLVMMCParser',
+'LLVMBitReader', 'LLVMMC', 'LLVMCore', 'LLVMSupport'
Is there any actual change in the LIBS content? Just for my info, what
is it?
Jose
+])
+elif llvm_version = distutils.version.LooseVersion('3.5'):
env.Prepend(LIBS = [
'LLVMBitWriter', 'LLVMMCJIT', 'LLVMRuntimeDyld',
'LLVMX86Disassembler', 'LLVMX86AsmParser', 'LLVMX86CodeGen',
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] mesa: fix up GLSL version when computing GL version
On Mon, Apr 27, 2015 at 10:22 AM, Brian Paul bri...@vmware.com wrote:
On 04/27/2015 08:05 AM, Ilia Mirkin wrote:
On Mon, Apr 27, 2015 at 9:58 AM, Brian Paul bri...@vmware.com wrote:
On 04/27/2015 07:39 AM, Ilia Mirkin wrote:
On Mon, Apr 27, 2015 at 9:38 AM, Brian Paul bri...@vmware.com wrote:
On 04/27/2015 07:23 AM, Ilia Mirkin wrote:
Some required extension might be missing, and we may expose a GLSL
version that does not match up with the GL version. Fix that up when
computing the GL version.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
src/mesa/main/version.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index a65ace0..bf0a1cf 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/version.c
@@ -207,7 +207,7 @@ _mesa_override_glsl_version(struct gl_constants
*consts)
*/
static GLuint
compute_version(const struct gl_extensions *extensions,
-const struct gl_constants *consts, gl_api api)
+struct gl_constants *consts, gl_api api)
{
GLuint major, minor, version;
@@ -330,38 +330,47 @@ compute_version(const struct gl_extensions
*extensions,
if (ver_4_2) {
major = 4;
minor = 2;
+ consts-GLSLVersion = 420;
}
else if (ver_4_1) {
major = 4;
minor = 1;
+ consts-GLSLVersion = 410;
}
else if (ver_4_0) {
major = 4;
minor = 0;
+ consts-GLSLVersion = 400;
}
else if (ver_3_3) {
major = 3;
minor = 3;
+ consts-GLSLVersion = 330;
}
else if (ver_3_2) {
major = 3;
minor = 2;
+ consts-GLSLVersion = 150;
}
else if (ver_3_1) {
major = 3;
minor = 1;
+ consts-GLSLVersion = 140;
}
else if (ver_3_0) {
major = 3;
minor = 0;
+ consts-GLSLVersion = 130;
}
else if (ver_2_1) {
major = 2;
minor = 1;
+ consts-GLSLVersion = 120;
}
else if (ver_2_0) {
major = 2;
minor = 0;
+ consts-GLSLVersion = 110;
}
else if (ver_1_5) {
major = 1;
This looks OK, but another approach might be to have a new function
which
returns the GLSL version for a given GL version (could be encoded in a
small
table). Then, use that function to clamp/set consts-GLSLVersion.
That
way
we can keep the nice const-ness of the compute_version() parameters.
Where do you envision the clamping be done?
How about _mesa_compute_version()?
... which is the only caller of compute_version().
Via _mesa_get_version() which also called from st_manager.c which seems to
be unconcerned with GLSL stuff.
You just want it
split up into a separate switch statement or something?
As I said, I thought a table would work, but a switch would be fine too.
If you feel this is too much work, it's not that big of deal. I just
thought it would be cleaner.
Nope, not too much work, just trying to tease out what you want me to
do. I got confused between _mesa_compute_version and
_mesa_get_version. It does seem like a switch is simpler than a table
though. (The table would have to be indexed by GL version, which is
pretty sparse if you do versions like 20, 33 and 40.)
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] mesa: fix up GLSL version when computing GL version
On Mon, Apr 27, 2015 at 9:38 AM, Brian Paul bri...@vmware.com wrote:
On 04/27/2015 07:23 AM, Ilia Mirkin wrote:
Some required extension might be missing, and we may expose a GLSL
version that does not match up with the GL version. Fix that up when
computing the GL version.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
src/mesa/main/version.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index a65ace0..bf0a1cf 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/version.c
@@ -207,7 +207,7 @@ _mesa_override_glsl_version(struct gl_constants
*consts)
*/
static GLuint
compute_version(const struct gl_extensions *extensions,
-const struct gl_constants *consts, gl_api api)
+struct gl_constants *consts, gl_api api)
{
GLuint major, minor, version;
@@ -330,38 +330,47 @@ compute_version(const struct gl_extensions
*extensions,
if (ver_4_2) {
major = 4;
minor = 2;
+ consts-GLSLVersion = 420;
}
else if (ver_4_1) {
major = 4;
minor = 1;
+ consts-GLSLVersion = 410;
}
else if (ver_4_0) {
major = 4;
minor = 0;
+ consts-GLSLVersion = 400;
}
else if (ver_3_3) {
major = 3;
minor = 3;
+ consts-GLSLVersion = 330;
}
else if (ver_3_2) {
major = 3;
minor = 2;
+ consts-GLSLVersion = 150;
}
else if (ver_3_1) {
major = 3;
minor = 1;
+ consts-GLSLVersion = 140;
}
else if (ver_3_0) {
major = 3;
minor = 0;
+ consts-GLSLVersion = 130;
}
else if (ver_2_1) {
major = 2;
minor = 1;
+ consts-GLSLVersion = 120;
}
else if (ver_2_0) {
major = 2;
minor = 0;
+ consts-GLSLVersion = 110;
}
else if (ver_1_5) {
major = 1;
This looks OK, but another approach might be to have a new function which
returns the GLSL version for a given GL version (could be encoded in a small
table). Then, use that function to clamp/set consts-GLSLVersion. That way
we can keep the nice const-ness of the compute_version() parameters.
Where do you envision the clamping be done?
Otherwise, we should at least update the comments to indicate that the
gl_constants can change.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 09/10] gallium, clover: add OpenCL interoperability support for CL events
Alright. I suppose it's okay to use bool, but hypothetically a gallium
driver could have an OpenCL stack that isn't clover and the interop
interface should work with it too.
Marek
On Mon, Apr 27, 2015 at 2:46 PM, Francisco Jerez curroje...@riseup.net wrote:
Marek Olšák mar...@gmail.com writes:
On Tue, Apr 21, 2015 at 3:50 PM, Francisco Jerez curroje...@riseup.net
wrote:
Marek Olšák mar...@gmail.com writes:
From: Marek Olšák marek.ol...@amd.com
Hi Marek, looks mostly OK to me, a few nits inline,
---
src/gallium/include/state_tracker/opencl_interop.h | 42 ++
src/gallium/state_trackers/clover/Makefile.sources | 1 +
src/gallium/state_trackers/clover/core/event.hpp | 4 ++
src/gallium/state_trackers/clover/core/interop.cpp | 66
++
src/gallium/targets/opencl/opencl.sym | 1 +
5 files changed, 114 insertions(+)
create mode 100644 src/gallium/include/state_tracker/opencl_interop.h
create mode 100644 src/gallium/state_trackers/clover/core/interop.cpp
diff --git a/src/gallium/include/state_tracker/opencl_interop.h
b/src/gallium/include/state_tracker/opencl_interop.h
new file mode 100644
index 000..31a3bd3
--- /dev/null
+++ b/src/gallium/include/state_tracker/opencl_interop.h
@@ -0,0 +1,42 @@
+/**
+ *
+ * Copyright 2015 Advanced Micro Devices, Inc.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * Software), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
+ * IN NO EVENT SHALL THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR
+ * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF
CONTRACT,
+ * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
+ * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+
**/
+
+#ifndef OPENCL_INTEROP_H
+#define OPENCL_INTEROP_H
+
+/* dlsym these without the _t suffix. You should get the correct symbols
+ * if the OpenCL driver is loaded.
+ *
+ * All functions return non-zero on success.
+ */
+
+typedef int (*opencl_dri_event_add_ref_t)(intptr_t cl_event);
+typedef int (*opencl_dri_event_release_t)(intptr_t cl_event);
+typedef int (*opencl_dri_event_wait_t)(intptr_t cl_event, uint64_t
timeout);
+typedef struct pipe_fence_handle
*(*opencl_dri_event_get_fence_t)(intptr_t cl_event);
+
Just curious, is there any reason you use intptr_t here and elsewhere
rather than cl_event or void *? The former is an typedef of an opaque
pointer anyway. Using CL types would likely avoid some ugly casts
later on. And maybe bool as return type?
I'll change intptr_t to void*. I don't trust that bool is the same in
both C and C++ and int seems to be a safe choice for an ABI.
Any sensible ABI [the same thing that guarantees that C's and C++'s
int are the same type ;)] that as far as I'm aware clover has ever
been compiled for should give identical representations to C's _Bool and
C++'s bool. Not sure what your concern is?
+#endif /* OPENCL_INTEROP_H */
diff --git a/src/gallium/state_trackers/clover/Makefile.sources
b/src/gallium/state_trackers/clover/Makefile.sources
index 5b3344c..4c2d0f3 100644
--- a/src/gallium/state_trackers/clover/Makefile.sources
+++ b/src/gallium/state_trackers/clover/Makefile.sources
@@ -22,6 +22,7 @@ CPP_SOURCES := \
core/event.hpp \
core/format.cpp \
core/format.hpp \
+ core/interop.cpp \
core/kernel.cpp \
core/kernel.hpp \
core/memory.cpp \
diff --git a/src/gallium/state_trackers/clover/core/event.hpp
b/src/gallium/state_trackers/clover/core/event.hpp
index 0e1359a..28f510f 100644
--- a/src/gallium/state_trackers/clover/core/event.hpp
+++ b/src/gallium/state_trackers/clover/core/event.hpp
@@ -116,6 +116,10 @@ namespace clover {
friend class command_queue;
+ struct pipe_fence_handle *get_fence() const {
The convention in the surrounding code is to name such accessors as the
object they access, how about pipe_fence_handle *fence() const?
OK.
+ return _fence;
+ }
+
private:
virtual
Re: [Mesa-dev] [PATCH] softpipe: fix another stencil-as-float issue
On 04/25/2015 02:17 PM, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
Hopefully this is the last one now (for texture X32_S8X24_UINT views).
+4 piglits.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90167
---
src/gallium/auxiliary/util/u_tile.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_tile.c
b/src/gallium/auxiliary/util/u_tile.c
index 8e19920..b91bb41 100644
--- a/src/gallium/auxiliary/util/u_tile.c
+++ b/src/gallium/auxiliary/util/u_tile.c
@@ -341,13 +341,13 @@ x32_s8_get_tile_rgba(const unsigned *src,
unsigned i, j;
for (i = 0; i h; i++) {
- float *pRow = p;
+ uint32_t *pRow = (uint32_t *)p;
for (j = 0; j w; j++, pRow += 4) {
src++;
pRow[0] =
pRow[1] =
pRow[2] =
- pRow[3] = (float)(*src++ 0xff);
+ pRow[3] = (*src++ 0xff);
}
p += dst_stride;
}
Reviewed-by: Brian Paul bri...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] mesa: fix up GLSL version when computing GL version
On 04/27/2015 08:05 AM, Ilia Mirkin wrote:
On Mon, Apr 27, 2015 at 9:58 AM, Brian Paul bri...@vmware.com wrote:
On 04/27/2015 07:39 AM, Ilia Mirkin wrote:
On Mon, Apr 27, 2015 at 9:38 AM, Brian Paul bri...@vmware.com wrote:
On 04/27/2015 07:23 AM, Ilia Mirkin wrote:
Some required extension might be missing, and we may expose a GLSL
version that does not match up with the GL version. Fix that up when
computing the GL version.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
src/mesa/main/version.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index a65ace0..bf0a1cf 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/version.c
@@ -207,7 +207,7 @@ _mesa_override_glsl_version(struct gl_constants
*consts)
*/
static GLuint
compute_version(const struct gl_extensions *extensions,
-const struct gl_constants *consts, gl_api api)
+struct gl_constants *consts, gl_api api)
{
GLuint major, minor, version;
@@ -330,38 +330,47 @@ compute_version(const struct gl_extensions
*extensions,
if (ver_4_2) {
major = 4;
minor = 2;
+ consts-GLSLVersion = 420;
}
else if (ver_4_1) {
major = 4;
minor = 1;
+ consts-GLSLVersion = 410;
}
else if (ver_4_0) {
major = 4;
minor = 0;
+ consts-GLSLVersion = 400;
}
else if (ver_3_3) {
major = 3;
minor = 3;
+ consts-GLSLVersion = 330;
}
else if (ver_3_2) {
major = 3;
minor = 2;
+ consts-GLSLVersion = 150;
}
else if (ver_3_1) {
major = 3;
minor = 1;
+ consts-GLSLVersion = 140;
}
else if (ver_3_0) {
major = 3;
minor = 0;
+ consts-GLSLVersion = 130;
}
else if (ver_2_1) {
major = 2;
minor = 1;
+ consts-GLSLVersion = 120;
}
else if (ver_2_0) {
major = 2;
minor = 0;
+ consts-GLSLVersion = 110;
}
else if (ver_1_5) {
major = 1;
This looks OK, but another approach might be to have a new function which
returns the GLSL version for a given GL version (could be encoded in a
small
table). Then, use that function to clamp/set consts-GLSLVersion. That
way
we can keep the nice const-ness of the compute_version() parameters.
Where do you envision the clamping be done?
How about _mesa_compute_version()?
... which is the only caller of compute_version().
Via _mesa_get_version() which also called from st_manager.c which seems
to be unconcerned with GLSL stuff.
You just want it
split up into a separate switch statement or something?
As I said, I thought a table would work, but a switch would be fine too.
If you feel this is too much work, it's not that big of deal. I just
thought it would be cleaner.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] scons : Support LLVM 3.5 and 3.6 on windows.
Hi Jose,
It seems the minimum version is 3.3 (var required_llvm_version).
LLVM 3.3 already provided llvm-config.h.
So, that should be enough ?
I compiled and ran osmesa and libgl-gdi successfully with llvm 3.4.2, 3.5.0 and
3.6.0 (msvc 2013 32 bits) with this patch.
It seems there is some changes in the library returned by llvm-config --libs
engine mcjit bitwriter x86asmprinter (as commented in llvm.py) with llvm 3.6
removed : LLVMJIT
added : LLVMProfileData, LLVMX86Desc, LLVMMCDisassembler
-Message d'origine-
De : mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] De la part de
Jose Fonseca
Envoyé : lundi 27 avril 2015 16:28
À : olivier.pena...@gmail.com; mesa-dev@lists.freedesktop.org
Objet : Re: [Mesa-dev] [PATCH] scons : Support LLVM 3.5 and 3.6 on windows.
On 27/04/15 11:23, olivier.pena...@gmail.com wrote:
From: Olivier Pena op...@isagri.fr
llvm/Config/llvm-config.h is parsed instead of llvm/Config/config.h for
detecting LLVM version
(http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-June/073707.html)
---
scons/llvm.py | 33 ++---
1 file changed, 26 insertions(+), 7 deletions(-)
diff --git a/scons/llvm.py b/scons/llvm.py
index be7df9f..6c6b733 100644
--- a/scons/llvm.py
+++ b/scons/llvm.py
@@ -72,18 +72,25 @@ def generate(env):
return
# Try to determine the LLVM version from llvm/Config/config.h
-llvm_config = os.path.join(llvm_dir, 'include/llvm/Config/config.h')
+llvm_config = os.path.join(llvm_dir,
'include/llvm/Config/llvm-config.h')
if not os.path.exists(llvm_config):
We must keep supporting down to LLVM version 3.3, so the patch needs to
be updated re-try with config.h (and the old regular expressions) when
llvm-config.h does not exist.
print 'scons: could not find %s' % llvm_config
return
-llvm_version_re = re.compile(r'^#define PACKAGE_VERSION ([^]*)')
+llvm_version_major_re = re.compile(r'^#define LLVM_VERSION_MAJOR
([0-9]+)')
+llvm_version_minor_re = re.compile(r'^#define LLVM_VERSION_MINOR
([0-9]+)')
llvm_version = None
+llvm_version_major = None
+llvm_version_minor = None
for line in open(llvm_config, 'rt'):
-mo = llvm_version_re.match(line)
+mo = llvm_version_major_re.match(line)
if mo:
-llvm_version = mo.group(1)
-llvm_version = distutils.version.LooseVersion(llvm_version)
-break
+llvm_version_major = mo.group(1)
+mo = llvm_version_minor_re.match(line)
+if mo:
+llvm_version_minor = mo.group(1)
+if (llvm_version_major is not None) and (llvm_version_minor is not
None):
+llvm_version =
distutils.version.LooseVersion('{0}.{1}'.format(llvm_version_major,
llvm_version_minor))
+
if llvm_version is None:
print 'scons: could not determine the LLVM version from %s' %
llvm_config
return
@@ -99,7 +106,19 @@ def generate(env):
])
env.Prepend(LIBPATH = [os.path.join(llvm_dir, 'lib')])
# LIBS should match the output of `llvm-config --libs engine mcjit
bitwriter x86asmprinter`
-if llvm_version = distutils.version.LooseVersion('3.5'):
+if llvm_version = distutils.version.LooseVersion('3.6'):
+env.Prepend(LIBS = [
+'LLVMBitWriter', 'LLVMX86Disassembler', 'LLVMX86AsmParser',
+'LLVMX86CodeGen', 'LLVMSelectionDAG', 'LLVMAsmPrinter',
+'LLVMCodeGen', 'LLVMScalarOpts', 'LLVMProfileData',
+'LLVMInstCombine', 'LLVMTransformUtils', 'LLVMipa',
+'LLVMAnalysis', 'LLVMX86Desc', 'LLVMMCDisassembler',
+'LLVMX86Info', 'LLVMX86AsmPrinter', 'LLVMX86Utils',
+'LLVMMCJIT', 'LLVMTarget', 'LLVMExecutionEngine',
+'LLVMRuntimeDyld', 'LLVMObject', 'LLVMMCParser',
+'LLVMBitReader', 'LLVMMC', 'LLVMCore', 'LLVMSupport'
Is there any actual change in the LIBS content? Just for my info, what
is it?
Jose
+])
+elif llvm_version = distutils.version.LooseVersion('3.5'):
env.Prepend(LIBS = [
'LLVMBitWriter', 'LLVMMCJIT', 'LLVMRuntimeDyld',
'LLVMX86Disassembler', 'LLVMX86AsmParser', 'LLVMX86CodeGen',
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Click https://www.mailcontrol.com/sr/MZbqvYs5QwJvpeaetUwhCQ== to report this
email as spam.
-
Ce message a été traité contre les virus par quatre outils différents
(Kaspersky, McAfee, Symantec et ThreatSeeker).
This message has been scanned for viruses (by Kaspersky, McAfee,
Re: [Mesa-dev] [PATCH] scons: add target osmesa using gallium state tracker.
Pushed. Thanks.
Jose
On 22/04/15 16:36, olivier.pena...@gmail.com wrote:
From: Olivier Pena op...@isagri.fr
---
src/gallium/SConscript| 5
src/gallium/state_trackers/osmesa/Makefile.am | 2 ++
src/gallium/state_trackers/osmesa/SConscript | 26
src/gallium/targets/osmesa/Makefile.am| 6 +++-
src/gallium/targets/osmesa/SConscript | 43 +++
src/gallium/targets/osmesa/osmesa.def | 16 ++
src/gallium/targets/osmesa/osmesa.mingw.def | 13
7 files changed, 110 insertions(+), 1 deletion(-)
create mode 100644 src/gallium/state_trackers/osmesa/SConscript
create mode 100644 src/gallium/targets/osmesa/SConscript
create mode 100644 src/gallium/targets/osmesa/osmesa.def
create mode 100644 src/gallium/targets/osmesa/osmesa.mingw.def
diff --git a/src/gallium/SConscript b/src/gallium/SConscript
index 680ad92..eeb1c78 100644
--- a/src/gallium/SConscript
+++ b/src/gallium/SConscript
@@ -60,6 +60,11 @@ SConscript([
])
if not env['embedded']:
+SConscript([
+'state_trackers/osmesa/SConscript',
+'targets/osmesa/SConscript',
+])
+
if env['x11']:
SConscript([
'state_trackers/glx/xlib/SConscript',
diff --git a/src/gallium/state_trackers/osmesa/Makefile.am
b/src/gallium/state_trackers/osmesa/Makefile.am
index 4ba6c20..22e65c8 100644
--- a/src/gallium/state_trackers/osmesa/Makefile.am
+++ b/src/gallium/state_trackers/osmesa/Makefile.am
@@ -39,3 +39,5 @@ AM_CPPFLAGS = \
noinst_LTLIBRARIES = libosmesa.la
libosmesa_la_SOURCES = $(C_SOURCES)
+
+EXTRA_DIST = SConscript
diff --git a/src/gallium/state_trackers/osmesa/SConscript
b/src/gallium/state_trackers/osmesa/SConscript
new file mode 100644
index 000..f5519f1
--- /dev/null
+++ b/src/gallium/state_trackers/osmesa/SConscript
@@ -0,0 +1,26 @@
+import os
+
+Import('*')
+
+env = env.Clone()
+
+env.Append(CPPPATH = [
+'#src/mapi',
+'#src/mesa',
+'.',
+])
+
+if env['platform'] == 'windows':
+env.AppendUnique(CPPDEFINES = [
+'BUILD_GL32', # declare gl* as __declspec(dllexport) in Mesa headers
+'WIN32_LEAN_AND_MEAN', #
http://msdn2.microsoft.com/en-us/library/6dwk3a1z.aspx
+])
+if not env['gles']:
+# prevent _glapi_* from being declared __declspec(dllimport)
+env.Append(CPPDEFINES = ['_GLAPI_NO_EXPORTS'])
+
+st_osmesa = env.ConvenienceLibrary(
+target ='st_osmesa',
+source = env.ParseSourceList('Makefile.sources', 'C_SOURCES'),
+)
+Export('st_osmesa')
diff --git a/src/gallium/targets/osmesa/Makefile.am
b/src/gallium/targets/osmesa/Makefile.am
index f53823a..2c09736 100644
--- a/src/gallium/targets/osmesa/Makefile.am
+++ b/src/gallium/targets/osmesa/Makefile.am
@@ -76,7 +76,11 @@ lib@OSMESA_LIB@_la_LIBADD +=
$(top_builddir)/src/gallium/drivers/llvmpipe/libllv
endif
EXTRA_lib@OSMESA_LIB@_la_DEPENDENCIES = osmesa.sym
-EXTRA_DIST = osmesa.sym
+EXTRA_DIST = \
+ osmesa.sym \
+ osmesa.def \
+ osmesa.mingw.def \
+ SConscript
include $(top_srcdir)/install-gallium-links.mk
diff --git a/src/gallium/targets/osmesa/SConscript
b/src/gallium/targets/osmesa/SConscript
new file mode 100644
index 000..4a9115b
--- /dev/null
+++ b/src/gallium/targets/osmesa/SConscript
@@ -0,0 +1,43 @@
+Import('*')
+
+env = env.Clone()
+
+env.Prepend(CPPPATH = [
+'#src/mapi',
+'#src/mesa',
+#Dir('../../../mapi'), # src/mapi build path for python-generated GL API
files/headers
+])
+
+env.Prepend(LIBS = [
+st_osmesa,
+ws_null,
+glapi,
+mesa,
+gallium,
+trace,
+glsl,
+mesautil,
+softpipe
+])
+
+env.Append(CPPDEFINES = ['GALLIUM_TRACE', 'GALLIUM_SOFTPIPE'])
+
+sources = ['target.c']
+
+if env['llvm']:
+env.Append(CPPDEFINES = 'GALLIUM_LLVMPIPE')
+env.Prepend(LIBS = [llvmpipe])
+
+if env['platform'] == 'windows':
+if env['gcc'] and env['machine'] != 'x86_64':
+sources += ['osmesa.mingw.def']
+else:
+sources += ['osmesa.def']
+
+gallium_osmesa = env.SharedLibrary(
+target ='osmesa',
+source = sources,
+LIBS = env['LIBS'],
+)
+
+env.Alias('osmesa', gallium_osmesa)
diff --git a/src/gallium/targets/osmesa/osmesa.def
b/src/gallium/targets/osmesa/osmesa.def
new file mode 100644
index 000..e2a31ab
--- /dev/null
+++ b/src/gallium/targets/osmesa/osmesa.def
@@ -0,0 +1,16 @@
+;DESCRIPTION 'Mesa OSMesa lib for Win32'
+VERSION 4.1
+
+EXPORTS
+ OSMesaCreateContext
+ OSMesaCreateContextExt
+ OSMesaDestroyContext
+ OSMesaMakeCurrent
+ OSMesaGetCurrentContext
+ OSMesaPixelStore
+ OSMesaGetIntegerv
+ OSMesaGetDepthBuffer
+ OSMesaGetColorBuffer
+ OSMesaGetProcAddress
+ OSMesaColorClamp
+ OSMesaPostprocess
diff --git a/src/gallium/targets/osmesa/osmesa.mingw.def
b/src/gallium/targets/osmesa/osmesa.mingw.def
new file mode 100644
index 000..874ac54
--- /dev/null
+++
[Mesa-dev] [PATCH 2/2] r600g, radeonsi: add a driver query returning GPU load
From: Marek Olšák marek.ol...@amd.com
---
src/gallium/drivers/radeon/Makefile.am| 4 +-
src/gallium/drivers/radeon/Makefile.sources | 1 +
src/gallium/drivers/radeon/r600_gpu_load.c| 141 ++
src/gallium/drivers/radeon/r600_pipe_common.c | 7 +-
src/gallium/drivers/radeon/r600_pipe_common.h | 13 ++
src/gallium/drivers/radeon/r600_query.c | 11 ++
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 16 +++
src/gallium/winsys/radeon/drm/radeon_winsys.h | 3 +
8 files changed, 194 insertions(+), 2 deletions(-)
create mode 100644 src/gallium/drivers/radeon/r600_gpu_load.c
diff --git a/src/gallium/drivers/radeon/Makefile.am
b/src/gallium/drivers/radeon/Makefile.am
index ef6b999..13d8976 100644
--- a/src/gallium/drivers/radeon/Makefile.am
+++ b/src/gallium/drivers/radeon/Makefile.am
@@ -4,7 +4,9 @@ include $(top_srcdir)/src/gallium/Automake.inc
AM_CFLAGS = \
$(GALLIUM_DRIVER_CFLAGS) \
- $(RADEON_CFLAGS)
+ $(RADEON_CFLAGS) \
+ -Wstrict-overflow=0
+# ^^ disable warnings about overflows (os_time_timeout)
noinst_LTLIBRARIES = libradeon.la
diff --git a/src/gallium/drivers/radeon/Makefile.sources
b/src/gallium/drivers/radeon/Makefile.sources
index f2b70a1..469f6d1 100644
--- a/src/gallium/drivers/radeon/Makefile.sources
+++ b/src/gallium/drivers/radeon/Makefile.sources
@@ -3,6 +3,7 @@ C_SOURCES := \
r600_buffer_common.c \
r600_cs.h \
r600d_common.h \
+ r600_gpu_load.c \
r600_pipe_common.c \
r600_pipe_common.h \
r600_query.c \
diff --git a/src/gallium/drivers/radeon/r600_gpu_load.c
b/src/gallium/drivers/radeon/r600_gpu_load.c
new file mode 100644
index 000..a653834
--- /dev/null
+++ b/src/gallium/drivers/radeon/r600_gpu_load.c
@@ -0,0 +1,141 @@
+/*
+ * Copyright 2015 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE
+ * SOFTWARE.
+ *
+ * Authors: Marek Olšák mar...@gmail.com
+ *
+ */
+
+/* The GPU load is measured as follows.
+ *
+ * There is a thread which samples the GRBM_STATUS register at a certain
+ * frequency and the busy or idle counter is incremented based on
+ * whether the GUI_ACTIVE bit is set or not.
+ *
+ * Then, the user can sample the counters twice and calculate the average
+ * GPU load between the two samples.
+ */
+
+#include r600_pipe_common.h
+#include os/os_time.h
+
+/* For good accuracy at 1000 fps or lower. This will be inaccurate for higher
+ * fps (there are too few samples per frame). */
+#define SAMPLES_PER_SEC 1
+
+#define GRBM_STATUS0x8010
+#define GUI_ACTIVE(x) (((x) 31) 0x1)
+
+static bool r600_is_gpu_busy(struct r600_common_screen *rscreen)
+{
+ uint32_t value = 0;
+
+ rscreen-ws-read_registers(rscreen-ws, GRBM_STATUS, 1, value);
+ return GUI_ACTIVE(value);
+}
+
+static PIPE_THREAD_ROUTINE(r600_gpu_load_thread, param)
+{
+ struct r600_common_screen *rscreen = (struct r600_common_screen*)param;
+ const int period_us = 100 / SAMPLES_PER_SEC;
+ int sleep_us = period_us;
+ int64_t cur_time, last_time = os_time_get();
+
+ while (!p_atomic_read(rscreen-gpu_load_stop_thread)) {
+ if (sleep_us)
+ os_time_sleep(sleep_us);
+
+ /* Make sure we sleep the ideal amount of time to match
+* the expected frequency. */
+ cur_time = os_time_get();
+
+ if (os_time_timeout(last_time, last_time + period_us,
+ cur_time))
+ sleep_us = MAX2(sleep_us - 1, 1);
+ else
+ sleep_us += 1;
+
+ /*printf(Hz: %.1f\n, 100.0 / (cur_time - last_time));*/
+ last_time = cur_time;
+
+ /* Update the counters. */
+ if (r600_is_gpu_busy(rscreen))
+
Re: [Mesa-dev] [PATCH] i965: Unhardcode a few more stage names and abbreviations.
On Mon, Apr 27, 2015 at 2:57 PM, Kenneth Graunke kenn...@whitecape.org wrote:
The stage_abbrev and stage_name fields in backend_visitor provide what
we need without any additional effort. It also means we'll get the
right names for compute shaders, SIMD8 geometry shaders, and both kinds
of tessellation shaders.
This does unfortunately change the capitalization of the stage
abbreviation in the INTEL_DEBUG=optimizer output filenames. It doesn't
seem worth adding code to handle, though.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 10 +++---
src/mesa/drivers/dri/i965/brw_vec4.cpp | 6 ++
2 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 61ee056..4e4f646 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -3763,8 +3763,6 @@ fs_visitor::calculate_register_pressure()
void
fs_visitor::optimize()
{
- const char *stage_name = stage == MESA_SHADER_VERTEX ? vs : fs;
-
split_virtual_grfs();
move_uniform_array_access_to_pull_constants();
@@ -3778,7 +3776,7 @@ fs_visitor::optimize()
if (unlikely(INTEL_DEBUG DEBUG_OPTIMIZER) this_progress) { \
char filename[64]; \
snprintf(filename, 64, %s%d-%04d-%02d-%02d- #pass, \
- stage_name, dispatch_width, shader_prog ?
shader_prog-Name : 0, iteration, pass_num); \
+ stage_abbrev, dispatch_width, shader_prog ?
shader_prog-Name : 0, iteration, pass_num); \
\
backend_visitor::dump_instructions(filename); \
} \
@@ -3790,7 +3788,8 @@ fs_visitor::optimize()
if (unlikely(INTEL_DEBUG DEBUG_OPTIMIZER)) {
char filename[64];
snprintf(filename, 64, %s%d-%04d-00-start,
- stage_name, dispatch_width, shader_prog ? shader_prog-Name :
0);
+ stage_abbrev, dispatch_width,
+ shader_prog ? shader_prog-Name : 0);
backend_visitor::dump_instructions(filename);
}
@@ -3882,9 +3881,6 @@ fs_visitor::allocate_registers()
}
if (!allocated_without_spills) {
- const char *stage_name = stage == MESA_SHADER_VERTEX ?
- Vertex : Fragment;
-
/* We assume that any spilling is worse than just dropping back to
* SIMD8. There's probably actually some intermediate point where
* SIMD16 with a couple of spills is still better.
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp
b/src/mesa/drivers/dri/i965/brw_vec4.cpp
index 8ce07637..57b507d 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
@@ -1700,8 +1700,6 @@ vec4_visitor::run()
move_push_constants_to_pull_constants();
split_virtual_grfs();
- const char *stage_name = stage == MESA_SHADER_GEOMETRY ? gs : vs;
-
#define OPT(pass, args...) ({ \
pass_num++; \
bool this_progress = pass(args); \
@@ -1709,7 +1707,7 @@ vec4_visitor::run()
if (unlikely(INTEL_DEBUG DEBUG_OPTIMIZER) this_progress) { \
char filename[64];\
snprintf(filename, 64, %s-%04d-%02d-%02d- #pass,\
- stage_name, shader_prog ? shader_prog-Name : 0,
iteration, pass_num); \
+ stage_abbrev, shader_prog ? shader_prog-Name : 0,
iteration, pass_num); \
\
backend_visitor::dump_instructions(filename); \
}\
@@ -1722,7 +1720,7 @@ vec4_visitor::run()
if (unlikely(INTEL_DEBUG DEBUG_OPTIMIZER)) {
char filename[64];
snprintf(filename, 64, %s-%04d-00-start,
- stage_name, shader_prog ? shader_prog-Name : 0);
+ stage_abbrev, shader_prog ? shader_prog-Name : 0);
backend_visitor::dump_instructions(filename);
}
--
2.3.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Reviewed-by: Anuj Phogat anuj.pho...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 13/20] i965/fs: Support compute programs in fs_visitor
On Friday, April 24, 2015 04:33:05 PM Jordan Justen wrote:
v2:
* Clean out some unneeded code copied from run_fs (krh)
* Always use NIR
* Split shader time out into a separate commit
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
src/mesa/drivers/dri/i965/brw_context.c | 2 +
src/mesa/drivers/dri/i965/brw_fs.cpp | 61
++--
src/mesa/drivers/dri/i965/brw_fs.h | 10 +
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 23 +++
4 files changed, 93 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index 9d90360..25b50c7 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -594,6 +594,8 @@ brw_initialize_context_constants(struct brw_context *brw)
if (brw_env_var_as_boolean(INTEL_USE_NIR, true))
ctx-Const.ShaderCompilerOptions[MESA_SHADER_FRAGMENT].NirOptions =
nir_options;
+ ctx-Const.ShaderCompilerOptions[MESA_SHADER_COMPUTE].NirOptions =
nir_options;
+
/* ARB_viewport_array */
if (brw-gen = 7 ctx-API == API_OPENGL_CORE) {
ctx-Const.MaxViewports = GEN7_NUM_VIEWPORTS;
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 61ee056..24d3fa9 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -1719,9 +1719,15 @@ fs_visitor::assign_curb_setup()
if (dispatch_width == 8) {
prog_data-dispatch_grf_start_reg = payload.num_regs;
} else {
- assert(stage == MESA_SHADER_FRAGMENT);
- brw_wm_prog_data *prog_data = (brw_wm_prog_data*) this-prog_data;
- prog_data-dispatch_grf_start_reg_16 = payload.num_regs;
+ if (stage == MESA_SHADER_FRAGMENT) {
+ brw_wm_prog_data *prog_data = (brw_wm_prog_data*) this-prog_data;
+ prog_data-dispatch_grf_start_reg_16 = payload.num_regs;
+ } else if (stage == MESA_SHADER_COMPUTE) {
+ brw_cs_prog_data *prog_data = (brw_cs_prog_data*) this-prog_data;
+ prog_data-dispatch_grf_start_reg_16 = payload.num_regs;
+ } else {
+ unreachable(Unsupported shader type!);
+ }
}
We should be able to eliminate brw_cs_prog_data::dispatch_grf_start_reg_16
and just use brw_stage_prog_data::dispatch_grf_start_reg (since compute
shaders only use one SIMD mode).
I think you want to simplify this hunk to:
if (stage != MESA_SHADER_FRAGMENT || dispatch_width == 8) {
prog_data-dispatch_grf_start_reg = payload.num_regs;
} else {
brw_wm_prog_data *prog_data = (brw_wm_prog_data*) this-prog_data;
prog_data-dispatch_grf_start_reg_16 = payload.num_regs;
}
prog_data-curb_read_length = ALIGN(stage_prog_data-nr_params, 8) / 8;
@@ -3726,6 +3732,14 @@ fs_visitor::setup_vs_payload()
}
void
+fs_visitor::setup_cs_payload()
+{
+ assert(brw-gen = 7);
+
+ payload.num_regs = 1;
+}
Are you planning to add more code here? Not sure if it's worth a
helper function. It's probably fine though :)
+
+void
fs_visitor::assign_binding_table_offsets()
{
assert(stage == MESA_SHADER_FRAGMENT);
@@ -4065,6 +4079,47 @@ fs_visitor::run_fs()
return !failed;
}
+bool
+fs_visitor::run_cs()
+{
+ assert(stage == MESA_SHADER_COMPUTE);
+ assert (shader);
^^^ bonus space
Patches 1-13 are:
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/38] main: Add utility function _mesa_lookup_framebuffer_err.
On Tue, Mar 3, 2015 at 5:31 PM, Laura Ekstrand la...@jlekstrand.net wrote:
---
src/mesa/main/fbobject.c | 18 ++
src/mesa/main/fbobject.h | 4
2 files changed, 22 insertions(+)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index f8d0d92..8c2eb25 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -136,6 +136,24 @@ _mesa_lookup_framebuffer(struct gl_context *ctx, GLuint
id)
return fb;
}
+/**
+ * A convenience function for direct state access that throws
+ * GL_INVALID_OPERATION if the framebuffer id is not found in the hash table.
+ */
+struct gl_framebuffer *
+_mesa_lookup_framebuffer_err(struct gl_context *ctx, GLuint id,
+ const char *func)
+{
+ struct gl_framebuffer *fb;
+
+ fb = _mesa_lookup_framebuffer(ctx, id);
+ if (!fb)
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ %s(non-generated framebuffer name=%u), func, id);
+
+ return fb;
+}
+
/**
* Mark the given framebuffer as invalid. This will force the
diff --git a/src/mesa/main/fbobject.h b/src/mesa/main/fbobject.h
index 77fdef4..7aa5205 100644
--- a/src/mesa/main/fbobject.h
+++ b/src/mesa/main/fbobject.h
@@ -67,6 +67,10 @@ _mesa_lookup_renderbuffer(struct gl_context *ctx, GLuint
id);
extern struct gl_framebuffer *
_mesa_lookup_framebuffer(struct gl_context *ctx, GLuint id);
+extern struct gl_framebuffer *
+_mesa_lookup_framebuffer_err(struct gl_context *ctx, GLuint id,
+ const char *func);
+
void
_mesa_update_texture_renderbuffer(struct gl_context *ctx,
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
With Fredrik's comment fixed:
Reviewed-by: Anuj Phogat anuj.pho...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] meta: remove unneeded #include colortab.h
--- src/mesa/drivers/common/meta.c | 1 - 1 file changed, 1 deletion(-) diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c index cf99d95..d2ab7b8 100644 --- a/src/mesa/drivers/common/meta.c +++ b/src/mesa/drivers/common/meta.c @@ -41,7 +41,6 @@ #include main/bufferobj.h #include main/buffers.h #include main/clear.h -#include main/colortab.h #include main/condrender.h #include main/depth.h #include main/enable.h -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] mesa: remove unneeded #include colortab.h
--- src/mesa/main/texobj.c | 1 - 1 file changed, 1 deletion(-) diff --git a/src/mesa/main/texobj.c b/src/mesa/main/texobj.c index e018ab9..c563f1e 100644 --- a/src/mesa/main/texobj.c +++ b/src/mesa/main/texobj.c @@ -30,7 +30,6 @@ #include stdio.h #include bufferobj.h -#include colortab.h #include context.h #include enums.h #include fbobject.h -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 15/20] i965/cs: Emit compute shader code and upload programs
On Friday, April 24, 2015 04:33:07 PM Jordan Justen wrote:
v2:
* Don't bother checking for 'gen 5' (krh)
* Populate sampler data in key (krh)
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
src/mesa/drivers/dri/i965/brw_context.h | 1 +
src/mesa/drivers/dri/i965/brw_cs.cpp | 224
+++
src/mesa/drivers/dri/i965/brw_state_upload.c | 3 +
3 files changed, 228 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index 56827d8..9e13c59 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -148,6 +148,7 @@ struct brw_vs_prog_key;
struct brw_vue_prog_key;
struct brw_wm_prog_key;
struct brw_wm_prog_data;
+struct brw_cs_prog_key;
struct brw_cs_prog_data;
enum brw_pipeline {
diff --git a/src/mesa/drivers/dri/i965/brw_cs.cpp
b/src/mesa/drivers/dri/i965/brw_cs.cpp
index 8021147..648f0f0 100644
--- a/src/mesa/drivers/dri/i965/brw_cs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_cs.cpp
@@ -22,8 +22,15 @@
*/
+#include util/ralloc.h
#include brw_context.h
#include brw_cs.h
+#include brw_fs.h
+#include brw_eu.h
+#include brw_wm.h
+#include intel_mipmap_tree.h
+#include brw_state.h
+#include intel_batchbuffer.h
extern C
bool
@@ -46,3 +53,220 @@ brw_cs_prog_data_compare(const void *in_a, const void
*in_b)
return true;
}
+
+
+static const unsigned *
+brw_cs_emit(struct brw_context *brw,
+void *mem_ctx,
+const struct brw_cs_prog_key *key,
+struct brw_cs_prog_data *prog_data,
+struct gl_compute_program *cp,
+struct gl_shader_program *prog,
+unsigned *final_assembly_size)
+{
+ bool start_busy = false;
+ double start_time = 0;
+
+ if (unlikely(brw-perf_debug)) {
+ start_busy = (brw-batch.last_bo
+drm_intel_bo_busy(brw-batch.last_bo));
+ start_time = get_time();
+ }
+
+ struct brw_shader *shader = NULL;
+ if (prog)
+ shader = (struct brw_shader *)
prog-_LinkedShaders[MESA_SHADER_COMPUTE];
+
+ if (unlikely(INTEL_DEBUG DEBUG_CS))
+ brw_dump_ir(compute, prog, shader-base, cp-Base);
+
+ /* Now the main event: Visit the shader IR and generate our CS IR for it.
+*/
+ fs_visitor v(brw, mem_ctx, key, prog_data, prog, cp, 8);
+ if (!v.run_cs()) {
+ if (prog) {
+ prog-LinkStatus = false;
+ ralloc_strcat(prog-InfoLog, v.fail_msg);
+ }
+
+ _mesa_problem(NULL, Failed to compile fragment shader: %s\n,
+v.fail_msg);
+
+ return NULL;
+ }
+
+ cfg_t *simd16_cfg = NULL;
+ fs_visitor v2(brw, mem_ctx, key, prog_data, prog, cp, 16);
+ if (likely(!(INTEL_DEBUG DEBUG_NO16))) {
I know some programs may require SIMD16 shaders to even function (on
some hardware), and that you're planning to make SIMD16 compute shader
compilation never fail (at some point). So we may want to rework this
logic eventually. But it's probably OK for now.
+ if (!v.simd16_unsupported) {
+ /* Try a SIMD16 compile */
+ v2.import_uniforms(v);
+ if (!v2.run_cs()) {
+perf_debug(SIMD16 shader failed to compile, falling back to
+ SIMD8 at a 10-20%% performance cost: %s,
v2.fail_msg);
+ } else {
+simd16_cfg = v2.cfg;
+ }
+ } else {
+ perf_debug(SIMD16 shader unsupported, falling back to
+SIMD8 at a 10-20%% performance cost: %s, v.no16_msg);
+ }
+ }
Let's eliminate the at a 10-20% performance cost part of the messages.
That was something Eric measured about fragment shading - the
performance characteristics of compute shaders will probably be entirely
different.
+
+ prog_data-local_size[0] = cp-LocalSize[0];
+ prog_data-local_size[1] = cp-LocalSize[1];
+ prog_data-local_size[2] = cp-LocalSize[2];
+
+ cfg_t *simd8_cfg;
+ int no_simd8 = (INTEL_DEBUG DEBUG_NO8) || brw-no_simd8;
I don't really see any value in supporting INTEL_DEBUG=no8 for compute
shaders. Let's just drop this.
Why don't we have a single cfg_t *cfg variable. After compiling the
SIMD8 program, set cfg = v.cfg and prog_data-simd_size = 8. If we
successfully compile a SIMD16 program, set cfg = v2.cfg and override
prog_data-simd_size = 16. Then pass cfg to fs_generator.
I think that'll streamline this code a fair bit.
+ if (no_simd8 simd16_cfg) {
+ simd8_cfg = NULL;
+ prog_data-no_8 = true;
+ } else {
+ simd8_cfg = v.cfg;
+ prog_data-no_8 = false;
+ }
+
+ fs_generator g(brw, mem_ctx, (void*) key, prog_data-base, cp-Base,
+ v.promoted_constants, v.runtime_check_aads_emit, CS);
+ if (INTEL_DEBUG DEBUG_CS) {
+ char *name = ralloc_asprintf(mem_ctx, %s compute shader %d,
+
Re: [Mesa-dev] [PATCH 5/7] i965: use _mesa_geometry_width/height/layers/samples for programming geometry of framebuffer to GEN
On Friday, April 24, 2015 04:02:18 PM Rogovin, Kevin wrote: Actually I realized that you add quite a bit of support to gen4-6 logic that _isn't_ used for gen7 and higher. In the last patch of the series you claim to enable this only for gen7 and higher - I'm confused. There are two reasons: 1. Because atoms get reused all the time across generations, it is just easier to use the _mesa_geomety_* functions in any batch buffer builder that is concerned about the geometry of the render target. It keeps the code consistent and much easier than checking what functions and atoms are directly or indirectly used by different Gens. However, blorp, blitting and a few others are left untouched since they want to talk about the buffer, not really 3D pipeline rasterization things. 2. At first I was going to support pre Gen7 hardware with the series. However, I do not have hardware on which to test it. In truth I want this to also run on pre-Gen7, but without testing on device, I cannot vouch for the patches. I believe it should just work for pre Gen7 (by just tweaking the last patch to enable it on pre Gen7), but I would rather be careful than in this case. I also confess, it is a silly extension for pre Gen7 anyways... -Kevin A couple of us chatted about this, and we all agreed that it's probably not useful to enable ARB_framebuffer_no_attachments on pre-Gen7. We don't expose atomics, SSBOs, or image load/store on those platforms (and probably won't), so the only way fragment shaders can output any data is via framebuffer writes. So I'd be inclined to just not touch the pre-Gen7 code at all. signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Regarding X.Org Endless Vacation of Code
Hello, I am a final year Computer Engineering student from Sardar Patel Institute of Technology. I have a good understanding of C and I have worked on projects using C as a part of my coursework. I am interested in working on the Improved application of GLSL complier optimizations project idea for EVoC. So before submitting an application, I understand that I need to understand the code base and submit patches to show my programming proficiency and problem solving skills. However, before I begin doing so, I would like you to answer few queries - 1. Can a proposal have only one 'easy' project idea (or will one have to club two easy ones)? 2. Could you point me to the necessary resources which will help me understand the project? 3. Could you also tell me how to set up the development environment for setting up this project? Thanks, Anish Kanchan Student, University of Mumbai ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Unhardcode a few more stage names and abbreviations.
On Mon, Apr 27, 2015 at 2:57 PM, Kenneth Graunke kenn...@whitecape.org wrote:
The stage_abbrev and stage_name fields in backend_visitor provide what
we need without any additional effort. It also means we'll get the
right names for compute shaders, SIMD8 geometry shaders, and both kinds
of tessellation shaders.
This does unfortunately change the capitalization of the stage
abbreviation in the INTEL_DEBUG=optimizer output filenames. It doesn't
seem worth adding code to handle, though.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 10 +++---
src/mesa/drivers/dri/i965/brw_vec4.cpp | 6 ++
2 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 61ee056..4e4f646 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -3763,8 +3763,6 @@ fs_visitor::calculate_register_pressure()
void
fs_visitor::optimize()
{
- const char *stage_name = stage == MESA_SHADER_VERTEX ? vs : fs;
-
split_virtual_grfs();
move_uniform_array_access_to_pull_constants();
@@ -3778,7 +3776,7 @@ fs_visitor::optimize()
if (unlikely(INTEL_DEBUG DEBUG_OPTIMIZER) this_progress) { \
char filename[64]; \
snprintf(filename, 64, %s%d-%04d-%02d-%02d- #pass, \
- stage_name, dispatch_width, shader_prog ?
shader_prog-Name : 0, iteration, pass_num); \
+ stage_abbrev, dispatch_width, shader_prog ?
shader_prog-Name : 0, iteration, pass_num); \
\
backend_visitor::dump_instructions(filename); \
} \
@@ -3790,7 +3788,8 @@ fs_visitor::optimize()
if (unlikely(INTEL_DEBUG DEBUG_OPTIMIZER)) {
char filename[64];
snprintf(filename, 64, %s%d-%04d-00-start,
- stage_name, dispatch_width, shader_prog ? shader_prog-Name :
0);
+ stage_abbrev, dispatch_width,
+ shader_prog ? shader_prog-Name : 0);
backend_visitor::dump_instructions(filename);
}
@@ -3882,9 +3881,6 @@ fs_visitor::allocate_registers()
}
if (!allocated_without_spills) {
- const char *stage_name = stage == MESA_SHADER_VERTEX ?
- Vertex : Fragment;
-
I was confused for a second how this could work, since stage_name is
used right after this hunk ends, but stage_name/stage_abbrev are
backend_visitor members. As long as you don't care that we're losing
the capital V/F with this change, the patch is
Reviewed-by: Matt Turner matts...@gmail.com
/* We assume that any spilling is worse than just dropping back to
* SIMD8. There's probably actually some intermediate point where
* SIMD16 with a couple of spills is still better.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 00/20] i965 basic CS program generation support
On Friday, April 24, 2015 04:32:52 PM Jordan Justen wrote: git://people.freedesktop.org/~jljusten/mesa i965-cs-prog-v2 These patches could use review: * [08/20] i965/fs: Add emit_cs_terminate to emit CS_OPCODE_CS_TERMINATE * [10/20] i965/cs: Add generator support for CS_OPCODE_CS_TERMINATE * [13/20] i965/fs: Support compute programs in fs_visitor * [14/20] i965/cs: Add max_cs_threads * [15/20] i965/cs: Emit compute shader code and upload programs * [16/20] i965: Add brw_setup_tex_for_precompile. Use in VS, GS FS. * [17/20] i965/cs: Support CS program precompile * [18/20] i965: Remove comment about chv device numbers relating to hsw gt1 * [19/20] i965/cs: Upload brw_cs_state * [20/20] i965/fs: Add CS shader time support Patch 19 is Acked-by, the rest are Reviewed-by, assuming you incorporate my suggestions. Nice work as usual! Thanks Jordan! signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Regarding X.Org Endless Vacation of Code
On Mon, Apr 27, 2015 at 3:58 PM, Anish Kanchan anishgkanc...@gmail.com wrote: Hello, I am a final year Computer Engineering student from Sardar Patel Institute of Technology. I have a good understanding of C and I have worked on projects using C as a part of my coursework. I am interested in working on the Improved application of GLSL complier optimizations project idea for EVoC. I responded to someone else's question about this project -- see here: http://lists.freedesktop.org/archives/mesa-dev/2015-March/079293.html Basically, I don't think it's an interesting project. It may have been at one point, but not any more. So before submitting an application, I understand that I need to understand the code base and submit patches to show my programming proficiency and problem solving skills. However, before I begin doing so, I would like you to answer few queries - 1. Can a proposal have only one 'easy' project idea (or will one have to club two easy ones)? 2. Could you point me to the necessary resources which will help me understand the project? It's not really a software project that you can just quickly understand fully. :) Lots of us have been working on it for years and aren't even interested in understanding it fully. 3. Could you also tell me how to set up the development environment for setting up this project? I've been meaning to create a wiki page. Hopefully I can do this soon. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 00/20] i965 basic CS program generation support
On Monday, April 27, 2015 05:44:48 PM Kenneth Graunke wrote: On Friday, April 24, 2015 04:32:52 PM Jordan Justen wrote: git://people.freedesktop.org/~jljusten/mesa i965-cs-prog-v2 These patches could use review: * [08/20] i965/fs: Add emit_cs_terminate to emit CS_OPCODE_CS_TERMINATE * [10/20] i965/cs: Add generator support for CS_OPCODE_CS_TERMINATE * [13/20] i965/fs: Support compute programs in fs_visitor * [14/20] i965/cs: Add max_cs_threads * [15/20] i965/cs: Emit compute shader code and upload programs * [16/20] i965: Add brw_setup_tex_for_precompile. Use in VS, GS FS. * [17/20] i965/cs: Support CS program precompile * [18/20] i965: Remove comment about chv device numbers relating to hsw gt1 * [19/20] i965/cs: Upload brw_cs_state * [20/20] i965/fs: Add CS shader time support Patch 19 is Acked-by, the rest are Reviewed-by, assuming you incorporate my suggestions. Nice work as usual! Thanks Jordan! Oh, sorry, I didn't actually review the thread count patch. I'm not completely following how that's used in order to verify the values. signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 90207] [r600g, bisected] regression: NI/Turks crash on WebGL Water (most WebGL stuff)
https://bugs.freedesktop.org/show_bug.cgi?id=90207 --- Comment #2 from Tapani Pälli lem...@gmail.com --- seems to work with chrome and firefox, will attempt to reproduce with konqueror -- You are receiving this mail because: You are on the CC list for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 03/13] nir: Add and use initializer #defines for nir_src and nir_dest
---
src/glsl/nir/glsl_to_nir.cpp | 2 +-
src/glsl/nir/nir.h | 13 +++--
src/glsl/nir/nir_builder.h | 6 ++
src/glsl/nir/nir_lower_samplers.cpp| 5 ++---
src/glsl/nir/nir_lower_tex_projector.c | 5 ++---
src/glsl/nir/nir_search.c | 2 +-
6 files changed, 15 insertions(+), 18 deletions(-)
diff --git a/src/glsl/nir/glsl_to_nir.cpp b/src/glsl/nir/glsl_to_nir.cpp
index f6b8331..ed70508 100644
--- a/src/glsl/nir/glsl_to_nir.cpp
+++ b/src/glsl/nir/glsl_to_nir.cpp
@@ -824,7 +824,7 @@ nir_visitor::evaluate_rvalue(ir_rvalue* ir)
nir_dest *dest = get_instr_dest(this-result);
assert(dest-is_ssa);
- nir_src src;
+ nir_src src = NIR_SRC_INIT;
src.is_ssa = true;
src.ssa = dest-ssa;
diff --git a/src/glsl/nir/nir.h b/src/glsl/nir/nir.h
index 98b0ec3..a174666 100644
--- a/src/glsl/nir/nir.h
+++ b/src/glsl/nir/nir.h
@@ -497,6 +497,8 @@ typedef struct nir_src {
bool is_ssa;
} nir_src;
+#define NIR_SRC_INIT (nir_src) { { { NULL } } }
+
typedef struct {
union {
nir_reg_dest reg;
@@ -506,10 +508,12 @@ typedef struct {
bool is_ssa;
} nir_dest;
+#define NIR_DEST_INIT (nir_dest) { { { NULL } } }
+
static inline nir_src
nir_src_for_ssa(nir_ssa_def *def)
{
- nir_src src;
+ nir_src src = NIR_SRC_INIT;
src.is_ssa = true;
src.ssa = def;
@@ -520,7 +524,7 @@ nir_src_for_ssa(nir_ssa_def *def)
static inline nir_src
nir_src_for_reg(nir_register *reg)
{
- nir_src src;
+ nir_src src = NIR_SRC_INIT;
src.is_ssa = false;
src.reg.reg = reg;
@@ -543,12 +547,9 @@ nir_src_get_parent_instr(const nir_src *src)
static inline nir_dest
nir_dest_for_reg(nir_register *reg)
{
- nir_dest dest;
+ nir_dest dest = NIR_DEST_INIT;
- dest.is_ssa = false;
dest.reg.reg = reg;
- dest.reg.indirect = NULL;
- dest.reg.base_offset = 0;
return dest;
}
diff --git a/src/glsl/nir/nir_builder.h b/src/glsl/nir/nir_builder.h
index d1419ee..9223e83 100644
--- a/src/glsl/nir/nir_builder.h
+++ b/src/glsl/nir/nir_builder.h
@@ -231,8 +231,7 @@ static inline nir_ssa_def *
nir_swizzle(nir_builder *build, nir_ssa_def *src, unsigned swiz[4],
unsigned num_components, bool use_fmov)
{
- nir_alu_src alu_src;
- memset(alu_src, 0, sizeof(alu_src));
+ nir_alu_src alu_src = { NIR_SRC_INIT };
alu_src.src = nir_src_for_ssa(src);
for (int i = 0; i 4; i++)
alu_src.swizzle[i] = swiz[i];
@@ -251,8 +250,7 @@ nir_ssa_for_src(nir_builder *build, nir_src src, int
num_components)
if (src.is_ssa src.ssa-num_components == num_components)
return src.ssa;
- nir_alu_src alu;
- memset(alu, 0, sizeof(alu));
+ nir_alu_src alu = { NIR_SRC_INIT };
alu.src = src;
for (int j = 0; j 4; j++)
alu.swizzle[j] = j;
diff --git a/src/glsl/nir/nir_lower_samplers.cpp
b/src/glsl/nir/nir_lower_samplers.cpp
index cf8ab83..e9e152f 100644
--- a/src/glsl/nir/nir_lower_samplers.cpp
+++ b/src/glsl/nir/nir_lower_samplers.cpp
@@ -95,9 +95,8 @@ lower_sampler(nir_tex_instr *instr, const struct
gl_shader_program *shader_progr
instr-sampler_array_size = glsl_get_length(deref-type);
-nir_src empty;
-memset(empty, 0, sizeof empty);
-nir_instr_rewrite_src(instr-instr, deref_array-indirect,
empty);
+nir_instr_rewrite_src(instr-instr, deref_array-indirect,
+ NIR_SRC_INIT);
if (deref_array-deref.child)
ralloc_strcat(name, [0]);
diff --git a/src/glsl/nir/nir_lower_tex_projector.c
b/src/glsl/nir/nir_lower_tex_projector.c
index 6b0e9c3..6e2cc80 100644
--- a/src/glsl/nir/nir_lower_tex_projector.c
+++ b/src/glsl/nir/nir_lower_tex_projector.c
@@ -109,9 +109,8 @@ nir_lower_tex_projector_block(nir_block *block, void
*void_state)
/* Now move the later tex sources down the array so that the projector
* disappears.
*/
- nir_src dead;
- memset(dead, 0, sizeof dead);
- nir_instr_rewrite_src(tex-instr, tex-src[proj_index].src, dead);
+ nir_instr_rewrite_src(tex-instr, tex-src[proj_index].src,
+NIR_SRC_INIT);
memmove(tex-src[proj_index],
tex-src[proj_index + 1],
(tex-num_srcs - proj_index) * sizeof(*tex-src));
diff --git a/src/glsl/nir/nir_search.c b/src/glsl/nir/nir_search.c
index 5ba0160..490b31f 100644
--- a/src/glsl/nir/nir_search.c
+++ b/src/glsl/nir/nir_search.c
@@ -276,7 +276,7 @@ construct_value(const nir_search_value *value, nir_alu_type
type,
const nir_search_variable *var = nir_search_value_as_variable(value);
assert(state-variables_seen (1 var-variable));
- nir_alu_src val;
+ nir_alu_src val = { NIR_SRC_INIT };
nir_alu_src_copy(val, state-variables[var-variable], mem_ctx);
assert(!var-is_constant);
--
2.3.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
[Mesa-dev] [PATCH 11/13] nir/nir: Use a linked list instead of a has set for use/def sets
This commit switches us from the current setup of using hash sets for
use/def sets to using linked lists. Doing so should save us quite a bit of
memory because we aren't carrying around 3 hash sets per register and 2 per
SSA value. It should also save us CPU time because adding/removing things
from use/def sets is 4 pointer manipulations instead of a hash lookup.
On the code complexity side of things, some things are now much easier and
others are a bit harder. One of the operations we perform constantly in
optimization passes is to replace one source with another. Due to the fact
that an instruction can use the same SSA value multiple times, we had to
iterate through the sources of the instruction and determine if the use we
were replacing was the only one before removing it from the set of uses.
With this patch, uses are per-source not per-instruction so we can just
remove it safely. On the other hand, trying to iterate over all of the
instructions that use a given value is more difficult. Fortunately, the
two places we do that are the ffma peephole where it doesn't matter and GCM
where we already gracefully handle duplicates visits to an instruction.
Another aspect here is that using linked lists in this way can be tricky to
get right. With sets, things were quite forgiving and the worst that
happened if you didn't properly remove a use was that it would get caught
in the validator. With linked lists, it can lead to linked list corruption
which can be harder to track. However, we do just as much validation of
the linked lists as we did of the sets so the validator should still catch
these problems. While working on this series, the vast majority of the
bugs I had to fix were caught by assertions. I don't think the lists are
going to be that much worse than the sets.
---
src/glsl/nir/nir.c | 228 +++-
src/glsl/nir/nir.h | 45 +++--
src/glsl/nir/nir_validate.c | 158 +++---
3 files changed, 194 insertions(+), 237 deletions(-)
diff --git a/src/glsl/nir/nir.c b/src/glsl/nir/nir.c
index b8f5dd4..be13c90 100644
--- a/src/glsl/nir/nir.c
+++ b/src/glsl/nir/nir.c
@@ -58,12 +58,9 @@ reg_create(void *mem_ctx, struct exec_list *list)
nir_register *reg = ralloc(mem_ctx, nir_register);
reg-parent_instr = NULL;
- reg-uses = _mesa_set_create(reg, _mesa_hash_pointer,
-_mesa_key_pointer_equal);
- reg-defs = _mesa_set_create(reg, _mesa_hash_pointer,
-_mesa_key_pointer_equal);
- reg-if_uses = _mesa_set_create(reg, _mesa_hash_pointer,
- _mesa_key_pointer_equal);
+ list_inithead(reg-uses);
+ list_inithead(reg-defs);
+ list_inithead(reg-if_uses);
reg-num_components = 0;
reg-num_array_elems = 0;
@@ -1070,11 +1067,14 @@ update_if_uses(nir_cf_node *node)
nir_if *if_stmt = nir_cf_node_as_if(node);
- struct set *if_uses_set = if_stmt-condition.is_ssa ?
- if_stmt-condition.ssa-if_uses :
- if_stmt-condition.reg.reg-uses;
-
- _mesa_set_add(if_uses_set, if_stmt);
+ if_stmt-condition.parent_if = if_stmt;
+ if (if_stmt-condition.is_ssa) {
+ list_addtail(if_stmt-condition.use_link,
+ if_stmt-condition.ssa-if_uses);
+ } else {
+ list_addtail(if_stmt-condition.use_link,
+ if_stmt-condition.reg.reg-if_uses);
+ }
}
void
@@ -1227,16 +1227,7 @@ cleanup_cf_node(nir_cf_node *node)
foreach_list_typed(nir_cf_node, child, node, if_stmt-else_list)
cleanup_cf_node(child);
- struct set *if_uses;
- if (if_stmt-condition.is_ssa) {
- if_uses = if_stmt-condition.ssa-if_uses;
- } else {
- if_uses = if_stmt-condition.reg.reg-if_uses;
- }
-
- struct set_entry *entry = _mesa_set_search(if_uses, if_stmt);
- assert(entry);
- _mesa_set_remove(if_uses, entry);
+ list_del(if_stmt-condition.use_link);
break;
}
@@ -1293,9 +1284,9 @@ add_use_cb(nir_src *src, void *state)
{
nir_instr *instr = state;
- struct set *uses_set = src-is_ssa ? src-ssa-uses : src-reg.reg-uses;
-
- _mesa_set_add(uses_set, instr);
+ src-parent_instr = instr;
+ list_addtail(src-use_link,
+src-is_ssa ? src-ssa-uses : src-reg.reg-uses);
return true;
}
@@ -1320,8 +1311,10 @@ add_reg_def_cb(nir_dest *dest, void *state)
{
nir_instr *instr = state;
- if (!dest-is_ssa)
- _mesa_set_add(dest-reg.reg-defs, instr);
+ if (!dest-is_ssa) {
+ dest-reg.parent_instr = instr;
+ list_addtail(dest-reg.def_link, dest-reg.reg-defs);
+ }
return true;
}
@@ -1436,13 +1429,7 @@ nir_instr_insert_after_cf_list(struct exec_list *list,
nir_instr *after)
static bool
remove_use_cb(nir_src *src, void *state)
{
- nir_instr *instr = state;
-
- struct set *uses_set = src-is_ssa ? src-ssa-uses : src-reg.reg-uses;
[Mesa-dev] [PATCH 04/13] nir: Add a function for rewriting the condition of an if statement
---
src/glsl/nir/nir.c | 22 ++
src/glsl/nir/nir.h | 1 +
2 files changed, 23 insertions(+)
diff --git a/src/glsl/nir/nir.c b/src/glsl/nir/nir.c
index 4cc074b..b8f5dd4 100644
--- a/src/glsl/nir/nir.c
+++ b/src/glsl/nir/nir.c
@@ -1895,6 +1895,28 @@ nir_instr_rewrite_src(nir_instr *instr, nir_src *src,
nir_src new_src)
}
void
+nir_if_rewrite_condition(nir_if *if_stmt, nir_src new_src)
+{
+ for (nir_src *src = if_stmt-condition; src;
+src = src-is_ssa ? NULL : src-reg.indirect) {
+ struct set *uses = src-is_ssa ? src-ssa-if_uses
+ : src-reg.reg-if_uses;
+ struct set_entry *entry = _mesa_set_search(uses, if_stmt);
+ assert(entry);
+ _mesa_set_remove(uses, entry);
+ }
+
+ if_stmt-condition = new_src;
+
+ for (nir_src *src = if_stmt-condition; src;
+src = src-is_ssa ? NULL : src-reg.indirect) {
+ struct set *uses = src-is_ssa ? src-ssa-if_uses
+ : src-reg.reg-if_uses;
+ _mesa_set_add(uses, if_stmt);
+ }
+}
+
+void
nir_ssa_def_init(nir_instr *instr, nir_ssa_def *def,
unsigned num_components, const char *name)
{
diff --git a/src/glsl/nir/nir.h b/src/glsl/nir/nir.h
index a174666..aaf1c57 100644
--- a/src/glsl/nir/nir.h
+++ b/src/glsl/nir/nir.h
@@ -1549,6 +1549,7 @@ bool nir_foreach_src(nir_instr *instr, nir_foreach_src_cb
cb, void *state);
nir_const_value *nir_src_as_const_value(nir_src src);
bool nir_srcs_equal(nir_src src1, nir_src src2);
void nir_instr_rewrite_src(nir_instr *instr, nir_src *src, nir_src new_src);
+void nir_if_rewrite_condition(nir_if *if_stmt, nir_src new_src);
void nir_ssa_dest_init(nir_instr *instr, nir_dest *dest,
unsigned num_components, const char *name);
--
2.3.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 13/13] SQUASH: nir: Update various components for the new list-based use/def sets
---
src/glsl/nir/nir_from_ssa.c | 11 +--
src/glsl/nir/nir_lower_locals_to_regs.c | 14 ++
src/glsl/nir/nir_lower_to_source_mods.c | 20
src/glsl/nir/nir_lower_vars_to_ssa.c| 3 ++-
src/glsl/nir/nir_opt_gcm.c | 14 ++
src/glsl/nir/nir_opt_global_to_local.c | 13 ++---
src/glsl/nir/nir_opt_peephole_ffma.c| 9 -
src/glsl/nir/nir_opt_peephole_select.c | 10 --
src/glsl/nir/nir_to_ssa.c | 19 ++-
9 files changed, 55 insertions(+), 58 deletions(-)
diff --git a/src/glsl/nir/nir_from_ssa.c b/src/glsl/nir/nir_from_ssa.c
index 5e7deca..94d1ced 100644
--- a/src/glsl/nir/nir_from_ssa.c
+++ b/src/glsl/nir/nir_from_ssa.c
@@ -345,6 +345,7 @@ isolate_phi_nodes_block(nir_block *block, void *void_state)
nir_parallel_copy_entry *entry = rzalloc(state-dead_ctx,
nir_parallel_copy_entry);
+ entry-src.parent_instr = pcopy-instr;
nir_ssa_dest_init(pcopy-instr, entry-dest,
phi-dest.ssa.num_components, src-src.ssa-name);
exec_list_push_tail(pcopy-entries, entry-node);
@@ -358,6 +359,7 @@ isolate_phi_nodes_block(nir_block *block, void *void_state)
nir_parallel_copy_entry *entry = rzalloc(state-dead_ctx,
nir_parallel_copy_entry);
+ entry-src.parent_instr = block_pcopy-instr;
nir_ssa_dest_init(block_pcopy-instr, entry-dest,
phi-dest.ssa.num_components, phi-dest.ssa.name);
exec_list_push_tail(block_pcopy-entries, entry-node);
@@ -503,7 +505,7 @@ rewrite_ssa_def(nir_ssa_def *def, void *void_state)
}
nir_ssa_def_rewrite_uses(def, nir_src_for_reg(reg), state-mem_ctx);
- assert(def-uses-entries == 0 def-if_uses-entries == 0);
+ assert(list_empty(def-uses) list_empty(def-if_uses));
if (def-parent_instr-type == nir_instr_type_ssa_undef)
return true;
@@ -515,12 +517,9 @@ rewrite_ssa_def(nir_ssa_def *def, void *void_state)
*/
nir_dest *dest = exec_node_data(nir_dest, def, ssa);
- _mesa_set_destroy(dest-ssa.uses, NULL);
- _mesa_set_destroy(dest-ssa.if_uses, NULL);
-
*dest = nir_dest_for_reg(reg);
-
- _mesa_set_add(reg-defs, state-instr);
+ dest-reg.parent_instr = state-instr;
+ list_addtail(dest-reg.def_link, reg-defs);
return true;
}
diff --git a/src/glsl/nir/nir_lower_locals_to_regs.c
b/src/glsl/nir/nir_lower_locals_to_regs.c
index bc6a3d3..28fdec5 100644
--- a/src/glsl/nir/nir_lower_locals_to_regs.c
+++ b/src/glsl/nir/nir_lower_locals_to_regs.c
@@ -269,18 +269,16 @@ lower_locals_to_regs_block(nir_block *block, void
*void_state)
static nir_block *
compute_reg_usedef_lca(nir_register *reg)
{
- struct set_entry *entry;
nir_block *lca = NULL;
- set_foreach(reg-defs, entry)
- lca = nir_dominance_lca(lca, ((nir_instr *)entry-key)-block);
+ list_for_each_entry(nir_dest, def_dest, reg-defs, reg.def_link)
+ lca = nir_dominance_lca(lca, def_dest-reg.parent_instr-block);
- set_foreach(reg-uses, entry)
- lca = nir_dominance_lca(lca, ((nir_instr *)entry-key)-block);
+ list_for_each_entry(nir_src, use_src, reg-uses, use_link)
+ lca = nir_dominance_lca(lca, use_src-parent_instr-block);
- set_foreach(reg-if_uses, entry) {
- nir_if *if_stmt = (nir_if *)entry-key;
- nir_cf_node *prev_node = nir_cf_node_prev(if_stmt-cf_node);
+ list_for_each_entry(nir_src, use_src, reg-if_uses, use_link) {
+ nir_cf_node *prev_node = nir_cf_node_prev(use_src-parent_if-cf_node);
assert(prev_node-type == nir_cf_node_block);
lca = nir_dominance_lca(lca, nir_cf_node_as_block(prev_node));
}
diff --git a/src/glsl/nir/nir_lower_to_source_mods.c
b/src/glsl/nir/nir_lower_to_source_mods.c
index 7b4a0f6..94c7e36 100644
--- a/src/glsl/nir/nir_lower_to_source_mods.c
+++ b/src/glsl/nir/nir_lower_to_source_mods.c
@@ -88,8 +88,8 @@ nir_lower_to_source_mods_block(nir_block *block, void *state)
alu-src[i].swizzle[j] =
parent-src[0].swizzle[alu-src[i].swizzle[j]];
}
- if (parent-dest.dest.ssa.uses-entries == 0
- parent-dest.dest.ssa.if_uses-entries == 0)
+ if (list_empty(parent-dest.dest.ssa.uses)
+ list_empty(parent-dest.dest.ssa.if_uses))
nir_instr_remove(parent-instr);
}
@@ -131,13 +131,13 @@ nir_lower_to_source_mods_block(nir_block *block, void
*state)
if (nir_op_infos[alu-op].output_type != nir_type_float)
continue;
- if (alu-dest.dest.ssa.if_uses-entries != 0)
+ if (!list_empty(alu-dest.dest.ssa.if_uses))
continue;
bool all_children_are_sat = true;
- struct set_entry *entry;
- set_foreach(alu-dest.dest.ssa.uses, entry) {
- const nir_instr *child = entry-key;
+ nir_foreach_use(alu-dest.dest.ssa, child_src) {
+
[Mesa-dev] [PATCH 07/13] util: Move gallium's linked list to util
The linked list in gallium is pretty much the kernel list and we would like
to have a C-based linked list for all of mesa. Let's not duplicate and
just steal the gallium one.
---
src/gallium/auxiliary/Makefile.sources | 1 -
src/gallium/auxiliary/hud/hud_private.h| 2 +-
.../auxiliary/pipebuffer/pb_buffer_fenced.c| 2 +-
src/gallium/auxiliary/pipebuffer/pb_bufmgr_cache.c | 2 +-
src/gallium/auxiliary/pipebuffer/pb_bufmgr_debug.c | 2 +-
src/gallium/auxiliary/pipebuffer/pb_bufmgr_mm.c| 2 +-
src/gallium/auxiliary/pipebuffer/pb_bufmgr_pool.c | 2 +-
src/gallium/auxiliary/pipebuffer/pb_bufmgr_slab.c | 2 +-
src/gallium/auxiliary/util/u_debug_flush.c | 2 +-
src/gallium/auxiliary/util/u_debug_memory.c| 2 +-
src/gallium/auxiliary/util/u_dirty_surfaces.h | 2 +-
src/gallium/auxiliary/util/u_double_list.h | 146 -
src/gallium/drivers/freedreno/freedreno_context.h | 2 +-
src/gallium/drivers/freedreno/freedreno_query_hw.h | 2 +-
src/gallium/drivers/freedreno/freedreno_resource.h | 2 +-
src/gallium/drivers/ilo/ilo_common.h | 2 +-
src/gallium/drivers/nouveau/nouveau_buffer.h | 2 +-
src/gallium/drivers/nouveau/nouveau_fence.c| 2 -
src/gallium/drivers/nouveau/nouveau_fence.h| 2 +-
src/gallium/drivers/nouveau/nouveau_mm.c | 2 +-
src/gallium/drivers/nouveau/nv30/nv30_screen.h | 2 +-
src/gallium/drivers/nouveau/nv50/nv50_resource.h | 2 +-
src/gallium/drivers/r600/compute_memory_pool.c | 2 +-
src/gallium/drivers/r600/evergreen_compute.c | 2 +-
src/gallium/drivers/r600/r600_llvm.c | 2 +-
src/gallium/drivers/r600/r600_pipe.h | 2 +-
src/gallium/drivers/radeon/r600_pipe_common.h | 2 +-
src/gallium/drivers/radeon/radeon_vce.h| 2 +-
src/gallium/drivers/svga/svga_context.h| 2 +-
src/gallium/drivers/svga/svga_resource_buffer.h| 2 -
.../drivers/svga/svga_resource_buffer_upload.c | 1 -
src/gallium/drivers/svga/svga_screen_cache.h | 2 +-
src/gallium/state_trackers/nine/basetexture9.h | 2 +-
src/gallium/state_trackers/nine/device9.h | 2 +-
src/gallium/state_trackers/nine/nine_state.h | 2 +-
src/gallium/state_trackers/nine/surface9.h | 2 +-
src/gallium/state_trackers/omx/vid_dec.h | 2 +-
src/gallium/state_trackers/omx/vid_enc.h | 2 +-
src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 2 +-
.../winsys/svga/drm/pb_buffer_simple_fenced.c | 2 +-
src/gallium/winsys/svga/drm/vmw_fence.c| 2 +-
src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c | 2 +-
src/util/Makefile.sources | 1 +
src/util/list.h| 146 +
44 files changed, 184 insertions(+), 189 deletions(-)
delete mode 100644 src/gallium/auxiliary/util/u_double_list.h
create mode 100644 src/util/list.h
diff --git a/src/gallium/auxiliary/Makefile.sources
b/src/gallium/auxiliary/Makefile.sources
index ec7547c..62e6b94 100644
--- a/src/gallium/auxiliary/Makefile.sources
+++ b/src/gallium/auxiliary/Makefile.sources
@@ -197,7 +197,6 @@ C_SOURCES := \
util/u_dirty_surfaces.h \
util/u_dl.c \
util/u_dl.h \
- util/u_double_list.h \
util/u_draw.c \
util/u_draw.h \
util/u_draw_quad.c \
diff --git a/src/gallium/auxiliary/hud/hud_private.h
b/src/gallium/auxiliary/hud/hud_private.h
index 1606ada..c74dc3b 100644
--- a/src/gallium/auxiliary/hud/hud_private.h
+++ b/src/gallium/auxiliary/hud/hud_private.h
@@ -29,7 +29,7 @@
#define HUD_PRIVATE_H
#include pipe/p_context.h
-#include util/u_double_list.h
+#include util/list.h
struct hud_graph {
/* initialized by common code */
diff --git a/src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c
b/src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c
index 9e0cace..7840467 100644
--- a/src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c
+++ b/src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c
@@ -46,7 +46,7 @@
#include util/u_debug.h
#include os/os_thread.h
#include util/u_memory.h
-#include util/u_double_list.h
+#include util/list.h
#include pb_buffer.h
#include pb_buffer_fenced.h
diff --git a/src/gallium/auxiliary/pipebuffer/pb_bufmgr_cache.c
b/src/gallium/auxiliary/pipebuffer/pb_bufmgr_cache.c
index 5eb8d06..5023687 100644
--- a/src/gallium/auxiliary/pipebuffer/pb_bufmgr_cache.c
+++ b/src/gallium/auxiliary/pipebuffer/pb_bufmgr_cache.c
@@ -38,7 +38,7 @@
#include util/u_debug.h
#include os/os_thread.h
#include util/u_memory.h
-#include util/u_double_list.h
+#include util/list.h
#include util/u_time.h
#include pb_buffer.h
diff --git a/src/gallium/auxiliary/pipebuffer/pb_bufmgr_debug.c
b/src/gallium/auxiliary/pipebuffer/pb_bufmgr_debug.c
index e5d8118..6236afb 100644
---
[Mesa-dev] [PATCH 01/13] nir/validate: Validate SSA def parent instructiosn
--- src/glsl/nir/nir_validate.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/glsl/nir/nir_validate.c b/src/glsl/nir/nir_validate.c index a7aa798..35a853d 100644 --- a/src/glsl/nir/nir_validate.c +++ b/src/glsl/nir/nir_validate.c @@ -236,6 +236,8 @@ validate_ssa_def(nir_ssa_def *def, validate_state *state) assert(!BITSET_TEST(state-ssa_defs_found, def-index)); BITSET_SET(state-ssa_defs_found, def-index); + assert(def-parent_instr == state-instr); + assert(def-num_components = 4); ssa_def_validate_state *def_state = ralloc(state-ssa_defs, -- 2.3.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 02/13] nir: Modernize the out-of-SSA pass
The out-of-SSA pass was one of the first passes written when getting SSA
up-and-going (for obvious reasons). As such, it came before a lot of the
nifty SSA-based helpers were introduced. This commit modernizes it so that
we're no longer doing nearly as much manual banging on use/def sets.
---
src/glsl/nir/nir_from_ssa.c | 139
1 file changed, 36 insertions(+), 103 deletions(-)
diff --git a/src/glsl/nir/nir_from_ssa.c b/src/glsl/nir/nir_from_ssa.c
index 184698a..5e7deca 100644
--- a/src/glsl/nir/nir_from_ssa.c
+++ b/src/glsl/nir/nir_from_ssa.c
@@ -37,7 +37,6 @@
struct from_ssa_state {
void *mem_ctx;
void *dead_ctx;
- struct hash_table *ssa_table;
struct hash_table *merge_node_table;
nir_instr *instr;
nir_function_impl *impl;
@@ -344,45 +343,31 @@ isolate_phi_nodes_block(nir_block *block, void
*void_state)
get_parallel_copy_at_end_of_block(src-pred);
assert(pcopy);
- nir_parallel_copy_entry *entry = ralloc(state-dead_ctx,
- nir_parallel_copy_entry);
- exec_list_push_tail(pcopy-entries, entry-node);
-
- nir_src_copy(entry-src, src-src, state-dead_ctx);
- _mesa_set_add(src-src.ssa-uses, pcopy-instr);
-
+ nir_parallel_copy_entry *entry = rzalloc(state-dead_ctx,
+ nir_parallel_copy_entry);
nir_ssa_dest_init(pcopy-instr, entry-dest,
phi-dest.ssa.num_components, src-src.ssa-name);
+ exec_list_push_tail(pcopy-entries, entry-node);
- struct set_entry *use_entry =
-_mesa_set_search(src-src.ssa-uses, instr);
- if (use_entry)
-/* It is possible that a phi node can use the same source twice
- * but for different basic blocks. If that happens, entry will
- * be NULL because we already deleted it. This is safe
- * because, by the time the loop is done, we will have deleted
- * all of the sources of the phi from their respective use sets
- * and moved them to the parallel copy definitions.
- */
-_mesa_set_remove(src-src.ssa-uses, use_entry);
+ assert(src-src.is_ssa);
+ nir_instr_rewrite_src(pcopy-instr, entry-src, src-src);
- src-src.ssa = entry-dest.ssa;
- _mesa_set_add(entry-dest.ssa.uses, instr);
+ nir_instr_rewrite_src(phi-instr, src-src,
+ nir_src_for_ssa(entry-dest.ssa));
}
- nir_parallel_copy_entry *entry = ralloc(state-dead_ctx,
- nir_parallel_copy_entry);
- exec_list_push_tail(block_pcopy-entries, entry-node);
-
+ nir_parallel_copy_entry *entry = rzalloc(state-dead_ctx,
+ nir_parallel_copy_entry);
nir_ssa_dest_init(block_pcopy-instr, entry-dest,
phi-dest.ssa.num_components, phi-dest.ssa.name);
+ exec_list_push_tail(block_pcopy-entries, entry-node);
+
nir_ssa_def_rewrite_uses(phi-dest.ssa,
nir_src_for_ssa(entry-dest.ssa),
state-mem_ctx);
- entry-src.is_ssa = true;
- entry-src.ssa = phi-dest.ssa;
- _mesa_set_add(phi-dest.ssa.uses, block_pcopy-instr);
+ nir_instr_rewrite_src(block_pcopy-instr, entry-src,
+nir_src_for_ssa(phi-dest.ssa));
}
return true;
@@ -472,12 +457,16 @@ agressive_coalesce_block(nir_block *block, void
*void_state)
return true;
}
-static nir_register *
-get_register_for_ssa_def(nir_ssa_def *def, struct from_ssa_state *state)
+static bool
+rewrite_ssa_def(nir_ssa_def *def, void *void_state)
{
+ struct from_ssa_state *state = void_state;
+ nir_register *reg;
+
struct hash_entry *entry =
_mesa_hash_table_search(state-merge_node_table, def);
if (entry) {
+ /* In this case, we're part of a phi web. Use the web's register. */
merge_node *node = (merge_node *)entry-data;
/* If it doesn't have a register yet, create one. Note that all of
@@ -491,20 +480,15 @@ get_register_for_ssa_def(nir_ssa_def *def, struct
from_ssa_state *state)
node-set-reg-num_array_elems = 0;
}
- return node-set-reg;
- }
-
- entry = _mesa_hash_table_search(state-ssa_table, def);
- if (entry) {
- return (nir_register *)entry-data;
+ reg = node-set-reg;
} else {
/* We leave load_const SSA values alone. They act as immediates to
* the backend. If it got coalesced into a phi, that's ok.
*/
if (def-parent_instr-type == nir_instr_type_load_const)
- return NULL;
+ return true;
- nir_register *reg = nir_local_reg_create(state-impl);
+ reg = nir_local_reg_create(state-impl);
reg-name = def-name;
reg-num_components =
[Mesa-dev] [PATCH 08/13] util/list: Add C99-based iterator macros
--- src/util/list.h | 33 + 1 file changed, 33 insertions(+) diff --git a/src/util/list.h b/src/util/list.h index 9dcf671..6144b0c 100644 --- a/src/util/list.h +++ b/src/util/list.h @@ -141,6 +141,39 @@ static inline void list_delinit(struct list_head *item) #define LIST_FOR_EACH_ENTRY_FROM_REV(pos, start, head, member) \ for (pos = NULL, pos = container_of((start), pos, member); \ pos-member != (head); \ + +#define list_for_each_entry(type, pos, head, member)\ + for (type *pos = container_of((head)-next, pos, member);\ + pos-member != (head); \ + pos = container_of(pos-member.next, pos, member)) + +#define list_for_each_entry_safe(type, pos, head, member) \ + for (type *pos = container_of((head)-next, pos, member),\ +*__next = container_of(pos-member.next, pos, member); \ + pos-member != (head); \ + pos = __next, \ +__next = container_of(__next-member.next, __next, member)) + +#define list_for_each_entry_rev(type, pos, head, member)\ + for (type *pos = container_of((head)-prev, pos, member);\ + pos-member != (head); \ + pos = container_of(pos-member.prev, pos, member)) + +#define list_for_each_entry_safe_rev(type, pos, head, member) \ + for (type *pos = container_of((head)-prev, pos, member),\ +*__prev = container_of(pos-member.prev, pos, member); \ + pos-member != (head); \ + pos = __prev, \ +__prev = container_of(__prev-member.prev, __prev, member)) + +#define list_for_each_entry_from(type, pos, start, head, member)\ + for (type *pos = container_of((start), pos, member); \ + pos-member != (head); \ + pos = container_of(pos-member.next, pos, member)) + +#define list_for_each_entry_from_rev(type, pos, start, head, member)\ + for (type *pos = container_of((start), pos, member); \ + pos-member != (head); \ pos = container_of(pos-member.prev, pos, member)) #endif /*_UTIL_LIST_H_*/ -- 2.3.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 09/13] util/list: Add list_empty and list_length functions
---
src/util/list.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/src/util/list.h b/src/util/list.h
index 6144b0c..246f826 100644
--- a/src/util/list.h
+++ b/src/util/list.h
@@ -92,6 +92,19 @@ static inline void list_delinit(struct list_head *item)
item-prev = item;
}
+static inline bool list_empty(struct list_head *list)
+{
+ return list-next == list;
+}
+
+static inline unsigned list_length(struct list_head *list)
+{
+ unsigned length = 0;
+ for (struct list_head *node = list-next; node != list; node = node-next)
+ length++;
+ return length;
+}
+
#define LIST_INITHEAD(__item) list_inithead(__item)
#define LIST_ADD(__item, __list) list_add(__item, __list)
#define LIST_ADDTAIL(__item, __list) list_addtail(__item, __list)
--
2.3.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 05/13] nir: Use nir_instr_rewrite_src in copy propagation
We were rolling our own rewrite_src variant in copy-propagation. Let's
stop doing that and use the ones in core NIR.
---
src/glsl/nir/nir_opt_copy_propagate.c | 71 +--
1 file changed, 10 insertions(+), 61 deletions(-)
diff --git a/src/glsl/nir/nir_opt_copy_propagate.c
b/src/glsl/nir/nir_opt_copy_propagate.c
index ee78e5a..71367d0 100644
--- a/src/glsl/nir/nir_opt_copy_propagate.c
+++ b/src/glsl/nir/nir_opt_copy_propagate.c
@@ -93,62 +93,6 @@ is_swizzleless_move(nir_alu_instr *instr)
}
}
-typedef struct {
- nir_ssa_def *def;
- bool found;
-} search_def_state;
-
-static bool
-search_def(nir_src *src, void *_state)
-{
- search_def_state *state = (search_def_state *) _state;
-
- if (src-is_ssa src-ssa == state-def)
- state-found = true;
-
- return true;
-}
-
-static void
-rewrite_src_instr(nir_src *src, nir_ssa_def *new_def, nir_instr *parent_instr)
-{
- nir_ssa_def *old_def = src-ssa;
-
- src-ssa = new_def;
-
- /*
-* The instruction could still use the old definition in one of its other
-* sources, so only remove the instruction from the uses if there are no
-* more uses left.
-*/
-
- search_def_state search_state;
- search_state.def = old_def;
- search_state.found = false;
- nir_foreach_src(parent_instr, search_def, search_state);
- if (!search_state.found) {
- struct set_entry *entry = _mesa_set_search(old_def-uses, parent_instr);
- assert(entry);
- _mesa_set_remove(old_def-uses, entry);
- }
-
- _mesa_set_add(new_def-uses, parent_instr);
-}
-
-static void
-rewrite_src_if(nir_if *if_stmt, nir_ssa_def *new_def)
-{
- nir_ssa_def *old_def = if_stmt-condition.ssa;
-
- if_stmt-condition.ssa = new_def;
-
- struct set_entry *entry = _mesa_set_search(old_def-if_uses, if_stmt);
- assert(entry);
- _mesa_set_remove(old_def-if_uses, entry);
-
- _mesa_set_add(new_def-if_uses, if_stmt);
-}
-
static bool
copy_prop_src(nir_src *src, nir_instr *parent_instr, nir_if *parent_if)
{
@@ -178,10 +122,14 @@ copy_prop_src(nir_src *src, nir_instr *parent_instr,
nir_if *parent_if)
return false;
}
- if (parent_instr)
- rewrite_src_instr(src, alu_instr-src[0].src.ssa, parent_instr);
- else
- rewrite_src_if(parent_if, alu_instr-src[0].src.ssa);
+ if (parent_instr) {
+ nir_instr_rewrite_src(parent_instr, src,
+nir_src_for_ssa(alu_instr-src[0].src.ssa));
+ } else {
+ assert(src == parent_if-condition);
+ nir_if_rewrite_condition(parent_if,
+ nir_src_for_ssa(alu_instr-src[0].src.ssa));
+ }
return true;
}
@@ -234,7 +182,8 @@ copy_prop_alu_src(nir_alu_instr *parent_alu_instr, unsigned
index)
for (unsigned i = 0; i 4; i++)
src-swizzle[i] = new_swizzle[i];
- rewrite_src_instr(src-src, def, parent_alu_instr-instr);
+ nir_instr_rewrite_src(parent_alu_instr-instr, src-src,
+ nir_src_for_ssa(def));
return true;
}
--
2.3.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 12/13] SQUASH: nir: Add a helper for moving a source and use it in texture lowering
One of the side-effects of using a linked list for use/def sets is that you
can no longer simply copy them around. There were a couple of places in
the texture lowering passes that realloced or used memmove on lists of
sources. Instead, this commit adds a helper for moving a source and uses
it for these cases.
---
src/glsl/nir/nir.c | 12
src/glsl/nir/nir.h | 1 +
src/glsl/nir/nir_lower_samplers.cpp| 29 +++--
src/glsl/nir/nir_lower_tex_projector.c | 7 ---
4 files changed, 36 insertions(+), 13 deletions(-)
diff --git a/src/glsl/nir/nir.c b/src/glsl/nir/nir.c
index be13c90..f03e80a 100644
--- a/src/glsl/nir/nir.c
+++ b/src/glsl/nir/nir.c
@@ -1864,6 +1864,18 @@ nir_instr_rewrite_src(nir_instr *instr, nir_src *src,
nir_src new_src)
}
void
+nir_instr_move_src(nir_instr *dest_instr, nir_src *dest, nir_src *src)
+{
+ assert(!src_is_valid(dest) || dest-parent_instr == dest_instr);
+
+ src_remove_all_uses(dest);
+ src_remove_all_uses(src);
+ *dest = *src;
+ *src = NIR_SRC_INIT;
+ src_add_all_uses(dest, dest_instr, NULL);
+}
+
+void
nir_if_rewrite_condition(nir_if *if_stmt, nir_src new_src)
{
nir_src *src = if_stmt-condition;
diff --git a/src/glsl/nir/nir.h b/src/glsl/nir/nir.h
index ac027b0..697d37e 100644
--- a/src/glsl/nir/nir.h
+++ b/src/glsl/nir/nir.h
@@ -1580,6 +1580,7 @@ bool nir_foreach_src(nir_instr *instr, nir_foreach_src_cb
cb, void *state);
nir_const_value *nir_src_as_const_value(nir_src src);
bool nir_srcs_equal(nir_src src1, nir_src src2);
void nir_instr_rewrite_src(nir_instr *instr, nir_src *src, nir_src new_src);
+void nir_instr_move_src(nir_instr *dest_instr, nir_src *dest, nir_src *src);
void nir_if_rewrite_condition(nir_if *if_stmt, nir_src new_src);
void nir_ssa_dest_init(nir_instr *instr, nir_dest *dest,
diff --git a/src/glsl/nir/nir_lower_samplers.cpp
b/src/glsl/nir/nir_lower_samplers.cpp
index e9e152f..8fc5909 100644
--- a/src/glsl/nir/nir_lower_samplers.cpp
+++ b/src/glsl/nir/nir_lower_samplers.cpp
@@ -83,21 +83,30 @@ lower_sampler(nir_tex_instr *instr, const struct
gl_shader_program *shader_progr
ralloc_asprintf_append(name, [%u], deref_array-base_offset);
break;
case nir_deref_array_type_indirect: {
-instr-src = reralloc(instr, instr-src, nir_tex_src,
- instr-num_srcs + 1);
-memset(instr-src[instr-num_srcs], 0, sizeof *instr-src);
+/* First, we have to resize the array of texture sources */
+nir_tex_src *new_srcs = rzalloc_array(instr, nir_tex_src,
+ instr-num_srcs + 1);
+
+for (unsigned i = 0; i instr-num_srcs; i++) {
+ new_srcs[i].src_type = instr-src[i].src_type;
+ nir_instr_move_src(instr-instr, new_srcs[i].src,
+ instr-src[i].src);
+}
+
+ralloc_free(instr-src);
+instr-src = new_srcs;
+
+/* Now we can go ahead and move the source over to being a
+ * first-class texture source.
+ */
instr-src[instr-num_srcs].src_type = nir_tex_src_sampler_offset;
instr-num_srcs++;
-
-nir_instr_rewrite_src(instr-instr,
- instr-src[instr-num_srcs - 1].src,
- deref_array-indirect);
+nir_instr_move_src(instr-instr,
+ instr-src[instr-num_srcs - 1].src,
+ deref_array-indirect);
instr-sampler_array_size = glsl_get_length(deref-type);
-nir_instr_rewrite_src(instr-instr, deref_array-indirect,
- NIR_SRC_INIT);
-
if (deref_array-deref.child)
ralloc_strcat(name, [0]);
break;
diff --git a/src/glsl/nir/nir_lower_tex_projector.c
b/src/glsl/nir/nir_lower_tex_projector.c
index 6e2cc80..357131c 100644
--- a/src/glsl/nir/nir_lower_tex_projector.c
+++ b/src/glsl/nir/nir_lower_tex_projector.c
@@ -111,9 +111,10 @@ nir_lower_tex_projector_block(nir_block *block, void
*void_state)
*/
nir_instr_rewrite_src(tex-instr, tex-src[proj_index].src,
NIR_SRC_INIT);
- memmove(tex-src[proj_index],
- tex-src[proj_index + 1],
- (tex-num_srcs - proj_index) * sizeof(*tex-src));
+ for (int i = proj_index + 1; i tex-num_srcs; i++) {
+ tex-src[i-1].src_type = tex-src[i].src_type;
+ nir_instr_move_src(tex-instr, tex-src[i-1].src, tex-src[i].src);
+ }
tex-num_srcs--;
}
--
2.3.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 06/13] gallium/double_list: s/INLINE/inline and remove the p_compiler include
---
src/gallium/auxiliary/util/u_double_list.h | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_double_list.h
b/src/gallium/auxiliary/util/u_double_list.h
index 247f0f2..e808333 100644
--- a/src/gallium/auxiliary/util/u_double_list.h
+++ b/src/gallium/auxiliary/util/u_double_list.h
@@ -39,7 +39,6 @@
#include stddef.h
-#include pipe/p_compiler.h
struct list_head
@@ -48,13 +47,13 @@ struct list_head
struct list_head *next;
};
-static INLINE void list_inithead(struct list_head *item)
+static inline void list_inithead(struct list_head *item)
{
item-prev = item;
item-next = item;
}
-static INLINE void list_add(struct list_head *item, struct list_head *list)
+static inline void list_add(struct list_head *item, struct list_head *list)
{
item-prev = list;
item-next = list-next;
@@ -62,7 +61,7 @@ static INLINE void list_add(struct list_head *item, struct
list_head *list)
list-next = item;
}
-static INLINE void list_addtail(struct list_head *item, struct list_head *list)
+static inline void list_addtail(struct list_head *item, struct list_head *list)
{
item-next = list;
item-prev = list-prev;
@@ -70,7 +69,7 @@ static INLINE void list_addtail(struct list_head *item,
struct list_head *list)
list-prev = item;
}
-static INLINE void list_replace(struct list_head *from, struct list_head *to)
+static inline void list_replace(struct list_head *from, struct list_head *to)
{
to-prev = from-prev;
to-next = from-next;
@@ -78,14 +77,14 @@ static INLINE void list_replace(struct list_head *from,
struct list_head *to)
from-prev-next = to;
}
-static INLINE void list_del(struct list_head *item)
+static inline void list_del(struct list_head *item)
{
item-prev-next = item-next;
item-next-prev = item-prev;
item-prev = item-next = NULL;
}
-static INLINE void list_delinit(struct list_head *item)
+static inline void list_delinit(struct list_head *item)
{
item-prev-next = item-next;
item-next-prev = item-prev;
--
2.3.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 10/13] util/list: Add a list validation function
---
src/util/list.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/util/list.h b/src/util/list.h
index 246f826..f11b858 100644
--- a/src/util/list.h
+++ b/src/util/list.h
@@ -105,6 +105,13 @@ static inline unsigned list_length(struct list_head *list)
return length;
}
+static inline void list_validate(struct list_head *list)
+{
+ assert(list-next-prev == list list-prev-next == list);
+ for (struct list_head *node = list-next; node != list; node = node-next)
+ assert(node-next-prev == node node-prev-next == node);
+}
+
#define LIST_INITHEAD(__item) list_inithead(__item)
#define LIST_ADD(__item, __list) list_add(__item, __list)
#define LIST_ADDTAIL(__item, __list) list_addtail(__item, __list)
--
2.3.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 00/11] Initial glsl + i965 barrier support
On Saturday, April 25, 2015 09:45:49 PM Jordan Justen wrote: git://people.freedesktop.org/~jljusten/mesa i965-barrier-v2 This series had a fair amount of comments r-b from v1. Patches 9 10 probably would be the most import to look at. Chris Forbes (2): glsl: Add ir node for barrier glsl: Add builtin barrier() function Jordan Justen (9): nir: Add barrier intrinsic function i965: Add GATEWAY_SFID definitions i965/inst: Add gateway_notify and gateway_subfuncid fields i965: Disassemble Gateway SEND messages i965: Add notification register i965: Add brw_WAIT to emit wait instruction i965: Add brw_barrier to emit a Gateway Barrier SEND i965/fs: Implement support for ir_barrier i965/nir: Support barrier intrinsic function I skimmed this series and it looks good to me. It looks like Chris already reviewed most of it, and Ben and Matt reviewed a few patches as well - that's totally sufficient in my book, so I'm going to skip looking at the details. :) signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 90207] [r600g, bisected] regression: NI/Turks crash on WebGL Water (most WebGL stuff)
https://bugs.freedesktop.org/show_bug.cgi?id=90207 Dieter Nützel die...@nuetzel-hh.de changed: What|Removed |Added Hardware|Other |x86-64 (AMD64) OS|All |Linux (All) Severity|normal |critical -- You are receiving this mail because: You are on the CC list for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 90207] [r600g, bisected] regression: NI/Turks crash on WebGL Water (most WebGL stuff)
https://bugs.freedesktop.org/show_bug.cgi?id=90207 --- Comment #6 from Dieter Nützel die...@nuetzel-hh.de --- (In reply to Dieter Nützel from comment #5) (In reply to Dieter Nützel from comment #4) (In reply to Tapani Pälli from comment #3) My konqueror does not seems to support webgl (?) is there something special I need to do to enable it? Hello Tapani! [snip] Maybe you have to use WebKit not KHTML. http://html5test.com/index.html It is in since 11./13.10.2011 through WebKit. kwebkitpart kwebkitpart-1.3.3-3.1.5.x86_64 -- You are receiving this mail because: You are on the CC list for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] freedreno/ir3: fix immediate usage in tgsi tex fe
get_immediate will return a const reference, the requested immediate
isn't necessarily in the x slot. Make sure to use the swizzle.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
I know you're behind the death to TGSI frontend banner, but while it's
around, should probably fix it up...
src/gallium/drivers/freedreno/ir3/ir3_compiler.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/freedreno/ir3/ir3_compiler.c
b/src/gallium/drivers/freedreno/ir3/ir3_compiler.c
index 43f4c95..1bfe050 100644
--- a/src/gallium/drivers/freedreno/ir3/ir3_compiler.c
+++ b/src/gallium/drivers/freedreno/ir3/ir3_compiler.c
@@ -1615,7 +1615,7 @@ trans_samp(const struct instr_translater *t,
instr-cat1.src_type = type_mov;
instr-cat1.dst_type = type_mov;
add_dst_reg(ctx, instr, tmp_dst, i);
- add_src_reg(ctx, instr, zero, 0);
+ add_src_reg(ctx, instr, zero, zero.SwizzleX);
i++;
}
if (tgt-array) {
@@ -1669,15 +1669,18 @@ trans_samp(const struct instr_translater *t,
*/
if (inst-Instruction.Opcode == TGSI_OPCODE_TXD) {
while (collect-regs_count 5)
- ssa_src(ctx, ir3_reg_create(collect, 0, IR3_REG_SSA),
zero, 0);
+ ssa_src(ctx, ir3_reg_create(collect, 0, IR3_REG_SSA),
+ zero, zero.SwizzleX);
for (i = 0; i tgt-dims; i++)
ssa_src(ctx, ir3_reg_create(collect, 0, IR3_REG_SSA),
dpdx, i);
if (tgt-dims 2)
- ssa_src(ctx, ir3_reg_create(collect, 0, IR3_REG_SSA),
zero, 0);
+ ssa_src(ctx, ir3_reg_create(collect, 0, IR3_REG_SSA),
+ zero, zero.SwizzleX);
for (i = 0; i tgt-dims; i++)
ssa_src(ctx, ir3_reg_create(collect, 0, IR3_REG_SSA),
dpdy, i);
if (tgt-dims 2)
- ssa_src(ctx, ir3_reg_create(collect, 0, IR3_REG_SSA),
zero, 0);
+ ssa_src(ctx, ir3_reg_create(collect, 0, IR3_REG_SSA),
+ zero, zero.SwizzleX);
tinf.src_wrmask |= ((1 (2 * MAX2(tgt-dims, 2))) - 1) 4;
}
@@ -1700,7 +1703,8 @@ trans_samp(const struct instr_translater *t,
ssa_src(ctx, ir3_reg_create(collect, 0, IR3_REG_SSA),
offset, i);
if (tgt-dims 2)
- ssa_src(ctx, ir3_reg_create(collect, 0, IR3_REG_SSA),
zero, 0);
+ ssa_src(ctx, ir3_reg_create(collect, 0, IR3_REG_SSA),
+ zero, zero.SwizzleX);
}
if (inst-Instruction.Opcode == TGSI_OPCODE_TXB2)
ssa_src(ctx, ir3_reg_create(collect, 0, IR3_REG_SSA),
--
2.0.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Upload atomic buffer state for compute shaders
On Friday, April 24, 2015 04:35:46 PM Jordan Justen wrote:
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
git://people.freedesktop.org/~jljusten/mesa i965-cs-atomic-counters-v1
src/mesa/drivers/dri/i965/brw_context.h | 2 +-
src/mesa/drivers/dri/i965/brw_state.h| 1 +
src/mesa/drivers/dri/i965/brw_state_upload.c | 2 ++
src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 25
4 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index e679d2b..48e8076 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1437,7 +1437,7 @@ struct brw_context
int num_atoms[BRW_NUM_PIPELINES];
const struct brw_tracked_state render_atoms[57];
- const struct brw_tracked_state compute_atoms[2];
+ const struct brw_tracked_state compute_atoms[3];
/* If (INTEL_DEBUG DEBUG_BATCH) */
struct {
diff --git a/src/mesa/drivers/dri/i965/brw_state.h
b/src/mesa/drivers/dri/i965/brw_state.h
index 4b3184c..7e2c74b 100644
--- a/src/mesa/drivers/dri/i965/brw_state.h
+++ b/src/mesa/drivers/dri/i965/brw_state.h
@@ -84,6 +84,7 @@ extern const struct brw_tracked_state brw_gs_binding_table;
extern const struct brw_tracked_state brw_vs_binding_table;
extern const struct brw_tracked_state brw_wm_ubo_surfaces;
extern const struct brw_tracked_state brw_wm_abo_surfaces;
+extern const struct brw_tracked_state brw_cs_abo_surfaces;
extern const struct brw_tracked_state brw_wm_unit;
extern const struct brw_tracked_state brw_interpolation_map;
diff --git a/src/mesa/drivers/dri/i965/brw_state_upload.c
b/src/mesa/drivers/dri/i965/brw_state_upload.c
index 686a3da..84b0861 100644
--- a/src/mesa/drivers/dri/i965/brw_state_upload.c
+++ b/src/mesa/drivers/dri/i965/brw_state_upload.c
@@ -250,6 +250,7 @@ static const struct brw_tracked_state
*gen7_render_atoms[] =
static const struct brw_tracked_state *gen7_compute_atoms[] =
{
brw_state_base_address,
+ brw_cs_abo_surfaces,
brw_cs_state,
};
@@ -332,6 +333,7 @@ static const struct brw_tracked_state
*gen8_render_atoms[] =
static const struct brw_tracked_state *gen8_compute_atoms[] =
{
gen8_state_base_address,
+ brw_cs_abo_surfaces,
brw_cs_state,
};
diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
index 161d140..62b606c 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
@@ -986,6 +986,31 @@ const struct brw_tracked_state brw_wm_abo_surfaces = {
.emit = brw_upload_wm_abo_surfaces,
};
+static void
+brw_upload_cs_abo_surfaces(struct brw_context *brw)
+{
+ struct gl_context *ctx = brw-ctx;
+ /* _NEW_PROGRAM */
+ struct gl_shader_program *prog =
+ ctx-_Shader-CurrentProgram[MESA_SHADER_COMPUTE];
+
+ if (prog) {
+ /* CACHE_NEW_WM_PROG */
I think you mean:
/* BRW_NEW_CS_PROG_DATA */
+ brw_upload_abo_surfaces(brw, prog, brw-cs.base,
+ brw-cs.prog_data-base);
+ }
+}
+
+const struct brw_tracked_state brw_cs_abo_surfaces = {
+ .dirty = {
+ .mesa = _NEW_PROGRAM,
+ .brw = BRW_NEW_COMPUTE_PROGRAM |
I don't see BRW_NEW_COMPUTE_PROGRAM used here (it uses _NEW_PROGRAM
instead) - I think you want BRW_NEW_CS_PROG_DATA here.
+ BRW_NEW_BATCH |
+ BRW_NEW_ATOMIC_BUFFER,
These should be alphabetized. With those fixed, this is:
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
+ },
+ .emit = brw_upload_cs_abo_surfaces,
+};
+
void
gen4_init_vtable_surface_functions(struct brw_context *brw)
{
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 02/11] glsl: Add builtin barrier() function
On Saturday, April 25, 2015 09:45:51 PM Jordan Justen wrote:
From: Chris Forbes chr...@ijw.co.nz
[jordan.l.jus...@intel.com: Add CS support]
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
Reviewed-by: Ben Widawsky b...@bwidawsk.net
---
src/glsl/builtin_functions.cpp | 29 +
1 file changed, 29 insertions(+)
diff --git a/src/glsl/builtin_functions.cpp b/src/glsl/builtin_functions.cpp
index 524b8d6..778470d 100644
--- a/src/glsl/builtin_functions.cpp
+++ b/src/glsl/builtin_functions.cpp
@@ -99,6 +99,18 @@ gs_only(const _mesa_glsl_parse_state *state)
}
static bool
+tcs_only(const _mesa_glsl_parse_state *state)
+{
+ return false; /* TODO: state-stage == MESA_SHADER_TESS_CTRL; */
+}
+
+static bool
+cs_only(const _mesa_glsl_parse_state *state)
+{
+ return state-stage == MESA_SHADER_COMPUTE;
+}
+
+static bool
v110(const _mesa_glsl_parse_state *state)
{
return !state-es_shader;
@@ -387,6 +399,12 @@ fp64(const _mesa_glsl_parse_state *state)
return state-has_double();
}
+static bool
+barrier_supported(const _mesa_glsl_parse_state *state)
+{
+ return tcs_only(state) || cs_only(state);
+}
+
I'd probably drop the cs_only/tcs_only functions unless you're going to
use them as a built-in predicate directly.
Writing this as:
static bool
barrier_supported(const _mesa_glsl_parse_state *state)
{
return state-stage == MESA_SHADER_COMPUTE;
/* TODO: || stage-state == MESA_SHADER_TESS_CTRL; */
}
seems simpler to me.
With that change, (or either way I guess),
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/18] winsys/radeon: move radeon_winsys.h up one directory
On 28.04.2015 03:57, Marek Olšák wrote: Can you elaborate on what amdgpu/sw would be good for? Frankly I don't see a point, therefore we don't need the drm subdirectory. I think Emil's main point (which I agree with) is that radeon_winsys.h should live somewhere under src/gallium/drivers/, probably src/gallium/drivers/radeon/, because the winsys interface is defined by the drivers, not the winsys. All other drivers have their *_winsys.h headers there. Maybe amdgpu/sw wasn't a good example, but at some point there might be e.g. amdgpu/haiku. ;) -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 90207] [r600g, bisected] regression: NI/Turks crash on WebGL Water (most WebGL stuff)
https://bugs.freedesktop.org/show_bug.cgi?id=90207 --- Comment #3 from Tapani Pälli lem...@gmail.com --- My konqueror does not seems to support webgl (?) is there something special I need to do to enable it? -- You are receiving this mail because: You are on the CC list for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 90207] [r600g, bisected] regression: NI/Turks crash on WebGL Water (most WebGL stuff)
https://bugs.freedesktop.org/show_bug.cgi?id=90207 --- Comment #4 from Dieter Nützel die...@nuetzel-hh.de --- (In reply to Tapani Pälli from comment #3) My konqueror does not seems to support webgl (?) is there something special I need to do to enable it? Hello Tapani! My Konqueror 4.14.6 and former versions (on openSUSE x86 and x86-64) support it for some months (years?) out of the box. What's weird that it do NOT run webgl if I go back to repro package Mesa-10.5.4 (from 27 Apr 2015). I can swear it worked with former versions... Have to retest on my poor RV730/x86 system tomorrow. Maybe you have to use WebKit not KHTML. http://html5test.com/index.html -- You are receiving this mail because: You are on the CC list for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 90207] [r600g, bisected] regression: NI/Turks crash on WebGL Water (most WebGL stuff)
https://bugs.freedesktop.org/show_bug.cgi?id=90207 Bug ID: 90207 Summary: [r600g, bisected] regression: NI/Turks crash on WebGL Water (most WebGL stuff) Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-de...@lists.freedesktop.org Reporter: die...@nuetzel-hh.de QA Contact: dri-de...@lists.freedesktop.org CC: mesa-dev@lists.freedesktop.org Current Mesa git (9143940) crash on WebGL Water demo and most WebGL stuff. http://madebyevan.com/webgl-water/ http://www.ibiblio.org/e-notes/webgl/webgl.htm I've bisected it to: /opt/mesa git bisect good a563689a408b7a28c710fb0e382272a0d823f38a is the first bad commit commit a563689a408b7a28c710fb0e382272a0d823f38a Author: Tapani Pälli tapani.pa...@intel.com Date: Thu Apr 23 11:13:17 2015 +0300 mesa: refactor active attrib queries for glGetProgramiv Main motivation here is to get rid of iterating IR and encapsulate queries within program resources. No functional changes. Piglit tests calling the modified functionality: - gl-get-active-attrib-returns-all-inputs - glsl-1.50-get-active-attrib-array - getactiveattrib Signed-off-by: Tapani Pälli tapani.pa...@intel.com Reviewed-by: Martin Peres martin.pe...@linux.intel.com :04 04 8983df05bac6cc3a455b2e5100a2038939e24eaa cd5fa256be39b9b02e9201a9ce6d313c670f2942 M src When I revert 'a563689' all is smooth, again. -- You are receiving this mail because: You are on the CC list for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 90207] [r600g, bisected] regression: NI/Turks crash on WebGL Water (most WebGL stuff)
https://bugs.freedesktop.org/show_bug.cgi?id=90207 --- Comment #5 from Dieter Nützel die...@nuetzel-hh.de --- (In reply to Dieter Nützel from comment #4) (In reply to Tapani Pälli from comment #3) My konqueror does not seems to support webgl (?) is there something special I need to do to enable it? Hello Tapani! [snip] Maybe you have to use WebKit not KHTML. http://html5test.com/index.html It is in since 11./13.10.2011 through WebKit. -- You are receiving this mail because: You are on the CC list for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 6/7] i965/cs: Implement brw_emit_gpgpu_walker
On Friday, April 24, 2015 04:33:43 PM Jordan Justen wrote:
Tested on Ivybridge, Haswell and Broadwell.
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
src/mesa/drivers/dri/i965/brw_compute.c | 39
-
src/mesa/drivers/dri/i965/brw_defines.h | 1 +
2 files changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_compute.c
b/src/mesa/drivers/dri/i965/brw_compute.c
index baed701..06ef448 100644
--- a/src/mesa/drivers/dri/i965/brw_compute.c
+++ b/src/mesa/drivers/dri/i965/brw_compute.c
@@ -31,12 +31,49 @@
#include brw_draw.h
#include brw_state.h
#include intel_batchbuffer.h
+#include brw_defines.h
static void
brw_emit_gpgpu_walker(struct brw_context *brw, const GLuint *num_groups)
{
- _mesa_problem(brw-ctx, TODO: implement brw_emit_gpgpu_walker);
+ const struct brw_cs_prog_data *prog_data = brw-cs.prog_data;
+
+ const unsigned simd_size = prog_data-simd_size;
+ unsigned group_size = prog_data-local_size[0] *
+ prog_data-local_size[1] * prog_data-local_size[2];
+ unsigned thread_width_max =
+ (group_size + simd_size - 1) / simd_size;
+
+ uint32_t right_mask = (1u simd_size) - 1;
+ const unsigned right_non_aligned = group_size (simd_size - 1);
+ if (right_non_aligned != 0)
+ right_mask = (simd_size - right_non_aligned);
I think this is equvalent to:
uint32_t right_mask = (1u (simd_size - (group_size % simd_size))) - 1;
which might be a bit simpler...
+ BEGIN_BATCH(dwords);
+ OUT_BATCH(GPGPU_WALKER 16 | (dwords - 2));
I was going to suggest splitting this into separate Gen8+ and Gen7
blocks, but now that I look at the code...these two are slightly
different indirect handling, and the later one is just a DWord of MBZ,
so...it's not really that different. I think what you have is fine :)
+ uint32_t dwords = brw-gen 8 ? 11 : 15;
+ OUT_BATCH(0);
+ if (brw-gen = 8) {
+ OUT_BATCH(0);
+ OUT_BATCH(0);
+ }
+ assert(thread_width_max = brw-max_cs_threads);
+ OUT_BATCH(((simd_size == 8) ? 0 : 1) 30 |
You might want to write this as ((simd_size / 8) - 1). That will work
for SIMD8/16/32.
Topi would probably suggest using SET_FIELD, i.e.
#define BRW_GPGPU_SIMD_SIZE_SHIFT 30
#define BRW_GPGPU_SIMD_SIZE_MASK INTEL_MASK(31, 30)
SET_FIELD((simd_size / 8) - 1, BRW_GPGPU_SIMD_SIZE)
It's probably a good idea here too.
+ (thread_width_max - 1));
Don't you need to set the thread height/depth maximums as well?
I'm not really sure how this works.
+ OUT_BATCH(0);
It'd be nice to label the 0's, i.e.
OUT_BATCH(0); /* Thread Group ID Starting X */
OUT_BATCH(num_groups[0]); /* Thread Group ID X Dimension */
With those changes, the whole series is:
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
I haven't verified that these execution masks are really what you want.
You know more about this than I do. :)
+ if (brw-gen = 8)
+ OUT_BATCH(0);
+ OUT_BATCH(num_groups[0]);
+ OUT_BATCH(0);
+ if (brw-gen = 8)
+ OUT_BATCH(0);
+ OUT_BATCH(num_groups[1]);
+ OUT_BATCH(0);
+ OUT_BATCH(num_groups[2]);
+ OUT_BATCH(right_mask);
+ OUT_BATCH(0x);
+ ADVANCE_BATCH();
}
diff --git a/src/mesa/drivers/dri/i965/brw_defines.h
b/src/mesa/drivers/dri/i965/brw_defines.h
index 36f46af..cd25511 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -2451,5 +2451,6 @@ enum brw_wm_barycentric_interp_mode {
#define MEDIA_VFE_STATE 0x7000
#define MEDIA_INTERFACE_DESCRIPTOR_LOAD 0x7002
+#define GPGPU_WALKER0x7105
#endif
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 6/7] i965: ensure execution of fragment shader when fragment shader has atomic buffer access
On Friday, April 24, 2015 08:21:36 PM Rogovin, Kevin wrote: Checking brw-ctx.Shader._CurrentFragmentProgram != NULL is unnecessary. There is always a valid pixel shader. (If the application is using fixed-function, we supply a fragment shader for them.) Please drop that check. Without this check(in the Gen7 function/code), about 30 crashes are induced on piglit tests for Gen7; the tests are all using GL fixed function pipeline. I have not run piglit without this check on Gen8 though. My mistake - we always have a pixel shader, but I think only GLSL programs have a _CurrentFragmentProgram pointer in place. Certainly ARB programs don't have a gl_shader_program, so you're right, this check is necessary. I thought that UAVs were essentially for Images...I'm not clear why this is needed. Perhaps Curro can confirm one way or another. The essential reason is to guarantee that the pixel shader gets invoked by Gen even when all render target surfaces are NULL surfaces. There are other flags one can use, but the UAV seems (to me) the most natural. -Kevin Yeah, that makes sense. Seems fine. signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 90207] [r600g, bisected] regression: NI/Turks crash on WebGL Water (most WebGL stuff)
https://bugs.freedesktop.org/show_bug.cgi?id=90207 --- Comment #1 from Dieter Nützel die...@nuetzel-hh.de --- Created attachment 115389 -- https://bugs.freedesktop.org/attachment.cgi?id=115389action=edit konqueror-20150428-051127.kcrash.txt -- You are receiving this mail because: You are on the CC list for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 90207] [r600g, bisected] regression: NI/Turks crash on WebGL Water (most WebGL stuff)
https://bugs.freedesktop.org/show_bug.cgi?id=90207 --- Comment #7 from Tapani Pälli lem...@gmail.com --- (In reply to Dieter Nützel from comment #6) (In reply to Dieter Nützel from comment #5) (In reply to Dieter Nützel from comment #4) (In reply to Tapani Pälli from comment #3) My konqueror does not seems to support webgl (?) is there something special I need to do to enable it? Hello Tapani! [snip] Maybe you have to use WebKit not KHTML. http://html5test.com/index.html It is in since 11./13.10.2011 through WebKit. kwebkitpart kwebkitpart-1.3.3-3.1.5.x86_64 Yes, installing this package made it work, demos seem to work for me though .. I will try some more and also investigate possible side-effects caused by my patch. -- You are receiving this mail because: You are on the CC list for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 09/10] gallium, clover: add OpenCL interoperability support for CL events
Marek Olšák mar...@gmail.com writes:
From: Marek Olšák marek.ol...@amd.com
v2: - move interop.cpp to clover/api
- change intptr_t to void* in the interface
- add a virtual function fence() to simplify some code
v3: - use bool in the interface
---
src/gallium/include/state_tracker/opencl_interop.h | 40 +++
src/gallium/state_trackers/clover/Makefile.sources | 1 +
src/gallium/state_trackers/clover/api/interop.cpp | 60
++
src/gallium/state_trackers/clover/core/event.hpp | 8 +++
src/gallium/targets/opencl/opencl.sym | 1 +
5 files changed, 110 insertions(+)
create mode 100644 src/gallium/include/state_tracker/opencl_interop.h
create mode 100644 src/gallium/state_trackers/clover/api/interop.cpp
diff --git a/src/gallium/include/state_tracker/opencl_interop.h
b/src/gallium/include/state_tracker/opencl_interop.h
new file mode 100644
index 000..4983644
--- /dev/null
+++ b/src/gallium/include/state_tracker/opencl_interop.h
@@ -0,0 +1,40 @@
+/**
+ *
+ * Copyright 2015 Advanced Micro Devices, Inc.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * Software), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
+ * IN NO EVENT SHALL THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR
+ * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
+ * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
+ * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ **/
+
+#ifndef OPENCL_INTEROP_H
+#define OPENCL_INTEROP_H
+
+/* dlsym these without the _t suffix. You should get the correct symbols
+ * if the OpenCL driver is loaded.
+ */
+
+typedef bool (*opencl_dri_event_add_ref_t)(void *cl_event);
+typedef bool (*opencl_dri_event_release_t)(void *cl_event);
+typedef bool (*opencl_dri_event_wait_t)(void *cl_event, uint64_t timeout);
+typedef struct pipe_fence_handle *(*opencl_dri_event_get_fence_t)(void
*cl_event);
+
+#endif /* OPENCL_INTEROP_H */
diff --git a/src/gallium/state_trackers/clover/Makefile.sources
b/src/gallium/state_trackers/clover/Makefile.sources
index 5b3344c..9e30c69 100644
--- a/src/gallium/state_trackers/clover/Makefile.sources
+++ b/src/gallium/state_trackers/clover/Makefile.sources
@@ -4,6 +4,7 @@ CPP_SOURCES := \
api/dispatch.cpp \
api/dispatch.hpp \
api/event.cpp \
+ api/interop.cpp \
api/kernel.cpp \
api/memory.cpp \
api/platform.cpp \
diff --git a/src/gallium/state_trackers/clover/api/interop.cpp
b/src/gallium/state_trackers/clover/api/interop.cpp
new file mode 100644
index 000..8d18200
--- /dev/null
+++ b/src/gallium/state_trackers/clover/api/interop.cpp
@@ -0,0 +1,60 @@
+//
+// Copyright 2015 Advanced Micro Devices, Inc.
+// All Rights Reserved.
+//
+// Permission is hereby granted, free of charge, to any person obtaining a
+// copy of this software and associated documentation files (the Software),
+// to deal in the Software without restriction, including without limitation
+// the rights to use, copy, modify, merge, publish, distribute, sublicense,
+// and/or sell copies of the Software, and to permit persons to whom the
+// Software is furnished to do so, subject to the following conditions:
+//
+// The above copyright notice and this permission notice shall be included in
+// all copies or substantial portions of the Software.
+//
+// THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+// IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+// FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+// THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
+// OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+// ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+// OTHER DEALINGS IN THE SOFTWARE.
+//
+
+#include core/event.hpp
+#include api/util.hpp
+
+using namespace clover;
+
+extern C {
+
+PUBLIC bool
Re: [Mesa-dev] Patch: typo fixing
Zoë Blade z...@bytenoise.co.uk writes: Hi! In this line there is a second typo in degnerate. Very well spotted, thank you! I've now fixed that particular typo, which appears in two different places: src/mesa/drivers/dri/i965/brw_clip_unfilled.c src/mesa/vbo/vbo_save_draw.c While I was at it, I spotted two more typos, now fixed: docs/relnotes/10.0.3.html src/gallium/drivers/llvmpipe/lp_scene.h I've amended http://bytenoise.co.uk/misc/fix-a-few-typos.patch with these additions. Thanks, pushed as 05e7f7f4388bde882b7ce74124000a4d435a. Thanks, Zoë. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] r600g, radeonsi: add driver queries for GPU temperature and shader+memory clocks
On Mon, Apr 27, 2015 at 10:46 AM, Marek Olšák mar...@gmail.com wrote:
From: Marek Olšák marek.ol...@amd.com
For the series:
Reviewed-by: Alex Deucher alexander.deuc...@amd.com
---
src/gallium/drivers/radeon/r600_pipe_common.c | 13 +++--
src/gallium/drivers/radeon/r600_pipe_common.h | 3 +++
src/gallium/drivers/radeon/r600_query.c | 21 +
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 19 +++
src/gallium/winsys/radeon/drm/radeon_winsys.h | 5 -
5 files changed, 58 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c
b/src/gallium/drivers/radeon/r600_pipe_common.c
index c6d7918..97eed13 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.c
+++ b/src/gallium/drivers/radeon/r600_pipe_common.c
@@ -665,12 +665,21 @@ static int r600_get_driver_query_info(struct
pipe_screen *screen,
{num-bytes-moved, R600_QUERY_NUM_BYTES_MOVED, 0, TRUE},
{VRAM-usage, R600_QUERY_VRAM_USAGE,
rscreen-info.vram_size, TRUE},
{GTT-usage, R600_QUERY_GTT_USAGE, rscreen-info.gart_size,
TRUE},
+ {temperature, R600_QUERY_GPU_TEMPERATURE, 100, FALSE},
+ {shader-clock, R600_QUERY_CURRENT_GPU_SCLK, 0, FALSE},
+ {memory-clock, R600_QUERY_CURRENT_GPU_MCLK, 0, FALSE}
};
+ unsigned num_queries;
+
+ if (rscreen-info.drm_major == 2 rscreen-info.drm_minor = 42)
+ num_queries = Elements(list);
+ else
+ num_queries = 8;
if (!info)
- return Elements(list);
+ return num_queries;
- if (index = Elements(list))
+ if (index = num_queries)
return 0;
*info = list[index];
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.h
b/src/gallium/drivers/radeon/r600_pipe_common.h
index 384a9a6..c23072c 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.h
+++ b/src/gallium/drivers/radeon/r600_pipe_common.h
@@ -55,6 +55,9 @@
#define R600_QUERY_NUM_BYTES_MOVED (PIPE_QUERY_DRIVER_SPECIFIC + 5)
#define R600_QUERY_VRAM_USAGE (PIPE_QUERY_DRIVER_SPECIFIC + 6)
#define R600_QUERY_GTT_USAGE (PIPE_QUERY_DRIVER_SPECIFIC + 7)
+#define R600_QUERY_GPU_TEMPERATURE (PIPE_QUERY_DRIVER_SPECIFIC + 8)
+#define R600_QUERY_CURRENT_GPU_SCLK(PIPE_QUERY_DRIVER_SPECIFIC + 9)
+#define R600_QUERY_CURRENT_GPU_MCLK(PIPE_QUERY_DRIVER_SPECIFIC + 10)
#define R600_CONTEXT_STREAMOUT_FLUSH (1u 0)
#define R600_CONTEXT_PRIVATE_FLAG (1u 1)
diff --git a/src/gallium/drivers/radeon/r600_query.c
b/src/gallium/drivers/radeon/r600_query.c
index 6a35ab8..758064a 100644
--- a/src/gallium/drivers/radeon/r600_query.c
+++ b/src/gallium/drivers/radeon/r600_query.c
@@ -86,6 +86,9 @@ static struct r600_resource *r600_new_query_buffer(struct
r600_common_context *c
case R600_QUERY_NUM_BYTES_MOVED:
case R600_QUERY_VRAM_USAGE:
case R600_QUERY_GTT_USAGE:
+ case R600_QUERY_GPU_TEMPERATURE:
+ case R600_QUERY_CURRENT_GPU_SCLK:
+ case R600_QUERY_CURRENT_GPU_MCLK:
return NULL;
}
@@ -382,6 +385,9 @@ static struct pipe_query *r600_create_query(struct
pipe_context *ctx, unsigned q
case R600_QUERY_NUM_BYTES_MOVED:
case R600_QUERY_VRAM_USAGE:
case R600_QUERY_GTT_USAGE:
+ case R600_QUERY_GPU_TEMPERATURE:
+ case R600_QUERY_CURRENT_GPU_SCLK:
+ case R600_QUERY_CURRENT_GPU_MCLK:
skip_allocation = true;
break;
default:
@@ -439,6 +445,9 @@ static void r600_begin_query(struct pipe_context *ctx,
struct pipe_query *query)
case R600_QUERY_REQUESTED_GTT:
case R600_QUERY_VRAM_USAGE:
case R600_QUERY_GTT_USAGE:
+ case R600_QUERY_GPU_TEMPERATURE:
+ case R600_QUERY_CURRENT_GPU_SCLK:
+ case R600_QUERY_CURRENT_GPU_MCLK:
rquery-begin_result = 0;
return;
case R600_QUERY_BUFFER_WAIT_TIME:
@@ -513,6 +522,15 @@ static void r600_end_query(struct pipe_context *ctx,
struct pipe_query *query)
case R600_QUERY_GTT_USAGE:
rquery-end_result = rctx-ws-query_value(rctx-ws,
RADEON_GTT_USAGE);
return;
+ case R600_QUERY_GPU_TEMPERATURE:
+ rquery-end_result = rctx-ws-query_value(rctx-ws,
RADEON_GPU_TEMPERATURE) / 1000;
+ return;
+ case R600_QUERY_CURRENT_GPU_SCLK:
+ rquery-end_result = rctx-ws-query_value(rctx-ws,
RADEON_CURRENT_SCLK) * 100;
+ return;
+ case R600_QUERY_CURRENT_GPU_MCLK:
+ rquery-end_result = rctx-ws-query_value(rctx-ws,
RADEON_CURRENT_MCLK) * 100;
+ return;
}
r600_emit_query_end(rctx, rquery);
@@ -570,6 +588,9 @@ static boolean
[Mesa-dev] [Bug 90167] [softpipe] piglit depthstencil-default_fb-drawpixels-32f_24_8_rev regression
https://bugs.freedesktop.org/show_bug.cgi?id=90167 Roland Scheidegger srol...@vmware.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Roland Scheidegger srol...@vmware.com --- Fixed by 7c3d1c132eea83fb257cbc473a8a79638ddc3014 -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] mesa: remove unused options var in compile_shader()
---
src/mesa/main/shaderapi.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
index cc001ba..a04b287 100644
--- a/src/mesa/main/shaderapi.c
+++ b/src/mesa/main/shaderapi.c
@@ -861,14 +861,11 @@ static void
compile_shader(struct gl_context *ctx, GLuint shaderObj)
{
struct gl_shader *sh;
- struct gl_shader_compiler_options *options;
sh = _mesa_lookup_shader_err(ctx, shaderObj, glCompileShader);
if (!sh)
return;
- options = ctx-Const.ShaderCompilerOptions[sh-Stage];
-
if (!sh-Source) {
/* If the user called glCompileShader without first calling
* glShaderSource, we should fail to compile, but not raise a GL_ERROR.
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 03/18] winsys/amdgpu: add a new winsys for the new kernel driver
On Tue, Apr 21, 2015 at 5:12 PM, Emil Velikov emil.l.veli...@gmail.com wrote: Hi Marek, Must admit that the current split/location of the new winsys looks a bit strange. I'm thinking that if one places the new winsys alongside the radeon one (i.e. winsys/amdgpu/drm) things should still work and thus we'll result in shorter and cleaner patch. See below for more details. I've moved it now and I'm in the middle of a rebase right now. On 20/04/15 22:23, Marek Olšák wrote: From: Marek Olšák marek.ol...@amd.com --- configure.ac | 5 + src/gallium/Makefile.am | 1 + src/gallium/drivers/r300/Automake.inc | 6 +- src/gallium/drivers/r600/Automake.inc | 6 +- src/gallium/drivers/radeonsi/Automake.inc | 6 +- src/gallium/targets/pipe-loader/Makefile.am | 12 +- src/gallium/winsys/radeon/amdgpu/Android.mk | 40 ++ src/gallium/winsys/radeon/amdgpu/Makefile.am | 12 + src/gallium/winsys/radeon/amdgpu/Makefile.sources | 8 + src/gallium/winsys/radeon/amdgpu/amdgpu_bo.c | 643 ++ src/gallium/winsys/radeon/amdgpu/amdgpu_bo.h | 75 +++ src/gallium/winsys/radeon/amdgpu/amdgpu_cs.c | 578 +++ src/gallium/winsys/radeon/amdgpu/amdgpu_cs.h | 149 + src/gallium/winsys/radeon/amdgpu/amdgpu_public.h | 14 + src/gallium/winsys/radeon/amdgpu/amdgpu_winsys.c | 491 + src/gallium/winsys/radeon/amdgpu/amdgpu_winsys.h | 80 +++ src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 8 + src/gallium/winsys/radeon/radeon_winsys.h | 4 + 18 files changed, 2129 insertions(+), 9 deletions(-) create mode 100644 src/gallium/winsys/radeon/amdgpu/Android.mk create mode 100644 src/gallium/winsys/radeon/amdgpu/Makefile.am create mode 100644 src/gallium/winsys/radeon/amdgpu/Makefile.sources create mode 100644 src/gallium/winsys/radeon/amdgpu/amdgpu_bo.c create mode 100644 src/gallium/winsys/radeon/amdgpu/amdgpu_bo.h create mode 100644 src/gallium/winsys/radeon/amdgpu/amdgpu_cs.c create mode 100644 src/gallium/winsys/radeon/amdgpu/amdgpu_cs.h create mode 100644 src/gallium/winsys/radeon/amdgpu/amdgpu_public.h create mode 100644 src/gallium/winsys/radeon/amdgpu/amdgpu_winsys.c create mode 100644 src/gallium/winsys/radeon/amdgpu/amdgpu_winsys.h diff --git a/configure.ac b/configure.ac index 095e23e..f22975f 100644 --- a/configure.ac +++ b/configure.ac @@ -68,6 +68,7 @@ AC_SUBST([OSMESA_VERSION]) dnl Versions for external dependencies LIBDRM_REQUIRED=2.4.38 LIBDRM_RADEON_REQUIRED=2.4.56 +LIBDRM_AMDGPU_REQUIRED=2.4.60 I guess this will need to be changed once the libdrm patches land ? Yes. LIBDRM_INTEL_REQUIRED=2.4.60 LIBDRM_NVVIEUX_REQUIRED=2.4.33 LIBDRM_NOUVEAU_REQUIRED=2.4.33 libdrm = 2.4.41 @@ -2091,6 +2092,7 @@ if test -n $with_gallium_drivers; then xr300) HAVE_GALLIUM_R300=yes PKG_CHECK_MODULES([RADEON], [libdrm_radeon = $LIBDRM_RADEON_REQUIRED]) +PKG_CHECK_MODULES([AMDGPU], [libdrm_amdgpu = $LIBDRM_AMDGPU_REQUIRED]) gallium_require_drm Gallium R300 gallium_require_drm_loader gallium_require_llvm Gallium R300 @@ -2098,6 +2100,7 @@ if test -n $with_gallium_drivers; then xr600) HAVE_GALLIUM_R600=yes PKG_CHECK_MODULES([RADEON], [libdrm_radeon = $LIBDRM_RADEON_REQUIRED]) +PKG_CHECK_MODULES([AMDGPU], [libdrm_amdgpu = $LIBDRM_AMDGPU_REQUIRED]) We can drop the above two hunks. gallium_require_drm Gallium R600 gallium_require_drm_loader if test x$enable_r600_llvm = xyes -o x$enable_opencl = xyes; then @@ -2114,6 +2117,7 @@ if test -n $with_gallium_drivers; then xradeonsi) HAVE_GALLIUM_RADEONSI=yes PKG_CHECK_MODULES([RADEON], [libdrm_radeon = $LIBDRM_RADEON_REQUIRED]) +PKG_CHECK_MODULES([AMDGPU], [libdrm_amdgpu = $LIBDRM_AMDGPU_REQUIRED]) gallium_require_drm radeonsi gallium_require_drm_loader radeon_llvm_check radeonsi @@ -2384,6 +2388,7 @@ AC_CONFIG_FILES([Makefile src/gallium/winsys/intel/drm/Makefile src/gallium/winsys/nouveau/drm/Makefile src/gallium/winsys/radeon/drm/Makefile + src/gallium/winsys/radeon/amdgpu/Makefile src/gallium/winsys/svga/drm/Makefile src/gallium/winsys/sw/dri/Makefile src/gallium/winsys/sw/kms-dri/Makefile diff --git a/src/gallium/Makefile.am b/src/gallium/Makefile.am index ede6e21..fa526d4 100644 --- a/src/gallium/Makefile.am +++ b/src/gallium/Makefile.am @@ -63,6 +63,7 @@ endif ## the radeon winsys - linked in by r300, r600 and radeonsi if NEED_RADEON_DRM_WINSYS SUBDIRS += winsys/radeon/drm +SUBDIRS += winsys/radeon/amdgpu Move
Re: [Mesa-dev] [PATCH 1/2] util/macros: Move DIV_ROUND_UP to util/macros.h
On 27/04/2015 15:52, Brian Paul wrote : On 04/26/2015 03:23 PM, Axel Davy wrote: */ #include svga3d_reg.h +#include util/macros.h Actually, it looks like this #include may not be needed. We get ARRAY_SIZE via including svga3d_reg.h, which includes svga_types.h, which includes p_compiler.h which includes util/macros.h Otherwise, for both: Reviewed-by: Brian Paul bri...@vmware.com Do you want I remove this include from the patch ? Or that I let it there for clarity ? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: properly setting var-data.binding if explicit_binding is true
Hi Alejandro On 26 April 2015 at 14:23, Alejandro Piñeiro apinhe...@igalia.com wrote: On 26/04/15 00:08, Timothy Arceri wrote: On Sat, 2015-04-25 at 18:46 +0200, Alejandro Piñeiro wrote: There was a typo on commit c0cd5b, doing it when explicit_binding was false. This prevented to use any binding point different to 0. Considering that the offending commit landed in 10.4-devel, please add the following line in the commit message. This way we won't forget picking this up for the stable branches. Cc: 10.4 10.5 mesa-sta...@lists.freedesktop.org --- Taking into account the explanation on the header about the variable binding (ast.h:553) /** * Binding specified via GL_ARB_shading_language_420pack's binding keyword. * * \note * This field is only valid if \c explicit_binding is set. */ int binding; The binding is correct (and should be updated) if explicit_binding is true. But the current behaviour was updating it if it was false. This was not detected by piglit because all the calls to glBindBufferBase(GL_ATOMIC_COUNTER_BUFFER are using 0. I tested this patch by running all piglit on my system, and I didn't detect regression. I also runned make check without issues. https://bugs.freedesktop.org/show_bug.cgi?id=90175 Please move the bug entry to the commit message and prefix with Bugzilla: You should probably convert your test program to a piglit test also so this bug can be detected if it happens again in the future. There are several piglit tests at spec/arb_shader_atomic_counters testing that you get what you expect while using atomic counters. Probably it would be enough to just modify some of the already existing tests, using a non-zero binding point (for example at semantics.c). But I don't have too much experience tweaking/creating piglit tests. What option would be preferred for this case? A new test or just modify a little one of the already available? Don't think that changing the behaviour of existing tests is a good idea. As Timothy mentioned, you can add a subtest which will cut down the copy/pasta a bit. Cheers, Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2] st/nine: Rework texture data allocation
Some applications assume the memory for multilevel
textures is allocated per continuous blocks.
This patch implements that behaviour.
v2: cache offsets
Signed-off-by: Axel Davy axel.d...@ens.fr
---
src/gallium/state_trackers/nine/cubetexture9.c | 46 ++-
src/gallium/state_trackers/nine/cubetexture9.h | 1 +
src/gallium/state_trackers/nine/nine_pipe.h| 41 +
src/gallium/state_trackers/nine/surface9.c | 51 ++
src/gallium/state_trackers/nine/surface9.h | 1 -
src/gallium/state_trackers/nine/texture9.c | 27 +-
src/gallium/state_trackers/nine/texture9.h | 1 +
7 files changed, 131 insertions(+), 37 deletions(-)
diff --git a/src/gallium/state_trackers/nine/cubetexture9.c
b/src/gallium/state_trackers/nine/cubetexture9.c
index d81cc70..f64764c 100644
--- a/src/gallium/state_trackers/nine/cubetexture9.c
+++ b/src/gallium/state_trackers/nine/cubetexture9.c
@@ -20,6 +20,8 @@
* OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
* USE OR OTHER DEALINGS IN THE SOFTWARE. */
+#include c99_alloca.h
+
#include device9.h
#include cubetexture9.h
#include nine_helpers.h
@@ -40,8 +42,10 @@ NineCubeTexture9_ctor( struct NineCubeTexture9 *This,
struct pipe_resource *info = This-base.base.info;
struct pipe_screen *screen = pParams-device-screen;
enum pipe_format pf;
-unsigned i;
+unsigned i, l, f, offset, face_size = 0;
+unsigned *level_offsets;
D3DSURFACE_DESC sfdesc;
+void *p;
HRESULT hr;
DBG(This=%p pParams=%p EdgeLength=%u Levels=%u Usage=%d
@@ -97,6 +101,16 @@ NineCubeTexture9_ctor( struct NineCubeTexture9 *This,
DBG(Application asked for Software Vertex Processing,
but this is unimplemented\n);
+if (Pool != D3DPOOL_DEFAULT) {
+level_offsets = alloca(sizeof(unsigned) * (info-last_level + 1));
+face_size = nine_format_get_size_and_offsets(pf, level_offsets,
+ EdgeLength, EdgeLength,
+ info-last_level);
+This-managed_buffer = MALLOC(6 * face_size);
+if (!This-managed_buffer)
+return E_OUTOFMEMORY;
+}
+
This-surfaces = CALLOC(6 * (info-last_level + 1),
sizeof(*This-surfaces));
if (!This-surfaces)
return E_OUTOFMEMORY;
@@ -117,16 +131,25 @@ NineCubeTexture9_ctor( struct NineCubeTexture9 *This,
sfdesc.Pool = Pool;
sfdesc.MultiSampleType = D3DMULTISAMPLE_NONE;
sfdesc.MultiSampleQuality = 0;
-for (i = 0; i (info-last_level + 1) * 6; ++i) {
-sfdesc.Width = sfdesc.Height = u_minify(EdgeLength, i / 6);
-
-hr = NineSurface9_new(This-base.base.base.device, NineUnknown(This),
- This-base.base.resource, NULL,
D3DRTYPE_CUBETEXTURE,
- i / 6, i % 6,
- sfdesc, This-surfaces[i]);
-if (FAILED(hr))
-return hr;
+/* We allocate the memory for the surfaces as continous blocks.
+ * This is the expected behaviour, however we haven't tested for
+ * cube textures in which order the faces/levels should be in memory
+ */
+for (f = 0; f 6; f++) {
+offset = f * face_size;
+for (l = 0; l = info-last_level; l++) {
+sfdesc.Width = sfdesc.Height = u_minify(EdgeLength, l);
+p = This-managed_buffer ? This-managed_buffer + offset +
+level_offsets[l] : NULL;
+
+hr = NineSurface9_new(This-base.base.base.device,
NineUnknown(This),
+ This-base.base.resource, p,
D3DRTYPE_CUBETEXTURE,
+ l, f, sfdesc, This-surfaces[f + 6 * l]);
+if (FAILED(hr))
+return hr;
+}
}
+
for (i = 0; i 6; ++i) /* width = 0 means empty, depth stays 1 */
This-dirty_rect[i].depth = 1;
@@ -146,6 +169,9 @@ NineCubeTexture9_dtor( struct NineCubeTexture9 *This )
FREE(This-surfaces);
}
+if (This-managed_buffer)
+FREE(This-managed_buffer);
+
NineBaseTexture9_dtor(This-base);
}
diff --git a/src/gallium/state_trackers/nine/cubetexture9.h
b/src/gallium/state_trackers/nine/cubetexture9.h
index e8594d3..ee7e275 100644
--- a/src/gallium/state_trackers/nine/cubetexture9.h
+++ b/src/gallium/state_trackers/nine/cubetexture9.h
@@ -31,6 +31,7 @@ struct NineCubeTexture9
struct NineBaseTexture9 base;
struct NineSurface9 **surfaces;
struct pipe_box dirty_rect[6]; /* covers all mip levels */
+uint8_t *managed_buffer;
};
static INLINE struct NineCubeTexture9 *
NineCubeTexture9( void *data )
diff --git a/src/gallium/state_trackers/nine/nine_pipe.h
b/src/gallium/state_trackers/nine/nine_pipe.h
index b8e728e..1b88612 100644
--- a/src/gallium/state_trackers/nine/nine_pipe.h
+++ b/src/gallium/state_trackers/nine/nine_pipe.h
@@
Re: [Mesa-dev] [PATCH v2] st/nine: Rework texture data allocation
On Mon, Apr 27, 2015 at 1:39 PM, Axel Davy axel.d...@ens.fr wrote:
Some applications assume the memory for multilevel
textures is allocated per continuous blocks.
This patch implements that behaviour.
v2: cache offsets
Thanks, this is much nicer IMO.
Reviewed-by: Ilia Mirkin imir...@alum.mit.edu
Signed-off-by: Axel Davy axel.d...@ens.fr
---
src/gallium/state_trackers/nine/cubetexture9.c | 46 ++-
src/gallium/state_trackers/nine/cubetexture9.h | 1 +
src/gallium/state_trackers/nine/nine_pipe.h| 41 +
src/gallium/state_trackers/nine/surface9.c | 51
++
src/gallium/state_trackers/nine/surface9.h | 1 -
src/gallium/state_trackers/nine/texture9.c | 27 +-
src/gallium/state_trackers/nine/texture9.h | 1 +
7 files changed, 131 insertions(+), 37 deletions(-)
diff --git a/src/gallium/state_trackers/nine/cubetexture9.c
b/src/gallium/state_trackers/nine/cubetexture9.c
index d81cc70..f64764c 100644
--- a/src/gallium/state_trackers/nine/cubetexture9.c
+++ b/src/gallium/state_trackers/nine/cubetexture9.c
@@ -20,6 +20,8 @@
* OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
* USE OR OTHER DEALINGS IN THE SOFTWARE. */
+#include c99_alloca.h
+
#include device9.h
#include cubetexture9.h
#include nine_helpers.h
@@ -40,8 +42,10 @@ NineCubeTexture9_ctor( struct NineCubeTexture9 *This,
struct pipe_resource *info = This-base.base.info;
struct pipe_screen *screen = pParams-device-screen;
enum pipe_format pf;
-unsigned i;
+unsigned i, l, f, offset, face_size = 0;
+unsigned *level_offsets;
D3DSURFACE_DESC sfdesc;
+void *p;
HRESULT hr;
DBG(This=%p pParams=%p EdgeLength=%u Levels=%u Usage=%d
@@ -97,6 +101,16 @@ NineCubeTexture9_ctor( struct NineCubeTexture9 *This,
DBG(Application asked for Software Vertex Processing,
but this is unimplemented\n);
+if (Pool != D3DPOOL_DEFAULT) {
+level_offsets = alloca(sizeof(unsigned) * (info-last_level + 1));
+face_size = nine_format_get_size_and_offsets(pf, level_offsets,
+ EdgeLength, EdgeLength,
+ info-last_level);
+This-managed_buffer = MALLOC(6 * face_size);
+if (!This-managed_buffer)
+return E_OUTOFMEMORY;
+}
+
This-surfaces = CALLOC(6 * (info-last_level + 1),
sizeof(*This-surfaces));
if (!This-surfaces)
return E_OUTOFMEMORY;
@@ -117,16 +131,25 @@ NineCubeTexture9_ctor( struct NineCubeTexture9 *This,
sfdesc.Pool = Pool;
sfdesc.MultiSampleType = D3DMULTISAMPLE_NONE;
sfdesc.MultiSampleQuality = 0;
-for (i = 0; i (info-last_level + 1) * 6; ++i) {
-sfdesc.Width = sfdesc.Height = u_minify(EdgeLength, i / 6);
-
-hr = NineSurface9_new(This-base.base.base.device, NineUnknown(This),
- This-base.base.resource, NULL,
D3DRTYPE_CUBETEXTURE,
- i / 6, i % 6,
- sfdesc, This-surfaces[i]);
-if (FAILED(hr))
-return hr;
+/* We allocate the memory for the surfaces as continous blocks.
+ * This is the expected behaviour, however we haven't tested for
+ * cube textures in which order the faces/levels should be in memory
+ */
+for (f = 0; f 6; f++) {
+offset = f * face_size;
+for (l = 0; l = info-last_level; l++) {
+sfdesc.Width = sfdesc.Height = u_minify(EdgeLength, l);
+p = This-managed_buffer ? This-managed_buffer + offset +
+level_offsets[l] : NULL;
+
+hr = NineSurface9_new(This-base.base.base.device,
NineUnknown(This),
+ This-base.base.resource, p,
D3DRTYPE_CUBETEXTURE,
+ l, f, sfdesc, This-surfaces[f + 6 * l]);
+if (FAILED(hr))
+return hr;
+}
}
+
for (i = 0; i 6; ++i) /* width = 0 means empty, depth stays 1 */
This-dirty_rect[i].depth = 1;
@@ -146,6 +169,9 @@ NineCubeTexture9_dtor( struct NineCubeTexture9 *This )
FREE(This-surfaces);
}
+if (This-managed_buffer)
+FREE(This-managed_buffer);
+
NineBaseTexture9_dtor(This-base);
}
diff --git a/src/gallium/state_trackers/nine/cubetexture9.h
b/src/gallium/state_trackers/nine/cubetexture9.h
index e8594d3..ee7e275 100644
--- a/src/gallium/state_trackers/nine/cubetexture9.h
+++ b/src/gallium/state_trackers/nine/cubetexture9.h
@@ -31,6 +31,7 @@ struct NineCubeTexture9
struct NineBaseTexture9 base;
struct NineSurface9 **surfaces;
struct pipe_box dirty_rect[6]; /* covers all mip levels */
+uint8_t *managed_buffer;
};
static INLINE struct NineCubeTexture9 *
Re: [Mesa-dev] [PATCH 1/2] util/macros: Move DIV_ROUND_UP to util/macros.h
On 04/27/2015 11:22 AM, Axel Davy wrote: On 27/04/2015 15:52, Brian Paul wrote : On 04/26/2015 03:23 PM, Axel Davy wrote: */ #include svga3d_reg.h +#include util/macros.h Actually, it looks like this #include may not be needed. We get ARRAY_SIZE via including svga3d_reg.h, which includes svga_types.h, which includes p_compiler.h which includes util/macros.h Otherwise, for both: Reviewed-by: Brian Paul bri...@vmware.com Do you want I remove this include from the patch ? Or that I let it there for clarity ? Let's remove it. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC 6/9] nir: Add an entirely C-based linked list implementation
Jason Ekstrand ja...@jlekstrand.net writes: This commit adds a C-based linked list implementation for NIR. Unlike exec_list in glsl/list.h, there is no C++ API. Also, this list is based on wl_list (from the Wayland project) which is, in turn, based on the kernel list. As such, it should be fairly familiar to people who have done anything in kernel space. Doesn't exec_list already have a C api? Yes, it does. However, exec_list has C++ constructors for exec_list and exec_node. In the patches that follow, I use linked lists for use/def sets for registers and SSA values. In order to do so, I have to be able to place lists and links inside of unions. Since exec_list and exec_node have constructors, doing so causes any C++ code that includes nir.h to die in a fire. Therefore, we can't just use exec_list. What about simple_list? Why re-create it? I thought about that too. However, the simple_list is badly named and the API isn't that great. Making it usable as a first-class datastructure would have taken as much work as adding nir_list. Also, simple_list isn't really a standard as it's only ever used in errors.c and the vc4 driver. Why a kernel list; why not keep the symantics of exec_list? The short version: I like it better. Also, while exec_list is familiar to people who have worked inside the mesa GLSL compiler, I think that the kernel list will be more familiar to people in the open-source graphics community in general. For whatever it's worth, I explicitly designed it with separate nir_list and nir_link structures so that we can switch from kernel list to exec_list symantics if we want to. Why put this in NIR and not in util? At the moment, NIR is the only user. I do expect that Eric may want to use it in vc4 over simple_list. However, vc4 is already using NIR anyway, so it's not really that polluting. It has also been suggested by Ken that we just pull the C bits out of exec_list and keep one underlying implementation for both C and C++ only with different names. While I think that this is definitely doable and may be the best long-term solution, I didn't want to do that refactoring prior to getting this series up-and-going and adding a list was easier. I'm ok with doing that instead of adding a list. Yes, please! I have never liked exec_list, and being gratuitously different from the other projects that we work on (linux, X) is really frustrating. I'd like us to use the same actual names as the kernel does if possible, but I understand if for now we want to have namespaced names for the functions because we might need to interact with two different types of lists. signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 09/10] gallium, clover: add OpenCL interoperability support for CL events
From: Marek Olšák marek.ol...@amd.com
v2: - move interop.cpp to clover/api
- change intptr_t to void* in the interface
- add a virtual function fence() to simplify some code
v3: - use bool in the interface
v4: - enclose the last two interop functions in try..catch
---
src/gallium/include/state_tracker/opencl_interop.h | 40 ++
src/gallium/state_trackers/clover/Makefile.sources | 1 +
src/gallium/state_trackers/clover/api/interop.cpp | 64 ++
src/gallium/state_trackers/clover/core/event.hpp | 8 +++
src/gallium/targets/opencl/opencl.sym | 1 +
5 files changed, 114 insertions(+)
create mode 100644 src/gallium/include/state_tracker/opencl_interop.h
create mode 100644 src/gallium/state_trackers/clover/api/interop.cpp
diff --git a/src/gallium/include/state_tracker/opencl_interop.h
b/src/gallium/include/state_tracker/opencl_interop.h
new file mode 100644
index 000..4983644
--- /dev/null
+++ b/src/gallium/include/state_tracker/opencl_interop.h
@@ -0,0 +1,40 @@
+/**
+ *
+ * Copyright 2015 Advanced Micro Devices, Inc.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * Software), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
+ * IN NO EVENT SHALL THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR
+ * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
+ * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
+ * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ **/
+
+#ifndef OPENCL_INTEROP_H
+#define OPENCL_INTEROP_H
+
+/* dlsym these without the _t suffix. You should get the correct symbols
+ * if the OpenCL driver is loaded.
+ */
+
+typedef bool (*opencl_dri_event_add_ref_t)(void *cl_event);
+typedef bool (*opencl_dri_event_release_t)(void *cl_event);
+typedef bool (*opencl_dri_event_wait_t)(void *cl_event, uint64_t timeout);
+typedef struct pipe_fence_handle *(*opencl_dri_event_get_fence_t)(void
*cl_event);
+
+#endif /* OPENCL_INTEROP_H */
diff --git a/src/gallium/state_trackers/clover/Makefile.sources
b/src/gallium/state_trackers/clover/Makefile.sources
index 5b3344c..9e30c69 100644
--- a/src/gallium/state_trackers/clover/Makefile.sources
+++ b/src/gallium/state_trackers/clover/Makefile.sources
@@ -4,6 +4,7 @@ CPP_SOURCES := \
api/dispatch.cpp \
api/dispatch.hpp \
api/event.cpp \
+ api/interop.cpp \
api/kernel.cpp \
api/memory.cpp \
api/platform.cpp \
diff --git a/src/gallium/state_trackers/clover/api/interop.cpp
b/src/gallium/state_trackers/clover/api/interop.cpp
new file mode 100644
index 000..ea0c7c7
--- /dev/null
+++ b/src/gallium/state_trackers/clover/api/interop.cpp
@@ -0,0 +1,64 @@
+//
+// Copyright 2015 Advanced Micro Devices, Inc.
+// All Rights Reserved.
+//
+// Permission is hereby granted, free of charge, to any person obtaining a
+// copy of this software and associated documentation files (the Software),
+// to deal in the Software without restriction, including without limitation
+// the rights to use, copy, modify, merge, publish, distribute, sublicense,
+// and/or sell copies of the Software, and to permit persons to whom the
+// Software is furnished to do so, subject to the following conditions:
+//
+// The above copyright notice and this permission notice shall be included in
+// all copies or substantial portions of the Software.
+//
+// THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+// IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+// FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+// THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
+// OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+// ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+// OTHER DEALINGS IN THE SOFTWARE.
+//
+
+#include core/event.hpp
+#include api/util.hpp
+
+using namespace clover;
+
+extern C {
+
+PUBLIC bool
+opencl_dri_event_add_ref(cl_event event)
+{
+ return clRetainEvent(event) == CL_SUCCESS;
+}
+
Re: [Mesa-dev] [PATCH 01/18] winsys/radeon: move radeon_winsys.h up one directory
Can you elaborate on what amdgpu/sw would be good for? Frankly I don't see a point, therefore we don't need the drm subdirectory. Marek On Tue, Apr 21, 2015 at 4:40 PM, Emil Velikov emil.l.veli...@gmail.com wrote: On 20/04/15 22:23, Marek Olšák wrote: From: Marek Olšák marek.ol...@amd.com --- .../auxiliary/target-helpers/inline_drm_helper.h | 6 +- src/gallium/drivers/r300/r300_chipset.c| 2 +- src/gallium/drivers/r300/r300_context.h| 1 - src/gallium/drivers/r300/r300_screen.h | 2 +- src/gallium/drivers/radeon/r600_pipe_common.h | 2 +- src/gallium/drivers/radeon/radeon_uvd.c| 1 - src/gallium/drivers/radeon/radeon_uvd.h| 2 +- src/gallium/drivers/radeon/radeon_vce.c| 1 - src/gallium/drivers/radeon/radeon_vce_40_2_2.c | 1 - src/gallium/drivers/radeon/radeon_video.c | 1 - src/gallium/drivers/radeon/radeon_video.h | 2 +- src/gallium/drivers/radeonsi/si_pm4.h | 2 +- src/gallium/targets/pipe-loader/pipe_r300.c| 2 +- src/gallium/targets/pipe-loader/pipe_r600.c| 2 +- src/gallium/targets/pipe-loader/pipe_radeonsi.c| 2 +- src/gallium/winsys/radeon/drm/Makefile.sources | 2 +- src/gallium/winsys/radeon/drm/radeon_drm_winsys.h | 2 +- src/gallium/winsys/radeon/drm/radeon_winsys.h | 604 - src/gallium/winsys/radeon/radeon_winsys.h | 604 + 19 files changed, 618 insertions(+), 623 deletions(-) delete mode 100644 src/gallium/winsys/radeon/drm/radeon_winsys.h create mode 100644 src/gallium/winsys/radeon/radeon_winsys.h Another solution would be to move it in gallium/drivers/radeon. This one might be better (and more consistent with every other driver) as the file defines the interface that the driver(s) require, while there can be many different providers for it - radeon/drm, amdgpu/drm or even amdgpu/sw :-) You might need to change two/three lines in the makefiles though :-\ -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 14/20] i965/cs: Add max_cs_threads
On Sat, Apr 25, 2015 at 09:06:53PM -0700, Ben Widawsky wrote:
On Sat, Apr 25, 2015 at 05:39:20PM -0700, Jordan Justen wrote:
On 2015-04-25 13:54:41, Ben Widawsky wrote:
On Fri, Apr 24, 2015 at 04:33:06PM -0700, Jordan Justen wrote:
Add some values for gen7 gen8. These are the number threads in a
subslice.
I forget if I asked this in the v1, but shouldn't we be moving to the
awful^wrequired kernel interface which exposes this information? I think
for BSW
it's actually required.
http://lists.freedesktop.org/archives/intel-gfx/2014-July/049917.html
I guess I915_PARAM_SUBSLICE_TOTAL and I915_PARAM_EU_TOTAL will be in
Linux 4.1, but I think mesa should come up with conservative defaults
for this info and refine it with the kernel calls when they are
available.
What do you think?
Yeah, maybe. Since we know until BSW, things are pretty predictable, maybe
just
exclude that for now (IIRC, we can't even guess a conservative default
there)??
With the some thinking about whether to keep BSW in, on your part:
Reviewed-by: Ben Widawsky b...@bwidawsk.net
Regarding using the values, so threads per subslice would be
(I915_PARAM_EU_TOTAL / I915_PARAM_SUBSLICE_TOTAL) * threads_per_eu?
Since the kernel doesn't provide threads_per_eu, I guess we need to
have that in brw_device_info?
-Jordan
You're right. I think this is incomplete. Jeff, how about platforms which
might
have different number of EUs per subslice? Can such a thing exist? If it
cannot,
then what Jordan said seems correct to me.
At the moment, the only uneven distribution of EU across subslices occurs
in BDW and SKL which are permitted to have a single EU in any subslice fuse-
disabled. My understanding is that the hardware is tolerant to the loss of
just the one EU, so software doesn't need to account for it. So you should
be safe to use the 'nominal' EU per subslice count determined by rounding
up eu_total/subslice_total to nearest integer.
-Jeff
Thread counts all look right afaict though.
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
Cc: Ben Widawsky b...@bwidawsk.net
Cc: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_context.c | 1 +
src/mesa/drivers/dri/i965/brw_context.h | 1 +
src/mesa/drivers/dri/i965/brw_device_info.c | 12 +++-
src/mesa/drivers/dri/i965/brw_device_info.h | 1 +
4 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index 25b50c7..7f8d430 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -835,6 +835,7 @@ brwCreateContext(gl_api api,
brw-max_ds_threads = devinfo-max_ds_threads;
brw-max_gs_threads = devinfo-max_gs_threads;
brw-max_wm_threads = devinfo-max_wm_threads;
+ brw-max_cs_threads = devinfo-max_cs_threads;
brw-urb.size = devinfo-urb.size;
brw-urb.min_vs_entries = devinfo-urb.min_vs_entries;
brw-urb.max_vs_entries = devinfo-urb.max_vs_entries;
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index 07847cc..56827d8 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1228,6 +1228,7 @@ struct brw_context
int max_ds_threads;
int max_gs_threads;
int max_wm_threads;
+ int max_cs_threads;
/* BRW_NEW_URB_ALLOCATIONS:
*/
diff --git a/src/mesa/drivers/dri/i965/brw_device_info.c
b/src/mesa/drivers/dri/i965/brw_device_info.c
index 928bf99..7999ba9 100644
--- a/src/mesa/drivers/dri/i965/brw_device_info.c
+++ b/src/mesa/drivers/dri/i965/brw_device_info.c
@@ -117,6 +117,7 @@ static const struct brw_device_info
brw_device_info_ivb_gt1 = {
.max_ds_threads = 36,
.max_gs_threads = 36,
.max_wm_threads = 48,
+ .max_cs_threads = 36,
.urb = {
.size = 128,
.min_vs_entries = 32,
@@ -135,6 +136,7 @@ static const struct brw_device_info
brw_device_info_ivb_gt2 = {
.max_ds_threads = 128,
.max_gs_threads = 128,
.max_wm_threads = 172,
+ .max_cs_threads = 64, /* Maybe 96? */
.urb = {
.size = 256,
.min_vs_entries = 32,
@@ -154,6 +156,7 @@ static const struct brw_device_info
brw_device_info_byt = {
.max_ds_threads = 36,
.max_gs_threads = 36,
.max_wm_threads = 48,
+ .max_cs_threads = 32,
.urb = {
.size = 128,
.min_vs_entries = 32,
@@ -176,6 +179,7 @@ static const struct brw_device_info
brw_device_info_hsw_gt1 = {
.max_ds_threads = 70,
.max_gs_threads = 70,
.max_wm_threads = 102,
+ .max_cs_threads = 70,
.urb
Re: [Mesa-dev] [PATCH v2 10/20] i965/cs: Add generator support for CS_OPCODE_CS_TERMINATE
On Friday, April 24, 2015 04:33:02 PM Jordan Justen wrote:
v2:
* Don't rely on brw_eu* to generate the send instruction. We now
generate the send here, and drop the i965/cs: Add support for the
SEND message that terminates a CS thread brw_eu* patch.
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
src/mesa/drivers/dri/i965/brw_fs.h | 1 +
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 35
++
2 files changed, 36 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.h
b/src/mesa/drivers/dri/i965/brw_fs.h
index b1e65cd..8a71ac7 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.h
+++ b/src/mesa/drivers/dri/i965/brw_fs.h
@@ -556,6 +556,7 @@ private:
GLuint nr);
void generate_fb_write(fs_inst *inst, struct brw_reg payload);
void generate_urb_write(fs_inst *inst, struct brw_reg payload);
+ void generate_cs_terminate(fs_inst *inst, struct brw_reg payload);
void generate_blorp_fb_write(fs_inst *inst);
void generate_linterp(fs_inst *inst, struct brw_reg dst,
struct brw_reg *src);
diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
index b88dc8e..114f938 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
@@ -370,6 +370,37 @@ fs_generator::generate_urb_write(fs_inst *inst, struct
brw_reg payload)
}
void
+fs_generator::generate_cs_terminate(fs_inst *inst, struct brw_reg payload)
+{
+ struct brw_inst *insn;
+
+ insn = brw_next_insn(p, BRW_OPCODE_SEND);
+
+ brw_set_dest(p, insn, brw_null_reg());
+ brw_set_src0(p, insn, payload);
+ brw_set_src1(p, insn, brw_imm_d(0));
+
+ /* Terminate a compute shader by sending a message to the thread spawner.
+*/
+ brw_inst_set_sfid(devinfo, insn, BRW_SFID_THREAD_SPAWNER);
+ brw_inst_set_mlen(devinfo, insn, 1);
+ brw_inst_set_rlen(devinfo, insn, 0);
+ brw_inst_set_eot(devinfo, insn, inst-eot);
+ brw_inst_set_header_present(devinfo, insn, false);
+
+ brw_inst_set_ts_opcode(devinfo, insn, 0); /* Dereference resource */
+ brw_inst_set_ts_request_type(devinfo, insn, 0); /* Root thread */
+
+ /* Note that even though the thread has a URB resource associated with it,
+* we set the do not dereference URB bit, because the URB resource is
+* managed by the fixed-function unit, so it will free it automatically.
+*/
+ brw_inst_set_ts_resource_select(devinfo, insn, 1); /* Do not dereference
URB */
+
+ brw_inst_set_mask_control(devinfo, insn, BRW_MASK_DISABLE);
+}
+
+void
fs_generator::generate_blorp_fb_write(fs_inst *inst)
{
brw_fb_WRITE(p,
@@ -2073,6 +2104,10 @@ fs_generator::generate_code(const cfg_t *cfg, int
dispatch_width)
GEN7_PIXEL_INTERPOLATOR_LOC_PER_SLOT_OFFSET);
break;
+ case CS_OPCODE_CS_TERMINATE:
+ generate_cs_terminate(inst, src[0]);
+ break;
+
Weird whitespace here.
I don't know how the media pipeline works, particularly, so I'm just
assuming that root threads are correct, and your URB management choices
are correct. You've looked into it a lot so I trust you on that :)
I did verify that header present MBZ for all thread spawner messages,
and g0 is just considered to be the message payload. (It looked a bit
funky at first, but makes sense I guess...)
The code looks reasonable, so
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
default:
unreachable(Unsupported opcode);
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC 6/9] nir: Add an entirely C-based linked list implementation
On Mon, Apr 27, 2015 at 1:36 PM, Eric Anholt e...@anholt.net wrote: Jason Ekstrand ja...@jlekstrand.net writes: This commit adds a C-based linked list implementation for NIR. Unlike exec_list in glsl/list.h, there is no C++ API. Also, this list is based on wl_list (from the Wayland project) which is, in turn, based on the kernel list. As such, it should be fairly familiar to people who have done anything in kernel space. Doesn't exec_list already have a C api? Yes, it does. However, exec_list has C++ constructors for exec_list and exec_node. In the patches that follow, I use linked lists for use/def sets for registers and SSA values. In order to do so, I have to be able to place lists and links inside of unions. Since exec_list and exec_node have constructors, doing so causes any C++ code that includes nir.h to die in a fire. Therefore, we can't just use exec_list. What about simple_list? Why re-create it? I thought about that too. However, the simple_list is badly named and the API isn't that great. Making it usable as a first-class datastructure would have taken as much work as adding nir_list. Also, simple_list isn't really a standard as it's only ever used in errors.c and the vc4 driver. Why a kernel list; why not keep the symantics of exec_list? The short version: I like it better. Also, while exec_list is familiar to people who have worked inside the mesa GLSL compiler, I think that the kernel list will be more familiar to people in the open-source graphics community in general. For whatever it's worth, I explicitly designed it with separate nir_list and nir_link structures so that we can switch from kernel list to exec_list symantics if we want to. Why put this in NIR and not in util? At the moment, NIR is the only user. I do expect that Eric may want to use it in vc4 over simple_list. However, vc4 is already using NIR anyway, so it's not really that polluting. It has also been suggested by Ken that we just pull the C bits out of exec_list and keep one underlying implementation for both C and C++ only with different names. While I think that this is definitely doable and may be the best long-term solution, I didn't want to do that refactoring prior to getting this series up-and-going and adding a list was easier. I'm ok with doing that instead of adding a list. Yes, please! I have never liked exec_list, and being gratuitously different from the other projects that we work on (linux, X) is really frustrating. I'd like us to use the same actual names as the kernel does if possible, but I understand if for now we want to have namespaced names for the functions because we might need to interact with two different types of lists. FWIW, if we want to go through with this (which it seems like a pretty big performance win and it gives us a lot more determinism, so why not?) then the consensus is that we should take gallium's u_double_list.h and move it to src/util/list.h. We'd need to clean up a few things, like s/INLINE/inline/ and perhaps make the iterators not ALL_CAPS, and we'd need to add C99-style iterators for NIR, but otherwise it's basically the same as the kernel list. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: finish implementing ARB_texture_stencil8 (v5)
On Tue, Apr 21, 2015 at 6:59 PM, Dave Airlie airl...@gmail.com wrote:
Parts of this were implemented previously, so finish it off.
v2: fix getteximage falling into the integer check
add fixes for the FBO paths, (fbo-stencil8 test).
v3: fix getteximage path harder.
v4: remove swapbytes from getteximage path (Ilia)
v5: brown paper bag the swapbytes removal. (Ilia)
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/mesa/main/extensions.c | 1 +
src/mesa/main/fbobject.c| 9 +---
src/mesa/main/texgetimage.c | 50
-
src/mesa/main/teximage.c| 3 ++-
4 files changed, 58 insertions(+), 5 deletions(-)
diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index 861b150..3d4965c 100644
--- a/src/mesa/main/extensions.c
+++ b/src/mesa/main/extensions.c
@@ -186,6 +186,7 @@ static const struct extension extension_table[] = {
{ GL_ARB_texture_rectangle, o(NV_texture_rectangle),
GL, 2004 },
{ GL_ARB_texture_rgb10_a2ui,
o(ARB_texture_rgb10_a2ui), GL, 2009 },
{ GL_ARB_texture_rg, o(ARB_texture_rg),
GL, 2008 },
+ { GL_ARB_texture_stencil8,o(ARB_texture_stencil8),
GL, 2013 },
{ GL_ARB_texture_storage, o(dummy_true),
GL, 2011 },
{ GL_ARB_texture_storage_multisample,
o(ARB_texture_multisample), GL, 2012 },
{ GL_ARB_texture_view,o(ARB_texture_view),
GL, 2012 },
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 8032585..27cf97f 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -813,8 +813,10 @@ test_attachment_completeness(const struct gl_context
*ctx, GLenum format,
if (ctx-Extensions.ARB_depth_texture
baseFormat == GL_DEPTH_STENCIL) {
/* OK */
- }
- else {
+ } else if (ctx-Extensions.ARB_texture_stencil8
+baseFormat == GL_STENCIL_INDEX) {
+/* OK */
+ } else {
/* no such thing as stencil-only textures */
att_incomplete(illegal stencil texture);
att-Complete = GL_FALSE;
@@ -978,7 +980,8 @@ _mesa_test_framebuffer_completeness(struct gl_context
*ctx,
if (!is_format_color_renderable(ctx, attFormat,
texImg-InternalFormat)
- !is_legal_depth_format(ctx, f)) {
+ !is_legal_depth_format(ctx, f)
+ f != GL_STENCIL_INDEX) {
fb-_Status = GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT;
fbo_incomplete(ctx, texture attachment incomplete, -1);
return;
diff --git a/src/mesa/main/texgetimage.c b/src/mesa/main/texgetimage.c
index 255d365..e6d6471 100644
--- a/src/mesa/main/texgetimage.c
+++ b/src/mesa/main/texgetimage.c
@@ -175,6 +175,51 @@ get_tex_depth_stencil(struct gl_context *ctx, GLuint
dimensions,
}
}
+/**
+ * glGetTexImage for stencil pixels.
+ */
+static void
+get_tex_stencil(struct gl_context *ctx, GLuint dimensions,
+GLenum format, GLenum type, GLvoid *pixels,
+struct gl_texture_image *texImage)
+{
+ const GLint width = texImage-Width;
+ const GLint height = texImage-Height;
+ const GLint depth = texImage-Depth;
+ GLint img, row;
+
+ assert(format == GL_STENCIL_INDEX);
+
+ for (img = 0; img depth; img++) {
+ GLubyte *srcMap;
+ GLint rowstride;
+
+ /* map src texture buffer */
+ ctx-Driver.MapTextureImage(ctx, texImage, img,
+ 0, 0, width, height, GL_MAP_READ_BIT,
+ srcMap, rowstride);
+
+ if (srcMap) {
+ for (row = 0; row height; row++) {
+const GLubyte *src = srcMap + row * rowstride;
+void *dest = _mesa_image_address(dimensions, ctx-Pack, pixels,
+ width, height, format, type,
+ img, row, 0);
+_mesa_unpack_ubyte_stencil_row(texImage-TexFormat,
+ width,
+ (const GLuint *) src,
+ dest);
+ }
+
+ ctx-Driver.UnmapTextureImage(ctx, texImage, img);
+ }
+ else {
+ _mesa_error(ctx, GL_OUT_OF_MEMORY, glGetTexImage);
+ break;
+ }
+ }
+}
+
/**
* glGetTexImage for YCbCr pixels.
@@ -684,6 +729,9 @@ _mesa_GetTexImage_sw(struct gl_context *ctx,
else if (format == GL_DEPTH_STENCIL_EXT) {
Re: [Mesa-dev] [PATCH 09/10] gallium, clover: add OpenCL interoperability support for CL events
Marek Olšák mar...@gmail.com writes: From: Marek Olšák marek.ol...@amd.com v2: - move interop.cpp to clover/api - change intptr_t to void* in the interface - add a virtual function fence() to simplify some code v3: - use bool in the interface v4: - enclose the last two interop functions in try..catch Looks good, thanks, Reviewed-by: Francisco Jerez curroje...@riseup.net --- src/gallium/include/state_tracker/opencl_interop.h | 40 ++ src/gallium/state_trackers/clover/Makefile.sources | 1 + src/gallium/state_trackers/clover/api/interop.cpp | 64 ++ src/gallium/state_trackers/clover/core/event.hpp | 8 +++ src/gallium/targets/opencl/opencl.sym | 1 + 5 files changed, 114 insertions(+) create mode 100644 src/gallium/include/state_tracker/opencl_interop.h create mode 100644 src/gallium/state_trackers/clover/api/interop.cpp diff --git a/src/gallium/include/state_tracker/opencl_interop.h b/src/gallium/include/state_tracker/opencl_interop.h new file mode 100644 index 000..4983644 --- /dev/null +++ b/src/gallium/include/state_tracker/opencl_interop.h @@ -0,0 +1,40 @@ +/** + * + * Copyright 2015 Advanced Micro Devices, Inc. + * All Rights Reserved. + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the + * Software), to deal in the Software without restriction, including + * without limitation the rights to use, copy, modify, merge, publish, + * distribute, sub license, and/or sell copies of the Software, and to + * permit persons to whom the Software is furnished to do so, subject to + * the following conditions: + * + * The above copyright notice and this permission notice (including the + * next paragraph) shall be included in all copies or substantial portions + * of the Software. + * + * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS + * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. + * IN NO EVENT SHALL THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR + * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, + * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE + * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. + * + **/ + +#ifndef OPENCL_INTEROP_H +#define OPENCL_INTEROP_H + +/* dlsym these without the _t suffix. You should get the correct symbols + * if the OpenCL driver is loaded. + */ + +typedef bool (*opencl_dri_event_add_ref_t)(void *cl_event); +typedef bool (*opencl_dri_event_release_t)(void *cl_event); +typedef bool (*opencl_dri_event_wait_t)(void *cl_event, uint64_t timeout); +typedef struct pipe_fence_handle *(*opencl_dri_event_get_fence_t)(void *cl_event); + +#endif /* OPENCL_INTEROP_H */ diff --git a/src/gallium/state_trackers/clover/Makefile.sources b/src/gallium/state_trackers/clover/Makefile.sources index 5b3344c..9e30c69 100644 --- a/src/gallium/state_trackers/clover/Makefile.sources +++ b/src/gallium/state_trackers/clover/Makefile.sources @@ -4,6 +4,7 @@ CPP_SOURCES := \ api/dispatch.cpp \ api/dispatch.hpp \ api/event.cpp \ + api/interop.cpp \ api/kernel.cpp \ api/memory.cpp \ api/platform.cpp \ diff --git a/src/gallium/state_trackers/clover/api/interop.cpp b/src/gallium/state_trackers/clover/api/interop.cpp new file mode 100644 index 000..ea0c7c7 --- /dev/null +++ b/src/gallium/state_trackers/clover/api/interop.cpp @@ -0,0 +1,64 @@ +// +// Copyright 2015 Advanced Micro Devices, Inc. +// All Rights Reserved. +// +// Permission is hereby granted, free of charge, to any person obtaining a +// copy of this software and associated documentation files (the Software), +// to deal in the Software without restriction, including without limitation +// the rights to use, copy, modify, merge, publish, distribute, sublicense, +// and/or sell copies of the Software, and to permit persons to whom the +// Software is furnished to do so, subject to the following conditions: +// +// The above copyright notice and this permission notice shall be included in +// all copies or substantial portions of the Software. +// +// THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +// IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +// FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL +// THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR +// OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, +// ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR +// OTHER DEALINGS IN THE SOFTWARE. +// +
[Mesa-dev] [PATCH v2] mesa: fix up GLSL version when computing GL version
In some situations it is convenient for a driver to expose a higher GLSL
version while some extensions are still incomplete. However in that
situation, it would report a GLSL version that was higher than the GL
version. Avoid that situation by limiting the GLSL version to the GL
version.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
v1 - v2:
do work in _mesa_compute_version, not in compute_version
only fix up core profile (easier and this situation doesn't come up for
compat)
src/mesa/main/version.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index da255b2..6024dc8 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/version.c
@@ -483,6 +483,17 @@ _mesa_compute_version(struct gl_context *ctx)
ctx-Version = _mesa_get_version(ctx-Extensions, ctx-Const, ctx-API);
+ /* Make sure that the GLSL version lines up with the GL version. In some
+* cases it can be too high, e.g. if an extension is missing.
+*/
+ if (ctx-API == API_OPENGL_CORE) {
+ switch (ctx-Version) {
+ case 31: ctx-Const.GLSLVersion = 140; break;
+ case 32: ctx-Const.GLSLVersion = 150; break;
+ default: ctx-Const.GLSLVersion = ctx-Version * 10; break;
+ }
+ }
+
switch (ctx-API) {
case API_OPENGL_COMPAT:
case API_OPENGL_CORE:
--
2.0.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
