[Mesa-dev] [PATCH] u_blitter: don't create illegal shaders for 1D/3D/RECT/CUBE MSAA
From: Dave Airlie airl...@redhat.com
I hit an assert playing with softpipe and texture MSAA today, makes me think
we might need something like this to stop creating illegal shaders.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/gallium/auxiliary/util/u_blitter.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/gallium/auxiliary/util/u_blitter.c
b/src/gallium/auxiliary/util/u_blitter.c
index e37be4e..ceaa9d0 100644
--- a/src/gallium/auxiliary/util/u_blitter.c
+++ b/src/gallium/auxiliary/util/u_blitter.c
@@ -924,6 +924,11 @@ void util_blitter_cache_all_shaders(struct blitter_context
*blitter)
(target == PIPE_TEXTURE_CUBE_ARRAY))
continue;
+if (max_samples 1
+(target != PIPE_TEXTURE_2D
+ target != PIPE_TEXTURE_2D_ARRAY))
+ continue;
+
blitter_get_fs_texfetch_col(ctx, target, i);
blitter_get_fs_texfetch_depth(ctx, target, i);
if (ctx-has_stencil_export) {
--
1.8.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] OES_external_image for i965
On Fri, Mar 01, 2013 at 10:03:45AM -0500, Kristian H?gsberg wrote: On Fri, Mar 1, 2013 at 3:51 AM, Pohjolainen, Topi topi.pohjolai...@intel.com wrote: On Tue, Feb 26, 2013 at 04:05:25PM +, Tom Cooksey wrote: Hi Topi, The second more or less questionable part is the support for creating YUV buffers. In order to test for YUV sampling one needs a way of providing them for the EGL stack. Here I chose to augment the dri driver backing gbm as I couldn't come up with anything better. It may be helpful to take a look at the corresponding piglit test case and framework support I've written for it. You might want to take a look at the EGL_EXT_image_dma_buf_import[i] which has been written specifically for this purpose. Though this does assume you have a driver which supports exporting a YUV buffer it has allocated with dma_buf, such as a v4l2 driver or even ion on Android. It certainly looks good addressing not only the individual plane setup but allowing one to control also the conversion coefficients and subsampling position. Coming from piglit testing point of view, do you have any ideas where to allocate the buffers from? I guess people wouldn't be too happy seeing v4l2 tied into piglit, for example. SInce you're already using intel specific ioctls to mmap the buffers, I'd suggest you just go all the way and allocate using intel specific ioctls (like my simple-yuv.c example). I don't really see any other approach, but it's not pretty... I used gbm buffer objects in order to match the logic later in 'dri2_drm_create_image_khr()' which expects the buffer to be of the type 'gbm_dri_bo' (gbm_bo) for the target EGL_NATIVE_PIXMAP_KHR. Giving drm buffer objects instead would require new target, I guess? Topi ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] st/mesa: add switch case for ir_txf_ms to silence warning
Am 02.03.2013 04:26, schrieb Dave Airlie:
On Sat, Mar 2, 2013 at 12:02 PM, Roland Scheidegger srol...@vmware.com
wrote:
Am 02.03.2013 01:36, schrieb Brian Paul:
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 8e3e3b8..c41b583 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -2746,6 +2746,9 @@ glsl_to_tgsi_visitor::visit(ir_texture *ir)
offset = this-result;
}
break;
+ case ir_txf_ms:
+ assert(!Unexpected ir_txf_ms opcode);
+ break;
}
if (ir-projector) {
Series looks good to me. I guess we need a new opcode like
(TGSI_OPCODE_TXF_MS?), unless we switch everything over and only use the
new sample style opcodes which already have that (SAMPLE_I_MS) :-).
I'm not really sure we do, from what I can see TXF is sufficent since
LOD is bogus with MS textures so you can reuse the slot. r600 hw at
least only has one LD instruction from what I can see.
Hmm yes but it doesn't sound like a very clean solution, to reuse the
opcode for something a bit different. Though granted since with the
combined texture/sampler state you always know the target (unlike with
the sample_i opcodes) it should be always possible to distinguish
txf-with-lod from txf-with-sample so it might indeed be ok.
Roland
I've already done a good bit of the state tracker for this, I just
need to get a driver I can run it on :-)
(gallium-texture-multisample branch in my repo)
Dave
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] multisample clears
Am 04.03.2013 04:54, schrieb Dave Airlie:
I've been playing with softpipe msaa on and off, but I hit a problem
with the clears and am just wondering if the state tracker should be
doing something like this.
Or maybe only if any bound buffer has nr_samples 1, or fallback to
the non-quad draw method.
I can't see how else the driver could distinguish a multisample clear.
The other problem I have and not figuring out is if rendering to a
buffer with multisample off, then turning it on is meant to be
meaningful, if you have to clear
the buffer in between, then with this fixed it should be cool.
Dave.
From e1ee59d87ba42d8a58be640ee1fd2b952414f45e Mon Sep 17 00:00:00 2001
From: Dave Airlie airl...@redhat.com
Date: Mon, 4 Mar 2013 13:39:17 +1000
Subject: [PATCH] st/mesa: enable multisample in clear quad code
Not sure if this is correct at all
---
src/mesa/state_tracker/st_cb_clear.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/src/mesa/state_tracker/st_cb_clear.c
b/src/mesa/state_tracker/st_cb_clear.c
index 4aa0bc1..649d7bd 100644
--- a/src/mesa/state_tracker/st_cb_clear.c
+++ b/src/mesa/state_tracker/st_cb_clear.c
@@ -282,7 +282,14 @@ clear_with_quad(struct gl_context *ctx,
cso_set_vertex_elements(st-cso_context, 2, st-velems_util_draw);
cso_set_stream_outputs(st-cso_context, 0, NULL, 0);
cso_set_sample_mask(st-cso_context, ~0);
- cso_set_rasterizer(st-cso_context, st-clear.raster);
+
+ {
+ struct pipe_rasterizer_state rs = st-clear.raster;
+
+ if (st-ctx-Multisample.Enabled)
+ rs.multisample = 1;
+ cso_set_rasterizer(st-cso_context, rs);
+ }
/* viewport state: viewport matching window dims */
{
Hmm I don't think this should be necessary (but it should be ok), since
it is perfectly legal to do non-multisampled rendering into a
multisampled buffer. The semantics of this are somewhat loose (you are
for instance allowed to perform depth test against a centermost sample
or do the test depth against individual samples, but in any case
rasterization will only have produced one depth value, and that depth
value is written to all samples if the depth test passes (but don't ask
me when the depth test is considered passed when you test against each
sample but still only can write the same value for all samples, I guess
it's easier to simply pick one sample)). Likewise all color samples are
set to the same value.
So as far as I can tell a clear should work with the same result,
regardless if you have multisampling enabled or not.
So yes it is indeed somewhat meaningful to render to a multisampled
buffer with multisampling off and on (though I'm quite sure some hw and
drivers don't quite support it correctly, it is probably not something
apps would do).
Roland
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] gallium: add get_sample_position interface
Am 03.03.2013 21:27, schrieb Dave Airlie:
From: Dave Airlie airl...@redhat.com
This is to be used to implement glGet GL_SAMPLE_POSITION.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/gallium/include/pipe/p_context.h | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/include/pipe/p_context.h
b/src/gallium/include/pipe/p_context.h
index 7ed946e..4ffee20 100644
--- a/src/gallium/include/pipe/p_context.h
+++ b/src/gallium/include/pipe/p_context.h
@@ -520,6 +520,10 @@ struct pipe_context {
const uint *block_layout, const uint *grid_layout,
uint32_t pc, const void *input);
/*@}*/
+ void (*get_sample_position)(struct pipe_context *context,
+ int max_samples,
+ unsigned sample_index,
+ float *out_value);
};
It looks like GL wants that function to depend on the currently bound
visual, and this is format-indepedent (which seems to be more sane
indeed). I think though max_samples should be num_samples or
something similar. Also some doc would be nice.
Otherwise LGTM.
Roland
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 61764] invalid enum in glEnable, glConvolutionFilter, glSeparableFilter, glColorTable
https://bugs.freedesktop.org/show_bug.cgi?id=61764 Roland Scheidegger srol...@vmware.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTABUG --- Comment #1 from Roland Scheidegger srol...@vmware.com --- Mesa does not (or rather, no longer, it did at some point) support the clunky and legacy ARB_imaging subset. Therefore, trying to use functions or enumerants requiring that extension will indeed generate errors. -- 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 61761] glPolygonOffsetEXT, OFFSET_BIAS incorrectly set to a huge number
https://bugs.freedesktop.org/show_bug.cgi?id=61761 --- Comment #1 from Roland Scheidegger srol...@vmware.com --- Looks like when using PolygonOffsetEXT() mesa will multiply the bias value by _DepthMaxF to set offset units (hence the same as calling PolygonOffset(). But the get will just return offset units instead of bias instead. I guess to really support that correctly we'd need to store bias separately. After all _DepthMaxF of the bound draw buffer could change. I don't know though if anyone is interested in that or we should just drop it... -- 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 2/2] st/mesa: add switch case for ir_txf_ms to silence warning
On Mon, Mar 4, 2013 at 11:53 AM, Roland Scheidegger srol...@vmware.com wrote:
Am 02.03.2013 04:26, schrieb Dave Airlie:
On Sat, Mar 2, 2013 at 12:02 PM, Roland Scheidegger srol...@vmware.com
wrote:
Am 02.03.2013 01:36, schrieb Brian Paul:
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 8e3e3b8..c41b583 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -2746,6 +2746,9 @@ glsl_to_tgsi_visitor::visit(ir_texture *ir)
offset = this-result;
}
break;
+ case ir_txf_ms:
+ assert(!Unexpected ir_txf_ms opcode);
+ break;
}
if (ir-projector) {
Series looks good to me. I guess we need a new opcode like
(TGSI_OPCODE_TXF_MS?), unless we switch everything over and only use the
new sample style opcodes which already have that (SAMPLE_I_MS) :-).
I'm not really sure we do, from what I can see TXF is sufficent since
LOD is bogus with MS textures so you can reuse the slot. r600 hw at
least only has one LD instruction from what I can see.
Hmm yes but it doesn't sound like a very clean solution, to reuse the
opcode for something a bit different. Though granted since with the
combined texture/sampler state you always know the target (unlike with
the sample_i opcodes) it should be always possible to distinguish
txf-with-lod from txf-with-sample so it might indeed be ok.
There is no need to look at the texture or sampler state. TGSI texture
instructions specify their own texture target (TGSI_TEXTURE_*). For
example:
TXF OUT[0], IN[0], 2D_MSAA
Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] u_blitter: don't create illegal shaders for 1D/3D/RECT/CUBE MSAA
The conditional should be if (i 1 ..; with that fixed, this is:
Reviewed-by: Marek Olšák mar...@gmail.com
Marek
On Mon, Mar 4, 2013 at 9:02 AM, Dave Airlie airl...@gmail.com wrote:
From: Dave Airlie airl...@redhat.com
I hit an assert playing with softpipe and texture MSAA today, makes me think
we might need something like this to stop creating illegal shaders.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/gallium/auxiliary/util/u_blitter.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/gallium/auxiliary/util/u_blitter.c
b/src/gallium/auxiliary/util/u_blitter.c
index e37be4e..ceaa9d0 100644
--- a/src/gallium/auxiliary/util/u_blitter.c
+++ b/src/gallium/auxiliary/util/u_blitter.c
@@ -924,6 +924,11 @@ void util_blitter_cache_all_shaders(struct
blitter_context *blitter)
(target == PIPE_TEXTURE_CUBE_ARRAY))
continue;
+if (max_samples 1
+(target != PIPE_TEXTURE_2D
+ target != PIPE_TEXTURE_2D_ARRAY))
+ continue;
+
blitter_get_fs_texfetch_col(ctx, target, i);
blitter_get_fs_texfetch_depth(ctx, target, i);
if (ctx-has_stencil_export) {
--
1.8.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] r600g: add support for remaining bits for multisample texture
The sample positions can be found in r600_emit_msaa_state,
evergreen_emit_msaa_state, and cayman_emit_msaa_state, though
extracting them from the arrays might not be so straightforward.
Marek
On Sun, Mar 3, 2013 at 9:27 PM, Dave Airlie airl...@gmail.com wrote:
From: Dave Airlie airl...@redhat.com
get sample position is most definitely wrong, need to find out what
sample positions the hardware uses.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/gallium/drivers/r600/r600_shader.c | 1 +
src/gallium/drivers/r600/r600_state_common.c | 35
2 files changed, 36 insertions(+)
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index 8642463..5fd3f83 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -4705,6 +4705,7 @@ static int tgsi_tex(struct r600_shader_ctx *ctx)
tex.src_sel_z = tex.src_sel_y;
}
} else if (inst-Texture.Texture == TGSI_TEXTURE_2D_ARRAY ||
+ inst-Texture.Texture == TGSI_TEXTURE_2D_ARRAY_MSAA ||
inst-Texture.Texture == TGSI_TEXTURE_SHADOW2D_ARRAY ||
((inst-Texture.Texture == TGSI_TEXTURE_CUBE_ARRAY ||
inst-Texture.Texture == TGSI_TEXTURE_SHADOWCUBE_ARRAY)
diff --git a/src/gallium/drivers/r600/r600_state_common.c
b/src/gallium/drivers/r600/r600_state_common.c
index 22ac846..8c8b665 100644
--- a/src/gallium/drivers/r600/r600_state_common.c
+++ b/src/gallium/drivers/r600/r600_state_common.c
@@ -1748,6 +1748,39 @@ bool sampler_state_needs_border_color(const struct
pipe_sampler_state *state)
wrap_mode_uses_border_color(state-wrap_r, linear_filter));
}
+static void r600_get_sample_position(struct pipe_context *ctx,
+int max_sample,
+unsigned sample_index,
+float *out_value)
+{
+ switch (max_sample) {
+ case 1:
+ default:
+ out_value[0] = out_value[1] = 0.5;
+ break;
+ case 4:
+ switch (sample_index) {
+ case 0:
+ out_value[0] = 0.25;
+ out_value[1] = 0.25;
+ break;
+ case 1:
+ out_value[0] = 0.25;
+ out_value[1] = 0.75;
+ break;
+ case 2:
+ out_value[0] = 0.75;
+ out_value[1] = 0.25;
+ break;
+ case 3:
+ out_value[0] = 0.75;
+ out_value[1] = 0.75;
+ break;
+ }
+ break;
+ }
+}
+
/* keep this at the end of this file, please */
void r600_init_common_state_functions(struct r600_context *rctx)
{
@@ -1785,6 +1818,8 @@ void r600_init_common_state_functions(struct
r600_context *rctx)
rctx-context.stream_output_target_destroy = r600_so_target_destroy;
rctx-context.set_stream_output_targets = r600_set_streamout_targets;
rctx-context.draw_vbo = r600_draw_vbo;
+
+ rctx-context.get_sample_position = r600_get_sample_position;
}
#if R600_TRACE_CS
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] multisample clears
On Mon, Mar 4, 2013 at 4:54 AM, Dave Airlie airl...@gmail.com wrote: I've been playing with softpipe msaa on and off, but I hit a problem with the clears and am just wondering if the state tracker should be doing something like this. Or maybe only if any bound buffer has nr_samples 1, or fallback to the non-quad draw method. I can't see how else the driver could distinguish a multisample clear. The other problem I have and not figuring out is if rendering to a buffer with multisample off, then turning it on is meant to be meaningful, if you have to clear the buffer in between, then with this fixed it should be cool. Dave. From e1ee59d87ba42d8a58be640ee1fd2b952414f45e Mon Sep 17 00:00:00 2001 From: Dave Airlie airl...@redhat.com Date: Mon, 4 Mar 2013 13:39:17 +1000 Subject: [PATCH] st/mesa: enable multisample in clear quad code Not sure if this is correct at all For clears, blits, and the like, multisampling doesn't have to be enabled, which means pixel values are stored in all samples regardless of sample positions. Multisampling can be problematic if the rendered quad doesn't cover whole pixels (floating-point precision may play a role, not sure), so it's better not to enable it. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] dri: Support depth-15 Visuals
Note: This is a candidate for the stable branches.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
src/mesa/drivers/dri/common/utils.c |5 +
1 file changed, 5 insertions(+)
diff --git a/src/mesa/drivers/dri/common/utils.c
b/src/mesa/drivers/dri/common/utils.c
index ac0773b..41cab13 100644
--- a/src/mesa/drivers/dri/common/utils.c
+++ b/src/mesa/drivers/dri/common/utils.c
@@ -189,6 +189,8 @@ driCreateConfigs(gl_format format,
{ 0x00FF, 0xFF00, 0x00FF, 0x },
/* MESA_FORMAT_ARGB */
{ 0x00FF, 0xFF00, 0x00FF, 0xFF00 },
+ /* MESA_FORMAT_ARGB1555 */
+ { 0x7c00, 0x03E0, 0x001F, 0x8000 },
};
const uint32_t * masks;
@@ -204,6 +206,9 @@ driCreateConfigs(gl_format format,
bool is_srgb;
switch (format) {
+ case MESA_FORMAT_ARGB1555:
+ masks = masks_table[3];
+ break;
case MESA_FORMAT_RGB565:
masks = masks_table[0];
break;
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] intel: Support depth-15 Visuals
Note: This is a candidate for the stable branches.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
src/mesa/drivers/dri/intel/intel_screen.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
b/src/mesa/drivers/dri/intel/intel_screen.c
index d223a0b..5beea37 100644
--- a/src/mesa/drivers/dri/intel/intel_screen.c
+++ b/src/mesa/drivers/dri/intel/intel_screen.c
@@ -789,8 +789,10 @@ intelCreateBuffer(__DRIscreen * driScrnPriv,
_mesa_initialize_window_framebuffer(fb, mesaVis);
- if (mesaVis-redBits == 5)
+ if (mesaVis-greenBits == 6)
rgbFormat = MESA_FORMAT_RGB565;
+ else if (mesaVis-greenBits == 5)
+ rgbFormat = MESA_FORMAT_ARGB1555;
else if (mesaVis-sRGBCapable)
rgbFormat = MESA_FORMAT_SARGB8;
else if (mesaVis-alphaBits == 0)
@@ -1023,6 +1025,7 @@ static __DRIconfig**
intel_screen_make_configs(__DRIscreen *dri_screen)
{
static const gl_format formats[] = {
+ MESA_FORMAT_ARGB1555,
MESA_FORMAT_RGB565,
MESA_FORMAT_ARGB
};
@@ -1051,7 +1054,8 @@ intel_screen_make_configs(__DRIscreen *dri_screen)
depth_bits[0] = 0;
stencil_bits[0] = 0;
- if (formats[i] == MESA_FORMAT_RGB565) {
+ if (formats[i] == MESA_FORMAT_ARGB1555 ||
+ formats[i] == MESA_FORMAT_RGB565) {
depth_bits[1] = 16;
stencil_bits[1] = 0;
if (screen-gen = 6) {
@@ -1080,7 +1084,8 @@ intel_screen_make_configs(__DRIscreen *dri_screen)
for (int i = 0; i ARRAY_SIZE(formats); i++) {
__DRIconfig **new_configs;
- if (formats[i] == MESA_FORMAT_RGB565) {
+ if (formats[i] == MESA_FORMAT_ARGB1555 ||
+ formats[i] == MESA_FORMAT_RGB565) {
depth_bits[0] = 16;
stencil_bits[0] = 0;
} else {
@@ -1120,7 +1125,8 @@ intel_screen_make_configs(__DRIscreen *dri_screen)
depth_bits[0] = 0;
stencil_bits[0] = 0;
- if (formats[i] == MESA_FORMAT_RGB565) {
+ if (formats[i] == MESA_FORMAT_ARGB1555 ||
+ formats[i] == MESA_FORMAT_RGB565) {
depth_bits[1] = 16;
stencil_bits[1] = 0;
} else {
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/4] st/mesa: add support for ARB_texture_multisample
On Sun, Mar 3, 2013 at 9:27 PM, Dave Airlie airl...@gmail.com wrote:
From: Dave Airlie airl...@redhat.com
This adds support to the mesa state tracker for ARB_texture_multisample.
hardware doesn't seem to use a different texture instructions, so
I don't think we need to create one for TGSI at this time.
Thanks to Marek for fixes to sample number picking.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/mesa/state_tracker/st_atom_framebuffer.c | 1 +
src/mesa/state_tracker/st_atom_msaa.c| 2 ++
src/mesa/state_tracker/st_cb_bitmap.c| 4 +--
src/mesa/state_tracker/st_cb_drawpixels.c| 2 +-
src/mesa/state_tracker/st_cb_fbo.c | 2 +-
src/mesa/state_tracker/st_cb_texture.c | 41
src/mesa/state_tracker/st_extensions.c | 7 +
src/mesa/state_tracker/st_gen_mipmap.c | 1 +
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 17 ++--
src/mesa/state_tracker/st_mesa_to_tgsi.c | 2 ++
src/mesa/state_tracker/st_texture.c | 8 +-
src/mesa/state_tracker/st_texture.h | 1 +
12 files changed, 74 insertions(+), 14 deletions(-)
diff --git a/src/mesa/state_tracker/st_atom_framebuffer.c
b/src/mesa/state_tracker/st_atom_framebuffer.c
index 3df8691..c752640 100644
--- a/src/mesa/state_tracker/st_atom_framebuffer.c
+++ b/src/mesa/state_tracker/st_atom_framebuffer.c
@@ -59,6 +59,7 @@ update_renderbuffer_surface(struct st_context *st,
enum pipe_format format = st-ctx-Color.sRGBEnabled ? resource-format :
util_format_linear(resource-format);
if (!strb-surface ||
+ strb-surface-texture-nr_samples != strb-Base.NumSamples ||
strb-surface-format != format ||
strb-surface-texture != resource ||
strb-surface-width != rtt_width ||
diff --git a/src/mesa/state_tracker/st_atom_msaa.c
b/src/mesa/state_tracker/st_atom_msaa.c
index 9baa4fc..b749a17 100644
--- a/src/mesa/state_tracker/st_atom_msaa.c
+++ b/src/mesa/state_tracker/st_atom_msaa.c
@@ -63,6 +63,8 @@ static void update_sample_mask( struct st_context *st )
sample_mask = ~sample_mask;
}
/* TODO merge with app-supplied sample mask */
+ if (st-ctx-Multisample.SampleMask)
+ sample_mask = st-ctx-Multisample.SampleMaskValue;
}
/* mask off unused bits or don't care? */
diff --git a/src/mesa/state_tracker/st_cb_bitmap.c
b/src/mesa/state_tracker/st_cb_bitmap.c
index 36fffe9..d7a95e2 100644
--- a/src/mesa/state_tracker/st_cb_bitmap.c
+++ b/src/mesa/state_tracker/st_cb_bitmap.c
@@ -299,7 +299,7 @@ make_bitmap_texture(struct gl_context *ctx, GLsizei
width, GLsizei height,
* Create texture to hold bitmap pattern.
*/
pt = st_texture_create(st, st-internal_target, st-bitmap.tex_format,
- 0, width, height, 1, 1,
+ 0, width, height, 1, 1, 0,
PIPE_BIND_SAMPLER_VIEW);
if (!pt) {
_mesa_unmap_pbo_source(ctx, unpack);
@@ -568,7 +568,7 @@ reset_cache(struct st_context *st)
cache-texture = st_texture_create(st, PIPE_TEXTURE_2D,
st-bitmap.tex_format, 0,
BITMAP_CACHE_WIDTH,
BITMAP_CACHE_HEIGHT,
- 1, 1,
+ 1, 1, 0,
PIPE_BIND_SAMPLER_VIEW);
}
diff --git a/src/mesa/state_tracker/st_cb_drawpixels.c
b/src/mesa/state_tracker/st_cb_drawpixels.c
index e282bf9..e609eb5 100644
--- a/src/mesa/state_tracker/st_cb_drawpixels.c
+++ b/src/mesa/state_tracker/st_cb_drawpixels.c
@@ -463,7 +463,7 @@ alloc_texture(struct st_context *st, GLsizei width,
GLsizei height,
struct pipe_resource *pt;
pt = st_texture_create(st, st-internal_target, texFormat, 0,
- width, height, 1, 1, PIPE_BIND_SAMPLER_VIEW);
+ width, height, 1, 1, 0, PIPE_BIND_SAMPLER_VIEW);
return pt;
}
diff --git a/src/mesa/state_tracker/st_cb_fbo.c
b/src/mesa/state_tracker/st_cb_fbo.c
index 72bc960..cf3e27f 100644
--- a/src/mesa/state_tracker/st_cb_fbo.c
+++ b/src/mesa/state_tracker/st_cb_fbo.c
@@ -430,7 +430,7 @@ st_render_texture(struct gl_context *ctx,
strb-rtt_level = att-TextureLevel;
strb-rtt_face = att-CubeMapFace;
strb-rtt_slice = att-Zoffset;
-
+ rb-NumSamples = texImage-NumSamples;
rb-Width = texImage-Width2;
rb-Height = texImage-Height2;
rb-_BaseFormat = texImage-_BaseFormat;
diff --git a/src/mesa/state_tracker/st_cb_texture.c
b/src/mesa/state_tracker/st_cb_texture.c
index c922a31..385bac6 100644
--- a/src/mesa/state_tracker/st_cb_texture.c
+++ b/src/mesa/state_tracker/st_cb_texture.c
@@ -78,6 +78,8 @@ gl_target_to_pipe(GLenum target)
case GL_TEXTURE_2D:
case GL_PROXY_TEXTURE_2D:
case GL_TEXTURE_EXTERNAL_OES:
+ case
[Mesa-dev] [Bug 60121] build - libvdpau_softpipe fails at runtime.
https://bugs.freedesktop.org/show_bug.cgi?id=60121 Andy Furniss li...@andyfurniss.entadsl.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Andy Furniss li...@andyfurniss.entadsl.com --- fixed by e29124717eae4f8d329bb6a9707b802c0ff4bdd9 -- 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 61764] invalid enum in glEnable, glConvolutionFilter, glSeparableFilter, glColorTable
https://bugs.freedesktop.org/show_bug.cgi?id=61764 --- Comment #2 from Blaž Hrastnik speed.the.b...@gmail.com --- I'd still argue that this is a bug. If the extensions were removed, their implementation should be fully removed (as in, these functions, especially the EXT/ARB versions of them should be removed), instead of leaving some sort of a buggy shell, which can still be called (or at least can be tried to be called). So I'd just fully remove these, so there'd be no confusion. -- 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 2/6] r600g: cleanup #include recursion between r600_pipe.h and evergreen_compute.h
On Fri, Mar 01, 2013 at 05:55:31PM +0100, Marek Olšák wrote: Patches 2-4 are: Reviewed-by: Tom Stellard thomas.stell...@amd.com Thanks for working on this, it is a nice improvement. -Tom --- src/gallium/drivers/r600/compute_memory_pool.c|1 + src/gallium/drivers/r600/evergreen_compute.h |2 +- src/gallium/drivers/r600/evergreen_compute_internal.c |1 + src/gallium/drivers/r600/r600_pipe.c |1 + src/gallium/drivers/r600/r600_pipe.h |1 - src/gallium/drivers/r600/r600_resource.c |1 + src/gallium/drivers/r600/r600_texture.c |1 + 7 files changed, 6 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/r600/compute_memory_pool.c b/src/gallium/drivers/r600/compute_memory_pool.c index 5b1cb1b..8896909 100644 --- a/src/gallium/drivers/r600/compute_memory_pool.c +++ b/src/gallium/drivers/r600/compute_memory_pool.c @@ -39,6 +39,7 @@ #include r600_pipe.h #include r600_formats.h #include compute_memory_pool.h +#include evergreen_compute.h #include evergreen_compute_internal.h #include inttypes.h diff --git a/src/gallium/drivers/r600/evergreen_compute.h b/src/gallium/drivers/r600/evergreen_compute.h index e68ebd8..db57520 100644 --- a/src/gallium/drivers/r600/evergreen_compute.h +++ b/src/gallium/drivers/r600/evergreen_compute.h @@ -32,7 +32,7 @@ struct r600_atom; struct evergreen_compute_resource; -void *evergreen_create_compute_state(struct pipe_context *ctx, const const struct pipe_compute_state *cso); +void *evergreen_create_compute_state(struct pipe_context *ctx, const struct pipe_compute_state *cso); void evergreen_delete_compute_state(struct pipe_context *ctx, void *state); void evergreen_compute_upload_input(struct pipe_context *context, const uint *block_layout, const uint *grid_layout, const void *input); void evergreen_init_atom_start_compute_cs(struct r600_context *rctx); diff --git a/src/gallium/drivers/r600/evergreen_compute_internal.c b/src/gallium/drivers/r600/evergreen_compute_internal.c index 2e8e9da..60bb3bf 100644 --- a/src/gallium/drivers/r600/evergreen_compute_internal.c +++ b/src/gallium/drivers/r600/evergreen_compute_internal.c @@ -42,6 +42,7 @@ #include r600_pipe.h #include r600_formats.h #include evergreend.h +#include evergreen_compute.h #include evergreen_compute_internal.h #include r600_hw_context_priv.h diff --git a/src/gallium/drivers/r600/r600_pipe.c b/src/gallium/drivers/r600/r600_pipe.c index e81856c..05bb755 100644 --- a/src/gallium/drivers/r600/r600_pipe.c +++ b/src/gallium/drivers/r600/r600_pipe.c @@ -23,6 +23,7 @@ #include r600_pipe.h #include r600_public.h #include r600_isa.h +#include evergreen_compute.h #include r600d.h #include errno.h diff --git a/src/gallium/drivers/r600/r600_pipe.h b/src/gallium/drivers/r600/r600_pipe.h index cb52083..c178285 100644 --- a/src/gallium/drivers/r600/r600_pipe.h +++ b/src/gallium/drivers/r600/r600_pipe.h @@ -33,7 +33,6 @@ #include r600_llvm.h #include r600_public.h #include r600_resource.h -#include evergreen_compute.h #define R600_NUM_ATOMS 38 diff --git a/src/gallium/drivers/r600/r600_resource.c b/src/gallium/drivers/r600/r600_resource.c index 5e637f6..5962f8a 100644 --- a/src/gallium/drivers/r600/r600_resource.c +++ b/src/gallium/drivers/r600/r600_resource.c @@ -22,6 +22,7 @@ */ #include r600_pipe.h +#include evergreen_compute.h static struct pipe_resource *r600_resource_create(struct pipe_screen *screen, const struct pipe_resource *templ) diff --git a/src/gallium/drivers/r600/r600_texture.c b/src/gallium/drivers/r600/r600_texture.c index aefc40f..1c071cb 100644 --- a/src/gallium/drivers/r600/r600_texture.c +++ b/src/gallium/drivers/r600/r600_texture.c @@ -25,6 +25,7 @@ * Corbin Simpson */ #include r600_formats.h +#include evergreen_compute.h #include r600d.h #include errno.h -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] OES_external_image for i965
On Mon, Mar 4, 2013 at 4:55 AM, Pohjolainen, Topi topi.pohjolai...@intel.com wrote: On Fri, Mar 01, 2013 at 10:03:45AM -0500, Kristian H?gsberg wrote: On Fri, Mar 1, 2013 at 3:51 AM, Pohjolainen, Topi topi.pohjolai...@intel.com wrote: On Tue, Feb 26, 2013 at 04:05:25PM +, Tom Cooksey wrote: Hi Topi, The second more or less questionable part is the support for creating YUV buffers. In order to test for YUV sampling one needs a way of providing them for the EGL stack. Here I chose to augment the dri driver backing gbm as I couldn't come up with anything better. It may be helpful to take a look at the corresponding piglit test case and framework support I've written for it. You might want to take a look at the EGL_EXT_image_dma_buf_import[i] which has been written specifically for this purpose. Though this does assume you have a driver which supports exporting a YUV buffer it has allocated with dma_buf, such as a v4l2 driver or even ion on Android. It certainly looks good addressing not only the individual plane setup but allowing one to control also the conversion coefficients and subsampling position. Coming from piglit testing point of view, do you have any ideas where to allocate the buffers from? I guess people wouldn't be too happy seeing v4l2 tied into piglit, for example. SInce you're already using intel specific ioctls to mmap the buffers, I'd suggest you just go all the way and allocate using intel specific ioctls (like my simple-yuv.c example). I don't really see any other approach, but it's not pretty... I used gbm buffer objects in order to match the logic later in 'dri2_drm_create_image_khr()' which expects the buffer to be of the type 'gbm_dri_bo' (gbm_bo) for the target EGL_NATIVE_PIXMAP_KHR. Giving drm buffer objects instead would require new target, I guess? Right... I'd use the extension Tom suggests: http://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt which is mostly implemented by this patch: http://lists.freedesktop.org/archives/mesa-dev/2013-February/035429.html with just the EGL extension bits missing. That way, you're also not dependent on any specific window system. As it is your test has to run under gbm, using the dmabuf import extension it can run under any window system. Kristian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] OES_external_image for i965
On Mon, Mar 04, 2013 at 09:56:34AM -0500, Kristian H?gsberg wrote: On Mon, Mar 4, 2013 at 4:55 AM, Pohjolainen, Topi topi.pohjolai...@intel.com wrote: On Fri, Mar 01, 2013 at 10:03:45AM -0500, Kristian H?gsberg wrote: On Fri, Mar 1, 2013 at 3:51 AM, Pohjolainen, Topi topi.pohjolai...@intel.com wrote: On Tue, Feb 26, 2013 at 04:05:25PM +, Tom Cooksey wrote: Hi Topi, The second more or less questionable part is the support for creating YUV buffers. In order to test for YUV sampling one needs a way of providing them for the EGL stack. Here I chose to augment the dri driver backing gbm as I couldn't come up with anything better. It may be helpful to take a look at the corresponding piglit test case and framework support I've written for it. You might want to take a look at the EGL_EXT_image_dma_buf_import[i] which has been written specifically for this purpose. Though this does assume you have a driver which supports exporting a YUV buffer it has allocated with dma_buf, such as a v4l2 driver or even ion on Android. It certainly looks good addressing not only the individual plane setup but allowing one to control also the conversion coefficients and subsampling position. Coming from piglit testing point of view, do you have any ideas where to allocate the buffers from? I guess people wouldn't be too happy seeing v4l2 tied into piglit, for example. SInce you're already using intel specific ioctls to mmap the buffers, I'd suggest you just go all the way and allocate using intel specific ioctls (like my simple-yuv.c example). I don't really see any other approach, but it's not pretty... I used gbm buffer objects in order to match the logic later in 'dri2_drm_create_image_khr()' which expects the buffer to be of the type 'gbm_dri_bo' (gbm_bo) for the target EGL_NATIVE_PIXMAP_KHR. Giving drm buffer objects instead would require new target, I guess? Right... I'd use the extension Tom suggests: http://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt which is mostly implemented by this patch: http://lists.freedesktop.org/archives/mesa-dev/2013-February/035429.html with just the EGL extension bits missing. That way, you're also not dependent on any specific window system. As it is your test has to run under gbm, using the dmabuf import extension it can run under any window system. Just to clarify that I understood correctly. The actual creation of the buffer (and dma_buf exporting) would still be via hardware specific ioctls (in intel's case GEM)? Your and Tom's material address only the importing side, or did I miss something? Topi ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g: allocate FMASK right after the texture, so that it's aligned with it
On Sun, Mar 3, 2013 at 9:13 AM, Marek Olšák mar...@gmail.com wrote:
This avoids the kernel CS checker errors with MSAA textures.
Reviewed-by: Jerome Glisse jgli...@redhat.com
---
src/gallium/drivers/r600/r600_texture.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/r600_texture.c
b/src/gallium/drivers/r600/r600_texture.c
index 484045e..4825592 100644
--- a/src/gallium/drivers/r600/r600_texture.c
+++ b/src/gallium/drivers/r600/r600_texture.c
@@ -435,8 +435,8 @@ r600_texture_create_object(struct pipe_screen *screen,
}
if (base-nr_samples 1 !rtex-is_depth !buf) {
- r600_texture_allocate_cmask(rscreen, rtex);
r600_texture_allocate_fmask(rscreen, rtex);
+ r600_texture_allocate_cmask(rscreen, rtex);
}
if (!rtex-is_depth base-nr_samples 1
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/6] r600g: inline r600_pipe_shader function
On Sun, Mar 3, 2013 at 8:39 AM, Marek Olšák mar...@gmail.com wrote:
also change names of other functions, so that they make sense
For the serie:
Reviewed-by: Jerome Glisse jgli...@redhat.com
---
src/gallium/drivers/r600/evergreen_state.c |4 +-
src/gallium/drivers/r600/r600_pipe.h |8 +--
src/gallium/drivers/r600/r600_shader.c | 89
--
src/gallium/drivers/r600/r600_state.c|4 +-
src/gallium/drivers/r600/r600_state_common.c |4 +-
5 files changed, 51 insertions(+), 58 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_state.c
b/src/gallium/drivers/r600/evergreen_state.c
index 97f91df..5c7cd40 100644
--- a/src/gallium/drivers/r600/evergreen_state.c
+++ b/src/gallium/drivers/r600/evergreen_state.c
@@ -3311,7 +3311,7 @@ void evergreen_init_atom_start_cs(struct r600_context
*rctx)
eg_store_loop_const(cb, R_03A200_SQ_LOOP_CONST_0 + (32 * 4),
0x01000FFF);
}
-void evergreen_pipe_shader_ps(struct pipe_context *ctx, struct
r600_pipe_shader *shader)
+void evergreen_update_ps_state(struct pipe_context *ctx, struct
r600_pipe_shader *shader)
{
struct r600_context *rctx = (struct r600_context *)ctx;
struct r600_pipe_state *rstate = shader-rstate;
@@ -3460,7 +3460,7 @@ void evergreen_pipe_shader_ps(struct pipe_context *ctx,
struct r600_pipe_shader
shader-flatshade = rctx-rasterizer-flatshade;
}
-void evergreen_pipe_shader_vs(struct pipe_context *ctx, struct
r600_pipe_shader *shader)
+void evergreen_update_vs_state(struct pipe_context *ctx, struct
r600_pipe_shader *shader)
{
struct r600_context *rctx = (struct r600_context *)ctx;
struct r600_pipe_state *rstate = shader-rstate;
diff --git a/src/gallium/drivers/r600/r600_pipe.h
b/src/gallium/drivers/r600/r600_pipe.h
index 3eb2968..28c7de3 100644
--- a/src/gallium/drivers/r600/r600_pipe.h
+++ b/src/gallium/drivers/r600/r600_pipe.h
@@ -626,8 +626,8 @@ void cayman_init_common_regs(struct r600_command_buffer
*cb,
void evergreen_init_state_functions(struct r600_context *rctx);
void evergreen_init_atom_start_cs(struct r600_context *rctx);
-void evergreen_pipe_shader_ps(struct pipe_context *ctx, struct
r600_pipe_shader *shader);
-void evergreen_pipe_shader_vs(struct pipe_context *ctx, struct
r600_pipe_shader *shader);
+void evergreen_update_ps_state(struct pipe_context *ctx, struct
r600_pipe_shader *shader);
+void evergreen_update_vs_state(struct pipe_context *ctx, struct
r600_pipe_shader *shader);
void *evergreen_create_db_flush_dsa(struct r600_context *rctx);
void *evergreen_create_resolve_blend(struct r600_context *rctx);
void *evergreen_create_decompress_blend(struct r600_context *rctx);
@@ -701,8 +701,8 @@ r600_create_sampler_view_custom(struct pipe_context *ctx,
unsigned width_first_level, unsigned
height_first_level);
void r600_init_state_functions(struct r600_context *rctx);
void r600_init_atom_start_cs(struct r600_context *rctx);
-void r600_pipe_shader_ps(struct pipe_context *ctx, struct r600_pipe_shader
*shader);
-void r600_pipe_shader_vs(struct pipe_context *ctx, struct r600_pipe_shader
*shader);
+void r600_update_ps_state(struct pipe_context *ctx, struct r600_pipe_shader
*shader);
+void r600_update_vs_state(struct pipe_context *ctx, struct r600_pipe_shader
*shader);
void *r600_create_db_flush_dsa(struct r600_context *rctx);
void *r600_create_resolve_blend(struct r600_context *rctx);
void *r700_create_resolve_blend(struct r600_context *rctx);
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index 949191a..7ecab7b 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -58,52 +58,6 @@ issued in the w slot as well.
The compiler must issue the source argument to slots z, y, and x
*/
-static int r600_pipe_shader(struct pipe_context *ctx, struct
r600_pipe_shader *shader)
-{
- struct r600_context *rctx = (struct r600_context *)ctx;
- struct r600_shader *rshader = shader-shader;
- uint32_t *ptr;
- int i;
-
- /* copy new shader */
- if (shader-bo == NULL) {
- shader-bo = (struct r600_resource*)
- pipe_buffer_create(ctx-screen, PIPE_BIND_CUSTOM,
PIPE_USAGE_IMMUTABLE, rshader-bc.ndw * 4);
- if (shader-bo == NULL) {
- return -ENOMEM;
- }
- ptr = r600_buffer_mmap_sync_with_rings(rctx, shader-bo,
PIPE_TRANSFER_WRITE);
- if (R600_BIG_ENDIAN) {
- for (i = 0; i rshader-bc.ndw; ++i) {
- ptr[i] = bswap_32(rshader-bc.bytecode[i]);
- }
- } else {
- memcpy(ptr, rshader-bc.bytecode, rshader-bc.ndw *
sizeof(*ptr));
- }
Re: [Mesa-dev] [PATCH 1/5] r600g: unify vgt states
On Wed, Feb 27, 2013 at 6:11 PM, Marek Olšák mar...@gmail.com wrote:
The states were split because we thought it caused a hardlock. Now we know
the hardlock was caused by something else and has since been fixed.
For the serie:
Reviewed-by: Jerome Glisse jgli...@redhat.com
---
src/gallium/drivers/r600/evergreen_state.c |3 +--
src/gallium/drivers/r600/r600_hw_context.c |1 -
src/gallium/drivers/r600/r600_pipe.h |6 --
src/gallium/drivers/r600/r600_state.c|3 +--
src/gallium/drivers/r600/r600_state_common.c | 22 +++---
5 files changed, 9 insertions(+), 26 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_state.c
b/src/gallium/drivers/r600/evergreen_state.c
index 205bbc5..244989d 100644
--- a/src/gallium/drivers/r600/evergreen_state.c
+++ b/src/gallium/drivers/r600/evergreen_state.c
@@ -2615,8 +2615,7 @@ void evergreen_init_state_functions(struct r600_context
*rctx)
r600_init_atom(rctx,
rctx-samplers[PIPE_SHADER_GEOMETRY].views.atom, id++,
evergreen_emit_gs_sampler_views, 0);
r600_init_atom(rctx,
rctx-samplers[PIPE_SHADER_FRAGMENT].views.atom, id++,
evergreen_emit_ps_sampler_views, 0);
- r600_init_atom(rctx, rctx-vgt_state.atom, id++,
r600_emit_vgt_state, 6);
- r600_init_atom(rctx, rctx-vgt2_state.atom, id++,
r600_emit_vgt2_state, 3);
+ r600_init_atom(rctx, rctx-vgt_state.atom, id++,
r600_emit_vgt_state, 7);
if (rctx-chip_class == EVERGREEN) {
r600_init_atom(rctx, rctx-sample_mask.atom, id++,
evergreen_emit_sample_mask, 3);
diff --git a/src/gallium/drivers/r600/r600_hw_context.c
b/src/gallium/drivers/r600/r600_hw_context.c
index 91af6b8..b78b004 100644
--- a/src/gallium/drivers/r600/r600_hw_context.c
+++ b/src/gallium/drivers/r600/r600_hw_context.c
@@ -827,7 +827,6 @@ void r600_begin_new_cs(struct r600_context *ctx)
ctx-framebuffer.atom.dirty = true;
ctx-poly_offset_state.atom.dirty = true;
ctx-vgt_state.atom.dirty = true;
- ctx-vgt2_state.atom.dirty = true;
ctx-sample_mask.atom.dirty = true;
ctx-scissor.atom.dirty = true;
ctx-config_state.atom.dirty = true;
diff --git a/src/gallium/drivers/r600/r600_pipe.h
b/src/gallium/drivers/r600/r600_pipe.h
index 570a284..4cfade1 100644
--- a/src/gallium/drivers/r600/r600_pipe.h
+++ b/src/gallium/drivers/r600/r600_pipe.h
@@ -127,10 +127,6 @@ struct r600_vgt_state {
struct r600_atom atom;
uint32_t vgt_multi_prim_ib_reset_en;
uint32_t vgt_multi_prim_ib_reset_indx;
-};
-
-struct r600_vgt2_state {
- struct r600_atom atom;
uint32_t vgt_indx_offset;
};
@@ -506,7 +502,6 @@ struct r600_context {
struct r600_config_stateconfig_state;
struct r600_stencil_ref_state stencil_ref;
struct r600_vgt_state vgt_state;
- struct r600_vgt2_state vgt2_state;
struct r600_viewport_state viewport;
/* Shaders and shader resources. */
struct r600_cso_state vertex_fetch_shader;
@@ -733,7 +728,6 @@ void r600_emit_cso_state(struct r600_context *rctx,
struct r600_atom *atom);
void r600_emit_alphatest_state(struct r600_context *rctx, struct r600_atom
*atom);
void r600_emit_blend_color(struct r600_context *rctx, struct r600_atom
*atom);
void r600_emit_vgt_state(struct r600_context *rctx, struct r600_atom *atom);
-void r600_emit_vgt2_state(struct r600_context *rctx, struct r600_atom *atom);
void r600_emit_clip_misc_state(struct r600_context *rctx, struct r600_atom
*atom);
void r600_emit_stencil_ref(struct r600_context *rctx, struct r600_atom
*atom);
void r600_emit_viewport_state(struct r600_context *rctx, struct r600_atom
*atom);
diff --git a/src/gallium/drivers/r600/r600_state.c
b/src/gallium/drivers/r600/r600_state.c
index bbff6bd..fd3b14e 100644
--- a/src/gallium/drivers/r600/r600_state.c
+++ b/src/gallium/drivers/r600/r600_state.c
@@ -2312,8 +2312,7 @@ void r600_init_state_functions(struct r600_context
*rctx)
r600_init_atom(rctx,
rctx-samplers[PIPE_SHADER_FRAGMENT].views.atom, id++,
r600_emit_ps_sampler_views, 0);
r600_init_atom(rctx, rctx-vertex_buffer_state.atom, id++,
r600_emit_vertex_buffers, 0);
- r600_init_atom(rctx, rctx-vgt_state.atom, id++,
r600_emit_vgt_state, 6);
- r600_init_atom(rctx, rctx-vgt2_state.atom, id++,
r600_emit_vgt2_state, 3);
+ r600_init_atom(rctx, rctx-vgt_state.atom, id++,
r600_emit_vgt_state, 7);
r600_init_atom(rctx, rctx-seamless_cube_map.atom, id++,
r600_emit_seamless_cube_map, 3);
r600_init_atom(rctx, rctx-sample_mask.atom, id++,
r600_emit_sample_mask, 3);
diff --git a/src/gallium/drivers/r600/r600_state_common.c
b/src/gallium/drivers/r600/r600_state_common.c
index 4c68506..8906695 100644
--- a/src/gallium/drivers/r600/r600_state_common.c
+++
[Mesa-dev] [Bug 61395] glEdgeFlag can't be set to false
https://bugs.freedesktop.org/show_bug.cgi?id=61395 Brian Paul bri...@vmware.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Brian Paul bri...@vmware.com --- Thanks for the reminder. I just pushed it. Commit b1390c7992c457f230cb5a7a64803b194de316e0 -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] OES_external_image for i965
On Mon, Mar 4, 2013 at 10:11 AM, Pohjolainen, Topi topi.pohjolai...@intel.com wrote: On Mon, Mar 04, 2013 at 09:56:34AM -0500, Kristian H?gsberg wrote: On Mon, Mar 4, 2013 at 4:55 AM, Pohjolainen, Topi topi.pohjolai...@intel.com wrote: On Fri, Mar 01, 2013 at 10:03:45AM -0500, Kristian H?gsberg wrote: On Fri, Mar 1, 2013 at 3:51 AM, Pohjolainen, Topi topi.pohjolai...@intel.com wrote: On Tue, Feb 26, 2013 at 04:05:25PM +, Tom Cooksey wrote: Hi Topi, The second more or less questionable part is the support for creating YUV buffers. In order to test for YUV sampling one needs a way of providing them for the EGL stack. Here I chose to augment the dri driver backing gbm as I couldn't come up with anything better. It may be helpful to take a look at the corresponding piglit test case and framework support I've written for it. You might want to take a look at the EGL_EXT_image_dma_buf_import[i] which has been written specifically for this purpose. Though this does assume you have a driver which supports exporting a YUV buffer it has allocated with dma_buf, such as a v4l2 driver or even ion on Android. It certainly looks good addressing not only the individual plane setup but allowing one to control also the conversion coefficients and subsampling position. Coming from piglit testing point of view, do you have any ideas where to allocate the buffers from? I guess people wouldn't be too happy seeing v4l2 tied into piglit, for example. SInce you're already using intel specific ioctls to mmap the buffers, I'd suggest you just go all the way and allocate using intel specific ioctls (like my simple-yuv.c example). I don't really see any other approach, but it's not pretty... I used gbm buffer objects in order to match the logic later in 'dri2_drm_create_image_khr()' which expects the buffer to be of the type 'gbm_dri_bo' (gbm_bo) for the target EGL_NATIVE_PIXMAP_KHR. Giving drm buffer objects instead would require new target, I guess? Right... I'd use the extension Tom suggests: http://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt which is mostly implemented by this patch: http://lists.freedesktop.org/archives/mesa-dev/2013-February/035429.html with just the EGL extension bits missing. That way, you're also not dependent on any specific window system. As it is your test has to run under gbm, using the dmabuf import extension it can run under any window system. Just to clarify that I understood correctly. The actual creation of the buffer (and dma_buf exporting) would still be via hardware specific ioctls (in intel's case GEM)? Your and Tom's material address only the importing side, or did I miss something? Yes, that's correct. You'll need intel create and export to fd functions, but you are already mapping the bo using intel specific ioctls. So I think it's cleaner to just have a chipset specific function to create the bo and return an fd, stride etc, and from there on it's generic code where you feed it into the dma_buf_import function. Kristian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 61764] invalid enum in glEnable, glConvolutionFilter, glSeparableFilter, glColorTable
https://bugs.freedesktop.org/show_bug.cgi?id=61764 --- Comment #3 from Roland Scheidegger srol...@vmware.com --- (In reply to comment #2) I'd still argue that this is a bug. If the extensions were removed, their implementation should be fully removed (as in, these functions, especially the EXT/ARB versions of them should be removed), instead of leaving some sort of a buggy shell, which can still be called (or at least can be tried to be called). So I'd just fully remove these, so there'd be no confusion. No this is not correct. The problem is there never was a separate ARB_imaging extension, this is (rather was) part of core but optionally supported. As such there's language in the spec which says you have to return invalid_enum for invalid operands and invalid_operation for unsupported functions belonging to this imaging subset. -- 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 2/4] st/mesa: add support for get sample position
Just minor formatting nits below.
On 03/03/2013 01:27 PM, Dave Airlie wrote:
From: Dave Airlieairl...@redhat.com
This just calls into the gallium interface.
Signed-off-by: Dave Airlieairl...@redhat.com
---
src/mesa/sources.mak| 1 +
src/mesa/state_tracker/st_cb_msaa.c | 52 +
src/mesa/state_tracker/st_cb_msaa.h | 39
src/mesa/state_tracker/st_context.c | 2 ++
4 files changed, 94 insertions(+)
create mode 100644 src/mesa/state_tracker/st_cb_msaa.c
create mode 100644 src/mesa/state_tracker/st_cb_msaa.h
diff --git a/src/mesa/sources.mak b/src/mesa/sources.mak
index 178ceb2..7498d96 100644
--- a/src/mesa/sources.mak
+++ b/src/mesa/sources.mak
@@ -224,6 +224,7 @@ STATETRACKER_FILES = \
$(SRCDIR)state_tracker/st_cb_eglimage.c \
$(SRCDIR)state_tracker/st_cb_fbo.c \
$(SRCDIR)state_tracker/st_cb_feedback.c \
+ $(SRCDIR)state_tracker/st_cb_msaa.c \
$(SRCDIR)state_tracker/st_cb_program.c \
$(SRCDIR)state_tracker/st_cb_queryobj.c \
$(SRCDIR)state_tracker/st_cb_rasterpos.c \
diff --git a/src/mesa/state_tracker/st_cb_msaa.c
b/src/mesa/state_tracker/st_cb_msaa.c
new file mode 100644
index 000..688d6a3
--- /dev/null
+++ b/src/mesa/state_tracker/st_cb_msaa.c
@@ -0,0 +1,52 @@
+/**
+ *
+ * Copyright 2013 Red Hat
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * Software), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
+ * IN NO EVENT SHALL THE AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR
+ * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
+ * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
+ * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ **/
+
+#include main/mfeatures.h
+#include main/bufferobj.h
+#include main/imports.h
+
+#include state_tracker/st_cb_msaa.h
+#include state_tracker/st_context.h
+#include state_tracker/st_cb_fbo.h
+
+#include pipe/p_context.h
Put a blank line or two after the #include line.
+static void st_GetSamplePosition(struct gl_context *ctx,
+ struct gl_framebuffer *fb,
+ GLuint index,
+ GLfloat *outValue)
Put 'static void' on its own line.
+{
+ struct st_context *st = st_context(ctx);
+ struct st_renderbuffer *strb;
+
+ if (st-pipe-get_sample_position)
+ st-pipe-get_sample_position(st-pipe, fb-Visual.samples, index,
outValue);
+}
+
+void st_init_msaa_functions(struct dd_function_table *functions)
'void' on its own line.
+{
+ functions-GetSamplePosition = st_GetSamplePosition;
+}
diff --git a/src/mesa/state_tracker/st_cb_msaa.h
b/src/mesa/state_tracker/st_cb_msaa.h
new file mode 100644
index 000..ba4c06f
--- /dev/null
+++ b/src/mesa/state_tracker/st_cb_msaa.h
@@ -0,0 +1,39 @@
+/**
+ *
+ * Copyright 2013 Red Hat
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * Software), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
+ * IN NO EVENT SHALL THE AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR
+ * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
+ * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
+ *
Re: [Mesa-dev] [PATCH 1/4] gallium: add get_sample_position interface
On 03/03/2013 01:27 PM, Dave Airlie wrote:
From: Dave Airlieairl...@redhat.com
This is to be used to implement glGet GL_SAMPLE_POSITION.
Signed-off-by: Dave Airlieairl...@redhat.com
---
src/gallium/include/pipe/p_context.h | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/include/pipe/p_context.h
b/src/gallium/include/pipe/p_context.h
index 7ed946e..4ffee20 100644
--- a/src/gallium/include/pipe/p_context.h
+++ b/src/gallium/include/pipe/p_context.h
@@ -520,6 +520,10 @@ struct pipe_context {
const uint *block_layout, const uint *grid_layout,
uint32_t pc, const void *input);
/*@}*/
+ void (*get_sample_position)(struct pipe_context *context,
+ int max_samples,
+ unsigned sample_index,
+ float *out_value);
};
Should max_samples be unsigned?
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 61764] invalid enum in glEnable, glConvolutionFilter, glSeparableFilter, glColorTable
https://bugs.freedesktop.org/show_bug.cgi?id=61764 --- Comment #4 from Blaž Hrastnik speed.the.b...@gmail.com --- Ah yes, I have found that bit later in the documentation. Thank you for clarification! -- 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 61761] glPolygonOffsetEXT, OFFSET_BIAS incorrectly set to a huge number
https://bugs.freedesktop.org/show_bug.cgi?id=61761 --- Comment #2 from Brian Paul bri...@vmware.com --- I wonder if we should just drop the GL_EXT_polygon_offset extension. I see that NVIDIA doesn't advertise it. -- 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 61761] glPolygonOffsetEXT, OFFSET_BIAS incorrectly set to a huge number
https://bugs.freedesktop.org/show_bug.cgi?id=61761 --- Comment #3 from Roland Scheidegger srol...@vmware.com --- I guess if nvidia doesn't advertize it (and by the looks of it they never did) it should be safe to remove (and amd doesn't seem to advertize it neither in their closed-source drivers). After all PolygonOffset became core in OpenGL 1.1, so you'd be looking at OpenGL 1.0 apps potentially using it. Some of the mesa demos actually can use it, though all of them will use the ordinary PolygonOffset by default. -- 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 2/2] configure.ac: Remove stale comment about --x-* arguments.
Should have been removed with e273ed37. --- configure.ac |6 -- 1 files changed, 0 insertions(+), 6 deletions(-) diff --git a/configure.ac b/configure.ac index 1b13d06..ea56a04 100644 --- a/configure.ac +++ b/configure.ac @@ -832,12 +832,6 @@ if test x$enable_dri = xyes; then fi fi -dnl Try to tell the user that the --x-* options are only used when -dnl pkg-config is not available. This must be right after AC_PATH_XTRA. -m4_divert_once([HELP_BEGIN], -[These options are only used when the X libraries cannot be found by the -pkg-config utility.]) - dnl Direct rendering or just indirect rendering case $host_os in gnu*) -- 1.7.8.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Fix build of swrast only without libdrm
On Thu, Feb 28, 2013 at 10:39 AM, Daniel Martin consume.no...@gmail.com wrote: Signed-off-by: Daniel Martin consume.no...@gmail.com --- There's a small logic error preventing mesa to be build with swrast only and not having libdrm. v2: || test replaced by -a configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 5f95a78..7852595 100644 --- a/configure.ac +++ b/configure.ac @@ -1095,7 +1095,7 @@ if test x$enable_dri = xyes; then fi # if we are building any dri driver other than swrast or using the dri state tracker ... -if test -n $DRI_DIRS -a x$DRI_DIRS != xswrast || test x$enable_dri = xyes; then +if test -n $DRI_DIRS -a x$DRI_DIRS != xswrast -a x$enable_dri = xyes; then # ... libdrm is required if test x$have_libdrm != xyes; then AC_MSG_ERROR([DRI drivers requires libdrm = $LIBDRM_REQUIRED]) -- 1.8.1.4 Committed. Thanks! ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g/radeonsi: unreference previous fence in flush
On Mon, 2013-03-04 at 13:17 -0500, j.gli...@gmail.com wrote:
From: Jerome Glisse jgli...@redhat.com
Some code calling the flush function gave a fence pointer that point
to an old fence and should be unreference to avoid leaking fence.
Candidate for 9.1
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
src/gallium/drivers/r600/r600_pipe.c | 8 +---
src/gallium/drivers/radeonsi/radeonsi_pipe.c | 9 ++---
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
index 78002ae..4bcfc67 100644
--- a/src/gallium/drivers/r600/r600_pipe.c
+++ b/src/gallium/drivers/r600/r600_pipe.c
@@ -145,12 +145,14 @@ static void r600_flush_from_st(struct pipe_context *ctx,
enum pipe_flush_flags flags)
{
struct r600_context *rctx = (struct r600_context *)ctx;
- struct r600_fence **rfence = (struct r600_fence**)fence;
+ struct r600_fence *rfence;
unsigned fflags;
fflags = flags PIPE_FLUSH_END_OF_FRAME ? RADEON_FLUSH_END_OF_FRAME :
0;
- if (rfence) {
- *rfence = r600_create_fence(rctx);
+ if (fence) {
+ rfence = r600_create_fence(rctx);
+ ctx-screen-fence_reference(ctx-screen, fence,
+ (struct pipe_fence_handle
*)rfence);
This change increases the reference count of the returned fence from 1
to 2. I don't think that's correct, but if it is, the change should be
amended with an explanation why.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g/radeonsi: unreference previous fence in flush
On Mon, Mar 4, 2013 at 2:05 PM, Michel Dänzer mic...@daenzer.net wrote:
On Mon, 2013-03-04 at 13:17 -0500, j.gli...@gmail.com wrote:
From: Jerome Glisse jgli...@redhat.com
Some code calling the flush function gave a fence pointer that point
to an old fence and should be unreference to avoid leaking fence.
Candidate for 9.1
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
src/gallium/drivers/r600/r600_pipe.c | 8 +---
src/gallium/drivers/radeonsi/radeonsi_pipe.c | 9 ++---
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
index 78002ae..4bcfc67 100644
--- a/src/gallium/drivers/r600/r600_pipe.c
+++ b/src/gallium/drivers/r600/r600_pipe.c
@@ -145,12 +145,14 @@ static void r600_flush_from_st(struct pipe_context
*ctx,
enum pipe_flush_flags flags)
{
struct r600_context *rctx = (struct r600_context *)ctx;
- struct r600_fence **rfence = (struct r600_fence**)fence;
+ struct r600_fence *rfence;
unsigned fflags;
fflags = flags PIPE_FLUSH_END_OF_FRAME ? RADEON_FLUSH_END_OF_FRAME :
0;
- if (rfence) {
- *rfence = r600_create_fence(rctx);
+ if (fence) {
+ rfence = r600_create_fence(rctx);
+ ctx-screen-fence_reference(ctx-screen, fence,
+ (struct pipe_fence_handle
*)rfence);
This change increases the reference count of the returned fence from 1
to 2. I don't think that's correct, but if it is, the change should be
amended with an explanation why.
No i have uncommited change in my tree. I will probably resend with
the xa patchset.
Jerome
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] configure.ac: Don't check for X11 unconditionally.
On 03/04/2013 11:31 AM, Matt Turner wrote: X11 is already checked conditionally below. Fixes OSMesa-only configurations to not require X11. --- configure.ac |8 1 files changed, 0 insertions(+), 8 deletions(-) diff --git a/configure.ac b/configure.ac index 7852595..1b13d06 100644 --- a/configure.ac +++ b/configure.ac @@ -832,20 +832,12 @@ if test x$enable_dri = xyes; then fi fi -dnl Find out if X is available. -PKG_CHECK_MODULES([X11], [x11], [no_x=no], [no_x=yes]) - dnl Try to tell the user that the --x-* options are only used when dnl pkg-config is not available. This must be right after AC_PATH_XTRA. m4_divert_once([HELP_BEGIN], [These options are only used when the X libraries cannot be found by the pkg-config utility.]) -dnl We need X for xlib and dri, so bomb now if it's not found -if test x$enable_glx = xyes -a x$no_x = xyes; then -AC_MSG_ERROR([X11 development libraries needed for GLX]) -fi - dnl Direct rendering or just indirect rendering case $host_os in gnu*) The series LGMT. Thanks, Matt! Candidates for the stable branches? Reviewed-by: Brian Paul bri...@vmware.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] configure.ac: Don't check for X11 unconditionally.
On Mon, Mar 4, 2013 at 11:14 AM, Brian Paul bri...@vmware.com wrote: On 03/04/2013 11:31 AM, Matt Turner wrote: X11 is already checked conditionally below. Fixes OSMesa-only configurations to not require X11. --- configure.ac |8 1 files changed, 0 insertions(+), 8 deletions(-) diff --git a/configure.ac b/configure.ac index 7852595..1b13d06 100644 --- a/configure.ac +++ b/configure.ac @@ -832,20 +832,12 @@ if test x$enable_dri = xyes; then fi fi -dnl Find out if X is available. -PKG_CHECK_MODULES([X11], [x11], [no_x=no], [no_x=yes]) - dnl Try to tell the user that the --x-* options are only used when dnl pkg-config is not available. This must be right after AC_PATH_XTRA. m4_divert_once([HELP_BEGIN], [These options are only used when the X libraries cannot be found by the pkg-config utility.]) -dnl We need X for xlib and dri, so bomb now if it's not found -if test x$enable_glx = xyes -a x$no_x = xyes; then -AC_MSG_ERROR([X11 development libraries needed for GLX]) -fi - dnl Direct rendering or just indirect rendering case $host_os in gnu*) The series LGMT. Thanks, Matt! Candidates for the stable branches? Sure. Reviewed-by: Brian Paul bri...@vmware.com Thanks! ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: Allow ETC2/EAC formats with ARB_ES3_compatibility.
Reported-by: Marek Olšák mar...@gmail.com
---
src/mesa/main/teximage.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 0dcf88a..e5260d1 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -520,7 +520,7 @@ _mesa_base_tex_format( struct gl_context *ctx, GLint
internalFormat )
}
}
- if (_mesa_is_gles3(ctx)) {
+ if (_mesa_is_gles3(ctx) || ctx-Extensions.ARB_ES3_compatibility) {
switch (internalFormat) {
case GL_COMPRESSED_RGB8_ETC2:
case GL_COMPRESSED_SRGB8_ETC2:
--
1.7.8.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Allow ETC2/EAC formats with ARB_ES3_compatibility.
On 03/04/2013 11:38 AM, Matt Turner wrote:
Reported-by: Marek Olšák mar...@gmail.com
Do our ETC2 piglit tests run in this mode? It would be good to see this
change actually fix a bug by making a failing test pass. :)
---
src/mesa/main/teximage.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 0dcf88a..e5260d1 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -520,7 +520,7 @@ _mesa_base_tex_format( struct gl_context *ctx, GLint
internalFormat )
}
}
- if (_mesa_is_gles3(ctx)) {
+ if (_mesa_is_gles3(ctx) || ctx-Extensions.ARB_ES3_compatibility) {
switch (internalFormat) {
case GL_COMPRESSED_RGB8_ETC2:
case GL_COMPRESSED_SRGB8_ETC2:
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: don't allocate a texture if width or height is 0 in CopyTexImage
---
src/mesa/main/teximage.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 0dcf88a..a7b88d1 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -3494,19 +3494,21 @@ copyteximage(struct gl_context *ctx, GLuint dims,
_mesa_init_teximage_fields(ctx, texImage, width, height, 1,
border, internalFormat, texFormat);
- /* Allocate texture memory (no pixel data yet) */
- ctx-Driver.AllocTextureImageBuffer(ctx, texImage);
+ if (width height) {
+/* Allocate texture memory (no pixel data yet) */
+ctx-Driver.AllocTextureImageBuffer(ctx, texImage);
- if (_mesa_clip_copytexsubimage(ctx, dstX, dstY, srcX, srcY,
-width, height)) {
-struct gl_renderbuffer *srcRb =
- get_copy_tex_image_source(ctx, texImage-TexFormat);
+if (_mesa_clip_copytexsubimage(ctx, dstX, dstY, srcX, srcY,
+ width, height)) {
+ struct gl_renderbuffer *srcRb =
+ get_copy_tex_image_source(ctx, texImage-TexFormat);
-ctx-Driver.CopyTexSubImage(ctx, dims, texImage, dstX, dstY, dstZ,
-srcRb, srcX, srcY, width, height);
- }
+ ctx-Driver.CopyTexSubImage(ctx, dims, texImage, dstX, dstY,
dstZ,
+ srcRb, srcX, srcY, width, height);
+}
- check_gen_mipmap(ctx, target, texObj, level);
+check_gen_mipmap(ctx, target, texObj, level);
+ }
_mesa_update_fbo_texture(ctx, texObj, face, level);
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Allow ETC2/EAC formats with ARB_ES3_compatibility.
On Mon, Mar 4, 2013 at 11:38 AM, Matt Turner matts...@gmail.com wrote:
Reported-by: Marek Olšák mar...@gmail.com
---
src/mesa/main/teximage.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 0dcf88a..e5260d1 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -520,7 +520,7 @@ _mesa_base_tex_format( struct gl_context *ctx, GLint
internalFormat )
}
}
- if (_mesa_is_gles3(ctx)) {
+ if (_mesa_is_gles3(ctx) || ctx-Extensions.ARB_ES3_compatibility) {
Similar change is required in compressed_texture_error_check() as well.
switch (internalFormat) {
case GL_COMPRESSED_RGB8_ETC2:
case GL_COMPRESSED_SRGB8_ETC2:
--
1.7.8.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] llvmpipe: add some scene limit sanity check assertions
Note: This is a candidate for the stable branches.
---
src/gallium/drivers/llvmpipe/lp_scene.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_scene.c
b/src/gallium/drivers/llvmpipe/lp_scene.c
index fec2f74..8056906 100644
--- a/src/gallium/drivers/llvmpipe/lp_scene.c
+++ b/src/gallium/drivers/llvmpipe/lp_scene.c
@@ -64,6 +64,26 @@ lp_scene_create( struct pipe_context *pipe )
pipe_mutex_init(scene-mutex);
+ /* Do some scene limit sanity checks here */
+ {
+ unsigned maxBins = TILES_X * TILES_Y;
+ unsigned maxCommandBytes = sizeof(struct cmd_block) * maxBins;
+ unsigned maxCommandPlusData = maxCommandBytes + DATA_BLOCK_SIZE;
+ /* We'll need at least one command block per bin. Make sure that's
+ * less than the max allowed scene size.
+ */
+ assert(maxCommandBytes LP_SCENE_MAX_SIZE);
+ /* We'll also need space for at least one other data block */
+ assert(maxCommandPlusData = LP_SCENE_MAX_SIZE);
+
+ /* Ideally, the size of a cmd_block object will be a power of two
+ * in order to avoid wasting space when we allocation them from
+ * data blocks (which are power of two also).
+ */
+ assert(sizeof(struct cmd_block) ==
+ util_next_power_of_two(sizeof(struct cmd_block)));
+ }
+
return scene;
}
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] llvmpipe: tweak CMD_BLOCK_MAX and LP_SCENE_MAX_SIZE
We advertise a max texture/surfaces size of 8K x 8K but the old values for these limits didn't actually allow us to handle that surface size. For 8K x 8K we'll have 16384 bins. Each bin needs at least one cmd_block object which was 2192 bytes in size. Since 16384 * 2192 exceeded LP_SCENE_MAX_SIZE we'd silently fail in lp_scene_new_data_block() and not draw the complete scene. By reducing CMD_BLOCK_MAX to 29 we get nice 512-byte cmd_blocks. And by increasing LP_SCENE_MAX_SIZE to 9 MB we can allocate enough command blocks for 8K x 8K, plus a few regular data blocks. Fixes the (improved) piglit fbo-maxsize test. Note: This is a candidate for the stable branches. --- src/gallium/drivers/llvmpipe/lp_scene.h | 10 -- 1 files changed, 8 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/llvmpipe/lp_scene.h b/src/gallium/drivers/llvmpipe/lp_scene.h index b1db61b..801829d 100644 --- a/src/gallium/drivers/llvmpipe/lp_scene.h +++ b/src/gallium/drivers/llvmpipe/lp_scene.h @@ -49,12 +49,18 @@ struct lp_rast_state; #define TILES_Y (LP_MAX_HEIGHT / TILE_SIZE) -#define CMD_BLOCK_MAX 128 +/* Commands per command block (ideally so sizeof(cmd_block) is a power of + * two in size.) + */ +#define CMD_BLOCK_MAX 29 + +/* Bytes per data block. + */ #define DATA_BLOCK_SIZE (64 * 1024) /* Scene temporary storage is clamped to this size: */ -#define LP_SCENE_MAX_SIZE (4*1024*1024) +#define LP_SCENE_MAX_SIZE (9*1024*1024) /* The maximum amount of texture storage referenced by a scene is * clamped ot this size: -- 1.7.3.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] llvmpipe: remove unused cmd_block_list struct
---
src/gallium/drivers/llvmpipe/lp_scene.h |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_scene.h
b/src/gallium/drivers/llvmpipe/lp_scene.h
index 801829d..1d0cd0e 100644
--- a/src/gallium/drivers/llvmpipe/lp_scene.h
+++ b/src/gallium/drivers/llvmpipe/lp_scene.h
@@ -81,10 +81,6 @@ struct cmd_block {
struct cmd_block *next;
};
-struct cmd_block_list {
- struct cmd_block *head;
- struct cmd_block *tail;
-};
struct data_block {
ubyte data[DATA_BLOCK_SIZE];
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] i965: Fix off-by-one in query object result gathering.
If we've written N pairs of values to the buffer, then last_index = N,
but the values are 0 .. N-1. Thus, we need to use , not =.
This worked anyway because we fill the buffer with zeroes, so we just
added an extra (0 - 0) to our results.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_queryobj.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_queryobj.c
b/src/mesa/drivers/dri/i965/brw_queryobj.c
index 0065513..b634a10 100644
--- a/src/mesa/drivers/dri/i965/brw_queryobj.c
+++ b/src/mesa/drivers/dri/i965/brw_queryobj.c
@@ -208,7 +208,7 @@ brw_queryobj_get_results(struct gl_context *ctx,
* run out of space in the query's BO and allocated a new one. If so,
* this function was already called to accumulate the results so far.
*/
- for (i = 0; i = query-last_index; i++) {
+ for (i = 0; i query-last_index; i++) {
query-Base.Result += results[i * 2 + 1] - results[i * 2];
}
break;
@@ -218,7 +218,7 @@ brw_queryobj_get_results(struct gl_context *ctx,
/* If the starting and ending PS_DEPTH_COUNT from any of the batches
* differ, then some fragments passed the depth test.
*/
- for (i = 0; i = query-last_index; i++) {
+ for (i = 0; i query-last_index; i++) {
if (results[i * 2 + 1] != results[i * 2]) {
query-Base.Result = GL_TRUE;
break;
--
1.8.1.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] i965: Don't fill buffer with zeroes.
This was only necessary because our bounds checking was off by one, and thus we read an extra pair of values. Signed-off-by: Kenneth Graunke kenn...@whitecape.org --- src/mesa/drivers/dri/i965/brw_queryobj.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_queryobj.c b/src/mesa/drivers/dri/i965/brw_queryobj.c index b634a10..430a3b1 100644 --- a/src/mesa/drivers/dri/i965/brw_queryobj.c +++ b/src/mesa/drivers/dri/i965/brw_queryobj.c @@ -510,12 +510,6 @@ ensure_bo_has_space(struct gl_context *ctx, struct brw_query_object *query) } query-bo = drm_intel_bo_alloc(intel-bufmgr, query, 4096, 1); - - /* Fill the buffer with zeroes. This is probably superfluous. */ - drm_intel_bo_map(query-bo, true); - memset((char *) query-bo-virtual, 0, 4096); - drm_intel_bo_unmap(query-bo); - query-last_index = 0; } } -- 1.8.1.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Allow ETC2/EAC formats with ARB_ES3_compatibility.
On Mon, Mar 4, 2013 at 11:41 AM, Ian Romanick i...@freedesktop.org wrote:
On 03/04/2013 11:38 AM, Matt Turner wrote:
Reported-by: Marek Olšák mar...@gmail.com
Do our ETC2 piglit tests run in this mode? It would be good to see this
change actually fix a bug by making a failing test pass. :)
ETC2 tests currently runs only on gles3. Need to add
config.supports_gl_compat_version = 30; to enable them on GL contexts.
---
src/mesa/main/teximage.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 0dcf88a..e5260d1 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -520,7 +520,7 @@ _mesa_base_tex_format( struct gl_context *ctx, GLint
internalFormat )
}
}
- if (_mesa_is_gles3(ctx)) {
+ if (_mesa_is_gles3(ctx) || ctx-Extensions.ARB_ES3_compatibility) {
switch (internalFormat) {
case GL_COMPRESSED_RGB8_ETC2:
case GL_COMPRESSED_SRGB8_ETC2:
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/3] llvmpipe: add some scene limit sanity check assertions
Am 04.03.2013 23:04, schrieb Brian Paul:
Note: This is a candidate for the stable branches.
---
src/gallium/drivers/llvmpipe/lp_scene.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_scene.c
b/src/gallium/drivers/llvmpipe/lp_scene.c
index fec2f74..8056906 100644
--- a/src/gallium/drivers/llvmpipe/lp_scene.c
+++ b/src/gallium/drivers/llvmpipe/lp_scene.c
@@ -64,6 +64,26 @@ lp_scene_create( struct pipe_context *pipe )
pipe_mutex_init(scene-mutex);
+ /* Do some scene limit sanity checks here */
+ {
+ unsigned maxBins = TILES_X * TILES_Y;
+ unsigned maxCommandBytes = sizeof(struct cmd_block) * maxBins;
+ unsigned maxCommandPlusData = maxCommandBytes + DATA_BLOCK_SIZE;
+ /* We'll need at least one command block per bin. Make sure that's
+ * less than the max allowed scene size.
+ */
+ assert(maxCommandBytes LP_SCENE_MAX_SIZE);
+ /* We'll also need space for at least one other data block */
+ assert(maxCommandPlusData = LP_SCENE_MAX_SIZE);
+
+ /* Ideally, the size of a cmd_block object will be a power of two
+ * in order to avoid wasting space when we allocation them from
allocation-allocate
+ * data blocks (which are power of two also).
+ */
+ assert(sizeof(struct cmd_block) ==
+ util_next_power_of_two(sizeof(struct cmd_block)));
+ }
I guess that's ok though the waste is not THAT big otherwise (especially
not with the smaller blocks now).
I guess doing STATIC_ASSERT with sizeof() wouldn't be portable? (Of
course it wouldn't work for the last assert.)
return scene;
}
Series looks good to me otherwise though we probably need to improve
that in the future.
Roland
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] i965: Fix off-by-one in query object result gathering.
Kenneth Graunke kenn...@whitecape.org writes: If we've written N pairs of values to the buffer, then last_index = N, but the values are 0 .. N-1. Thus, we need to use , not =. This worked anyway because we fill the buffer with zeroes, so we just added an extra (0 - 0) to our results. This series is: Reviewed-by: Eric Anholt e...@anholt.net pgpuqQ809jrcW.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 61827] New: [softpipe] piglit fbo-clear-formats GL_ARB_depth_buffer_float stencil regression
https://bugs.freedesktop.org/show_bug.cgi?id=61827 Priority: medium Bug ID: 61827 Keywords: regression CC: anuj.pho...@gmail.com Assignee: mesa-dev@lists.freedesktop.org Summary: [softpipe] piglit fbo-clear-formats GL_ARB_depth_buffer_float stencil regression Severity: normal Classification: Unclassified OS: Linux (All) Reporter: v...@freedesktop.org Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Other Product: Mesa mesa: e21460b4d515a7ea41e2694c89b5d94b0bd84d54 (master) $ ./bin/fbo-clear-formats GL_ARB_depth_buffer_float stencil -auto Mesa warning: failed to remap glClampColorARB Mesa warning: failed to remap glTexBufferARB Mesa warning: failed to remap glFramebufferTextureARB Mesa warning: failed to remap glVertexAttribDivisorARB Mesa warning: failed to remap glProgramParameteriARB Using test set: GL_ARB_depth_buffer_float Testing GL_DEPTH_COMPONENT32F - no stencil. Testing GL_DEPTH32F_STENCIL8 Mesa: User error: GL_INVALID_OPERATION in glBlitFramebuffer(stencil attachment depth format mismatch) fbo-clear-formats: piglit/tests/fbo/fbo-clear-formats.c:332: draw_stencil_mipmap: Assertion `piglit_dispatch_glGetError() == 0' failed. Aborted (core dumped) (gdb) bt #0 0x7fcaf932a425 in __GI_raise (sig=optimized out) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x7fcaf932db8b in __GI_abort () at abort.c:91 #2 0x7fcaf93230ee in __assert_fail_base (fmt=optimized out, assertion=0x4061f8 piglit_dispatch_glGetError() == 0, file=0x4061b8 piglit/tests/fbo/fbo-clear-formats.c, line=optimized out, function=optimized out) at assert.c:94 #3 0x7fcaf9323192 in __GI___assert_fail (assertion=0x4061f8 piglit_dispatch_glGetError() == 0, file=0x4061b8 piglit/tests/fbo/fbo-clear-formats.c, line=332, function=0x406280 draw_stencil_mipmap) at assert.c:103 #4 0x00402ce9 in draw_stencil_mipmap (x=1, y=1, dim=256, tex=1, level=0) at piglit/tests/fbo/fbo-clear-formats.c:332 #5 0x004035c9 in test_format (format=0x404ed8) at piglit/tests/fbo/fbo-clear-formats.c:535 #6 0x00401f92 in fbo_formats_display (test_format=0x40346d test_format) at piglit/tests/fbo/fbo-formats.h:641 #7 0x004036d4 in piglit_display () at piglit/tests/fbo/fbo-clear-formats.c:563 #8 0x7fcaf991c418 in display () at piglit/tests/util/piglit-framework-gl/piglit_glut_framework.c:60 #9 0x7fcaf90ce137 in fghRedrawWindow (window=0x21a7e60) at freeglut_main.c:210 #10 fghcbDisplayWindow (window=0x21a7e60, enumerator=0x7fff69b020d0) at freeglut_main.c:227 #11 0x7fcaf90d1889 in fgEnumWindows (enumCallback=0x7fcaf90ce0d0 fghcbDisplayWindow, enumerator=0x7fff69b020d0) at freeglut_structure.c:394 #12 0x7fcaf90ce5fa in fghDisplayAll () at freeglut_main.c:249 #13 glutMainLoopEvent () at freeglut_main.c:1450 #14 0x7fcaf90cef05 in glutMainLoop () at freeglut_main.c:1498 #15 0x7fcaf991c5f0 in run_test (gl_fw=0x7fcaf9befbc0, argc=3, argv=0x7fff69b02498) at piglit/tests/util/piglit-framework-gl/piglit_glut_framework.c:127 #16 0x7fcaf991a736 in piglit_gl_test_run (argc=3, argv=0x7fff69b02498, config=0x7fff69b02380) at piglit/tests/util/piglit-framework-gl.c:127 #17 0x004020c0 in main (argc=4, argv=0x7fff69b02498) at piglit/tests/fbo/fbo-clear-formats.c:49 (gdb) frame 4 #4 0x00402ce9 in draw_stencil_mipmap (x=1, y=1, dim=256, tex=1, level=0) at piglit/tests/fbo/fbo-clear-formats.c:332 332assert(glGetError() == 0); 252573ae0fe6c928885f005cf6e77200b45601fb is the first bad commit commit 252573ae0fe6c928885f005cf6e77200b45601fb Author: Anuj Phogat anuj.pho...@gmail.com Date: Mon Jan 7 15:55:31 2013 -0800 mesa: Fix GL error generation in glBlitFramebuffer() V2: If mask has GL_STENCIL_BUFFER_BIT set, the depth formats for readRenderBuffer and drawRenderBuffer must match unless one of the two buffers doesn't have depth, in which case it's not blitted, so the format check should be ignored. Same comment goes for stencil formats in depth renderbuffers if mask has GL_DEPTH_BUFFER_BIT set. v3 (Kayden): Refactor code to be a bit more readable. Signed-off-by: Anuj Phogat anuj.pho...@gmail.com Signed-off-by: Kenneth Graunke kenn...@whitecape.org Reviewed-by: Kenneth Graunke kenn...@whitecape.org Reviewed-by: Ian Romanick ian.d.roman...@intel.com :04 04 56dc8f187d114e82f922ff7b0dcf6800a1eb174c 0891bad034833aa6624fa0caf7a6cf2818ddfc59 Msrc bisect run success -- 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 61828] New: [softpipe] tgsi/tgsi_exec.c:1936:exec_tex: Assertion `modifier != 1' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=61828 Priority: medium Bug ID: 61828 Keywords: have-backtrace, regression CC: srol...@vmware.com Assignee: mesa-dev@lists.freedesktop.org Summary: [softpipe] tgsi/tgsi_exec.c:1936:exec_tex: Assertion `modifier != 1' failed. Severity: critical Classification: Unclassified OS: Linux (All) Reporter: v...@freedesktop.org Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Other Product: Mesa mesa: e21460b4d515a7ea41e2694c89b5d94b0bd84d54 (master) Run piglit array-texture test on softpipe. $ ./bin/array-texture -auto Mesa warning: failed to remap glClampColorARB Mesa warning: failed to remap glTexBufferARB Mesa warning: failed to remap glFramebufferTextureARB Mesa warning: failed to remap glVertexAttribDivisorARB Mesa warning: failed to remap glProgramParameteriARB tgsi/tgsi_exec.c:1936:exec_tex: Assertion `modifier != 1' failed. Trace/breakpoint trap (core dumped) (gdb) bt #0 0x7f28bca0d722 in _debug_assert_fail (expr=0x7f28bcc2b24e modifier != 1, file=0x7f28bcc2afc4 tgsi/tgsi_exec.c, line=1936, function=0x7f28bcc2b93d exec_tex) at util/u_debug.c:278 #1 0x7f28bc9ee42c in exec_tex (mach=0x7f28b29e3010, inst=0x28ab2d0, modifier=1, sampler=1) at tgsi/tgsi_exec.c:1936 #2 0x7f28bc9f55c1 in exec_instruction (mach=0x7f28b29e3010, inst=0x28ab2d0, pc=0x733b9298) at tgsi/tgsi_exec.c:3862 #3 0x7f28bc9f7b0f in tgsi_exec_machine_run (mach=0x7f28b29e3010) at tgsi/tgsi_exec.c:4484 #4 0x7f28bcabe8d6 in exec_run (var=0x28aac90, machine=0x7f28b29e3010, quad=0x2501710) at sp_fs_exec.c:129 #5 0x7f28bcac6ca8 in shade_quad (qs=0x24355f0, quad=0x2501710) at sp_quad_fs.c:78 #6 0x7f28bcac6e5c in shade_quads (qs=0x24355f0, quads=0x2503b90, nr=1) at sp_quad_fs.c:131 #7 0x7f28bcad0237 in flush_spans (setup=0x2501690) at sp_setup.c:250 #8 0x7f28bcad161b in subtriangle (setup=0x2501690, eleft=0x25016e8, eright=0x25016b8, lines=100) at sp_setup.c:759 #9 0x7f28bcad18d3 in sp_setup_tri (setup=0x2501690, v0=0x2674f10, v1=0x2674f30, v2=0x2674ef0) at sp_setup.c:848 #10 0x7f28bcac2428 in sp_vbuf_draw_arrays (vbr=0x2501600, start=0, nr=4) at sp_prim_vbuf.c:577 #11 0x7f28bc9be148 in draw_pt_emit_linear (emit=0x24fe3f0, vert_info=0x733b9660, prim_info=0x733b9710) at draw/draw_pt_emit.c:255 #12 0x7f28bc9c0888 in emit (emit=0x24fe3f0, vert_info=0x733b9660, prim_info=0x733b9710) at draw/draw_pt_fetch_shade_pipeline.c:187 #13 0x7f28bc9c0c03 in fetch_pipeline_generic (middle=0x24fe2b0, fetch_info=0x0, prim_info=0x733b9710) at draw/draw_pt_fetch_shade_pipeline.c:306 #14 0x7f28bc9c0d31 in fetch_pipeline_linear_run (middle=0x24fe2b0, start=0, count=4, prim_flags=0) at draw/draw_pt_fetch_shade_pipeline.c:364 #15 0x7f28bc9c861f in vsplit_segment_simple_linear (vsplit=0x24fb680, flags=0, istart=0, icount=4) at draw/draw_pt_vsplit_tmp.h:235 #16 0x7f28bc9c8924 in vsplit_run_linear (frontend=0x24fb680, start=0, count=4) at draw/draw_split_tmp.h:61 #17 0x7f28bc9bcaf1 in draw_pt_arrays (draw=0x24f1170, prim=9, start=0, count=4) at draw/draw_pt.c:148 #18 0x7f28bc9bd75a in draw_vbo (draw=0x24f1170, info=0x733b9950) at draw/draw_pt.c:539 #19 0x7f28bcac08a4 in softpipe_draw_vbo (pipe=0x2436020, info=0x733b9950) at sp_draw_arrays.c:109 #20 0x7f28bc9a6f2d in cso_draw_vbo (cso=0x2585b60, info=0x733b9950) at cso_cache/cso_context.c:1347 #21 0x7f28bc8bbe90 in st_draw_vbo (ctx=0x25253f0, prims=0x2570bac, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=0, max_index=3, tfb_vertcount=0x0) at ../../src/mesa/state_tracker/st_draw.c:287 #22 0x7f28bc87d79b in vbo_exec_vtx_flush (exec=0x2570318, keepUnmapped=1 '\001') at ../../src/mesa/vbo/vbo_exec_draw.c:400 #23 0x7f28bc876966 in vbo_exec_FlushVertices_internal (exec=0x2570318, unmap=1 '\001') at ../../src/mesa/vbo/vbo_exec_api.c:556 #24 0x7f28bc878ebe in vbo_exec_FlushVertices (ctx=0x25253f0, flags=1) at ../../src/mesa/vbo/vbo_exec_api.c:1256 #25 0x7f28bc7fa510 in _mesa_ReadnPixelsARB (x=50, y=150, width=1, height=1, format=6407, type=5126, bufSize=2147483647, pixels=0x733b9b70) at ../../src/mesa/main/readpix.c:735 #26 0x7f28bc7faac5 in _mesa_ReadPixels (x=50, y=150, width=1, height=1, format=6407, type=5126, pixels=0x733b9b70) at ../../src/mesa/main/readpix.c:869 #27 0x7f28c0462cd8 in piglit_probe_pixel_rgb (x=50, y=150, expected=0x6030a0) at piglit/tests/util/piglit-util-gl.c:414 #28 0x00401861 in test_2d_array_texture (tex=1) at piglit/tests/texturing/array-texture.c:196 #29 0x00401c6d in piglit_display () at piglit/tests/texturing/array-texture.c:299 #30 0x7f28c03fd418 in display () at piglit/tests/util/piglit-framework-gl/piglit_glut_framework.c:60 #31 0x7f28bfdb2137 in
[Mesa-dev] [Bug 61828] [softpipe] tgsi/tgsi_exec.c:1936:exec_tex: Assertion `modifier != 1' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=61828 --- Comment #1 from Roland Scheidegger srol...@vmware.com --- Whoa I thought noone ever defined TXP for array textures. But it turns out I was wrong since apparently GL_MESA_texture_array supports array textures even with fixed function hence TXP. Sick. (The spec does not actually seem to define if the array coord should be projected or not, but I guess from previous softpipe behavior not. I don't think any real hw actually implements this correctly however.) Well I will just kill those assertions again. I am quite sure we can't really handle that correctly everywhere however anyway (for instance the glsl-to-tgsi code lowering texture opcodes with lod and projection would do the projective divide itself on all coords but then again probably noone cares). -- 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] texobj: add verbose api trace messages to several routines
Jose Fonseca jfons...@vmware.com writes: I see. But one can use apitrace through LD_LIBRARY_PATH instead of LD_PRELOAD. Steam is not the first app to have issues with LD_PRELOAD. I spend some time looking at this issue today. First, things aren't as bad as I had first thought. I had misunderstood the original report thinking that the Steam overlay made it so that no Steam games could be traced. But in fact, it's easy to trace a Steam game with apitrace trace—the only trick is to ensure that LD_PRELOAD does not include gamoverlayrenderer.so. But, yes, there's definitely a failure if one actually does want to trace the operation of the overlay itself. And switching from LD_PRELOAD to LD_LIBRARY_PATH for apitrace didn't fix things in my experiments. Regardless of the mechanism for invoking apitrace, I found the same behavior: If both apitrace and gameoverlayrenderer are loaded then the game will segfault. The crash is from infinite mutual recursion as the two wrappers continue to call into each others functions. I don't think it should be too hard to get this to work, (though it may require a source change to the Steam overlay). I'll do some more experiments tomorrow and see if I can't make a concrete recommendation to be able to give to Valve as a bug report. And, obviously, if there's something we can do to make apitrace more robust here, I'll submit that change as well. -Carl -- carl.d.wo...@intel.com pgpJYhYGV47X5.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC] egl/dri2: Add Mir platform backend
From: Christopher James Halse Rogers r...@ubuntu.com
A first pass at a Mir platform for EGL.
This is RFC mainly because I hope to shortly make Mir's API less painfully
pointless-callback-based. There's no point in committing this as-is, but
it's hopefully still useful to review.
---
configure.ac| 5 +-
src/egl/drivers/dri2/Makefile.am| 6 +
src/egl/drivers/dri2/egl_dri2.c | 6 +
src/egl/drivers/dri2/egl_dri2.h | 19 +-
src/egl/drivers/dri2/platform_mir.c | 344
src/egl/main/Makefile.am| 6 +
src/egl/main/egldisplay.c | 12 +-
src/egl/main/egldisplay.h | 1 +
8 files changed, 395 insertions(+), 4 deletions(-)
create mode 100644 src/egl/drivers/dri2/platform_mir.c
diff --git a/configure.ac b/configure.ac
index 7852595..6f35e9e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1559,7 +1559,9 @@ for plat in $egl_platforms; do
android|gdi)
;;
-
+mir)
+PKG_CHECK_MODULES([MIR], [mirclient])
+;;
*)
AC_MSG_ERROR([EGL platform '$plat' does not exist])
;;
@@ -1587,6 +1589,7 @@ AM_CONDITIONAL(HAVE_EGL_PLATFORM_WAYLAND, echo
$egl_platforms | grep 'wayland'
AM_CONDITIONAL(HAVE_EGL_PLATFORM_DRM, echo $egl_platforms | grep 'drm'
/dev/null 21)
AM_CONDITIONAL(HAVE_EGL_PLATFORM_FBDEV, echo $egl_platforms | grep 'fbdev'
/dev/null 21)
AM_CONDITIONAL(HAVE_EGL_PLATFORM_NULL, echo $egl_platforms | grep 'null'
/dev/null 21)
+AM_CONDITIONAL(HAVE_EGL_PLATFORM_MIR, echo $egl_platforms | grep 'mir'
/dev/null 21)
AM_CONDITIONAL(HAVE_EGL_DRIVER_DRI2, test x$HAVE_EGL_DRIVER_DRI2 != x)
AM_CONDITIONAL(HAVE_EGL_DRIVER_GLX, test x$HAVE_EGL_DRIVER_GLX != x)
diff --git a/src/egl/drivers/dri2/Makefile.am b/src/egl/drivers/dri2/Makefile.am
index 45f7dfa..dfb0c05 100644
--- a/src/egl/drivers/dri2/Makefile.am
+++ b/src/egl/drivers/dri2/Makefile.am
@@ -62,3 +62,9 @@ if HAVE_EGL_PLATFORM_DRM
libegl_dri2_la_SOURCES += platform_drm.c
AM_CFLAGS += -DHAVE_DRM_PLATFORM
endif
+
+if HAVE_EGL_PLATFORM_MIR
+libegl_dri2_la_SOURCES += platform_mir.c
+AM_CFLAGS += -DHAVE_MIR_PLATFORM
+AM_CFLAGS += $(MIR_CFLAGS)
+endif
diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index b774919..ddd0314 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -599,6 +599,12 @@ dri2_initialize(_EGLDriver *drv, _EGLDisplay *disp)
return EGL_TRUE;
return dri2_initialize_wayland(drv, disp);
#endif
+#ifdef HAVE_MIR_PLATFORM
+ case _EGL_PLATFORM_MIR:
+ if (disp-Options.TestOnly)
+ return EGL_TRUE;
+ return dri2_initialize_mir(drv, disp);
+#endif
#endif
#ifdef HAVE_ANDROID_PLATFORM
case _EGL_PLATFORM_ANDROID:
diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
index 84ea2a6..d82b9f8 100644
--- a/src/egl/drivers/dri2/egl_dri2.h
+++ b/src/egl/drivers/dri2/egl_dri2.h
@@ -65,6 +65,10 @@
#endif /* HAVE_ANDROID_PLATFORM */
+#ifdef HAVE_MIR_PLATFORM
+#include mir_client_library.h
+#endif
+
#include eglconfig.h
#include eglcontext.h
#include egldisplay.h
@@ -134,6 +138,10 @@ struct dri2_egl_display
int formats;
#endif
+#ifdef HAVE_MIR_PLATFORM
+ MirConnection*mir_conn;
+#endif
+
int (*authenticate) (_EGLDisplay *disp, uint32_t id);
};
@@ -182,7 +190,9 @@ struct dri2_egl_surface
struct gbm_dri_surface *gbm_surf;
#endif
-#if defined(HAVE_WAYLAND_PLATFORM) || defined(HAVE_DRM_PLATFORM)
+#if defined(HAVE_WAYLAND_PLATFORM) \
+ || defined(HAVE_DRM_PLATFORM) \
+ || defined(HAVE_MIR_PLATFORM)
__DRIbuffer *dri_buffers[__DRI_BUFFER_COUNT];
struct {
#ifdef HAVE_WAYLAND_PLATFORM
@@ -204,6 +214,10 @@ struct dri2_egl_surface
/* EGL-owned buffers */
__DRIbuffer *local_buffers[__DRI_BUFFER_COUNT];
#endif
+
+#ifdef HAVE_MIR_PLATFORM
+ MirSurface*mir_surf;
+#endif
};
@@ -265,6 +279,9 @@ dri2_initialize_wayland(_EGLDriver *drv, _EGLDisplay *disp);
EGLBoolean
dri2_initialize_android(_EGLDriver *drv, _EGLDisplay *disp);
+EGLBoolean
+dri2_initialize_mir(_EGLDriver *drv, _EGLDisplay *disp);
+
char *
dri2_get_driver_for_fd(int fd);
char *
diff --git a/src/egl/drivers/dri2/platform_mir.c
b/src/egl/drivers/dri2/platform_mir.c
new file mode 100644
index 000..965a1df
--- /dev/null
+++ b/src/egl/drivers/dri2/platform_mir.c
@@ -0,0 +1,344 @@
+/*
+ * Copyright © 2012 Canonical, Inc
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
