Re: [Mesa-dev] [PATCH v2 13/15] glsl linker: support arrays of interface block instances
On Sat, Mar 23, 2013 at 01:48:44PM -0700, Kenneth Graunke wrote: On 03/19/2013 03:57 AM, Pohjolainen, Topi wrote: On Mon, Mar 18, 2013 at 04:35:10PM -0700, Jordan Justen wrote: With this change we now support interface block arrays. For example, cases like this: out block_name { float f; } block_instance[2]; This allows Mesa to pass the piglit glsl-1.50 test: * execution/interface-blocks-complex-vs-fs.shader_test Signed-off-by: Jordan Justen jordan.l.jus...@intel.com --- src/glsl/lower_named_interface_blocks.cpp | 53 - 1 file changed, 44 insertions(+), 9 deletions(-) diff --git a/src/glsl/lower_named_interface_blocks.cpp b/src/glsl/lower_named_interface_blocks.cpp index 2e0c322..405e7a9 100644 --- a/src/glsl/lower_named_interface_blocks.cpp +++ b/src/glsl/lower_named_interface_blocks.cpp @@ -107,22 +107,47 @@ flatten_named_interface_blocks_declarations::run(exec_list *instructions) if (var-mode == ir_var_uniform) continue; - const glsl_type *const t = var-type; + const glsl_type * iface_t = var-type; + const glsl_type * array_t = NULL; exec_node *insert_pos = var; - char *iface_field_name; - for (unsigned i = 0; i t-length; i++) { -iface_field_name = ralloc_asprintf(mem_ctx, %s.%s, t-name, - t-fields.structure[i].name); + + if (iface_t-is_array()) { +array_t = iface_t; +iface_t = array_t-fields.array; + } + + assert (iface_t-is_interface()); + + for (unsigned i = 0; i iface_t-length; i++) { +const char * field_name = iface_t-fields.structure[i].name; +char *iface_field_name = + ralloc_asprintf(mem_ctx, %s.%s, + iface_t-name, field_name); ir_variable *found_var = (ir_variable *) hash_table_find(interface_namespace, iface_field_name); if (!found_var) { ir_variable *new_var = - new(mem_ctx) ir_variable(t-fields.structure[i].type, - ralloc_strdup(mem_ctx, t-fields.structure[i].name), + new(mem_ctx) ir_variable(iface_t-fields.structure[i].type, + ralloc_strdup(mem_ctx, iface_t-fields.structure[i].name), (ir_variable_mode) var-mode); - new_var-interface_type = t; + if (array_t != NULL) { + const glsl_type *new_array_type = + glsl_type::get_array_instance( +iface_t-fields.structure[i].type, +array_t-length); + char *array_var_name = + ralloc_asprintf(mem_ctx, %s[%d], + new_var-name, array_t-length); + ir_variable *new_array_var = + new(mem_ctx) ir_variable(new_array_type, + array_var_name, + (ir_variable_mode) var-mode); + new_var = new_array_var; Don't you leak the previously allocated instance of 'ir_variable' (assigned to 'new_var')? Or is it just left until 'mem_ctx' gets released? I'm not that familiar with the glsl core that I may well be missing something. This is actually fairly common in the GLSL code - we routinely just drop allocated memory on the floor. But, it all works out thanks to the magic of talloc/ralloc(*). With talloc, you allocate memory out af a 'context'. Freeing a context frees any memory associated with it, which means you can free a whole bunch of things without tracking them all down and calling free() on each individual pointer. It also means you don't need to explicitly keep pointers to each object, as the memory context does that for you. Any talloced piece of memory is also a new context, which allows you to create a tree-like structure (the 't' in talloc is for 'tree', and the 'r' in ralloc is for 'recursive'). In the GLSL compiler, we allocate IR out of either the parser state or the gl_shader object (I forget which). During optimization, linking, and so on, we create new IR, and remove other IR, all without worrying about memory. Then, when we're done compiling/linking, we walk through the remaining IR tree, calling talloc_steal() on each remaining IR node to reparent the memory to a second memory context. Then we free the original memory context, which now contains only the junk we don't need anymore. (*) ralloc is my poor man's reimplementation of talloc, licensed under the MIT license rather than LGPLv3. It also has a slightly different API and
[Mesa-dev] [PATCH] mesa: only check sample count if we actually wanted multisampling
Fixes various test fallout from 90b5a2425a on Pineview, which claims to support ARB_internalformat_query but doesn't actually provide the driverfunc. That driver is still broken [GetInternalformativ will still segfault!] but it was silly to be going through the sample count logic in the nonmultisampling case at all. Signed-off-by: Chris Forbes chr...@ijw.co.nz --- src/mesa/main/fbobject.c | 19 ++- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c index 3fdf626..c1f5299 100644 --- a/src/mesa/main/fbobject.c +++ b/src/mesa/main/fbobject.c @@ -1537,15 +1537,16 @@ renderbuffer_storage(GLenum target, GLenum internalFormat, /* NumSamples == 0 indicates non-multisampling */ samples = 0; } - - /* check the sample count; -* note: driver may choose to use more samples than what's requested -*/ - sample_count_error = _mesa_check_sample_count(ctx, target, - internalFormat, samples); - if (sample_count_error != GL_NO_ERROR) { - _mesa_error(ctx, sample_count_error, %s(samples), func); - return; + else { + /* check the sample count; + * note: driver may choose to use more samples than what's requested + */ + sample_count_error = _mesa_check_sample_count(ctx, target, +internalFormat, samples); + if (sample_count_error != GL_NO_ERROR) { + _mesa_error(ctx, sample_count_error, %s(samples), func); + return; + } } rb = ctx-CurrentRenderbuffer; -- 1.8.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] glxgears is faster but 3D render is so slow
Hi Brian, On 3/22/13, Brian Paul bri...@vmware.com wrote: On 03/21/2013 03:51 AM, jupiter wrote: Hi Brian, On 3/21/13, Brian Paulbri...@vmware.com wrote: On 03/20/2013 04:07 AM, jupiter wrote: Hi Brian, On 3/19/13, Brian Paulbri...@vmware.com wrote: It is fair to say, if running llvm driver in my local machine (a 32-bit CentOS 6.2 without VNC connection), it was indeed faster than the xlib driver. Seems to me that the llvm driver broken the xlib VNC connection which could be caused by either I haven't configure the llvm correctly, or mesa llvm compile process may have bugs. I don't understand what you mean by llvm driver broken the xlib VNC connection. I have tested llvm driver in two platforms: (1) A local computer running on CentOS 6.2 which does not have hardware acceleration, but I can directly access it. The llvm driver is indeed much faster than the swrast, I could run an application with 3D structure rotation. (2) A virtual machine running on CentOS 6.2, I have to access it via VNC. I was not able to run the 3D application, the graphic jerky and could not respond. If I changed to run swrast, the 3D application graphic could be run much smoothly and response was normal, but the 3D rotation was stopped because it was too slower to rotate the 3D structure. That was what I mean the llvm broken the xlib VNC connection. Have you tested the llvm driver in VNC connection? No, I haven't. I'm really not sure what's happening in this situation. My only totally wild guess is there's competition between the VNC server and Mesa for CPU time. The llvmpipe driver is threaded and creates as many threads as there are CPU cores. You can set the LP_NUM_THREADS to tell llvmpipe how many threads to use (0 for no threading). How many CPU cores do you have? The virtual machine I tested has only one CPU, but we can make it more cups if it helps. I'll try to set up LP_NUM_THREADS tomorrow, but I don't expect it caused the problem. One thing I have to address is that xlib swrast is running very well in VNC connection despite it is too slower to do 3D structure rotation. May be you can look at the difference between the xlib LLVM driver and xlib swrast driver. The drivers are totally different, but underneath both they render into shared X images which are then copied to the on-screen window during glXSwapBuffers. That code is pretty much the same. I don't know what else would account for the difference you're seeing. I'll be happy to help testing or debugging llvm driver on VNC connection if you are going to resolve the issues seriously and if you can tell me the procedure and data collection you need. I'm just way too busy right now to dig into this. Hopefully you can make some progress playing with virtual CPUs and LP_NUM_THREADS. I guess to define LP_NUM_THREADS as an environment variable, correct? I've tried to define LP_NUM_THREADS=10, but does not work. I'll try it again it I was wrong. Otherwise, let me know if I can help for testing on the virtual machine when you are available to try the debug. Kind regards, Jupiter -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] glsl_to_tgsi: avoid creating arrays if driver doesn't support them
From: Christian König christian.koe...@amd.com Avoid creating arrays if we replace indirect addressing anyway. Signed-off-by: Christian König christian.koe...@amd.com --- src/mesa/state_tracker/st_glsl_to_tgsi.cpp |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp index 0885564..e728f79 100644 --- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp +++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp @@ -1009,7 +1009,9 @@ glsl_to_tgsi_visitor::get_temp(const glsl_type *type) src.reladdr = NULL; src.negate = 0; - if (type-is_array() || type-is_matrix()) { + if (!options-EmitNoIndirectTemp + (type-is_array() || type-is_matrix())) { + src.file = PROGRAM_ARRAY; src.index = next_array 16 | 0x8000; array_sizes[next_array] = type_size(type); -- 1.7.9.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] glsl_to_tgsi: make simplify_cmp work with arrays
From: Christian König christian.koe...@amd.com Even when we have arrays it is possible for simplify_cmp to work on temps, just not on arrays. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=62696 Signed-off-by: Christian König christian.koe...@amd.com --- src/mesa/state_tracker/st_glsl_to_tgsi.cpp |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp index e3718ee..0885564 100644 --- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp +++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp @@ -3191,7 +3191,7 @@ glsl_to_tgsi_visitor::simplify_cmp(void) prevWriteMask = tempWrites[inst-dst.index]; tempWrites[inst-dst.index] |= inst-dst.writemask; } else - break; + continue; /* For a CMP to be considered a conditional write, the destination * register and source register two must be the same. */ -- 1.7.9.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 54557] Segfault calling eglWaitClient on EGL X11 platform with software rendering
https://bugs.freedesktop.org/show_bug.cgi?id=54557 Kalyan kondapallykal...@gmail.com changed: What|Removed |Added CC||kondapallykal...@gmail.com -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] glxgears is faster but 3D render is so slow
On 03/25/2013 04:59 AM, jupiter wrote: Hi Brian, On 3/22/13, Brian Paulbri...@vmware.com wrote: On 03/21/2013 03:51 AM, jupiter wrote: Hi Brian, On 3/21/13, Brian Paulbri...@vmware.com wrote: On 03/20/2013 04:07 AM, jupiter wrote: Hi Brian, On 3/19/13, Brian Paulbri...@vmware.comwrote: It is fair to say, if running llvm driver in my local machine (a 32-bit CentOS 6.2 without VNC connection), it was indeed faster than the xlib driver. Seems to me that the llvm driver broken the xlib VNC connection which could be caused by either I haven't configure the llvm correctly, or mesa llvm compile process may have bugs. I don't understand what you mean by llvm driver broken the xlib VNC connection. I have tested llvm driver in two platforms: (1) A local computer running on CentOS 6.2 which does not have hardware acceleration, but I can directly access it. The llvm driver is indeed much faster than the swrast, I could run an application with 3D structure rotation. (2) A virtual machine running on CentOS 6.2, I have to access it via VNC. I was not able to run the 3D application, the graphic jerky and could not respond. If I changed to run swrast, the 3D application graphic could be run much smoothly and response was normal, but the 3D rotation was stopped because it was too slower to rotate the 3D structure. That was what I mean the llvm broken the xlib VNC connection. Have you tested the llvm driver in VNC connection? No, I haven't. I'm really not sure what's happening in this situation. My only totally wild guess is there's competition between the VNC server and Mesa for CPU time. The llvmpipe driver is threaded and creates as many threads as there are CPU cores. You can set the LP_NUM_THREADS to tell llvmpipe how many threads to use (0 for no threading). How many CPU cores do you have? The virtual machine I tested has only one CPU, but we can make it more cups if it helps. I'll try to set up LP_NUM_THREADS tomorrow, but I don't expect it caused the problem. One thing I have to address is that xlib swrast is running very well in VNC connection despite it is too slower to do 3D structure rotation. May be you can look at the difference between the xlib LLVM driver and xlib swrast driver. The drivers are totally different, but underneath both they render into shared X images which are then copied to the on-screen window during glXSwapBuffers. That code is pretty much the same. I don't know what else would account for the difference you're seeing. I'll be happy to help testing or debugging llvm driver on VNC connection if you are going to resolve the issues seriously and if you can tell me the procedure and data collection you need. I'm just way too busy right now to dig into this. Hopefully you can make some progress playing with virtual CPUs and LP_NUM_THREADS. I guess to define LP_NUM_THREADS as an environment variable, correct? Yes. I've tried to define LP_NUM_THREADS=10, but does not work. The limit is currently 8. If your VM only has one CPU core, then llvmpipe will automatically set num_threads = 1 and increasing it with LP_NUM_THREADS won't accomplish much. I'll try it again it I was wrong. Otherwise, let me know if I can help for testing on the virtual machine when you are available to try the debug. Can you try increasing the number of cores in your VM? But like I said above, that's just a wild guess for something to try. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/5] Head-up display for Gallium DRI2 drivers
On 03/22/2013 05:50 PM, Marek Olšák wrote: Hi everyone, one image is better than a thousand words: http://people.freedesktop.org/~mareko/gallium-hud.png So there you have it. This gallium module can draw transparent graphs and text on top of what apps are rendering. By default, it can show framerate, cpu load (each CPU or the average of all of them), and the results of PRIMITIVES_GENERATED and OCCLUSION_COUNTER queries (the latter is printed as pixels rendered). Furthermore, there is a new interface for gallium allowing drivers to expose driver-specific queries in a way similar to GL_AMD_performance_monitor. It uses the existing pipe_query interface. Drivers can use this to expose performance counters or other internal information. BTW, I guess I should mention that I ripped the font off from freeglut. The HUD is controlled by the GALLIUM_HUD environment variable, where you can list names of data sources. Set GALLIUM_HUD=help for more info, it also prints all available names (including the driver-specific queries). This is what I used for the image above: GALLIUM_HUD=cpu0+cpu1+cpu2+cpu3:100,cpu:100,fps;draw-calls,requested-VRAM+requested-GTT,pixels-rendered So basically I'd like to be able to display as much useful info in the HUD as possible. We should definitely add some ioctls for querying useful stats from the kernel DRM/TTM and be able to see in real time what happens in Mesa and the kernel. It's pretty easy - just expose a new query through the gallium interface and the HUD will automatically pick it up. (for moderators: the second patch might get stuck in the moderation queue) This looks really great, Marek! Could you update the gallium docs with your interface additions? Could you also create a Mesa/docs/ page which describes how this works and how to use it? I can't wait to try this with llvmpipe and the svga driver. I'll try to review your patches ASAP... -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/5] Head-up display for Gallium DRI2 drivers
On 03/25/2013 08:45 AM, Brian Paul wrote: On 03/22/2013 05:50 PM, Marek Olšák wrote: Hi everyone, one image is better than a thousand words: http://people.freedesktop.org/~mareko/gallium-hud.png So there you have it. This gallium module can draw transparent graphs and text on top of what apps are rendering. By default, it can show framerate, cpu load (each CPU or the average of all of them), and the results of PRIMITIVES_GENERATED and OCCLUSION_COUNTER queries (the latter is printed as pixels rendered). Furthermore, there is a new interface for gallium allowing drivers to expose driver-specific queries in a way similar to GL_AMD_performance_monitor. It uses the existing pipe_query interface. Drivers can use this to expose performance counters or other internal information. BTW, I guess I should mention that I ripped the font off from freeglut. The HUD is controlled by the GALLIUM_HUD environment variable, where you can list names of data sources. Set GALLIUM_HUD=help for more info, it also prints all available names (including the driver-specific queries). This is what I used for the image above: GALLIUM_HUD=cpu0+cpu1+cpu2+cpu3:100,cpu:100,fps;draw-calls,requested-VRAM+requested-GTT,pixels-rendered So basically I'd like to be able to display as much useful info in the HUD as possible. We should definitely add some ioctls for querying useful stats from the kernel DRM/TTM and be able to see in real time what happens in Mesa and the kernel. It's pretty easy - just expose a new query through the gallium interface and the HUD will automatically pick it up. (for moderators: the second patch might get stuck in the moderation queue) This looks really great, Marek! Could you update the gallium docs with your interface additions? Could you also create a Mesa/docs/ page which describes how this works and how to use it? I can't wait to try this with llvmpipe and the svga driver. I'll try to review your patches ASAP... OK, I did a quick pass through the series and it looks good to me. Reviewed-by: Brian Paul bri...@vmware.com After you check this in I'll hook the HUD into the st/xlib code for llvmpipe... -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965/gen7: Use WE_all mode when enabling channel masks for URB write.
Paul Berry stereotype...@gmail.com writes: Gen7 adds mask bits to the message header for a URB write which allow the write to apply only to certain channels. We don't use this functionality, so to ensure that the entire write always occurs, we emit an OR instruction to set the mask bits. With the advent of geometry shaders, URB writes won't just happen at the end of a thread; they will happen in mid-thread too. Thus, we can no longer rely on channel 0 being enabled, so we need to emit the OR instruction in WE_all mode to ensure that it is executed. Reviewed-by: Eric Anholt e...@anholt.net pgpp7DcwcHBB_.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radeonsi: add cs tracing
From: Jerome Glisse jgli...@redhat.com Same as on r600, trace cs execution by writting cs offset after each states, this allow to pin point lockup inside command stream and narrow down the scope of lockup investigation. Signed-off-by: Jerome Glisse jgli...@redhat.com --- src/gallium/drivers/radeonsi/r600_hw_context.c | 58 ++ src/gallium/drivers/radeonsi/r600_texture.c| 2 +- src/gallium/drivers/radeonsi/radeonsi_pipe.c | 22 ++ src/gallium/drivers/radeonsi/radeonsi_pipe.h | 12 ++ src/gallium/drivers/radeonsi/radeonsi_pm4.c| 12 ++ src/gallium/drivers/radeonsi/si_state_draw.c | 7 +++- 6 files changed, 111 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/radeonsi/r600_hw_context.c b/src/gallium/drivers/radeonsi/r600_hw_context.c index bd348f9..3cd5d0e 100644 --- a/src/gallium/drivers/radeonsi/r600_hw_context.c +++ b/src/gallium/drivers/radeonsi/r600_hw_context.c @@ -142,6 +142,12 @@ void si_need_cs_space(struct r600_context *ctx, unsigned num_dw, /* Save 16 dwords for the fence mechanism. */ num_dw += 16; +#if R600_TRACE_CS + if (ctx-screen-trace_bo) { + num_dw += R600_TRACE_CS_DWORDS; + } +#endif + /* Flush if there's not enough space. */ if (num_dw RADEON_MAX_CMDBUF_DWORDS) { radeonsi_flush(ctx-context, NULL, RADEON_FLUSH_ASYNC); @@ -206,9 +212,41 @@ void si_context_flush(struct r600_context *ctx, unsigned flags) /* force to keep tiling flags */ flags |= RADEON_FLUSH_KEEP_TILING_FLAGS; +#if R600_TRACE_CS + if (ctx-screen-trace_bo) { + struct r600_screen *rscreen = ctx-screen; + unsigned i; + + for (i = 0; i cs-cdw; i++) { + fprintf(stderr, [%4d] [%5d] 0x%08x\n, rscreen-cs_count, i, cs-buf[i]); + } + rscreen-cs_count++; + } +#endif + /* Flush the CS. */ ctx-ws-cs_flush(ctx-cs, flags); +#if R600_TRACE_CS + if (ctx-screen-trace_bo) { + struct r600_screen *rscreen = ctx-screen; + unsigned i; + + for (i = 0; i 10; i++) { + usleep(5); + if (!ctx-ws-buffer_is_busy(rscreen-trace_bo-buf, RADEON_USAGE_READWRITE)) { + break; + } + } + if (i == 10) { + fprintf(stderr, timeout on cs lockup likely happen at cs %d dw %d\n, + rscreen-trace_ptr[1], rscreen-trace_ptr[0]); + } else { + fprintf(stderr, cs %d executed in %dms\n, rscreen-trace_ptr[1], i * 5); + } + } +#endif + ctx-pm4_dirty_cdwords = 0; ctx-flags = 0; @@ -665,3 +703,23 @@ void r600_context_draw_opaque_count(struct r600_context *ctx, struct r600_so_tar cs-buf[cs-cdw++] = r600_context_bo_reloc(ctx, t-filled_size, RADEON_USAGE_READ); } + +#if R600_TRACE_CS +void r600_trace_emit(struct r600_context *rctx) +{ + struct r600_screen *rscreen = rctx-screen; + struct radeon_winsys_cs *cs = rctx-cs; + uint64_t va; + uint32_t reloc; + + va = r600_resource_va(rscreen-screen, (void*)rscreen-trace_bo); + reloc = r600_context_bo_reloc(rctx, rscreen-trace_bo, RADEON_USAGE_READWRITE); + cs-buf[cs-cdw++] = PKT3(PKT3_MEM_WRITE, 3, 0); + cs-buf[cs-cdw++] = va 0xUL; + cs-buf[cs-cdw++] = (va 32UL) 0xFFUL; + cs-buf[cs-cdw++] = cs-cdw; + cs-buf[cs-cdw++] = rscreen-cs_count; + cs-buf[cs-cdw++] = PKT3(PKT3_NOP, 0, 0); + cs-buf[cs-cdw++] = reloc; +} +#endif diff --git a/src/gallium/drivers/radeonsi/r600_texture.c b/src/gallium/drivers/radeonsi/r600_texture.c index 6cafc3d..3d074a3 100644 --- a/src/gallium/drivers/radeonsi/r600_texture.c +++ b/src/gallium/drivers/radeonsi/r600_texture.c @@ -550,7 +550,7 @@ struct pipe_resource *si_texture_create(struct pipe_screen *screen, if (!(templ-flags R600_RESOURCE_FLAG_TRANSFER) !(templ-bind PIPE_BIND_SCANOUT)) { - array_mode = V_009910_ARRAY_2D_TILED_THIN1; + array_mode = V_009910_ARRAY_1D_TILED_THIN1; } r = r600_init_surface(rscreen, surface, templ, array_mode, diff --git a/src/gallium/drivers/radeonsi/radeonsi_pipe.c b/src/gallium/drivers/radeonsi/radeonsi_pipe.c index c5dac29..a370d7e 100644 --- a/src/gallium/drivers/radeonsi/radeonsi_pipe.c +++ b/src/gallium/drivers/radeonsi/radeonsi_pipe.c @@ -525,6 +525,14 @@ static void r600_destroy_screen(struct pipe_screen* pscreen) rscreen-ws-buffer_unmap(rscreen-fences.bo-cs_buf); si_resource_reference(rscreen-fences.bo, NULL); } + +#if R600_TRACE_CS + if (rscreen-trace_bo) { + rscreen-ws-buffer_unmap(rscreen-trace_bo-cs_buf); + pipe_resource_reference((struct
Re: [Mesa-dev] [PATCH] radeonsi: add cs tracing
On Mon, 2013-03-25 at 12:01 -0400, j.gli...@gmail.com wrote: From: Jerome Glisse jgli...@redhat.com Same as on r600, trace cs execution by writting cs offset after each states, this allow to pin point lockup inside command stream and narrow down the scope of lockup investigation. Signed-off-by: Jerome Glisse jgli...@redhat.com [...] diff --git a/src/gallium/drivers/radeonsi/r600_texture.c b/src/gallium/drivers/radeonsi/r600_texture.c index 6cafc3d..3d074a3 100644 --- a/src/gallium/drivers/radeonsi/r600_texture.c +++ b/src/gallium/drivers/radeonsi/r600_texture.c @@ -550,7 +550,7 @@ struct pipe_resource *si_texture_create(struct pipe_screen *screen, if (!(templ-flags R600_RESOURCE_FLAG_TRANSFER) !(templ-bind PIPE_BIND_SCANOUT)) { - array_mode = V_009910_ARRAY_2D_TILED_THIN1; + array_mode = V_009910_ARRAY_1D_TILED_THIN1; } r = r600_init_surface(rscreen, surface, templ, array_mode, What's this hunk doing in here? :) The rest looks good to me on a quick look. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] swrast: init vars to silence warnings
--- src/mesa/swrast/s_blit.c |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/mesa/swrast/s_blit.c b/src/mesa/swrast/s_blit.c index 82fa43f..051354d 100644 --- a/src/mesa/swrast/s_blit.c +++ b/src/mesa/swrast/s_blit.c @@ -110,8 +110,8 @@ blit_nearest(struct gl_context *ctx, GLint dstX0, GLint dstY0, GLint dstX1, GLint dstY1, GLbitfield buffer) { - struct gl_renderbuffer *readRb, *drawRb; - struct gl_renderbuffer_attachment *readAtt, *drawAtt; + struct gl_renderbuffer *readRb, *drawRb = NULL; + struct gl_renderbuffer_attachment *readAtt = NULL, *drawAtt = NULL; struct gl_framebuffer *readFb = ctx-ReadBuffer; struct gl_framebuffer *drawFb = ctx-DrawBuffer; GLuint numDrawBuffers = 0; @@ -135,12 +135,12 @@ blit_nearest(struct gl_context *ctx, UNPACK_Z_FLOAT, UNPACK_Z_INT, UNPACK_S, - } mode; + } mode = DIRECT; GLubyte *srcMap, *dstMap; GLint srcRowStride, dstRowStride; GLint dstRow; - GLint pixelSize; + GLint pixelSize = 0; GLvoid *srcBuffer, *dstBuffer; GLint prevY = -1; -- 1.7.3.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] gallivm: init vars to silence warnings
--- src/gallium/drivers/llvmpipe/lp_state_fs.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/llvmpipe/lp_state_fs.c b/src/gallium/drivers/llvmpipe/lp_state_fs.c index b87e1a4..de51f39 100644 --- a/src/gallium/drivers/llvmpipe/lp_state_fs.c +++ b/src/gallium/drivers/llvmpipe/lp_state_fs.c @@ -1219,7 +1219,7 @@ convert_to_blend_type(struct gallivm_state *gallivm, for (i = 0; i num_srcs; ++i) { LLVMValueRef chans[4]; - LLVMValueRef res; + LLVMValueRef res = NULL; unsigned sa = 0; dst[i] = LLVMBuildZExt(builder, src[i], lp_build_vec_type(gallivm, src_type), ); @@ -1368,7 +1368,7 @@ convert_from_blend_type(struct gallivm_state *gallivm, for (i = 0; i num_srcs; ++i) { LLVMValueRef chans[4]; - LLVMValueRef res; + LLVMValueRef res = NULL; unsigned sa = 0; dst[i] = LLVMBuildBitCast(builder, src[i], lp_build_vec_type(gallivm, src_type), ); -- 1.7.3.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] gallium: undef PACKAGE_* macros to silence warnings
--- src/gallium/auxiliary/gallivm/lp_bld_misc.cpp |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp index 6a560df..46cdbad 100644 --- a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp +++ b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp @@ -40,6 +40,14 @@ #define __STDC_CONSTANT_MACROS #endif +// Undef these vars just to silence warnings +#undef PACKAGE_BUGREPORT +#undef PACKAGE_NAME +#undef PACKAGE_STRING +#undef PACKAGE_TARNAME +#undef PACKAGE_VERSION + + #include stddef.h #include llvm-c/Core.h -- 1.7.3.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radeonsi: add cs tracing
On Mon, Mar 25, 2013 at 12:17 PM, Michel Dänzer mic...@daenzer.net wrote: On Mon, 2013-03-25 at 12:01 -0400, j.gli...@gmail.com wrote: From: Jerome Glisse jgli...@redhat.com Same as on r600, trace cs execution by writting cs offset after each states, this allow to pin point lockup inside command stream and narrow down the scope of lockup investigation. Signed-off-by: Jerome Glisse jgli...@redhat.com [...] diff --git a/src/gallium/drivers/radeonsi/r600_texture.c b/src/gallium/drivers/radeonsi/r600_texture.c index 6cafc3d..3d074a3 100644 --- a/src/gallium/drivers/radeonsi/r600_texture.c +++ b/src/gallium/drivers/radeonsi/r600_texture.c @@ -550,7 +550,7 @@ struct pipe_resource *si_texture_create(struct pipe_screen *screen, if (!(templ-flags R600_RESOURCE_FLAG_TRANSFER) !(templ-bind PIPE_BIND_SCANOUT)) { - array_mode = V_009910_ARRAY_2D_TILED_THIN1; + array_mode = V_009910_ARRAY_1D_TILED_THIN1; } r = r600_init_surface(rscreen, surface, templ, array_mode, What's this hunk doing in here? :) The rest looks good to me on a quick look. Oops i did it on top of my 2d tiling stuff Cheers, Jerome ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radeonsi: add cs tracing
On Mon, Mar 25, 2013 at 12:01 PM, j.gli...@gmail.com wrote: From: Jerome Glisse jgli...@redhat.com Same as on r600, trace cs execution by writting cs offset after each states, this allow to pin point lockup inside command stream and narrow down the scope of lockup investigation. Signed-off-by: Jerome Glisse jgli...@redhat.com --- src/gallium/drivers/radeonsi/r600_hw_context.c | 58 ++ src/gallium/drivers/radeonsi/r600_texture.c| 2 +- src/gallium/drivers/radeonsi/radeonsi_pipe.c | 22 ++ src/gallium/drivers/radeonsi/radeonsi_pipe.h | 12 ++ src/gallium/drivers/radeonsi/radeonsi_pm4.c| 12 ++ src/gallium/drivers/radeonsi/si_state_draw.c | 7 +++- 6 files changed, 111 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/radeonsi/r600_hw_context.c b/src/gallium/drivers/radeonsi/r600_hw_context.c index bd348f9..3cd5d0e 100644 --- a/src/gallium/drivers/radeonsi/r600_hw_context.c +++ b/src/gallium/drivers/radeonsi/r600_hw_context.c @@ -142,6 +142,12 @@ void si_need_cs_space(struct r600_context *ctx, unsigned num_dw, /* Save 16 dwords for the fence mechanism. */ num_dw += 16; +#if R600_TRACE_CS + if (ctx-screen-trace_bo) { + num_dw += R600_TRACE_CS_DWORDS; + } +#endif + /* Flush if there's not enough space. */ if (num_dw RADEON_MAX_CMDBUF_DWORDS) { radeonsi_flush(ctx-context, NULL, RADEON_FLUSH_ASYNC); @@ -206,9 +212,41 @@ void si_context_flush(struct r600_context *ctx, unsigned flags) /* force to keep tiling flags */ flags |= RADEON_FLUSH_KEEP_TILING_FLAGS; +#if R600_TRACE_CS + if (ctx-screen-trace_bo) { + struct r600_screen *rscreen = ctx-screen; + unsigned i; + + for (i = 0; i cs-cdw; i++) { + fprintf(stderr, [%4d] [%5d] 0x%08x\n, rscreen-cs_count, i, cs-buf[i]); + } + rscreen-cs_count++; + } +#endif + /* Flush the CS. */ ctx-ws-cs_flush(ctx-cs, flags); +#if R600_TRACE_CS + if (ctx-screen-trace_bo) { + struct r600_screen *rscreen = ctx-screen; + unsigned i; + + for (i = 0; i 10; i++) { + usleep(5); + if (!ctx-ws-buffer_is_busy(rscreen-trace_bo-buf, RADEON_USAGE_READWRITE)) { + break; + } + } + if (i == 10) { + fprintf(stderr, timeout on cs lockup likely happen at cs %d dw %d\n, + rscreen-trace_ptr[1], rscreen-trace_ptr[0]); + } else { + fprintf(stderr, cs %d executed in %dms\n, rscreen-trace_ptr[1], i * 5); + } + } +#endif + ctx-pm4_dirty_cdwords = 0; ctx-flags = 0; @@ -665,3 +703,23 @@ void r600_context_draw_opaque_count(struct r600_context *ctx, struct r600_so_tar cs-buf[cs-cdw++] = r600_context_bo_reloc(ctx, t-filled_size, RADEON_USAGE_READ); } + +#if R600_TRACE_CS +void r600_trace_emit(struct r600_context *rctx) +{ + struct r600_screen *rscreen = rctx-screen; + struct radeon_winsys_cs *cs = rctx-cs; + uint64_t va; + uint32_t reloc; + + va = r600_resource_va(rscreen-screen, (void*)rscreen-trace_bo); + reloc = r600_context_bo_reloc(rctx, rscreen-trace_bo, RADEON_USAGE_READWRITE); + cs-buf[cs-cdw++] = PKT3(PKT3_MEM_WRITE, 3, 0); I would suggest using the WRITE_DATA packet here since MEM_WRITE is deprecated on SI. Alex + cs-buf[cs-cdw++] = va 0xUL; + cs-buf[cs-cdw++] = (va 32UL) 0xFFUL; + cs-buf[cs-cdw++] = cs-cdw; + cs-buf[cs-cdw++] = rscreen-cs_count; + cs-buf[cs-cdw++] = PKT3(PKT3_NOP, 0, 0); + cs-buf[cs-cdw++] = reloc; +} +#endif diff --git a/src/gallium/drivers/radeonsi/r600_texture.c b/src/gallium/drivers/radeonsi/r600_texture.c index 6cafc3d..3d074a3 100644 --- a/src/gallium/drivers/radeonsi/r600_texture.c +++ b/src/gallium/drivers/radeonsi/r600_texture.c @@ -550,7 +550,7 @@ struct pipe_resource *si_texture_create(struct pipe_screen *screen, if (!(templ-flags R600_RESOURCE_FLAG_TRANSFER) !(templ-bind PIPE_BIND_SCANOUT)) { - array_mode = V_009910_ARRAY_2D_TILED_THIN1; + array_mode = V_009910_ARRAY_1D_TILED_THIN1; } r = r600_init_surface(rscreen, surface, templ, array_mode, diff --git a/src/gallium/drivers/radeonsi/radeonsi_pipe.c b/src/gallium/drivers/radeonsi/radeonsi_pipe.c index c5dac29..a370d7e 100644 --- a/src/gallium/drivers/radeonsi/radeonsi_pipe.c +++ b/src/gallium/drivers/radeonsi/radeonsi_pipe.c @@ -525,6 +525,14 @@ static void r600_destroy_screen(struct pipe_screen* pscreen)
Re: [Mesa-dev] [PATCH] radeonsi: add cs tracing
Am 25.03.2013 17:01, schrieb j.gli...@gmail.com: From: Jerome Glisse jgli...@redhat.com Same as on r600, trace cs execution by writting cs offset after each states, this allow to pin point lockup inside command stream and narrow down the scope of lockup investigation. Signed-off-by: Jerome Glisse jgli...@redhat.com Could your rewrite this to use an si_pm4_state instead of hand coding it? It's cleaner and should reduce the needed code quite a bit. Christian. --- src/gallium/drivers/radeonsi/r600_hw_context.c | 58 ++ src/gallium/drivers/radeonsi/r600_texture.c| 2 +- src/gallium/drivers/radeonsi/radeonsi_pipe.c | 22 ++ src/gallium/drivers/radeonsi/radeonsi_pipe.h | 12 ++ src/gallium/drivers/radeonsi/radeonsi_pm4.c| 12 ++ src/gallium/drivers/radeonsi/si_state_draw.c | 7 +++- 6 files changed, 111 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/radeonsi/r600_hw_context.c b/src/gallium/drivers/radeonsi/r600_hw_context.c index bd348f9..3cd5d0e 100644 --- a/src/gallium/drivers/radeonsi/r600_hw_context.c +++ b/src/gallium/drivers/radeonsi/r600_hw_context.c @@ -142,6 +142,12 @@ void si_need_cs_space(struct r600_context *ctx, unsigned num_dw, /* Save 16 dwords for the fence mechanism. */ num_dw += 16; +#if R600_TRACE_CS + if (ctx-screen-trace_bo) { + num_dw += R600_TRACE_CS_DWORDS; + } +#endif + /* Flush if there's not enough space. */ if (num_dw RADEON_MAX_CMDBUF_DWORDS) { radeonsi_flush(ctx-context, NULL, RADEON_FLUSH_ASYNC); @@ -206,9 +212,41 @@ void si_context_flush(struct r600_context *ctx, unsigned flags) /* force to keep tiling flags */ flags |= RADEON_FLUSH_KEEP_TILING_FLAGS; +#if R600_TRACE_CS + if (ctx-screen-trace_bo) { + struct r600_screen *rscreen = ctx-screen; + unsigned i; + + for (i = 0; i cs-cdw; i++) { + fprintf(stderr, [%4d] [%5d] 0x%08x\n, rscreen-cs_count, i, cs-buf[i]); + } + rscreen-cs_count++; + } +#endif + /* Flush the CS. */ ctx-ws-cs_flush(ctx-cs, flags); +#if R600_TRACE_CS + if (ctx-screen-trace_bo) { + struct r600_screen *rscreen = ctx-screen; + unsigned i; + + for (i = 0; i 10; i++) { + usleep(5); + if (!ctx-ws-buffer_is_busy(rscreen-trace_bo-buf, RADEON_USAGE_READWRITE)) { + break; + } + } + if (i == 10) { + fprintf(stderr, timeout on cs lockup likely happen at cs %d dw %d\n, + rscreen-trace_ptr[1], rscreen-trace_ptr[0]); + } else { + fprintf(stderr, cs %d executed in %dms\n, rscreen-trace_ptr[1], i * 5); + } + } +#endif + ctx-pm4_dirty_cdwords = 0; ctx-flags = 0; @@ -665,3 +703,23 @@ void r600_context_draw_opaque_count(struct r600_context *ctx, struct r600_so_tar cs-buf[cs-cdw++] = r600_context_bo_reloc(ctx, t-filled_size, RADEON_USAGE_READ); } + +#if R600_TRACE_CS +void r600_trace_emit(struct r600_context *rctx) +{ + struct r600_screen *rscreen = rctx-screen; + struct radeon_winsys_cs *cs = rctx-cs; + uint64_t va; + uint32_t reloc; + + va = r600_resource_va(rscreen-screen, (void*)rscreen-trace_bo); + reloc = r600_context_bo_reloc(rctx, rscreen-trace_bo, RADEON_USAGE_READWRITE); + cs-buf[cs-cdw++] = PKT3(PKT3_MEM_WRITE, 3, 0); + cs-buf[cs-cdw++] = va 0xUL; + cs-buf[cs-cdw++] = (va 32UL) 0xFFUL; + cs-buf[cs-cdw++] = cs-cdw; + cs-buf[cs-cdw++] = rscreen-cs_count; + cs-buf[cs-cdw++] = PKT3(PKT3_NOP, 0, 0); + cs-buf[cs-cdw++] = reloc; +} +#endif diff --git a/src/gallium/drivers/radeonsi/r600_texture.c b/src/gallium/drivers/radeonsi/r600_texture.c index 6cafc3d..3d074a3 100644 --- a/src/gallium/drivers/radeonsi/r600_texture.c +++ b/src/gallium/drivers/radeonsi/r600_texture.c @@ -550,7 +550,7 @@ struct pipe_resource *si_texture_create(struct pipe_screen *screen, if (!(templ-flags R600_RESOURCE_FLAG_TRANSFER) !(templ-bind PIPE_BIND_SCANOUT)) { - array_mode = V_009910_ARRAY_2D_TILED_THIN1; + array_mode = V_009910_ARRAY_1D_TILED_THIN1; } r = r600_init_surface(rscreen, surface, templ, array_mode, diff --git a/src/gallium/drivers/radeonsi/radeonsi_pipe.c b/src/gallium/drivers/radeonsi/radeonsi_pipe.c index c5dac29..a370d7e 100644 --- a/src/gallium/drivers/radeonsi/radeonsi_pipe.c +++ b/src/gallium/drivers/radeonsi/radeonsi_pipe.c @@ -525,6 +525,14 @@ static void r600_destroy_screen(struct pipe_screen* pscreen) rscreen-ws-buffer_unmap(rscreen-fences.bo-cs_buf);
[Mesa-dev] OpenGL ES 3.0 support
Hello, I was eager to try the OpenGL ES 3.0 support on the newest Mesa 9.1. I installed the latest Fedora Rawhide on my Sandy Bridge. I think the graphics chip is HD 2000, lspci says I have a Xeon E3-1200 V2/3rd gen processor. glxinfo states that I have Mesa 9.1, and lsmod lists i915 as my VGA driver, so it seems that the setup is right. I wrote a simple EGL program (used the opengles2 example as basis) and tried to create am OpenGL ES3 context. I tried two methods: 1) Giving a value of 3 in the API version eglChooseConfig (EGL_CONTEXT_CLIENT_VERSION=3) This had the result that no matching configs were found. 2) Supplying the EGL_OPENGL_ES3_BIT_KHR flag in eglCreateContext (the EGL_KHR_create_context extension is present). This didn't work either (eglCreateContext returns an error). I am probably doing it the wrong way, but I didn't find any information on the internet on how to try the ES3.0 support (I checked the mesa-users mailing list, the mesa news, the intel linux drivers webpage, and even searched the commit history of mesa...). I would really appreciate some help! ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/5] Head-up display for Gallium DRI2 drivers
I feel rather awkward asking, but: why implement this inside of Gallium, instead of as a standalone {egl,glX}SwapBuffers interceptor obtaining counter values via GL extensions, such as ARB_occlusion_query or AMD_performance_monitor? That way Intel (and Nouveau?) people could also benefit from it. Best regards, Alexander ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radeonsi: add cs tracing
On Mon, Mar 25, 2013 at 12:38 PM, Christian König deathsim...@vodafone.de wrote: Am 25.03.2013 17:01, schrieb j.gli...@gmail.com: From: Jerome Glisse jgli...@redhat.com Same as on r600, trace cs execution by writting cs offset after each states, this allow to pin point lockup inside command stream and narrow down the scope of lockup investigation. Signed-off-by: Jerome Glisse jgli...@redhat.com Could your rewrite this to use an si_pm4_state instead of hand coding it? It's cleaner and should reduce the needed code quite a bit. Christian. Well no, the whole point is to emit inside each si_pm4_state_emit so that you can pin point which reg/packet trigger the lockup. Cheers, Jerome ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] OpenGL ES 3.0 support
On Mon, Mar 25, 2013 at 9:41 AM, violin yanev violin.ya...@gmail.com wrote: Hello, I was eager to try the OpenGL ES 3.0 support on the newest Mesa 9.1. I installed the latest Fedora Rawhide on my Sandy Bridge. I think the graphics chip is HD 2000, lspci says I have a Xeon E3-1200 V2/3rd gen processor. glxinfo states that I have Mesa 9.1, and lsmod lists i915 as my VGA driver, so it seems that the setup is right. I wrote a simple EGL program (used the opengles2 example as basis) and tried to create am OpenGL ES3 context. I tried two methods: 1) Giving a value of 3 in the API version eglChooseConfig (EGL_CONTEXT_CLIENT_VERSION=3) This had the result that no matching configs were found. 2) Supplying the EGL_OPENGL_ES3_BIT_KHR flag in eglCreateContext (the EGL_KHR_create_context extension is present). This didn't work either (eglCreateContext returns an error). I am probably doing it the wrong way, but I didn't find any information on the internet on how to try the ES3.0 support (I checked the mesa-users mailing list, the mesa news, the intel linux drivers webpage, and even searched the commit history of mesa...). I would really appreciate some help! To narrow the problem, does eglinfo (from http://cgit.freedesktop.org/mesa/demos in src/egl/opengl) say that OpenGL_ES3 is an EGL client API? My Sandybridge system says EGL API version: 1.4 EGL vendor string: Mesa Project EGL version string: 1.4 (DRI2) EGL client APIs: OpenGL OpenGL_ES OpenGL_ES2 OpenGL_ES3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] OpenGL ES 3.0 support
On Mon, Mar 25, 2013 at 9:41 AM, violin yanev violin.ya...@gmail.com wrote: Hello, I was eager to try the OpenGL ES 3.0 support on the newest Mesa 9.1. I installed the latest Fedora Rawhide on my Sandy Bridge. I believe this Fedora commit which disabled GL3 for Intel graphics will also disable GLES3 for Intel graphics: http://pkgs.fedoraproject.org/cgit/mesa.git/commit/?id=cbd72a1775d26a74f76be5de337ce036467e2043 -Jordan I think the graphics chip is HD 2000, lspci says I have a Xeon E3-1200 V2/3rd gen processor. glxinfo states that I have Mesa 9.1, and lsmod lists i915 as my VGA driver, so it seems that the setup is right. I wrote a simple EGL program (used the opengles2 example as basis) and tried to create am OpenGL ES3 context. I tried two methods: 1) Giving a value of 3 in the API version eglChooseConfig (EGL_CONTEXT_CLIENT_VERSION=3) This had the result that no matching configs were found. 2) Supplying the EGL_OPENGL_ES3_BIT_KHR flag in eglCreateContext (the EGL_KHR_create_context extension is present). This didn't work either (eglCreateContext returns an error). I am probably doing it the wrong way, but I didn't find any information on the internet on how to try the ES3.0 support (I checked the mesa-users mailing list, the mesa news, the intel linux drivers webpage, and even searched the commit history of mesa...). I would really appreciate some help! ___ 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] radeonsi: add cs tracing
Am 25.03.2013 17:50, schrieb Jerome Glisse: On Mon, Mar 25, 2013 at 12:38 PM, Christian König deathsim...@vodafone.de wrote: Am 25.03.2013 17:01, schrieb j.gli...@gmail.com: From: Jerome Glisse jgli...@redhat.com Same as on r600, trace cs execution by writting cs offset after each states, this allow to pin point lockup inside command stream and narrow down the scope of lockup investigation. Signed-off-by: Jerome Glisse jgli...@redhat.com Could your rewrite this to use an si_pm4_state instead of hand coding it? It's cleaner and should reduce the needed code quite a bit. Christian. Well no, the whole point is to emit inside each si_pm4_state_emit so that you can pin point which reg/packet trigger the lockup. Ok, well then it makes no sense that you increment the counter only once per flush. Christian. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radeonsi: add cs tracing v2
From: Jerome Glisse jgli...@redhat.com Same as on r600, trace cs execution by writting cs offset after each states, this allow to pin point lockup inside command stream and narrow down the scope of lockup investigation. v2: Use WRITE_DATA packet instead of WRITE_MEM Signed-off-by: Jerome Glisse jgli...@redhat.com --- src/gallium/drivers/radeonsi/r600_hw_context.c | 61 ++ src/gallium/drivers/radeonsi/radeonsi_pipe.c | 22 ++ src/gallium/drivers/radeonsi/radeonsi_pipe.h | 12 + src/gallium/drivers/radeonsi/radeonsi_pm4.c| 12 + src/gallium/drivers/radeonsi/si_state_draw.c | 7 ++- src/gallium/drivers/radeonsi/sid.h | 14 ++ 6 files changed, 127 insertions(+), 1 deletion(-) diff --git a/src/gallium/drivers/radeonsi/r600_hw_context.c b/src/gallium/drivers/radeonsi/r600_hw_context.c index bd348f9..967f093 100644 --- a/src/gallium/drivers/radeonsi/r600_hw_context.c +++ b/src/gallium/drivers/radeonsi/r600_hw_context.c @@ -142,6 +142,12 @@ void si_need_cs_space(struct r600_context *ctx, unsigned num_dw, /* Save 16 dwords for the fence mechanism. */ num_dw += 16; +#if R600_TRACE_CS + if (ctx-screen-trace_bo) { + num_dw += R600_TRACE_CS_DWORDS; + } +#endif + /* Flush if there's not enough space. */ if (num_dw RADEON_MAX_CMDBUF_DWORDS) { radeonsi_flush(ctx-context, NULL, RADEON_FLUSH_ASYNC); @@ -206,9 +212,41 @@ void si_context_flush(struct r600_context *ctx, unsigned flags) /* force to keep tiling flags */ flags |= RADEON_FLUSH_KEEP_TILING_FLAGS; +#if R600_TRACE_CS + if (ctx-screen-trace_bo) { + struct r600_screen *rscreen = ctx-screen; + unsigned i; + + for (i = 0; i cs-cdw; i++) { + fprintf(stderr, [%4d] [%5d] 0x%08x\n, rscreen-cs_count, i, cs-buf[i]); + } + rscreen-cs_count++; + } +#endif + /* Flush the CS. */ ctx-ws-cs_flush(ctx-cs, flags); +#if R600_TRACE_CS + if (ctx-screen-trace_bo) { + struct r600_screen *rscreen = ctx-screen; + unsigned i; + + for (i = 0; i 10; i++) { + usleep(5); + if (!ctx-ws-buffer_is_busy(rscreen-trace_bo-buf, RADEON_USAGE_READWRITE)) { + break; + } + } + if (i == 10) { + fprintf(stderr, timeout on cs lockup likely happen at cs %d dw %d\n, + rscreen-trace_ptr[1], rscreen-trace_ptr[0]); + } else { + fprintf(stderr, cs %d executed in %dms\n, rscreen-trace_ptr[1], i * 5); + } + } +#endif + ctx-pm4_dirty_cdwords = 0; ctx-flags = 0; @@ -665,3 +703,26 @@ void r600_context_draw_opaque_count(struct r600_context *ctx, struct r600_so_tar cs-buf[cs-cdw++] = r600_context_bo_reloc(ctx, t-filled_size, RADEON_USAGE_READ); } + +#if R600_TRACE_CS +void r600_trace_emit(struct r600_context *rctx) +{ + struct r600_screen *rscreen = rctx-screen; + struct radeon_winsys_cs *cs = rctx-cs; + uint64_t va; + uint32_t reloc; + + va = r600_resource_va(rscreen-screen, (void*)rscreen-trace_bo); + reloc = r600_context_bo_reloc(rctx, rscreen-trace_bo, RADEON_USAGE_READWRITE); + cs-buf[cs-cdw++] = PKT3(PKT3_WRITE_DATA, 4, 0); + cs-buf[cs-cdw++] = PKT3_WRITE_DATA_DST_SEL(PKT3_WRITE_DATA_DST_SEL_MEM_SYNC) | + PKT3_WRITE_DATA_WR_CONFIRM | + PKT3_WRITE_DATA_ENGINE_SEL(PKT3_WRITE_DATA_ENGINE_SEL_ME); + cs-buf[cs-cdw++] = va 0xUL; + cs-buf[cs-cdw++] = (va 32UL) 0xUL; + cs-buf[cs-cdw++] = cs-cdw; + cs-buf[cs-cdw++] = rscreen-cs_count; + cs-buf[cs-cdw++] = PKT3(PKT3_NOP, 0, 0); + cs-buf[cs-cdw++] = reloc; +} +#endif diff --git a/src/gallium/drivers/radeonsi/radeonsi_pipe.c b/src/gallium/drivers/radeonsi/radeonsi_pipe.c index c5dac29..a370d7e 100644 --- a/src/gallium/drivers/radeonsi/radeonsi_pipe.c +++ b/src/gallium/drivers/radeonsi/radeonsi_pipe.c @@ -525,6 +525,14 @@ static void r600_destroy_screen(struct pipe_screen* pscreen) rscreen-ws-buffer_unmap(rscreen-fences.bo-cs_buf); si_resource_reference(rscreen-fences.bo, NULL); } + +#if R600_TRACE_CS + if (rscreen-trace_bo) { + rscreen-ws-buffer_unmap(rscreen-trace_bo-cs_buf); + pipe_resource_reference((struct pipe_resource**)rscreen-trace_bo, NULL); + } +#endif + pipe_mutex_destroy(rscreen-fences.mutex); rscreen-ws-destroy(rscreen-ws); @@ -727,5 +735,19 @@ struct pipe_screen *radeonsi_screen_create(struct radeon_winsys *ws) LIST_INITHEAD(rscreen-fences.blocks); pipe_mutex_init(rscreen-fences.mutex);
Re: [Mesa-dev] [PATCH 0/5] Head-up display for Gallium DRI2 drivers
- Original Message - Hi everyone, one image is better than a thousand words: http://people.freedesktop.org/~mareko/gallium-hud.png So there you have it. This gallium module can draw transparent graphs and text on top of what apps are rendering. By default, it can show framerate, cpu load (each CPU or the average of all of them), and the results of PRIMITIVES_GENERATED and OCCLUSION_COUNTER queries (the latter is printed as pixels rendered). Furthermore, there is a new interface for gallium allowing drivers to expose driver-specific queries in a way similar to GL_AMD_performance_monitor. It uses the existing pipe_query interface. Drivers can use this to expose performance counters or other internal information. BTW, I guess I should mention that I ripped the font off from freeglut. The HUD is controlled by the GALLIUM_HUD environment variable, where you can list names of data sources. Set GALLIUM_HUD=help for more info, it also prints all available names (including the driver-specific queries). This is what I used for the image above: GALLIUM_HUD=cpu0+cpu1+cpu2+cpu3:100,cpu:100,fps;draw-calls,requested-VRAM+requested-GTT,pixels-rendered So basically I'd like to be able to display as much useful info in the HUD as possible. We should definitely add some ioctls for querying useful stats from the kernel DRM/TTM and be able to see in real time what happens in Mesa and the kernel. It's pretty easy - just expose a new query through the gallium interface and the HUD will automatically pick it up. Hi Marek, Sounds good in principle (and looks great in the screenshot!) I've skimmed through http://cgit.freedesktop.org/~mareko/mesa/log/?h=hud and one thing I noticed is that there isn't a consistent prefix in the new hud module symbols/defines/source files (hud_ is used in most cases, but not all). Please standardize that to prevent symbol collisions. The gallium interface changes look alright. We might eventually want to standardize some of these performance counters, but it looks perfectly adequate for now. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radeonsi: add cs tracing
On Mon, Mar 25, 2013 at 1:12 PM, Christian König deathsim...@vodafone.de wrote: Am 25.03.2013 17:50, schrieb Jerome Glisse: On Mon, Mar 25, 2013 at 12:38 PM, Christian König deathsim...@vodafone.de wrote: Am 25.03.2013 17:01, schrieb j.gli...@gmail.com: From: Jerome Glisse jgli...@redhat.com Same as on r600, trace cs execution by writting cs offset after each states, this allow to pin point lockup inside command stream and narrow down the scope of lockup investigation. Signed-off-by: Jerome Glisse jgli...@redhat.com Could your rewrite this to use an si_pm4_state instead of hand coding it? It's cleaner and should reduce the needed code quite a bit. Christian. Well no, the whole point is to emit inside each si_pm4_state_emit so that you can pin point which reg/packet trigger the lockup. Ok, well then it makes no sense that you increment the counter only once per flush. Christian. The counter is for tracking the cs number (number of call to cs ioctl), while in r600_emit_trace i emit both the counter and the cs-cdw value so that you have both the dwords offset of last trace that went through as well as which cs ioctl call it was. The printf of command stream print both so that you can easily pin point things. Cheers, Jerome ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] freedreno: document debug flag
Signed-off-by: Erik Faye-Lund kusmab...@gmail.com --- I just peeked into the freedreno code, and noticed that it had some undocumented debug-code. Perhaps it could make sense to document it, like this? src/gallium/docs/source/debugging.rst | 4 1 file changed, 4 insertions(+) diff --git a/src/gallium/docs/source/debugging.rst b/src/gallium/docs/source/debugging.rst index e081cbf..3257618 100644 --- a/src/gallium/docs/source/debugging.rst +++ b/src/gallium/docs/source/debugging.rst @@ -81,6 +81,10 @@ Debug :ref:`flags` for the llvmpipe driver. Number of threads that the llvmpipe driver should use. +.. envvar:: FD_MESA_DEBUG bool (false) + +Output debug information for the freedreno driver. + .. _flags: -- 1.8.1.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] freedreno: document debug flag
On Mon, Mar 25, 2013 at 6:25 PM, Erik Faye-Lund kusmab...@gmail.com wrote: Signed-off-by: Erik Faye-Lund kusmab...@gmail.com --- I just peeked into the freedreno code, and noticed that it had some undocumented debug-code. Perhaps it could make sense to document it, like this? src/gallium/docs/source/debugging.rst | 4 1 file changed, 4 insertions(+) diff --git a/src/gallium/docs/source/debugging.rst b/src/gallium/docs/source/debugging.rst index e081cbf..3257618 100644 --- a/src/gallium/docs/source/debugging.rst +++ b/src/gallium/docs/source/debugging.rst @@ -81,6 +81,10 @@ Debug :ref:`flags` for the llvmpipe driver. Number of threads that the llvmpipe driver should use. +.. envvar:: FD_MESA_DEBUG bool (false) + +Output debug information for the freedreno driver. + OK, so it turns out I was a bit trigger-happy. This isn't a normal bool, it's a bitflag. So perhaps something like this instead? diff --git a/src/gallium/docs/source/debugging.rst b/src/gallium/docs/source/debugging.rst index 3257618..8658412 100644 --- a/src/gallium/docs/source/debugging.rst +++ b/src/gallium/docs/source/debugging.rst @@ -81,9 +81,10 @@ Debug :ref:`flags` for the llvmpipe driver. Number of threads that the llvmpipe driver should use. -.. envvar:: FD_MESA_DEBUG bool (false) +.. envvar:: FD_MESA_DEBUG bitflag (false) -Output debug information for the freedreno driver. +Output debug information for the freedreno driver. Bit #0 enables debug +prints, while bit #1 enables TGSI and ASM dumps. .. _flags: ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] gallium: undef PACKAGE_* macros to silence warnings
- Original Message - --- src/gallium/auxiliary/gallivm/lp_bld_misc.cpp |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp index 6a560df..46cdbad 100644 --- a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp +++ b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp @@ -40,6 +40,14 @@ #define __STDC_CONSTANT_MACROS #endif +// Undef these vars just to silence warnings +#undef PACKAGE_BUGREPORT +#undef PACKAGE_NAME +#undef PACKAGE_STRING +#undef PACKAGE_TARNAME +#undef PACKAGE_VERSION + + #include stddef.h #include llvm-c/Core.h -- 1.7.3.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev Series looks good Reviewed-by: Jose Fonseca jfons...@vmware.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Status of GL_ARB_separate_shader_objects? I would like to help.
On 03/23/2013 02:05 PM, gregory hainaut wrote: On Fri, 22 Mar 2013 15:44:07 -0700 Matt Turner matts...@gmail.com wrote: On Fri, Mar 22, 2013 at 1:00 PM, gregory hainaut gregory.hain...@gmail.com wrote: * GenProgramPipelines doesn't create object! ... Spec extract: These names are marked as used, for the purposes of GenBuffers only, but they acquire buffer state only when they are first bound with BindBuffer (see below), just as if they were unused. ... Basically any command (like BindBuffer) that access the pipeline will create the pipeline. It seems like vertex array object. From an implemention point of view it seems much easier to create the object during GenProgramPipelines call. However I don't know if IsProgramPipeline must return FALSE if the object was never really created (bind) like VAO. This is a weird part of the spec. After glGen* (but before glBind*) the associated glIs* function usually returns false. It's something that no one but conformance tests seem to care about. See commit fd93d55141f11069fb76a9b377ad1af88d0ecdd3 (in Mesa) for how to fix this kind of thing. I said usually above because there is some inconsistency. The ARB_sampler_objects spec says that the act of calling glIsSampler() actually creates the object. It looks like for ARB_separate_shader_objects that glGen* followed by glIs* should return false (like VAOs). Ok. Thanks for the example. I updated my code and create a piglit test. By the way, fglrx doesn't follow this behavior, dunno for nvidia. On the mix UseProgram/BindProgramPipeline subjet. I try to search the spec for additional info and found this example: ## Issue 4: When a non-zero program is passed to UseProgram, any subsequent uniform updates will affect that program, ignoring the active program in any bound pipeline object. For example: glUseProgram(0); glBindProgramPipeline(1); glActiveProgram(1, 2); glUniform1f(0, 3.0); // affects program 2 glUseProgram(3); glUniform1f(0, 3.0); // affects program 3 glUseProgram(0); glUniform1f(0, 3.0); // affects program 2 ### So after glUseProgram(0), the state of the pipeline is restored (or they forgot to update this part of the spec when they clarify the priority rule), at least the ActiveProgram. Anyway, I write an extensive piglit test and check the behavior on fglrx. Here the outcome, glUseProgram(0) destroy current program state, the pipeline need to be rebound again for any shader based rendering. However ActiveProgram is restored as the previous example! Any opinion is welcome, run the test on nvidia? Mimic AMD behavior? There are a few places in GL that behave this way. There are two separate pieces of state that may be used. In this case, either the UseProgram state or the BindProgramPipeline state. If UseProgram sets a non-zero program, that state is used. Otherwise the BindProgramPipeline state is used. In Mesa we generally handle this by having both sets of state tracked in the context and a third _State field that's the one actually in use. Right now in the context we have struct gl_shader_state Shader; /** GLSL shader object state */ I think we'd expand this to struct gl_shader_state Shader; /** GLSL shader object state */ struct gl_shader_state SSOShader; struct gl_shader_state *_Shader; /** Points to ::Shader or ::SSOShader */ Or similar. In this case, I think AMD's behavior is incorrect. Cheers ___ 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] freedreno: document debug flag
On Mon, Mar 25, 2013 at 6:36 PM, Erik Faye-Lund kusmab...@gmail.com wrote: On Mon, Mar 25, 2013 at 6:25 PM, Erik Faye-Lund kusmab...@gmail.com wrote: Signed-off-by: Erik Faye-Lund kusmab...@gmail.com --- I just peeked into the freedreno code, and noticed that it had some undocumented debug-code. Perhaps it could make sense to document it, like this? src/gallium/docs/source/debugging.rst | 4 1 file changed, 4 insertions(+) diff --git a/src/gallium/docs/source/debugging.rst b/src/gallium/docs/source/debugging.rst index e081cbf..3257618 100644 --- a/src/gallium/docs/source/debugging.rst +++ b/src/gallium/docs/source/debugging.rst @@ -81,6 +81,10 @@ Debug :ref:`flags` for the llvmpipe driver. Number of threads that the llvmpipe driver should use. +.. envvar:: FD_MESA_DEBUG bool (false) + +Output debug information for the freedreno driver. + OK, so it turns out I was a bit trigger-happy. This isn't a normal bool, it's a bitflag. So perhaps something like this instead? diff --git a/src/gallium/docs/source/debugging.rst b/src/gallium/docs/source/debugging.rst index 3257618..8658412 100644 --- a/src/gallium/docs/source/debugging.rst +++ b/src/gallium/docs/source/debugging.rst @@ -81,9 +81,10 @@ Debug :ref:`flags` for the llvmpipe driver. Number of threads that the llvmpipe driver should use. -.. envvar:: FD_MESA_DEBUG bool (false) +.. envvar:: FD_MESA_DEBUG bitflag (false) -Output debug information for the freedreno driver. +Output debug information for the freedreno driver. Bit #0 enables debug +prints, while bit #1 enables TGSI and ASM dumps. .. _flags: ...and with Rob's recent commit, I guess it should be: diff --git a/src/gallium/docs/source/debugging.rst b/src/gallium/docs/source/deb index e081cbf..dc308e5 100644 --- a/src/gallium/docs/source/debugging.rst +++ b/src/gallium/docs/source/debugging.rst @@ -81,6 +81,10 @@ Debug :ref:`flags` for the llvmpipe driver. Number of threads that the llvmpipe driver should use. +.. envvar:: FD_MESA_DEBUG flags (0x0) + +Debug :ref:`flags` for the freedreno driver. + .. _flags: ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] freedreno: document debug flag
On Mon, Mar 25, 2013 at 3:27 PM, Erik Faye-Lund kusmab...@gmail.com wrote: On Mon, Mar 25, 2013 at 6:36 PM, Erik Faye-Lund kusmab...@gmail.com wrote: On Mon, Mar 25, 2013 at 6:25 PM, Erik Faye-Lund kusmab...@gmail.com wrote: Signed-off-by: Erik Faye-Lund kusmab...@gmail.com --- I just peeked into the freedreno code, and noticed that it had some undocumented debug-code. Perhaps it could make sense to document it, like this? src/gallium/docs/source/debugging.rst | 4 1 file changed, 4 insertions(+) diff --git a/src/gallium/docs/source/debugging.rst b/src/gallium/docs/source/debugging.rst index e081cbf..3257618 100644 --- a/src/gallium/docs/source/debugging.rst +++ b/src/gallium/docs/source/debugging.rst @@ -81,6 +81,10 @@ Debug :ref:`flags` for the llvmpipe driver. Number of threads that the llvmpipe driver should use. +.. envvar:: FD_MESA_DEBUG bool (false) + +Output debug information for the freedreno driver. + OK, so it turns out I was a bit trigger-happy. This isn't a normal bool, it's a bitflag. So perhaps something like this instead? diff --git a/src/gallium/docs/source/debugging.rst b/src/gallium/docs/source/debugging.rst index 3257618..8658412 100644 --- a/src/gallium/docs/source/debugging.rst +++ b/src/gallium/docs/source/debugging.rst @@ -81,9 +81,10 @@ Debug :ref:`flags` for the llvmpipe driver. Number of threads that the llvmpipe driver should use. -.. envvar:: FD_MESA_DEBUG bool (false) +.. envvar:: FD_MESA_DEBUG bitflag (false) -Output debug information for the freedreno driver. +Output debug information for the freedreno driver. Bit #0 enables debug +prints, while bit #1 enables TGSI and ASM dumps. .. _flags: ...and with Rob's recent commit, I guess it should be: diff --git a/src/gallium/docs/source/debugging.rst b/src/gallium/docs/source/deb index e081cbf..dc308e5 100644 --- a/src/gallium/docs/source/debugging.rst +++ b/src/gallium/docs/source/debugging.rst @@ -81,6 +81,10 @@ Debug :ref:`flags` for the llvmpipe driver. Number of threads that the llvmpipe driver should use. +.. envvar:: FD_MESA_DEBUG flags (0x0) + +Debug :ref:`flags` for the freedreno driver. + care to squash that down into one patch, and I'll push? BR, -R .. _flags: ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/5] Head-up display for Gallium DRI2 drivers
That's a very good question. There are a couple of reasons for this. 1) Writing any kind of meta operation and custom rendering code on top of GL is a horrible idea and very prone to errors. If you don't restore all states after you're done, you may break the application. If the application sets a state you didn't take into account, it may break the HUD rendering. And there is a lot of functionality in GL that must be taken into account, while it's pretty simple with Gallium, which has tools for saving and restoring states. 2) I would have to add code paths for GL2, GL3 core, GLES1, and GLES2. I don't really want to worry about all those APIs or any future API. It might also be interesting to use the HUD with non-OpenGL state trackers, like st/xorg and st/xa. 3) Gallium has lower overhead than GL and the HUD should have as little impact on framerate as possible. I'm pretty sure everybody will benefit from this except Intel. I wholeheartedly wish the situation were different, but there is nothing I can do about that. Marek On Mon, Mar 25, 2013 at 5:47 PM, Alexander Monakov amona...@gmail.com wrote: I feel rather awkward asking, but: why implement this inside of Gallium, instead of as a standalone {egl,glX}SwapBuffers interceptor obtaining counter values via GL extensions, such as ARB_occlusion_query or AMD_performance_monitor? That way Intel (and Nouveau?) people could also benefit from it. Best regards, Alexander ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/5] Head-up display for Gallium DRI2 drivers
On Mon, Mar 25, 2013 at 6:14 PM, Jose Fonseca jfons...@vmware.com wrote: - Original Message - Hi everyone, one image is better than a thousand words: http://people.freedesktop.org/~mareko/gallium-hud.png So there you have it. This gallium module can draw transparent graphs and text on top of what apps are rendering. By default, it can show framerate, cpu load (each CPU or the average of all of them), and the results of PRIMITIVES_GENERATED and OCCLUSION_COUNTER queries (the latter is printed as pixels rendered). Furthermore, there is a new interface for gallium allowing drivers to expose driver-specific queries in a way similar to GL_AMD_performance_monitor. It uses the existing pipe_query interface. Drivers can use this to expose performance counters or other internal information. BTW, I guess I should mention that I ripped the font off from freeglut. The HUD is controlled by the GALLIUM_HUD environment variable, where you can list names of data sources. Set GALLIUM_HUD=help for more info, it also prints all available names (including the driver-specific queries). This is what I used for the image above: GALLIUM_HUD=cpu0+cpu1+cpu2+cpu3:100,cpu:100,fps;draw-calls,requested-VRAM+requested-GTT,pixels-rendered So basically I'd like to be able to display as much useful info in the HUD as possible. We should definitely add some ioctls for querying useful stats from the kernel DRM/TTM and be able to see in real time what happens in Mesa and the kernel. It's pretty easy - just expose a new query through the gallium interface and the HUD will automatically pick it up. Hi Marek, Sounds good in principle (and looks great in the screenshot!) I've skimmed through http://cgit.freedesktop.org/~mareko/mesa/log/?h=hud and one thing I noticed is that there isn't a consistent prefix in the new hud module symbols/defines/source files (hud_ is used in most cases, but not all). Please standardize that to prevent symbol collisions. Alright, though too many underscores in a function name looks scary. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] freedreno: document debug flag
On Mon, Mar 25, 2013 at 9:28 PM, Rob Clark robdcl...@gmail.com wrote: On Mon, Mar 25, 2013 at 3:27 PM, Erik Faye-Lund kusmab...@gmail.com wrote: On Mon, Mar 25, 2013 at 6:36 PM, Erik Faye-Lund kusmab...@gmail.com wrote: On Mon, Mar 25, 2013 at 6:25 PM, Erik Faye-Lund kusmab...@gmail.com wrote: Signed-off-by: Erik Faye-Lund kusmab...@gmail.com --- I just peeked into the freedreno code, and noticed that it had some undocumented debug-code. Perhaps it could make sense to document it, like this? src/gallium/docs/source/debugging.rst | 4 1 file changed, 4 insertions(+) diff --git a/src/gallium/docs/source/debugging.rst b/src/gallium/docs/source/debugging.rst index e081cbf..3257618 100644 --- a/src/gallium/docs/source/debugging.rst +++ b/src/gallium/docs/source/debugging.rst @@ -81,6 +81,10 @@ Debug :ref:`flags` for the llvmpipe driver. Number of threads that the llvmpipe driver should use. +.. envvar:: FD_MESA_DEBUG bool (false) + +Output debug information for the freedreno driver. + OK, so it turns out I was a bit trigger-happy. This isn't a normal bool, it's a bitflag. So perhaps something like this instead? diff --git a/src/gallium/docs/source/debugging.rst b/src/gallium/docs/source/debugging.rst index 3257618..8658412 100644 --- a/src/gallium/docs/source/debugging.rst +++ b/src/gallium/docs/source/debugging.rst @@ -81,9 +81,10 @@ Debug :ref:`flags` for the llvmpipe driver. Number of threads that the llvmpipe driver should use. -.. envvar:: FD_MESA_DEBUG bool (false) +.. envvar:: FD_MESA_DEBUG bitflag (false) -Output debug information for the freedreno driver. +Output debug information for the freedreno driver. Bit #0 enables debug +prints, while bit #1 enables TGSI and ASM dumps. .. _flags: ...and with Rob's recent commit, I guess it should be: diff --git a/src/gallium/docs/source/debugging.rst b/src/gallium/docs/source/deb index e081cbf..dc308e5 100644 --- a/src/gallium/docs/source/debugging.rst +++ b/src/gallium/docs/source/debugging.rst @@ -81,6 +81,10 @@ Debug :ref:`flags` for the llvmpipe driver. Number of threads that the llvmpipe driver should use. +.. envvar:: FD_MESA_DEBUG flags (0x0) + +Debug :ref:`flags` for the freedreno driver. + care to squash that down into one patch, and I'll push? Well, that IS one patch. But you might want something for git-am? I'll send one a bit later, sure! ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/5] Head-up display for Gallium DRI2 drivers
On Saturday 23 of March 2013 00:50:59 Marek Olšák wrote: Hi everyone, one image is better than a thousand words: ... Hi, I tried your patches and hit a few problems. As first, they do not apply cleanly on master as they are expecting another your patch cso: add constant buffer save/restore feature for postprocessing to be present. But I guess you are aware of that. Second problem is that when I build mesa with HUD on my 32bit virtual machine, HUD works (with 32bit app of course). When I build it on 64bit (both are same uptodate OS openSUSE 12.3), HUD is not working (with 64bit app). I managed to track it down to failed IMM instruction parsing during HUD_create function. It appears that translate_ctx structure in tgsi_text_translate (file src/gallium/auxiliary/tgsi/tgsi_text.c) is not initialized to zeros under my 64bit system, instead ctx.num_immediates is equal to 1 and hence trigger Immediates must be sorted error. Following fixes HUD for me (note that I really don't know if I am not broking something here in regards to mesa): diff --git a/src/gallium/auxiliary/tgsi/tgsi_text.c b/src/gallium/auxiliary/tgsi/tgsi_text.c index 6b97bee..247ec75 100644 --- a/src/gallium/auxiliary/tgsi/tgsi_text.c +++ b/src/gallium/auxiliary/tgsi/tgsi_text.c @@ -1577,6 +1577,7 @@ tgsi_text_translate( ctx.tokens = tokens; ctx.tokens_cur = tokens; ctx.tokens_end = tokens + num_tokens; + ctx.num_immediates = 0; if (!translate( ctx )) return FALSE; The third issue is that on both 32bit and 64bit build fonts are not displayed in HUD. I see graphs and transparent background rectangles for text but no text is visible. This one I did not yet solve. One last thought, is it intentional when wrong query is entered that hud graph is displayed but empty? Maybe some text like wrong query XXX would be a good hint. I know it is printed on stdout but looking for warnings in chatty apps like openarena is little tricky. Thanks for your work, OH ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/5] Head-up display for Gallium DRI2 drivers
On 03/25/2013 03:38 PM, Ondrej Holecek wrote: On Saturday 23 of March 2013 00:50:59 Marek Olšák wrote: Hi everyone, one image is better than a thousand words: ... Hi, I tried your patches and hit a few problems. As first, they do not apply cleanly on master as they are expecting another your patch cso: add constant buffer save/restore feature for postprocessing to be present. But I guess you are aware of that. Second problem is that when I build mesa with HUD on my 32bit virtual machine, HUD works (with 32bit app of course). When I build it on 64bit (both are same uptodate OS openSUSE 12.3), HUD is not working (with 64bit app). I managed to track it down to failed IMM instruction parsing during HUD_create function. It appears that translate_ctx structure in tgsi_text_translate (file src/gallium/auxiliary/tgsi/tgsi_text.c) is not initialized to zeros under my 64bit system, instead ctx.num_immediates is equal to 1 and hence trigger Immediates must be sorted error. Following fixes HUD for me (note that I really don't know if I am not broking something here in regards to mesa): diff --git a/src/gallium/auxiliary/tgsi/tgsi_text.c b/src/gallium/auxiliary/tgsi/tgsi_text.c index 6b97bee..247ec75 100644 --- a/src/gallium/auxiliary/tgsi/tgsi_text.c +++ b/src/gallium/auxiliary/tgsi/tgsi_text.c @@ -1577,6 +1577,7 @@ tgsi_text_translate( ctx.tokens = tokens; ctx.tokens_cur = tokens; ctx.tokens_end = tokens + num_tokens; + ctx.num_immediates = 0; if (!translate(ctx )) return FALSE; We should init the whole object to zeros to be safe. I'll post a patch for that. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] tgsi: init translate ctx to zeros
Fixes uninitialized member bug spotted by Ondrej Holecek. Note: This is a candidate for the stable branches. --- src/gallium/auxiliary/tgsi/tgsi_text.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/gallium/auxiliary/tgsi/tgsi_text.c b/src/gallium/auxiliary/tgsi/tgsi_text.c index 6b97bee..fd243a5 100644 --- a/src/gallium/auxiliary/tgsi/tgsi_text.c +++ b/src/gallium/auxiliary/tgsi/tgsi_text.c @@ -1570,7 +1570,7 @@ tgsi_text_translate( struct tgsi_token *tokens, uint num_tokens ) { - struct translate_ctx ctx; + struct translate_ctx ctx = { 0 }; ctx.text = text; ctx.cur = text; -- 1.7.3.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/5] Head-up display for Gallium DRI2 drivers
On Mon, Mar 25, 2013 at 10:38 PM, Ondrej Holecek aaa...@gmail.com wrote: On Saturday 23 of March 2013 00:50:59 Marek Olšák wrote: Hi everyone, one image is better than a thousand words: ... Hi, I tried your patches and hit a few problems. As first, they do not apply cleanly on master as they are expecting another your patch cso: add constant buffer save/restore feature for postprocessing to be present. But I guess you are aware of that. Yes, I sent the patch to mesa-dev earlier. Second problem is that when I build mesa with HUD on my 32bit virtual machine, HUD works (with 32bit app of course). When I build it on 64bit (both are same uptodate OS openSUSE 12.3), HUD is not working (with 64bit app). I managed to track it down to failed IMM instruction parsing during HUD_create function. It appears that translate_ctx structure in tgsi_text_translate (file src/gallium/auxiliary/tgsi/tgsi_text.c) is not initialized to zeros under my 64bit system, instead ctx.num_immediates is equal to 1 and hence trigger Immediates must be sorted error. Following fixes HUD for me (note that I really don't know if I am not broking something here in regards to mesa): diff --git a/src/gallium/auxiliary/tgsi/tgsi_text.c b/src/gallium/auxiliary/tgsi/tgsi_text.c index 6b97bee..247ec75 100644 --- a/src/gallium/auxiliary/tgsi/tgsi_text.c +++ b/src/gallium/auxiliary/tgsi/tgsi_text.c @@ -1577,6 +1577,7 @@ tgsi_text_translate( ctx.tokens = tokens; ctx.tokens_cur = tokens; ctx.tokens_end = tokens + num_tokens; + ctx.num_immediates = 0; if (!translate( ctx )) return FALSE; I've sent a fix for this a couple of days ago: http://www.mail-archive.com/mesa-dev@lists.freedesktop.org/msg36038.html The third issue is that on both 32bit and 64bit build fonts are not displayed in HUD. I see graphs and transparent background rectangles for text but no text is visible. This one I did not yet solve. Your driver must support the I8_UNORM texture format. One last thought, is it intentional when wrong query is entered that hud graph is displayed but empty? Maybe some text like wrong query XXX would be a good hint. I know it is printed on stdout but looking for warnings in chatty apps like openarena is little tricky. Yes, it's intentional. I guess I can at least make it not draw an empty pane. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] tgsi: init translate ctx to zeros
I sent almost the same patch 3 days ago. I should have given it a better commit message: http://www.mail-archive.com/mesa-dev@lists.freedesktop.org/msg36038.html Marek On Mon, Mar 25, 2013 at 10:54 PM, Brian Paul bri...@vmware.com wrote: Fixes uninitialized member bug spotted by Ondrej Holecek. Note: This is a candidate for the stable branches. --- src/gallium/auxiliary/tgsi/tgsi_text.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/gallium/auxiliary/tgsi/tgsi_text.c b/src/gallium/auxiliary/tgsi/tgsi_text.c index 6b97bee..fd243a5 100644 --- a/src/gallium/auxiliary/tgsi/tgsi_text.c +++ b/src/gallium/auxiliary/tgsi/tgsi_text.c @@ -1570,7 +1570,7 @@ tgsi_text_translate( struct tgsi_token *tokens, uint num_tokens ) { - struct translate_ctx ctx; + struct translate_ctx ctx = { 0 }; ctx.text = text; ctx.cur = text; -- 1.7.3.4 ___ 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] r600g: Use virtual address for PIPE_QUERY_SO* in r600_emit_query_end
On Mon, Mar 25, 2013 at 6:11 PM, Martin Andersson g02ma...@gmail.com wrote: Virtual address is used for PIPE_QUERY_SO* queries in r600_emit_query_begin, but not in r600_emit_query_end. This will trigger a GPU fault when one of those queries is made and virtual address is enabled. Should also go to the 9.1 branch. Reviewed-by: Alex Deucher alexander.deuc...@amd.com --- src/gallium/drivers/r600/r600_query.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/r600/r600_query.c b/src/gallium/drivers/r600/r600_query.c index 0335189..782ad26 100644 --- a/src/gallium/drivers/r600/r600_query.c +++ b/src/gallium/drivers/r600/r600_query.c @@ -186,10 +186,11 @@ static void r600_emit_query_end(struct r600_context *ctx, struct r600_query *que case PIPE_QUERY_PRIMITIVES_GENERATED: case PIPE_QUERY_SO_STATISTICS: case PIPE_QUERY_SO_OVERFLOW_PREDICATE: + va += query-buffer.results_end + query-result_size/2; cs-buf[cs-cdw++] = PKT3(PKT3_EVENT_WRITE, 2, 0); cs-buf[cs-cdw++] = EVENT_TYPE(EVENT_TYPE_SAMPLE_STREAMOUTSTATS) | EVENT_INDEX(3); - cs-buf[cs-cdw++] = query-buffer.results_end + query-result_size/2; - cs-buf[cs-cdw++] = 0; + cs-buf[cs-cdw++] = va; + cs-buf[cs-cdw++] = (va 32UL) 0xFF; break; case PIPE_QUERY_TIME_ELAPSED: va += query-buffer.results_end + query-result_size/2; -- 1.8.2 ___ 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] tgsi: init translate ctx to zeros
Go ahead and push yours. Reviewed-by: Brian Paul bri...@vmware.com On 03/25/2013 04:03 PM, Marek Olšák wrote: I sent almost the same patch 3 days ago. I should have given it a better commit message: http://www.mail-archive.com/mesa-dev@lists.freedesktop.org/msg36038.html Marek On Mon, Mar 25, 2013 at 10:54 PM, Brian Paulbri...@vmware.com wrote: Fixes uninitialized member bug spotted by Ondrej Holecek. Note: This is a candidate for the stable branches. --- src/gallium/auxiliary/tgsi/tgsi_text.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/gallium/auxiliary/tgsi/tgsi_text.c b/src/gallium/auxiliary/tgsi/tgsi_text.c index 6b97bee..fd243a5 100644 --- a/src/gallium/auxiliary/tgsi/tgsi_text.c +++ b/src/gallium/auxiliary/tgsi/tgsi_text.c @@ -1570,7 +1570,7 @@ tgsi_text_translate( struct tgsi_token *tokens, uint num_tokens ) { - struct translate_ctx ctx; + struct translate_ctx ctx = { 0 }; ctx.text = text; ctx.cur = text; -- 1.7.3.4 ___ 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 v3 02/17] glsl parser: rename uniform block to interface block
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com Reviewed-by: Eric Anholt e...@anholt.net Reviewed-by: Kenneth Graunke kenn...@whitecape.org --- src/glsl/glsl_parser.yy | 24 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy index cd33078..33b74ea 100644 --- a/src/glsl/glsl_parser.yy +++ b/src/glsl/glsl_parser.yy @@ -115,7 +115,7 @@ static void yyerror(YYLTYPE *loc, _mesa_glsl_parse_state *st, const char *msg) %token STRUCT VOID_TOK WHILE %token identifier IDENTIFIER TYPE_IDENTIFIER NEW_IDENTIFIER %type identifier any_identifier -%type uniform_block instance_name_opt +%type interface_block instance_name_opt %token real FLOATCONSTANT %token n INTCONSTANT UINTCONSTANT BOOLCONSTANT %token identifier FIELD_SELECTION @@ -164,7 +164,7 @@ static void yyerror(YYLTYPE *loc, _mesa_glsl_parse_state *st, const char *msg) %type type_qualifier interpolation_qualifier %type type_qualifier layout_qualifier %type type_qualifier layout_qualifier_id_list layout_qualifier_id -%type type_qualifier uniform_block_layout_qualifier +%type type_qualifier interface_block_layout_qualifier %type type_specifier type_specifier %type type_specifier type_specifier_no_prec %type type_specifier type_specifier_nonarray @@ -223,8 +223,8 @@ static void yyerror(YYLTYPE *loc, _mesa_glsl_parse_state *st, const char *msg) %type node declaration %type node declaration_statement %type node jump_statement -%type node uniform_block -%type uniform_block basic_uniform_block +%type node interface_block +%type interface_block basic_interface_block %type struct_specifier struct_specifier %type declarator_list struct_declaration_list %type declarator_list struct_declaration @@ -784,7 +784,7 @@ declaration: $3-is_precision_statement = true; $$ = $3; } - | uniform_block + | interface_block { $$ = $1; } @@ -1140,7 +1140,7 @@ layout_qualifier_id: } } - /* See also uniform_block_layout_qualifier. */ + /* See also interface_block_layout_qualifier. */ if (!$$.flags.i state-ARB_uniform_buffer_object_enable) { if (strcmp($1, std140) == 0) { $$.flags.q.std140 = 1; @@ -1211,7 +1211,7 @@ layout_qualifier_id: identifier `%s' used\n, $1); } } - | uniform_block_layout_qualifier + | interface_block_layout_qualifier { $$ = $1; /* Layout qualifiers for ARB_uniform_buffer_object. */ @@ -1232,7 +1232,7 @@ layout_qualifier_id: * most qualifiers. See the any_identifier path of * layout_qualifier_id for the others. */ -uniform_block_layout_qualifier: +interface_block_layout_qualifier: ROW_MAJOR { memset( $$, 0, sizeof($$)); @@ -1893,12 +1893,12 @@ function_definition: ; /* layout_qualifieropt is packed into this rule */ -uniform_block: - basic_uniform_block +interface_block: + basic_interface_block { $$ = $1; } - | layout_qualifier basic_uniform_block + | layout_qualifier basic_interface_block { ast_interface_block *block = $2; if (!block-layout.merge_qualifier( @1, state, $1)) { @@ -1908,7 +1908,7 @@ uniform_block: } ; -basic_uniform_block: +basic_interface_block: UNIFORM NEW_IDENTIFIER '{' member_list '}' instance_name_opt ';' { ast_interface_block *const block = $6; -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 03/17] glsl: parse in/out types for interface blocks
Previously only 'uniform' was allowed for uniform blocks. Now, in/out can be parsed, but it will only be allowed for GLSL = 150. Signed-off-by: Jordan Justen jordan.l.jus...@intel.com Reviewed-by: Eric Anholt e...@anholt.net --- src/glsl/glsl_parser.yy | 51 +-- 1 file changed, 40 insertions(+), 11 deletions(-) diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy index 33b74ea..0a2a77b 100644 --- a/src/glsl/glsl_parser.yy +++ b/src/glsl/glsl_parser.yy @@ -165,6 +165,7 @@ static void yyerror(YYLTYPE *loc, _mesa_glsl_parse_state *st, const char *msg) %type type_qualifier layout_qualifier %type type_qualifier layout_qualifier_id_list layout_qualifier_id %type type_qualifier interface_block_layout_qualifier +%type type_qualifier interface_qualifier %type type_specifier type_specifier %type type_specifier type_specifier_no_prec %type type_specifier type_specifier_nonarray @@ -1215,11 +1216,11 @@ layout_qualifier_id: { $$ = $1; /* Layout qualifiers for ARB_uniform_buffer_object. */ - if (!state-ARB_uniform_buffer_object_enable) { + if ($$.flags.q.uniform !state-ARB_uniform_buffer_object_enable) { _mesa_glsl_error( @1, state, #version 140 / GL_ARB_uniform_buffer_object layout qualifier `%s' is used\n, $1); - } else if (state-ARB_uniform_buffer_object_warn) { + } else if ($$.flags.q.uniform state-ARB_uniform_buffer_object_warn) { _mesa_glsl_warning( @1, state, #version 140 / GL_ARB_uniform_buffer_object layout qualifier `%s' is used\n, $1); @@ -1909,21 +1910,29 @@ interface_block: ; basic_interface_block: - UNIFORM NEW_IDENTIFIER '{' member_list '}' instance_name_opt ';' + interface_qualifier NEW_IDENTIFIER '{' member_list '}' instance_name_opt ';' { ast_interface_block *const block = $6; block-block_name = $2; block-declarations.push_degenerate_list_at_head( $4-link); - if (!state-ARB_uniform_buffer_object_enable) { - _mesa_glsl_error( @1, state, - #version 140 / GL_ARB_uniform_buffer_object - required for defining uniform blocks\n); - } else if (state-ARB_uniform_buffer_object_warn) { - _mesa_glsl_warning( @1, state, -#version 140 / GL_ARB_uniform_buffer_object -required for defining uniform blocks\n); + if ($1.flags.q.uniform) { + if (!state-ARB_uniform_buffer_object_enable) { +_mesa_glsl_error( @1, state, + #version 140 / GL_ARB_uniform_buffer_object + required for defining uniform blocks\n); + } else if (state-ARB_uniform_buffer_object_warn) { +_mesa_glsl_warning( @1, state, + #version 140 / GL_ARB_uniform_buffer_object + required for defining uniform blocks\n); + } + } else { + if (state-es_shader || state-language_version 150) { +_mesa_glsl_error( @1, state, +#version 150 required for using +interface blocks.\n); + } } /* Since block arrays require names, and both features are added in @@ -1937,10 +1946,30 @@ basic_interface_block: blocks with an instance name\n); } + block-layout.flags.i |= $1.flags.i; + $$ = block; } ; +interface_qualifier: + IN_TOK + { + memset( $$, 0, sizeof($$)); + $$.flags.q.in = 1; + } + | OUT_TOK + { + memset( $$, 0, sizeof($$)); + $$.flags.q.out = 1; + } + | UNIFORM + { + memset( $$, 0, sizeof($$)); + $$.flags.q.uniform = 1; + } + ; + instance_name_opt: /* empty */ { -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 06/17] glsl parser: handle interface block member qualifier
An interface block member may specify the type: in { in vec4 in_var_with_qualifier; }; When specified with the member, it must match the same type as interface block type. It can also omit the qualifier: uniform { vec4 uniform_var_without_qualifier; }; When the type is not specified with the member, it will adopt the same type as the interface block. Signed-off-by: Jordan Justen jordan.l.jus...@intel.com --- src/glsl/glsl_parser.yy | 26 ++ 1 file changed, 26 insertions(+) diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy index 70764d6..c254a2f 100644 --- a/src/glsl/glsl_parser.yy +++ b/src/glsl/glsl_parser.yy @@ -1958,8 +1958,34 @@ basic_interface_block: an instance name are not allowed); } + unsigned interface_type_mask, interface_type_flags; + struct ast_type_qualifier temp_type_qualifier; + + temp_type_qualifier.flags.i = 0; + temp_type_qualifier.flags.q.uniform = true; + temp_type_qualifier.flags.q.in = true; + temp_type_qualifier.flags.q.out = true; + interface_type_mask = temp_type_qualifier.flags.i; + interface_type_flags = $1.flags.i interface_type_mask; block-layout.flags.i |= $1.flags.i; + foreach_list_typed (ast_declarator_list, member, link, block-declarations) { + ast_type_qualifier qualifier = member-type-qualifier; + if ((qualifier.flags.i interface_type_mask) == 0) { +qualifier.flags.i |= interface_type_flags; + } else if ((qualifier.flags.i interface_type_mask) != +interface_type_flags) { +/* GLSLangSpec.1.50.11, 4.3.7 Interface Blocks: + * Input variables, output variables, and uniform variables can only + * be in in blocks, out blocks, and uniform blocks, respectively. + */ +_mesa_glsl_error( @1, state, + uniform/in/out qualifier on + interface block member does not match + the interface block\n); + } + } + $$ = block; } ; -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 04/17] glsl parser: reject VS+in FS+out interface blocks
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com Reviewed-by: Eric Anholt e...@anholt.net Reviewed-by: Kenneth Graunke kenn...@whitecape.org --- src/glsl/glsl_parser.yy | 14 ++ 1 file changed, 14 insertions(+) diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy index 0a2a77b..dbc25a4 100644 --- a/src/glsl/glsl_parser.yy +++ b/src/glsl/glsl_parser.yy @@ -1935,6 +1935,20 @@ basic_interface_block: } } + /* From the GLSL 1.50.11 spec, section 4.3.7 (Interface Blocks): + * It is illegal to have an input block in a vertex shader + * or an output block in a fragment shader + */ + if ((state-target == vertex_shader) $1.flags.q.in) { + _mesa_glsl_error( @1, state, + `in' interface block is not allowed for + a vertex shader\n); + } else if ((state-target == fragment_shader) $1.flags.q.out) { + _mesa_glsl_error( @1, state, + `out' interface block is not allowed for + a fragment shader\n); + } + /* Since block arrays require names, and both features are added in * the same language versions, we don't have to explicitly * version-check both things. -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 10/17] glsl ast_to_hir: move uniform block symbols to interface blocks namespace
Uniform/interface blocks are a separate namespace from types. Signed-off-by: Jordan Justen jordan.l.jus...@intel.com --- src/glsl/ast_to_hir.cpp |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp index 612b3e4..9913309 100644 --- a/src/glsl/ast_to_hir.cpp +++ b/src/glsl/ast_to_hir.cpp @@ -4288,7 +4288,7 @@ ast_interface_block::hir(exec_list *instructions, packing, this-block_name); - if (!state-symbols-add_type(block_type-name, block_type)) { + if (!state-symbols-add_interface(block_type-name, block_type, ir_var_uniform)) { YYLTYPE loc = this-get_location(); _mesa_glsl_error(loc, state, Uniform block name `%s' already taken in the current scope.\n, this-block_name); -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 08/17] glsl parser: allow in out for interface block members
Previously uniform blocks allowed for the 'uniform' keyword to be used with members of a uniform blocks. With interface blocks 'in' can be used on 'in' interface block members and 'out' can be used on 'out' interface block members. The basic_interface_block rule will verify that the same qualifier type is used with the block and each member. Signed-off-by: Jordan Justen jordan.l.jus...@intel.com --- src/glsl/glsl_parser.yy | 47 ++- 1 file changed, 30 insertions(+), 17 deletions(-) diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy index c254a2f..6d88263 100644 --- a/src/glsl/glsl_parser.yy +++ b/src/glsl/glsl_parser.yy @@ -2051,41 +2051,54 @@ member_list: } ; -/* Specifying uniform inside of a uniform block is redundant. */ -uniformopt: - /* nothing */ - | UNIFORM - ; - member_declaration: - layout_qualifier uniformopt type_specifier struct_declarator_list ';' + layout_qualifier fully_specified_type struct_declarator_list ';' { void *ctx = state; - ast_fully_specified_type *type = new(ctx) ast_fully_specified_type(); + ast_fully_specified_type *type = $2; type-set_location(yylloc); - type-qualifier = $1; - type-qualifier.flags.q.uniform = true; - type-specifier = $3; + if (!type-qualifier.merge_qualifier( @1, state, $1)) { + YYERROR; + } + + if (type-qualifier.flags.q.attribute) { + _mesa_glsl_error( @1, state, + keyword 'attribute' cannot be used with + interface block member\n); + } else if (type-qualifier.flags.q.varying) { + _mesa_glsl_error( @1, state, + keyword 'varying' cannot be used with + interface block member\n); + } + $$ = new(ctx) ast_declarator_list(type); $$-set_location(yylloc); $$-ubo_qualifiers_valid = true; - $$-declarations.push_degenerate_list_at_head( $4-link); + $$-declarations.push_degenerate_list_at_head( $3-link); } - | uniformopt type_specifier struct_declarator_list ';' + | fully_specified_type struct_declarator_list ';' { void *ctx = state; - ast_fully_specified_type *type = new(ctx) ast_fully_specified_type(); + ast_fully_specified_type *type = $1; type-set_location(yylloc); - type-qualifier.flags.q.uniform = true; - type-specifier = $2; + if (type-qualifier.flags.q.attribute) { + _mesa_glsl_error( @1, state, + keyword 'attribute' cannot be used in + interface block\n); + } else if (type-qualifier.flags.q.varying) { + _mesa_glsl_error( @1, state, + keyword 'varying' cannot be used in + interface block\n); + } + $$ = new(ctx) ast_declarator_list(type); $$-set_location(yylloc); $$-ubo_qualifiers_valid = true; - $$-declarations.push_degenerate_list_at_head( $3-link); + $$-declarations.push_degenerate_list_at_head( $2-link); } ; -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 01/17] glsl: rename ast_uniform_block to ast_interface_block
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com Reviewed-by: Eric Anholt e...@anholt.net Reviewed-by: Kenneth Graunke kenn...@whitecape.org --- src/glsl/ast.h |4 ++-- src/glsl/ast_to_hir.cpp |6 +++--- src/glsl/glsl_parser.yy | 14 +++--- 3 files changed, 12 insertions(+), 12 deletions(-) diff --git a/src/glsl/ast.h b/src/glsl/ast.h index fcc6b45..49c3939 100644 --- a/src/glsl/ast.h +++ b/src/glsl/ast.h @@ -805,9 +805,9 @@ public: ast_compound_statement *body; }; -class ast_uniform_block : public ast_node { +class ast_interface_block : public ast_node { public: - ast_uniform_block(ast_type_qualifier layout, + ast_interface_block(ast_type_qualifier layout, const char *instance_name, ast_expression *array_size) : layout(layout), block_name(NULL), instance_name(instance_name), diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp index 92065f5..40f3188 100644 --- a/src/glsl/ast_to_hir.cpp +++ b/src/glsl/ast_to_hir.cpp @@ -4244,12 +4244,12 @@ ast_struct_specifier::hir(exec_list *instructions, } ir_rvalue * -ast_uniform_block::hir(exec_list *instructions, - struct _mesa_glsl_parse_state *state) +ast_interface_block::hir(exec_list *instructions, + struct _mesa_glsl_parse_state *state) { YYLTYPE loc = this-get_location(); - /* The ast_uniform_block has a list of ast_declarator_lists. We + /* The ast_interface_block has a list of ast_declarator_lists. We * need to turn those into ir_variables with an association * with this uniform block. */ diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy index f52ed9b..cd33078 100644 --- a/src/glsl/glsl_parser.yy +++ b/src/glsl/glsl_parser.yy @@ -79,7 +79,7 @@ static void yyerror(YYLTYPE *loc, _mesa_glsl_parse_state *st, const char *msg) ast_case_label_list *case_label_list; ast_case_statement *case_statement; ast_case_statement_list *case_statement_list; - ast_uniform_block *uniform_block; + ast_interface_block *interface_block; struct { ast_node *cond; @@ -1900,7 +1900,7 @@ uniform_block: } | layout_qualifier basic_uniform_block { - ast_uniform_block *block = $2; + ast_interface_block *block = $2; if (!block-layout.merge_qualifier( @1, state, $1)) { YYERROR; } @@ -1911,7 +1911,7 @@ uniform_block: basic_uniform_block: UNIFORM NEW_IDENTIFIER '{' member_list '}' instance_name_opt ';' { - ast_uniform_block *const block = $6; + ast_interface_block *const block = $6; block-block_name = $2; block-declarations.push_degenerate_list_at_head( $4-link); @@ -1944,19 +1944,19 @@ basic_uniform_block: instance_name_opt: /* empty */ { - $$ = new(state) ast_uniform_block(*state-default_uniform_qualifier, + $$ = new(state) ast_interface_block(*state-default_uniform_qualifier, NULL, NULL); } | NEW_IDENTIFIER { - $$ = new(state) ast_uniform_block(*state-default_uniform_qualifier, + $$ = new(state) ast_interface_block(*state-default_uniform_qualifier, $1, NULL); } | NEW_IDENTIFIER '[' constant_expression ']' { - $$ = new(state) ast_uniform_block(*state-default_uniform_qualifier, + $$ = new(state) ast_interface_block(*state-default_uniform_qualifier, $1, $3); } @@ -1965,7 +1965,7 @@ instance_name_opt: _mesa_glsl_error( @1, state, instance block arrays must be explicitly sized\n); - $$ = new(state) ast_uniform_block(*state-default_uniform_qualifier, + $$ = new(state) ast_interface_block(*state-default_uniform_qualifier, $1, NULL); } -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 11/17] glsl ast_to_hir: reject row/column_major for in/out interface blocks
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com --- src/glsl/ast_to_hir.cpp |6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp index 9913309..25fcee4 100644 --- a/src/glsl/ast_to_hir.cpp +++ b/src/glsl/ast_to_hir.cpp @@ -4178,7 +4178,11 @@ ast_process_structure_or_interface_block(exec_list *instructions, fields[i].name = decl-identifier; if (qual-flags.q.row_major || qual-flags.q.column_major) { -if (!field_type-is_matrix() !field_type-is_record()) { +if (!qual-flags.q.uniform) { + _mesa_glsl_error(loc, state, +row_major and column_major can only be +applied to uniform interface blocks.); +} else if (!field_type-is_matrix() !field_type-is_record()) { _mesa_glsl_error(loc, state, uniform block layout qualifiers row_major and column_major can only be applied to matrix and -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 00/17] GLSL 1.50 interface blocks support
git://people.freedesktop.org/~jljusten/mesa interface-blocks-v3 v3: * Several clean-ups based on v2 code review * Fix (proposed) piglit test: execution/interface-blocks-same-uniform-varying-name.shader_test (varying interface block having the same name as a uniform interface block.) * Fix (proposed) piglit test: compiler/interface-blocks-invalid-member-qualifiers.shader_test v2: * 3 new patches added to series * Add support for interface block instance arrays * Add support for rejecting unmatched interface blocks during the linking phase. * Known issue: fails new piglit glsl-1.50 test: execution/interface-blocks-same-uniform-varying-name.shader_test v1: * Initial support for GLSL 1.50 interface block support * Known issue: interface block arrays are not working * Known issue: rejection of unmatched interface blocks is not working * Piglit tests for known issues have been sent to piglit list Jordan Justen (17): glsl: rename ast_uniform_block to ast_interface_block glsl parser: rename uniform block to interface block glsl: parse in/out types for interface blocks glsl parser: reject VS+in FS+out interface blocks glsl parser: on desktop GL require GLSL 150 for instance names glsl parser: handle interface block member qualifier glsl ast_to_hir: reject interpolation qualifiers for uniform blocks glsl parser: allow in out for interface block members glsl_symbol_table: add interface block namespaces glsl ast_to_hir: move uniform block symbols to interface blocks namespace glsl ast_to_hir: reject row/column_major for in/out interface blocks glsl ast_to_hir: support in/out for interface blocks glsl linker: remove interface block instance names glsl link_varyings: link interface blocks using the block name glsl linker: support arrays of interface block instances glsl linker: compare interface blocks during intrastage linking glsl linker: compare interface blocks during interstage linking src/glsl/Makefile.sources |2 + src/glsl/ast.h|4 +- src/glsl/ast_to_hir.cpp | 46 -- src/glsl/glsl_parser.yy | 182 -- src/glsl/glsl_symbol_table.cpp| 84 +- src/glsl/glsl_symbol_table.h |4 + src/glsl/interface_blocks.cpp | 129 +++ src/glsl/interface_blocks.h | 36 + src/glsl/ir_optimization.h|1 + src/glsl/link_varyings.cpp| 33 +++- src/glsl/linker.cpp | 19 +++ src/glsl/lower_named_interface_blocks.cpp | 241 + 12 files changed, 711 insertions(+), 70 deletions(-) create mode 100644 src/glsl/interface_blocks.cpp create mode 100644 src/glsl/interface_blocks.h create mode 100644 src/glsl/lower_named_interface_blocks.cpp -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 05/17] glsl parser: on desktop GL require GLSL 150 for instance names
Interface blocks in GLSL 150 allow an instance name to be used. v2: * use state-check_version Signed-off-by: Jordan Justen jordan.l.jus...@intel.com Reviewed-by: Eric Anholt e...@anholt.net Reviewed-by: Kenneth Graunke kenn...@whitecape.org --- src/glsl/glsl_parser.yy |8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy index dbc25a4..70764d6 100644 --- a/src/glsl/glsl_parser.yy +++ b/src/glsl/glsl_parser.yy @@ -1953,11 +1953,9 @@ basic_interface_block: * the same language versions, we don't have to explicitly * version-check both things. */ - if (block-instance_name != NULL - !(state-language_version == 300 state-es_shader)) { - _mesa_glsl_error( @1, state, - #version 300 es required for using uniform - blocks with an instance name\n); + if (block-instance_name != NULL) { + state-check_version(150, 300, @1, interface blocks with + an instance name are not allowed); } block-layout.flags.i |= $1.flags.i; -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 07/17] glsl ast_to_hir: reject interpolation qualifiers for uniform blocks
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com --- src/glsl/ast_to_hir.cpp |6 ++ 1 file changed, 6 insertions(+) diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp index 40f3188..612b3e4 100644 --- a/src/glsl/ast_to_hir.cpp +++ b/src/glsl/ast_to_hir.cpp @@ -4187,6 +4187,12 @@ ast_process_structure_or_interface_block(exec_list *instructions, validate_matrix_layout_for_type(state, loc, field_type); } + if (qual-flags.q.uniform qual-has_interpolation()) { +_mesa_glsl_error(loc, state, + interpolation qualifiers cannot be used + with uniform interface blocks); + } + if (field_type-is_matrix() || (field_type-is_array() field_type-fields.array-is_matrix())) { fields[i].row_major = block_row_major; -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 09/17] glsl_symbol_table: add interface block namespaces
For interface blocks, there are three separate namespaces for uniform, input and output blocks. Signed-off-by: Jordan Justen jordan.l.jus...@intel.com --- src/glsl/glsl_symbol_table.cpp | 84 ++-- src/glsl/glsl_symbol_table.h |4 ++ 2 files changed, 85 insertions(+), 3 deletions(-) diff --git a/src/glsl/glsl_symbol_table.cpp b/src/glsl/glsl_symbol_table.cpp index 8d34547..50bf113 100644 --- a/src/glsl/glsl_symbol_table.cpp +++ b/src/glsl/glsl_symbol_table.cpp @@ -41,13 +41,67 @@ public: ralloc_free(entry); } - symbol_table_entry(ir_variable *v) : v(v), f(0), t(0) {} - symbol_table_entry(ir_function *f) : v(0), f(f), t(0) {} - symbol_table_entry(const glsl_type *t) : v(0), f(0), t(t) {} + bool add_interface(const glsl_type *i, enum ir_variable_mode mode) + { + const glsl_type **dest; + + switch (mode) { + case ir_var_uniform: + dest = ibu; + break; + case ir_var_shader_in: + dest = ibi; + break; + case ir_var_shader_out: + dest = ibo; + break; + default: + assert(!Unsupported interface variable mode!); + return false; + } + + if (*dest != NULL) { + return false; + } else { + *dest = i; + return true; + } + } + + const glsl_type *get_interface(enum ir_variable_mode mode) + { + switch (mode) { + case ir_var_uniform: + return ibu; + case ir_var_shader_in: + return ibi; + case ir_var_shader_out: + return ibo; + default: + assert(!Unsupported interface variable mode!); + return NULL; + } + } + + symbol_table_entry(ir_variable *v) : + v(v), f(0), t(0), ibu(0), ibi(0), ibo(0) {} + symbol_table_entry(ir_function *f) : + v(0), f(f), t(0), ibu(0), ibi(0), ibo(0) {} + symbol_table_entry(const glsl_type *t) : + v(0), f(0), t(t), ibu(0), ibi(0), ibo(0) {} + symbol_table_entry(const glsl_type *t, enum ir_variable_mode mode) : + v(0), f(0), t(0), ibu(0), ibi(0), ibo(0) + { + assert(t-is_interface()); + add_interface(t, mode); + } ir_variable *v; ir_function *f; const glsl_type *t; + const glsl_type *ibu; + const glsl_type *ibi; + const glsl_type *ibo; }; glsl_symbol_table::glsl_symbol_table() @@ -118,6 +172,23 @@ bool glsl_symbol_table::add_type(const char *name, const glsl_type *t) return _mesa_symbol_table_add_symbol(table, -1, name, entry) == 0; } +bool glsl_symbol_table::add_interface(const char *name, const glsl_type *i, + enum ir_variable_mode mode) +{ + assert(i-is_interface()); + symbol_table_entry *entry = get_entry(name); + if (entry == NULL) { + symbol_table_entry *entry = + new(mem_ctx) symbol_table_entry(i, mode); + bool add_interface_symbol_result = + _mesa_symbol_table_add_symbol(table, -1, name, entry) == 0; + assert(add_interface_symbol_result); + return add_interface_symbol_result; + } else { + return entry-add_interface(i, mode); + } +} + bool glsl_symbol_table::add_function(ir_function *f) { if (this-separate_function_namespace name_declared_this_scope(f-name)) { @@ -152,6 +223,13 @@ const glsl_type *glsl_symbol_table::get_type(const char *name) return entry != NULL ? entry-t : NULL; } +const glsl_type *glsl_symbol_table::get_interface(const char *name, + enum ir_variable_mode mode) +{ + symbol_table_entry *entry = get_entry(name); + return entry != NULL ? entry-get_interface(mode) : NULL; +} + ir_function *glsl_symbol_table::get_function(const char *name) { symbol_table_entry *entry = get_entry(name); diff --git a/src/glsl/glsl_symbol_table.h b/src/glsl/glsl_symbol_table.h index 9f56027..2753bdf 100644 --- a/src/glsl/glsl_symbol_table.h +++ b/src/glsl/glsl_symbol_table.h @@ -99,6 +99,8 @@ public: bool add_variable(ir_variable *v); bool add_type(const char *name, const glsl_type *t); bool add_function(ir_function *f); + bool add_interface(const char *name, const glsl_type *i, + enum ir_variable_mode mode); /*@}*/ /** @@ -113,6 +115,8 @@ public: ir_variable *get_variable(const char *name); const glsl_type *get_type(const char *name); ir_function *get_function(const char *name); + const glsl_type *get_interface(const char *name, + enum ir_variable_mode mode); /*@}*/ private: -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 12/17] glsl ast_to_hir: support in/out for interface blocks
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com Reviewed-by: Kenneth Graunke kenn...@whitecape.org --- src/glsl/ast_to_hir.cpp | 28 ++-- 1 file changed, 22 insertions(+), 6 deletions(-) diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp index 25fcee4..8005fbd 100644 --- a/src/glsl/ast_to_hir.cpp +++ b/src/glsl/ast_to_hir.cpp @@ -4286,16 +4286,32 @@ ast_interface_block::hir(exec_list *instructions, true, block_row_major); + ir_variable_mode var_mode; + const char *iface_type_name; + if (this-layout.flags.q.in) { + var_mode = ir_var_shader_in; + iface_type_name = in; + } else if (this-layout.flags.q.out) { + var_mode = ir_var_shader_out; + iface_type_name = out; + } else if (this-layout.flags.q.uniform) { + var_mode = ir_var_uniform; + iface_type_name = uniform; + } else { + assert(!interface block layout qualifier not found!); + } + const glsl_type *block_type = glsl_type::get_interface_instance(fields, num_variables, packing, this-block_name); - if (!state-symbols-add_interface(block_type-name, block_type, ir_var_uniform)) { + if (!state-symbols-add_interface(block_type-name, block_type, var_mode)) { YYLTYPE loc = this-get_location(); - _mesa_glsl_error(loc, state, Uniform block name `%s' already taken in - the current scope.\n, this-block_name); + _mesa_glsl_error(loc, state, Interface block `%s' with type `%s' + already taken in the current scope.\n, + this-block_name, iface_type_name); } /* Since interface blocks cannot contain statements, it should be @@ -4319,11 +4335,11 @@ ast_interface_block::hir(exec_list *instructions, var = new(state) ir_variable(block_array_type, this-instance_name, - ir_var_uniform); + var_mode); } else { var = new(state) ir_variable(block_type, this-instance_name, - ir_var_uniform); + var_mode); } var-interface_type = block_type; @@ -4339,7 +4355,7 @@ ast_interface_block::hir(exec_list *instructions, ir_variable *var = new(state) ir_variable(fields[i].type, ralloc_strdup(state, fields[i].name), - ir_var_uniform); + var_mode); var-interface_type = block_type; state-symbols-add_variable(var); -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 16/17] glsl linker: compare interface blocks during intrastage linking
Verify that interface blocks match when combining compilation units at the same stage. (For example, when merging all vertex shaders.) Fixes piglit glsl-1.50 test: * linker/interface-blocks-multiple-vs-member-count-mismatch.shader_test Signed-off-by: Jordan Justen jordan.l.jus...@intel.com --- src/glsl/Makefile.sources |1 + src/glsl/interface_blocks.cpp | 86 + src/glsl/interface_blocks.h | 32 +++ src/glsl/linker.cpp |7 4 files changed, 126 insertions(+) create mode 100644 src/glsl/interface_blocks.cpp create mode 100644 src/glsl/interface_blocks.h diff --git a/src/glsl/Makefile.sources b/src/glsl/Makefile.sources index 86ae43e..ba37ad2 100644 --- a/src/glsl/Makefile.sources +++ b/src/glsl/Makefile.sources @@ -25,6 +25,7 @@ LIBGLSL_FILES = \ $(GLSL_SRCDIR)/glsl_types.cpp \ $(GLSL_SRCDIR)/glsl_symbol_table.cpp \ $(GLSL_SRCDIR)/hir_field_selection.cpp \ + $(GLSL_SRCDIR)/interface_blocks.cpp \ $(GLSL_SRCDIR)/ir_basic_block.cpp \ $(GLSL_SRCDIR)/ir_builder.cpp \ $(GLSL_SRCDIR)/ir_clone.cpp \ diff --git a/src/glsl/interface_blocks.cpp b/src/glsl/interface_blocks.cpp new file mode 100644 index 000..6dfd0c4 --- /dev/null +++ b/src/glsl/interface_blocks.cpp @@ -0,0 +1,86 @@ +/* + * Copyright (c) 2013 Intel Corporation + * + * 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. + */ + +/** + * \file interface_blocks.cpp + * GLSL interface blocks support + */ + +#include ir.h +#include glsl_symbol_table.h +#include main/macros.h +#include program/hash_table.h + +static bool +cross_validate_interface_blocks(const gl_shader **shader_list, +unsigned num_shaders) +{ + bool ok = true; + glsl_symbol_table interfaces; + + for (unsigned int i = 0; ok i num_shaders; i++) { + if (shader_list[i] == NULL) + continue; + + foreach_list(node, shader_list[i]-ir) { + ir_variable *var = ((ir_instruction *) node)-as_variable(); + if (!var) +continue; + + const glsl_type *iface_type = var-interface_type; + + if (iface_type == NULL) +continue; + + const char *iface_name = iface_type-name; + + const glsl_type *old_iface_type = +interfaces.get_interface(iface_name, + (enum ir_variable_mode) var-mode); + + /* This is the first time we've seen the interface, so save + * it into our symbol table. + */ + if (old_iface_type == NULL) { +interfaces.add_interface(iface_name, iface_type, + (enum ir_variable_mode) var-mode); +old_iface_type = iface_type; + } + + ok = old_iface_type == iface_type; + if (!ok) +break; + } + } + + return ok; +} + +bool +validate_intrastage_interface_blocks(const gl_shader **shader_list, + unsigned num_shaders) +{ + return cross_validate_interface_blocks(shader_list, + num_shaders); +} + diff --git a/src/glsl/interface_blocks.h b/src/glsl/interface_blocks.h new file mode 100644 index 000..4c37c02 --- /dev/null +++ b/src/glsl/interface_blocks.h @@ -0,0 +1,32 @@ +/* + * Copyright (c) 2013 Intel Corporation + * + * 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
[Mesa-dev] [PATCH v3 13/17] glsl linker: remove interface block instance names
Convert interface blocks with instance names into flat interface blocks without an instance name. Signed-off-by: Jordan Justen jordan.l.jus...@intel.com --- src/glsl/Makefile.sources |1 + src/glsl/ir_optimization.h|1 + src/glsl/linker.cpp |6 + src/glsl/lower_named_interface_blocks.cpp | 202 + 4 files changed, 210 insertions(+) create mode 100644 src/glsl/lower_named_interface_blocks.cpp diff --git a/src/glsl/Makefile.sources b/src/glsl/Makefile.sources index c294aa4..86ae43e 100644 --- a/src/glsl/Makefile.sources +++ b/src/glsl/Makefile.sources @@ -62,6 +62,7 @@ LIBGLSL_FILES = \ $(GLSL_SRCDIR)/lower_mat_op_to_vec.cpp \ $(GLSL_SRCDIR)/lower_noise.cpp \ $(GLSL_SRCDIR)/lower_packed_varyings.cpp \ + $(GLSL_SRCDIR)/lower_named_interface_blocks.cpp \ $(GLSL_SRCDIR)/lower_packing_builtins.cpp \ $(GLSL_SRCDIR)/lower_texture_projection.cpp \ $(GLSL_SRCDIR)/lower_variable_index_to_cond_assign.cpp \ diff --git a/src/glsl/ir_optimization.h b/src/glsl/ir_optimization.h index 2454bbe..c0850ce 100644 --- a/src/glsl/ir_optimization.h +++ b/src/glsl/ir_optimization.h @@ -105,6 +105,7 @@ void lower_ubo_reference(struct gl_shader *shader, exec_list *instructions); void lower_packed_varyings(void *mem_ctx, unsigned location_base, unsigned locations_used, ir_variable_mode mode, gl_shader *shader); +void lower_named_interface_blocks(void *mem_ctx, gl_shader *shader); bool optimize_redundant_jumps(exec_list *instructions); bool optimize_split_arrays(exec_list *instructions, bool linked); diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp index 2b30d2b..31339e1 100644 --- a/src/glsl/linker.cpp +++ b/src/glsl/linker.cpp @@ -1733,6 +1733,12 @@ link_shaders(struct gl_context *ctx, struct gl_shader_program *prog) prog-LinkStatus = true; } + + for (unsigned int i = 0; i MESA_SHADER_TYPES; i++) { + if (prog-_LinkedShaders[i] != NULL) + lower_named_interface_blocks(mem_ctx, prog-_LinkedShaders[i]); + } + /* Implement the GLSL 1.30+ rule for discard vs infinite loops Do * it before optimization because we want most of the checks to get * dropped thanks to constant propagation. diff --git a/src/glsl/lower_named_interface_blocks.cpp b/src/glsl/lower_named_interface_blocks.cpp new file mode 100644 index 000..2e0c322 --- /dev/null +++ b/src/glsl/lower_named_interface_blocks.cpp @@ -0,0 +1,202 @@ +/* + * Copyright (c) 2013 Intel Corporation + * + * 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. + */ + +/** + * \file lower_named_interface_blocks.cpp + * + * This lowering pass converts all interface blocks with instance names + * into interface blocks without an interface name. + * + * For example, the following shader: + * + * out block { + * float block_var; + * } inst_name; + * + * main() + * { + * inst_name.block_var = 0.0; + * } + * + * Is rewritten to: + * + * out block { + * float block_var; + * }; + * + * main() + * { + * block_var = 0.0; + * } + * + * This takes place after the shader code has already been verified with + * the interface name in place. + * + * The linking phase will use the interface name rather than the + * interface's instance name. + * + * This modification to the ir allows our currently existing dead code + * elimination to work with interface blocks without changes. + */ + +#include glsl_symbol_table.h +#include ir.h +#include ir_optimization.h +#include ir_rvalue_visitor.h +#include program/hash_table.h + +class flatten_named_interface_blocks_declarations : public ir_rvalue_visitor +{ +public: + void * const mem_ctx; + hash_table *interface_namespace; + + flatten_named_interface_blocks_declarations(void *mem_ctx) + : mem_ctx(mem_ctx) + { + } +
[Mesa-dev] [PATCH v3 14/17] glsl link_varyings: link interface blocks using the block name
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com --- src/glsl/link_varyings.cpp | 33 + 1 file changed, 29 insertions(+), 4 deletions(-) diff --git a/src/glsl/link_varyings.cpp b/src/glsl/link_varyings.cpp index 04c9fdd..b374049 100644 --- a/src/glsl/link_varyings.cpp +++ b/src/glsl/link_varyings.cpp @@ -965,6 +965,8 @@ assign_varying_locations(struct gl_context *ctx, = hash_table_ctor(0, hash_table_string_hash, hash_table_string_compare); hash_table *consumer_inputs = hash_table_ctor(0, hash_table_string_hash, hash_table_string_compare); + hash_table *consumer_interface_inputs + = hash_table_ctor(0, hash_table_string_hash, hash_table_string_compare); /* Operate in a total of three passes. * @@ -983,8 +985,17 @@ assign_varying_locations(struct gl_context *ctx, ((ir_instruction *) node)-as_variable(); if ((input_var != NULL) (input_var-mode == ir_var_shader_in)) { -hash_table_insert(consumer_inputs, input_var, - ralloc_strdup(mem_ctx, input_var-name)); +if (input_var-interface_type != NULL) { + char *const iface_field_name = + ralloc_asprintf(mem_ctx, %s.%s, + input_var-interface_type-name, + input_var-name); + hash_table_insert(consumer_interface_inputs, input_var, + iface_field_name); +} else { + hash_table_insert(consumer_inputs, input_var, + ralloc_strdup(mem_ctx, input_var-name)); +} } } } @@ -998,8 +1009,19 @@ assign_varying_locations(struct gl_context *ctx, tfeedback_candidate_generator g(mem_ctx, tfeedback_candidates); g.process(output_var); - ir_variable *input_var = - (ir_variable *) hash_table_find(consumer_inputs, output_var-name); + ir_variable *input_var; + if (output_var-interface_type != NULL) { + char *const iface_field_name = +ralloc_asprintf(mem_ctx, %s.%s, +output_var-interface_type-name, +output_var-name); + input_var = +(ir_variable *) hash_table_find(consumer_interface_inputs, +iface_field_name); + } else { + input_var = +(ir_variable *) hash_table_find(consumer_inputs, output_var-name); + } if (input_var input_var-mode != ir_var_shader_in) input_var = NULL; @@ -1019,6 +1041,7 @@ assign_varying_locations(struct gl_context *ctx, if (matched_candidate == NULL) { hash_table_dtor(tfeedback_candidates); hash_table_dtor(consumer_inputs); + hash_table_dtor(consumer_interface_inputs); return false; } @@ -1036,12 +1059,14 @@ assign_varying_locations(struct gl_context *ctx, if (!tfeedback_decls[i].assign_location(ctx, prog)) { hash_table_dtor(tfeedback_candidates); hash_table_dtor(consumer_inputs); + hash_table_dtor(consumer_interface_inputs); return false; } } hash_table_dtor(tfeedback_candidates); hash_table_dtor(consumer_inputs); + hash_table_dtor(consumer_interface_inputs); if (ctx-Const.DisableVaryingPacking) { /* Transform feedback code assumes varyings are packed, so if the driver -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 15/17] glsl linker: support arrays of interface block instances
With this change we now support interface block arrays. For example, cases like this: out block_name { float f; } block_instance[2]; This allows Mesa to pass the piglit glsl-1.50 test: * execution/interface-blocks-complex-vs-fs.shader_test Signed-off-by: Jordan Justen jordan.l.jus...@intel.com --- src/glsl/lower_named_interface_blocks.cpp | 61 +++-- 1 file changed, 50 insertions(+), 11 deletions(-) diff --git a/src/glsl/lower_named_interface_blocks.cpp b/src/glsl/lower_named_interface_blocks.cpp index 2e0c322..699a345 100644 --- a/src/glsl/lower_named_interface_blocks.cpp +++ b/src/glsl/lower_named_interface_blocks.cpp @@ -107,22 +107,51 @@ flatten_named_interface_blocks_declarations::run(exec_list *instructions) if (var-mode == ir_var_uniform) continue; - const glsl_type *const t = var-type; + const glsl_type * iface_t = var-type; + const glsl_type * array_t = NULL; exec_node *insert_pos = var; - char *iface_field_name; - for (unsigned i = 0; i t-length; i++) { -iface_field_name = ralloc_asprintf(mem_ctx, %s.%s, t-name, - t-fields.structure[i].name); + + if (iface_t-is_array()) { +array_t = iface_t; +iface_t = array_t-fields.array; + } + + assert (iface_t-is_interface()); + + for (unsigned i = 0; i iface_t-length; i++) { +const char * field_name = iface_t-fields.structure[i].name; +char *iface_field_name = + ralloc_asprintf(mem_ctx, %s.%s, + iface_t-name, field_name); ir_variable *found_var = (ir_variable *) hash_table_find(interface_namespace, iface_field_name); if (!found_var) { - ir_variable *new_var = - new(mem_ctx) ir_variable(t-fields.structure[i].type, - ralloc_strdup(mem_ctx, t-fields.structure[i].name), - (ir_variable_mode) var-mode); - new_var-interface_type = t; + ir_variable *new_var; + if (array_t == NULL) { + char *var_name = + ralloc_strdup(mem_ctx, iface_t-fields.structure[i].name); + new_var = + new(mem_ctx) ir_variable(iface_t-fields.structure[i].type, + var_name, + (ir_variable_mode) var-mode); + } else { + const glsl_type *new_array_type = + glsl_type::get_array_instance( +iface_t-fields.structure[i].type, +array_t-length); + char *var_name = + ralloc_asprintf(mem_ctx, %s[%d], + iface_t-fields.structure[i].name, + array_t-length); + new_var = + new(mem_ctx) ir_variable(new_array_type, + var_name, + (ir_variable_mode) var-mode); + } + + new_var-interface_type = iface_t; hash_table_insert(interface_namespace, new_var, iface_field_name); insert_pos-insert_after(new_var); @@ -187,9 +216,19 @@ flatten_named_interface_blocks_declarations::handle_rvalue(ir_rvalue **rvalue) (ir_variable *) hash_table_find(interface_namespace, iface_field_name); assert(found_var); + ir_dereference_variable *deref_var = new(mem_ctx) ir_dereference_variable(found_var); - *rvalue = deref_var; + + ir_dereference_array *deref_array = + ir-record-as_dereference_array(); + if (deref_array != NULL) { + *rvalue = +new(mem_ctx) ir_dereference_array(deref_var, + deref_array-array_index); + } else { + *rvalue = deref_var; + } } } -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 17/17] glsl linker: compare interface blocks during interstage linking
Verify that interface blocks match when linking separate shader stages into a program. Fixes piglit glsl-1.50 tests: * linker/interface-blocks-vs-fs-member-count-mismatch.shader_test * linker/interface-blocks-vs-fs-member-order-mismatch.shader_test Signed-off-by: Jordan Justen jordan.l.jus...@intel.com --- src/glsl/interface_blocks.cpp | 47 +++-- src/glsl/interface_blocks.h |4 src/glsl/linker.cpp |6 ++ 3 files changed, 55 insertions(+), 2 deletions(-) diff --git a/src/glsl/interface_blocks.cpp b/src/glsl/interface_blocks.cpp index 6dfd0c4..b458b59 100644 --- a/src/glsl/interface_blocks.cpp +++ b/src/glsl/interface_blocks.cpp @@ -30,14 +30,21 @@ #include glsl_symbol_table.h #include main/macros.h #include program/hash_table.h +#include linker.h static bool cross_validate_interface_blocks(const gl_shader **shader_list, -unsigned num_shaders) +unsigned num_shaders, +bool interstage) { bool ok = true; glsl_symbol_table interfaces; + /* Interstage linking checks assume 2 shaders. First the producer, and +* then the consumer. +*/ + assert(!interstage || num_shaders == 2); + for (unsigned int i = 0; ok i num_shaders; i++) { if (shader_list[i] == NULL) continue; @@ -52,6 +59,18 @@ cross_validate_interface_blocks(const gl_shader **shader_list, if (iface_type == NULL) continue; + /* If we are checking interstage linking then we assume: + * * The first shader (producer) has i == 0, and for the + *producer we don't need to check input interfaces. + * * The second shader (consumer) has i == 1, and for the + *consumer we don't need to check output interfaces. + */ + if (interstage + ((var-mode == ir_var_shader_in i == 0) || + (var-mode == ir_var_shader_out i == 1)) +) +continue; + const char *iface_name = iface_type-name; const glsl_type *old_iface_type = @@ -70,6 +89,18 @@ cross_validate_interface_blocks(const gl_shader **shader_list, ok = old_iface_type == iface_type; if (!ok) break; + + /* For interstage linking, if the interface is an input, then + * we need to verify that its type matches a previously declared + * output type. + */ + if (interstage var-mode == ir_var_shader_in) { +old_iface_type = + interfaces.get_interface(iface_name, ir_var_shader_out); +ok = old_iface_type == iface_type; +if (!ok) + break; + } } } @@ -81,6 +112,18 @@ validate_intrastage_interface_blocks(const gl_shader **shader_list, unsigned num_shaders) { return cross_validate_interface_blocks(shader_list, - num_shaders); + num_shaders, + false); +} + +bool +validate_interstage_interface_blocks(const gl_shader *producer, + const gl_shader *consumer) +{ + const gl_shader *shader_list[] = { producer, consumer }; + + return cross_validate_interface_blocks((const gl_shader **) shader_list, + ARRAY_SIZE(shader_list), + true); } diff --git a/src/glsl/interface_blocks.h b/src/glsl/interface_blocks.h index 4c37c02..58c847c 100644 --- a/src/glsl/interface_blocks.h +++ b/src/glsl/interface_blocks.h @@ -29,4 +29,8 @@ bool validate_intrastage_interface_blocks(const gl_shader **shader_list, unsigned num_shaders); +bool +validate_interstage_interface_blocks(const gl_shader *producer, + const gl_shader *consumer); + #endif /* GLSL_INTERFACE_BLOCKS_H */ diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp index 187bc4b..7d13a5e 100644 --- a/src/glsl/linker.cpp +++ b/src/glsl/linker.cpp @@ -1729,6 +1729,12 @@ link_shaders(struct gl_context *ctx, struct gl_shader_program *prog) if (prog-_LinkedShaders[i] == NULL) continue; + if (!validate_interstage_interface_blocks(prog-_LinkedShaders[prev], + prog-_LinkedShaders[i])) { +linker_error(prog, interface block mismatch between shader stages\n); +goto done; + } + if (!cross_validate_outputs_to_inputs(prog, prog-_LinkedShaders[prev], prog-_LinkedShaders[i])) -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org
Re: [Mesa-dev] [PATCH 0/5] Head-up display for Gallium DRI2 drivers
Pushed, except for creating a page in mesa/docs. I'll do that some time later. Marek On Mon, Mar 25, 2013 at 3:45 PM, Brian Paul bri...@vmware.com wrote: On 03/22/2013 05:50 PM, Marek Olšák wrote: Hi everyone, one image is better than a thousand words: http://people.freedesktop.org/~mareko/gallium-hud.png So there you have it. This gallium module can draw transparent graphs and text on top of what apps are rendering. By default, it can show framerate, cpu load (each CPU or the average of all of them), and the results of PRIMITIVES_GENERATED and OCCLUSION_COUNTER queries (the latter is printed as pixels rendered). Furthermore, there is a new interface for gallium allowing drivers to expose driver-specific queries in a way similar to GL_AMD_performance_monitor. It uses the existing pipe_query interface. Drivers can use this to expose performance counters or other internal information. BTW, I guess I should mention that I ripped the font off from freeglut. The HUD is controlled by the GALLIUM_HUD environment variable, where you can list names of data sources. Set GALLIUM_HUD=help for more info, it also prints all available names (including the driver-specific queries). This is what I used for the image above: GALLIUM_HUD=cpu0+cpu1+cpu2+cpu3:100,cpu:100,fps;draw-calls,requested-VRAM+requested-GTT,pixels-rendered So basically I'd like to be able to display as much useful info in the HUD as possible. We should definitely add some ioctls for querying useful stats from the kernel DRM/TTM and be able to see in real time what happens in Mesa and the kernel. It's pretty easy - just expose a new query through the gallium interface and the HUD will automatically pick it up. (for moderators: the second patch might get stuck in the moderation queue) This looks really great, Marek! Could you update the gallium docs with your interface additions? Could you also create a Mesa/docs/ page which describes how this works and how to use it? I can't wait to try this with llvmpipe and the svga driver. I'll try to review your patches ASAP... -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Very low framerate when recording desktop content in Weston using mesa git on Radeon 5770 (glReadPixels slow path)
Marek, do you have an idea on where the currency bottleneck is? I just did a profiling with sysprof, zooming in on the desktop in Weston and moving the mouse wildly around, so that the buffer is completely changed for every frame. I got around 5 fps, which isn't *that* much, but still an order of magnitude better than without your patches. sysprof says there is 100% CPU usage, but unlike the previous 0.5-FPS recording, it's not in a single function, but spread out over several functions: 35% weston_recorder_frame_notify 11% __memcpy_ssse3 4.5% clear_page_c 4.3% output_run Although I'm not completely sure I'm reading the sysprof output right. weston_recorder_frame_notify, for example, has 35% CPU usage, but none of its child functions has any significant CPU usage. I presume the CPU usage in that function is from calling glReadPixels, although that's not apparent from sysprof: weston_recorder_frame_notify 39.15% 39.15% - - kernel - - 0.00% 0.01% ret_from_intr 0.00% 0.01% __irqentry_text_start 0.00% 0.01% irq_exit 0.00% 0.01% do_softirq 0.00% 0.01% call_softirq 0.00% 0.01% __do_softirq0.00% 0.01% blk_done_softirq 0.00% 0.01% scsi_softirq_done 0.00% 0.01% scsi_finish_command 0.00% 0.01% scsi_io_completion 0.00% 0.01% blk_end_request 0.00% 0.01% blk_end_bidi_request0.00% 0.01% blk_update_bidi_request 0.00% 0.01% blk_update_request 0.00% 0.01% req_bio_endio.isra.46 0.00% 0.01% bio_endio 0.00% 0.01% end_swap_bio_write0.00% 0.01% end_page_writeback 0.00% 0.01% rotate_reclaimable_page 0.01% 0.01% Another possible bottleneck is simply disk access, although it doesn't seem to be relevant on my system (since I have 100% CPU usage). The 36-second recording I made was 1.3 GB in size, so that's around 36 MB/s. Med venlig hilsen, Rune Kjær Svendsen Østerbrogade 111, 3. - 302 2100 København Ø Tlf.: 2835 0726 On Mon, Mar 18, 2013 at 1:20 AM, Marek Olšák mar...@gmail.com wrote: Slowness is not usually a bug. I guess it can be optimized even more. It depends on where the bottleneck is now. Marek On Sun, Mar 17, 2013 at 10:14 PM, Rune Kjær Svendsen runesv...@gmail.com wrote: Thank you very much! This is much better. It's gone from 0.5-ish FPS when zooming in to around 10 FPS, depending on screen content. So I figure this isn't a bug? I assumed it was a bug, but is the case simply that an efficient glReadPixels path for radeon/gallium doesn't exist? The patch set sure helps in that regard, although it'd be really nice to get 30 FPS consistently, if at all possible. Thanks again. /Rune On Sun, Mar 17, 2013 at 6:46 PM, Andreas Boll andreas.boll@gmail.com wrote: 2013/3/17 Rune Kjær Svendsen runesv...@gmail.com: Hello list I'm having problems recording the desktop content using the Weston compositor's built-in recording function. When I start a recording and do something that changes a lot of screen content (like zooming in on the desktop, for example), I get around 0.5 FPS. Using sysprof, I can see that ~98% of CPU is used in the function unpack_XRGB(). krh has told me this is caused by glReadPixels going through a slowpath. I have a Radeon HD 5770 GPU and I'm using mesa git (I've tried the mesa version in the Ubuntu 12.10 repos, and the xorg-edgers PPA, same result). Does anyone know what the issue could be, or how to debug the problem further? This patch series [1] should help. You might want to try it. [1] http://lists.freedesktop.org/archives/mesa-dev/2013-March/036214.html Doing some debugging, it seems the call to ctx-Driver.ReadPixels() in _mesa_ReadnPixelsARB leads to _mesa_readpixels() being called in readpix.c. I'm attaching some output of gdb that will hopefully be useful. I'm also attaching the debug terminal output of running Weston with the DRM backend. Let me know if I can provide other useful information.