Re: [Mesa-dev] [PATCH 3/4] intel: Add a flag for miptree mapping to disable transcoding.
On Tue, Feb 26, 2013 at 11:15 PM, Eric Anholt e...@anholt.net wrote:
I want to reuse intel_miptree_map() to replace some region mapping that's
broken for separate stencil, but doing so would result in new demands on
ETC transcode that we actually don't want to happen.
---
src/mesa/drivers/dri/intel/intel_mipmap_tree.c |8
src/mesa/drivers/dri/intel/intel_mipmap_tree.h | 11 +++
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
index 306cbbe..217f13d 100644
--- a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
@@ -1575,9 +1575,9 @@ intel_miptree_map_singlesample(struct intel_context
*intel,
if (mt-format == MESA_FORMAT_S8) {
intel_miptree_map_s8(intel, mt, map, level, slice);
- } else if (mt-wraps_etc) {
+ } else if (mt-wraps_etc !(mode BRW_MAP_DIRECT_BIT)) {
intel_miptree_map_etc(intel, mt, map, level, slice);
- } else if (mt-stencil_mt) {
+ } else if (mt-stencil_mt !(mode BRW_MAP_DIRECT_BIT)) {
intel_miptree_map_depthstencil(intel, mt, map, level, slice);
}
/* According to the Ivy Bridge PRM, Vol1 Part4, section 1.2.1.2 (Graphics
@@ -1633,9 +1633,9 @@ intel_miptree_unmap_singlesample(struct intel_context
*intel,
if (mt-format == MESA_FORMAT_S8) {
intel_miptree_unmap_s8(intel, mt, map, level, slice);
- } else if (mt-wraps_etc) {
+ } else if (mt-wraps_etc !(map-mode BRW_MAP_DIRECT_BIT)) {
intel_miptree_unmap_etc(intel, mt, map, level, slice);
- } else if (mt-stencil_mt) {
+ } else if (mt-stencil_mt !(map-mode BRW_MAP_DIRECT_BIT)) {
intel_miptree_unmap_depthstencil(intel, mt, map, level, slice);
} else if (map-bo) {
intel_miptree_unmap_blit(intel, mt, map, level, slice);
diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.h
b/src/mesa/drivers/dri/intel/intel_mipmap_tree.h
index 27540bc..acd5e9e 100644
--- a/src/mesa/drivers/dri/intel/intel_mipmap_tree.h
+++ b/src/mesa/drivers/dri/intel/intel_mipmap_tree.h
@@ -66,6 +66,17 @@ extern C {
struct intel_resolve_map;
struct intel_texture_image;
+/**
+ * When calling intel_miptree_map() on an ETC-transcoded-to-RGB miptree or a
+ * depthstencil-split-to-separate-stencil miptree, we'll normally make a
+ * tmeporary and recreate the kind of data requested by Mesa core, since
we're
^
Typo.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] build: remove unused API_DEFINES
--- Depends on Brian's remove-mfeatures branch. configure.ac |3 --- src/gallium/targets/egl-static/Makefile.am |3 +-- src/glsl/Makefile.am |3 +-- src/mesa/Makefile.am |2 +- src/mesa/drivers/dri/common/Makefile.am|1 - src/mesa/drivers/dri/i915/Makefile.am |1 - src/mesa/drivers/dri/i965/Makefile.am |1 - src/mesa/drivers/dri/nouveau/Makefile.am |1 - src/mesa/drivers/dri/r200/Makefile.am |1 - src/mesa/drivers/dri/radeon/Makefile.am|1 - src/mesa/drivers/dri/swrast/Makefile.am|1 - src/mesa/drivers/osmesa/Makefile.am|3 +-- src/mesa/drivers/x11/Makefile.am |1 - src/mesa/libdricore/Makefile.am|1 - src/mesa/main/tests/Makefile.am|2 +- src/mesa/main/tests/hash_table/Makefile.am |2 +- src/mesa/program/Makefile.am |2 +- src/mesa/x86-64/Makefile.am|1 - src/mesa/x86/Makefile.am |1 - 19 files changed, 7 insertions(+), 24 deletions(-) diff --git a/configure.ac b/configure.ac index 94304e1..98c2293 100644 --- a/configure.ac +++ b/configure.ac @@ -685,9 +685,6 @@ if test x$enable_opengl = xno -a \ AC_MSG_ERROR([at least one API should be enabled]) fi -API_DEFINES= -AC_SUBST([API_DEFINES]) - if test x$enable_glx = xno; then AC_MSG_WARN([GLX disabled, disabling Xlib-GLX]) enable_xlib_glx=no diff --git a/src/gallium/targets/egl-static/Makefile.am b/src/gallium/targets/egl-static/Makefile.am index 5c40ae8..3bd9781 100644 --- a/src/gallium/targets/egl-static/Makefile.am +++ b/src/gallium/targets/egl-static/Makefile.am @@ -100,8 +100,7 @@ endif if HAVE_OPENGL AM_CPPFLAGS += \ - -I$(top_srcdir)/src/mesa \ - $(API_DEFINES) + -I$(top_srcdir)/src/mesa egl_gallium_la_LIBADD += \ $(top_builddir)/src/mesa/libmesagallium.la diff --git a/src/glsl/Makefile.am b/src/glsl/Makefile.am index d0e5cd1..2bbad3d 100644 --- a/src/glsl/Makefile.am +++ b/src/glsl/Makefile.am @@ -27,8 +27,7 @@ AM_CPPFLAGS = \ -I$(top_srcdir)/src/mesa/ \ -I$(top_srcdir)/src/glsl/glcpp \ -I$(top_srcdir)/src/gtest/include \ - $(DEFINES) \ - $(API_DEFINES) + $(DEFINES) AM_CFLAGS = $(VISIBILITY_CFLAGS) AM_CXXFLAGS = $(VISIBILITY_CXXFLAGS) diff --git a/src/mesa/Makefile.am b/src/mesa/Makefile.am index 84fc3eb..23bd82f 100644 --- a/src/mesa/Makefile.am +++ b/src/mesa/Makefile.am @@ -81,7 +81,7 @@ SRCDIR = $(top_srcdir)/src/mesa/ BUILDDIR = $(top_builddir)/src/mesa/ include sources.mak -AM_CPPFLAGS = $(API_DEFINES) $(DEFINES) $(INCLUDE_DIRS) +AM_CPPFLAGS = $(DEFINES) $(INCLUDE_DIRS) AM_CFLAGS = $(LLVM_CFLAGS) $(VISIBILITY_CFLAGS) AM_CXXFLAGS = $(LLVM_CFLAGS) $(VISIBILITY_CXXFLAGS) diff --git a/src/mesa/drivers/dri/common/Makefile.am b/src/mesa/drivers/dri/common/Makefile.am index dfc8f3b..ce4119d 100644 --- a/src/mesa/drivers/dri/common/Makefile.am +++ b/src/mesa/drivers/dri/common/Makefile.am @@ -27,7 +27,6 @@ AM_CFLAGS = \ -I$(top_srcdir)/src/mapi \ -I$(top_srcdir)/src/mesa/ \ $(DEFINES) \ - $(API_DEFINES) \ $(LIBDRM_CFLAGS) \ $(VISIBILITY_CFLAGS) diff --git a/src/mesa/drivers/dri/i915/Makefile.am b/src/mesa/drivers/dri/i915/Makefile.am index 72e0659..be3494f 100644 --- a/src/mesa/drivers/dri/i915/Makefile.am +++ b/src/mesa/drivers/dri/i915/Makefile.am @@ -34,7 +34,6 @@ AM_CFLAGS = \ -I$(top_srcdir)/src/mesa/drivers/dri/intel/server \ -I$(top_builddir)/src/mesa/drivers/dri/common \ $(DEFINES) \ - $(API_DEFINES) \ $(VISIBILITY_CFLAGS) \ $(INTEL_CFLAGS) diff --git a/src/mesa/drivers/dri/i965/Makefile.am b/src/mesa/drivers/dri/i965/Makefile.am index dc140df..b7a1eee 100644 --- a/src/mesa/drivers/dri/i965/Makefile.am +++ b/src/mesa/drivers/dri/i965/Makefile.am @@ -36,7 +36,6 @@ AM_CFLAGS = \ -I$(top_srcdir)/src/gtest/include \ -I$(top_builddir)/src/mesa/drivers/dri/common \ $(DEFINES) \ - $(API_DEFINES) \ $(VISIBILITY_CFLAGS) \ $(INTEL_CFLAGS) diff --git a/src/mesa/drivers/dri/nouveau/Makefile.am b/src/mesa/drivers/dri/nouveau/Makefile.am index 00ee1df..2b47f75 100644 --- a/src/mesa/drivers/dri/nouveau/Makefile.am +++ b/src/mesa/drivers/dri/nouveau/Makefile.am @@ -30,7 +30,6 @@ AM_CFLAGS = \ -I$(top_srcdir)/src/mesa/ \ -I$(top_srcdir)/src/mesa/drivers/dri/common \ $(DEFINES) \ - $(API_DEFINES) \ $(VISIBILITY_CFLAGS) \ $(NOUVEAU_CFLAGS) diff --git a/src/mesa/drivers/dri/r200/Makefile.am b/src/mesa/drivers/dri/r200/Makefile.am index 4991399..4357922 100644 --- a/src/mesa/drivers/dri/r200/Makefile.am +++ b/src/mesa/drivers/dri/r200/Makefile.am @@ -33,7 +33,6 @@ AM_CFLAGS = \ -I$(top_srcdir)/src/mesa/drivers/dri/r200/server \ -I$(top_builddir)/src/mesa/drivers/dri/common \
Re: [Mesa-dev] [PATCH] texobj: add verbose api trace messages to several routines
- Original Message - Jordan Justen jordan.l.jus...@intel.com writes: Motivated by wanting to see if GenTextures was called by an application while debugging another Steam overlay issue. Making a systematic MESA_DEBUG=api using dispatch tables and code generation seems like it would be nice instead of adding it ad-hoc. Not something against this patch, just maybe a project for a janitor list if we have one. apitrace seems like it would be to replace it, but I've seen enough apps where it doesn't work (and in this case with the steam overlay it definitely doesn't) that we can't just rely on that. Could you elaborate on that? I'd like to understand how apitrace would miss intercepting calls. A apart of some bug, the only explanation I can think of is calls done inside Callists. If so then the only way to zoom in would be for Apitrace to actually implement callists itself, and then inline them. But this would have several side effects, and be too onerous for a legacy feature. There is also internal meta calls... Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] llvmpipe: support rendering to buffer render targets.
What is this good for? Is it for UAVs? (unordered access views)
For UAVs, I think there is ARB_shader_storage_buffer_object and
pipe_context::set_shader_resources.
Marek
On Wed, Feb 27, 2013 at 3:18 AM, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
Unfortunately not usable from OpenGL, and no cap bit.
Pretty similar to a 1d texture, though allows specifying a start element.
The util code for handling clears also needs adjustments (and fix
a bug causing crashes for handling pure integer formats there too).
---
src/gallium/auxiliary/util/u_surface.c | 55
+++
src/gallium/drivers/llvmpipe/lp_rast.c | 25 ++--
src/gallium/drivers/llvmpipe/lp_rast_priv.h |4 +-
src/gallium/drivers/llvmpipe/lp_scene.c | 35 +++--
src/gallium/drivers/llvmpipe/lp_texture.c | 44 +++--
5 files changed, 108 insertions(+), 55 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_surface.c
b/src/gallium/auxiliary/util/u_surface.c
index b948b46..fba0798 100644
--- a/src/gallium/auxiliary/util/u_surface.c
+++ b/src/gallium/auxiliary/util/u_surface.c
@@ -323,20 +323,59 @@ util_clear_render_target(struct pipe_context *pipe,
if (!dst-texture)
return;
/* XXX: should handle multiple layers */
- dst_map = pipe_transfer_map(pipe,
- dst-texture,
- dst-u.tex.level,
- dst-u.tex.first_layer,
- PIPE_TRANSFER_WRITE,
- dstx, dsty, width, height, dst_trans);
+
+ if (dst-texture-target == PIPE_BUFFER) {
+ /*
+ * The fill naturally works on the surface format, however
+ * the transfer uses resource format which is just bytes for buffers.
+ */
+ unsigned dx, w;
+ unsigned pixstride = util_format_get_blocksize(dst-format);
+ dx = dstx * pixstride;
+ w = width * pixstride;
+ dst_map = pipe_transfer_map(pipe,
+ dst-texture,
+ 0, 0,
+ PIPE_TRANSFER_WRITE,
+ dx, 0, w, 1,
+ dst_trans);
+ dst_map = (uint8_t *)dst_map + dst-u.buf.first_element * pixstride;
+ }
+ else {
+ /* XXX: should handle multiple layers */
+ dst_map = pipe_transfer_map(pipe,
+ dst-texture,
+ dst-u.tex.level,
+ dst-u.tex.first_layer,
+ PIPE_TRANSFER_WRITE,
+ dstx, dsty, width, height, dst_trans);
+
+ }
assert(dst_map);
if (dst_map) {
+ enum pipe_format format = dst-format;
assert(dst_trans-stride 0);
- util_pack_color(color-f, dst-texture-format, uc);
- util_fill_rect(dst_map, dst-texture-format,
+ if (util_format_is_pure_integer(format)) {
+ /*
+ * We expect int/uint clear values here, though some APIs
+ * might disagree (but in any case util_pack_color()
+ * couldn't handle it)...
+ */
+ if (util_format_is_pure_sint(format)) {
+util_format_write_4i(format, color-i, 0, uc, 0, 0, 0, 1, 1);
+ }
+ else {
+assert(util_format_is_pure_uint(format));
+util_format_write_4ui(format, color-ui, 0, uc, 0, 0, 0, 1, 1);
+ }
+ }
+ else {
+ util_pack_color(color-f, dst-format, uc);
+ }
+ util_fill_rect(dst_map, dst-format,
dst_trans-stride,
0, 0, width, height, uc);
diff --git a/src/gallium/drivers/llvmpipe/lp_rast.c
b/src/gallium/drivers/llvmpipe/lp_rast.c
index b5e5da6..6183f41 100644
--- a/src/gallium/drivers/llvmpipe/lp_rast.c
+++ b/src/gallium/drivers/llvmpipe/lp_rast.c
@@ -165,32 +165,13 @@ lp_rast_clear_color(struct lp_rasterizer_task *task,
for (i = 0; i scene-fb.nr_cbufs; i++) {
enum pipe_format format = scene-fb.cbufs[i]-format;
-/*
- * XXX the format_write_4i/ui functions do clamping to max value
- * and I'm not sure that's actually right - spec doesn't seem to
- * say much about that topic. If it is should probably adjust the
- * border color handling to do the same. If not and chopping off
- * bits is the way to go, the write_4i and write_4ui functions
- * would be identical.
- */
-if (util_format_is_pure_sint(format)) {
- int rgba[4];
- rgba[0] = arg.clear_color.i[0];
- rgba[1] = arg.clear_color.i[1];
- rgba[2] = arg.clear_color.i[2];
- rgba[3] = arg.clear_color.i[3];
-
Re: [Mesa-dev] [PATCH] llvmpipe: support rendering to buffer render targets.
- Original Message -
What is this good for? Is it for UAVs? (unordered access views)
No, it is just a standard D3D10 feature:
http://msdn.microsoft.com/en-gb/library/windows/desktop/bb204897.aspx
Not sure if there's a particular use case for it (e.g, maybe DirectCompute uses
this extensively), or just a matter of symmetry in the API (ie., if one can
sample from buffer textures, then why not render into them?)
For UAVs, I think there is ARB_shader_storage_buffer_object and
pipe_context::set_shader_resources.
Yeah, D3D11 UAVs are also supposed to be bound separately in the pipeline.
Jose
Marek
On Wed, Feb 27, 2013 at 3:18 AM, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
Unfortunately not usable from OpenGL, and no cap bit.
Pretty similar to a 1d texture, though allows specifying a start element.
The util code for handling clears also needs adjustments (and fix
a bug causing crashes for handling pure integer formats there too).
---
src/gallium/auxiliary/util/u_surface.c | 55
+++
src/gallium/drivers/llvmpipe/lp_rast.c | 25 ++--
src/gallium/drivers/llvmpipe/lp_rast_priv.h |4 +-
src/gallium/drivers/llvmpipe/lp_scene.c | 35 +++--
src/gallium/drivers/llvmpipe/lp_texture.c | 44 +++--
5 files changed, 108 insertions(+), 55 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_surface.c
b/src/gallium/auxiliary/util/u_surface.c
index b948b46..fba0798 100644
--- a/src/gallium/auxiliary/util/u_surface.c
+++ b/src/gallium/auxiliary/util/u_surface.c
@@ -323,20 +323,59 @@ util_clear_render_target(struct pipe_context *pipe,
if (!dst-texture)
return;
/* XXX: should handle multiple layers */
- dst_map = pipe_transfer_map(pipe,
- dst-texture,
- dst-u.tex.level,
- dst-u.tex.first_layer,
- PIPE_TRANSFER_WRITE,
- dstx, dsty, width, height, dst_trans);
+
+ if (dst-texture-target == PIPE_BUFFER) {
+ /*
+ * The fill naturally works on the surface format, however
+ * the transfer uses resource format which is just bytes for
buffers.
+ */
+ unsigned dx, w;
+ unsigned pixstride = util_format_get_blocksize(dst-format);
+ dx = dstx * pixstride;
+ w = width * pixstride;
+ dst_map = pipe_transfer_map(pipe,
+ dst-texture,
+ 0, 0,
+ PIPE_TRANSFER_WRITE,
+ dx, 0, w, 1,
+ dst_trans);
+ dst_map = (uint8_t *)dst_map + dst-u.buf.first_element * pixstride;
+ }
+ else {
+ /* XXX: should handle multiple layers */
+ dst_map = pipe_transfer_map(pipe,
+ dst-texture,
+ dst-u.tex.level,
+ dst-u.tex.first_layer,
+ PIPE_TRANSFER_WRITE,
+ dstx, dsty, width, height, dst_trans);
+
+ }
assert(dst_map);
if (dst_map) {
+ enum pipe_format format = dst-format;
assert(dst_trans-stride 0);
- util_pack_color(color-f, dst-texture-format, uc);
- util_fill_rect(dst_map, dst-texture-format,
+ if (util_format_is_pure_integer(format)) {
+ /*
+ * We expect int/uint clear values here, though some APIs
+ * might disagree (but in any case util_pack_color()
+ * couldn't handle it)...
+ */
+ if (util_format_is_pure_sint(format)) {
+util_format_write_4i(format, color-i, 0, uc, 0, 0, 0, 1, 1);
+ }
+ else {
+assert(util_format_is_pure_uint(format));
+util_format_write_4ui(format, color-ui, 0, uc, 0, 0, 0, 1,
1);
+ }
+ }
+ else {
+ util_pack_color(color-f, dst-format, uc);
+ }
+ util_fill_rect(dst_map, dst-format,
dst_trans-stride,
0, 0, width, height, uc);
diff --git a/src/gallium/drivers/llvmpipe/lp_rast.c
b/src/gallium/drivers/llvmpipe/lp_rast.c
index b5e5da6..6183f41 100644
--- a/src/gallium/drivers/llvmpipe/lp_rast.c
+++ b/src/gallium/drivers/llvmpipe/lp_rast.c
@@ -165,32 +165,13 @@ lp_rast_clear_color(struct lp_rasterizer_task *task,
for (i = 0; i scene-fb.nr_cbufs; i++) {
enum pipe_format format = scene-fb.cbufs[i]-format;
-/*
- * XXX the format_write_4i/ui functions do clamping to max
value
- * and I'm not sure that's actually right - spec doesn't seem
to
- * say much about that
[Mesa-dev] [Bug 61361] Version mismatch error. This is libtool 2.4.2, but the definition of this LT_INIT comes from libtool 2.2.8.
https://bugs.freedesktop.org/show_bug.cgi?id=61361 --- Comment #1 from Andreas Boll andreas.boll@gmail.com --- Does this happen if you build from git or from release tarball? -- 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 57018] syntax error near unexpected token `[2.4.2]'
https://bugs.freedesktop.org/show_bug.cgi?id=57018 --- Comment #2 from Andreas Boll andreas.boll@gmail.com --- Does this happen if you build from git or from release tarball? -- 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] llvmpipe: support rendering to buffer render targets.
On 27.02.2013 10:44, Jose Fonseca wrote:
- Original Message -
What is this good for? Is it for UAVs? (unordered access views)
No, it is just a standard D3D10 feature:
http://msdn.microsoft.com/en-gb/library/windows/desktop/bb204897.aspx
Not sure if there's a particular use case for it (e.g, maybe DirectCompute
uses this extensively), or just a matter of symmetry in the API (ie., if one
can sample from buffer textures, then why not render into them?)
I can think of rendering to vertex buffers. It's just annoying that
there are no alignment restrictions on the range that is bound (worst
case you have to render to a temporary buffer and copy stuff around);
but at least it has to be = 8192 bytes (or elements, not sure) in D3D10.
For UAVs, I think there is ARB_shader_storage_buffer_object and
pipe_context::set_shader_resources.
Yeah, D3D11 UAVs are also supposed to be bound separately in the pipeline.
Jose
Marek
On Wed, Feb 27, 2013 at 3:18 AM, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
Unfortunately not usable from OpenGL, and no cap bit.
Pretty similar to a 1d texture, though allows specifying a start element.
The util code for handling clears also needs adjustments (and fix
a bug causing crashes for handling pure integer formats there too).
---
src/gallium/auxiliary/util/u_surface.c | 55
+++
src/gallium/drivers/llvmpipe/lp_rast.c | 25 ++--
src/gallium/drivers/llvmpipe/lp_rast_priv.h |4 +-
src/gallium/drivers/llvmpipe/lp_scene.c | 35 +++--
src/gallium/drivers/llvmpipe/lp_texture.c | 44 +++--
5 files changed, 108 insertions(+), 55 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_surface.c
b/src/gallium/auxiliary/util/u_surface.c
index b948b46..fba0798 100644
--- a/src/gallium/auxiliary/util/u_surface.c
+++ b/src/gallium/auxiliary/util/u_surface.c
@@ -323,20 +323,59 @@ util_clear_render_target(struct pipe_context *pipe,
if (!dst-texture)
return;
/* XXX: should handle multiple layers */
- dst_map = pipe_transfer_map(pipe,
- dst-texture,
- dst-u.tex.level,
- dst-u.tex.first_layer,
- PIPE_TRANSFER_WRITE,
- dstx, dsty, width, height, dst_trans);
+
+ if (dst-texture-target == PIPE_BUFFER) {
+ /*
+ * The fill naturally works on the surface format, however
+ * the transfer uses resource format which is just bytes for
buffers.
+ */
+ unsigned dx, w;
+ unsigned pixstride = util_format_get_blocksize(dst-format);
+ dx = dstx * pixstride;
+ w = width * pixstride;
+ dst_map = pipe_transfer_map(pipe,
+ dst-texture,
+ 0, 0,
+ PIPE_TRANSFER_WRITE,
+ dx, 0, w, 1,
+ dst_trans);
+ dst_map = (uint8_t *)dst_map + dst-u.buf.first_element * pixstride;
+ }
+ else {
+ /* XXX: should handle multiple layers */
+ dst_map = pipe_transfer_map(pipe,
+ dst-texture,
+ dst-u.tex.level,
+ dst-u.tex.first_layer,
+ PIPE_TRANSFER_WRITE,
+ dstx, dsty, width, height, dst_trans);
+
+ }
assert(dst_map);
if (dst_map) {
+ enum pipe_format format = dst-format;
assert(dst_trans-stride 0);
- util_pack_color(color-f, dst-texture-format, uc);
- util_fill_rect(dst_map, dst-texture-format,
+ if (util_format_is_pure_integer(format)) {
+ /*
+ * We expect int/uint clear values here, though some APIs
+ * might disagree (but in any case util_pack_color()
+ * couldn't handle it)...
+ */
+ if (util_format_is_pure_sint(format)) {
+util_format_write_4i(format, color-i, 0, uc, 0, 0, 0, 1, 1);
+ }
+ else {
+assert(util_format_is_pure_uint(format));
+util_format_write_4ui(format, color-ui, 0, uc, 0, 0, 0, 1,
1);
+ }
+ }
+ else {
+ util_pack_color(color-f, dst-format, uc);
+ }
+ util_fill_rect(dst_map, dst-format,
dst_trans-stride,
0, 0, width, height, uc);
diff --git a/src/gallium/drivers/llvmpipe/lp_rast.c
b/src/gallium/drivers/llvmpipe/lp_rast.c
index b5e5da6..6183f41 100644
--- a/src/gallium/drivers/llvmpipe/lp_rast.c
+++ b/src/gallium/drivers/llvmpipe/lp_rast.c
@@ -165,32 +165,13 @@ lp_rast_clear_color(struct lp_rasterizer_task *task,
for (i = 0; i scene-fb.nr_cbufs; i++) {
enum pipe_format format =
[Mesa-dev] [Bug 61415] Clover ignores --with-opencl-libdir path
https://bugs.freedesktop.org/show_bug.cgi?id=61415 Francisco Jerez curroje...@riseup.net changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Francisco Jerez curroje...@riseup.net --- Just pushed a patch clarifying the meanining of this configure option. Closing as fixed... -- 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 61415] Clover ignores --with-opencl-libdir path
https://bugs.freedesktop.org/show_bug.cgi?id=61415 --- Comment #7 from Mike Lothian m...@fireburn.co.uk --- Please could you clarify what libraries should be installed into this directory? I was building i965 r600g and clover all together and wasn't seeing anything in there -- 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] llvmpipe: support rendering to buffer render targets.
Am 27.02.2013 12:05, schrieb Christoph Bumiller:
On 27.02.2013 10:44, Jose Fonseca wrote:
- Original Message -
What is this good for? Is it for UAVs? (unordered access views)
No, it is just a standard D3D10 feature:
http://msdn.microsoft.com/en-gb/library/windows/desktop/bb204897.aspx
Not sure if there's a particular use case for it (e.g, maybe DirectCompute
uses this extensively), or just a matter of symmetry in the API (ie., if one
can sample from buffer textures, then why not render into them?)
I can think of rendering to vertex buffers. It's just annoying that
there are no alignment restrictions on the range that is bound (worst
case you have to render to a temporary buffer and copy stuff around);
but at least it has to be = 8192 bytes (or elements, not sure) in D3D10.
It is 8192 elements (so same as 1d texture width really).
There is some minimal alignment restriction, the range needs to be
aligned to element width (this follows from specifying the start in
terms of elements directly). Well at least if I understand everything
correctly it doesn't work so well in testing yet :-).
I thought hw would be able to do this without hacks but can't tell for
sure. Note that d3d10 prevents you from having a depth buffer bound at
the same time if you use that feature so it's quite limited (though I
think this follows from the requirement that depth/stencil buffers need
same resource type as rendertargets, and you can't bind buffers as
depth/stencil).
All OpenGL extensions I've seen which allow you to write to some kind of
buffer require some special means to do that, and don't allow buffers to
be bound as ordinary render targets. Might be a mess to specify wrt
framebuffer (completeness requirements etc.) and due to
non-orthogonality (no depth buffer).
Roland
For UAVs, I think there is ARB_shader_storage_buffer_object and
pipe_context::set_shader_resources.
Yeah, D3D11 UAVs are also supposed to be bound separately in the pipeline.
Jose
Marek
On Wed, Feb 27, 2013 at 3:18 AM, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
Unfortunately not usable from OpenGL, and no cap bit.
Pretty similar to a 1d texture, though allows specifying a start element.
The util code for handling clears also needs adjustments (and fix
a bug causing crashes for handling pure integer formats there too).
---
src/gallium/auxiliary/util/u_surface.c | 55
+++
src/gallium/drivers/llvmpipe/lp_rast.c | 25 ++--
src/gallium/drivers/llvmpipe/lp_rast_priv.h |4 +-
src/gallium/drivers/llvmpipe/lp_scene.c | 35 +++--
src/gallium/drivers/llvmpipe/lp_texture.c | 44 +++--
5 files changed, 108 insertions(+), 55 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_surface.c
b/src/gallium/auxiliary/util/u_surface.c
index b948b46..fba0798 100644
--- a/src/gallium/auxiliary/util/u_surface.c
+++ b/src/gallium/auxiliary/util/u_surface.c
@@ -323,20 +323,59 @@ util_clear_render_target(struct pipe_context *pipe,
if (!dst-texture)
return;
/* XXX: should handle multiple layers */
- dst_map = pipe_transfer_map(pipe,
- dst-texture,
- dst-u.tex.level,
- dst-u.tex.first_layer,
- PIPE_TRANSFER_WRITE,
- dstx, dsty, width, height, dst_trans);
+
+ if (dst-texture-target == PIPE_BUFFER) {
+ /*
+ * The fill naturally works on the surface format, however
+ * the transfer uses resource format which is just bytes for
buffers.
+ */
+ unsigned dx, w;
+ unsigned pixstride = util_format_get_blocksize(dst-format);
+ dx = dstx * pixstride;
+ w = width * pixstride;
+ dst_map = pipe_transfer_map(pipe,
+ dst-texture,
+ 0, 0,
+ PIPE_TRANSFER_WRITE,
+ dx, 0, w, 1,
+ dst_trans);
+ dst_map = (uint8_t *)dst_map + dst-u.buf.first_element * pixstride;
+ }
+ else {
+ /* XXX: should handle multiple layers */
+ dst_map = pipe_transfer_map(pipe,
+ dst-texture,
+ dst-u.tex.level,
+ dst-u.tex.first_layer,
+ PIPE_TRANSFER_WRITE,
+ dstx, dsty, width, height, dst_trans);
+
+ }
assert(dst_map);
if (dst_map) {
+ enum pipe_format format = dst-format;
assert(dst_trans-stride 0);
- util_pack_color(color-f, dst-texture-format, uc);
- util_fill_rect(dst_map, dst-texture-format,
+ if (util_format_is_pure_integer(format)) {
+ /*
+ * We expect int/uint clear values here, though
Re: [Mesa-dev] [PATCH] llvmpipe: support rendering to buffer render targets.
Looks good.
I think the u_surface change could go in separately though.
BTW, now that we can render/sampler from buffers,
llvmpipe_is_resource_referenced needs to be updated: buffer may be referenced
if they have BIND_SAMPLER/RENDERTARGET.
Weshould do something like if !BIND_SAMPLER/RENDERTARGET, return UNREFERENCED.
Jose
- Original Message -
From: Roland Scheidegger srol...@vmware.com
Unfortunately not usable from OpenGL, and no cap bit.
Pretty similar to a 1d texture, though allows specifying a start element.
The util code for handling clears also needs adjustments (and fix
a bug causing crashes for handling pure integer formats there too).
---
src/gallium/auxiliary/util/u_surface.c | 55
+++
src/gallium/drivers/llvmpipe/lp_rast.c | 25 ++--
src/gallium/drivers/llvmpipe/lp_rast_priv.h |4 +-
src/gallium/drivers/llvmpipe/lp_scene.c | 35 +++--
src/gallium/drivers/llvmpipe/lp_texture.c | 44 +++--
5 files changed, 108 insertions(+), 55 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_surface.c
b/src/gallium/auxiliary/util/u_surface.c
index b948b46..fba0798 100644
--- a/src/gallium/auxiliary/util/u_surface.c
+++ b/src/gallium/auxiliary/util/u_surface.c
@@ -323,20 +323,59 @@ util_clear_render_target(struct pipe_context *pipe,
if (!dst-texture)
return;
/* XXX: should handle multiple layers */
- dst_map = pipe_transfer_map(pipe,
- dst-texture,
- dst-u.tex.level,
- dst-u.tex.first_layer,
- PIPE_TRANSFER_WRITE,
- dstx, dsty, width, height, dst_trans);
+
+ if (dst-texture-target == PIPE_BUFFER) {
+ /*
+ * The fill naturally works on the surface format, however
+ * the transfer uses resource format which is just bytes for buffers.
+ */
+ unsigned dx, w;
+ unsigned pixstride = util_format_get_blocksize(dst-format);
+ dx = dstx * pixstride;
+ w = width * pixstride;
+ dst_map = pipe_transfer_map(pipe,
+ dst-texture,
+ 0, 0,
+ PIPE_TRANSFER_WRITE,
+ dx, 0, w, 1,
+ dst_trans);
+ dst_map = (uint8_t *)dst_map + dst-u.buf.first_element * pixstride;
+ }
+ else {
+ /* XXX: should handle multiple layers */
+ dst_map = pipe_transfer_map(pipe,
+ dst-texture,
+ dst-u.tex.level,
+ dst-u.tex.first_layer,
+ PIPE_TRANSFER_WRITE,
+ dstx, dsty, width, height, dst_trans);
+
+ }
assert(dst_map);
if (dst_map) {
+ enum pipe_format format = dst-format;
assert(dst_trans-stride 0);
- util_pack_color(color-f, dst-texture-format, uc);
- util_fill_rect(dst_map, dst-texture-format,
+ if (util_format_is_pure_integer(format)) {
+ /*
+ * We expect int/uint clear values here, though some APIs
+ * might disagree (but in any case util_pack_color()
+ * couldn't handle it)...
+ */
+ if (util_format_is_pure_sint(format)) {
+util_format_write_4i(format, color-i, 0, uc, 0, 0, 0, 1, 1);
+ }
+ else {
+assert(util_format_is_pure_uint(format));
+util_format_write_4ui(format, color-ui, 0, uc, 0, 0, 0, 1, 1);
+ }
+ }
+ else {
+ util_pack_color(color-f, dst-format, uc);
+ }
+ util_fill_rect(dst_map, dst-format,
dst_trans-stride,
0, 0, width, height, uc);
diff --git a/src/gallium/drivers/llvmpipe/lp_rast.c
b/src/gallium/drivers/llvmpipe/lp_rast.c
index b5e5da6..6183f41 100644
--- a/src/gallium/drivers/llvmpipe/lp_rast.c
+++ b/src/gallium/drivers/llvmpipe/lp_rast.c
@@ -165,32 +165,13 @@ lp_rast_clear_color(struct lp_rasterizer_task *task,
for (i = 0; i scene-fb.nr_cbufs; i++) {
enum pipe_format format = scene-fb.cbufs[i]-format;
-/*
- * XXX the format_write_4i/ui functions do clamping to max value
- * and I'm not sure that's actually right - spec doesn't seem to
- * say much about that topic. If it is should probably adjust
the
- * border color handling to do the same. If not and chopping off
- * bits is the way to go, the write_4i and write_4ui functions
- * would be identical.
- */
-if (util_format_is_pure_sint(format)) {
- int rgba[4];
- rgba[0] = arg.clear_color.i[0];
- rgba[1] =
Re: [Mesa-dev] [PATCH] llvmpipe: support rendering to buffer render targets.
Am 27.02.2013 14:11, schrieb Jose Fonseca:
Looks good.
I think the u_surface change could go in separately though.
Ok.
BTW, now that we can render/sampler from buffers,
llvmpipe_is_resource_referenced needs to be updated: buffer may be referenced
if they have BIND_SAMPLER/RENDERTARGET.
You are right. I actually looked at that llvmpipe_flush_resource
function and the rest seemed ok but didn't notice that
llvmpipe_is_resource_referenced wouldn't do anything for buffers.
I'll fix that.
Weshould do something like if !BIND_SAMPLER/RENDERTARGET, return UNREFERENCED.
Jose
- Original Message -
From: Roland Scheidegger srol...@vmware.com
Unfortunately not usable from OpenGL, and no cap bit.
Pretty similar to a 1d texture, though allows specifying a start element.
The util code for handling clears also needs adjustments (and fix
a bug causing crashes for handling pure integer formats there too).
---
src/gallium/auxiliary/util/u_surface.c | 55
+++
src/gallium/drivers/llvmpipe/lp_rast.c | 25 ++--
src/gallium/drivers/llvmpipe/lp_rast_priv.h |4 +-
src/gallium/drivers/llvmpipe/lp_scene.c | 35 +++--
src/gallium/drivers/llvmpipe/lp_texture.c | 44 +++--
5 files changed, 108 insertions(+), 55 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_surface.c
b/src/gallium/auxiliary/util/u_surface.c
index b948b46..fba0798 100644
--- a/src/gallium/auxiliary/util/u_surface.c
+++ b/src/gallium/auxiliary/util/u_surface.c
@@ -323,20 +323,59 @@ util_clear_render_target(struct pipe_context *pipe,
if (!dst-texture)
return;
/* XXX: should handle multiple layers */
- dst_map = pipe_transfer_map(pipe,
- dst-texture,
- dst-u.tex.level,
- dst-u.tex.first_layer,
- PIPE_TRANSFER_WRITE,
- dstx, dsty, width, height, dst_trans);
+
+ if (dst-texture-target == PIPE_BUFFER) {
+ /*
+ * The fill naturally works on the surface format, however
+ * the transfer uses resource format which is just bytes for buffers.
+ */
+ unsigned dx, w;
+ unsigned pixstride = util_format_get_blocksize(dst-format);
+ dx = dstx * pixstride;
+ w = width * pixstride;
+ dst_map = pipe_transfer_map(pipe,
+ dst-texture,
+ 0, 0,
+ PIPE_TRANSFER_WRITE,
+ dx, 0, w, 1,
+ dst_trans);
+ dst_map = (uint8_t *)dst_map + dst-u.buf.first_element * pixstride;
+ }
+ else {
+ /* XXX: should handle multiple layers */
+ dst_map = pipe_transfer_map(pipe,
+ dst-texture,
+ dst-u.tex.level,
+ dst-u.tex.first_layer,
+ PIPE_TRANSFER_WRITE,
+ dstx, dsty, width, height, dst_trans);
+
+ }
assert(dst_map);
if (dst_map) {
+ enum pipe_format format = dst-format;
assert(dst_trans-stride 0);
- util_pack_color(color-f, dst-texture-format, uc);
- util_fill_rect(dst_map, dst-texture-format,
+ if (util_format_is_pure_integer(format)) {
+ /*
+ * We expect int/uint clear values here, though some APIs
+ * might disagree (but in any case util_pack_color()
+ * couldn't handle it)...
+ */
+ if (util_format_is_pure_sint(format)) {
+util_format_write_4i(format, color-i, 0, uc, 0, 0, 0, 1, 1);
+ }
+ else {
+assert(util_format_is_pure_uint(format));
+util_format_write_4ui(format, color-ui, 0, uc, 0, 0, 0, 1, 1);
+ }
+ }
+ else {
+ util_pack_color(color-f, dst-format, uc);
+ }
+ util_fill_rect(dst_map, dst-format,
dst_trans-stride,
0, 0, width, height, uc);
diff --git a/src/gallium/drivers/llvmpipe/lp_rast.c
b/src/gallium/drivers/llvmpipe/lp_rast.c
index b5e5da6..6183f41 100644
--- a/src/gallium/drivers/llvmpipe/lp_rast.c
+++ b/src/gallium/drivers/llvmpipe/lp_rast.c
@@ -165,32 +165,13 @@ lp_rast_clear_color(struct lp_rasterizer_task *task,
for (i = 0; i scene-fb.nr_cbufs; i++) {
enum pipe_format format = scene-fb.cbufs[i]-format;
-/*
- * XXX the format_write_4i/ui functions do clamping to max value
- * and I'm not sure that's actually right - spec doesn't seem to
- * say much about that topic. If it is should probably adjust
the
- * border color handling to do the same. If not and chopping off
- * bits is the way to
[Mesa-dev] [Bug 61364] LLVM assertion when starting X11
https://bugs.freedesktop.org/show_bug.cgi?id=61364 a.ra...@arcor.de changed: What|Removed |Added CC||a.ra...@arcor.de -- 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] glx: Verify that drawable creation on the client side actually worked
On 04/05/2011 22:50, Adam Jackson wrote:
... and clean up if it didn't.
Signed-off-by: Adam Jackson a...@redhat.com
---
src/glx/glx_pbuffer.c | 76
-
src/glx/glxcmds.c | 74 +++-
2 files changed, 98 insertions(+), 52 deletions(-)
diff --git a/src/glx/glx_pbuffer.c b/src/glx/glx_pbuffer.c
index 5f91bc6..1d9c1e9 100644
--- a/src/glx/glx_pbuffer.c
+++ b/src/glx/glx_pbuffer.c
#else
-static void
+static GLboolean
CreateDRIDrawable(Display *dpy, const struct glx_config * fbconfig,
XID drawable, XID glxdrawable,
const int *attrib_list, size_t num_attribs)
{
+return GL_FALSE;
}
Always returning GL_FALSE (failed) here when built without
GLX_DIRECT_RENDERING defined ...
/**
* Create a non-pbuffer GLX drawable.
*
@@ -378,6 +402,7 @@ CreateDrawable(Display *dpy, struct glx_config *config,
Drawable drawable, const int *attrib_list, CARD8 glxCode)
{
xGLXCreateWindowReq *req;
+ GLXDrawable ret;
CARD32 *data;
unsigned int i;
CARD8 opcode;
@@ -401,7 +426,7 @@ CreateDrawable(Display *dpy, struct glx_config *config,
req-screen = config-screen;
req-fbconfig = config-fbconfigID;
req-window = drawable;
- req-glxwindow = XAllocID(dpy);
+ req-glxwindow = ret = XAllocID(dpy);
req-numAttribs = i;
if (attrib_list)
@@ -410,9 +435,16 @@ CreateDrawable(Display *dpy, struct glx_config *config,
UnlockDisplay(dpy);
SyncHandle();
- CreateDRIDrawable(dpy, config, drawable, req-glxwindow, attrib_list, i);
+ if (!CreateDRIDrawable(dpy, config, drawable, ret, attrib_list, i)) {
+ if (glxCode == X_GLXCreatePixmap)
+ glxCode = X_GLXDestroyPixmap;
+ else
+ glxCode = X_GLXDestroyWindow;
+ protocolDestroyDrawable(dpy, ret, glxCode);
+ ret = None;
+ }
... and then always checking the result here, looks like this makes
CreateDrawable (and hence glXCreateWindow() and glXCreatePbuffer()) always
fail (when built without GLX_DIRECT_RENDERING defined)
- return req-glxwindow;
+ return ret;
}
@@ -474,6 +490,7 @@ CreatePbuffer(Display * dpy, struct glx_config *config,
CARD8 opcode;
unsigned int i;
Pixmap pixmap;
+ GLboolean glx_1_3 = GL_FALSE;
i = 0;
if (attrib_list) {
@@ -492,6 +509,8 @@ CreatePbuffer(Display * dpy, struct glx_config *config,
xGLXCreatePbufferReq *req;
unsigned int extra = (size_in_attribs) ? 0 : 2;
+ glx_1_3 = GL_TRUE;
+
GetReqExtra(GLXCreatePbuffer, (8 * (i + extra)), req);
data = (CARD32 *) (req + 1);
@@ -536,7 +555,12 @@ CreatePbuffer(Display * dpy, struct glx_config *config,
pixmap = XCreatePixmap(dpy, RootWindow(dpy, config-screen),
width, height, config-rgbBits);
- CreateDRIDrawable(dpy, config, pixmap, id, attrib_list, i);
+ if (!CreateDRIDrawable(dpy, config, pixmap, id, attrib_list, i)) {
+ CARD32 o = glx_1_3 ? X_GLXDestroyPbuffer :
X_GLXvop_DestroyGLXPbufferSGIX;
+ XFreePixmap(dpy, pixmap);
+ protocolDestroyDrawable(dpy, id, o);
+ id = None;
+ }
Ditto.
return id;
}
Attached is a patch to fix.
From f210b48ed7ae8d0286676ed94c38c5a6ca4338b4 Mon Sep 17 00:00:00 2001
From: Jon TURNEY jon.tur...@dronecode.org.uk
Date: Tue, 26 Feb 2013 15:47:44 +
Subject: [PATCH] glXCreateWindow() always fails when built without
GLX_DIRECT_RENDERING defined
glXCreateWindow() and glXCreatePbuffer() always fail when built without
GLX_DIRECT_RENDERING defined since commit
4833104718677caad0027d5e7539ca9bba389392
Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
---
src/glx/glx_pbuffer.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/glx/glx_pbuffer.c b/src/glx/glx_pbuffer.c
index e4b2c86..f11305a 100644
--- a/src/glx/glx_pbuffer.c
+++ b/src/glx/glx_pbuffer.c
@@ -241,7 +241,7 @@ CreateDRIDrawable(Display *dpy, const struct glx_config *
fbconfig,
XID drawable, XID glxdrawable,
const int *attrib_list, size_t num_attribs)
{
-return GL_FALSE;
+return GL_TRUE;
}
static void
--
1.7.9
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/3] Fixes for glapi/test/check_table test
Now that the make target is supported, I've turned on 'make check' for mesa in my tinderbox, but it fails [1] The logic behind patch [3/3] is sufficently convoluted that I'm not sure I've got it right. However, I'm pretty sure that the code is wrong as it stands, as it's checking for a #define which is never made. [1] http://tinderbox.freedesktop.org/builds/2013-02-27-0010/logs/libGL/#check Jon TURNEY (3): Fix out-of-tree build of 'make check' in src/mapi/glapi/tests/ Fix glapi/tests/check_table.cpp for standardized OpenGL function names Properly check GLX_INDIRECT_RENDERING in glapi/tests/check_table src/mapi/glapi/tests/Makefile.am |7 +- src/mapi/glapi/tests/check_table.cpp | 530 +- 2 files changed, 269 insertions(+), 268 deletions(-) -- 1.7.9 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] Fix out-of-tree build of 'make check' in src/mapi/glapi/tests/
Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk --- src/mapi/glapi/tests/Makefile.am |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/mapi/glapi/tests/Makefile.am b/src/mapi/glapi/tests/Makefile.am index a23eef2..3553b99 100644 --- a/src/mapi/glapi/tests/Makefile.am +++ b/src/mapi/glapi/tests/Makefile.am @@ -1,9 +1,9 @@ if !HAVE_SHARED_GLAPI AM_CFLAGS = $(PTHREAD_CFLAGS) AM_CPPFLAGS = \ - -I$(top_builddir)/src/gtest/include \ - -I$(top_builddir)/src/mapi \ - -I$(top_builddir)/include + -I$(top_srcdir)/src/gtest/include \ + -I$(top_srcdir)/src/mapi \ + -I$(top_srcdir)/include TESTS = glapi-test check_PROGRAMS = glapi-test -- 1.7.9 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] Fix glapi/tests/check_table.cpp for standardized OpenGL function names
It looks like this has been broken since commit
1a1db1746db82efc7f0643508886dfc78a15eb71 Standardize names of OpenGL
functions.
Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
---
src/mapi/glapi/tests/check_table.cpp | 528 +-
1 files changed, 264 insertions(+), 264 deletions(-)
diff --git a/src/mapi/glapi/tests/check_table.cpp
b/src/mapi/glapi/tests/check_table.cpp
index 807d3c3..dffec83 100644
--- a/src/mapi/glapi/tests/check_table.cpp
+++ b/src/mapi/glapi/tests/check_table.cpp
@@ -523,40 +523,40 @@ const struct name_offset linux_gl_abi[] = {
{ glTexImage3D, 371 },
{ glTexSubImage3D, 372 },
{ glCopyTexSubImage3D, 373 },
- { glActiveTextureARB, 374 },
- { glClientActiveTextureARB, 375 },
- { glMultiTexCoord1dARB, 376 },
- { glMultiTexCoord1dvARB, 377 },
+ { glActiveTexture, 374 },
+ { glClientActiveTexture, 375 },
+ { glMultiTexCoord1d, 376 },
+ { glMultiTexCoord1dv, 377 },
{ glMultiTexCoord1fARB, 378 },
{ glMultiTexCoord1fvARB, 379 },
- { glMultiTexCoord1iARB, 380 },
- { glMultiTexCoord1ivARB, 381 },
- { glMultiTexCoord1sARB, 382 },
- { glMultiTexCoord1svARB, 383 },
- { glMultiTexCoord2dARB, 384 },
- { glMultiTexCoord2dvARB, 385 },
+ { glMultiTexCoord1i, 380 },
+ { glMultiTexCoord1iv, 381 },
+ { glMultiTexCoord1s, 382 },
+ { glMultiTexCoord1sv, 383 },
+ { glMultiTexCoord2d, 384 },
+ { glMultiTexCoord2dv, 385 },
{ glMultiTexCoord2fARB, 386 },
{ glMultiTexCoord2fvARB, 387 },
- { glMultiTexCoord2iARB, 388 },
- { glMultiTexCoord2ivARB, 389 },
- { glMultiTexCoord2sARB, 390 },
- { glMultiTexCoord2svARB, 391 },
- { glMultiTexCoord3dARB, 392 },
- { glMultiTexCoord3dvARB, 393 },
+ { glMultiTexCoord2i, 388 },
+ { glMultiTexCoord2iv, 389 },
+ { glMultiTexCoord2s, 390 },
+ { glMultiTexCoord2sv, 391 },
+ { glMultiTexCoord3d, 392 },
+ { glMultiTexCoord3dv, 393 },
{ glMultiTexCoord3fARB, 394 },
{ glMultiTexCoord3fvARB, 395 },
- { glMultiTexCoord3iARB, 396 },
- { glMultiTexCoord3ivARB, 397 },
- { glMultiTexCoord3sARB, 398 },
- { glMultiTexCoord3svARB, 399 },
- { glMultiTexCoord4dARB, 400 },
- { glMultiTexCoord4dvARB, 401 },
+ { glMultiTexCoord3i, 396 },
+ { glMultiTexCoord3iv, 397 },
+ { glMultiTexCoord3s, 398 },
+ { glMultiTexCoord3sv, 399 },
+ { glMultiTexCoord4d, 400 },
+ { glMultiTexCoord4dv, 401 },
{ glMultiTexCoord4fARB, 402 },
{ glMultiTexCoord4fvARB, 403 },
- { glMultiTexCoord4iARB, 404 },
- { glMultiTexCoord4ivARB, 405 },
- { glMultiTexCoord4sARB, 406 },
- { glMultiTexCoord4svARB, 407 },
+ { glMultiTexCoord4i, 404 },
+ { glMultiTexCoord4iv, 405 },
+ { glMultiTexCoord4s, 406 },
+ { glMultiTexCoord4sv, 407 },
{ NULL, 0 }
};
@@ -937,40 +937,40 @@ const struct name_offset known_dispatch[] = {
{ glTexImage3D, _O(TexImage3D) },
{ glTexSubImage3D, _O(TexSubImage3D) },
{ glCopyTexSubImage3D, _O(CopyTexSubImage3D) },
- { glActiveTextureARB, _O(ActiveTextureARB) },
- { glClientActiveTextureARB, _O(ClientActiveTextureARB) },
- { glMultiTexCoord1dARB, _O(MultiTexCoord1dARB) },
- { glMultiTexCoord1dvARB, _O(MultiTexCoord1dvARB) },
+ { glActiveTexture, _O(ActiveTexture) },
+ { glClientActiveTexture, _O(ClientActiveTexture) },
+ { glMultiTexCoord1d, _O(MultiTexCoord1d) },
+ { glMultiTexCoord1dv, _O(MultiTexCoord1dv) },
{ glMultiTexCoord1fARB, _O(MultiTexCoord1fARB) },
{ glMultiTexCoord1fvARB, _O(MultiTexCoord1fvARB) },
- { glMultiTexCoord1iARB, _O(MultiTexCoord1iARB) },
- { glMultiTexCoord1ivARB, _O(MultiTexCoord1ivARB) },
- { glMultiTexCoord1sARB, _O(MultiTexCoord1sARB) },
- { glMultiTexCoord1svARB, _O(MultiTexCoord1svARB) },
- { glMultiTexCoord2dARB, _O(MultiTexCoord2dARB) },
- { glMultiTexCoord2dvARB, _O(MultiTexCoord2dvARB) },
+ { glMultiTexCoord1i, _O(MultiTexCoord1i) },
+ { glMultiTexCoord1iv, _O(MultiTexCoord1iv) },
+ { glMultiTexCoord1s, _O(MultiTexCoord1s) },
+ { glMultiTexCoord1sv, _O(MultiTexCoord1sv) },
+ { glMultiTexCoord2d, _O(MultiTexCoord2d) },
+ { glMultiTexCoord2dv, _O(MultiTexCoord2dv) },
{ glMultiTexCoord2fARB, _O(MultiTexCoord2fARB) },
{ glMultiTexCoord2fvARB, _O(MultiTexCoord2fvARB) },
- { glMultiTexCoord2iARB, _O(MultiTexCoord2iARB) },
- { glMultiTexCoord2ivARB, _O(MultiTexCoord2ivARB) },
- { glMultiTexCoord2sARB, _O(MultiTexCoord2sARB) },
- { glMultiTexCoord2svARB, _O(MultiTexCoord2svARB) },
- { glMultiTexCoord3dARB, _O(MultiTexCoord3dARB) },
- { glMultiTexCoord3dvARB, _O(MultiTexCoord3dvARB) },
+ { glMultiTexCoord2i, _O(MultiTexCoord2i) },
+ { glMultiTexCoord2iv, _O(MultiTexCoord2iv) },
+ { glMultiTexCoord2s, _O(MultiTexCoord2s) },
+ { glMultiTexCoord2sv, _O(MultiTexCoord2sv) },
+ { glMultiTexCoord3d, _O(MultiTexCoord3d) },
+ { glMultiTexCoord3dv, _O(MultiTexCoord3dv) },
{ glMultiTexCoord3fARB, _O(MultiTexCoord3fARB) },
{ glMultiTexCoord3fvARB, _O(MultiTexCoord3fvARB) },
- { glMultiTexCoord3iARB,
[Mesa-dev] [PATCH 3/3] Properly check GLX_INDIRECT_RENDERING in glapi/tests/check_table
Actually use $DEFINES, so we can see if GLX_INDIRECT_RENDERING is defined
If GLX_INDIRECT_RENDERING is defined, _GLAPI_SKIP_PROTO_ENTRY_POINTS will
be defined, and libglapi won't contain the 'protocol entry points', so we
should provide stubs in check_table.cpp
Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
---
src/mapi/glapi/tests/Makefile.am |1 +
src/mapi/glapi/tests/check_table.cpp |2 +-
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/mapi/glapi/tests/Makefile.am b/src/mapi/glapi/tests/Makefile.am
index 3553b99..f375e9b 100644
--- a/src/mapi/glapi/tests/Makefile.am
+++ b/src/mapi/glapi/tests/Makefile.am
@@ -1,6 +1,7 @@
if !HAVE_SHARED_GLAPI
AM_CFLAGS = $(PTHREAD_CFLAGS)
AM_CPPFLAGS = \
+$(DEFINES) \
-I$(top_srcdir)/src/gtest/include \
-I$(top_srcdir)/src/mapi \
-I$(top_srcdir)/include
diff --git a/src/mapi/glapi/tests/check_table.cpp
b/src/mapi/glapi/tests/check_table.cpp
index dffec83..375645b 100644
--- a/src/mapi/glapi/tests/check_table.cpp
+++ b/src/mapi/glapi/tests/check_table.cpp
@@ -1511,7 +1511,7 @@ const struct name_offset known_dispatch[] = {
{ NULL, 0 }
};
-#ifndef GLX_INDIRECT_RENDERING
+#ifdef GLX_INDIRECT_RENDERING
extern C {
GLAPI GLboolean GLAPIENTRY
glAreTexturesResidentEXT(GLsizei n, const GLuint *textures,
--
1.7.9
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] texobj: add verbose api trace messages to several routines
Jose Fonseca jfons...@vmware.com writes: - Original Message - Jordan Justen jordan.l.jus...@intel.com writes: Motivated by wanting to see if GenTextures was called by an application while debugging another Steam overlay issue. Making a systematic MESA_DEBUG=api using dispatch tables and code generation seems like it would be nice instead of adding it ad-hoc. Not something against this patch, just maybe a project for a janitor list if we have one. apitrace seems like it would be to replace it, but I've seen enough apps where it doesn't work (and in this case with the steam overlay it definitely doesn't) that we can't just rely on that. Could you elaborate on that? I'd like to understand how apitrace would miss intercepting calls. A apart of some bug, the only explanation I can think of is calls done inside Callists. If so then the only way to zoom in would be for Apitrace to actually implement callists itself, and then inline them. But this would have several side effects, and be too onerous for a legacy feature. Because apitrace isn't the only LD_PRELOAD libGL that people have done, and I think to get them to chain one has to know the other (and you probably want apitrace to be the last one before the GL). pgpDomxK2hXE5.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] texobj: add verbose api trace messages to several routines
- Original Message - On Wed, Feb 27, 2013 at 1:21 AM, Jose Fonseca jfons...@vmware.com wrote: - Original Message - Jordan Justen jordan.l.jus...@intel.com writes: Motivated by wanting to see if GenTextures was called by an application while debugging another Steam overlay issue. Making a systematic MESA_DEBUG=api using dispatch tables and code generation seems like it would be nice instead of adding it ad-hoc. Not something against this patch, just maybe a project for a janitor list if we have one. apitrace seems like it would be to replace it, but I've seen enough apps where it doesn't work (and in this case with the steam overlay it definitely doesn't) that we can't just rely on that. Could you elaborate on that? I'd like to understand how apitrace would miss intercepting calls. The Steam overlay uses LD_PRELOAD and there doesn't seem to be a way to both use the overlay and capture a trace. I see. But one can use apitrace through LD_LIBRARY_PATH instead of LD_PRELOAD. Steam is not the first app to have issues with LD_PRELOAD. Currently there's no easy way to trace like through LD_LIBRARY_PATH -- one needs to follow the manual instructions in https://github.com/apitrace/apitrace/blob/master/README.markdown#linux but it this does indeed help, then we could add logic to the apitrace trace CLI command to setup LD_LIBRARY_PATH. LD_PRELOAD tends to be more convenient but LD_LIBRARY_PATH should be indistinguishable for applications. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glx: Verify that drawable creation on the client side actually worked
On Wed, 2013-02-27 at 14:02 +, Jon TURNEY wrote: Attached is a patch to fix. Pushed, thanks. - ajax ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] llvmpipe: check buffers in llvmpipe_is_resource_referenced
From: Roland Scheidegger srol...@vmware.com
Now that buffers can be used as textures or render targets
make sure they aren't skipped.
Fix suggested by Jose Fonseca.
---
src/gallium/drivers/llvmpipe/lp_surface.c | 14 +++---
src/gallium/drivers/llvmpipe/lp_texture.c |4 +++-
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_surface.c
b/src/gallium/drivers/llvmpipe/lp_surface.c
index a83a903..5e6a6eb 100644
--- a/src/gallium/drivers/llvmpipe/lp_surface.c
+++ b/src/gallium/drivers/llvmpipe/lp_surface.c
@@ -65,13 +65,6 @@ lp_resource_copy(struct pipe_context *pipe,
unsigned depth = src_box-depth;
unsigned z;
- /* Fallback for buffers. */
- if (dst-target == PIPE_BUFFER src-target == PIPE_BUFFER) {
- util_resource_copy_region(pipe, dst, dst_level, dstx, dsty, dstz,
-src, src_level, src_box);
- return;
- }
-
llvmpipe_flush_resource(pipe,
dst, dst_level,
FALSE, /* read_only */
@@ -86,6 +79,13 @@ lp_resource_copy(struct pipe_context *pipe,
FALSE, /* do_not_block */
blit src);
+ /* Fallback for buffers. */
+ if (dst-target == PIPE_BUFFER src-target == PIPE_BUFFER) {
+ util_resource_copy_region(pipe, dst, dst_level, dstx, dsty, dstz,
+src, src_level, src_box);
+ return;
+ }
+
/*
printf(surface copy from %u lvl %u to %u lvl %u: %u,%u,%u to %u,%u,%u %u x
%u x %u\n,
src_tex-id, src_level, dst_tex-id, dst_level,
diff --git a/src/gallium/drivers/llvmpipe/lp_texture.c
b/src/gallium/drivers/llvmpipe/lp_texture.c
index a64139f..75104bb 100644
--- a/src/gallium/drivers/llvmpipe/lp_texture.c
+++ b/src/gallium/drivers/llvmpipe/lp_texture.c
@@ -755,7 +755,9 @@ llvmpipe_is_resource_referenced( struct pipe_context *pipe,
{
struct llvmpipe_context *llvmpipe = llvmpipe_context( pipe );
- if (presource-target == PIPE_BUFFER)
+ if (!(presource-bind (PIPE_BIND_DEPTH_STENCIL |
+PIPE_BIND_RENDER_TARGET |
+PIPE_BIND_SAMPLER_VIEW)))
return LP_UNREFERENCED;
return lp_setup_is_resource_referenced(llvmpipe-setup, presource);
--
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 2/4] i965: Add WARN_ONCE for depthstencil workarounds we shouldn't be hitting.
On 02/26/2013 11:15 PM, Eric Anholt wrote: --- src/mesa/drivers/dri/i965/gen6_blorp.cpp |3 +++ src/mesa/drivers/dri/i965/gen7_blorp.cpp |3 +++ 2 files changed, 6 insertions(+) diff --git a/src/mesa/drivers/dri/i965/gen6_blorp.cpp b/src/mesa/drivers/dri/i965/gen6_blorp.cpp index 3834ae2..2b6db82 100644 Patch 2 is Reviewed-by: Chad Versace chad.vers...@linux.intel.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] intel: Fix software copying of miptree faces for weird formats.
On 02/26/2013 11:15 PM, Eric Anholt wrote: Now that we have W-tiled S8, we can't just region_map and poke at bits -- there has to be some swizzling. Rely on intel_miptree_map to get that job done. This should also get the highest performance path we know of for the mapping (interesting if I get around to finishing movntdqa some day). Fixes around 32 piglit tests if brw_workaround_depthstencil_alignment() is tweaked to always do a rebase. --- src/mesa/drivers/dri/intel/intel_mipmap_tree.c | 95 +++- src/mesa/drivers/dri/intel/intel_regions.c | 33 src/mesa/drivers/dri/intel/intel_regions.h | 10 --- 3 files changed, 77 insertions(+), 61 deletions(-) diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c index 217f13d..29dfd20 100644 --- a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c +++ b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c @@ -703,6 +703,68 @@ intel_miptree_get_tile_offsets(struct intel_mipmap_tree *mt, + /* Don't forget to copy the stencil data over, too. We could have skipped +* passing BRW_MAP_NO_TRANSCODE_BIT, but that would have meant ^ The name needs an update. Other than that, patches 3 and 4 are Reviewed-by: Chad Versace chad.vers...@linux.intel.com @@ -752,25 +827,9 @@ intel_miptree_copy_slice(struct intel_context *intel, fallback_debug(miptree validate blit for %s failed\n, _mesa_get_format_name(format)); - void *dst = intel_region_map(intel, dst_mt-region, GL_MAP_WRITE_BIT); - void *src = intel_region_map(intel, src_mt-region, GL_MAP_READ_BIT); - - _mesa_copy_rect(dst, - dst_mt-cpp, - dst_mt-region-pitch, - dst_x, dst_y, - width, height, - src, src_mt-region-pitch, - src_x, src_y); - - intel_region_unmap(intel, dst_mt-region); - intel_region_unmap(intel, src_mt-region); Ugh we really did this for S8 :( ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] i965: Fix fulsim assertion failures by aligning HiZ ops to 8x4.
Chad Versace chad.vers...@linux.intel.com writes: On 02/26/2013 11:15 PM, Eric Anholt wrote: I have some debug of HiZ rendering that looks like some rendering is not landing in my HiZ buffer. Unfortunately, fulsim choking on us violating hiz rendering rules was preventing me from using it as a debug aid. Once we get things reliable, we'll also be able to take advantage of this to get fast clears on modes like 1366x768. --- src/mesa/drivers/dri/i965/brw_blorp.cpp | 10 ++ 1 file changed, 10 insertions(+) diff --git a/src/mesa/drivers/dri/i965/brw_blorp.cpp b/src/mesa/drivers/dri/i965/brw_blorp.cpp index 5f72b5d..49dcacb 100644 --- a/src/mesa/drivers/dri/i965/brw_blorp.cpp +++ b/src/mesa/drivers/dri/i965/brw_blorp.cpp @@ -181,6 +181,16 @@ brw_hiz_op_params::brw_hiz_op_params(struct intel_mipmap_tree *mt, this-hiz_op = op; depth.set(mt, level, layer); + + /* HiZ operations require alignment to 8x4. Our depth and hiz miplevels +* should have their start offsets aligned to that (except for a bug on +* non-Z16) so we won't draw into a neighboring miplevel, and we allocate +* memory aligned to pages (128bytesx32), so we won't draw into memory not +* owned by our miptree. +*/ + depth.width = ALIGN(depth.width, 8); + depth.height = ALIGN(depth.height, 4); + This should be moved into the brw_hiz_op_params() constructor. That's where this is. Were you thinking of a version that was posted in my tree at one point instead? pgpsbFHoSP2IX.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [MESA][PATCH] tgsi: fix mis-matching AOS instruction emission
Catched this that morning From e50374e62254e7532c695bebb3e608242638bb73 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Maxence=20Le=20Dor=C3=A9?= maxence.led...@gmail.com Date: Wed, 27 Feb 2013 10:24:10 +0100 Subject: [PATCH] tgsi: fix mis-matching instruction emission --- src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c index dbd9ccb..9a30cc8 100644 --- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c +++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c @@ -536,7 +536,7 @@ lp_emit_instruction_aos( case TGSI_OPCODE_MIN: src0 = lp_build_emit_fetch(bld-bld_base, inst, 0, LP_CHAN_ALL); src1 = lp_build_emit_fetch(bld-bld_base, inst, 1, LP_CHAN_ALL); - dst0 = lp_build_max(bld-bld_base.base, src0, src1); + dst0 = lp_build_min(bld-bld_base.base, src0, src1); break; case TGSI_OPCODE_MAX: -- 1.7.9.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 61364] LLVM assertion when starting X11
https://bugs.freedesktop.org/show_bug.cgi?id=61364 marci...@gmail.com changed: What|Removed |Added CC||marci...@gmail.com -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [MESA][PATCH] tgsi: fix mis-matching AOS instruction emission
Good catch. Thanks! Jose - Original Message - Catched this that morning From e50374e62254e7532c695bebb3e608242638bb73 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Maxence=20Le=20Dor=C3=A9?= maxence.led...@gmail.com Date: Wed, 27 Feb 2013 10:24:10 +0100 Subject: [PATCH] tgsi: fix mis-matching instruction emission --- src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c index dbd9ccb..9a30cc8 100644 --- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c +++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c @@ -536,7 +536,7 @@ lp_emit_instruction_aos( case TGSI_OPCODE_MIN: src0 = lp_build_emit_fetch(bld-bld_base, inst, 0, LP_CHAN_ALL); src1 = lp_build_emit_fetch(bld-bld_base, inst, 1, LP_CHAN_ALL); - dst0 = lp_build_max(bld-bld_base.base, src0, src1); + dst0 = lp_build_min(bld-bld_base.base, src0, src1); break; case TGSI_OPCODE_MAX: -- 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 1/4] i965: Fix fulsim assertion failures by aligning HiZ ops to 8x4.
On 02/27/2013 11:39 AM, Eric Anholt wrote: Chad Versace chad.vers...@linux.intel.com writes: On 02/26/2013 11:15 PM, Eric Anholt wrote: I have some debug of HiZ rendering that looks like some rendering is not landing in my HiZ buffer. Unfortunately, fulsim choking on us violating hiz rendering rules was preventing me from using it as a debug aid. Once we get things reliable, we'll also be able to take advantage of this to get fast clears on modes like 1366x768. --- src/mesa/drivers/dri/i965/brw_blorp.cpp | 10 ++ 1 file changed, 10 insertions(+) diff --git a/src/mesa/drivers/dri/i965/brw_blorp.cpp b/src/mesa/drivers/dri/i965/brw_blorp.cpp index 5f72b5d..49dcacb 100644 --- a/src/mesa/drivers/dri/i965/brw_blorp.cpp +++ b/src/mesa/drivers/dri/i965/brw_blorp.cpp @@ -181,6 +181,16 @@ brw_hiz_op_params::brw_hiz_op_params(struct intel_mipmap_tree *mt, this-hiz_op = op; depth.set(mt, level, layer); + + /* HiZ operations require alignment to 8x4. Our depth and hiz miplevels +* should have their start offsets aligned to that (except for a bug on +* non-Z16) so we won't draw into a neighboring miplevel, and we allocate +* memory aligned to pages (128bytesx32), so we won't draw into memory not +* owned by our miptree. +*/ + depth.width = ALIGN(depth.width, 8); + depth.height = ALIGN(depth.height, 4); + This should be moved into the brw_hiz_op_params() constructor. That's where this is. Were you thinking of a version that was posted in my tree at one point instead? No, I was talking with my foot in my mouth. :/ I meant it should be set by call to depth.set() above, which is brw_blorp_mip_info::set(), like this: this-width = ALIGN(mt-level[level].width, 8); this-height = ALIGN(mt-level[level].height, 4); The responsibility of setting brw_blorp_mip_info fields should belong to that method. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 46376] render error when run glsl demo or mesa demo with X
https://bugs.freedesktop.org/show_bug.cgi?id=46376 --- Comment #5 from Kenneth Graunke kenn...@whitecape.org --- I don't understand how to reproduce this bug. What do you mean by only X? GNOME uses X. I've also verified that they work fine in KDE (also using X). Can you provide some instructions on how to reproduce it? (Like, are you creating an .xinitrc that just runs the demo, or...?) -- 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] (remove-mfeatures) mesa: generate glGet code for all APIs (v2)
From: Brian Paul bri...@vmware.com
No longer pass -a flag to get_hash_generate.py script to specify
OpenGL, ES1, ES2, etc.
v2[chadv]: Fix Android makefile too.
---
Brian, this patch in your series breaks the Android build. Here is
a fixed version of your patch. The only difference is the hunk in
file Android.gen.mk
src/mesa/Android.gen.mk | 3 +--
src/mesa/Makefile.am| 6 ++
src/mesa/main/get_hash_generator.py | 26 +++---
3 files changed, 6 insertions(+), 29 deletions(-)
diff --git a/src/mesa/Android.gen.mk b/src/mesa/Android.gen.mk
index 35f00da..c6280f5 100644
--- a/src/mesa/Android.gen.mk
+++ b/src/mesa/Android.gen.mk
@@ -111,8 +111,7 @@ $(intermediates)/main/api_exec.c: $(dispatch_deps)
$(call es-gen)
GET_HASH_GEN := $(LOCAL_PATH)/main/get_hash_generator.py
-GET_HASH_GEN_FLAGS := $(patsubst %,-a %,$(MESA_ENABLED_APIS))
$(intermediates)/main/get_hash.h: $(glapi)/gl_and_es_API.xml \
$(LOCAL_PATH)/main/get_hash_params.py $(GET_HASH_GEN)
- @$(MESA_PYTHON2) $(GET_HASH_GEN) $(GET_HASH_GEN_FLAGS) -f $ $@
+ @$(MESA_PYTHON2) $(GET_HASH_GEN) -f $ $@
diff --git a/src/mesa/Makefile.am b/src/mesa/Makefile.am
index 41483dd..84fc3eb 100644
--- a/src/mesa/Makefile.am
+++ b/src/mesa/Makefile.am
@@ -59,14 +59,12 @@ CLEANFILES = \
git_sha1.h.tmp
GET_HASH_GEN = main/get_hash_generator.py
-GET_HASH_GEN_FLAGS := $(patsubst -DFEATURE_%=1,-a %, \
- $(patsubst -DFEATURE_%=0,,$(API_DEFINES)))
main/get_hash.h: $(GLAPI)/gl_and_es_API.xml main/get_hash_params.py\
$(GET_HASH_GEN) Makefile
$(AM_V_GEN)set -e; \
- $(PYTHON2) $(PYTHON_FLAGS) $(srcdir)/$(GET_HASH_GEN)\
- $(GET_HASH_GEN_FLAGS) -f $ $@.tmp; \
+ $(PYTHON2) $(PYTHON_FLAGS) $(srcdir)/$(GET_HASH_GEN)\
+ -f $ $@.tmp; \
mv $@.tmp $@;
noinst_LTLIBRARIES =
diff --git a/src/mesa/main/get_hash_generator.py
b/src/mesa/main/get_hash_generator.py
index 04bf9ff..96bc495 100644
--- a/src/mesa/main/get_hash_generator.py
+++ b/src/mesa/main/get_hash_generator.py
@@ -179,54 +179,34 @@ def generate_hash_tables(enum_list, enabled_apis,
param_descriptors):
return params, merge_tables(sorted_tables)
-def opt_to_apis(feature):
- _map = {ES1: GLES, ES2: GLES2, GL: GL}
- if feature not in _map:
- return None
-
- apis = set([_map[feature]])
- if GL in apis:
- apis.add(GL_CORE)
- if GLES2 in apis:
- apis.add(GLES3)
-
- return apis
def show_usage():
sys.stderr.write(
Usage: %s [OPTIONS]
-f file specify GL API XML file
- -a [GL|ES1|ES2]specify APIs to generate hash tables for
% (program))
exit(1)
if __name__ == '__main__':
try:
- (opts, args) = getopt.getopt(sys.argv[1:], f:a:)
+ (opts, args) = getopt.getopt(sys.argv[1:], f:)
except Exception,e:
show_usage()
if len(args) != 0:
show_usage()
- enabled_apis = set([])
api_desc_file =
for opt_name, opt_val in opts:
if opt_name == -f:
api_desc_file = opt_val
- if opt_name == -a:
- apis = opt_to_apis(opt_val.upper())
- if not apis:
-die(invalid API %s\n % opt_val)
-
- enabled_apis |= apis
if not api_desc_file:
die(missing descriptor file (-f)\n)
- if len(enabled_apis) == 0:
- die(need at least a single enabled API\n)
+ # generate the code for all APIs
+ enabled_apis = set([GLES, GLES2, GLES3, GL, GL_CORE])
try:
api_desc = gl_XML.parse_GL_API(api_desc_file)
--
1.8.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] intel: Remove intel_mipmap_tree::wraps_etc
The field was equivalent to (etc_format != MESA_FORMAT_NONE), and
therefore duplicate information.
This patch removes field and replaces all references to it with
`etc_format != MESA_FORMAT_NONE`.
No Piglit ETC test regresses on Intel Sandybridge.
Signed-off-by: Chad Versace chad.vers...@linux.intel.com
---
src/mesa/drivers/dri/intel/intel_mipmap_tree.c | 10 +++---
src/mesa/drivers/dri/intel/intel_mipmap_tree.h | 14 --
2 files changed, 3 insertions(+), 21 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
index 306cbbe..e150501 100644
--- a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
@@ -390,7 +390,6 @@ intel_miptree_create(struct intel_context *intel,
total_height = ALIGN(total_height, 64);
}
- mt-wraps_etc = (etc_format != MESA_FORMAT_NONE) ? true : false;
mt-etc_format = etc_format;
mt-region = intel_region_alloc(intel-intelScreen,
tiling,
@@ -1309,10 +1308,7 @@ intel_miptree_map_etc(struct intel_context *intel,
unsigned int level,
unsigned int slice)
{
- /* For justification see intel_mipmap_tree:wraps_etc.
-*/
- assert(mt-wraps_etc);
-
+ assert(mt-etc_format != MESA_FORMAT_NONE);
if (mt-etc_format == MESA_FORMAT_ETC1_RGB8) {
assert(mt-format == MESA_FORMAT_RGBX_REV);
}
@@ -1575,7 +1571,7 @@ intel_miptree_map_singlesample(struct intel_context
*intel,
if (mt-format == MESA_FORMAT_S8) {
intel_miptree_map_s8(intel, mt, map, level, slice);
- } else if (mt-wraps_etc) {
+ } else if (mt-etc_format != MESA_FORMAT_NONE) {
intel_miptree_map_etc(intel, mt, map, level, slice);
} else if (mt-stencil_mt) {
intel_miptree_map_depthstencil(intel, mt, map, level, slice);
@@ -1633,7 +1629,7 @@ intel_miptree_unmap_singlesample(struct intel_context
*intel,
if (mt-format == MESA_FORMAT_S8) {
intel_miptree_unmap_s8(intel, mt, map, level, slice);
- } else if (mt-wraps_etc) {
+ } else if (mt-etc_format != MESA_FORMAT_NONE) {
intel_miptree_unmap_etc(intel, mt, map, level, slice);
} else if (mt-stencil_mt) {
intel_miptree_unmap_depthstencil(intel, mt, map, level, slice);
diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.h
b/src/mesa/drivers/dri/intel/intel_mipmap_tree.h
index 27540bc..2070be7 100644
--- a/src/mesa/drivers/dri/intel/intel_mipmap_tree.h
+++ b/src/mesa/drivers/dri/intel/intel_mipmap_tree.h
@@ -360,20 +360,6 @@ struct intel_mipmap_tree
*/
struct intel_mipmap_tree *mcs_mt;
- /**
-* \brief The miptree contains uncompressed data that was originally
-* ETC1/ETC2 data.
-*
-* On hardware that lacks support for ETC1/ETC2 textures, we do the
following
-* on calls to glCompressedTexImage2D() with an ETC1/ETC2 texture format:
-* 1. Create a miptree whose format is a suitable uncompressed mesa format
-* with the wraps_etc flag set.
-* 2. Translate the ETC1/ETC2 data into uncompressed mesa format.
-* 3. Store the uncompressed data into the miptree and discard the
ETC1/ETC2
-* data.
-*/
- bool wraps_etc;
-
/* These are also refcounted:
*/
GLuint refcount;
--
1.8.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] r600g: status of my work on the shader optimization
Could you please test glxgears and other simple mesa demos? It's easier to spot the problems with small apps that don't use a lot of complex shaders. If some of them don't work correctly, please send me the dumps with R600_DUMP_SHADERS=2 R600_SB_DUMP=3. All of the mesa demos work with and without llvm. Same here running on RV790 (HD 4890) Also it might help if you can look for piglit regressions against the piglit results with R600_SB=0 and send me the dumps for a few regressed tests. OK, I already got the dumps with piglit regressions on r700, the dump with nexuiz may also help. Thanks. Do you still need some piglit test on rv790 hardware? I've also tried running Serious Sam 3 with the standard, llvm and your optimized backend and SS3 finally manages to not be a slideshow above the lowest settings. Great improvement but unfortunately there is some graphic corruption. Let me know what you need, I'm willing to test! Vadim ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [MESA][PATCH] tgsi: fix mis-matching AOS instruction emission
Yeah the tgsi_aos emit code doesn't really get much testing, as it isn't actually used anywhere. It might have other unnoticed bugs. Roland Am 27.02.2013 21:21, schrieb Jose Fonseca: Good catch. Thanks! Jose - Original Message - Catched this that morning From e50374e62254e7532c695bebb3e608242638bb73 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Maxence=20Le=20Dor=C3=A9?= maxence.led...@gmail.com Date: Wed, 27 Feb 2013 10:24:10 +0100 Subject: [PATCH] tgsi: fix mis-matching instruction emission --- src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c index dbd9ccb..9a30cc8 100644 --- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c +++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c @@ -536,7 +536,7 @@ lp_emit_instruction_aos( case TGSI_OPCODE_MIN: src0 = lp_build_emit_fetch(bld-bld_base, inst, 0, LP_CHAN_ALL); src1 = lp_build_emit_fetch(bld-bld_base, inst, 1, LP_CHAN_ALL); - dst0 = lp_build_max(bld-bld_base.base, src0, src1); + dst0 = lp_build_min(bld-bld_base.base, src0, src1); break; case TGSI_OPCODE_MAX: -- 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 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel: Remove intel_mipmap_tree::wraps_etc
On 02/27/2013 01:31 PM, Chad Versace wrote: The field was equivalent to (etc_format != MESA_FORMAT_NONE), and therefore duplicate information. This patch removes field and replaces all references to it with `etc_format != MESA_FORMAT_NONE`. No Piglit ETC test regresses on Intel Sandybridge. Signed-off-by: Chad Versace chad.vers...@linux.intel.com Reviewed-by: Kenneth Graunke kenn...@whitecape.org ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/5] r600g: unify vgt states
The states were split because we thought it caused a hardlock. Now we know
the hardlock was caused by something else and has since been fixed.
---
src/gallium/drivers/r600/evergreen_state.c |3 +--
src/gallium/drivers/r600/r600_hw_context.c |1 -
src/gallium/drivers/r600/r600_pipe.h |6 --
src/gallium/drivers/r600/r600_state.c|3 +--
src/gallium/drivers/r600/r600_state_common.c | 22 +++---
5 files changed, 9 insertions(+), 26 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_state.c
b/src/gallium/drivers/r600/evergreen_state.c
index 205bbc5..244989d 100644
--- a/src/gallium/drivers/r600/evergreen_state.c
+++ b/src/gallium/drivers/r600/evergreen_state.c
@@ -2615,8 +2615,7 @@ void evergreen_init_state_functions(struct r600_context
*rctx)
r600_init_atom(rctx, rctx-samplers[PIPE_SHADER_GEOMETRY].views.atom,
id++, evergreen_emit_gs_sampler_views, 0);
r600_init_atom(rctx, rctx-samplers[PIPE_SHADER_FRAGMENT].views.atom,
id++, evergreen_emit_ps_sampler_views, 0);
- r600_init_atom(rctx, rctx-vgt_state.atom, id++, r600_emit_vgt_state,
6);
- r600_init_atom(rctx, rctx-vgt2_state.atom, id++,
r600_emit_vgt2_state, 3);
+ r600_init_atom(rctx, rctx-vgt_state.atom, id++, r600_emit_vgt_state,
7);
if (rctx-chip_class == EVERGREEN) {
r600_init_atom(rctx, rctx-sample_mask.atom, id++,
evergreen_emit_sample_mask, 3);
diff --git a/src/gallium/drivers/r600/r600_hw_context.c
b/src/gallium/drivers/r600/r600_hw_context.c
index 91af6b8..b78b004 100644
--- a/src/gallium/drivers/r600/r600_hw_context.c
+++ b/src/gallium/drivers/r600/r600_hw_context.c
@@ -827,7 +827,6 @@ void r600_begin_new_cs(struct r600_context *ctx)
ctx-framebuffer.atom.dirty = true;
ctx-poly_offset_state.atom.dirty = true;
ctx-vgt_state.atom.dirty = true;
- ctx-vgt2_state.atom.dirty = true;
ctx-sample_mask.atom.dirty = true;
ctx-scissor.atom.dirty = true;
ctx-config_state.atom.dirty = true;
diff --git a/src/gallium/drivers/r600/r600_pipe.h
b/src/gallium/drivers/r600/r600_pipe.h
index 570a284..4cfade1 100644
--- a/src/gallium/drivers/r600/r600_pipe.h
+++ b/src/gallium/drivers/r600/r600_pipe.h
@@ -127,10 +127,6 @@ struct r600_vgt_state {
struct r600_atom atom;
uint32_t vgt_multi_prim_ib_reset_en;
uint32_t vgt_multi_prim_ib_reset_indx;
-};
-
-struct r600_vgt2_state {
- struct r600_atom atom;
uint32_t vgt_indx_offset;
};
@@ -506,7 +502,6 @@ struct r600_context {
struct r600_config_stateconfig_state;
struct r600_stencil_ref_state stencil_ref;
struct r600_vgt_state vgt_state;
- struct r600_vgt2_state vgt2_state;
struct r600_viewport_state viewport;
/* Shaders and shader resources. */
struct r600_cso_state vertex_fetch_shader;
@@ -733,7 +728,6 @@ void r600_emit_cso_state(struct r600_context *rctx, struct
r600_atom *atom);
void r600_emit_alphatest_state(struct r600_context *rctx, struct r600_atom
*atom);
void r600_emit_blend_color(struct r600_context *rctx, struct r600_atom *atom);
void r600_emit_vgt_state(struct r600_context *rctx, struct r600_atom *atom);
-void r600_emit_vgt2_state(struct r600_context *rctx, struct r600_atom *atom);
void r600_emit_clip_misc_state(struct r600_context *rctx, struct r600_atom
*atom);
void r600_emit_stencil_ref(struct r600_context *rctx, struct r600_atom *atom);
void r600_emit_viewport_state(struct r600_context *rctx, struct r600_atom
*atom);
diff --git a/src/gallium/drivers/r600/r600_state.c
b/src/gallium/drivers/r600/r600_state.c
index bbff6bd..fd3b14e 100644
--- a/src/gallium/drivers/r600/r600_state.c
+++ b/src/gallium/drivers/r600/r600_state.c
@@ -2312,8 +2312,7 @@ void r600_init_state_functions(struct r600_context *rctx)
r600_init_atom(rctx, rctx-samplers[PIPE_SHADER_FRAGMENT].views.atom,
id++, r600_emit_ps_sampler_views, 0);
r600_init_atom(rctx, rctx-vertex_buffer_state.atom, id++,
r600_emit_vertex_buffers, 0);
- r600_init_atom(rctx, rctx-vgt_state.atom, id++, r600_emit_vgt_state,
6);
- r600_init_atom(rctx, rctx-vgt2_state.atom, id++,
r600_emit_vgt2_state, 3);
+ r600_init_atom(rctx, rctx-vgt_state.atom, id++, r600_emit_vgt_state,
7);
r600_init_atom(rctx, rctx-seamless_cube_map.atom, id++,
r600_emit_seamless_cube_map, 3);
r600_init_atom(rctx, rctx-sample_mask.atom, id++,
r600_emit_sample_mask, 3);
diff --git a/src/gallium/drivers/r600/r600_state_common.c
b/src/gallium/drivers/r600/r600_state_common.c
index 4c68506..8906695 100644
--- a/src/gallium/drivers/r600/r600_state_common.c
+++ b/src/gallium/drivers/r600/r600_state_common.c
@@ -192,15 +192,9 @@ void r600_emit_vgt_state(struct r600_context *rctx, struct
r600_atom *atom)
struct r600_vgt_state *a = (struct r600_vgt_state *)atom;
r600_write_context_reg(cs,
[Mesa-dev] [PATCH 2/5] r600g: cleanup deprecated register tables
These registers are either already emitted elsewhere or moved to start_cs.
---
src/gallium/drivers/r600/evergreen_hw_context.c | 42 ---
src/gallium/drivers/r600/evergreen_state.c | 14
src/gallium/drivers/r600/r600_hw_context.c |3 --
3 files changed, 14 insertions(+), 45 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_hw_context.c
b/src/gallium/drivers/r600/evergreen_hw_context.c
index bb47530..b0f64b4 100644
--- a/src/gallium/drivers/r600/evergreen_hw_context.c
+++ b/src/gallium/drivers/r600/evergreen_hw_context.c
@@ -28,18 +28,7 @@
#include util/u_memory.h
#include util/u_math.h
-static const struct r600_reg cayman_config_reg_list[] = {
- {R_009100_SPI_CONFIG_CNTL, REG_FLAG_ENABLE_ALWAYS |
REG_FLAG_FLUSH_CHANGE, 0},
- {R_00913C_SPI_CONFIG_CNTL_1, REG_FLAG_ENABLE_ALWAYS |
REG_FLAG_FLUSH_CHANGE, 0},
-};
-
static const struct r600_reg evergreen_context_reg_list[] = {
- {R_028010_DB_RENDER_OVERRIDE2, 0, 0},
- {GROUP_FORCE_NEW_BLOCK, 0, 0},
- {R_028014_DB_HTILE_DATA_BASE, REG_FLAG_NEED_BO, 0},
- {GROUP_FORCE_NEW_BLOCK, 0, 0},
- {R_028234_PA_SU_HARDWARE_SCREEN_OFFSET, 0, 0},
- {GROUP_FORCE_NEW_BLOCK, 0, 0},
{R_02861C_SPI_VS_OUT_ID_0, 0, 0},
{R_028620_SPI_VS_OUT_ID_1, 0, 0},
{R_028624_SPI_VS_OUT_ID_2, 0, 0},
@@ -85,30 +74,19 @@ static const struct r600_reg evergreen_context_reg_list[] =
{
{R_0286C0_SPI_PS_INPUT_CNTL_31, 0, 0},
{GROUP_FORCE_NEW_BLOCK, 0, 0},
{R_0286C4_SPI_VS_OUT_CONFIG, 0, 0},
- {R_0286C8_SPI_THREAD_GROUPING, 0, 0},
{R_0286CC_SPI_PS_IN_CONTROL_0, 0, 0},
{R_0286D0_SPI_PS_IN_CONTROL_1, 0, 0},
{R_0286D8_SPI_INPUT_Z, 0, 0},
{R_0286E0_SPI_BARYC_CNTL, 0, 0},
{R_0286E4_SPI_PS_IN_CONTROL_2, 0, 0},
- {R_0286E8_SPI_COMPUTE_INPUT_CNTL, 0, 0},
{R_028840_SQ_PGM_START_PS, REG_FLAG_NEED_BO, 0},
{R_028844_SQ_PGM_RESOURCES_PS, 0, 0},
{R_02884C_SQ_PGM_EXPORTS_PS, 0, 0},
{R_02885C_SQ_PGM_START_VS, REG_FLAG_NEED_BO, 0},
{R_028860_SQ_PGM_RESOURCES_VS, 0, 0},
- {R_0288EC_SQ_LDS_ALLOC_PS, 0, 0},
- {R_028ABC_DB_HTILE_SURFACE, 0, 0},
- {R_028B54_VGT_SHADER_STAGES_EN, 0, 0},
};
static const struct r600_reg cayman_context_reg_list[] = {
- {R_028010_DB_RENDER_OVERRIDE2, 0, 0},
- {GROUP_FORCE_NEW_BLOCK, 0, 0},
- {R_028014_DB_HTILE_DATA_BASE, REG_FLAG_NEED_BO, 0},
- {GROUP_FORCE_NEW_BLOCK, 0, 0},
- {R_028234_PA_SU_HARDWARE_SCREEN_OFFSET, 0, 0},
- {GROUP_FORCE_NEW_BLOCK, 0, 0},
{R_02861C_SPI_VS_OUT_ID_0, 0, 0},
{R_028620_SPI_VS_OUT_ID_1, 0, 0},
{R_028624_SPI_VS_OUT_ID_2, 0, 0},
@@ -152,31 +130,16 @@ static const struct r600_reg cayman_context_reg_list[] = {
{R_0286BC_SPI_PS_INPUT_CNTL_30, 0, 0},
{R_0286C0_SPI_PS_INPUT_CNTL_31, 0, 0},
{R_0286C4_SPI_VS_OUT_CONFIG, 0, 0},
- {R_0286C8_SPI_THREAD_GROUPING, 0, 0},
{R_0286CC_SPI_PS_IN_CONTROL_0, 0, 0},
{R_0286D0_SPI_PS_IN_CONTROL_1, 0, 0},
{R_0286D8_SPI_INPUT_Z, 0, 0},
{R_0286E0_SPI_BARYC_CNTL, 0, 0},
{R_0286E4_SPI_PS_IN_CONTROL_2, 0, 0},
- {R_0286E8_SPI_COMPUTE_INPUT_CNTL, 0, 0},
- {R_028838_SQ_DYN_GPR_RESOURCE_LIMIT_1, 0, 0},
{R_028840_SQ_PGM_START_PS, REG_FLAG_NEED_BO, 0},
{R_028844_SQ_PGM_RESOURCES_PS, 0, 0},
{R_02884C_SQ_PGM_EXPORTS_PS, 0, 0},
{R_02885C_SQ_PGM_START_VS, REG_FLAG_NEED_BO, 0},
{R_028860_SQ_PGM_RESOURCES_VS, 0, 0},
- {R_028900_SQ_ESGS_RING_ITEMSIZE, 0, 0},
- {R_028904_SQ_GSVS_RING_ITEMSIZE, 0, 0},
- {R_028908_SQ_ESTMP_RING_ITEMSIZE, 0, 0},
- {R_02890C_SQ_GSTMP_RING_ITEMSIZE, 0, 0},
- {R_028910_SQ_VSTMP_RING_ITEMSIZE, 0, 0},
- {R_028914_SQ_PSTMP_RING_ITEMSIZE, 0, 0},
- {R_02891C_SQ_GS_VERT_ITEMSIZE, 0, 0},
- {R_028920_SQ_GS_VERT_ITEMSIZE_1, 0, 0},
- {R_028924_SQ_GS_VERT_ITEMSIZE_2, 0, 0},
- {R_028928_SQ_GS_VERT_ITEMSIZE_3, 0, 0},
- {R_028ABC_DB_HTILE_SURFACE, 0, 0},
- {R_028B54_VGT_SHADER_STAGES_EN, 0, 0},
};
int evergreen_context_init(struct r600_context *ctx)
@@ -185,11 +148,6 @@ int evergreen_context_init(struct r600_context *ctx)
/* add blocks */
if (ctx-family = CHIP_CAYMAN)
- r = r600_context_add_block(ctx, cayman_config_reg_list,
- Elements(cayman_config_reg_list),
PKT3_SET_CONFIG_REG, EVERGREEN_CONFIG_REG_OFFSET);
- if (r)
- goto out_err;
- if (ctx-family = CHIP_CAYMAN)
r = r600_context_add_block(ctx, cayman_context_reg_list,
Elements(cayman_context_reg_list),
PKT3_SET_CONTEXT_REG, EVERGREEN_CONTEXT_REG_OFFSET);
else
diff --git a/src/gallium/drivers/r600/evergreen_state.c
b/src/gallium/drivers/r600/evergreen_state.c
index 244989d..38f83e9 100644
---
[Mesa-dev] [PATCH 3/5] r600g: pad the DMA CS to a multiple of 8 dwords
NOTE: This is a candidate for the 9.1 branch.
---
src/gallium/drivers/r600/r600_pipe.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
index e2d86e9..27c98ec 100644
--- a/src/gallium/drivers/r600/r600_pipe.c
+++ b/src/gallium/drivers/r600/r600_pipe.c
@@ -23,6 +23,7 @@
#include r600_pipe.h
#include r600_public.h
#include r600_isa.h
+#include r600d.h
#include errno.h
#include pipe/p_shader_tokens.h
@@ -166,12 +167,23 @@ static void r600_flush_gfx_ring(void *ctx, unsigned flags)
static void r600_flush_dma_ring(void *ctx, unsigned flags)
{
struct r600_context *rctx = (struct r600_context *)ctx;
+ struct radeon_winsys_cs *cs = rctx-rings.dma.cs;
+ unsigned padding_dw, i;
- if (!rctx-rings.dma.cs-cdw) {
+ if (!cs-cdw) {
return;
}
+
+ /* Pad the DMA CS to a multiple of 8 dwords. */
+ padding_dw = 8 - cs-cdw % 8;
+ if (padding_dw 8) {
+ for (i = 0; i padding_dw; i++) {
+ cs-buf[cs-cdw++] = DMA_PACKET(DMA_PACKET_NOP, 0, 0,
0);
+ }
+ }
+
rctx-rings.dma.flushing = true;
- rctx-ws-cs_flush(rctx-rings.dma.cs, flags);
+ rctx-ws-cs_flush(cs, flags);
rctx-rings.dma.flushing = false;
}
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/5] gallium/util: add helper code for 1D integer range
---
src/gallium/auxiliary/util/u_range.h | 91 ++
1 file changed, 91 insertions(+)
create mode 100644 src/gallium/auxiliary/util/u_range.h
diff --git a/src/gallium/auxiliary/util/u_range.h
b/src/gallium/auxiliary/util/u_range.h
new file mode 100644
index 000..ae9cc37
--- /dev/null
+++ b/src/gallium/auxiliary/util/u_range.h
@@ -0,0 +1,91 @@
+/*
+ * Copyright 2013 Marek Olšák mar...@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
+ * on the rights to use, copy, modify, merge, publish, distribute, sub
+ * license, and/or sell copies of the Software, and to permit persons to whom
+ * the Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHOR(S) AND/OR THEIR SUPPLIERS BE LIABLE FOR ANY CLAIM,
+ * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+ * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
+ * USE OR OTHER DEALINGS IN THE SOFTWARE. */
+
+/**
+ * @file
+ * 1D integer range, capable of the union and intersection operations.
+ *
+ * It only maintains a single interval which is extended when the union is
+ * done. This implementation is partially thread-safe (readers are not
+ * protected by a lock).
+ *
+ * @author Marek Olšák
+ */
+
+#ifndef U_RANGE_H
+#define U_RANGE_H
+
+#include os/os_thread.h
+
+struct util_range {
+ unsigned start; /* inclusive */
+ unsigned end; /* exclusive */
+
+ /* for the range to be consistent with multiple contexts: */
+ pipe_mutex write_mutex;
+};
+
+
+static INLINE void
+util_range_set_empty(struct util_range *range)
+{
+ range-start = ~0;
+ range-end = 0;
+}
+
+/* This is like a union of two sets. */
+static INLINE void
+util_range_add(struct util_range *range, unsigned start, unsigned end)
+{
+ if (start range-start || end range-end) {
+ pipe_mutex_lock(range-write_mutex);
+ if (start range-start)
+ range-start = start;
+ if (end range-end)
+ range-end = end;
+ pipe_mutex_unlock(range-write_mutex);
+ }
+}
+
+static INLINE boolean
+util_ranges_intersect(struct util_range *range, unsigned start, unsigned end)
+{
+ return MAX2(start, range-start) MIN2(end, range-end);
+}
+
+
+/* Init/deinit */
+
+static INLINE void
+util_range_init(struct util_range *range)
+{
+ pipe_mutex_init(range-write_mutex);
+ util_range_set_empty(range);
+}
+
+static INLINE void
+util_range_destroy(struct util_range *range)
+{
+ pipe_mutex_destroy(range-write_mutex);
+}
+
+#endif
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/5] r600g: always map uninitialized buffer range as unsynchronized
Any driver can implement this simple and efficient optimization.
Team Fortress 2 hits it always. The DISCARD_RANGE codepath is not even used
with TF2 anymore, so we avoid a ton of useless buffer copies.
---
src/gallium/drivers/r600/evergreen_hw_context.c |3 +++
src/gallium/drivers/r600/evergreen_state.c |4
src/gallium/drivers/r600/r600.h | 11 +++
src/gallium/drivers/r600/r600_buffer.c | 17 +
src/gallium/drivers/r600/r600_hw_context.c |6 ++
src/gallium/drivers/r600/r600_state_common.c|4
6 files changed, 45 insertions(+)
diff --git a/src/gallium/drivers/r600/evergreen_hw_context.c
b/src/gallium/drivers/r600/evergreen_hw_context.c
index b0f64b4..f81d7f3 100644
--- a/src/gallium/drivers/r600/evergreen_hw_context.c
+++ b/src/gallium/drivers/r600/evergreen_hw_context.c
@@ -241,4 +241,7 @@ void evergreen_dma_copy(struct r600_context *rctx,
src_offset += csize shift;
size -= csize;
}
+
+ util_range_add(rdst-valid_buffer_range, dst_offset,
+ dst_offset + size);
}
diff --git a/src/gallium/drivers/r600/evergreen_state.c
b/src/gallium/drivers/r600/evergreen_state.c
index 38f83e9..4a41c28 100644
--- a/src/gallium/drivers/r600/evergreen_state.c
+++ b/src/gallium/drivers/r600/evergreen_state.c
@@ -1376,6 +1376,10 @@ void evergreen_init_color_surface_rat(struct
r600_context *rctx,
* elements. */
surf-cb_color_dim = pipe_buffer-width0;
+ /* Set the buffer range the GPU will have access to: */
+ util_range_add(r600_resource(pipe_buffer)-valid_buffer_range,
+ 0, pipe_buffer-width0);
+
surf-cb_color_cmask = surf-cb_color_base;
surf-cb_color_cmask_slice = 0;
surf-cb_color_fmask = surf-cb_color_base;
diff --git a/src/gallium/drivers/r600/r600.h b/src/gallium/drivers/r600/r600.h
index d018ebb..15196f7 100644
--- a/src/gallium/drivers/r600/r600.h
+++ b/src/gallium/drivers/r600/r600.h
@@ -28,6 +28,7 @@
#include ../../winsys/radeon/drm/radeon_winsys.h
#include util/u_double_list.h
+#include util/u_range.h
#include util/u_transfer.h
#define R600_ERR(fmt, args...) \
@@ -50,6 +51,16 @@ struct r600_resource {
/* Resource state. */
unsigneddomains;
+
+ /* The buffer range which is initialized (with a write transfer,
+* streamout, DMA, or as a random access target). The rest of
+* the buffer is considered invalid and can be mapped unsynchronized.
+*
+* This allows unsychronized mapping of a buffer range which hasn't
+* been used yet. It's for applications which forget to use
+* the unsynchronized map flag and expect the driver to figure it out.
+ */
+ struct util_range valid_buffer_range;
};
#define R600_BLOCK_MAX_BO 32
diff --git a/src/gallium/drivers/r600/r600_buffer.c
b/src/gallium/drivers/r600/r600_buffer.c
index da6e529..8080611 100644
--- a/src/gallium/drivers/r600/r600_buffer.c
+++ b/src/gallium/drivers/r600/r600_buffer.c
@@ -34,6 +34,7 @@ static void r600_buffer_destroy(struct pipe_screen *screen,
{
struct r600_resource *rbuffer = r600_resource(buf);
+ util_range_destroy(rbuffer-valid_buffer_range);
pb_reference(rbuffer-buf, NULL);
FREE(rbuffer);
}
@@ -98,6 +99,14 @@ static void *r600_buffer_transfer_map(struct pipe_context
*ctx,
assert(box-x + box-width = resource-width0);
+ /* See if the buffer range being mapped has never been initialized,
+* in which case it can be mapped unsynchronized. */
+ if (!(usage PIPE_TRANSFER_UNSYNCHRONIZED)
+ usage PIPE_TRANSFER_WRITE
+ !util_ranges_intersect(rbuffer-valid_buffer_range, box-x, box-x
+ box-width)) {
+ usage |= PIPE_TRANSFER_UNSYNCHRONIZED;
+ }
+
if (usage PIPE_TRANSFER_DISCARD_WHOLE_RESOURCE
!(usage PIPE_TRANSFER_UNSYNCHRONIZED)) {
assert(usage PIPE_TRANSFER_WRITE);
@@ -182,6 +191,7 @@ static void r600_buffer_transfer_unmap(struct pipe_context
*pipe,
{
struct r600_context *rctx = (struct r600_context*)pipe;
struct r600_transfer *rtransfer = (struct r600_transfer*)transfer;
+ struct r600_resource *rbuffer = r600_resource(transfer-resource);
if (rtransfer-staging) {
struct pipe_resource *dst, *src;
@@ -207,6 +217,11 @@ static void r600_buffer_transfer_unmap(struct pipe_context
*pipe,
}
pipe_resource_reference((struct
pipe_resource**)rtransfer-staging, NULL);
}
+
+ if (transfer-usage PIPE_TRANSFER_WRITE) {
+ util_range_add(rbuffer-valid_buffer_range, transfer-box.x,
+ transfer-box.x + transfer-box.width);
+ }
util_slab_free(rctx-pool_transfers, transfer);
}
@@ -263,6 +278,7 @@ bool
Re: [Mesa-dev] [PATCH] intel: Remove intel_mipmap_tree::wraps_etc
On Wed, Feb 27, 2013 at 1:31 PM, Chad Versace
chad.vers...@linux.intel.com wrote:
The field was equivalent to (etc_format != MESA_FORMAT_NONE), and
therefore duplicate information.
This patch removes field and replaces all references to it with
`etc_format != MESA_FORMAT_NONE`.
No Piglit ETC test regresses on Intel Sandybridge.
Signed-off-by: Chad Versace chad.vers...@linux.intel.com
---
src/mesa/drivers/dri/intel/intel_mipmap_tree.c | 10 +++---
src/mesa/drivers/dri/intel/intel_mipmap_tree.h | 14 --
2 files changed, 3 insertions(+), 21 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
index 306cbbe..e150501 100644
--- a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
@@ -390,7 +390,6 @@ intel_miptree_create(struct intel_context *intel,
total_height = ALIGN(total_height, 64);
}
- mt-wraps_etc = (etc_format != MESA_FORMAT_NONE) ? true : false;
mt-etc_format = etc_format;
mt-region = intel_region_alloc(intel-intelScreen,
tiling,
@@ -1309,10 +1308,7 @@ intel_miptree_map_etc(struct intel_context *intel,
unsigned int level,
unsigned int slice)
{
- /* For justification see intel_mipmap_tree:wraps_etc.
-*/
- assert(mt-wraps_etc);
-
+ assert(mt-etc_format != MESA_FORMAT_NONE);
if (mt-etc_format == MESA_FORMAT_ETC1_RGB8) {
assert(mt-format == MESA_FORMAT_RGBX_REV);
}
@@ -1575,7 +1571,7 @@ intel_miptree_map_singlesample(struct intel_context
*intel,
if (mt-format == MESA_FORMAT_S8) {
intel_miptree_map_s8(intel, mt, map, level, slice);
- } else if (mt-wraps_etc) {
+ } else if (mt-etc_format != MESA_FORMAT_NONE) {
intel_miptree_map_etc(intel, mt, map, level, slice);
} else if (mt-stencil_mt) {
intel_miptree_map_depthstencil(intel, mt, map, level, slice);
@@ -1633,7 +1629,7 @@ intel_miptree_unmap_singlesample(struct intel_context
*intel,
if (mt-format == MESA_FORMAT_S8) {
intel_miptree_unmap_s8(intel, mt, map, level, slice);
- } else if (mt-wraps_etc) {
+ } else if (mt-etc_format != MESA_FORMAT_NONE) {
intel_miptree_unmap_etc(intel, mt, map, level, slice);
} else if (mt-stencil_mt) {
intel_miptree_unmap_depthstencil(intel, mt, map, level, slice);
diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.h
b/src/mesa/drivers/dri/intel/intel_mipmap_tree.h
index 27540bc..2070be7 100644
--- a/src/mesa/drivers/dri/intel/intel_mipmap_tree.h
+++ b/src/mesa/drivers/dri/intel/intel_mipmap_tree.h
@@ -360,20 +360,6 @@ struct intel_mipmap_tree
*/
struct intel_mipmap_tree *mcs_mt;
- /**
-* \brief The miptree contains uncompressed data that was originally
-* ETC1/ETC2 data.
-*
-* On hardware that lacks support for ETC1/ETC2 textures, we do the
following
-* on calls to glCompressedTexImage2D() with an ETC1/ETC2 texture format:
-* 1. Create a miptree whose format is a suitable uncompressed mesa
format
-* with the wraps_etc flag set.
-* 2. Translate the ETC1/ETC2 data into uncompressed mesa format.
-* 3. Store the uncompressed data into the miptree and discard the
ETC1/ETC2
-* data.
-*/
- bool wraps_etc;
-
/* These are also refcounted:
*/
GLuint refcount;
--
1.8.1.4
Reviewed-by: Anuj Phogat anuj.pho...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 61361] Version mismatch error. This is libtool 2.4.2, but the definition of this LT_INIT comes from libtool 2.2.8.
https://bugs.freedesktop.org/show_bug.cgi?id=61361 --- Comment #2 from Dennis Heuer dh-b...@online.de --- release tarball -- 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] [RFC 12/13] i965: support for YUV formatted external textures
On Wed, Feb 27, 2013 at 2:32 AM, Pohjolainen, Topi topi.pohjolai...@intel.com wrote: On Tue, Feb 26, 2013 at 12:28:14PM -0500, Kristian H?gsberg wrote: On Tue, Feb 26, 2013 at 8:19 AM, Topi Pohjolainen topi.pohjolai...@intel.com wrote: Namely YUV420, YVU420 (YV12) and NV12. Here one extends the shader program with instructions that sample the separate Y- and U/V-planes and convert the YUV to RGB as specified by ITU-R BT.601. Packed formats are handled through the normal paths. I didn't read the entire patch series yet, but this doesn't sound right. You can't handle packed (YUYV) buffers through normal sampling. If you're filtering, you end up blending the wrong components. If you're sampling the buffer as 32 bpp, you'll blend Y components not with their neighboring pixel but the pixel one over, as each sample has two Y components. If you sample the texture as 16bpp, you end up blending the U and V components as you sample. The trick is to set up two textures for the same buffer and sample Y using a 16 bpp texture and sample the U and V components using a 32 bpp buffer. Here the first two (YUV420, YVU420) have all the components in different planes and I'm giving each plane its own sampling surface, and hence sampling them separately as R8_UNORM. The packed UV-plane of NV12 I'm treating in turn as having two channels (sampling using R8G8_UNORM). Does that make sense? I haven't written support for anything more complex yet, but it is good to know your trick if the need arises. Right, that works for thos formats. The trick of using two samplers on the same buffer applies to YUYV buffers, ie packed format where each 32bit word contains two Y samples, one U and one V sample and corresponds to two pixels. Kristian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/5] r600g: always map uninitialized buffer range as unsynchronized
On Wed, Feb 27, 2013 at 6:11 PM, Marek Olšák mar...@gmail.com wrote:
Any driver can implement this simple and efficient optimization.
Team Fortress 2 hits it always. The DISCARD_RANGE codepath is not even used
with TF2 anymore, so we avoid a ton of useless buffer copies.
With this patch applied are you still seeing issues any issues with CP
DMA? If not maybe we can leave it enabled for 6xx/7xx.
Alex
---
src/gallium/drivers/r600/evergreen_hw_context.c |3 +++
src/gallium/drivers/r600/evergreen_state.c |4
src/gallium/drivers/r600/r600.h | 11 +++
src/gallium/drivers/r600/r600_buffer.c | 17 +
src/gallium/drivers/r600/r600_hw_context.c |6 ++
src/gallium/drivers/r600/r600_state_common.c|4
6 files changed, 45 insertions(+)
diff --git a/src/gallium/drivers/r600/evergreen_hw_context.c
b/src/gallium/drivers/r600/evergreen_hw_context.c
index b0f64b4..f81d7f3 100644
--- a/src/gallium/drivers/r600/evergreen_hw_context.c
+++ b/src/gallium/drivers/r600/evergreen_hw_context.c
@@ -241,4 +241,7 @@ void evergreen_dma_copy(struct r600_context *rctx,
src_offset += csize shift;
size -= csize;
}
+
+ util_range_add(rdst-valid_buffer_range, dst_offset,
+ dst_offset + size);
}
diff --git a/src/gallium/drivers/r600/evergreen_state.c
b/src/gallium/drivers/r600/evergreen_state.c
index 38f83e9..4a41c28 100644
--- a/src/gallium/drivers/r600/evergreen_state.c
+++ b/src/gallium/drivers/r600/evergreen_state.c
@@ -1376,6 +1376,10 @@ void evergreen_init_color_surface_rat(struct
r600_context *rctx,
* elements. */
surf-cb_color_dim = pipe_buffer-width0;
+ /* Set the buffer range the GPU will have access to: */
+ util_range_add(r600_resource(pipe_buffer)-valid_buffer_range,
+ 0, pipe_buffer-width0);
+
surf-cb_color_cmask = surf-cb_color_base;
surf-cb_color_cmask_slice = 0;
surf-cb_color_fmask = surf-cb_color_base;
diff --git a/src/gallium/drivers/r600/r600.h b/src/gallium/drivers/r600/r600.h
index d018ebb..15196f7 100644
--- a/src/gallium/drivers/r600/r600.h
+++ b/src/gallium/drivers/r600/r600.h
@@ -28,6 +28,7 @@
#include ../../winsys/radeon/drm/radeon_winsys.h
#include util/u_double_list.h
+#include util/u_range.h
#include util/u_transfer.h
#define R600_ERR(fmt, args...) \
@@ -50,6 +51,16 @@ struct r600_resource {
/* Resource state. */
unsigneddomains;
+
+ /* The buffer range which is initialized (with a write transfer,
+* streamout, DMA, or as a random access target). The rest of
+* the buffer is considered invalid and can be mapped unsynchronized.
+*
+* This allows unsychronized mapping of a buffer range which hasn't
+* been used yet. It's for applications which forget to use
+* the unsynchronized map flag and expect the driver to figure it out.
+ */
+ struct util_range valid_buffer_range;
};
#define R600_BLOCK_MAX_BO 32
diff --git a/src/gallium/drivers/r600/r600_buffer.c
b/src/gallium/drivers/r600/r600_buffer.c
index da6e529..8080611 100644
--- a/src/gallium/drivers/r600/r600_buffer.c
+++ b/src/gallium/drivers/r600/r600_buffer.c
@@ -34,6 +34,7 @@ static void r600_buffer_destroy(struct pipe_screen *screen,
{
struct r600_resource *rbuffer = r600_resource(buf);
+ util_range_destroy(rbuffer-valid_buffer_range);
pb_reference(rbuffer-buf, NULL);
FREE(rbuffer);
}
@@ -98,6 +99,14 @@ static void *r600_buffer_transfer_map(struct pipe_context
*ctx,
assert(box-x + box-width = resource-width0);
+ /* See if the buffer range being mapped has never been initialized,
+* in which case it can be mapped unsynchronized. */
+ if (!(usage PIPE_TRANSFER_UNSYNCHRONIZED)
+ usage PIPE_TRANSFER_WRITE
+ !util_ranges_intersect(rbuffer-valid_buffer_range, box-x,
box-x + box-width)) {
+ usage |= PIPE_TRANSFER_UNSYNCHRONIZED;
+ }
+
if (usage PIPE_TRANSFER_DISCARD_WHOLE_RESOURCE
!(usage PIPE_TRANSFER_UNSYNCHRONIZED)) {
assert(usage PIPE_TRANSFER_WRITE);
@@ -182,6 +191,7 @@ static void r600_buffer_transfer_unmap(struct
pipe_context *pipe,
{
struct r600_context *rctx = (struct r600_context*)pipe;
struct r600_transfer *rtransfer = (struct r600_transfer*)transfer;
+ struct r600_resource *rbuffer = r600_resource(transfer-resource);
if (rtransfer-staging) {
struct pipe_resource *dst, *src;
@@ -207,6 +217,11 @@ static void r600_buffer_transfer_unmap(struct
pipe_context *pipe,
}
pipe_resource_reference((struct
pipe_resource**)rtransfer-staging, NULL);
Re: [Mesa-dev] [PATCH 4/5] gallium/util: add helper code for 1D integer range
On 02/27/2013 04:11 PM, Marek Olšák wrote:
---
src/gallium/auxiliary/util/u_range.h | 91 ++
1 file changed, 91 insertions(+)
create mode 100644 src/gallium/auxiliary/util/u_range.h
diff --git a/src/gallium/auxiliary/util/u_range.h
b/src/gallium/auxiliary/util/u_range.h
new file mode 100644
index 000..ae9cc37
--- /dev/null
+++ b/src/gallium/auxiliary/util/u_range.h
@@ -0,0 +1,91 @@
+/*
+ * Copyright 2013 Marek Olšákmar...@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
+ * on the rights to use, copy, modify, merge, publish, distribute, sub
+ * license, and/or sell copies of the Software, and to permit persons to whom
+ * the Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHOR(S) AND/OR THEIR SUPPLIERS BE LIABLE FOR ANY CLAIM,
+ * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+ * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
+ * USE OR OTHER DEALINGS IN THE SOFTWARE. */
+
+/**
+ * @file
+ * 1D integer range, capable of the union and intersection operations.
+ *
+ * It only maintains a single interval which is extended when the union is
+ * done. This implementation is partially thread-safe (readers are not
+ * protected by a lock).
+ *
+ * @author Marek Olšák
+ */
+
+#ifndef U_RANGE_H
+#define U_RANGE_H
+
+#include os/os_thread.h
#include pipe/p_compiler.h for completeness?
+
+struct util_range {
+ unsigned start; /* inclusive */
+ unsigned end; /* exclusive */
+
+ /* for the range to be consistent with multiple contexts: */
+ pipe_mutex write_mutex;
+};
3-space indentation?
+
+
+static INLINE void
+util_range_set_empty(struct util_range *range)
+{
+ range-start = ~0;
+ range-end = 0;
+}
Would a util_range_is_empty() function be useful?
+
+/* This is like a union of two sets. */
+static INLINE void
+util_range_add(struct util_range *range, unsigned start, unsigned end)
+{
+ if (start range-start || end range-end) {
+ pipe_mutex_lock(range-write_mutex);
+ if (start range-start)
+ range-start = start;
+ if (end range-end)
+ range-end = end;
How about:
range-start = MIN2(range-start, start);
range-end = MAX2(range-end, end);
+ pipe_mutex_unlock(range-write_mutex);
+ }
+}
+
+static INLINE boolean
+util_ranges_intersect(struct util_range *range, unsigned start, unsigned end)
+{
+ return MAX2(start, range-start) MIN2(end, range-end);
+}
+
+
+/* Init/deinit */
+
+static INLINE void
+util_range_init(struct util_range *range)
+{
+ pipe_mutex_init(range-write_mutex);
+ util_range_set_empty(range);
+}
+
+static INLINE void
+util_range_destroy(struct util_range *range)
+{
+ pipe_mutex_destroy(range-write_mutex);
+}
+
+#endif
Reviewed-by: Brian Paul bri...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] (remove-mfeatures) mesa: generate glGet code for all APIs (v2)
On 02/27/2013 02:17 PM, Chad Versace wrote: From: Brian Paulbri...@vmware.com No longer pass -a flag to get_hash_generate.py script to specify OpenGL, ES1, ES2, etc. v2[chadv]: Fix Android makefile too. --- Brian, this patch in your series breaks the Android build. Here is a fixed version of your patch. The only difference is the hunk in file Android.gen.mk Thanks. I think I'll have to respin the branch to fix this up and a couple other things. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/9] remove mfeatures.h file
On 02/26/2013 10:16 AM, Andreas Boll wrote:
2013/2/26 Brian Paulbri...@vmware.com:
OK, I have a git tree on fd.o with this patch series (plus updates to
intel_screen.c and configure.ac).
With your configure.ac patch API_DEFINES seems now unused.
But from what I can see src/gallium/targets/egl-static/egl_st.c used
it to define FEATURE_{GL,ES1,ES2}
I think we went a bit too far with FEATURE removal here.
When the user specifies some combination of --disable-opengl
--enable-gles1 --enable-gles2 --enable-openvg on the command line,
that's going to control whether or not some components are built (like
the vega state tracker).
So I think that the configure script should still define FEATURE_GL,
FEATURE_ES1, FEATURE_VG, etc. because in gallium targets such as
egl-static we want to test for those CPP symbols so we don't introduce
function calls to non-existant objects.
So code like this in egl-static/egl_st.c should probably stay as-is:
switch (api) {
case ST_API_OPENGL:
#if FEATURE_GL || FEATURE_ES1 || FEATURE_ES2
#if _EGL_EXTERNAL_GL
stapi = egl_st_load_gl();
#else
stapi = st_gl_api_create();
#endif
#endif
break;
case ST_API_OPENVG:
#if FEATURE_VG
stapi = (struct st_api *) vg_api_get();
#endif
break;
default:
assert(!Unknown API Type\n);
break;
}
The point of the branch was to get rid of the mfeatures.h file. I
think I'll make a new remove-mfeatures-2 branch and stop short of
changing the configure/scons files. It might be a few days...
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 61582] New: meta ops should log perf debug messages when they fall back to software
https://bugs.freedesktop.org/show_bug.cgi?id=61582 Priority: medium Bug ID: 61582 Assignee: mesa-dev@lists.freedesktop.org Summary: meta ops should log perf debug messages when they fall back to software Severity: enhancement Classification: Unclassified OS: All Reporter: i...@freedesktop.org Hardware: All Status: NEW Version: unspecified Component: Mesa core Product: Mesa In bug #61412 we encountered a case when an application accidentally had fog enabled when calling glBitmap. As a result, meta fell back to software, and the app when from ~100fps to 6fps. Had meta provided feedback to the application developer, the problem could have been resolved much more quickly. -- 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 61412] glCallLists/glBitmap calls slow on Intel implementation of Mesa drivers
https://bugs.freedesktop.org/show_bug.cgi?id=61412 Ian Romanick i...@freedesktop.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |WONTFIX --- Comment #23 from Ian Romanick i...@freedesktop.org --- I'm closing this bug as WONTFIX, and I've just opened bug #61582 to replace it. Meta should have provided this feedback to the app. If James had gotten a message like glBitmap fell back to software because fog was enabled, a lot of his time would have been saved tracking this issue down. He really shouldn't have had to trace into _mesa_meta_Bitmap to figure this out. We've added some support for messages like this, and we just need to add more. -- 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 3/5] Bug fix: skip padding in get_called_parameter_string
From: Paul Berry stereotype...@gmail.com This bug is currently benign, since get_called_parameter_string() is currently only used for functions that return true for glx_function.has_different_protocol(), and none of those functions include padding. However, in order to implement marshalling of GL API functions, we'll need to use get_called_parameter_string() far more often. --- src/mapi/glapi/gen/gl_XML.py |2 ++ 1 file changed, 2 insertions(+) diff --git a/src/mapi/glapi/gen/gl_XML.py b/src/mapi/glapi/gen/gl_XML.py index 227e9fc..3bbc794 100644 --- a/src/mapi/glapi/gen/gl_XML.py +++ b/src/mapi/glapi/gen/gl_XML.py @@ -802,6 +802,8 @@ class gl_function( gl_item ): comma = for p in self.parameterIterator(): +if p.is_padding: +continue p_string = p_string + comma + p.name comma = , -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/5] Fixup program_parse.y to avoid uninitialized $$
From: Paul Berry stereotype...@gmail.com
Without this patch, $$.negate, $$.rgba_valid, and $$.xyzw_valid take
on garbage values. At the moment this problem is benign (the garbage
values happen to be zero), but in my experiments executing GL
operations on a background thread, the garbage values change, leading
to piglit failures.
Reviewed-by: Eric Anholt e...@anholt.net
---
src/mesa/program/program_parse.y |5 +
1 file changed, 5 insertions(+)
diff --git a/src/mesa/program/program_parse.y b/src/mesa/program/program_parse.y
index 025b547..baa436b 100644
--- a/src/mesa/program/program_parse.y
+++ b/src/mesa/program/program_parse.y
@@ -709,6 +709,7 @@ extSwizSel: INTEGER
}
$$.swz = ($1 == 0) ? SWIZZLE_ZERO : SWIZZLE_ONE;
+ $$.negate = 0;
/* 0 and 1 are valid for both RGBA swizzle names and XYZW
* swizzle names.
@@ -728,6 +729,10 @@ extSwizSel: INTEGER
s = $1[0];
free($1);
+ $$.rgba_valid = 0;
+ $$.xyzw_valid = 0;
+ $$.negate = 0;
+
switch (s) {
case 'x':
$$.swz = SWIZZLE_X;
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] glthread prep series
Here's a small series of fixes that have accumulated in the glthread-5 branch, located in my tree as glthread-push. Patch 1 replaces the LOL HAX commit of glthread-5, which I'll be rebasing out as my next step there. The glapi attribute additions aren't strictly fixes, but I think it's good to have them regardless of whether the glthread stuff ends up panning out -- this is surely not the only use of the API XML for logging arguments that we can imagine. Mostly, though, I want a chance to shorten what's becoming a rather long branch. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/5] mesa: Use quotes on bool driconf options to prevent stdbool.h breakage.
Since stdbool.h's true and false are #defines, they got expanded when used as macro arguments, and that expanded value was stored in the XML string, producing XML that driconf would then fail to parse. Currently no drivers included stdbool along with driconf, but I keep accidentally doing so on intel as we move towards using normal C. --- src/gallium/state_trackers/dri/common/dri_screen.c |4 +-- src/mesa/drivers/dri/common/xmlpool.h |7 + src/mesa/drivers/dri/common/xmlpool/t_options.h| 26 +- src/mesa/drivers/dri/intel/intel_screen.c | 28 ++-- src/mesa/drivers/dri/radeon/radeon_screen.c| 16 +-- 5 files changed, 44 insertions(+), 37 deletions(-) diff --git a/src/gallium/state_trackers/dri/common/dri_screen.c b/src/gallium/state_trackers/dri/common/dri_screen.c index a908e28..8354e90 100644 --- a/src/gallium/state_trackers/dri/common/dri_screen.c +++ b/src/gallium/state_trackers/dri/common/dri_screen.c @@ -53,7 +53,7 @@ PUBLIC const char __driConfigOptions[] = DRI_CONF_SECTION_END DRI_CONF_SECTION_QUALITY -/* DRI_CONF_FORCE_S3TC_ENABLE(false) */ +/* DRI_CONF_FORCE_S3TC_ENABLE(false) */ DRI_CONF_ALLOW_LARGE_TEXTURES(1) DRI_CONF_PP_CELSHADE(0) DRI_CONF_PP_NORED(0) @@ -64,7 +64,7 @@ PUBLIC const char __driConfigOptions[] = DRI_CONF_SECTION_END DRI_CONF_SECTION_DEBUG - DRI_CONF_FORCE_GLSL_EXTENSIONS_WARN(false) + DRI_CONF_FORCE_GLSL_EXTENSIONS_WARN(false) DRI_CONF_SECTION_END DRI_CONF_END; diff --git a/src/mesa/drivers/dri/common/xmlpool.h b/src/mesa/drivers/dri/common/xmlpool.h index ffea430..ebd4e7c 100644 --- a/src/mesa/drivers/dri/common/xmlpool.h +++ b/src/mesa/drivers/dri/common/xmlpool.h @@ -60,6 +60,13 @@ #define DRI_CONF_OPT_BEGIN(name,type,def) \ option name=\#name\ type=\#type\ default=\#def\\n +/** + * \brief Begin a boolean option definition, with the default value passed in + * as a string + */ +#define DRI_CONF_OPT_BEGIN_B(name,def) \ +option name=\#name\ type=\bool\ default=#def\n + /** \brief Begin an option definition with quoted default value */ #define DRI_CONF_OPT_BEGIN_Q(name,type,def) \ option name=\#name\ type=\#type\ default=#def\n diff --git a/src/mesa/drivers/dri/common/xmlpool/t_options.h b/src/mesa/drivers/dri/common/xmlpool/t_options.h index 683a473..b7d175c 100644 --- a/src/mesa/drivers/dri/common/xmlpool/t_options.h +++ b/src/mesa/drivers/dri/common/xmlpool/t_options.h @@ -53,12 +53,12 @@ DRI_CONF_SECTION_BEGIN \ DRI_CONF_DESC(en,gettext(Debugging)) #define DRI_CONF_NO_RAST(def) \ -DRI_CONF_OPT_BEGIN(no_rast,bool,def) \ +DRI_CONF_OPT_BEGIN_B(no_rast,def) \ DRI_CONF_DESC(en,gettext(Disable 3D acceleration)) \ DRI_CONF_OPT_END #define DRI_CONF_PERFORMANCE_BOXES(def) \ -DRI_CONF_OPT_BEGIN(performance_boxes,bool,def) \ +DRI_CONF_OPT_BEGIN_B(performance_boxes,def) \ DRI_CONF_DESC(en,gettext(Show performance boxes)) \ DRI_CONF_OPT_END @@ -69,7 +69,7 @@ DRI_CONF_SECTION_BEGIN \ DRI_CONF_DESC(en,gettext(Image Quality)) #define DRI_CONF_EXCESS_MIPMAP(def) \ -DRI_CONF_OPT_BEGIN(excess_mipmap,bool,def) \ +DRI_CONF_OPT_BEGIN_B(excess_mipmap,def) \ DRI_CONF_DESC(en,Enable extra mipmap level) \ DRI_CONF_OPT_END @@ -93,12 +93,12 @@ DRI_CONF_OPT_BEGIN_V(def_max_anisotropy,float,def,range) \ DRI_CONF_OPT_END #define DRI_CONF_NO_NEG_LOD_BIAS(def) \ -DRI_CONF_OPT_BEGIN(no_neg_lod_bias,bool,def) \ +DRI_CONF_OPT_BEGIN_B(no_neg_lod_bias,def) \ DRI_CONF_DESC(en,gettext(Forbid negative texture LOD bias)) \ DRI_CONF_OPT_END #define DRI_CONF_FORCE_S3TC_ENABLE(def) \ -DRI_CONF_OPT_BEGIN(force_s3tc_enable,bool,def) \ +DRI_CONF_OPT_BEGIN_B(force_s3tc_enable,def) \ DRI_CONF_DESC(en,gettext(Enable S3TC texture compression even if software support is not available)) \ DRI_CONF_OPT_END @@ -135,7 +135,7 @@ DRI_CONF_OPT_BEGIN_V(dither_mode,enum,def,0:2) \ DRI_CONF_OPT_END #define DRI_CONF_FLOAT_DEPTH(def) \ -DRI_CONF_OPT_BEGIN(float_depth,bool,def) \ +DRI_CONF_OPT_BEGIN_B(float_depth,def) \ DRI_CONF_DESC(en,gettext(Floating point depth buffer)) \ DRI_CONF_OPT_END @@ -187,7 +187,7 @@ DRI_CONF_OPT_END #define DRI_CONF_HYPERZ_DISABLED 0 #define DRI_CONF_HYPERZ_ENABLED 1 #define DRI_CONF_HYPERZ(def) \ -DRI_CONF_OPT_BEGIN(hyperz,bool,def) \ +DRI_CONF_OPT_BEGIN_B(hyperz,def) \ DRI_CONF_DESC(en,gettext(Use HyperZ to boost performance)) \ DRI_CONF_OPT_END @@ -259,31 +259,31 @@ DRI_CONF_SECTION_BEGIN \ DRI_CONF_DESC(en,gettext(Features that are not hardware-accelerated)) #define DRI_CONF_ARB_VERTEX_PROGRAM(def) \ -DRI_CONF_OPT_BEGIN(arb_vertex_program,bool,def) \ +DRI_CONF_OPT_BEGIN_B(arb_vertex_program,def) \ DRI_CONF_DESC(en,gettext(Enable extension GL_ARB_vertex_program)) \ DRI_CONF_OPT_END #define DRI_CONF_ALWAYS_FLUSH_BATCH(def) \
[Mesa-dev] [PATCH 4/5] glapi: Add parameter count information for uniforms.
This is the kind of information that would have been present for GLX, if GLX supported modern GL. This allows these entrypoints to get automatic asynchronous marshalling code generated for glthread. --- src/mapi/glapi/gen/GL3x.xml | 16 +- src/mapi/glapi/gen/gl_API.xml | 68 - 2 files changed, 42 insertions(+), 42 deletions(-) diff --git a/src/mapi/glapi/gen/GL3x.xml b/src/mapi/glapi/gen/GL3x.xml index c17a644..9ca3d47 100644 --- a/src/mapi/glapi/gen/GL3x.xml +++ b/src/mapi/glapi/gen/GL3x.xml @@ -424,26 +424,26 @@ function name=Uniform1uiv es2=3.0 offset=assign param name=location type=GLint/ -param name=count type=GLsizei/ -param name=value type=const GLuint */ +param name=count type=GLsizei counter=true/ +param name=value type=const GLuint * count=count/ /function function name=Uniform2uiv es2=3.0 offset=assign param name=location type=GLint/ -param name=count type=GLsizei/ -param name=value type=const GLuint */ +param name=count type=GLsizei counter=true/ +param name=value type=const GLuint * count=count count_scale=2/ /function function name=Uniform3uiv es2=3.0 offset=assign param name=location type=GLint/ -param name=count type=GLsizei/ -param name=value type=const GLuint */ +param name=count type=GLsizei counter=true/ +param name=value type=const GLuint * count=count count_scale=3/ /function function name=Uniform4uiv es2=3.0 offset=assign param name=location type=GLint/ -param name=count type=GLsizei/ -param name=value type=const GLuint */ +param name=count type=GLsizei counter=true/ +param name=value type=const GLuint * count=count count_scale=4/ /function !-- These functions alias ones from GL_EXT_texture_integer -- diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml index 4cbd724..803b1aa 100644 --- a/src/mapi/glapi/gen/gl_API.xml +++ b/src/mapi/glapi/gen/gl_API.xml @@ -5685,83 +5685,83 @@ function name=Uniform1fv es2=2.0 offset=assign param name=location type=GLint/ -param name=count type=GLsizei/ -param name=value type=const GLfloat */ +param name=count type=GLsizei counter=true/ +param name=value type=const GLfloat * count=count/ glx ignore=true/ glx ignore=true/ /function function name=Uniform2fv es2=2.0 offset=assign param name=location type=GLint/ -param name=count type=GLsizei/ -param name=value type=const GLfloat */ +param name=count type=GLsizei counter=true/ +param name=value type=const GLfloat * count=count count_scale=2/ glx ignore=true/ glx ignore=true/ /function function name=Uniform3fv es2=2.0 offset=assign param name=location type=GLint/ -param name=count type=GLsizei/ -param name=value type=const GLfloat */ +param name=count type=GLsizei counter=true/ +param name=value type=const GLfloat * count=count count_scale=3/ glx ignore=true/ glx ignore=true/ /function function name=Uniform4fv es2=2.0 offset=assign param name=location type=GLint/ -param name=count type=GLsizei/ -param name=value type=const GLfloat */ +param name=count type=GLsizei counter=true/ +param name=value type=const GLfloat * count=count count_scale=4/ glx ignore=true/ glx ignore=true/ /function function name=Uniform1iv es2=2.0 offset=assign param name=location type=GLint/ -param name=count type=GLsizei/ -param name=value type=const GLint */ +param name=count type=GLsizei counter=true/ +param name=value type=const GLint * count=count/ glx ignore=true/ glx ignore=true/ /function function name=Uniform2iv es2=2.0 offset=assign param name=location type=GLint/ -param name=count type=GLsizei/ -param name=value type=const GLint */ +param name=count type=GLsizei counter=true/ +param name=value type=const GLint * count=count count_scale=2/ glx ignore=true/ glx ignore=true/ /function function name=Uniform3iv es2=2.0 offset=assign param name=location type=GLint/ -param name=count type=GLsizei/ -param name=value type=const GLint */ +param name=count type=GLsizei counter=true/ +param name=value type=const GLint * count=count count_scale=3/ glx ignore=true/ glx ignore=true/ /function function name=Uniform4iv es2=2.0 offset=assign param name=location type=GLint/ -param name=count type=GLsizei/ -param name=value type=const GLint */ +param name=count type=GLsizei counter=true/ +param name=value type=const GLint * count=count count_scale=4/ glx ignore=true/ glx ignore=true/ /function
[Mesa-dev] [PATCH 5/5] glapi: Add counter information for glBufferData(), like glBufferSubData().
This causes this function to become asynchronous with glthread. --- src/mapi/glapi/gen/gl_API.xml |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml index 803b1aa..aa3e8a8 100644 --- a/src/mapi/glapi/gen/gl_API.xml +++ b/src/mapi/glapi/gen/gl_API.xml @@ -7656,8 +7656,8 @@ function name=BufferDataARB alias=BufferData param name=target type=GLenum/ -param name=size type=GLsizeiptrARB/ -param name=data type=const GLvoid */ +param name=size type=GLsizeiptrARB counter=true/ +param name=data type=const GLvoid * count=size/ param name=usage type=GLenum/ /function -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC 12/13] i965: support for YUV formatted external textures
On 02/27/2013 03:41 PM, Kristian Høgsberg wrote: On Wed, Feb 27, 2013 at 2:32 AM, Pohjolainen, Topi topi.pohjolai...@intel.com wrote: On Tue, Feb 26, 2013 at 12:28:14PM -0500, Kristian H?gsberg wrote: On Tue, Feb 26, 2013 at 8:19 AM, Topi Pohjolainen topi.pohjolai...@intel.com wrote: Namely YUV420, YVU420 (YV12) and NV12. Here one extends the shader program with instructions that sample the separate Y- and U/V-planes and convert the YUV to RGB as specified by ITU-R BT.601. Packed formats are handled through the normal paths. I didn't read the entire patch series yet, but this doesn't sound right. You can't handle packed (YUYV) buffers through normal sampling. If you're filtering, you end up blending the wrong components. If you're sampling the buffer as 32 bpp, you'll blend Y components not with their neighboring pixel but the pixel one over, as each sample has two Y components. If you sample the texture as 16bpp, you end up blending the U and V components as you sample. The trick is to set up two textures for the same buffer and sample Y using a 16 bpp texture and sample the U and V components using a 32 bpp buffer. Here the first two (YUV420, YVU420) have all the components in different planes and I'm giving each plane its own sampling surface, and hence sampling them separately as R8_UNORM. The packed UV-plane of NV12 I'm treating in turn as having two channels (sampling using R8G8_UNORM). Does that make sense? I haven't written support for anything more complex yet, but it is good to know your trick if the need arises. Right, that works for thos formats. The trick of using two samplers on the same buffer applies to YUYV buffers, ie packed format where each 32bit word contains two Y samples, one U and one V sample and corresponds to two pixels. We have surface formats, BRW_SURFACEFORMAT_YCRCB_*, for those kinds of packed formats. We use that (or used to use that) to support GL_MESA_ycbcr_texture. On GEN4+ it just doesn't do the color space conversion. I do like your trick, though. :) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 46376] render error when run glsl demo or mesa demo with X
https://bugs.freedesktop.org/show_bug.cgi?id=46376 --- Comment #6 from libo bo.c...@intel.com --- Sorry for my ambiguous explanation. only X mean that only execute command xinit but not start gnome or KDE before run the demo. for example: 1.xinit 2../gloss To the contrary, for example, 1.xinit 2.gnome 2../gloss -- 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] wl_drm: Buffer-sharing by fd-passing
This little patch series adds support for creating a __DRIimage from a prime/dma_buf fd and then uses that to add support for wl_drm buffer sharing by fd-passing. The __DRIimage patch is interesting in itself as it should enable the EGL_EXT_dmabuf_image extension that's come up a few times. Kristian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] wayland: allocate a __DRIimage for the color buffer
No functional change here, but this will let us query the image
for an fd handle later.
---
src/egl/drivers/dri2/egl_dri2.h | 3 +-
src/egl/drivers/dri2/platform_wayland.c | 57 -
2 files changed, 37 insertions(+), 23 deletions(-)
diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
index 84ea2a6..7f3ed4e 100644
--- a/src/egl/drivers/dri2/egl_dri2.h
+++ b/src/egl/drivers/dri2/egl_dri2.h
@@ -187,7 +187,8 @@ struct dri2_egl_surface
struct {
#ifdef HAVE_WAYLAND_PLATFORM
struct wl_buffer *wl_buffer;
- __DRIbuffer*dri_buffer;
+ __DRIimage *dri_image;
+ int pitch, name;
#endif
#ifdef HAVE_DRM_PLATFORM
struct gbm_bo *bo;
diff --git a/src/egl/drivers/dri2/platform_wayland.c
b/src/egl/drivers/dri2/platform_wayland.c
index 6e702ab..b5cd04a 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -204,9 +204,8 @@ dri2_destroy_surface(_EGLDriver *drv, _EGLDisplay *disp,
_EGLSurface *surf)
for (i = 0; i ARRAY_SIZE(dri2_surf-color_buffers); i++) {
if (dri2_surf-color_buffers[i].wl_buffer)
wl_buffer_destroy(dri2_surf-color_buffers[i].wl_buffer);
- if (dri2_surf-color_buffers[i].dri_buffer)
- dri2_dpy-dri2-releaseBuffer(dri2_dpy-dri_screen,
- dri2_surf-color_buffers[i].dri_buffer);
+ if (dri2_surf-color_buffers[i].dri_image)
+ dri2_dpy-image-destroyImage(dri2_surf-color_buffers[i].dri_image);
}
for (i = 0; i __DRI_BUFFER_COUNT; i++)
@@ -239,12 +238,11 @@ dri2_release_buffers(struct dri2_egl_surface *dri2_surf)
if (dri2_surf-color_buffers[i].wl_buffer
!dri2_surf-color_buffers[i].locked)
wl_buffer_destroy(dri2_surf-color_buffers[i].wl_buffer);
- if (dri2_surf-color_buffers[i].dri_buffer)
- dri2_dpy-dri2-releaseBuffer(dri2_dpy-dri_screen,
- dri2_surf-color_buffers[i].dri_buffer);
+ if (dri2_surf-color_buffers[i].dri_image)
+ dri2_dpy-image-destroyImage(dri2_surf-color_buffers[i].dri_image);
dri2_surf-color_buffers[i].wl_buffer = NULL;
- dri2_surf-color_buffers[i].dri_buffer = NULL;
+ dri2_surf-color_buffers[i].dri_image = NULL;
dri2_surf-color_buffers[i].locked = 0;
}
@@ -260,7 +258,8 @@ get_back_bo(struct dri2_egl_surface *dri2_surf, __DRIbuffer
*buffer)
{
struct dri2_egl_display *dri2_dpy =
dri2_egl_display(dri2_surf-base.Resource.Display);
- int i;
+ __DRIimage *image;
+ int i, name, pitch;
/* There might be a buffer release already queued that wasn't processed */
wl_display_dispatch_queue_pending(dri2_dpy-wl_dpy, dri2_dpy-wl_queue);
@@ -273,26 +272,41 @@ get_back_bo(struct dri2_egl_surface *dri2_surf,
__DRIbuffer *buffer)
continue;
if (dri2_surf-back == NULL)
dri2_surf-back = dri2_surf-color_buffers[i];
- else if (dri2_surf-back-dri_buffer == NULL)
+ else if (dri2_surf-back-dri_image == NULL)
dri2_surf-back = dri2_surf-color_buffers[i];
}
}
if (dri2_surf-back == NULL)
return -1;
- if (dri2_surf-back-dri_buffer == NULL) {
- dri2_surf-back-dri_buffer =
- dri2_dpy-dri2-allocateBuffer(dri2_dpy-dri_screen,
-__DRI_BUFFER_BACK_LEFT, 32,
-dri2_surf-base.Width,
-dri2_surf-base.Height);
+ if (dri2_surf-back-dri_image == NULL) {
+ dri2_surf-back-dri_image =
+ dri2_dpy-image-createImage(dri2_dpy-dri_screen,
+ dri2_surf-base.Width,
+ dri2_surf-base.Height,
+ __DRI_IMAGE_FORMAT_ARGB,
+ __DRI_IMAGE_USE_SHARE,
+ NULL);
dri2_surf-back-age = 0;
}
- if (dri2_surf-back-dri_buffer == NULL)
+ if (dri2_surf-back-dri_image == NULL)
return -1;
+ image = dri2_surf-back-dri_image;
+
+ dri2_dpy-image-queryImage(image, __DRI_IMAGE_ATTRIB_NAME, name);
+ dri2_dpy-image-queryImage(image, __DRI_IMAGE_ATTRIB_STRIDE, pitch);
+
+ dri2_surf-back-name = name;
+ dri2_surf-back-pitch = pitch;
+
+ buffer-attachment = __DRI_BUFFER_BACK_LEFT;
+ buffer-name = name;
+ buffer-pitch = pitch;
+ buffer-cpp = 4;
+ buffer-flags = 0;
+
dri2_surf-back-locked = 1;
- memcpy(buffer, dri2_surf-back-dri_buffer, sizeof *buffer);
return 0;
}
@@ -368,10 +382,9 @@ dri2_get_buffers_with_format(__DRIdrawable * driDrawable,
if (!dri2_surf-color_buffers[i].locked
dri2_surf-color_buffers[i].wl_buffer) {
wl_buffer_destroy(dri2_surf-color_buffers[i].wl_buffer);
- dri2_dpy-dri2-releaseBuffer(dri2_dpy-dri_screen,
-
[Mesa-dev] [PATCH 2/3] Add dri image entry point for creating image from fd
---
include/GL/internal/dri_interface.h| 14 +++-
src/mesa/drivers/dri/intel/intel_regions.c | 33 +++
src/mesa/drivers/dri/intel/intel_regions.h | 6
src/mesa/drivers/dri/intel/intel_screen.c | 53 --
4 files changed, 102 insertions(+), 4 deletions(-)
diff --git a/include/GL/internal/dri_interface.h
b/include/GL/internal/dri_interface.h
index 42147e9..a1392ab 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -938,7 +938,7 @@ struct __DRIdri2ExtensionRec {
* extensions.
*/
#define __DRI_IMAGE DRI_IMAGE
-#define __DRI_IMAGE_VERSION 6
+#define __DRI_IMAGE_VERSION 7
/**
* These formats correspond to the similarly named MESA_FORMAT_*
@@ -1021,6 +1021,9 @@ struct __DRIdri2ExtensionRec {
#define __DRI_IMAGE_ATTRIB_WIDTH 0x2004 /* available in versions 4+ */
#define __DRI_IMAGE_ATTRIB_HEIGHT 0x2005
#define __DRI_IMAGE_ATTRIB_COMPONENTS 0x2006 /* available in versions 5+ */
+#define __DRI_IMAGE_ATTRIB_FD 0x2007 /* available in versions
+* 7+. Each query will return a
+* new fd. */
/**
* \name Reasons that __DRIimageExtensionRec::createImageFromTexture might fail
@@ -1117,6 +1120,15 @@ struct __DRIimageExtensionRec {
int level,
unsigned *error,
void *loaderPrivate);
+ /**
+* Like createImageFromNames, but takes a prime fd instead.
+*
+* \since 7
+*/
+ __DRIimage *(*createImageFromFd)(__DRIscreen *screen,
+int width, int height, int fourcc,
+int fd, int *strides, int *offsets,
+void *loaderPrivate);
};
diff --git a/src/mesa/drivers/dri/intel/intel_regions.c
b/src/mesa/drivers/dri/intel/intel_regions.c
index 89d91b0..74f191f 100644
--- a/src/mesa/drivers/dri/intel/intel_regions.c
+++ b/src/mesa/drivers/dri/intel/intel_regions.c
@@ -284,6 +284,39 @@ intel_region_alloc_for_handle(struct intel_screen *screen,
return region;
}
+struct intel_region *
+intel_region_alloc_for_fd(struct intel_screen *screen,
+ GLuint cpp,
+ GLuint width, GLuint height, GLuint pitch,
+ int fd, const char *name)
+{
+ struct intel_region *region;
+ drm_intel_bo *buffer;
+ int ret;
+ uint32_t bit_6_swizzle, tiling;
+
+ buffer = drm_intel_bo_gem_create_from_prime(screen-bufmgr,
+ fd, height * pitch);
+ if (buffer == NULL)
+ return NULL;
+ ret = drm_intel_bo_get_tiling(buffer, tiling, bit_6_swizzle);
+ if (ret != 0) {
+ fprintf(stderr, Couldn't get tiling of buffer (%s): %s\n,
+ name, strerror(-ret));
+ drm_intel_bo_unreference(buffer);
+ return NULL;
+ }
+
+ region = intel_region_alloc_internal(screen, cpp,
+ width, height, pitch, tiling, buffer);
+ if (region == NULL) {
+ drm_intel_bo_unreference(buffer);
+ return NULL;
+ }
+
+ return region;
+}
+
void
intel_region_reference(struct intel_region **dst, struct intel_region *src)
{
diff --git a/src/mesa/drivers/dri/intel/intel_regions.h
b/src/mesa/drivers/dri/intel/intel_regions.h
index 28d581c..6757cc2 100644
--- a/src/mesa/drivers/dri/intel/intel_regions.h
+++ b/src/mesa/drivers/dri/intel/intel_regions.h
@@ -89,6 +89,12 @@ intel_region_alloc_for_handle(struct intel_screen *screen,
GLuint width, GLuint height, GLuint pitch,
unsigned int handle, const char *name);
+struct intel_region *
+intel_region_alloc_for_fd(struct intel_screen *screen,
+ GLuint cpp,
+ GLuint width, GLuint height, GLuint pitch,
+ int fd, const char *name);
+
bool
intel_region_flink(struct intel_region *region, uint32_t *name);
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
b/src/mesa/drivers/dri/intel/intel_screen.c
index 277b133..3ee0d69 100644
--- a/src/mesa/drivers/dri/intel/intel_screen.c
+++ b/src/mesa/drivers/dri/intel/intel_screen.c
@@ -546,6 +546,9 @@ intel_query_image(__DRIimage *image, int attrib, int *value)
return false;
*value = image-planar_format-components;
return true;
+ case __DRI_IMAGE_ATTRIB_FD:
+ drm_intel_bo_gem_export_to_prime(image-region-bo, value);
+ return true;
default:
return false;
}
@@ -623,8 +626,8 @@ intel_create_image_from_names(__DRIscreen *screen,
names[0], strides[0],
loaderPrivate);
-if (image == NULL)
-return NULL;
+ if (image == NULL)
+ return NULL;
[Mesa-dev] [PATCH 3/3] wayland: Add prime fd passing as a buffer sharing mechanism
---
src/egl/drivers/dri2/egl_dri2.c | 27 ---
src/egl/drivers/dri2/egl_dri2.h | 1 +
src/egl/drivers/dri2/platform_wayland.c | 69 ++---
src/egl/wayland/wayland-drm/wayland-drm.c | 40 ++---
src/egl/wayland/wayland-drm/wayland-drm.h | 7 ++-
src/egl/wayland/wayland-drm/wayland-drm.xml | 29 +++-
6 files changed, 144 insertions(+), 29 deletions(-)
diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index b774919..fc64a6c 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -320,7 +320,7 @@ static struct dri2_extension_match dri2_driver_extensions[]
= {
static struct dri2_extension_match dri2_core_extensions[] = {
{ __DRI2_FLUSH, 1, offsetof(struct dri2_egl_display, flush) },
{ __DRI_TEX_BUFFER, 2, offsetof(struct dri2_egl_display, tex_buffer) },
- { __DRI_IMAGE, 1, offsetof(struct dri2_egl_display, image) },
+ { __DRI_IMAGE, 7, offsetof(struct dri2_egl_display, image) },
{ NULL, 0, 0 }
};
@@ -1498,7 +1498,7 @@ dri2_export_drm_image_mesa(_EGLDriver *drv, _EGLDisplay
*disp, _EGLImage *img,
#ifdef HAVE_WAYLAND_PLATFORM
static void
-dri2_wl_reference_buffer(void *user_data, uint32_t name,
+dri2_wl_reference_buffer(void *user_data, uint32_t name, int fd,
struct wl_drm_buffer *buffer)
{
_EGLDisplay *disp = user_data;
@@ -1506,10 +1506,21 @@ dri2_wl_reference_buffer(void *user_data, uint32_t name,
__DRIimage *img;
int i, dri_components = 0;
- img = dri2_dpy-image-createImageFromNames(dri2_dpy-dri_screen,
+ if (fd == -1)
+ img = dri2_dpy-image-createImageFromNames(dri2_dpy-dri_screen,
+ buffer-buffer.width,
+ buffer-buffer.height,
+ buffer-format,
+ (int*)name, 1,
+ buffer-stride,
+ buffer-offset,
+ NULL);
+ else
+ img = dri2_dpy-image-createImageFromFd(dri2_dpy-dri_screen,
buffer-buffer.width,
buffer-buffer.height,
- buffer-format, (int*)name, 1,
+ buffer-format,
+ fd,
buffer-stride,
buffer-offset,
NULL);
@@ -1550,6 +1561,8 @@ dri2_bind_wayland_display_wl(_EGLDriver *drv, _EGLDisplay
*disp,
struct wl_display *wl_dpy)
{
struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
+ int ret, flags = 0;
+ uint64_t cap;
(void) drv;
@@ -1559,9 +1572,13 @@ dri2_bind_wayland_display_wl(_EGLDriver *drv,
_EGLDisplay *disp,
wl_drm_callbacks.authenticate =
(int(*)(void *, uint32_t)) dri2_dpy-authenticate;
+ ret = drmGetCap(dri2_dpy-fd, DRM_CAP_PRIME, cap);
+ if (ret == 0 cap == (DRM_PRIME_CAP_IMPORT | DRM_PRIME_CAP_EXPORT))
+ flags |= WAYLAND_DRM_PRIME;
+
dri2_dpy-wl_server_drm =
wayland_drm_init(wl_dpy, dri2_dpy-device_name,
-wl_drm_callbacks, disp);
+wl_drm_callbacks, disp, flags);
if (!dri2_dpy-wl_server_drm)
return EGL_FALSE;
diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
index 7f3ed4e..6dfdf94 100644
--- a/src/egl/drivers/dri2/egl_dri2.h
+++ b/src/egl/drivers/dri2/egl_dri2.h
@@ -132,6 +132,7 @@ struct dri2_egl_display
struct wl_event_queue*wl_queue;
int authenticated;
int formats;
+ uint32_t capabilities;
#endif
int (*authenticate) (_EGLDisplay *disp, uint32_t id);
diff --git a/src/egl/drivers/dri2/platform_wayland.c
b/src/egl/drivers/dri2/platform_wayland.c
index b5cd04a..1b42a98 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -451,6 +451,46 @@ static const struct wl_callback_listener frame_listener = {
wayland_frame_callback
};
+static void
+create_wl_buffer(struct dri2_egl_surface *dri2_surf)
+{
+ struct dri2_egl_display *dri2_dpy =
+ dri2_egl_display(dri2_surf-base.Resource.Display);
+ int fd;
+
+ if (dri2_surf-current-wl_buffer != NULL)
+ return;
+
+ if (dri2_dpy-capabilities WL_DRM_CAPABILITY_PRIME) {
+ dri2_dpy-image-queryImage(dri2_surf-current-dri_image,
+ __DRI_IMAGE_ATTRIB_FD, fd);
+
+ dri2_surf-current-wl_buffer =
+wl_drm_create_prime_buffer(dri2_dpy-wl_drm,
Re: [Mesa-dev] [RFC 12/13] i965: support for YUV formatted external textures
On Wed, Feb 27, 2013 at 8:15 PM, Ian Romanick i...@freedesktop.org wrote: On 02/27/2013 03:41 PM, Kristian Høgsberg wrote: On Wed, Feb 27, 2013 at 2:32 AM, Pohjolainen, Topi topi.pohjolai...@intel.com wrote: On Tue, Feb 26, 2013 at 12:28:14PM -0500, Kristian H?gsberg wrote: On Tue, Feb 26, 2013 at 8:19 AM, Topi Pohjolainen topi.pohjolai...@intel.com wrote: Namely YUV420, YVU420 (YV12) and NV12. Here one extends the shader program with instructions that sample the separate Y- and U/V-planes and convert the YUV to RGB as specified by ITU-R BT.601. Packed formats are handled through the normal paths. I didn't read the entire patch series yet, but this doesn't sound right. You can't handle packed (YUYV) buffers through normal sampling. If you're filtering, you end up blending the wrong components. If you're sampling the buffer as 32 bpp, you'll blend Y components not with their neighboring pixel but the pixel one over, as each sample has two Y components. If you sample the texture as 16bpp, you end up blending the U and V components as you sample. The trick is to set up two textures for the same buffer and sample Y using a 16 bpp texture and sample the U and V components using a 32 bpp buffer. Here the first two (YUV420, YVU420) have all the components in different planes and I'm giving each plane its own sampling surface, and hence sampling them separately as R8_UNORM. The packed UV-plane of NV12 I'm treating in turn as having two channels (sampling using R8G8_UNORM). Does that make sense? I haven't written support for anything more complex yet, but it is good to know your trick if the need arises. Right, that works for thos formats. The trick of using two samplers on the same buffer applies to YUYV buffers, ie packed format where each 32bit word contains two Y samples, one U and one V sample and corresponds to two pixels. We have surface formats, BRW_SURFACEFORMAT_YCRCB_*, for those kinds of packed formats. We use that (or used to use that) to support GL_MESA_ycbcr_texture. On GEN4+ it just doesn't do the color space conversion. I did see those in the spec and tried to get them to work, I just never got the right result. I didn't try very hard, but it's also not a format that our decoders generate (intel hw). Kristian I do like your trick, though. :) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] egl: Add MESA_image_sRGB extension.
On Mon, Feb 25, 2013 at 8:55 PM, Ian Romanick i...@freedesktop.org wrote: Also... are there piglit tests coming? Not unless you convince me otherwise. I don't think I'll be able to verify that said tests work however. More recent versions of the spec template include a section for describing conformance tests. This would be a good place to document piglit tests. It also helps app developers know how things should work. Where is this template? Interactions with GL_ARB_texture_view? Really, texture views seem like the right way to do this. GL_ARB_texture_view doesn't interact with EGL images at all from what I can see. What if the underlying driver doesn't support sRGB? It should just return EGL_BAD_VIEW_MESA then. Since this extension depends on KHR_image_base, the enable needs to at least depend on dri2_dpy-image. Shouldn't attrs sill be const? If Mesa does const by default, then sure. Why can't I create an sRGB view of a pixmap? It's just a reinterpretation of the bits. Because it's not implemented. I prefer not to touch code I won't even manually test after (no pixmaps in Wayland). The spec doesn't give much guidance about why the implementation may not support creating the specified gamma view. At least mentioning something in the issues section would be helpful. I could probably add something. I know the ifdef stuff is used other places, but since this comes from our own header file, I don't think it's necessary. Surrounding code had it. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
