[Mesa-dev] [Bug 74122] loader.c:71:19: fatal error: dlfcn.h: No such file or directory
https://bugs.freedesktop.org/show_bug.cgi?id=74122 José Fonseca jfons...@vmware.com changed: What|Removed |Added CC||bri...@vmware.com, ||emil.l.veli...@gmail.com --- Comment #2 from José Fonseca jfons...@vmware.com --- Why is DRI code being built for a windows target? Sounds like scons's windows build is wrong. Yes, it appears that there is no point to build loader for windows. However egl-static was supposed to buil on Windows and it is now hardcoded to depend on loader: Linking build/windows-x86-debug/gallium/targets/egl-static/libEGL.dll ... build/windows-x86-debug/gallium/targets/egl-static/egl.o: In function `create_drm_screen': /home/jfonseca/projects/opengl/mesa/src/gallium/targets/egl-static/egl.c:64: undefined reference to `_loader_get_driver_for_fd' build/windows-x86-debug/gallium/targets/egl-static/egl.o: In function `loader_init': /home/jfonseca/projects/opengl/mesa/src/gallium/targets/egl-static/egl.c:99: undefined reference to `_loader_set_logger' collect2: ld returned 1 exit status scons: *** [build/windows-x86-debug/gallium/targets/egl-static/libEGL.dll] Error 1 Not sure what to do here. I suspect I'll have to revert http://cgit.freedesktop.org/mesa/mesa/commit/?id=a9800242244098fddcd2b963d8f5ccda5dea8290 and a few more until the cross-platform portability of loader is addressed. Emil, if you could into this it would be appreciated. To repro all you need is cross-mingw compilers installed, and do scons platform=windows toolchain=crossmingw -- 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 v2 14/17] radeonsi: We don't support indirect addressing of geometry shader inputs
From: Michel Dänzer michel.daen...@amd.com Fixes piglit spec/glsl-1.50/execution/geometry/dynamic_input_array_index Signed-off-by: Michel Dänzer michel.daen...@amd.com --- v2: Limit to geometry shader inputs, add explanatory comment src/gallium/drivers/radeonsi/si_pipe.c | 4 1 file changed, 4 insertions(+) diff --git a/src/gallium/drivers/radeonsi/si_pipe.c b/src/gallium/drivers/radeonsi/si_pipe.c index 040944d..768b84d 100644 --- a/src/gallium/drivers/radeonsi/si_pipe.c +++ b/src/gallium/drivers/radeonsi/si_pipe.c @@ -380,6 +380,10 @@ static int si_get_shader_param(struct pipe_screen* pscreen, unsigned shader, enu case PIPE_SHADER_CAP_TGSI_SQRT_SUPPORTED: return 0; case PIPE_SHADER_CAP_INDIRECT_INPUT_ADDR: + /* Indirection of geometry shader input dimension is not +* handled yet +*/ + return shader PIPE_SHADER_GEOMETRY; case PIPE_SHADER_CAP_INDIRECT_OUTPUT_ADDR: case PIPE_SHADER_CAP_INDIRECT_TEMP_ADDR: case PIPE_SHADER_CAP_INDIRECT_CONST_ADDR: -- 1.8.5.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 03/17] radeonsi: Fix handling of geometry shader output vertex ID
From: Michel Dänzer michel.daen...@amd.com
It needs to increment at shader runtime, not at shader compile time, as
the geometry shader can emit vertices in loops. LLVM automagically
converts the ID back to an immediate value if its value can be
determined at compile time.
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
v2: Drop excessive HAVE_LLVM preprocessor guards
src/gallium/drivers/radeonsi/si_shader.c | 26 +++---
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeonsi/si_shader.c
index a04110b..8696d03 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -61,7 +61,6 @@ struct si_shader_context
struct si_pipe_shader *shader;
struct si_shader *gs_for_vs;
unsigned type; /* TGSI_PROCESSOR_* specifies the type of shader. */
- unsigned gs_next_vertex;
int param_streamout_config;
int param_streamout_write_index;
int param_streamout_offset[4];
@@ -76,6 +75,7 @@ struct si_shader_context
LLVMValueRef *resources;
LLVMValueRef *samplers;
LLVMValueRef so_buffers[4];
+ LLVMValueRef gs_next_vertex;
};
static struct si_shader_context * si_shader_context(
@@ -1854,9 +1854,11 @@ static void si_llvm_emit_vertex(
struct lp_build_emit_data *emit_data)
{
struct si_shader_context *si_shader_ctx = si_shader_context(bld_base);
+ struct lp_build_context *uint = bld_base-uint_bld;
struct si_shader *shader = si_shader_ctx-shader-shader;
struct gallivm_state *gallivm = bld_base-base.gallivm;
LLVMTypeRef i32 = LLVMInt32TypeInContext(gallivm-context);
+ LLVMValueRef gs_next_vertex;
LLVMValueRef t_list_ptr;
LLVMValueRef t_list;
LLVMValueRef args[2];
@@ -1882,20 +1884,22 @@ static void si_llvm_emit_vertex(
}
/* Write vertex attribute values to GSVS ring */
+ gs_next_vertex = LLVMBuildLoad(gallivm-builder,
si_shader_ctx-gs_next_vertex, );
for (i = 0; i shader-noutput; i++) {
LLVMValueRef *out_ptr =
si_shader_ctx-radeon_bld.soa.outputs[shader-output[i].index];
for (chan = 0; chan 4; chan++) {
LLVMValueRef out_val = LLVMBuildLoad(gallivm-builder,
out_ptr[chan], );
- LLVMValueRef voffset =
- lp_build_const_int32(gallivm,
-((i * 4 + chan) *
-
shader-gs_max_out_vertices +
-
si_shader_ctx-gs_next_vertex) * 4);
LLVMValueRef soffset =
LLVMGetParam(si_shader_ctx-radeon_bld.main_fn,
SI_PARAM_GS2VS_OFFSET);
+ LLVMValueRef voffset =
+ lp_build_const_int32(gallivm, (i * 4 + chan) *
+
shader-gs_max_out_vertices);
+
+ voffset = lp_build_add(uint, voffset, gs_next_vertex);
+ voffset = lp_build_mul_imm(uint, voffset, 4);
out_val = LLVMBuildBitCast(gallivm-builder, out_val,
i32, );
@@ -1906,7 +1910,9 @@ static void si_llvm_emit_vertex(
1, 0, 1, 1, 0);
}
}
- si_shader_ctx-gs_next_vertex++;
+ gs_next_vertex = lp_build_add(uint, gs_next_vertex,
+ lp_build_const_int32(gallivm, 1));
+ LLVMBuildStore(gallivm-builder, gs_next_vertex,
si_shader_ctx-gs_next_vertex);
/* Signal vertex emission */
args[0] = lp_build_const_int32(gallivm, SENDMSG_GS_OP_EMIT |
SENDMSG_GS);
@@ -2483,6 +2489,12 @@ int si_pipe_shader_create(
si_dump_streamout(sel-so);
}
+ if (si_shader_ctx.type == TGSI_PROCESSOR_GEOMETRY) {
+ si_shader_ctx.gs_next_vertex =
+ lp_build_alloca(bld_base-base.gallivm,
+ bld_base-uint_bld.elem_type, );
+ }
+
if (!lp_build_tgsi_llvm(bld_base, sel-tokens)) {
fprintf(stderr, Failed to translate shader from TGSI to
LLVM\n);
goto out;
--
1.8.5.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 16/17] radeonsi: Enable OpenGL 3.3
From: Michel Dänzer michel.daen...@amd.com Signed-off-by: Michel Dänzer michel.daen...@amd.com --- v2: * Drop excessive HAVE_LLVM preprocessor guards * Update docs/GL3.txt docs/GL3.txt | 36 +- src/gallium/drivers/radeonsi/si_pipe.c | 8 +--- 2 files changed, 23 insertions(+), 21 deletions(-) diff --git a/docs/GL3.txt b/docs/GL3.txt index 2dc3569..6d6fe71 100644 --- a/docs/GL3.txt +++ b/docs/GL3.txt @@ -63,35 +63,35 @@ GL 3.1 --- all DONE: i965, nv50, nvc0, r600, radeonsi Signed normalized textures (GL_EXT_texture_snorm) DONE (r300) -GL 3.2 --- all DONE: i965, nv50, nvc0 +GL 3.2 --- all DONE: i965, nv50, nvc0, radeonsi Core/compatibility profiles DONE GLSL 1.50 DONE () Geometry shaders DONE () - BGRA vertex order (GL_ARB_vertex_array_bgra) DONE (r300, r600, radeonsi, swrast) - Base vertex offset(GL_ARB_draw_elements_base_vertex) DONE (r300, r600, radeonsi, swrast) - Frag shader coord (GL_ARB_fragment_coord_conventions) DONE (r300, r600, radeonsi, swrast) - Provoking vertex (GL_ARB_provoking_vertex)DONE (r300, r600, radeonsi, swrast) - Seamless cubemaps (GL_ARB_seamless_cube_map) DONE (r600, radeonsi) - Multisample textures (GL_ARB_texture_multisample) DONE (r600, radeonsi) - Frag depth clamp (GL_ARB_depth_clamp) DONE (r600, swrast, radeonsi) - Fence objects (GL_ARB_sync) DONE (r300, r600, radeonsi, swrast) + BGRA vertex order (GL_ARB_vertex_array_bgra) DONE (r300, r600, swrast) + Base vertex offset(GL_ARB_draw_elements_base_vertex) DONE (r300, r600, swrast) + Frag shader coord (GL_ARB_fragment_coord_conventions) DONE (r300, r600, swrast) + Provoking vertex (GL_ARB_provoking_vertex)DONE (r300, r600, swrast) + Seamless cubemaps (GL_ARB_seamless_cube_map) DONE (r600) + Multisample textures (GL_ARB_texture_multisample) DONE (r600) + Frag depth clamp (GL_ARB_depth_clamp) DONE (r600, swrast) + Fence objects (GL_ARB_sync) DONE (r300, r600, swrast) GLX_ARB_create_context_profileDONE -GL 3.3 --- all DONE: i965, nv50, nvc0 +GL 3.3 --- all DONE: i965, nv50, nvc0, radeonsi GLSL 3.30 DONE () - GL_ARB_blend_func_extendedDONE (r600, radeonsi, softpipe) + GL_ARB_blend_func_extendedDONE (r600, softpipe) GL_ARB_explicit_attrib_location DONE (all drivers that support GLSL) - GL_ARB_occlusion_query2 DONE (r300, r600, radeonsi, swrast) + GL_ARB_occlusion_query2 DONE (r300, r600, swrast) GL_ARB_sampler_objectsDONE (all drivers) - GL_ARB_shader_bit_encodingDONE (r600, radeonsi) - GL_ARB_texture_rgb10_a2ui DONE (r600, radeonsi) - GL_ARB_texture_swizzleDONE (r300, r600, radeonsi, swrast) - GL_ARB_timer_queryDONE (r600, radeonsi) - GL_ARB_instanced_arrays DONE (r300, r600, radeonsi) - GL_ARB_vertex_type_2_10_10_10_rev DONE (r600, radeonsi) + GL_ARB_shader_bit_encodingDONE (r600) + GL_ARB_texture_rgb10_a2ui DONE (r600) + GL_ARB_texture_swizzleDONE (r300, r600, swrast) + GL_ARB_timer_queryDONE (r600) + GL_ARB_instanced_arrays DONE (r300, r600) + GL_ARB_vertex_type_2_10_10_10_rev DONE (r600) GL 4.0: diff --git a/src/gallium/drivers/radeonsi/si_pipe.c b/src/gallium/drivers/radeonsi/si_pipe.c index 768b84d..01e93ba 100644 --- a/src/gallium/drivers/radeonsi/si_pipe.c +++ b/src/gallium/drivers/radeonsi/si_pipe.c @@ -269,7 +269,7 @@ static int si_get_param(struct pipe_screen* pscreen, enum pipe_cap param) return 256; case PIPE_CAP_GLSL_FEATURE_LEVEL: - return 140; + return HAVE_LLVM = 0x0305 ? 330 : 140; case PIPE_CAP_TEXTURE_BUFFER_OFFSET_ALIGNMENT: return 1; @@ -307,7 +307,7 @@ static int si_get_param(struct pipe_screen* pscreen, enum pipe_cap param) case PIPE_CAP_MAX_TEXTURE_ARRAY_LAYERS: return 16384; case PIPE_CAP_MAX_COMBINED_SAMPLERS: - return 32; + return HAVE_LLVM = 0x0305 ? 48: 32; /* Render targets. */ case PIPE_CAP_MAX_RENDER_TARGETS: @@ -340,8 +340,10 @@ static int si_get_shader_param(struct pipe_screen* pscreen, unsigned shader, enu case PIPE_SHADER_VERTEX:
[Mesa-dev] [PATCH 17/17] radeonsi; Put GS ring buffer descriptors with streamout buffer descriptors
From: Michel Dänzer michel.daen...@amd.com
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
src/gallium/drivers/radeonsi/si_descriptors.c | 93 ---
src/gallium/drivers/radeonsi/si_pipe.h| 6 +-
src/gallium/drivers/radeonsi/si_shader.c | 22 ---
src/gallium/drivers/radeonsi/si_shader.h | 72 +++--
src/gallium/drivers/radeonsi/si_state.h | 6 +-
5 files changed, 115 insertions(+), 84 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c
b/src/gallium/drivers/radeonsi/si_descriptors.c
index 2a54fcb..9078c6c 100644
--- a/src/gallium/drivers/radeonsi/si_descriptors.c
+++ b/src/gallium/drivers/radeonsi/si_descriptors.c
@@ -516,7 +516,7 @@ void si_set_ring_buffer(struct pipe_context *ctx, uint
shader, uint slot,
unsigned element_size, unsigned index_stride)
{
struct si_context *sctx = (struct si_context *)ctx;
- struct si_buffer_resources *buffers = sctx-const_buffers[shader];
+ struct si_buffer_resources *buffers = sctx-rw_buffers[shader];
if (shader = SI_NUM_SHADERS)
return;
@@ -608,9 +608,9 @@ static void si_set_streamout_targets(struct pipe_context
*ctx,
unsigned append_bitmask)
{
struct si_context *sctx = (struct si_context *)ctx;
- struct si_buffer_resources *buffers = sctx-streamout_buffers;
+ struct si_buffer_resources *buffers =
sctx-rw_buffers[PIPE_SHADER_VERTEX];
unsigned old_num_targets = sctx-b.streamout.num_targets;
- unsigned i;
+ unsigned i, bufidx;
/* Streamout buffers must be bound in 2 places:
* 1) in VGT by setting the VGT_STRMOUT registers
@@ -622,12 +622,14 @@ static void si_set_streamout_targets(struct pipe_context
*ctx,
/* Set the shader resources.*/
for (i = 0; i num_targets; i++) {
+ bufidx = SI_RW_SO + i;
+
if (targets[i]) {
struct pipe_resource *buffer = targets[i]-buffer;
uint64_t va = r600_resource_va(ctx-screen, buffer);
/* Set the descriptor. */
- uint32_t *desc = buffers-desc_data[i];
+ uint32_t *desc = buffers-desc_data[bufidx];
desc[0] = va;
desc[1] = S_008F04_BASE_ADDRESS_HI(va 32);
desc[2] = 0x;
@@ -637,25 +639,29 @@ static void si_set_streamout_targets(struct pipe_context
*ctx,
S_008F0C_DST_SEL_W(V_008F0C_SQ_SEL_W);
/* Set the resource. */
- pipe_resource_reference(buffers-buffers[i], buffer);
+ pipe_resource_reference(buffers-buffers[bufidx],
+ buffer);
r600_context_bo_reloc(sctx-b, sctx-b.rings.gfx,
(struct r600_resource*)buffer,
buffers-shader_usage);
- buffers-desc.enabled_mask |= 1 i;
+ buffers-desc.enabled_mask |= 1 bufidx;
} else {
/* Clear the descriptor and unset the resource. */
- memset(buffers-desc_data[i], 0, sizeof(uint32_t) * 4);
- pipe_resource_reference(buffers-buffers[i], NULL);
- buffers-desc.enabled_mask = ~(1 i);
+ memset(buffers-desc_data[bufidx], 0,
+ sizeof(uint32_t) * 4);
+ pipe_resource_reference(buffers-buffers[bufidx],
+ NULL);
+ buffers-desc.enabled_mask = ~(1 bufidx);
}
- buffers-desc.dirty_mask |= 1 i;
+ buffers-desc.dirty_mask |= 1 bufidx;
}
for (; i old_num_targets; i++) {
+ bufidx = SI_RW_SO + i;
/* Clear the descriptor and unset the resource. */
- memset(buffers-desc_data[i], 0, sizeof(uint32_t) * 4);
- pipe_resource_reference(buffers-buffers[i], NULL);
- buffers-desc.enabled_mask = ~(1 i);
- buffers-desc.dirty_mask |= 1 i;
+ memset(buffers-desc_data[bufidx], 0, sizeof(uint32_t) * 4);
+ pipe_resource_reference(buffers-buffers[bufidx], NULL);
+ buffers-desc.enabled_mask = ~(1 bufidx);
+ buffers-desc.dirty_mask |= 1 bufidx;
}
si_update_descriptors(sctx, buffers-desc);
@@ -712,25 +718,37 @@ static void si_invalidate_buffer(struct pipe_context
*ctx, struct pipe_resource
/* Vertex buffers. */
/* Nothing to do. Vertex buffer bindings are updated before every draw
call. */
- /* Streamout buffers. */
- for (i = 0; i
Re: [Mesa-dev] [PATCH] i965/blorp: do not use unnecessary hw-blending support
On Mon, Jan 27, 2014 at 06:00:54PM -0800, Kenneth Graunke wrote:
On 01/27/2014 11:06 AM, Pohjolainen, Topi wrote:
On Mon, Jan 27, 2014 at 10:20:54AM -0800, Eric Anholt wrote:
Topi Pohjolainen topi.pohjolai...@intel.com writes:
This is really not needed as blorp blit programs already sample
XRGB normally and get alpha channel set to 1.0 automatically by
the sampler engine. This is simply copied directly to the payload
of the render target write message and hence there is no need for
any additional blending support from the pixel processing pipeline.
Fixes recently modified piglit test gl-3.2-layered-rendering-blit
on IVB. No regressions on IVB.
What about when you have a RGB-but-not-alpha gl format that's been
promoted to an ARGB Mesa and BRW surface format? I don't think blorp's
samplers have any overrides going on there.
I relied on the restriction that only blits from RGBX to RGBA and vice
versa are allowed. Otherwise the formats must match.
I think Eric's right. Technically, it works for BlitFramebuffer because
of what you say...but...we allow nearly arbitrary format conversions for
CopyTexSubImage today, so I think dropping this could break things
there. Plus, we hope to add that for BlitFramebuffer too (it's trivial).
So, I think this code may need to stay after all...sorry for the confusion.
This is fine by me, I'd rather understand it fully before changing it anyway.
Further observation I made is that if I left just the alpha channel blending
in place and removed the color blending than the test case passes also:
diff --git a/src/mesa/drivers/dri/i965/gen6_blorp.cpp b/src/mesa/drivers/dri/i96
index 90b9fbb..959ed05 100644
--- a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
@@ -262,14 +262,10 @@ gen6_blorp_emit_blend_state(struct brw_context *brw,
if (params-src.mt
_mesa_get_format_bits(params-dst.mt-format, GL_ALPHA_BITS) 0
_mesa_get_format_bits(params-src.mt-format, GL_ALPHA_BITS) == 0) {
- blend-blend0.blend_enable = 1;
blend-blend0.ia_blend_enable = 1;
- blend-blend0.blend_func = BRW_BLENDFUNCTION_ADD;
blend-blend0.ia_blend_func = BRW_BLENDFUNCTION_ADD;
- blend-blend0.source_blend_factor = BRW_BLENDFACTOR_SRC_COLOR;
- blend-blend0.dest_blend_factor = BRW_BLENDFACTOR_ZERO;
blend-blend0.ia_source_blend_factor = BRW_BLENDFACTOR_ONE;
blend-blend0.ia_dest_blend_factor = BRW_BLENDFACTOR_ZERO;
}
If I read this correctly the color blending should be no-op anyway
((1.0 * src) + (0 * dst)) and should be therefore safe to drop anyway?
Naturally it is still unclear why it behaves as (src * src) instead:
Expected: 0.50 0.40 0.30
Observed: 0.250980 0.160784 0.090196
There is a note in the PRM saying Enabling LogicOp and ColorBufferBlending
at the same time is UNDEFINED. I don't know exactly what is this referring
to.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 14/16] radeonsi: We don't support indirect addressing of shader inputs/outputs
On Mon, 2014-01-27 at 12:03 +0100, Marek Olšák wrote: The function emit_fetch in radeon_setup_tgsi_llvm.c seems to implement indirect addressing of everything but constants. Ah, there it is, thanks. v2 of the patch only disallows indirect addressing of geometry shader inputs. -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 02/16] radeonsi: Initial geometry shader support
On Sam, 2014-01-25 at 02:21 +0100, Marek Olšák wrote: On Fri, Jan 24, 2014 at 10:19 PM, Marek Olšák mar...@gmail.com wrote: 1) Do we really have to have so much code inside #if...#endif? Can we always compile everything and just not set the pipe_context functions if LLVM 3.5 and the same for get_(shader_)param? You can even do it without the preprocessor, e.g. if (HAVE_LLVM = 0x0305) ... Okay, dropped most of them in the v2 patches. 2) Sooner or later we'll have GL_ARB_shader_storage_buffer_object, which adds shader read-write resources. Maybe it would be better to put the ring buffers in a new array of descriptors and leave the constant buffers with the READ-only usage. The new array of descriptors could later be used for OpenGL read-write resources in addition to being used for ring buffers. Actually, my original plan was to put stream-out buffers after OpenGL shader-storage buffers. We'll probably want to use the same array for OpenGL shader atomic counters as well. Makes sense, added patch 17 which puts the ring buffer descriptors together with the streamout buffer descriptors. 3) In si_init_gs_rings: - could you please use readable decimal numbers for specifying the sizes? Like 1024 * 1024 * ... [...] - isn't 64 MB too many for a ring buffer? I can write the numbers any way you like. :) But I just copied them from the corresponding r600g patches; I don't know yet how these numbers were derived, or what the constraints are for the ring buffer sizes. I'm trying to find out more about this. - could you please add an assertion to make sure the function is not called twice to prevent potential memory leaks Done in v2. 4) If the GS is disabled, GS_OUT_PRIM_TYPE should be compatible with the draw_info primitive for transform feedback to work properly. It was a requirement on R600-Evergreen. Not sure if it applies to SI too. Doesn't seem to make a difference, but I guess it can't hurt, done in v2. -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965/blorp: do not use unnecessary hw-blending support
On Tue, Jan 28, 2014 at 11:48:18AM +0200, Pohjolainen, Topi wrote:
On Mon, Jan 27, 2014 at 06:00:54PM -0800, Kenneth Graunke wrote:
On 01/27/2014 11:06 AM, Pohjolainen, Topi wrote:
On Mon, Jan 27, 2014 at 10:20:54AM -0800, Eric Anholt wrote:
Topi Pohjolainen topi.pohjolai...@intel.com writes:
This is really not needed as blorp blit programs already sample
XRGB normally and get alpha channel set to 1.0 automatically by
the sampler engine. This is simply copied directly to the payload
of the render target write message and hence there is no need for
any additional blending support from the pixel processing pipeline.
Fixes recently modified piglit test gl-3.2-layered-rendering-blit
on IVB. No regressions on IVB.
What about when you have a RGB-but-not-alpha gl format that's been
promoted to an ARGB Mesa and BRW surface format? I don't think blorp's
samplers have any overrides going on there.
I relied on the restriction that only blits from RGBX to RGBA and vice
versa are allowed. Otherwise the formats must match.
I think Eric's right. Technically, it works for BlitFramebuffer because
of what you say...but...we allow nearly arbitrary format conversions for
CopyTexSubImage today, so I think dropping this could break things
there. Plus, we hope to add that for BlitFramebuffer too (it's trivial).
So, I think this code may need to stay after all...sorry for the confusion.
This is fine by me, I'd rather understand it fully before changing it anyway.
Further observation I made is that if I left just the alpha channel blending
in place and removed the color blending than the test case passes also:
diff --git a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
b/src/mesa/drivers/dri/i96
index 90b9fbb..959ed05 100644
--- a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
@@ -262,14 +262,10 @@ gen6_blorp_emit_blend_state(struct brw_context *brw,
if (params-src.mt
_mesa_get_format_bits(params-dst.mt-format, GL_ALPHA_BITS) 0
_mesa_get_format_bits(params-src.mt-format, GL_ALPHA_BITS) == 0) {
- blend-blend0.blend_enable = 1;
blend-blend0.ia_blend_enable = 1;
- blend-blend0.blend_func = BRW_BLENDFUNCTION_ADD;
blend-blend0.ia_blend_func = BRW_BLENDFUNCTION_ADD;
- blend-blend0.source_blend_factor = BRW_BLENDFACTOR_SRC_COLOR;
- blend-blend0.dest_blend_factor = BRW_BLENDFACTOR_ZERO;
blend-blend0.ia_source_blend_factor = BRW_BLENDFACTOR_ONE;
blend-blend0.ia_dest_blend_factor = BRW_BLENDFACTOR_ZERO;
}
Reading the PRM more carefully I now get the impression that the independent
alpha channel blending is just a _special_ case of the color buffer blending
and cannot be used alone - this is why you had that no-op color component
blending there in the first place, I guess. I effectively did the same thing
as the original patch of mine - disabled the blending altogether.
If I read this correctly the color blending should be no-op anyway
((1.0 * src) + (0 * dst)) and should be therefore safe to drop anyway?
Naturally it is still unclear why it behaves as (src * src) instead:
Expected: 0.50 0.40 0.30
Observed: 0.250980 0.160784 0.090196
There is a note in the PRM saying Enabling LogicOp and ColorBufferBlending
at the same time is UNDEFINED. I don't know exactly what is this referring
to.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] loader: do not print the pci id on release builds
Ignore this patch, I had it completely wrong. I'll send a proper solution in a moment. -Emil On 23/01/14 18:03, Emil Velikov wrote: Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- src/loader/loader.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/loader/loader.c b/src/loader/loader.c index a5bd769..a6dc40c 100644 --- a/src/loader/loader.c +++ b/src/loader/loader.c @@ -307,9 +307,11 @@ loader_get_driver_for_fd(int fd, unsigned driver_types) } out: +#ifdef DEBUG log_(driver ? _LOADER_INFO : _LOADER_WARNING, pci id for fd %d: %04x:%04x, driver %s, fd, vendor_id, chip_id, driver); +#endif return driver; } ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] What use do swap interval 1 and OML_sync_control divisor and remainder have?
Hi Ian and Jason On Mon, 27 Jan 2014 12:26:23 -0700 Ian Romanick i...@freedesktop.org wrote: On 01/24/2014 04:32 AM, Pekka Paalanen wrote: Hi, I am investigating what kind of Wayland protocol extensions would be needed to support proper presentation timing. Looking at existing works, I am wondering about two things whether they have any real use. Where is swap interval (e.g. eglSwapInterval) greater than one useful? Intervals 0 and 1 I understand, and Mesa EGL Wayland already supports those. But when would you like to make your framerate a fraction of the display's? There are a number of theoretical uses, but I don't know that we've ever seen any in the wild. One is video playback. You likely want 30fps there. I would hope that no video player will use swap interval as a means of target timing, because the buffer queueing protocol I'm planning is supposed to be superior for accurately timed video presentation. The protocol will also be usable with EGL provided content, if the EGL implementation can cope with buffers being reserved by the display server for longer than usual. Imagine that you have a game that only needs 30fps to be playable. When you're running on battery, you may want the system to throttle you to a lower framerate to save battery. You could also have a game that can always hit at least 30fps, but sometimes it may go higher. Using a swap interval of 2 gives the the game a consistent framerate. Sometimes that is better. 120Hz monitors. These are good points. I can easily come up with a counter argument for at least the first and last, how something else would be better than the application itself setting swap interval. I can even see a compositor user option limit this window/application to a fraction of the refresh rate Hz which is already possible in Wayland without any protocol changes. Whether that would be a good UI is another question. After this and the discussion on #xorg-devel, I am now fairly confident, that I do not have to design for swap interval 1 support at this time. If such support really is needed, I see two possibilies already. - Use the buffer queueing protocol to target presentation at last realized presentation time plus two frame periods. EGL internally could keep on waiting for the usual frame callback (a Wayland protocol feature) like it does now for swap interval = 1. Enabling this occurred to me yesterday, and I have it in my buffer queue plans now. - Add a new request alike wl_surface.frame, which has a parameter of how many output refresh cycles should pass since the last presentation before this presentation is executed. When are the target-MSC related remainder and divisor parameters as defined in the GLX_OML_sync_control useful? Why does also X11 Present protocol include remainder and divisor? X11 Present has it to support GLX_OML_sync_control. I believe that GLX_OML_sync_control has it to support playback of content on monitors that aren't 60Hz. There used to be these things called CRTs, and some of them had wonkey refresh rates... like 72Hz. But the divisor and remainder apply only if the original target-MSC is missed, causing the presentation to be postponed to a later point in time determined by matching the modulus of MSC. I still don't really understand when that was useful, or how it was even used. Are you saying that these were used to pretend that the monitor refresh rate was something lower than what it really was? Did that really work better than just presenting the content update at the earliest possible refresh? On Fri, 24 Jan 2014 12:27:11 -0600 Jason Ekstrand ja...@jlekstrand.net wrote: On Jan 24, 2014 6:32 AM, Pekka Paalanen ppaala...@gmail.com wrote: GLX_OML_sync_control defines that for interlaced displays MSC is incremented for each field. With divisor and remainder you could then target only top or bottom fields. Is that useful, and do we care about interlaced displays anymore? I think we do. In particular, we should care about TV set-top boxes. Even though most TVs are LCD, DLP, or similar, hdmi does support interlacing and it is still used (particularly in HDTV). I have no idea what implications this has for a present extension, but I think we could still handle it in a sane way without going for MSC. Right, there was quite some discussion on #xorg-devel about interlacing. All that lead me to write down the following in my notes: Supporting interlaced material and displays is punted for a later extension. Presumably the protocol supporting interlaced content would be as simple as having an extra wl_surface-like request to say on which of the two fields the content should be displayed first. The field designation would be an additional restriction on when a content update should initially hit the screen. I.e. if both field and target timestamp are given, both conditions must pass. This means that giving a field may delay the
[Mesa-dev] [PATCH 1/3] loader: print WARNING and FATAL messages using the default logger
Lower values are used for more severe cases.
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
src/loader/loader.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/loader/loader.c b/src/loader/loader.c
index 6d179a1..6b60ce7 100644
--- a/src/loader/loader.c
+++ b/src/loader/loader.c
@@ -80,7 +80,7 @@
static void default_logger(int level, const char *fmt, ...)
{
- if (level = _LOADER_WARNING) {
+ if (level = _LOADER_WARNING) {
va_list args;
va_start(args, fmt);
vfprintf(stderr, fmt, args);
--
1.8.5.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/3] loader: misc patches
Hi list, A few small patches on the infamous loader topic. The first two are cosmetic - they make sure that messages is higher severity (although defined by lower numbers) are printed, and promoting the pci id printout to DEBUG. The last patch covers unfortunate regression, where we would try to include dlfcn.h on platforms that are lacking it (Windows). -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] loader: include dlfcn.h when building with HAVE_LIBUDEV
The code depending on the definitions is already wrapped in the same conditional so go ahead and wrap the include. Otherwise we'll brake compilation on platforms that are missing the header. Add assert.h in there as well, as it is introduced and used in the same fashon. Cc: Eric Anholt e...@anholt.net Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74122 Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- src/loader/loader.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/loader/loader.c b/src/loader/loader.c index 5a36423..626046a 100644 --- a/src/loader/loader.c +++ b/src/loader/loader.c @@ -67,8 +67,10 @@ #include stdarg.h #include stdio.h #include string.h +#ifdef HAVE_LIBUDEV #include assert.h #include dlfcn.h +#endif #include loader.h #ifndef __NOT_HAVE_DRM_H -- 1.8.5.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] loader: do not print the pci id during normal operation
Spamming the pci id is not beneficial. Make sure it's printed only when needed. v2: Change severity to _LOADER_DEBUG, rather than removing the message. Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- src/loader/loader.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/loader/loader.c b/src/loader/loader.c index 6b60ce7..5a36423 100644 --- a/src/loader/loader.c +++ b/src/loader/loader.c @@ -348,7 +348,7 @@ loader_get_driver_for_fd(int fd, unsigned driver_types) } out: - log_(driver ? _LOADER_INFO : _LOADER_WARNING, + log_(driver ? _LOADER_DEBUG : _LOADER_WARNING, pci id for fd %d: %04x:%04x, driver %s\n, fd, vendor_id, chip_id, driver); return driver; -- 1.8.5.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Correct test for depth parameter for checking if dimension is legal
Okay if we make this the subject? mesa: Allow depth = 0 parameter for TexImage3D. Sure, that is fine and more succinct. -Kevin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965/blorp: do not use unnecessary hw-blending support
On Tue, Jan 28, 2014 at 11:48:18AM +0200, Pohjolainen, Topi wrote:
On Mon, Jan 27, 2014 at 06:00:54PM -0800, Kenneth Graunke wrote:
On 01/27/2014 11:06 AM, Pohjolainen, Topi wrote:
On Mon, Jan 27, 2014 at 10:20:54AM -0800, Eric Anholt wrote:
Topi Pohjolainen topi.pohjolai...@intel.com writes:
This is really not needed as blorp blit programs already sample
XRGB normally and get alpha channel set to 1.0 automatically by
the sampler engine. This is simply copied directly to the payload
of the render target write message and hence there is no need for
any additional blending support from the pixel processing pipeline.
Fixes recently modified piglit test gl-3.2-layered-rendering-blit
on IVB. No regressions on IVB.
What about when you have a RGB-but-not-alpha gl format that's been
promoted to an ARGB Mesa and BRW surface format? I don't think blorp's
samplers have any overrides going on there.
I relied on the restriction that only blits from RGBX to RGBA and vice
versa are allowed. Otherwise the formats must match.
I think Eric's right. Technically, it works for BlitFramebuffer because
of what you say...but...we allow nearly arbitrary format conversions for
CopyTexSubImage today, so I think dropping this could break things
there. Plus, we hope to add that for BlitFramebuffer too (it's trivial).
So, I think this code may need to stay after all...sorry for the confusion.
This is fine by me, I'd rather understand it fully before changing it anyway.
Further observation I made is that if I left just the alpha channel blending
in place and removed the color blending than the test case passes also:
diff --git a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
b/src/mesa/drivers/dri/i96
index 90b9fbb..959ed05 100644
--- a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
@@ -262,14 +262,10 @@ gen6_blorp_emit_blend_state(struct brw_context *brw,
if (params-src.mt
_mesa_get_format_bits(params-dst.mt-format, GL_ALPHA_BITS) 0
_mesa_get_format_bits(params-src.mt-format, GL_ALPHA_BITS) == 0) {
- blend-blend0.blend_enable = 1;
blend-blend0.ia_blend_enable = 1;
- blend-blend0.blend_func = BRW_BLENDFUNCTION_ADD;
blend-blend0.ia_blend_func = BRW_BLENDFUNCTION_ADD;
- blend-blend0.source_blend_factor = BRW_BLENDFACTOR_SRC_COLOR;
- blend-blend0.dest_blend_factor = BRW_BLENDFACTOR_ZERO;
blend-blend0.ia_source_blend_factor = BRW_BLENDFACTOR_ONE;
blend-blend0.ia_dest_blend_factor = BRW_BLENDFACTOR_ZERO;
}
If I read this correctly the color blending should be no-op anyway
((1.0 * src) + (0 * dst)) and should be therefore safe to drop anyway?
Naturally it is still unclear why it behaves as (src * src) instead:
Expected: 0.50 0.40 0.30
Observed: 0.250980 0.160784 0.090196
There is a note in the PRM saying Enabling LogicOp and ColorBufferBlending
at the same time is UNDEFINED. I don't know exactly what is this referring
to.
These logic operations are controlled by the blend state as well and they are
always disabled in the blorp setup.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] egl/dri2/android: free driver_name in dri2_initialize_android error path
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- src/egl/drivers/dri2/platform_android.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/egl/drivers/dri2/platform_android.c b/src/egl/drivers/dri2/platform_android.c index 4a201c8..e149a4b 100644 --- a/src/egl/drivers/dri2/platform_android.c +++ b/src/egl/drivers/dri2/platform_android.c @@ -722,6 +722,8 @@ cleanup_screen: dri2_dpy-core-destroyScreen(dri2_dpy-dri_screen); cleanup_driver: dlclose(dri2_dpy-driver); +cleanup_driver_name: + free(dri2_dpy-driver_name); cleanup_device: close(dri2_dpy-fd); cleanup_display: -- 1.8.5.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965/blorp: do not use unnecessary hw-blending support
On Tue, Jan 28, 2014 at 11:48:18AM +0200, Pohjolainen, Topi wrote:
On Mon, Jan 27, 2014 at 06:00:54PM -0800, Kenneth Graunke wrote:
On 01/27/2014 11:06 AM, Pohjolainen, Topi wrote:
On Mon, Jan 27, 2014 at 10:20:54AM -0800, Eric Anholt wrote:
Topi Pohjolainen topi.pohjolai...@intel.com writes:
This is really not needed as blorp blit programs already sample
XRGB normally and get alpha channel set to 1.0 automatically by
the sampler engine. This is simply copied directly to the payload
of the render target write message and hence there is no need for
any additional blending support from the pixel processing pipeline.
Fixes recently modified piglit test gl-3.2-layered-rendering-blit
on IVB. No regressions on IVB.
What about when you have a RGB-but-not-alpha gl format that's been
promoted to an ARGB Mesa and BRW surface format? I don't think blorp's
samplers have any overrides going on there.
I relied on the restriction that only blits from RGBX to RGBA and vice
versa are allowed. Otherwise the formats must match.
I think Eric's right. Technically, it works for BlitFramebuffer because
of what you say...but...we allow nearly arbitrary format conversions for
CopyTexSubImage today, so I think dropping this could break things
there. Plus, we hope to add that for BlitFramebuffer too (it's trivial).
So, I think this code may need to stay after all...sorry for the confusion.
This is fine by me, I'd rather understand it fully before changing it anyway.
Further observation I made is that if I left just the alpha channel blending
in place and removed the color blending than the test case passes also:
diff --git a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
b/src/mesa/drivers/dri/i96
index 90b9fbb..959ed05 100644
--- a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
@@ -262,14 +262,10 @@ gen6_blorp_emit_blend_state(struct brw_context *brw,
if (params-src.mt
_mesa_get_format_bits(params-dst.mt-format, GL_ALPHA_BITS) 0
_mesa_get_format_bits(params-src.mt-format, GL_ALPHA_BITS) == 0) {
- blend-blend0.blend_enable = 1;
blend-blend0.ia_blend_enable = 1;
- blend-blend0.blend_func = BRW_BLENDFUNCTION_ADD;
blend-blend0.ia_blend_func = BRW_BLENDFUNCTION_ADD;
- blend-blend0.source_blend_factor = BRW_BLENDFACTOR_SRC_COLOR;
- blend-blend0.dest_blend_factor = BRW_BLENDFACTOR_ZERO;
blend-blend0.ia_source_blend_factor = BRW_BLENDFACTOR_ONE;
blend-blend0.ia_dest_blend_factor = BRW_BLENDFACTOR_ZERO;
}
If I read this correctly the color blending should be no-op anyway
((1.0 * src) + (0 * dst)) and should be therefore safe to drop anyway?
Naturally it is still unclear why it behaves as (src * src) instead:
Expected: 0.50 0.40 0.30
Observed: 0.250980 0.160784 0.090196
Well, I think I now understand it. We are setting the _multiplier_ of the
source as the source itself instead of just one. This passes the test and
makes sense to me at least:
diff --git a/src/mesa/drivers/dri/i965/gen6_blorp.cpp b/src/mesa/drivers/dri/i96
index 90b9fbb..4ddfc74 100644
--- a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
@@ -268,7 +268,7 @@ gen6_blorp_emit_blend_state(struct brw_context *brw,
blend-blend0.blend_func = BRW_BLENDFUNCTION_ADD;
blend-blend0.ia_blend_func = BRW_BLENDFUNCTION_ADD;
- blend-blend0.source_blend_factor = BRW_BLENDFACTOR_SRC_COLOR;
+ blend-blend0.source_blend_factor = BRW_BLENDFACTOR_ONE;
blend-blend0.dest_blend_factor = BRW_BLENDFACTOR_ZERO;
blend-blend0.ia_source_blend_factor = BRW_BLENDFACTOR_ONE;
blend-blend0.ia_dest_blend_factor = BRW_BLENDFACTOR_ZERO;
There is a note in the PRM saying Enabling LogicOp and ColorBufferBlending
at the same time is UNDEFINED. I don't know exactly what is this referring
to.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965/blorp: do not use unnecessary hw-blending support
On Tue, Jan 28, 2014 at 02:20:47PM +0200, Pohjolainen, Topi wrote:
On Tue, Jan 28, 2014 at 11:48:18AM +0200, Pohjolainen, Topi wrote:
On Mon, Jan 27, 2014 at 06:00:54PM -0800, Kenneth Graunke wrote:
On 01/27/2014 11:06 AM, Pohjolainen, Topi wrote:
On Mon, Jan 27, 2014 at 10:20:54AM -0800, Eric Anholt wrote:
Topi Pohjolainen topi.pohjolai...@intel.com writes:
This is really not needed as blorp blit programs already sample
XRGB normally and get alpha channel set to 1.0 automatically by
the sampler engine. This is simply copied directly to the payload
of the render target write message and hence there is no need for
any additional blending support from the pixel processing pipeline.
Fixes recently modified piglit test gl-3.2-layered-rendering-blit
on IVB. No regressions on IVB.
What about when you have a RGB-but-not-alpha gl format that's been
promoted to an ARGB Mesa and BRW surface format? I don't think blorp's
samplers have any overrides going on there.
I relied on the restriction that only blits from RGBX to RGBA and vice
versa are allowed. Otherwise the formats must match.
I think Eric's right. Technically, it works for BlitFramebuffer because
of what you say...but...we allow nearly arbitrary format conversions for
CopyTexSubImage today, so I think dropping this could break things
there. Plus, we hope to add that for BlitFramebuffer too (it's trivial).
So, I think this code may need to stay after all...sorry for the
confusion.
This is fine by me, I'd rather understand it fully before changing it
anyway.
Further observation I made is that if I left just the alpha channel blending
in place and removed the color blending than the test case passes also:
diff --git a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
b/src/mesa/drivers/dri/i96
index 90b9fbb..959ed05 100644
--- a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
@@ -262,14 +262,10 @@ gen6_blorp_emit_blend_state(struct brw_context *brw,
if (params-src.mt
_mesa_get_format_bits(params-dst.mt-format, GL_ALPHA_BITS) 0
_mesa_get_format_bits(params-src.mt-format, GL_ALPHA_BITS) == 0) {
- blend-blend0.blend_enable = 1;
blend-blend0.ia_blend_enable = 1;
- blend-blend0.blend_func = BRW_BLENDFUNCTION_ADD;
blend-blend0.ia_blend_func = BRW_BLENDFUNCTION_ADD;
- blend-blend0.source_blend_factor = BRW_BLENDFACTOR_SRC_COLOR;
- blend-blend0.dest_blend_factor = BRW_BLENDFACTOR_ZERO;
blend-blend0.ia_source_blend_factor = BRW_BLENDFACTOR_ONE;
blend-blend0.ia_dest_blend_factor = BRW_BLENDFACTOR_ZERO;
}
If I read this correctly the color blending should be no-op anyway
((1.0 * src) + (0 * dst)) and should be therefore safe to drop anyway?
Naturally it is still unclear why it behaves as (src * src) instead:
Expected: 0.50 0.40 0.30
Observed: 0.250980 0.160784 0.090196
Well, I think I now understand it. We are setting the _multiplier_ of the
source as the source itself instead of just one. This passes the test and
makes sense to me at least:
diff --git a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
b/src/mesa/drivers/dri/i96
index 90b9fbb..4ddfc74 100644
--- a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
@@ -268,7 +268,7 @@ gen6_blorp_emit_blend_state(struct brw_context *brw,
blend-blend0.blend_func = BRW_BLENDFUNCTION_ADD;
blend-blend0.ia_blend_func = BRW_BLENDFUNCTION_ADD;
- blend-blend0.source_blend_factor = BRW_BLENDFACTOR_SRC_COLOR;
+ blend-blend0.source_blend_factor = BRW_BLENDFACTOR_ONE;
blend-blend0.dest_blend_factor = BRW_BLENDFACTOR_ZERO;
blend-blend0.ia_source_blend_factor = BRW_BLENDFACTOR_ONE;
blend-blend0.ia_dest_blend_factor = BRW_BLENDFACTOR_ZERO;
And I think we need additionally the following to take care of the cases
mentioned by Eric where the alpha is not set to 1.0 by the sampler. There
we need to get destination alpha fixed to 1.0 regardless of the value returned
by the sampler engine for the source. Does this make any sense?
diff --git a/src/mesa/drivers/dri/i965/gen6_blorp.cpp b/src/mesa/drivers/dri/i96
index 4ddfc74..ca903fd 100644
--- a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
@@ -270,7 +270,7 @@ gen6_blorp_emit_blend_state(struct brw_context *brw,
blend-blend0.source_blend_factor = BRW_BLENDFACTOR_ONE;
blend-blend0.dest_blend_factor = BRW_BLENDFACTOR_ZERO;
- blend-blend0.ia_source_blend_factor = BRW_BLENDFACTOR_ONE;
+ blend-blend0.ia_source_blend_factor = BRW_BLENDFACTOR_CONST_ALPHA;
blend-blend0.ia_dest_blend_factor = BRW_BLENDFACTOR_ZERO;
}
@@ -291,6 +291,8 @@ gen6_blorp_emit_cc_state(struct brw_context *brw,
Re: [Mesa-dev] [PATCH 17/17] radeonsi; Put GS ring buffer descriptors with streamout buffer descriptors
For the series:
Reviewed-by: Marek Olšák marek.ol...@amd.com
Marek
On Tue, Jan 28, 2014 at 10:46 AM, Michel Dänzer mic...@daenzer.net wrote:
From: Michel Dänzer michel.daen...@amd.com
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
src/gallium/drivers/radeonsi/si_descriptors.c | 93
---
src/gallium/drivers/radeonsi/si_pipe.h| 6 +-
src/gallium/drivers/radeonsi/si_shader.c | 22 ---
src/gallium/drivers/radeonsi/si_shader.h | 72 +++--
src/gallium/drivers/radeonsi/si_state.h | 6 +-
5 files changed, 115 insertions(+), 84 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c
b/src/gallium/drivers/radeonsi/si_descriptors.c
index 2a54fcb..9078c6c 100644
--- a/src/gallium/drivers/radeonsi/si_descriptors.c
+++ b/src/gallium/drivers/radeonsi/si_descriptors.c
@@ -516,7 +516,7 @@ void si_set_ring_buffer(struct pipe_context *ctx, uint
shader, uint slot,
unsigned element_size, unsigned index_stride)
{
struct si_context *sctx = (struct si_context *)ctx;
- struct si_buffer_resources *buffers = sctx-const_buffers[shader];
+ struct si_buffer_resources *buffers = sctx-rw_buffers[shader];
if (shader = SI_NUM_SHADERS)
return;
@@ -608,9 +608,9 @@ static void si_set_streamout_targets(struct pipe_context
*ctx,
unsigned append_bitmask)
{
struct si_context *sctx = (struct si_context *)ctx;
- struct si_buffer_resources *buffers = sctx-streamout_buffers;
+ struct si_buffer_resources *buffers =
sctx-rw_buffers[PIPE_SHADER_VERTEX];
unsigned old_num_targets = sctx-b.streamout.num_targets;
- unsigned i;
+ unsigned i, bufidx;
/* Streamout buffers must be bound in 2 places:
* 1) in VGT by setting the VGT_STRMOUT registers
@@ -622,12 +622,14 @@ static void si_set_streamout_targets(struct
pipe_context *ctx,
/* Set the shader resources.*/
for (i = 0; i num_targets; i++) {
+ bufidx = SI_RW_SO + i;
+
if (targets[i]) {
struct pipe_resource *buffer = targets[i]-buffer;
uint64_t va = r600_resource_va(ctx-screen, buffer);
/* Set the descriptor. */
- uint32_t *desc = buffers-desc_data[i];
+ uint32_t *desc = buffers-desc_data[bufidx];
desc[0] = va;
desc[1] = S_008F04_BASE_ADDRESS_HI(va 32);
desc[2] = 0x;
@@ -637,25 +639,29 @@ static void si_set_streamout_targets(struct
pipe_context *ctx,
S_008F0C_DST_SEL_W(V_008F0C_SQ_SEL_W);
/* Set the resource. */
- pipe_resource_reference(buffers-buffers[i], buffer);
+ pipe_resource_reference(buffers-buffers[bufidx],
+ buffer);
r600_context_bo_reloc(sctx-b, sctx-b.rings.gfx,
(struct r600_resource*)buffer,
buffers-shader_usage);
- buffers-desc.enabled_mask |= 1 i;
+ buffers-desc.enabled_mask |= 1 bufidx;
} else {
/* Clear the descriptor and unset the resource. */
- memset(buffers-desc_data[i], 0, sizeof(uint32_t) *
4);
- pipe_resource_reference(buffers-buffers[i], NULL);
- buffers-desc.enabled_mask = ~(1 i);
+ memset(buffers-desc_data[bufidx], 0,
+ sizeof(uint32_t) * 4);
+ pipe_resource_reference(buffers-buffers[bufidx],
+ NULL);
+ buffers-desc.enabled_mask = ~(1 bufidx);
}
- buffers-desc.dirty_mask |= 1 i;
+ buffers-desc.dirty_mask |= 1 bufidx;
}
for (; i old_num_targets; i++) {
+ bufidx = SI_RW_SO + i;
/* Clear the descriptor and unset the resource. */
- memset(buffers-desc_data[i], 0, sizeof(uint32_t) * 4);
- pipe_resource_reference(buffers-buffers[i], NULL);
- buffers-desc.enabled_mask = ~(1 i);
- buffers-desc.dirty_mask |= 1 i;
+ memset(buffers-desc_data[bufidx], 0, sizeof(uint32_t) * 4);
+ pipe_resource_reference(buffers-buffers[bufidx], NULL);
+ buffers-desc.enabled_mask = ~(1 bufidx);
+ buffers-desc.dirty_mask |= 1 bufidx;
}
si_update_descriptors(sctx, buffers-desc);
@@ -712,25 +718,37 @@ static void si_invalidate_buffer(struct
[Mesa-dev] [PATCH] r600g, radeonsi: Don't set resource_create in r600_common_screen_init()
From: Tom Stellard thomas.stell...@amd.com
r600g and radeonsi have different implementations of resource_create.
https://bugs.freedesktop.org/show_bug.cgi?id=74139
---
src/gallium/drivers/radeon/r600_pipe_common.c | 1 -
src/gallium/drivers/radeonsi/si_pipe.c| 1 +
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c
b/src/gallium/drivers/radeon/r600_pipe_common.c
index f40adf2..98164f0 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.c
+++ b/src/gallium/drivers/radeon/r600_pipe_common.c
@@ -598,7 +598,6 @@ bool r600_common_screen_init(struct r600_common_screen
*rscreen,
rscreen-b.fence_finish = r600_fence_finish;
rscreen-b.fence_reference = r600_fence_reference;
rscreen-b.fence_signalled = r600_fence_signalled;
- rscreen-b.resource_create = r600_resource_create_common;
rscreen-b.resource_destroy = u_resource_destroy_vtbl;
if (rscreen-info.has_uvd) {
diff --git a/src/gallium/drivers/radeonsi/si_pipe.c
b/src/gallium/drivers/radeonsi/si_pipe.c
index 2249f79..5182ec1 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -413,6 +413,7 @@ struct pipe_screen *radeonsi_screen_create(struct
radeon_winsys *ws)
sscreen-b.b.get_param = si_get_param;
sscreen-b.b.get_shader_param = si_get_shader_param;
sscreen-b.b.is_format_supported = si_is_format_supported;
+ sscreen-b.b.resource_create = r600_resource_create_common;
if (!r600_common_screen_init(sscreen-b, ws)) {
FREE(sscreen);
--
1.8.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g, radeonsi: Don't set resource_create in r600_common_screen_init()
Reviewed-by: Marek Olšák marek.ol...@amd.com
Marek
On Tue, Jan 28, 2014 at 4:01 PM, Tom Stellard t...@stellard.net wrote:
From: Tom Stellard thomas.stell...@amd.com
r600g and radeonsi have different implementations of resource_create.
https://bugs.freedesktop.org/show_bug.cgi?id=74139
---
src/gallium/drivers/radeon/r600_pipe_common.c | 1 -
src/gallium/drivers/radeonsi/si_pipe.c| 1 +
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c
b/src/gallium/drivers/radeon/r600_pipe_common.c
index f40adf2..98164f0 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.c
+++ b/src/gallium/drivers/radeon/r600_pipe_common.c
@@ -598,7 +598,6 @@ bool r600_common_screen_init(struct r600_common_screen
*rscreen,
rscreen-b.fence_finish = r600_fence_finish;
rscreen-b.fence_reference = r600_fence_reference;
rscreen-b.fence_signalled = r600_fence_signalled;
- rscreen-b.resource_create = r600_resource_create_common;
rscreen-b.resource_destroy = u_resource_destroy_vtbl;
if (rscreen-info.has_uvd) {
diff --git a/src/gallium/drivers/radeonsi/si_pipe.c
b/src/gallium/drivers/radeonsi/si_pipe.c
index 2249f79..5182ec1 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -413,6 +413,7 @@ struct pipe_screen *radeonsi_screen_create(struct
radeon_winsys *ws)
sscreen-b.b.get_param = si_get_param;
sscreen-b.b.get_shader_param = si_get_shader_param;
sscreen-b.b.is_format_supported = si_is_format_supported;
+ sscreen-b.b.resource_create = r600_resource_create_common;
if (!r600_common_screen_init(sscreen-b, ws)) {
FREE(sscreen);
--
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
[Mesa-dev] [Bug 74098] [clover] adaptor.hpp:47:16: error: function cannot return function type 'std::vectorunsigned long, std::allocatorunsigned long (unsigned long, unsigned long)'
https://bugs.freedesktop.org/show_bug.cgi?id=74098 Francisco Jerez curroje...@riseup.net changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTOURBUG -- 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 74098] [clover] adaptor.hpp:47:16: error: function cannot return function type 'std::vectorunsigned long, std::allocatorunsigned long (unsigned long, unsigned long)'
https://bugs.freedesktop.org/show_bug.cgi?id=74098 --- Comment #3 from Francisco Jerez curroje...@riseup.net --- Created attachment 92932 -- https://bugs.freedesktop.org/attachment.cgi?id=92932action=edit clover_workaround_clang_function_argument_deduction.patch I suspect this is a clang bug. In the function call to map(F f, ...) in util/factor.hpp:115 it deduces the template argument F as a function type instead of an lvalue-reference to function type, as it should be because the provided argument is an lvalue. Would you mind bringing this to the LLVM bug tracker? For the meantime you can use the attached work-around to get it to build with clang. -- 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] can we have gl_framebuffer _NumColorDrawBuffers = 1 and all the entries in the array NULL
If drivers has issues dealing with NULL cbufs, then we could have the state trackers using dummy rendertargets. But probably it's more efficent to handle in the pipe drivers. My concern is that this ends up being a rare condition in practice, and that pipe drivers end up having a lot of bugs handling it. So even though it's less efficient, its more piece of mind there won't be exploits here. Jose - Original Message - Hi Dave, Yes, it's legal. Drivers should handle NULL color buffer bindings and there is a test for it: https://urldefense.proofpoint.com/v1/url?u=http://cgit.freedesktop.org/piglit/commit/?id%3Dff2398a4e3c4805e7d1bea38f4ae6f9811b42edek=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=5XVVc6HPMBuXPEd7Z6EjczrwK%2FCkUYUHD7AIExEK7Yw%3D%0As=cf39ce3ddd6d3fcabef701dc10f6ee54e18d1a6ad1cc03348ca3e2e668c93697 I fixed it just recently. That said, I think we don't have to bind NULL color buffers which appear at the end of the color buffer list. Marek On Tue, Jan 28, 2014 at 7:33 AM, Dave Airlie airl...@gmail.com wrote: I've just been playing with layered rendering on r600g and the depth test Marek wrote, and I noticed I'm sometimes getting a gallium framebuffer state with 1 cbuf but no defined cbuf, this comes direct from the Mesa state in the gl_framebuffer object, is this legal? Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=5XVVc6HPMBuXPEd7Z6EjczrwK%2FCkUYUHD7AIExEK7Yw%3D%0As=4792592da81e92e70acddc2f776823be927fec5c5f31a517b6e62e7eca068050 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=5XVVc6HPMBuXPEd7Z6EjczrwK%2FCkUYUHD7AIExEK7Yw%3D%0As=4792592da81e92e70acddc2f776823be927fec5c5f31a517b6e62e7eca068050 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 74098] [clover] adaptor.hpp:47:16: error: function cannot return function type 'std::vectorunsigned long, std::allocatorunsigned long (unsigned long, unsigned long)'
https://bugs.freedesktop.org/show_bug.cgi?id=74098 Vinson Lee v...@freedesktop.org changed: What|Removed |Added See Also||http://llvm.org/bugs/show_b ||ug.cgi?id=18645 -- 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] egl/dri2/android: free driver_name in dri2_initialize_android error path
On Tue, Jan 28, 2014 at 11:59:14AM +, Emil Velikov wrote:
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
src/egl/drivers/dri2/platform_android.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/egl/drivers/dri2/platform_android.c
b/src/egl/drivers/dri2/platform_android.c
index 4a201c8..e149a4b 100644
--- a/src/egl/drivers/dri2/platform_android.c
+++ b/src/egl/drivers/dri2/platform_android.c
@@ -722,6 +722,8 @@ cleanup_screen:
dri2_dpy-core-destroyScreen(dri2_dpy-dri_screen);
cleanup_driver:
dlclose(dri2_dpy-driver);
+cleanup_driver_name:
+ free(dri2_dpy-driver_name);
cleanup_device:
close(dri2_dpy-fd);
cleanup_display:
--
1.8.5.2
The driver name still leaks when this failure is hit:
if (!dri2_load_driver(dpy)) {
err = DRI2: failed to load driver;
goto cleanup_device;
}
To fix the leak, I think that failure block should goto
cleanup_driver_name.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] loader: fix running with --disable-egl builds
Dave Airlie airl...@gmail.com writes: From: Dave Airlie airl...@redhat.com I sometimes build without EGL just for speed purposes, however it no longer finds my drivers when I do due to the HAVE_LIBUDEV defines being wrong. Reviewed-by: Eric Anholt e...@anholt.net pgpAk2C4zftCK.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/3] loader: misc patches
Emil Velikov emil.l.veli...@gmail.com writes: Hi list, A few small patches on the infamous loader topic. The first two are cosmetic - they make sure that messages is higher severity (although defined by lower numbers) are printed, and promoting the pci id printout to DEBUG. The last patch covers unfortunate regression, where we would try to include dlfcn.h on platforms that are lacking it (Windows). These are: Reviewed-by: Eric Anholt e...@anholt.net pgp2oPb3m56pt.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Generate correct error code in glDrawBuffers()
On 01/27/2014 07:29 PM, Anuj Phogat wrote:
OpenGL 3.3 spec expects GL_INVALID_OPERATION:
For both the default framebuffer and framebuffer objects, the
constants FRONT, BACK, LEFT, RIGHT, and FRONT AND BACK are not
valid in the bufs array passed to DrawBuffers, and will result
in the error INVALID OPERATION.
But OpenGL 4.0 spec changed the error code to GL_INVALID_ENUM:
For both the default framebuffer and framebuffer objects, the
constants FRONT, BACK, LEFT, RIGHT, and FRONT_AND_BACK are not
valid in the bufs array passed to DrawBuffers, and will result
in the error INVALID_ENUM.
At the very least the spec quotation in the code needs to be updated
with the 4.0 reference. Right now the comment still says
INVALID_OPERATION. The comment should also say, Previous versions of
the spec say INVALID_OPERATION, but the conformance tests expect
INVALID_ENUM.
This patch changes the behaviour to match OpenGL 4.0 spec
Fixes Khronos OpenGL CTS draw_buffers_api.test.
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
---
src/mesa/main/buffers.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/buffers.c b/src/mesa/main/buffers.c
index 2bdbf41..cdae7c5 100644
--- a/src/mesa/main/buffers.c
+++ b/src/mesa/main/buffers.c
@@ -369,7 +369,7 @@ _mesa_DrawBuffers(GLsizei n, const GLenum *buffers)
* table 4.4.
*/
if (_mesa_bitcount(destMask[output]) 1) {
-_mesa_error(ctx, GL_INVALID_OPERATION,
glDrawBuffersARB(buffer));
+_mesa_error(ctx, GL_INVALID_ENUM, glDrawBuffersARB(buffer));
return;
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH RFC 07/11] glsl: add SSA infrastructure
On 22 January 2014 09:16, Connor Abbott cwabbo...@gmail.com wrote:
This patch introduces all the changes to the IR that are necessary for
representing programs in the SSA form. This consists of a new variable
mode, the SSA temporary, which is guarenteed to be written to exactly
once, and classes to represent phi nodes in the IR.
In the current code, variables are first declared using an ir_variable
instruction inserted into the instruction stream, and then every
dereference will point to the ir_variable declared earlier. SSA
temporaries, however, do not work this way. Instead, the variable
is declared when it is assigned. That is, the variable is owned by
the one and only instruction where it is defined.
In SSA, phi nodes may exist at the beginning of any join nodes, or
basic blocks with more than one predecessor. In our IR, this can happen
in one of three places:
- After an if statement, where the then branch and the else branch
converge.
- At the beginning of a loop, which can be reached from either before
the loop (on the first iteration), the end of the loop (when we get to
the end of the loop and jump back to the beginning), or any continue
statement.
- At the end of a loop, which can be reached from any break statement
within the loop.
Accordingly, there are three different types of phi nodes: if phi nodes,
phi nodes at the beginning of a loop, and phi nodes at the end of a
loop, all of which derive from the ir_phi base class.
---
src/glsl/ir.cpp| 56 +++
src/glsl/ir.h | 196
-
src/glsl/ir_clone.cpp | 147 ---
src/glsl/ir_hierarchical_visitor.cpp | 36 +
src/glsl/ir_hierarchical_visitor.h | 11 ++
src/glsl/ir_hv_accept.cpp | 55 ++-
src/glsl/ir_print_visitor.cpp | 196
-
src/glsl/ir_print_visitor.h| 15 ++
src/glsl/ir_validate.cpp | 158 +++-
src/glsl/ir_visitor.h | 8 +
src/mesa/drivers/dri/i965/brw_fs.h | 4 +
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 28
src/mesa/drivers/dri/i965/brw_vec4.h | 4 +
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 24 +++
src/mesa/program/ir_to_mesa.cpp| 28
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 29
16 files changed, 956 insertions(+), 39 deletions(-)
diff --git a/src/glsl/ir.cpp b/src/glsl/ir.cpp
index 1a36bd6..f1ded80 100644
--- a/src/glsl/ir.cpp
+++ b/src/glsl/ir.cpp
@@ -1229,6 +1229,37 @@ ir_loop::ir_loop()
}
+ir_phi::ir_phi()
+{
+ this-dest = NULL;
+}
Rather than have a no-argument constructor for ir_phi that sets this-dest
to NULL, and then have the derived classes set dest to the appropriate
value, let's just do:
ir_phi::ir_phi(ir_variable *dest)
: dest(dest)
{
}
Then in the derived classes we can just pass dest on through, e.g.:
ir_phi_if::ir_phi_if(ir_variable *dest, ir_variable *if_src,
ir_variable *else_src)
: ir_phi(dest), if_src(if_src), else_src(else_src)
{
this-ir_type = ir_type_phi_if;
}
+
+
+ir_phi_if::ir_phi_if(ir_variable *dest, ir_variable *if_src,
+ir_variable *else_src)
+ : if_src(if_src), else_src(else_src)
+{
+ this-ir_type = ir_type_phi_if;
+ this-dest = dest;
+}
+
+
+ir_phi_loop_begin::ir_phi_loop_begin(ir_variable* dest, ir_variable*
enter_src,
+ir_variable* repeat_src)
+ : enter_src(enter_src), repeat_src(repeat_src)
+{
+ this-ir_type = ir_type_phi_loop_begin;
+ this-dest = dest;
+}
+
+
+ir_phi_loop_end::ir_phi_loop_end(ir_variable *dest)
+{
+ this-ir_type = ir_type_phi_loop_end;
+ this-dest = dest;
+}
+
+
ir_dereference_variable::ir_dereference_variable(ir_variable *var)
{
assert(var != NULL);
@@ -1554,6 +1585,9 @@ ir_variable::ir_variable(const struct glsl_type
*type, const char *name,
this-data.max_array_access = 0;
this-data.atomic.buffer_index = 0;
this-data.atomic.offset = 0;
+ this-ssa_assignment = NULL;
+ this-ssa_phi = NULL;
+ this-ssa_call = NULL;
if (type != NULL) {
if (type-base_type == GLSL_TYPE_SAMPLER)
@@ -1722,12 +1756,19 @@ steal_memory(ir_instruction *ir, void *new_ctx)
{
ir_variable *var = ir-as_variable();
ir_constant *constant = ir-as_constant();
+ ir_dereference_variable *deref = ir-as_dereference_variable();
+ ir_phi *phi = ir-as_phi();
+ ir_phi_loop_begin *phi_loop_begin = ir-as_phi_loop_begin();
+ ir_phi_loop_end *phi_loop_end = ir-as_phi_loop_end();
if (var != NULL var-constant_value != NULL)
steal_memory(var-constant_value, ir);
if (var != NULL var-constant_initializer != NULL)
steal_memory(var-constant_initializer, ir);
+ if
Re: [Mesa-dev] [PATCH 00/12] ARB_fragment_layer_viewport for i965
On 01/24/2014 11:51 PM, Chris Forbes wrote: This series adds support for ARB_fragment_layer_viewport on i965 Gen7, in core contexts [the same conditions as for ARB_viewport_array being exposed]. This is another tiny piece of GL4.3, allowing the GS- [or with AMD_vertex_shader_*, VS- ] written values of gl_Layer and gl_ViewportIndex to be read by the fragment shader. Note that there are a few oddities in the spec, which I've assumed hopefully reasonable corrections for: - Dependencies section specifies that ARB_geometry_shader4 is required, but should probably be 'geometry shaders are required', or perhaps 'GL 3.2 or ARB_geometry_shader4 is required'. - In the description of gl_Layer's behavior, there is a stray reference to `gl_Value` which should be `gl_Layer`. - The extension doesn't list a new define for shaders to test for presence. I've assumed the usual pattern in 6/12. Thanks for reporting these. I've submitted a spec bug and a patch. ___ 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 07/12] glsl: Add gl_Layer and gl_ViewportIndex builtins to fragment shader
Patches 1-7 are
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
On 01/24/2014 11:51 PM, Chris Forbes wrote:
Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
src/glsl/builtin_variables.cpp | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/glsl/builtin_variables.cpp b/src/glsl/builtin_variables.cpp
index d6bc3c0..bb499fa 100644
--- a/src/glsl/builtin_variables.cpp
+++ b/src/glsl/builtin_variables.cpp
@@ -864,6 +864,11 @@ builtin_variable_generator::generate_fs_special_vars()
if (state-ARB_gpu_shader5_enable) {
add_system_value(SYSTEM_VALUE_SAMPLE_MASK_IN, array(int_t, 1),
gl_SampleMaskIn);
}
+
+ if (state-ARB_fragment_layer_viewport_enable) {
+ add_input(VARYING_SLOT_LAYER, int_t, gl_Layer);
+ add_input(VARYING_SLOT_VIEWPORT, int_t, gl_ViewportIndex);
+ }
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 0/7] i965/gen7 instanced GS support for ARB_gpu_shader5
v2: * Convert gl_InvocationID to a system value No piglit regressions on HSW. MESA_EXTENSION_OVERRIDE=GL_ARB_gpu_shader5 allows piglit arb_gpu_shader5/execution/invocation-id-basic.shader_test to pass. There are known issues with invalid layout qualifiers being allowed by the compiler. (Most are pre-existing bugs) Piglit master has tests highlighting these issues. Patches are available at: git://people.freedesktop.org/~jljusten/mesa gs-inv-id-v2 Jordan Justen (7): glsl: parse invocations layout qualifier for ARB_gpu_shader5 glsl/linker: produce gl_shader_program Geom.Invocations mesa: initialize gl_geometry_program Invocations field main/shaderapi: GL_GEOMETRY_SHADER_INVOCATIONS GetProgramiv support glsl: add gl_InvocationID variable for ARB_gpu_shader5 i965: support gl_InvocationID for gen7 i965: support instanced GS on gen7 src/glsl/ast.h| 15 ++-- src/glsl/ast_to_hir.cpp | 14 +++ src/glsl/ast_type.cpp | 11 + src/glsl/builtin_variables.cpp| 2 ++ src/glsl/glsl_parser.yy | 19 +- src/glsl/glsl_parser_extras.cpp | 2 ++ src/glsl/glsl_parser_extras.h | 3 +++ src/glsl/linker.cpp | 18 ++ src/mesa/drivers/dri/i965/brw_context.h | 2 ++ src/mesa/drivers/dri/i965/brw_defines.h | 6 + src/mesa/drivers/dri/i965/brw_vec4_gs.c | 2 ++ src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp | 30 +++ src/mesa/drivers/dri/i965/gen7_gs_state.c | 2 ++ src/mesa/main/mtypes.h| 4 +++ src/mesa/main/shaderapi.c | 7 ++ src/mesa/program/program.c| 1 + src/mesa/state_tracker/st_glsl_to_tgsi.cpp| 1 + src/mesa/state_tracker/st_program.c | 1 + 18 files changed, 132 insertions(+), 8 deletions(-) -- 1.8.5.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 1/7] glsl: parse invocations layout qualifier for ARB_gpu_shader5
_mesa_glsl_parse_state::gs_invocations will store the
invocation count.
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
src/glsl/ast.h| 15 +--
src/glsl/ast_to_hir.cpp | 14 ++
src/glsl/ast_type.cpp | 11 +++
src/glsl/glsl_parser.yy | 19 ++-
src/glsl/glsl_parser_extras.h | 3 +++
5 files changed, 59 insertions(+), 3 deletions(-)
diff --git a/src/glsl/ast.h b/src/glsl/ast.h
index 0bda28d..abe9190 100644
--- a/src/glsl/ast.h
+++ b/src/glsl/ast.h
@@ -460,6 +460,11 @@ struct ast_type_qualifier {
unsigned prim_type:1;
unsigned max_vertices:1;
/** \} */
+
+ /** \name Layout qualifiers for GL_ARB_gpu_shader5 */
+ /** \{ */
+ unsigned invocations:1;
+ /** \} */
}
/** \brief Set of flags, accessed by name. */
q;
@@ -471,6 +476,9 @@ struct ast_type_qualifier {
/** Precision of the type (highp/medium/lowp). */
unsigned precision:2;
+ /** Geometry shader invocations for GL_ARB_gpu_shader5. */
+ int invocations;
+
/**
* Location specified via GL_ARB_explicit_attrib_location layout
*
@@ -977,8 +985,8 @@ public:
class ast_gs_input_layout : public ast_node
{
public:
- ast_gs_input_layout(const struct YYLTYPE locp, GLenum prim_type)
- : prim_type(prim_type)
+ ast_gs_input_layout(const struct YYLTYPE locp, const ast_type_qualifier
qual)
+ : prim_type(qual.prim_type), invocations(qual.invocations)
{
set_location(locp);
}
@@ -988,6 +996,9 @@ public:
private:
const GLenum prim_type;
+
+ /** Geometry shader invocations for GL_ARB_gpu_shader5. */
+ int invocations;
};
/*@}*/
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 1bfb4e5..45b1efd 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -5256,8 +5256,22 @@ ast_gs_input_layout::hir(exec_list *instructions,
return NULL;
}
+ /* Make sure all shader inputs specify the same number of invocations.
+*/
+ if ((state-gs_invocations != 0 this-invocations != 0)
+ state-gs_invocations != this-invocations) {
+ _mesa_glsl_error(loc, state,
+ different geometry shader invocation counts were
+specified (%d and %d),
+ state-gs_invocations, this-invocations
+ );
+ return NULL;
+ }
+
state-gs_input_prim_type_specified = true;
state-gs_input_prim_type = this-prim_type;
+ if (this-invocations != 0)
+ state-gs_invocations = this-invocations;
/* If any shader inputs occurred before this declaration and did not
* specify an array size, their size is determined now.
diff --git a/src/glsl/ast_type.cpp b/src/glsl/ast_type.cpp
index 637da0d..30213af 100644
--- a/src/glsl/ast_type.cpp
+++ b/src/glsl/ast_type.cpp
@@ -153,6 +153,17 @@ ast_type_qualifier::merge_qualifier(YYLTYPE *loc,
this-max_vertices = q.max_vertices;
}
+ if (q.flags.q.invocations) {
+ if (this-flags.q.invocations this-invocations != q.invocations) {
+_mesa_glsl_error(loc, state,
+ geometry shader set conflicting invocations
+ (%d and %d), this-invocations, q.invocations);
+return false;
+ }
+ this-invocations = q.invocations;
+ this-flags.q.invocations = 1;
+ }
+
if ((q.flags.i ubo_mat_mask.flags.i) != 0)
this-flags.i = ~ubo_mat_mask.flags.i;
if ((q.flags.i ubo_layout_mask.flags.i) != 0)
diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
index 928c57e..66fb3c3 100644
--- a/src/glsl/glsl_parser.yy
+++ b/src/glsl/glsl_parser.yy
@@ -1291,6 +1291,23 @@ layout_qualifier_id:
}
}
+ if (match_layout_qualifier(invocations, $1, state) == 0) {
+ $$.flags.q.invocations = 1;
+
+ if ($3 0) {
+_mesa_glsl_error( @3, state,
+ invalid invocations %d specified, $3);
+YYERROR;
+ } else {
+$$.invocations = $3;
+if (!state-ARB_gpu_shader5_enable) {
+ _mesa_glsl_error( @3, state,
+GL_ARB_gpu_shader5 invocations
+qualifier specified, $3);
+}
+ }
+ }
+
/* If the identifier didn't match any known layout identifiers,
* emit an error.
*/
@@ -2350,7 +2367,7 @@ layout_defaults:
case GL_LINES_ADJACENCY:
case GL_TRIANGLES:
case GL_TRIANGLES_ADJACENCY:
-$$ = new(ctx) ast_gs_input_layout(@1, $1.prim_type);
+$$ = new(ctx) ast_gs_input_layout(@1, $1);
break;
default:
_mesa_glsl_error(@1, state,
diff --git a/src/glsl/glsl_parser_extras.h b/src/glsl/glsl_parser_extras.h
index 8a4cbf1..f35df27 100644
--- a/src/glsl/glsl_parser_extras.h
+++
[Mesa-dev] [PATCH v2 3/7] mesa: initialize gl_geometry_program Invocations field
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com --- src/mesa/main/mtypes.h | 1 + src/mesa/main/shaderapi.c | 1 + src/mesa/program/program.c | 1 + src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 1 + src/mesa/state_tracker/st_program.c| 1 + 5 files changed, 5 insertions(+) diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h index 2d90b0a..2131fed 100644 --- a/src/mesa/main/mtypes.h +++ b/src/mesa/main/mtypes.h @@ -2138,6 +2138,7 @@ struct gl_geometry_program GLint VerticesIn; GLint VerticesOut; + GLint Invocations; GLenum InputType; /** GL_POINTS, GL_LINES, GL_LINES_ADJACENCY_ARB, GL_TRIANGLES, or GL_TRIANGLES_ADJACENCY_ARB */ GLenum OutputType; /** GL_POINTS, GL_LINE_STRIP or GL_TRIANGLE_STRIP */ diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c index 61ac0e3..a8336c9 100644 --- a/src/mesa/main/shaderapi.c +++ b/src/mesa/main/shaderapi.c @@ -1834,6 +1834,7 @@ _mesa_copy_linked_program_data(gl_shader_stage type, struct gl_geometry_program *dst_gp = (struct gl_geometry_program *) dst; dst_gp-VerticesIn = src-Geom.VerticesIn; dst_gp-VerticesOut = src-Geom.VerticesOut; + dst_gp-Invocations = src-Geom.Invocations; dst_gp-InputType = src-Geom.InputType; dst_gp-OutputType = src-Geom.OutputType; dst-UsesClipDistanceOut = src-Geom.UsesClipDistance; diff --git a/src/mesa/program/program.c b/src/mesa/program/program.c index ea8eb0d..7686b31 100644 --- a/src/mesa/program/program.c +++ b/src/mesa/program/program.c @@ -530,6 +530,7 @@ _mesa_clone_program(struct gl_context *ctx, const struct gl_program *prog) struct gl_geometry_program *gpc = gl_geometry_program(clone); gpc-VerticesOut = gp-VerticesOut; gpc-InputType = gp-InputType; + gpc-Invocations = gp-Invocations; gpc-OutputType = gp-OutputType; } break; diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp index 0871dd0..235696e 100644 --- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp +++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp @@ -5180,6 +5180,7 @@ get_mesa_program(struct gl_context *ctx, stgp-Base.InputType = shader_program-Geom.InputType; stgp-Base.OutputType = shader_program-Geom.OutputType; stgp-Base.VerticesOut = shader_program-Geom.VerticesOut; + stgp-Base.Invocations = shader_program-Geom.Invocations; break; default: assert(!should not be reached); diff --git a/src/mesa/state_tracker/st_program.c b/src/mesa/state_tracker/st_program.c index cadbe17..f67b0fa 100644 --- a/src/mesa/state_tracker/st_program.c +++ b/src/mesa/state_tracker/st_program.c @@ -1087,6 +1087,7 @@ st_translate_geometry_program(struct st_context *st, ureg_property_gs_input_prim(ureg, stgp-Base.InputType); ureg_property_gs_output_prim(ureg, stgp-Base.OutputType); ureg_property_gs_max_vertices(ureg, stgp-Base.VerticesOut); + ureg_property_gs_invocations(ureg, stgp-Base.Invocations); if (stgp-glsl_to_tgsi) st_translate_program(st-ctx, -- 1.8.5.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 6/7] i965: support gl_InvocationID for gen7
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
src/mesa/drivers/dri/i965/brw_defines.h | 5 +
src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp | 24 ---
2 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_defines.h
b/src/mesa/drivers/dri/i965/brw_defines.h
index 7f4cd10..5fe1aba 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -1500,6 +1500,11 @@ enum brw_message_target {
# define BRW_GS_EDGE_INDICATOR_0 (1 8)
# define BRW_GS_EDGE_INDICATOR_1 (1 9)
+/* GS Thread Payload
+ */
+/* R0 */
+# define GEN7_GS_PAYLOAD_INSTANCE_ID_SHIFT 27
+
/* 3DSTATE_GS Output Vertex Size has an effective maximum of 62. It's
* counted in multiples of 16 bytes.
*/
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
index 40743cc..12e137c 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
@@ -51,9 +51,27 @@ vec4_gs_visitor::vec4_gs_visitor(struct brw_context *brw,
dst_reg *
vec4_gs_visitor::make_reg_for_system_value(ir_variable *ir)
{
- /* Geometry shaders don't use any system values. */
- assert(!Unreached);
- return NULL;
+ dst_reg *reg;
+ src_reg r0(retype(brw_vec4_grf(0, 0), BRW_REGISTER_TYPE_UD));
+
+ switch (ir-data.location) {
+ case SYSTEM_VALUE_INVOCATION_ID:
+ this-current_annotation = initialize gl_InvocationID;
+
+ reg = new(mem_ctx) dst_reg(this, ir-type);
+
+ /* Copy and shift gen7 instance id from R0 into the
+ * gl_InvocationID register.
+ */
+ emit(SHR(*reg, src_reg(r0),
+ (uint32_t) GEN7_GS_PAYLOAD_INSTANCE_ID_SHIFT));
+ break;
+ default:
+ assert(!not reached);
+ break;
+ }
+
+ return reg;
}
--
1.8.5.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 4/7] main/shaderapi: GL_GEOMETRY_SHADER_INVOCATIONS GetProgramiv support
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com --- src/mesa/main/shaderapi.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c index a8336c9..fb107d5 100644 --- a/src/mesa/main/shaderapi.c +++ b/src/mesa/main/shaderapi.c @@ -603,6 +603,12 @@ get_programiv(struct gl_context *ctx, GLuint program, GLenum pname, GLint *param if (check_gs_query(ctx, shProg)) *params = shProg-Geom.VerticesOut; return; + case GL_GEOMETRY_SHADER_INVOCATIONS: + if (!has_core_gs) + break; + if (check_gs_query(ctx, shProg)) + *params = shProg-Geom.Invocations; + return; case GL_GEOMETRY_INPUT_TYPE: if (!has_core_gs) break; -- 1.8.5.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 5/7] glsl: add gl_InvocationID variable for ARB_gpu_shader5
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com --- src/glsl/builtin_variables.cpp | 2 ++ src/mesa/main/mtypes.h | 1 + 2 files changed, 3 insertions(+) diff --git a/src/glsl/builtin_variables.cpp b/src/glsl/builtin_variables.cpp index d6bc3c0..d9ed2db 100644 --- a/src/glsl/builtin_variables.cpp +++ b/src/glsl/builtin_variables.cpp @@ -782,6 +782,8 @@ builtin_variable_generator::generate_gs_special_vars() add_output(VARYING_SLOT_LAYER, int_t, gl_Layer); if (state-ARB_viewport_array_enable) add_output(VARYING_SLOT_VIEWPORT, int_t, gl_ViewportIndex); + if (state-ARB_gpu_shader5_enable) + add_system_value(SYSTEM_VALUE_INVOCATION_ID, int_t, gl_InvocationID); /* Although gl_PrimitiveID appears in tessellation control and tessellation * evaluation shaders, it has a different function there than it has in diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h index 2131fed..eff268c 100644 --- a/src/mesa/main/mtypes.h +++ b/src/mesa/main/mtypes.h @@ -2008,6 +2008,7 @@ typedef enum SYSTEM_VALUE_SAMPLE_ID, /** Fragment shader only */ SYSTEM_VALUE_SAMPLE_POS, /** Fragment shader only */ SYSTEM_VALUE_SAMPLE_MASK_IN, /** Fragment shader only */ + SYSTEM_VALUE_INVOCATION_ID, /** Geometry shader only */ SYSTEM_VALUE_MAX /** Number of values */ } gl_system_value; -- 1.8.5.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 7/7] i965: support instanced GS on gen7
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
src/mesa/drivers/dri/i965/brw_context.h | 2 ++
src/mesa/drivers/dri/i965/brw_defines.h | 1 +
src/mesa/drivers/dri/i965/brw_vec4_gs.c | 2 ++
src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp | 6 --
src/mesa/drivers/dri/i965/gen7_gs_state.c | 2 ++
5 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index 8d098e6..ade4458 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -639,6 +639,8 @@ struct brw_gs_prog_data
bool include_primitive_id;
+ int invocations;
+
/**
* True if the thread should be dispatched in DUAL_INSTANCE mode, false if
* it should be dispatched in DUAL_OBJECT mode.
diff --git a/src/mesa/drivers/dri/i965/brw_defines.h
b/src/mesa/drivers/dri/i965/brw_defines.h
index 5fe1aba..eaf6e8f 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -1478,6 +1478,7 @@ enum brw_message_target {
# define GEN7_GS_CONTROL_DATA_FORMAT_GSCTL_CUT 0
# define GEN7_GS_CONTROL_DATA_FORMAT_GSCTL_SID 1
# define GEN7_GS_CONTROL_DATA_HEADER_SIZE_SHIFT20
+# define GEN7_GS_INSTANCE_CONTROL_SHIFT15
# define GEN7_GS_DISPATCH_MODE_SINGLE (0 11)
# define GEN7_GS_DISPATCH_MODE_DUAL_INSTANCE (1 11)
# define GEN7_GS_DISPATCH_MODE_DUAL_OBJECT (2 11)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_gs.c
b/src/mesa/drivers/dri/i965/brw_vec4_gs.c
index abc181b..3c6393f 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_gs.c
+++ b/src/mesa/drivers/dri/i965/brw_vec4_gs.c
@@ -48,6 +48,8 @@ do_gs_prog(struct brw_context *brw,
c.prog_data.include_primitive_id =
(gp-program.Base.InputsRead VARYING_BIT_PRIMITIVE_ID) != 0;
+ c.prog_data.invocations = gp-program.Invocations;
+
/* Allocate the references to the uniforms that will end up in the
* prog_data associated with the compiled program, and which will be freed
* by the state cache.
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
index 12e137c..21dbc29 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
@@ -596,9 +596,11 @@ brw_gs_emit(struct brw_context *brw,
}
/* Compile the geometry shader in DUAL_OBJECT dispatch mode, if we can do
-* so without spilling.
+* so without spilling. If the GS invocations count 1, then we can't use
+* dual object mode.
*/
- if (likely(!(INTEL_DEBUG DEBUG_NO_DUAL_OBJECT_GS))) {
+ if (c-prog_data.invocations = 1 ||
+ likely(!(INTEL_DEBUG DEBUG_NO_DUAL_OBJECT_GS))) {
c-prog_data.dual_instanced_dispatch = false;
vec4_gs_visitor v(brw, c, prog, shader, mem_ctx, true /* no_spills */);
diff --git a/src/mesa/drivers/dri/i965/gen7_gs_state.c
b/src/mesa/drivers/dri/i965/gen7_gs_state.c
index d2ba354..b179d19 100644
--- a/src/mesa/drivers/dri/i965/gen7_gs_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_gs_state.c
@@ -153,6 +153,8 @@ upload_gs_state(struct brw_context *brw)
((brw-max_gs_threads - 1) max_threads_shift) |
(brw-gs.prog_data-control_data_header_size_hwords
GEN7_GS_CONTROL_DATA_HEADER_SIZE_SHIFT) |
+ ((brw-gs.prog_data-invocations - 1)
+ GEN7_GS_INSTANCE_CONTROL_SHIFT) |
(brw-gs.prog_data-dual_instanced_dispatch ?
GEN7_GS_DISPATCH_MODE_DUAL_INSTANCE :
GEN7_GS_DISPATCH_MODE_DUAL_OBJECT) |
--
1.8.5.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 2/7] glsl/linker: produce gl_shader_program Geom.Invocations
Grab the parsed invocation count, check for consistency
during linking, and finally save the result in
gl_shader_program Geom.Invocations.
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
src/glsl/glsl_parser_extras.cpp | 2 ++
src/glsl/linker.cpp | 18 ++
src/mesa/main/mtypes.h | 2 ++
3 files changed, 22 insertions(+)
diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
index 87784ed..3e98966 100644
--- a/src/glsl/glsl_parser_extras.cpp
+++ b/src/glsl/glsl_parser_extras.cpp
@@ -1339,6 +1339,8 @@ set_shader_inout_layout(struct gl_shader *shader,
if (state-out_qualifier-flags.q.max_vertices)
shader-Geom.VerticesOut = state-out_qualifier-max_vertices;
+ shader-Geom.Invocations = state-gs_invocations;
+
if (state-gs_input_prim_type_specified) {
shader-Geom.InputType = state-gs_input_prim_type;
} else {
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 93b4754..800de0b 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -1206,6 +1206,7 @@ link_gs_inout_layout_qualifiers(struct gl_shader_program
*prog,
unsigned num_shaders)
{
linked_shader-Geom.VerticesOut = 0;
+ linked_shader-Geom.Invocations = 0;
linked_shader-Geom.InputType = PRIM_UNKNOWN;
linked_shader-Geom.OutputType = PRIM_UNKNOWN;
@@ -1259,6 +1260,18 @@ link_gs_inout_layout_qualifiers(struct gl_shader_program
*prog,
}
linked_shader-Geom.VerticesOut = shader-Geom.VerticesOut;
}
+
+ if (shader-Geom.Invocations != 0) {
+if (linked_shader-Geom.Invocations != 0
+linked_shader-Geom.Invocations != shader-Geom.Invocations) {
+ linker_error(prog, geometry shader defined with conflicting
+invocation count (%d and %d)\n,
+linked_shader-Geom.Invocations,
+shader-Geom.Invocations);
+ return;
+}
+linked_shader-Geom.Invocations = shader-Geom.Invocations;
+ }
}
/* Just do the intrastage - interstage propagation right now,
@@ -1285,6 +1298,11 @@ link_gs_inout_layout_qualifiers(struct gl_shader_program
*prog,
return;
}
prog-Geom.VerticesOut = linked_shader-Geom.VerticesOut;
+
+ if (linked_shader-Geom.Invocations == 0)
+ linked_shader-Geom.Invocations = 1;
+
+ prog-Geom.Invocations = linked_shader-Geom.Invocations;
}
/**
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 3d42a21..2d90b0a 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -2401,6 +2401,7 @@ struct gl_shader
*/
struct {
GLint VerticesOut;
+ GLint Invocations;
/**
* GL_POINTS, GL_LINES, GL_LINES_ADJACENCY, GL_TRIANGLES, or
* GL_TRIANGLES_ADJACENCY, or PRIM_UNKNOWN if it's not set in this
@@ -2599,6 +2600,7 @@ struct gl_shader_program
struct {
GLint VerticesIn;
GLint VerticesOut;
+ GLint Invocations;
GLenum InputType; /** GL_POINTS, GL_LINES, GL_LINES_ADJACENCY_ARB,
GL_TRIANGLES, or GL_TRIANGLES_ADJACENCY_ARB */
GLenum OutputType; /** GL_POINTS, GL_LINE_STRIP or GL_TRIANGLE_STRIP */
--
1.8.5.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 03/16] llvmpipe: Use alignment of 64 instead of 16 for buffer allocation
- Original Message -
From: Siavash Eliasi siavashser...@gmail.com
v2: Changed allocation alignment of llvmpipe_displaytarget_layout.
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
---
src/gallium/drivers/llvmpipe/lp_texture.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_texture.c
b/src/gallium/drivers/llvmpipe/lp_texture.c
index fe7b9a2..f601181 100644
--- a/src/gallium/drivers/llvmpipe/lp_texture.c
+++ b/src/gallium/drivers/llvmpipe/lp_texture.c
@@ -200,7 +200,7 @@ llvmpipe_displaytarget_layout(struct llvmpipe_screen
*screen,
lpr-base.bind,
lpr-base.format,
width, height,
- 16,
+ 64,
lpr-row_stride[0] );
if (lpr-dt == NULL)
@@ -261,7 +261,7 @@ llvmpipe_resource_create(struct pipe_screen *_screen,
* read/write always LP_RASTER_BLOCK_SIZE pixels, but the element
* offset doesn't need to be aligned to LP_RASTER_BLOCK_SIZE.
*/
- lpr-data = align_malloc(bytes + (LP_RASTER_BLOCK_SIZE - 1) * 4 *
sizeof(float), 16);
+ lpr-data = align_malloc(bytes + (LP_RASTER_BLOCK_SIZE - 1) * 4 *
sizeof(float), 64);
/*
* buffers don't really have stride but it's probably safer
* (for code doing same calculations for buffers and textures)
@@ -746,7 +746,7 @@ llvmpipe_get_texture_image_address(struct
llvmpipe_resource *lpr,
static void
alloc_image_data(struct llvmpipe_resource *lpr)
{
- uint alignment = MAX2(16, util_cpu_caps.cacheline);
+ uint alignment = MAX2(64, util_cpu_caps.cacheline);
uint level;
uint offset = 0;
--
1.8.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Reviewed-by: Jose Fonseca jfons...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/3] loader: misc patches
On 01/28/2014 02:35 AM, Emil Velikov wrote: Hi list, A few small patches on the infamous loader topic. The first two are cosmetic - they make sure that messages is higher severity (although defined by lower numbers) are printed, and promoting the pci id printout to DEBUG. The last patch covers unfortunate regression, where we would try to include dlfcn.h on platforms that are lacking it (Windows). -Emil Series is: Reviewed-by: Kenneth Graunke kenn...@whitecape.org Thanks for hiding the PCI ID print statement. signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] glsl: s/_NDEBUG/NDEBUG/
On 01/23/2014 10:03 AM, Emil Velikov wrote:
The former symbol is never defined within mesa. Based
it seems that the original intent was to use NDEBUG.
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
src/glsl/ir.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/glsl/ir.h b/src/glsl/ir.h
index 19e8383..e266328 100644
--- a/src/glsl/ir.h
+++ b/src/glsl/ir.h
@@ -471,7 +471,7 @@ public:
void reinit_interface_type(const struct glsl_type *type)
{
if (this-max_ifc_array_access != NULL) {
-#ifndef _NDEBUG
+#ifndef NDEBUG
/* Redeclaring gl_PerVertex is only allowed if none of the built-ins
* it defines have been accessed yet; so it's safe to throw away the
* old max_ifc_array_access pointer, since all of its values are
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH RFC 07/11] glsl: add SSA infrastructure
On 22 January 2014 09:16, Connor Abbott cwabbo...@gmail.com wrote:
diff --git a/src/glsl/ir_clone.cpp b/src/glsl/ir_clone.cpp
index cb732a5..7075579 100644
--- a/src/glsl/ir_clone.cpp
+++ b/src/glsl/ir_clone.cpp
@@ -40,7 +40,15 @@ ir_rvalue::clone(void *mem_ctx, struct hash_table *ht)
const
ir_variable *
ir_variable::clone(void *mem_ctx, struct hash_table *ht) const
{
- ir_variable *var = new(mem_ctx) ir_variable(this-type, this-name,
+ ir_variable *var;
+
+ if (ht) {
+ var = (ir_variable *)hash_table_find(ht, this);
+ if (var)
+return var;
+ }
Can you add a comment explaining why it's necessary to do a hashtable
lookup now? (I'm guessing it's because a phi node can refer to an SSA
temporary that occurs later in the instruction stream, and therefore when
we go to clone an SSA temporary variable, it's possible that we've already
cloned it, but I'm not 100% certain about that).
+
+ var = new(mem_ctx) ir_variable(this-type, this-name,
(ir_variable_mode)
this-data.mode);
Let's fix up this line to align the opening paren with the initial t in
this-type.
+
+ir_phi *
+ir_phi::clone(void *mem_ctx, struct hash_table *ht) const
+{
+ /* shouldn't get here */
+ assert(0);
+ return new(mem_ctx) ir_phi();
+}
There's no need to implement this function. If we leave it out (and leave
out the corresponding declaration of clone() in ir.h's declaration of the
ir_phi class), then ir_phi will be an abstract base class, and the compiler
will make sure we never instantiate it.
+static ir_phi_jump_src *
+clone_phi_jump_src(ir_phi_jump_src *src, void *mem_ctx, struct hash_table
*ht)
+{
+ ir_phi_jump_src *new_src = new(mem_ctx) ir_phi_jump_src();
+ new_src-src = src-src-clone(mem_ctx, ht);
+ new_src-jump = src-jump-clone(mem_ctx, ht);
+ return new_src;
Let's make a constructor for ir_phi_jump_src that takes src and jump as
arguments, so that we can just do:
return new(mem_ctx) ir_phi_jump_src(src-src-clone(mem_ctx, ht),
src-jump-clone(mem_ctx, ht));
+
+
+void
+ir_print_visitor::visit(ir_phi *ir)
+{
+ printf(error);
+}
I think if we make ir_phi an abstract base class (like I suggested earlier)
we can drop this function entirely, as well as all the other visit(class
ir_phi *) functions introduced in this patch.
+
+
+void
+ir_print_visitor::visit(ir_phi_if *ir)
+{
+ printf((phi\n);
For consistency with the class names, I'd prefer for this to be:
printf((phi_if\n);
+
+ indentation++;
+ indent();
+ ir-dest-accept(this);
+ printf(\n);
+
+ indent();
+ if (ir-if_src) {
+ printf(%s , unique_name(ir-if_src));
+ } else {
+ printf((undefined) );
+ }
+ if (ir-else_src) {
+ printf(%s), unique_name(ir-else_src));
+ } else {
+ printf((undefined)));
+ }
Would it be worth modifying unique_name() so that it returns (undefined)
if it's passed a null pointer? That would allow us to simplify the 10
lines above to:
printf(%s %s, unique_name(ir-if_src), unique_name(ir-else_src));
As well as similar simplifications in the functions below.
+ indentation--;
+}
+
+void
+ir_print_visitor::print_phi_jump_src(ir_phi_jump_src *src)
+{
+ printf((%s , unique_name(src-jump));
I think this is going to make the output IR difficult to follow, since it
won't be obvious that (break@1 ...) represents a phi node rather than a
break instruction. I'd recommend changing this to:
printf((phi_jump_src %s , unique_name(src-jump));
+ if (src-src) {
+ printf( %s)\n, unique_name(src-src));
+ } else {
+ printf( (undefined))\n);
+ }
+}
+
+void
+ir_print_visitor::visit(ir_phi_loop_begin *ir)
+{
+ printf((phi\n);
As with ir_phi_if, I'd recommend changing this to:
printf((phi_loop_begin\n);
A similar comment applies to ir_print_visitor::visit(ir_phi_loop_end *).
+
+ indentation++;
+ indent();
+ ir-dest-accept(this);
+ printf(\n);
+
+ indent();
+ if (ir-enter_src) {
+ printf(%s , unique_name(ir-enter_src));
+ } else {
+ printf((undefined) );
+ }
+ if (ir-repeat_src) {
+ printf(%s\n, unique_name(ir-repeat_src));
+ } else {
+ printf((undefined)\n);
+ }
+
+ foreach_list(n, ir-continue_srcs) {
+ ir_phi_jump_src *src = (ir_phi_jump_src *) n;
+ indent();
+ print_phi_jump_src(src);
+ }
+
+ indentation--;
+ indent();
+ printf());
+}
+
+
+
+
+ir_visitor_status
+ir_validate::visit(ir_phi_loop_begin *ir)
+{
+ validate_phi_dest(ir, this-ht);
+
+ /*
+* note: ir_phi_loop_begin is a special case in that variables may be,
and in
+* fact normally are, defined *after* they are used in everything
except
+* enter_src
+*/
+
+ if (ir-enter_src) {
+ validate_var_use(ir-enter_src, this-ht, (void *) ir,
ir_phi_loop_begin);
+ }
+
Re: [Mesa-dev] glsl: vectorize pass probably needs to change types of scalar constants as well?
On Mon, Jan 27, 2014 at 10:28 PM, Aras Pranckevicius a...@unity3d.com wrote:
The new vectorization pass (added in 4bd6e0d7c69) properly changes types of
scalar dereferences. Doesn't it need to change types of scalar constants as
well?
Consider this shader:
uniform sampler2D maintex;
uniform float factor;
varying vec2 uv;
void main() {
vec4 c = texture2D(maintex, uv);
vec4 r;
r.x = max(0.123, c.x);
r.y = max(0.123, c.y);
r.z = min(c.z, factor);
r.w = min(c.w, factor);
gl_FragColor = r;
}
Scalar dereference gets properly vectorized into:
r.zw = min (c.zw, vec2(factor));
However scalar constant is vectorized into:
r.xy = max (0.123, c.xy); // type mismatch
It seems that handling ir_constant same way as ir_dereference inside
opt_vectorize.cpp rewrite_swizzle() should fix the issue.
--
Aras Pranckevičius
work: http://unity3d.com
home: http://aras-p.info
Thanks Aras. I think you're right. I'll try to look into this today
unless you beat me to it.
Thanks,
Matt
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Sandybridge ARB_gpu_shader5 gather bits
Hi Ian, Replying to IRC: idr chrisf: You know if SNB can do the enhanced textureGatherOffset modes from ARB_gpu_shader5? Sandybridge has per-slot offset support (gather4_po) but lacks: * Channel select bits in the message header * Any ability to sample from a multi-component texture. Only red/alpha formats are supported. * Depth compare (although you can emulate this since there's no filtering) That's enough that ARB_gpu_shader5 is impossible. There are also bugs in even what ARB_texture_gather requires, which is why it's not enabled: * gather4 on UINT/SINT only returns good data for two of the texels. Getting all four texels requires a second gather4 with an adjusted offset. I had a workaround written for this which works for 2D surfaces, but the sampler can't do offsets with cubes. I stopped short of doing cubemapping in the shader by hand, although it's not too awful. :) This also reduces the available range of offsets for these formats to -7..7, whereas the spec requires -8..7. An alternative workaround might be to treat the surface as something completely different (UNORM, and possibly switching to FLOAT for large formats?) and reinterpret the bits in the shader. The workaround would require custom surface state, some format bits in the sampler key, and some format-dependent unmangling of the bits back into the proper int/uint value, but would allow proper offset range, hardware cube sampling, etc. Ken and I discussed a third possibility when I was working on this, of converting the gather to four texelFetch or texelFetchOffset, but that's messy and still requires a lot of special handling for cubes etc. -- Chris ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH 3/5] glcpp: Set extension defines after resolving the GLSL version.
Matt Turner matts...@gmail.com writes: Unless there are objections, I think we should probably skip this patch going to the stable branches. Thanks, Matt. I've updated my .cherry-ignore file so that I won't accidentally pick this one over to the stable branch. To everyone, Matt's protocol here is a good one. If you ever realize that a patch previously nominated for the stable branch has a problem, please let me know so that we don't introduce known regressions into a stable release. Here are two good mechanisms for doing this, (and doing both is a great idea): 1. Email a note to mesa-stable@ to warn the stable maintainer 2. Commit a test to piglit that fails if the regression is present -Carl -- carl.d.wo...@intel.com pgp4Bmz41lmqb.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 09/12] i965/fs: Add support for gl_ViewportIndex input
On 01/26/2014 02:31 PM, Chris Forbes wrote:
Ian,
I'd thought about that a bit while building this, and struggled to
find cases where this was observable in a defined fragment shader
execution.
Yeah, I've been thinking about it a bit too.
The ARB_viewport_array spec says:
If the value of the viewport index is outside the range zero to the value
of MAX_VIEWPORTS minus one, the results of the viewport
transformation are undefined.
There is similar language for layer.
It seems absurd to carry around an extra real slot which only adds any
value in a case where we're not required to be performing any
particular fragment shader invocations at all.
That's the rub. If there are no invocations, then we shouldn't have to
carry it. If there are invocations... We can test that with a simple
fragment shader:
#version 150
#extension GL_ARB_fragment_layer_viewport: require
in int viewport_index;
layout (binding = 0, offset = 0) uniform atomic_uint invocations;
layout (binding = 0, offset = 4) uniform atomic_uint matches;
void main()
{
atomicCounterIncrement(invocations);
if (gl_ViewportIndex == viewport_index)
atomicCounterIncrement(matches);
}
If invocations and matches match after rendering, we should be good.
I can see cases where an out-of-range gl_Layer *almost* makes sense --
only interactions with the framebuffer are undefined, so you could
have no framebuffer writes, no fragment tests, and then do something
based on gl_Layer with atomics, images, or shader storage buffers. But
it's still a mad thing to do.
Do you know the rationale for having this language in the spec?
I believe DX has a similar requirement. I'm not sure if there's some
additional method by which out-of-range values can be observed.
In any case, happy to park this for now -- it just looked like an easy
win, and it turns out it's not quite.
-- Chris
On Mon, Jan 27, 2014 at 5:59 AM, Ian Romanick i...@freedesktop.org wrote:
On 01/24/2014 10:51 PM, Chris Forbes wrote:
Same idea as gl_Layer -- this is delivered in part of R0.0.
NAK.
The spec says:
... the fragment stage will read the same value written by
the geometry stage, even if that value is out of range.
If the geometry shader passes 0xDEADBEEF, the fragment shader is
supposed to read 0xDEADBEEF. That won't fit in the 4-bits available in
R0.0. That's why I didn't implement this when I did the
GL_ARB_viewport_array work. :)
I think I want to provide an Intel extension that provides the value the
hardware will actually use. I'm thinking take the existing ARB spec and
replace that one sentence with
If the value written by the geometry stage is out of range, the
value read by the fragment stage is undefined.
We would also replace the next sentence with:
If a fragment shader contains a static access to gl_ViewportIndex,
it will NOT count against the implementation defined limit for the
maximum number of inputs to the fragment stage.
There are probably a couple other little edits too.
I'm also concerned about interactions with this extension and SSO.
Since we have to assign a real slot for gl_ViewportIndex, a separable
geometry shader that writes it will always have to write to the shadow
copy. If the separable fragment shader doesn't read it, the varying
layouts may not match. :(
Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 22 ++
src/mesa/drivers/dri/i965/brw_fs.h | 1 +
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 2 ++
3 files changed, 25 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 17d5237..e32133b 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -1294,6 +1294,28 @@ fs_visitor::emit_layer_setup(ir_variable *ir)
return reg;
}
+fs_reg *
+fs_visitor::emit_viewport_index_setup(ir_variable *ir)
+{
+ /* The value for gl_ViewportIndex is provided in bits 30:27 of R0.0. */
+
+ /* These bits are actually present on all Gen4+ h/w, but until GS is
enabled
+* on earlier platforms we don't expect to get here on anything earlier
+* than Gen7.
+*/
+ assert(brw-gen = 7);
+
+ this-current_annotation = gl_ViewportIndex;
+ fs_reg *reg = new(this-mem_ctx) fs_reg(this, ir-type);
+ fs_reg temp = fs_reg(this, glsl_type::int_type);
+ emit(BRW_OPCODE_SHR, temp,
+ fs_reg(retype(brw_vec1_grf(0, 0), BRW_REGISTER_TYPE_D)),
+ fs_reg(brw_imm_d(27)));
+ emit(BRW_OPCODE_AND, *reg, temp,
+ fs_reg(brw_imm_d(0x0f)));
+ return reg;
+}
+
fs_reg
fs_visitor::fix_math_operand(fs_reg src)
{
diff --git a/src/mesa/drivers/dri/i965/brw_fs.h
b/src/mesa/drivers/dri/i965/brw_fs.h
index e04c341..e47fff4 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.h
+++
Re: [Mesa-dev] can we have gl_framebuffer _NumColorDrawBuffers = 1 and all the entries in the array NULL
Yes, it's legal. Drivers should handle NULL color buffer bindings and there is a test for it: http://cgit.freedesktop.org/piglit/commit/?id=ff2398a4e3c4805e7d1bea38f4ae6f9811b42ede I fixed it just recently. Ah okay on r600g this is broken due to how we work out the CB_TARGET_MASK, the kernel cs checker gives out, I'll fixup the patch I wrote and send it. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 02/16] radeonsi: Initial geometry shader support
3) In si_init_gs_rings: - could you please use readable decimal numbers for specifying the sizes? Like 1024 * 1024 * ... [...] - isn't 64 MB too many for a ring buffer? I can write the numbers any way you like. :) But I just copied them from the corresponding r600g patches; I don't know yet how these numbers were derived, or what the constraints are for the ring buffer sizes. I'm trying to find out more about this. I don't think they are derived from anything yet, they were just big numbers Vadim used, I suppose we can calculate them from max vertices for the geom shader * number of outputs * size of each output. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] mesa: Ensure that transform feedback refers to the correct program.
Paul Berry stereotype...@gmail.com writes:
Previous to this patch, the _mesa_{Begin,Resume}TransformFeedback
functions were using ctx-Shader.CurrentProgram[MESA_SHADER_VERTEX]
I see that this commit was nominated for the stable branch when it was
committed.
However, it appears to depend at least on commit b22146dc714 which is on
master, but is not on the 10.0 branch. So this patch cannot be applied
as-is to 10.0.
My current inclination is to simply drop this patch from the list of
candidates for 10.0. If you think differently, please recommend an
alternate plan.
-Carl
pgpgf7TFlcKKu.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Ignore 'centroid' interpolation qualifier in case of persample shading
On Wed, Jan 22, 2014 at 3:54 PM, Anuj Phogat anuj.pho...@gmail.com wrote: I missed this change in commit f5cfb4a. It fixes the incorrect rendering caused in Dolphin Emulator. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73915 Cc: Markus wick wickmar...@web.de Capitalize his last name (and turn the Cc into a Tested-by?), and Reviewed-by: Matt Turner matts...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] mesa: Ensure that transform feedback refers to the correct program.
On 28 January 2014 13:15, Carl Worth cwo...@cworth.org wrote:
Paul Berry stereotype...@gmail.com writes:
Previous to this patch, the _mesa_{Begin,Resume}TransformFeedback
functions were using ctx-Shader.CurrentProgram[MESA_SHADER_VERTEX]
I see that this commit was nominated for the stable branch when it was
committed.
However, it appears to depend at least on commit b22146dc714 which is on
I think you mean 3b22146dc714 (mesa: Replace
ctx-Shader.Current{Vertex,Fragment,Geometry}Program with an array.).
master, but is not on the 10.0 branch. So this patch cannot be applied
as-is to 10.0.
My current inclination is to simply drop this patch from the list of
candidates for 10.0. If you think differently, please recommend an
alternate plan.
-Carl
(Also from IRC: cworth stereotype441: In my recent mail, I should have
included 43e77215b13 as well. (It's another patch I plan to drop from
stable unless you guide me differently.))
In principle we could make versions of these patches that don't depend on
commit 3b22146dc714, but I don't think it's worth it--the bugs I've fixed
in these patches are unlikely to arise until ARB_separate_shader_objects is
supported.
So yeah, I'm ok with dropping these two patches from the list of candidates
for 10.0.
I believe it was Ken who initially suggested marking these patches as
candidates for stable. Cc'ing him in case he wants to express a dissenting
opinion.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 09/12] i965/fs: Add support for gl_ViewportIndex input
Am 28.01.2014 21:45, schrieb Ian Romanick:
On 01/26/2014 02:31 PM, Chris Forbes wrote:
Ian,
I'd thought about that a bit while building this, and struggled to
find cases where this was observable in a defined fragment shader
execution.
Yeah, I've been thinking about it a bit too.
The ARB_viewport_array spec says:
If the value of the viewport index is outside the range zero to the value
of MAX_VIEWPORTS minus one, the results of the viewport
transformation are undefined.
There is similar language for layer.
It seems absurd to carry around an extra real slot which only adds any
value in a case where we're not required to be performing any
particular fragment shader invocations at all.
That's the rub. If there are no invocations, then we shouldn't have to
carry it. If there are invocations... We can test that with a simple
fragment shader:
#version 150
#extension GL_ARB_fragment_layer_viewport: require
in int viewport_index;
layout (binding = 0, offset = 0) uniform atomic_uint invocations;
layout (binding = 0, offset = 4) uniform atomic_uint matches;
void main()
{
atomicCounterIncrement(invocations);
if (gl_ViewportIndex == viewport_index)
atomicCounterIncrement(matches);
}
If invocations and matches match after rendering, we should be good.
I can see cases where an out-of-range gl_Layer *almost* makes sense --
only interactions with the framebuffer are undefined, so you could
have no framebuffer writes, no fragment tests, and then do something
based on gl_Layer with atomics, images, or shader storage buffers. But
it's still a mad thing to do.
Do you know the rationale for having this language in the spec?
I believe DX has a similar requirement. I'm not sure if there's some
additional method by which out-of-range values can be observed.
That is very much true and probably why it's in there. That said, d3d10
has a LOT of very well defined error behavior usually going way beyond
what OpenGL requires, to the point of being silly (but yes the tests
will test all of that error behavior).
For viewport, like GL, it also has the fs input value being the same as
gs output. Furthermore however, d3d10 also requires defined behavior for
vp indices out of range for vp transform (index is set to 0) - hence the
behavior of such an input in the fs is well defined and makes a bit more
sense probably with d3d10 than it does in GL. Not that I'd expect any
app outside whck to rely on that.
Roland
In any case, happy to park this for now -- it just looked like an easy
win, and it turns out it's not quite.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/7] dri2: Trust our own driver name lookup over the server's.
This patch could cause the i965 driver to not load if Mesa was built on a system without libudev devel present. For example on Fedora one should install systemd-devel before configuring and building Mesa drivers subsequent to this change. On Sun, Jan 26, 2014 at 4:02 PM, Keith Packard kei...@keithp.com wrote: Eric Anholt e...@anholt.net writes: This allows Mesa to choose to rename driver .sos (or split drivers), without needing a flag day with the corresponding 2D driver. Reviewed-by: Keith Packard kei...@keithp.com -- keith.pack...@intel.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH V2] mesa: Generate correct error code in glDrawBuffers()
OpenGL 3.3 spec expects GL_INVALID_OPERATION:
For both the default framebuffer and framebuffer objects, the
constants FRONT, BACK, LEFT, RIGHT, and FRONT AND BACK are not
valid in the bufs array passed to DrawBuffers, and will result
in the error INVALID OPERATION.
But OpenGL 4.0 spec changed the error code to GL_INVALID_ENUM:
For both the default framebuffer and framebuffer objects, the
constants FRONT, BACK, LEFT, RIGHT, and FRONT_AND_BACK are not
valid in the bufs array passed to DrawBuffers, and will result
in the error INVALID_ENUM.
This patch changes the behaviour to match OpenGL 4.0 spec
Fixes Khronos OpenGL CTS draw_buffers_api.test.
V2: Update the comment in code.
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
---
src/mesa/main/buffers.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/buffers.c b/src/mesa/main/buffers.c
index 2bdbf41..6cbce9d 100644
--- a/src/mesa/main/buffers.c
+++ b/src/mesa/main/buffers.c
@@ -360,16 +360,18 @@ _mesa_DrawBuffers(GLsizei n, const GLenum *buffers)
return;
}
- /* From the OpenGL 3.0 specification, page 259:
+ /* From the OpenGL 4.0 specification, page 256:
* For both the default framebuffer and framebuffer objects, the
* constants FRONT, BACK, LEFT, RIGHT, and FRONT_AND_BACK are not
* valid in the bufs array passed to DrawBuffers, and will result in
- * the error INVALID_OPERATION. This restriction is because these
+ * the error INVALID_ENUM. This restriction is because these
* constants may themselves refer to multiple buffers, as shown in
* table 4.4.
+ * Previous versions of the OpenGL specification say
INVALID_OPERATION,
+ * but the Khronos conformance tests expect INVALID_ENUM.
*/
if (_mesa_bitcount(destMask[output]) 1) {
-_mesa_error(ctx, GL_INVALID_OPERATION, glDrawBuffersARB(buffer));
+_mesa_error(ctx, GL_INVALID_ENUM, glDrawBuffersARB(buffer));
return;
}
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] mesa: Ensure that transform feedback refers to the correct program.
On 01/28/2014 01:26 PM, Paul Berry wrote:
On 28 January 2014 13:15, Carl Worth cwo...@cworth.org
mailto:cwo...@cworth.org wrote:
Paul Berry stereotype...@gmail.com
mailto:stereotype...@gmail.com writes:
Previous to this patch, the _mesa_{Begin,Resume}TransformFeedback
functions were using ctx-Shader.CurrentProgram[MESA_SHADER_VERTEX]
I see that this commit was nominated for the stable branch when it was
committed.
However, it appears to depend at least on commit b22146dc714 which is on
I think you mean 3b22146dc714 (mesa: Replace
ctx-Shader.Current{Vertex,Fragment,Geometry}Program with an array.).
master, but is not on the 10.0 branch. So this patch cannot be applied
as-is to 10.0.
My current inclination is to simply drop this patch from the list of
candidates for 10.0. If you think differently, please recommend an
alternate plan.
-Carl
(Also from IRC: cworth stereotype441: In my recent mail, I should have
included 43e77215b13 as well. (It's another patch I plan to drop from
stable unless you guide me differently.))
In principle we could make versions of these patches that don't depend
on commit 3b22146dc714, but I don't think it's worth it--the bugs I've
fixed in these patches are unlikely to arise until
ARB_separate_shader_objects is supported.
So yeah, I'm ok with dropping these two patches from the list of
candidates for 10.0.
I believe it was Ken who initially suggested marking these patches as
candidates for stable. Cc'ing him in case he wants to express a
dissenting opinion.
Given that we discovered the only use of shader is a NULL-check to
determine if it's GLSL or ARB programs...I don't think it's nearly as
important as I thought. I'd just drop it from stable.
signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH V2] mesa: Generate correct error code in glDrawBuffers()
On 01/28/2014 02:52 PM, Anuj Phogat wrote:
OpenGL 3.3 spec expects GL_INVALID_OPERATION:
For both the default framebuffer and framebuffer objects, the
constants FRONT, BACK, LEFT, RIGHT, and FRONT AND BACK are not
valid in the bufs array passed to DrawBuffers, and will result
in the error INVALID OPERATION.
But OpenGL 4.0 spec changed the error code to GL_INVALID_ENUM:
For both the default framebuffer and framebuffer objects, the
constants FRONT, BACK, LEFT, RIGHT, and FRONT_AND_BACK are not
valid in the bufs array passed to DrawBuffers, and will result
in the error INVALID_ENUM.
This patch changes the behaviour to match OpenGL 4.0 spec
Fixes Khronos OpenGL CTS draw_buffers_api.test.
V2: Update the comment in code.
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
---
src/mesa/main/buffers.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/buffers.c b/src/mesa/main/buffers.c
index 2bdbf41..6cbce9d 100644
--- a/src/mesa/main/buffers.c
+++ b/src/mesa/main/buffers.c
@@ -360,16 +360,18 @@ _mesa_DrawBuffers(GLsizei n, const GLenum *buffers)
return;
}
- /* From the OpenGL 3.0 specification, page 259:
+ /* From the OpenGL 4.0 specification, page 256:
* For both the default framebuffer and framebuffer objects, the
* constants FRONT, BACK, LEFT, RIGHT, and FRONT_AND_BACK are not
* valid in the bufs array passed to DrawBuffers, and will result
in
- * the error INVALID_OPERATION. This restriction is because these
+ * the error INVALID_ENUM. This restriction is because these
* constants may themselves refer to multiple buffers, as shown in
* table 4.4.
+ * Previous versions of the OpenGL specification say
INVALID_OPERATION,
+ * but the Khronos conformance tests expect INVALID_ENUM.
*/
if (_mesa_bitcount(destMask[output]) 1) {
-_mesa_error(ctx, GL_INVALID_OPERATION,
glDrawBuffersARB(buffer));
+_mesa_error(ctx, GL_INVALID_ENUM, glDrawBuffersARB(buffer));
return;
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallivm: fix opcode and function nesting
gallivm soa code supported only a single level of nesting for
control flow opcodes (if, switch, loops...) but the d3d10 spec
clearly states that those are nested within functions. To support
nesting of conditionals inside functions we need to store the
nesting data inside function contexts and keep a stack of those.
Furthermore we make sure that if nesting for subroutines is deeper
than 32 then we simply ignore all subsequent 'call' invocations.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi.h | 72 ++---
src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c | 377
2 files changed, 292 insertions(+), 157 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi.h
b/src/gallium/auxiliary/gallivm/lp_bld_tgsi.h
index 4f988b8..839ab85 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi.h
+++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi.h
@@ -260,49 +260,51 @@ struct lp_exec_mask {
LLVMTypeRef int_vec_type;
- LLVMValueRef cond_stack[LP_MAX_TGSI_NESTING];
- int cond_stack_size;
- LLVMValueRef cond_mask;
-
- /* keep track if break belongs to switch or loop */
- enum lp_exec_mask_break_type break_type_stack[LP_MAX_TGSI_NESTING];
- enum lp_exec_mask_break_type break_type;
+ LLVMValueRef exec_mask;
- struct {
- LLVMValueRef switch_val;
- LLVMValueRef switch_mask;
- LLVMValueRef switch_mask_default;
- boolean switch_in_default;
- unsigned switch_pc;
- } switch_stack[LP_MAX_TGSI_NESTING];
- int switch_stack_size;
- LLVMValueRef switch_val;
+ LLVMValueRef ret_mask;
+ LLVMValueRef cond_mask;
LLVMValueRef switch_mask; /* current switch exec mask */
- LLVMValueRef switch_mask_default; /* reverse of switch mask used for
default */
- boolean switch_in_default;/* if switch exec is currently in default
*/
- unsigned switch_pc; /* when used points to default or
endswitch-1 */
-
- LLVMBasicBlockRef loop_block;
LLVMValueRef cont_mask;
LLVMValueRef break_mask;
- LLVMValueRef break_var;
- struct {
- LLVMBasicBlockRef loop_block;
- LLVMValueRef cont_mask;
- LLVMValueRef break_mask;
- LLVMValueRef break_var;
- } loop_stack[LP_MAX_TGSI_NESTING];
- int loop_stack_size;
- LLVMValueRef ret_mask;
- struct {
+ struct function_ctx {
int pc;
LLVMValueRef ret_mask;
- } call_stack[LP_MAX_TGSI_NESTING];
- int call_stack_size;
- LLVMValueRef exec_mask;
- LLVMValueRef loop_limiter;
+ LLVMValueRef cond_stack[LP_MAX_TGSI_NESTING];
+ int cond_stack_size;
+
+ /* keep track if break belongs to switch or loop */
+ enum lp_exec_mask_break_type break_type_stack[LP_MAX_TGSI_NESTING];
+ enum lp_exec_mask_break_type break_type;
+
+ struct {
+ LLVMValueRef switch_val;
+ LLVMValueRef switch_mask;
+ LLVMValueRef switch_mask_default;
+ boolean switch_in_default;
+ unsigned switch_pc;
+ } switch_stack[LP_MAX_TGSI_NESTING];
+ int switch_stack_size;
+ LLVMValueRef switch_val;
+ LLVMValueRef switch_mask_default; /* reverse of switch mask used for
default */
+ boolean switch_in_default;/* if switch exec is currently in
default */
+ unsigned switch_pc; /* when used points to default or
endswitch-1 */
+
+ LLVMValueRef loop_limiter;
+ LLVMBasicBlockRef loop_block;
+ LLVMValueRef break_var;
+ struct {
+ LLVMBasicBlockRef loop_block;
+ LLVMValueRef cont_mask;
+ LLVMValueRef break_mask;
+ LLVMValueRef break_var;
+ } loop_stack[LP_MAX_TGSI_NESTING];
+ int loop_stack_size;
+
+ } *function_stack;
+ int function_stack_size;
};
struct lp_build_tgsi_inst_list
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
index f01b50c..52e1b51 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
@@ -66,6 +66,10 @@
#include lp_bld_sample.h
#include lp_bld_struct.h
+/* SM 4.0 says that subroutines can nest 32 deep and
+ * we need one more for our main function */
+#define LP_MAX_NUM_FUNCS 33
+
#define DUMP_GS_EMITS 0
/*
@@ -98,38 +102,108 @@ emit_dump_reg(struct gallivm_state *gallivm,
lp_build_print_value(gallivm, buf, value);
}
+static INLINE struct function_ctx *
+func_ctx(struct lp_exec_mask *mask)
+{
+ assert(mask-function_stack_size 0);
+ assert(mask-function_stack_size = LP_MAX_NUM_FUNCS);
+ return mask-function_stack[mask-function_stack_size - 1];
+}
-static void lp_exec_mask_init(struct lp_exec_mask *mask, struct
lp_build_context *bld)
+static INLINE boolean
+mask_has_loop(struct lp_exec_mask *mask)
{
- LLVMTypeRef int_type = LLVMInt32TypeInContext(bld-gallivm-context);
- LLVMBuilderRef builder = bld-gallivm-builder;
+ int i;
+ for (i = mask-function_stack_size - 1; i = 0; --i) {
+
Re: [Mesa-dev] [PATCH 4/7] dri2: Trust our own driver name lookup over the server's.
On 01/28/2014 02:51 PM, Mark Mueller wrote: This patch could cause the i965 driver to not load if Mesa was built on a system without libudev devel present. For example on Fedora one should install systemd-devel before configuring and building Mesa drivers subsequent to this change. I don't think so. loader_get_driver_for_fd should return NULL in that case, and the loader will fallback to the old behavior. On Sun, Jan 26, 2014 at 4:02 PM, Keith Packard kei...@keithp.com mailto:kei...@keithp.com wrote: Eric Anholt e...@anholt.net mailto:e...@anholt.net writes: This allows Mesa to choose to rename driver .sos (or split drivers), without needing a flag day with the corresponding 2D driver. Reviewed-by: Keith Packard kei...@keithp.com mailto:kei...@keithp.com -- keith.pack...@intel.com mailto:keith.pack...@intel.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org mailto:mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Ignore 'centroid' interpolation qualifier in case of persample shading
On 01/22/2014 04:54 PM, Anuj Phogat wrote:
I missed this change in commit f5cfb4a. It fixes the incorrect
rendering caused in Dolphin Emulator.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73915
Cc: Markus wick wickmar...@web.de
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
---
src/mesa/drivers/dri/i965/brw_wm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_wm.c
b/src/mesa/drivers/dri/i965/brw_wm.c
index a6b558f..862c626 100644
--- a/src/mesa/drivers/dri/i965/brw_wm.c
+++ b/src/mesa/drivers/dri/i965/brw_wm.c
@@ -62,7 +62,8 @@ brw_compute_barycentric_interp_modes(struct brw_context
*brw,
for (attr = 0; attr VARYING_SLOT_MAX; ++attr) {
enum glsl_interp_qualifier interp_qualifier =
fprog-InterpQualifier[attr];
- bool is_centroid = fprog-IsCentroid BITFIELD64_BIT(attr);
+ bool is_centroid = (fprog-IsCentroid BITFIELD64_BIT(attr))
+ !persample_shading;
bool is_sample = (fprog-IsSample BITFIELD64_BIT(attr)) ||
persample_shading;
bool is_gl_Color = attr == VARYING_SLOT_COL0 || attr ==
VARYING_SLOT_COL1;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] glsl: s/_NDEBUG/NDEBUG/
On 01/23/2014 11:03 AM, Emil Velikov wrote:
The former symbol is never defined within mesa. Based
it seems that the original intent was to use NDEBUG.
That seems right to me.
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
It looks like this code was originally written by Paul, so he may have
some comment.
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
src/glsl/ir.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/glsl/ir.h b/src/glsl/ir.h
index 19e8383..e266328 100644
--- a/src/glsl/ir.h
+++ b/src/glsl/ir.h
@@ -471,7 +471,7 @@ public:
void reinit_interface_type(const struct glsl_type *type)
{
if (this-max_ifc_array_access != NULL) {
-#ifndef _NDEBUG
+#ifndef NDEBUG
/* Redeclaring gl_PerVertex is only allowed if none of the built-ins
* it defines have been accessed yet; so it's safe to throw away the
* old max_ifc_array_access pointer, since all of its values are
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] can we have gl_framebuffer _NumColorDrawBuffers = 1 and all the entries in the array NULL
I was hoping my kernel fix would be backported to old kernels: http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-3.14id=56492e0fac2dbaf7735ffd66b206a90624917789 I guess I should have fixed up the user space as well. Marek On Tue, Jan 28, 2014 at 10:06 PM, Dave Airlie airl...@gmail.com wrote: Yes, it's legal. Drivers should handle NULL color buffer bindings and there is a test for it: http://cgit.freedesktop.org/piglit/commit/?id=ff2398a4e3c4805e7d1bea38f4ae6f9811b42ede I fixed it just recently. Ah okay on r600g this is broken due to how we work out the CB_TARGET_MASK, the kernel cs checker gives out, I'll fixup the patch I wrote and send it. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] i965/fs: Guess nr_color_regions better in precompile
On 01/25/2014 04:07 PM, Chris Forbes wrote: Signed-off-by: Chris Forbes chr...@ijw.co.nz --- src/mesa/drivers/dri/i965/brw_fs.cpp | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp b/src/mesa/drivers/dri/i965/brw_fs.cpp index 1e6c3e0..d6ebe50 100644 --- a/src/mesa/drivers/dri/i965/brw_fs.cpp +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp @@ -3589,7 +3589,9 @@ brw_fs_precompile(struct gl_context *ctx, struct gl_shader_program *prog) key.render_to_fbo = _mesa_is_user_fbo(ctx-DrawBuffer); } - key.nr_color_regions = 1; + key.nr_color_regions = _mesa_bitcount_64(fp-Base.OutputsWritten + ~(BITFIELD64_BIT(FRAG_RESULT_DEPTH) | + BITFIELD64_BIT(FRAG_RESULT_SAMPLE_MASK))); /* GL_FRAGMENT_SHADER_DERIVATIVE_HINT is almost always GL_DONT_CARE. The * quality of the derivatives is likely to be determined by the driconf Both are: Reviewed-by: Kenneth Graunke kenn...@whitecape.org signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl: Expand non-expr non-swizzle scalar rvalues in vectorizing.
---
src/glsl/opt_vectorize.cpp | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/src/glsl/opt_vectorize.cpp b/src/glsl/opt_vectorize.cpp
index 5ad1320..8ee81f1 100644
--- a/src/glsl/opt_vectorize.cpp
+++ b/src/glsl/opt_vectorize.cpp
@@ -106,9 +106,10 @@ public:
* the nodes of the tree (expression float log2 (swiz z (var_ref v0))),
* rewriting it into (expression vec3 log2 (swiz xyz (var_ref v0))).
*
- * The function modifies only ir_expressions and ir_swizzles. For expressions
- * it sets a new type and swizzles any scalar dereferences into appropriately
- * sized vector arguments. For example, if combining
+ * The function operates on ir_expressions (and its operands) and ir_swizzles.
+ * For expressions it sets a new type and swizzles any non-expression and non-
+ * swizzle scalar operands into appropriately sized vector arguments. For
+ * example, if combining
*
* (assign (x) (var_ref r1) (expression float + (swiz x (var_ref v0) (var_ref
v1
* (assign (y) (var_ref r1) (expression float + (swiz y (var_ref v0) (var_ref
v1
@@ -146,9 +147,10 @@ rewrite_swizzle(ir_instruction *ir, void *data)
mask-num_components, 1);
for (unsigned i = 0; i 4; i++) {
if (expr-operands[i]) {
-ir_dereference *deref = expr-operands[i]-as_dereference();
-if (deref deref-type-is_scalar()) {
- expr-operands[i] = new(ir) ir_swizzle(deref, 0, 0, 0, 0,
+ir_rvalue *rval = expr-operands[i]-as_rvalue();
+if (rval rval-type-is_scalar()
+!rval-as_expression() !rval-as_swizzle()) {
+ expr-operands[i] = new(ir) ir_swizzle(rval, 0, 0, 0, 0,
mask-num_components);
}
}
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Request for support of GL_AMD_pinned_memory and GL_ARB_buffer_storage extensions
Yes, GL_ARB_buffer_storage is being worked on. We'll support it on all Radeon cards R300 and up. Anyway, GL_STREAM_DRAW should give you the same behavior as GL_CLIENT_STORAGE_BIT on open source Radeon drivers. Marek On Sun, Nov 24, 2013 at 1:19 PM, Tony Wasserka neobra...@googlemail.com wrote: Hello everyone, I was told on IRC that my question would get most attention around here - so bear with me if this is the wrong place to ask I'm one of the developers of the GC/Wii emulator Dolphin. We recently rewrote our OpenGL renderer to use modern OpenGL 3 features, however one thing that we stumbled upon are the lack of efficient (vertex/index) buffer data streaming mechanisms in OpenGL. Basically, most of our vertex data is used once and never again after that (we have to do this for accurate emulation) - so all vertex data gets streamed into one huge ring buffer (and analogously for index data, which uses its own huge ring buffer). For buffer streaming, we have multiple code paths using a combination of glMapBufferRange, glBufferSubData, fences and buffer orphaning, yet none of these come anywhere close to the performance of (legacy) rendering from a vertex array stored in RAM. There are two OpenGL extensions which greatly help us in this situation: AMD's pinned memory [1], and buffer storage[2] in GL 4.4. We currently have no buffer storage code path, but usage of pinned memory gave us a speedup of up to 60% under heavy workloads when working with AMD's Catalyst driver under Windows. We expect the same speedup when using buffer storage (specifically we need CLIENT_STORAGE_BIT, if I recall correctly). So the natural question that arises is: Is either of these two extensions going to be supported in mesa anytime soon or is it of lower priority than other extensions? Also, is the pinned memory extension AMD hardware specific or would it be possible to support it for other hardware, too? I'm not sure if buffer storage (being a GL 4.4 extension, and I read that it might actually depend on some other GL 4.3 extension) is possible to implement on older hardware, yet it would be very useful for us to have efficient streaming methods for old GPUs, too. I hope this mail doesn't sound too commanding or anything, it's just supposed to be a friendly question on improving the emulator experience for our user base Thanks in advance! Best regards, Tony [1] http://www.opengl.org/registry/specs/AMD/pinned_memory.txt [2] http://www.opengl.org/registry/specs/ARB/buffer_storage.txt ___ 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] Request for support of GL_AMD_pinned_memory and GL_ARB_buffer_storage extensions
On 01/28/2014 05:35 PM, Marek Olšák wrote: Yes, GL_ARB_buffer_storage is being worked on. We'll support it on all Radeon cards R300 and up. Are you guys working on that? Have an ETA? :) Anyway, GL_STREAM_DRAW should give you the same behavior as GL_CLIENT_STORAGE_BIT on open source Radeon drivers. I think a big piece of functionality that Tony wants is the ability to have CPU pointers that persist for the lifetime of the context. Without GL_ARB_buffer_storage or GL_AMD_pinned_memory the application has to MapBuffer and UnmapBuffer around draw calls. Marek On Sun, Nov 24, 2013 at 1:19 PM, Tony Wasserka neobra...@googlemail.com wrote: Hello everyone, I was told on IRC that my question would get most attention around here - so bear with me if this is the wrong place to ask I'm one of the developers of the GC/Wii emulator Dolphin. We recently rewrote our OpenGL renderer to use modern OpenGL 3 features, however one thing that we stumbled upon are the lack of efficient (vertex/index) buffer data streaming mechanisms in OpenGL. Basically, most of our vertex data is used once and never again after that (we have to do this for accurate emulation) - so all vertex data gets streamed into one huge ring buffer (and analogously for index data, which uses its own huge ring buffer). For buffer streaming, we have multiple code paths using a combination of glMapBufferRange, glBufferSubData, fences and buffer orphaning, yet none of these come anywhere close to the performance of (legacy) rendering from a vertex array stored in RAM. There are two OpenGL extensions which greatly help us in this situation: AMD's pinned memory [1], and buffer storage[2] in GL 4.4. We currently have no buffer storage code path, but usage of pinned memory gave us a speedup of up to 60% under heavy workloads when working with AMD's Catalyst driver under Windows. We expect the same speedup when using buffer storage (specifically we need CLIENT_STORAGE_BIT, if I recall correctly). So the natural question that arises is: Is either of these two extensions going to be supported in mesa anytime soon or is it of lower priority than other extensions? Also, is the pinned memory extension AMD hardware specific or would it be possible to support it for other hardware, too? I'm not sure if buffer storage (being a GL 4.4 extension, and I read that it might actually depend on some other GL 4.3 extension) is possible to implement on older hardware, yet it would be very useful for us to have efficient streaming methods for old GPUs, too. I hope this mail doesn't sound too commanding or anything, it's just supposed to be a friendly question on improving the emulator experience for our user base Thanks in advance! Best regards, Tony [1] http://www.opengl.org/registry/specs/AMD/pinned_memory.txt [2] http://www.opengl.org/registry/specs/ARB/buffer_storage.txt ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Request for support of GL_AMD_pinned_memory and GL_ARB_buffer_storage extensions
On Wed, Jan 29, 2014 at 1:42 AM, Ian Romanick i...@freedesktop.org wrote: On 01/28/2014 05:35 PM, Marek Olšák wrote: Yes, GL_ARB_buffer_storage is being worked on. We'll support it on all Radeon cards R300 and up. Are you guys working on that? Have an ETA? :) It's done. I'm writing piglit tests at the moment. I'll send my patches tomorrow. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Question about OSMesa
Does OSMesa support OpenGL versions higher than GL1? If it does, how can I make it work? Muhammad ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] glcpp: Add testing for #line with integer expression.
This was enabled in the previous commit. Now add a test for make check to ensure it works. --- src/glsl/glcpp/tests/120-hash-line-expression.c | 8 src/glsl/glcpp/tests/120-hash-line-expression.c.expected | 9 + 2 files changed, 17 insertions(+) create mode 100644 src/glsl/glcpp/tests/120-hash-line-expression.c create mode 100644 src/glsl/glcpp/tests/120-hash-line-expression.c.expected diff --git a/src/glsl/glcpp/tests/120-hash-line-expression.c b/src/glsl/glcpp/tests/120-hash-line-expression.c new file mode 100644 index 000..eb159a5 --- /dev/null +++ b/src/glsl/glcpp/tests/120-hash-line-expression.c @@ -0,0 +1,8 @@ +#line 1 +__LINE__ +#line (2) +__LINE__ +#line (1+2) +__LINE__ +#line +4 +__LINE__ diff --git a/src/glsl/glcpp/tests/120-hash-line-expression.c.expected b/src/glsl/glcpp/tests/120-hash-line-expression.c.expected new file mode 100644 index 000..5357d6c --- /dev/null +++ b/src/glsl/glcpp/tests/120-hash-line-expression.c.expected @@ -0,0 +1,9 @@ +#line 1 +1 +#line 2 +2 +#line 3 +3 +#line 4 +4 + -- 1.8.5.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] glcpp: Allow integer expression for #line directive.
The GLSL specification explicitly allows for an in integer expression here,
not just a literal integer. The specification says:
#line must have, after macro substitution, one of the following forms:
#line line
#line line source-string-number
where line and source-string-number are constant integer expressions.
Previously, the implementation required a literal integer (after substitution)
so things like #line (25) or #line +15 were allowed by the specification
but rejected by the implementation.
With this change to the grammar, #line will accept integer expressions like
these.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72273
---
src/glsl/glcpp/glcpp-parse.y | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/glsl/glcpp/glcpp-parse.y b/src/glsl/glcpp/glcpp-parse.y
index 17bc649..2d9008a 100644
--- a/src/glsl/glcpp/glcpp-parse.y
+++ b/src/glsl/glcpp/glcpp-parse.y
@@ -221,7 +221,7 @@ expanded_line:
| ELIF_EXPANDED expression NEWLINE {
_glcpp_parser_skip_stack_change_if (parser, @1, elif, $2);
}
-| LINE_EXPANDED integer_constant NEWLINE {
+| LINE_EXPANDED expression NEWLINE {
parser-has_new_line_number = 1;
parser-new_line_number = $2;
ralloc_asprintf_rewrite_tail (parser-output,
@@ -229,7 +229,7 @@ expanded_line:
#line % PRIiMAX \n,
$2);
}
-| LINE_EXPANDED integer_constant integer_constant NEWLINE {
+| LINE_EXPANDED expression integer_constant NEWLINE {
parser-has_new_line_number = 1;
parser-new_line_number = $2;
parser-has_new_source_number = 1;
--
1.8.5.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] glcpp: Allow integer expression for #line directive.
On Tue, Jan 28, 2014 at 5:56 PM, Carl Worth cwo...@cworth.org wrote:
The GLSL specification explicitly allows for an in integer expression here,
not just a literal integer. The specification says:
#line must have, after macro substitution, one of the following forms:
#line line
#line line source-string-number
where line and source-string-number are constant integer expressions.
If this is the case, then
Previously, the implementation required a literal integer (after substitution)
so things like #line (25) or #line +15 were allowed by the specification
but rejected by the implementation.
With this change to the grammar, #line will accept integer expressions like
these.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72273
---
src/glsl/glcpp/glcpp-parse.y | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/glsl/glcpp/glcpp-parse.y b/src/glsl/glcpp/glcpp-parse.y
index 17bc649..2d9008a 100644
--- a/src/glsl/glcpp/glcpp-parse.y
+++ b/src/glsl/glcpp/glcpp-parse.y
@@ -221,7 +221,7 @@ expanded_line:
| ELIF_EXPANDED expression NEWLINE {
_glcpp_parser_skip_stack_change_if (parser, @1, elif, $2);
}
-| LINE_EXPANDED integer_constant NEWLINE {
+| LINE_EXPANDED expression NEWLINE {
parser-has_new_line_number = 1;
parser-new_line_number = $2;
ralloc_asprintf_rewrite_tail (parser-output,
@@ -229,7 +229,7 @@ expanded_line:
#line % PRIiMAX \n,
$2);
}
-| LINE_EXPANDED integer_constant integer_constant NEWLINE {
+| LINE_EXPANDED expression integer_constant NEWLINE {
shouldn't this should be
LINE_EXPANDED expression expression NEWLINE
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 70410] egl-static/Makefile: linking fails with llvm = 3.4
https://bugs.freedesktop.org/show_bug.cgi?id=70410 Nikoli nik...@gmx.us changed: What|Removed |Added CC||nik...@gmx.us -- 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 02/16] radeonsi: Initial geometry shader support
On Wed, 2014-01-29 at 07:13 +1000, Dave Airlie wrote: 3) In si_init_gs_rings: - could you please use readable decimal numbers for specifying the sizes? Like 1024 * 1024 * ... [...] - isn't 64 MB too many for a ring buffer? I can write the numbers any way you like. :) But I just copied them from the corresponding r600g patches; I don't know yet how these numbers were derived, or what the constraints are for the ring buffer sizes. I'm trying to find out more about this. I don't think they are derived from anything yet, they were just big numbers Vadim used, IIRC all these magic numbers were taken from the fglrx command stream for some simple GS test on my 512MB juniper card. Vadim I suppose we can calculate them from max vertices for the geom shader * number of outputs * size of each output. Dave. ___ 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] [Bug 35268] initial-exec TLS model breaks dlopen'ed libGL
https://bugs.freedesktop.org/show_bug.cgi?id=35268 Natanael Copa natanael.c...@gmail.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|NOTOURBUG |--- --- Comment #8 from Natanael Copa natanael.c...@gmail.com --- initial-exec TLS and dlopen'ed libGL is still an issue with musl libc. Here is a backtrace from a coredump of firefox: 0x664c2c6f5000 Core was generated by `/usr/lib/firefox-26.0/firefox'. Program terminated with signal 11, Segmentation fault. #0 0x664c1fb519a8 in __glXSetupForCommand (dpy=0xae298156200) at glxext.c:917 917glxext.c: No such file or directory. (gdb) bt #0 0x664c1fb519a8 in __glXSetupForCommand (dpy=0xae298156200) at glxext.c:917 #1 0x664c1fb4ffcd in glx_context_init (gc=gc@entry=0xae298165480, psc=psc@entry=0xae298164d60, config=config@entry=0xae29816f3e0) at glxcmds.c:258 #2 0x664c1fb7b940 in dri2_create_context (base=0xae298164d60, config_base=0xae29816f3e0, shareList=optimized out, renderType=32788) at dri2_glx.c:228 #3 0x664c1fb4f3ed in CreateContext (dpy=dpy@entry=0xae298156200, generic_id=141, config=0xae29816f3e0, shareList_user=shareList_user@entry=0x0, allowDirect=optimized out, code=code@entry=3, renderType=32788, screen=0) at glxcmds.c:301 #4 0x664c1fb4f6e1 in glXCreateContext (dpy=0xae298156200, vis=0xae2981651e0, shareList=0x0, allowDirect=1) at glxcmds.c:430 #5 0x664c28f95774 in ?? () from /usr/lib/firefox-26.0/xulrunner/libxul.so #6 0x664c28f95918 in ?? () from /usr/lib/firefox-26.0/xulrunner/libxul.so #7 0x664c28f8da28 in ?? () from /usr/lib/firefox-26.0/xulrunner/libxul.so #8 0x664c28f90e76 in ?? () from /usr/lib/firefox-26.0/xulrunner/libxul.so #9 0x664c28f91127 in XRE_main () from /usr/lib/firefox-26.0/xulrunner/libxul.so #10 0x0ae2946dd30f in do_main (xreDirectory=0x664c2c16e440, argv=0x733c6106a4c8, argc=1) at /home/buildozer/aports/main/firefox/src/mozilla-release/browser/app/nsBrowserApp.cpp:275 #11 main (argc=optimized out, argv=optimized out) at /home/buildozer/aports/main/firefox/src/mozilla-release/browser/app/nsBrowserApp.cpp:635 (gdb) It is mesa 9.2.5, so the segfault happens in: http://cgit.freedesktop.org/mesa/mesa/tree/src/glx/glxext.c?h=9.2#n917 gc = __glXGetCurrentContext(); I believe that __glxGetCurrentContext is defined as a macro: http://cgit.freedesktop.org/mesa/mesa/tree/src/glx/glxcurrent.c?h=9.2#n82 I believe that it segfaults due to the use of initial-exec use: __thread void *__glX_tls_Context __attribute__ ((tls_model(initial-exec))) = dummyContext; -- 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
