Re: [Mesa-dev] [PATCH] Add support for NV_depth_buffer_float v2.
Ian, I will shortly send a changeset incorporating the changes, thanks for summarizing. On Tuesday, September 09, 2014 16:11:45 Ian Romanick wrote: I also second Marek's comment about testing. My recollection from Khronos meetings is that at least AMD GL 3.x-class hardware can only handle the clamped version. That's why GL_ARB_depth_buffer_float exists. Well, I must say that I have not tested the whole range of possible use scenarios. But there is a single use scenario, which is nicely described at http://outerra.blogspot.de/2012/11/maximizing-depth-buffer-range-and.html. So, this whole attempt to include this extension is to be able to avoid that != 0 offset in the viewport depth transform which indeed destroys your depth resolution in the described setup. At least the gallium drivers exactly follow the viewport equation and by that use this (f+n)/2 offset in the viewport transform which must happen independent of the multiplication with the projection matrix usually happening in the shader stages. So, you can only eliminate if you allow for symmetrical ranges, means n = -f, which is impossible with glDepthRange() due to clamping. So long story, I have a quick hack test already in my local piglit which tests about what is needed for the above use case. I can polish this and post this to piglit. I have to say, that I am currently short on oss driver test systems. But llvmpipe works fine with the patch and the test. Sure others should be tested too... May be off topic for the patch, but alternatively, since this implementation is more driven by an application need: Do you know any other extension that solves the above use case of a more or less indefinite far projection matrix without depth partitioning, with simple and fast directly routed z values and without partially loosing early z test capabilities by the need of a real logarithmic shader transform before writing and comparing the depth buffer value? Greetings Mathias ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 79662] [DRI3 all Bisected] Many webglc cases fail
https://bugs.freedesktop.org/show_bug.cgi?id=79662 lu hua huax...@intel.com changed: What|Removed |Added Summary|[DRI3 all Bisected] Many|[DRI3 all Bisected] Many |webglc cases fail and X |webglc cases fail |fails on PNV| --- Comment #9 from lu hua huax...@intel.com --- X works well on PNV, modify the summary. -- 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 1/3] radeon/video: use more of the common buffer code v2
From: Christian König christian.koe...@amd.com
In preparation to using buffers clears with the hw engine(s).
v2: split out flipping to using hw buffer clears.
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/drivers/radeon/radeon_uvd.c| 40 ++-
src/gallium/drivers/radeon/radeon_vce.c| 17 +
src/gallium/drivers/radeon/radeon_vce.h| 1 +
src/gallium/drivers/radeon/radeon_vce_40_2_2.c | 5 ++-
src/gallium/drivers/radeon/radeon_video.c | 53 +++---
src/gallium/drivers/radeon/radeon_video.h | 13 +++
6 files changed, 62 insertions(+), 67 deletions(-)
diff --git a/src/gallium/drivers/radeon/radeon_uvd.c
b/src/gallium/drivers/radeon/radeon_uvd.c
index 9d3b2bf..6ad2d24 100644
--- a/src/gallium/drivers/radeon/radeon_uvd.c
+++ b/src/gallium/drivers/radeon/radeon_uvd.c
@@ -68,6 +68,7 @@ struct ruvd_decoder {
unsignedstream_handle;
unsignedframe_number;
+ struct pipe_screen *screen;
struct radeon_winsys* ws;
struct radeon_winsys_cs*cs;
@@ -122,7 +123,7 @@ static void map_msg_fb_buf(struct ruvd_decoder *dec)
buf = dec-msg_fb_buffers[dec-cur_buffer];
/* and map it for CPU access */
- ptr = dec-ws-buffer_map(buf-cs_handle, dec-cs, PIPE_TRANSFER_WRITE);
+ ptr = dec-ws-buffer_map(buf-res-cs_buf, dec-cs,
PIPE_TRANSFER_WRITE);
/* calc buffer offsets */
dec-msg = (struct ruvd_msg *)ptr;
@@ -142,12 +143,12 @@ static void send_msg_buf(struct ruvd_decoder *dec)
buf = dec-msg_fb_buffers[dec-cur_buffer];
/* unmap the buffer */
- dec-ws-buffer_unmap(buf-cs_handle);
+ dec-ws-buffer_unmap(buf-res-cs_buf);
dec-msg = NULL;
dec-fb = NULL;
/* and send it to the hardware */
- send_cmd(dec, RUVD_CMD_MSG_BUFFER, buf-cs_handle, 0,
+ send_cmd(dec, RUVD_CMD_MSG_BUFFER, buf-res-cs_buf, 0,
RADEON_USAGE_READ, RADEON_DOMAIN_GTT);
}
@@ -601,7 +602,7 @@ static void ruvd_begin_frame(struct pipe_video_codec
*decoder,
dec-bs_size = 0;
dec-bs_ptr = dec-ws-buffer_map(
- dec-bs_buffers[dec-cur_buffer].cs_handle,
+ dec-bs_buffers[dec-cur_buffer].res-cs_buf,
dec-cs, PIPE_TRANSFER_WRITE);
}
@@ -640,14 +641,14 @@ static void ruvd_decode_bitstream(struct pipe_video_codec
*decoder,
struct rvid_buffer *buf = dec-bs_buffers[dec-cur_buffer];
unsigned new_size = dec-bs_size + sizes[i];
- if (new_size buf-buf-size) {
- dec-ws-buffer_unmap(buf-cs_handle);
- if (!rvid_resize_buffer(dec-ws, dec-cs, buf,
new_size)) {
+ if (new_size buf-res-buf-size) {
+ dec-ws-buffer_unmap(buf-res-cs_buf);
+ if (!rvid_resize_buffer(dec-screen, dec-cs, buf,
new_size)) {
RVID_ERR(Can't resize bitstream buffer!);
return;
}
- dec-bs_ptr = dec-ws-buffer_map(buf-cs_handle,
dec-cs,
+ dec-bs_ptr = dec-ws-buffer_map(buf-res-cs_buf,
dec-cs,
PIPE_TRANSFER_WRITE);
if (!dec-bs_ptr)
return;
@@ -683,7 +684,7 @@ static void ruvd_end_frame(struct pipe_video_codec *decoder,
bs_size = align(dec-bs_size, 128);
memset(dec-bs_ptr, 0, bs_size - dec-bs_size);
- dec-ws-buffer_unmap(bs_buf-cs_handle);
+ dec-ws-buffer_unmap(bs_buf-res-cs_buf);
map_msg_fb_buf(dec);
dec-msg-size = sizeof(*dec-msg);
@@ -696,7 +697,7 @@ static void ruvd_end_frame(struct pipe_video_codec *decoder,
dec-msg-body.decode.width_in_samples = dec-base.width;
dec-msg-body.decode.height_in_samples = dec-base.height;
- dec-msg-body.decode.dpb_size = dec-dpb.buf-size;
+ dec-msg-body.decode.dpb_size = dec-dpb.res-buf-size;
dec-msg-body.decode.bsd_size = bs_size;
dt = dec-set_dtb(dec-msg, (struct vl_video_buffer *)target);
@@ -731,13 +732,13 @@ static void ruvd_end_frame(struct pipe_video_codec
*decoder,
send_msg_buf(dec);
- send_cmd(dec, RUVD_CMD_DPB_BUFFER, dec-dpb.cs_handle, 0,
+ send_cmd(dec, RUVD_CMD_DPB_BUFFER, dec-dpb.res-cs_buf, 0,
RADEON_USAGE_READWRITE, RADEON_DOMAIN_VRAM);
- send_cmd(dec, RUVD_CMD_BITSTREAM_BUFFER, bs_buf-cs_handle,
+ send_cmd(dec, RUVD_CMD_BITSTREAM_BUFFER, bs_buf-res-cs_buf,
0, RADEON_USAGE_READ, RADEON_DOMAIN_GTT);
send_cmd(dec, RUVD_CMD_DECODING_TARGET_BUFFER, dt, 0,
RADEON_USAGE_WRITE, RADEON_DOMAIN_VRAM);
- send_cmd(dec, RUVD_CMD_FEEDBACK_BUFFER, msg_fb_buf-cs_handle,
+ send_cmd(dec,
[Mesa-dev] [PATCH 2/3] radeon/video: use the hw to initial clear the buffers
From: Christian König christian.koe...@amd.com
Less CPU overhead and avoids contention over CPU accessible memory on startup.
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/drivers/radeon/radeon_uvd.c | 6 +++---
src/gallium/drivers/radeon/radeon_video.c | 10 --
src/gallium/drivers/radeon/radeon_video.h | 2 +-
3 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/src/gallium/drivers/radeon/radeon_uvd.c
b/src/gallium/drivers/radeon/radeon_uvd.c
index 6ad2d24..69f5cdc 100644
--- a/src/gallium/drivers/radeon/radeon_uvd.c
+++ b/src/gallium/drivers/radeon/radeon_uvd.c
@@ -830,8 +830,8 @@ struct pipe_video_codec *ruvd_create_decoder(struct
pipe_context *context,
goto error;
}
- rvid_clear_buffer(dec-ws, dec-cs, dec-msg_fb_buffers[i]);
- rvid_clear_buffer(dec-ws, dec-cs, dec-bs_buffers[i]);
+ rvid_clear_buffer(context, dec-msg_fb_buffers[i]);
+ rvid_clear_buffer(context, dec-bs_buffers[i]);
}
if (!rvid_create_buffer(dec-screen, dec-dpb, dpb_size,
PIPE_USAGE_DEFAULT)) {
@@ -839,7 +839,7 @@ struct pipe_video_codec *ruvd_create_decoder(struct
pipe_context *context,
goto error;
}
- rvid_clear_buffer(dec-ws, dec-cs, dec-dpb);
+ rvid_clear_buffer(context, dec-dpb);
map_msg_fb_buf(dec);
dec-msg-size = sizeof(*dec-msg);
diff --git a/src/gallium/drivers/radeon/radeon_video.c
b/src/gallium/drivers/radeon/radeon_video.c
index 0bc4390..f6cfdff 100644
--- a/src/gallium/drivers/radeon/radeon_video.c
+++ b/src/gallium/drivers/radeon/radeon_video.c
@@ -118,14 +118,12 @@ error:
}
/* clear the buffer with zeros */
-void rvid_clear_buffer(struct radeon_winsys *ws, struct radeon_winsys_cs *cs,
struct rvid_buffer* buffer)
+void rvid_clear_buffer(struct pipe_context *context, struct rvid_buffer*
buffer)
{
- void *ptr = ws-buffer_map(buffer-res-cs_buf, cs,
PIPE_TRANSFER_WRITE);
- if (!ptr)
- return;
+ struct r600_common_context *rctx = (struct r600_common_context*)context;
- memset(ptr, 0, buffer-res-buf-size);
- ws-buffer_unmap(buffer-res-cs_buf);
+ rctx-clear_buffer(context, buffer-res-b.b, 0,
buffer-res-buf-size, 0);
+ context-flush(context, NULL, 0);
}
/**
diff --git a/src/gallium/drivers/radeon/radeon_video.h
b/src/gallium/drivers/radeon/radeon_video.h
index fe3088a..974ea4f 100644
--- a/src/gallium/drivers/radeon/radeon_video.h
+++ b/src/gallium/drivers/radeon/radeon_video.h
@@ -62,7 +62,7 @@ bool rvid_resize_buffer(struct pipe_screen *screen, struct
radeon_winsys_cs *cs,
struct rvid_buffer *new_buf, unsigned new_size);
/* clear the buffer with zeros */
-void rvid_clear_buffer(struct radeon_winsys *ws, struct radeon_winsys_cs *cs,
struct rvid_buffer* buffer);
+void rvid_clear_buffer(struct pipe_context *context, struct rvid_buffer*
buffer);
/* join surfaces into the same buffer with identical tiling params
sumup their sizes and replace the backend buffers with a single bo */
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Compiling of shader gets stuck in infinite loop
Hi,
I have been looking into this bug:
Compiling of shader gets stuck in infinite loop
https://bugs.freedesktop.org/show_bug.cgi?id=78468
Although this occurs at link time when the Intel driver has run some of
its specific lowering passes, it looks like the problem could hit other
drivers if the right conditions are met, as the actual problem happens
inside common optimization passes.
I reproduced the problem with a very simple shader like this:
uniform sampler2D tex;
out vec4 FragColor;
void main()
{
vec4 col = texture(tex, vec2(0, 0));
for (int i=0; i30; i++)
col += vec4(0.1, 0.1, 0.1, 0.1);
col = vec4(col.rgb / 2.0, col.a);
FragColor = col;
}
and for this shader, I traced the problem down to the fact that
do_tree_grafting() is generating instructions like this:
(assign (x) (var_ref flattening_tmp_y@116) (expression float * (swiz x
(expression float + (swiz x (expression float + (swiz x (expression
float + (swiz x (expression float + (swiz x (expression float + (swiz x
(expression float + (swiz x (expression float + (swiz x (expression
float + (swiz x (expression float + (swiz x (expression float + (swiz x
(expression float + (swiz x (expression float + (swiz x (expression
float + (swiz x (expression float + (swiz x (expression float + (swiz x
(expression float + (swiz x (expression float + (swiz x (expression
float + (swiz x (expression float + (swiz x (expression float + (swiz x
(expression float + (swiz x (expression float + (swiz x (expression
float + (swiz x (expression float + (swiz x (expression float + (swiz x
(expression float + (swiz x (expression float + (swiz x (expression
float + (swiz x (expression float + (var_ref col_y) (constant float
(0.10)) ) )(constant float (0.10)) ) )(constant float
(0.10)) ) )(constant float (0.10)) ) )(constant float
(0.10)) ) )(constant float (0.10)) ) )(constant float
(0.10)) ) )(constant float (0.10)) ) )(constant float
(0.10)) ) )(constant float (0.10)) ) )(constant float
(0.10)) ) )(constant float (0.10)) ) )(constant float
(0.10)) ) )(constant float (0.10)) ) )(constant float
(0.10)) ) )(constant float (0.10)) ) )(constant float
(0.10)) ) )(constant float (0.10)) ) )(constant float
(0.10)) ) )(constant float (0.10)) ) )(constant float
(0.10)) ) )(constant float (0.10)) ) )(constant float
(0.10)) ) )(constant float (0.10)) ) )(constant float
(0.10)) ) )(constant float (0.10)) ) )(constant float
(0.10)) ) )(constant float (0.10)) ) )(constant float
(0.10)) ) )(constant float (0.50)) ) )
And when we feed these to do_constant_folding() it takes forever to
finish. For this shader in particular, removing the tree grafting pass
from do_common_optimization eliminates the problem.
Notice that small, seemingly irrelevant changes to the shader code, can
make it so that this never happens. For example, if we initialize 'col'
to something like vec4(0,0,0,0) instead of using the texture function,
or we remove the division by 2.0 in the last assignment to 'col', these
instructions are never produced and the shader compiles okay.
The number of iterations in the loop is also important, if we have too
many we do not unroll the loop and the problem never happens, if we have
too few, rather than generating a super large tree of expressions like
above, we generate something like this and the problem, again, does not
happen: (notice how it adds 0.1 nine times to make 0.9 rather than
chaining 9 add expressions for 10 iterations of the loop):
(assign (x) (var_ref flattening_tmp_y) (expression float * (expression
float + (constant float (0.90)) (var_ref col_y) ) (constant float
(0.50)) ) )
So it seems that whether we generate a huge chunk of expressions or not
is subject to a number of factors, but when the right conditions are met
we can generate code that can stall compilation forever.
Reading what tree grafting is supposed to do, this does not seem to be
an unexpected result though, so I wonder what would be the right way to
fix this. It would look like we would want to do whatever we are doing
when we only have a few iterations in the loop, but I don't know why we
generate different code in that case and I am not familiar enough with
all the optimization and lowering passes to assess what would make sense
to do here... so, any suggestions?
Iago
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radeonsi: Program RASTER_CONFIG for harvested GPUs v4
On 10.09.2014 22:59, Tom Stellard wrote:
+ /* Always use the default config when all backends are enabled.
*/
+ if (rb_mask util_bitcount(rb_mask) max_backends) {
+ /* XXX: I can't figure out what the *_XSEL and *_YSEL
+* fields are for, so I'm leaving them as their default
+* values. */
+ unsigned pkr_mask = (sh_per_se | 0x1);
+ unsigned se0_pkr0 = rb_mask pkr_mask;
+ unsigned se0_pkr1 = (rb_mask = sh_per_se) pkr_mask;
+ unsigned se1_pkr0 = (rb_mask = sh_per_se) pkr_mask;
+ unsigned se1_pkr1 = (rb_mask = sh_per_se) pkr_mask;
+ unsigned se_map = 0;
+ unsigned se0_pkr_map = 0;
+ unsigned se1_pkr_map = 0;
+ unsigned se0_pkr0_rb_map = 0;
+ unsigned se0_pkr1_rb_map = 0;
+ unsigned se1_pkr0_rb_map = 0;
+ unsigned se1_pkr1_rb_map = 0;
+ if (!se0_pkr0 !se0_pkr1) {
+ /* se0 disabled */
+ se_map |= 0x1;
+ }
+ if (se1_pkr0 || se1_pkr1) {
+ /* se1 enabled */
+ se_map |= 0x2;
+ }
+ if (!se0_pkr0) {
+ /* se0 pkr0 disabled */
+ se0_pkr_map |= 0x1;
+ }
+ if (se0_pkr1) {
+ /* se0 pkr1 enabled */
+ se0_pkr_map |= 0x2;
+ }
+ if (!se1_pkr0) {
+ /* se1 pkr0 disabled */
+ se1_pkr_map |= 0x1;
+ }
+ if (se1_pkr1) {
+ /* se1 pkr1 enabled */
+ se1_pkr_map |= 0x2;
+ }
+
+ se0_pkr0_rb_map = pkr_mask_to_map(se0_pkr0);
+ se0_pkr1_rb_map = pkr_mask_to_map(se0_pkr1);
+ se1_pkr0_rb_map = pkr_mask_to_map(se1_pkr0);
+ se1_pkr1_rb_map = pkr_mask_to_map(se1_pkr1);
+
+ assert(!se0_pkr0 || !se1_pkr0 || (se0_pkr0_rb_map ==
se1_pkr0_rb_map));
+ assert(!se0_pkr1 || !se1_pkr1 || (se0_pkr1_rb_map ==
se1_pkr1_rb_map));
+ raster_config = C_028350_RB_MAP_PKR0;
+ raster_config |= S_028350_RB_MAP_PKR0(se0_pkr0_rb_map);
+ raster_config = C_028350_RB_MAP_PKR1;
+ raster_config |= S_028350_RB_MAP_PKR1(se0_pkr1_rb_map);
+ raster_config = C_028350_PKR_MAP;
+ raster_config |= S_028350_PKR_MAP(se0_pkr_map);
+ raster_config = C_028350_SE_MAP;
+ raster_config |= S_028350_SE_MAP(se_map);
+ }
Taking a closer look again at the kernel code and register spec, I'm
afraid this logic is too static. I came up with the attached incremental
patch. It tries to only modify raster_config as necessary, i.e. only if
there are two SEs / packers per SE / RBs per packer but one of them is
disabled. The result may be different between SEs.
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
commit 7103b9ccbc5b7ab9acc6eda2046b3db58bb6645d
Author: Michel Dänzer michel.daen...@amd.com
Date: Thu Sep 11 17:12:54 2014 +0900
radeonsi: Improve RASTER_CONFIG calculation for harvested cards
diff --git a/src/gallium/drivers/radeonsi/si_state.c b/src/gallium/drivers/radeonsi/si_state.c
index 21b9c34..91ada67 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -2989,15 +2989,114 @@ void si_init_state_functions(struct si_context *sctx)
sctx-b.b.draw_vbo = si_draw_vbo;
}
-static unsigned pkr_mask_to_map(unsigned mask)
-{
- switch(mask 0x3) {
- case 0x0:
- case 0x1: return 0x0;
- case 0x2: return 0x3;
- case 0x3: return 0x2;
+static void
+si_write_harvested_raster_configs(struct si_context *sctx,
+ struct si_pm4_state *pm4,
+ unsigned raster_config)
+{
+ unsigned sh_per_se = MAX2(sctx-screen-b.info.max_sh_per_se, 1);
+ unsigned num_se = MAX2(sctx-screen-b.info.max_se, 1);
+ unsigned rb_mask = sctx-screen-b.info.si_backend_enabled_mask;
+ unsigned num_rb = sctx-screen-b.info.r600_num_backends;
+ unsigned rb_per_pkr = num_rb / num_se / sh_per_se;
+ unsigned rb_per_se = num_rb / num_se;
+ unsigned se0_mask = (1 rb_per_se) - 1;
+ unsigned se1_mask = se0_mask rb_per_se;
+ unsigned se;
+
+ assert(num_se == 1 || num_se == 2);
+
Re: [Mesa-dev] [PATCH 1/3] radeon/video: use more of the common buffer code v2
On 11.09.2014 16:55, Christian König wrote: From: Christian König christian.koe...@amd.com In preparation to using buffers clears with the hw engine(s). v2: split out flipping to using hw buffer clears. Thanks! The series is Reviewed-by: Michel Dänzer michel.daen...@amd.com -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radeonsi: Simplify si_dma_copy_tile function
On 11.09.2014 00:28, Grigori Goronzy wrote: On 10.09.2014 10:54, Michel Dänzer wrote: From: Michel Dänzer michel.daen...@amd.com + array_mode = si_array_mode(rtiled-surface.level[tiled_lvl].mode); Wouldn't it be more consistent to pull the array_mode from the tile mode array like other parameters? I don't have a strong opinion on that either way, but it doesn't make a difference unless there's a bug elsewhere. That will break old kernels, but I think it should be okay by now. We could maybe disable tiled DMA copies completely on those. Patches welcome. :) The purpose of this patch was only to simplify the function without any functional change. -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radeonsi: Fix si_dma_copy(_tile) for compressed formats
On 11.09.2014 07:05, Marek Olšák wrote: Sorry, the function is too confusing for me to understand it, but it looks good. Thanks, but unfortunately, it breaks the fbo-generatemipmap-formats test with compressed formats for some reason. Investigating that now. I think it would be cleaner to convert all parameters of the compressed texture copy into a non-compressed texture copy at the beginning of si_dma_copy, with the box being (x/4, y/4, w/4, h/4), i.e. blitting whole blocks instead of pixels. Then, all the other DMA functions don't have to worry about compressed textures in theory. Thanks for the suggestion, I'll keep that in mind. -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 83669] fix build with gcc link time optimizer
https://bugs.freedesktop.org/show_bug.cgi?id=83669 --- Comment #10 from Marc Dietrich marvi...@gmx.de --- I check with -g -O0 and debug symbols are generated, but I can't tell about their usefulness. Compiling with --enable-debug fails though because -DDEBUG seems to do strange things in combination with --enable-glx-tls, but works without: CCLD glapi/libglapi.la /tmp/ccLLavDU.ltrans4.ltrans.o: In function `entry_get_public': ccLLavDU.ltrans4.o:(.text+0x10): undefined reference to `x86_64_entry_start' /usr/lib64/gcc/x86_64-suse-linux/4.9/../../../../x86_64-suse-linux/bin/ld: /tmp/ccLLavDU.ltrans4.ltrans.o: relocation R_X86_64_PC32 against undefined symbol `x86_64_entry_start' can not be used when making a shared object; recompile with -fPIC /usr/lib64/gcc/x86_64-suse-linux/4.9/../../../../x86_64-suse-linux/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status The problem mentioned in comment 7 (all files are compiled with sse4.1 enabled using lto) might really exist. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54231. The recommendation is to add the target pragma instead of adding linker flags, but I think this is not portable. Here is my configuration if anyone wants to try: COMMON_FLAGS=--prefix=/usr \ --enable-texture-float \ --enable-gles1 \ --enable-gles2 \ --enable-openvg \ --enable-gallium-osmesa \ --enable-dri3 \ --enable-xa \ --enable-xvmc \ --enable-vdpau \ --enable-omx\ --enable-r600-llvm-compiler \ --enable-glx-tls\ --enable-gbm\ --enable-gallium-llvm \ --enable-gallium-gbm\ --enable-gallium-egl\ --with-gallium-drivers=r600,swrast \ --enable-debug \ --with-egl-platforms=drm,x11,wayland \ --with-dri-drivers=no ./autogen.sh \ $COMMON_FLAGS \ CFLAGS=-march=native -flto -fuse-ld=gold -fuse-linker-plugin \ CXXFLAGS=-march=native -flto -fuse-ld=gold -fuse-linker-plugin \ LDFLAGS=-march=native -flto -fuse-ld=gold -fuse-linker-plugin \ LD=ld.gold \ AR=gcc-ar-4.9 \ NM=gcc-nm-4.9 \ RANLIB=gcc-ranlib-4.9 -- 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 83669] fix build with gcc link time optimizer
https://bugs.freedesktop.org/show_bug.cgi?id=83669
--- Comment #11 from Marc Dietrich marvi...@gmx.de ---
sorry for spamming this bug, here is a better patch to fix the problem
diff --git a/src/mesa/Makefile.am b/src/mesa/Makefile.am
index e71bccb..bbdb36f 100644
--- a/src/mesa/Makefile.am
+++ b/src/mesa/Makefile.am
@@ -152,7 +152,6 @@ libmesagallium_la_LIBADD = \
libmesa_sse41_la_SOURCES = \
main/streaming-load-memcpy.c
-libmesa_sse41_la_CFLAGS = $(AM_CFLAGS) -msse4.1
pkgconfigdir = $(libdir)/pkgconfig
pkgconfig_DATA = gl.pc
diff --git a/src/mesa/main/streaming-load-memcpy.c
b/src/mesa/main/streaming-load-memcpy.c
index 8427149..94b0e0a 100644
--- a/src/mesa/main/streaming-load-memcpy.c
+++ b/src/mesa/main/streaming-load-memcpy.c
@@ -26,7 +26,7 @@
*
*/
-#ifdef __SSE4_1__
+#ifdef USE_SSE41
#include main/macros.h
#include main/streaming-load-memcpy.h
#include smmintrin.h
@@ -34,7 +34,7 @@
/* Copies memory from src to dst, using SSE 4.1's MOVNTDQA to get streaming
* read performance from uncached memory.
*/
-void
+void __attribute__ ((target(sse4.1)))
_mesa_streaming_load_memcpy(void *restrict dst, void *restrict src, size_t
len)
{
char *restrict d = dst;
--
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 70599] [SNB/IVB/HSW Bisected]Piglit glx/GLX_ARB_create_context/current_with_no_framebuffer segfault
https://bugs.freedesktop.org/show_bug.cgi?id=70599 Tapani Pälli lem...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Tapani Pälli lem...@gmail.com --- The commit mentioned in the bug description has been reverted from Mesa 9.2 tree, the test still fails on 9.2 but does not segfault. Mesa versions with the test: - 9.2 fail - 10.0 segfault - 10.1 pass - 10.2 pass - 10.3 pass - 10.4-dev (6816d85) pass For gallium it has been fixed to pass by commit db8b6fb, not sure what fixes it for others. As it now passes on master, I'll resolved this as fixed. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/5] mesa: Have validate_uniform_parameters return the gl_uniform_storage pointer
On Sat, Aug 2, 2014 at 4:09 AM, Ian Romanick i...@freedesktop.org wrote:
diff --git a/src/mesa/main/uniform_query.cpp b/src/mesa/main/uniform_query.cpp
index 609d94b..7b089fa 100644
--- a/src/mesa/main/uniform_query.cpp
+++ b/src/mesa/main/uniform_query.cpp
@@ -266,30 +265,32 @@ validate_uniform_parameters(struct gl_context *ctx,
*/
if (shProg-UniformRemapTable[location] ==
INACTIVE_UNIFORM_EXPLICIT_LOCATION)
- return false;
+ return NULL;
- _mesa_uniform_split_location_offset(shProg, location, loc, array_index);
+ unsigned loc;
+ _mesa_uniform_split_location_offset(shProg, location, loc, array_index);
+ struct gl_uniform_storage *const uni = shProg-UniformStorage[loc];
- if (shProg-UniformStorage[*loc].array_elements == 0 count 1) {
+ if (uni-array_elements == 0 count 1) {
I'm getting a NULL-pointer deference here when running piglit's
spec/ARB_explicit_uniform_location/arb_explicit_uniform_location-use-of-unused-loc
on yesterday's master. A quick git-log doesn't seem to contain a fix
in today's master either.
Perhaps something like this is in order?
- if (uni-array_elements == 0 count 1) {
+ if (uni uni-array_elements == 0 count 1) {
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/5] mesa: Have validate_uniform_parameters return the gl_uniform_storage pointer
On Thu, Sep 11, 2014 at 1:27 PM, Erik Faye-Lund kusmab...@gmail.com wrote:
On Sat, Aug 2, 2014 at 4:09 AM, Ian Romanick i...@freedesktop.org wrote:
diff --git a/src/mesa/main/uniform_query.cpp
b/src/mesa/main/uniform_query.cpp
index 609d94b..7b089fa 100644
--- a/src/mesa/main/uniform_query.cpp
+++ b/src/mesa/main/uniform_query.cpp
@@ -266,30 +265,32 @@ validate_uniform_parameters(struct gl_context *ctx,
*/
if (shProg-UniformRemapTable[location] ==
INACTIVE_UNIFORM_EXPLICIT_LOCATION)
- return false;
+ return NULL;
- _mesa_uniform_split_location_offset(shProg, location, loc, array_index);
+ unsigned loc;
+ _mesa_uniform_split_location_offset(shProg, location, loc, array_index);
+ struct gl_uniform_storage *const uni = shProg-UniformStorage[loc];
- if (shProg-UniformStorage[*loc].array_elements == 0 count 1) {
+ if (uni-array_elements == 0 count 1) {
I'm getting a NULL-pointer deference here when running piglit's
spec/ARB_explicit_uniform_location/arb_explicit_uniform_location-use-of-unused-loc
on yesterday's master. A quick git-log doesn't seem to contain a fix
in today's master either.
Perhaps something like this is in order?
- if (uni-array_elements == 0 count 1) {
+ if (uni uni-array_elements == 0 count 1) {
Actually, that just moves the issue a few lines, as line 282 also
dereferences 'uni'. Earlying out by checking for NULL in uni seems
more appropriate, but if I do so without setting GL_INVALID_OEPRATION,
the piglit test fails.
Doing
---8---
diff --git a/src/mesa/main/uniform_query.cpp b/src/mesa/main/uniform_query.cpp
index 4cd2bca..4483948 100644
--- a/src/mesa/main/uniform_query.cpp
+++ b/src/mesa/main/uniform_query.cpp
@@ -268,6 +268,12 @@ validate_uniform_parameters(struct gl_context *ctx,
return NULL;
struct gl_uniform_storage *const uni = shProg-UniformRemapTable[location];
+ if (!uni) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ %s(nonexistent uniform, location=%d),
+ caller, location);
+ return NULL;
+ }
if (uni-array_elements == 0 count 1) {
_mesa_error(ctx, GL_INVALID_OPERATION,
---8---
...seems to fix both the crash and the test. Looking a bit more
closely at the test, it seems somewhat appropriate.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/5] mesa: Have validate_uniform_parameters return the gl_uniform_storage pointer
On 09/11/2014 02:27 PM, Erik Faye-Lund wrote:
On Sat, Aug 2, 2014 at 4:09 AM, Ian Romanick i...@freedesktop.org wrote:
diff --git a/src/mesa/main/uniform_query.cpp
b/src/mesa/main/uniform_query.cpp
index 609d94b..7b089fa 100644
--- a/src/mesa/main/uniform_query.cpp
+++ b/src/mesa/main/uniform_query.cpp
@@ -266,30 +265,32 @@ validate_uniform_parameters(struct gl_context *ctx,
*/
if (shProg-UniformRemapTable[location] ==
INACTIVE_UNIFORM_EXPLICIT_LOCATION)
- return false;
+ return NULL;
- _mesa_uniform_split_location_offset(shProg, location, loc, array_index);
+ unsigned loc;
+ _mesa_uniform_split_location_offset(shProg, location, loc, array_index);
+ struct gl_uniform_storage *const uni = shProg-UniformStorage[loc];
- if (shProg-UniformStorage[*loc].array_elements == 0 count 1) {
+ if (uni-array_elements == 0 count 1) {
I'm getting a NULL-pointer deference here when running piglit's
spec/ARB_explicit_uniform_location/arb_explicit_uniform_location-use-of-unused-loc
on yesterday's master. A quick git-log doesn't seem to contain a fix
in today's master either.
Perhaps something like this is in order?
- if (uni-array_elements == 0 count 1) {
+ if (uni uni-array_elements == 0 count 1) {
fix is here:
http://lists.freedesktop.org/archives/mesa-dev/2014-August/066752.html
remaptable contains entries that are set NULL for inactive uniforms
___
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/5] mesa: Have validate_uniform_parameters return the gl_uniform_storage pointer
On Thu, Sep 11, 2014 at 2:00 PM, Tapani Pälli tapani.pa...@intel.com wrote:
On 09/11/2014 02:27 PM, Erik Faye-Lund wrote:
On Sat, Aug 2, 2014 at 4:09 AM, Ian Romanick i...@freedesktop.org wrote:
diff --git a/src/mesa/main/uniform_query.cpp
b/src/mesa/main/uniform_query.cpp
index 609d94b..7b089fa 100644
--- a/src/mesa/main/uniform_query.cpp
+++ b/src/mesa/main/uniform_query.cpp
@@ -266,30 +265,32 @@ validate_uniform_parameters(struct gl_context *ctx,
*/
if (shProg-UniformRemapTable[location] ==
INACTIVE_UNIFORM_EXPLICIT_LOCATION)
- return false;
+ return NULL;
- _mesa_uniform_split_location_offset(shProg, location, loc, array_index);
+ unsigned loc;
+ _mesa_uniform_split_location_offset(shProg, location, loc,
array_index);
+ struct gl_uniform_storage *const uni = shProg-UniformStorage[loc];
- if (shProg-UniformStorage[*loc].array_elements == 0 count 1) {
+ if (uni-array_elements == 0 count 1) {
I'm getting a NULL-pointer deference here when running piglit's
spec/ARB_explicit_uniform_location/arb_explicit_uniform_location-use-of-unused-loc
on yesterday's master. A quick git-log doesn't seem to contain a fix
in today's master either.
Perhaps something like this is in order?
- if (uni-array_elements == 0 count 1) {
+ if (uni uni-array_elements == 0 count 1) {
fix is here:
http://lists.freedesktop.org/archives/mesa-dev/2014-August/066752.html
remaptable contains entries that are set NULL for inactive uniforms
Thanks.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: check that uniform exists in glUniform* functions
On Thu, Aug 28, 2014 at 9:58 AM, Tapani Pälli tapani.pa...@intel.com wrote:
Remap table for uniforms may contain empty entries when using explicit
uniform locations. If no active/inactive variable exists with given
location, remap table contains NULL.
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
---
src/mesa/main/uniform_query.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/uniform_query.cpp b/src/mesa/main/uniform_query.cpp
index 4cd2bca..5dcb528 100644
--- a/src/mesa/main/uniform_query.cpp
+++ b/src/mesa/main/uniform_query.cpp
@@ -239,7 +239,7 @@ validate_uniform_parameters(struct gl_context *ctx,
* - if count is greater than one, and the uniform declared in the
* shader is not an array variable,
*/
- if (location -1) {
+ if (location -1 || !shProg-UniformRemapTable[location]) {
_mesa_error(ctx, GL_INVALID_OPERATION, %s(location=%d),
caller, location);
Nice. But shouldn't the the error-message be updated? With a location
smaller than -1, it's very clear what's wrong. But when triggering the
introduced condition, it's not. I think some wording should be added
to make it clear that the location does not exist.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: check that uniform exists in glUniform* functions
On 09/11/2014 03:12 PM, Erik Faye-Lund wrote:
On Thu, Aug 28, 2014 at 9:58 AM, Tapani Pälli tapani.pa...@intel.com wrote:
Remap table for uniforms may contain empty entries when using explicit
uniform locations. If no active/inactive variable exists with given
location, remap table contains NULL.
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
---
src/mesa/main/uniform_query.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/uniform_query.cpp b/src/mesa/main/uniform_query.cpp
index 4cd2bca..5dcb528 100644
--- a/src/mesa/main/uniform_query.cpp
+++ b/src/mesa/main/uniform_query.cpp
@@ -239,7 +239,7 @@ validate_uniform_parameters(struct gl_context *ctx,
* - if count is greater than one, and the uniform declared in the
* shader is not an array variable,
*/
- if (location -1) {
+ if (location -1 || !shProg-UniformRemapTable[location]) {
_mesa_error(ctx, GL_INVALID_OPERATION, %s(location=%d),
caller, location);
Nice. But shouldn't the the error-message be updated? With a location
smaller than -1, it's very clear what's wrong. But when triggering the
introduced condition, it's not. I think some wording should be added
to make it clear that the location does not exist.
It's not a new condition, this is the same error you got already before
this code existed when calling glUniform() with some random number (not
retrieved with getUniformLocation) which is the case here also. But we
could have a better error message, any proposals?
// Tapani
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] replace file specific compiler optimization with inline attibute
File specific optimization as used for src/mesa/main/streaming-load-memcpy.c
currently will cause problems with LTO in the future
(see: https://bugs.freedesktop.org/show_bug.cgi?id=83669). Replace it with
in-file target specification.
This only works for gcc for now. The intel compiler has
__attribute__((cpu_specific(cpuid))) with cpuid core_2_duo_sse4_1, but I'm
not sure if mesa compiles with it and how it behaves on different platforms.
Signed-off-by: Marc Dietrich marvi...@gmx.de
---
src/mesa/Makefile.am | 1 -
src/mesa/main/streaming-load-memcpy.c | 4 ++--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/src/mesa/Makefile.am b/src/mesa/Makefile.am
index e71bccb..bbdb36f 100644
--- a/src/mesa/Makefile.am
+++ b/src/mesa/Makefile.am
@@ -152,7 +152,6 @@ libmesagallium_la_LIBADD = \
libmesa_sse41_la_SOURCES = \
main/streaming-load-memcpy.c
-libmesa_sse41_la_CFLAGS = $(AM_CFLAGS) -msse4.1
pkgconfigdir = $(libdir)/pkgconfig
pkgconfig_DATA = gl.pc
diff --git a/src/mesa/main/streaming-load-memcpy.c
b/src/mesa/main/streaming-load-memcpy.c
index 8427149..94b0e0a 100644
--- a/src/mesa/main/streaming-load-memcpy.c
+++ b/src/mesa/main/streaming-load-memcpy.c
@@ -26,7 +26,7 @@
*
*/
-#ifdef __SSE4_1__
+#ifdef USE_SSE41
#include main/macros.h
#include main/streaming-load-memcpy.h
#include smmintrin.h
@@ -34,7 +34,7 @@
/* Copies memory from src to dst, using SSE 4.1's MOVNTDQA to get streaming
* read performance from uncached memory.
*/
-void
+void __attribute__ ((target(sse4.1)))
_mesa_streaming_load_memcpy(void *restrict dst, void *restrict src, size_t len)
{
char *restrict d = dst;
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 83570] Glyphy demo throws unhandled Integer division by zero exception
https://bugs.freedesktop.org/show_bug.cgi?id=83570 --- Comment #13 from Roland Scheidegger srol...@vmware.com --- (In reply to comment #12) Roland, Perhaps you can help me here. I'm looking at udiv_emit_cpu and I'm just not getting it. The comment says: /* udiv by zero is guaranteed to return 0x */ but the way I read it, udiv by zero returns the numerator. Am I missing something? Well in the end it is ored with the comparison mask, hence it's going to be all ones (comparison masks are either all ones or all zeros). So the first or is there to make sure the zero in the division gets replaced by something else (all ones because this is easiest) so it doesn't crash, and the second or is there to make sure the result is all ones (because d3d10 requires this result, but since d3d10 lacks signed integer division there's not really any such requirement for idiv). -- 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 83570] Glyphy demo throws unhandled Integer division by zero exception
https://bugs.freedesktop.org/show_bug.cgi?id=83570 --- Comment #14 from rcond...@hotmail.com --- (In reply to comment #13) (comparison masks are either all ones or all zeros). AHH!!! That was the piece I was missing. My hair follicles thank you. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] replace file specific compiler optimization with inline attibute
On Thu, Sep 11, 2014 at 6:58 AM, Marc Dietrich marvi...@gmx.de wrote: File specific optimization as used for src/mesa/main/streaming-load-memcpy.c currently will cause problems with LTO in the future (see: https://bugs.freedesktop.org/show_bug.cgi?id=83669). Replace it with in-file target specification. This is only available in gcc-4.8 and later. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 83777] New: [regression] ilo fails to build
https://bugs.freedesktop.org/show_bug.cgi?id=83777 Priority: medium Bug ID: 83777 CC: olva...@gmail.com Assignee: mesa-dev@lists.freedesktop.org Summary: [regression] ilo fails to build Severity: normal Classification: Unclassified OS: Linux (All) Reporter: fabio@libero.it Hardware: All Status: NEW Version: git Component: Mesa core Product: Mesa After latest changes ilo fails to build. Full log, including configure options, is here: https://launchpadlibrarian.net/184568683/buildlog_ubuntu-trusty-amd64.mesa_10.4~git1409111930.a46d75~gd~t_FAILEDTOBUILD.txt.gz Error: libtool: compile: gcc -DPACKAGE_NAME=\Mesa\ -DPACKAGE_TARNAME=\mesa\ -DPACKAGE_VERSION=\10.4.0-devel\ -DPACKAGE_STRING=\Mesa 10.4.0-devel\ -DPACKAGE_BUGREPORT=\https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa\; -DPACKAGE_URL=\\ -DPACKAGE=\mesa\ -DVERSION=\10.4.0-devel\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\.libs/\ -DYYTEXT_POINTER=1 -DHAVE___BUILTIN_BSWAP32=1 -DHAVE___BUILTIN_BSWAP64=1 -DHAVE_DLADDR=1 -DHAVE_CLOCK_GETTIME=1 -DHAVE_PTHREAD=1 -I. -I../../../../../../src/gallium/drivers/ilo -I../../../../../../src/gallium/drivers/ilo/include -I../../../../../../src -I../../../../../../include -I../../../../../../src/gallium/include -I../../../../../../src/gallium/auxiliary -I../../../../../../src/gallium/drivers -I../../../../../../src/gallium/winsys -DUSE_EXTERNAL_DXTN_LIB=1 -D_GNU_SOURCE -DHAVE_PTHREAD -DUSE_SSE41 -DTEXTURE_FLOAT_ENABLED -DUSE_X86_64_ASM -DHAVE_DLOPEN -DHAVE_POSIX_MEMALIGN -DHAVE_LIBDRM -DGLX_USE_DRM -DHAVE_LIBUDEV -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DGLX_USE_TLS -DHAVE_PTHREAD -DHAVE_ALIAS -DHAVE_DRI3 -DHAVE_MINCORE -DHAVE_LLVM=0x0305 -DLLVM_VERSION_PATCH=0 -fvisibility=hidden -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno-builtin-memcmp -MT shader/toy_compiler_disasm.lo -MD -MP -MF shader/.deps/toy_compiler_disasm.Tpo -c ../../../../../../src/gallium/drivers/ilo/shader/toy_compiler_disasm.c -fPIC -DPIC -o shader/.libs/toy_compiler_disasm.o ../../../../../../src/gallium/drivers/ilo/shader/toy_compiler_disasm.c: In function 'disasm_printer_add_operand': ../../../../../../src/gallium/drivers/ilo/shader/toy_compiler_disasm.c:1020:7: error: format not a string literal and no format arguments [-Werror=format-security] disasm_printer_add(printer, name); ^ cc1: some warnings being treated as errors make[4]: *** [shader/toy_compiler_disasm.lo] Error 1 -- 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 83631] /usr/include/GL/glxext.h:480:143: error: 'GLintptr' has not been declared
https://bugs.freedesktop.org/show_bug.cgi?id=83631
--- Comment #3 from Brian Paul bri...@vmware.com ---
#include GL/glx.h should pull in GL/gl.h (line 32) which should include
GL/glext.h So by time we hit the use of GLintptr, it should have been defined.
When I compile a trivial test program like this:
#include GL/glx.h
int main(void)
{
GLintptr p;
return 0;
}
it seems to work.
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965/vec4: Only examine virtual_grf_end for GRF sources
On Wednesday, September 10, 2014 06:01:19 PM Ian Romanick wrote:
From: Ian Romanick ian.d.roman...@intel.com
If the source is not a GRF, it could have a register = virtual_grf_count.
Accessing virtual_grf_end with such a register would lead to
out-of-bounds access. Make sure the source is a GRF before accessing
virtual_grf_end.
Fixes gles3conform failure in:
ES3-CTS.shaders.struct.uniform.sampler_array_vertex.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83215
---
src/mesa/drivers/dri/i965/brw_vec4_cse.cpp | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_cse.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_cse.cpp
index a0f6e77..da3e65a 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_cse.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_cse.cpp
@@ -224,14 +224,21 @@ vec4_visitor::opt_cse_local(bblock_t *block)
/* Kill any AEB entries using registers that don't get reused any
* more -- a sure sign they'll fail operands_match().
*/
-int last_reg_use = MAX2(MAX2(virtual_grf_end[src-reg * 4 + 0],
- virtual_grf_end[src-reg * 4 + 1]),
-MAX2(virtual_grf_end[src-reg * 4 + 2],
- virtual_grf_end[src-reg * 4 + 3]));
-if (src-file == GRF last_reg_use ip) {
- entry-remove();
- ralloc_free(entry);
- break;
+if (src-file == GRF) {
+ assert((src-reg * 4 + 0) (virtual_grf_count * 4));
+ assert((src-reg * 4 + 1) (virtual_grf_count * 4));
+ assert((src-reg * 4 + 2) (virtual_grf_count * 4));
I'd probably drop these from the final patch.
Otherwise, (and with the fixes test line removed), this is:
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
Thanks, Ian! Good find!
+ assert((src-reg * 4 + 3) (virtual_grf_count * 4));
+
+ int last_reg_use = MAX2(MAX2(virtual_grf_end[src-reg * 4 +
0],
+virtual_grf_end[src-reg * 4 +
1]),
+ MAX2(virtual_grf_end[src-reg * 4 +
2],
+virtual_grf_end[src-reg * 4 +
3]));
+ if (last_reg_use ip) {
+ entry-remove();
+ ralloc_free(entry);
+ break;
+ }
}
}
}
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/5] mesa: Have validate_uniform_parameters return the gl_uniform_storage pointer
On 09/11/2014 05:09 AM, Erik Faye-Lund wrote:
On Thu, Sep 11, 2014 at 2:00 PM, Tapani Pälli tapani.pa...@intel.com wrote:
On 09/11/2014 02:27 PM, Erik Faye-Lund wrote:
On Sat, Aug 2, 2014 at 4:09 AM, Ian Romanick i...@freedesktop.org wrote:
diff --git a/src/mesa/main/uniform_query.cpp
b/src/mesa/main/uniform_query.cpp
index 609d94b..7b089fa 100644
--- a/src/mesa/main/uniform_query.cpp
+++ b/src/mesa/main/uniform_query.cpp
@@ -266,30 +265,32 @@ validate_uniform_parameters(struct gl_context *ctx,
*/
if (shProg-UniformRemapTable[location] ==
INACTIVE_UNIFORM_EXPLICIT_LOCATION)
- return false;
+ return NULL;
- _mesa_uniform_split_location_offset(shProg, location, loc,
array_index);
+ unsigned loc;
+ _mesa_uniform_split_location_offset(shProg, location, loc,
array_index);
+ struct gl_uniform_storage *const uni = shProg-UniformStorage[loc];
- if (shProg-UniformStorage[*loc].array_elements == 0 count 1) {
+ if (uni-array_elements == 0 count 1) {
I'm getting a NULL-pointer deference here when running piglit's
spec/ARB_explicit_uniform_location/arb_explicit_uniform_location-use-of-unused-loc
on yesterday's master. A quick git-log doesn't seem to contain a fix
in today's master either.
Perhaps something like this is in order?
- if (uni-array_elements == 0 count 1) {
+ if (uni uni-array_elements == 0 count 1) {
fix is here:
http://lists.freedesktop.org/archives/mesa-dev/2014-August/066752.html
remaptable contains entries that are set NULL for inactive uniforms
Thanks.
Does Tapani's patch fix the problem for you? If so, can we call that a
Tested-by? :)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radeonsi: Program RASTER_CONFIG for harvested GPUs v4
On Thu, Sep 11, 2014 at 05:24:03PM +0900, Michel Dänzer wrote:
On 10.09.2014 22:59, Tom Stellard wrote:
+/* Always use the default config when all backends are enabled.
*/
+if (rb_mask util_bitcount(rb_mask) max_backends) {
+/* XXX: I can't figure out what the *_XSEL and *_YSEL
+ * fields are for, so I'm leaving them as their default
+ * values. */
+unsigned pkr_mask = (sh_per_se | 0x1);
+unsigned se0_pkr0 = rb_mask pkr_mask;
+unsigned se0_pkr1 = (rb_mask = sh_per_se) pkr_mask;
+unsigned se1_pkr0 = (rb_mask = sh_per_se) pkr_mask;
+unsigned se1_pkr1 = (rb_mask = sh_per_se) pkr_mask;
+unsigned se_map = 0;
+unsigned se0_pkr_map = 0;
+unsigned se1_pkr_map = 0;
+unsigned se0_pkr0_rb_map = 0;
+unsigned se0_pkr1_rb_map = 0;
+unsigned se1_pkr0_rb_map = 0;
+unsigned se1_pkr1_rb_map = 0;
+if (!se0_pkr0 !se0_pkr1) {
+/* se0 disabled */
+se_map |= 0x1;
+}
+if (se1_pkr0 || se1_pkr1) {
+/* se1 enabled */
+se_map |= 0x2;
+}
+if (!se0_pkr0) {
+/* se0 pkr0 disabled */
+se0_pkr_map |= 0x1;
+}
+if (se0_pkr1) {
+/* se0 pkr1 enabled */
+se0_pkr_map |= 0x2;
+}
+if (!se1_pkr0) {
+/* se1 pkr0 disabled */
+se1_pkr_map |= 0x1;
+}
+if (se1_pkr1) {
+/* se1 pkr1 enabled */
+se1_pkr_map |= 0x2;
+}
+
+se0_pkr0_rb_map = pkr_mask_to_map(se0_pkr0);
+se0_pkr1_rb_map = pkr_mask_to_map(se0_pkr1);
+se1_pkr0_rb_map = pkr_mask_to_map(se1_pkr0);
+se1_pkr1_rb_map = pkr_mask_to_map(se1_pkr1);
+
+assert(!se0_pkr0 || !se1_pkr0 || (se0_pkr0_rb_map ==
se1_pkr0_rb_map));
+assert(!se0_pkr1 || !se1_pkr1 || (se0_pkr1_rb_map ==
se1_pkr1_rb_map));
+raster_config = C_028350_RB_MAP_PKR0;
+raster_config |= S_028350_RB_MAP_PKR0(se0_pkr0_rb_map);
+raster_config = C_028350_RB_MAP_PKR1;
+raster_config |= S_028350_RB_MAP_PKR1(se0_pkr1_rb_map);
+raster_config = C_028350_PKR_MAP;
+raster_config |= S_028350_PKR_MAP(se0_pkr_map);
+raster_config = C_028350_SE_MAP;
+raster_config |= S_028350_SE_MAP(se_map);
+}
Taking a closer look again at the kernel code and register spec, I'm
afraid this logic is too static. I came up with the attached
incremental patch. It tries to only modify raster_config as
necessary, i.e. only if there are two SEs / packers per SE / RBs per
packer but one of them is disabled. The result may be different
between SEs.
Does this mean that different values of R_028350_PA_SC_RASTER_CONFIG will
be written depending on the SE? My understanding was that this register
stored the information for both SEs, so the same value would be used for
SE0 and SE1.
-Tom
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
commit 7103b9ccbc5b7ab9acc6eda2046b3db58bb6645d
Author: Michel D??nzer michel.daen...@amd.com
Date: Thu Sep 11 17:12:54 2014 +0900
radeonsi: Improve RASTER_CONFIG calculation for harvested cards
diff --git a/src/gallium/drivers/radeonsi/si_state.c
b/src/gallium/drivers/radeonsi/si_state.c
index 21b9c34..91ada67 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -2989,15 +2989,114 @@ void si_init_state_functions(struct si_context *sctx)
sctx-b.b.draw_vbo = si_draw_vbo;
}
-static unsigned pkr_mask_to_map(unsigned mask)
-{
- switch(mask 0x3) {
- case 0x0:
- case 0x1: return 0x0;
- case 0x2: return 0x3;
- case 0x3: return 0x2;
+static void
+si_write_harvested_raster_configs(struct si_context *sctx,
+ struct si_pm4_state *pm4,
+ unsigned raster_config)
+{
+ unsigned sh_per_se = MAX2(sctx-screen-b.info.max_sh_per_se, 1);
+ unsigned num_se = MAX2(sctx-screen-b.info.max_se, 1);
+ unsigned rb_mask =
Re: [Mesa-dev] [PATCH] mesa: check that uniform exists in glUniform* functions
On 08/28/2014 12:58 AM, Tapani Pälli wrote:
Remap table for uniforms may contain empty entries when using explicit
uniform locations. If no active/inactive variable exists with given
location, remap table contains NULL.
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
---
src/mesa/main/uniform_query.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/uniform_query.cpp b/src/mesa/main/uniform_query.cpp
index 4cd2bca..5dcb528 100644
--- a/src/mesa/main/uniform_query.cpp
+++ b/src/mesa/main/uniform_query.cpp
@@ -239,7 +239,7 @@ validate_uniform_parameters(struct gl_context *ctx,
* - if count is greater than one, and the uniform declared in the
* shader is not an array variable,
*/
- if (location -1) {
+ if (location -1 || !shProg-UniformRemapTable[location]) {
_mesa_error(ctx, GL_INVALID_OPERATION, %s(location=%d),
caller, location);
return NULL;
So... this would occur if someone explicitly put uniforms at locations 0
and 2, then queried location 1, right? What happens if someone queries
location 0x7fff? Will it commit an out-of-bounds acces of
UniformRemapTable, or is there an earlier check that's not visible in
the patch?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/5] mesa: Have validate_uniform_parameters return the gl_uniform_storage pointer
On Thu, Sep 11, 2014 at 8:35 PM, Ian Romanick i...@freedesktop.org wrote:
On 09/11/2014 05:09 AM, Erik Faye-Lund wrote:
On Thu, Sep 11, 2014 at 2:00 PM, Tapani Pälli tapani.pa...@intel.com wrote:
On 09/11/2014 02:27 PM, Erik Faye-Lund wrote:
On Sat, Aug 2, 2014 at 4:09 AM, Ian Romanick i...@freedesktop.org wrote:
diff --git a/src/mesa/main/uniform_query.cpp
b/src/mesa/main/uniform_query.cpp
index 609d94b..7b089fa 100644
--- a/src/mesa/main/uniform_query.cpp
+++ b/src/mesa/main/uniform_query.cpp
@@ -266,30 +265,32 @@ validate_uniform_parameters(struct gl_context *ctx,
*/
if (shProg-UniformRemapTable[location] ==
INACTIVE_UNIFORM_EXPLICIT_LOCATION)
- return false;
+ return NULL;
- _mesa_uniform_split_location_offset(shProg, location, loc,
array_index);
+ unsigned loc;
+ _mesa_uniform_split_location_offset(shProg, location, loc,
array_index);
+ struct gl_uniform_storage *const uni = shProg-UniformStorage[loc];
- if (shProg-UniformStorage[*loc].array_elements == 0 count 1) {
+ if (uni-array_elements == 0 count 1) {
I'm getting a NULL-pointer deference here when running piglit's
spec/ARB_explicit_uniform_location/arb_explicit_uniform_location-use-of-unused-loc
on yesterday's master. A quick git-log doesn't seem to contain a fix
in today's master either.
Perhaps something like this is in order?
- if (uni-array_elements == 0 count 1) {
+ if (uni uni-array_elements == 0 count 1) {
fix is here:
http://lists.freedesktop.org/archives/mesa-dev/2014-August/066752.html
remaptable contains entries that are set NULL for inactive uniforms
Thanks.
Does Tapani's patch fix the problem for you? If so, can we call that a
Tested-by? :)
It does indeed, so:
Tested-by: Erik Faye-Lund kusmab...@gmail.com.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: check that uniform exists in glUniform* functions
On Thu, Sep 11, 2014 at 8:39 PM, Ian Romanick i...@freedesktop.org wrote:
On 08/28/2014 12:58 AM, Tapani Pälli wrote:
Remap table for uniforms may contain empty entries when using explicit
uniform locations. If no active/inactive variable exists with given
location, remap table contains NULL.
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
---
src/mesa/main/uniform_query.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/uniform_query.cpp
b/src/mesa/main/uniform_query.cpp
index 4cd2bca..5dcb528 100644
--- a/src/mesa/main/uniform_query.cpp
+++ b/src/mesa/main/uniform_query.cpp
@@ -239,7 +239,7 @@ validate_uniform_parameters(struct gl_context *ctx,
* - if count is greater than one, and the uniform declared in
the
* shader is not an array variable,
*/
- if (location -1) {
+ if (location -1 || !shProg-UniformRemapTable[location]) {
_mesa_error(ctx, GL_INVALID_OPERATION, %s(location=%d),
caller, location);
return NULL;
So... this would occur if someone explicitly put uniforms at locations 0
and 2, then queried location 1, right? What happens if someone queries
location 0x7fff? Will it commit an out-of-bounds acces of
UniformRemapTable, or is there an earlier check that's not visible in
the patch?
Outch. That check is right *after* this lookup, so no... that's not
going to work as-is.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Compiling of shader gets stuck in infinite loop
I have looked at this problem quite a bit but never got to the bottom of it.
This problem really started to show with commit 857f3a6 - glsl: Ignore
loop-too-large heuristic if there's bad variable indexing.
That commit makes many more loops unroll.
Here is another example piglit shader_runner test that shows the problem.
Changing the value of LOOP_COUNT and running this with time shader_runner
-auto
shows that the compile time doubles each time the loop count is incremented
by one.
Large values may seem to take forever. But they do eventually finish.
Loop counts over 32 will still prevent unrolling and avoid the slow compile.
A key part of the problem is the assignment to col.rgb in your shader or
tmpvar_3.xyz in this shader.
The operation on only some channels results in splitting the vec4 into one
temporary per channel.
This comment from src/mesa/drivers/dri/i965/brw_fs_vector_splitting.cpp is
telling.
27│ * If a vector is only ever referenced by its components, then
28│ * split those components out to individual variables so they can be
29│ * handled normally by other optimization passes.
brw_do_vector_splitting creates the flattening_tmp_y and flattening_tmp_z
temporaries.
Operations on one of the channels are optimized quickly.
But the other two channels are handled badly.
The operations on the first channel prevent the same simplification of the
expressions for the other two channels.
Changing ir_vector_splitting_visitor::visit_leave to use writemask = 1
i; instead of writemask = 1;
in the if (lhs) case makes the y and z channels get handled like the x
channel.
That results in something like
(assign (y) (var_ref flattening_tmp_y) (expression float * (swiz y
(var_ref texture2D_retval) )(var_ref channel_expressions@8114) ) )
It is very fast to compile, but produces bad code that hangs the GPU.
It is putting the y channel float value into a non-existent y channel of
a simple float temporary, then later reading the real x channel.
[require]
GLSL = 1.10
[vertex shader]
#version 120
attribute vec2 Tex0;
attribute vec3 Position;
void main ()
{
vec4 inPos_1;
inPos_1.xy = Position.xy;
inPos_1.z = 1.0;
inPos_1.w = 1.0;
gl_Position = inPos_1;
vec4 tmpvar_2;
tmpvar_2.zw = vec2(0.0, 0.0);
tmpvar_2.xy = Tex0;
gl_TexCoord[0] = tmpvar_2;
}
[fragment shader]
#version 120
#define LOOP_COUNT 25
uniform sampler2D u_sampler;
void main ()
{
vec2 tmpvar_1;
tmpvar_1 = gl_TexCoord[0].xy;
vec4 tmpvar_3;
tmpvar_3 = vec4(0.0, 0.0, 0.0, 1.0);
float weighting_5[LOOP_COUNT];
for (int i = 0; i LOOP_COUNT; i++) {
float tmpvar_10;
tmpvar_10 = ((float(int(abs ((float(i) - 15.0) / 15.);
float tmpvar_11;
tmpvar_11 = exp ((-(tmpvar_10) * tmpvar_10));
weighting_5[i] = tmpvar_11;
};
for (int k = 0; k LOOP_COUNT; k++) {
tmpvar_3.xyz += (texture2D (u_sampler, tmpvar_1).xyz * weighting_5[k]);
};
gl_FragData[0] = tmpvar_3;
}
[test]
draw rect -1 -1 2 2
probe rgb 1 1 0.0 0.0 0.0
On Thu, Sep 11, 2014 at 2:02 AM, Iago Toral Quiroga ito...@igalia.com
wrote:
Hi,
I have been looking into this bug:
Compiling of shader gets stuck in infinite loop
https://bugs.freedesktop.org/show_bug.cgi?id=78468
Although this occurs at link time when the Intel driver has run some of
its specific lowering passes, it looks like the problem could hit other
drivers if the right conditions are met, as the actual problem happens
inside common optimization passes.
I reproduced the problem with a very simple shader like this:
uniform sampler2D tex;
out vec4 FragColor;
void main()
{
vec4 col = texture(tex, vec2(0, 0));
for (int i=0; i30; i++)
col += vec4(0.1, 0.1, 0.1, 0.1);
col = vec4(col.rgb / 2.0, col.a);
FragColor = col;
}
and for this shader, I traced the problem down to the fact that
do_tree_grafting() is generating instructions like this:
(assign (x) (var_ref flattening_tmp_y@116) (expression float * (swiz x
(expression float + (swiz x (expression float + (swiz x (expression
float + (swiz x (expression float + (swiz x (expression float + (swiz x
(expression float + (swiz x (expression float + (swiz x (expression
float + (swiz x (expression float + (swiz x (expression float + (swiz x
(expression float + (swiz x (expression float + (swiz x (expression
float + (swiz x (expression float + (swiz x (expression float + (swiz x
(expression float + (swiz x (expression float + (swiz x (expression
float + (swiz x (expression float + (swiz x (expression float + (swiz x
(expression float + (swiz x (expression float + (swiz x (expression
float + (swiz x (expression float + (swiz x (expression float + (swiz x
(expression float + (swiz x (expression float + (swiz x (expression
float + (swiz x (expression float + (var_ref col_y) (constant float
(0.10)) ) )(constant float (0.10)) ) )(constant float
(0.10)) ) )(constant float (0.10)) ) )(constant float
(0.10)) ) )(constant
[Mesa-dev] [PATCH] nv50,nvc0: fix Z24 formats
also fixes nv50_blit_eng2d_get_mask for PIPE_FORMAT_X8Z24_UNORM
Tested-by: Tiziano Bacocco tizb...@gmail.com (on NVC0)
Signed-off-by: David Heidelberger david.heidelber...@ixit.cz
---
src/gallium/drivers/nouveau/nv50/nv50_blit.h| 26
-
src/gallium/drivers/nouveau/nv50/nv50_surface.c | 1 +
src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c | 1 +
3 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_blit.h
b/src/gallium/drivers/nouveau/nv50/nv50_blit.h
index bdd6a63..6b9ddac 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_blit.h
+++ b/src/gallium/drivers/nouveau/nv50/nv50_blit.h
@@ -111,6 +111,7 @@ nv50_blit_zeta_to_colour_format(enum pipe_format
format)
case PIPE_FORMAT_Z24_UNORM_S8_UINT:
case PIPE_FORMAT_S8_UINT_Z24_UNORM:
case PIPE_FORMAT_Z24X8_UNORM:
+ case PIPE_FORMAT_X8Z24_UNORM:
return PIPE_FORMAT_R8G8B8A8_UNORM;
case PIPE_FORMAT_Z32_FLOAT:
return PIPE_FORMAT_R32_FLOAT;
@@ -127,23 +128,20 @@ static INLINE uint16_t
nv50_blit_derive_color_mask(const struct pipe_blit_info *info)
{
const unsigned mask = info-mask;
-
uint16_t color_mask = 0;
switch (info-dst.format) {
case PIPE_FORMAT_Z24_UNORM_S8_UINT:
- if (mask PIPE_MASK_S)
- color_mask |= 0x1000;
+ if (mask PIPE_MASK_S) color_mask |= 0x1000;
/* fall through */
case PIPE_FORMAT_Z24X8_UNORM:
- if (mask PIPE_MASK_Z)
- color_mask |= 0x0111;
+ if (mask PIPE_MASK_Z) color_mask |= 0x0111;
break;
case PIPE_FORMAT_S8_UINT_Z24_UNORM:
- if (mask PIPE_MASK_Z)
- color_mask |= 0x1110;
- if (mask PIPE_MASK_S)
- color_mask |= 0x0001;
+ if (mask PIPE_MASK_S) color_mask |= 0x0001;
+ /* fall through */
+ case PIPE_FORMAT_X8Z24_UNORM:
+ if (mask PIPE_MASK_Z) color_mask |= 0x1110;
break;
default:
if (mask (PIPE_MASK_R | PIPE_MASK_Z)) color_mask |= 0x0001;
@@ -152,7 +150,6 @@ nv50_blit_derive_color_mask(const struct
pipe_blit_info *info)
if (mask PIPE_MASK_A) color_mask |= 0x1000;
break;
}
-
return color_mask;
}
@@ -163,15 +160,16 @@ nv50_blit_eng2d_get_mask(const struct
pipe_blit_info *info)
switch (info-dst.format) {
case PIPE_FORMAT_Z24_UNORM_S8_UINT:
- if (info-mask PIPE_MASK_Z) mask |= 0x00ff;
if (info-mask PIPE_MASK_S) mask |= 0xff00;
+ /* fall through */
+ case PIPE_FORMAT_Z24X8_UNORM:
+ if (info-mask PIPE_MASK_Z) mask |= 0x00ff;
break;
case PIPE_FORMAT_S8_UINT_Z24_UNORM:
- if (info-mask PIPE_MASK_Z) mask |= 0xff00;
if (info-mask PIPE_MASK_S) mask |= 0x00ff;
- break;
+ /* fall through */
case PIPE_FORMAT_X8Z24_UNORM:
- if (info-mask PIPE_MASK_Z) mask = 0x00ff;
+ if (info-mask PIPE_MASK_Z) mask |= 0xff00;
break;
default:
mask = 0x;
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_surface.c
b/src/gallium/drivers/nouveau/nv50/nv50_surface.c
index 3f33033..cc683e3 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_surface.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_surface.c
@@ -834,6 +834,7 @@ nv50_blit_select_mode(const struct pipe_blit_info
*info)
return NV50_BLIT_MODE_X24S8;
}
case PIPE_FORMAT_S8_UINT_Z24_UNORM:
+ case PIPE_FORMAT_X8Z24_UNORM:
switch (mask PIPE_MASK_ZS) {
case PIPE_MASK_ZS: return NV50_BLIT_MODE_S8Z24;
case PIPE_MASK_Z: return NV50_BLIT_MODE_X8Z24;
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c
index 3baa752..4b4d090 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c
@@ -53,6 +53,7 @@ nvc0_mt_choose_storage_type(struct nv50_miptree *mt,
boolean compressed)
else
tile_flags = 0x01;
break;
+ case PIPE_FORMAT_X8Z24_UNORM:
case PIPE_FORMAT_S8_UINT_Z24_UNORM:
if (compressed)
tile_flags = 0x51 + ms;
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nv50,nvc0: fix Z24 formats
On Thu, Sep 11, 2014 at 5:45 PM, David Heidelberger
david.heidelber...@ixit.cz wrote:
also fixes nv50_blit_eng2d_get_mask for PIPE_FORMAT_X8Z24_UNORM
Can you explain the problem a little bit and what the end-effect of
this fix is? If not, that's OK, I can probably work it out...
Tested-by: Tiziano Bacocco tizb...@gmail.com (on NVC0)
What was the test that was done? Full piglit run before and after?
Signed-off-by: David Heidelberger david.heidelber...@ixit.cz
---
src/gallium/drivers/nouveau/nv50/nv50_blit.h| 26
-
src/gallium/drivers/nouveau/nv50/nv50_surface.c | 1 +
src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c | 1 +
3 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_blit.h
b/src/gallium/drivers/nouveau/nv50/nv50_blit.h
index bdd6a63..6b9ddac 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_blit.h
+++ b/src/gallium/drivers/nouveau/nv50/nv50_blit.h
@@ -111,6 +111,7 @@ nv50_blit_zeta_to_colour_format(enum pipe_format format)
case PIPE_FORMAT_Z24_UNORM_S8_UINT:
case PIPE_FORMAT_S8_UINT_Z24_UNORM:
case PIPE_FORMAT_Z24X8_UNORM:
+ case PIPE_FORMAT_X8Z24_UNORM:
return PIPE_FORMAT_R8G8B8A8_UNORM;
case PIPE_FORMAT_Z32_FLOAT:
return PIPE_FORMAT_R32_FLOAT;
@@ -127,23 +128,20 @@ static INLINE uint16_t
nv50_blit_derive_color_mask(const struct pipe_blit_info *info)
{
const unsigned mask = info-mask;
-
uint16_t color_mask = 0;
switch (info-dst.format) {
case PIPE_FORMAT_Z24_UNORM_S8_UINT:
- if (mask PIPE_MASK_S)
- color_mask |= 0x1000;
+ if (mask PIPE_MASK_S) color_mask |= 0x1000;
/* fall through */
case PIPE_FORMAT_Z24X8_UNORM:
- if (mask PIPE_MASK_Z)
- color_mask |= 0x0111;
+ if (mask PIPE_MASK_Z) color_mask |= 0x0111;
break;
case PIPE_FORMAT_S8_UINT_Z24_UNORM:
- if (mask PIPE_MASK_Z)
- color_mask |= 0x1110;
- if (mask PIPE_MASK_S)
- color_mask |= 0x0001;
+ if (mask PIPE_MASK_S) color_mask |= 0x0001;
+ /* fall through */
+ case PIPE_FORMAT_X8Z24_UNORM:
+ if (mask PIPE_MASK_Z) color_mask |= 0x1110;
break;
default:
if (mask (PIPE_MASK_R | PIPE_MASK_Z)) color_mask |= 0x0001;
@@ -152,7 +150,6 @@ nv50_blit_derive_color_mask(const struct pipe_blit_info
*info)
if (mask PIPE_MASK_A) color_mask |= 0x1000;
break;
}
-
return color_mask;
}
@@ -163,15 +160,16 @@ nv50_blit_eng2d_get_mask(const struct pipe_blit_info
*info)
switch (info-dst.format) {
case PIPE_FORMAT_Z24_UNORM_S8_UINT:
- if (info-mask PIPE_MASK_Z) mask |= 0x00ff;
if (info-mask PIPE_MASK_S) mask |= 0xff00;
+ /* fall through */
+ case PIPE_FORMAT_Z24X8_UNORM:
+ if (info-mask PIPE_MASK_Z) mask |= 0x00ff;
break;
case PIPE_FORMAT_S8_UINT_Z24_UNORM:
- if (info-mask PIPE_MASK_Z) mask |= 0xff00;
if (info-mask PIPE_MASK_S) mask |= 0x00ff;
- break;
+ /* fall through */
case PIPE_FORMAT_X8Z24_UNORM:
- if (info-mask PIPE_MASK_Z) mask = 0x00ff;
+ if (info-mask PIPE_MASK_Z) mask |= 0xff00;
break;
default:
mask = 0x;
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_surface.c
b/src/gallium/drivers/nouveau/nv50/nv50_surface.c
index 3f33033..cc683e3 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_surface.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_surface.c
@@ -834,6 +834,7 @@ nv50_blit_select_mode(const struct pipe_blit_info *info)
return NV50_BLIT_MODE_X24S8;
}
case PIPE_FORMAT_S8_UINT_Z24_UNORM:
+ case PIPE_FORMAT_X8Z24_UNORM:
switch (mask PIPE_MASK_ZS) {
case PIPE_MASK_ZS: return NV50_BLIT_MODE_S8Z24;
case PIPE_MASK_Z: return NV50_BLIT_MODE_X8Z24;
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c
index 3baa752..4b4d090 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c
@@ -53,6 +53,7 @@ nvc0_mt_choose_storage_type(struct nv50_miptree *mt,
boolean compressed)
else
tile_flags = 0x01;
break;
+ case PIPE_FORMAT_X8Z24_UNORM:
case PIPE_FORMAT_S8_UINT_Z24_UNORM:
if (compressed)
tile_flags = 0x51 + ms;
--
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
Re: [Mesa-dev] [PATCH] nv50,nvc0: fix Z24 formats
I started using PIPE_FORMAT_X8Z24_UNORM and
PIPE_FORMAT_S8_UINT_Z24_UNORM in Nine state tracker.
As it shows up, it caused problems on NVC0 (PGRAPH errors), which are
solved by adding PIPE_FORMAT_X8Z24_UNORM in nvc0_miptree.c.
By quick grep I also noticed, there is lot places in nv50, where missing
case for S8Z24 and X8Z24 which may cause problems.
Also I fixed mask for PIPE_FORMAT_X8Z24_UNORM in
nv50_blit_eng2d_get_mask from 0x00ff to 0xff00 (same pattern as
for PIPE_FORMAT_S8_UINT_Z24_UNORM, which seems to be correct)
David
Dne 2014-09-11 23:01, Ilia Mirkin napsal:
On Thu, Sep 11, 2014 at 5:45 PM, David Heidelberger
david.heidelber...@ixit.cz wrote:
also fixes nv50_blit_eng2d_get_mask for PIPE_FORMAT_X8Z24_UNORM
Can you explain the problem a little bit and what the end-effect of
this fix is? If not, that's OK, I can probably work it out...
Tested-by: Tiziano Bacocco tizb...@gmail.com (on NVC0)
What was the test that was done? Full piglit run before and after?
Signed-off-by: David Heidelberger david.heidelber...@ixit.cz
---
src/gallium/drivers/nouveau/nv50/nv50_blit.h| 26
-
src/gallium/drivers/nouveau/nv50/nv50_surface.c | 1 +
src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c | 1 +
3 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_blit.h
b/src/gallium/drivers/nouveau/nv50/nv50_blit.h
index bdd6a63..6b9ddac 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_blit.h
+++ b/src/gallium/drivers/nouveau/nv50/nv50_blit.h
@@ -111,6 +111,7 @@ nv50_blit_zeta_to_colour_format(enum pipe_format
format)
case PIPE_FORMAT_Z24_UNORM_S8_UINT:
case PIPE_FORMAT_S8_UINT_Z24_UNORM:
case PIPE_FORMAT_Z24X8_UNORM:
+ case PIPE_FORMAT_X8Z24_UNORM:
return PIPE_FORMAT_R8G8B8A8_UNORM;
case PIPE_FORMAT_Z32_FLOAT:
return PIPE_FORMAT_R32_FLOAT;
@@ -127,23 +128,20 @@ static INLINE uint16_t
nv50_blit_derive_color_mask(const struct pipe_blit_info *info)
{
const unsigned mask = info-mask;
-
uint16_t color_mask = 0;
switch (info-dst.format) {
case PIPE_FORMAT_Z24_UNORM_S8_UINT:
- if (mask PIPE_MASK_S)
- color_mask |= 0x1000;
+ if (mask PIPE_MASK_S) color_mask |= 0x1000;
/* fall through */
case PIPE_FORMAT_Z24X8_UNORM:
- if (mask PIPE_MASK_Z)
- color_mask |= 0x0111;
+ if (mask PIPE_MASK_Z) color_mask |= 0x0111;
break;
case PIPE_FORMAT_S8_UINT_Z24_UNORM:
- if (mask PIPE_MASK_Z)
- color_mask |= 0x1110;
- if (mask PIPE_MASK_S)
- color_mask |= 0x0001;
+ if (mask PIPE_MASK_S) color_mask |= 0x0001;
+ /* fall through */
+ case PIPE_FORMAT_X8Z24_UNORM:
+ if (mask PIPE_MASK_Z) color_mask |= 0x1110;
break;
default:
if (mask (PIPE_MASK_R | PIPE_MASK_Z)) color_mask |= 0x0001;
@@ -152,7 +150,6 @@ nv50_blit_derive_color_mask(const struct
pipe_blit_info
*info)
if (mask PIPE_MASK_A) color_mask |= 0x1000;
break;
}
-
return color_mask;
}
@@ -163,15 +160,16 @@ nv50_blit_eng2d_get_mask(const struct
pipe_blit_info
*info)
switch (info-dst.format) {
case PIPE_FORMAT_Z24_UNORM_S8_UINT:
- if (info-mask PIPE_MASK_Z) mask |= 0x00ff;
if (info-mask PIPE_MASK_S) mask |= 0xff00;
+ /* fall through */
+ case PIPE_FORMAT_Z24X8_UNORM:
+ if (info-mask PIPE_MASK_Z) mask |= 0x00ff;
break;
case PIPE_FORMAT_S8_UINT_Z24_UNORM:
- if (info-mask PIPE_MASK_Z) mask |= 0xff00;
if (info-mask PIPE_MASK_S) mask |= 0x00ff;
- break;
+ /* fall through */
case PIPE_FORMAT_X8Z24_UNORM:
- if (info-mask PIPE_MASK_Z) mask = 0x00ff;
+ if (info-mask PIPE_MASK_Z) mask |= 0xff00;
break;
default:
mask = 0x;
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_surface.c
b/src/gallium/drivers/nouveau/nv50/nv50_surface.c
index 3f33033..cc683e3 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_surface.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_surface.c
@@ -834,6 +834,7 @@ nv50_blit_select_mode(const struct pipe_blit_info
*info)
return NV50_BLIT_MODE_X24S8;
}
case PIPE_FORMAT_S8_UINT_Z24_UNORM:
+ case PIPE_FORMAT_X8Z24_UNORM:
switch (mask PIPE_MASK_ZS) {
case PIPE_MASK_ZS: return NV50_BLIT_MODE_S8Z24;
case PIPE_MASK_Z: return NV50_BLIT_MODE_X8Z24;
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c
index 3baa752..4b4d090 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c
@@ -53,6 +53,7 @@ nvc0_mt_choose_storage_type(struct nv50_miptree *mt,
boolean compressed)
else
tile_flags = 0x01;
break;
+ case PIPE_FORMAT_X8Z24_UNORM:
case PIPE_FORMAT_S8_UINT_Z24_UNORM:
if (compressed)
tile_flags = 0x51 + ms;
--
2.1.0
[Mesa-dev] [PATCH] Copy Layered field in reuse_framebuffer_texture_attachment
Fix #83596 https://bugs.freedesktop.org/show_bug.cgi?id=83596 --- src/mesa/main/fbobject.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c index ae3a418..5eaf1a3 100644 --- a/src/mesa/main/fbobject.c +++ b/src/mesa/main/fbobject.c @@ -2299,6 +2299,7 @@ reuse_framebuffer_texture_attachment(struct gl_framebuffer *fb, dst_att-Complete = src_att-Complete; dst_att-TextureLevel = src_att-TextureLevel; dst_att-Zoffset = src_att-Zoffset; + dst_att-Layered = src_att-Layered; } -- 1.9.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 08/13] mesa/format_utils: Add a general format conversion function
Am 15.08.2014 04:50, schrieb Jason Ekstrand: On Aug 14, 2014 7:13 PM, Dieter Nützel die...@nuetzel-hh.de wrote: Am 15.08.2014 02:36, schrieb Dave Airlie: On 08/02/2014 02:11 PM, Jason Ekstrand wrote: Most format conversion operations required by GL can be performed by converting one channel at a time, shuffling the channels around, and optionally filling missing channels with zeros and ones. This adds a function to do just that in a general, yet efficient, way. v2: * Add better comments including full docs for functions * Don't use __typeof__ * Use inline helpers instead of writing out conversions by hand, * Force full loop unrolling for better performance This file seems to anger gcc a lot. It seems to take upwards of a minute or two to compile here. gcc 4.8.3 on 32-bit x86. Dave. For me (on our poor little Duron 1800/2 GB) it ran ~5 minutes... gcc 4.8.1 on 32-bit x86. If we'd like, the way the macros are set up, it would be easy to change it so that we do less unrolling in the cases where we are actually doing substantial format conversion and wouldn't notice the extra logic quite as much. I'll play with it a bit tomorrow or next week and see how how much of a hit we would actually take if we unrolled a little less in places. --Jason Ekstrand Ping. In a second it took 11+ minutes , here... Thanks! Dieter ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Copy Layered field in reuse_framebuffer_texture_attachment
It would be good to also have a piglit test which demonstrates this bad behavior. Patch is: Reviewed-by: Chris Forbes chr...@ijw.co.nz On Fri, Sep 12, 2014 at 9:42 AM, Vincent Lejeune v...@ovi.com wrote: Fix #83596 https://bugs.freedesktop.org/show_bug.cgi?id=83596 --- src/mesa/main/fbobject.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c index ae3a418..5eaf1a3 100644 --- a/src/mesa/main/fbobject.c +++ b/src/mesa/main/fbobject.c @@ -2299,6 +2299,7 @@ reuse_framebuffer_texture_attachment(struct gl_framebuffer *fb, dst_att-Complete = src_att-Complete; dst_att-TextureLevel = src_att-TextureLevel; dst_att-Zoffset = src_att-Zoffset; + dst_att-Layered = src_att-Layered; } -- 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] Mesa 10.3 release plan
On 09/10/2014 05:45 AM, Emil Velikov wrote: Hello all, The original plan from Ian was to have four release candidates prior to the final release. From what I can see there has been no serious amount of patches nominated for 10.3-rc4, so I'm planning to keep with the plan and release 10.3 this Friday. If you know of any serious issues that must land or any other reason why we should delay 10.3 please let me know ASAP. I hope this is soon enough. :( Ken and I have a few bug fixes that we'd like to have land in the release. I think they're all out on the list for review, but Ken might have one more. Once they land on master, I'll send you a pull-request. Could we do one more RC tomorrow and the final release next week? We probably don't need to wait until Friday, but I don't have a strong opinion. 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 v2 08/13] mesa/format_utils: Add a general format conversion function
On Thu, Sep 11, 2014 at 2:55 PM, Dieter Nützel die...@nuetzel-hh.de wrote: Am 15.08.2014 04:50, schrieb Jason Ekstrand: On Aug 14, 2014 7:13 PM, Dieter Nützel die...@nuetzel-hh.de wrote: Am 15.08.2014 02:36, schrieb Dave Airlie: On 08/02/2014 02:11 PM, Jason Ekstrand wrote: Most format conversion operations required by GL can be performed by converting one channel at a time, shuffling the channels around, and optionally filling missing channels with zeros and ones. This adds a function to do just that in a general, yet efficient, way. v2: * Add better comments including full docs for functions * Don't use __typeof__ * Use inline helpers instead of writing out conversions by hand, * Force full loop unrolling for better performance This file seems to anger gcc a lot. It seems to take upwards of a minute or two to compile here. gcc 4.8.3 on 32-bit x86. Dave. For me (on our poor little Duron 1800/2 GB) it ran ~5 minutes... gcc 4.8.1 on 32-bit x86. If we'd like, the way the macros are set up, it would be easy to change it so that we do less unrolling in the cases where we are actually doing substantial format conversion and wouldn't notice the extra logic quite as much. I'll play with it a bit tomorrow or next week and see how how much of a hit we would actually take if we unrolled a little less in places. --Jason Ekstrand Ping. In a second it took 11+ minutes , here... 11 minutes! What system are you running? and are you using -03 or something? Yes, we can do something to cut it down, but it will probably require a configure flag; the question is what flag. --Jason ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Generate a warning when not writing gl_Position with GLES.
On Wed, Sep 10, 2014 at 8:20 PM, Kalyan Kondapally
kondapallykalyancontrib...@gmail.com wrote:
With GLES we don't give any kind of warning in case we don't
write to gl_position. This patch makes changes so that we
generate a warning in case of GLES (VER 300) and an error
in case of GL.
Signed-off-by: Kalyan Kondapally kalyan.kondapa...@intel.com
---
src/glsl/linker.cpp | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index e9cf550..f4a35e2 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -562,11 +562,18 @@ validate_vertex_shader_executable(struct
gl_shader_program *prog,
* All GLSL ES Versions are similar to GLSL 1.40--failing to write to
* gl_Position is not an error.
*/
- if (!prog-IsES prog-Version 140) {
+ if (prog-Version (prog-IsES ? 300 : 140)) {
find_assignment_visitor find(gl_Position);
find.run(shader-ir);
if (!find.variable_found()) {
-linker_error(prog, vertex shader does not write to
`gl_Position'\n);
+if (prog-IsES) {
+ linker_warning(prog,
+ vertex shader does not write to `gl_Position'.
+ It's value is undefined. \n);
+} else {
+ linker_error(prog,
+ vertex shader does not write to `gl_Position'. \n);
+}
return;
}
}
--
1.7.9.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Reviewed-by: Anuj Phogat anuj.pho...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 08/13] mesa/format_utils: Add a general format conversion function
On Thu, Sep 11, 2014 at 3:31 PM, Jason Ekstrand ja...@jlekstrand.net wrote: On Thu, Sep 11, 2014 at 2:55 PM, Dieter Nützel die...@nuetzel-hh.de wrote: Am 15.08.2014 04:50, schrieb Jason Ekstrand: On Aug 14, 2014 7:13 PM, Dieter Nützel die...@nuetzel-hh.de wrote: Am 15.08.2014 02:36, schrieb Dave Airlie: On 08/02/2014 02:11 PM, Jason Ekstrand wrote: Most format conversion operations required by GL can be performed by converting one channel at a time, shuffling the channels around, and optionally filling missing channels with zeros and ones. This adds a function to do just that in a general, yet efficient, way. v2: * Add better comments including full docs for functions * Don't use __typeof__ * Use inline helpers instead of writing out conversions by hand, * Force full loop unrolling for better performance This file seems to anger gcc a lot. It seems to take upwards of a minute or two to compile here. gcc 4.8.3 on 32-bit x86. Dave. For me (on our poor little Duron 1800/2 GB) it ran ~5 minutes... gcc 4.8.1 on 32-bit x86. If we'd like, the way the macros are set up, it would be easy to change it so that we do less unrolling in the cases where we are actually doing substantial format conversion and wouldn't notice the extra logic quite as much. I'll play with it a bit tomorrow or next week and see how how much of a hit we would actually take if we unrolled a little less in places. --Jason Ekstrand Ping. In a second it took 11+ minutes , here... 11 minutes! What system are you running? and are you using -03 or something? Yes, we can do something to cut it down, but it will probably require a configure flag; the question is what flag. --Jason I'm also open to re-factoring it in some way that's a little easier on compilers. That said, it's very sensitive to performance, so whatever refactor gets done will have to be done carefully. --Jason ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 08/13] mesa/format_utils: Add a general format conversion function
Am 12.09.2014 00:31, schrieb Jason Ekstrand: On Thu, Sep 11, 2014 at 2:55 PM, Dieter Nützel die...@nuetzel-hh.de wrote: Am 15.08.2014 04:50, schrieb Jason Ekstrand: On Aug 14, 2014 7:13 PM, Dieter Nützel die...@nuetzel-hh.de wrote: Am 15.08.2014 02:36, schrieb Dave Airlie: On 08/02/2014 02:11 PM, Jason Ekstrand wrote: Most format conversion operations required by GL can be performed by converting one channel at a time, shuffling the channels around, and optionally filling missing channels with zeros and ones. This adds a function to do just that in a general, yet efficient, way. v2: * Add better comments including full docs for functions * Don't use __typeof__ * Use inline helpers instead of writing out conversions by hand, * Force full loop unrolling for better performance This file seems to anger gcc a lot. It seems to take upwards of a minute or two to compile here. gcc 4.8.3 on 32-bit x86. Dave. For me (on our poor little Duron 1800/2 GB) it ran ~5 minutes... gcc 4.8.1 on 32-bit x86. If we'd like, the way the macros are set up, it would be easy to change it so that we do less unrolling in the cases where we are actually doing substantial format conversion and wouldn't notice the extra logic quite as much. I'll play with it a bit tomorrow or next week and see how how much of a hit we would actually take if we unrolled a little less in places. --Jason Ekstrand Ping. In a second it took 11+ minutes , here... 11 minutes! What system are you running? and are you using -03 or something? Yes, we can do something to cut it down, but it will probably require a configure flag; the question is what flag. --Jason See above, the old children's system... ;-) -O2 -m32 -march=athlon-mp -mtune=athlon-mp -m3dnow -msse -mmmx -mfpmath=sse,387 -pipe Bad? - Worked for ages on AthlonMP8-) Maybe it is bad on Duron (the MP thing, much smaller cache and better GCC), now. Dieter ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 08/13] mesa/format_utils: Add a general format conversion function
On Thu, Sep 11, 2014 at 3:53 PM, Dieter Nützel die...@nuetzel-hh.de wrote: Am 12.09.2014 00:31, schrieb Jason Ekstrand: On Thu, Sep 11, 2014 at 2:55 PM, Dieter Nützel die...@nuetzel-hh.de wrote: Am 15.08.2014 04:50, schrieb Jason Ekstrand: On Aug 14, 2014 7:13 PM, Dieter Nützel die...@nuetzel-hh.de wrote: Am 15.08.2014 02:36, schrieb Dave Airlie: On 08/02/2014 02:11 PM, Jason Ekstrand wrote: Most format conversion operations required by GL can be performed by converting one channel at a time, shuffling the channels around, and optionally filling missing channels with zeros and ones. This adds a function to do just that in a general, yet efficient, way. v2: * Add better comments including full docs for functions * Don't use __typeof__ * Use inline helpers instead of writing out conversions by hand, * Force full loop unrolling for better performance This file seems to anger gcc a lot. It seems to take upwards of a minute or two to compile here. gcc 4.8.3 on 32-bit x86. Dave. For me (on our poor little Duron 1800/2 GB) it ran ~5 minutes... gcc 4.8.1 on 32-bit x86. If we'd like, the way the macros are set up, it would be easy to change it so that we do less unrolling in the cases where we are actually doing substantial format conversion and wouldn't notice the extra logic quite as much. I'll play with it a bit tomorrow or next week and see how how much of a hit we would actually take if we unrolled a little less in places. --Jason Ekstrand Ping. In a second it took 11+ minutes , here... 11 minutes! What system are you running? and are you using -03 or something? Yes, we can do something to cut it down, but it will probably require a configure flag; the question is what flag. --Jason See above, the old children's system... ;-) -O2 -m32 -march=athlon-mp -mtune=athlon-mp -m3dnow -msse -mmmx -mfpmath=sse,387 -pipe Bad? - Worked for ages on AthlonMP8-) Maybe it is bad on Duron (the MP thing, much smaller cache and better GCC), now. Dieter Yeah, my recommendation would be hacking the macros to not unroll and keep the patch locally. If you've got a better idea as to how to organize the code so the compiler likes it, I'm open as long as we don't loose performance. --Jason ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 83777] [regression] ilo fails to build
https://bugs.freedesktop.org/show_bug.cgi?id=83777 --- Comment #1 from sarnex commendsar...@gmail.com --- Exact same issue here. -- 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 83777] [regression] ilo fails to build
https://bugs.freedesktop.org/show_bug.cgi?id=83777 sarnex commendsar...@gmail.com changed: What|Removed |Added Severity|normal |major Priority|medium |high -- 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 83777] [regression] ilo fails to build
https://bugs.freedesktop.org/show_bug.cgi?id=83777 sarnex commendsar...@gmail.com changed: What|Removed |Added Severity|major |critical -- 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 83777] [regression] ilo fails to build
https://bugs.freedesktop.org/show_bug.cgi?id=83777 Chia-I Wu olva...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Chia-I Wu olva...@gmail.com --- This should have been fixed by commit 1187dbdd10. Thanks. -- 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 83785] New: Shader branches excluded by uniform values are not optimized out
https://bugs.freedesktop.org/show_bug.cgi?id=83785
Priority: medium
Bug ID: 83785
Assignee: mesa-dev@lists.freedesktop.org
Summary: Shader branches excluded by uniform values are not
optimized out
Severity: major
Classification: Unclassified
OS: All
Reporter: rcond...@hotmail.com
Hardware: x86-64 (AMD64)
Status: NEW
Version: 10.2
Component: Mesa core
Product: Mesa
In investigating bug 83570 I noticed that for shader code such as
uniform bool u_debug;
if(!u_debug)
{
//do some stuff
}
else
{
//do some other stuff
}
both the if and else are executing. Seems like a pretty trivial
optimization...is there a reason it doesn't optimize out the excluded branch,
or is it just yet to be done?
--
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 83785] Shader branches excluded by uniform values are not optimized out
https://bugs.freedesktop.org/show_bug.cgi?id=83785 Roland Scheidegger srol...@vmware.com changed: What|Removed |Added Severity|major |enhancement Component|Mesa core |Other --- Comment #1 from Roland Scheidegger srol...@vmware.com --- Are you talking about specific drivers? Doesn't look like a mesa core problem to me, since if it's a uniform glsl can't do anything, and drivers will have to handle that appropriately (typically hw either has if/else constructs with implicit built-in mask evaluation so there's jump addresses specified there (intel hd graphics seems to work like that) or the jump is done explicitly (radeon gcn seems to do that). If you're talking llvmpipe, you would be right it always evaluates all branches, no matter the current condition mask (which, in case the branch condition is based only on uniforms, indeed means one part of the branch will always be executed for nothing), and simply masks out the values for the not taken branch part when storing the values. This is probably both due to simplicity and historical reasons (don't forget early programmable hw did not always have true branches neither). It is something I was thinking about, I think there'd definitely be benefits but I never looked at it closely enough to know how much work it would be. For starters, you'd need to put the code in the branches into different basic blocks, and get all the things right related to it. In some cases it could possibly be a loss due to missing some optimizations (if both branches need to be evaluated - I don't think you'd want to do this just in case of uniform branch condition, though this might be a start). -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: check that uniform exists in glUniform* functions
On 09/11/2014 09:39 PM, Ian Romanick wrote:
On 08/28/2014 12:58 AM, Tapani Pälli wrote:
Remap table for uniforms may contain empty entries when using explicit
uniform locations. If no active/inactive variable exists with given
location, remap table contains NULL.
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
---
src/mesa/main/uniform_query.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/uniform_query.cpp
b/src/mesa/main/uniform_query.cpp
index 4cd2bca..5dcb528 100644
--- a/src/mesa/main/uniform_query.cpp
+++ b/src/mesa/main/uniform_query.cpp
@@ -239,7 +239,7 @@ validate_uniform_parameters(struct gl_context *ctx,
* - if count is greater than one, and the uniform declared in
the
* shader is not an array variable,
*/
- if (location -1) {
+ if (location -1 || !shProg-UniformRemapTable[location]) {
_mesa_error(ctx, GL_INVALID_OPERATION, %s(location=%d),
caller, location);
return NULL;
So... this would occur if someone explicitly put uniforms at locations 0
and 2, then queried location 1, right? What happens if someone queries
location 0x7fff? Will it commit an out-of-bounds acces of
UniformRemapTable, or is there an earlier check that's not visible in
the patch?
Right, the checks are in wrong order now .. I'll make a v2 and move the
upper bounds check to happen before this one, this fixes both cases
properly.
Thanks;
// Tapani
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] i965: Skip allocating UNIFORM file storage for uniforms of size 0.
Samplers take up zero slots and therefore don't exist in the params
array, nor are they included in stage_prog_data-nr_params. There's no
need to store their size in param_size, as it's only used for dealing
with arrays of real uniforms (ones uploaded as shader constants).
We run into all kinds of problems trying to refer to the uniform storage
for variables that don't have uniform storage. For one, we may use some
other variable's index, or access out of bounds in arrays. In the FS
backend, our extra 2 * MaxSamplerImageUnits params for texture rectangle
rescaling paper over a lot of problems. In the VS backend, we claim
samplers take up a slot, which also papers over problems.
Instead, just skip allocating storage for variables that don't have any.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
Cc: mesa-sta...@lists.freedesktop.org
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 6 +++---
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 5d2e7c8..2d5318a 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -109,10 +109,10 @@ fs_visitor::visit(ir_variable *ir)
* ir_binop_ubo_load expressions and not ir_dereference_variable for UBO
* variables, so no need for them to be in variable_ht.
*
- * Atomic counters take no uniform storage, no need to do
- * anything here.
+ * Some uniforms, such as samplers and atomic counters, have no actual
+ * storage, so we should ignore them.
*/
- if (ir-is_in_uniform_block() || ir-type-contains_atomic())
+ if (ir-is_in_uniform_block() || type_size(ir-type) == 0)
return;
if (dispatch_width == 16) {
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index 1e823da..d504e2e 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -1023,10 +1023,10 @@ vec4_visitor::visit(ir_variable *ir)
* ir_binop_ubo_load expressions and not ir_dereference_variable for UBO
* variables, so no need for them to be in variable_ht.
*
- * Atomic counters take no uniform storage, no need to do
- * anything here.
+ * Some uniforms, such as samplers and atomic counters, have no actual
+ * storage, so we should ignore them.
*/
- if (ir-is_in_uniform_block() || ir-type-contains_atomic())
+ if (ir-is_in_uniform_block() || type_size(ir-type) == 0)
return;
/* Track how big the whole uniform variable is, in case we need to put a
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] i965/vec4: Make type_size() return 0 for samplers.
The FS backend has always used 0, and the VS backend has always used 1. I think 1 is just working around other problems, and is incorrect. Samplers are baked in; nothing uses the UNIFORM register we would create, and we shouldn't upload any constant values for them. Fixes ES3-CTS.shaders.struct.uniform.sampler_array_vertex. Signed-off-by: Kenneth Graunke kenn...@whitecape.org Cc: mesa-sta...@lists.freedesktop.org --- src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp index d504e2e..473b3c5 100644 --- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp +++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp @@ -588,10 +588,10 @@ type_size(const struct glsl_type *type) } return size; case GLSL_TYPE_SAMPLER: - /* Samplers take up one slot in UNIFORMS[], but they're baked in - * at link time. + /* Samplers take up no register space, since they're baked in at + * link time. */ - return 1; + return 0; case GLSL_TYPE_ATOMIC_UINT: return 0; case GLSL_TYPE_IMAGE: -- 2.1.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 70599] [SNB/IVB/HSW Bisected]Piglit glx/GLX_ARB_create_context/current_with_no_framebuffer segfault
https://bugs.freedesktop.org/show_bug.cgi?id=70599
lu hua huax...@intel.com changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
--- Comment #3 from lu hua huax...@intel.com ---
(In reply to comment #2)
The commit mentioned in the bug description has been reverted from Mesa 9.2
tree, the test still fails on 9.2 but does not segfault.
Mesa versions with the test:
- 9.2 fail
- 10.0 segfault
- 10.1 pass
- 10.2 pass
- 10.3 pass
- 10.4-dev (6816d85) pass
For gallium it has been fixed to pass by commit db8b6fb, not sure what fixes
it for others. As it now passes on master, I'll resolved this as fixed.
Test on mesa master branch and 10.3 branch.
The segfault goes away, but it's fail(Bug 79629). Close it.
output:
PIGLIT: {result: fail }
--
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
