Re: [Mesa-dev] [PATCH 2/6] i965/fs: Silence unused parameter warning
On 03/01/2015 05:19 PM, Jason Ekstrand wrote:
Not sure why you Cc'd me, but whatever. Seems obvious enough.
Because b18fd23 was your commit. Sometimes left over, unused parameters
are the result of a mistake. I just wanted to be sure.
Reviewed-by: Jason Ekstrand jason.ekstr...@intel.com
On 02/27/2015 06:50 PM, Ian Romanick wrote:
From: Ian Romanick ian.d.roman...@intel.com
Unused since b18fd23.
brw_fs.cpp:2878:44: warning: unused parameter 'dispatch_width'
[-Wunused-parameter]
clear_deps_for_inst_src(fs_inst *inst, int dispatch_width, bool *deps,
^
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
Cc: Jason Ekstrand jason.ekstr...@intel.com
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 0354f56..126b7d0 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -2875,8 +2875,7 @@ fs_visitor::remove_duplicate_mrf_writes()
}
static void
-clear_deps_for_inst_src(fs_inst *inst, int dispatch_width, bool *deps,
-int first_grf, int grf_len)
+clear_deps_for_inst_src(fs_inst *inst, bool *deps, int first_grf, int
grf_len)
{
/* Clear the flag for registers that actually got read (as
expected). */
for (int i = 0; i inst-sources; i++) {
@@ -2927,8 +2926,7 @@
fs_visitor::insert_gen4_pre_send_dependency_workarounds(bblock_t *block,
memset(needs_dep, false, sizeof(needs_dep));
memset(needs_dep, true, write_len);
- clear_deps_for_inst_src(inst, dispatch_width,
- needs_dep, first_write_grf, write_len);
+ clear_deps_for_inst_src(inst, needs_dep, first_write_grf, write_len);
/* Walk backwards looking for writes to registers we're writing
which
* aren't read since being written. If we hit the start of the
program,
@@ -2968,8 +2966,7 @@
fs_visitor::insert_gen4_pre_send_dependency_workarounds(bblock_t *block,
}
/* Clear the flag for registers that actually got read (as
expected). */
- clear_deps_for_inst_src(scan_inst, dispatch_width,
- needs_dep, first_write_grf, write_len);
+ clear_deps_for_inst_src(scan_inst, needs_dep, first_write_grf,
write_len);
/* Continue the loop only if we haven't resolved all the
dependencies */
int i;
@@ -3014,8 +3011,7 @@
fs_visitor::insert_gen4_post_send_dependency_workarounds(bblock_t
*block, fs_ins
}
/* Clear the flag for registers that actually got read (as
expected). */
- clear_deps_for_inst_src(scan_inst, dispatch_width,
- needs_dep, first_write_grf, write_len);
+ clear_deps_for_inst_src(scan_inst, needs_dep, first_write_grf,
write_len);
/* We insert our reads as late as possible since they're
reading the
* result of a SEND, which has massive latency.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glx/tests: add -I src/ to fix make check
--- src/glx/tests/Makefile.am | 1 + 1 file changed, 1 insertion(+) diff --git a/src/glx/tests/Makefile.am b/src/glx/tests/Makefile.am index dd82449..b02a9e3 100644 --- a/src/glx/tests/Makefile.am +++ b/src/glx/tests/Makefile.am @@ -2,6 +2,7 @@ if HAVE_SHARED_GLAPI AM_CFLAGS = $(PTHREAD_CFLAGS) AM_CPPFLAGS = \ -I$(top_srcdir)/src/gtest/include \ + -I$(top_srcdir)/src \ -I$(top_srcdir)/src/mapi \ -I$(top_srcdir)/src/mesa \ -I$(top_srcdir)/src/glx \ -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] common: Correct PBO 2D_ARRAY handling.
The Meta PBO upload path does not exist in 10.4, so we don't need to worry about a backport. On Tue, Mar 3, 2015 at 6:01 PM, Emil Velikov emil.l.veli...@gmail.com wrote: On 24 February 2015 at 23:20, Laura Ekstrand la...@jlekstrand.net wrote: Changes PBO uploads and downloads to use a tall (height * depth) 2D texture for blitting. This fixes the bug where 2D_ARRAY, 3D, and CUBE_MAP_ARRAY textures are not properly uploaded and downloaded. Removes the option to use a 2D ARRAY texture for the PBO during upload and download. This option didn't work because the miptree couldn't be set up reliably. v2: Review from Jason Ekstrand and Neil Roberts: -Delete the depth parameter from create_texture_for_pbo -Abandon the option to create a 2D ARRAY texture in create_texture_for_pbo --- src/mesa/drivers/common/meta_tex_subimage.c | 26 +- 1 file changed, 17 insertions(+), 9 deletions(-) diff --git a/src/mesa/drivers/common/meta_tex_subimage.c b/src/mesa/drivers/common/meta_tex_subimage.c index 2d2b9d8..b659426 100644 --- a/src/mesa/drivers/common/meta_tex_subimage.c +++ b/src/mesa/drivers/common/meta_tex_subimage.c @@ -44,7 +44,7 @@ static struct gl_texture_image * create_texture_for_pbo(struct gl_context *ctx, bool create_pbo, - GLenum pbo_target, int width, int height, int depth, + GLenum pbo_target, int width, int height, GLenum format, GLenum type, const void *pixels, const struct gl_pixelstore_attrib *packing, GLuint *tmp_pbo, GLuint *tmp_tex) @@ -57,8 +57,7 @@ create_texture_for_pbo(struct gl_context *ctx, bool create_pbo, struct gl_texture_image *tex_image; bool read_only; - if ((packing-ImageHeight != 0 packing-ImageHeight != height) || - packing-SwapBytes || + if (packing-SwapBytes || packing-LsbFirst || packing-Invert) return NULL; @@ -99,7 +98,6 @@ create_texture_for_pbo(struct gl_context *ctx, bool create_pbo, _mesa_GenTextures(1, tmp_tex); tex_obj = _mesa_lookup_texture(ctx, *tmp_tex); - tex_obj-Target = depth 1 ? GL_TEXTURE_2D_ARRAY : GL_TEXTURE_2D; _mesa_initialize_texture_object(ctx, tex_obj, *tmp_tex, GL_TEXTURE_2D); /* This must be set after _mesa_initialize_texture_object, not before. */ tex_obj-Immutable = GL_TRUE; @@ -109,7 +107,7 @@ create_texture_for_pbo(struct gl_context *ctx, bool create_pbo, internal_format = _mesa_get_format_base_format(pbo_format); tex_image = _mesa_get_tex_image(ctx, tex_obj, tex_obj-Target, 0); - _mesa_init_teximage_fields(ctx, tex_image, width, height, depth, + _mesa_init_teximage_fields(ctx, tex_image, width, height, 1, 0, internal_format, pbo_format); read_only = pbo_target == GL_PIXEL_UNPACK_BUFFER; @@ -169,9 +167,14 @@ _mesa_meta_pbo_TexSubImage(struct gl_context *ctx, GLuint dims, return true; } + /* Only accept tightly packed pixels from the user. */ + if (packing-ImageHeight != 0 packing-ImageHeight != height) + return false; + + /* For arrays, use a tall (height * depth) 2D texture. */ pbo_tex_image = create_texture_for_pbo(ctx, create_pbo, GL_PIXEL_UNPACK_BUFFER, - width, height, depth, + width, height * depth, format, type, pixels, packing, pbo, pbo_tex); if (!pbo_tex_image) @@ -225,7 +228,7 @@ _mesa_meta_pbo_TexSubImage(struct gl_context *ctx, GLuint dims, _mesa_update_state(ctx); _mesa_meta_BlitFramebuffer(ctx, ctx-ReadBuffer, ctx-DrawBuffer, - 0, 0, width, height, + 0, z * height, width, (z + 1) * height, xoffset, yoffset, xoffset + width, yoffset + height, GL_COLOR_BUFFER_BIT, GL_NEAREST); @@ -285,8 +288,13 @@ _mesa_meta_pbo_GetTexSubImage(struct gl_context *ctx, GLuint dims, return true; } + /* Only accept tightly packed pixels from the user. */ + if (packing-ImageHeight != 0 packing-ImageHeight != height) + return false; + + /* For arrays, use a tall (height * depth) 2D texture. */ pbo_tex_image = create_texture_for_pbo(ctx, false, GL_PIXEL_PACK_BUFFER, - width, height, depth, + width, height * depth, format, type, pixels, packing, pbo, pbo_tex); if (!pbo_tex_image) @@ -347,7 +355,7
[Mesa-dev] [PATCH 3/3] meta: Fix the y offset for 1D_ARRAY in _mesa_meta_pbo_TexSubImage
The yoffset needs to be interpreted as a slice offset for 1D array
textures. This patch implements that by moving the yoffset into
zoffset similar to how it moves the height into depth.
---
src/mesa/drivers/common/meta_tex_subimage.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/mesa/drivers/common/meta_tex_subimage.c
b/src/mesa/drivers/common/meta_tex_subimage.c
index f360d64..e29addb 100644
--- a/src/mesa/drivers/common/meta_tex_subimage.c
+++ b/src/mesa/drivers/common/meta_tex_subimage.c
@@ -205,8 +205,12 @@ _mesa_meta_pbo_TexSubImage(struct gl_context *ctx, GLuint
dims,
if (tex_image-TexObject-Target == GL_TEXTURE_1D_ARRAY) {
assert(depth == 1);
+ assert(zoffset == 0);
depth = height;
height = 1;
+ image_height = 1;
+ zoffset = yoffset;
+ yoffset = 0;
}
_mesa_meta_bind_fbo_image(GL_READ_FRAMEBUFFER, GL_COLOR_ATTACHMENT0,
@@ -322,8 +326,12 @@ _mesa_meta_pbo_GetTexSubImage(struct gl_context *ctx,
GLuint dims,
if (tex_image tex_image-TexObject-Target == GL_TEXTURE_1D_ARRAY) {
assert(depth == 1);
+ assert(zoffset == 0);
depth = height;
height = 1;
+ image_height = 1;
+ zoffset = yoffset;
+ yoffset = 0;
}
/* If we were given a texture, bind it to the read framebuffer. If not,
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Throttle rendering to an fbo
On 02/26/2015 05:24 AM, Chris Wilson wrote:
When rendering to an fbo, even though it may be acting as a winsys
frontbuffer or just generally, we never throttle. However, when rendering
to an fbo, there is no natural frame boundary. Conventionally we use
SwapBuffers and glFinish, but potential callers avoid often glFinish for
being too heavy handed (waiting on all outstanding rendering to complete).
The kernel provides a soft-throttling option for this case that waits for
rendering older than 20ms to be complete (that's a little too lax to be
used for swapbuffers, but is here a useful safety net). The remaining
choice is then either never to throttle, throttle after every draw call,
or at an intermediate user defined point such as glFlush and thus all the
implied flushes. This patch opts for the latter.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Kenneth Graunke kenn...@whitecape.org
Cc: Ben Widawsky b...@bwidawsk.net
Cc: Kristian Høgsberg k...@bitplanet.net
---
src/mesa/drivers/dri/i965/brw_context.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index c844888..f190df1 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -229,11 +229,14 @@ static void
intel_glFlush(struct gl_context *ctx)
{
struct brw_context *brw = brw_context(ctx);
+ __DRIscreen *psp = brw-intelScreen-driScrnPriv;
intel_batchbuffer_flush(brw);
intel_flush_front(ctx);
if (brw_is_front_buffer_drawing(ctx-DrawBuffer))
brw-need_throttle = true;
+
+ drmCommandNone(psp-fd, DRM_I915_GEM_THROTTLE);
}
static void
glFlush should not wait for previous rendering to complete. It's not supposed
to be a blocking operation.
Why this patch? What are you trying to fix?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Throttle rendering to an fbo
On Wed, Mar 04, 2015 at 09:41:56AM -0800, Chad Versace wrote:
On 02/26/2015 05:24 AM, Chris Wilson wrote:
When rendering to an fbo, even though it may be acting as a winsys
frontbuffer or just generally, we never throttle. However, when rendering
to an fbo, there is no natural frame boundary. Conventionally we use
SwapBuffers and glFinish, but potential callers avoid often glFinish for
being too heavy handed (waiting on all outstanding rendering to complete).
The kernel provides a soft-throttling option for this case that waits for
rendering older than 20ms to be complete (that's a little too lax to be
used for swapbuffers, but is here a useful safety net). The remaining
choice is then either never to throttle, throttle after every draw call,
or at an intermediate user defined point such as glFlush and thus all the
implied flushes. This patch opts for the latter.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Kenneth Graunke kenn...@whitecape.org
Cc: Ben Widawsky b...@bwidawsk.net
Cc: Kristian Høgsberg k...@bitplanet.net
---
src/mesa/drivers/dri/i965/brw_context.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index c844888..f190df1 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -229,11 +229,14 @@ static void
intel_glFlush(struct gl_context *ctx)
{
struct brw_context *brw = brw_context(ctx);
+ __DRIscreen *psp = brw-intelScreen-driScrnPriv;
intel_batchbuffer_flush(brw);
intel_flush_front(ctx);
if (brw_is_front_buffer_drawing(ctx-DrawBuffer))
brw-need_throttle = true;
+
+ drmCommandNone(psp-fd, DRM_I915_GEM_THROTTLE);
}
static void
glFlush should not wait for previous rendering to complete. It's not supposed
to be a blocking operation.
The manpage for glFlush says
glFlush can return at any time. It does not wait until the execution of *all*
previously issued GL commands is complete.
Emphasis mine. In double buffered, and normal frontbuffered (non-fbo),
rendering the throttle is a no-op as there will not be any old rendering
to wait upon.
Why this patch? What are you trying to fix?
http://patchwork.freedesktop.org/patch/43432/
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glx/tests: add -I src/ to fix make check
Right. -Brian On 03/04/2015 10:56 AM, Ian Romanick wrote: Due to 0339e7db, right? If so, Reviewed-by: Ian Romanick ian.d.roman...@intel.com On 03/04/2015 09:03 AM, Brian Paul wrote: --- src/glx/tests/Makefile.am | 1 + 1 file changed, 1 insertion(+) diff --git a/src/glx/tests/Makefile.am b/src/glx/tests/Makefile.am index dd82449..b02a9e3 100644 --- a/src/glx/tests/Makefile.am +++ b/src/glx/tests/Makefile.am @@ -2,6 +2,7 @@ if HAVE_SHARED_GLAPI AM_CFLAGS = $(PTHREAD_CFLAGS) AM_CPPFLAGS = \ -I$(top_srcdir)/src/gtest/include \ + -I$(top_srcdir)/src \ -I$(top_srcdir)/src/mapi \ -I$(top_srcdir)/src/mesa \ -I$(top_srcdir)/src/glx \ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] clover: Enable cl_khr_fp64 for devices that support doubles v4
v2:
- Report correct values for CL_DEVICE_NATIVE_VECTOR_WIDTH_DOUBLE
and CL_DEVICE_PREFERRED_VECTOR_WIDTH_DOUBLE.
- Only define cl_khr_fp64 if the extension is supported.
- Remove trailing space from extension string.
- Rename device query function from cl_khr_fp86() to
has_doubles().
v3:
- Return 0 for device::doubled_fp_confg() when doubles aren't
supported.
v4:
- Remove device query for double fp_config.
---
src/gallium/state_trackers/clover/api/device.cpp | 21 ++---
src/gallium/state_trackers/clover/core/device.cpp | 6 ++
src/gallium/state_trackers/clover/core/device.hpp | 1 +
3 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/src/gallium/state_trackers/clover/api/device.cpp
b/src/gallium/state_trackers/clover/api/device.cpp
index e825468..b1f556f 100644
--- a/src/gallium/state_trackers/clover/api/device.cpp
+++ b/src/gallium/state_trackers/clover/api/device.cpp
@@ -145,7 +145,7 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info param,
break;
case CL_DEVICE_PREFERRED_VECTOR_WIDTH_DOUBLE:
- buf.as_scalarcl_uint() = 2;
+ buf.as_scalarcl_uint() = dev.has_doubles() ? 2 : 0;
break;
case CL_DEVICE_PREFERRED_VECTOR_WIDTH_HALF:
@@ -205,6 +205,21 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info param,
CL_FP_DENORM | CL_FP_INF_NAN | CL_FP_ROUND_TO_NEAREST;
break;
+ case CL_DEVICE_DOUBLE_FP_CONFIG:
+ if (dev.has_doubles())
+ // This is the mandated minimum double precision floating-point
+ // capability
+ buf.as_scalarcl_device_fp_config() =
+ CL_FP_FMA
+ | CL_FP_ROUND_TO_NEAREST
+ | CL_FP_ROUND_TO_ZERO
+ | CL_FP_ROUND_TO_INF
+ | CL_FP_INF_NAN
+ | CL_FP_DENORM;
+ else
+ buf.as_scalarcl_device_fp_config() = 0;
+ break;
+
case CL_DEVICE_GLOBAL_MEM_CACHE_TYPE:
buf.as_scalarcl_device_mem_cache_type() = CL_NONE;
break;
@@ -283,7 +298,7 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info param,
break;
case CL_DEVICE_EXTENSIONS:
- buf.as_string() = ;
+ buf.as_string() = dev.has_doubles() ? cl_khr_fp64 : ;
break;
case CL_DEVICE_PLATFORM:
@@ -315,7 +330,7 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info param,
break;
case CL_DEVICE_NATIVE_VECTOR_WIDTH_DOUBLE:
- buf.as_scalarcl_uint() = 2;
+ buf.as_scalarcl_uint() = dev.has_doubles() ? 2 : 0;
break;
case CL_DEVICE_NATIVE_VECTOR_WIDTH_HALF:
diff --git a/src/gallium/state_trackers/clover/core/device.cpp
b/src/gallium/state_trackers/clover/core/device.cpp
index 688a7dd..c3f3b4e 100644
--- a/src/gallium/state_trackers/clover/core/device.cpp
+++ b/src/gallium/state_trackers/clover/core/device.cpp
@@ -173,6 +173,12 @@ device::image_support() const {
PIPE_COMPUTE_CAP_IMAGES_SUPPORTED)[0];
}
+bool
+device::has_doubles() const {
+ return pipe-get_shader_param(pipe, PIPE_SHADER_COMPUTE,
+ PIPE_SHADER_CAP_DOUBLES);
+}
+
std::vectorsize_t
device::max_block_size() const {
auto v = get_compute_paramuint64_t(pipe, PIPE_COMPUTE_CAP_MAX_BLOCK_SIZE);
diff --git a/src/gallium/state_trackers/clover/core/device.hpp
b/src/gallium/state_trackers/clover/core/device.hpp
index 2201700..de5fc6b 100644
--- a/src/gallium/state_trackers/clover/core/device.hpp
+++ b/src/gallium/state_trackers/clover/core/device.hpp
@@ -64,6 +64,7 @@ namespace clover {
cl_uint max_clock_frequency() const;
cl_uint max_compute_units() const;
bool image_support() const;
+ bool has_doubles() const;
std::vectorsize_t max_block_size() const;
std::string device_name() const;
--
2.0.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2] i965/skl: Disable SIMD16 when 3-source instructions are used
Steppings C0 and D0 of Skylake fail when using SIMD16 with 3-source
instructions (such as MAD). This patch just makes it disable SIMD16 in
those cases.
This implements WaDisableSIMD16On3SrcInstr and fixes ~190 Piglit
tests.
v2: Also apply on stepping D0
---
Damien Lespiau pointed out that the workaround also needs to be
applied on stepping D0.
src/mesa/drivers/dri/i965/brw_fs.cpp | 22 ++
src/mesa/drivers/dri/i965/brw_fs.h | 1 +
2 files changed, 23 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 533feb4..b61208b 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -3729,6 +3729,27 @@ fs_visitor::fixup_3src_null_dest()
}
}
+/**
+ * 3-source instructions don't work on Skylake steppings C0 and D0. If the
+ * revision isn't known then it will take the safe option and disable it in
+ * case it's one of those. Implements WaDisableSIMD16On3SrcInstr.
+ */
+void
+fs_visitor::disable_simd16_with_3src()
+{
+ if (brw-gen != 9 ||
+ (brw-revision != 2 brw-revision != 3 brw-revision != -1))
+ return;
+
+ foreach_block_and_inst_safe (block, fs_inst, inst, cfg) {
+ if (inst-is_3src()) {
+ no16(SIMD16 doesn't work with 3-source instructions on
+ Gen9 steppings C0 and D0\n);
+ return;
+ }
+ }
+}
+
void
fs_visitor::allocate_registers()
{
@@ -3910,6 +3931,7 @@ fs_visitor::run_fs()
assign_urb_setup();
fixup_3src_null_dest();
+ disable_simd16_with_3src();
allocate_registers();
if (failed)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.h
b/src/mesa/drivers/dri/i965/brw_fs.h
index 70098d8..7091b9f 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.h
+++ b/src/mesa/drivers/dri/i965/brw_fs.h
@@ -196,6 +196,7 @@ public:
void setup_payload_gen6();
void setup_vs_payload();
void fixup_3src_null_dest();
+ void disable_simd16_with_3src();
void assign_curb_setup();
void calculate_urb_setup();
void assign_urb_setup();
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallivm: init MM = NULL to silence warning
Hi Brian,
Did you try to `make check` in mesa with these patches?
I get errors compiling glx-test:
src/glx/glxclient.h:59:25: fatal error: util/macros.h: No such file or
directory
-Mark
Brian Paul bri...@vmware.com writes:
---
src/gallium/auxiliary/gallivm/lp_bld_misc.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
index 5210acc..e2578cf 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
+++ b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
@@ -493,7 +493,7 @@
lp_build_create_jit_compiler_for_module(LLVMExecutionEngineRef *OutJIT,
builder.setMCPU(MCPU);
#endif
- ShaderMemoryManager *MM;
+ ShaderMemoryManager *MM = NULL;
if (useMCJIT) {
#if HAVE_LLVM 0x0303
BaseMemoryManager* JMM = reinterpret_castBaseMemoryManager*(CMM);
--
1.9.1
___
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/2] i965: Store the GPU revision number in brw_context
On Wed, Mar 4, 2015 at 6:32 AM, Neil Roberts n...@linux.intel.com wrote:
brwContextInit now queries the GPU revision number via a new parameter
for DRM_I915_GETPARAM. This new parameter requires a kernel patch and
a patch to libdrm. If the kernel doesn't support it then it will
continue but set the revision number to -1. The intention is to use
this to implement workarounds that are only needed on certain
steppings of the GPU.
Reviewed-by: Kristian Høgsberg k...@bitplanet.net
---
configure.ac| 2 +-
src/mesa/drivers/dri/i965/brw_context.c | 19 +++
src/mesa/drivers/dri/i965/brw_context.h | 4
3 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index c5abbfd..23ac927 100644
--- a/configure.ac
+++ b/configure.ac
@@ -61,7 +61,7 @@ AC_SUBST([OSMESA_VERSION])
dnl Versions for external dependencies
LIBDRM_REQUIRED=2.4.38
LIBDRM_RADEON_REQUIRED=2.4.56
-LIBDRM_INTEL_REQUIRED=2.4.52
+LIBDRM_INTEL_REQUIRED=2.4.59
LIBDRM_NVVIEUX_REQUIRED=2.4.33
LIBDRM_NOUVEAU_REQUIRED=2.4.33 libdrm = 2.4.41
LIBDRM_FREEDRENO_REQUIRED=2.4.57
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index 786e6f5..18f72d8 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -651,6 +651,24 @@ brw_process_driconf_options(struct brw_context *brw)
driQueryOptionb(options, allow_glsl_extension_directive_midshader);
}
+static int
+brw_get_revision(int fd)
+{
+ struct drm_i915_getparam gp;
+ int revision;
+ int ret;
+
+ memset(gp, 0, sizeof(gp));
+ gp.param = I915_PARAM_REVISION;
+ gp.value = revision;
+
+ ret = drmCommandWriteRead(fd, DRM_I915_GETPARAM, gp, sizeof(gp));
+ if (ret)
+ revision = -1;
+
+ return revision;
+}
+
GLboolean
brwCreateContext(gl_api api,
const struct gl_config *mesaVis,
@@ -709,6 +727,7 @@ brwCreateContext(gl_api api,
brw-has_negative_rhw_bug = devinfo-has_negative_rhw_bug;
brw-needs_unlit_centroid_workaround =
devinfo-needs_unlit_centroid_workaround;
+ brw-revision = brw_get_revision(sPriv-fd);
brw-must_use_separate_stencil = screen-hw_must_use_separate_stencil;
brw-has_swizzling = screen-hw_has_swizzling;
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index 682fbe9..10e8274 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1064,6 +1064,10 @@ struct brw_context
int gen;
int gt;
+ /* GT revision. This will be -1 if the revision couldn't be determined
(eg,
+* if the kernel doesn't support the query).
+*/
+ int revision;
bool is_g4x;
bool is_baytrail;
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 6/6] i965: Don't write past the end of the application supplied buffer
From: Ian Romanick ian.d.roman...@intel.com
Both the AMD and Intel APIs provide a dataSize parameter, and this
function would merrily ignore it. Neither API specifies what to do when
the buffer isn't big enough. I take the easy route of writing all the
complete bits of data that will fit. With more complete specs, we could
probably do something different.
I noticed this while looking into an unused parameter warning. The
warning was actually useful!
brw_performance_monitor.c: In function 'brw_get_perf_monitor_result':
brw_performance_monitor.c:1261:37: warning: unused parameter 'data_size'
[-Wunused-parameter]
GLsizei data_size,
^
v2: Fix checks to include offset in the calculation. Noticed by Jan.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
Cc: Kenneth Graunke kenn...@whitecape.org
Cc: Jan Vesely jan.ves...@rutgers.edu
---
src/mesa/drivers/dri/i965/brw_performance_monitor.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_performance_monitor.c
b/src/mesa/drivers/dri/i965/brw_performance_monitor.c
index 6c31d4c..2c8cd49 100644
--- a/src/mesa/drivers/dri/i965/brw_performance_monitor.c
+++ b/src/mesa/drivers/dri/i965/brw_performance_monitor.c
@@ -1264,6 +1264,7 @@ brw_get_perf_monitor_result(struct gl_context *ctx,
{
struct brw_context *brw = brw_context(ctx);
struct brw_perf_monitor_object *monitor = brw_perf_monitor(m);
+ const GLuint *const data_end = (GLuint *)((uint8_t *) data + data_size);
DBG(GetResult(%d)\n, m-Name);
brw_dump_perf_monitors(brw);
@@ -1309,9 +1310,11 @@ brw_get_perf_monitor_result(struct gl_context *ctx,
if (counter 0 || !BITSET_TEST(m-ActiveCounters[group], counter))
continue;
- data[offset++] = group;
- data[offset++] = counter;
- data[offset++] = monitor-oa_results[i];
+ if (data + offset + 3 = data_end) {
+data[offset++] = group;
+data[offset++] = counter;
+data[offset++] = monitor-oa_results[i];
+ }
}
clean_bookend_bo(brw);
@@ -1335,10 +1338,12 @@ brw_get_perf_monitor_result(struct gl_context *ctx,
for (int i = 0; i num_counters; i++) {
if (BITSET_TEST(m-ActiveCounters[PIPELINE_STATS_COUNTERS], i)) {
-data[offset++] = PIPELINE_STATS_COUNTERS;
-data[offset++] = i;
-*((uint64_t *) (data[offset])) =
monitor-pipeline_stats_results[i];
-offset += 2;
+if (data + offset + 4 = data_end) {
+ data[offset++] = PIPELINE_STATS_COUNTERS;
+ data[offset++] = i;
+ *((uint64_t *) (data[offset])) =
monitor-pipeline_stats_results[i];
+ offset += 2;
+}
}
}
}
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] meta: Allow GL_UN/PACK_IMAGE_HEIGHT in _mesa_meta_pbo_Get/TexSubImage
Now that a layered source PBO is interpreted as a single tall 2D image
it's quite easy to accept the image height packing option by just
creating an image that is tall enough to include the image padding.
I'm not sure whether the image height property should affect 1D_ARRAY
textures. My intuition and interpretation of the GL spec (which is a
bit vague) would be that it shouldn't. However the software fallback
path in Mesa uses the property for packing but not for unpacking. The
binary NVidia driver uses it for both. This patch doesn't use it for
either case so it is different from the software fallback. There is
some discussion about this here:
http://lists.freedesktop.org/archives/mesa-dev/2015-February/077925.html
This is tested by the texsubimage Piglit test with the array and pbo
arguments. Previously this test was skipping this code path because it
always sets the image height.
I've also tested it by modifying the getteximage-targets test. It
wasn't using this code path before because it was using the default
texture object so this code couldn't successfully create a frame
buffer. I also modified it to add some image padding with the image
height in the PBO.
---
src/mesa/drivers/common/meta_tex_subimage.c | 32 ++---
1 file changed, 20 insertions(+), 12 deletions(-)
diff --git a/src/mesa/drivers/common/meta_tex_subimage.c
b/src/mesa/drivers/common/meta_tex_subimage.c
index 1fef79d..f360d64 100644
--- a/src/mesa/drivers/common/meta_tex_subimage.c
+++ b/src/mesa/drivers/common/meta_tex_subimage.c
@@ -144,6 +144,7 @@ _mesa_meta_pbo_TexSubImage(struct gl_context *ctx, GLuint
dims,
const struct gl_pixelstore_attrib *packing)
{
GLuint pbo = 0, pbo_tex = 0, fbos[2] = { 0, 0 };
+ int full_height, image_height;
struct gl_texture_image *pbo_tex_image;
GLenum status;
bool success = false;
@@ -177,14 +178,16 @@ _mesa_meta_pbo_TexSubImage(struct gl_context *ctx, GLuint
dims,
return true;
}
- /* Only accept tightly packed pixels from the user. */
- if (packing-ImageHeight != 0 packing-ImageHeight != height)
- return false;
+ /* For arrays, use a tall (height * depth) 2D texture but taking into
+* account the inter-image padding specified with the image height packing
+* property.
+*/
+ image_height = packing-ImageHeight == 0 ? height : packing-ImageHeight;
+ full_height = image_height * (depth - 1) + height;
- /* For arrays, use a tall (height * depth) 2D texture. */
pbo_tex_image = create_texture_for_pbo(ctx, create_pbo,
GL_PIXEL_UNPACK_BUFFER,
- width, height * depth,
+ width, full_height,
format, type, pixels, packing,
pbo, pbo_tex);
if (!pbo_tex_image)
@@ -236,7 +239,8 @@ _mesa_meta_pbo_TexSubImage(struct gl_context *ctx, GLuint
dims,
_mesa_update_state(ctx);
_mesa_meta_BlitFramebuffer(ctx, ctx-ReadBuffer, ctx-DrawBuffer,
- 0, z * height, width, (z + 1) * height,
+ 0, z * image_height,
+ width, z * image_height + height,
xoffset, yoffset,
xoffset + width, yoffset + height,
GL_COLOR_BUFFER_BIT, GL_NEAREST);
@@ -263,6 +267,7 @@ _mesa_meta_pbo_GetTexSubImage(struct gl_context *ctx,
GLuint dims,
const struct gl_pixelstore_attrib *packing)
{
GLuint pbo = 0, pbo_tex = 0, fbos[2] = { 0, 0 };
+ int full_height, image_height;
struct gl_texture_image *pbo_tex_image;
GLenum status;
bool success = false;
@@ -296,13 +301,15 @@ _mesa_meta_pbo_GetTexSubImage(struct gl_context *ctx,
GLuint dims,
return true;
}
- /* Only accept tightly packed pixels from the user. */
- if (packing-ImageHeight != 0 packing-ImageHeight != height)
- return false;
+ /* For arrays, use a tall (height * depth) 2D texture but taking into
+* account the inter-image padding specified with the image height packing
+* property.
+*/
+ image_height = packing-ImageHeight == 0 ? height : packing-ImageHeight;
+ full_height = image_height * (depth - 1) + height;
- /* For arrays, use a tall (height * depth) 2D texture. */
pbo_tex_image = create_texture_for_pbo(ctx, false, GL_PIXEL_PACK_BUFFER,
- width, height * depth,
+ width, full_height * depth,
format, type, pixels, packing,
pbo, pbo_tex);
if (!pbo_tex_image)
@@ -361,7 +368,8 @@ _mesa_meta_pbo_GetTexSubImage(struct gl_context *ctx,
GLuint dims,
_mesa_meta_BlitFramebuffer(ctx,
Re: [Mesa-dev] [PATCH] glx/tests: add -I src/ to fix make check
Due to 0339e7db, right? If so, Reviewed-by: Ian Romanick ian.d.roman...@intel.com On 03/04/2015 09:03 AM, Brian Paul wrote: --- src/glx/tests/Makefile.am | 1 + 1 file changed, 1 insertion(+) diff --git a/src/glx/tests/Makefile.am b/src/glx/tests/Makefile.am index dd82449..b02a9e3 100644 --- a/src/glx/tests/Makefile.am +++ b/src/glx/tests/Makefile.am @@ -2,6 +2,7 @@ if HAVE_SHARED_GLAPI AM_CFLAGS = $(PTHREAD_CFLAGS) AM_CPPFLAGS = \ -I$(top_srcdir)/src/gtest/include \ + -I$(top_srcdir)/src \ -I$(top_srcdir)/src/mapi \ -I$(top_srcdir)/src/mesa \ -I$(top_srcdir)/src/glx \ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] nesa-10.4.4: gallivm/lp_bld_misc.cpp:503:38: error: no viable conversion from 'ShaderMemoryManager *' to 'std::unique_ptrRTDyldMemoryManager'
Am 04.03.2015 um 12:38 schrieb Jose Fonseca: On 04/03/15 02:00, Emil Velikov wrote: On 27 February 2015 at 23:28, Sedat Dilek sedat.di...@gmail.com wrote: On Mon, Feb 9, 2015 at 6:30 PM, Emil Velikov emil.l.veli...@gmail.com wrote: On 07/02/15 21:44, Sedat Dilek wrote: Hi, I was building mesa v10.4.4 with my llvm-toolchain v3.6.0rc2. My build breaks like this... ... Please cherry-pick... commit ef7e0b39a24966526b102643523feac765771842 gallivm: Update for RTDyldMemoryManager becoming an unique_ptr. ..for mesa 10.4 Git branch. Hi Sedat, Picking a fix in a stable branch against a non-final release sounds like a no-go in our books. As the official llvm 3.6 rolls out we'll pick this fix for the stable branches - until then I would recommend (a) applying it locally or (b) using mesa from the 10.5 or master branch. Just FYI... [LLVMdev] LLVM 3.6 Release (see [1]). Please pick this patch for-10.4, thanks. As promised, mesa 10.4.6 will feature this. But is cross-porting this patch enough? As I said when this first issue was raised fixing the build with LLVM 3.6 is just half of the problem. It must also _run_ correctly. And building correctly doesn't necessarily means it will run correctly. That is, unless somebody actually ensures that all LLVM 3.6 related fixes have been crossported and that things run correctly, it is misleading to enable the build of Mesa 10.4.6 with LLVM 3.6. I don't know about radeon drivers, but at least from llvmpipe POV I simply don't have the time to do this (go through every LLVM 3.6 related patch, ensure they are all in 10.4.6, and test). I quickly went through the diffs between 10.4 branch, and found one such commit is missing: http://cgit.freedesktop.org/mesa/mesa/commit/?id=74f505fa73eda0c9b5b1984bebb44cedac8e8794 https://bugs.freedesktop.org/show_bug.cgi?id=85467 But there might be more, and I don't know if crossporting this is safe or not. Therefore my stance for is that building Mesa stable releases with LLVM releases after the Mesa release was branched is still unsupported. If people want to do so, they will do at their own peril. And any incoming bugs will be unsupported, use Mesa. If having a Mesa release capable of building LLVM 3.6 is so important, I think it might be easier/safer to just make a new release from a recent enough commit, than trying to backport it. This is quite right, the above commit is a must if you want to build with llvm 3.6. I am quite sure crossport should be safe (it missed the branch point of 10.4 just narrowly), and I don't think there's any other patches missing, but no guarantees... I think it is sort of unfortunate that the latest mesa release wouldn't run with the latest llvm release, but the fact remains that without testing this sounds all a bit risky... Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/6] i965: Silence unused parameter warning
On 02/28/2015 10:33 AM, Ilia Mirkin wrote: On Sat, Feb 28, 2015 at 1:26 PM, Carl Worth cwo...@cworth.org wrote: On Fri, Feb 27 2015, Ian Romanick wrote: All dd functions take a gl_context as the first parameter. Instead of removing it, just silence the warning. For code using gcc, I really prefer the __attribute__((__unused__)) style, (though, obviously hidden in a reasonable looking macro). That results in cleaner looking code than these weird unused expressions being cast to void. Another clean alternative is to leave the name of the variable out, i.e. function(struct gl_context *) instead of function(struct gl_context *foo) I use that method a lot because it makes the intention very obvious, but, as others have mentioned, it's only available in C++. Does MSVC have an equivalent? Or, does it not emit the warning in the first place such that we could just define the macro as empty outside of gcc? So there's room for investigation here. In the meantime: Reviewed-by: Carl Worth cwo...@cworth.org -Carl ___ 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] mapi: fix build after 8aa9191878a5608fc6e4e8c72bea1d25cd821dec
Brian also sent this patch, and I sent his a R-b because I saw it first. :) On 03/04/2015 09:49 AM, Mark Janes wrote: Due to recent #include changes, `make check` fails on glx-test. The target requires a standard include path to find util/macros.h. --- src/glx/tests/Makefile.am | 1 + 1 file changed, 1 insertion(+) diff --git a/src/glx/tests/Makefile.am b/src/glx/tests/Makefile.am index dd82449..4db01c0 100644 --- a/src/glx/tests/Makefile.am +++ b/src/glx/tests/Makefile.am @@ -1,6 +1,7 @@ if HAVE_SHARED_GLAPI AM_CFLAGS = $(PTHREAD_CFLAGS) AM_CPPFLAGS = \ + -I$(top_srcdir)/src \ -I$(top_srcdir)/src/gtest/include \ -I$(top_srcdir)/src/mapi \ -I$(top_srcdir)/src/mesa \ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] i965/skl: Disable SIMD16 when 3-source instructions are used
On Wed, Mar 4, 2015 at 9:20 AM, Neil Roberts n...@linux.intel.com wrote:
Steppings C0 and D0 of Skylake fail when using SIMD16 with 3-source
instructions (such as MAD). This patch just makes it disable SIMD16 in
those cases.
This implements WaDisableSIMD16On3SrcInstr and fixes ~190 Piglit
tests.
v2: Also apply on stepping D0
---
Damien Lespiau pointed out that the workaround also needs to be
applied on stepping D0.
src/mesa/drivers/dri/i965/brw_fs.cpp | 22 ++
src/mesa/drivers/dri/i965/brw_fs.h | 1 +
2 files changed, 23 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 533feb4..b61208b 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -3729,6 +3729,27 @@ fs_visitor::fixup_3src_null_dest()
}
}
+/**
+ * 3-source instructions don't work on Skylake steppings C0 and D0. If the
+ * revision isn't known then it will take the safe option and disable it in
+ * case it's one of those. Implements WaDisableSIMD16On3SrcInstr.
+ */
+void
+fs_visitor::disable_simd16_with_3src()
+{
+ if (brw-gen != 9 ||
+ (brw-revision != 2 brw-revision != 3 brw-revision != -1))
+ return;
+
+ foreach_block_and_inst_safe (block, fs_inst, inst, cfg) {
+ if (inst-is_3src()) {
+ no16(SIMD16 doesn't work with 3-source instructions on
+ Gen9 steppings C0 and D0\n);
+ return;
+ }
+ }
+}
+
void
fs_visitor::allocate_registers()
{
@@ -3910,6 +3931,7 @@ fs_visitor::run_fs()
assign_urb_setup();
fixup_3src_null_dest();
+ disable_simd16_with_3src();
We need this in run_vs() too, right?
Kristian
allocate_registers();
if (failed)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.h
b/src/mesa/drivers/dri/i965/brw_fs.h
index 70098d8..7091b9f 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.h
+++ b/src/mesa/drivers/dri/i965/brw_fs.h
@@ -196,6 +196,7 @@ public:
void setup_payload_gen6();
void setup_vs_payload();
void fixup_3src_null_dest();
+ void disable_simd16_with_3src();
void assign_curb_setup();
void calculate_urb_setup();
void assign_urb_setup();
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/6] main: Refactor Tex[ture]Buffer[Range].
On Fri, Feb 27, 2015 at 4:07 PM, Laura Ekstrand la...@jlekstrand.net wrote:
Uses _mesa_lookup_bufferobj_err to clean up buffer object retrieval. Moves
error checking statements into separate functions to allow code sharing
between traditional and ARB_direct_state_access entry points.
It's little difficult to follow the changes in this patch. I think the patch
can be split in to two:
Patch 1: Use _mesa_lookup_bufferobj_err to clean up buffer object retrieval.
Patch 2: Use helper functions for error checking in
_mesa_Tex{ture}Buffer{Range}
---
src/mesa/main/teximage.c | 201
++-
src/mesa/main/teximage.h | 6 +-
2 files changed, 132 insertions(+), 75 deletions(-)
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index d454dd9..9853bc0 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -5301,24 +5301,34 @@ _mesa_validate_texbuffer_format(const struct
gl_context *ctx,
void
_mesa_texture_buffer_range(struct gl_context *ctx,
- struct gl_texture_object *texObj, GLenum target,
+ struct gl_texture_object *texObj,
GLenum internalFormat,
struct gl_buffer_object *bufObj,
- GLintptr offset, GLsizeiptr size, bool range,
- bool dsa)
+ GLintptr offset, GLsizeiptr size,
+ const char *caller)
{
mesa_format format;
- FLUSH_VERTICES(ctx, 0);
+ /* NOTE: ARB_texture_buffer_object has interactions with
+* the compatibility profile that are not implemented.
+*/
+ if (!(ctx-API == API_OPENGL_CORE
+ ctx-Extensions.ARB_texture_buffer_object)) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ %s(ARB_texture_buffer_object is not
+ implemented for the compatibility profile), caller);
+ return;
+ }
format = _mesa_validate_texbuffer_format(ctx, internalFormat);
if (format == MESA_FORMAT_NONE) {
_mesa_error(ctx, GL_INVALID_ENUM,
- glTex%sBuffer%s(internalFormat 0x%x), dsa ? ture : ,
- range ? Range : , internalFormat);
+ %s(internalFormat 0x%x), caller, internalFormat);
return;
}
+ FLUSH_VERTICES(ctx, 0);
+
_mesa_lock_texture(ctx, texObj);
{
_mesa_reference_buffer_object(ctx, texObj-BufferObject, bufObj);
@@ -5337,6 +5347,75 @@ _mesa_texture_buffer_range(struct gl_context *ctx,
}
+/**
+ * Make sure the texture buffer target is GL_TEXTURE_BUFFER.
+ * Return true if it is, and return false if it is not
+ * (and throw INVALID ENUM as dictated in the OpenGL 4.5
+ * core spec, 02.02.2015, PDF page 245).
+ */
+static bool
+check_texture_buffer_target(struct gl_context *ctx, GLenum target,
+const char *caller)
+{
+ if (target != GL_TEXTURE_BUFFER_ARB) {
+ _mesa_error(ctx, GL_INVALID_ENUM,
+ %s(texture target is not GL_TEXTURE_BUFFER), caller);
+ return false;
+ }
+ else
else on the same line as curly brace.
+ return true;
+}
+
+/**
+ * Check for errors related to the texture buffer range.
+ * Return false if errors are found, true if none are found.
+ */
+static bool
+check_texture_buffer_range(struct gl_context *ctx,
+ struct gl_buffer_object *bufObj,
+ GLintptr offset, GLsizeiptr size,
+ const char *caller)
+{
+ /* OpenGL 4.5 core spec (02.02.2015) says in Section 8.9 Buffer
+* Textures (PDF page 245):
+*An INVALID_VALUE error is generated if offset is negative, if
+*size is less than or equal to zero, or if offset + size is greater
+*than the value of BUFFER_SIZE for the buffer bound to target.
+*/
+ if (offset 0) {
+ _mesa_error(ctx, GL_INVALID_VALUE, %s(offset=%d 0), caller,
+ (int) offset);
+ return false;
+ }
+
+ if (size = 0) {
+ _mesa_error(ctx, GL_INVALID_VALUE, %s(size=%d = 0), caller,
+ (int) size);
+ return false;
+ }
+
+ if (offset + size bufObj-Size) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ %s(offset=%d + size=%d buffer_size=%d), caller,
+ (int) offset, (int) size, (int) bufObj-Size);
+ return false;
+ }
+
+ /* OpenGL 4.5 core spec (02.02.2015) says in Section 8.9 Buffer
+* Textures (PDF page 245):
+*An INVALID_VALUE error is generated if offset is not an integer
+*multiple of the value of TEXTURE_BUFFER_OFFSET_ALIGNMENT.
+*/
+ if (offset % ctx-Const.TextureBufferOffsetAlignment) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ %s(invalid offset alignment), caller);
+ return false;
+ }
+
+ return true;
+}
+
+
Re: [Mesa-dev] [PATCH 4/6] main: Add utility function _mesa_lookup_bufferobj_err.
On Tue, Mar 3, 2015 at 5:39 PM, Laura Ekstrand la...@jlekstrand.net wrote:
I also need it in teximage.c for Texture Buffer objects.
Right. That's just one file in this series. Mention it in the commit
message If you're aware of future use of this function in multiple
files.
On Tue, Mar 3, 2015 at 5:24 PM, Fredrik Höglund fred...@kde.org wrote:
On Wednesday 04 March 2015, Anuj Phogat wrote:
On Fri, Feb 27, 2015 at 4:07 PM, Laura Ekstrand la...@jlekstrand.net
wrote:
---
src/mesa/main/bufferobj.c | 19 +++
src/mesa/main/bufferobj.h | 4
2 files changed, 23 insertions(+)
diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index f026fc3..617242b 100644
--- a/src/mesa/main/bufferobj.c
+++ b/src/mesa/main/bufferobj.c
@@ -1006,6 +1006,25 @@ _mesa_lookup_bufferobj_locked(struct gl_context
*ctx, GLuint buffer)
_mesa_HashLookupLocked(ctx-Shared-BufferObjects, buffer);
}
+/**
+ * A convenience function for direct state access functions that
throws
+ * GL_INVALID_OPERATION if buffer is not the name of a buffer object
in the
+ * hash table.
+ */
+struct gl_buffer_object *
+_mesa_lookup_bufferobj_err(struct gl_context *ctx, GLuint buffer,
+ const char *caller)
+{
+ struct gl_buffer_object *bufObj;
+
+ bufObj = _mesa_lookup_bufferobj(ctx, buffer);
+ if (!bufObj)
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ %s(non-generated buffer name %u), caller,
buffer);
+
+ return bufObj;
+}
+
void
_mesa_begin_bufferobj_lookups(struct gl_context *ctx)
diff --git a/src/mesa/main/bufferobj.h b/src/mesa/main/bufferobj.h
index fe294fc..8e53bfd 100644
--- a/src/mesa/main/bufferobj.h
+++ b/src/mesa/main/bufferobj.h
@@ -89,6 +89,10 @@ _mesa_lookup_bufferobj(struct gl_context *ctx,
GLuint buffer);
extern struct gl_buffer_object *
_mesa_lookup_bufferobj_locked(struct gl_context *ctx, GLuint buffer);
+extern struct gl_buffer_object *
+_mesa_lookup_bufferobj_err(struct gl_context *ctx, GLuint buffer,
+ const char *caller);
+
This function is used just inside teximage.c in patch 5/6. So, it can be
made
static.
No, I'm using it in arrayobj.c in my arb-direct-state-access branch.
extern void
_mesa_begin_bufferobj_lookups(struct gl_context *ctx);
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Throttle rendering to an fbo
On Wed, Mar 04, 2015 at 10:28:16AM -0800, Chad Versace wrote: On 03/04/2015 09:52 AM, Chris Wilson wrote: The manpage for glFlush says glFlush can return at any time. It does not wait until the execution of *all* previously issued GL commands is complete. Emphasis mine. In double buffered, and normal frontbuffered (non-fbo), rendering the throttle is a no-op as there will not be any old rendering to wait upon. That text does not appear in the GL spec. When I read the manpage alongside the GL spec, to get a more complete context, I think the manpage contains that phrase simply to contrast with glFinish. In my reading, it does not imply that glFlush may wait for *some* previously issued GL commands to complete. As usual, the GL spec is too terse and too vague. So I quote Apple's GL documentation [1]. I believe it correctly explains the behavior of glFlush. Q: What's the difference between glFlush() and glFinish()? A: [...] glFlush() causes all OpenGL commands currently queued to be submitted to the hardware for execution. This function returns immediately after having transferred the pending OpenGL command queue to the hardware (or software) renderer. These commands are queued for execution in some finite amount of time, but glFlush() does not block waiting for command completion. [1] https://developer.apple.com/library/mac/qa/qa1158/_index.html And I don't agree that the throttle is a no-op in double-buffered rendering. Consider the following calls: 0 // Setup the draw. 1 glDraw(); 2 eglSwapBuffers(); -- internally calls glFlush 3 // Setup the draw 4 glDraw(); 5 eglSwapBuffers(); -- internally calls glFlush 6 // Setup the draw 7 glDraw(); 8 eglSwapBuffers(); -- internally calls glFlush Before your patch, call 5 returns immediately, even if draw 1 has not completed, allowing the app to proceed to the CPU actions in line 6. If the app calls eglSwapBuffers too frequently, then call 8 will block as needed (assuming EGL_SWAP_INTERVAL != 0 and double-buffering). Today steps 3, 6, 9... block due to brw-need_throttle (intel_prepare_render can occur before a draw operation). If double buffering and swap-interval!=0, then step 2 (naively, for us it would be step 3) would block. If triple buffering step 5/6, except for the brw-need_throttle already causing throttling. After your patch, call 5 may block, throttling on batches that may have been submitted during the setup in lines 3 and 4. (The glDraw at 4 may submit batches for resolve operations, for example). That prevents the app from proceeding to whatever CPU actions are planned for line 6. Double-buffered eglSwapBuffers now sometimes blocks, behaving like an almost-glFinish, even when the back buffer is free for rendering. No, actually it won't block in that situation. It only waits for rendering older than 20ms to complete, which given that your back buffer is free for rendering must have already completed. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Throttle rendering to an fbo
On 03/04/2015 09:52 AM, Chris Wilson wrote:
On Wed, Mar 04, 2015 at 09:41:56AM -0800, Chad Versace wrote:
On 02/26/2015 05:24 AM, Chris Wilson wrote:
When rendering to an fbo, even though it may be acting as a winsys
frontbuffer or just generally, we never throttle. However, when rendering
to an fbo, there is no natural frame boundary. Conventionally we use
SwapBuffers and glFinish, but potential callers avoid often glFinish for
being too heavy handed (waiting on all outstanding rendering to complete).
The kernel provides a soft-throttling option for this case that waits for
rendering older than 20ms to be complete (that's a little too lax to be
used for swapbuffers, but is here a useful safety net). The remaining
choice is then either never to throttle, throttle after every draw call,
or at an intermediate user defined point such as glFlush and thus all the
implied flushes. This patch opts for the latter.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Kenneth Graunke kenn...@whitecape.org
Cc: Ben Widawsky b...@bwidawsk.net
Cc: Kristian Høgsberg k...@bitplanet.net
---
src/mesa/drivers/dri/i965/brw_context.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index c844888..f190df1 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -229,11 +229,14 @@ static void
intel_glFlush(struct gl_context *ctx)
{
struct brw_context *brw = brw_context(ctx);
+ __DRIscreen *psp = brw-intelScreen-driScrnPriv;
intel_batchbuffer_flush(brw);
intel_flush_front(ctx);
if (brw_is_front_buffer_drawing(ctx-DrawBuffer))
brw-need_throttle = true;
+
+ drmCommandNone(psp-fd, DRM_I915_GEM_THROTTLE);
}
static void
glFlush should not wait for previous rendering to complete. It's not supposed
to be a blocking operation.
The manpage for glFlush says
glFlush can return at any time. It does not wait until the execution of
*all*
previously issued GL commands is complete.
Emphasis mine. In double buffered, and normal frontbuffered (non-fbo),
rendering the throttle is a no-op as there will not be any old rendering
to wait upon.
That text does not appear in the GL spec. When I read the manpage alongside
the GL spec, to get a more complete context, I think the manpage contains
that phrase simply to contrast with glFinish. In my reading, it does not imply
that
glFlush may wait for *some* previously issued GL commands to complete.
As usual, the GL spec is too terse and too vague. So I quote Apple's GL
documentation [1].
I believe it correctly explains the behavior of glFlush.
Q: What's the difference between glFlush() and glFinish()?
A: [...] glFlush() causes all OpenGL commands currently queued to be
submitted to
the hardware for execution. This function returns immediately after
having
transferred the pending OpenGL command queue to the hardware (or
software)
renderer. These commands are queued for execution in some finite amount
of time,
but glFlush() does not block waiting for command completion.
[1] https://developer.apple.com/library/mac/qa/qa1158/_index.html
And I don't agree that the throttle is a no-op in double-buffered rendering.
Consider
the following calls:
0 // Setup the draw.
1 glDraw();
2 eglSwapBuffers(); -- internally calls glFlush
3 // Setup the draw
4 glDraw();
5 eglSwapBuffers(); -- internally calls glFlush
6 // Setup the draw
7 glDraw();
8 eglSwapBuffers(); -- internally calls glFlush
Before your patch, call 5 returns immediately, even if draw 1 has not
completed, allowing the app to proceed to the CPU actions in line 6.
If the app calls eglSwapBuffers too frequently, then call 8 will block
as needed (assuming EGL_SWAP_INTERVAL != 0 and double-buffering).
After your patch, call 5 may block, throttling on batches that may have been
submitted during the setup in lines 3 and 4. (The glDraw at 4 may submit
batches for
resolve operations, for example). That prevents the app from proceeding
to whatever CPU actions are planned for line 6. Double-buffered eglSwapBuffers
now
sometimes blocks, behaving like an almost-glFinish, even when the back buffer is
free for rendering.
Why this patch? What are you trying to fix?
http://patchwork.freedesktop.org/patch/43432/
A valid bug. But I'm not convinced this Mesa patch is correct.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mapi: fix build after 8aa9191878a5608fc6e4e8c72bea1d25cd821dec
Reviewed-by: Jose Fonseca jfons...@vmware.com On 04/03/15 17:49, Mark Janes wrote: Due to recent #include changes, `make check` fails on glx-test. The target requires a standard include path to find util/macros.h. --- src/glx/tests/Makefile.am | 1 + 1 file changed, 1 insertion(+) diff --git a/src/glx/tests/Makefile.am b/src/glx/tests/Makefile.am index dd82449..4db01c0 100644 --- a/src/glx/tests/Makefile.am +++ b/src/glx/tests/Makefile.am @@ -1,6 +1,7 @@ if HAVE_SHARED_GLAPI AM_CFLAGS = $(PTHREAD_CFLAGS) AM_CPPFLAGS = \ + -I$(top_srcdir)/src \ -I$(top_srcdir)/src/gtest/include \ -I$(top_srcdir)/src/mapi \ -I$(top_srcdir)/src/mesa \ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] include: Add helper header to help trap includes inside extern C.
Jose Fonseca jfons...@vmware.com writes:
From: José Fonseca jfons...@vmware.com
This is just to help repro and fixing these issues with any C++ compiler --
commiting this will of course wait until all issues are addressed.
Hi Jose,
I have a patch which trivially fixes extern C in the 14 files
identified by no_extern_c.h errors.
Should I send the patch? This helper header was sent a long time ago,
but it seems like a useful mechanism to me.
-Mark
$ scons src/glsl/
scons: Reading SConscript files ...
Checking for GCC ... yes
Checking for Clang ... no
Checking for X11 (x11 xext xdamage xfixes glproto = 1.4.13)... yes
Checking for XCB (x11-xcb xcb-glx = 1.8.1 xcb-dri2 = 1.8)... yes
Checking for XF86VIDMODE (xxf86vm)... yes
Checking for DRM (libdrm = 2.4.38)... yes
Checking for UDEV (libudev = 151)... yes
warning: LLVM disabled: not building llvmpipe
scons: done reading SConscript files.
scons: Building targets ...
scons: building associated VariantDir targets: build/linux-x86_64-debug/glsl
Compiling src/glsl/ast_array_index.cpp ...
Compiling src/glsl/ast_expr.cpp ...
Compiling src/glsl/ast_function.cpp ...
Compiling src/glsl/ast_to_hir.cpp ...
Compiling src/glsl/ast_type.cpp ...
Compiling src/glsl/builtin_functions.cpp ...
In file included from include/c99_compat.h:28:0,
from src/mapi/u_compiler.h:4,
from src/mapi/u_thread.h:47,
from src/mapi/glapi/glapi.h:47,
from src/mesa/main/mtypes.h:42,
from src/mesa/main/errors.h:47,
from src/mesa/main/imports.h:41,
from src/mesa/main/core.h:44,
from src/glsl/builtin_functions.cpp:58:
include/no_extern_c.h:48:1: error: template with C linkage
templateclass T class _IncludeInsideExternCNotPortable;
^
In file included from include/c99_compat.h:28:0,
from include/c11/threads.h:38,
from src/mapi/u_thread.h:49,
from src/mapi/glapi/glapi.h:47,
from src/mesa/main/mtypes.h:42,
from src/mesa/main/errors.h:47,
from src/mesa/main/imports.h:41,
from src/mesa/main/core.h:44,
from src/glsl/builtin_functions.cpp:58:
include/no_extern_c.h:48:1: error: template with C linkage
templateclass T class _IncludeInsideExternCNotPortable;
^
Compiling src/glsl/builtin_types.cpp ...
Compiling src/glsl/builtin_variables.cpp ...
scons: *** [build/linux-x86_64-debug/glsl/builtin_functions.os] Error 1
scons: building terminated because of errors.
---
include/c99_compat.h | 2 ++
include/no_extern_c.h | 49 +
src/util/u_atomic.h | 3 +++
3 files changed, 54 insertions(+)
create mode 100644 include/no_extern_c.h
diff --git a/include/c99_compat.h b/include/c99_compat.h
index 429c601..a8819ac 100644
--- a/include/c99_compat.h
+++ b/include/c99_compat.h
@@ -25,6 +25,8 @@
*
**/
+#include no_extern_c.h
+
#ifndef _C99_COMPAT_H_
#define _C99_COMPAT_H_
diff --git a/include/no_extern_c.h b/include/no_extern_c.h
new file mode 100644
index 000..d038a4f
--- /dev/null
+++ b/include/no_extern_c.h
@@ -0,0 +1,49 @@
+/**
+ *
+ * Copyright 2014 VMware, Inc.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included
+ * in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ **/
+
+
+/*
+ * Including system's headers inside `extern C { ... }` is not safe, as
system
+ * headers may have C++ code in them, and C++ code inside extern C
+ * leads to syntatically incorrect code.
+ *
+ * This is because putting code inside extern C won't make __cplusplus
Re: [Mesa-dev] [PATCH 1/2] i965: Refactor SIMD16-to-2xSIMD8 checks.
On Wed, Mar 4, 2015 at 12:53 PM, Kenneth Graunke kenn...@whitecape.org wrote: Gathering all the checks into a single place makes it easier to add new workarounds. Signed-off-by: Kenneth Graunke kenn...@whitecape.org Cc: Neil Roberts n...@linux.intel.com Cc: Matt Turner matts...@gmail.com --- src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 28 +-- src/mesa/drivers/dri/i965/brw_shader.cpp | 48 ++ src/mesa/drivers/dri/i965/brw_shader.h | 1 + 3 files changed, 58 insertions(+), 19 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp index cbe6191..8a5ad9b 100644 --- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp +++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp @@ -1613,6 +1613,9 @@ fs_generator::generate_code(const cfg_t *cfg, int dispatch_width) unreachable(!Invalid instruction width); } + bool must_break_down_simd16_to_simd8 = dispatch_width == 16 + !brw_instruction_supports_simd16(brw, inst-opcode); Instead of calling this for every instruction we emit, can we just put it in the existing if-statements we're modifying below? With that, Reviewed-by: Matt Turner matts...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/6] i965/fs: Silence unused parameter warning
On Wed, Mar 4, 2015 at 8:45 AM, Ian Romanick i...@freedesktop.org wrote:
On 03/01/2015 05:19 PM, Jason Ekstrand wrote:
Not sure why you Cc'd me, but whatever. Seems obvious enough.
Because b18fd23 was your commit. Sometimes left over, unused parameters
are the result of a mistake. I just wanted to be sure.
Right... Sorry, it's been a while and I forgot I touched those functions.
That said, it makes sense that b18fd23 would have. Sorry for the noise
--Jason
Reviewed-by: Jason Ekstrand jason.ekstr...@intel.com
On 02/27/2015 06:50 PM, Ian Romanick wrote:
From: Ian Romanick ian.d.roman...@intel.com
Unused since b18fd23.
brw_fs.cpp:2878:44: warning: unused parameter 'dispatch_width'
[-Wunused-parameter]
clear_deps_for_inst_src(fs_inst *inst, int dispatch_width, bool *deps,
^
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
Cc: Jason Ekstrand jason.ekstr...@intel.com
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 0354f56..126b7d0 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -2875,8 +2875,7 @@ fs_visitor::remove_duplicate_mrf_writes()
}
static void
-clear_deps_for_inst_src(fs_inst *inst, int dispatch_width, bool *deps,
-int first_grf, int grf_len)
+clear_deps_for_inst_src(fs_inst *inst, bool *deps, int first_grf, int
grf_len)
{
/* Clear the flag for registers that actually got read (as
expected). */
for (int i = 0; i inst-sources; i++) {
@@ -2927,8 +2926,7 @@
fs_visitor::insert_gen4_pre_send_dependency_workarounds(bblock_t *block,
memset(needs_dep, false, sizeof(needs_dep));
memset(needs_dep, true, write_len);
- clear_deps_for_inst_src(inst, dispatch_width,
- needs_dep, first_write_grf, write_len);
+ clear_deps_for_inst_src(inst, needs_dep, first_write_grf,
write_len);
/* Walk backwards looking for writes to registers we're writing
which
* aren't read since being written. If we hit the start of the
program,
@@ -2968,8 +2966,7 @@
fs_visitor::insert_gen4_pre_send_dependency_workarounds(bblock_t *block,
}
/* Clear the flag for registers that actually got read (as
expected). */
- clear_deps_for_inst_src(scan_inst, dispatch_width,
- needs_dep, first_write_grf, write_len);
+ clear_deps_for_inst_src(scan_inst, needs_dep, first_write_grf,
write_len);
/* Continue the loop only if we haven't resolved all the
dependencies */
int i;
@@ -3014,8 +3011,7 @@
fs_visitor::insert_gen4_post_send_dependency_workarounds(bblock_t
*block, fs_ins
}
/* Clear the flag for registers that actually got read (as
expected). */
- clear_deps_for_inst_src(scan_inst, dispatch_width,
- needs_dep, first_write_grf, write_len);
+ clear_deps_for_inst_src(scan_inst, needs_dep, first_write_grf,
write_len);
/* We insert our reads as late as possible since they're
reading the
* result of a SEND, which has massive latency.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] i965: Refactor SIMD16-to-2xSIMD8 checks.
Gathering all the checks into a single place makes it easier to add new
workarounds.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
Cc: Neil Roberts n...@linux.intel.com
Cc: Matt Turner matts...@gmail.com
---
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 28 +--
src/mesa/drivers/dri/i965/brw_shader.cpp | 48 ++
src/mesa/drivers/dri/i965/brw_shader.h | 1 +
3 files changed, 58 insertions(+), 19 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
index cbe6191..8a5ad9b 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
@@ -1613,6 +1613,9 @@ fs_generator::generate_code(const cfg_t *cfg, int
dispatch_width)
unreachable(!Invalid instruction width);
}
+ bool must_break_down_simd16_to_simd8 = dispatch_width == 16
+ !brw_instruction_supports_simd16(brw, inst-opcode);
+
switch (inst-opcode) {
case BRW_OPCODE_MOV:
brw_MOV(p, dst, src[0]);
@@ -1637,7 +1640,7 @@ fs_generator::generate_code(const cfg_t *cfg, int
dispatch_width)
case BRW_OPCODE_MAD:
assert(brw-gen = 6);
brw_set_default_access_mode(p, BRW_ALIGN_16);
- if (dispatch_width == 16 brw-gen 8 !brw-is_haswell) {
+ if (must_break_down_simd16_to_simd8) {
brw_set_default_compression_control(p, BRW_COMPRESSION_NONE);
brw_inst *f = brw_MAD(p, firsthalf(dst), firsthalf(src[0]),
firsthalf(src[1]), firsthalf(src[2]));
brw_set_default_compression_control(p, BRW_COMPRESSION_2NDHALF);
@@ -1658,7 +1661,7 @@ fs_generator::generate_code(const cfg_t *cfg, int
dispatch_width)
case BRW_OPCODE_LRP:
assert(brw-gen = 6);
brw_set_default_access_mode(p, BRW_ALIGN_16);
- if (dispatch_width == 16 brw-gen 8 !brw-is_haswell) {
+ if (must_break_down_simd16_to_simd8) {
brw_set_default_compression_control(p, BRW_COMPRESSION_NONE);
brw_inst *f = brw_LRP(p, firsthalf(dst), firsthalf(src[0]),
firsthalf(src[1]), firsthalf(src[2]));
brw_set_default_compression_control(p, BRW_COMPRESSION_2NDHALF);
@@ -1730,7 +1733,7 @@ fs_generator::generate_code(const cfg_t *cfg, int
dispatch_width)
* coissuing would affect CMP instructions not otherwise affected by
* the errata.
*/
- if (dispatch_width == 16 brw-gen == 7 !brw-is_haswell) {
+ if (must_break_down_simd16_to_simd8) {
if (dst.file == BRW_GENERAL_REGISTER_FILE) {
brw_set_default_compression_control(p, BRW_COMPRESSION_NONE);
brw_CMP(p, firsthalf(dst), inst-conditional_mod,
@@ -1795,7 +1798,7 @@ fs_generator::generate_code(const cfg_t *cfg, int
dispatch_width)
case BRW_OPCODE_BFE:
assert(brw-gen = 7);
brw_set_default_access_mode(p, BRW_ALIGN_16);
- if (dispatch_width == 16 brw-gen 8 !brw-is_haswell) {
+ if (must_break_down_simd16_to_simd8) {
brw_set_default_compression_control(p, BRW_COMPRESSION_NONE);
brw_BFE(p, firsthalf(dst), firsthalf(src[0]), firsthalf(src[1]),
firsthalf(src[2]));
brw_set_default_compression_control(p, BRW_COMPRESSION_2NDHALF);
@@ -1809,12 +1812,7 @@ fs_generator::generate_code(const cfg_t *cfg, int
dispatch_width)
case BRW_OPCODE_BFI1:
assert(brw-gen = 7);
- /* The Haswell WaForceSIMD8ForBFIInstruction workaround says that we
- * should
- *
- *Force BFI instructions to be executed always in SIMD8.
- */
- if (dispatch_width == 16 brw-is_haswell) {
+ if (must_break_down_simd16_to_simd8) {
brw_set_default_compression_control(p, BRW_COMPRESSION_NONE);
brw_BFI1(p, firsthalf(dst), firsthalf(src[0]), firsthalf(src[1]));
brw_set_default_compression_control(p, BRW_COMPRESSION_2NDHALF);
@@ -1827,15 +1825,7 @@ fs_generator::generate_code(const cfg_t *cfg, int
dispatch_width)
case BRW_OPCODE_BFI2:
assert(brw-gen = 7);
brw_set_default_access_mode(p, BRW_ALIGN_16);
- /* The Haswell WaForceSIMD8ForBFIInstruction workaround says that we
- * should
- *
- *Force BFI instructions to be executed always in SIMD8.
- *
- * Otherwise we would be able to emit compressed instructions like we
- * do for the other three-source instructions.
- */
- if (dispatch_width == 16 brw-gen 8) {
+ if (must_break_down_simd16_to_simd8) {
brw_set_default_compression_control(p, BRW_COMPRESSION_NONE);
brw_BFI2(p, firsthalf(dst), firsthalf(src[0]), firsthalf(src[1]),
firsthalf(src[2]));
brw_set_default_compression_control(p, BRW_COMPRESSION_2NDHALF);
diff --git
[Mesa-dev] [PATCH 2/2] i965/skl: Break down SIMD16 3-source instructions when required.
Several steppings of Skylake fail when using SIMD16 with 3-source
instructions (such as MAD).
This implements WaDisableSIMD16On3SrcInstr and fixes ~190 Piglit
tests.
Based on a patch by Neil Roberts.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
Cc: Neil Roberts n...@linux.intel.com
Cc: Matt Turner matts...@gmail.com
---
src/mesa/drivers/dri/i965/brw_shader.cpp | 6 ++
1 file changed, 6 insertions(+)
Neil, what do you think of this approach? It's a bit smaller of a hammer
than turning off SIMD16 altogether, and pretty simple. I haven't tested
it at all, though.
Feel free to --reset-author and claim authorship on this patch - it's
really your code, I just moved it over a bit.
diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp
b/src/mesa/drivers/dri/i965/brw_shader.cpp
index fed4ba3..74c0e50 100644
--- a/src/mesa/drivers/dri/i965/brw_shader.cpp
+++ b/src/mesa/drivers/dri/i965/brw_shader.cpp
@@ -400,6 +400,12 @@ bool
brw_instruction_supports_simd16(const struct brw_context *brw, enum opcode op)
{
bool supports_3src = brw-is_haswell || brw-gen = 8;
+ /* WaDisableSIMD16On3SrcInstr: 3-source instructions don't work in SIMD16
+* on a few steppings of Skylake.
+*/
+ if (brw-gen == 9 (brw-revision == 2 || brw-revision == 3 ||
+ brw-revision == -1))
+ supports_3src = false;
switch (op) {
case BRW_OPCODE_MAD:
--
2.2.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] i965/skl: Break down SIMD16 3-source instructions when required.
On Wed, Mar 4, 2015 at 12:53 PM, Kenneth Graunke kenn...@whitecape.org wrote:
Several steppings of Skylake fail when using SIMD16 with 3-source
instructions (such as MAD).
This implements WaDisableSIMD16On3SrcInstr and fixes ~190 Piglit
tests.
Based on a patch by Neil Roberts.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
Cc: Neil Roberts n...@linux.intel.com
Cc: Matt Turner matts...@gmail.com
---
src/mesa/drivers/dri/i965/brw_shader.cpp | 6 ++
1 file changed, 6 insertions(+)
Neil, what do you think of this approach? It's a bit smaller of a hammer
than turning off SIMD16 altogether, and pretty simple. I haven't tested
it at all, though.
Feel free to --reset-author and claim authorship on this patch - it's
really your code, I just moved it over a bit.
diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp
b/src/mesa/drivers/dri/i965/brw_shader.cpp
index fed4ba3..74c0e50 100644
--- a/src/mesa/drivers/dri/i965/brw_shader.cpp
+++ b/src/mesa/drivers/dri/i965/brw_shader.cpp
@@ -400,6 +400,12 @@ bool
brw_instruction_supports_simd16(const struct brw_context *brw, enum opcode
op)
{
bool supports_3src = brw-is_haswell || brw-gen = 8;
Newline here before the comment?
+ /* WaDisableSIMD16On3SrcInstr: 3-source instructions don't work in SIMD16
+* on a few steppings of Skylake.
+*/
+ if (brw-gen == 9 (brw-revision == 2 || brw-revision == 3 ||
+ brw-revision == -1))
+ supports_3src = false;
I don't have any idea about the actual functional change. I'll leave
that for someone working on Skylake.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] clover: Enable cl_khr_fp64 for devices that support doubles v4
On Wed, Mar 4, 2015 at 7:47 AM, Tom Stellard thomas.stell...@amd.com wrote: v2: - Report correct values for CL_DEVICE_NATIVE_VECTOR_WIDTH_DOUBLE and CL_DEVICE_PREFERRED_VECTOR_WIDTH_DOUBLE. - Only define cl_khr_fp64 if the extension is supported. - Remove trailing space from extension string. - Rename device query function from cl_khr_fp86() to Fingers were off-by-two: s/86/64/ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] i965/skl: Disable SIMD16 when 3-source instructions are used
On Wed, Mar 4, 2015 at 6:33 AM, Neil Roberts n...@linux.intel.com wrote: Stepping C0 of Skylake fails when using SIMD16 with 3-source instructions (such as MAD). This patch just makes it disable SIMD16 in that case. This implements WaDisableSIMD16On3SrcInstr and fixes ~190 Piglit tests. --- We already have code in brw_fs_generator.cpp to split SIMD16 instructions into 2x SIMD8 for all of the three-source instructions we support (MAD, LRP, BFE, BFI2). Is there some reason you can't just enable that for these particular Skylake steppings? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa/st: remove unused TexData
this isn't hooked up to anything at all from what I can see.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/mesa/state_tracker/st_cb_texture.c | 21 -
src/mesa/state_tracker/st_texture.h| 6 --
2 files changed, 27 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_texture.c
b/src/mesa/state_tracker/st_cb_texture.c
index 0525e87..6b72680 100644
--- a/src/mesa/state_tracker/st_cb_texture.c
+++ b/src/mesa/state_tracker/st_cb_texture.c
@@ -177,9 +177,6 @@ st_FreeTextureImageBuffer(struct gl_context *ctx,
pipe_resource_reference(stImage-pt, NULL);
}
- _mesa_align_free(stImage-TexData);
- stImage-TexData = NULL;
-
free(stImage-transfer);
stImage-transfer = NULL;
stImage-num_transfers = 0;
@@ -500,7 +497,6 @@ st_AllocTextureImageBuffer(struct gl_context *ctx,
DBG(%s\n, __FUNCTION__);
- assert(!stImage-TexData);
assert(!stImage-pt); /* xxx this might be wrong */
/* Look if the parent texture object has space for this image */
@@ -1520,23 +1516,6 @@ copy_image_data_to_texture(struct st_context *st,
pipe_resource_reference(stImage-pt, NULL);
}
- else if (stImage-TexData) {
- /* Copy from malloc'd memory */
- /* XXX this should be re-examined/tested with a compressed format */
- GLuint blockSize = util_format_get_blocksize(stObj-pt-format);
- GLuint srcRowStride = stImage-base.Width * blockSize;
- GLuint srcSliceStride = stImage-base.Height * srcRowStride;
- st_texture_image_data(st,
-stObj-pt,
-stImage-base.Face,
-dstLevel,
-stImage-TexData,
-srcRowStride,
-srcSliceStride);
- _mesa_align_free(stImage-TexData);
- stImage-TexData = NULL;
- }
-
pipe_resource_reference(stImage-pt, stObj-pt);
}
diff --git a/src/mesa/state_tracker/st_texture.h
b/src/mesa/state_tracker/st_texture.h
index 6b7f8c7..3fa55ae 100644
--- a/src/mesa/state_tracker/st_texture.h
+++ b/src/mesa/state_tracker/st_texture.h
@@ -55,13 +55,7 @@ struct st_texture_image
{
struct gl_texture_image base;
- /** Used to store texture data that doesn't fit in the parent
-* object's mipmap buffer.
-*/
- GLubyte *TexData;
-
/* If stImage-pt != NULL, image data is stored here.
-* Else if stImage-TexData != NULL, image is stored there.
* Else there is no image data.
*/
struct pipe_resource *pt;
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/6] v2 of Compressed Textures Cube Map Support
This cleans up ARB_direct_state_access texture cube map functions (mostly in response to reviews from Anuj Phogat). Laura Ekstrand (6): main: _mesa_cube_level_complete checks NumLayers. main: Remove redundant NumLayers checks. main: Remove redundant copy of cube map block comment in GetTextureImage. main: assert(texImage) in ARB_DSA texture cube map functions. main: Add TEXTURE_CUBE_MAP support for glCompressedTextureSubImage3D. main: Checking for cube completeness in GetCompressedTextureImage. src/mesa/main/texgetimage.c | 61 --- src/mesa/main/teximage.c| 177 +--- src/mesa/main/teximage.h| 3 +- src/mesa/main/texobj.c | 4 + 4 files changed, 156 insertions(+), 89 deletions(-) -- 2.1.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 6/6] main: Checking for cube completeness in GetCompressedTextureImage.
v2: Review from Anuj Phogat
- Remove redundant copies of the cube map block comment
- Replace redundant if (!texImage) return; statements with
assert(texImage)
---
src/mesa/main/texgetimage.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/texgetimage.c b/src/mesa/main/texgetimage.c
index 9411db8..255d365 100644
--- a/src/mesa/main/texgetimage.c
+++ b/src/mesa/main/texgetimage.c
@@ -1303,7 +1303,16 @@ _mesa_GetCompressedTextureImage(GLuint texture, GLint
level,
/* Must handle special case GL_TEXTURE_CUBE_MAP. */
if (texObj-Target == GL_TEXTURE_CUBE_MAP) {
- assert(texObj-NumLayers = 6);
+
+ /* Make sure the texture object is a proper cube.
+ * (See texturesubimage in teximage.c for details on why this check is
+ * performed.)
+ */
+ if (!_mesa_cube_level_complete(texObj, level)) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ glGetCompressedTextureImage(cube map incomplete));
+ return;
+ }
/* Copy each face. */
for (i = 0; i 6; ++i) {
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/6] main: _mesa_cube_level_complete checks NumLayers.
_mesa_cube_level_complete now verifies that a cube map texture object actually has six texture images before proceeding. --- src/mesa/main/texobj.c | 4 1 file changed, 4 insertions(+) diff --git a/src/mesa/main/texobj.c b/src/mesa/main/texobj.c index d5aa620..0b200a1 100644 --- a/src/mesa/main/texobj.c +++ b/src/mesa/main/texobj.c @@ -878,6 +878,10 @@ _mesa_cube_level_complete(const struct gl_texture_object *texObj, if (texObj-Target != GL_TEXTURE_CUBE_MAP) return GL_FALSE; + /* Make sure we have enough image planes for a cube map. */ + if (texObj-NumLayers 6) + return GL_FALSE; + if ((level 0) || (level = MAX_TEXTURE_LEVELS)) return GL_FALSE; -- 2.1.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/6] main: Remove redundant NumLayers checks.
ARB_direct_state_access texture functions that operate on cube maps no longer
need to verify that cube map texture objects contain six texture images
because _mesa_cube_level_complete now does that for them.
---
src/mesa/main/texgetimage.c | 13 -
src/mesa/main/teximage.c| 14 --
2 files changed, 27 deletions(-)
diff --git a/src/mesa/main/texgetimage.c b/src/mesa/main/texgetimage.c
index f975c16..42044dd 100644
--- a/src/mesa/main/texgetimage.c
+++ b/src/mesa/main/texgetimage.c
@@ -1088,19 +1088,6 @@ _mesa_GetTextureImage(GLuint texture, GLint level,
GLenum format,
/* Must handle special case GL_TEXTURE_CUBE_MAP. */
if (texObj-Target == GL_TEXTURE_CUBE_MAP) {
- /* Error checking */
- if (texObj-NumLayers 6) {
- /* Not enough image planes for a cube map. The spec does not say
- * what should happen in this case because the user has always
- * specified each cube face separately (using
- * GL_TEXTURE_CUBE_MAP_POSITIVE_X+i) in previous GL versions.
- * This is addressed in Khronos Bug 13223.
- */
- _mesa_error(ctx, GL_INVALID_OPERATION,
- glGetTextureImage(insufficient cube map storage));
- return;
- }
-
/*
* What do we do if the user created a texture with the following code
* and then called this function with its handle?
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 611d664..cb1c81a 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -3636,20 +3636,6 @@ texturesubimage(struct gl_context *ctx, GLuint dims,
if (texObj-Target == GL_TEXTURE_CUBE_MAP) {
GLint rowStride;
- /* Error checking */
- if (texObj-NumLayers 6) {
- /* Not enough image planes for a cube map. The spec does not say
- * what should happen in this case because the user has always
- * specified each cube face separately (using
- * GL_TEXTURE_CUBE_MAP_POSITIVE_X+i) in previous GL versions.
- * This is addressed in Khronos Bug 13223.
- */
- _mesa_error(ctx, GL_INVALID_OPERATION,
- glTextureSubImage%uD(insufficient cube map storage),
- dims);
- return;
- }
-
/*
* What do we do if the user created a texture with the following code
* and then called this function with its handle?
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965: Reserve more batch space to accomodate Gen6 perfmonitors.
Ben noticed that I said each PIPE_CONTROL was 4 DWords, but it's
actually 5 DWords on Gen6-7. We've been reserving insufficient space
for performance monitoring on Sandybridge, which means it would likely
break if you used that functionality. (Thankfully, no one does...)
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/intel_batchbuffer.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
We should probably Cc this to stable unless we delete the broken
performance monitoring code altogether.
diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.h
b/src/mesa/drivers/dri/i965/intel_batchbuffer.h
index 7bdd836..5a16456 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.h
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.h
@@ -22,12 +22,12 @@ extern C {
* - Disabling OA counters on Gen6+ (3 DWords = 12 bytes)
* - Ending MI_REPORT_PERF_COUNT on Gen5+, plus associated PIPE_CONTROLs:
* - Two sets of PIPE_CONTROLs, which become 3 PIPE_CONTROLs each on SNB,
- * which are 4 DWords each == 2 * 3 * 4 * 4 = 96 bytes
+ * which are 5 DWords each == 2 * 3 * 5 * 4 = 120 bytes
* - 3 DWords for MI_REPORT_PERF_COUNT itself on Gen6+. == 12 bytes.
* On Ironlake, it's 6 DWords, but we have some slack due to the lack of
* Sandybridge PIPE_CONTROL madness.
*/
-#define BATCH_RESERVED 146
+#define BATCH_RESERVED 152
struct intel_batchbuffer;
--
2.2.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 6/6] i965: Don't write past the end of the application supplied buffer
On Wed, 2015-03-04 at 09:55 -0800, Ian Romanick wrote:
From: Ian Romanick ian.d.roman...@intel.com
Both the AMD and Intel APIs provide a dataSize parameter, and this
function would merrily ignore it. Neither API specifies what to do when
the buffer isn't big enough. I take the easy route of writing all the
complete bits of data that will fit. With more complete specs, we could
probably do something different.
I noticed this while looking into an unused parameter warning. The
warning was actually useful!
brw_performance_monitor.c: In function 'brw_get_perf_monitor_result':
brw_performance_monitor.c:1261:37: warning: unused parameter 'data_size'
[-Wunused-parameter]
GLsizei data_size,
^
v2: Fix checks to include offset in the calculation. Noticed by Jan.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
Cc: Kenneth Graunke kenn...@whitecape.org
Cc: Jan Vesely jan.ves...@rutgers.edu
---
src/mesa/drivers/dri/i965/brw_performance_monitor.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_performance_monitor.c
b/src/mesa/drivers/dri/i965/brw_performance_monitor.c
index 6c31d4c..2c8cd49 100644
--- a/src/mesa/drivers/dri/i965/brw_performance_monitor.c
+++ b/src/mesa/drivers/dri/i965/brw_performance_monitor.c
@@ -1264,6 +1264,7 @@ brw_get_perf_monitor_result(struct gl_context *ctx,
{
struct brw_context *brw = brw_context(ctx);
struct brw_perf_monitor_object *monitor = brw_perf_monitor(m);
+ const GLuint *const data_end = (GLuint *)((uint8_t *) data + data_size);
DBG(GetResult(%d)\n, m-Name);
brw_dump_perf_monitors(brw);
@@ -1309,9 +1310,11 @@ brw_get_perf_monitor_result(struct gl_context *ctx,
if (counter 0 || !BITSET_TEST(m-ActiveCounters[group], counter))
continue;
- data[offset++] = group;
- data[offset++] = counter;
- data[offset++] = monitor-oa_results[i];
+ if (data + offset + 3 = data_end) {
+data[offset++] = group;
+data[offset++] = counter;
+data[offset++] = monitor-oa_results[i];
+ }
}
clean_bookend_bo(brw);
@@ -1335,10 +1338,12 @@ brw_get_perf_monitor_result(struct gl_context *ctx,
for (int i = 0; i num_counters; i++) {
if (BITSET_TEST(m-ActiveCounters[PIPELINE_STATS_COUNTERS], i)) {
-data[offset++] = PIPELINE_STATS_COUNTERS;
-data[offset++] = i;
-*((uint64_t *) (data[offset])) =
monitor-pipeline_stats_results[i];
-offset += 2;
+if (data + offset + 4 = data_end) {
+ data[offset++] = PIPELINE_STATS_COUNTERS;
+ data[offset++] = i;
+ *((uint64_t *) (data[offset])) =
monitor-pipeline_stats_results[i];
+ offset += 2;
+}
}
}
}
don't now anything about i965 driver, but the checks seem OK now
Reviewed-by : Jan Vesely jan.ves...@rutgers.edu
--
Jan Vesely jan.ves...@rutgers.edu
signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] State of Geometry shader instancing on radeonsi
Then you can count me as working on ARB_viewport_array. Alexandre Demers On 2015-02-25 14:25, Marek Olšák wrote: Nobody is working on ARB_gpu_shader5 for radeonsi. Marek On Wed, Feb 25, 2015 at 6:41 PM, Ilia Mirkin imir...@alum.mit.edu wrote: On Wed, Feb 25, 2015 at 11:24 AM, Alexandre Demers alexandre.f.dem...@gmail.com wrote: Hi everyone, I'd like to know if someone is working on Geometry shader instancing for radeonsi or if there is already a work in progress somewhere I would have missed. I might be interested in giving it a try and then on GL_ARB_viewport_array. While there's no harm in working on GS instancing on its own, note that it's only a small part of the ARB_gpu_shader5 extension, so won't be immediately useful until the other pieces are completed (which will mostly involve adding LLVM support for the ops in question if they're not there yet, and then wiring them up). ARB_viewport_array is a much more self-contained extension. Note that ARB_fragment_layer_viewport will automatically get enabled once you claim multiple viewports, so make sure to make gl_ViewportIndex work in fp as well if you decide to do it. You may have to pass it as a varying by hand, not sure... IIRC I had to do that in r600. There are piglits that cover the various cases. [Hopefully Marek and/or some of the other AMD guys will pipe up if they've worked on any of these things and just haven't published yet.] -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] Revert common: Fix PBOs for 1D_ARRAY.
Series is Reviewed-by: Jason Ekstrand jason.ekstr...@intel.com On Wed, Mar 4, 2015 at 3:15 PM, Emil Velikov emil.l.veli...@gmail.com wrote: On 4 March 2015 at 17:22, Neil Roberts n...@linux.intel.com wrote: This reverts commit 546aba143d13ba3f993ead4cc30b2404abfc0202. I think the changes to the calls to glBlitFramebuffer from this patch are no different to what it was doing previously because it used to set height to 1 before doing the blits. However it was introducing some problems with the blit for layer 0 because this was no longer special cased. It didn't fix problems with the yoffset which needs to be interpreted as a slice offset. I think a better solution would be to modify the original if statement to cope with the yoffset. Neil, if others agree with this revert can you cc stable. Seems that the offending commit already has the tag, plus I've already picked it up :-\ That's ok. Just add this series to stable once it gets pushed too. --Jason Cc: 10.5 mesa-sta...@lists.freedesktop.org Thanks Emil ___ 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] i965: Tell intel_get_memcpy() which direction the memcpy() is going.
On Wed, Mar 4, 2015 at 5:28 PM, Matt Turner matts...@gmail.com wrote: On Wed, Mar 4, 2015 at 5:07 PM, Jason Ekstrand ja...@jlekstrand.net wrote: On Wed, Mar 4, 2015 at 4:56 PM, Matt Turner matts...@gmail.com wrote: @@ -357,16 +394,22 @@ linear_to_xtiled_faster(uint32_t x0, uint32_t x1, uint32_t x2, uint32_t x3, if (mem_copy == memcpy) return linear_to_xtiled(0, 0, xtile_width, xtile_width, 0, xtile_height, dst, src, src_pitch, swizzle_bit, memcpy); - else if (mem_copy == rgba8_copy) + else if (mem_copy == rgba8_copy_aligned_dst) return linear_to_xtiled(0, 0, xtile_width, xtile_width, 0, xtile_height, - dst, src, src_pitch, swizzle_bit, rgba8_copy); + dst, src, src_pitch, swizzle_bit, + rgba8_copy_aligned_dst); + else + unreachable(not reached); I'm not sure what I think about the unreachable here. The original versions of the *_faster functions would work regardless of what memcpy you passed in. Well, yeah, but there were only two. :) The *_faster was only to force the compiler to inline the universe in the case where we knew some parameters. Adding unreachable changes that. Oh, I didn't know what you meant, until I realized that the if-elseif is supposed to fall through to another function call in the case that mem_copy wasn't matched. At the very least I should split that out into a separate patch. Using unreachable(), if it's safe, cuts more than 1k of text: text databssdechex filename 9663 0 0 9663 25bf .libs/intel_tiled_memcpy.o 8215 0 0 8215 2017 .libs/intel_tiled_memcpy.o I'll drop the unreachable()s from this patch. Fine with me. In any case, my R-B still applies. --Jason That said, we never call them with anything other than memcpy or rgba8_copy_aligned_* so it's probably ok. I think I'm ok with it with or without the unreachable()'s. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Reserve more batch space to accomodate Gen6 perfmonitors.
On Wed, Mar 4, 2015 at 3:46 PM, Kenneth Graunke kenn...@whitecape.org wrote:
Ben noticed that I said each PIPE_CONTROL was 4 DWords, but it's
actually 5 DWords on Gen6-7. We've been reserving insufficient space
for performance monitoring on Sandybridge, which means it would likely
break if you used that functionality. (Thankfully, no one does...)
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/intel_batchbuffer.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
We should probably Cc this to stable unless we delete the broken
performance monitoring code altogether.
diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.h
b/src/mesa/drivers/dri/i965/intel_batchbuffer.h
index 7bdd836..5a16456 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.h
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.h
@@ -22,12 +22,12 @@ extern C {
* - Disabling OA counters on Gen6+ (3 DWords = 12 bytes)
* - Ending MI_REPORT_PERF_COUNT on Gen5+, plus associated PIPE_CONTROLs:
* - Two sets of PIPE_CONTROLs, which become 3 PIPE_CONTROLs each on SNB,
- * which are 4 DWords each == 2 * 3 * 4 * 4 = 96 bytes
+ * which are 5 DWords each == 2 * 3 * 5 * 4 = 120 bytes
* - 3 DWords for MI_REPORT_PERF_COUNT itself on Gen6+. == 12 bytes.
* On Ironlake, it's 6 DWords, but we have some slack due to the lack
of
* Sandybridge PIPE_CONTROL madness.
*/
-#define BATCH_RESERVED 146
+#define BATCH_RESERVED 152
struct intel_batchbuffer;
--
2.2.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Reviewed-by: Anuj Phogat anuj.pho...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89433] GCC 4.2 does not support -Wvla
https://bugs.freedesktop.org/show_bug.cgi?id=89433 --- Comment #1 from Jonathan Gray j...@openbsd.org --- Created attachment 114016 -- https://bugs.freedesktop.org/attachment.cgi?id=114016action=edit make -Wvla conditional How about the attached patch to make it conditional on the GCC version? -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89433] GCC 4.2 does not support -Wvla
https://bugs.freedesktop.org/show_bug.cgi?id=89433 Bug ID: 89433 Summary: GCC 4.2 does not support -Wvla Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Keywords: regression Severity: blocker Priority: medium Component: Mesa core Assignee: mesa-dev@lists.freedesktop.org Reporter: v...@freedesktop.org QA Contact: mesa-dev@lists.freedesktop.org CC: jfons...@vmware.com, j...@openbsd.org mesa: b5eb6f769db71557c86c72c3352db149379fdade (master 10.6.0-devel) -Wvla is available with gcc = 4.3. Build fails with this error. cc1: error: -Werror=vla: No option -Wvla -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/7] main: Add utility function _mesa_lookup_bufferobj_err.
This function is exposed to mesa driver internals so that texture buffer
objects and array objects can use it.
---
src/mesa/main/bufferobj.c | 19 +++
src/mesa/main/bufferobj.h | 4
2 files changed, 23 insertions(+)
diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index e1c5877..cef284f 100644
--- a/src/mesa/main/bufferobj.c
+++ b/src/mesa/main/bufferobj.c
@@ -1006,6 +1006,25 @@ _mesa_lookup_bufferobj_locked(struct gl_context *ctx,
GLuint buffer)
_mesa_HashLookupLocked(ctx-Shared-BufferObjects, buffer);
}
+/**
+ * A convenience function for direct state access functions that throws
+ * GL_INVALID_OPERATION if buffer is not the name of a buffer object in the
+ * hash table.
+ */
+struct gl_buffer_object *
+_mesa_lookup_bufferobj_err(struct gl_context *ctx, GLuint buffer,
+ const char *caller)
+{
+ struct gl_buffer_object *bufObj;
+
+ bufObj = _mesa_lookup_bufferobj(ctx, buffer);
+ if (!bufObj)
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ %s(non-generated buffer name %u), caller, buffer);
+
+ return bufObj;
+}
+
void
_mesa_begin_bufferobj_lookups(struct gl_context *ctx)
diff --git a/src/mesa/main/bufferobj.h b/src/mesa/main/bufferobj.h
index fe294fc..8e53bfd 100644
--- a/src/mesa/main/bufferobj.h
+++ b/src/mesa/main/bufferobj.h
@@ -89,6 +89,10 @@ _mesa_lookup_bufferobj(struct gl_context *ctx, GLuint
buffer);
extern struct gl_buffer_object *
_mesa_lookup_bufferobj_locked(struct gl_context *ctx, GLuint buffer);
+extern struct gl_buffer_object *
+_mesa_lookup_bufferobj_err(struct gl_context *ctx, GLuint buffer,
+ const char *caller);
+
extern void
_mesa_begin_bufferobj_lookups(struct gl_context *ctx);
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] include: Add helper header to help trap includes inside extern C.
Assuming my patch to fix 'extern C' issues is pushed before this one,
Reviewed-by: Mark Janes mark.a.ja...@intel.com
Jose Fonseca jfons...@vmware.com writes:
From: José Fonseca jfons...@vmware.com
This is just to help repro and fixing these issues with any C++ compiler --
commiting this will of course wait until all issues are addressed.
$ scons src/glsl/
scons: Reading SConscript files ...
Checking for GCC ... yes
Checking for Clang ... no
Checking for X11 (x11 xext xdamage xfixes glproto = 1.4.13)... yes
Checking for XCB (x11-xcb xcb-glx = 1.8.1 xcb-dri2 = 1.8)... yes
Checking for XF86VIDMODE (xxf86vm)... yes
Checking for DRM (libdrm = 2.4.38)... yes
Checking for UDEV (libudev = 151)... yes
warning: LLVM disabled: not building llvmpipe
scons: done reading SConscript files.
scons: Building targets ...
scons: building associated VariantDir targets: build/linux-x86_64-debug/glsl
Compiling src/glsl/ast_array_index.cpp ...
Compiling src/glsl/ast_expr.cpp ...
Compiling src/glsl/ast_function.cpp ...
Compiling src/glsl/ast_to_hir.cpp ...
Compiling src/glsl/ast_type.cpp ...
Compiling src/glsl/builtin_functions.cpp ...
In file included from include/c99_compat.h:28:0,
from src/mapi/u_compiler.h:4,
from src/mapi/u_thread.h:47,
from src/mapi/glapi/glapi.h:47,
from src/mesa/main/mtypes.h:42,
from src/mesa/main/errors.h:47,
from src/mesa/main/imports.h:41,
from src/mesa/main/core.h:44,
from src/glsl/builtin_functions.cpp:58:
include/no_extern_c.h:48:1: error: template with C linkage
templateclass T class _IncludeInsideExternCNotPortable;
^
In file included from include/c99_compat.h:28:0,
from include/c11/threads.h:38,
from src/mapi/u_thread.h:49,
from src/mapi/glapi/glapi.h:47,
from src/mesa/main/mtypes.h:42,
from src/mesa/main/errors.h:47,
from src/mesa/main/imports.h:41,
from src/mesa/main/core.h:44,
from src/glsl/builtin_functions.cpp:58:
include/no_extern_c.h:48:1: error: template with C linkage
templateclass T class _IncludeInsideExternCNotPortable;
^
Compiling src/glsl/builtin_types.cpp ...
Compiling src/glsl/builtin_variables.cpp ...
scons: *** [build/linux-x86_64-debug/glsl/builtin_functions.os] Error 1
scons: building terminated because of errors.
---
include/c99_compat.h | 2 ++
include/no_extern_c.h | 49 +
src/util/u_atomic.h | 3 +++
3 files changed, 54 insertions(+)
create mode 100644 include/no_extern_c.h
diff --git a/include/c99_compat.h b/include/c99_compat.h
index 429c601..a8819ac 100644
--- a/include/c99_compat.h
+++ b/include/c99_compat.h
@@ -25,6 +25,8 @@
*
**/
+#include no_extern_c.h
+
#ifndef _C99_COMPAT_H_
#define _C99_COMPAT_H_
diff --git a/include/no_extern_c.h b/include/no_extern_c.h
new file mode 100644
index 000..d038a4f
--- /dev/null
+++ b/include/no_extern_c.h
@@ -0,0 +1,49 @@
+/**
+ *
+ * Copyright 2014 VMware, Inc.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included
+ * in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ **/
+
+
+/*
+ * Including system's headers inside `extern C { ... }` is not safe, as
system
+ * headers may have C++ code in them, and C++ code inside extern C
+ * leads to syntatically incorrect code.
+ *
+ * This is because putting code inside extern C won't make __cplusplus
define
+ * go away, that is, the headers being included thinks is free to use C++ as
it
+ * sees fits.
+ *
Re: [Mesa-dev] New stable-branch 10.4 candidate pushed
On Wed, Mar 4, 2015 at 4:53 AM, Emil Velikov emil.l.veli...@gmail.com wrote: Trivial merge conflicts --- Here are the commits where I manually merged conflicts, so these might merit additional review: commit a598a9bdfe9f5d0ed35ca89a55cf74a2b678e8e1 Author: Matt Turner matts...@gmail.com mesa: Correct backwards NULL check. (cherry picked from commit 491d42135ad0e5670756216154f2ba9fc79d4ba7) Again looks like I tagged something for 10.4 that doesn't apply. This one needs to be reverted (we've changed it so that if length is NULL, dereference it!) If we want to apply fixes for GetProgramBinary, we need 201b9c18, 4fd8b301, and f591712e first. I'd revert this commit, cherry-pick those just mentioned and then cherry-pick 491d42135 on top of that. commit 39ae85732d29906ea2a16dfdfc77f8e5dbed5853 Author: Eduardo Lima Mitev el...@igalia.com mesa: Fix error validating args for TexSubImage3D (cherry picked from commit 2aa71e9485a5a062b1bd2dd8bdc081a8fa4c873d) Looks like we're only applying half of this commit. I'm not sure what the right thing to do is. I might just drop it? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/3] meta: Allow GL_UN/PACK_IMAGE_HEIGHT in _mesa_meta_pbo_Get/TexSubImage
I have a new texturing/getteximage-targets test on the Piglit ML that
cleans up the test considerably and causes it to hit these Meta PBO paths.
It just hasn't been given R-B's yet.
http://patchwork.freedesktop.org/patch/42864/
On Wed, Mar 4, 2015 at 9:22 AM, Neil Roberts n...@linux.intel.com wrote:
Now that a layered source PBO is interpreted as a single tall 2D image
it's quite easy to accept the image height packing option by just
creating an image that is tall enough to include the image padding.
I'm not sure whether the image height property should affect 1D_ARRAY
textures. My intuition and interpretation of the GL spec (which is a
bit vague) would be that it shouldn't. However the software fallback
path in Mesa uses the property for packing but not for unpacking. The
binary NVidia driver uses it for both. This patch doesn't use it for
either case so it is different from the software fallback. There is
some discussion about this here:
http://lists.freedesktop.org/archives/mesa-dev/2015-February/077925.html
This is tested by the texsubimage Piglit test with the array and pbo
arguments. Previously this test was skipping this code path because it
always sets the image height.
I've also tested it by modifying the getteximage-targets test. It
wasn't using this code path before because it was using the default
texture object so this code couldn't successfully create a frame
buffer. I also modified it to add some image padding with the image
height in the PBO.
---
src/mesa/drivers/common/meta_tex_subimage.c | 32
++---
1 file changed, 20 insertions(+), 12 deletions(-)
diff --git a/src/mesa/drivers/common/meta_tex_subimage.c
b/src/mesa/drivers/common/meta_tex_subimage.c
index 1fef79d..f360d64 100644
--- a/src/mesa/drivers/common/meta_tex_subimage.c
+++ b/src/mesa/drivers/common/meta_tex_subimage.c
@@ -144,6 +144,7 @@ _mesa_meta_pbo_TexSubImage(struct gl_context *ctx,
GLuint dims,
const struct gl_pixelstore_attrib *packing)
{
GLuint pbo = 0, pbo_tex = 0, fbos[2] = { 0, 0 };
+ int full_height, image_height;
struct gl_texture_image *pbo_tex_image;
GLenum status;
bool success = false;
@@ -177,14 +178,16 @@ _mesa_meta_pbo_TexSubImage(struct gl_context *ctx,
GLuint dims,
return true;
}
- /* Only accept tightly packed pixels from the user. */
- if (packing-ImageHeight != 0 packing-ImageHeight != height)
- return false;
+ /* For arrays, use a tall (height * depth) 2D texture but taking into
+* account the inter-image padding specified with the image height
packing
+* property.
+*/
+ image_height = packing-ImageHeight == 0 ? height :
packing-ImageHeight;
+ full_height = image_height * (depth - 1) + height;
- /* For arrays, use a tall (height * depth) 2D texture. */
pbo_tex_image = create_texture_for_pbo(ctx, create_pbo,
GL_PIXEL_UNPACK_BUFFER,
- width, height * depth,
+ width, full_height,
format, type, pixels, packing,
pbo, pbo_tex);
if (!pbo_tex_image)
@@ -236,7 +239,8 @@ _mesa_meta_pbo_TexSubImage(struct gl_context *ctx,
GLuint dims,
_mesa_update_state(ctx);
_mesa_meta_BlitFramebuffer(ctx, ctx-ReadBuffer, ctx-DrawBuffer,
- 0, z * height, width, (z + 1) * height,
+ 0, z * image_height,
+ width, z * image_height + height,
xoffset, yoffset,
xoffset + width, yoffset + height,
GL_COLOR_BUFFER_BIT, GL_NEAREST);
@@ -263,6 +267,7 @@ _mesa_meta_pbo_GetTexSubImage(struct gl_context *ctx,
GLuint dims,
const struct gl_pixelstore_attrib *packing)
{
GLuint pbo = 0, pbo_tex = 0, fbos[2] = { 0, 0 };
+ int full_height, image_height;
struct gl_texture_image *pbo_tex_image;
GLenum status;
bool success = false;
@@ -296,13 +301,15 @@ _mesa_meta_pbo_GetTexSubImage(struct gl_context
*ctx, GLuint dims,
return true;
}
- /* Only accept tightly packed pixels from the user. */
- if (packing-ImageHeight != 0 packing-ImageHeight != height)
- return false;
+ /* For arrays, use a tall (height * depth) 2D texture but taking into
+* account the inter-image padding specified with the image height
packing
+* property.
+*/
+ image_height = packing-ImageHeight == 0 ? height :
packing-ImageHeight;
+ full_height = image_height * (depth - 1) + height;
- /* For arrays, use a tall (height * depth) 2D texture. */
pbo_tex_image = create_texture_for_pbo(ctx, false,
GL_PIXEL_PACK_BUFFER,
-
[Mesa-dev] [PATCH 12/12] osmesa: include stdio.h
--- src/mesa/drivers/osmesa/osmesa.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/mesa/drivers/osmesa/osmesa.c b/src/mesa/drivers/osmesa/osmesa.c index 9f1a5a8..022523e 100644 --- a/src/mesa/drivers/osmesa/osmesa.c +++ b/src/mesa/drivers/osmesa/osmesa.c @@ -33,6 +33,7 @@ */ +#include stdio.h #include main/glheader.h #include GL/osmesa.h #include main/api_exec.h -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/7] mapi: THREADS was always defined, remove it
THREADS was defined if HAVE_PTHREADS or _WIN32 was defined. That's always the case. The build would die in c11/threads.h otherwise. --- src/mapi/glapi/gen/gl_x86-64_asm.py | 6 +- src/mapi/glapi/gen/gl_x86_asm.py| 14 ++ src/mapi/glapi/glapi.h | 13 ++--- src/mapi/glapi/glapi_entrypoint.c | 4 +--- src/mapi/glapi/glapi_priv.h | 4 +--- src/mapi/u_current.c| 22 ++ src/mapi/u_thread.h | 6 -- 7 files changed, 13 insertions(+), 56 deletions(-) diff --git a/src/mapi/glapi/gen/gl_x86-64_asm.py b/src/mapi/glapi/gen/gl_x86-64_asm.py index 19e0e15..5a69e034 100644 --- a/src/mapi/glapi/gen/gl_x86-64_asm.py +++ b/src/mapi/glapi/gen/gl_x86-64_asm.py @@ -138,10 +138,6 @@ class PrintGenericStubs(gl_XML.gl_print_base): print '# define GL_PREFIX(n) GLNAME(CONCAT(gl,n))' print '# endif' print '' -print '#if defined(HAVE_PTHREAD) || defined(_WIN32)' -print '# define THREADS' -print '#endif' -print '' print '\t.text' print '' print '#ifdef GLX_USE_TLS' @@ -170,7 +166,7 @@ class PrintGenericStubs(gl_XML.gl_print_base): print '\tmovl\t(%rax), %edi' print '\tjmp\tpthread_getspecific@PLT' print '' -print '#elif defined(THREADS)' +print '#else' print '' print '\t.extern\t_glapi_get_dispatch' print '' diff --git a/src/mapi/glapi/gen/gl_x86_asm.py b/src/mapi/glapi/gen/gl_x86_asm.py index d87d0bd..f855dba 100644 --- a/src/mapi/glapi/gen/gl_x86_asm.py +++ b/src/mapi/glapi/gen/gl_x86_asm.py @@ -78,9 +78,6 @@ class PrintGenericStubs(gl_XML.gl_print_base): print '#define GLOBL_FN(x) GLOBL x' print '#endif' print '' -print '#if defined(HAVE_PTHREAD) || defined(_WIN32)' -print '# define THREADS' -print '#endif' print '' print '#ifdef GLX_USE_TLS' print '' @@ -109,7 +106,7 @@ class PrintGenericStubs(gl_XML.gl_print_base): print '\tJMP(GL_OFFSET(off)) ;\t\t\t\t\\' print '1:\tCALL(_x86_get_dispatch) ;\t\t\t\\' print '\tJMP(GL_OFFSET(off))' -print '#elif defined(THREADS)' +print '#else' print '# define GL_STUB(fn,off,fn_alt)\t\t\t\\' print 'ALIGNTEXT16;\t\t\t\t\t\t\\' print 'GLOBL_FN(GL_PREFIX(fn, fn_alt));\t\t\t\\' @@ -120,13 +117,6 @@ class PrintGenericStubs(gl_XML.gl_print_base): print '\tJMP(GL_OFFSET(off)) ;\t\t\t\t\\' print '1:\tCALL(_glapi_get_dispatch) ;\t\t\t\\' print '\tJMP(GL_OFFSET(off))' -print '#else /* Non-threaded version. */' -print '# define GL_STUB(fn,off,fn_alt)\t\t\t\\' -print 'ALIGNTEXT16;\t\t\t\t\t\t\\' -print 'GLOBL_FN(GL_PREFIX(fn, fn_alt));\t\t\t\\' -print 'GL_PREFIX(fn, fn_alt):\t\t\t\t\t\\' -print '\tMOV_L(CONTENT(GLNAME(_glapi_Dispatch)), EAX) ;\t\\' -print '\tJMP(GL_OFFSET(off))' print '#endif' print '' print '#ifdef HAVE_ALIAS' @@ -164,7 +154,7 @@ class PrintGenericStubs(gl_XML.gl_print_base): print '\tCALL(GLNAME(pthread_getspecific))' print '\tADD_L(CONST(28), ESP)' print '\tRET' -print '#elif defined(THREADS)' +print '#else' print 'EXTERN GLNAME(_glapi_get_dispatch)' print '#endif' print '' diff --git a/src/mapi/glapi/glapi.h b/src/mapi/glapi/glapi.h index e3f76b4..b2d6632 100644 --- a/src/mapi/glapi/glapi.h +++ b/src/mapi/glapi/glapi.h @@ -103,21 +103,12 @@ _GLAPI_EXPORT extern const void *_glapi_Context; _GLAPI_EXPORT extern struct _glapi_table *_glapi_Dispatch; _GLAPI_EXPORT extern void *_glapi_Context; -# ifdef THREADS - -# define GET_DISPATCH() \ +#define GET_DISPATCH() \ (likely(_glapi_Dispatch) ? _glapi_Dispatch : _glapi_get_dispatch()) -# define GET_CURRENT_CONTEXT(C) struct gl_context *C = (struct gl_context *) \ +#define GET_CURRENT_CONTEXT(C) struct gl_context *C = (struct gl_context *) \ (likely(_glapi_Context) ? _glapi_Context : _glapi_get_context()) -# else - -# define GET_DISPATCH() _glapi_Dispatch -# define GET_CURRENT_CONTEXT(C) struct gl_context *C = (struct gl_context *) _glapi_Context - -# endif - #endif /* defined (GLX_USE_TLS) */ diff --git a/src/mapi/glapi/glapi_entrypoint.c b/src/mapi/glapi/glapi_entrypoint.c index 362a8f1..53104ce 100644 --- a/src/mapi/glapi/glapi_entrypoint.c +++ b/src/mapi/glapi/glapi_entrypoint.c @@ -120,11 +120,9 @@ fill_in_entrypoint_offset(_glapi_proc entrypoint, unsigned int offset) #if defined(GLX_USE_TLS) *((unsigned int *)(code + 8)) = 4 * offset; -#elif defined(THREADS) +#else *((unsigned int *)(code + 11)) = 4 * offset; *((unsigned int *)(code + 22)) = 4 * offset; -#else - *((unsigned int *)(code + 7)) = 4 * offset; #endif } diff --git a/src/mapi/glapi/glapi_priv.h b/src/mapi/glapi/glapi_priv.h index
[Mesa-dev] [PATCH 1/7] mapi: remove u_macros.h
Only U_STRINGIFY() is used in entry.c --- src/mapi/Makefile.sources | 1 - src/mapi/entry.c| 4 +++- src/mapi/entry_x86-64_tls.h | 1 - src/mapi/entry_x86_tls.h| 1 - src/mapi/entry_x86_tsd.h| 1 - src/mapi/u_macros.h | 12 6 files changed, 3 insertions(+), 17 deletions(-) delete mode 100644 src/mapi/u_macros.h diff --git a/src/mapi/Makefile.sources b/src/mapi/Makefile.sources index a179662..4e92f5e 100644 --- a/src/mapi/Makefile.sources +++ b/src/mapi/Makefile.sources @@ -19,7 +19,6 @@ MAPI_UTIL_FILES = \ u_current.h \ u_execmem.c \ u_execmem.h \ - u_macros.h \ u_thread.h MAPI_BRIDGE_FILES = \ diff --git a/src/mapi/entry.c b/src/mapi/entry.c index f0287a0..27d0db4 100644 --- a/src/mapi/entry.c +++ b/src/mapi/entry.c @@ -27,7 +27,9 @@ #include entry.h #include u_current.h -#include u_macros.h + +#define _U_STRINGIFY(x) #x +#define U_STRINGIFY(x) _U_STRINGIFY(x) /* define macros for use by assembly dispatchers */ #define ENTRY_CURRENT_TABLE U_STRINGIFY(u_current_table) diff --git a/src/mapi/entry_x86-64_tls.h b/src/mapi/entry_x86-64_tls.h index d571df9..5c03b04 100644 --- a/src/mapi/entry_x86-64_tls.h +++ b/src/mapi/entry_x86-64_tls.h @@ -25,7 +25,6 @@ *Chia-I Wu o...@lunarg.com */ -#include u_macros.h __asm__(.text\n .balign 32\n diff --git a/src/mapi/entry_x86_tls.h b/src/mapi/entry_x86_tls.h index df31dce..46d2ece 100644 --- a/src/mapi/entry_x86_tls.h +++ b/src/mapi/entry_x86_tls.h @@ -26,7 +26,6 @@ */ #include string.h -#include u_macros.h __asm__(.text); diff --git a/src/mapi/entry_x86_tsd.h b/src/mapi/entry_x86_tsd.h index ece00fa..ea7bacb 100644 --- a/src/mapi/entry_x86_tsd.h +++ b/src/mapi/entry_x86_tsd.h @@ -25,7 +25,6 @@ *Chia-I Wu o...@lunarg.com */ -#include u_macros.h #define X86_ENTRY_SIZE 32 diff --git a/src/mapi/u_macros.h b/src/mapi/u_macros.h deleted file mode 100644 index 72345b5..000 --- a/src/mapi/u_macros.h +++ /dev/null @@ -1,12 +0,0 @@ -#ifndef _U_MACROS_ -#define _U_MACROS_ - -#define _U_STRINGIFY(x) #x -#define _U_CONCAT(x, y) x ## y -#define _U_CONCAT_STR(x, y) #x#y - -#define U_STRINGIFY(x) _U_STRINGIFY(x) -#define U_CONCAT(x, y) _U_CONCAT(x, y) -#define U_CONCAT_STR(x, y) _U_CONCAT_STR(x, y) - -#endif /* _U_MACROS_ */ -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 08/12] st/xlib: include stdio.h
--- src/gallium/state_trackers/glx/xlib/glx_api.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/state_trackers/glx/xlib/glx_api.c b/src/gallium/state_trackers/glx/xlib/glx_api.c index f59b0ba..d1bd760 100644 --- a/src/gallium/state_trackers/glx/xlib/glx_api.c +++ b/src/gallium/state_trackers/glx/xlib/glx_api.c @@ -33,6 +33,7 @@ #define GLX_GLXEXT_PROTOTYPES #include GL/glx.h +#include stdio.h #include X11/Xmd.h #include GL/glxproto.h -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 07/12] st/mesa: include stdio.h where needed
--- src/mesa/state_tracker/st_atom.c | 1 + src/mesa/state_tracker/st_cb_texture.c | 1 + 2 files changed, 2 insertions(+) diff --git a/src/mesa/state_tracker/st_atom.c b/src/mesa/state_tracker/st_atom.c index 8cc6af2..f0fe11f 100644 --- a/src/mesa/state_tracker/st_atom.c +++ b/src/mesa/state_tracker/st_atom.c @@ -26,6 +26,7 @@ **/ +#include stdio.h #include main/glheader.h #include main/context.h diff --git a/src/mesa/state_tracker/st_cb_texture.c b/src/mesa/state_tracker/st_cb_texture.c index 0525e87..a8b19a1 100644 --- a/src/mesa/state_tracker/st_cb_texture.c +++ b/src/mesa/state_tracker/st_cb_texture.c @@ -25,6 +25,7 @@ * **/ +#include stdio.h #include main/bufferobj.h #include main/enums.h #include main/fbobject.h -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 03/12] glsl: include stdio.h where needed
--- src/glsl/s_expression.cpp | 1 + src/glsl/standalone_scaffolding.cpp | 1 + 2 files changed, 2 insertions(+) diff --git a/src/glsl/s_expression.cpp b/src/glsl/s_expression.cpp index 2928a4d..7eaa491 100644 --- a/src/glsl/s_expression.cpp +++ b/src/glsl/s_expression.cpp @@ -24,6 +24,7 @@ #include assert.h #include limits +#include stdio.h #include s_expression.h s_symbol::s_symbol(const char *str, size_t n) diff --git a/src/glsl/standalone_scaffolding.cpp b/src/glsl/standalone_scaffolding.cpp index ad0d75b..6f5a27f 100644 --- a/src/glsl/standalone_scaffolding.cpp +++ b/src/glsl/standalone_scaffolding.cpp @@ -30,6 +30,7 @@ #include standalone_scaffolding.h #include assert.h +#include stdio.h #include string.h #include util/ralloc.h -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 04/12] dri/common: include stdio.h where needed
--- src/mesa/drivers/dri/common/utils.c | 1 + src/mesa/drivers/dri/common/xmlconfig.c | 1 + 2 files changed, 2 insertions(+) diff --git a/src/mesa/drivers/dri/common/utils.c b/src/mesa/drivers/dri/common/utils.c index ccdc971..bb22107 100644 --- a/src/mesa/drivers/dri/common/utils.c +++ b/src/mesa/drivers/dri/common/utils.c @@ -30,6 +30,7 @@ */ #include string.h +#include stdio.h #include stdlib.h #include stdbool.h #include stdint.h diff --git a/src/mesa/drivers/dri/common/xmlconfig.c b/src/mesa/drivers/dri/common/xmlconfig.c index 6357e92..2b284cc 100644 --- a/src/mesa/drivers/dri/common/xmlconfig.c +++ b/src/mesa/drivers/dri/common/xmlconfig.c @@ -28,6 +28,7 @@ */ #include stdarg.h +#include stdio.h #include string.h #include assert.h #include expat.h -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 10/12] st/osmesa: include stdio.h
--- src/gallium/state_trackers/osmesa/osmesa.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/state_trackers/osmesa/osmesa.c b/src/gallium/state_trackers/osmesa/osmesa.c index 4e2b2e0..2d5d096 100644 --- a/src/gallium/state_trackers/osmesa/osmesa.c +++ b/src/gallium/state_trackers/osmesa/osmesa.c @@ -49,6 +49,7 @@ */ +#include stdio.h #include GL/osmesa.h #include glapi/glapi.h /* for OSMesaGetProcAddress below */ -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 01/12] mesa: include c11/threads.h in mtypes.h
Let's directly include c11/threads.h instead of relying on glapi.h to provide it. --- src/mesa/main/mtypes.h | 1 + 1 file changed, 1 insertion(+) diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h index 6e99773..efeee8b 100644 --- a/src/mesa/main/mtypes.h +++ b/src/mesa/main/mtypes.h @@ -36,6 +36,7 @@ #include stdint.h /* uint32_t */ #include stdbool.h +#include c11/threads.h #include main/glheader.h #include main/config.h -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 09/12] st/xlib: include stdio.h
--- src/gallium/state_trackers/glx/xlib/glx_usefont.c | 1 + src/gallium/state_trackers/glx/xlib/xm_api.c | 1 + 2 files changed, 2 insertions(+) diff --git a/src/gallium/state_trackers/glx/xlib/glx_usefont.c b/src/gallium/state_trackers/glx/xlib/glx_usefont.c index f7ee68b..b3e9c79 100644 --- a/src/gallium/state_trackers/glx/xlib/glx_usefont.c +++ b/src/gallium/state_trackers/glx/xlib/glx_usefont.c @@ -30,6 +30,7 @@ */ +#include stdio.h #include main/core.h #include GL/glx.h diff --git a/src/gallium/state_trackers/glx/xlib/xm_api.c b/src/gallium/state_trackers/glx/xlib/xm_api.c index e6f40c3..a0ee59c 100644 --- a/src/gallium/state_trackers/glx/xlib/xm_api.c +++ b/src/gallium/state_trackers/glx/xlib/xm_api.c @@ -53,6 +53,7 @@ #undef __WIN32__ #endif +#include stdio.h #include xm_api.h #include xm_st.h -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 02/12] mesa: include stdio.h where needed
Instead of relying on glapi.h or some other header to provide it. --- src/mesa/main/blit.c | 1 + src/mesa/main/debug.c | 1 + src/mesa/main/dlist.h | 2 +- src/mesa/main/errors.c| 1 + src/mesa/main/execmem.c | 1 + src/mesa/main/framebuffer.c | 2 +- src/mesa/main/imports.c | 1 + src/mesa/main/texobj.c| 1 + src/mesa/main/texstate.c | 1 + src/mesa/main/varray.c| 1 + src/mesa/main/version.c | 1 + src/mesa/math/m_vector.c | 1 + src/mesa/program/prog_statevars.c | 1 + src/mesa/tnl/t_draw.c | 2 ++ src/mesa/tnl/t_vb_render.c| 1 + src/mesa/tnl/t_vertex.c | 1 + src/mesa/vbo/vbo_exec_array.c | 1 + src/mesa/vbo/vbo_exec_draw.c | 1 + src/mesa/vbo/vbo_rebase.c | 1 + src/mesa/vbo/vbo_save_loopback.c | 1 + src/mesa/vbo/vbo_split_copy.c | 2 ++ src/mesa/x86/gen_matypes.c| 2 ++ 22 files changed, 25 insertions(+), 2 deletions(-) diff --git a/src/mesa/main/blit.c b/src/mesa/main/blit.c index 2898723..0694466 100644 --- a/src/mesa/main/blit.c +++ b/src/mesa/main/blit.c @@ -28,6 +28,7 @@ */ #include stdbool.h +#include stdio.h #include context.h #include enums.h diff --git a/src/mesa/main/debug.c b/src/mesa/main/debug.c index 4522114..eda4937 100644 --- a/src/mesa/main/debug.c +++ b/src/mesa/main/debug.c @@ -23,6 +23,7 @@ * OTHER DEALINGS IN THE SOFTWARE. */ +#include stdio.h #include mtypes.h #include attrib.h #include colormac.h diff --git a/src/mesa/main/dlist.h b/src/mesa/main/dlist.h index 6189632..a121467 100644 --- a/src/mesa/main/dlist.h +++ b/src/mesa/main/dlist.h @@ -32,7 +32,7 @@ #ifndef DLIST_H #define DLIST_H - +#include stdio.h #include main/mtypes.h diff --git a/src/mesa/main/errors.c b/src/mesa/main/errors.c index 33c1730..8ffbf41 100644 --- a/src/mesa/main/errors.c +++ b/src/mesa/main/errors.c @@ -29,6 +29,7 @@ #include stdarg.h +#include stdio.h #include errors.h #include enums.h #include imports.h diff --git a/src/mesa/main/execmem.c b/src/mesa/main/execmem.c index 7267cf8..3a13385 100644 --- a/src/mesa/main/execmem.c +++ b/src/mesa/main/execmem.c @@ -31,6 +31,7 @@ */ +#include stdio.h #include imports.h diff --git a/src/mesa/main/framebuffer.c b/src/mesa/main/framebuffer.c index 5df1ecc..4f7736a 100644 --- a/src/mesa/main/framebuffer.c +++ b/src/mesa/main/framebuffer.c @@ -29,7 +29,7 @@ * ushorts, uints, etc. */ - +#include stdio.h #include glheader.h #include imports.h #include blend.h diff --git a/src/mesa/main/imports.c b/src/mesa/main/imports.c index 752cf5a..a7ffe22 100644 --- a/src/mesa/main/imports.c +++ b/src/mesa/main/imports.c @@ -42,6 +42,7 @@ * OTHER DEALINGS IN THE SOFTWARE. */ +#include stdio.h #include stdarg.h #include c99_math.h #include imports.h diff --git a/src/mesa/main/texobj.c b/src/mesa/main/texobj.c index d5aa620..e018ab9 100644 --- a/src/mesa/main/texobj.c +++ b/src/mesa/main/texobj.c @@ -28,6 +28,7 @@ */ +#include stdio.h #include bufferobj.h #include colortab.h #include context.h diff --git a/src/mesa/main/texstate.c b/src/mesa/main/texstate.c index 78ae7d2..0a7f983 100644 --- a/src/mesa/main/texstate.c +++ b/src/mesa/main/texstate.c @@ -28,6 +28,7 @@ * Texture state handling. */ +#include stdio.h #include glheader.h #include bufferobj.h #include colormac.h diff --git a/src/mesa/main/varray.c b/src/mesa/main/varray.c index 3db9e06..42e7f89 100644 --- a/src/mesa/main/varray.c +++ b/src/mesa/main/varray.c @@ -24,6 +24,7 @@ */ +#include stdio.h #include inttypes.h /* for PRId64 macro */ #include glheader.h diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c index 4951891..8e0c3ef 100644 --- a/src/mesa/main/version.c +++ b/src/mesa/main/version.c @@ -23,6 +23,7 @@ */ +#include stdio.h #include imports.h #include mtypes.h #include version.h diff --git a/src/mesa/math/m_vector.c b/src/mesa/math/m_vector.c index ff42396..831f953 100644 --- a/src/mesa/math/m_vector.c +++ b/src/mesa/math/m_vector.c @@ -26,6 +26,7 @@ * New (3.1) transformation code written by Keith Whitwell. */ +#include stdio.h #include main/glheader.h #include main/imports.h diff --git a/src/mesa/program/prog_statevars.c b/src/mesa/program/prog_statevars.c index 4cde744..57b25a7 100644 --- a/src/mesa/program/prog_statevars.c +++ b/src/mesa/program/prog_statevars.c @@ -29,6 +29,7 @@ */ +#include stdio.h #include main/glheader.h #include main/context.h #include main/blend.h diff --git a/src/mesa/tnl/t_draw.c b/src/mesa/tnl/t_draw.c index be3f059..60265d6 100644 --- a/src/mesa/tnl/t_draw.c +++ b/src/mesa/tnl/t_draw.c @@ -25,6 +25,8 @@ *Keith Whitwell kei...@vmware.com */ +#include stdio.h + #include main/glheader.h #include main/bufferobj.h #include main/condrender.h diff --git a/src/mesa/tnl/t_vb_render.c b/src/mesa/tnl/t_vb_render.c index a090c48..4960ac0 100644 ---
[Mesa-dev] [PATCH 05/12] nouveau: include stdio.h where needed
--- src/mesa/drivers/dri/nouveau/nouveau_context.c | 1 + src/mesa/drivers/dri/nouveau/nouveau_driver.c | 1 + src/mesa/drivers/dri/nouveau/nouveau_screen.c | 1 + 3 files changed, 3 insertions(+) diff --git a/src/mesa/drivers/dri/nouveau/nouveau_context.c b/src/mesa/drivers/dri/nouveau/nouveau_context.c index e1bb7e8..a049d9b 100644 --- a/src/mesa/drivers/dri/nouveau/nouveau_context.c +++ b/src/mesa/drivers/dri/nouveau/nouveau_context.c @@ -25,6 +25,7 @@ */ #include stdbool.h +#include stdio.h #include nouveau_driver.h #include nouveau_context.h #include nouveau_bufferobj.h diff --git a/src/mesa/drivers/dri/nouveau/nouveau_driver.c b/src/mesa/drivers/dri/nouveau/nouveau_driver.c index c1f8672..7f31b28 100644 --- a/src/mesa/drivers/dri/nouveau/nouveau_driver.c +++ b/src/mesa/drivers/dri/nouveau/nouveau_driver.c @@ -24,6 +24,7 @@ * */ +#include stdio.h #include main/mtypes.h #include main/fbobject.h diff --git a/src/mesa/drivers/dri/nouveau/nouveau_screen.c b/src/mesa/drivers/dri/nouveau/nouveau_screen.c index b9ae959..153f18e 100644 --- a/src/mesa/drivers/dri/nouveau/nouveau_screen.c +++ b/src/mesa/drivers/dri/nouveau/nouveau_screen.c @@ -24,6 +24,7 @@ * */ +#include stdio.h #include xf86drm.h #include nouveau_drm.h #include nouveau_driver.h -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 06/12] swrast: include stdio.h where needed
--- src/mesa/drivers/dri/swrast/swrast.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/mesa/drivers/dri/swrast/swrast.c b/src/mesa/drivers/dri/swrast/swrast.c index b801476..fb29078 100644 --- a/src/mesa/drivers/dri/swrast/swrast.c +++ b/src/mesa/drivers/dri/swrast/swrast.c @@ -32,6 +32,7 @@ * The back-buffer is allocated by the driver and is private. */ +#include stdio.h #include main/api_exec.h #include main/context.h #include main/extensions.h -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/7] mapi: fix preprocessor check in u_current_destroy()
So it matches the preprocessor check around the u_current_init_tsd() code.
---
src/mapi/u_current.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mapi/u_current.c b/src/mapi/u_current.c
index afa887e..eb77cc7 100644
--- a/src/mapi/u_current.c
+++ b/src/mapi/u_current.c
@@ -125,7 +125,7 @@ static int ThreadSafe;
void
u_current_destroy(void)
{
-#if defined(THREADS) defined(_WIN32)
+#if defined(THREADS) !defined(GLX_USE_TLS)
u_tsd_destroy(u_current_table_tsd);
u_tsd_destroy(u_current_context_tsd);
#endif
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/7] mapi: rewrite u_current_init() function without u_thread_self()
Remove u_thread_self() since u_thread.h is going away soon.
Create a simple thread ID abstraction which wraps WIN32 or c11 threads.
This also gets rid of the questionable casting of thrd_t to an unsigned
long.
---
src/mapi/u_current.c | 43 ---
src/mapi/u_thread.h | 24
2 files changed, 40 insertions(+), 27 deletions(-)
diff --git a/src/mapi/u_current.c b/src/mapi/u_current.c
index eb77cc7..c1a486b 100644
--- a/src/mapi/u_current.c
+++ b/src/mapi/u_current.c
@@ -146,6 +146,43 @@ u_current_init_tsd(void)
*/
static mtx_t ThreadCheckMutex = _MTX_INITIALIZER_NP;
+
+#ifdef _WIN32
+typedef DWORD thread_id;
+#else
+typedef thrd_t thread_id;
+#endif
+
+
+static inline thread_id
+get_thread_id(void)
+{
+ /*
+* XXX: Callers of of this function assume it is a lightweight function.
+* But unfortunately C11's thrd_current() gives no such guarantees. In
+* fact, it's pretty hard to have a compliant implementation of
+* thrd_current() on Windows with such characteristics. So for now, we
+* side-step this mess and use Windows thread primitives directly here.
+*/
+#ifdef _WIN32
+ return GetCurrentThreadId();
+#else
+ return thrd_current();
+#endif
+}
+
+
+static inline int
+thread_id_equal(thread_id t1, thread_id t2)
+{
+#ifdef _WIN32
+ return t1 == t2;
+#else
+ return thrd_equal(t1, t2);
+#endif
+}
+
+
/**
* We should call this periodically from a function such as glXMakeCurrent
* in order to test if multiple threads are being used.
@@ -153,7 +190,7 @@ static mtx_t ThreadCheckMutex = _MTX_INITIALIZER_NP;
void
u_current_init(void)
{
- static unsigned long knownID;
+ static thread_id knownID;
static int firstCall = 1;
if (ThreadSafe)
@@ -163,10 +200,10 @@ u_current_init(void)
if (firstCall) {
u_current_init_tsd();
- knownID = u_thread_self();
+ knownID = get_thread_id();
firstCall = 0;
}
- else if (knownID != u_thread_self()) {
+ else if (!thread_id_equal(knownID, get_thread_id())) {
ThreadSafe = 1;
u_current_set_table(NULL);
u_current_set_context(NULL);
diff --git a/src/mapi/u_thread.h b/src/mapi/u_thread.h
index 4dd9515..e57c69a 100644
--- a/src/mapi/u_thread.h
+++ b/src/mapi/u_thread.h
@@ -80,30 +80,6 @@ struct u_tsd {
};
-static inline unsigned long
-u_thread_self(void)
-{
- /*
-* XXX: Callers of u_thread_self assume it is a lightweight function,
-* returning a numeric value. But unfortunately C11's thrd_current() gives
-* no such guarantees. In fact, it's pretty hard to have a compliant
-* implementation of thrd_current() on Windows with such characteristics.
-* So for now, we side-step this mess and use Windows thread primitives
-* directly here.
-*
-* FIXME: On the other hand, u_thread_self() is a bad
-* abstraction. Even with pthreads, there is no guarantee that
-* pthread_self() will return numeric IDs -- we should be using
-* pthread_equal() instead of assuming we can compare thread ids...
-*/
-#ifdef _WIN32
- return GetCurrentThreadId();
-#else
- return (unsigned long) (uintptr_t) thrd_current();
-#endif
-}
-
-
static inline void
u_tsd_init(struct u_tsd *tsd)
{
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 11/12] xlib: include stdio.h
--- src/mesa/drivers/x11/fakeglx.c | 2 +- src/mesa/drivers/x11/xfonts.c | 1 + src/mesa/drivers/x11/xm_api.c | 1 + src/mesa/drivers/x11/xm_tri.c | 1 + 4 files changed, 4 insertions(+), 1 deletion(-) diff --git a/src/mesa/drivers/x11/fakeglx.c b/src/mesa/drivers/x11/fakeglx.c index 00c583f..3869e94 100644 --- a/src/mesa/drivers/x11/fakeglx.c +++ b/src/mesa/drivers/x11/fakeglx.c @@ -40,7 +40,7 @@ */ - +#include stdio.h #include glxheader.h #include glxapi.h #include main/context.h diff --git a/src/mesa/drivers/x11/xfonts.c b/src/mesa/drivers/x11/xfonts.c index e9a38ba..8405013 100644 --- a/src/mesa/drivers/x11/xfonts.c +++ b/src/mesa/drivers/x11/xfonts.c @@ -28,6 +28,7 @@ * Copyright (C) 1995 Thorsten.Ohl @ Physik.TH-Darmstadt.de */ +#include stdio.h #include glxheader.h #include main/context.h #include main/imports.h diff --git a/src/mesa/drivers/x11/xm_api.c b/src/mesa/drivers/x11/xm_api.c index 89c219e..681b81a 100644 --- a/src/mesa/drivers/x11/xm_api.c +++ b/src/mesa/drivers/x11/xm_api.c @@ -62,6 +62,7 @@ #undef __WIN32__ #endif +#include stdio.h #include glxheader.h #include xmesaP.h #include main/api_exec.h diff --git a/src/mesa/drivers/x11/xm_tri.c b/src/mesa/drivers/x11/xm_tri.c index 528d10b..da26235 100644 --- a/src/mesa/drivers/x11/xm_tri.c +++ b/src/mesa/drivers/x11/xm_tri.c @@ -30,6 +30,7 @@ */ +#include stdio.h #include c99_math.h #include main/imports.h #include main/mtypes.h -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 6/7] mapi: use c11 call_once() instead of pthread_once()
---
src/mapi/glapi/glapi_entrypoint.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/mapi/glapi/glapi_entrypoint.c
b/src/mapi/glapi/glapi_entrypoint.c
index 53104ce..7facd8a 100644
--- a/src/mapi/glapi/glapi_entrypoint.c
+++ b/src/mapi/glapi/glapi_entrypoint.c
@@ -29,6 +29,7 @@
*/
+#include c11/threads.h
#include glapi/glapi_priv.h
#include u_execmem.h
@@ -336,7 +337,7 @@ void
init_glapi_relocs_once( void )
{
#if defined(HAVE_PTHREAD) || defined(GLX_USE_TLS)
- static pthread_once_t once_control = PTHREAD_ONCE_INIT;
- pthread_once( once_control, init_glapi_relocs );
+ static once_flag flag = ONCE_FLAG_INIT;
+ call_once(flag, init_glapi_relocs);
#endif
}
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/7] mesa: remove THREADS check, printf calls in debug.c
THREADS is going away in the next commit. --- src/mesa/main/debug.c | 5 - 1 file changed, 5 deletions(-) diff --git a/src/mesa/main/debug.c b/src/mesa/main/debug.c index eda4937..b50d79e 100644 --- a/src/mesa/main/debug.c +++ b/src/mesa/main/debug.c @@ -118,11 +118,6 @@ void _mesa_print_info( struct gl_context *ctx ) */ _mesa_debug(NULL, Mesa GL_EXTENSIONS = %s\n, ctx-Extensions.String); -#if defined(THREADS) - _mesa_debug(NULL, Mesa thread-safe: YES\n); -#else - _mesa_debug(NULL, Mesa thread-safe: NO\n); -#endif #if defined(USE_X86_ASM) _mesa_debug(NULL, Mesa x86-optimized: YES\n); #else -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] nesa-10.4.4: gallivm/lp_bld_misc.cpp:503:38: error: no viable conversion from 'ShaderMemoryManager *' to 'std::unique_ptrRTDyldMemoryManager'
On Wed, Mar 4, 2015 at 3:00 AM, Emil Velikov emil.l.veli...@gmail.com wrote: On 27 February 2015 at 23:28, Sedat Dilek sedat.di...@gmail.com wrote: On Mon, Feb 9, 2015 at 6:30 PM, Emil Velikov emil.l.veli...@gmail.com wrote: On 07/02/15 21:44, Sedat Dilek wrote: Hi, I was building mesa v10.4.4 with my llvm-toolchain v3.6.0rc2. My build breaks like this... ... Please cherry-pick... commit ef7e0b39a24966526b102643523feac765771842 gallivm: Update for RTDyldMemoryManager becoming an unique_ptr. ..for mesa 10.4 Git branch. Hi Sedat, Picking a fix in a stable branch against a non-final release sounds like a no-go in our books. As the official llvm 3.6 rolls out we'll pick this fix for the stable branches - until then I would recommend (a) applying it locally or (b) using mesa from the 10.5 or master branch. Just FYI... [LLVMdev] LLVM 3.6 Release (see [1]). Please pick this patch for-10.4, thanks. As promised, mesa 10.4.6 will feature this. Thanks for the reminder. Thanks. One patch less I have to care in my local Git branches :-). - Sedat - ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965/hsw: Implement end of batch workaround
This patch can cause an infinite recursion if the previous patch titled, i965:
Track finished batch state isn't present (backporters take notice).
v2: Sent out the wrong patch originally. This patches switches the order of
flushes, doing the generic flush before the CC_STATE, and the required
workaround flush afterwards
v3: Only perform workaround for render ring
Add text to the BATCH_RESERVE comments
Cc: Kenneth Graunke kenn...@whitecape.org
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 17 +
src/mesa/drivers/dri/i965/intel_batchbuffer.h | 4
2 files changed, 21 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
index 8b097c8..e4ad6b9 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
@@ -32,6 +32,7 @@
#include intel_buffers.h
#include intel_fbo.h
#include brw_context.h
+#include brw_defines.h
static void
intel_batchbuffer_reset(struct brw_context *brw);
@@ -218,6 +219,22 @@ brw_finish_batch(struct brw_context *brw)
if (brw-batch.ring == RENDER_RING)
brw_perf_monitor_finish_batch(brw);
+ if (brw-is_haswell brw-batch.ring == RENDER_RING) {
+ /* SW must program 3DSTATE_CC_STATE_POINTERS command at the end of every
+ * 3D batch buffer followed by a PIPE_CONTROL with RC flush and CS stall.
+ *
+ * From the example in the docs, it seems to expect a regular pipe
control
+ * flush here as well. We may have done it already, but meh.
+ */
+ intel_batchbuffer_emit_mi_flush(brw);
+ BEGIN_BATCH(2);
+ OUT_BATCH(_3DSTATE_CC_STATE_POINTERS 16 | (2 - 2));
+ OUT_BATCH(brw-cc.state_offset | 1);
+ ADVANCE_BATCH();
+ brw_emit_pipe_control_flush(brw, PIPE_CONTROL_RENDER_TARGET_FLUSH |
+ PIPE_CONTROL_CS_STALL);
+ }
+
/* Mark that the current program cache BO has been used by the GPU.
* It will be reallocated if we need to put new programs in for the
* next batch.
diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.h
b/src/mesa/drivers/dri/i965/intel_batchbuffer.h
index 7bdd836..5cc4d7f 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.h
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.h
@@ -26,6 +26,10 @@ extern C {
* - 3 DWords for MI_REPORT_PERF_COUNT itself on Gen6+. == 12 bytes.
* On Ironlake, it's 6 DWords, but we have some slack due to the lack of
* Sandybridge PIPE_CONTROL madness.
+ * - CC_STATE workaround on HSW (12 * 4 = 48 bytes)
+ * - 5 dwords for initial mi_flush
+ * - 2 dwords for CC state setup
+ * - 5 dwords for the required pipe control at the end
*/
#define BATCH_RESERVED 146
--
2.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89364] c99_alloca.h:40:22: fatal error: alloca.h: No such file or directory
https://bugs.freedesktop.org/show_bug.cgi?id=89364 Vinson Lee v...@freedesktop.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Vinson Lee v...@freedesktop.org --- I no longer see this specific build error. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/6] main: assert(texImage) in ARB_DSA texture cube map functions.
ARB_direct_state_access functions that deal with texture cube
maps need to make sure that texture images are not NULL before operating on
them. In the following cases, the error check functions already throw an
error if texImage == NULL, so an assert can be raised instead.
v2: Review from Anuj Phogat
- Replace redundant if (!texImage) return; statements with
assert(texImage)
---
src/mesa/main/texgetimage.c | 5 +++--
src/mesa/main/teximage.c| 5 +++--
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/src/mesa/main/texgetimage.c b/src/mesa/main/texgetimage.c
index 0287ebf..9411db8 100644
--- a/src/mesa/main/texgetimage.c
+++ b/src/mesa/main/texgetimage.c
@@ -1101,6 +1101,8 @@ _mesa_GetTextureImage(GLuint texture, GLint level, GLenum
format,
/* Copy each face. */
for (i = 0; i 6; ++i) {
texImage = texObj-Image[i][level];
+ assert(texImage);
+
_mesa_get_texture_image(ctx, texObj, texImage, texObj-Target, level,
format, type, bufSize, pixels, true);
@@ -1306,8 +1308,7 @@ _mesa_GetCompressedTextureImage(GLuint texture, GLint
level,
/* Copy each face. */
for (i = 0; i 6; ++i) {
texImage = texObj-Image[i][level];
- if (!texImage)
-return;
+ assert(texImage);
_mesa_get_compressed_texture_image(ctx, texObj, texImage,
texObj-Target, level,
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index cb1c81a..92e2371 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -3677,6 +3677,8 @@ texturesubimage(struct gl_context *ctx, GLuint dims,
/* Copy in each face. */
for (i = 0; i 6; ++i) {
texImage = texObj-Image[i][level];
+ assert(texImage);
+
_mesa_texture_sub_image(ctx, 3, texObj, texImage, texObj-Target,
level, xoffset, yoffset, zoffset,
width, height, 1, format,
@@ -3686,8 +3688,7 @@ texturesubimage(struct gl_context *ctx, GLuint dims,
}
else {
texImage = _mesa_select_tex_image(texObj, texObj-Target, level);
- if (!texImage)
- return;
+ assert(texImage);
_mesa_texture_sub_image(ctx, dims, texObj, texImage, texObj-Target,
level, xoffset, yoffset, zoffset,
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/6] main: Remove redundant copy of cube map block comment in GetTextureImage.
The comment describing why ARB_direct_state_access texture cube map functions
use _mesa_cube_level_complete is very long. To save room in the files,
readers are now referred to one central comment on texturesubimage in
teximage.c.
v2: Review from Anuj Phogat
- Remove redundant copies of the cube map block comment
---
src/mesa/main/texgetimage.c | 32 +++-
1 file changed, 3 insertions(+), 29 deletions(-)
diff --git a/src/mesa/main/texgetimage.c b/src/mesa/main/texgetimage.c
index 42044dd..0287ebf 100644
--- a/src/mesa/main/texgetimage.c
+++ b/src/mesa/main/texgetimage.c
@@ -1088,35 +1088,9 @@ _mesa_GetTextureImage(GLuint texture, GLint level,
GLenum format,
/* Must handle special case GL_TEXTURE_CUBE_MAP. */
if (texObj-Target == GL_TEXTURE_CUBE_MAP) {
- /*
- * What do we do if the user created a texture with the following code
- * and then called this function with its handle?
- *
- *GLuint tex;
- *glCreateTextures(GL_TEXTURE_CUBE_MAP, 1, tex);
- *glBindTexture(GL_TEXTURE_CUBE_MAP, tex);
- *glTexImage2D(GL_TEXTURE_CUBE_MAP_POSITIVE_X, 0, ...);
- *glTexImage2D(GL_TEXTURE_CUBE_MAP_NEGATIVE_X, 0, ...);
- *glTexImage2D(GL_TEXTURE_CUBE_MAP_POSITIVE_Y, 0, ...);
- *// Note: GL_TEXTURE_CUBE_MAP_NEGATIVE_Y not set, or given the
- *// wrong format, or given the wrong size, etc.
- *glTexImage2D(GL_TEXTURE_CUBE_MAP_POSITIVE_Z, 0, ...);
- *glTexImage2D(GL_TEXTURE_CUBE_MAP_NEGATIVE_Z, 0, ...);
- *
- * A bug has been filed against the spec for this case. In the
- * meantime, we will check for cube completeness.
- *
- * According to Section 8.17 Texture Completeness in the OpenGL 4.5
- * Core Profile spec (30.10.2014):
- *[A] cube map texture is cube complete if the
- *following conditions all hold true: The [base level] texture
- *images of each of the six cube map faces have identical, positive,
- *and square dimensions. The [base level] images were each specified
- *with the same internal format.
- *
- * It seems reasonable to check for cube completeness of an arbitrary
- * level here so that the returned data has a consistent format and size
- * and therefore fits in the user's buffer.
+ /* Make sure the texture object is a proper cube.
+ * (See texturesubimage in teximage.c for details on why this check is
+ * performed.)
*/
if (!_mesa_cube_level_complete(texObj, level)) {
_mesa_error(ctx, GL_INVALID_OPERATION,
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/6] main: Add TEXTURE_CUBE_MAP support for glCompressedTextureSubImage3D.
v2: Review from Anuj Phogat
- Remove redundant copies of the cube map block comment
- Replace redundant if (!texImage) return; statements with
assert(texImage)
---
src/mesa/main/teximage.c | 158 +++
src/mesa/main/teximage.h | 3 +-
2 files changed, 133 insertions(+), 28 deletions(-)
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 92e2371..345a8ff 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -4735,30 +4735,19 @@ _mesa_CompressedTexImage3D(GLenum target, GLint level,
void
_mesa_compressed_texture_sub_image(struct gl_context *ctx, GLuint dims,
struct gl_texture_object *texObj,
+ struct gl_texture_image *texImage,
GLenum target, GLint level,
GLint xoffset, GLint yoffset,
GLint zoffset,
GLsizei width, GLsizei height,
GLsizei depth,
GLenum format, GLsizei imageSize,
- const GLvoid *data, bool dsa)
+ const GLvoid *data)
{
- struct gl_texture_image *texImage;
-
- if (compressed_subtexture_error_check(ctx, dims, texObj, target,
- level, xoffset, yoffset, zoffset,
- width, height, depth,
- format, imageSize, dsa)) {
- return;
- }
-
FLUSH_VERTICES(ctx, 0);
_mesa_lock_texture(ctx, texObj);
{
- texImage = _mesa_select_tex_image(texObj, target, level);
- assert(texImage);
-
if (width 0 height 0 depth 0) {
ctx-Driver.CompressedTexSubImage(ctx, dims, texImage,
xoffset, yoffset, zoffset,
@@ -4782,6 +4771,8 @@ _mesa_CompressedTexSubImage1D(GLenum target, GLint level,
GLint xoffset,
GLsizei imageSize, const GLvoid *data)
{
struct gl_texture_object *texObj;
+ struct gl_texture_image *texImage;
+
GET_CURRENT_CONTEXT(ctx);
if (compressed_subtexture_target_check(ctx, target, 1, format, false,
@@ -4793,9 +4784,19 @@ _mesa_CompressedTexSubImage1D(GLenum target, GLint
level, GLint xoffset,
if (!texObj)
return;
- _mesa_compressed_texture_sub_image(ctx, 1, texObj, target, level,
+ if (compressed_subtexture_error_check(ctx, 1, texObj, target,
+ level, xoffset, 0, 0,
+ width, 1, 1,
+ format, imageSize, false)) {
+ return;
+ }
+
+ texImage = _mesa_select_tex_image(texObj, target, level);
+ assert(texImage);
+
+ _mesa_compressed_texture_sub_image(ctx, 1, texObj, texImage, target, level,
xoffset, 0, 0, width, 1, 1,
- format, imageSize, data, false);
+ format, imageSize, data);
}
void GLAPIENTRY
@@ -4804,6 +4805,8 @@ _mesa_CompressedTextureSubImage1D(GLuint texture, GLint
level, GLint xoffset,
GLsizei imageSize, const GLvoid *data)
{
struct gl_texture_object *texObj;
+ struct gl_texture_image *texImage;
+
GET_CURRENT_CONTEXT(ctx);
texObj = _mesa_lookup_texture_err(ctx, texture,
@@ -4817,9 +4820,20 @@ _mesa_CompressedTextureSubImage1D(GLuint texture, GLint
level, GLint xoffset,
return;
}
- _mesa_compressed_texture_sub_image(ctx, 1, texObj, texObj-Target, level,
+ if (compressed_subtexture_error_check(ctx, 1, texObj, texObj-Target,
+ level, xoffset, 0, 0,
+ width, 1, 1,
+ format, imageSize, true)) {
+ return;
+ }
+
+ texImage = _mesa_select_tex_image(texObj, texObj-Target, level);
+ assert(texImage);
+
+ _mesa_compressed_texture_sub_image(ctx, 1, texObj, texImage,
+ texObj-Target, level,
xoffset, 0, 0, width, 1, 1,
- format, imageSize, data, true);
+ format, imageSize, data);
}
@@ -4830,6 +4844,8 @@ _mesa_CompressedTexSubImage2D(GLenum target, GLint level,
GLint xoffset,
const GLvoid *data)
{
struct gl_texture_object *texObj;
+ struct gl_texture_image *texImage;
+
GET_CURRENT_CONTEXT(ctx);
if (compressed_subtexture_target_check(ctx, target, 2, format, false,
@@ -4841,9 +4857,20 @@ _mesa_CompressedTexSubImage2D(GLenum target, GLint
level, GLint xoffset,
if (!texObj)
return;
- _mesa_compressed_texture_sub_image(ctx, 2, texObj, target, level,
[Mesa-dev] [PATCH] Fix invalid extern C around header inclusion.
System headers may contain C++ declarations, which cannot be given C
linkage. For this reason, include statements should never occur
inside extern C.
This patch moves the C linkage statements to enclose only the
declarations within a single header.
---
src/gallium/auxiliary/util/u_math.h | 11 +--
src/gallium/drivers/r600/r600_shader.h | 12
src/gallium/drivers/r600/sb/sb_bc.h | 2 --
src/gallium/drivers/r600/sb/sb_bc_parser.cpp | 2 --
src/gallium/drivers/r600/sb/sb_core.cpp | 2 --
src/gallium/drivers/r600/sb/sb_public.h | 12
src/glx/indirect_init.h | 8
src/glx/tests/indirect_api.cpp | 2 --
src/mapi/shared-glapi/tests/check_table.cpp | 2 --
src/mesa/drivers/common/driverfuncs.h| 7 +++
src/mesa/drivers/dri/i965/brw_fs.cpp | 3 ---
src/mesa/drivers/dri/i965/brw_fs_channel_expressions.cpp | 2 --
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 3 ---
src/mesa/drivers/dri/i965/brw_fs_vector_splitting.cpp| 2 --
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 3 ---
src/mesa/drivers/dri/i965/brw_shader.cpp | 2 --
src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp | 3 ---
src/mesa/drivers/dri/i965/brw_wm.h | 8
src/mesa/main/api_exec.h | 7 +++
src/mesa/main/tests/dispatch_sanity.cpp | 2 --
src/mesa/main/tests/program_state_string.cpp | 2 --
src/mesa/main/vtxfmt.h | 8
src/mesa/vbo/vbo.h | 8
src/mesa/vbo/vbo_context.h | 8
src/util/Makefile.am | 3 +++
src/util/register_allocate.h | 10 ++
26 files changed, 96 insertions(+), 38 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_math.h
b/src/gallium/auxiliary/util/u_math.h
index 5400fce..8f62cac 100644
--- a/src/gallium/auxiliary/util/u_math.h
+++ b/src/gallium/auxiliary/util/u_math.h
@@ -41,12 +41,6 @@
#include pipe/p_compiler.h
-
-#ifdef __cplusplus
-extern C {
-#endif
-
-
#include c99_math.h
#include float.h
#include stdarg.h
@@ -56,6 +50,11 @@ extern C {
#endif
+#ifdef __cplusplus
+extern C {
+#endif
+
+
#ifndef M_SQRT2
#define M_SQRT2 1.41421356237309504880
#endif
diff --git a/src/gallium/drivers/r600/r600_shader.h
b/src/gallium/drivers/r600/r600_shader.h
index b2559e9..dd359d7 100644
--- a/src/gallium/drivers/r600/r600_shader.h
+++ b/src/gallium/drivers/r600/r600_shader.h
@@ -25,6 +25,12 @@
#include r600_asm.h
+
+#ifdef __cplusplus
+extern C {
+#endif
+
+
struct r600_shader_io {
unsignedname;
unsignedgpr;
@@ -125,4 +131,10 @@ struct r600_pipe_shader {
TGSI_INTERPOLATE_LOC_CENTER/SAMPLE/COUNT. Other input values return -1. */
int eg_get_interpolator_index(unsigned interpolate, unsigned location);
+
+#ifdef __cplusplus
+} // extern C
+#endif
+
+
#endif
diff --git a/src/gallium/drivers/r600/sb/sb_bc.h
b/src/gallium/drivers/r600/sb/sb_bc.h
index 072d8f8..ab988f8 100644
--- a/src/gallium/drivers/r600/sb/sb_bc.h
+++ b/src/gallium/drivers/r600/sb/sb_bc.h
@@ -27,10 +27,8 @@
#ifndef SB_BC_H_
#define SB_BC_H_
-extern C {
#include stdint.h
#include r600_isa.h
-}
#include cstdio
#include string
diff --git a/src/gallium/drivers/r600/sb/sb_bc_parser.cpp
b/src/gallium/drivers/r600/sb/sb_bc_parser.cpp
index 403f938..08e7f5c 100644
--- a/src/gallium/drivers/r600/sb/sb_bc_parser.cpp
+++ b/src/gallium/drivers/r600/sb/sb_bc_parser.cpp
@@ -32,10 +32,8 @@
#define BCP_DUMP(q)
#endif
-extern C {
#include r600_pipe.h
#include r600_shader.h
-}
#include stack
diff --git a/src/gallium/drivers/r600/sb/sb_core.cpp
b/src/gallium/drivers/r600/sb/sb_core.cpp
index 9fd9d9a..7db8008 100644
--- a/src/gallium/drivers/r600/sb/sb_core.cpp
+++ b/src/gallium/drivers/r600/sb/sb_core.cpp
@@ -26,13 +26,11 @@
#define SB_RA_SCHED_CHECK DEBUG
-extern C {
#include os/os_time.h
#include r600_pipe.h
#include r600_shader.h
#include sb_public.h
-}
#include stack
#include map
diff --git a/src/gallium/drivers/r600/sb/sb_public.h
b/src/gallium/drivers/r600/sb/sb_public.h
index c9f5f97..a90771f 100644
--- a/src/gallium/drivers/r600/sb/sb_public.h
+++ b/src/gallium/drivers/r600/sb/sb_public.h
@@ -27,6 +27,12 @@
#ifndef R600_SB_H_
#define R600_SB_H_
+
+#ifdef __cplusplus
+extern C {
+#endif
+
+
struct r600_shader;
void r600_sb_context_destroy(void *sctx);
@@ -37,4 +43,10 @@ int r600_sb_bytecode_process(struct r600_context *rctx,
int dump_source_bytecode,
int optimize);
+
+#ifdef
Re: [Mesa-dev] [PATCH] i965: Tell intel_get_memcpy() which direction the memcpy() is going.
On Wed, Mar 4, 2015 at 4:56 PM, Matt Turner matts...@gmail.com wrote:
The SSSE3 swizzling code was written for fast uploads to the GPU and
assumed the destination was always 16-byte aligned. When we began using
this code for fast downloads as well we didn't do anything to account
for the fact that the destination pointer given by glReadPixels() or
glGetTexImage() is not guaranteed to be suitably aligned.
With SSSE3 enabled (at compile-time), some applications would crash when
an SSE aligned-store instruction tried to store to an unaligned
destination (or an assertion that the destination is aligned would
trigger).
To remedy this, tell intel_get_memcpy() whether we're uploading or
downloading so that it can select whether to assume the destination or
source is aligned, respectively.
Cc: 10.5 mesa-sta...@lists.freedesktop.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89416
Tested-by: Uriy Zhuravlev stalk...@gmail.com [v1]
Reviewed-by: Jason Ekstrand jason.ekstr...@intel.com
---
Benchmarks I should run?
I'm not worried about it. Maybe changing from aligned to unaligned reads
makes more or less of a difference than changing writes.
src/mesa/drivers/dri/i965/intel_pixel_read.c | 3 +-
src/mesa/drivers/dri/i965/intel_tex_image.c| 3 +-
src/mesa/drivers/dri/i965/intel_tex_subimage.c | 3 +-
src/mesa/drivers/dri/i965/intel_tiled_memcpy.c | 140
++---
src/mesa/drivers/dri/i965/intel_tiled_memcpy.h | 15 ++-
5 files changed, 122 insertions(+), 42 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_pixel_read.c
b/src/mesa/drivers/dri/i965/intel_pixel_read.c
index df22a63..0972121 100644
--- a/src/mesa/drivers/dri/i965/intel_pixel_read.c
+++ b/src/mesa/drivers/dri/i965/intel_pixel_read.c
@@ -139,7 +139,8 @@ intel_readpixels_tiled_memcpy(struct gl_context * ctx,
rb-Format == MESA_FORMAT_R8G8B8X8_UNORM)
return false;
- if (!intel_get_memcpy(rb-Format, format, type, mem_copy, cpp))
+ if (!intel_get_memcpy(rb-Format, format, type, mem_copy, cpp,
+ INTEL_DOWNLOAD))
return false;
if (!irb-mt ||
diff --git a/src/mesa/drivers/dri/i965/intel_tex_image.c
b/src/mesa/drivers/dri/i965/intel_tex_image.c
index da42fdd..00bf9ce 100644
--- a/src/mesa/drivers/dri/i965/intel_tex_image.c
+++ b/src/mesa/drivers/dri/i965/intel_tex_image.c
@@ -408,7 +408,8 @@ intel_gettexsubimage_tiled_memcpy(struct gl_context
*ctx,
texImage-TexFormat == MESA_FORMAT_R8G8B8X8_UNORM)
return false;
- if (!intel_get_memcpy(texImage-TexFormat, format, type, mem_copy,
cpp))
+ if (!intel_get_memcpy(texImage-TexFormat, format, type, mem_copy,
cpp,
+ INTEL_DOWNLOAD))
return false;
/* If this is a nontrivial texture view, let another path handle it
instead. */
diff --git a/src/mesa/drivers/dri/i965/intel_tex_subimage.c
b/src/mesa/drivers/dri/i965/intel_tex_subimage.c
index 4262f71..909ff25 100644
--- a/src/mesa/drivers/dri/i965/intel_tex_subimage.c
+++ b/src/mesa/drivers/dri/i965/intel_tex_subimage.c
@@ -118,7 +118,8 @@ intel_texsubimage_tiled_memcpy(struct gl_context * ctx,
packing-Invert)
return false;
- if (!intel_get_memcpy(texImage-TexFormat, format, type, mem_copy,
cpp))
+ if (!intel_get_memcpy(texImage-TexFormat, format, type, mem_copy,
cpp,
+ INTEL_UPLOAD))
return false;
/* If this is a nontrivial texture view, let another path handle it
instead. */
diff --git a/src/mesa/drivers/dri/i965/intel_tiled_memcpy.c
b/src/mesa/drivers/dri/i965/intel_tiled_memcpy.c
index f2b35cb..dcf0462 100644
--- a/src/mesa/drivers/dri/i965/intel_tiled_memcpy.c
+++ b/src/mesa/drivers/dri/i965/intel_tiled_memcpy.c
@@ -60,42 +60,79 @@ static const uint32_t ytile_span = 16;
static const uint8_t rgba8_permutation[16] =
{ 2,1,0,3, 6,5,4,7, 10,9,8,11, 14,13,12,15 };
-/* NOTE: dst must be 16 byte aligned */
-#define rgba8_copy_16(dst, src) \
- *(__m128i *)(dst) = _mm_shuffle_epi8(\
- (__m128i) _mm_loadu_ps((float *)(src)), \
- *(__m128i *) rgba8_permutation\
- )
+/* NOTE: dst must be 16-byte aligned. src may be unaligned. */
+#define rgba8_copy_16_aligned_dst(dst, src)\
+ _mm_store_si128((__m128i *)(dst), \
+ _mm_shuffle_epi8(_mm_loadu_si128((__m128i *)(src)), \
+*(__m128i *) rgba8_permutation))
+
+/* NOTE: src must be 16-byte aligned. dst may be unaligned. */
+#define rgba8_copy_16_aligned_src(dst, src)\
+ _mm_storeu_si128((__m128i *)(dst), \
+_mm_shuffle_epi8(_mm_load_si128((__m128i *)(src)), \
+ *(__m128i *) rgba8_permutation))
#endif
/**
- * Copy RGBA
Re: [Mesa-dev] [PATCH] i965: Tell intel_get_memcpy() which direction the memcpy() is going.
On Wed, Mar 4, 2015 at 5:07 PM, Jason Ekstrand ja...@jlekstrand.net wrote: On Wed, Mar 4, 2015 at 4:56 PM, Matt Turner matts...@gmail.com wrote: @@ -357,16 +394,22 @@ linear_to_xtiled_faster(uint32_t x0, uint32_t x1, uint32_t x2, uint32_t x3, if (mem_copy == memcpy) return linear_to_xtiled(0, 0, xtile_width, xtile_width, 0, xtile_height, dst, src, src_pitch, swizzle_bit, memcpy); - else if (mem_copy == rgba8_copy) + else if (mem_copy == rgba8_copy_aligned_dst) return linear_to_xtiled(0, 0, xtile_width, xtile_width, 0, xtile_height, - dst, src, src_pitch, swizzle_bit, rgba8_copy); + dst, src, src_pitch, swizzle_bit, + rgba8_copy_aligned_dst); + else + unreachable(not reached); I'm not sure what I think about the unreachable here. The original versions of the *_faster functions would work regardless of what memcpy you passed in. Well, yeah, but there were only two. :) The *_faster was only to force the compiler to inline the universe in the case where we knew some parameters. Adding unreachable changes that. Oh, I didn't know what you meant, until I realized that the if-elseif is supposed to fall through to another function call in the case that mem_copy wasn't matched. At the very least I should split that out into a separate patch. Using unreachable(), if it's safe, cuts more than 1k of text: text databssdechex filename 9663 0 0 9663 25bf .libs/intel_tiled_memcpy.o 8215 0 0 8215 2017 .libs/intel_tiled_memcpy.o I'll drop the unreachable()s from this patch. That said, we never call them with anything other than memcpy or rgba8_copy_aligned_* so it's probably ok. I think I'm ok with it with or without the unreachable()'s. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Tell intel_get_memcpy() which direction the memcpy() is going.
On Wed, Mar 4, 2015 at 4:19 PM, Matt Turner matts...@gmail.com wrote:
The SSSE3 swizzling code was written for fast uploads to the GPU and
assumed the destination was always 16-byte aligned. When we began using
this code for fast downloads as well we didn't do anything to account
for the fact that the destination pointer given by glReadPixels() or
glGetTexImage() is not guaranteed to be suitably aligned.
With SSSE3 enabled (at compile-time), some applications would crash when
an SSE aligned-store instruction tried to store to an unaligned
destination (or an assertion that the destination is aligned would
trigger).
To remedy this, tell intel_get_memcpy() whether we're uploading or
downloading so that it can select whether to assume the destination or
source is aligned, respectively.
Cc: 10.5 mesa-sta...@lists.freedesktop.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89416
---
I don't know what benchmarks I should run to test this code?
src/mesa/drivers/dri/i965/intel_pixel_read.c | 3 +-
src/mesa/drivers/dri/i965/intel_tex_image.c| 3 +-
src/mesa/drivers/dri/i965/intel_tex_subimage.c | 3 +-
src/mesa/drivers/dri/i965/intel_tiled_memcpy.c | 156
+++--
src/mesa/drivers/dri/i965/intel_tiled_memcpy.h | 15 ++-
5 files changed, 138 insertions(+), 42 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_pixel_read.c
b/src/mesa/drivers/dri/i965/intel_pixel_read.c
index df22a63..0972121 100644
--- a/src/mesa/drivers/dri/i965/intel_pixel_read.c
+++ b/src/mesa/drivers/dri/i965/intel_pixel_read.c
@@ -139,7 +139,8 @@ intel_readpixels_tiled_memcpy(struct gl_context * ctx,
rb-Format == MESA_FORMAT_R8G8B8X8_UNORM)
return false;
- if (!intel_get_memcpy(rb-Format, format, type, mem_copy, cpp))
+ if (!intel_get_memcpy(rb-Format, format, type, mem_copy, cpp,
+ INTEL_DOWNLOAD))
return false;
if (!irb-mt ||
diff --git a/src/mesa/drivers/dri/i965/intel_tex_image.c
b/src/mesa/drivers/dri/i965/intel_tex_image.c
index da42fdd..a3312d2 100644
--- a/src/mesa/drivers/dri/i965/intel_tex_image.c
+++ b/src/mesa/drivers/dri/i965/intel_tex_image.c
@@ -408,7 +408,8 @@ intel_gettexsubimage_tiled_memcpy(struct gl_context
*ctx,
texImage-TexFormat == MESA_FORMAT_R8G8B8X8_UNORM)
return false;
- if (!intel_get_memcpy(texImage-TexFormat, format, type, mem_copy,
cpp))
+ if (!intel_get_memcpy(texImage-TexFormat, format, type, mem_copy,
cpp,
+ INTEL_UPLOAD))
Should be INTEL_DOWNLOAD
return false;
/* If this is a nontrivial texture view, let another path handle it
instead. */
diff --git a/src/mesa/drivers/dri/i965/intel_tex_subimage.c
b/src/mesa/drivers/dri/i965/intel_tex_subimage.c
index 4262f71..909ff25 100644
--- a/src/mesa/drivers/dri/i965/intel_tex_subimage.c
+++ b/src/mesa/drivers/dri/i965/intel_tex_subimage.c
@@ -118,7 +118,8 @@ intel_texsubimage_tiled_memcpy(struct gl_context * ctx,
packing-Invert)
return false;
- if (!intel_get_memcpy(texImage-TexFormat, format, type, mem_copy,
cpp))
+ if (!intel_get_memcpy(texImage-TexFormat, format, type, mem_copy,
cpp,
+ INTEL_UPLOAD))
return false;
/* If this is a nontrivial texture view, let another path handle it
instead. */
diff --git a/src/mesa/drivers/dri/i965/intel_tiled_memcpy.c
b/src/mesa/drivers/dri/i965/intel_tiled_memcpy.c
index f2b35cb..c43383b 100644
--- a/src/mesa/drivers/dri/i965/intel_tiled_memcpy.c
+++ b/src/mesa/drivers/dri/i965/intel_tiled_memcpy.c
@@ -60,42 +60,79 @@ static const uint32_t ytile_span = 16;
static const uint8_t rgba8_permutation[16] =
{ 2,1,0,3, 6,5,4,7, 10,9,8,11, 14,13,12,15 };
-/* NOTE: dst must be 16 byte aligned */
-#define rgba8_copy_16(dst, src) \
- *(__m128i *)(dst) = _mm_shuffle_epi8(\
- (__m128i) _mm_loadu_ps((float *)(src)), \
- *(__m128i *) rgba8_permutation\
- )
+/* NOTE: dst must be 16-byte aligned. src may be unaligned. */
+#define rgba8_copy_16_aligned_dst(dst, src)\
+ _mm_store_si128((__m128i *)(dst), \
+ _mm_shuffle_epi8(_mm_loadu_si128((__m128i *)(src)), \
+*(__m128i *) rgba8_permutation))
+
+/* NOTE: src must be 16-byte aligned. dst may be unaligned. */
+#define rgba8_copy_16_aligned_src(dst, src)\
+ _mm_storeu_si128((__m128i *)(dst), \
+_mm_shuffle_epi8(_mm_load_si128((__m128i *)(src)), \
+ *(__m128i *) rgba8_permutation))
#endif
/**
- * Copy RGBA to BGRA - swap R and B.
+ * Copy RGBA to BGRA - swap R and B, with the destination 16-byte aligned.
*/
static inline void *
-rgba8_copy(void *dst, const void *src, size_t
[Mesa-dev] [PATCH 3/7] main: Refactor _mesa_texture_buffer_range.
Changes how the caller is identified in error messages, moves a check for
ARB_texture_buffer_object from the entry points to the shared code in
_mesa_texture_buffer_range, and removes an unused argument (GLenum target).
v2: Review from Anuj Phogat
- Split rebase of Tex[ture]Buffer[Range]
---
src/mesa/main/teximage.c | 58 ++--
src/mesa/main/teximage.h | 6 ++---
2 files changed, 25 insertions(+), 39 deletions(-)
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 6374ec9..706c76b 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -5243,24 +5243,34 @@ _mesa_validate_texbuffer_format(const struct gl_context
*ctx,
void
_mesa_texture_buffer_range(struct gl_context *ctx,
- struct gl_texture_object *texObj, GLenum target,
+ struct gl_texture_object *texObj,
GLenum internalFormat,
struct gl_buffer_object *bufObj,
- GLintptr offset, GLsizeiptr size, bool range,
- bool dsa)
+ GLintptr offset, GLsizeiptr size,
+ const char *caller)
{
mesa_format format;
- FLUSH_VERTICES(ctx, 0);
+ /* NOTE: ARB_texture_buffer_object has interactions with
+* the compatibility profile that are not implemented.
+*/
+ if (!(ctx-API == API_OPENGL_CORE
+ ctx-Extensions.ARB_texture_buffer_object)) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ %s(ARB_texture_buffer_object is not
+ implemented for the compatibility profile), caller);
+ return;
+ }
format = _mesa_validate_texbuffer_format(ctx, internalFormat);
if (format == MESA_FORMAT_NONE) {
_mesa_error(ctx, GL_INVALID_ENUM,
- glTex%sBuffer%s(internalFormat 0x%x), dsa ? ture : ,
- range ? Range : , internalFormat);
+ %s(internalFormat 0x%x), caller, internalFormat);
return;
}
+ FLUSH_VERTICES(ctx, 0);
+
_mesa_lock_texture(ctx, texObj);
{
_mesa_reference_buffer_object(ctx, texObj-BufferObject, bufObj);
@@ -5294,15 +5304,6 @@ _mesa_TexBuffer(GLenum target, GLenum internalFormat,
GLuint buffer)
return;
}
- /* NOTE: ARB_texture_buffer_object has interactions with
-* the compatibility profile that are not implemented.
-*/
- if (!(ctx-API == API_OPENGL_CORE
- ctx-Extensions.ARB_texture_buffer_object)) {
- _mesa_error(ctx, GL_INVALID_OPERATION, glTexBuffer);
- return;
- }
-
if (buffer) {
bufObj = _mesa_lookup_bufferobj_err(ctx, buffer, glTexBuffer);
if (!bufObj)
@@ -5314,8 +5315,8 @@ _mesa_TexBuffer(GLenum target, GLenum internalFormat,
GLuint buffer)
if (!texObj)
return;
- _mesa_texture_buffer_range(ctx, texObj, target, internalFormat, bufObj, 0,
- buffer ? -1 : 0, false, false);
+ _mesa_texture_buffer_range(ctx, texObj, internalFormat, bufObj, 0,
+ buffer ? -1 : 0, glTexBuffer);
}
@@ -5335,12 +5336,6 @@ _mesa_TexBufferRange(GLenum target, GLenum
internalFormat, GLuint buffer,
return;
}
- if (!(ctx-API == API_OPENGL_CORE
- ctx-Extensions.ARB_texture_buffer_range)) {
- _mesa_error(ctx, GL_INVALID_OPERATION, glTexBufferRange);
- return;
- }
-
bufObj = _mesa_lookup_bufferobj(ctx, buffer);
if (bufObj) {
if (offset 0 ||
@@ -5367,8 +5362,8 @@ _mesa_TexBufferRange(GLenum target, GLenum
internalFormat, GLuint buffer,
if (!texObj)
return;
- _mesa_texture_buffer_range(ctx, texObj, target, internalFormat, bufObj,
- offset, size, true, false);
+ _mesa_texture_buffer_range(ctx, texObj, internalFormat, bufObj,
+ offset, size, glTexBufferRange);
}
void GLAPIENTRY
@@ -5379,15 +5374,6 @@ _mesa_TextureBuffer(GLuint texture, GLenum
internalFormat, GLuint buffer)
GET_CURRENT_CONTEXT(ctx);
- /* NOTE: ARB_texture_buffer_object has interactions with
-* the compatibility profile that are not implemented.
-*/
- if (!(ctx-API == API_OPENGL_CORE
- ctx-Extensions.ARB_texture_buffer_object)) {
- _mesa_error(ctx, GL_INVALID_OPERATION, glTextureBuffer);
- return;
- }
-
if (buffer) {
bufObj = _mesa_lookup_bufferobj_err(ctx, buffer, glTextureBuffer);
if (!bufObj)
@@ -5406,8 +5392,8 @@ _mesa_TextureBuffer(GLuint texture, GLenum
internalFormat, GLuint buffer)
return;
}
- _mesa_texture_buffer_range(ctx, texObj, texObj-Target, internalFormat,
- bufObj, 0, buffer ? -1 : 0, false, true);
+ _mesa_texture_buffer_range(ctx, texObj, internalFormat,
+ bufObj, 0, buffer ? -1 : 0, glTextureBuffer);
}
static GLboolean
diff --git a/src/mesa/main/teximage.h
[Mesa-dev] [PATCH 5/7] main: Add check_texture_buffer_range.
Creates a shared function that TexBufferRange and TextureBufferRange can use
to check the buffer range. This cleans up TexBufferRange considerably.
v2: Review from Anuj Phogat
- Split rebase of Tex[ture]Buffer[Range]
---
src/mesa/main/teximage.c | 73 ++--
1 file changed, 58 insertions(+), 15 deletions(-)
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 22574bd..d9e2c66 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -5289,6 +5289,56 @@ _mesa_texture_buffer_range(struct gl_context *ctx,
}
+/**
+ * Check for errors related to the texture buffer range.
+ * Return false if errors are found, true if none are found.
+ */
+static bool
+check_texture_buffer_range(struct gl_context *ctx,
+ struct gl_buffer_object *bufObj,
+ GLintptr offset, GLsizeiptr size,
+ const char *caller)
+{
+ /* OpenGL 4.5 core spec (02.02.2015) says in Section 8.9 Buffer
+* Textures (PDF page 245):
+*An INVALID_VALUE error is generated if offset is negative, if
+*size is less than or equal to zero, or if offset + size is greater
+*than the value of BUFFER_SIZE for the buffer bound to target.
+*/
+ if (offset 0) {
+ _mesa_error(ctx, GL_INVALID_VALUE, %s(offset=%d 0), caller,
+ (int) offset);
+ return false;
+ }
+
+ if (size = 0) {
+ _mesa_error(ctx, GL_INVALID_VALUE, %s(size=%d = 0), caller,
+ (int) size);
+ return false;
+ }
+
+ if (offset + size bufObj-Size) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ %s(offset=%d + size=%d buffer_size=%d), caller,
+ (int) offset, (int) size, (int) bufObj-Size);
+ return false;
+ }
+
+ /* OpenGL 4.5 core spec (02.02.2015) says in Section 8.9 Buffer
+* Textures (PDF page 245):
+*An INVALID_VALUE error is generated if offset is not an integer
+*multiple of the value of TEXTURE_BUFFER_OFFSET_ALIGNMENT.
+*/
+ if (offset % ctx-Const.TextureBufferOffsetAlignment) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ %s(invalid offset alignment), caller);
+ return false;
+ }
+
+ return true;
+}
+
+
/** GL_ARB_texture_buffer_object */
void GLAPIENTRY
_mesa_TexBuffer(GLenum target, GLenum internalFormat, GLuint buffer)
@@ -5336,23 +5386,15 @@ _mesa_TexBufferRange(GLenum target, GLenum
internalFormat, GLuint buffer,
return;
}
- bufObj = _mesa_lookup_bufferobj(ctx, buffer);
- if (bufObj) {
- if (offset 0 ||
- size = 0 ||
- (offset + size) bufObj-Size) {
- _mesa_error(ctx, GL_INVALID_VALUE, glTexBufferRange);
+ if (buffer) {
+ bufObj = _mesa_lookup_bufferobj_err(ctx, buffer, glTexBufferRange);
+ if (!bufObj)
return;
- }
- if (offset % ctx-Const.TextureBufferOffsetAlignment) {
- _mesa_error(ctx, GL_INVALID_VALUE,
- glTexBufferRange(invalid offset alignment));
+
+ if (!check_texture_buffer_range(ctx, bufObj, offset, size,
+ glTexBufferRange))
return;
- }
- } else if (buffer) {
- _mesa_error(ctx, GL_INVALID_OPERATION, glTexBufferRange(buffer %u),
- buffer);
- return;
+
} else {
/* OpenGL 4.5 core spec (02.02.2015) says in Section 8.9 Buffer
@@ -5364,6 +5406,7 @@ _mesa_TexBufferRange(GLenum target, GLenum
internalFormat, GLuint buffer,
*/
offset = 0;
size = 0;
+ bufObj = NULL;
}
texObj = _mesa_get_current_tex_object(ctx, target);
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/7] main: Use _mesa_lookup_bufferobj_err to simplify Tex[ture]Buffer[Range].
v2: Review from Anuj Phogat
- Split rebase of Tex[ture]Buffer[Range]
- Closing curly brace on the same line as else
---
src/mesa/main/teximage.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 345a8ff..6374ec9 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -5303,11 +5303,12 @@ _mesa_TexBuffer(GLenum target, GLenum internalFormat,
GLuint buffer)
return;
}
- bufObj = _mesa_lookup_bufferobj(ctx, buffer);
- if (!bufObj buffer) {
- _mesa_error(ctx, GL_INVALID_OPERATION, glTexBuffer(buffer %u), buffer);
- return;
- }
+ if (buffer) {
+ bufObj = _mesa_lookup_bufferobj_err(ctx, buffer, glTexBuffer);
+ if (!bufObj)
+ return;
+ } else
+ bufObj = NULL;
texObj = _mesa_get_current_tex_object(ctx, target);
if (!texObj)
@@ -5387,12 +5388,12 @@ _mesa_TextureBuffer(GLuint texture, GLenum
internalFormat, GLuint buffer)
return;
}
- bufObj = _mesa_lookup_bufferobj(ctx, buffer);
- if (!bufObj buffer) {
- _mesa_error(ctx, GL_INVALID_OPERATION, glTextureBuffer(buffer %u),
- buffer);
- return;
- }
+ if (buffer) {
+ bufObj = _mesa_lookup_bufferobj_err(ctx, buffer, glTextureBuffer);
+ if (!bufObj)
+ return;
+ } else
+ bufObj = NULL;
/* Get the texture object by Name. */
texObj = _mesa_lookup_texture_err(ctx, texture,
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/7] main: Cosmetic changes for Texture Buffers.
Adds a useful comment and some whitespace. Fixes an error message.
v2: Review from Anuj Phogat
- Split rebase of Tex[ture]Buffer[Range]
---
src/mesa/main/teximage.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 706c76b..22574bd 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -5354,6 +5354,14 @@ _mesa_TexBufferRange(GLenum target, GLenum
internalFormat, GLuint buffer,
buffer);
return;
} else {
+
+ /* OpenGL 4.5 core spec (02.02.2015) says in Section 8.9 Buffer
+ * Textures (PDF page 254):
+ *If buffer is zero, then any buffer object attached to the buffer
+ *texture is detached, the values offset and size are ignored and
+ *the state for offset and size for the buffer texture are reset to
+ *zero.
+ */
offset = 0;
size = 0;
}
@@ -5382,8 +5390,7 @@ _mesa_TextureBuffer(GLuint texture, GLenum
internalFormat, GLuint buffer)
bufObj = NULL;
/* Get the texture object by Name. */
- texObj = _mesa_lookup_texture_err(ctx, texture,
- glTextureBuffer(texture));
+ texObj = _mesa_lookup_texture_err(ctx, texture, glTextureBuffer);
if (!texObj)
return;
@@ -5396,6 +5403,7 @@ _mesa_TextureBuffer(GLuint texture, GLenum
internalFormat, GLuint buffer)
bufObj, 0, buffer ? -1 : 0, glTextureBuffer);
}
+
static GLboolean
is_renderable_texture_format(struct gl_context *ctx, GLenum internalformat)
{
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 6/7] main: Add check_texture_buffer_target.
Creates a shared function to ensure that texture buffer target is
GL_TEXTURE_BUFFER. Helps to clean up the Tex[ture]Buffer[Range] functions.
v2: Review from Anuj Phogat
- Split rebase of Tex[ture]Buffer[Range]
---
src/mesa/main/teximage.c | 39 ---
1 file changed, 28 insertions(+), 11 deletions(-)
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index d9e2c66..2b981ff 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -5290,6 +5290,25 @@ _mesa_texture_buffer_range(struct gl_context *ctx,
/**
+ * Make sure the texture buffer target is GL_TEXTURE_BUFFER.
+ * Return true if it is, and return false if it is not
+ * (and throw INVALID ENUM as dictated in the OpenGL 4.5
+ * core spec, 02.02.2015, PDF page 245).
+ */
+static bool
+check_texture_buffer_target(struct gl_context *ctx, GLenum target,
+const char *caller)
+{
+ if (target != GL_TEXTURE_BUFFER_ARB) {
+ _mesa_error(ctx, GL_INVALID_ENUM,
+ %s(texture target is not GL_TEXTURE_BUFFER), caller);
+ return false;
+ }
+ else
+ return true;
+}
+
+/**
* Check for errors related to the texture buffer range.
* Return false if errors are found, true if none are found.
*/
@@ -5348,11 +5367,11 @@ _mesa_TexBuffer(GLenum target, GLenum internalFormat,
GLuint buffer)
GET_CURRENT_CONTEXT(ctx);
- /* Need to catch this before it gets to _mesa_get_current_tex_object */
- if (target != GL_TEXTURE_BUFFER_ARB) {
- _mesa_error(ctx, GL_INVALID_ENUM, glTexBuffer(target));
+ /* Need to catch a bad target before it gets to
+* _mesa_get_current_tex_object.
+*/
+ if (!check_texture_buffer_target(ctx, target, glTexBuffer))
return;
- }
if (buffer) {
bufObj = _mesa_lookup_bufferobj_err(ctx, buffer, glTexBuffer);
@@ -5380,11 +5399,11 @@ _mesa_TexBufferRange(GLenum target, GLenum
internalFormat, GLuint buffer,
GET_CURRENT_CONTEXT(ctx);
- /* Need to catch this before it gets to _mesa_get_current_tex_object */
- if (target != GL_TEXTURE_BUFFER_ARB) {
- _mesa_error(ctx, GL_INVALID_ENUM, glTexBufferRange(target));
+ /* Need to catch a bad target before it gets to
+* _mesa_get_current_tex_object.
+*/
+ if (!check_texture_buffer_target(ctx, target, glTexBufferRange))
return;
- }
if (buffer) {
bufObj = _mesa_lookup_bufferobj_err(ctx, buffer, glTexBufferRange);
@@ -5437,10 +5456,8 @@ _mesa_TextureBuffer(GLuint texture, GLenum
internalFormat, GLuint buffer)
if (!texObj)
return;
- if (texObj-Target != GL_TEXTURE_BUFFER_ARB) {
- _mesa_error(ctx, GL_INVALID_ENUM, glTextureBuffer(target));
+ if (!check_texture_buffer_target(ctx, texObj-Target, glTextureBuffer))
return;
- }
_mesa_texture_buffer_range(ctx, texObj, internalFormat,
bufObj, 0, buffer ? -1 : 0, glTextureBuffer);
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 7/7] main: Add entry point for TextureBufferRange.
v2: Review by Martin Peres
- Get rid of difficult-to-follow code copied and pasted from
the original TexBufferRange
---
src/mapi/glapi/gen/ARB_direct_state_access.xml | 8 +
src/mesa/main/tests/dispatch_sanity.cpp| 1 +
src/mesa/main/teximage.c | 46 ++
src/mesa/main/teximage.h | 4 +++
4 files changed, 59 insertions(+)
diff --git a/src/mapi/glapi/gen/ARB_direct_state_access.xml
b/src/mapi/glapi/gen/ARB_direct_state_access.xml
index 2fe1638..86c00f9 100644
--- a/src/mapi/glapi/gen/ARB_direct_state_access.xml
+++ b/src/mapi/glapi/gen/ARB_direct_state_access.xml
@@ -21,6 +21,14 @@
param name=buffer type=GLuint /
/function
+ function name=TextureBufferRange offset=assign
+ param name=texture type=GLuint /
+ param name=internalformat type=GLenum /
+ param name=buffer type=GLuint /
+ param name=offset type=GLintptr /
+ param name=size type=GLsizeiptr /
+ /function
+
function name=TextureStorage1D offset=assign
param name=texture type=GLuint /
param name=levels type=GLsizei /
diff --git a/src/mesa/main/tests/dispatch_sanity.cpp
b/src/mesa/main/tests/dispatch_sanity.cpp
index c14ad32..6dddb81 100644
--- a/src/mesa/main/tests/dispatch_sanity.cpp
+++ b/src/mesa/main/tests/dispatch_sanity.cpp
@@ -987,6 +987,7 @@ const struct function gl_core_functions_possible[] = {
{ glTextureStorage2DMultisample, 45, -1 },
{ glTextureStorage3DMultisample, 45, -1 },
{ glTextureBuffer, 45, -1 },
+ { glTextureBufferRange, 45, -1 },
/* GL_EXT_polygon_offset_clamp */
{ glPolygonOffsetClampEXT, 11, -1 },
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 2b981ff..1766123 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -5463,6 +5463,52 @@ _mesa_TextureBuffer(GLuint texture, GLenum
internalFormat, GLuint buffer)
bufObj, 0, buffer ? -1 : 0, glTextureBuffer);
}
+void GLAPIENTRY
+_mesa_TextureBufferRange(GLuint texture, GLenum internalFormat, GLuint buffer,
+ GLintptr offset, GLsizeiptr size)
+{
+ struct gl_texture_object *texObj;
+ struct gl_buffer_object *bufObj;
+
+ GET_CURRENT_CONTEXT(ctx);
+
+ if (buffer) {
+ bufObj = _mesa_lookup_bufferobj_err(ctx, buffer,
+ glTextureBufferRange);
+ if (!bufObj)
+ return;
+
+ if (!check_texture_buffer_range(ctx, bufObj, offset, size,
+ glTextureBufferRange))
+ return;
+
+ } else {
+
+ /* OpenGL 4.5 core spec (02.02.2015) says in Section 8.9 Buffer
+ * Textures (PDF page 254):
+ *If buffer is zero, then any buffer object attached to the buffer
+ *texture is detached, the values offset and size are ignored and
+ *the state for offset and size for the buffer texture are reset to
+ *zero.
+ */
+ offset = 0;
+ size = 0;
+ bufObj = NULL;
+ }
+
+ /* Get the texture object by Name. */
+ texObj = _mesa_lookup_texture_err(ctx, texture, glTextureBufferRange);
+ if (!texObj)
+ return;
+
+ if (!check_texture_buffer_target(ctx, texObj-Target,
+ glTextureBufferRange))
+ return;
+
+ _mesa_texture_buffer_range(ctx, texObj, internalFormat,
+ bufObj, offset, size, glTextureBufferRange);
+}
+
static GLboolean
is_renderable_texture_format(struct gl_context *ctx, GLenum internalformat)
diff --git a/src/mesa/main/teximage.h b/src/mesa/main/teximage.h
index db6b648..0ce4a30 100644
--- a/src/mesa/main/teximage.h
+++ b/src/mesa/main/teximage.h
@@ -409,6 +409,10 @@ _mesa_TexBufferRange(GLenum target, GLenum internalFormat,
GLuint buffer,
extern void GLAPIENTRY
_mesa_TextureBuffer(GLuint texture, GLenum internalFormat, GLuint buffer);
+extern void GLAPIENTRY
+_mesa_TextureBufferRange(GLuint texture, GLenum internalFormat, GLuint buffer,
+ GLintptr offset, GLsizeiptr size);
+
extern void GLAPIENTRY
_mesa_TexImage2DMultisample(GLenum target, GLsizei samples,
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/7] v2 of Tex[ture]Buffer[Range] functions
This divides a major rework of Tex[ture]Buffer[Range] into multiple patches as recommended by Anuj Phogat. Laura Ekstrand (7): main: Add utility function _mesa_lookup_bufferobj_err. main: Use _mesa_lookup_bufferobj_err to simplify Tex[ture]Buffer[Range]. main: Refactor _mesa_texture_buffer_range. main: Cosmetic changes for Texture Buffers. main: Add check_texture_buffer_range. main: Add check_texture_buffer_target. main: Add entry point for TextureBufferRange. src/mapi/glapi/gen/ARB_direct_state_access.xml | 8 + src/mesa/main/bufferobj.c | 19 ++ src/mesa/main/bufferobj.h | 4 + src/mesa/main/tests/dispatch_sanity.cpp| 1 + src/mesa/main/teximage.c | 241 ++--- src/mesa/main/teximage.h | 10 +- 6 files changed, 210 insertions(+), 73 deletions(-) -- 2.1.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 79706] [TRACKER] Mesa regression tracker
https://bugs.freedesktop.org/show_bug.cgi?id=79706 Bug 79706 depends on bug 79098, which changed state. Bug 79098 Summary: x86/common_x86.c:51:19: error: cpuid.h: No such file or directory https://bugs.freedesktop.org/show_bug.cgi?id=79098 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX -- 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 79098] x86/common_x86.c:51:19: error: cpuid.h: No such file or directory
https://bugs.freedesktop.org/show_bug.cgi?id=79098 Matt Turner matts...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Matt Turner matts...@gmail.com --- We don't support gcc-4.1 any 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] i965: Split Gen4-5 BlitFramebuffer code; prefer BLT over Meta.
A while back I switched intel_blit_framebuffer to prefer Meta over the
BLT. This meant that Gen8 platforms would start using the 3D engine
for blits, just like we do on Gen6-7.5.
However, I hadn't considered Gen4-5 when making that change. The BLT
engine appears to be substantially faster on 965GM than using Meta to
drive the 3D engine. This isn't too surprising: original Gen4 doesn't
support tile offsets (that came on G45), and the level/layer fields
don't work for cubemap rendering, so for inconvenient miplevel
alignments, we end up blitting or copying data to/from temporaries
in order to render to it. We may as well just use the blitter.
I chose to use the BLT on Gen4-5 because they use the same ring for
both 3D and BLT; Gen6+ splits it out.
Fixes regressions on 965GM due to botched tile offset code (we should
fix those properly as well, but they're longstanding bugs - for now,
put things back to the status quo).
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89430
Cc: 10.5 mesa-sta...@lists.freedesktop.org
Cc: Mark Janes mark.a.ja...@intel.com
---
src/mesa/drivers/dri/i965/intel_fbo.c | 50 ++-
1 file changed, 49 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/intel_fbo.c
b/src/mesa/drivers/dri/i965/intel_fbo.c
index 04e5030..121c97f 100644
--- a/src/mesa/drivers/dri/i965/intel_fbo.c
+++ b/src/mesa/drivers/dri/i965/intel_fbo.c
@@ -916,6 +916,51 @@ intel_blit_framebuffer(struct gl_context *ctx,
}
/**
+ * Gen4-5 implementation of glBlitFrameBuffer().
+ *
+ * Tries BLT, Meta, then swrast.
+ *
+ * Gen4-5 have a single ring for both 3D and BLT operations, so there's no
+ * inter-ring synchronization issues like on Gen6+. It is apparently faster
+ * than using the 3D pipeline. Original Gen4 also has to rebase and copy
+ * miptree slices in order to render to unaligned locations.
+ */
+static void
+gen4_blit_framebuffer(struct gl_context *ctx,
+ struct gl_framebuffer *readFb,
+ struct gl_framebuffer *drawFb,
+ GLint srcX0, GLint srcY0, GLint srcX1, GLint srcY1,
+ GLint dstX0, GLint dstY0, GLint dstX1, GLint dstY1,
+ GLbitfield mask, GLenum filter)
+{
+ /* Page 679 of OpenGL 4.4 spec says:
+*Added BlitFramebuffer to commands affected by conditional rendering
in
+* section 10.10 (Bug 9562).
+*/
+ if (!_mesa_check_conditional_render(ctx))
+ return;
+
+ mask = intel_blit_framebuffer_with_blitter(ctx, readFb, drawFb,
+ srcX0, srcY0, srcX1, srcY1,
+ dstX0, dstY0, dstX1, dstY1,
+ mask, filter);
+ if (mask == 0x0)
+ return;
+
+ mask = _mesa_meta_BlitFramebuffer(ctx, readFb, drawFb,
+ srcX0, srcY0, srcX1, srcY1,
+ dstX0, dstY0, dstX1, dstY1,
+ mask, filter);
+ if (mask == 0x0)
+ return;
+
+ _swrast_BlitFramebuffer(ctx, readFb, drawFb,
+ srcX0, srcY0, srcX1, srcY1,
+ dstX0, dstY0, dstX1, dstY1,
+ mask, filter);
+}
+
+/**
* Does the renderbuffer have hiz enabled?
*/
bool
@@ -1049,7 +1094,10 @@ intel_fbo_init(struct brw_context *brw)
dd-UnmapRenderbuffer = intel_unmap_renderbuffer;
dd-RenderTexture = intel_render_texture;
dd-ValidateFramebuffer = intel_validate_framebuffer;
- dd-BlitFramebuffer = intel_blit_framebuffer;
+ if (brw-gen = 6)
+ dd-BlitFramebuffer = intel_blit_framebuffer;
+ else
+ dd-BlitFramebuffer = gen4_blit_framebuffer;
dd-EGLImageTargetRenderbufferStorage =
intel_image_target_renderbuffer_storage;
--
2.2.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] Revert common: Fix PBOs for 1D_ARRAY.
On 4 March 2015 at 17:22, Neil Roberts n...@linux.intel.com wrote: This reverts commit 546aba143d13ba3f993ead4cc30b2404abfc0202. I think the changes to the calls to glBlitFramebuffer from this patch are no different to what it was doing previously because it used to set height to 1 before doing the blits. However it was introducing some problems with the blit for layer 0 because this was no longer special cased. It didn't fix problems with the yoffset which needs to be interpreted as a slice offset. I think a better solution would be to modify the original if statement to cope with the yoffset. Neil, if others agree with this revert can you cc stable. Seems that the offending commit already has the tag, plus I've already picked it up :-\ Cc: 10.5 mesa-sta...@lists.freedesktop.org Thanks Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965: Tell intel_get_memcpy() which direction the memcpy() is going.
The SSSE3 swizzling code was written for fast uploads to the GPU and
assumed the destination was always 16-byte aligned. When we began using
this code for fast downloads as well we didn't do anything to account
for the fact that the destination pointer given by glReadPixels() or
glGetTexImage() is not guaranteed to be suitably aligned.
With SSSE3 enabled (at compile-time), some applications would crash when
an SSE aligned-store instruction tried to store to an unaligned
destination (or an assertion that the destination is aligned would
trigger).
To remedy this, tell intel_get_memcpy() whether we're uploading or
downloading so that it can select whether to assume the destination or
source is aligned, respectively.
Cc: 10.5 mesa-sta...@lists.freedesktop.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89416
---
I don't know what benchmarks I should run to test this code?
src/mesa/drivers/dri/i965/intel_pixel_read.c | 3 +-
src/mesa/drivers/dri/i965/intel_tex_image.c| 3 +-
src/mesa/drivers/dri/i965/intel_tex_subimage.c | 3 +-
src/mesa/drivers/dri/i965/intel_tiled_memcpy.c | 156 +++--
src/mesa/drivers/dri/i965/intel_tiled_memcpy.h | 15 ++-
5 files changed, 138 insertions(+), 42 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_pixel_read.c
b/src/mesa/drivers/dri/i965/intel_pixel_read.c
index df22a63..0972121 100644
--- a/src/mesa/drivers/dri/i965/intel_pixel_read.c
+++ b/src/mesa/drivers/dri/i965/intel_pixel_read.c
@@ -139,7 +139,8 @@ intel_readpixels_tiled_memcpy(struct gl_context * ctx,
rb-Format == MESA_FORMAT_R8G8B8X8_UNORM)
return false;
- if (!intel_get_memcpy(rb-Format, format, type, mem_copy, cpp))
+ if (!intel_get_memcpy(rb-Format, format, type, mem_copy, cpp,
+ INTEL_DOWNLOAD))
return false;
if (!irb-mt ||
diff --git a/src/mesa/drivers/dri/i965/intel_tex_image.c
b/src/mesa/drivers/dri/i965/intel_tex_image.c
index da42fdd..a3312d2 100644
--- a/src/mesa/drivers/dri/i965/intel_tex_image.c
+++ b/src/mesa/drivers/dri/i965/intel_tex_image.c
@@ -408,7 +408,8 @@ intel_gettexsubimage_tiled_memcpy(struct gl_context *ctx,
texImage-TexFormat == MESA_FORMAT_R8G8B8X8_UNORM)
return false;
- if (!intel_get_memcpy(texImage-TexFormat, format, type, mem_copy, cpp))
+ if (!intel_get_memcpy(texImage-TexFormat, format, type, mem_copy, cpp,
+ INTEL_UPLOAD))
return false;
/* If this is a nontrivial texture view, let another path handle it
instead. */
diff --git a/src/mesa/drivers/dri/i965/intel_tex_subimage.c
b/src/mesa/drivers/dri/i965/intel_tex_subimage.c
index 4262f71..909ff25 100644
--- a/src/mesa/drivers/dri/i965/intel_tex_subimage.c
+++ b/src/mesa/drivers/dri/i965/intel_tex_subimage.c
@@ -118,7 +118,8 @@ intel_texsubimage_tiled_memcpy(struct gl_context * ctx,
packing-Invert)
return false;
- if (!intel_get_memcpy(texImage-TexFormat, format, type, mem_copy, cpp))
+ if (!intel_get_memcpy(texImage-TexFormat, format, type, mem_copy, cpp,
+ INTEL_UPLOAD))
return false;
/* If this is a nontrivial texture view, let another path handle it
instead. */
diff --git a/src/mesa/drivers/dri/i965/intel_tiled_memcpy.c
b/src/mesa/drivers/dri/i965/intel_tiled_memcpy.c
index f2b35cb..c43383b 100644
--- a/src/mesa/drivers/dri/i965/intel_tiled_memcpy.c
+++ b/src/mesa/drivers/dri/i965/intel_tiled_memcpy.c
@@ -60,42 +60,79 @@ static const uint32_t ytile_span = 16;
static const uint8_t rgba8_permutation[16] =
{ 2,1,0,3, 6,5,4,7, 10,9,8,11, 14,13,12,15 };
-/* NOTE: dst must be 16 byte aligned */
-#define rgba8_copy_16(dst, src) \
- *(__m128i *)(dst) = _mm_shuffle_epi8(\
- (__m128i) _mm_loadu_ps((float *)(src)), \
- *(__m128i *) rgba8_permutation\
- )
+/* NOTE: dst must be 16-byte aligned. src may be unaligned. */
+#define rgba8_copy_16_aligned_dst(dst, src)\
+ _mm_store_si128((__m128i *)(dst), \
+ _mm_shuffle_epi8(_mm_loadu_si128((__m128i *)(src)), \
+*(__m128i *) rgba8_permutation))
+
+/* NOTE: src must be 16-byte aligned. dst may be unaligned. */
+#define rgba8_copy_16_aligned_src(dst, src)\
+ _mm_storeu_si128((__m128i *)(dst), \
+_mm_shuffle_epi8(_mm_load_si128((__m128i *)(src)), \
+ *(__m128i *) rgba8_permutation))
#endif
/**
- * Copy RGBA to BGRA - swap R and B.
+ * Copy RGBA to BGRA - swap R and B, with the destination 16-byte aligned.
*/
static inline void *
-rgba8_copy(void *dst, const void *src, size_t bytes)
+rgba8_copy_aligned_dst(void *dst, const void *src, size_t bytes)
{
uint8_t *d = dst;
uint8_t const *s = src;
#ifdef __SSSE3__
- /* Fast copying for tile spans.
-
[Mesa-dev] [PATCH] i965: Tell intel_get_memcpy() which direction the memcpy() is going.
The SSSE3 swizzling code was written for fast uploads to the GPU and
assumed the destination was always 16-byte aligned. When we began using
this code for fast downloads as well we didn't do anything to account
for the fact that the destination pointer given by glReadPixels() or
glGetTexImage() is not guaranteed to be suitably aligned.
With SSSE3 enabled (at compile-time), some applications would crash when
an SSE aligned-store instruction tried to store to an unaligned
destination (or an assertion that the destination is aligned would
trigger).
To remedy this, tell intel_get_memcpy() whether we're uploading or
downloading so that it can select whether to assume the destination or
source is aligned, respectively.
Cc: 10.5 mesa-sta...@lists.freedesktop.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89416
Tested-by: Uriy Zhuravlev stalk...@gmail.com [v1]
Reviewed-by: Jason Ekstrand jason.ekstr...@intel.com
---
Benchmarks I should run?
src/mesa/drivers/dri/i965/intel_pixel_read.c | 3 +-
src/mesa/drivers/dri/i965/intel_tex_image.c| 3 +-
src/mesa/drivers/dri/i965/intel_tex_subimage.c | 3 +-
src/mesa/drivers/dri/i965/intel_tiled_memcpy.c | 140 ++---
src/mesa/drivers/dri/i965/intel_tiled_memcpy.h | 15 ++-
5 files changed, 122 insertions(+), 42 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_pixel_read.c
b/src/mesa/drivers/dri/i965/intel_pixel_read.c
index df22a63..0972121 100644
--- a/src/mesa/drivers/dri/i965/intel_pixel_read.c
+++ b/src/mesa/drivers/dri/i965/intel_pixel_read.c
@@ -139,7 +139,8 @@ intel_readpixels_tiled_memcpy(struct gl_context * ctx,
rb-Format == MESA_FORMAT_R8G8B8X8_UNORM)
return false;
- if (!intel_get_memcpy(rb-Format, format, type, mem_copy, cpp))
+ if (!intel_get_memcpy(rb-Format, format, type, mem_copy, cpp,
+ INTEL_DOWNLOAD))
return false;
if (!irb-mt ||
diff --git a/src/mesa/drivers/dri/i965/intel_tex_image.c
b/src/mesa/drivers/dri/i965/intel_tex_image.c
index da42fdd..00bf9ce 100644
--- a/src/mesa/drivers/dri/i965/intel_tex_image.c
+++ b/src/mesa/drivers/dri/i965/intel_tex_image.c
@@ -408,7 +408,8 @@ intel_gettexsubimage_tiled_memcpy(struct gl_context *ctx,
texImage-TexFormat == MESA_FORMAT_R8G8B8X8_UNORM)
return false;
- if (!intel_get_memcpy(texImage-TexFormat, format, type, mem_copy, cpp))
+ if (!intel_get_memcpy(texImage-TexFormat, format, type, mem_copy, cpp,
+ INTEL_DOWNLOAD))
return false;
/* If this is a nontrivial texture view, let another path handle it
instead. */
diff --git a/src/mesa/drivers/dri/i965/intel_tex_subimage.c
b/src/mesa/drivers/dri/i965/intel_tex_subimage.c
index 4262f71..909ff25 100644
--- a/src/mesa/drivers/dri/i965/intel_tex_subimage.c
+++ b/src/mesa/drivers/dri/i965/intel_tex_subimage.c
@@ -118,7 +118,8 @@ intel_texsubimage_tiled_memcpy(struct gl_context * ctx,
packing-Invert)
return false;
- if (!intel_get_memcpy(texImage-TexFormat, format, type, mem_copy, cpp))
+ if (!intel_get_memcpy(texImage-TexFormat, format, type, mem_copy, cpp,
+ INTEL_UPLOAD))
return false;
/* If this is a nontrivial texture view, let another path handle it
instead. */
diff --git a/src/mesa/drivers/dri/i965/intel_tiled_memcpy.c
b/src/mesa/drivers/dri/i965/intel_tiled_memcpy.c
index f2b35cb..dcf0462 100644
--- a/src/mesa/drivers/dri/i965/intel_tiled_memcpy.c
+++ b/src/mesa/drivers/dri/i965/intel_tiled_memcpy.c
@@ -60,42 +60,79 @@ static const uint32_t ytile_span = 16;
static const uint8_t rgba8_permutation[16] =
{ 2,1,0,3, 6,5,4,7, 10,9,8,11, 14,13,12,15 };
-/* NOTE: dst must be 16 byte aligned */
-#define rgba8_copy_16(dst, src) \
- *(__m128i *)(dst) = _mm_shuffle_epi8(\
- (__m128i) _mm_loadu_ps((float *)(src)), \
- *(__m128i *) rgba8_permutation\
- )
+/* NOTE: dst must be 16-byte aligned. src may be unaligned. */
+#define rgba8_copy_16_aligned_dst(dst, src)\
+ _mm_store_si128((__m128i *)(dst), \
+ _mm_shuffle_epi8(_mm_loadu_si128((__m128i *)(src)), \
+*(__m128i *) rgba8_permutation))
+
+/* NOTE: src must be 16-byte aligned. dst may be unaligned. */
+#define rgba8_copy_16_aligned_src(dst, src)\
+ _mm_storeu_si128((__m128i *)(dst), \
+_mm_shuffle_epi8(_mm_load_si128((__m128i *)(src)), \
+ *(__m128i *) rgba8_permutation))
#endif
/**
- * Copy RGBA to BGRA - swap R and B.
+ * Copy RGBA to BGRA - swap R and B, with the destination 16-byte aligned.
*/
static inline void *
-rgba8_copy(void *dst, const void *src, size_t bytes)
+rgba8_copy_aligned_dst(void *dst, const void *src, size_t bytes)
{
uint8_t *d = dst;
uint8_t const
Re: [Mesa-dev] [PATCH 2/7] mapi: fix preprocessor check in u_current_destroy()
On Wed, Mar 4, 2015 at 8:18 PM, Matt Turner matts...@gmail.com wrote: Patches 1-2 are Reviewed-by: Matt Turner matts...@gmail.com As are patches 3-7. Thanks Brian! ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/7] mapi: fix preprocessor check in u_current_destroy()
On Wed, Mar 4, 2015 at 6:19 PM, Brian Paul bri...@vmware.com wrote:
So it matches the preprocessor check around the u_current_init_tsd() code.
---
src/mapi/u_current.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mapi/u_current.c b/src/mapi/u_current.c
index afa887e..eb77cc7 100644
--- a/src/mapi/u_current.c
+++ b/src/mapi/u_current.c
@@ -125,7 +125,7 @@ static int ThreadSafe;
void
u_current_destroy(void)
{
-#if defined(THREADS) defined(_WIN32)
+#if defined(THREADS) !defined(GLX_USE_TLS)
u_tsd_destroy(u_current_table_tsd);
u_tsd_destroy(u_current_context_tsd);
#endif
--
1.9.1
It looks like this dates from
commit a73c6540d9a7f6e26d8568ba2fc522cb865f0a6c
Author: Chia-I Wu o...@lunarg.com
Date: Fri Apr 23 16:06:26 2010 +0800
mapi: Add mapi and share the code with glapi.
(see _glapi_destroy_multithread)
and in that same commit it has
+void
+u_tsd_destroy(struct u_tsd *tsd); /* WIN32 only */
So at some point this changed, but it's not clear to me when.
Patches 1-2 are
Reviewed-by: Matt Turner matts...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/12] mesa: include c11/threads.h in mtypes.h
On Wed, Mar 4, 2015 at 6:18 PM, Brian Paul bri...@vmware.com wrote: Let's directly include c11/threads.h instead of relying on glapi.h to provide it. --- This one is Reviewed-by: Matt Turner matts...@gmail.com The rest are Acked-by: Matt Turner matts...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] main/base_tex_format: Properly handle STENCIL_INDEX1/4/16
On Tue, Mar 03, 2015 at 05:08:23PM +, Neil Roberts wrote: Jason Ekstrand ja...@jlekstrand.net writes: On Mon, Mar 2, 2015 at 11:33 AM, Ilia Mirkin imir...@alum.mit.edu wrote: On Mon, Mar 2, 2015 at 2:32 PM, Jason Ekstrand ja...@jlekstrand.net wrote: On Mon, Mar 2, 2015 at 11:18 AM, Ilia Mirkin imir...@alum.mit.edu wrote: Hmmm... I was just looking at this code in connection to attepmting to enable ARB_texture_stencil8, and it _seems_ like that should be if (ARB_texture_stencil8) -- I didn't see what in ARB_stencil_texturing had to do with being able to have a GL_STENCIL_INDEX* internal format... I just pushed it because it does fix a bug... However, you do raise a good point. Maybe we should change the i965 driver to use GL_STENCIL_INDEX for the internal format for our internal stencil buffers. How do you end up with a GL_STENCIL_INDEX internal format in the first place? Without ARB_texture_stencil8 that's not a thing, is it? We're using it internally for doing stencil blits. I'm going to Cc Neil and he can explain what's going on there better than I can as he was the one who wrote most of that code. Do you mean the code to do the meta stencil blit? I haven't touched that. Maybe I can pass the buck on to Topi :) I may not be answering to the question but I'll explain what the meta path does. It sets the texturing mode using: _mesa_TexParameteri(target, GL_DEPTH_STENCIL_TEXTURE_MODE, GL_STENCIL_INDEX); This in order to follow the spec: Texture lookups involving texture objects with an internal format of DEPTH_STENCIL can read the stencil value as described in section 3.10.18 by setting the DEPTH_STENCIL_TEXTURE_MODE to STENCIL_INDEX. But this should be effecting only gl_texture_object::StencilSampling which is considered by the surface state setup later on in i965. I don't believe I have altered any internal format related logic for this. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] egl dma-buf export extension again
Hi, On 3 March 2015 at 23:26, Kristian Høgsberg k...@bitplanet.net wrote: On Tue, Mar 3, 2015 at 10:43 AM, Chad Versace chad.vers...@intel.com wrote: Please use EGLImages as the import/export object. That provides consistency with existing similar EGL APIs. And it allows a clean separation between EGL-aware code and GL-aware code in applications and compositors. For what it's worth, extensions in this area being developed by Google's Chrome OS team also use EGLImages as the transport object. We can't both implement EGLImages in a compliant way *and* use them for cross-process sharing like we do. The spec language around orphaning and siblings is obscure, but the idea is that whenever you add a sibling (another client API object, eg a texture or a vg renderbuffer) the contents become invalid. The intended use case is that you create all siblings up front and then start using them. For example, to share an image between VG and GL, you create the VG buffer, then the EGLImage and then the GL texture. Implementations will defer allocation until all the siblings are set up and then only once you start rendering allocate the memory. This allows the implementation to accommodate constraints from all siblings. If you add another sibling, the implementation may have to reallocate storage to satisfy new constraints. This clearly isn't compatible with how we create and share EGLImages left and right across process boundaries. Khronos specifically developed EGLStreams as a cross-process color buffer sharing mechanism without pulling in EGLImage as a dependency. Anyway, the damage is done and we can continue digging ourselves deeper into this hole, but we should at least 1) have a good reason why the extra EGLImage indirection is necessary (it also rules out GLX usage) and 2) acknowledge that we're going to continue to rely on our broken EGLImage semantics. Which is all fair enough, but I think it's worth noting that SurfaceFlinger, when confronted with the exact same problem space, decided that the same answer was the best way forward. So we've got some precedent established there. Given the various interesting and creative ways in which people have broken their EGLImage implementations, I'm not really sure that I want to leave them to chance another, much less standard, spec, which has less of a precedent around it. Cheers, Daniel ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: Fix GCC unused-variable warning in release build.
Reviewed-by: Timothy Arceri t_arc...@yahoo.com.au
On Tue, 2015-03-03 at 18:49 -0800, Vinson Lee wrote:
CXX ast_array_index.lo
ast_array_index.cpp: In function ‘void update_max_array_access(ir_rvalue*,
int, YYLTYPE*, _mesa_glsl_parse_state*)’:
ast_array_index.cpp:86:30: warning: unused variable ‘interface_type’
[-Wunused-variable]
const glsl_type *interface_type =
^
Signed-off-by: Vinson Lee v...@freedesktop.org
---
src/glsl/ast_array_index.cpp | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/src/glsl/ast_array_index.cpp b/src/glsl/ast_array_index.cpp
index ff0c757..ecef651 100644
--- a/src/glsl/ast_array_index.cpp
+++ b/src/glsl/ast_array_index.cpp
@@ -83,11 +83,9 @@ update_max_array_access(ir_rvalue *ir, int idx, YYLTYPE
*loc,
if (deref_var != NULL) {
if (deref_var-var-is_interface_instance()) {
-const glsl_type *interface_type =
- deref_var-var-get_interface_type();
unsigned field_index =
deref_record-record-type-field_index(deref_record-field);
-assert(field_index interface_type-length);
+assert(field_index
deref_var-var-get_interface_type()-length);
unsigned *const max_ifc_array_access =
deref_var-var-get_max_ifc_array_access();
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Prune stale components
On 04/03/15 00:24, Emil Velikov wrote: On 03/03/15 22:04, Jose Fonseca wrote: On 03/03/15 18:39, Emil Velikov wrote: On 3 March 2015 at 17:16, Jose Fonseca jfons...@vmware.com wrote: ... I've prototyped this in https://urldefense.proofpoint.com/v2/url?u=http-3A__cgit.freedesktop.org_-7Ejrfonseca_mesa_log_-3Fh-3Dremove-2Dst-2Degld=AwIBaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzEm=DBmTkQmzY89vDw_KLOol0FBhKxmBTyqNfsx_ly5H-ZUs=zhIQc271rsRkCQHGsaFYKm3SFwRTGWAib63t3Fjdhyoe= The changes are massive, so I'm not sure it's even worth spamming the list with them. Could you please give a look and let me know if there are any concerns? I've spotted a few trivial bits: - windows/gdi: Remove. Drop drivers/windows from src/mesa/Makefile.am:EXTRA_DIST The driver had interesting api/wrapper similar to osmesa. Did not know that :-) - st/egl: Remove. Update the src/egl/main/Sconscript to create a SharedLibrary, add versioning, create symlink - copy the bits from egl-static. Drop st/egl and targets/egl-static from src/gallium/Makefile.am:EXTRA_DIST Remove the _EGL_BUILT_IN_DRIVER_GALLIUM define from src/egl/main/Android.mk. - st/vega: Remove. A few openvg references left - one in configure.ac another one in docs/contents.html Thanks. I pushed a new version of the branch with all issues fixed. I'm guessing you made a typo in src/egl/main/SConscript +egl = env.InstallSharedLibrary(egl, version=(1, 0, 0)) Shouldn't the version be 1.4 ? No, it wasn't a typo. It matches what autotools does now. I can't say which is more correct 1.0 or 1.4, but it doesn't make sense for SCons to do something different than autotools for the exact same code. The only snafu is Android.mk -- it will be broken with gallium drivers until somebody familiar with that infrastructure updates it to use egl_dri2. But it should build fine without gallium drivers. The Android build is mostly limping around mesa 10.4. I've pinged the Android-x86 guys, but but might get to it soon(ish). Don't worry too much about it. I'm guessing that the scons and automake build do not point out anything unusual ? Right. automake, scons/linux and scons/windows all build happily. Of course, automake has many options, and I only tested one (with dri and gallium sw rasterizers). These components are rather nicely isolated, so it should not matter that much. I'm suspecting that scons does not link against all libs for libEGL. ldd -r build/linux-x86_64-debug/egl/main/libEGL.so is clean. Adding -Wl,--no-undefined/-Wl,-z,defs to SHLINKFLAGS should clear it up, yet feel free to do it as a follow up. I would highly recommend adding it (-Wl...) for every SharedLibrary in scons. Using the version scripts like autotools, to restrict the exported symbols, will be great. I'll see what can be done. Unfortunately (at least in the past) we used to have .so depending on symbols from the .so/executable that dlopened it (ie, cyclic dependencies), so doing this universally woulddn't be possible. Not sure if that's still the case. With the versioning question addressed, feel free to add Reviewed-by: Emil Velikov emil.l.veli...@gmail.com Thanks for the reviews. Please drop a couple of lines in the release notes, when you're finished removing all the old/unused bits. Sure. -Emil P.S. Strange. After spending so much time fixing the builds, it feels so nice as various chunks of it end up removed :-P Yeah. I feel the same, even with code I wrote myself. Maintaining code takes a toll in time and energy (all those worries about things one should have done but never had the time). So removing code (or abandoning projects) is effectively taking a weight from ones conscience. And enables one to use that time/energy for better things. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH excerpt] mesa: Wrap unlikely() around conditions leading to _mesa_error().
On Monday, March 02, 2015 03:03:00 PM Eric Anholt wrote:
Kenneth Graunke kenn...@whitecape.org writes:
Generated by the following Coccinelle semantic patch:
@@
expression E;
@@
if (
-E
+unlikely(E)
)
{ ... _mesa_error(...) ... }
Improves performance in OglBatch7 (a CPU-bound microbenchmark) on
an i7 4750HQ (Haswell) by 1.08546% +/- 0.519734% (n=292).
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
Neat!
I think you're supposed to be able to get the same result by marking
_mesa_error as attribute cold. Then nobody can forget to mark their
conditions as unlikely in the future.
Oh, neat! I wasn't aware of __attribute__((cold)).
I tried it out and ran some measurements, this time on Baytrail (since
it should more more sensitive to CPU improvements like this). Oddly,
the results were different:
attribute cold on _mesa_error: -1.60367% +/- 0.43555%
unlikely on all _mesa_error callers: -2.92994% +/- 0.0632798%
I haven't dug into the assembly yet to try and see why.
(It's also bizarre to me that these /hurt/ performance on Baytrail, on
a CPU-limited microbenchmark that never hits _mesa_error, both with or
without the performance governor set. More mysteries...)
I'll have to try measuring on Haswell.
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Prune stale components
On 4 March 2015 at 08:31, Jose Fonseca jfons...@vmware.com wrote: On 04/03/15 00:24, Emil Velikov wrote: On 03/03/15 22:04, Jose Fonseca wrote: On 03/03/15 18:39, Emil Velikov wrote: On 3 March 2015 at 17:16, Jose Fonseca jfons...@vmware.com wrote: ... I've prototyped this in https://urldefense.proofpoint.com/v2/url?u=http-3A__cgit.freedesktop.org_-7Ejrfonseca_mesa_log_-3Fh-3Dremove-2Dst-2Degld=AwIBaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzEm=DBmTkQmzY89vDw_KLOol0FBhKxmBTyqNfsx_ly5H-ZUs=zhIQc271rsRkCQHGsaFYKm3SFwRTGWAib63t3Fjdhyoe= The changes are massive, so I'm not sure it's even worth spamming the list with them. Could you please give a look and let me know if there are any concerns? I've spotted a few trivial bits: - windows/gdi: Remove. Drop drivers/windows from src/mesa/Makefile.am:EXTRA_DIST The driver had interesting api/wrapper similar to osmesa. Did not know that :-) - st/egl: Remove. Update the src/egl/main/Sconscript to create a SharedLibrary, add versioning, create symlink - copy the bits from egl-static. Drop st/egl and targets/egl-static from src/gallium/Makefile.am:EXTRA_DIST Remove the _EGL_BUILT_IN_DRIVER_GALLIUM define from src/egl/main/Android.mk. - st/vega: Remove. A few openvg references left - one in configure.ac another one in docs/contents.html Thanks. I pushed a new version of the branch with all issues fixed. I'm guessing you made a typo in src/egl/main/SConscript +egl = env.InstallSharedLibrary(egl, version=(1, 0, 0)) Shouldn't the version be 1.4 ? No, it wasn't a typo. It matches what autotools does now. I can't say which is more correct 1.0 or 1.4, but it doesn't make sense for SCons to do something different than autotools for the exact same code. Nicely spotted. I've naively assumed that we had 1.4 for Autotools. The only snafu is Android.mk -- it will be broken with gallium drivers until somebody familiar with that infrastructure updates it to use egl_dri2. But it should build fine without gallium drivers. The Android build is mostly limping around mesa 10.4. I've pinged the Android-x86 guys, but but might get to it soon(ish). Don't worry too much about it. I'm guessing that the scons and automake build do not point out anything unusual ? Right. automake, scons/linux and scons/windows all build happily. Of course, automake has many options, and I only tested one (with dri and gallium sw rasterizers). These components are rather nicely isolated, so it should not matter that much. I'm suspecting that scons does not link against all libs for libEGL. ldd -r build/linux-x86_64-debug/egl/main/libEGL.so is clean. Adding -Wl,--no-undefined/-Wl,-z,defs to SHLINKFLAGS should clear it up, yet feel free to do it as a follow up. I would highly recommend adding it (-Wl...) for every SharedLibrary in scons. Using the version scripts like autotools, to restrict the exported symbols, will be great. I'll see what can be done. Unfortunately (at least in the past) we used to have .so depending on symbols from the .so/executable that dlopened it (ie, cyclic dependencies), so doing this universally woulddn't be possible. Not sure if that's still the case. The only such case in current mesa ought to be the dri modules (LoadableModule) - both gallium and classic ones. That is for the Autotools build, cannot say anything for scons. Thanks again for clearing these up. -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] GSoC 2015 Proposal : Porting Glean tests to piglit
Hello, Here is my proposal for Adding Porting Glean tests to piglit. I'll like to get your comments and tweaks. Thanks, Juliet Porting Glean tests to Piglit framework OPW Proposal https://docs.google.com/document/d/1Y5flvgsJg5s6XUfTP955qKDbhG0ldXBCjGd-YROtTtM/edit?usp=drive_web ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] nesa-10.4.4: gallivm/lp_bld_misc.cpp:503:38: error: no viable conversion from 'ShaderMemoryManager *' to 'std::unique_ptrRTDyldMemoryManager'
On 04/03/15 02:00, Emil Velikov wrote: On 27 February 2015 at 23:28, Sedat Dilek sedat.di...@gmail.com wrote: On Mon, Feb 9, 2015 at 6:30 PM, Emil Velikov emil.l.veli...@gmail.com wrote: On 07/02/15 21:44, Sedat Dilek wrote: Hi, I was building mesa v10.4.4 with my llvm-toolchain v3.6.0rc2. My build breaks like this... ... Please cherry-pick... commit ef7e0b39a24966526b102643523feac765771842 gallivm: Update for RTDyldMemoryManager becoming an unique_ptr. ..for mesa 10.4 Git branch. Hi Sedat, Picking a fix in a stable branch against a non-final release sounds like a no-go in our books. As the official llvm 3.6 rolls out we'll pick this fix for the stable branches - until then I would recommend (a) applying it locally or (b) using mesa from the 10.5 or master branch. Just FYI... [LLVMdev] LLVM 3.6 Release (see [1]). Please pick this patch for-10.4, thanks. As promised, mesa 10.4.6 will feature this. But is cross-porting this patch enough? As I said when this first issue was raised fixing the build with LLVM 3.6 is just half of the problem. It must also _run_ correctly. And building correctly doesn't necessarily means it will run correctly. That is, unless somebody actually ensures that all LLVM 3.6 related fixes have been crossported and that things run correctly, it is misleading to enable the build of Mesa 10.4.6 with LLVM 3.6. I don't know about radeon drivers, but at least from llvmpipe POV I simply don't have the time to do this (go through every LLVM 3.6 related patch, ensure they are all in 10.4.6, and test). I quickly went through the diffs between 10.4 branch, and found one such commit is missing: http://cgit.freedesktop.org/mesa/mesa/commit/?id=74f505fa73eda0c9b5b1984bebb44cedac8e8794 https://bugs.freedesktop.org/show_bug.cgi?id=85467 But there might be more, and I don't know if crossporting this is safe or not. Therefore my stance for is that building Mesa stable releases with LLVM releases after the Mesa release was branched is still unsupported. If people want to do so, they will do at their own peril. And any incoming bugs will be unsupported, use Mesa. If having a Mesa release capable of building LLVM 3.6 is so important, I think it might be easier/safer to just make a new release from a recent enough commit, than trying to backport it. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
