[Mesa-dev] [Bug 72062] New: build broken for x11 egl apps
https://bugs.freedesktop.org/show_bug.cgi?id=72062 Priority: medium Bug ID: 72062 Assignee: mesa-dev@lists.freedesktop.org Summary: build broken for x11 egl apps Severity: critical Classification: Unclassified OS: All Reporter: lem...@gmail.com Hardware: Other Status: NEW Version: git Component: EGL Product: Mesa Cannot run opengles2.0 apps anymore on X11 backend, such as es2gears in Mesa demos. bisected to: commit a594cec7e3ef275c386054127a357110a19dd823 Author: Samuel Thibault samuel.thiba...@ens-lyon.org Date: Sun Nov 10 19:32:01 2013 +0100 EGL: fix build without libdrm This fixes building EGL without libdrm support. Signed-off-by: Samuel Thibault samuel.thiba...@ens-lyon.org -- 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 72062] build broken for x11 egl apps
https://bugs.freedesktop.org/show_bug.cgi?id=72062 --- Comment #1 from Tapani Pälli lem...@gmail.com --- More specifically, building mesa like this: ./autogen.sh --enable-gles2 --with-egl-platforms=x11 does not result in having a working egl and gles2 implementation. Reverting a594cec7e3ef275c386054127a357110a19dd823 fixes the situation. -- 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 72062] build broken for x11 egl apps
https://bugs.freedesktop.org/show_bug.cgi?id=72062 Tapani Pälli lem...@gmail.com changed: What|Removed |Added CC||samuel.thiba...@ens-lyon.or ||g -- 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 72062] build broken for x11 egl apps
https://bugs.freedesktop.org/show_bug.cgi?id=72062 --- Comment #2 from Samuel Thibault samuel.thiba...@ens-lyon.org --- Created attachment 89891 -- https://bugs.freedesktop.org/attachment.cgi?id=89891action=edit fix Could you try the attached patch? I wasn't completely sure whether dri2_authenticate was supposed to fail or not when drm is not compiled in. By looking more, since this is the client side, and dri2_authenticated is store in the structure, it seems returning true is the right way. -- 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 72062] build broken for x11 egl apps
https://bugs.freedesktop.org/show_bug.cgi?id=72062 --- Comment #3 from Tapani Pälli lem...@gmail.com --- Created attachment 89892 -- https://bugs.freedesktop.org/attachment.cgi?id=89892action=edit patch to fix the issue This patch adds additional HAVE_LIBDRM for x11_platform to compile correctly. -- 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 72062] build broken for x11 egl apps
https://bugs.freedesktop.org/show_bug.cgi?id=72062 --- Comment #4 from Tapani Pälli lem...@gmail.com --- (In reply to comment #2) Created attachment 89891 [details] [review] fix Could you try the attached patch? I wasn't completely sure whether dri2_authenticate was supposed to fail or not when drm is not compiled in. By looking more, since this is the client side, and dri2_authenticated is store in the structure, it seems returning true is the right way. This does not do the trick, I want to use platform_x11 with libdrm but not having HAVE_DRM_PLATFORM since that is for gbm backend. I've attached a patch that fixes this issue for me. -- 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 72062] build broken for x11 egl apps
https://bugs.freedesktop.org/show_bug.cgi?id=72062 --- Comment #5 from Samuel Thibault samuel.thiba...@ens-lyon.org --- Ok, but I guess both patches are needed actually, because otherwise a completely-non-drm build would have a similar issue? -- 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 72062] build broken for x11 egl apps
https://bugs.freedesktop.org/show_bug.cgi?id=72062 --- Comment #6 from Tapani Pälli lem...@gmail.com --- (In reply to comment #5) Ok, but I guess both patches are needed actually, because otherwise a completely-non-drm build would have a similar issue? Yep, probably so. What is the type of build you are doing (non-drm and ...) so I could test that also? I'll need to fix my patch, it seems it actually does not work correctly yet. -- 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 72062] build broken for x11 egl apps
https://bugs.freedesktop.org/show_bug.cgi?id=72062 Tapani Pälli lem...@gmail.com changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|mesa-dev@lists.freedesktop. |lem...@gmail.com |org | Attachment #89892|0 |1 is obsolete|| --- Comment #7 from Tapani Pälli lem...@gmail.com --- Created attachment 89893 -- https://bugs.freedesktop.org/attachment.cgi?id=89893action=edit patch to fix the issue -- 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] mesa/llvmpipe: add fake MSAA support
This adds a gallium cap that allows us to fake GL3.0 by
not exposing MSAA on sw rendering. It also forces the
extra extensions needed for GL3.2. Along with a patch to
raise the GLSL version in llvmpipe this will expose GL3.3
on llvmpipe.
However we still need Marek's code for layered clears.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/gallium/drivers/llvmpipe/lp_screen.c | 2 ++
src/gallium/include/pipe/p_defines.h | 3 ++-
src/mesa/main/mtypes.h | 1 +
src/mesa/main/version.c | 2 +-
src/mesa/state_tracker/st_extensions.c | 7 +++
5 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c
b/src/gallium/drivers/llvmpipe/lp_screen.c
index f61df98..218b3f8 100644
--- a/src/gallium/drivers/llvmpipe/lp_screen.c
+++ b/src/gallium/drivers/llvmpipe/lp_screen.c
@@ -234,6 +234,8 @@ llvmpipe_get_param(struct pipe_screen *screen, enum
pipe_cap param)
return PIPE_MAX_VIEWPORTS;
case PIPE_CAP_ENDIANNESS:
return PIPE_ENDIAN_NATIVE;
+ case PIPE_CAP_FAKE_SW_MSAA:
+ return 1;
}
/* should only get here on unhandled cases */
debug_printf(Unexpected PIPE_CAP %d query\n, param);
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/include/pipe/p_defines.h
index db6db32..27f1bcf 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -513,7 +513,8 @@ enum pipe_cap {
PIPE_CAP_MAX_TEXTURE_BUFFER_SIZE = 83,
PIPE_CAP_MAX_VIEWPORTS = 84,
PIPE_CAP_ENDIANNESS = 85,
- PIPE_CAP_MIXED_FRAMEBUFFER_SIZES = 86
+ PIPE_CAP_MIXED_FRAMEBUFFER_SIZES = 86,
+ PIPE_CAP_FAKE_SW_MSAA = 87
};
#define PIPE_QUIRK_TEXTURE_BORDER_COLOR_SWIZZLE_NV50 (1 0)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index ecfb5e0..39b8abd 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -3302,6 +3302,7 @@ struct gl_constants
/** GL_ARB_vertex_attrib_binding */
GLint MaxVertexAttribRelativeOffset;
GLint MaxVertexAttribBindings;
+ GLboolean FakeSWMSAA;
};
diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index 55411fa..1dfce09 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/version.c
@@ -229,7 +229,7 @@ compute_version(struct gl_context *ctx)
ctx-Extensions.EXT_texture_sRGB);
const GLboolean ver_3_0 = (ver_2_1
ctx-Const.GLSLVersion = 130
- ctx-Const.MaxSamples = 4
+ (ctx-Const.MaxSamples = 4 ||
ctx-Const.FakeSWMSAA)
(ctx-API == API_OPENGL_CORE ||
ctx-Extensions.ARB_color_buffer_float)
ctx-Extensions.ARB_depth_buffer_float
diff --git a/src/mesa/state_tracker/st_extensions.c
b/src/mesa/state_tracker/st_extensions.c
index cd10a0c..701086a 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -715,6 +715,13 @@ void st_init_extensions(struct st_context *st)
ctx-Extensions.EXT_framebuffer_multisample_blit_scaled = GL_TRUE;
}
+ if (ctx-Const.MaxSamples == 0 screen-get_param(screen,
PIPE_CAP_FAKE_SW_MSAA)) {
+ ctx-Const.FakeSWMSAA = GL_TRUE;
+ctx-Extensions.EXT_framebuffer_multisample = GL_TRUE;
+ctx-Extensions.EXT_framebuffer_multisample_blit_scaled = GL_TRUE;
+ctx-Extensions.ARB_texture_multisample = GL_TRUE;
+ }
+
if (ctx-Const.MaxDualSourceDrawBuffers 0
!st-options.disable_blend_func_extended)
ctx-Extensions.ARB_blend_func_extended = GL_TRUE;
--
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] Fixed memory leak.
Thank you very much Alex for the tip. I'll modify commits and send a v2 series of patches. Before that I want to make sure that patch #17 is done correctly. I'll be thankful if someone finds time to review and comment on this patch: [Mesa-dev] [PATCH 17/17] Deleted gl_extensions::ARB_map_buffer_alignment and all of its use cases. http://lists.freedesktop.org/archives/mesa-dev/2013-November/049047.html Regards, Siavash Eliasi. On 11/26/2013 10:26 PM, Alex Deucher wrote: On Tue, Nov 26, 2013 at 1:22 PM, Siavash Eliasi siavashser...@gmail.com wrote: In general, when you fix problems in prior patches, you should integrate the fix into the original patch(es) where the problems were, update the commit message to note what bugs were fixed and then re-send the patch set. That prevents broken commits from getting into the git tree even if they are fixed in a later commit. You can use git rebase -i to integrate your fixes. Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Question: in i965 question, potential bug pull vs push constants in vertex shader
Hi all, I was taking a look in i965 taking a closer look at the upload to GPU of param and pull_param for vertex shaders. What I found was this: 1) in vec4_visitor::move_uniform_array_access_to_pull_constants(), those uniforms that are relatively addressed are cloned from param to pull_param. 2) in gen6_upload_vec4_push_constants() (which is used by Gen6 and Gen7) -all- values of param are uploaded, but there is an assert() checking that no more than a critical number push constants are uploaded (i.e. essentially, before padding that nr_params/8 is not more than 32) 3) the only assignment I see to nr_params is in vec4_visitor::setup_uniforms() setting it to this-uniforms*4 However, I did not find anywhere in the code that guaranteed that nr_params is no more than 256. So, where is it set? Or is vec4_visitor::uniforms guaranteed not to go beyond 64 somehow? -Kevin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/2] v3: Fix array overrun with too many uniforms
Third version of this patch series sent in full, both patches changed a bit. As per advice, I assigned the required size to prog_data-nr_params, which is unused until vec4_visitor::setup_uniforms() sets it again. This is done in do_vs_prog() and do_gs_prog(), with accompanying comments that explain the implications. I tested this patch with a test program and ran piglit tests, until no regressions were found. To my understanding, the allocated size is enough for user-defined uniforms, builtin uniforms, clip planes, and sampler variables, with some extra which I think comes from padding somewhere earlier. Extra means something like 3 or 7 too much, not a factor too much. I removed the noncopyable chunk by request too, that will possibly be sent later in a separate patch. Petri Latvala (2): i965: Allocate vec4_visitor's uniform_size and uniform_vector_size arrays dynamically. i965: Assert array index on access to vec4_visitor's arrays. src/mesa/drivers/dri/i965/brw_vec4.cpp | 2 ++ src/mesa/drivers/dri/i965/brw_vec4.h | 5 +++-- src/mesa/drivers/dri/i965/brw_vec4_gs.c| 5 + src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 13 + src/mesa/drivers/dri/i965/brw_vs.c | 8 5 files changed, 31 insertions(+), 2 deletions(-) -- 1.8.4.rc3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] i965: Assert array index on access to vec4_visitor's arrays.
Signed-off-by: Petri Latvala petri.latv...@intel.com
---
src/mesa/drivers/dri/i965/brw_vec4.cpp | 2 ++
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 6 ++
2 files changed, 8 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp
b/src/mesa/drivers/dri/i965/brw_vec4.cpp
index 73f91a0..0cbdc98 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
@@ -410,6 +410,7 @@ vec4_visitor::pack_uniform_registers()
/* Now, figure out a packing of the live uniform vectors into our
* push constants.
*/
+ assert(uniforms uniform_param_count);
for (int src = 0; src uniforms; src++) {
int size = this-uniform_vector_size[src];
@@ -1315,6 +1316,7 @@ vec4_visitor::setup_uniforms(int reg)
* matter what, or the GPU would hang.
*/
if (brw-gen 6 this-uniforms == 0) {
+ assert(this-uniforms this-uniform_param_count);
this-uniform_vector_size[this-uniforms] = 1;
prog_data-param = reralloc(NULL, prog_data-param, const float *, 4);
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index b9226dc..d01c8d5 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -662,6 +662,7 @@ vec4_visitor::setup_uniform_values(ir_variable *ir)
storage-type-matrix_columns);
for (unsigned s = 0; s vector_count; s++) {
+ assert(uniforms uniform_param_count);
uniform_vector_size[uniforms] = storage-type-vector_elements;
int i;
@@ -685,6 +686,7 @@ vec4_visitor::setup_uniform_clipplane_values()
gl_clip_plane *clip_planes = brw_select_clip_planes(ctx);
for (int i = 0; i key-nr_userclip_plane_consts; ++i) {
+ assert(this-uniforms uniform_param_count);
this-uniform_vector_size[this-uniforms] = 4;
this-userplane[i] = dst_reg(UNIFORM, this-uniforms);
this-userplane[i].type = BRW_REGISTER_TYPE_F;
@@ -715,6 +717,7 @@ vec4_visitor::setup_builtin_uniform_values(ir_variable *ir)
(gl_state_index *)slots[i].tokens);
float *values = this-prog-Parameters-ParameterValues[index][0].f;
+ assert(this-uniforms uniform_param_count);
this-uniform_vector_size[this-uniforms] = 0;
/* Add each of the unique swizzled channels of the element.
* This will end up matching the size of the glsl_type of this field.
@@ -725,6 +728,7 @@ vec4_visitor::setup_builtin_uniform_values(ir_variable *ir)
last_swiz = swiz;
prog_data-param[this-uniforms * 4 + j] = values[swiz];
+assert(this-uniforms uniform_param_count);
if (swiz = last_swiz)
this-uniform_vector_size[this-uniforms]++;
}
@@ -983,6 +987,7 @@ vec4_visitor::visit(ir_variable *ir)
/* Track how big the whole uniform variable is, in case we need to put a
* copy of its data into pull constants for array access.
*/
+ assert(this-uniforms uniform_param_count);
this-uniform_size[this-uniforms] = type_size(ir-type);
if (!strncmp(ir-name, gl_, 3)) {
@@ -3197,6 +3202,7 @@
vec4_visitor::move_uniform_array_access_to_pull_constants()
pull_constant_loc[uniform] = prog_data-nr_pull_params / 4;
+ assert(uniform uniform_param_count);
for (int j = 0; j uniform_size[uniform] * 4; j++) {
prog_data-pull_param[prog_data-nr_pull_params++]
= values[j];
--
1.8.4.rc3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] i965: Allocate vec4_visitor's uniform_size and uniform_vector_size arrays dynamically.
v2: Don't add function parameters, pass the required size in
prog_data-nr_params.
Signed-off-by: Petri Latvala petri.latv...@intel.com
---
src/mesa/drivers/dri/i965/brw_vec4.h | 5 +++--
src/mesa/drivers/dri/i965/brw_vec4_gs.c| 5 +
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 7 +++
src/mesa/drivers/dri/i965/brw_vs.c | 8
4 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h
b/src/mesa/drivers/dri/i965/brw_vec4.h
index 5cec9f9..5f5f5cd 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.h
+++ b/src/mesa/drivers/dri/i965/brw_vec4.h
@@ -325,8 +325,9 @@ public:
*/
dst_reg output_reg[BRW_VARYING_SLOT_COUNT];
const char *output_reg_annotation[BRW_VARYING_SLOT_COUNT];
- int uniform_size[MAX_UNIFORMS];
- int uniform_vector_size[MAX_UNIFORMS];
+ int *uniform_size;
+ int *uniform_vector_size;
+ int uniform_param_count; /* Size of uniform_[vector_]size arrays */
int uniforms;
src_reg shader_start_time;
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_gs.c
b/src/mesa/drivers/dri/i965/brw_vec4_gs.c
index 018b0b6..7cf9bac 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_gs.c
+++ b/src/mesa/drivers/dri/i965/brw_vec4_gs.c
@@ -64,6 +64,11 @@ do_gs_prog(struct brw_context *brw,
c.prog_data.base.param = rzalloc_array(NULL, const float *, param_count);
c.prog_data.base.pull_param = rzalloc_array(NULL, const float *,
param_count);
+ /* Setting nr_params here NOT to the size of the param and pull_param
+* arrays, but to the number of uniform components vec4_visitor
+* needs. vec4_visitor::setup_uniforms() will set it back to a proper value.
+*/
+ c.prog_data.base.nr_params = param_count / 4 + gs-num_samplers;
if (gp-program.OutputType == GL_POINTS) {
/* When the output type is points, the geometry shader may output data
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index a13eafb..b9226dc 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -3253,6 +3253,10 @@ vec4_visitor::vec4_visitor(struct brw_context *brw,
fail_msg(NULL),
first_non_payload_grf(0),
need_all_constants_in_pull_buffer(false),
+ /* Initialize uniform_param_count to at least 1 because gen6 VS requires
at
+ * least one. See setup_uniforms() in brw_vec4.cpp.
+ */
+ uniform_param_count(prog_data-nr_params ? prog_data-nr_params : 1),
debug_flag(debug_flag),
no_spills(no_spills)
{
@@ -3290,6 +3294,9 @@ vec4_visitor::vec4_visitor(struct brw_context *brw,
this-max_grf = brw-gen = 7 ? GEN7_MRF_HACK_START : BRW_MAX_GRF;
this-uniforms = 0;
+
+ this-uniform_size = rzalloc_array(mem_ctx, int, this-uniform_param_count);
+ this-uniform_vector_size = rzalloc_array(mem_ctx, int,
this-uniform_param_count);
}
vec4_visitor::~vec4_visitor()
diff --git a/src/mesa/drivers/dri/i965/brw_vs.c
b/src/mesa/drivers/dri/i965/brw_vs.c
index b5c8b63..8d0933d 100644
--- a/src/mesa/drivers/dri/i965/brw_vs.c
+++ b/src/mesa/drivers/dri/i965/brw_vs.c
@@ -242,6 +242,14 @@ do_vs_prog(struct brw_context *brw,
prog_data.base.param = rzalloc_array(NULL, const float *, param_count);
prog_data.base.pull_param = rzalloc_array(NULL, const float *, param_count);
+ /* Setting nr_params here NOT to the size of the param and pull_param
+* arrays, but to the number of uniform components vec4_visitor
+* needs. vec4_visitor::setup_uniforms() will set it back to a proper value.
+*/
+ prog_data.base.nr_params = param_count / 4;
+ if (vs) {
+ prog_data.base.nr_params += vs-num_samplers;
+ }
GLbitfield64 outputs_written = vp-program.Base.OutputsWritten;
prog_data.inputs_read = vp-program.Base.InputsRead;
--
1.8.4.rc3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 11/17] Modified _mesa_buffer_data to use _mesa_align_malloc.
On Tue, Nov 26, 2013 at 11:34 AM, Siavash Eliasi siavashser...@gmail.comwrote: Now I understand why _mesa_realloc is not appropriate to use here. From spec: glBufferData creates a new data store for the buffer object currently bound to target. Any pre-existing data store is deleted. The new data store is created with the specified size in bytes and usage. If data is NULL, a data store of the specified size is still created, but its contents remain uninitialized and thus undefined. Best regards, Siavash Eliasi. On 11/26/2013 09:34 AM, Siavash Eliasi wrote: Yes I think you are right, I guess *_mesa_align_realloc* is the correct function which should be used here. What do you think Ian? Best regards, Siavash Eliasi. Realloc was a poor choice in the first place. It would needlessly copy data from the old buffer to the new one. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: add assert after calloc before access memory in attrib.c
Signed-off-by: Juha-Pekka Heikkila juhapekka.heikk...@gmail.com
---
src/mesa/main/attrib.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/mesa/main/attrib.c b/src/mesa/main/attrib.c
index c9332bd..5185f89 100644
--- a/src/mesa/main/attrib.c
+++ b/src/mesa/main/attrib.c
@@ -1488,6 +1488,9 @@ init_array_attrib_data(struct gl_context *ctx,
{
/* Get a non driver gl_array_object. */
attrib-ArrayObj = CALLOC_STRUCT( gl_array_object );
+
+ assert(attrib-ArrayObj != NULL);
+
_mesa_initialize_array_object(ctx, attrib-ArrayObj, 0);
}
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] radeonsi: always set the scanout flag?
This fixes the issue for me, However looking at your patch, I believe you made a small mistake. I think with your patch, the RADEON_SURF_SCANOUT flag would be always be set for cards inferior to SI, since your calculation of scanout: *scanout = !(bo-rws-gen = DRV_SI args.tiling_flags RADEON_TILING_R600_NO_SCANOUT); Would make scanout set to 1 when the card is inferior to SI. I think the correct calculus is: *scanout = (bo-rws-gen = DRV_SI) !(args.tiling_flags RADEON_TILING_R600_NO_SCANOUT); Thank you for having fixed this issue, Axel Davy On 26/11/2013, Marek Olšák wrote : Does the attached patch fix the issue for you? Marek On Tue, Nov 26, 2013 at 9:20 AM, Axel Davy axel.d...@ens.fr wrote: Hi, When importing an handle (src/gallium/drivers/radeon/r600_texture.c), the RADEON_SURF_SCANOUT flag is always set on SI. The code is associated with a comment: /* always set the scanout flags on SI */ I was getting bad tiling mode on Wayland with my radeonsi card, and recent Mesa, and I discovered that setting this flag there was causing my tiling issue. I think one possible reason for this code is X dri2, since the DDX allocates the buffers with this flag. Could this flag be passed via buffer_get_tiling? If not, then there would probably need to force this flag when creating a resource on SI. But ideally, if it makes a performance difference, we would like to be able to control that with Wayland when allocating the buffers. Axel Davy ___ 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] glx: Add assert after malloc before accessing memory in glx/clientattrib.c
Signed-off-by: Juha-Pekka Heikkila juhapekka.heikk...@gmail.com
---
src/glx/clientattrib.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/glx/clientattrib.c b/src/glx/clientattrib.c
index 1b306ea..6162b49 100644
--- a/src/glx/clientattrib.c
+++ b/src/glx/clientattrib.c
@@ -76,6 +76,9 @@ __indirect_glPushClientAttrib(GLuint mask)
if (spp gc-attributes.stack[__GL_CLIENT_ATTRIB_STACK_DEPTH]) {
if (!(sp = *spp)) {
sp = malloc(sizeof(__GLXattribute));
+
+ assert(sp != NULL);
+
*spp = sp;
}
sp-mask = mask;
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/4] Refactor i965 DRI image implementation
From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com Hi, The main motivation for this series is to split the image code out of intel_screen.c so that this could be compiled into a separate statically linked library that we could also use in GBM. The last patch is quite big, but I couldn't figure out a way to split that change into smaller steps while still keeping everything working. Thanks, Ander Ander Conselvan de Oliveira (4): i965: Support allocation of subregions of an intel_region i965: Change intel_region interface to not depend on intelScreen i965: Make names of DRI image extension functions more consistent i965: Refactor DRI image code src/mesa/drivers/dri/i965/Makefile.sources|1 + src/mesa/drivers/dri/i965/brw_context.c | 10 +- src/mesa/drivers/dri/i965/intel_fbo.c | 13 +- src/mesa/drivers/dri/i965/intel_image.c | 390 + src/mesa/drivers/dri/i965/intel_image.h | 73 src/mesa/drivers/dri/i965/intel_mipmap_tree.c |4 +- src/mesa/drivers/dri/i965/intel_regions.c | 48 ++- src/mesa/drivers/dri/i965/intel_regions.h | 32 +- src/mesa/drivers/dri/i965/intel_screen.c | 554 +++-- src/mesa/drivers/dri/i965/intel_tex_image.c | 13 +- 10 files changed, 681 insertions(+), 457 deletions(-) create mode 100644 src/mesa/drivers/dri/i965/intel_image.c create mode 100644 src/mesa/drivers/dri/i965/intel_image.h -- 1.7.9.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/4] i965: Make names of DRI image extension functions more consistent
From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
Prefix everything with intel_dri_image.
---
src/mesa/drivers/dri/i965/intel_screen.c | 116 +++---
1 file changed, 59 insertions(+), 57 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
b/src/mesa/drivers/dri/i965/intel_screen.c
index 00339f9..fe412b5 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -355,9 +355,9 @@ intel_setup_image_from_dimensions(__DRIimage *image)
}
static __DRIimage *
-intel_create_image_from_name(__DRIscreen *screen,
-int width, int height, int format,
-int name, int pitch, void *loaderPrivate)
+intel_dri_image_create_from_name(__DRIscreen *screen,
+ int width, int height, int format,
+ int name, int pitch, void *loaderPrivate)
{
struct intel_screen *intelScreen = screen-driverPrivate;
__DRIimage *image;
@@ -385,8 +385,9 @@ intel_create_image_from_name(__DRIscreen *screen,
}
static __DRIimage *
-intel_create_image_from_renderbuffer(__DRIcontext *context,
-int renderbuffer, void *loaderPrivate)
+intel_dri_image_create_from_renderbuffer(__DRIcontext *context,
+ int renderbuffer,
+ void *loaderPrivate)
{
__DRIimage *image;
struct brw_context *brw = context-driverPrivate;
@@ -419,11 +420,11 @@ intel_create_image_from_renderbuffer(__DRIcontext
*context,
}
static __DRIimage *
-intel_create_image_from_texture(__DRIcontext *context, int target,
-unsigned texture, int zoffset,
-int level,
-unsigned *error,
-void *loaderPrivate)
+intel_dri_image_create_from_texture(__DRIcontext *context, int target,
+unsigned texture, int zoffset,
+int level,
+unsigned *error,
+void *loaderPrivate)
{
__DRIimage *image;
struct brw_context *brw = context-driverPrivate;
@@ -479,17 +480,17 @@ intel_create_image_from_texture(__DRIcontext *context,
int target,
}
static void
-intel_destroy_image(__DRIimage *image)
+intel_dri_image_destroy(__DRIimage *image)
{
intel_region_release(image-region);
free(image);
}
static __DRIimage *
-intel_create_image(__DRIscreen *screen,
- int width, int height, int format,
- unsigned int use,
- void *loaderPrivate)
+intel_dri_image_create(__DRIscreen *screen,
+ int width, int height, int format,
+ unsigned int use,
+ void *loaderPrivate)
{
__DRIimage *image;
struct intel_screen *intelScreen = screen-driverPrivate;
@@ -525,7 +526,7 @@ intel_create_image(__DRIscreen *screen,
}
static GLboolean
-intel_query_image(__DRIimage *image, int attrib, int *value)
+intel_dri_image_query(__DRIimage *image, int attrib, int *value)
{
switch (attrib) {
case __DRI_IMAGE_ATTRIB_STRIDE:
@@ -560,7 +561,7 @@ intel_query_image(__DRIimage *image, int attrib, int *value)
}
static __DRIimage *
-intel_dup_image(__DRIimage *orig_image, void *loaderPrivate)
+intel_dri_image_dup(__DRIimage *orig_image, void *loaderPrivate)
{
__DRIimage *image;
@@ -588,7 +589,7 @@ intel_dup_image(__DRIimage *orig_image, void *loaderPrivate)
}
static GLboolean
-intel_validate_usage(__DRIimage *image, unsigned int use)
+intel_dri_image_validate_usage(__DRIimage *image, unsigned int use)
{
if (use __DRI_IMAGE_USE_CURSOR) {
if (image-region-width != 64 || image-region-height != 64)
@@ -599,11 +600,11 @@ intel_validate_usage(__DRIimage *image, unsigned int use)
}
static __DRIimage *
-intel_create_image_from_names(__DRIscreen *screen,
- int width, int height, int fourcc,
- int *names, int num_names,
- int *strides, int *offsets,
- void *loaderPrivate)
+intel_dri_image_create_from_names(__DRIscreen *screen,
+ int width, int height, int fourcc,
+ int *names, int num_names,
+ int *strides, int *offsets,
+ void *loaderPrivate)
{
struct intel_image_format *f = NULL;
__DRIimage *image;
@@ -616,10 +617,10 @@ intel_create_image_from_names(__DRIscreen *screen,
if (f == NULL)
return NULL;
-image = intel_create_image_from_name(screen, width, height,
- __DRI_IMAGE_FORMAT_NONE,
- names[0],
[Mesa-dev] [PATCH 1/4] i965: Support allocation of subregions of an intel_region
From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
Both __DRIimage and intel_region have width and height fields. They
actually differ when an image is created for a texture but are the
same in all the other cases. For images created from a planar image,
a special intel_region that represents only a part of the storage used
by the image is used. It references the same bo but contains offset
information plus different dimensions and pitch.
This patch adds an entry point for creating an intel_region that
represents a sub region of another intel_region. This entry point is
then used when creating images from textures or from planar images.
This lets us remove the duplicate width and height fields from
__DRIimage and move the offset, tile_x and tile_y filed into
intel_region.
---
src/mesa/drivers/dri/i965/brw_context.c |8 ++--
src/mesa/drivers/dri/i965/intel_fbo.c |2 +-
src/mesa/drivers/dri/i965/intel_regions.c | 28 +
src/mesa/drivers/dri/i965/intel_regions.h | 16 ---
src/mesa/drivers/dri/i965/intel_screen.c| 60 +++
src/mesa/drivers/dri/i965/intel_tex_image.c |7 ++--
6 files changed, 72 insertions(+), 49 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index bee98e3..ffbfb43 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -1387,8 +1387,8 @@ intel_update_image_buffers(struct brw_context *brw,
__DRIdrawable *drawable)
images);
if (images.image_mask __DRI_IMAGE_BUFFER_FRONT) {
- drawable-w = images.front-width;
- drawable-h = images.front-height;
+ drawable-w = images.front-region-width;
+ drawable-h = images.front-region-height;
intel_update_image_buffer(brw,
drawable,
front_rb,
@@ -1396,8 +1396,8 @@ intel_update_image_buffers(struct brw_context *brw,
__DRIdrawable *drawable)
__DRI_IMAGE_BUFFER_FRONT);
}
if (images.image_mask __DRI_IMAGE_BUFFER_BACK) {
- drawable-w = images.back-width;
- drawable-h = images.back-height;
+ drawable-w = images.back-region-width;
+ drawable-h = images.back-region-height;
intel_update_image_buffer(brw,
drawable,
back_rb,
diff --git a/src/mesa/drivers/dri/i965/intel_fbo.c
b/src/mesa/drivers/dri/i965/intel_fbo.c
index ddecb2b..ae978f1 100644
--- a/src/mesa/drivers/dri/i965/intel_fbo.c
+++ b/src/mesa/drivers/dri/i965/intel_fbo.c
@@ -291,7 +291,7 @@ intel_image_target_renderbuffer_storage(struct gl_context
*ctx,
irb-mt = intel_miptree_create_for_bo(brw,
image-region-bo,
image-format,
- image-offset,
+ image-region-offset,
image-region-width,
image-region-height,
image-region-pitch,
diff --git a/src/mesa/drivers/dri/i965/intel_regions.c
b/src/mesa/drivers/dri/i965/intel_regions.c
index 3920f4f..8ad6129 100644
--- a/src/mesa/drivers/dri/i965/intel_regions.c
+++ b/src/mesa/drivers/dri/i965/intel_regions.c
@@ -238,6 +238,34 @@ intel_region_alloc_for_fd(struct intel_screen *screen,
return region;
}
+struct intel_region *
+intel_region_alloc_subregion(struct intel_region *parent_region,
+ GLuint cpp,
+ GLuint width, GLuint height, GLuint pitch,
+ GLuint offset, GLuint tile_x, GLuint tile_y)
+{
+ struct intel_region *region;
+
+ region = calloc(1, sizeof *region);
+ if (region == NULL)
+ return NULL;
+
+ region-bo = parent_region-bo;
+ drm_intel_bo_reference(region-bo);
+
+ region-cpp = cpp;
+ region-width = width;
+ region-height = height;
+ region-pitch = pitch;
+ region-refcount = 1;
+ region-tiling = parent_region-tiling;
+ region-offset = offset;
+ region-tile_x = tile_x;
+ region-tile_y = tile_y;
+
+ return region;
+}
+
void
intel_region_reference(struct intel_region **dst, struct intel_region *src)
{
diff --git a/src/mesa/drivers/dri/i965/intel_regions.h
b/src/mesa/drivers/dri/i965/intel_regions.h
index 05dfef3..58a6dd1 100644
--- a/src/mesa/drivers/dri/i965/intel_regions.h
+++ b/src/mesa/drivers/dri/i965/intel_regions.h
@@ -70,6 +70,11 @@ struct intel_region
uint32_t tiling; /** Which tiling mode the region is in */
uint32_t name; /** Global name for the bo */
+
+ /** Describe the offset of the region within the bo */
+ uint32_t offset;
+ GLuint tile_x;
+ GLuint tile_y;
};
@@ -95,6 +100,12 @@ intel_region_alloc_for_fd(struct intel_screen *screen,
[Mesa-dev] [PATCH 2/4] i965: Change intel_region interface to not depend on intelScreen
From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
The only field from intelScreen used by the intel_region code is the
drm_intel_bufmgr, so take that as a parameter instead of the whole
screen.
---
src/mesa/drivers/dri/i965/brw_context.c |2 +-
src/mesa/drivers/dri/i965/intel_mipmap_tree.c |4 ++--
src/mesa/drivers/dri/i965/intel_regions.c | 20 ++--
src/mesa/drivers/dri/i965/intel_regions.h |7 +++
src/mesa/drivers/dri/i965/intel_screen.c |9 +
5 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index ffbfb43..4c8b61d 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -1291,7 +1291,7 @@ intel_process_dri2_buffer(struct brw_context *brw,
}
intel_miptree_release(rb-mt);
- region = intel_region_alloc_for_handle(brw-intelScreen,
+ region = intel_region_alloc_for_handle(brw-intelScreen-bufmgr,
buffer-cpp,
drawable-w,
drawable-h,
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index 884ddef..7eaaa59 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -563,7 +563,7 @@ intel_miptree_create(struct brw_context *brw,
bool y_or_x = tiling == (I915_TILING_Y | I915_TILING_X);
mt-etc_format = etc_format;
- mt-region = intel_region_alloc(brw-intelScreen,
+ mt-region = intel_region_alloc(brw-intelScreen-bufmgr,
y_or_x ? I915_TILING_Y : tiling,
mt-cpp,
total_width,
@@ -579,7 +579,7 @@ intel_miptree_create(struct brw_context *brw,
mt-total_width, mt-total_height);
intel_region_release(mt-region);
- mt-region = intel_region_alloc(brw-intelScreen,
+ mt-region = intel_region_alloc(brw-intelScreen-bufmgr,
I915_TILING_X,
mt-cpp,
total_width,
diff --git a/src/mesa/drivers/dri/i965/intel_regions.c
b/src/mesa/drivers/dri/i965/intel_regions.c
index 8ad6129..65213d0 100644
--- a/src/mesa/drivers/dri/i965/intel_regions.c
+++ b/src/mesa/drivers/dri/i965/intel_regions.c
@@ -105,7 +105,7 @@ debug_backtrace(void)
#endif
static struct intel_region *
-intel_region_alloc_internal(struct intel_screen *screen,
+intel_region_alloc_internal(drm_intel_bufmgr *bufmgr,
GLuint cpp,
GLuint width, GLuint height, GLuint pitch,
uint32_t tiling, drm_intel_bo *buffer)
@@ -129,7 +129,7 @@ intel_region_alloc_internal(struct intel_screen *screen,
}
struct intel_region *
-intel_region_alloc(struct intel_screen *screen,
+intel_region_alloc(drm_intel_bufmgr *bufmgr,
uint32_t tiling,
GLuint cpp, GLuint width, GLuint height,
bool expect_accelerated_upload)
@@ -142,13 +142,13 @@ intel_region_alloc(struct intel_screen *screen,
if (expect_accelerated_upload)
flags |= BO_ALLOC_FOR_RENDER;
- buffer = drm_intel_bo_alloc_tiled(screen-bufmgr, region,
+ buffer = drm_intel_bo_alloc_tiled(bufmgr, region,
width, height, cpp,
tiling, aligned_pitch, flags);
if (buffer == NULL)
return NULL;
- region = intel_region_alloc_internal(screen, cpp, width, height,
+ region = intel_region_alloc_internal(bufmgr, cpp, width, height,
aligned_pitch, tiling, buffer);
if (region == NULL) {
drm_intel_bo_unreference(buffer);
@@ -172,7 +172,7 @@ intel_region_flink(struct intel_region *region, uint32_t
*name)
}
struct intel_region *
-intel_region_alloc_for_handle(struct intel_screen *screen,
+intel_region_alloc_for_handle(drm_intel_bufmgr *bufmgr,
GLuint cpp,
GLuint width, GLuint height, GLuint pitch,
GLuint handle, const char *name)
@@ -182,7 +182,7 @@ intel_region_alloc_for_handle(struct intel_screen *screen,
int ret;
uint32_t bit_6_swizzle, tiling;
- buffer = intel_bo_gem_create_from_name(screen-bufmgr, name, handle);
+ buffer = intel_bo_gem_create_from_name(bufmgr, name, handle);
if (buffer == NULL)
return NULL;
ret = drm_intel_bo_get_tiling(buffer, tiling, bit_6_swizzle);
@@ -193,7 +193,7 @@ intel_region_alloc_for_handle(struct intel_screen *screen,
return NULL;
}
- region = intel_region_alloc_internal(screen, cpp,
+ region = intel_region_alloc_internal(bufmgr, cpp,
[Mesa-dev] [PATCH 4/4] i965: Refactor DRI image code
From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
The DRI image extension gained a lot of new entry points lately. Some
of the new additions have a slightly different signature. The planar
image introduces the concept of an image without a format from which
different well structured images can be created. The way this has
been done means that one can't aways rely on all of the fields in a
__DRIimage to be valid or useable.
This patch tries to make the whole implementation more consistent. All
images become planar with a valid intel_image_format. The dri_image and
gl_format fields are dropped, and when creating an image from a texture
or renderbuffer, a custom intel_image_format is allocated to match that
of the original object. Every image has at least one plane and a field
inside the image tells to which plane that particular image refers to.
For allocating the image, both DRI_FORMAT_* and DRI_FOURCC_* were used.
Now the allocation code always takes fourcc and the extension entry
points convert from dri format when necessary. Also, intel_image_format
now holds a regular gl_format, so dri_format is not used internally
anymore.
The bulk of the image code is moved to a separate file and the part in
intel_screen.c only does some parameter conversion and calls into the
other file.
---
src/mesa/drivers/dri/i965/Makefile.sources |1 +
src/mesa/drivers/dri/i965/intel_fbo.c | 11 +-
src/mesa/drivers/dri/i965/intel_image.c | 390
src/mesa/drivers/dri/i965/intel_image.h | 73 +
src/mesa/drivers/dri/i965/intel_regions.h |9 +-
src/mesa/drivers/dri/i965/intel_screen.c| 427 +--
src/mesa/drivers/dri/i965/intel_tex_image.c |8 +-
7 files changed, 559 insertions(+), 360 deletions(-)
create mode 100644 src/mesa/drivers/dri/i965/intel_image.c
create mode 100644 src/mesa/drivers/dri/i965/intel_image.h
diff --git a/src/mesa/drivers/dri/i965/Makefile.sources
b/src/mesa/drivers/dri/i965/Makefile.sources
index 5724458..abd9890 100644
--- a/src/mesa/drivers/dri/i965/Makefile.sources
+++ b/src/mesa/drivers/dri/i965/Makefile.sources
@@ -10,6 +10,7 @@ i965_FILES = \
intel_debug.c \
intel_extensions.c \
intel_fbo.c \
+ intel_image.c \
intel_mipmap_tree.c \
intel_regions.c \
intel_resolve_map.c \
diff --git a/src/mesa/drivers/dri/i965/intel_fbo.c
b/src/mesa/drivers/dri/i965/intel_fbo.c
index ae978f1..87c3b33 100644
--- a/src/mesa/drivers/dri/i965/intel_fbo.c
+++ b/src/mesa/drivers/dri/i965/intel_fbo.c
@@ -254,6 +254,7 @@ intel_image_target_renderbuffer_storage(struct gl_context
*ctx,
struct intel_renderbuffer *irb;
__DRIscreen *screen;
__DRIimage *image;
+ gl_format format;
screen = brw-intelScreen-driScrnPriv;
image = screen-dri2.image-lookupEGLImage(screen, image_handle,
@@ -261,7 +262,7 @@ intel_image_target_renderbuffer_storage(struct gl_context
*ctx,
if (image == NULL)
return;
- if (image-planar_format image-planar_format-nplanes 1) {
+ if (image-format-nplanes 1) {
_mesa_error(ctx, GL_INVALID_OPERATION,
glEGLImageTargetRenderbufferStorage(planar buffers are not
supported as render targets.);
@@ -276,7 +277,9 @@ intel_image_target_renderbuffer_storage(struct gl_context
*ctx,
}
/* __DRIimage is opaque to the core so it has to be checked here */
- switch (image-format) {
+ format = image-format-planes[0].format;
+
+ switch (format) {
case MESA_FORMAT_RGBA_REV:
_mesa_error(ctx, GL_INVALID_OPERATION,
glEGLImageTargetRenderbufferStorage(unsupported image format);
@@ -290,7 +293,7 @@ intel_image_target_renderbuffer_storage(struct gl_context
*ctx,
intel_miptree_release(irb-mt);
irb-mt = intel_miptree_create_for_bo(brw,
image-region-bo,
- image-format,
+ format,
image-region-offset,
image-region-width,
image-region-height,
@@ -302,7 +305,7 @@ intel_image_target_renderbuffer_storage(struct gl_context
*ctx,
rb-InternalFormat = image-internal_format;
rb-Width = image-region-width;
rb-Height = image-region-height;
- rb-Format = image-format;
+ rb-Format = format;
rb-_BaseFormat = _mesa_base_fbo_format(ctx, image-internal_format);
rb-NeedsFinishRenderTexture = true;
}
diff --git a/src/mesa/drivers/dri/i965/intel_image.c
b/src/mesa/drivers/dri/i965/intel_image.c
new file mode 100644
index 000..cb258cf
--- /dev/null
+++ b/src/mesa/drivers/dri/i965/intel_image.c
@@ -0,0 +1,390 @@
+/*
+ * Copyright © 2013 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files
Re: [Mesa-dev] [PATCH] mesa: add assert after calloc before access memory in attrib.c
Adding assertions won't fix the errors found by the static analysis tool
because they don't exist in release builds. The technical correct way
to deal with memory allocation failures in GL is to generate
GL_OUT_OF_MEMORY and return.
On 11/27/2013 06:53 AM, Juha-Pekka Heikkila wrote:
Signed-off-by: Juha-Pekka Heikkila juhapekka.heikk...@gmail.com
---
src/mesa/main/attrib.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/mesa/main/attrib.c b/src/mesa/main/attrib.c
index c9332bd..5185f89 100644
--- a/src/mesa/main/attrib.c
+++ b/src/mesa/main/attrib.c
@@ -1488,6 +1488,9 @@ init_array_attrib_data(struct gl_context *ctx,
{
/* Get a non driver gl_array_object. */
attrib-ArrayObj = CALLOC_STRUCT( gl_array_object );
+
+ assert(attrib-ArrayObj != NULL);
+
_mesa_initialize_array_object(ctx, attrib-ArrayObj, 0);
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965/gen6: Fix multisample resolve blits for luminance/intensity 32F formats.
On gen6, multisamble resolve blits use the SAMPLE message to blend
together the 4 samples for each texel. For some reason, SAMPLE
doesn't blend together the proper samples when the source format is
L32_FLOAT or I32_FLOAT, resulting in blocky artifacts.
To work around this problem, sample from the source surface using
R32_FLOAT. This shouldn't affect rendering correctness, because when
doing these resolve blits, the destination format is R32_FLOAT, so the
channel replication done by L32_FLOAT and I32_FLOAT is unnecessary.
Fixes piglit tests on Sandy Bridge:
- spec/ARB_texture_float/multisample-formats 2 GL_ARB_texture_float
- spec/ARB_texture_float/multisample-formats 4 GL_ARB_texture_float
No piglit regressions on Sandy Bridge.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70601
Cc: Kenneth Graunke kenn...@whitecape.org
Cc: mesa-sta...@lists.freedesktop.org
---
src/mesa/drivers/dri/i965/brw_blorp_blit.cpp | 15 +++
1 file changed, 15 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
index 2d2edc1..9c48eac 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
@@ -2099,6 +2099,21 @@ brw_blorp_blit_params::brw_blorp_blit_params(struct
brw_context *brw,
src.brw_surfaceformat = dst.brw_surfaceformat;
}
+ /* When doing a multisample resolve of a GL_LUMINANCE32F or GL_INTENSITY32F
+* texture, the above code configures the source format for L32_FLOAT or
+* I32_FLOAT, and the destination format for R32_FLOAT. On Sandy Bridge,
+* the SAMPLE message appears to handle multisampled L32_FLOAT and
+* I32_FLOAT textures incorrectly, resulting in blocky artifacts. So work
+* around the problem by using a source format of R32_FLOAT. This
+* shouldn't affect rendering correctness, since the destination format is
+* R32_FLOAT, so only the contents of the red channel matters.
+*/
+ if (brw-gen == 6 src.num_samples 1 dst.num_samples = 1
+ src_mt-format == dst_mt-format
+ dst.brw_surfaceformat == BRW_SURFACEFORMAT_R32_FLOAT) {
+ src.brw_surfaceformat = dst.brw_surfaceformat;
+ }
+
use_wm_prog = true;
memset(wm_prog_key, 0, sizeof(wm_prog_key));
--
1.8.4.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Enable ARB_map_buffer_alignment in all drivers - first try
On 11/26/2013 07:42 PM, Timothy Arceri wrote: Hi Thomas, Looks like Siavash Eliasi beat you to it. But here is some quick feedback. You seem to have made the same mistake with your case statements [1] Also you shouldn't attach the patch to your email but should use git-send-email there is a link to more info on the Newbie page ;) I did a quick skim, and it looks like most of the Thomas's and Siavash's changes are similar. Another way Thomas could help is by reviewing Siavash's patches... places where they're the same can get a trivial Reviewed-by. Places where they're different should incite some disucssion. As for the remaining Newbie tasks it looks like work has been started on those [2] but the ARB_clear_buffer_object work hasn't been tested so you could have a go at writing the piglit tests this would give you a good understanding on the spec and what the extension is meant to do from there you might be able to fix up any issues with the patch. [1]http://lists.freedesktop.org/archives/mesa-dev/2013-November/049054.html [2]http://lists.freedesktop.org/archives/mesa-dev/2013-November/048944.html On Tue, 2013-11-26 at 19:48 +, Thomas Prescher wrote: Hi, today I read an article on phoronix (http://www.phoronix.com/scan.php?page=news_itempx=MTUyNDY) which linked to a wiki page (http://wiki.freedesktop.org/dri/NewbieProjects/) where easy projects to start with were listed. I gave it a shot and tried to implement the ARB_map_buffer_alignment extensions for all drivers. Long story short, here is the patch I've created. I'm not completely sure whether everything I did was what the creator of the wiki page had in mind. I am especially unsure about the last item. Ofc it would be very great iff one of you guys can provide some feedback :) -Thomas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa/llvmpipe: add fake MSAA support
Looks great. Thanks for doing this! Future is now.
Jose
- Original Message -
This adds a gallium cap that allows us to fake GL3.0 by
not exposing MSAA on sw rendering. It also forces the
extra extensions needed for GL3.2. Along with a patch to
raise the GLSL version in llvmpipe this will expose GL3.3
on llvmpipe.
However we still need Marek's code for layered clears.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/gallium/drivers/llvmpipe/lp_screen.c | 2 ++
src/gallium/include/pipe/p_defines.h | 3 ++-
src/mesa/main/mtypes.h | 1 +
src/mesa/main/version.c | 2 +-
src/mesa/state_tracker/st_extensions.c | 7 +++
5 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c
b/src/gallium/drivers/llvmpipe/lp_screen.c
index f61df98..218b3f8 100644
--- a/src/gallium/drivers/llvmpipe/lp_screen.c
+++ b/src/gallium/drivers/llvmpipe/lp_screen.c
@@ -234,6 +234,8 @@ llvmpipe_get_param(struct pipe_screen *screen, enum
pipe_cap param)
return PIPE_MAX_VIEWPORTS;
case PIPE_CAP_ENDIANNESS:
return PIPE_ENDIAN_NATIVE;
+ case PIPE_CAP_FAKE_SW_MSAA:
+ return 1;
}
/* should only get here on unhandled cases */
debug_printf(Unexpected PIPE_CAP %d query\n, param);
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/include/pipe/p_defines.h
index db6db32..27f1bcf 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -513,7 +513,8 @@ enum pipe_cap {
PIPE_CAP_MAX_TEXTURE_BUFFER_SIZE = 83,
PIPE_CAP_MAX_VIEWPORTS = 84,
PIPE_CAP_ENDIANNESS = 85,
- PIPE_CAP_MIXED_FRAMEBUFFER_SIZES = 86
+ PIPE_CAP_MIXED_FRAMEBUFFER_SIZES = 86,
+ PIPE_CAP_FAKE_SW_MSAA = 87
};
#define PIPE_QUIRK_TEXTURE_BORDER_COLOR_SWIZZLE_NV50 (1 0)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index ecfb5e0..39b8abd 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -3302,6 +3302,7 @@ struct gl_constants
/** GL_ARB_vertex_attrib_binding */
GLint MaxVertexAttribRelativeOffset;
GLint MaxVertexAttribBindings;
+ GLboolean FakeSWMSAA;
};
diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index 55411fa..1dfce09 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/version.c
@@ -229,7 +229,7 @@ compute_version(struct gl_context *ctx)
ctx-Extensions.EXT_texture_sRGB);
const GLboolean ver_3_0 = (ver_2_1
ctx-Const.GLSLVersion = 130
- ctx-Const.MaxSamples = 4
+ (ctx-Const.MaxSamples = 4 ||
ctx-Const.FakeSWMSAA)
(ctx-API == API_OPENGL_CORE ||
ctx-Extensions.ARB_color_buffer_float)
ctx-Extensions.ARB_depth_buffer_float
diff --git a/src/mesa/state_tracker/st_extensions.c
b/src/mesa/state_tracker/st_extensions.c
index cd10a0c..701086a 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -715,6 +715,13 @@ void st_init_extensions(struct st_context *st)
ctx-Extensions.EXT_framebuffer_multisample_blit_scaled = GL_TRUE;
}
+ if (ctx-Const.MaxSamples == 0 screen-get_param(screen,
PIPE_CAP_FAKE_SW_MSAA)) {
+ ctx-Const.FakeSWMSAA = GL_TRUE;
+ctx-Extensions.EXT_framebuffer_multisample = GL_TRUE;
+ctx-Extensions.EXT_framebuffer_multisample_blit_scaled = GL_TRUE;
+ctx-Extensions.ARB_texture_multisample = GL_TRUE;
+ }
+
if (ctx-Const.MaxDualSourceDrawBuffers 0
!st-options.disable_blend_func_extended)
ctx-Extensions.ARB_blend_func_extended = GL_TRUE;
--
1.8.3.1
___
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=1xgfm7klIhkbdFhXv%2BVT%2BbSODyva1JcPkn8e6J5df6k%3D%0As=b9c729d850a706176cc517e7516cc780e4bd2672a660c5a646045dbb3329379c
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] trace: Dump PIPE_QUERY_* enums.
From: José Fonseca jfons...@vmware.com
---
src/gallium/auxiliary/util/u_dump.h | 3 ++
src/gallium/auxiliary/util/u_dump_defines.c | 33
src/gallium/drivers/trace/tr_context.c | 3 +-
src/gallium/drivers/trace/tr_dump_defines.h | 58 +
src/gallium/drivers/trace/tr_dump_state.c | 10 +
src/gallium/drivers/trace/tr_dump_state.h | 3 --
src/gallium/drivers/trace/tr_screen.c | 3 +-
7 files changed, 98 insertions(+), 15 deletions(-)
create mode 100644 src/gallium/drivers/trace/tr_dump_defines.h
diff --git a/src/gallium/auxiliary/util/u_dump.h
b/src/gallium/auxiliary/util/u_dump.h
index 71750a6..58e7dfd 100644
--- a/src/gallium/auxiliary/util/u_dump.h
+++ b/src/gallium/auxiliary/util/u_dump.h
@@ -85,6 +85,9 @@ util_dump_tex_mipfilter(unsigned value, boolean shortened);
const char *
util_dump_tex_filter(unsigned value, boolean shortened);
+const char *
+util_dump_query_type(unsigned value, boolean shortened);
+
/*
* p_state.h, through a FILE
diff --git a/src/gallium/auxiliary/util/u_dump_defines.c
b/src/gallium/auxiliary/util/u_dump_defines.c
index cc62687..03fd15d 100644
--- a/src/gallium/auxiliary/util/u_dump_defines.c
+++ b/src/gallium/auxiliary/util/u_dump_defines.c
@@ -359,3 +359,36 @@ util_dump_tex_filter_short_names[] = {
};
DEFINE_UTIL_DUMP_CONTINUOUS(tex_filter)
+
+
+static const char *
+util_dump_query_type_names[] = {
+ PIPE_QUERY_OCCLUSION_COUNTER,
+ PIPE_QUERY_OCCLUSION_PREDICATE,
+ PIPE_QUERY_TIMESTAMP,
+ PIPE_QUERY_TIMESTAMP_DISJOINT,
+ PIPE_QUERY_TIME_ELAPSED,
+ PIPE_QUERY_PRIMITIVES_GENERATED,
+ PIPE_QUERY_PRIMITIVES_EMITTED,
+ PIPE_QUERY_SO_STATISTICS,
+ PIPE_QUERY_SO_OVERFLOW_PREDICATE,
+ PIPE_QUERY_GPU_FINISHED,
+ PIPE_QUERY_PIPELINE_STATISTICS,
+};
+
+static const char *
+util_dump_query_type_short_names[] = {
+ occlusion_counter,
+ occlusion_predicate,
+ timestamp,
+ timestamp_disjoint,
+ time_elapsed,
+ primitives_generated,
+ primitives_emitted,
+ so_statistics,
+ so_overflow_predicate,
+ gpu_finished,
+ pipeline_statistics,
+};
+
+DEFINE_UTIL_DUMP_CONTINUOUS(query_type)
diff --git a/src/gallium/drivers/trace/tr_context.c
b/src/gallium/drivers/trace/tr_context.c
index d9afb0a..4ac7d9b 100644
--- a/src/gallium/drivers/trace/tr_context.c
+++ b/src/gallium/drivers/trace/tr_context.c
@@ -33,6 +33,7 @@
#include pipe/p_screen.h
#include tr_dump.h
+#include tr_dump_defines.h
#include tr_dump_state.h
#include tr_public.h
#include tr_screen.h
@@ -135,7 +136,7 @@ trace_context_create_query(struct pipe_context *_pipe,
trace_dump_call_begin(pipe_context, create_query);
trace_dump_arg(ptr, pipe);
- trace_dump_arg(uint, query_type);
+ trace_dump_arg(query_type, query_type);
query = pipe-create_query(pipe, query_type);
diff --git a/src/gallium/drivers/trace/tr_dump_defines.h
b/src/gallium/drivers/trace/tr_dump_defines.h
new file mode 100644
index 000..0c83c2b
--- /dev/null
+++ b/src/gallium/drivers/trace/tr_dump_defines.h
@@ -0,0 +1,58 @@
+/**
+ *
+ * Copyright 2013 VMware, Inc.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * Software), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
+ * IN NO EVENT SHALL VMWARE AND/OR ITS SUPPLIERS BE LIABLE FOR
+ * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
+ * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
+ * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ **/
+
+#ifndef TR_DUMP_DEFINES_H_
+#define TR_DUMP_DEFINES_H_
+
+#include pipe/p_compiler.h
+#include util/u_format.h
+#include util/u_dump.h
+#include tr_dump.h
+
+
+static INLINE void
+trace_dump_format(enum pipe_format format)
+{
+ if (!trace_dumping_enabled_locked())
+ return;
+
+ trace_dump_enum(util_format_name(format));
+}
+
+
+static INLINE void
+trace_dump_query_type(unsigned value)
+{
+ if (!trace_dumping_enabled_locked())
+ return;
+
+ trace_dump_enum(util_dump_query_type(value, FALSE));
+}
+
+
+
+#endif /* TR_DUMP_DEFINES_H_ */
diff --git
Re: [Mesa-dev] [PATCH] i965/gen6: Fix multisample resolve blits for luminance/intensity 32F formats.
On 11/27/2013 08:37 AM, Paul Berry wrote:
On gen6, multisamble resolve blits use the SAMPLE message to blend
together the 4 samples for each texel. For some reason, SAMPLE
doesn't blend together the proper samples when the source format is
L32_FLOAT or I32_FLOAT, resulting in blocky artifacts.
To work around this problem, sample from the source surface using
R32_FLOAT. This shouldn't affect rendering correctness, because when
doing these resolve blits, the destination format is R32_FLOAT, so the
channel replication done by L32_FLOAT and I32_FLOAT is unnecessary.
Fixes piglit tests on Sandy Bridge:
- spec/ARB_texture_float/multisample-formats 2 GL_ARB_texture_float
- spec/ARB_texture_float/multisample-formats 4 GL_ARB_texture_float
No piglit regressions on Sandy Bridge.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70601
Cc: Kenneth Graunke kenn...@whitecape.org
Cc: mesa-sta...@lists.freedesktop.org
---
src/mesa/drivers/dri/i965/brw_blorp_blit.cpp | 15 +++
1 file changed, 15 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
index 2d2edc1..9c48eac 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
@@ -2099,6 +2099,21 @@ brw_blorp_blit_params::brw_blorp_blit_params(struct
brw_context *brw,
src.brw_surfaceformat = dst.brw_surfaceformat;
}
+ /* When doing a multisample resolve of a GL_LUMINANCE32F or
GL_INTENSITY32F
+* texture, the above code configures the source format for L32_FLOAT or
+* I32_FLOAT, and the destination format for R32_FLOAT. On Sandy Bridge,
+* the SAMPLE message appears to handle multisampled L32_FLOAT and
+* I32_FLOAT textures incorrectly, resulting in blocky artifacts. So work
+* around the problem by using a source format of R32_FLOAT. This
+* shouldn't affect rendering correctness, since the destination format is
+* R32_FLOAT, so only the contents of the red channel matters.
+*/
+ if (brw-gen == 6 src.num_samples 1 dst.num_samples = 1
+ src_mt-format == dst_mt-format
+ dst.brw_surfaceformat == BRW_SURFACEFORMAT_R32_FLOAT) {
+ src.brw_surfaceformat = dst.brw_surfaceformat;
+ }
+
use_wm_prog = true;
memset(wm_prog_key, 0, sizeof(wm_prog_key));
I wasn't sure whether we should apply this more broadly, since any L or
I - R blit could sensibly be overridden. But I kind of like how you've
isolated the exact case that's broken and needs special treatment.
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Feasibility of KHR_gl_texture_cubemap_image in mesa/gallium
.. let me try that again. I've been looking into adding support for the KHR_gl_*_image extensions to mesa/gallium as was attempted here: http://lists.freedesktop.org/archives/mesa-dev/2010-September/002900.html Looking further into how creating an eglimage out of a cubemap face has got me wondering whether or not it's feasible in the gallium framework. The trouble I'm seeing is that texture memory is hidden from the state_tracker layer as the state_tracker can only see a pipe_resource or a winsys handle not how the various cubemap faces are layed out in memory. pipe_resources for a cubemap texture have a specific type (PIPE_TARGET_CUBEMAP) and I presume that the underlying driver implementation is free to allocate memory for cubemaps in whatever way it sees fit (i.e. it's not stipulated by the gallium interface). So then if a user wants to take an eglimage sourced from a cubemap texture and then use that to target a 2D texture, the created 2D texture has to somehow reference the memory attached to the cubemap pipe_resource, but only one face of it. I can think of two general approaches: (1) Somehow create a pipe_resource with a winsys handle that points to only a sub-face of memory attached to the cubemap pipe_resource. (2) Find a way to use the cubemap pipe_resource such that we only look at one face and it behaves like a 2D texture. I thought (2) could perhaps be accomplished with sampler_views. But any experimenting I've done there has convinced me that a sampler_view (with first_layer and last_layer restricted to the face that I care about) can't convince the underlying driver/GPU to make the cupemap texture behave like a 2d texture. And for (1), I haven't seen any mechanisms that allow for this kind of sub-referencing of memory regions. So my question is, does anyone with more experience with gallium / the mesa state_tracker have an idea of how targeting a 2D texture with an eglimage sourced from a cubemap face would work? Are any of my above assumptions/conclusions incorrect? Thanks. On Wed, Nov 27, 2013 at 1:04 PM, Ryan Morris ryanmorris...@gmail.comwrote: Hi, This is my first post to this forum, so apologies if I say anything horrendously wrong. I've been looking into adding support for the KHR_gl_*_image extensions to mesa/gallium as was attempted here: ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/6] glsl: Create an accessor for the built-in function shader.
On 11/23/2013 05:45 PM, Kenneth Graunke wrote: On 11/23/2013 04:03 PM, Ian Romanick wrote: Would it be better to just make _mesa_glsl_get_builtin_function_shader a friend? In this case, I don't think it makes much practical difference - the builtin_builder class is entirely contained within the builtin_functions.cpp file. So making this public is basically making all the ordinary functions at the bottom of the file friends, which seems fairly reasonable. --Ken Ian, after that answer, are you okay with the patch? Or would you like it changed? --Ken ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl: Remove unused field loop_variable_state::loop.
This field was neither initialized nor used. It was just dead memory. --- src/glsl/loop_analysis.h | 5 - 1 file changed, 5 deletions(-) diff --git a/src/glsl/loop_analysis.h b/src/glsl/loop_analysis.h index 769d626..98414b3 100644 --- a/src/glsl/loop_analysis.h +++ b/src/glsl/loop_analysis.h @@ -71,11 +71,6 @@ public: /** -* Loop whose variable state is being tracked by this structure -*/ - ir_loop *loop; - - /** * Variables that have not yet been classified */ exec_list variables; -- 1.8.4.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: Remove unused field loop_variable_state::loop.
On 11/27/2013 10:59 AM, Paul Berry wrote: This field was neither initialized nor used. It was just dead memory. --- src/glsl/loop_analysis.h | 5 - 1 file changed, 5 deletions(-) diff --git a/src/glsl/loop_analysis.h b/src/glsl/loop_analysis.h index 769d626..98414b3 100644 --- a/src/glsl/loop_analysis.h +++ b/src/glsl/loop_analysis.h @@ -71,11 +71,6 @@ public: /** -* Loop whose variable state is being tracked by this structure -*/ - ir_loop *loop; - - /** * Variables that have not yet been classified */ exec_list variables; Sounds good to me. Reviewed-by: Kenneth Graunke kenn...@whitecape.org ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Feasibility of KHR_gl_texture_cubemap_image in mesa/gallium
This should be possible with: struct pipe_resource * (*resource_from_handle)(struct pipe_screen *, const struct pipe_resource *templat, struct winsys_handle *handle); Nothing impedes this to work with cubemaps. templat needs to match of course, and it is assumed that given the same template and handle info, the same layout will be replicated. If more info is necesary, the struct winsys_handle should have the information -- struct winsys_handle could have any members desired, or be a pointer to a shared memory where all the layout is described. All the state tracker needs to know is which face to use, when creating the sampler/surface views. Jose - Original Message - .. let me try that again. I've been looking into adding support for the KHR_gl_*_image extensions to mesa/gallium as was attempted here: http://lists.freedesktop.org/archives/mesa-dev/2010-September/002900.html Looking further into how creating an eglimage out of a cubemap face has got me wondering whether or not it's feasible in the gallium framework. The trouble I'm seeing is that texture memory is hidden from the state_tracker layer as the state_tracker can only see a pipe_resource or a winsys handle not how the various cubemap faces are layed out in memory. pipe_resources for a cubemap texture have a specific type (PIPE_TARGET_CUBEMAP) and I presume that the underlying driver implementation is free to allocate memory for cubemaps in whatever way it sees fit (i.e. it's not stipulated by the gallium interface). So then if a user wants to take an eglimage sourced from a cubemap texture and then use that to target a 2D texture, the created 2D texture has to somehow reference the memory attached to the cubemap pipe_resource, but only one face of it. I can think of two general approaches: (1) Somehow create a pipe_resource with a winsys handle that points to only a sub-face of memory attached to the cubemap pipe_resource. (2) Find a way to use the cubemap pipe_resource such that we only look at one face and it behaves like a 2D texture. I thought (2) could perhaps be accomplished with sampler_views. But any experimenting I've done there has convinced me that a sampler_view (with first_layer and last_layer restricted to the face that I care about) can't convince the underlying driver/GPU to make the cupemap texture behave like a 2d texture. And for (1), I haven't seen any mechanisms that allow for this kind of sub-referencing of memory regions. So my question is, does anyone with more experience with gallium / the mesa state_tracker have an idea of how targeting a 2D texture with an eglimage sourced from a cubemap face would work? Are any of my above assumptions/conclusions incorrect? Thanks. On Wed, Nov 27, 2013 at 1:04 PM, Ryan Morris ryanmorris...@gmail.com wrote: Hi, This is my first post to this forum, so apologies if I say anything horrendously wrong. I've been looking into adding support for the KHR_gl_*_image extensions to mesa/gallium as was attempted here: ___ 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=Iex6Y9OBTPLHmrCnHXxtJDPlHBsprQK0Oa3EW6tPgJE%3D%0As=6dd50ee644eb2f6c109c94a5110dc633528ca381d1c223c39904e8436fb29621 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/4] glsl: Improve documentation of ir_loop counter/control fields.
---
src/glsl/ir.h | 34 --
1 file changed, 28 insertions(+), 6 deletions(-)
diff --git a/src/glsl/ir.h b/src/glsl/ir.h
index 4f775da..b898d61 100644
--- a/src/glsl/ir.h
+++ b/src/glsl/ir.h
@@ -1032,13 +1032,33 @@ public:
* If \c from and \c to are the same value, the loop will execute once.
*/
/*@{*/
- ir_rvalue *from; /** Value of the loop counter on the first
-* iteration of the loop.
-*/
- ir_rvalue *to; /** Value of the loop counter on the last
-* iteration of the loop.
-*/
+
+ /**
+* Value which should be assigned to \c counter before the first iteration
+* of the loop. Must be non-null whenever \c counter is non-null, and vice
+* versa.
+*/
+ ir_rvalue *from;
+
+ /**
+* Value which \c counter should be compared to in order to determine
+* whether to exit the loop. Must be non-null whenever \c counter is
+* non-null, and vice versa.
+*/
+ ir_rvalue *to;
+
+ /**
+* Value which should be added to \c counter at the end of each loop
+* iteration. Must be non-null whenever \c counter is non-null, and vice
+* versa.
+*/
ir_rvalue *increment;
+
+ /**
+* Variable which counts loop iterations. This is a brand new ir_variable
+* declaration (not a reference to a previously declared ir_variable, as in
+* ir_dereference_variable).
+*/
ir_variable *counter;
/**
@@ -1047,6 +1067,8 @@ public:
* If any of the loop control fields are non-\c NULL, this field must be
* one of \c ir_binop_less, \c ir_binop_greater, \c ir_binop_lequal,
* \c ir_binop_gequal, \c ir_binop_equal, or \c ir_binop_nequal.
+*
+* Ignored if \c counter is NULL.
*/
int cmp;
/*@}*/
--
1.8.4.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/4] glsl: Fix inconsistent assumptions about ir_loop::counter.
The compiler back-ends (i965's fs_visitor and brw_visitor,
ir_to_mesa_visitor, and glsl_to_tgsi_visitor) assume that when
ir_loop::counter is non-null, it points to a fresh ir_variable that
should be used as the loop counter (as opposed to an ir_variable that
exists elsewhere in the instruction stream).
However, previous to this patch:
(1) loop_control_visitor did not create a new variable for
ir_loop::counter; instead it re-used the existing ir_variable.
This caused the loop counter to be double-incremented (once
explicitly by the body of the loop, and once implicitly by
ir_loop::increment).
(2) ir_clone did not clone ir_loop::counter properly, resulting in the
cloned ir_loop pointing to the source ir_loop's counter.
(3) ir_hierarchical_visitor did not visit ir_loop::counter, resulting
in the ir_variable being missed by reparenting.
Additionally, most optimization passes (e.g. loop unrolling) assume
that the variable mentioned by ir_loop::counter is not accessed in the
body of the loop (an assumption which (1) violates).
The combination of these factors caused a perfect storm in which the
code worked properly nearly all of the time: for loops that got
unrolled, (1) would introduce a double-increment, but loop unrolling
would fail to notice it (since it assumes that ir_loop::counter is not
accessed in the body of the loop), so it would unroll the loop the
correct number of times. For loops that didn't get unrolled, (1)
would introduce a double-increment, but then later when the IR was
cloned for linking, (2) would prevent the loop counter from being
cloned properly, so it would look to further analysis stages like an
independent variable (and hence the double-increment would stop
occurring). At the end of linking, (3) would prevent the loop counter
from being reparented, so it would still belong to the shader object
rather than the linked program object. Provided that the client
program didn't delete the shader object, the memory would never get
reclaimed, and so the shader would function properly.
However, for loops that didn't get unrolled, if the client program did
delete the shader object, and the memory belonging to the loop counter
got re-used, this could cause a use-after-free bug, leading to a
crash.
This patch fixes loop_control_visitor, ir_clone, and
ir_hierarchical_visitor to treat ir_loop::counter the same way the
back-ends treat it: as a freshly allocated ir_variable that needs to
be visited and cloned independently of other ir_variables.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72026
---
src/glsl/ir_clone.cpp | 3 ++-
src/glsl/ir_hv_accept.cpp | 6 ++
src/glsl/loop_controls.cpp | 2 +-
3 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/src/glsl/ir_clone.cpp b/src/glsl/ir_clone.cpp
index 40ed33a..8f57499 100644
--- a/src/glsl/ir_clone.cpp
+++ b/src/glsl/ir_clone.cpp
@@ -163,7 +163,8 @@ ir_loop::clone(void *mem_ctx, struct hash_table *ht) const
new_loop-to = this-to-clone(mem_ctx, ht);
if (this-increment)
new_loop-increment = this-increment-clone(mem_ctx, ht);
- new_loop-counter = counter;
+ if (this-counter)
+ new_loop-counter = this-counter-clone(mem_ctx, ht);
foreach_iter(exec_list_iterator, iter, this-body_instructions) {
ir_instruction *ir = (ir_instruction *)iter.get();
diff --git a/src/glsl/ir_hv_accept.cpp b/src/glsl/ir_hv_accept.cpp
index 941b25e..a0fe3b9 100644
--- a/src/glsl/ir_hv_accept.cpp
+++ b/src/glsl/ir_hv_accept.cpp
@@ -87,6 +87,12 @@ ir_loop::accept(ir_hierarchical_visitor *v)
if (s != visit_continue)
return (s == visit_continue_with_parent) ? visit_continue : s;
+ if (this-counter) {
+ s = this-counter-accept(v);
+ if (s != visit_continue)
+ return (s == visit_continue_with_parent) ? visit_continue : s;
+ }
+
s = visit_list_elements(v, this-body_instructions);
if (s == visit_stop)
return s;
diff --git a/src/glsl/loop_controls.cpp b/src/glsl/loop_controls.cpp
index 2648193..0eb103f 100644
--- a/src/glsl/loop_controls.cpp
+++ b/src/glsl/loop_controls.cpp
@@ -254,7 +254,7 @@ loop_control_visitor::visit_leave(ir_loop *ir)
ir-from = init-clone(ir, NULL);
ir-to = limit-clone(ir, NULL);
ir-increment = lv-increment-clone(ir, NULL);
-ir-counter = lv-var;
+ir-counter = lv-var-clone(ir, NULL);
ir-cmp = cmp;
max_iterations = iterations;
--
1.8.4.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/4] glsl: In ir_validate, check that ir_loop::counter always refers to a new var.
The compiler back-ends (i965's fs_visitor and brw_visitor,
ir_to_mesa_visitor, and glsl_to_tgsi_visitor) have been assuming this
for some time. Thanks to the preceding patch, the compiler front-end
no longer breaks this assumption.
This patch adds code to validate the assumption so that if we have
future bugs, we'll be able to catch them earlier.
---
src/glsl/ir_validate.cpp | 13 +
1 file changed, 13 insertions(+)
diff --git a/src/glsl/ir_validate.cpp b/src/glsl/ir_validate.cpp
index 13e41a0..26d6388 100644
--- a/src/glsl/ir_validate.cpp
+++ b/src/glsl/ir_validate.cpp
@@ -63,6 +63,7 @@ public:
virtual ir_visitor_status visit_enter(ir_if *ir);
+ virtual ir_visitor_status visit_enter(ir_loop *ir);
virtual ir_visitor_status visit_leave(ir_loop *ir);
virtual ir_visitor_status visit_enter(ir_function *ir);
virtual ir_visitor_status visit_leave(ir_function *ir);
@@ -149,6 +150,18 @@ ir_validate::visit_enter(ir_if *ir)
ir_visitor_status
+ir_validate::visit_enter(ir_loop *ir)
+{
+ if (ir-counter != NULL hash_table_find(ht, ir-counter) != NULL) {
+ printf(ir_loop @ %p specifies already-declared variable `%s' @ %p\n,
+ (void *) ir, ir-counter-name, (void *) ir-counter);
+ abort();
+ }
+ return visit_continue;
+}
+
+
+ir_visitor_status
ir_validate::visit_leave(ir_loop *ir)
{
if (ir-counter != NULL) {
--
1.8.4.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/4] glsl: Teach ir_variable_refcount about ir_loop::counter variables.
If an ir_loop has a non-null counter field, the variable referred to
by this field is implicitly read and written by the loop. We need to
account for this in ir_variable_refcount, otherwise there is a danger
we will try to dead-code-eliminate the loop counter variable.
Note: at the moment the dead code elimination bug doesn't occur due to
a bug in ir_hierarchical_visitor: it doesn't visit the counter
field, so dead code elimination doesn't treat it as a candidate for
elimination. But the patch to follow will fix that bug, so we need to
fix ir_variable_refcount first in order to avoid breaking dead code
elimination.
---
src/glsl/ir_variable_refcount.cpp | 21 +
src/glsl/ir_variable_refcount.h | 1 +
2 files changed, 22 insertions(+)
diff --git a/src/glsl/ir_variable_refcount.cpp
b/src/glsl/ir_variable_refcount.cpp
index 923eb1a..425ed81 100644
--- a/src/glsl/ir_variable_refcount.cpp
+++ b/src/glsl/ir_variable_refcount.cpp
@@ -132,3 +132,24 @@ ir_variable_refcount_visitor::visit_leave(ir_assignment
*ir)
return visit_continue;
}
+
+
+ir_visitor_status
+ir_variable_refcount_visitor::visit_leave(ir_loop *ir)
+{
+ /* If the loop has a counter variable, it is implicitly referenced and
+* assigned to. Note that since the LHS of an assignment is counted as a
+* reference, we actually have to increment referenced_count by 2 so that
+* later code will know that the variable isn't just assigned to.
+*/
+ if (ir-counter != NULL) {
+ ir_variable_refcount_entry *entry =
+ this-get_variable_entry(ir-counter);
+ if (entry) {
+ entry-referenced_count += 2;
+ entry-assigned_count++;
+ }
+ }
+
+ return visit_continue;
+}
diff --git a/src/glsl/ir_variable_refcount.h b/src/glsl/ir_variable_refcount.h
index c15e811..03fa7b5 100644
--- a/src/glsl/ir_variable_refcount.h
+++ b/src/glsl/ir_variable_refcount.h
@@ -60,6 +60,7 @@ public:
virtual ir_visitor_status visit_enter(ir_function_signature *);
virtual ir_visitor_status visit_leave(ir_assignment *);
+ virtual ir_visitor_status visit_leave(ir_loop *);
ir_variable_refcount_entry *get_variable_entry(ir_variable *var);
--
1.8.4.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl: Don't emit empty declaration warning for a struct specifier
From: Ian Romanick ian.d.roman...@intel.com
The intention is that things like
int;
will generate a warning. However, we were also accidentally emitting
the same warning for things like
struct Foo { int x; };
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68838
Cc: Aras Pranckevicius a...@unity3d.com
Cc: 9.2 10.0 mesa-sta...@lists.freedesktop.org
---
I think it's okay for this to wait until 10.0.1. It's a fairly minor
issue, though it is annoying...
src/glsl/ast_to_hir.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 43cf497..37be1cb 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -2940,7 +2940,7 @@ ast_declarator_list::hir(exec_list *instructions,
precision_names[this-type-qualifier.precision],
type_name);
}
- } else {
+ } else if (this-type-specifier-structure == NULL) {
_mesa_glsl_warning(loc, state, empty declaration);
}
}
--
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] Fixed memory leak.
Patches 16, 17 are: Reviewed-by: Chris Forbes chr...@ijw.co.nz I'm not quite sure I buy the 4K alignment for i965 in patch 15 -- it's true that any real BO mappings will be 4K-aligned, but when we have to return a temporary chunk of memory this seems excessive. Ian? On Wed, Nov 27, 2013 at 11:26 PM, Siavash Eliasi siavashser...@gmail.com wrote: Thank you very much Alex for the tip. I'll modify commits and send a v2 series of patches. Before that I want to make sure that patch #17 is done correctly. I'll be thankful if someone finds time to review and comment on this patch: [Mesa-dev] [PATCH 17/17] Deleted gl_extensions::ARB_map_buffer_alignment and all of its use cases. http://lists.freedesktop.org/archives/mesa-dev/2013-November/049047.html Regards, Siavash Eliasi. On 11/26/2013 10:26 PM, Alex Deucher wrote: On Tue, Nov 26, 2013 at 1:22 PM, Siavash Eliasi siavashser...@gmail.com wrote: In general, when you fix problems in prior patches, you should integrate the fix into the original patch(es) where the problems were, update the commit message to note what bugs were fixed and then re-send the patch set. That prevents broken commits from getting into the git tree even if they are fixed in a later commit. You can use git rebase -i to integrate your fixes. Alex ___ 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 7/8] mesa: Remove support for GL_MESA_texture_array
On 11/26/2013 03:54 PM, Ian Romanick wrote:
From: Ian Romanick ian.d.roman...@intel.com
This extension enabled the use of texture array with fixed-function and
assembly fragment shaders. No applications are known to use this
extension.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
I'm going to temporarily NAK this patch and the next one. There appear
to be some paths in meta (glCopyTexSubImage2D) that rely on using
texture arrays with fixed-function. :(
---
docs/relnotes/10.1.html| 6 +-
docs/specs/MESA_texture_array.spec | 2 +-
src/mesa/main/attrib.c | 17 ++---
src/mesa/main/enable.c | 19 ---
src/mesa/main/extensions.c | 1 -
src/mesa/program/program_parse_extra.c | 9 -
6 files changed, 8 insertions(+), 46 deletions(-)
diff --git a/docs/relnotes/10.1.html b/docs/relnotes/10.1.html
index 1b8ea22..dfb0969 100644
--- a/docs/relnotes/10.1.html
+++ b/docs/relnotes/10.1.html
@@ -54,7 +54,11 @@ TBD.
h2Changes/h2
-TBD.
+ul
+liRemoved support for the GL_MESA_texture_array extension. This extension
+ enabled the use of texture array with fixed-function and assembly fragment
+ shaders. No applications are known to use this extension./li
+/ul
/div
/body
diff --git a/docs/specs/MESA_texture_array.spec
b/docs/specs/MESA_texture_array.spec
index b146821..3e3e82c 100644
--- a/docs/specs/MESA_texture_array.spec
+++ b/docs/specs/MESA_texture_array.spec
@@ -16,7 +16,7 @@ IP Status
Status
-Shipping in Mesa 7.1
+DEPRECATED - Support removed in Mesa 10.1.
Version
diff --git a/src/mesa/main/attrib.c b/src/mesa/main/attrib.c
index 718eb83..ca67fd4 100644
--- a/src/mesa/main/attrib.c
+++ b/src/mesa/main/attrib.c
@@ -641,12 +641,6 @@ pop_enable_group(struct gl_context *ctx, const struct
gl_enable_attrib *enable)
_mesa_set_enable(ctx, GL_TEXTURE_CUBE_MAP,
!!(enabled TEXTURE_CUBE_BIT));
}
- if (ctx-Extensions.EXT_texture_array) {
-_mesa_set_enable(ctx, GL_TEXTURE_1D_ARRAY_EXT,
- !!(enabled TEXTURE_1D_ARRAY_BIT));
-_mesa_set_enable(ctx, GL_TEXTURE_2D_ARRAY_EXT,
- !!(enabled TEXTURE_2D_ARRAY_BIT));
- }
}
if (ctx-Texture.Unit[i].TexGenEnabled != genEnabled) {
@@ -688,12 +682,6 @@ pop_texture_group(struct gl_context *ctx, struct
texture_state *texstate)
_mesa_set_enable(ctx, GL_TEXTURE_RECTANGLE_NV,
!!(unit-Enabled TEXTURE_RECT_BIT));
}
- if (ctx-Extensions.EXT_texture_array) {
- _mesa_set_enable(ctx, GL_TEXTURE_1D_ARRAY_EXT,
- !!(unit-Enabled TEXTURE_1D_ARRAY_BIT));
- _mesa_set_enable(ctx, GL_TEXTURE_2D_ARRAY_EXT,
- !!(unit-Enabled TEXTURE_2D_ARRAY_BIT));
- }
_mesa_TexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, unit-EnvMode);
_mesa_TexEnvfv(GL_TEXTURE_ENV, GL_TEXTURE_ENV_COLOR, unit-EnvColor);
_mesa_TexGeni(GL_S, GL_TEXTURE_GEN_MODE, unit-GenS.Mode);
@@ -766,9 +754,8 @@ pop_texture_group(struct gl_context *ctx, struct
texture_state *texstate)
!ctx-Extensions.NV_texture_rectangle) {
continue;
}
- else if ((obj-Target == GL_TEXTURE_1D_ARRAY_EXT ||
- obj-Target == GL_TEXTURE_2D_ARRAY_EXT)
- !ctx-Extensions.EXT_texture_array) {
+ else if (obj-Target == GL_TEXTURE_1D_ARRAY_EXT ||
+ obj-Target == GL_TEXTURE_2D_ARRAY_EXT) {
continue;
}
else if (obj-Target == GL_TEXTURE_CUBE_MAP_ARRAY
diff --git a/src/mesa/main/enable.c b/src/mesa/main/enable.c
index 869c8a2..bb4a23c 100644
--- a/src/mesa/main/enable.c
+++ b/src/mesa/main/enable.c
@@ -934,25 +934,6 @@ _mesa_set_enable(struct gl_context *ctx, GLenum cap,
GLboolean state)
ctx-ATIFragmentShader.Enabled = state;
break;
- /* GL_MESA_texture_array */
- case GL_TEXTURE_1D_ARRAY_EXT:
- if (ctx-API != API_OPENGL_COMPAT)
-goto invalid_enum_error;
- CHECK_EXTENSION(EXT_texture_array, cap);
- if (!enable_texture(ctx, state, TEXTURE_1D_ARRAY_BIT)) {
-return;
- }
- break;
-
- case GL_TEXTURE_2D_ARRAY_EXT:
- if (ctx-API != API_OPENGL_COMPAT)
-goto invalid_enum_error;
- CHECK_EXTENSION(EXT_texture_array, cap);
- if (!enable_texture(ctx, state, TEXTURE_2D_ARRAY_BIT)) {
-return;
- }
- break;
-
case GL_TEXTURE_CUBE_MAP_SEAMLESS:
if (!_mesa_is_desktop_gl(ctx))
goto invalid_enum_error;
diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index 04d1828..77b5504 100644
---
[Mesa-dev] use fs generator to compile i965 blorp clear programs
One way to enable blorp programs on gen8 is to use the already existing assembly generator. But the generator(s) take i965 fs instructions as input while the existing blorp programs are represented directly using the low level EU presentation. Hence the existing logic needs to be lifted from direct EU to higher FS after which the generator can output the EU instead. This series attempts to rewrite the blorp clear programs. Topi Pohjolainen (9): i965: generate fs programs also without any 8-width instructions i965: allow fs generator use without gl_fragment_program i965: remove redundant initialization of blorp program data i965: remove unused members in blorp clear program i965: treat the fixed blorp clear base mrf as constant i965: compile non-replicated blorp clear program with fs generator i965: introduce new FS IR opcode for simd16 replicated write i965: teach fs generator to handle simd16 replicated write i965: compile replicated blorp clear program with fs generator src/mesa/drivers/dri/i965/brw_blorp_clear.cpp | 110 +++--- src/mesa/drivers/dri/i965/brw_defines.h | 1 + src/mesa/drivers/dri/i965/brw_fs.cpp | 1 + src/mesa/drivers/dri/i965/brw_fs.h| 1 + src/mesa/drivers/dri/i965/brw_fs_generator.cpp| 41 +++- src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp | 1 + src/mesa/drivers/dri/i965/brw_shader.cpp | 2 + 7 files changed, 74 insertions(+), 83 deletions(-) -- 1.8.3.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/9] i965: remove redundant initialization of blorp program data
As the entire structure is memset just before compilation.
Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
src/mesa/drivers/dri/i965/brw_blorp_clear.cpp | 2 --
1 file changed, 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
index 02ec273..2fa0b50 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
@@ -128,8 +128,6 @@
brw_blorp_const_color_program::brw_blorp_const_color_program(
clear_rgba(),
base_mrf(0)
{
- prog_data.first_curbe_grf = 0;
- prog_data.persample_msaa_dispatch = false;
brw_init_compile(brw, func, mem_ctx);
}
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/9] i965: allow fs generator use without gl_fragment_program
Prepares the generator to accept hand-crafted blorp programs.
Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
index e562db8..467d255 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
@@ -116,7 +116,7 @@ fs_generator::generate_fb_write(fs_inst *inst)
brw_set_mask_control(p, BRW_MASK_DISABLE);
brw_set_compression_control(p, BRW_COMPRESSION_NONE);
- if (fp-UsesKill || c-key.alpha_test_func) {
+ if ((fp fp-UsesKill) || c-key.alpha_test_func) {
struct brw_reg pixel_mask;
if (brw-gen = 6)
@@ -1300,9 +1300,12 @@ fs_generator::generate_code(exec_list *instructions)
if (shader) {
printf(Native code for fragment shader %d (%d-wide dispatch):\n,
prog-Name, dispatch_width);
- } else {
+ } else if (fp) {
printf(Native code for fragment program %d (%d-wide dispatch):\n,
fp-Base.Id, dispatch_width);
+ } else {
+ printf(Native code for blorp program (%d-wide dispatch):\n,
+dispatch_width);
}
}
@@ -1340,7 +1343,7 @@ fs_generator::generate_code(exec_list *instructions)
else {
const prog_instruction *fpi;
fpi = (const prog_instruction *)inst-ir;
- printf(%d: , (int)(fpi - fp-Base.Instructions));
+ printf(%d: , (int)(fpi - (fp ? fp-Base.Instructions :
0)));
_mesa_fprint_instruction_opt(stdout,
fpi,
0, PROG_PRINT_DEBUG, NULL);
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/9] i965: generate fs programs also without any 8-width instructions
Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
index 6626a8c..e562db8 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
@@ -1804,8 +1804,12 @@ fs_generator::generate_assembly(exec_list
*simd8_instructions,
exec_list *simd16_instructions,
unsigned *assembly_size)
{
- dispatch_width = 8;
- generate_code(simd8_instructions);
+ assert(simd8_instructions || simd16_instructions);
+
+ if (simd8_instructions) {
+ dispatch_width = 8;
+ generate_code(simd8_instructions);
+ }
if (simd16_instructions) {
/* We have to do a compaction pass now, or the one at the end of
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/9] i965: treat the fixed blorp clear base mrf as constant
Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
src/mesa/drivers/dri/i965/brw_blorp_clear.cpp | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
index a937edb..d25c6cb 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
@@ -108,7 +108,7 @@ private:
struct brw_reg clear_rgba;
/* MRF used for render target writes */
- GLuint base_mrf;
+ static const unsigned base_mrf = 2;
};
brw_blorp_const_color_program::brw_blorp_const_color_program(
@@ -117,8 +117,7 @@
brw_blorp_const_color_program::brw_blorp_const_color_program(
: mem_ctx(ralloc_context(NULL)),
brw(brw),
key(key),
- clear_rgba(),
- base_mrf(0)
+ clear_rgba()
{
brw_init_compile(brw, func, mem_ctx);
}
@@ -362,8 +361,6 @@ brw_blorp_const_color_program::alloc_regs()
/* Make sure we didn't run out of registers */
assert(reg = GEN7_MRF_HACK_START);
-
- this-base_mrf = 2;
}
const GLuint *
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/9] i965: remove unused members in blorp clear program
Documentation for R0 and R1 is taken from
fs_visitor::setup_payload_gen6().
Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
src/mesa/drivers/dri/i965/brw_blorp_clear.cpp | 15 +++
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
index 2fa0b50..a937edb 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
@@ -104,12 +104,6 @@ private:
const brw_blorp_const_color_prog_key *key;
struct brw_compile func;
- /* Thread dispatch header */
- struct brw_reg R0;
-
- /* Pixel X/Y coordinates (always in R1). */
- struct brw_reg R1;
-
/* Register with push constants (a single vec4) */
struct brw_reg clear_rgba;
@@ -123,8 +117,6 @@
brw_blorp_const_color_program::brw_blorp_const_color_program(
: mem_ctx(ralloc_context(NULL)),
brw(brw),
key(key),
- R0(),
- R1(),
clear_rgba(),
base_mrf(0)
{
@@ -363,11 +355,8 @@ brw_blorp_const_color_params::get_wm_prog(struct
brw_context *brw,
void
brw_blorp_const_color_program::alloc_regs()
{
- int reg = 0;
- this-R0 = retype(brw_vec8_grf(reg++, 0), BRW_REGISTER_TYPE_UW);
- this-R1 = retype(brw_vec8_grf(reg++, 0), BRW_REGISTER_TYPE_UW);
+ int reg = prog_data.first_curbe_grf;
- prog_data.first_curbe_grf = reg;
clear_rgba = retype(brw_vec4_grf(reg++, 0), BRW_REGISTER_TYPE_F);
reg += BRW_BLORP_NUM_PUSH_CONST_REGS;
@@ -384,6 +373,8 @@ brw_blorp_const_color_program::compile(struct brw_context
*brw,
/* Set up prog_data */
memset(prog_data, 0, sizeof(prog_data));
prog_data.persample_msaa_dispatch = false;
+ /* R0-1: masks, pixel X/Y coordinates. */
+ prog_data.first_curbe_grf = 2;
alloc_regs();
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 9/9] i965: compile replicated blorp clear program with fs generator
No regressions on Ivy Bridge. I also checked the eu-instruction
dump before and after, and they were identical:
0x: mov(4) g1141F g24,4,1F { align1 WE_all };
0x0010: sendc(16) null g1148,8,1F
render ( RT write, 1, 1, 12) mlen 1 rlen 0 { align1 WE_normal 1H EOT };
The dump isn't available anymore with blorp option but with fs.
Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
src/mesa/drivers/dri/i965/brw_blorp_clear.cpp | 77 ++-
1 file changed, 16 insertions(+), 61 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
index 03614ea..af4e32c 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
@@ -34,7 +34,6 @@ extern C {
#include brw_blorp.h
#include brw_context.h
-#include brw_eu.h
#include brw_state.h
#include brw_fs.h
@@ -103,10 +102,6 @@ private:
void *mem_ctx;
struct brw_context *brw;
const brw_blorp_const_color_prog_key *key;
- struct brw_compile func;
-
- /* Register with push constants (a single vec4) */
- struct brw_reg clear_rgba;
/* MRF used for render target writes */
static const unsigned base_mrf = 2;
@@ -117,10 +112,8 @@
brw_blorp_const_color_program::brw_blorp_const_color_program(
const brw_blorp_const_color_prog_key *key)
: mem_ctx(ralloc_context(NULL)),
brw(brw),
- key(key),
- clear_rgba()
+ key(key)
{
- brw_init_compile(brw, func, mem_ctx);
}
brw_blorp_const_color_program::~brw_blorp_const_color_program()
@@ -352,18 +345,6 @@ brw_blorp_const_color_params::get_wm_prog(struct
brw_context *brw,
return prog_offset;
}
-void
-brw_blorp_const_color_program::alloc_regs()
-{
- int reg = prog_data.first_curbe_grf;
-
- clear_rgba = retype(brw_vec4_grf(reg++, 0), BRW_REGISTER_TYPE_F);
- reg += BRW_BLORP_NUM_PUSH_CONST_REGS;
-
- /* Make sure we didn't run out of registers */
- assert(reg = GEN7_MRF_HACK_START);
-}
-
const GLuint *
brw_blorp_const_color_program::compile(struct brw_context *brw,
GLuint *program_size)
@@ -379,24 +360,16 @@ brw_blorp_const_color_program::compile(struct brw_context
*brw,
struct brw_wm_compile *c = rzalloc(mem_ctx, struct brw_wm_compile);
- alloc_regs();
-
- brw_set_compression_control(func, BRW_COMPRESSION_NONE);
-
- struct brw_reg mrf_rt_write =
- retype(vec16(brw_message_reg(base_mrf)), BRW_REGISTER_TYPE_F);
-
- uint32_t mlen, msg_type;
if (key-use_simd16_replicated_data) {
- /* The message payload is a single register with the low 4 floats/ints
- * filled with the constant clear color.
- */
- brw_set_mask_control(func, BRW_MASK_DISABLE);
- brw_MOV(func, vec4(brw_message_reg(base_mrf)), clear_rgba);
- brw_set_mask_control(func, BRW_MASK_ENABLE);
+ inst = new (mem_ctx) fs_inst(
+ BRW_OPCODE_MOV,
+ fs_reg(vec4(brw_message_reg(base_mrf))),
+ fs_reg(brw_vec4_grf(prog_data.first_curbe_grf, 0)));
+ inst-force_writemask_all = true;
+ instructions.push_tail(inst);
- msg_type =
BRW_DATAPORT_RENDER_TARGET_WRITE_SIMD16_SINGLE_SOURCE_REPLICATED;
- mlen = 1;
+ inst = new (mem_ctx) fs_inst(FS_OPCODE_FB_WRITE_SIMD16_REPLICATED);
+ inst-mlen = 1;
} else {
for (int i = 0; i 4; i++) {
/* The message payload is pairs of registers for 16 pixels each of r,
@@ -409,35 +382,17 @@ brw_blorp_const_color_program::compile(struct brw_context
*brw,
}
inst = new (mem_ctx) fs_inst(FS_OPCODE_FB_WRITE);
- inst-eot = true;
- inst-base_mrf = base_mrf;
inst-mlen = 8;
- inst-target = BRW_BLORP_RENDERBUFFER_BINDING_TABLE_INDEX;
+ }
- instructions.push_tail(inst);
+ inst-eot = true;
+ inst-base_mrf = base_mrf;
+ inst-target = BRW_BLORP_RENDERBUFFER_BINDING_TABLE_INDEX;
- return fs_generator(brw, c, NULL, NULL, false).generate_assembly(
- NULL, instructions, program_size);
- }
+ instructions.push_tail(inst);
- /* Now write to the render target and terminate the thread */
- brw_fb_WRITE(func,
-16 /* dispatch_width */,
-base_mrf /* msg_reg_nr */,
-mrf_rt_write /* src0 */,
-msg_type,
-BRW_BLORP_RENDERBUFFER_BINDING_TABLE_INDEX,
-mlen,
-0 /* response_length */,
-true /* eot */,
-false /* header present */);
-
- if (unlikely(INTEL_DEBUG DEBUG_BLORP)) {
- printf(Native code for BLORP clear:\n);
- brw_dump_compile(func, stdout, 0, func.next_insn_offset);
- printf(\n);
- }
- return brw_get_program(func, program_size);
+ return fs_generator(brw, c, NULL, NULL, false).generate_assembly(
+ NULL, instructions, program_size);
}
--
1.8.3.1
___
mesa-dev
[Mesa-dev] [PATCH 6/9] i965: compile non-replicated blorp clear program with fs generator
I forced the non-replicated compilation unconditionally by
fixing 'use_simd16_replicated_data' to 'false' and saw no
regressions on Ivy Bridge. I also checked the eu-instruction
dump before and after, and they were identical:
0x: mov(16) g1141F g20,1,0F{ align1 WE_normal 1H };
0x0010: mov(16) g1161F g2.10,1,0F { align1 WE_normal 1H };
0x0020: mov(16) g1181F g2.20,1,0F { align1 WE_normal 1H };
0x0030: mov(16) g1201F g2.30,1,0F { align1 WE_normal 1H };
0x0040: sendc(16) null g1148,8,1F
render ( RT write, 1, 0, 12) mlen 8 rlen 0 { align1 WE_normal 1H EOT };
The dump isn't available anymore with blorp option but with fs.
Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
src/mesa/drivers/dri/i965/brw_blorp_clear.cpp | 27 ---
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
index d25c6cb..03614ea 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
@@ -36,6 +36,7 @@ extern C {
#include brw_context.h
#include brw_eu.h
#include brw_state.h
+#include brw_fs.h
#define FILE_DEBUG_FLAG DEBUG_BLORP
@@ -367,12 +368,17 @@ const GLuint *
brw_blorp_const_color_program::compile(struct brw_context *brw,
GLuint *program_size)
{
+ exec_list instructions;
+ fs_inst *inst;
+
/* Set up prog_data */
memset(prog_data, 0, sizeof(prog_data));
prog_data.persample_msaa_dispatch = false;
/* R0-1: masks, pixel X/Y coordinates. */
prog_data.first_curbe_grf = 2;
+ struct brw_wm_compile *c = rzalloc(mem_ctx, struct brw_wm_compile);
+
alloc_regs();
brw_set_compression_control(func, BRW_COMPRESSION_NONE);
@@ -396,15 +402,22 @@ brw_blorp_const_color_program::compile(struct brw_context
*brw,
/* The message payload is pairs of registers for 16 pixels each of r,
* g, b, and a.
*/
- brw_set_compression_control(func, BRW_COMPRESSION_COMPRESSED);
- brw_MOV(func,
- brw_message_reg(base_mrf + i * 2),
- brw_vec1_grf(clear_rgba.nr, i));
- brw_set_compression_control(func, BRW_COMPRESSION_NONE);
+ instructions.push_tail(new (mem_ctx) fs_inst(
+BRW_OPCODE_MOV,
+fs_reg(MRF, base_mrf + i * 2),
+fs_reg(brw_vec1_grf(prog_data.first_curbe_grf, i;
}
- msg_type = BRW_DATAPORT_RENDER_TARGET_WRITE_SIMD16_SINGLE_SOURCE;
- mlen = 8;
+ inst = new (mem_ctx) fs_inst(FS_OPCODE_FB_WRITE);
+ inst-eot = true;
+ inst-base_mrf = base_mrf;
+ inst-mlen = 8;
+ inst-target = BRW_BLORP_RENDERBUFFER_BINDING_TABLE_INDEX;
+
+ instructions.push_tail(inst);
+
+ return fs_generator(brw, c, NULL, NULL, false).generate_assembly(
+ NULL, instructions, program_size);
}
/* Now write to the render target and terminate the thread */
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 8/9] i965: teach fs generator to handle simd16 replicated write
Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
src/mesa/drivers/dri/i965/brw_fs.h | 1 +
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 24
2 files changed, 25 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.h
b/src/mesa/drivers/dri/i965/brw_fs.h
index 7991b87..1095ad9 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.h
+++ b/src/mesa/drivers/dri/i965/brw_fs.h
@@ -511,6 +511,7 @@ public:
private:
void generate_code(exec_list *instructions);
void generate_fb_write(fs_inst *inst);
+ void generate_fb_write_simd16_replicated(fs_inst *inst);
void generate_pixel_xy(struct brw_reg dst, bool is_x);
void generate_linterp(fs_inst *inst, struct brw_reg dst,
struct brw_reg *src);
diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
index 467d255..10c9e45 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
@@ -190,6 +190,26 @@ fs_generator::generate_fb_write(fs_inst *inst)
mark_surface_used(surf_index);
}
+void
+fs_generator::generate_fb_write_simd16_replicated(fs_inst *inst)
+{
+ uint32_t surf_index =
+ c-prog_data.binding_table.render_target_start + inst-target;
+ brw_fb_WRITE(
+ p,
+ 16,
+ inst-base_mrf,
+ retype(vec16(brw_message_reg(inst-base_mrf)), BRW_REGISTER_TYPE_F),
+ BRW_DATAPORT_RENDER_TARGET_WRITE_SIMD16_SINGLE_SOURCE_REPLICATED,
+ surf_index,
+ inst-mlen,
+ 0,
+ inst-eot,
+ false);
+
+ mark_surface_used(surf_index);
+}
+
/* Computes the integer pixel x,y values from the origin.
*
* This is the basis of gl_FragCoord computation, but is also used
@@ -1704,6 +1724,10 @@ fs_generator::generate_code(exec_list *instructions)
generate_fb_write(inst);
break;
+ case FS_OPCODE_FB_WRITE_SIMD16_REPLICATED:
+ generate_fb_write_simd16_replicated(inst);
+ break;
+
case FS_OPCODE_MOV_DISPATCH_TO_FLAGS:
generate_mov_dispatch_to_flags(inst);
break;
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 7/9] i965: introduce new FS IR opcode for simd16 replicated write
Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
src/mesa/drivers/dri/i965/brw_defines.h | 1 +
src/mesa/drivers/dri/i965/brw_fs.cpp | 1 +
src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp | 1 +
src/mesa/drivers/dri/i965/brw_shader.cpp | 2 ++
4 files changed, 5 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_defines.h
b/src/mesa/drivers/dri/i965/brw_defines.h
index 597d3b2..9eb8503 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -752,6 +752,7 @@ enum opcode {
* instructions.
*/
FS_OPCODE_FB_WRITE = 128,
+ FS_OPCODE_FB_WRITE_SIMD16_REPLICATED,
SHADER_OPCODE_RCP,
SHADER_OPCODE_RSQ,
SHADER_OPCODE_SQRT,
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 261f906..42a3c8c 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -773,6 +773,7 @@ fs_visitor::implied_mrf_writes(fs_inst *inst)
case SHADER_OPCODE_LOD:
return 1;
case FS_OPCODE_FB_WRITE:
+ case FS_OPCODE_FB_WRITE_SIMD16_REPLICATED:
return 2;
case FS_OPCODE_UNIFORM_PULL_CONSTANT_LOAD:
case SHADER_OPCODE_GEN4_SCRATCH_READ:
diff --git a/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
b/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
index 8567afd..8b252af 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
@@ -285,6 +285,7 @@ fs_visitor::setup_payload_interference(struct ra_graph *g,
/* Special case instructions which have extra implied registers used. */
switch (inst-opcode) {
case FS_OPCODE_FB_WRITE:
+ case FS_OPCODE_FB_WRITE_SIMD16_REPLICATED:
/* We could omit this for the !inst-header_present case, except that
* the simulator apparently incorrectly reads from g0/g1 instead of
* sideband. It also really freaks out driver developers to see g0
diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp
b/src/mesa/drivers/dri/i965/brw_shader.cpp
index ddb4524..702c25b 100644
--- a/src/mesa/drivers/dri/i965/brw_shader.cpp
+++ b/src/mesa/drivers/dri/i965/brw_shader.cpp
@@ -413,6 +413,8 @@ brw_instruction_name(enum opcode op)
switch (op) {
case FS_OPCODE_FB_WRITE:
return fb_write;
+ case FS_OPCODE_FB_WRITE_SIMD16_REPLICATED:
+ return fb_write_simd16_replicated;
case SHADER_OPCODE_RCP:
return rcp;
--
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 2/4] glsl: Fix inconsistent assumptions about ir_loop::counter.
On 27 November 2013 12:44, Paul Berry stereotype...@gmail.com wrote:
The compiler back-ends (i965's fs_visitor and brw_visitor,
ir_to_mesa_visitor, and glsl_to_tgsi_visitor) assume that when
ir_loop::counter is non-null, it points to a fresh ir_variable that
should be used as the loop counter (as opposed to an ir_variable that
exists elsewhere in the instruction stream).
However, previous to this patch:
(1) loop_control_visitor did not create a new variable for
ir_loop::counter; instead it re-used the existing ir_variable.
This caused the loop counter to be double-incremented (once
explicitly by the body of the loop, and once implicitly by
ir_loop::increment).
(2) ir_clone did not clone ir_loop::counter properly, resulting in the
cloned ir_loop pointing to the source ir_loop's counter.
(3) ir_hierarchical_visitor did not visit ir_loop::counter, resulting
in the ir_variable being missed by reparenting.
Additionally, most optimization passes (e.g. loop unrolling) assume
that the variable mentioned by ir_loop::counter is not accessed in the
body of the loop (an assumption which (1) violates).
The combination of these factors caused a perfect storm in which the
code worked properly nearly all of the time: for loops that got
unrolled, (1) would introduce a double-increment, but loop unrolling
would fail to notice it (since it assumes that ir_loop::counter is not
accessed in the body of the loop), so it would unroll the loop the
correct number of times. For loops that didn't get unrolled, (1)
would introduce a double-increment, but then later when the IR was
cloned for linking, (2) would prevent the loop counter from being
cloned properly, so it would look to further analysis stages like an
independent variable (and hence the double-increment would stop
occurring). At the end of linking, (3) would prevent the loop counter
from being reparented, so it would still belong to the shader object
rather than the linked program object. Provided that the client
program didn't delete the shader object, the memory would never get
reclaimed, and so the shader would function properly.
However, for loops that didn't get unrolled, if the client program did
delete the shader object, and the memory belonging to the loop counter
got re-used, this could cause a use-after-free bug, leading to a
crash.
This patch fixes loop_control_visitor, ir_clone, and
ir_hierarchical_visitor to treat ir_loop::counter the same way the
back-ends treat it: as a freshly allocated ir_variable that needs to
be visited and cloned independently of other ir_variables.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72026
Note: this change is just invasive enough that it probably shouldn't be
picked over to stable before the 10.0 release. But I recommend picking it
over to stable after the 10.0 release.
---
src/glsl/ir_clone.cpp | 3 ++-
src/glsl/ir_hv_accept.cpp | 6 ++
src/glsl/loop_controls.cpp | 2 +-
3 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/src/glsl/ir_clone.cpp b/src/glsl/ir_clone.cpp
index 40ed33a..8f57499 100644
--- a/src/glsl/ir_clone.cpp
+++ b/src/glsl/ir_clone.cpp
@@ -163,7 +163,8 @@ ir_loop::clone(void *mem_ctx, struct hash_table *ht)
const
new_loop-to = this-to-clone(mem_ctx, ht);
if (this-increment)
new_loop-increment = this-increment-clone(mem_ctx, ht);
- new_loop-counter = counter;
+ if (this-counter)
+ new_loop-counter = this-counter-clone(mem_ctx, ht);
foreach_iter(exec_list_iterator, iter, this-body_instructions) {
ir_instruction *ir = (ir_instruction *)iter.get();
diff --git a/src/glsl/ir_hv_accept.cpp b/src/glsl/ir_hv_accept.cpp
index 941b25e..a0fe3b9 100644
--- a/src/glsl/ir_hv_accept.cpp
+++ b/src/glsl/ir_hv_accept.cpp
@@ -87,6 +87,12 @@ ir_loop::accept(ir_hierarchical_visitor *v)
if (s != visit_continue)
return (s == visit_continue_with_parent) ? visit_continue : s;
+ if (this-counter) {
+ s = this-counter-accept(v);
+ if (s != visit_continue)
+ return (s == visit_continue_with_parent) ? visit_continue : s;
+ }
+
s = visit_list_elements(v, this-body_instructions);
if (s == visit_stop)
return s;
diff --git a/src/glsl/loop_controls.cpp b/src/glsl/loop_controls.cpp
index 2648193..0eb103f 100644
--- a/src/glsl/loop_controls.cpp
+++ b/src/glsl/loop_controls.cpp
@@ -254,7 +254,7 @@ loop_control_visitor::visit_leave(ir_loop *ir)
ir-from = init-clone(ir, NULL);
ir-to = limit-clone(ir, NULL);
ir-increment = lv-increment-clone(ir, NULL);
-ir-counter = lv-var;
+ir-counter = lv-var-clone(ir, NULL);
ir-cmp = cmp;
max_iterations = iterations;
--
1.8.4.2
___
mesa-dev mailing list
Re: [Mesa-dev] [PATCH 7/8] mesa: Remove support for GL_MESA_texture_array
On 11/27/2013 12:55 PM, Ian Romanick wrote:
On 11/26/2013 03:54 PM, Ian Romanick wrote:
From: Ian Romanick ian.d.roman...@intel.com
This extension enabled the use of texture array with fixed-function and
assembly fragment shaders. No applications are known to use this
extension.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
I'm going to temporarily NAK this patch and the next one. There appear
to be some paths in meta (glCopyTexSubImage2D) that rely on using
texture arrays with fixed-function. :(
NAK that NAK. :) It turns out that the test case was just broken. It
was trying to use array textures with fixed function, but it was only
testing for GL_EXT_texture_array... which doesn't add support for array
textures with fixed function.
I've submitted a patch to the piglit list to fix the copyteximage test
for GL_TEXTURE_1D_ARRAY and GL_TEXTURE_2D_ARRAY targets.
---
docs/relnotes/10.1.html| 6 +-
docs/specs/MESA_texture_array.spec | 2 +-
src/mesa/main/attrib.c | 17 ++---
src/mesa/main/enable.c | 19 ---
src/mesa/main/extensions.c | 1 -
src/mesa/program/program_parse_extra.c | 9 -
6 files changed, 8 insertions(+), 46 deletions(-)
diff --git a/docs/relnotes/10.1.html b/docs/relnotes/10.1.html
index 1b8ea22..dfb0969 100644
--- a/docs/relnotes/10.1.html
+++ b/docs/relnotes/10.1.html
@@ -54,7 +54,11 @@ TBD.
h2Changes/h2
-TBD.
+ul
+liRemoved support for the GL_MESA_texture_array extension. This extension
+ enabled the use of texture array with fixed-function and assembly fragment
+ shaders. No applications are known to use this extension./li
+/ul
/div
/body
diff --git a/docs/specs/MESA_texture_array.spec
b/docs/specs/MESA_texture_array.spec
index b146821..3e3e82c 100644
--- a/docs/specs/MESA_texture_array.spec
+++ b/docs/specs/MESA_texture_array.spec
@@ -16,7 +16,7 @@ IP Status
Status
-Shipping in Mesa 7.1
+DEPRECATED - Support removed in Mesa 10.1.
Version
diff --git a/src/mesa/main/attrib.c b/src/mesa/main/attrib.c
index 718eb83..ca67fd4 100644
--- a/src/mesa/main/attrib.c
+++ b/src/mesa/main/attrib.c
@@ -641,12 +641,6 @@ pop_enable_group(struct gl_context *ctx, const struct
gl_enable_attrib *enable)
_mesa_set_enable(ctx, GL_TEXTURE_CUBE_MAP,
!!(enabled TEXTURE_CUBE_BIT));
}
- if (ctx-Extensions.EXT_texture_array) {
-_mesa_set_enable(ctx, GL_TEXTURE_1D_ARRAY_EXT,
- !!(enabled TEXTURE_1D_ARRAY_BIT));
-_mesa_set_enable(ctx, GL_TEXTURE_2D_ARRAY_EXT,
- !!(enabled TEXTURE_2D_ARRAY_BIT));
- }
}
if (ctx-Texture.Unit[i].TexGenEnabled != genEnabled) {
@@ -688,12 +682,6 @@ pop_texture_group(struct gl_context *ctx, struct
texture_state *texstate)
_mesa_set_enable(ctx, GL_TEXTURE_RECTANGLE_NV,
!!(unit-Enabled TEXTURE_RECT_BIT));
}
- if (ctx-Extensions.EXT_texture_array) {
- _mesa_set_enable(ctx, GL_TEXTURE_1D_ARRAY_EXT,
- !!(unit-Enabled TEXTURE_1D_ARRAY_BIT));
- _mesa_set_enable(ctx, GL_TEXTURE_2D_ARRAY_EXT,
- !!(unit-Enabled TEXTURE_2D_ARRAY_BIT));
- }
_mesa_TexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, unit-EnvMode);
_mesa_TexEnvfv(GL_TEXTURE_ENV, GL_TEXTURE_ENV_COLOR, unit-EnvColor);
_mesa_TexGeni(GL_S, GL_TEXTURE_GEN_MODE, unit-GenS.Mode);
@@ -766,9 +754,8 @@ pop_texture_group(struct gl_context *ctx, struct
texture_state *texstate)
!ctx-Extensions.NV_texture_rectangle) {
continue;
}
- else if ((obj-Target == GL_TEXTURE_1D_ARRAY_EXT ||
- obj-Target == GL_TEXTURE_2D_ARRAY_EXT)
- !ctx-Extensions.EXT_texture_array) {
+ else if (obj-Target == GL_TEXTURE_1D_ARRAY_EXT ||
+ obj-Target == GL_TEXTURE_2D_ARRAY_EXT) {
continue;
}
else if (obj-Target == GL_TEXTURE_CUBE_MAP_ARRAY
diff --git a/src/mesa/main/enable.c b/src/mesa/main/enable.c
index 869c8a2..bb4a23c 100644
--- a/src/mesa/main/enable.c
+++ b/src/mesa/main/enable.c
@@ -934,25 +934,6 @@ _mesa_set_enable(struct gl_context *ctx, GLenum cap,
GLboolean state)
ctx-ATIFragmentShader.Enabled = state;
break;
- /* GL_MESA_texture_array */
- case GL_TEXTURE_1D_ARRAY_EXT:
- if (ctx-API != API_OPENGL_COMPAT)
-goto invalid_enum_error;
- CHECK_EXTENSION(EXT_texture_array, cap);
- if (!enable_texture(ctx, state, TEXTURE_1D_ARRAY_BIT)) {
-return;
- }
- break;
-
- case GL_TEXTURE_2D_ARRAY_EXT:
- if (ctx-API != API_OPENGL_COMPAT)
-goto
Re: [Mesa-dev] [PATCH 5/6] glsl: Create an accessor for the built-in function shader.
On 11/27/2013 10:47 AM, Kenneth Graunke wrote: On 11/23/2013 05:45 PM, Kenneth Graunke wrote: On 11/23/2013 04:03 PM, Ian Romanick wrote: Would it be better to just make _mesa_glsl_get_builtin_function_shader a friend? In this case, I don't think it makes much practical difference - the builtin_builder class is entirely contained within the builtin_functions.cpp file. So making this public is basically making all the ordinary functions at the bottom of the file friends, which seems fairly reasonable. --Ken Ian, after that answer, are you okay with the patch? Or would you like it changed? I don't have a strong opinion... since none of the more hard-core C++ guys spoke up, I'm fine with it as-is. Reviewed-by: Ian Romanick ian.d.roman...@intel.com --Ken ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/5] docs: describe the INTEL_* envvars that do exist
On Mon, Nov 25, 2013 at 12:20 AM, Chris Forbes chr...@ijw.co.nz wrote: I've pushed these now, including dropping the old names for those debug bits. I've left the stats stuff as-is for now, but suggested more useful options in the docs. I'm really unhappy that and how 195994fe4cd (drop old INTEL_DEBUG names for `perf` (fall) and `fs` (wm)) was committed. I don't see it ever being sent to the list much less Ken actually reviewing it. shader-db uses the old wm name, so I've now wasted a pile of time tracking down why none of my fragment shaders are being executed. If it had been sent to the list I could have told you this. I'm reverting this (195994fe4cd) out of principle. On Mon, Nov 25, 2013 at 4:44 AM, Kenneth Graunke kenn...@whitecape.org wrote: On 11/23/2013 09:13 PM, Chris Forbes wrote: Signed-off-by: Chris Forbes chr...@ijw.co.nz --- docs/envvars.html | 32 1 file changed, 32 insertions(+) diff --git a/docs/envvars.html b/docs/envvars.html index 81e74e6..d831826 100644 --- a/docs/envvars.html +++ b/docs/envvars.html @@ -121,6 +121,38 @@ See the a href=xlibdriver.htmlXlib software driver page/a for details. h2i945/i965 driver environment variables (non-Gallium)/h2 ul +liINTEL_NO_HW - if set to 1, prevents batches from being submitted to the hardware. + This is useful for debugging hangs, etc./li +liINTEL_DEBUG - a comma-separated list of named flags, which do various things: +ul + litex - emit messages about textures./li + listate - emit messages about state flag tracking/li + liblit - emit messages about blit operations/li + limiptree - emit messages about miptrees/li + lifall/perf - emit messages about performance issues/li Not sure if the old names are worth documenting. I guess if people find old text on wikis or something that says INTEL_DEBUG=fall, they'll know what it means. We might want to actually just drop the 'fall' name at this point...people seem to have moved over completely. + liperfmon - emit messages about AMD_performance_monitor/li + libat - emit batch information/li + lipix - emit messages about pixel operations/li + libuf - emit messages about buffer objects/li + lireg - emit messages about regions/li + lifbo - emit messages about framebuffers/li + lifs/wm - dump shader assembly for fragment shaders/li I've pretty much universally moved over to INTEL_DEBUG=fs too, but I don't know about others. + ligs - dump shader assembly for geometry shaders/li + lisync - emit messages about synchronization/li + liprim - emit messages about drawing primitives/li + livert - emit messages about vertex assembly/li + lidri - emit messages about the DRI interface/li + lisf - emit messages about the strips amp; fans unit (for old gens, includes the SF program)/li + listats - ?/li This enables statistics counters for the vertex fetcher (on all generations), and for other units on Gen4-5. That said, the counters aren't exposed other than reading registers, and on Gen6+ you can't even use intel_reg_read due to hardware contexts. Frankly, it seems pretty useless, and I think we ought to delete it. + liurb - emit messages about URB setup/li + livs - dump shader assembly for vertex shaders/li + liclip - emit messages about the clip unit (for old gens, includes the CLIP program)/li + liaub - dump batches into an AUB trace for use with simulation tools/li + lishader_time - record how much GPU time is spent in each shader/li + lino16 - suppress generation of 16-wide fragment shaders. useful for debugging broken shaders/li + liblorp - emit messages about the blorp operations (blits amp; clears)/li + linodualobj - suppress generation of dual-object geometry shader code/li +/ul /ul Thanks for doing this, Chris. For the series: Reviewed-by: Kenneth Graunke kenn...@whitecape.org ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/5] docs: describe the INTEL_* envvars that do exist
Yikes, really sorry for the trouble. -- Chris On Thu, Nov 28, 2013 at 10:40 AM, Matt Turner matts...@gmail.com wrote: On Mon, Nov 25, 2013 at 12:20 AM, Chris Forbes chr...@ijw.co.nz wrote: I've pushed these now, including dropping the old names for those debug bits. I've left the stats stuff as-is for now, but suggested more useful options in the docs. I'm really unhappy that and how 195994fe4cd (drop old INTEL_DEBUG names for `perf` (fall) and `fs` (wm)) was committed. I don't see it ever being sent to the list much less Ken actually reviewing it. shader-db uses the old wm name, so I've now wasted a pile of time tracking down why none of my fragment shaders are being executed. If it had been sent to the list I could have told you this. I'm reverting this (195994fe4cd) out of principle. On Mon, Nov 25, 2013 at 4:44 AM, Kenneth Graunke kenn...@whitecape.org wrote: On 11/23/2013 09:13 PM, Chris Forbes wrote: Signed-off-by: Chris Forbes chr...@ijw.co.nz --- docs/envvars.html | 32 1 file changed, 32 insertions(+) diff --git a/docs/envvars.html b/docs/envvars.html index 81e74e6..d831826 100644 --- a/docs/envvars.html +++ b/docs/envvars.html @@ -121,6 +121,38 @@ See the a href=xlibdriver.htmlXlib software driver page/a for details. h2i945/i965 driver environment variables (non-Gallium)/h2 ul +liINTEL_NO_HW - if set to 1, prevents batches from being submitted to the hardware. + This is useful for debugging hangs, etc./li +liINTEL_DEBUG - a comma-separated list of named flags, which do various things: +ul + litex - emit messages about textures./li + listate - emit messages about state flag tracking/li + liblit - emit messages about blit operations/li + limiptree - emit messages about miptrees/li + lifall/perf - emit messages about performance issues/li Not sure if the old names are worth documenting. I guess if people find old text on wikis or something that says INTEL_DEBUG=fall, they'll know what it means. We might want to actually just drop the 'fall' name at this point...people seem to have moved over completely. + liperfmon - emit messages about AMD_performance_monitor/li + libat - emit batch information/li + lipix - emit messages about pixel operations/li + libuf - emit messages about buffer objects/li + lireg - emit messages about regions/li + lifbo - emit messages about framebuffers/li + lifs/wm - dump shader assembly for fragment shaders/li I've pretty much universally moved over to INTEL_DEBUG=fs too, but I don't know about others. + ligs - dump shader assembly for geometry shaders/li + lisync - emit messages about synchronization/li + liprim - emit messages about drawing primitives/li + livert - emit messages about vertex assembly/li + lidri - emit messages about the DRI interface/li + lisf - emit messages about the strips amp; fans unit (for old gens, includes the SF program)/li + listats - ?/li This enables statistics counters for the vertex fetcher (on all generations), and for other units on Gen4-5. That said, the counters aren't exposed other than reading registers, and on Gen6+ you can't even use intel_reg_read due to hardware contexts. Frankly, it seems pretty useless, and I think we ought to delete it. + liurb - emit messages about URB setup/li + livs - dump shader assembly for vertex shaders/li + liclip - emit messages about the clip unit (for old gens, includes the CLIP program)/li + liaub - dump batches into an AUB trace for use with simulation tools/li + lishader_time - record how much GPU time is spent in each shader/li + lino16 - suppress generation of 16-wide fragment shaders. useful for debugging broken shaders/li + liblorp - emit messages about the blorp operations (blits amp; clears)/li + linodualobj - suppress generation of dual-object geometry shader code/li +/ul /ul Thanks for doing this, Chris. For the series: Reviewed-by: Kenneth Graunke kenn...@whitecape.org ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Feasibility of KHR_gl_texture_cubemap_image in mesa/gallium
1) resource_from_handle and resource_get_handle only support 2D textures without mipmaps on Radeon. Adding support for more texture types is possible, but changes are needed in the kernel driver too, which is where we store information about the layout of the resource. 2) This is not possible with Gallium at the moment. We would need to add a texture target variable to pipe_sampler_view, which would override pipe_resource's target. This is required by ARB_texture_view, so it will happen sooner or later anyway. I think you'll need both. Marek On Wed, Nov 27, 2013 at 7:23 PM, Ryan Morris ryanmorris...@gmail.com wrote: .. let me try that again. I've been looking into adding support for the KHR_gl_*_image extensions to mesa/gallium as was attempted here: http://lists.freedesktop.org/archives/mesa-dev/2010-September/002900.html Looking further into how creating an eglimage out of a cubemap face has got me wondering whether or not it's feasible in the gallium framework. The trouble I'm seeing is that texture memory is hidden from the state_tracker layer as the state_tracker can only see a pipe_resource or a winsys handle not how the various cubemap faces are layed out in memory. pipe_resources for a cubemap texture have a specific type (PIPE_TARGET_CUBEMAP) and I presume that the underlying driver implementation is free to allocate memory for cubemaps in whatever way it sees fit (i.e. it's not stipulated by the gallium interface). So then if a user wants to take an eglimage sourced from a cubemap texture and then use that to target a 2D texture, the created 2D texture has to somehow reference the memory attached to the cubemap pipe_resource, but only one face of it. I can think of two general approaches: (1) Somehow create a pipe_resource with a winsys handle that points to only a sub-face of memory attached to the cubemap pipe_resource. (2) Find a way to use the cubemap pipe_resource such that we only look at one face and it behaves like a 2D texture. I thought (2) could perhaps be accomplished with sampler_views. But any experimenting I've done there has convinced me that a sampler_view (with first_layer and last_layer restricted to the face that I care about) can't convince the underlying driver/GPU to make the cupemap texture behave like a 2d texture. And for (1), I haven't seen any mechanisms that allow for this kind of sub-referencing of memory regions. So my question is, does anyone with more experience with gallium / the mesa state_tracker have an idea of how targeting a 2D texture with an eglimage sourced from a cubemap face would work? Are any of my above assumptions/conclusions incorrect? Thanks. On Wed, Nov 27, 2013 at 1:04 PM, Ryan Morris ryanmorris...@gmail.com wrote: Hi, This is my first post to this forum, so apologies if I say anything horrendously wrong. I've been looking into adding support for the KHR_gl_*_image extensions to mesa/gallium as was attempted here: ___ 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 70766] Run-time link error in swrast_dri.so
https://bugs.freedesktop.org/show_bug.cgi?id=70766 --- Comment #4 from Andreas Hartmetz ahartm...@gmail.com --- The LLVM patch does the trick for me. With the patch, llvm-config --cxxflags output contains -fno-rtti (at the very end) and Mesa drivers radeonsi and swrast can be loaded. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Properly reject __DRI_CTX_FLAG_ROBUST_BUFFER_ACCESS when __DRI2_ROBUSTNESS is not enabled
On Tue, Nov 26, 2013 at 5:11 PM, Ian Romanick i...@freedesktop.org wrote: From: Ian Romanick ian.d.roman...@intel.com Only allow __DRI_CTX_FLAG_ROBUST_BUFFER_ACCESS in brwCreateContext if intelInitScreen2 also enabled __DRI2_ROBUSTNESS (thereby enabling GLX_ARB_create_context). This fixes a regression in the piglit test glx/GLX_ARB_create_context/invalid flag Signed-off-by: Ian Romanick ian.d.roman...@intel.com Reported-by: Paul Berry stereotype...@gmail.com Cc: 10.0 mesa-sta...@lists.freedesktop.org --- The patch that causes the regression (9b1c686) hasn't been picked to 10.0 yet, so this patch should get squashed with it when they're both picked. 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] Feasibility of KHR_gl_texture_cubemap_image in mesa/gallium
Hmm yes doing things like 1) will get hacky pretty fast. resource_from_handle is more like a necessary kludge, because we can't enforce everybody to use a common object type (like pipe_resource) for sharing outside gallium. I wouldn't know how to do this cleanly there. I agree that we're probably going to need a target override in pipe_sampler_view. Though just about the only interesting override ARB_texture_view allows is the cube-array and vice versa mapping, the rest (non-array-array and vice versa) is only necessary because GL still has distinct array and non-array resources. Though I actually thought some hw really had different texture layouts for cube maps and 2d array textures. Might have been early intel dx10 hw? In any case though I guess ever since cube map arrays probably everybody can do this, and the gallium changes required should be relatively straightforward (drivers supporting it simply need to use the target from the view instead of the underlying resource, and for those which don't support it no changes should be necessary). Roland Am 27.11.2013 23:14, schrieb Marek Olšák: 1) resource_from_handle and resource_get_handle only support 2D textures without mipmaps on Radeon. Adding support for more texture types is possible, but changes are needed in the kernel driver too, which is where we store information about the layout of the resource. 2) This is not possible with Gallium at the moment. We would need to add a texture target variable to pipe_sampler_view, which would override pipe_resource's target. This is required by ARB_texture_view, so it will happen sooner or later anyway. I think you'll need both. Marek On Wed, Nov 27, 2013 at 7:23 PM, Ryan Morris ryanmorris...@gmail.com wrote: .. let me try that again. I've been looking into adding support for the KHR_gl_*_image extensions to mesa/gallium as was attempted here: https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/archives/mesa-dev/2010-September/002900.htmlk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0Am=iCWtx4XZULBjHaK8iC2Y%2BZi%2Fs%2FE1zfBy%2BbxgXKGWhRI%3D%0As=2a6413295f63c3caf64b7c5c8555f1b720994c5a321786be450a00dd3cf82e09 Looking further into how creating an eglimage out of a cubemap face has got me wondering whether or not it's feasible in the gallium framework. The trouble I'm seeing is that texture memory is hidden from the state_tracker layer as the state_tracker can only see a pipe_resource or a winsys handle not how the various cubemap faces are layed out in memory. pipe_resources for a cubemap texture have a specific type (PIPE_TARGET_CUBEMAP) and I presume that the underlying driver implementation is free to allocate memory for cubemaps in whatever way it sees fit (i.e. it's not stipulated by the gallium interface). So then if a user wants to take an eglimage sourced from a cubemap texture and then use that to target a 2D texture, the created 2D texture has to somehow reference the memory attached to the cubemap pipe_resource, but only one face of it. I can think of two general approaches: (1) Somehow create a pipe_resource with a winsys handle that points to only a sub-face of memory attached to the cubemap pipe_resource. (2) Find a way to use the cubemap pipe_resource such that we only look at one face and it behaves like a 2D texture. I thought (2) could perhaps be accomplished with sampler_views. But any experimenting I've done there has convinced me that a sampler_view (with first_layer and last_layer restricted to the face that I care about) can't convince the underlying driver/GPU to make the cupemap texture behave like a 2d texture. And for (1), I haven't seen any mechanisms that allow for this kind of sub-referencing of memory regions. So my question is, does anyone with more experience with gallium / the mesa state_tracker have an idea of how targeting a 2D texture with an eglimage sourced from a cubemap face would work? Are any of my above assumptions/conclusions incorrect? Thanks. On Wed, Nov 27, 2013 at 1:04 PM, Ryan Morris ryanmorris...@gmail.com wrote: Hi, This is my first post to this forum, so apologies if I say anything horrendously wrong. I've been looking into adding support for the KHR_gl_*_image extensions to mesa/gallium as was attempted here: ___ 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=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0Am=iCWtx4XZULBjHaK8iC2Y%2BZi%2Fs%2FE1zfBy%2BbxgXKGWhRI%3D%0As=ba627f40999f4b12b1743290bd33af31c65dfe66483cf3d53f3d5a5b8f20d8e0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org
Re: [Mesa-dev] [PATCH] i965: Properly reject __DRI_CTX_FLAG_ROBUST_BUFFER_ACCESS when __DRI2_ROBUSTNESS is not enabled
On Tue, Nov 26, 2013 at 5:11 PM, Ian Romanick i...@freedesktop.org wrote:
From: Ian Romanick ian.d.roman...@intel.com
Only allow __DRI_CTX_FLAG_ROBUST_BUFFER_ACCESS in brwCreateContext if
intelInitScreen2 also enabled __DRI2_ROBUSTNESS (thereby enabling
GLX_ARB_create_context).
This fixes a regression in the piglit test
glx/GLX_ARB_create_context/invalid flag
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
Reported-by: Paul Berry stereotype...@gmail.com
Cc: 10.0 mesa-sta...@lists.freedesktop.org
---
The patch that causes the regression (9b1c686) hasn't been picked to
10.0 yet, so this patch should get squashed with it when they're both
picked.
src/mesa/drivers/dri/i965/brw_context.c | 13 ++---
src/mesa/drivers/dri/i965/intel_screen.c | 4 +++-
src/mesa/drivers/dri/i965/intel_screen.h | 5 +
3 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index 67ac01c..948f3bd 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -558,9 +558,16 @@ brwCreateContext(gl_api api,
struct dd_function_table functions;
struct gl_config visual;
- if (flags ~(__DRI_CTX_FLAG_DEBUG
- | __DRI_CTX_FLAG_FORWARD_COMPATIBLE
- | __DRI_CTX_FLAG_ROBUST_BUFFER_ACCESS)) {
+ /* Only allow the __DRI_CTX_FLAG_ROBUST_BUFFER_ACCESS flag if the kernel
+* provides us with context reset notifications.
+*/
+ uint32_t allowed_flags = __DRI_CTX_FLAG_DEBUG
+ | __DRI_CTX_FLAG_FORWARD_COMPATIBLE;
+
+ if (/*false */ screen-has_context_reset_notification)
commented debug code...
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
+ allowed_flags |= __DRI_CTX_FLAG_ROBUST_BUFFER_ACCESS;
+
+ if (flags ~allowed_flags) {
*dri_ctx_error = __DRI_CTX_ERROR_UNKNOWN_FLAG;
return false;
}
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
b/src/mesa/drivers/dri/i965/intel_screen.c
index 051c000..39c2f35 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -1344,7 +1344,9 @@ __DRIconfig **intelInitScreen2(__DRIscreen *psp)
const int ret = drmIoctl(psp-fd, DRM_IOCTL_I915_GET_RESET_STATS, stats);
- psp-extensions = (ret == -1 errno == EINVAL)
+ intelScreen-has_context_reset_notification = (ret != -1 || errno !=
EINVAL);
+
+ psp-extensions = !intelScreen-has_context_reset_notification
? intelScreenExtensions : intelRobustScreenExtensions;
return (const __DRIconfig**) intel_screen_make_configs(psp);
diff --git a/src/mesa/drivers/dri/i965/intel_screen.h
b/src/mesa/drivers/dri/i965/intel_screen.h
index 2e3043e..924e1f2 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.h
+++ b/src/mesa/drivers/dri/i965/intel_screen.h
@@ -50,6 +50,11 @@ struct intel_screen
bool hw_has_swizzling;
+ /**
+* Does the kernel support context reset notifications?
+*/
+ bool has_context_reset_notification;
+
dri_bufmgr *bufmgr;
/**
--
1.8.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Properly reject __DRI_CTX_FLAG_ROBUST_BUFFER_ACCESS when __DRI2_ROBUSTNESS is not enabled
On 11/27/2013 03:00 PM, Jordan Justen wrote:
On Tue, Nov 26, 2013 at 5:11 PM, Ian Romanick i...@freedesktop.org wrote:
From: Ian Romanick ian.d.roman...@intel.com
Only allow __DRI_CTX_FLAG_ROBUST_BUFFER_ACCESS in brwCreateContext if
intelInitScreen2 also enabled __DRI2_ROBUSTNESS (thereby enabling
GLX_ARB_create_context).
This fixes a regression in the piglit test
glx/GLX_ARB_create_context/invalid flag
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
Reported-by: Paul Berry stereotype...@gmail.com
Cc: 10.0 mesa-sta...@lists.freedesktop.org
---
The patch that causes the regression (9b1c686) hasn't been picked to
10.0 yet, so this patch should get squashed with it when they're both
picked.
src/mesa/drivers/dri/i965/brw_context.c | 13 ++---
src/mesa/drivers/dri/i965/intel_screen.c | 4 +++-
src/mesa/drivers/dri/i965/intel_screen.h | 5 +
3 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index 67ac01c..948f3bd 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -558,9 +558,16 @@ brwCreateContext(gl_api api,
struct dd_function_table functions;
struct gl_config visual;
- if (flags ~(__DRI_CTX_FLAG_DEBUG
- | __DRI_CTX_FLAG_FORWARD_COMPATIBLE
- | __DRI_CTX_FLAG_ROBUST_BUFFER_ACCESS)) {
+ /* Only allow the __DRI_CTX_FLAG_ROBUST_BUFFER_ACCESS flag if the kernel
+* provides us with context reset notifications.
+*/
+ uint32_t allowed_flags = __DRI_CTX_FLAG_DEBUG
+ | __DRI_CTX_FLAG_FORWARD_COMPATIBLE;
+
+ if (/*false */ screen-has_context_reset_notification)
commented debug code...
Oops! Good catch. :)
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
+ allowed_flags |= __DRI_CTX_FLAG_ROBUST_BUFFER_ACCESS;
+
+ if (flags ~allowed_flags) {
*dri_ctx_error = __DRI_CTX_ERROR_UNKNOWN_FLAG;
return false;
}
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
b/src/mesa/drivers/dri/i965/intel_screen.c
index 051c000..39c2f35 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -1344,7 +1344,9 @@ __DRIconfig **intelInitScreen2(__DRIscreen *psp)
const int ret = drmIoctl(psp-fd, DRM_IOCTL_I915_GET_RESET_STATS,
stats);
- psp-extensions = (ret == -1 errno == EINVAL)
+ intelScreen-has_context_reset_notification = (ret != -1 || errno !=
EINVAL);
+
+ psp-extensions = !intelScreen-has_context_reset_notification
? intelScreenExtensions : intelRobustScreenExtensions;
return (const __DRIconfig**) intel_screen_make_configs(psp);
diff --git a/src/mesa/drivers/dri/i965/intel_screen.h
b/src/mesa/drivers/dri/i965/intel_screen.h
index 2e3043e..924e1f2 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.h
+++ b/src/mesa/drivers/dri/i965/intel_screen.h
@@ -50,6 +50,11 @@ struct intel_screen
bool hw_has_swizzling;
+ /**
+* Does the kernel support context reset notifications?
+*/
+ bool has_context_reset_notification;
+
dri_bufmgr *bufmgr;
/**
--
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] Nesa-dev now integrated with patchwork
For those of you who don't know, freedesktop.org runs an instance of Patchwork to aid in tracking patches that are in need of review. We've just finished getting it integrated with the Mesa-dev list. Here's a brief run-down of what Patchwork provides for us. Automatic flow of patches in Patchwork -- Each patch sent to mesa-dev@ is automatically entered into Patchwork's database in the New state. You can browse the patches in Patchwork's database here: http://patchwork.freedesktop.org/project/mesa/list/ Replies to the patch are also collected and made visible in the web interface. When a branch is pushed to the master git repo, a git hook will automatically search for the patch in the database, and if it is found, put it in the Accepted state. When this happens, you'll see something like the following in the console output of the git push command: remote: I: patch #PATCHWORK_ID updated using rev GIT_COMMIT. If, instead, git push gives you output such as: remote: E: failed to find patch for rev GIT_COMMIT. this means that you pushed a patch to master that wasn't found in Patchwork's database. This can happen if you neglected to email the patch to the mailing list prior to pushing the commit, or if you made a change to the patch between mailing it and pushing it. If the latter, then you'll likely want to manually update patchwork (see below). Manual updates to Patchwork patch state --- You can also change the state of patchwork patches through the web interface or through a command-line client. First, you'll need to create a patchwork login at: http://patchwork.freedesktop.org/register/ Once you have created an account, you'll now see buttons such as Change state and Delegate to for patches that you have submitted. If you want to help maintain the state of other patches in patchwork, please let me know and I can add you to patchwork's maintainers list for mesa. For now, the most common manual change might be to change a patch from the New to the Accepted state when this didn't happen automatically at the time of git push. There are other states in the Patchwork database by default, (Under review, Rejected, Superseded, etc.). And we can easily add or remove any items we want from this list. It will probably take some experimenting within our community to find what states and workflows we find useful. Command-line access to Patchwork with pwclient -- In addition to the web interface, Patchwork also includes a handy command-line script for interaction. You can download the pwclient python script from: http://patchwork.freedesktop.org/pwclient/ Before this utility is useful, you'll also need a .pwclientrc file in your home directory. If you're currently logged into patchwork, the following URL provides a pre-configured .pwclientrc file for you with your username/password in it: http://patchwork.freedesktop.org/project/mesa/pwclientrc/ I've also attached an example file you can fill out. The pwclient script allows you to view and update patches just like the web interface: pwclient list -s new# List all patches in New state pwclient update -s Accepted PWID # Update a specific patch In addition, you can download or download-and-apply a patch with commands such as: pwclient get PWID pwclient git-am PWID So give things a try, and let's see if this is a useful additional tool for us, (not replacing either of the mailing list nor bugzilla, but hopefully providing some new, useful views). -Carl pwclientrc Description: Binary data pgpn0QyAyZDDo.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/llvmpipe: add fake MSAA support
On Thu, Nov 28, 2013 at 4:13 AM, Roland Scheidegger srol...@vmware.com wrote: Looks good to me. Though frankly I don't know if that really is better than your idea of faking 4-sample resources - it at least is simpler. But noone else chimed in... I'm pretty ambivalent about which way to go, this is probably simpler and triggers less piglit tests to run as they seem to check max samples and refuse to run at least :-) We probably can't advertise 150 glsl until Marek's changes are also in, then we can just go 330. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 8/8] mesa: Remove GL_MESA_texture_array cruft from gl.h
Series Reviewed-by: Jordan Justen jordan.l.jus...@intel.com On Tue, Nov 26, 2013 at 3:54 PM, Ian Romanick i...@freedesktop.org wrote: From: Ian Romanick ian.d.roman...@intel.com glext.h has had all the necessary bits for years. Signed-off-by: Ian Romanick ian.d.roman...@intel.com --- include/GL/gl.h | 33 - 1 file changed, 33 deletions(-) diff --git a/include/GL/gl.h b/include/GL/gl.h index b484b96..48343f6 100644 --- a/include/GL/gl.h +++ b/include/GL/gl.h @@ -2078,39 +2078,6 @@ typedef void (APIENTRYP PFNGLMULTITEXCOORD4SVARBPROC) (GLenum target, const GLsh #endif /* GL_MESA_packed_depth_stencil */ -#ifndef GL_MESA_texture_array -#define GL_MESA_texture_array 1 - -/* GL_MESA_texture_array uses the same enum values as GL_EXT_texture_array. - */ -#ifndef GL_EXT_texture_array - -#ifdef GL_GLEXT_PROTOTYPES -GLAPI void APIENTRY glFramebufferTextureLayerEXT(GLenum target, -GLenum attachment, GLuint texture, GLint level, GLint layer); -#endif /* GL_GLEXT_PROTOTYPES */ - -#if 0 -/* (temporarily) disabled because of collision with typedef in glext.h - * that happens if apps include both gl.h and glext.h - */ -typedef void (APIENTRYP PFNGLFRAMEBUFFERTEXTURELAYEREXTPROC) (GLenum target, -GLenum attachment, GLuint texture, GLint level, GLint layer); -#endif - -#define GL_TEXTURE_1D_ARRAY_EXT 0x8C18 -#define GL_PROXY_TEXTURE_1D_ARRAY_EXT 0x8C19 -#define GL_TEXTURE_2D_ARRAY_EXT 0x8C1A -#define GL_PROXY_TEXTURE_2D_ARRAY_EXT 0x8C1B -#define GL_TEXTURE_BINDING_1D_ARRAY_EXT 0x8C1C -#define GL_TEXTURE_BINDING_2D_ARRAY_EXT 0x8C1D -#define GL_MAX_ARRAY_TEXTURE_LAYERS_EXT 0x88FF -#define GL_FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT 0x8CD4 -#endif - -#endif - - #ifndef GL_ATI_blend_equation_separate #define GL_ATI_blend_equation_separate 1 -- 1.8.1.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Move wayland-drm protocol from Mesa to wayland-core
On Nov 27, 2013 10:53 AM, Benjamin Gaignard benjamin.gaign...@linaro.org wrote: Hi all, I'm working for Linaro on enabling a zero copy path in GStreamer by using dmabuf. To make this possible I have patched gst wayland sink to use wayland drm protocol: https://bugzilla.gnome.org/show_bug.cgi?id=711155 Today wayland drm protocol is limited to Mesa so I have decided to move it into wayland-core. My hardware doesn't have gpu support yet so I have patched weston (pixman) to allow usage of wl_drm buffers. With this I able to share/use a buffer allocated by DRM in gstreamer pipeline even if I don't have gpu and EGL. What do you think about make wayland drm protocol available like this ? Benjamin, The problem here is that wl_drm is really a mesa extension. Well, more of an open-source linux graphics stack extension. The point is that there are other graphics stacks: Rhaspberry Pi, libhybris, other proprietary stacks, etc. and each of these graphics stacks has its own extension for passing hardware buffers around. This means that if you want your GStreamer sink to work on these other stacks with zero-copy, you will have to talk their protocols. Because wl_drm isn't global to all of wayland, it probably shouldn't go into the wayland core. This does not mean, however, that wl_drm can't be exposed in a more sensible way. As of 1.3, we are now exporting wayland.xml to /usr/share/wayland and we can put other extensions there as well. We could have, for instance, a /usr/share/mesa.xml file that provides the mesa extensions. Then projects wanting to talk directly to mesa can generate the header and C files from the system-installed xml file. This would solve the problem of keeping everything in sync. One last note (this one's been bugging me for a while). If we are going to export wl_drm in some way, we should probably rename it to something like mesa_drm. We really need to get out of the habit of using the wl_ namespace for everything that talks the wayland protocol. If we don't alter the details of wl_drm in the rename, it shouldn't be too hard to move everyone over from wl_drm to mesa_drm. Hope that's sensible/helpful. --Jason Ekstrand ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Move wayland-drm protocol from Mesa to wayland-core
Wasn't EGLStreams supposed to solve the use case of passing hardware buffers around in a standard way? On Wed, Nov 27, 2013 at 1:22 PM, Jason Ekstrand ja...@jlekstrand.netwrote: On Nov 27, 2013 10:53 AM, Benjamin Gaignard benjamin.gaign...@linaro.org wrote: Hi all, I'm working for Linaro on enabling a zero copy path in GStreamer by using dmabuf. To make this possible I have patched gst wayland sink to use wayland drm protocol: https://bugzilla.gnome.org/show_bug.cgi?id=711155 Today wayland drm protocol is limited to Mesa so I have decided to move it into wayland-core. My hardware doesn't have gpu support yet so I have patched weston (pixman) to allow usage of wl_drm buffers. With this I able to share/use a buffer allocated by DRM in gstreamer pipeline even if I don't have gpu and EGL. What do you think about make wayland drm protocol available like this ? Benjamin, The problem here is that wl_drm is really a mesa extension. Well, more of an open-source linux graphics stack extension. The point is that there are other graphics stacks: Rhaspberry Pi, libhybris, other proprietary stacks, etc. and each of these graphics stacks has its own extension for passing hardware buffers around. This means that if you want your GStreamer sink to work on these other stacks with zero-copy, you will have to talk their protocols. Because wl_drm isn't global to all of wayland, it probably shouldn't go into the wayland core. This does not mean, however, that wl_drm can't be exposed in a more sensible way. As of 1.3, we are now exporting wayland.xml to /usr/share/wayland and we can put other extensions there as well. We could have, for instance, a /usr/share/mesa.xml file that provides the mesa extensions. Then projects wanting to talk directly to mesa can generate the header and C files from the system-installed xml file. This would solve the problem of keeping everything in sync. One last note (this one's been bugging me for a while). If we are going to export wl_drm in some way, we should probably rename it to something like mesa_drm. We really need to get out of the habit of using the wl_ namespace for everything that talks the wayland protocol. If we don't alter the details of wl_drm in the rename, it shouldn't be too hard to move everyone over from wl_drm to mesa_drm. Hope that's sensible/helpful. --Jason Ekstrand ___ wayland-devel mailing list wayland-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel -- Jasper ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Move wayland-drm protocol from Mesa to wayland-core
Hi all,
I'm working for Linaro on enabling a zero copy path in GStreamer by
using dmabuf.
To make this possible I have patched gst wayland sink to use wayland
drm protocol: https://bugzilla.gnome.org/show_bug.cgi?id=711155
Today wayland drm protocol is limited to Mesa so I have decided to
move it into wayland-core.
My hardware doesn't have gpu support yet so I have patched weston
(pixman) to allow usage of wl_drm buffers.
With this I able to share/use a buffer allocated by DRM in gstreamer
pipeline even if I don't have gpu and EGL.
What do you think about make wayland drm protocol available like this ?
Please note those patches are for wayland/weston 1.1.0
Regards,
Benjamin
--
Benjamin Gaignard
Graphic Working Group
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
From b185fe89a1ea8ddbe19d943cb19272f369b7b438 Mon Sep 17 00:00:00 2001
From: Benjamin Gaignard benjamin.gaign...@linaro.org
Date: Mon, 25 Nov 2013 11:38:12 +0100
Subject: [PATCH] make weston able to use wl_drm protocol
Make compositor-drm able to provide wl_drm buffer even if EGL isn't used.
Update pixman to allow it to compose wl_drm buffer like it does for wl_shm.
Signed-off-by: Benjamin Gaignard benjamin.gaign...@linaro.org
---
src/compositor-drm.c | 131 +++--
src/pixman-renderer.c | 60 +++---
2 files changed, 169 insertions(+), 22 deletions(-)
diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index da1ba79..b336127 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -45,6 +45,8 @@
#include pixman-renderer.h
#include udev-seat.h
#include launcher-util.h
+#include wayland-drm.h
+#include wayland-drm-server-protocol.h
static int option_current_mode = 0;
static char *output_name;
@@ -79,10 +81,12 @@ struct drm_compositor {
struct udev_monitor *udev_monitor;
struct wl_event_source *udev_drm_source;
+ struct wl_drm *wl_server_drm;
struct {
int id;
int fd;
+ char *device_name;
} drm;
struct gbm_device *gbm;
uint32_t *crtcs;
@@ -754,7 +758,7 @@ drm_output_prepare_overlay_surface(struct weston_output *output_base,
if (es-alpha != 1.0f)
return NULL;
- if (wl_buffer_is_shm(es-buffer_ref.buffer))
+ if (wl_buffer_is_shm(es-buffer_ref.buffer) || wayland_buffer_is_drm(es-buffer_ref.buffer))
return NULL;
if (!drm_surface_transform_supported(es))
@@ -876,7 +880,7 @@ drm_output_prepare_cursor_surface(struct weston_output *output_base,
if (c-cursors_are_broken)
return NULL;
if (es-buffer_ref.buffer == NULL ||
- !wl_buffer_is_shm(es-buffer_ref.buffer) ||
+ (!wl_buffer_is_shm(es-buffer_ref.buffer) !wayland_buffer_is_drm(es-buffer_ref.buffer)) ||
es-geometry.width 64 || es-geometry.height 64)
return NULL;
@@ -966,10 +970,10 @@ drm_assign_planes(struct weston_output *output)
primary = c-base.primary_plane;
wl_list_for_each_safe(es, next, c-base.surface_list, link) {
/* test whether this buffer can ever go into a plane:
- * non-shm, or small enough to be a cursor
+ * non-shm, non-drm, or small enough to be a cursor
*/
if ((es-buffer_ref.buffer
- !wl_buffer_is_shm(es-buffer_ref.buffer)) ||
+ (!wl_buffer_is_shm(es-buffer_ref.buffer) !wayland_buffer_is_drm(es-buffer_ref.buffer))) ||
(es-geometry.width = 64 es-geometry.height = 64))
es-keep_buffer = 1;
else
@@ -1174,8 +1178,120 @@ init_drm(struct drm_compositor *ec, struct udev_device *device)
weston_log(using %s\n, filename);
ec-drm.fd = fd;
+ ec-drm.device_name = strdup(filename);
+ return 0;
+}
+
+static int
+drm_display_authenticate(void *user_data, uint32_t magic)
+{
+ struct drm_compositor *ec = user_data;
+ weston_log(authentification\n);
+ return drmAuthMagic(ec-drm.fd, magic);
+}
+
+struct drm_driver_buffer {
+ uint32_t size;
+ uint32_t handle;
+ char *data;
+};
+
+static void
+drm_reference_buffer(void *user_data, uint32_t name, int prime_fd,
+ struct wl_drm_buffer *buffer)
+{
+ struct drm_compositor *ec = user_data;
+ uint32_t handles[4], pitches[4], offsets[4];
+ int ret;
+ uint32_t fd;
+ struct drm_driver_buffer *driver_buffer;
+ weston_log(reference buffer fd %d\n, prime_fd);
+ if (prime_fd == -1)
+ return;
+
+ drmPrimeFDToHandle(ec-drm.fd, prime_fd, handles[0]);
+ pitches[0] = buffer-stride[0];
+ pitches[1] = buffer-stride[1];
+ pitches[2] = buffer-stride[2];
+ offsets[0] = buffer-offset[0];
+ offsets[1] = buffer-offset[1];
+ offsets[2] = buffer-offset[2];
+
+ weston_log(drmModeAddFB2 fd %d\n, prime_fd);
+ ret = drmModeAddFB2 (ec-drm.fd, buffer-buffer.width, buffer-buffer.height,
+ buffer-format, handles, pitches, offsets, fd, 0);
+ if (ret) {
+ weston_log(addfb2 failed: %m\n);
+ return;
+ }
+
+ weston_log(addfb2 success\n);
+ driver_buffer = malloc(sizeof *driver_buffer);
+ if (driver_buffer == NULL)
+ return;
+
+ driver_buffer-size = buffer-buffer.width * buffer-buffer.height * 4;
+ driver_buffer-handle = handles[0];
+
Re: [Mesa-dev] [PATCH 3/4] glsl: In ir_validate, check that ir_loop::counter always refers to a new var.
On 27 November 2013 14:43, Ian Romanick i...@freedesktop.org wrote:
On 11/27/2013 12:44 PM, Paul Berry wrote:
The compiler back-ends (i965's fs_visitor and brw_visitor,
ir_to_mesa_visitor, and glsl_to_tgsi_visitor) have been assuming this
for some time. Thanks to the preceding patch, the compiler front-end
no longer breaks this assumption.
This patch adds code to validate the assumption so that if we have
future bugs, we'll be able to catch them earlier.
---
src/glsl/ir_validate.cpp | 13 +
1 file changed, 13 insertions(+)
diff --git a/src/glsl/ir_validate.cpp b/src/glsl/ir_validate.cpp
index 13e41a0..26d6388 100644
--- a/src/glsl/ir_validate.cpp
+++ b/src/glsl/ir_validate.cpp
@@ -63,6 +63,7 @@ public:
virtual ir_visitor_status visit_enter(ir_if *ir);
+ virtual ir_visitor_status visit_enter(ir_loop *ir);
virtual ir_visitor_status visit_leave(ir_loop *ir);
virtual ir_visitor_status visit_enter(ir_function *ir);
virtual ir_visitor_status visit_leave(ir_function *ir);
@@ -149,6 +150,18 @@ ir_validate::visit_enter(ir_if *ir)
ir_visitor_status
+ir_validate::visit_enter(ir_loop *ir)
+{
+ if (ir-counter != NULL hash_table_find(ht, ir-counter) != NULL)
{
+ printf(ir_loop @ %p specifies already-declared variable `%s' @
%p\n,
+ (void *) ir, ir-counter-name, (void *) ir-counter);
+ abort();
+ }
We should enforce the invariants that you mention in the next patch.
That should happen either in this patch or a follow-on... but probably
here. Yeah?
You mean the stuff about from, to, and increment being non-null when
counter is non-null and vice versa? That's already enforced in
ir_validate::visit_leave(ir_loop *).
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 7/9] mesa: Fill out ARB_texture_view entry points
On Tue, Nov 26, 2013 at 3:59 PM, Courtney Goeltzenleuchter court...@lunarg.com wrote: With these changes, what needs to happen to commit these changes to master? I'd like to do another quick review but I'm on vacation this week and not finding much time for email/reviewing. Maybe in a few days. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] drisw/gallium/llvmpipe: add MESA_copy_sub_buffer support
This patches add MESA_copy_sub_buffer support to the dri sw loader and
then to gallium state tracker, llvmpipe, softpipe and other bits.
It reuses the dri1 driver extension interface, and it updates the swrast
loader interface for a new putimage which can take a stride.
I've tested this with gnome-shell with a cogl hacked to reenable sub copies
for llvmpipe and the one piglit test.
I could probably split this patch up as well.
Signed-off-by: Dave Airlie airl...@redhat.com
---
include/GL/internal/dri_interface.h | 9 +++-
src/gallium/drivers/llvmpipe/lp_screen.c | 17 +++
src/gallium/drivers/softpipe/sp_screen.c | 19
src/gallium/include/pipe/p_screen.h | 6 ++-
src/gallium/include/state_tracker/drisw_api.h | 2 +
src/gallium/include/state_tracker/sw_winsys.h | 6 +++
src/gallium/state_trackers/dri/sw/drisw.c | 64 ++-
src/gallium/winsys/sw/dri/dri_sw_winsys.c | 22 -
src/glx/drisw_glx.c | 43 +++---
src/mesa/drivers/dri/common/dri_util.c| 15 +++
src/mesa/drivers/dri/common/dri_util.h| 5 ++-
11 files changed, 198 insertions(+), 10 deletions(-)
diff --git a/include/GL/internal/dri_interface.h
b/include/GL/internal/dri_interface.h
index b012570..81f7e60 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -437,7 +437,7 @@ struct __DRIdamageExtensionRec {
* SWRast Loader extension.
*/
#define __DRI_SWRAST_LOADER DRI_SWRastLoader
-#define __DRI_SWRAST_LOADER_VERSION 1
+#define __DRI_SWRAST_LOADER_VERSION 2
struct __DRIswrastLoaderExtensionRec {
__DRIextension base;
@@ -461,6 +461,13 @@ struct __DRIswrastLoaderExtensionRec {
void (*getImage)(__DRIdrawable *readable,
int x, int y, int width, int height,
char *data, void *loaderPrivate);
+
+/**
+ * Put image to drawable
+ */
+void (*putImage2)(__DRIdrawable *drawable, int op,
+ int x, int y, int width, int height, int stride,
+ char *data, void *loaderPrivate);
};
/**
diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c
b/src/gallium/drivers/llvmpipe/lp_screen.c
index f61df98..a4bf27a 100644
--- a/src/gallium/drivers/llvmpipe/lp_screen.c
+++ b/src/gallium/drivers/llvmpipe/lp_screen.c
@@ -415,6 +415,22 @@ llvmpipe_flush_frontbuffer(struct pipe_screen *_screen,
winsys-displaytarget_display(winsys, texture-dt, context_private);
}
+static void
+llvmpipe_flush_sub_frontbuffer(struct pipe_screen *_screen,
+ struct pipe_resource *resource,
+ unsigned level, unsigned layer,
+ void *context_private,
+ int x, int y, int w, int h)
+{
+ struct llvmpipe_screen *screen = llvmpipe_screen(_screen);
+ struct sw_winsys *winsys = screen-winsys;
+ struct llvmpipe_resource *texture = llvmpipe_resource(resource);
+
+ assert(texture-dt);
+ if (texture-dt)
+ winsys-displaytarget_sub_display(winsys, texture-dt, context_private,
+x, y, w, h);
+}
static void
llvmpipe_destroy_screen( struct pipe_screen *_screen )
@@ -525,6 +541,7 @@ llvmpipe_create_screen(struct sw_winsys *winsys)
screen-base.context_create = llvmpipe_create_context;
screen-base.flush_frontbuffer = llvmpipe_flush_frontbuffer;
+ screen-base.flush_sub_frontbuffer = llvmpipe_flush_sub_frontbuffer;
screen-base.fence_reference = llvmpipe_fence_reference;
screen-base.fence_signalled = llvmpipe_fence_signalled;
screen-base.fence_finish = llvmpipe_fence_finish;
diff --git a/src/gallium/drivers/softpipe/sp_screen.c
b/src/gallium/drivers/softpipe/sp_screen.c
index 47ef20e..093357b 100644
--- a/src/gallium/drivers/softpipe/sp_screen.c
+++ b/src/gallium/drivers/softpipe/sp_screen.c
@@ -377,6 +377,23 @@ softpipe_flush_frontbuffer(struct pipe_screen *_screen,
winsys-displaytarget_display(winsys, texture-dt, context_private);
}
+static void
+softpipe_flush_sub_frontbuffer(struct pipe_screen *_screen,
+ struct pipe_resource *resource,
+ unsigned level, unsigned layer,
+ void *context_private,
+ int x, int y, int w, int h)
+{
+ struct softpipe_screen *screen = softpipe_screen(_screen);
+ struct sw_winsys *winsys = screen-winsys;
+ struct softpipe_resource *texture = softpipe_resource(resource);
+
+ assert(texture-dt);
+ if (texture-dt)
+ winsys-displaytarget_sub_display(winsys, texture-dt, context_private,
+x, y, w, h);
+}
+
static uint64_t
softpipe_get_timestamp(struct pipe_screen *_screen)
{
@@ -411,6 +428,8 @@ softpipe_create_screen(struct sw_winsys *winsys)
screen-base.context_create = softpipe_create_context;
Re: [Mesa-dev] [PATCH] i965: Always reserve binding table space for at least one render target.
Kenneth Graunke kenn...@whitecape.org writes: In brw_update_renderbuffer_surfaces(), if there are no color draw buffers, we always set up a null render target at surface index 0 so we have something to use with the FB write marking the end of thread. However, when we recently began computing surface indexes dynamically, we failed to reserve space for it. This meant that the first texture would be assigned surface index 0, and our closing FB write would clobber the texture. Fixes Piglit's EXT_packed_depth_stencil/fbo-blit-d24s8 test on Gen4-5, which regressed as of commit 4e5306453da6a1c076309e543ec92d999e02f67a (i965/fs: Dynamically set up the WM binding table offsets.) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70605 Signed-off-by: Kenneth Graunke kenn...@whitecape.org Cc: Eric Anholt e...@anholt.net Cc: 10.0 mesa-sta...@lists.freedesktop.org Reviewed-by: Eric Anholt e...@anholt.net pgpwvCC6JgyKo.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
