Re: [Mesa-dev] [PATCH 01/12] build: Rename sources.mak - Makefile.sources
Assuming this matched your make-dist-1 branch, Series Reviewed-by: Jordan Justen jordan.l.jus...@intel.com On Thu, Apr 11, 2013 at 4:29 PM, Matt Turner matts...@gmail.com wrote: For the sake of consistency. Tested-by: Emil Velikov emil.l.veli...@gmail.com Reviewed-and-Tested-by: Andreas Boll andreas.boll@gmail.com --- src/glx/apple/Makefile | 2 +- src/mapi/glapi/Makefile.am | 4 +- src/mapi/glapi/Makefile.sources | 19 ++ src/mapi/glapi/sources.mak | 19 -- src/mapi/mapi/Makefile.sources | 36 src/mapi/mapi/sources.mak | 36 src/mapi/shared-glapi/Makefile.am | 2 +- src/mapi/vgapi/Makefile.am | 2 +- src/mesa/Android.libmesa_dricore.mk | 2 +- src/mesa/Android.libmesa_st_mesa.mk | 2 +- src/mesa/Makefile.am| 2 +- src/mesa/Makefile.sources | 350 src/mesa/libdricore/Makefile.am | 2 +- src/mesa/program/Android.mk | 4 +- src/mesa/program/Makefile.am| 2 +- src/mesa/sources.mak| 350 16 files changed, 417 insertions(+), 417 deletions(-) create mode 100644 src/mapi/glapi/Makefile.sources delete mode 100644 src/mapi/glapi/sources.mak create mode 100644 src/mapi/mapi/Makefile.sources delete mode 100644 src/mapi/mapi/sources.mak create mode 100644 src/mesa/Makefile.sources delete mode 100644 src/mesa/sources.mak diff --git a/src/glx/apple/Makefile b/src/glx/apple/Makefile index f6faa1e..7dab068 100644 --- a/src/glx/apple/Makefile +++ b/src/glx/apple/Makefile @@ -58,7 +58,7 @@ SOURCES = \ ../xfont.c \ ../applegl_glx.c -include $(TOP)/src/mesa/sources.mak +include $(TOP)/src/mesa/Makefile.sources # override GLAPI_LIB GLAPI_LIB = $(TOP)/src/mapi/glapi/libglapi.a diff --git a/src/mapi/glapi/Makefile.am b/src/mapi/glapi/Makefile.am index bdb527d..cf2602a 100644 --- a/src/mapi/glapi/Makefile.am +++ b/src/mapi/glapi/Makefile.am @@ -20,8 +20,8 @@ # IN THE SOFTWARE. TOP = $(top_srcdir) -include sources.mak -include ../mapi/sources.mak +include Makefile.sources +include ../mapi/Makefile.sources AM_CPPFLAGS = \ $(DEFINES) \ diff --git a/src/mapi/glapi/Makefile.sources b/src/mapi/glapi/Makefile.sources new file mode 100644 index 000..58d28c5 --- /dev/null +++ b/src/mapi/glapi/Makefile.sources @@ -0,0 +1,19 @@ +# src/mapi/glapi/Makefile.sources + +GLAPI_SOURCES = \ + glapi_dispatch.c \ + glapi_entrypoint.c \ + glapi_gentable.c \ + glapi_getproc.c \ + glapi_nop.c \ + glthread.c \ + glapi.c + +X86_API = \ + glapi_x86.S + +X86_64_API = \ + glapi_x86-64.S + +SPARC_API =\ + glapi_sparc.S diff --git a/src/mapi/glapi/sources.mak b/src/mapi/glapi/sources.mak deleted file mode 100644 index aa8a4d4..000 --- a/src/mapi/glapi/sources.mak +++ /dev/null @@ -1,19 +0,0 @@ -# src/mapi/glapi/sources.mak - -GLAPI_SOURCES = \ - glapi_dispatch.c \ - glapi_entrypoint.c \ - glapi_gentable.c \ - glapi_getproc.c \ - glapi_nop.c \ - glthread.c \ - glapi.c - -X86_API = \ - glapi_x86.S - -X86_64_API = \ - glapi_x86-64.S - -SPARC_API =\ - glapi_sparc.S diff --git a/src/mapi/mapi/Makefile.sources b/src/mapi/mapi/Makefile.sources new file mode 100644 index 000..a2f6c71 --- /dev/null +++ b/src/mapi/mapi/Makefile.sources @@ -0,0 +1,36 @@ +# src/mapi/mapi/Makefile.sources +# +# mapi may be used in several ways +# +# - In default mode, mapi implements the interface defined by mapi.h. To use +#this mode, compile MAPI_FILES. +# +# - In util mode, mapi provides utility functions for use with glapi. To use +#this mode, compile MAPI_UTIL_FILES with MAPI_MODE_UTIL defined. +# +# - In glapi mode, mapi implements the interface defined by glapi.h. To use +#this mode, compile MAPI_GLAPI_FILES with MAPI_MODE_GLAPI defined. +# +# - In bridge mode, mapi provides entry points calling into glapi. To use +#this mode, compile MAPI_BRIDGE_FILES with MAPI_MODE_BRIDGE defined. + +MAPI_UTIL_FILES = \ + $(TOP)/src/mapi/mapi/u_current.c \ + $(TOP)/src/mapi/mapi/u_execmem.c + +MAPI_FILES = \ + $(TOP)/src/mapi/mapi/entry.c \ + $(TOP)/src/mapi/mapi/mapi.c \ + $(TOP)/src/mapi/mapi/stub.c \ + $(TOP)/src/mapi/mapi/table.c \ + $(MAPI_UTIL_FILES) + +MAPI_GLAPI_FILES = \ + $(TOP)/src/mapi/mapi/entry.c \ + $(TOP)/src/mapi/mapi/mapi_glapi.c \ + $(TOP)/src/mapi/mapi/stub.c \ + $(TOP)/src/mapi/mapi/table.c \ + $(MAPI_UTIL_FILES) + +MAPI_BRIDGE_FILES = \ + $(TOP)/src/mapi/mapi/entry.c diff --git a/src/mapi/mapi/sources.mak
[Mesa-dev] GSoC - Introduction and Project Discussion - Find common patterns in real GLSL shaders
Hi all
I am interested to participate in GSoC this year in X.org. I have gone
through the proposed ideas and I am interested in working on finding common
patterns in real GLSL shaders.
I understand that this is a datamining problem where we mine patterns in
the shaders. So, how do I go ahead now?
I have searched for sample GLSL shaders on the internet and found this on
on the Wikipedia page related to GLSL
#version 400
layout( vertices = 3 ) out;void main( ){
gl_out[ gl_InvocationID ].gl_Position = gl_in[ gl_InvocationID
].gl_Position;
gl_TessLevelOuter[0] = 1.0;
gl_TessLevelOuter[1] = 1.0;
gl_TessLevelOuter[2] = 1.0;
gl_TessLevelInner[0] = 1.0;
gl_TessLevelInner[1] = 1.0;}
To mine text like this, I think, we must tokenize the shader properly (I
will have to know more about GLSL before I define what this properly means)
and then mine the patterns.
Let me know if I am on the right path and also how to go ahead with this
project!
I would like to introduce myself here.
I am Sreyantha Chary (lets make it Sreyanth), a 3rd year undergrad majoring
in Computer Engineering at the National Institute of Technology Karnataka.
I am proficient in C. I wont consider myself an expert in python
programming, but yeah, I am good enough to work on intermediate projects.
Research wise, I am into Machine Learning, Information Retrieval and Data
Mining. And coding wise, I try crazy stuff. I am updating my appspot site
right now, so it takes time to see my code online.
You can see my CV here:
http://sreyanth.appspot.com/docs/SreyanthaChary_CV.pdf
Let me know how I can turn this project idea into a successful GSoC offer!
Thanks in advance. Thanks for your time!
*
Thanks and regards
*
*Mora Sreyantha Chary*
*Computer Engineering '14*
*National Institute of Technology Karnataka*
*Surathkal, India 575 025*
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] GL/GLSL tests for GL 3.2, 3.3 query
I wanted to know if it would be possible for me to do the project if I am a good coder in the C language but have never used OpenGL.If you would guide me from were to read then I would definitely do that . ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/12] build: Rename sources.mak - Makefile.sources
On Thu, Apr 11, 2013 at 11:35 PM, Jordan Justen jljus...@gmail.com wrote: Assuming this matched your make-dist-1 branch, It does. Series Reviewed-by: Jordan Justen jordan.l.jus...@intel.com Thanks! ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] autoconf: enable detection of vdpau and xvmc by default
From: Christian König christian.koe...@amd.com Since we now have UVD support we should enable them by default. Signed-off-by: Christian König christian.koe...@amd.com --- configure.ac |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/configure.ac b/configure.ac index 55ebb07..aa95406 100644 --- a/configure.ac +++ b/configure.ac @@ -1353,10 +1353,10 @@ dnl dnl Gallium G3DVL configuration dnl AC_ARG_ENABLE([gallium-g3dvl], -[AS_HELP_STRING([--enable-gallium-g3dvl], -[build gallium g3dvl @:@default=disabled@:@])], +[AS_HELP_STRING([--disable-gallium-g3dvl], +[build gallium g3dvl @:@default=enabled@:@])], [enable_gallium_g3dvl=$enableval], -[enable_gallium_g3dvl=no]) +[enable_gallium_g3dvl=yes]) if test x$enable_gallium_g3dvl = xyes; then if test x$with_gallium_drivers = x; then AC_MSG_ERROR([cannot enable G3DVL without Gallium]) -- 1.7.9.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] gallivm/gs: fix the end primitive calls
- Original Message -
The issue with SOA execution and end_primitive opcode is that it
can be executed both when we haven't emitted any vertices, in
which case we don't want to emit an empty primitive, and when
the execution mask is zero and the execution should be skipped. We
handled only the latter of those conditions. Now we're combining the
execution mask with a mask created from emitted vertices to handle
both cases. As a result we don't need the pending_end_primitive
flag which was broken because it was static and could be affected
by both above mentioned conditions at run-time.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi.h |6 --
src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c | 71
---
2 files changed, 50 insertions(+), 27 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi.h
b/src/gallium/auxiliary/gallivm/lp_bld_tgsi.h
index 23ccacc..f1b1d79 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi.h
+++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi.h
@@ -396,12 +396,6 @@ struct lp_build_tgsi_soa_context
LLVMValueRef emitted_prims_vec_ptr;
LLVMValueRef total_emitted_vertices_vec_ptr;
LLVMValueRef emitted_vertices_vec_ptr;
- /* if a shader doesn't have ENDPRIM instruction but it has
-* a number of EMIT instructions it means the END instruction
-* implicitly invokes ENDPRIM. handle this via a flag here
-* in the future maybe we can enforce TGSI to always have
-* an explicit ENDPRIM */
- boolean pending_end_primitive;
LLVMValueRef consts_ptr;
const LLVMValueRef *pos;
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
index 8a29635..b54fc13 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
@@ -65,6 +65,7 @@
#include lp_bld_sample.h
#include lp_bld_struct.h
+/*#define DUMP_GS_EMITS 1*/
#define DUMP_GS_EMITS 0
static void lp_exec_mask_init(struct lp_exec_mask *mask, struct
lp_build_context *bld)
{
@@ -2278,27 +2279,25 @@ emit_vertex(
increment_vec_ptr_by_mask(bld_base,
bld-total_emitted_vertices_vec_ptr,
masked_ones);
#if DUMP_GS_EMITS
- lp_build_print_value(bld-bld_base.base.gallivm, +++ emit vertex
masked ones = ,
+ lp_build_print_value(bld-bld_base.base.gallivm,
++++ emit vertex masked ones = ,
masked_ones);
- lp_build_print_value(bld-bld_base.base.gallivm, +++ emit vertex
emitted = ,
+ lp_build_print_value(bld-bld_base.base.gallivm,
++++ emit vertex emitted = ,
total_emitted_vertices_vec);
#endif
- bld-pending_end_primitive = TRUE;
}
}
static void
-end_primitive(
- const struct lp_build_tgsi_action * action,
- struct lp_build_tgsi_context * bld_base,
- struct lp_build_emit_data * emit_data)
+end_primitive_masked(struct lp_build_tgsi_context * bld_base,
+ LLVMValueRef masked_ones)
{
struct lp_build_tgsi_soa_context * bld = lp_soa_context(bld_base);
LLVMBuilderRef builder = bld-bld_base.base.gallivm-builder;
if (bld-gs_iface-end_primitive) {
- LLVMValueRef masked_ones = mask_to_one_vec(bld_base);
LLVMValueRef emitted_vertices_vec =
LLVMBuildLoad(builder, bld-emitted_vertices_vec_ptr, );
LLVMValueRef emitted_prims_vec =
@@ -2309,23 +2308,55 @@ end_primitive(
emitted_prims_vec);
#if DUMP_GS_EMITS
- lp_build_print_value(bld-bld_base.base.gallivm, +++ end prim masked
ones = ,
+ lp_build_print_value(bld-bld_base.base.gallivm,
++++ end prim masked ones = ,
masked_ones);
- lp_build_print_value(bld-bld_base.base.gallivm, +++ end prim
emitted verts1 = ,
+ lp_build_print_value(bld-bld_base.base.gallivm,
++++ end prim emitted verts1 = ,
emitted_vertices_vec);
- lp_build_print_value(bld-bld_base.base.gallivm, +++ end prim
emitted prims1 = ,
- LLVMBuildLoad(builder,
bld-emitted_prims_vec_ptr, ));
+ lp_build_print_value(bld-bld_base.base.gallivm,
++++ end prim emitted prims1 = ,
+ LLVMBuildLoad(builder,
+ bld-emitted_prims_vec_ptr, ));
#endif
increment_vec_ptr_by_mask(bld_base, bld-emitted_prims_vec_ptr,
masked_ones);
clear_uint_vec_ptr_from_mask(bld_base, bld-emitted_vertices_vec_ptr,
masked_ones);
#if DUMP_GS_EMITS
- lp_build_print_value(bld-bld_base.base.gallivm, +++ end prim
Re: [Mesa-dev] [PATCH 2/2] draw: implement pipeline statistics in the draw module
- Original Message -
This is a basic implementation of the pipeline statistics in the
draw module. The interface is similar to the stream output statistics
and also requires that the callers explicitly enable it.
Included is the implementation of the interface in llvmpipe and
softpipe. Only softpipe enables the pipeline statistics capability
though because llvmpipe is lacking gathering of the fragment shading
and rasterization statistics.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/draw/draw_context.c | 16 +
src/gallium/auxiliary/draw/draw_context.h |7
src/gallium/auxiliary/draw/draw_gs.c | 24 +++---
src/gallium/auxiliary/draw/draw_private.h |3 ++
src/gallium/auxiliary/draw/draw_pt.c |6
src/gallium/auxiliary/draw/draw_pt_emit.c | 21
.../auxiliary/draw/draw_pt_fetch_shade_pipeline.c |6
.../draw/draw_pt_fetch_shade_pipeline_llvm.c |7
src/gallium/auxiliary/draw/draw_vbuf.h |8 +
src/gallium/auxiliary/util/u_prim.h| 35
+++-
src/gallium/drivers/llvmpipe/lp_context.h |3 ++
src/gallium/drivers/llvmpipe/lp_draw_arrays.c |6
src/gallium/drivers/llvmpipe/lp_query.c| 16 +
src/gallium/drivers/llvmpipe/lp_query.h|2 ++
src/gallium/drivers/llvmpipe/lp_rast.c |2 ++
src/gallium/drivers/llvmpipe/lp_setup_vbuf.c | 23 +
src/gallium/drivers/softpipe/sp_context.h |3 ++
src/gallium/drivers/softpipe/sp_draw_arrays.c |7
src/gallium/drivers/softpipe/sp_prim_vbuf.c| 23 +
src/gallium/drivers/softpipe/sp_quad_fs.c |5 +++
src/gallium/drivers/softpipe/sp_query.c| 18 +-
src/gallium/drivers/softpipe/sp_screen.c |2 +-
src/gallium/drivers/softpipe/sp_setup.c|4 +++
23 files changed, 226 insertions(+), 21 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_context.c
b/src/gallium/auxiliary/draw/draw_context.c
index 2fb9bac..0f98021 100644
--- a/src/gallium/auxiliary/draw/draw_context.c
+++ b/src/gallium/auxiliary/draw/draw_context.c
@@ -842,3 +842,19 @@ draw_get_shader_param(unsigned shader, enum
pipe_shader_cap param)
return draw_get_shader_param_no_llvm(shader, param);
}
+/**
+ * Enables or disables collection of statistics.
+ *
+ * Draw module is capable of generating statistics for the vertex
+ * processing pipeline. Collection of that data isn't free and so
+ * it's disabled by default. The users of the module can enable
+ * (or disable) this functionality through this function.
+ * The actual data will be emitted through the VBUF interface,
+ * the 'pipeline_statistics' callback to be exact.
I wonder if, instead of sending statistics down the pipe with through vbuf, it
would be simpler to just have
void draw_statistics_start(struct draw_context *draw)
void draw_statistics_end(struct draw_context *draw,
struct pipe_query_data_pipeline_statistics
*out_statistics)
It seems to me that thist would map nicely to the pipe query calls. Of course,
the setup/fragment statistics would need to be filled independently, and the
draw module would need to flush in these calls.
This would also allow to accumulate multiple statistics across multiple draws
nicely, and probably less overhead.
Jose
+ */
+void
+draw_collect_pipeline_statistics(struct draw_context *draw,
+ boolean enable)
+{
+ draw-collect_statistics = enable;
+}
diff --git a/src/gallium/auxiliary/draw/draw_context.h
b/src/gallium/auxiliary/draw/draw_context.h
index 1d25b7f..94fac88 100644
--- a/src/gallium/auxiliary/draw/draw_context.h
+++ b/src/gallium/auxiliary/draw/draw_context.h
@@ -264,6 +264,13 @@ void draw_set_driver_clipping( struct draw_context
*draw,
void draw_set_force_passthrough( struct draw_context *draw,
boolean enable );
+
+/***
+ * Draw statistics
+ */
+void draw_collect_pipeline_statistics(struct draw_context *draw,
+ boolean enable);
+
/***
* Draw pipeline
*/
diff --git a/src/gallium/auxiliary/draw/draw_gs.c
b/src/gallium/auxiliary/draw/draw_gs.c
index 70db837..ce820ef 100644
--- a/src/gallium/auxiliary/draw/draw_gs.c
+++ b/src/gallium/auxiliary/draw/draw_gs.c
@@ -353,6 +353,10 @@ static void gs_flush(struct draw_geometry_shader
*shader)
unsigned input_primitives = shader-fetched_prim_count;
+ if (shader-draw-collect_statistics) {
+ shader-draw-statistics.gs_invocations +=
[Mesa-dev] [RESENT] Restructure documents directory
No code change since previous version - just git format-patch was being silly With --find-renames, git produces a more sensible patches (max 90k for patch1) Feel free to commit as I do not have access ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCHv2 2/4] docs: move specs to a separate folder
Handle legacy/obsolete specs as well
List all specs in extensions.html
Mark 'OLD' extensions as obsolete in extensions.html
Update the spec location in old relnotes
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
docs/extensions.html | 34 +-
docs/relnotes/5.1 | 2 +-
docs/{ = specs}/MESA_agp_offset.spec | 0
docs/{ = specs}/MESA_copy_sub_buffer.spec | 0
docs/{ = specs}/MESA_drm_image.spec | 0
docs/{ = specs}/MESA_multithread_makecurrent.spec | 0
docs/{ = specs}/MESA_pack_invert.spec | 0
docs/{ = specs}/MESA_pixmap_colormap.spec | 0
docs/{ = specs}/MESA_release_buffers.spec | 0
docs/{ = specs}/MESA_resize_buffers.spec | 0
docs/{ = specs}/MESA_set_3dfx_mode.spec | 0
docs/{ = specs}/MESA_shader_debug.spec| 0
docs/{ = specs}/MESA_swap_control.spec| 0
docs/{ = specs}/MESA_swap_frame_usage.spec| 0
docs/{ = specs}/MESA_texture_array.spec | 0
docs/{ = specs}/MESA_texture_signed_rgba.spec | 0
docs/{ = specs}/MESA_window_pos.spec | 0
docs/{ = specs}/MESA_ycbcr_texture.spec | 0
.../{ = specs}/OLD/MESA_packed_depth_stencil.spec | 0
docs/{ = specs}/OLD/MESA_program_debug.spec | 0
docs/{ = specs}/OLD/MESA_sprite_point.spec| 0
docs/{ = specs}/OLD/MESA_trace.spec | 0
docs/{ = specs}/WL_bind_wayland_display.spec | 0
docs/{ = specs}/enums.txt | 0
docs/xlibdriver.html | 6 ++--
25 files changed, 25 insertions(+), 17 deletions(-)
rename docs/{ = specs}/MESA_agp_offset.spec (100%)
rename docs/{ = specs}/MESA_copy_sub_buffer.spec (100%)
rename docs/{ = specs}/MESA_drm_image.spec (100%)
rename docs/{ = specs}/MESA_multithread_makecurrent.spec (100%)
rename docs/{ = specs}/MESA_pack_invert.spec (100%)
rename docs/{ = specs}/MESA_pixmap_colormap.spec (100%)
rename docs/{ = specs}/MESA_release_buffers.spec (100%)
rename docs/{ = specs}/MESA_resize_buffers.spec (100%)
rename docs/{ = specs}/MESA_set_3dfx_mode.spec (100%)
rename docs/{ = specs}/MESA_shader_debug.spec (100%)
rename docs/{ = specs}/MESA_swap_control.spec (100%)
rename docs/{ = specs}/MESA_swap_frame_usage.spec (100%)
rename docs/{ = specs}/MESA_texture_array.spec (100%)
rename docs/{ = specs}/MESA_texture_signed_rgba.spec (100%)
rename docs/{ = specs}/MESA_window_pos.spec (100%)
rename docs/{ = specs}/MESA_ycbcr_texture.spec (100%)
rename docs/{ = specs}/OLD/MESA_packed_depth_stencil.spec (100%)
rename docs/{ = specs}/OLD/MESA_program_debug.spec (100%)
rename docs/{ = specs}/OLD/MESA_sprite_point.spec (100%)
rename docs/{ = specs}/OLD/MESA_trace.spec (100%)
rename docs/{ = specs}/WL_bind_wayland_display.spec (100%)
rename docs/{ = specs}/enums.txt (100%)
diff --git a/docs/extensions.html b/docs/extensions.html
index 5d790fb..40f59d3 100644
--- a/docs/extensions.html
+++ b/docs/extensions.html
@@ -23,19 +23,27 @@ The specifications follow.
ul
-lia href=MESA_agp_offset.specMESA_agp_offset.spec/a
-lia href=MESA_copy_sub_buffer.specMESA_copy_sub_buffer.spec/a
-lia href=MESA_packed_depth_stencil.specMESA_packed_depth_stencil.spec/a
-lia href=MESA_pack_invert.specMESA_pack_invert.spec/a
-lia href=MESA_pixmap_colormap.specMESA_pixmap_colormap.spec/a
-lia href=MESA_release_buffers.specMESA_release_buffers.spec/a
-lia href=MESA_resize_buffers.specMESA_resize_buffers.spec/a
-lia href=MESA_set_3dfx_mode.specMESA_set_3dfx_mode.spec/a
-lia href=MESA_sprite_point.specMESA_sprite_point.spec/a (obsolete)
-lia href=MESA_texture_signed_rgba.specMESA_texture_signed_rgba.spec/a
-lia href=MESA_trace.specMESA_trace.spec/a (obsolete)
-lia href=MESA_window_pos.specMESA_window_pos.spec/a
-lia href=MESA_ycbcr_texture.specMESA_ycbcr_texture.spec/a
+lia href=specs/MESA_agp_offset.specMESA_agp_offset.spec/a
+lia href=specs/MESA_copy_sub_buffer.specMESA_copy_sub_buffer.spec/a
+lia href=specs/MESA_drm_image.specMESA_drm_image.spec/a
+lia
href=specs/MESA_multithread_makecurrent.specMESA_multithread_makecurrent.spec/a
+lia
href=specs/OLD/MESA_packed_depth_stencil.specMESA_packed_depth_stencil.spec/a
(obsolete)
+lia href=specs/MESA_pack_invert.specMESA_pack_invert.spec/a
+lia href=specs/MESA_pixmap_colormap.specMESA_pixmap_colormap.spec/a
+lia href=specs/OLD/MESA_program_debug.specMESA_program_debug.spec/a
(obsolete)
+lia href=specs/MESA_release_buffers.specMESA_release_buffers.spec/a
+lia href=specs/MESA_resize_buffers.specMESA_resize_buffers.spec/a
+lia href=specs/MESA_set_3dfx_mode.specMESA_set_3dfx_mode.spec/a
+lia href=specs/MESA_shader_debug.specMESA_shader_debug.spec/a
+lia href=specs/OLD/MESA_sprite_point.specMESA_sprite_point.spec/a
(obsolete)
+lia href=specs/MESA_swap_control.specMESA_swap_control.spec/a
+lia href=specs/MESA_swap_frame_usage.specMESA_swap_frame_usage.spec/a
+lia
[Mesa-dev] [PATCHv2 3/4] docs: Add some missing release notes
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- docs/relnotes.html | 3 +++ 1 file changed, 3 insertions(+) diff --git a/docs/relnotes.html b/docs/relnotes.html index 049a979..819d2ce 100644 --- a/docs/relnotes.html +++ b/docs/relnotes.html @@ -22,6 +22,7 @@ The release notes summarize what's new or changed in each Mesa release. ul lia href=relnotes/9.2.html9.2 release notes/a +lia href=relnotes/9.1.1.html9.1.1 release notes/a lia href=relnotes/9.1.html9.1 release notes/a lia href=relnotes/9.0.3.html9.0.3 release notes/a lia href=relnotes/9.0.2.html9.0.2 release notes/a @@ -83,10 +84,12 @@ Versions of Mesa prior to 6.4 are summarized in the ul lia href=relnotes/6.3.26.3.2 release notes/a +lia href=relnotes/6.3.16.3.1 release notes/a lia href=relnotes/6.36.3 release notes/a lia href=relnotes/6.2.16.2.1 release notes/a lia href=relnotes/6.26.2 release notes/a lia href=relnotes/6.16.1 release notes/a +lia href=relnotes/6.0.16.0.1 release notes/a lia href=relnotes/6.06.0 release notes/a lia href=relnotes/5.15.1 release notes/a lia href=relnotes/5.0.25.0.2 release notes/a -- 1.8.2.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCHv2 4/4] docs: Update 'Making new mesa release'
Add a note to update PACKAGE_VERSION for Android and scons builds Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- docs/devinfo.html | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/devinfo.html b/docs/devinfo.html index 5c03344..7176824 100644 --- a/docs/devinfo.html +++ b/docs/devinfo.html @@ -197,6 +197,8 @@ branch is relevant. dl dtMakefile.am/dt + dtSConstruct/dt + dtAndroid.common.mk/dt ddPACKAGE_VERSION/dd dtconfigure.ac/dt ddAC_INIT/dd -- 1.8.2.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 63435] [Regression since 9.0] Flickering in EGL OpenGL full-screen window with swap interval 1
https://bugs.freedesktop.org/show_bug.cgi?id=63435 --- Comment #2 from post+...@ralfj.de --- This bug also breaks KWin on top of EGL when v-sync is enabled: https://bugs.kde.org/show_bug.cgi?id=318212 -- 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
[Mesa-dev] [Bug 63469] New: OSMesa Gallium llvmpipe VTK Test Failures
https://bugs.freedesktop.org/show_bug.cgi?id=63469 Priority: medium Bug ID: 63469 Assignee: mesa-dev@lists.freedesktop.org Summary: OSMesa Gallium llvmpipe VTK Test Failures Severity: normal Classification: Unclassified OS: Linux (All) Reporter: hob...@ohiou.edu Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Mesa core Product: Mesa Since OSMesa switched to Gallium and defaults to the llvmpipe driver VTK's test : vtkRenderingOpenGLCxx-TestTransformCoordinateUseDouble has been failing. This test has a page on VTK's dashboard : http://open.cdash.org/testSummary.php?project=11name=vtkRenderingOpenGLCxx-TestTransformCoordinateUseDoubledate=2013-04-12 The take home message is that the test passes in my OSMesa-9.1.1 build which uses the Mesa Offscreen driver and fails on all of the builds that use the llvmpipe driver. I played around with different drivers by setting GALLIUM_DRIVER to one llvmpipe or softpipe and used on screen and off screen builds of VTK. I set LIBGL_ALWAYS_SOFTWARE to get one of the software drivers or left it unset to use the nouveau driver on my on screen build. What I got was : OSMesa-9.1.1 offscreen pass OSMesa-git softpipe pass OSMesa-git llvmpipe fail Mesa-9.1.1 softpipe pass Mesa-9.1.1 nouveau pass Mesa-9.1.1 llvmpipe fail Mesa-git softpipe pass Mesa-git nouveau pass Mesa-git llvmpipe fail which says that llvmpipe is the issue. I did a bunch of apitraces and put them here : http://crab-lab.zool.ohiou.edu/kevin/vtk_apitraces.tar.bz2 -- 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] [PATCH] autoconf: enable detection of vdpau and xvmc by default
On Fri, Apr 12, 2013 at 4:26 AM, Christian König deathsim...@vodafone.de wrote: From: Christian König christian.koe...@amd.com Since we now have UVD support we should enable them by default. Signed-off-by: Christian König christian.koe...@amd.com Reviewed-by: Alex Deucher alexander.deuc...@amd.com --- configure.ac |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/configure.ac b/configure.ac index 55ebb07..aa95406 100644 --- a/configure.ac +++ b/configure.ac @@ -1353,10 +1353,10 @@ dnl dnl Gallium G3DVL configuration dnl AC_ARG_ENABLE([gallium-g3dvl], -[AS_HELP_STRING([--enable-gallium-g3dvl], -[build gallium g3dvl @:@default=disabled@:@])], +[AS_HELP_STRING([--disable-gallium-g3dvl], +[build gallium g3dvl @:@default=enabled@:@])], [enable_gallium_g3dvl=$enableval], -[enable_gallium_g3dvl=no]) +[enable_gallium_g3dvl=yes]) if test x$enable_gallium_g3dvl = xyes; then if test x$with_gallium_drivers = x; then AC_MSG_ERROR([cannot enable G3DVL without Gallium]) -- 1.7.9.5 ___ 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 2/2] draw: implement pipeline statistics in the draw module
- Original Message -
I wonder if, instead of sending statistics down the pipe with through vbuf,
it would be simpler to just have
void draw_statistics_start(struct draw_context *draw)
void draw_statistics_end(struct draw_context *draw,
struct pipe_query_data_pipeline_statistics
*out_statistics)
It seems to me that thist would map nicely to the pipe query calls. Of
course, the setup/fragment statistics would need to be filled independently,
and the draw module would need to flush in these calls.
I started this way and ended up rewriting it because I didn't like the fact
that the interface was different than for the stream-output queries. I figured
that if we'll be switching we'll need to switch both, otherwise the interface
is just going to be a mess. Also, from the users of the module it comes down to
the same thing - that draw module gives it the statistics for the current run,
how the callers handle that data is really independent of the interface.
This would also allow to accumulate multiple statistics across multiple draws
nicely, and probably less overhead.
That's a feature that's important. I implemented it on top of this patch with
the simple diff I'm attaching (I'd merge them both into a single pass but it's
going to be easier for everyone to see what's going on with just the diff).
zdiff --git a/src/gallium/drivers/llvmpipe/lp_draw_arrays.c b/src/gallium/drivers/llvmpipe/lp_draw_arrays.c
index 8b7903b..e8a5880 100644
--- a/src/gallium/drivers/llvmpipe/lp_draw_arrays.c
+++ b/src/gallium/drivers/llvmpipe/lp_draw_arrays.c
@@ -108,10 +108,6 @@ llvmpipe_draw_vbo(struct pipe_context *pipe, const struct pipe_draw_info *info)
draw_vs_attach_so(lp-vs-draw_data, lp-gs-shader.stream_output);
}
}
- if (lp-active_statistics_queries) {
- memset(lp-pipeline_statistics, 0,
- sizeof(lp-pipeline_statistics));
- }
draw_collect_pipeline_statistics(draw,
lp-active_statistics_queries 0);
diff --git a/src/gallium/drivers/llvmpipe/lp_query.c b/src/gallium/drivers/llvmpipe/lp_query.c
index 319a070..96e1e3f 100644
--- a/src/gallium/drivers/llvmpipe/lp_query.c
+++ b/src/gallium/drivers/llvmpipe/lp_query.c
@@ -195,7 +195,12 @@ llvmpipe_begin_query(struct pipe_context *pipe, struct pipe_query *q)
}
if (pq-type == PIPE_QUERY_PIPELINE_STATISTICS) {
- memset(pq-stats, 0, sizeof(pq-stats));
+ /* reset our cache */
+ if (llvmpipe-active_statistics_queries == 0) {
+ memset(llvmpipe-pipeline_statistics, 0,
+sizeof(llvmpipe-pipeline_statistics));
+ }
+ memcpy(pq-stats, llvmpipe-pipeline_statistics, sizeof(pq-stats));
llvmpipe-active_statistics_queries++;
}
@@ -228,7 +233,23 @@ llvmpipe_end_query(struct pipe_context *pipe, struct pipe_query *q)
}
if (pq-type == PIPE_QUERY_PIPELINE_STATISTICS) {
- pq-stats = llvmpipe-pipeline_statistics;
+ pq-stats.ia_vertices =
+ llvmpipe-pipeline_statistics.ia_vertices - pq-stats.ia_vertices;
+ pq-stats.ia_primitives =
+ llvmpipe-pipeline_statistics.ia_primitives - pq-stats.ia_primitives;
+ pq-stats.vs_invocations =
+ llvmpipe-pipeline_statistics.vs_invocations - pq-stats.vs_invocations;
+ pq-stats.gs_invocations =
+ llvmpipe-pipeline_statistics.gs_invocations - pq-stats.gs_invocations;
+ pq-stats.gs_primitives =
+ llvmpipe-pipeline_statistics.gs_primitives - pq-stats.gs_primitives;
+ pq-stats.c_invocations =
+ llvmpipe-pipeline_statistics.c_invocations - pq-stats.c_invocations;
+ pq-stats.c_primitives =
+ llvmpipe-pipeline_statistics.c_primitives - pq-stats.c_primitives;
+ pq-stats.ps_invocations =
+ llvmpipe-pipeline_statistics.ps_invocations - pq-stats.ps_invocations;
+
llvmpipe-active_statistics_queries--;
}
diff --git a/src/gallium/drivers/llvmpipe/lp_setup_vbuf.c b/src/gallium/drivers/llvmpipe/lp_setup_vbuf.c
index f2a1f21..8173994 100644
--- a/src/gallium/drivers/llvmpipe/lp_setup_vbuf.c
+++ b/src/gallium/drivers/llvmpipe/lp_setup_vbuf.c
@@ -555,17 +555,17 @@ lp_setup_pipeline_statistics(
struct lp_setup_context *setup = lp_setup_context(vbr);
struct llvmpipe_context *llvmpipe = llvmpipe_context(setup-pipe);
- llvmpipe-pipeline_statistics.ia_vertices =
+ llvmpipe-pipeline_statistics.ia_vertices +=
stats-ia_vertices;
- llvmpipe-pipeline_statistics.ia_primitives =
+ llvmpipe-pipeline_statistics.ia_primitives +=
stats-ia_primitives;
- llvmpipe-pipeline_statistics.vs_invocations =
+ llvmpipe-pipeline_statistics.vs_invocations +=
stats-vs_invocations;
- llvmpipe-pipeline_statistics.gs_invocations =
+ llvmpipe-pipeline_statistics.gs_invocations +=
stats-gs_invocations;
- llvmpipe-pipeline_statistics.gs_primitives =
+ llvmpipe-pipeline_statistics.gs_primitives +=
[Mesa-dev] [Bug 63472] New: OSMesa Gallium Segfault in VTK Test
https://bugs.freedesktop.org/show_bug.cgi?id=63472 Priority: medium Bug ID: 63472 Assignee: mesa-dev@lists.freedesktop.org Summary: OSMesa Gallium Segfault in VTK Test Severity: normal Classification: Unclassified OS: Linux (All) Reporter: hob...@ohiou.edu Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Mesa core Product: Mesa Created attachment 77885 -- https://bugs.freedesktop.org/attachment.cgi?id=77885action=edit gdb backtrace of segfaulting test Since OSMesa Switched to Gallium The VTK test : vtkRenderingVolumePython-cursor3D has been segfaulting on one of the two machines which run the test with OSMesa from git. I ran the test in gdb and got the backtrace in the attached vtk_osmesa_backtrace.txt On a hunch I tried setting breakpoints at cso_release_all and vtkOSOpenGLRenderWindow::DestroyOffScreenWindow but they are entered only once. -- 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
[Mesa-dev] [Bug 63435] [Regression since 9.0] Flickering in EGL OpenGL full-screen window with swap interval 1
https://bugs.freedesktop.org/show_bug.cgi?id=63435 Hrvoje Senjan hrvoje.sen...@gmail.com changed: What|Removed |Added CC||hrvoje.sen...@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
[Mesa-dev] [PATCH] r600/uvd: cleanup disabling tiling on pre EG asics
From: Christian König christian.koe...@amd.com
Set transfer flag instead of fiddling with the tilling params directly.
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/drivers/r600/r600_uvd.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_uvd.c
b/src/gallium/drivers/r600/r600_uvd.c
index bdda7e1..dafddfa 100644
--- a/src/gallium/drivers/r600/r600_uvd.c
+++ b/src/gallium/drivers/r600/r600_uvd.c
@@ -76,6 +76,8 @@ struct pipe_video_buffer *r600_video_buffer_create(struct
pipe_context *pipe,
template.height = align(tmpl-height / depth, VL_MACROBLOCK_HEIGHT);
vl_vide_buffer_template(templ, template, resource_formats[0], depth,
PIPE_USAGE_STATIC, 0);
+ if (ctx-chip_class EVERGREEN)
+ templ.flags = R600_RESOURCE_FLAG_TRANSFER;
resources[0] = (struct r600_texture *)
pipe-screen-resource_create(pipe-screen, templ);
if (!resources[0])
@@ -83,6 +85,8 @@ struct pipe_video_buffer *r600_video_buffer_create(struct
pipe_context *pipe,
if (resource_formats[1] != PIPE_FORMAT_NONE) {
vl_vide_buffer_template(templ, template, resource_formats[1],
depth, PIPE_USAGE_STATIC, 1);
+ if (ctx-chip_class EVERGREEN)
+ templ.flags = R600_RESOURCE_FLAG_TRANSFER;
resources[1] = (struct r600_texture *)
pipe-screen-resource_create(pipe-screen, templ);
if (!resources[1])
@@ -91,6 +95,8 @@ struct pipe_video_buffer *r600_video_buffer_create(struct
pipe_context *pipe,
if (resource_formats[2] != PIPE_FORMAT_NONE) {
vl_vide_buffer_template(templ, template, resource_formats[2],
depth, PIPE_USAGE_STATIC, 2);
+ if (ctx-chip_class EVERGREEN)
+ templ.flags = R600_RESOURCE_FLAG_TRANSFER;
resources[2] = (struct r600_texture *)
pipe-screen-resource_create(pipe-screen, templ);
if (!resources[2])
@@ -103,11 +109,6 @@ struct pipe_video_buffer *r600_video_buffer_create(struct
pipe_context *pipe,
pbs[i] = resources[i]-resource.buf;
surfaces[i] = resources[i]-surface;
-
- if (ctx-chip_class EVERGREEN) {
- resources[i]-array_mode[0] =
V_038000_ARRAY_LINEAR_ALIGNED;
- resources[i]-surface.level[0].mode =
RADEON_SURF_MODE_LINEAR_ALIGNED;
- }
}
ruvd_join_surfaces(ctx-ws, templ.bind, pbs, surfaces);
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 53835] [build error] /usr/bin/ld: cannot find -l-O2
https://bugs.freedesktop.org/show_bug.cgi?id=53835 rsw ask...@qq.com changed: What|Removed |Added CC||ask...@qq.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
[Mesa-dev] [Bug 63476] New: nothing find
https://bugs.freedesktop.org/show_bug.cgi?id=63476 Priority: medium Bug ID: 63476 Assignee: mesa-dev@lists.freedesktop.org Summary: nothing find Severity: blocker Classification: Unclassified OS: All Reporter: ask...@qq.com Hardware: x86-64 (AMD64) Status: NEW Version: 9.1 Component: GLU Product: Mesa -- 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
[Mesa-dev] [PATCH 00/12] RFC: add support of ARB_separate_shader_object extensions V2
V2: * fix ralloc memory leak * follow mesa formating rule * rename Pipeline.PipelineObj to Pipeline.Current * rename gl_shader_state to gl_pipeline_object * rebase on current mesa Please find an implementation of the ARB_separate_shader_objects extensions. I concentrate mostly on the state part of the extensions aka the pipeline object. I think GLSL already compiled program separately anyway. I test my implementation on the test that I send few day ago on piglit. All tests are ok but I miss a test for new uniform function. Besides there are still some parts unimplemented: 1/ GLX Protocol: dropped 2/ Display list: would be done later if someone is interested otherwise dropped Stuff that bug me: 1/ I implement the feature as a pure mesa state. I don't know if they're any rule to create driver functions. Maybe it would be better to add CreatePipelineObject/DeletePipelineObject/BindPipeline/UseProgramStages. Opinion is welcome Note: Rebase done on ac1118d53c0b22db8dcd6fcdcd2d1a245037dbc1 Note2: I create the xml manually, don't know if there is any automatic flow. gregory (12): sso: Create extensions entry points sso: Add pipeline container/state sso: add support of GL_PROGRAM_SEPARABLE and CreateShaderProgramv sso: implement ActiveShaderProgram GetProgramPipelineiv sso: replace Shader binding point with _Shader sso: rename Shader to the pointer _Shader sso: update meta state sso: Implement _mesa_UseProgramStages sso: implement BindProgramPipeline sso: update glGet: GL_PROGRAM_PIPELINE_BINDING sso: implement ValidateProgramPipeline and GetProgramPipelineInfoLog sso: Finally enable the extension on Gallium src/mapi/glapi/gen/ARB_separate_shader_objects.xml | 392 ++ src/mapi/glapi/gen/Makefile.am |1 + src/mapi/glapi/gen/gl_API.xml |6 +- src/mapi/glapi/gen/gl_genexec.py |1 + src/mesa/drivers/common/meta.c | 38 +- src/mesa/drivers/dri/i965/brw_gs.c |2 +- src/mesa/drivers/dri/i965/brw_shader.cpp |4 +- src/mesa/drivers/dri/i965/brw_vs.c |4 +- src/mesa/drivers/dri/i965/brw_vs_surface_state.c |2 +- src/mesa/drivers/dri/i965/brw_wm.c |2 +- src/mesa/drivers/dri/i965/brw_wm_surface_state.c |2 +- src/mesa/drivers/dri/i965/gen6_sol.c |6 +- src/mesa/drivers/dri/i965/gen6_vs_state.c |2 +- src/mesa/drivers/dri/i965/gen6_wm_state.c |2 +- src/mesa/drivers/dri/i965/gen7_sol_state.c |4 +- src/mesa/drivers/dri/i965/gen7_vs_state.c |2 +- src/mesa/drivers/dri/i965/gen7_wm_state.c |2 +- src/mesa/main/api_validate.c |2 +- src/mesa/main/context.c| 44 +- src/mesa/main/extensions.c |1 + src/mesa/main/ff_fragment_shader.cpp |8 +- src/mesa/main/get.c| 19 + src/mesa/main/get_hash_params.py |3 + src/mesa/main/mtypes.h | 43 +- src/mesa/main/pipelineobj.c| 827 src/mesa/main/pipelineobj.h| 101 +++ src/mesa/main/shaderapi.c | 252 -- src/mesa/main/shaderapi.h | 10 +- src/mesa/main/state.c | 14 +- src/mesa/main/texstate.c | 12 +- src/mesa/main/transformfeedback.c |4 +- src/mesa/main/uniform_query.cpp| 75 +- src/mesa/main/uniforms.c | 466 ++- src/mesa/main/uniforms.h | 86 ++ src/mesa/program/ir_to_mesa.cpp| 12 +- src/mesa/sources.mak |1 + src/mesa/state_tracker/st_atom_clip.c |2 +- src/mesa/state_tracker/st_atom_constbuf.c |4 +- src/mesa/state_tracker/st_cb_drawpixels.c |2 +- src/mesa/state_tracker/st_draw.c |6 +- src/mesa/state_tracker/st_extensions.c |1 + src/mesa/state_tracker/st_glsl_to_tgsi.cpp |2 +- src/mesa/state_tracker/st_program.c|6 +- src/mesa/swrast/s_fragprog.c |2 +- 44 files changed, 2302 insertions(+), 175 deletions(-) create mode 100644 src/mapi/glapi/gen/ARB_separate_shader_objects.xml create mode 100644 src/mesa/main/pipelineobj.c create mode 100644 src/mesa/main/pipelineobj.h -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 01/12] sso: Create extensions entry points
V2: formatting improvement Nothings implemented yet but glProgramUniform* which are mostly a copy/paste of the older function glUniform* I create dedicated pipelineobj.[ch] file that will contains function related to the new pipeline container object. --- src/mapi/glapi/gen/ARB_separate_shader_objects.xml | 392 +++ src/mapi/glapi/gen/Makefile.am |1 + src/mapi/glapi/gen/gl_API.xml |6 +- src/mapi/glapi/gen/gl_genexec.py |1 + src/mesa/main/extensions.c |1 + src/mesa/main/mtypes.h |1 + src/mesa/main/pipelineobj.c| 135 +++ src/mesa/main/pipelineobj.h| 73 src/mesa/main/shaderapi.c |9 + src/mesa/main/shaderapi.h |3 + src/mesa/main/uniforms.c | 400 src/mesa/main/uniforms.h | 83 src/mesa/sources.mak |1 + 13 files changed, 1105 insertions(+), 1 deletion(-) create mode 100644 src/mapi/glapi/gen/ARB_separate_shader_objects.xml create mode 100644 src/mesa/main/pipelineobj.c create mode 100644 src/mesa/main/pipelineobj.h diff --git a/src/mapi/glapi/gen/ARB_separate_shader_objects.xml b/src/mapi/glapi/gen/ARB_separate_shader_objects.xml new file mode 100644 index 000..29a37f5 --- /dev/null +++ b/src/mapi/glapi/gen/ARB_separate_shader_objects.xml @@ -0,0 +1,392 @@ +?xml version=1.0? +!DOCTYPE OpenGLAPI SYSTEM gl_API.dtd + +!-- Note: no GLX protocol info yet. -- + +OpenGLAPI + category name=ARB_separate_shader_objects number=97 + enum name=ACTIVE_PROGRAM value=0x8259/ + enum name=PROGRAM_PIPELINE_BINDING value=0x825A/ + enum name=VERTEX_SHADER_BIT value=0x0001/ + enum name=FRAGMENT_SHADER_BIT value=0x0002/ + enum name=GEOMETRY_SHADER_BIT value=0x0004/ + enum name=TESS_CONTROL_SHADER_BIT value=0x0008/ + enum name=TESS_EVALUATION_SHADER_BIT value=0x0010/ + enum name=ALL_SHADER_BITS value=0x/ + enum name=PROGRAM_SEPARABLE value=0x8258/ + + function name=UseProgramStages offset=assign + param name=pipeline type=GLuint / + param name=stages type=GLbitfield / + param name=program type=GLuint / + /function + function name=ActiveShaderProgram offset=assign + param name=pipeline type=GLuint / + param name=program type=GLuint / + /function + function name=CreateShaderProgramv offset=assign + param name=type type=GLenum / + param name=count type=GLsizei / + param name=strings type=const GLchar * const * / + return type=uint/ + /function + function name=BindProgramPipeline offset=assign + param name=pipeline type=GLuint / + /function + function name=DeleteProgramPipelines offset=assign + param name=n type=GLsizei / + param name=pipelines type=const GLuint * / + /function + function name=GenProgramPipelines offset=assign + param name=n type=GLsizei / + param name=pipelines type=GLuint * / + /function + function name=IsProgramPipeline offset=assign + param name=pipeline type=GLuint / + return type=GLboolean/ + /function + function name=GetProgramPipelineiv offset=assign + param name=pipeline type=GLuint / + param name=pname type=GLenum / + param name=params type=GLint * / + /function + function name=ProgramUniform1i offset=assign + param name=program type=GLuint / + param name=location type=GLint / + param name=x type=GLint / + /function + function name=ProgramUniform2i offset=assign + param name=program type=GLuint / + param name=location type=GLint / + param name=x type=GLint / + param name=y type=GLint / + /function + function name=ProgramUniform3i offset=assign + param name=program type=GLuint / + param name=location type=GLint / + param name=x type=GLint / + param name=y type=GLint / + param name=z type=GLint / + /function + function name=ProgramUniform4i offset=assign + param name=program type=GLuint / + param name=location type=GLint / + param name=x type=GLint / + param name=y type=GLint / + param name=z type=GLint / + param name=w type=GLint / + /function + function name=ProgramUniform1ui offset=assign + param name=program type=GLuint / + param name=location type=GLint / +
[Mesa-dev] [PATCH 02/12] sso: Add pipeline container/state
V2:
* Rename gl_shader_state to gl_pipeline_object
* Rename Pipeline.PipelineObj to Pipeline.Current
* Rename ValidationStatus to Validated
* Formatting improvement
V1:
* Extend gl_shader_state as pipeline object state
* Add a new container gl_pipeline_shader_state that contains
binding point of the previous object
* Update mesa init/free shader state due to the extension of
the attibute
* Add an init/free pipeline function for the context
* Implement GenProgramPipeline/DeleteProgramPipeline/IsProgramPipeline.
I based my work on the VAO code.
---
src/mesa/main/context.c |3 +
src/mesa/main/mtypes.h | 30 +-
src/mesa/main/pipelineobj.c | 231 ++-
src/mesa/main/pipelineobj.h | 25 +
src/mesa/main/shaderapi.c | 14 ++-
src/mesa/main/shaderapi.h |3 +
6 files changed, 300 insertions(+), 6 deletions(-)
diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index 0539934..d089827 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
@@ -106,6 +106,7 @@
#include macros.h
#include matrix.h
#include multisample.h
+#include pipelineobj.h
#include pixel.h
#include pixelstore.h
#include points.h
@@ -762,6 +763,7 @@ init_attrib_groups(struct gl_context *ctx)
_mesa_init_lighting( ctx );
_mesa_init_matrix( ctx );
_mesa_init_multisample( ctx );
+ _mesa_init_pipeline( ctx );
_mesa_init_pixel( ctx );
_mesa_init_pixelstore( ctx );
_mesa_init_point( ctx );
@@ -1167,6 +1169,7 @@ _mesa_free_context_data( struct gl_context *ctx )
_mesa_free_texture_data( ctx );
_mesa_free_matrix_data( ctx );
_mesa_free_viewport_data( ctx );
+ _mesa_free_pipeline_data(ctx);
_mesa_free_program_data(ctx);
_mesa_free_shader_state(ctx);
_mesa_free_queryobj_data(ctx);
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 05d8518..4487068 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -2381,9 +2381,19 @@ struct gl_shader_program
/**
* Context state for GLSL vertex/fragment shaders.
+ * Extended to support pipeline object
*/
-struct gl_shader_state
+struct gl_pipeline_object
{
+ /** Name of the pipeline object as received from glGenProgramPipelines.
+* It would be 0 for shaders without separate shader objects.
+*/
+ GLuint Name;
+
+ GLint RefCount;
+
+ _glthread_Mutex Mutex;
+
/**
* Programs used for rendering
*
@@ -2405,8 +2415,23 @@ struct gl_shader_state
struct gl_shader_program *ActiveProgram;
GLbitfield Flags;/** Mask of GLSL_x flags */
+
+ GLboolean Validated; /** Pipeline Validation status */
+
+ GLboolean EverBound; /** Has the pipeline object been
created */
};
+/**
+ * Context state for GLSL pipeline shaders.
+ */
+struct gl_pipeline_shader_state
+{
+ /** Currently bound pipeline object. See _mesa_BindProgramPipeline() */
+ struct gl_pipeline_object *Current;
+
+ /** Pipeline objects */
+ struct _mesa_HashTable *Objects;
+};
/**
* Compiler options for a single GLSL shaders type
@@ -3514,7 +3539,8 @@ struct gl_context
struct gl_geometry_program_state GeometryProgram;
struct gl_ati_fragment_shader_state ATIFragmentShader;
- struct gl_shader_state Shader; /** GLSL shader object state */
+ struct gl_pipeline_shader_state Pipeline; /** GLSL pipeline shader object
state */
+ struct gl_pipeline_object Shader; /** GLSL shader object state */
struct gl_shader_compiler_options ShaderCompilerOptions[MESA_SHADER_TYPES];
struct gl_query_state Query; /** occlusion, timer queries */
diff --git a/src/mesa/main/pipelineobj.c b/src/mesa/main/pipelineobj.c
index 651c1a0..cf741a1 100644
--- a/src/mesa/main/pipelineobj.c
+++ b/src/mesa/main/pipelineobj.c
@@ -53,6 +53,168 @@
#include ../glsl/glsl_parser_extras.h
#include ../glsl/ir_uniform.h
+/**
+ * Delete a pipeline object.
+ */
+void
+_mesa_delete_pipeline_object(struct gl_context *ctx, struct gl_pipeline_object
*obj)
+{
+ _mesa_reference_shader_program(ctx, obj-_CurrentFragmentProgram, NULL);
+ _mesa_reference_shader_program(ctx, obj-CurrentFragmentProgram, NULL);
+ _mesa_reference_shader_program(ctx, obj-CurrentVertexProgram, NULL);
+ _mesa_reference_shader_program(ctx, obj-CurrentGeometryProgram, NULL);
+ _mesa_reference_shader_program(ctx, obj-ActiveProgram, NULL);
+ _glthread_DESTROY_MUTEX(obj-Mutex);
+ ralloc_free(obj);
+}
+
+/**
+ * Allocate and initialize a new pipeline object.
+ */
+static struct gl_pipeline_object *
+_mesa_new_pipeline_object(struct gl_context *ctx, GLuint name)
+{
+ struct gl_pipeline_object *obj = rzalloc(NULL, struct gl_pipeline_object);
+ if (obj) {
+ obj-Name = name;
+ _glthread_INIT_MUTEX(obj-Mutex);
+ obj-RefCount = 1;
+ obj-Flags = _mesa_get_shader_flags();
+ }
+
+ return obj;
+}
+
+/**
+ * Initialize pipeline object state for given context.
+ */
+void
+_mesa_init_pipeline(struct gl_context
[Mesa-dev] [PATCH 03/12] sso: add support of GL_PROGRAM_SEPARABLE and CreateShaderProgramv
V2: Formatting improvement
V1:
CreateShaderProgramv is similar as CreateShaderProgramEXT. The 2 differences are
1/ it an array of strings
2/ it support the GL_PROGRAM_SEPARABLE (aka SeparateShader) flag
---
src/mesa/main/mtypes.h|5 +++
src/mesa/main/shaderapi.c | 94 +++--
src/mesa/main/shaderapi.h |3 +-
3 files changed, 72 insertions(+), 30 deletions(-)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 4487068..f979cd0 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -2255,6 +2255,11 @@ struct gl_shader_program
* glClear()).
*/
GLboolean InternalSeparateShader;
+ /* ARB_separate_shader_objects
+* indicates whether program can be bound for individual pipeline stages
using
+* UseProgramStages after it is next linked.
+*/
+ GLboolean SeparateShader;
GLuint NumShaders; /** number of attached shaders */
struct gl_shader **Shaders; /** List of attached the shaders */
diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
index 774163d..46072ba 100644
--- a/src/mesa/main/shaderapi.c
+++ b/src/mesa/main/shaderapi.c
@@ -622,6 +622,11 @@ get_programiv(struct gl_context *ctx, GLuint program,
GLenum pname, GLint *param
case GL_PROGRAM_BINARY_LENGTH:
*params = 0;
return;
+ case GL_PROGRAM_SEPARABLE:
+ if (!ctx-Extensions.ARB_separate_shader_objects)
+ break;
+ *params = shProg-SeparateShader;
+ return;
default:
break;
}
@@ -1702,6 +1707,25 @@ _mesa_ProgramParameteri(GLuint program, GLenum pname,
GLint value)
*/
shProg-BinaryRetreivableHint = value;
return;
+
+ case GL_PROGRAM_SEPARABLE:
+ if (!ctx-Extensions.ARB_separate_shader_objects)
+ break;
+
+ /* Spec imply that the behavior is the same as ARB_get_program_binary
+ * Chapter 7.3 Program Objects
+ */
+ if (value != GL_TRUE value != GL_FALSE) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ glProgramParameteri(pname=%s, value=%d):
+ value must be 0 or 1.,
+ _mesa_lookup_enum_by_nr(pname),
+ value);
+ return;
+ }
+ shProg-SeparateShader = value;
+ return;
+
default:
break;
}
@@ -1773,59 +1797,71 @@ _mesa_ActiveProgramEXT(GLuint program)
return;
}
-
-/**
- * For GL_EXT_separate_shader_objects
- */
-GLuint GLAPIENTRY
-_mesa_CreateShaderProgramEXT(GLenum type, const GLchar *string)
+static GLuint
+_mesa_create_shader_program(struct gl_context* ctx, GLboolean separate,
+GLenum type, GLsizei count, const GLchar* const
*strings)
{
- GET_CURRENT_CONTEXT(ctx);
const GLuint shader = create_shader(ctx, type);
GLuint program = 0;
if (shader) {
- shader_source(ctx, shader, _mesa_strdup(string));
+ _mesa_ShaderSource(shader, count, strings, NULL);
+
compile_shader(ctx, shader);
program = create_shader_program(ctx);
if (program) {
-struct gl_shader_program *shProg;
-struct gl_shader *sh;
-GLint compiled = GL_FALSE;
+ struct gl_shader_program *shProg;
+ struct gl_shader *sh;
+ GLint compiled = GL_FALSE;
-shProg = _mesa_lookup_shader_program(ctx, program);
-sh = _mesa_lookup_shader(ctx, shader);
+ shProg = _mesa_lookup_shader_program(ctx, program);
+ sh = _mesa_lookup_shader(ctx, shader);
-get_shaderiv(ctx, shader, GL_COMPILE_STATUS, compiled);
-if (compiled) {
- attach_shader(ctx, program, shader);
- link_program(ctx, program);
- detach_shader(ctx, program, shader);
+ shProg-SeparateShader = separate;
+ get_shaderiv(ctx, shader, GL_COMPILE_STATUS, compiled);
+ if (compiled) {
+attach_shader(ctx, program, shader);
+link_program(ctx, program);
+detach_shader(ctx, program, shader);
#if 0
- /* Possibly... */
- if (active-user-defined-varyings-in-linked-program) {
- append-error-to-info-log;
- shProg-LinkStatus = GL_FALSE;
- }
+/* Possibly... */
+if (active-user-defined-varyings-in-linked-program) {
+ append-error-to-info-log;
+ shProg-LinkStatus = GL_FALSE;
+}
#endif
-}
+ }
-ralloc_strcat(shProg-InfoLog, sh-InfoLog);
+ ralloc_strcat(shProg-InfoLog, sh-InfoLog);
}
-
delete_shader(ctx, shader);
}
-
return program;
}
/**
+ * For GL_EXT_separate_shader_objects
+ */
+GLuint GLAPIENTRY
+_mesa_CreateShaderProgramEXT(GLenum type, const GLchar *string)
+{
+ GET_CURRENT_CONTEXT(ctx);
+
+ return _mesa_create_shader_program(ctx, GL_FALSE, type, 1, string);
+}
+
+/**
* ARB_separate_shader_objects: Compile Link Program
+ * Basically the same as
[Mesa-dev] [PATCH 04/12] sso: implement ActiveShaderProgram GetProgramPipelineiv
V2:
* Rename object
* Formatting improvement
---
src/mesa/main/pipelineobj.c | 77 +++
1 file changed, 77 insertions(+)
diff --git a/src/mesa/main/pipelineobj.c b/src/mesa/main/pipelineobj.c
index cf741a1..6c9a56f 100644
--- a/src/mesa/main/pipelineobj.c
+++ b/src/mesa/main/pipelineobj.c
@@ -230,6 +230,30 @@ _mesa_UseProgramStages(GLuint pipeline, GLbitfield stages,
GLuint program)
void GLAPIENTRY
_mesa_ActiveShaderProgram(GLuint pipeline, GLuint program)
{
+ GET_CURRENT_CONTEXT(ctx);
+ struct gl_shader_program *shProg = (program != 0)
+ ? _mesa_lookup_shader_program_err(ctx, program,
glActiveShaderProgram(program))
+ : NULL;
+
+ struct gl_pipeline_object *pipe = lookup_pipeline_object(ctx, pipeline);
+
+ if (!pipe) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
glActiveShaderProgram(pipeline));
+ return;
+ }
+
+ /* Object is created by any Pipeline call but glGenProgramPipelines,
+* glIsProgramPipeline and GetProgramPipelineInfoLog
+*/
+ pipe-EverBound = GL_TRUE;
+
+ if ((shProg != NULL) !shProg-LinkStatus) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+glActiveShaderProgram(program %u not linked), shProg-Name);
+ return;
+ }
+
+ _mesa_reference_shader_program(ctx, pipe-ActiveProgram, shProg);
}
/**
@@ -347,6 +371,59 @@ _mesa_IsProgramPipeline(GLuint pipeline)
void GLAPIENTRY
_mesa_GetProgramPipelineiv(GLuint pipeline, GLenum pname, GLint *params)
{
+ GET_CURRENT_CONTEXT(ctx);
+ struct gl_pipeline_object *pipe = lookup_pipeline_object(ctx, pipeline);
+
+ /* Are geometry shaders available in this context?
+*/
+ const bool has_gs = _mesa_is_desktop_gl(ctx)
ctx-Extensions.ARB_geometry_shader4;
+
+ if (!pipe) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
glGetProgramPipelineiv(pipeline));
+ return;
+ }
+
+ /* Object is created by any Pipeline call but glGenProgramPipelines,
+* glIsProgramPipeline and GetProgramPipelineInfoLog
+*/
+ pipe-EverBound = GL_TRUE;
+
+ switch (pname) {
+ case GL_ACTIVE_PROGRAM:
+ *params = pipe-ActiveProgram ? pipe-ActiveProgram-Name : 0;
+ return;
+ case GL_INFO_LOG_LENGTH:
+ // TODO
+ *params = 0;
+ return;
+ case GL_VALIDATE_STATUS:
+ *params = pipe-ValidationStatus;
+ return;
+ case GL_VERTEX_SHADER:
+ *params = pipe-CurrentVertexProgram ? pipe-CurrentVertexProgram-Name
: 0;
+ return;
+ case GL_TESS_EVALUATION_SHADER:
+ /* NOT YET SUPPORTED */
+ break;
+ case GL_TESS_CONTROL_SHADER:
+ /* NOT YET SUPPORTED */
+ break;
+ case GL_GEOMETRY_SHADER:
+ if (!has_gs) break;
+ *params = pipe-CurrentGeometryProgram ?
pipe-CurrentGeometryProgram-Name : 0;;
+ return;
+ case GL_FRAGMENT_SHADER:
+ *params = pipe-CurrentFragmentProgram ?
pipe-CurrentFragmentProgram-Name : 0;;
+ return;
+ case GL_COMPUTE_SHADER:
+ /* NOT YET SUPPORTED */
+ break;
+ default:
+ break;
+ }
+
+ _mesa_error(ctx, GL_INVALID_ENUM, glGetProgramPipelineiv(pname=%s),
+ _mesa_lookup_enum_by_nr(pname));
}
/**
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 06/12] sso: rename Shader to the pointer _Shader
V2: formatting improvement
Basically a sed but shaderapi.c and get.c.
get.c = GL_CURRENT_PROGAM always refer to the old UseProgram behavior
shaderapi.c = the old api stil update the Shader object directly
---
src/mesa/drivers/common/meta.c | 10 ++--
src/mesa/drivers/dri/i965/brw_gs.c |2 +-
src/mesa/drivers/dri/i965/brw_shader.cpp |4 +-
src/mesa/drivers/dri/i965/brw_vs.c |4 +-
src/mesa/drivers/dri/i965/brw_vs_surface_state.c |2 +-
src/mesa/drivers/dri/i965/brw_wm.c |2 +-
src/mesa/drivers/dri/i965/brw_wm_surface_state.c |2 +-
src/mesa/drivers/dri/i965/gen6_sol.c |6 +-
src/mesa/drivers/dri/i965/gen6_vs_state.c|2 +-
src/mesa/drivers/dri/i965/gen6_wm_state.c|2 +-
src/mesa/drivers/dri/i965/gen7_sol_state.c |4 +-
src/mesa/drivers/dri/i965/gen7_vs_state.c|2 +-
src/mesa/drivers/dri/i965/gen7_wm_state.c|2 +-
src/mesa/main/api_validate.c |2 +-
src/mesa/main/context.c | 32 +--
src/mesa/main/ff_fragment_shader.cpp |8 +--
src/mesa/main/get.c | 10
src/mesa/main/shaderapi.c| 26 -
src/mesa/main/state.c| 14 ++---
src/mesa/main/texstate.c | 12 ++--
src/mesa/main/transformfeedback.c|4 +-
src/mesa/main/uniform_query.cpp |4 +-
src/mesa/main/uniforms.c | 66 +++---
src/mesa/program/ir_to_mesa.cpp | 12 ++--
src/mesa/state_tracker/st_atom_clip.c|2 +-
src/mesa/state_tracker/st_atom_constbuf.c|4 +-
src/mesa/state_tracker/st_cb_drawpixels.c|2 +-
src/mesa/state_tracker/st_draw.c |6 +-
src/mesa/state_tracker/st_glsl_to_tgsi.cpp |2 +-
src/mesa/state_tracker/st_program.c |6 +-
src/mesa/swrast/s_fragprog.c |2 +-
31 files changed, 134 insertions(+), 124 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index e3ab82b..927573d 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -617,13 +617,13 @@ _mesa_meta_begin(struct gl_context *ctx, GLbitfield state)
if (ctx-Extensions.ARB_shader_objects) {
_mesa_reference_shader_program(ctx, save-VertexShader,
- ctx-Shader.CurrentVertexProgram);
+ ctx-_Shader-CurrentVertexProgram);
_mesa_reference_shader_program(ctx, save-GeometryShader,
- ctx-Shader.CurrentGeometryProgram);
+ ctx-_Shader-CurrentGeometryProgram);
_mesa_reference_shader_program(ctx, save-FragmentShader,
- ctx-Shader.CurrentFragmentProgram);
+ ctx-_Shader-CurrentFragmentProgram);
_mesa_reference_shader_program(ctx, save-ActiveShader,
- ctx-Shader.ActiveProgram);
+ ctx-_Shader-ActiveProgram);
_mesa_UseProgram(0);
}
@@ -965,7 +965,7 @@ _mesa_meta_end(struct gl_context *ctx)
_mesa_use_shader_program(ctx, GL_FRAGMENT_SHADER,
save-FragmentShader);
- _mesa_reference_shader_program(ctx, ctx-Shader.ActiveProgram,
+ _mesa_reference_shader_program(ctx, ctx-_Shader-ActiveProgram,
save-ActiveShader);
_mesa_reference_shader_program(ctx, save-VertexShader, NULL);
diff --git a/src/mesa/drivers/dri/i965/brw_gs.c
b/src/mesa/drivers/dri/i965/brw_gs.c
index caa3b3e..31b01df 100644
--- a/src/mesa/drivers/dri/i965/brw_gs.c
+++ b/src/mesa/drivers/dri/i965/brw_gs.c
@@ -189,7 +189,7 @@ static void populate_key( struct brw_context *brw,
/* _NEW_TRANSFORM_FEEDBACK */
if (_mesa_is_xfb_active_and_unpaused(ctx)) {
const struct gl_shader_program *shaderprog =
-ctx-Shader.CurrentVertexProgram;
+ctx-_Shader-CurrentVertexProgram;
const struct gl_transform_feedback_info *linked_xfb_info =
shaderprog-LinkedTransformFeedback;
int i;
diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp
b/src/mesa/drivers/dri/i965/brw_shader.cpp
index b3bd1b9..7259fde 100644
--- a/src/mesa/drivers/dri/i965/brw_shader.cpp
+++ b/src/mesa/drivers/dri/i965/brw_shader.cpp
@@ -257,7 +257,7 @@ brw_link_shader(struct gl_context *ctx, struct
gl_shader_program *shProg)
_mesa_reference_program(ctx, prog, NULL);
- if (ctx-Shader.Flags GLSL_DUMP) {
+ if (ctx-_Shader-Flags GLSL_DUMP) {
printf(\n);
printf(GLSL IR for linked %s program %d:\n,
[Mesa-dev] [PATCH 07/12] sso: update meta state
V2: formatting improvement
save and restore _Shader/Pipeline binding point. Rational we don't want any
conflict
when the program will be unattached.
---
src/mesa/drivers/common/meta.c | 28 +---
1 file changed, 25 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index 927573d..01a63bd 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -51,6 +51,7 @@
#include main/macros.h
#include main/matrix.h
#include main/mipmap.h
+#include main/pipelineobj.h
#include main/pixel.h
#include main/pbo.h
#include main/polygon.h
@@ -142,6 +143,8 @@ struct save_state
struct gl_shader_program *GeometryShader;
struct gl_shader_program *FragmentShader;
struct gl_shader_program *ActiveShader;
+ struct gl_pipeline_object *_Shader;
+ struct gl_pipeline_object *Pipeline;
/** MESA_META_STENCIL_TEST */
struct gl_stencil_attrib Stencil;
@@ -615,6 +618,14 @@ _mesa_meta_begin(struct gl_context *ctx, GLbitfield state)
_mesa_set_enable(ctx, GL_FRAGMENT_SHADER_ATI, GL_FALSE);
}
+ if (ctx-Extensions.ARB_separate_shader_objects) {
+ /* Warning it must be done before _mesa_UseProgram call */
+ _mesa_reference_pipeline_object(ctx, save-_Shader, ctx-_Shader);
+ _mesa_reference_pipeline_object(ctx, save-Pipeline,
+ ctx-Pipeline.Current);
+ _mesa_BindProgramPipeline(0);
+ }
+
if (ctx-Extensions.ARB_shader_objects) {
_mesa_reference_shader_program(ctx, save-VertexShader,
ctx-_Shader-CurrentVertexProgram);
@@ -954,16 +965,26 @@ _mesa_meta_end(struct gl_context *ctx)
save-ATIFragmentShaderEnabled);
}
+ /* Warning it must be done before _mesa_use_shader_program call */
+ if (ctx-Extensions.ARB_separate_shader_objects) {
+ _mesa_reference_pipeline_object(ctx, ctx-_Shader, save-_Shader);
+ _mesa_reference_pipeline_object(ctx, ctx-Pipeline.Current,
+ save-Pipeline);
+ _mesa_reference_pipeline_object(ctx, save-Pipeline, NULL);
+ }
+
if (ctx-Extensions.ARB_vertex_shader)
-_mesa_use_shader_program(ctx, GL_VERTEX_SHADER, save-VertexShader);
+_mesa_use_shader_program(ctx, GL_VERTEX_SHADER, save-VertexShader,
+ ctx-_Shader);
if (ctx-Extensions.ARB_geometry_shader4)
_mesa_use_shader_program(ctx, GL_GEOMETRY_SHADER_ARB,
- save-GeometryShader);
+ save-GeometryShader, ctx-_Shader);
if (ctx-Extensions.ARB_fragment_shader)
_mesa_use_shader_program(ctx, GL_FRAGMENT_SHADER,
- save-FragmentShader);
+ save-FragmentShader, ctx-_Shader);
+
_mesa_reference_shader_program(ctx, ctx-_Shader-ActiveProgram,
save-ActiveShader);
@@ -972,6 +993,7 @@ _mesa_meta_end(struct gl_context *ctx)
_mesa_reference_shader_program(ctx, save-GeometryShader, NULL);
_mesa_reference_shader_program(ctx, save-FragmentShader, NULL);
_mesa_reference_shader_program(ctx, save-ActiveShader, NULL);
+ _mesa_reference_pipeline_object(ctx, save-_Shader, NULL);
}
if (state MESA_META_STENCIL_TEST) {
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 08/12] sso: Implement _mesa_UseProgramStages
V2: formatting rename
Implement _mesa_UseProgramStages =
arb_separate_shader_object-GetProgramPipelineiv is now pass :)
Extend use_shader_program to support a different target. Allow to reuse the
function to update
the pipeline state. Note I bypass the flush when target isn't current. Maybe it
would be better to
create a new UseProgramStages driver function
---
src/mesa/main/pipelineobj.c | 109 +++
src/mesa/main/shaderapi.c | 32 +++--
src/mesa/main/shaderapi.h |3 +-
3 files changed, 129 insertions(+), 15 deletions(-)
diff --git a/src/mesa/main/pipelineobj.c b/src/mesa/main/pipelineobj.c
index 9ccf116..14bbcd9 100644
--- a/src/mesa/main/pipelineobj.c
+++ b/src/mesa/main/pipelineobj.c
@@ -230,6 +230,115 @@ _mesa_reference_pipeline_object_(struct gl_context *ctx,
void GLAPIENTRY
_mesa_UseProgramStages(GLuint pipeline, GLbitfield stages, GLuint program)
{
+ GET_CURRENT_CONTEXT(ctx);
+
+ struct gl_pipeline_object *pipe = lookup_pipeline_object(ctx, pipeline);
+ struct gl_shader_program *shProg = NULL;
+
+ if (!pipe) {
+ _mesa_error(ctx, GL_INVALID_OPERATION, glUseProgramStages(pipeline));
+ return;
+ }
+
+ /* Object is created by any Pipeline call but glGenProgramPipelines,
+* glIsProgramPipeline and GetProgramPipelineInfoLog
+*/
+ pipe-EverBound = GL_TRUE;
+
+ /* NOT YET SUPPORTED:
+* GL_TESS_CONTROL_SHADER_BIT
+* GL_TESS_EVALUATION_SHADER_BIT
+* GL_COMPUTE_SHADER_BIT
+*/
+ GLbitfield any_valid_stages = GL_VERTEX_SHADER_BIT | GL_FRAGMENT_SHADER_BIT;
+ if (_mesa_is_desktop_gl(ctx) ctx-Extensions.ARB_geometry_shader4)
+ any_valid_stages |= GL_GEOMETRY_SHADER_BIT;
+
+ if (stages != GL_ALL_SHADER_BITS (stages ~any_valid_stages) != 0) {
+ _mesa_error(ctx, GL_INVALID_VALUE, glUseProgramStages(Stages));
+ return;
+ }
+
+ /*
+* An INVALID_OPERATION error is generated :
+* by UseProgramStages if the program pipeline object it refers to is
current
+* and the current transform feedback object is active and not paused;
+*/
+ /*
+* 6a. Should the fragment shader program object be allowed to changed
+* within transform feedback mode?
+* RESOLVED: No, this should generate an GL_INVALID_OPERATION error.
+*/
+ if (ctx-_Shader == pipe) {
+ if (_mesa_is_xfb_active_and_unpaused(ctx)) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ glUseProgramStages(transform feedback active));
+ return;
+ }
+ }
+
+ if (program) {
+ /* An INVALID_OPERATION error is generated if program is the name of a
+ * shader object
+ */
+ struct gl_shader *sh = _mesa_lookup_shader(ctx, program);
+ if (sh != NULL) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ glUseProgramStages(progam is a shader object));
+ return;
+ }
+
+ /* An INVALID_VALUE error is generated if program is not the name of ei-
+ * ther a program or shader object
+ */
+ shProg = _mesa_lookup_shader_program(ctx, program);
+ if (shProg == NULL) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ glUseProgramStages(progam is not a program object));
+ return;
+ }
+
+ /* An INVALID_OPERATION error is generated if the program object named
+ * by program was linked without the PROGRAM_SEPARABLE parameter set, has
+ * not been linked, or was last linked unsuccessfully. The corresponding
shader
+ * stages in pipeline are not modified.
+ */
+ if (!shProg-LinkStatus) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ glUseProgramStages(program not linked));
+ return;
+ }
+ if (!shProg-SeparateShader) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ glUseProgramStages(program wasn't linked with the
PROGRAM_SEPARABLE flag));
+ return;
+ }
+ }
+
+ /*
+* 7. What happens if you have a program object current for a shader
stage,
+*but the program object doesn't contain an executable for that stage?
+
+*RESOLVED: This is not an error; instead it is as though there were no
+*program bound to that stage. We have two different notions for
+*programs bound to shader stages. A program is current for a stage
+*if it bound to that stage in the active program pipeline object. A
+*program is active for a stage if it is current and it has an
+*executable for this stage. In this case, the program would be current
+*but not active.
+
+*When no program is active for a stage, the stage will be replaced with
+*fixed functionality logic (compatibility profile vertex and fragment),
+*disabled (tessellation control and evaluation, geometry), or have
+*undefined results (core profile vertex and fragment).
+*/
+
+ if (stages GL_VERTEX_SHADER_BIT)
+
[Mesa-dev] [PATCH 09/12] sso: implement BindProgramPipeline
V2: formatting rename
Test become green in piglit:
The updated ext_transform_feedback-api-errors:useprogstage_noactive
useprogstage_active bind_pipeline
arb_separate_shader_object-GetProgramPipelineiv
arb_separate_shader_object-IsProgramPipeline
For the moment I reuse Driver.UseProgram but I guess it will be better to create
a UseProgramStages functions. Opinion is welcome
---
src/mesa/main/pipelineobj.c | 56 +++
1 file changed, 56 insertions(+)
diff --git a/src/mesa/main/pipelineobj.c b/src/mesa/main/pipelineobj.c
index 14bbcd9..a275796 100644
--- a/src/mesa/main/pipelineobj.c
+++ b/src/mesa/main/pipelineobj.c
@@ -379,6 +379,62 @@ _mesa_ActiveShaderProgram(GLuint pipeline, GLuint program)
void GLAPIENTRY
_mesa_BindProgramPipeline(GLuint pipeline)
{
+ GET_CURRENT_CONTEXT(ctx);
+ struct gl_pipeline_object *newObj = NULL;
+
+ if (ctx-_Shader-Name == pipeline)
+ return; /* rebinding the same pipeline object- no change */
+
+ /*
+* An INVALID_OPERATION error is generated :
+* by BindProgramPipeline if the current transform feedback object is
active
+* and not paused;
+*/
+ if (_mesa_is_xfb_active_and_unpaused(ctx)) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+glBindProgramPipeline(transform feedback active));
+ return;
+ }
+
+ /*
+* Get pointer to new pipeline object (newObj)
+*/
+ if (pipeline) {
+ /* non-default pipeline object */
+ newObj = lookup_pipeline_object(ctx, pipeline);
+ if (!newObj) {
+ _mesa_error(ctx, GL_INVALID_OPERATION, glBindProgramPipeline(non-gen
name));
+ return;
+ }
+
+ /* Object is created by any Pipeline call but glGenProgramPipelines,
+ * glIsProgramPipeline and GetProgramPipelineInfoLog
+ */
+ newObj-EverBound = GL_TRUE;
+ }
+
+ /* First bind the Pipeline to pipeline binding point */
+ _mesa_reference_pipeline_object(ctx, ctx-Pipeline.Current, newObj);
+
+ /* Spec say:
+* if any program is bound to the context, the current pipeline object is
+* ignored.
+*/
+ if (ctx-Shader != ctx-_Shader) {
+ if (pipeline) {
+ /* Bound the pipeline to the current program and
+ * restore the pipeline state
+ */
+ _mesa_reference_pipeline_object(ctx, ctx-_Shader, newObj);
+ } else {
+ /* Unbind the pipeline */
+ _mesa_reference_pipeline_object(ctx, ctx-_Shader,
ctx-Pipeline.Default);
+ }
+ FLUSH_VERTICES(ctx, _NEW_PROGRAM | _NEW_PROGRAM_CONSTANTS);
+ /* FIXME */
+ if (ctx-Driver.UseProgram)
+ ctx-Driver.UseProgram(ctx, 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 10/12] sso: update glGet: GL_PROGRAM_PIPELINE_BINDING
---
src/mesa/main/get.c |9 +
src/mesa/main/get_hash_params.py |3 +++
2 files changed, 12 insertions(+)
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index 54159c0..6cbb7db 100644
--- a/src/mesa/main/get.c
+++ b/src/mesa/main/get.c
@@ -369,6 +369,7 @@ EXTRA_EXT(ARB_map_buffer_alignment);
EXTRA_EXT(ARB_texture_cube_map_array);
EXTRA_EXT(ARB_texture_buffer_range);
EXTRA_EXT(ARB_texture_multisample);
+EXTRA_EXT(ARB_separate_shader_objects);
static const int
extra_ARB_color_buffer_float_or_glcore[] = {
@@ -889,6 +890,14 @@ find_custom_value(struct gl_context *ctx, const struct
value_desc *d, union valu
_mesa_problem(ctx, driver doesn't implement GetTimestamp);
}
break;
+ /* GL_ARB_separate_shader_objects */
+ case GL_PROGRAM_PIPELINE_BINDING:
+ if (ctx-Pipeline.Current) {
+ v-value_int = ctx-Pipeline.Current-Name;
+ } else {
+ v-value_int = 0;
+ }
+ break;
}
}
diff --git a/src/mesa/main/get_hash_params.py b/src/mesa/main/get_hash_params.py
index 2b97da6..43a11cf 100644
--- a/src/mesa/main/get_hash_params.py
+++ b/src/mesa/main/get_hash_params.py
@@ -709,6 +709,9 @@ descriptor=[
# GL_ARB_texture_cube_map_array
[ TEXTURE_BINDING_CUBE_MAP_ARRAY_ARB, LOC_CUSTOM, TYPE_INT,
TEXTURE_CUBE_ARRAY_INDEX, extra_ARB_texture_cube_map_array ],
+
+# GL_ARB_separate_shader_objects
+ [ PROGRAM_PIPELINE_BINDING, LOC_CUSTOM, TYPE_INT,
GL_PROGRAM_PIPELINE_BINDING, extra_ARB_separate_shader_objects ],
]},
# Enums restricted to OpenGL Core profile
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 11/12] sso: implement ValidateProgramPipeline and GetProgramPipelineInfoLog
V2:
Fix memory leak with ralloc_strdup
Formatting improvement
V1:
Implementation note:
I don't use context for ralloc (don't know how).
The check on PROGRAM_SEPARABLE flags is also done when the pipeline isn't bound.
It doesn't make any sense in a DSA style API.
Maybe we could replace _mesa_validate_program_pipeline by
_mesa_validate_program_pipeline.
For example we could recreate a dummy pipeline object. However the new function
checks
also the TEXTURE_IMAGE_UNIT number not sure of the impact.
---
src/mesa/main/context.c |9 ++
src/mesa/main/mtypes.h |2 +
src/mesa/main/pipelineobj.c | 221 ++-
src/mesa/main/pipelineobj.h |3 +
src/mesa/main/uniform_query.cpp | 71 +
src/mesa/main/uniforms.h|3 +
6 files changed, 305 insertions(+), 4 deletions(-)
diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index 6a0619a..559e21f 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
@@ -1767,6 +1767,7 @@ _mesa_check_blend_func_error(struct gl_context *ctx)
* Prior to drawing anything with glBegin, glDrawArrays, etc. this function
* is called to see if it's valid to render. This involves checking that
* the current shader is valid and the framebuffer is complete.
+ * It also check the current pipeline object is valid if any.
* If an error is detected it'll be recorded here.
* \return GL_TRUE if OK to render, GL_FALSE if not
*/
@@ -1876,6 +1877,14 @@ _mesa_valid_to_render(struct gl_context *ctx, const char
*where)
}
}
+ /* A pipeline object is bound */
+ if (ctx-_Shader-Name !ctx-_Shader-Validated) {
+ /* Error message will be printed inside _mesa_validate_program_pipeline
*/
+ if (!_mesa_validate_program_pipeline(ctx, ctx-_Shader, GL_TRUE)) {
+ return GL_FALSE;
+ }
+ }
+
if (ctx-DrawBuffer-_Status != GL_FRAMEBUFFER_COMPLETE_EXT) {
_mesa_error(ctx, GL_INVALID_FRAMEBUFFER_OPERATION_EXT,
%s(incomplete framebuffer), where);
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index adf518b..ce88860 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -2424,6 +2424,8 @@ struct gl_pipeline_object
GLboolean Validated; /** Pipeline Validation status */
GLboolean EverBound; /** Has the pipeline object been
created */
+
+ GLchar *InfoLog;
};
/**
diff --git a/src/mesa/main/pipelineobj.c b/src/mesa/main/pipelineobj.c
index a275796..f065531 100644
--- a/src/mesa/main/pipelineobj.c
+++ b/src/mesa/main/pipelineobj.c
@@ -80,6 +80,7 @@ _mesa_new_pipeline_object(struct gl_context *ctx, GLuint name)
_glthread_INIT_MUTEX(obj-Mutex);
obj-RefCount = 1;
obj-Flags = _mesa_get_shader_flags();
+ obj-InfoLog = ralloc_strdup(obj, );
}
return obj;
@@ -332,13 +333,15 @@ _mesa_UseProgramStages(GLuint pipeline, GLbitfield
stages, GLuint program)
*disabled (tessellation control and evaluation, geometry), or have
*undefined results (core profile vertex and fragment).
*/
-
if (stages GL_VERTEX_SHADER_BIT)
_mesa_use_shader_program(ctx, GL_VERTEX_SHADER, shProg, pipe);
if (stages GL_FRAGMENT_SHADER_BIT)
_mesa_use_shader_program(ctx, GL_FRAGMENT_SHADER, shProg, pipe);
if (stages GL_GEOMETRY_SHADER_BIT)
_mesa_use_shader_program(ctx, GL_GEOMETRY_SHADER_ARB, shProg, pipe);
+
+ /* Validation would need to be redone */
+ pipe-Validated = GL_FALSE;
}
/**
@@ -566,11 +569,10 @@ _mesa_GetProgramPipelineiv(GLuint pipeline, GLenum pname,
GLint *params)
*params = pipe-ActiveProgram ? pipe-ActiveProgram-Name : 0;
return;
case GL_INFO_LOG_LENGTH:
- // TODO
- *params = 0;
+ *params = pipe-Validated;
return;
case GL_VALIDATE_STATUS:
- *params = pipe-ValidationStatus;
+ *params = pipe-Validated;
return;
case GL_VERTEX_SHADER:
*params = pipe-CurrentVertexProgram ? pipe-CurrentVertexProgram-Name
: 0;
@@ -599,16 +601,227 @@ _mesa_GetProgramPipelineiv(GLuint pipeline, GLenum
pname, GLint *params)
_mesa_lookup_enum_by_nr(pname));
}
+static GLboolean
+ProgramEnabledEverywhere(struct gl_pipeline_object *pipe,
+ struct gl_shader_program *prog,
+ char *errMsg, size_t errMsgLength)
+{
+ if (!prog) return GL_TRUE;
+
+ GLboolean status = GL_TRUE;
+
+ if (prog-_LinkedShaders[MESA_SHADER_VERTEX]) {
+ if (pipe-CurrentVertexProgram) {
+ if (prog-Name != pipe-CurrentVertexProgram-Name) {
+status = GL_FALSE;
+ }
+ } else {
+ status = GL_FALSE;
+ }
+ }
+
+ if (prog-_LinkedShaders[MESA_SHADER_FRAGMENT]) {
+ if (pipe-CurrentFragmentProgram) {
+ if (prog-Name != pipe-CurrentFragmentProgram-Name) {
+status = GL_FALSE;
+ }
+ } else {
+ status = GL_FALSE;
+ }
+
[Mesa-dev] [PATCH 12/12] sso: Finally enable the extension on Gallium
Note: it probably work on others drivers. --- src/mesa/state_tracker/st_extensions.c |1 + 1 file changed, 1 insertion(+) diff --git a/src/mesa/state_tracker/st_extensions.c b/src/mesa/state_tracker/st_extensions.c index f986480..4ce74f2 100644 --- a/src/mesa/state_tracker/st_extensions.c +++ b/src/mesa/state_tracker/st_extensions.c @@ -519,6 +519,7 @@ void st_init_extensions(struct st_context *st) ctx-Extensions.ARB_half_float_vertex = GL_TRUE; ctx-Extensions.ARB_internalformat_query = GL_TRUE; ctx-Extensions.ARB_map_buffer_range = GL_TRUE; + ctx-Extensions.ARB_separate_shader_objects = GL_TRUE; ctx-Extensions.ARB_shader_objects = GL_TRUE; ctx-Extensions.ARB_shading_language_100 = GL_TRUE; ctx-Extensions.ARB_texture_border_clamp = GL_TRUE; /* XXX temp */ -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/12] RFC: add support of ARB_separate_shader_object extensions V2
- Original Message - From: gregory gregory.hain...@gmail.com To: gregory hainaut gregory.hain...@gmail.com FWIW, your emails BCC'ing the list are a bit of a pain. They manage elude most of my mail filtering rules, and replying-to-all doesn't include the list... Jose Sent: Friday, April 12, 2013 5:22:02 PM Subject: [Mesa-dev] [PATCH 00/12] RFC: add support of ARB_separate_shader_object extensions V2 [...] ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/12] RFC: add support of ARB_separate_shader_object extensions V2
On Fri, 12 Apr 2013 09:39:15 -0700 (PDT) Jose Fonseca jfons...@vmware.com wrote: - Original Message - From: gregory gregory.hain...@gmail.com To: gregory hainaut gregory.hain...@gmail.com FWIW, your emails BCC'ing the list are a bit of a pain. They manage elude most of my mail filtering rules, and replying-to-all doesn't include the list... Jose Sent: Friday, April 12, 2013 5:22:02 PM Subject: [Mesa-dev] [PATCH 00/12] RFC: add support of ARB_separate_shader_object extensions V2 [...] Thanks for the info I will look. Actually I'm not sure it is a bcc. I setup git to send the email to my draft box, then I used the redirect (to avoid wrapping issue) feature of claws-mail and I manually set to: mesa and myself in cc. The to :myself was done by git header but I'm not sure it is used. Maybe it will work better if I send directly git email to my upload queue with the good cc! Sorry for the disturbance ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] i965/vs: Add instruction scheduling.
While this doesn't have the detail that the FS scheduler does, and is
ignorant of dependency control, it's still good for a 0.60% +/- 0.15%
performance improvement on GLBenchmark 2.7 (n=45/47, outliers removed)
---
src/mesa/drivers/dri/i965/Makefile.sources |1 +
src/mesa/drivers/dri/i965/brw_vec4.cpp |2 +
src/mesa/drivers/dri/i965/brw_vec4.h |1 +
.../drivers/dri/i965/brw_vec4_reg_allocate.cpp |4 +
.../dri/i965/brw_vec4_schedule_instructions.cpp| 484
5 files changed, 492 insertions(+)
create mode 100644 src/mesa/drivers/dri/i965/brw_vec4_schedule_instructions.cpp
diff --git a/src/mesa/drivers/dri/i965/Makefile.sources
b/src/mesa/drivers/dri/i965/Makefile.sources
index be8d630..a5231ee 100644
--- a/src/mesa/drivers/dri/i965/Makefile.sources
+++ b/src/mesa/drivers/dri/i965/Makefile.sources
@@ -86,6 +86,7 @@ i965_FILES = \
brw_vec4.cpp \
brw_vec4_copy_propagation.cpp \
brw_vec4_emit.cpp \
+ brw_vec4_schedule_instructions.cpp \
brw_vec4_live_variables.cpp \
brw_vec4_reg_allocate.cpp \
brw_vec4_visitor.cpp \
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp
b/src/mesa/drivers/dri/i965/brw_vec4.cpp
index dc7865f..e81dccd 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
@@ -1489,6 +1489,8 @@ vec4_visitor::run()
opt_set_dependency_control();
+ opt_schedule_instructions();
+
/* If any state parameters were appended, then ParameterValues could have
* been realloced, in which case the driver uniform storage set up by
* _mesa_associate_uniform_storage() would point to freed memory. Make
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h
b/src/mesa/drivers/dri/i965/brw_vec4.h
index 697ab86..c9f1a4e 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.h
+++ b/src/mesa/drivers/dri/i965/brw_vec4.h
@@ -340,6 +340,7 @@ public:
bool opt_algebraic();
bool opt_register_coalesce();
void opt_set_dependency_control();
+ void opt_schedule_instructions();
bool can_do_source_mods(vec4_instruction *inst);
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp
index ac3d401..7149d46 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp
@@ -102,6 +102,8 @@ brw_alloc_reg_set_for_classes(struct brw_context *brw,
int class_count,
int base_reg_count)
{
+ struct intel_context *intel = brw-intel;
+
/* Compute the total number of registers across all classes. */
int ra_reg_count = 0;
for (int i = 0; i class_count; i++) {
@@ -112,6 +114,8 @@ brw_alloc_reg_set_for_classes(struct brw_context *brw,
brw-vs.ra_reg_to_grf = ralloc_array(brw, uint8_t, ra_reg_count);
ralloc_free(brw-vs.regs);
brw-vs.regs = ra_alloc_reg_set(brw, ra_reg_count);
+ if (intel-gen = 6)
+ ra_set_allocate_round_robin(brw-vs.regs);
ralloc_free(brw-vs.classes);
brw-vs.classes = ralloc_array(brw, int, class_count + 1);
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_schedule_instructions.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_schedule_instructions.cpp
new file mode 100644
index 000..f1e997a
--- /dev/null
+++ b/src/mesa/drivers/dri/i965/brw_vec4_schedule_instructions.cpp
@@ -0,0 +1,484 @@
+/*
+ * Copyright © 2010 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.
+ *
+ * Authors:
+ *Eric Anholt e...@anholt.net
+ *
+ */
+
+extern C {
+#include main/macros.h
+}
+#include brw_vec4.h
+#include glsl/glsl_types.h
+#include glsl/ir_optimization.h
+#include glsl/ir_print_visitor.h
+
+/** @file brw_vec4_schedule_instructions.cpp
+ *
+ * List scheduling of vec4 instructions.
+ *
+ * The basic model of the list scheduler is to take a basic
[Mesa-dev] [PATCH 1/2] i965/fs: Print out the estimated cycle count in INTEL_DEBUG=wm
This could be used by shader-db for hopefully more accurate regression
testing.
---
src/mesa/drivers/dri/i965/brw_fs_schedule_instructions.cpp |5 +
1 file changed, 5 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_schedule_instructions.cpp
b/src/mesa/drivers/dri/i965/brw_fs_schedule_instructions.cpp
index 901a362..7567123 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_schedule_instructions.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_schedule_instructions.cpp
@@ -834,6 +834,11 @@ instruction_scheduler::schedule_instructions(fs_inst
*next_block_header)
}
}
+ if (unlikely(INTEL_DEBUG DEBUG_WM) post_reg_alloc) {
+ printf(fs%d estimated execution time: %d cycles\n,
+ v-dispatch_width, time);
+ }
+
assert(instructions_to_schedule == 0);
}
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] mesa: Add core support for the GL_AMD_performance_monitor extension.
Kenneth Graunke kenn...@whitecape.org writes: This provides an interface for applications (and OpenGL-based tools) to access GPU performance counters. Since the exact performance counters available vary between vendors and hardware generations, the extension provides an API the application can use to get the names, types, and minimum/maximum values of all available counters. Counters are also organized into groups. Applications create performance monitor objects, select the counters they want to track, and Begin/End monitoring, much like OpenGL's query API. Multiple monitors can be in flight simultaneously. We chose not to implement the similar GL_INTEL_performance_queries extension because Intel has not bothered to publish a specification in the OpenGL registry. performance_monitor.c seems to be missing. pgpYYJaWlUDSg.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] i965: Add support for GL_AMD_performance_monitor on Ironlake.
Kenneth Graunke kenn...@whitecape.org writes:
Ironlake's counters are always enabled; userspace can simply send a
MI_REPROT_PERF_COUNT packet to take a snapshot of them. This makes it
easy to implement.
The counters are documented in the source code for the intel-gpu-tools
intel_perf_counters utility.
+/**
+ * i965 representation of a performance monitor object.
+ */
+struct brw_perf_monitor_object
+{
+ /** The base class. */
+ struct gl_perf_monitor_object base;
+
+ /**
+* The GPU-facing BO, holding raw counter data in a hardware specific
form.
+*/
+ drm_intel_bo *gpu_facing_bo;
+};
Why all the emphasis of GPU-facing? We don't use BOs for anything
that the GPU doesn't touch.
+/**
+ * Driver hook for glEndPerformanceMonitorAMD().
+ */
+static void
+brw_end_perf_monitor(struct gl_context *ctx,
+ struct gl_perf_monitor_object *m)
+{
+ struct brw_context *brw = brw_context(ctx);
+ struct brw_perf_monitor_object *monitor = brw_perf_monitor(m);
+ if (aggregating_counters_needed(brw, m)) {
+ snapshot_aggregating_counters(brw, monitor-gpu_facing_bo,
+brw-perfmon.total_counter_size);
At least some variants of the command require 64b alignment -- I'd
probably stick the ending dump at some fixed offset in the BO, like
halfway through.
pgp1V56WMkBdu.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/12] build: Rename sources.mak - Makefile.sources
On Thu, Apr 11, 2013 at 4:29 PM, Matt Turner matts...@gmail.com wrote: For the sake of consistency. Tested-by: Emil Velikov emil.l.veli...@gmail.com Reviewed-and-Tested-by: Andreas Boll andreas.boll@gmail.com --- Chad Jose, Could you test the first two patches of this series with the Android and scons build systems? I've tried to make the proper changes to both build systems. Branch available at git://people.freedesktop.org/~mattst88/mesa make-dist-1 Thanks, Matt ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] mesa: Add core support for the GL_AMD_performance_monitor extension.
Kenneth Graunke kenn...@whitecape.org writes: AMD_draw_buffers_blend.xml \ + AMD_performance_monitor.xml \ Hi Ken, Did you forget to add this new file to git? (I notice that other files next to it, like AMD_draw_buffers_blend.xml are under revision control). -Carl -- carl.d.wo...@intel.com pgpC2UpaZ6LDY.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/12] build: Rename sources.mak - Makefile.sources
On 04/12/2013 11:24 AM, Matt Turner wrote: On Thu, Apr 11, 2013 at 4:29 PM, Matt Turner matts...@gmail.com wrote: For the sake of consistency. Tested-by: Emil Velikov emil.l.veli...@gmail.com Reviewed-and-Tested-by: Andreas Boll andreas.boll@gmail.com --- Chad Jose, Could you test the first two patches of this series with the Android and scons build systems? I've tried to make the proper changes to both build systems. Branch available at git://people.freedesktop.org/~mattst88/mesa make-dist-1 Thanks for checking with me. The branch looks good, and I verified that it doesn't break the Android Intel build. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/12] RFC: add support of ARB_separate_shader_object extensions V2
On Fri, 12 Apr 2013 19:02:47 +0200 gregory hainaut gregory.hain...@gmail.com wrote: On Fri, 12 Apr 2013 09:39:15 -0700 (PDT) Jose Fonseca jfons...@vmware.com wrote: - Original Message - From: gregory gregory.hain...@gmail.com To: gregory hainaut gregory.hain...@gmail.com FWIW, your emails BCC'ing the list are a bit of a pain. They manage elude most of my mail filtering rules, and replying-to-all doesn't include the list... Jose Sent: Friday, April 12, 2013 5:22:02 PM Subject: [Mesa-dev] [PATCH 00/12] RFC: add support of ARB_separate_shader_object extensions V2 [...] Thanks for the info I will look. Actually I'm not sure it is a bcc. I setup git to send the email to my draft box, then I used the redirect (to avoid wrapping issue) feature of claws-mail and I manually set to: mesa and myself in cc. The to :myself was done by git header but I'm not sure it is used. Maybe it will work better if I send directly git email to my upload queue with the good cc! Sorry for the disturbance FYI, I changed my flow to bypass the redirect feature. Future patch will be better :) By the way I upload a github tree: https://github.com/gregory38/mesa-sso/tree/sso2 Branch: sso2 Gregory ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH resend] mesa: Add core support for the GL_AMD_performance_monitor extension.
This provides an interface for applications (and OpenGL-based tools) to access GPU performance counters. Since the exact performance counters available vary between vendors and hardware generations, the extension provides an API the application can use to get the names, types, and minimum/maximum values of all available counters. Counters are also organized into groups. Applications create performance monitor objects, select the counters they want to track, and Begin/End monitoring, much like OpenGL's query API. Multiple monitors can be in flight simultaneously. We chose not to implement the similar GL_INTEL_performance_queries extension because Intel has not bothered to publish a specification in the OpenGL registry. Signed-off-by: Kenneth Graunke kenn...@whitecape.org --- src/mapi/glapi/gen/AMD_performance_monitor.xml | 87 src/mapi/glapi/gen/Makefile.am | 1 + src/mapi/glapi/gen/gl_API.xml | 2 + src/mapi/glapi/gen/gl_genexec.py | 1 + src/mesa/SConscript| 1 + src/mesa/main/context.c| 2 + src/mesa/main/dd.h | 22 + src/mesa/main/extensions.c | 1 + src/mesa/main/mtypes.h | 84 src/mesa/main/performance_monitor.c| 563 + src/mesa/main/performance_monitor.h| 85 src/mesa/sources.mak | 1 + 12 files changed, 850 insertions(+) create mode 100644 src/mapi/glapi/gen/AMD_performance_monitor.xml create mode 100644 src/mesa/main/performance_monitor.c create mode 100644 src/mesa/main/performance_monitor.h This time with the actual contents of the patch...yikes. diff --git a/src/mapi/glapi/gen/AMD_performance_monitor.xml b/src/mapi/glapi/gen/AMD_performance_monitor.xml new file mode 100644 index 000..b96b263 --- /dev/null +++ b/src/mapi/glapi/gen/AMD_performance_monitor.xml @@ -0,0 +1,87 @@ +?xml version=1.0? +!DOCTYPE OpenGLAPI SYSTEM gl_API.dtd + +OpenGLAPI + +category name=GL_AMD_performance_monitor number=360 + +function name=GetPerfMonitorGroupsAMD offset=assign +param name=numGroups type=GLint */ +param name=groupsSize type=GLsizei/ +param name=groups type=GLuint */ +/function + +function name=GetPerfMonitorCountersAMD offset=assign +param name=group type=GLuint/ +param name=numCounters type=GLint */ +param name=maxActiveCounters type=GLint */ +param name=countersSize type=GLsizei/ +param name=counters type=GLuint */ +/function + +function name=GetPerfMonitorGroupStringAMD offset=assign +param name=group type=GLuint/ +param name=bufSize type=GLsizei/ +param name=length type=GLsizei */ +param name=groupString type=GLchar */ +/function + +function name=GetPerfMonitorCounterStringAMD offset=assign +param name=group type=GLuint/ +param name=counter type=GLuint/ +param name=bufSize type=GLsizei/ +param name=length type=GLsizei */ +param name=counterString type=GLchar */ +/function + +function name=GetPerfMonitorCounterInfoAMD offset=assign +param name=group type=GLuint/ +param name=counter type=GLuint/ +param name=pname type=GLenum/ +param name=data type=GLvoid */ +/function + +function name=GenPerfMonitorsAMD offset=assign +param name=n type=GLsizei/ +param name=monitors type=GLuint */ +/function + +function name=DeletePerfMonitorsAMD offset=assign +param name=n type=GLsizei/ +param name=monitors type=GLuint */ +/function + +function name=SelectPerfMonitorCountersAMD offset=assign +param name=monitor type=GLuint/ +param name=enable type=GLboolean/ +param name=group type=GLuint/ +param name=numCounters type=GLint/ +param name=counterList type=GLuint */ +/function + +function name=BeginPerfMonitorAMD offset=assign +param name=monitor type=GLuint/ +/function + +function name=EndPerfMonitorAMD offset=assign +param name=monitor type=GLuint/ +/function + +function name=GetPerfMonitorCounterDataAMD offset=assign +param name=monitor type=GLuint/ +param name=pname type=GLenum/ +param name=dataSize type=GLsizei/ +param name=data type=GLuint */ +param name=bytesWritten type=GLint */ +/function + +enum name=COUNTER_TYPE_AMD value=0x8BC0/ +enum name=COUNTER_RANGE_AMD value=0x8BC1/ +enum name=UNSIGNED_INT64_AMD value=0x8BC2/ +enum name=PECENTAGE_AMD value=0x8BC3/ +enum name=PERFMON_RESULT_AVAILABLE_AMD value=0x8BC4/ +enum name=PERFMON_RESULT_SIZE_AMD value=0x8BC5/ +enum name=PERFMON_RESULT_AMD value=0x8BC6/ +/category + +/OpenGLAPI diff --git a/src/mapi/glapi/gen/Makefile.am b/src/mapi/glapi/gen/Makefile.am index 36e47e2..baf8afc
Re: [Mesa-dev] [PATCH 1/2] mesa: Add core support for the GL_AMD_performance_monitor extension.
On 04/12/2013 10:55 AM, Eric Anholt wrote: Kenneth Graunke kenn...@whitecape.org writes: This provides an interface for applications (and OpenGL-based tools) to access GPU performance counters. Since the exact performance counters available vary between vendors and hardware generations, the extension provides an API the application can use to get the names, types, and minimum/maximum values of all available counters. Counters are also organized into groups. Applications create performance monitor objects, select the counters they want to track, and Begin/End monitoring, much like OpenGL's query API. Multiple monitors can be in flight simultaneously. We chose not to implement the similar GL_INTEL_performance_queries extension because Intel has not bothered to publish a specification in the OpenGL registry. performance_monitor.c seems to be missing. Yikes. The .c, .h, and .xml file were all missing. Apparently I forgot to re-add all the new files after resetting to split a patch. I've resent a version that actually has everything. Sorry for the trouble. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g: Fix UMAD on Cayman
I have made some progress with this issue. Vadim, I did as you suggested and tried to mimic the output from the shader analyser tool. I used your patch as a base and then tried various ways to see what would work. After many tries (and lockups) I did managed to get the ext_transform_feedback/order test to pass. It is a very ugly patch but it should illustrate what the problem (and potential solution) is. Your test program fails however because explicit break statements do not work. It should be possible to use the same code for the explicit breaks as for the implicit loop break.The reason it does not is that I detect the implicit break with a hack and it does notwork for explicit breaks. The problem is that I need to detect the break statement when creating the corresponding if statement. So that I can treat it differently than other regular if statements. Anyone knows how I could do that, or is this the wrong approach? //Martin On Thu, Apr 11, 2013 at 5:31 PM, Vadim Girlin vadimgir...@gmail.com wrote: On 04/11/2013 02:08 AM, Marek Olšák wrote: Here's the output: creating vs ... shader compilation status: OK creating fs ... shader compilation status: OK thread #0 (0;0) : ref = 16608 thread #1 (1;0) : ref = 27873 thread #2 (0;1) : ref = 16608 thread #3 (1;1) : ref = 27877 results: thread 0 (0, 0): expected = 16608, observed = 27876, FAIL thread 1 (1, 0): expected = 27873, observed = 27873, OK thread 2 (0, 1): expected = 16608, observed = 27876, FAIL thread 3 (1, 1): expected = 27877, observed = 27877, OK Thanks. According to these results, it looks like LOOP_START_DX10 for inner loop somehow reactivates the threads that were put into inactive-break state by the LOOP_BREAK in the outer loop. Also it seems LOOP_BREAK in the inner loop doesn't work as expected in this case. In other words, it looks weird. I can't explain why would this happen. It might be interesting to run these tests with llvm backend to see if there are any differences. Probably it might help if we'll implement LOOP_BREAK via EXECUTE_MASK_OP in the PRED_SET encoding as in my earlier patch, but without any stack push/pop operations and jumps (where it's possible), closer to what the catalyst (shader analyzer) does. I'm not sure if it will help though, and anyway we'll need stack operations in some cases, so I'm afraid this won't fix the issue completely. So far I have no other ideas. Vadim Marek On Wed, Apr 10, 2013 at 11:42 PM, Vadim Girlin vadimgir...@gmail.comwrote: On 04/10/2013 01:53 PM, Marek Olšák wrote: glsl-fs-loop-nested passes here. nstack is 3 and adding 4 to it doesn't help. Ok, thanks. Also I wrote a simple test app that should reproduce the issue if it's really related to diverging control flow with nested loops and might more information about what's going wrong. The source is in the attachment and needs to be compiled with -lGL -lglut -lGLEW. The app renders four points and computes some value for each point in the loops similar to the transform feedback order test, but it doesn't use tfb. It should render four green or red squares depending on correctness of the result. Here is the correct output produced for me on evergreen: thread 0 (0, 0): expected = 16608, observed = 16608, OK thread 1 (1, 0): expected = 27873, observed = 27873, OK thread 2 (0, 1): expected = 16608, observed = 16608, OK thread 3 (1, 1): expected = 27877, observed = 27877, OK Please post the output if it fails on cayman. Vadim Marek On Wed, Apr 10, 2013 at 8:46 AM, Vadim Girlin vadimgir...@gmail.com wrote: On 04/10/2013 03:58 AM, Marek Olšák wrote: Hi Vadim, your patch does not fix the test. Hmm, I'm out of ideas then. Thanks for testing. I've checked the shader dump few times but I don't see anything obviously wrong there, and the same code (except the minor ALU grouping changes due to the VLIW4/VLIW5 difference) works fine for me on evergreen. According to the Martin's observations it looks like if the threads that shouldn't execute the loop body were incorrectly left in the active state. LOOP_BREAK should put them into the inactive-break state, but something goes wrong. Do the other piglit tests with nested loops (e.g. glsl-fs-loop-nested) work on cayman? Though possibly there are no other tests with the diverging loops as in this case. I'll try to write a simpler test with the diverging loops to see if the issue is really caused by the incorrect control flow handling, and to figure out the exact instruction that results in the incorrect active state. Also probably it worth checking if the stack size is correct for that shader (latest mesa should print nstack value in the shader disassemble header, I think it should be 3 for that shader) and maybe try adding some constant, e.g. 4 to the bc-nstack in the r600_bytecode_build just to be sure that we reserve enough of stack space, though I don't think stack
Re: [Mesa-dev] [PATCH 01/12] sso: Create extensions entry points
Please, patches for Mesa have to actually be addressed to Mesa. I'm really excited to see progress on SSO, so hopefully we can get some of this landed soon. gregory gregory.hain...@gmail.com writes: V2: formatting improvement patch versioning generally comes at the end of the commit message. Also, could you fix up your git author info to include your full name? diff --git a/src/mapi/glapi/gen/ARB_separate_shader_objects.xml b/src/mapi/glapi/gen/ARB_separate_shader_objects.xml new file mode 100644 index 000..29a37f5 --- /dev/null +++ b/src/mapi/glapi/gen/ARB_separate_shader_objects.xml + function name=GenProgramPipelines offset=assign + param name=n type=GLsizei / + param name=pipelines type=GLuint * / + /function + function name=IsProgramPipeline offset=assign + param name=pipeline type=GLuint / + return type=GLboolean/ + /function Missing ProgramParameteri here. + function name=GetProgramPipelineiv offset=assign + param name=pipeline type=GLuint / + param name=pname type=GLenum / + param name=params type=GLint * / + /function + !-- depends on GL_ARB_gpu_shader_fp64 +function name=ProgramUniform1d offset=assign +param name=program type=GLuint / +param name=location type=GLint / +param name=x type=GLdouble / +/function Indentation suddenly changed for the double-valued uniform commands, could they be made consistent with the ones above? +function name=ProgramUniformMatrix2dv offset=assign +param name=program type=GLuint / +param name=location type=GLint / +param name=count type=GLsizei / +param name=transpose type=GLboolean / +param name=value type=const GLdouble * / +/function +function name=ProgramUniformMatrix3dv offset=assign +param name=program type=GLuint / +param name=location type=GLint / +param name=count type=GLsizei / +param name=transpose type=GLboolean / +param name=value type=const GLdouble * / +/function +function name=ProgramUniformMatrix4dv offset=assign +param name=program type=GLuint / +param name=location type=GLint / +param name=count type=GLsizei / +param name=transpose type=GLboolean / +param name=value type=const GLdouble * / +/function +function name=ProgramUniform1dv offset=assign +param name=program type=GLuint / +param name=location type=GLint / +param name=count type=GLsizei / +param name=value type=const GLdouble * / +/function +function name=ProgramUniform2dv offset=assign +param name=program type=GLuint / +param name=location type=GLint / +param name=count type=GLsizei / +param name=value type=const GLdouble * / +/function +function name=ProgramUniform3dv offset=assign +param name=program type=GLuint / +param name=location type=GLint / +param name=count type=GLsizei / +param name=value type=const GLdouble * / +/function +function name=ProgramUniform4dv offset=assign +param name=program type=GLuint / +param name=location type=GLint / +param name=count type=GLsizei / +param name=value type=const GLdouble * / +/function These are sorted differently from the spec for reasons I don't follow, which made reviewing a little weird. diff --git a/src/mesa/main/pipelineobj.c b/src/mesa/main/pipelineobj.c new file mode 100644 index 000..651c1a0 --- /dev/null +++ b/src/mesa/main/pipelineobj.c @@ -0,0 +1,135 @@ +/* + * Mesa 3-D graphics library + * + * Copyright (C) 2013-2013 Gregory Hainaut gregory.hain...@gmail.com + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the Software), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included + * in all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * GREGORY HAINAUT 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. + */ Please use the updated MIT license, which doesn't explicitly name the author
Re: [Mesa-dev] [PATCH 2/2] i965: Add support for GL_AMD_performance_monitor on Ironlake.
Kenneth Graunke kenn...@whitecape.org writes:
Ironlake's counters are always enabled; userspace can simply send a
MI_REPROT_PERF_COUNT packet to take a snapshot of them. This makes it
easy to implement.
The counters are documented in the source code for the intel-gpu-tools
intel_perf_counters utility.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
+/**
+ * Is a performance monitor result available?
+ */
+static GLboolean
+brw_is_perf_monitor_result_available(struct gl_perf_monitor_object *m)
+{
+ struct brw_perf_monitor_object *monitor = brw_perf_monitor(m);
+ return !m-Active monitor-gpu_facing_bo
+ !drm_intel_bo_busy(monitor-gpu_facing_bo);
+}
This also needs to check for !drm_intel_bo_references by the batch --
otherwise if the batch hasn't flushed, we'll report result_available
when it isn't ready.
pgpaUaWM7xUJ5.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/12] sso: Create extensions entry points
On Fri, 12 Apr 2013 12:38:19 -0700 Eric Anholt e...@anholt.net wrote: Please, patches for Mesa have to actually be addressed to Mesa. What do you mean? The github tree (was requested by Jordan)? Or because the mail header doesn't contains mesa address (mail client setup issue that it is now fixed) ? I'm really excited to see progress on SSO, so hopefully we can get some of this landed soon. gregory gregory.hain...@gmail.com writes: V2: formatting improvement patch versioning generally comes at the end of the commit message. Also, could you fix up your git author info to include your full name? diff --git a/src/mapi/glapi/gen/ARB_separate_shader_objects.xml b/src/mapi/glapi/gen/ARB_separate_shader_objects.xml new file mode 100644 index 000..29a37f5 --- /dev/null +++ b/src/mapi/glapi/gen/ARB_separate_shader_objects.xml + function name=GenProgramPipelines offset=assign + param name=n type=GLsizei / + param name=pipelines type=GLuint * / + /function + function name=IsProgramPipeline offset=assign + param name=pipeline type=GLuint / + return type=GLboolean/ + /function Missing ProgramParameteri here. Unfortunately it complains about duplication. The function is already defined in ARB_get_program_binary.xml. I could put a dummy name with an alias. I don't see any specific syntax on the python. + function name=GetProgramPipelineiv offset=assign + param name=pipeline type=GLuint / + param name=pname type=GLenum / + param name=params type=GLint * / + /function + !-- depends on GL_ARB_gpu_shader_fp64 +function name=ProgramUniform1d offset=assign +param name=program type=GLuint / +param name=location type=GLint / +param name=x type=GLdouble / +/function Indentation suddenly changed for the double-valued uniform commands, could they be made consistent with the ones above? +function name=ProgramUniformMatrix2dv offset=assign +param name=program type=GLuint / +param name=location type=GLint / +param name=count type=GLsizei / +param name=transpose type=GLboolean / +param name=value type=const GLdouble * / +/function +function name=ProgramUniformMatrix3dv offset=assign +param name=program type=GLuint / +param name=location type=GLint / +param name=count type=GLsizei / +param name=transpose type=GLboolean / +param name=value type=const GLdouble * / +/function +function name=ProgramUniformMatrix4dv offset=assign +param name=program type=GLuint / +param name=location type=GLint / +param name=count type=GLsizei / +param name=transpose type=GLboolean / +param name=value type=const GLdouble * / +/function +function name=ProgramUniform1dv offset=assign +param name=program type=GLuint / +param name=location type=GLint / +param name=count type=GLsizei / +param name=value type=const GLdouble * / +/function +function name=ProgramUniform2dv offset=assign +param name=program type=GLuint / +param name=location type=GLint / +param name=count type=GLsizei / +param name=value type=const GLdouble * / +/function +function name=ProgramUniform3dv offset=assign +param name=program type=GLuint / +param name=location type=GLint / +param name=count type=GLsizei / +param name=value type=const GLdouble * / +/function +function name=ProgramUniform4dv offset=assign +param name=program type=GLuint / +param name=location type=GLint / +param name=count type=GLsizei / +param name=value type=const GLdouble * / +/function These are sorted differently from the spec for reasons I don't follow, which made reviewing a little weird. I follow that, not sure it the golden reference: http://www.opengl.org/registry/specs/ARB/separate_shader_objects.txt The only different is that I pack all double stuff at the end to avoid multiple comment. diff --git a/src/mesa/main/pipelineobj.c b/src/mesa/main/pipelineobj.c new file mode 100644 index 000..651c1a0 --- /dev/null +++ b/src/mesa/main/pipelineobj.c @@ -0,0 +1,135 @@ +/* + * Mesa 3-D graphics library + * + * Copyright (C) 2013-2013 Gregory Hainaut gregory.hain...@gmail.com + * + * 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 + *
Re: [Mesa-dev] [PATCH resend] mesa: Add core support for the GL_AMD_performance_monitor extension.
diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
index 8f3cd3d..60e7653 100644
--- a/src/mesa/main/dd.h
+++ b/src/mesa/main/dd.h
@@ -646,6 +646,28 @@ struct dd_function_table {
void (*WaitQuery)(struct gl_context *ctx, struct gl_query_object *q);
/*@}*/
+ /**
+* \name Performance monitors
+*/
+ /*@{*/
+ struct gl_perf_monitor_object * (*NewPerfMonitor)(void);
+ void (*DeletePerfMonitor)(struct gl_perf_monitor_object *m);
+ void (*BeginPerfMonitor)(struct gl_context *ctx,
+struct gl_perf_monitor_object *m);
+
+ /** Stop an active performance monitor, discarding results. */
+ void (*ResetPerfMonitor)(struct gl_context *ctx,
+struct gl_perf_monitor_object *m);
+ void (*EndPerfMonitor)(struct gl_context *ctx,
+ struct gl_perf_monitor_object *m);
+ GLboolean (*IsPerfMonitorResultAvailable)(struct gl_perf_monitor_object
*m);
+ void (*GetPerfMonitorResult)(struct gl_context *ctx,
+struct gl_perf_monitor_object *m,
+GLsizei dataSize,
+GLuint *data,
+GLint *bytesWritten);
+ /*@}*/
+
/**
* \name Vertex Array objects
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index e46fa39..892f8e8 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -1774,6 +1774,87 @@ struct gl_transform_feedback_state
/**
+ * A performance monitor as described in AMD_performance_monitor.
+ */
+struct gl_perf_monitor_object
+{
+ GLboolean Active;
+
+ /* Actually BITSET_WORD but we can't #include that here. */
+ GLuint *ActiveCounters;
This should probably be void * instead of something you might
acidentally do the wrong bitfield manipulation on.
+void GLAPIENTRY
+_mesa_GetPerfMonitorGroupStringAMD(GLuint group, GLsizei bufSize,
+ GLsizei *length, GLchar *groupString)
+{
+ GET_CURRENT_CONTEXT(ctx);
+
+ const struct gl_perf_monitor_group *group_obj = get_group(ctx, group);
+
+ if (group_obj == NULL) {
+ _mesa_error(ctx, GL_INVALID_VALUE, glGetPerfMonitorGroupStringAMD);
+ return;
+ }
+
+ if (bufSize == 0) {
+ /* Return the number of characters that would be required to hold the
+ * group string, excluding the null terminator.
+ */
+ if (length != NULL)
+ *length = strlen(group_obj-Name);
+ } else {
+ if (length != NULL)
+ *length = MIN2(strlen(group_obj-Name), bufSize);
+ if (groupString != NULL)
+ strncpy(groupString, group_obj-Name, bufSize);
I think you could use the usual _mesa_copy_string() here (and
elsewhere). It enforces null termination, which seems like a really
good idea.
+void GLAPIENTRY
+_mesa_GetPerfMonitorCounterStringAMD(GLuint group, GLuint counter,
+ GLsizei bufSize, GLsizei *length,
+ GLchar *counterString)
+{
+ GET_CURRENT_CONTEXT(ctx);
+
+ const struct gl_perf_monitor_counter *counter_obj;
+
+ /* Validate the group even though we don't use it. */
+ if (get_group(ctx, group) == NULL) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ glGetPerfMonitorCounterStringAMD(invalid group));
+ return;
+ }
+
+ if (counter = ctx-PerfMonitor.NumCounters) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ glGetPerfMonitorCounterStringAMD(invalid counter));
+ return;
+ }
+
+ counter_obj = ctx-PerfMonitor.Counters[counter];
Also check that counter_obj-GroupID == group (or counter does not
reference a valid counter within the group ID)
+void GLAPIENTRY
+_mesa_GetPerfMonitorCounterInfoAMD(GLuint group, GLuint counter, GLenum
pname,
+ GLvoid *data)
+{
+ GET_CURRENT_CONTEXT(ctx);
+
+ const struct gl_perf_monitor_counter *counter_obj;
+
+ /* Validate the group even though we don't use it. */
+ if (get_group(ctx, group) == NULL) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ glGetPerfMonitorCounterInfoAMD(invalid group));
+ return;
+ }
+
+ if (counter = ctx-PerfMonitor.NumCounters) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ glGetPerfMonitorCounterInfoAMD(invalid counter));
+ return;
+ }
+
+ counter_obj = ctx-PerfMonitor.Counters[counter];
Same.
+void GLAPIENTRY
+_mesa_SelectPerfMonitorCountersAMD(GLuint monitor, GLboolean enable,
+ GLuint group, GLint numCounters,
+ GLuint *counterList)
+{
+ GET_CURRENT_CONTEXT(ctx);
+ int i;
+ struct gl_perf_monitor_object *m = lookup_monitor(ctx, monitor);
+ /* When SelectPerfMonitorCountersAMD is called on a monitor, any
outstanding
+* results for that monitor become
Re: [Mesa-dev] [PATCH 01/12] sso: Create extensions entry points
gregory hainaut gregory.hain...@gmail.com writes: On Fri, 12 Apr 2013 12:38:19 -0700 Eric Anholt e...@anholt.net wrote: Please, patches for Mesa have to actually be addressed to Mesa. What do you mean? The github tree (was requested by Jordan)? Or because the mail header doesn't contains mesa address (mail client setup issue that it is now fixed) ? The mail header. + function name=GenProgramPipelines offset=assign + param name=n type=GLsizei / + param name=pipelines type=GLuint * / + /function + function name=IsProgramPipeline offset=assign + param name=pipeline type=GLuint / + return type=GLboolean/ + /function Missing ProgramParameteri here. Unfortunately it complains about duplication. The function is already defined in ARB_get_program_binary.xml. I could put a dummy name with an alias. I don't see any specific syntax on the python. Ah, it already exists. Great. (A little comment here would be reasonable) I'm surprised this patch builds -- I thought we had requirements that Mesa functions be present for all the new stuff in the API XML right away (unless explicitly marked somehow), but the uniform double functions aren't present. Have you run make check on this patch? Normally it must build fine except if I screw up on a rebase. I comment the uniform double on the xml. If you prefer I can reenable them on the xml and put dummy uniform function. Oh, I missed that the whole block was commented out in the XML -- I thought the comment block was closed. Makes sense now. pgpMELrcHtdKU.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: Handle new format for configuration values emitted by the LLVM backend
From: Tom Stellard thomas.stell...@amd.com
Instead of emitting configuration values (e.g. number of gprs used) in a
predefined order, the LLVM backend now emits these values in
register/value pairs. The first dword contains the register address and
the second dword contians the value to write.
---
src/gallium/drivers/radeonsi/radeonsi_shader.c | 26 +++---
1 file changed, 23 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/radeonsi_shader.c
b/src/gallium/drivers/radeonsi/radeonsi_shader.c
index 0aeecc2..2f9c9d4 100644
--- a/src/gallium/drivers/radeonsi/radeonsi_shader.c
+++ b/src/gallium/drivers/radeonsi/radeonsi_shader.c
@@ -1175,9 +1175,29 @@ int si_pipe_shader_create(
}
}
- shader-num_sgprs = util_le32_to_cpu(*(uint32_t*)binary.config);
- shader-num_vgprs = util_le32_to_cpu(*(uint32_t*)(binary.config + 4));
- shader-spi_ps_input_ena = util_le32_to_cpu(*(uint32_t*)(binary.config
+ 8));
+ /* XXX: We may be able to emit some of these values directly rather than
+* extracting fields to be emitted later.
+*/
+ for (i = 0; i binary.config_size; i+= 8) {
+ unsigned reg = util_le32_to_cpu(*(uint32_t*)(binary.config +
i));
+ unsigned value = util_le32_to_cpu(*(uint32_t*)(binary.config +
i + 4));
+ switch (reg) {
+ case R_00B028_SPI_SHADER_PGM_RSRC1_PS:
+ case R_00B128_SPI_SHADER_PGM_RSRC1_VS:
+ case R_00B228_SPI_SHADER_PGM_RSRC1_GS:
+ case R_00B848_COMPUTE_PGM_RSRC1:
+ shader-num_sgprs = (G_00B028_SGPRS(value) + 1) * 8;
+ shader-num_vgprs = (G_00B028_VGPRS(value) + 1) * 4;
+ break;
+ case R_0286CC_SPI_PS_INPUT_ENA:
+ shader-spi_ps_input_ena = value;
+ break;
+ default:
+ fprintf(stderr, Warning: Compiler emitted unknown
+ config register: 0x%x\n, reg);
+ break;
+ }
+ }
radeon_llvm_dispose(si_shader_ctx.radeon_bld);
tgsi_parse_free(si_shader_ctx.parse);
--
1.8.1.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g: Fix UMAD on Cayman
On 04/12/2013 11:36 PM, Martin Andersson wrote: I have made some progress with this issue. Vadim, I did as you suggested and tried to mimic the output from the shader analyser tool. I used your patch as a base and then tried various ways to see what would work. After many tries (and lockups) I did managed to get the ext_transform_feedback/order test to pass. It is a very ugly patch but it should illustrate what the problem (and potential solution) is. Your test program fails however because explicit break statements do not work. It should be possible to use the same code for the explicit breaks as for the implicit loop break.The reason it does not is that I detect the implicit break with a hack and it does notwork for explicit breaks. The problem is that I need to detect the break statement when creating the corresponding if statement. So that I can treat it differently than other regular if statements. Anyone knows how I could do that, or is this the wrong approach? It doesn't work with my test app because IF/ENDIF blocks with BRK may contain other code, so you can't simply throw away IF/ENDIF making that code execute unconditionally. By the way, shader analyzer in some cases also produces the code with JUMP/POP around PRED_SET-BREAK, though I'm not sure if that code will really work as expected with catalyst. Possibly we're simply missing something in the hardware configuration. Also there is one thing that I didn't take into account in my initial patch - r600g converts ALU followed by POP to ALU_POP_AFTER and this might explain why my initial patch doesn't work. Possibly if we prevent that optimization for ALU containing PRED_SET-BREAK and leave separate POP, it might be enough to make it work. I'm attaching the additional patch that will force POP to be a separate instruction in this case, please test it (on top of the my first patch). This would be at least not very intrusive. If this won't help, then I think we should understand what exactly we are trying to fix before implementing any big changes, possibly there is a better solution or at least a more clean workaround. In the worst case we can return to your approach and improve it to handle other cases. Vadim //Martin On Thu, Apr 11, 2013 at 5:31 PM, Vadim Girlin vadimgir...@gmail.com wrote: On 04/11/2013 02:08 AM, Marek Olšák wrote: Here's the output: creating vs ... shader compilation status: OK creating fs ... shader compilation status: OK thread #0 (0;0) : ref = 16608 thread #1 (1;0) : ref = 27873 thread #2 (0;1) : ref = 16608 thread #3 (1;1) : ref = 27877 results: thread 0 (0, 0): expected = 16608, observed = 27876, FAIL thread 1 (1, 0): expected = 27873, observed = 27873, OK thread 2 (0, 1): expected = 16608, observed = 27876, FAIL thread 3 (1, 1): expected = 27877, observed = 27877, OK Thanks. According to these results, it looks like LOOP_START_DX10 for inner loop somehow reactivates the threads that were put into inactive-break state by the LOOP_BREAK in the outer loop. Also it seems LOOP_BREAK in the inner loop doesn't work as expected in this case. In other words, it looks weird. I can't explain why would this happen. It might be interesting to run these tests with llvm backend to see if there are any differences. Probably it might help if we'll implement LOOP_BREAK via EXECUTE_MASK_OP in the PRED_SET encoding as in my earlier patch, but without any stack push/pop operations and jumps (where it's possible), closer to what the catalyst (shader analyzer) does. I'm not sure if it will help though, and anyway we'll need stack operations in some cases, so I'm afraid this won't fix the issue completely. So far I have no other ideas. Vadim Marek On Wed, Apr 10, 2013 at 11:42 PM, Vadim Girlin vadimgir...@gmail.comwrote: On 04/10/2013 01:53 PM, Marek Olšák wrote: glsl-fs-loop-nested passes here. nstack is 3 and adding 4 to it doesn't help. Ok, thanks. Also I wrote a simple test app that should reproduce the issue if it's really related to diverging control flow with nested loops and might more information about what's going wrong. The source is in the attachment and needs to be compiled with -lGL -lglut -lGLEW. The app renders four points and computes some value for each point in the loops similar to the transform feedback order test, but it doesn't use tfb. It should render four green or red squares depending on correctness of the result. Here is the correct output produced for me on evergreen: thread 0 (0, 0): expected = 16608, observed = 16608, OK thread 1 (1, 0): expected = 27873, observed = 27873, OK thread 2 (0, 1): expected = 16608, observed = 16608, OK thread 3 (1, 1): expected = 27877, observed = 27877, OK Please post the output if it fails on cayman. Vadim Marek On Wed, Apr 10, 2013 at 8:46 AM, Vadim Girlin vadimgir...@gmail.com wrote: On 04/10/2013 03:58 AM, Marek Olšák wrote: Hi Vadim, your patch does not fix the test. Hmm,
