Re: [Mesa-dev] [v6 2/9] intel: do not create renderbuffers out of planar images
On 05/30/2013 01:20 AM, Daniel Vetter wrote:
On Thu, May 30, 2013 at 9:49 AM, Pohjolainen, Topi
topi.pohjolai...@intel.com wrote:
On Tue, May 28, 2013 at 01:33:18PM -0700, Eric Anholt wrote:
Topi Pohjolainen topi.pohjolai...@intel.com writes:
Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
src/mesa/drivers/dri/intel/intel_fbo.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
b/src/mesa/drivers/dri/intel/intel_fbo.c
index 69f8629..7ccbaa8 100644
--- a/src/mesa/drivers/dri/intel/intel_fbo.c
+++ b/src/mesa/drivers/dri/intel/intel_fbo.c
@@ -280,6 +280,10 @@ intel_image_target_renderbuffer_storage(struct gl_context
*ctx,
if (image == NULL)
return;
+ /* Planar buffers are not supported as render targets. */
+ if (image-planar_format image-planar_format-nplanes 1)
+ return;
+
/* __DRIimage is opaque to the core so it has to be checked here */
switch (image-format) {
case MESA_FORMAT_RGBA_REV:
OK, this answers one question I had about what our support was going to
be. But what about glEGLImageTargetTexture2DOES()?
Are we only going to support planar textures with image_external? My
thought is yes. How about on HSW with the YUV sampler support? Are
we going to relayout the data in the incoming fds to a copy that can
support sampling from them, or are we going to reject incoming fds that
don't fit the required layout? And if we decide to reject anything, are
we going to reject it at the or the dmabuf_import stage or the
image_external stage?
I was also thinking that planar would be supported only by image_external, and I
hadn't even thought about HSW yet.
I think the same formats supported in image_external should also be supported
by dma_buf_import. This would allow us to write Piglit tests for any supported
image_external format.
If the set of supported dma_buf_import formats is a subset of the image_external
formats, then how do you propose we write tests (Piglit or non-Piglit) for the
extra image_external formats?
To avoid any implementation weirdness, though, I think we should prevent
creation of 2D texture targets (GL_TEXTURE_2D) from dma_buf images, and
permit only creation of external textures (GL_TEXTURE_EXTERNAL).
Clearly I haven't been thinking as far as you, I thought that images can be
created relatively freely - it would be their uses that would fail if not
supported. But this is wrong I guess. Once an image is created it should be
guaranteed to be usable for quite a number of things.
Having said that I realize that I don't most likely know enough about all the
ways images can be used so that I could introduce proper constraints to the
image creation logic.
I guess we have two questions here: The first is deciding where we
fail the import process if the client api can't directly access the
data in the imported dma_buf. I think it's better to fail late since
doing all possible checks at egl image creation time might be ugly and
too restrictive. Otoh failing late will make it even harder for
applications to figure out what's possible.
I think we should fail at image creation time if the driver is unable
to texture from the given dma_buf configuration. If the image cannot
be textured from, it's a useless brick, so why allow its creation?
Validation of the image's texturability must be done at some time, most likely
at either either time of image creation or of texture creation. I don't see how
anything is gained by postponing the validation until time of
texture creation, so let's just do it early so as to prevent the creation of
bricked images.
The other questions is who will be responsible for copying. Doing any
kinds of transparent relayouting (e.g. when resampling a planar yuv
with oes image external to something a hw sampler could directly cope
with in case of a mismatch) doesn't sound too good: It'll break users
if they try to re-use dma_bufs/egl_images and the client api objects
created from them. So we might want to disallow any kind of egl image
orphaning and any other non-zero-copy conversion for images backed by
dma_bufs. Otoh this could get really ugly if we add a egl_image -
dma_buf export extension.
If we allow creation of a GL_TEXTURE_2D from dma_buf images, then the
GL_OES_EGL_image
spec requires orphaning under some situations. Here is issue #1 of that spec:
1. What happens if an application tries to specify a new mipmap
level (or respecify an existing mipmap level) for a texture
object that was originally specified using
EGLImageTargetTexture2D (e.g., by subsequent calls to
{Copy}TexImage, GenerateMipmapOES, and/or setting the
texture's GENERATE_MIPMAP_SGIS parameter to TRUE) ?
RESOLVED: If the application respecifies any properties of
an EGLImage target texture, the GL should allocate additional
memory for the respecified object, copying any data from
[Mesa-dev] [PATCH] mesa: Prevent possible out-of-bounds read by save_SamplerParameterfv.
Fixes Out-of-bounds access defect reported by Coverity.
Signed-off-by: Vinson Lee v...@freedesktop.org
---
src/mesa/main/dlist.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/dlist.c b/src/mesa/main/dlist.c
index c37b15e..6c26313 100644
--- a/src/mesa/main/dlist.c
+++ b/src/mesa/main/dlist.c
@@ -7056,7 +7056,10 @@ save_SamplerParameterfv(GLuint sampler, GLenum pname,
const GLfloat *params)
static void GLAPIENTRY
save_SamplerParameterf(GLuint sampler, GLenum pname, GLfloat param)
{
- save_SamplerParameterfv(sampler, pname, param);
+ GLfloat parray[4];
+ parray[0] = param;
+ parray[1] = parray[2] = parray[3] = 0.0F;
+ save_SamplerParameterfv(sampler, pname, parray);
}
static void GLAPIENTRY
--
1.8.2.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] i965/gen7: Add defines for Memory Object Control State
On 05/09/2013 04:48 PM, Chad Versace wrote:
Tested-by: Matt Turner matts...@gmail.com
Signed-off-by: Chad Versace chad.vers...@linux.intel.com
---
src/mesa/drivers/dri/i965/brw_defines.h | 20
1 file changed, 20 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_defines.h
b/src/mesa/drivers/dri/i965/brw_defines.h
index 6517f24..f574cb7 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -503,6 +503,8 @@
#define BRW_SURFACE_Y_OFFSET_MASK INTEL_MASK(23, 20)
#define GEN7_SURFACE_MIN_LOD_SHIFT 4
#define GEN7_SURFACE_MIN_LOD_MASK INTEL_MASK(7, 4)
+#define GEN7_SURFACE_MOCS_SHIFT 16
+#define GEN7_SURFACE_MOCS_MASK INTEL_MASK(19, 16)
/* Surface state DW6 */
#define GEN7_SURFACE_MCS_ENABLE (1 0)
@@ -1660,6 +1662,24 @@ enum brw_wm_barycentric_interp_mode {
*/
#define BRW_MAX_NUM_BUFFER_ENTRIES(1 27)
+/* Memory Object Control State, Gen7 */
+/* L3 Cacheability Control */
+#define GEN7_MOCS_L3_UNCACHEABLE0
+#define GEN7_MOCS_L3_CACHEABLE 1
+/* LCC Cacheability Control */
+#define GEN7_MOCS_LCC_USE_PTE (0 1)
+#define GEN7_MOCS_LCC_CACHEABLE (1 1)
+
+/* Memory Object Control State, Haswell */
+/* L3 Cacheability Control */
+#define HSW_MOCS_L3_UNCACHEABLE 0
+#define HSW_MOCS_L3_CACHEABLE 1
+/* LCC Cacheability Control */
+#define HSW_MOCS_LCC_USE_PTE(0 1)
+#define HSW_MOCS_LCC_UNCACHEABLE(1 1)
+#define HSW_MOCS_LCC_WB_TO_LLC_ELLC (2 1)
+#define HSW_MOCS_LCC_WB_TO_LLC (3 1)
FWIW, this last #define is wrong. 3 1 means write-back caching in
eLLC only, but uncached in LLC.
I'm working up a new patch set.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] hw_gl_select branch status
Hello dear mesa developers, What is current status of hw_gl_select branch? Is there any reason keeping it back from being merged into the master branch? Best regards, Siavash Eliasi. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] glsl: Make a local variable to avoid restating this array lookup.
On Fri, May 31, 2013 at 12:37:36PM -0700, Eric Anholt wrote:
---
src/glsl/link_uniforms.cpp | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/src/glsl/link_uniforms.cpp b/src/glsl/link_uniforms.cpp
index ad63668..54d54cf 100644
--- a/src/glsl/link_uniforms.cpp
+++ b/src/glsl/link_uniforms.cpp
@@ -640,7 +640,9 @@ link_assign_uniform_locations(struct gl_shader_program
*prog)
*/
count_uniform_size uniform_size(prog-UniformHash);
for (unsigned i = 0; i MESA_SHADER_TYPES; i++) {
- if (prog-_LinkedShaders[i] == NULL)
+ struct gl_shader *sh = prog-_LinkedShaders[i];
+
+ if (sh == NULL)
continue;
/* Uniforms that lack an initializer in the shader code have an initial
@@ -655,13 +657,13 @@ link_assign_uniform_locations(struct gl_shader_program
*prog)
memset(prog-_LinkedShaders[i]-SamplerUnits, 0,
sizeof(prog-_LinkedShaders[i]-SamplerUnits));
Use it here as well?
- link_update_uniform_buffer_variables(prog-_LinkedShaders[i]);
+ link_update_uniform_buffer_variables(sh);
/* Reset various per-shader target counts.
*/
uniform_size.start_shader();
- foreach_list(node, prog-_LinkedShaders[i]-ir) {
+ foreach_list(node, sh-ir) {
ir_variable *const var = ((ir_instruction *) node)-as_variable();
if ((var == NULL) || (var-mode != ir_var_uniform))
@@ -678,9 +680,8 @@ link_assign_uniform_locations(struct gl_shader_program
*prog)
uniform_size.process(var);
}
- prog-_LinkedShaders[i]-num_samplers =
uniform_size.num_shader_samplers;
- prog-_LinkedShaders[i]-num_uniform_components =
- uniform_size.num_shader_uniform_components;
+ sh-num_samplers = uniform_size.num_shader_samplers;
+ sh-num_uniform_components =
uniform_size.num_shader_uniform_components;
}
const unsigned num_user_uniforms = uniform_size.num_active_uniforms;
--
1.8.3.rc0
___
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 63404] [wayland egl] intel_do_flush_locked failed: invalid argument, crash
https://bugs.freedesktop.org/show_bug.cgi?id=63404 Ander Conselvan de Oliveira conselv...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Ander Conselvan de Oliveira conselv...@gmail.com --- Kernel stable releases 3.8.13 and 3.9.2 contain the fix for this issue. People still seeing this should (request their distros to) pick up the following patch: authorDave Airlie airl...@gmail.com2013-04-21 23:54:36 (GMT) committerDave Airlie airl...@redhat.com2013-04-30 23:30:15 (GMT) commit219b47339ced80ca580bb6ce7d1636166984afa7 (patch) tree1646e5e3b5998a5b13f71c8f06b7a28a0163fbe7 parentc55b6b3da25aa3af36ec51a13a4ed15fef0d7a73 (diff) drm/prime: keep a reference from the handle to exported dma-buf (v6) -- 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] hw_gl_select branch status
On Mon, Jun 3, 2013 at 3:22 AM, Siavash Eliasi siavashser...@gmail.com wrote: Hello dear mesa developers, What is current status of hw_gl_select branch? Is there any reason keeping it back from being merged into the master branch? IIRC, Brian wanted to review it a bit more, but I guess he never got to it. It probably needs to be fixed up for the changes in mesa since then. Here's the previous thread: http://lists.freedesktop.org/archives/mesa-dev/2011-August/010072.html Alex Best regards, Siavash Eliasi. ___ 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] [v6 2/9] intel: do not create renderbuffers out of planar images
On Mon, Jun 3, 2013 at 2:21 AM, Chad Versace chad.vers...@linux.intel.com wrote: I'll say it again: I think we should prevent creation of 2D texture targets from dma_buf images, and permit only creation of external textures. yeah, I think the intention was only external textures.. I can't think of any use case where we need to create a full blown texture from dmabuf. I guess probably the better route if you needed to do this would be to have some other extension to export to dmabuf from a non-external eglImage. BR, -R ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] and a random apitrace/gallium question..
- Original Message - On Fri, May 31, 2013 at 10:18 AM, José Fonseca jose.r.fons...@gmail.com wrote: I'd support such change. Be it through GL_GREMEDY_string_marker, or ARB_debug_output's glDebugMessageInsertARB(DEBUG_SOURCE_THIRD_PARTY_ARB, ...), or KHR_debug's glPushDebugGroup(). A Gallium interface change would be necessary to pass these annotations to the drivers. This discussion would be more appropriate in Mesa-dev mailing list though. I looked at the relevant specs (KHR_debug, ARB_debug_output), and I believe the most natural / standard-compliant way of implementing this would be to rely on glDebugMessageInsertARB(GL_DEBUG_SOURCE_THIRD_PARTY_ARB). In particular: - apitrace's glretrace should be extended with an option (--insert-markers) that would annotated the GL command stream with calls like: glDebugMessageInsertARB( GL_DEBUG_SOURCE_THIRD_PARTY, // We still filter out these messages. GL_DEBUG_TYPE_OTHER, 123456, GL_DEBUG_SEVERITY_MEDIUM, -1, Call 123456); but only where there is a bound countext and (probably only outside glBegin/glEnd). and it should call glDebugMessageControlARB(GL_DEBUG_SOURCE_THIRD_PARTY, GL_DONT_CARE, GL_DONT_CARE, 0, NULL, GL_FALSE); to prevent dumping its own messages. - gallium interface should be extended with a new method pipe_context::insert_marker(pipe_context *, const char *marker) which would be called for at least GL_DEBUG_SOURCE_THIRD_PARTY (and potentially GL_DEBUG_SOURCE_APPLICATION), but only on debug builds. This is for full GL. For GLES we could do the same via EXT_debug_marker.txt's glInsertEventMarkerEXT. I could probably handle the gallium bits to let the driver intercept the messages. I'd appreciate that. As I'm afraid I don't have the time to do it myself, and it is probably better if this is done on a driver that actually cares about this. I'd just wait a couple more days before start executing to give opportunity for others to voice any concerns/suggestions. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] and a random apitrace/gallium question..
On Mon, Jun 3, 2013 at 10:41 AM, Jose Fonseca jfons...@vmware.com wrote: - Original Message - On Fri, May 31, 2013 at 10:18 AM, José Fonseca jose.r.fons...@gmail.com wrote: I'd support such change. Be it through GL_GREMEDY_string_marker, or ARB_debug_output's glDebugMessageInsertARB(DEBUG_SOURCE_THIRD_PARTY_ARB, ...), or KHR_debug's glPushDebugGroup(). A Gallium interface change would be necessary to pass these annotations to the drivers. This discussion would be more appropriate in Mesa-dev mailing list though. I looked at the relevant specs (KHR_debug, ARB_debug_output), and I believe the most natural / standard-compliant way of implementing this would be to rely on glDebugMessageInsertARB(GL_DEBUG_SOURCE_THIRD_PARTY_ARB). hmm, these look more about letting the gl driver send log msgs to the app.. although maybe it is the best extension we have? Anyways, I'll give a few days to see if anyone else has any opinions and then try to figure out how to hook it up through gallium BR, -R In particular: - apitrace's glretrace should be extended with an option (--insert-markers) that would annotated the GL command stream with calls like: glDebugMessageInsertARB( GL_DEBUG_SOURCE_THIRD_PARTY, // We still filter out these messages. GL_DEBUG_TYPE_OTHER, 123456, GL_DEBUG_SEVERITY_MEDIUM, -1, Call 123456); but only where there is a bound countext and (probably only outside glBegin/glEnd). and it should call glDebugMessageControlARB(GL_DEBUG_SOURCE_THIRD_PARTY, GL_DONT_CARE, GL_DONT_CARE, 0, NULL, GL_FALSE); to prevent dumping its own messages. - gallium interface should be extended with a new method pipe_context::insert_marker(pipe_context *, const char *marker) which would be called for at least GL_DEBUG_SOURCE_THIRD_PARTY (and potentially GL_DEBUG_SOURCE_APPLICATION), but only on debug builds. This is for full GL. For GLES we could do the same via EXT_debug_marker.txt's glInsertEventMarkerEXT. I could probably handle the gallium bits to let the driver intercept the messages. I'd appreciate that. As I'm afraid I don't have the time to do it myself, and it is probably better if this is done on a driver that actually cares about this. I'd just wait a couple more days before start executing to give opportunity for others to voice any concerns/suggestions. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 65225] [softpipe] piglit interpolation-none-gl_BackColor-flat-fixed regression
https://bugs.freedesktop.org/show_bug.cgi?id=65225 --- Comment #1 from Zack Rusin za...@vmware.com --- That seems to be passing now, is that right? I think I fixed it in a commit 978d5ed06bfc3d87a4b1ca1981caeeaa88de2790 draw: fix vs/fs input/output mismatches committed right after the one you mentioned. -- 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] softpipe: draw_find_shader_output returns -1 on invalid outputs
It was changed from 0 to allow shader outputs at 0 that are different from position. Signed-off-by: Zack Rusin za...@vmware.com --- src/gallium/drivers/softpipe/sp_state_derived.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/drivers/softpipe/sp_state_derived.c b/src/gallium/drivers/softpipe/sp_state_derived.c index 93cd38e..6115349 100644 --- a/src/gallium/drivers/softpipe/sp_state_derived.c +++ b/src/gallium/drivers/softpipe/sp_state_derived.c @@ -127,7 +127,7 @@ softpipe_get_vertex_info(struct softpipe_context *softpipe) src = draw_find_shader_output(softpipe-draw, fsInfo-input_semantic_name[i], fsInfo-input_semantic_index[i]); -if (fsInfo-input_semantic_name[i] == TGSI_SEMANTIC_COLOR src == 0) +if (fsInfo-input_semantic_name[i] == TGSI_SEMANTIC_COLOR src == -1) /* try and find a bcolor */ src = draw_find_shader_output(softpipe-draw, TGSI_SEMANTIC_BCOLOR, fsInfo-input_semantic_index[i]); -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] hw_gl_select branch status
I've rebased the patch and fixed up some build failures. If you want to play with it, here is the updated branch: http://cgit.freedesktop.org/~ab/mesa/log/?h=hw_gl_select2 And for more information there is this bug report: https://bugs.freedesktop.org/show_bug.cgi?id=34495 Andreas. 2013/6/3 Alex Deucher alexdeuc...@gmail.com On Mon, Jun 3, 2013 at 3:22 AM, Siavash Eliasi siavashser...@gmail.com wrote: Hello dear mesa developers, What is current status of hw_gl_select branch? Is there any reason keeping it back from being merged into the master branch? IIRC, Brian wanted to review it a bit more, but I guess he never got to it. It probably needs to be fixed up for the changes in mesa since then. Here's the previous thread: http://lists.freedesktop.org/archives/mesa-dev/2011-August/010072.html Alex Best regards, Siavash Eliasi. ___ 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] softpipe: draw_find_shader_output returns -1 on invalid outputs
On Thu, May 30, 2013 at 3:03 PM, Zack Rusin za...@vmware.com wrote: It was changed from 0 to allow shader outputs at 0 that are different from position. Signed-off-by: Zack Rusin za...@vmware.com --- src/gallium/drivers/softpipe/sp_state_derived.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/drivers/softpipe/sp_state_derived.c b/src/gallium/drivers/softpipe/sp_state_derived.c index 93cd38e..6115349 100644 --- a/src/gallium/drivers/softpipe/sp_state_derived.c +++ b/src/gallium/drivers/softpipe/sp_state_derived.c @@ -127,7 +127,7 @@ softpipe_get_vertex_info(struct softpipe_context *softpipe) src = draw_find_shader_output(softpipe-draw, fsInfo-input_semantic_name[i], fsInfo-input_semantic_index[i]); -if (fsInfo-input_semantic_name[i] == TGSI_SEMANTIC_COLOR src == 0) +if (fsInfo-input_semantic_name[i] == TGSI_SEMANTIC_COLOR src == -1) /* try and find a bcolor */ src = draw_find_shader_output(softpipe-draw, TGSI_SEMANTIC_BCOLOR, fsInfo-input_semantic_index[i]); Reviewed-by: Brian Paul bri...@vmware.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Prevent possible out-of-bounds read by save_SamplerParameterfv.
On Mon, Jun 3, 2013 at 12:24 AM, Vinson Lee v...@freedesktop.org wrote:
Fixes Out-of-bounds access defect reported by Coverity.
Signed-off-by: Vinson Lee v...@freedesktop.org
---
src/mesa/main/dlist.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/dlist.c b/src/mesa/main/dlist.c
index c37b15e..6c26313 100644
--- a/src/mesa/main/dlist.c
+++ b/src/mesa/main/dlist.c
@@ -7056,7 +7056,10 @@ save_SamplerParameterfv(GLuint sampler, GLenum
pname, const GLfloat *params)
static void GLAPIENTRY
save_SamplerParameterf(GLuint sampler, GLenum pname, GLfloat param)
{
- save_SamplerParameterfv(sampler, pname, param);
+ GLfloat parray[4];
+ parray[0] = param;
+ parray[1] = parray[2] = parray[3] = 0.0F;
+ save_SamplerParameterfv(sampler, pname, parray);
}
static void GLAPIENTRY
Reviewed-by: Brian Paul bri...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] hw_gl_select branch status
On Mon, Jun 3, 2013 at 7:26 AM, Alex Deucher alexdeuc...@gmail.com wrote: On Mon, Jun 3, 2013 at 3:22 AM, Siavash Eliasi siavashser...@gmail.com wrote: Hello dear mesa developers, What is current status of hw_gl_select branch? Is there any reason keeping it back from being merged into the master branch? IIRC, Brian wanted to review it a bit more, but I guess he never got to it. Yeah, that was a long time ago. I'll try to take a look this week. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/15] Fixes for MSAA GLX visuals, u_blitter cleanups
On Sat, Jun 1, 2013 at 8:29 AM, Marek Olšák mar...@gmail.com wrote: This series fixes a lot of issues with MSAA visuals, in particular the management of MSAA front and back buffers in st/dri and CopyPixels in st/mesa. There is a change in st/dri which may improve performance if a DRI2 invalidate event is generated every frame (e.g. with page flipping). I didn't look at the r600 change very closely but patches 1-7 are Reviewed-by: Brian Paul bri...@vmware.com -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] and a random apitrace/gallium question..
- Original Message - On Mon, Jun 3, 2013 at 10:41 AM, Jose Fonseca jfons...@vmware.com wrote: - Original Message - On Fri, May 31, 2013 at 10:18 AM, José Fonseca jose.r.fons...@gmail.com wrote: I'd support such change. Be it through GL_GREMEDY_string_marker, or ARB_debug_output's glDebugMessageInsertARB(DEBUG_SOURCE_THIRD_PARTY_ARB, ...), or KHR_debug's glPushDebugGroup(). A Gallium interface change would be necessary to pass these annotations to the drivers. This discussion would be more appropriate in Mesa-dev mailing list though. I looked at the relevant specs (KHR_debug, ARB_debug_output), and I believe the most natural / standard-compliant way of implementing this would be to rely on glDebugMessageInsertARB(GL_DEBUG_SOURCE_THIRD_PARTY_ARB). hmm, these look more about letting the gl driver send log msgs to the app.. Far from it. The spec is crystal clear on that regard, from http://www.opengl.org/registry/specs/KHR/debug.txt : [...] This extension also defines debug markers, a mechanism for the OpenGL application to annotate the command stream with markers for discrete events. [...] 5.5.1 - Debug Messages A debug message is uniquely identified by the source that generated it, a type within that source, and an unsigned integer ID identifying the message within that type. The message source is one of the symbolic constants listed in Table 5.3. The message type is one of the symbolic constants listed in Table 5.4. Debug Output Message Source Messages Generated by --- - DEBUG_SOURCE_API_ARB The GL DEBUG_SOURCE_SHADER_COMPILER_ARB The GLSL shader compiler or compilers for other extension-provided languages DEBUG_SOURCE_WINDOW_SYSTEM_ARBThe window system, such as WGL or GLX DEBUG_SOURCE_THIRD_PARTY_ARB External debuggers or third-party middleware libraries DEBUG_SOURCE_APPLICATION_ARB The application DEBUG_SOURCE_OTHER_ARBSources that do not fit to any of the ones listed above Table 5.3: Sources of debug output messages. Each message must originate from a source listed in this table. although maybe it is the best extension we have? It seems to fit our needs quite well AFAICT. KHR_debug is pretty much a superset of everything out there, plus it is part of core OpenGL 4.3. And there is even a source for our needs -- DEBUG_SOURCE_THIRD_PARTY_ARB -- External debuggers... Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [v6 2/9] intel: do not create renderbuffers out of planar images
Chad Versace chad.vers...@linux.intel.com writes:
On 05/30/2013 01:20 AM, Daniel Vetter wrote:
On Thu, May 30, 2013 at 9:49 AM, Pohjolainen, Topi
topi.pohjolai...@intel.com wrote:
On Tue, May 28, 2013 at 01:33:18PM -0700, Eric Anholt wrote:
Topi Pohjolainen topi.pohjolai...@intel.com writes:
Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
src/mesa/drivers/dri/intel/intel_fbo.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
b/src/mesa/drivers/dri/intel/intel_fbo.c
index 69f8629..7ccbaa8 100644
--- a/src/mesa/drivers/dri/intel/intel_fbo.c
+++ b/src/mesa/drivers/dri/intel/intel_fbo.c
@@ -280,6 +280,10 @@ intel_image_target_renderbuffer_storage(struct
gl_context *ctx,
if (image == NULL)
return;
+ /* Planar buffers are not supported as render targets. */
+ if (image-planar_format image-planar_format-nplanes 1)
+ return;
+
/* __DRIimage is opaque to the core so it has to be checked here */
switch (image-format) {
case MESA_FORMAT_RGBA_REV:
OK, this answers one question I had about what our support was going to
be. But what about glEGLImageTargetTexture2DOES()?
Are we only going to support planar textures with image_external? My
thought is yes. How about on HSW with the YUV sampler support? Are
we going to relayout the data in the incoming fds to a copy that can
support sampling from them, or are we going to reject incoming fds that
don't fit the required layout? And if we decide to reject anything, are
we going to reject it at the or the dmabuf_import stage or the
image_external stage?
I was also thinking that planar would be supported only by image_external,
and I
hadn't even thought about HSW yet.
I think the same formats supported in image_external should also be supported
by dma_buf_import. This would allow us to write Piglit tests for any supported
image_external format.
If the set of supported dma_buf_import formats is a subset of the
image_external
formats, then how do you propose we write tests (Piglit or non-Piglit) for the
extra image_external formats?
To avoid any implementation weirdness, though, I think we should prevent
creation of 2D texture targets (GL_TEXTURE_2D) from dma_buf images, and
permit only creation of external textures (GL_TEXTURE_EXTERNAL).
External unfortunately requires that you rewrite your shaders, which is
ridiculous, but I don't see any way to make GL_OES_EGL_image really
useful what with:
As a result of this referencing operation, all of the pixel
data in the buffer used as the EGLImage source resource (i.e., the
buffer parameter passed to the CreateImageOES command that returned
image) will become undefined.
So, while I *hate* the external spec, I don't really see much point in
supporting dmabufs with GL_OES_EGL_image any more, given that it allows
the driver to just throw out the data that was in the image before.
pgp7vHWRQ4nrr.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] and a random apitrace/gallium question..
On Mon, Jun 3, 2013 at 11:56 AM, Jose Fonseca jfons...@vmware.com wrote: - Original Message - On Mon, Jun 3, 2013 at 10:41 AM, Jose Fonseca jfons...@vmware.com wrote: - Original Message - On Fri, May 31, 2013 at 10:18 AM, José Fonseca jose.r.fons...@gmail.com wrote: I'd support such change. Be it through GL_GREMEDY_string_marker, or ARB_debug_output's glDebugMessageInsertARB(DEBUG_SOURCE_THIRD_PARTY_ARB, ...), or KHR_debug's glPushDebugGroup(). A Gallium interface change would be necessary to pass these annotations to the drivers. This discussion would be more appropriate in Mesa-dev mailing list though. I looked at the relevant specs (KHR_debug, ARB_debug_output), and I believe the most natural / standard-compliant way of implementing this would be to rely on glDebugMessageInsertARB(GL_DEBUG_SOURCE_THIRD_PARTY_ARB). hmm, these look more about letting the gl driver send log msgs to the app.. Far from it. The spec is crystal clear on that regard, from http://www.opengl.org/registry/specs/KHR/debug.txt : [...] This extension also defines debug markers, a mechanism for the OpenGL application to annotate the command stream with markers for discrete events. ahh, my bad.. I stopped reading too soon :-P yeah, then it sounds like a good fit BR, -R [...] 5.5.1 - Debug Messages A debug message is uniquely identified by the source that generated it, a type within that source, and an unsigned integer ID identifying the message within that type. The message source is one of the symbolic constants listed in Table 5.3. The message type is one of the symbolic constants listed in Table 5.4. Debug Output Message Source Messages Generated by --- - DEBUG_SOURCE_API_ARB The GL DEBUG_SOURCE_SHADER_COMPILER_ARB The GLSL shader compiler or compilers for other extension-provided languages DEBUG_SOURCE_WINDOW_SYSTEM_ARBThe window system, such as WGL or GLX DEBUG_SOURCE_THIRD_PARTY_ARB External debuggers or third-party middleware libraries DEBUG_SOURCE_APPLICATION_ARB The application DEBUG_SOURCE_OTHER_ARBSources that do not fit to any of the ones listed above Table 5.3: Sources of debug output messages. Each message must originate from a source listed in this table. although maybe it is the best extension we have? It seems to fit our needs quite well AFAICT. KHR_debug is pretty much a superset of everything out there, plus it is part of core OpenGL 4.3. And there is even a source for our needs -- DEBUG_SOURCE_THIRD_PARTY_ARB -- External debuggers... Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 08/15] st/mesa: make generic CopyPixels path work with MSAA visuals
On Sat, Jun 1, 2013 at 8:29 AM, Marek Olšák mar...@gmail.com wrote:
We have to use pipe-blit, not resource_copy_region, so that the read
buffer
is resolved if it's multisampled. I also removed the CPU-based copying,
which just did format conversion (obsoleted by the blit).
Also, the layer/slice/face of the read buffer is taken into account (this
was
ignored).
Last but not least, the format choosing is improved to take float and
integer
read buffers into account.
---
src/mesa/state_tracker/st_cb_drawpixels.c | 162
+
1 file changed, 70 insertions(+), 92 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_drawpixels.c
b/src/mesa/state_tracker/st_cb_drawpixels.c
index eb75500..1c26315 100644
--- a/src/mesa/state_tracker/st_cb_drawpixels.c
+++ b/src/mesa/state_tracker/st_cb_drawpixels.c
@@ -1474,10 +1474,9 @@ st_CopyPixels(struct gl_context *ctx, GLint srcx,
GLint srcy,
struct pipe_sampler_view *sv[2];
int num_sampler_view = 1;
GLfloat *color;
- enum pipe_format srcFormat, texFormat;
+ enum pipe_format srcFormat;
GLboolean invertTex = GL_FALSE;
GLint readX, readY, readW, readH;
- GLuint sample_count;
struct gl_pixelstore_attrib pack = ctx-DefaultPacking;
struct st_fp_variant *fpv;
@@ -1539,35 +1538,51 @@ st_CopyPixels(struct gl_context *ctx, GLint srcx,
GLint srcy,
/* update fragment program constants */
st_upload_constants(st, fpv-parameters, PIPE_SHADER_FRAGMENT);
- sample_count = rbRead-texture-nr_samples;
- /* I believe this would be legal, presumably would need to do a resolve
- for color, and for depth/stencil spec says to just use one of the
- depth/stencil samples per pixel? Need some transfer clarifications.
*/
- assert(sample_count 2);
-
+ /* Choose the format for the temporary texture. */
srcFormat = rbRead-texture-format;
- if (screen-is_format_supported(screen, srcFormat, st-internal_target,
- sample_count,
- PIPE_BIND_SAMPLER_VIEW)) {
- texFormat = srcFormat;
- }
- else {
- /* srcFormat can't be used as a texture format */
+ if (!screen-is_format_supported(screen, srcFormat,
st-internal_target, 0,
+PIPE_BIND_SAMPLER_VIEW |
+(type == GL_COLOR ?
PIPE_BIND_RENDER_TARGET
+ : PIPE_BIND_DEPTH_STENCIL))) {
if (type == GL_DEPTH) {
- texFormat = st_choose_format(st, GL_DEPTH_COMPONENT,
- GL_NONE, GL_NONE,
st-internal_target,
- sample_count,
PIPE_BIND_DEPTH_STENCIL,
- FALSE);
- assert(texFormat != PIPE_FORMAT_NONE);
+ srcFormat = st_choose_format(st, GL_DEPTH_COMPONENT, GL_NONE,
+ GL_NONE, st-internal_target, 0,
+ PIPE_BIND_SAMPLER_VIEW |
+ PIPE_BIND_DEPTH_STENCIL, FALSE);
}
else {
- /* default color format */
- texFormat = st_choose_format(st, GL_RGBA,
- GL_NONE, GL_NONE,
st-internal_target,
- sample_count,
PIPE_BIND_SAMPLER_VIEW,
- FALSE);
- assert(texFormat != PIPE_FORMAT_NONE);
+ assert(type == GL_COLOR);
+
+ if (util_format_is_float(srcFormat)) {
+srcFormat = st_choose_format(st, GL_RGBA32F, GL_NONE,
+ GL_NONE, st-internal_target, 0,
+ PIPE_BIND_SAMPLER_VIEW |
+ PIPE_BIND_RENDER_TARGET, FALSE);
+ }
+ else if (util_format_is_pure_sint(srcFormat)) {
+srcFormat = st_choose_format(st, GL_RGBA32I, GL_NONE,
+ GL_NONE, st-internal_target, 0,
+ PIPE_BIND_SAMPLER_VIEW |
+ PIPE_BIND_RENDER_TARGET, FALSE);
+ }
+ else if (util_format_is_pure_uint(srcFormat)) {
+srcFormat = st_choose_format(st, GL_RGBA32UI, GL_NONE,
+ GL_NONE, st-internal_target, 0,
+ PIPE_BIND_SAMPLER_VIEW |
+ PIPE_BIND_RENDER_TARGET, FALSE);
+ }
+ else {
+srcFormat = st_choose_format(st, GL_RGBA, GL_NONE,
+ GL_NONE, st-internal_target, 0,
+ PIPE_BIND_SAMPLER_VIEW |
+ PIPE_BIND_RENDER_TARGET, FALSE);
+ }
+ }
I seem to recall that this choose a gallium format
[Mesa-dev] [PATCH] gallium: Document format name conventions
Other things to maybe add: - More detail on FOURCC formats, or at least a link - SSCALED/USCALED? Not sure what they're meant to be really Signed-off-by: Adam Jackson a...@redhat.com --- src/gallium/docs/format.rst | 39 +++ 1 file changed, 39 insertions(+) create mode 100644 src/gallium/docs/format.rst diff --git a/src/gallium/docs/format.rst b/src/gallium/docs/format.rst new file mode 100644 index 000..e6de569 --- /dev/null +++ b/src/gallium/docs/format.rst @@ -0,0 +1,39 @@ +Formats in gallium +== + +Gallium format names mostly follow D3D10 conventions, with some extensions. + +Format names like XnYnZnWn have the X component in the lowest-address n bits +and the W component in the highest-address n bits; for B8G8R8A8, byte 0 is +blue and byte 3 is red. Note that platform endianness is not considered +in this definition. + +Format suffixes affect the interpretation of the channel: + +- ``SINT``: N bit signed integer [-2^(N-1) ... 2^(N-1) - 1] +- ``SNORM``:N bit signed integer normalized to [-1 ... 1] +- ``FIXED``:Signed fixed point integer, (N/2 - 1) bits of mantissa +- ``FLOAT``:N bit IEEE754 float +- ``NORM``: Normalized integers, signed or unsigned per channel +- ``UINT``: N bit unsigned integer [0 ... 2^N - 1] +- ``UNORM``:N bit unsigned integer normalized to [0 ... 1] + +There are two exceptions for ``FLOAT``. ``R9G9B9E5_FLOAT`` is nine bits +each of red green and blue mantissa, with a shared five bit exponent. +``R11G11B10_FLOAT`` is five bits of exponent and five or six bits of mantissa +for each color channel. + +For the ``NORM`` suffix, the signedness of each channel is indicated with an +S or U after the number of channel bits, as in ``R5SG5SB6U_NORM``. + +The ``SRGB`` suffix is like ``UNORM`` in range, but in the sRGB colorspace. + +Compressed formats are named first by the compression format string (``DXT1``, +``ETC1``, etc), followed by a format-specific subtype. Refer to the +appropriate compression spec for details. + +Formats used in video playback are named by their FOURCC code. + +Format names with an embedded underscore are subsampled. ``R8G8_B8G8`` is a +single 32-bit block of two pixels, where the R and B values are repeated in +both pixels. -- 1.8.2.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] meta: In CopyTexSubImage, use matching format for Z32_FLOAT_X24S8 textures.
On 3 June 2013 09:02, Eric Anholt e...@anholt.net wrote:
Paul Berry stereotype...@gmail.com writes:
The meta path for CopyTexSubImage operates by reading the source image
to a temporary buffer using glReadPixels and then uploading it to the
texture using TexSubImage. This patch ensures that when the texture
format is MESA_FORMAT_Z32_FLOAT_X24S8, we use the proper image type
for the temporary buffer (GL_FLOAT_32_UNSIGNED_INT_24_8_REV).
Fixes some failures with piglit tests copyteximage
{1D,2D,CUBE,RECT,2D_ARRAY}.
---
src/mesa/drivers/common/meta.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/common/meta.c
b/src/mesa/drivers/common/meta.c
index ca5f5a1..637ec70 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -3767,7 +3767,10 @@ get_temp_image_type(struct gl_context *ctx,
gl_format format)
case GL_DEPTH_COMPONENT:
return GL_UNSIGNED_INT;
case GL_DEPTH_STENCIL:
- return GL_UNSIGNED_INT_24_8;
+ if (format == MESA_FORMAT_Z32_FLOAT_X24S8)
+ return GL_FLOAT_32_UNSIGNED_INT_24_8_REV;
+ else
+ return GL_UNSIGNED_INT_24_8;
default:
_mesa_problem(ctx, Unexpected format %d in
get_temp_image_type(),
baseFormat);
--
1.8.3
I think the version of this patch I sent out on Thursday is better.
Do you mean [PATCH 2/2] meta: Fix temporary image type for float
depth/stencil.? I'm ok going with your version instead. It looks like it
got a positive review on Thrusday--when are you planning to push it?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] intel: Don't try to blorp or blit CopyTexSubImage(1D_ARRAY).
Paul Berry stereotype...@gmail.com writes: Blorp and the hardware blitter can't be used to implement CopyTexSubImage when the image type is 1D_ARRAY, because of a coordinate system mismatch (the Y coordinate in the source image is supposed to be matched up to the Z coordinate in the destination texture). The hardware blitter path (intel_copy_texsubimage) contained a perf debug warning for this case, but it failed to actually fall back. The blorp path didn't even check. Fixes piglit test copyteximage 1D_ARRAY. I have a patch locally that fixed this within blorp, but I think I actually want to just change the driver interface so that Mesa core drives multi-slice copyteximages and the driver just gets a layer field for which one it's supposed to do. So I'm fine with this patch for the moment, since it will take a couple of days to do the core change. Reviewed-by: Eric Anholt e...@anholt.net pgpBR9MGcN1RM.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 15/15] st/dri: if flushing a drawable, don't set reason=SWAPBUFFERS
On Sat, Jun 1, 2013 at 8:29 AM, Marek Olšák mar...@gmail.com wrote:
0 means SWAPBUFFERS.
---
src/gallium/state_trackers/dri/drm/dri2.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/dri/drm/dri2.c
b/src/gallium/state_trackers/dri/drm/dri2.c
index 032614c..cc843b1 100644
--- a/src/gallium/state_trackers/dri/drm/dri2.c
+++ b/src/gallium/state_trackers/dri/drm/dri2.c
@@ -46,7 +46,7 @@
static void
dri2_flush_drawable(__DRIdrawable *dPriv)
{
- dri_flush(dPriv-driContextPriv, dPriv, __DRI2_FLUSH_DRAWABLE, 0);
+ dri_flush(dPriv-driContextPriv, dPriv, __DRI2_FLUSH_DRAWABLE, -1);
}
static void
I'm not terribly familiar with the DRI code you're touching, but the
changes look OK to me.
For the rest of the series: Reviewed-by: Brian Paul bri...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 65225] [softpipe] piglit interpolation-none-gl_BackColor-flat-fixed regression
https://bugs.freedesktop.org/show_bug.cgi?id=65225 --- Comment #2 from Vinson Lee v...@freedesktop.org --- (In reply to comment #1) That seems to be passing now, is that right? I think I fixed it in a commit 978d5ed06bfc3d87a4b1ca1981caeeaa88de2790 draw: fix vs/fs input/output mismatches committed right after the one you mentioned. mesa: c754f7a8fd53906acb9ef6ade715481a2c9f17de (master) Test still fails. -- 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] hw_gl_select branch status
On 06/03/2013 08:11 PM, Brian Paul wrote: On Mon, Jun 3, 2013 at 7:26 AM, Alex Deucher alexdeuc...@gmail.com mailto:alexdeuc...@gmail.com wrote: On Mon, Jun 3, 2013 at 3:22 AM, Siavash Eliasi siavashser...@gmail.com mailto:siavashser...@gmail.com wrote: Hello dear mesa developers, What is current status of hw_gl_select branch? Is there any reason keeping it back from being merged into the master branch? IIRC, Brian wanted to review it a bit more, but I guess he never got to it. Yeah, that was a long time ago. I'll try to take a look this week. -Brian I really appreciate your work to get this patch merged. This patch will hopefully make workflow a lot more pleasant for all Blender users. Thank you all for brilliant work! Best regards, Siavash Eliasi. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 65225] [softpipe] piglit interpolation-none-gl_BackColor-flat-fixed regression
https://bugs.freedesktop.org/show_bug.cgi?id=65225 --- Comment #3 from Zack Rusin za...@vmware.com --- Thanks Vinson. It should be now fixed with e54c924a0e9b9a504eae1eb68daaf51f21689629 , softpipe: draw_find_shader_output returns -1 on invalid outputs. -- 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] and a random apitrace/gallium question..
Thanks. That sounds handy. Another potentially very useful improvement along those lines, would be for apitrace to replay GL_KHR_debug's glObjectLabel() calls, and then use those application supplied labels instead of numbers when dumping state (in qapitrace). This would enable the app developer (or gl implementer) to see e.g. rock texture instead texture 99. And it would be relatively easy to implement on top of what you probably have. Of course, this would require GL apps and vendors to use/implement GL_KHR_debug. But given that it is part of OpenGL 4.3 standard, and is a small superset of ARB_debug_output, that shouldn't be an obstacle. Jose On Mon, Jun 3, 2013 at 5:29 PM, Peter Lohrmann pet...@valvesoftware.comwrote: I have a local change which extends ApiTrace to better support the various debug extensions, and have used it to mark up my traces. I don't track the whole log or handle the registering of callback functions, but do allow glDebugMessageInsertARB(..) and a few others to be included in the trace (and will get replayed if the host driver supports the extension). This allows those messages to also be used by other 3rd party debugging tools. At some point I hope to extend qapitrace to utilize these markers in the list of api calls to give a hierarchical view, but that's a ways off. I'll try to isolate that change and create a branch today to make it more widely available. - Peter -Original Message- From: apitrace-bounces+peterl=valvesoftware@lists.freedesktop.org[mailto: apitrace-bounces+peterl=valvesoftware@lists.freedesktop.org] On Behalf Of Rob Clark Sent: Monday, June 03, 2013 8:59 AM To: Jose Fonseca Cc: mesa-dev@lists.freedesktop.org; apitr...@lists.freedesktop.org Subject: Re: [Mesa-dev] and a random apitrace/gallium question.. On Mon, Jun 3, 2013 at 11:56 AM, Jose Fonseca jfons...@vmware.com wrote: - Original Message - On Mon, Jun 3, 2013 at 10:41 AM, Jose Fonseca jfons...@vmware.com wrote: - Original Message - On Fri, May 31, 2013 at 10:18 AM, José Fonseca jose.r.fons...@gmail.com wrote: I'd support such change. Be it through GL_GREMEDY_string_marker, or ARB_debug_output's glDebugMessageInsertARB(DEBUG_SOURCE_THIRD_PARTY_ARB, ...), or KHR_debug's glPushDebugGroup(). A Gallium interface change would be necessary to pass these annotations to the drivers. This discussion would be more appropriate in Mesa-dev mailing list though. I looked at the relevant specs (KHR_debug, ARB_debug_output), and I believe the most natural / standard-compliant way of implementing this would be to rely on glDebugMessageInsertARB(GL_DEBUG_SOURCE_THIRD_PARTY_ARB). hmm, these look more about letting the gl driver send log msgs to the app.. Far from it. The spec is crystal clear on that regard, from http://www.opengl.org/registry/specs/KHR/debug.txt : [...] This extension also defines debug markers, a mechanism for the OpenGL application to annotate the command stream with markers for discrete events. ahh, my bad.. I stopped reading too soon :-P yeah, then it sounds like a good fit BR, -R [...] 5.5.1 - Debug Messages A debug message is uniquely identified by the source that generated it, a type within that source, and an unsigned integer ID identifying the message within that type. The message source is one of the symbolic constants listed in Table 5.3. The message type is one of the symbolic constants listed in Table 5.4. Debug Output Message Source Messages Generated by --- - DEBUG_SOURCE_API_ARB The GL DEBUG_SOURCE_SHADER_COMPILER_ARB The GLSL shader compiler or compilers for other extension-provided languages DEBUG_SOURCE_WINDOW_SYSTEM_ARBThe window system, such as WGL or GLX DEBUG_SOURCE_THIRD_PARTY_ARB External debuggers or third-party middleware libraries DEBUG_SOURCE_APPLICATION_ARB The application DEBUG_SOURCE_OTHER_ARBSources that do not fit to any of the ones listed above Table 5.3: Sources of debug output messages. Each message must originate from a source listed in this table. although maybe it is the best extension we have? It seems to fit our needs quite well AFAICT. KHR_debug is pretty much a superset of everything out there, plus it is part of core OpenGL 4.3. And there is even a source for our needs -- DEBUG_SOURCE_THIRD_PARTY_ARB -- External debuggers... Jose ___ apitrace mailing list apitr...@lists.freedesktop.org
Re: [Mesa-dev] Do we support front buffer rendering with EGL? Do we want to?
On 05/31/2013 03:01 PM, Paul Berry wrote: The EGL 1.4 spec leaves some wiggle room about whether front buffer rendering is allowed, to accommodate window systems that don't permit front buffer rendering. However, since X11 supports front buffer rendering, it seems to me that Mesa-EGL-X11 ought to support it. I suspect that the wiggle room you mention refers to this text: -8- Some window systems may not allow rendering directly to the front buffer of a window surface. When such windows are made current to a context, the context will always have an EGL_RENDER_BUFFER attribute value of EGL_BACK_BUFFER. From the client API point of view these surfaces have only a back buffer and no front buffer, similar to pbuffer rendering (see section 2.2.2). Client APIs which generally have the ability to switch render target from back to front will not be able to do so when the window system does not allow this; from the point of view of the client API the front buffer for such windows does not exist. -8- When I read this, I think of Android's window system, in which the front buffer truly does not exist. Historically, X does have front buffers, so I don't think this the wiggle room clauses in this text apply to X. Also, some of us have pipe dreams of a future where Linux desktop apps transition over to using EGL instead of GLX. It seems like supporting front buffer rendering via EGL would help encourage that. If we really wish to deprecate GLX and push applications to use EGL, then I believe we need to support front-buffer rendering in EGL lest we break any existing and future GL applications that may rely on it. However, I've never done a survey of which applications do front buffer rendering and why, so some may argue that we really shouldn't care. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Fix glColorPointer(GL_FIXED)
On 05/31/2013 03:49 PM, Chad Versace wrote:
When a gl_client_array is created with glColorPointer,
gl_client_array::Normalized is true. This caused the translation from the
gl_client_array's type to a BRW_SURFACEFORMAT to assertion fail.
Yes, it does set Normalized, and yes, that would cause the translation
to fail.
This looks right to me.
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
Fixes the spinning cube's color in Android 4.2's ApiDemos.apk,
Graphics OpenGL ES.
Fixes assertion failure in mesa-demos/src/egl/opengles1/tri_x11 on Haswell
and Ivybridge:
brw_draw_upload.c:287: get_surface_type: Assertion `0' failed.
No Piglit regressions on Haswell.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42182
Issue: AXIA-2954
Signed-off-by: Chad Versace chad.vers...@linux.intel.com
---
src/mesa/drivers/dri/i965/brw_draw_upload.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_draw_upload.c
b/src/mesa/drivers/dri/i965/brw_draw_upload.c
index d2451f9..2ded14b 100644
--- a/src/mesa/drivers/dri/i965/brw_draw_upload.c
+++ b/src/mesa/drivers/dri/i965/brw_draw_upload.c
@@ -263,6 +263,14 @@ get_surface_type(struct intel_context *intel,
else {
return ubyte_types_norm[size];
}
+ case GL_FIXED:
+ if (intel-gen = 8 || intel-is_haswell)
+return fixed_point_types[size];
+
+ /* This produces GL_FIXED inputs as values between INT32_MIN and
+ * INT32_MAX, which will be scaled down by 1/65536 by the VS.
+ */
+ return int_types_scale[size];
/* See GL_ARB_vertex_type_2_10_10_10_rev.
* W/A: Pre-Haswell, the hardware doesn't really support the formats
we'd
* like to use here, so upload everything as UINT and fix
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/4] gallivm: (trivial) fix lp_build_concat_n
From: Roland Scheidegger srol...@vmware.com
The code was designed to handle no-op concat but failed (unless the
caller was using same pointer for src and dst).
---
src/gallium/auxiliary/gallivm/lp_bld_pack.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_pack.c
b/src/gallium/auxiliary/gallivm/lp_bld_pack.c
index 0a57e39..14fcd38 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_pack.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_pack.c
@@ -241,8 +241,12 @@ lp_build_concat_n(struct gallivm_state *gallivm,
assert(num_srcs = num_dsts);
assert((num_srcs % size) == 0);
- if (num_srcs == num_dsts)
+ if (num_srcs == num_dsts) {
+ for (i = 0; i num_dsts; ++i) {
+ dst[i] = src[i];
+ }
return 1;
+ }
for (i = 0; i num_dsts; ++i) {
dst[i] = lp_build_concat(gallivm, src[i * size], src_type, size);
--
1.7.9.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/4] gallivm: enhance special sse2 4x4f and 2x8f - 1x16ub conversion
From: Roland Scheidegger srol...@vmware.com
There's no good reason why it can't handle 2x4f-1x8ub, 1x4f-1x4ub and
1x8f-1x8ub cases, there might be legitimate reasons why we don't have
enough input vectors for a full destination vector, and using pack
intrinsics should still be much better than using generic conversion
(it looks like convert_alpha from the blend code might hit this though
I suspect it could be avoided).
---
src/gallium/auxiliary/gallivm/lp_bld_conv.c | 90 +--
1 file changed, 58 insertions(+), 32 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_conv.c
b/src/gallium/auxiliary/gallivm/lp_bld_conv.c
index eb2d096..f11361a 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_conv.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_conv.c
@@ -530,24 +530,22 @@ int lp_build_conv_auto(struct gallivm_state *gallivm,
dst_type-width== 8)
{
/* Special case 4x4f -- 1x16ub */
- if (src_type.length == 4 util_cpu_caps.has_sse2)
+ if (src_type.length == 4
+ util_cpu_caps.has_sse2)
{
- assert((num_srcs % 4) == 0);
-
- num_dsts = num_srcs / 4;
- dst_type-length = 16;
+ num_dsts = (num_srcs + 3) / 4;
+ dst_type-length = num_srcs * 4 = 16 ? 16 : num_srcs * 4;
lp_build_conv(gallivm, src_type, *dst_type, src, num_srcs, dst,
num_dsts);
return num_dsts;
}
/* Special case 2x8f -- 1x16ub */
- if (src_type.length == 8 util_cpu_caps.has_avx)
+ if (src_type.length == 8
+ util_cpu_caps.has_avx)
{
- assert((num_srcs % 2) == 0);
-
- num_dsts = num_srcs / 2;
- dst_type-length = 16;
+ num_dsts = (num_srcs + 1) / 2;
+ dst_type-length = num_srcs * 8 = 16 ? 16 : num_srcs * 8;
lp_build_conv(gallivm, src_type, *dst_type, src, num_srcs, dst,
num_dsts);
return num_dsts;
@@ -602,7 +600,7 @@ lp_build_conv(struct gallivm_state *gallivm,
num_tmps = num_srcs;
- /* Special case 4x4f -- 1x16ub
+ /* Special case 4x4f -- 1x16ub, 2x4f - 1x8ub, 1x4f - 1x4ub
*/
if (src_type.floating == 1
src_type.fixed== 0
@@ -616,20 +614,23 @@ lp_build_conv(struct gallivm_state *gallivm,
dst_type.sign == 0
dst_type.norm == 1
dst_type.width== 8
- dst_type.length == 16
- 4 * num_dsts == num_srcs
+ ((dst_type.length == 16 4 * num_dsts == num_srcs) ||
+(num_dsts == 1 dst_type.length * num_srcs == 16 num_srcs != 3))
util_cpu_caps.has_sse2)
{
struct lp_build_context bld;
- struct lp_type int16_type = dst_type;
- struct lp_type int32_type = dst_type;
+ struct lp_type int16_type, int32_type;
+ struct lp_type dst_type_ext = dst_type;
LLVMValueRef const_255f;
unsigned i, j;
lp_build_context_init(bld, gallivm, src_type);
+ dst_type_ext.length = 16;
+ int16_type = int32_type = dst_type_ext;
+
int16_type.width *= 2;
int16_type.length /= 2;
int16_type.sign = 1;
@@ -643,21 +644,34 @@ lp_build_conv(struct gallivm_state *gallivm,
for (i = 0; i num_dsts; ++i, src += 4) {
LLVMValueRef lo, hi;
- for (j = 0; j 4; ++j) {
+ for (j = 0; j dst_type.length / 4; ++j) {
tmp[j] = LLVMBuildFMul(builder, src[j], const_255f, );
tmp[j] = lp_build_iround(bld, tmp[j]);
}
+ if (num_srcs == 1) {
+tmp[1] = tmp[0];
+ }
+
/* relying on clamping behavior of sse2 intrinsics here */
lo = lp_build_pack2(gallivm, int32_type, int16_type, tmp[0], tmp[1]);
- hi = lp_build_pack2(gallivm, int32_type, int16_type, tmp[2], tmp[3]);
- dst[i] = lp_build_pack2(gallivm, int16_type, dst_type, lo, hi);
+
+ if (num_srcs 4) {
+hi = lo;
+ }
+ else {
+hi = lp_build_pack2(gallivm, int32_type, int16_type, tmp[2],
tmp[3]);
+ }
+ dst[i] = lp_build_pack2(gallivm, int16_type, dst_type_ext, lo, hi);
+ }
+ if (num_srcs 4) {
+ dst[0] = lp_build_extract_range(gallivm, dst[0], 0, dst_type.length);
}
return;
}
- /* Special case 2x8f -- 1x16ub
+ /* Special case 2x8f -- 1x16ub, 1x8f -1x8ub
*/
else if (src_type.floating == 1
src_type.fixed== 0
@@ -671,20 +685,23 @@ lp_build_conv(struct gallivm_state *gallivm,
dst_type.sign == 0
dst_type.norm == 1
dst_type.width== 8
- dst_type.length == 16
- 2 * num_dsts == num_srcs
+ ((dst_type.length == 16 2 * num_dsts == num_srcs) ||
+ (num_dsts == 1 dst_type.length * num_srcs == 8))
util_cpu_caps.has_avx) {
struct lp_build_context bld;
- struct lp_type int16_type = dst_type;
- struct lp_type int32_type = dst_type;
+ struct lp_type int16_type, int32_type;
+
[Mesa-dev] [PATCH 3/4] llvmpipe: cleanup of generate_unswizzled_blend
From: Roland Scheidegger srol...@vmware.com
Some parameters were used inconsistently, for instance not using
block_width/block_height/block_size for deferring number of pixels
but rather relying on guesses from the number of fragment shaders etc,
so fix this up (no actual change in behavior since the block size stays
fixed). (Though most of the code would work with different block_height,
with three exceptions, one being the hacked r11g11b10 conversions and
twiddle code which only work with block_height 2 not 1, and the last
one being blend vector type not being 128bit wide.)
---
src/gallium/drivers/llvmpipe/lp_state_fs.c | 59 +---
1 file changed, 37 insertions(+), 22 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_state_fs.c
b/src/gallium/drivers/llvmpipe/lp_state_fs.c
index a20cc78..a7bd836 100644
--- a/src/gallium/drivers/llvmpipe/lp_state_fs.c
+++ b/src/gallium/drivers/llvmpipe/lp_state_fs.c
@@ -100,6 +100,7 @@
#include lp_tex_sample.h
#include lp_flush.h
#include lp_state_fs.h
+#include lp_rast.h
/** Fragment shader number (for debugging) */
@@ -528,7 +529,7 @@ generate_fs_twiddle(struct gallivm_state *gallivm,
bool twiddle;
bool split;
- unsigned pixels = num_fs == 4 ? 1 : 2;
+ unsigned pixels = type.length / 4;
unsigned reorder_group;
unsigned src_channels;
unsigned src_count;
@@ -537,7 +538,7 @@ generate_fs_twiddle(struct gallivm_state *gallivm,
src_channels = dst_channels 3 ? dst_channels : 4;
src_count = num_fs * src_channels;
- assert(pixels == 2 || num_fs == 4);
+ assert(pixels == 2 || pixels == 1);
assert(num_fs * src_channels = Elements(src));
/*
@@ -917,6 +918,7 @@ scale_bits(struct gallivm_state *gallivm,
*/
static void
convert_to_blend_type(struct gallivm_state *gallivm,
+ unsigned block_size,
const struct util_format_description *src_fmt,
struct lp_type src_type,
struct lp_type dst_type,
@@ -928,7 +930,7 @@ convert_to_blend_type(struct gallivm_state *gallivm,
struct lp_type blend_type;
struct lp_type mem_type;
unsigned i, j, k;
- unsigned pixels = 16 / num_srcs;
+ unsigned pixels = block_size / num_srcs;
bool is_arith;
/*
@@ -945,13 +947,15 @@ convert_to_blend_type(struct gallivm_state *gallivm,
assert(dst_type.floating);
assert(dst_type.width == 32);
assert(dst_type.length % 4 == 0);
+ assert(num_srcs % 4 == 0);
+
for (i = 0; i 4; i++) {
tmpsrc[i] = src[i];
}
for (i = 0; i num_srcs / 4; i++) {
LLVMValueRef tmpsoa[4];
LLVMValueRef tmps = tmpsrc[i];
- if (num_srcs == 8) {
+ if (dst_type.length == 8) {
LLVMValueRef shuffles[8];
unsigned j;
/* fetch was 4 values but need 8-wide output values */
@@ -1062,6 +1066,7 @@ convert_to_blend_type(struct gallivm_state *gallivm,
*/
static void
convert_from_blend_type(struct gallivm_state *gallivm,
+unsigned block_size,
const struct util_format_description *src_fmt,
struct lp_type src_type,
struct lp_type dst_type,
@@ -1073,7 +1078,7 @@ convert_from_blend_type(struct gallivm_state *gallivm,
struct lp_type mem_type;
struct lp_type blend_type;
LLVMBuilderRef builder = gallivm-builder;
- unsigned pixels = 16 / num_srcs;
+ unsigned pixels = block_size / num_srcs;
bool is_arith;
/*
@@ -1090,11 +1095,12 @@ convert_from_blend_type(struct gallivm_state *gallivm,
assert(src_type.width == 32);
assert(src_type.length % 4 == 0);
assert(dst_type.width == 32);
+
for (i = 0; i num_srcs / 4; i++) {
LLVMValueRef tmpsoa[4], tmpdst;
lp_build_transpose_aos(gallivm, src_type, src[i * 4], tmpsoa);
tmpdst = lp_build_float_to_r11g11b10(gallivm, tmpsoa);
- if (num_srcs == 8) {
+ if (src_type.length == 8) {
LLVMValueRef tmpaos, shuffles[8];
unsigned j;
/*
@@ -1228,9 +1234,13 @@ convert_alpha(struct gallivm_state *gallivm,
row_type.length = alpha_type.length;
/* Twiddle the alpha to match pixels */
- lp_bld_quad_twiddle(gallivm, alpha_type, src_alpha, 4, src_alpha);
+ lp_bld_quad_twiddle(gallivm, alpha_type, src_alpha, block_height,
src_alpha);
- for (i = 0; i 4; ++i) {
+ /*
+* TODO this should use single lp_build_conv call for
+* src_count == 1 dst_channels == 1 case (dropping the concat below)
+*/
+ for (i = 0; i block_height; ++i) {
lp_build_conv(gallivm, alpha_type, row_type, src_alpha[i], 1,
src_alpha[i], 1);
}
@@ -1238,10 +1248,9 @@ convert_alpha(struct gallivm_state *gallivm,
row_type.length = length;
/* If only one channel we can only need the single alpha value per pixel */
- if (src_count == 1) {
-
[Mesa-dev] [PATCH 4/4] llvmpipe: reduce alignment requirement for 1d resources from 4x4 to 4x1
From: Roland Scheidegger srol...@vmware.com
For rendering to buffers, we cannot have any y alignment.
So make sure that tile clear commands only clear up to the fb width/height,
not more (do this for all resources actually as clearing more seems
pointless for other resources too). For the jit fs function, skip execution
of the lower half of the fragment shader for the 4x4 stamp completely,
for depth/stencil only load/store the values from the first row
(replace other row with undef).
For the blend function, also only load half the values from fs output,
replace the rest with undefs so that everything still operates on the
full 4x4 block to keep code the same between 4x1 and 4x4 (except for
load/store of course which also needs to skip (store) or replace these
values with undefs (load))., at the cost of slightly less optimal code
being produced in some cases.
Also reduce 1d and 1d array alignment too, because they can be handled the
same as buffers so don't need to waste memory.
v2: don't try to run special blend code for 4x1, (very) slightly less
complexity if we just use the same code as for 4x4 which may or may not
make it easier to optimize in the future (as we care a lot more about 4x4
performance than 1d).
---
src/gallium/drivers/llvmpipe/lp_bld_depth.c | 19 -
src/gallium/drivers/llvmpipe/lp_bld_depth.h |2 +
src/gallium/drivers/llvmpipe/lp_rast.c |8 +-
src/gallium/drivers/llvmpipe/lp_scene.c |2 -
src/gallium/drivers/llvmpipe/lp_scene.h |4 -
src/gallium/drivers/llvmpipe/lp_state_fs.c | 109 +--
src/gallium/drivers/llvmpipe/lp_state_fs.h |1 +
src/gallium/drivers/llvmpipe/lp_texture.c | 24 --
src/gallium/drivers/llvmpipe/lp_texture.h | 21 ++
9 files changed, 146 insertions(+), 44 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_bld_depth.c
b/src/gallium/drivers/llvmpipe/lp_bld_depth.c
index df6a6c4..a8bd15f 100644
--- a/src/gallium/drivers/llvmpipe/lp_bld_depth.c
+++ b/src/gallium/drivers/llvmpipe/lp_bld_depth.c
@@ -525,6 +525,7 @@ lp_build_occlusion_count(struct gallivm_state *gallivm,
*
* \param type the data type of the fragment depth/stencil values
* \param format_desc description of the depth/stencil surface
+ * \param is_1d whether this resource has only one dimension
* \param loop_counter the current loop iteration
* \param depth_ptr pointer to the depth/stencil values of this 4x4 block
* \param depth_stride stride of the depth/stencil buffer
@@ -535,6 +536,7 @@ void
lp_build_depth_stencil_load_swizzled(struct gallivm_state *gallivm,
struct lp_type z_src_type,
const struct util_format_description
*format_desc,
+ boolean is_1d,
LLVMValueRef depth_ptr,
LLVMValueRef depth_stride,
LLVMValueRef *z_fb,
@@ -592,9 +594,14 @@ lp_build_depth_stencil_load_swizzled(struct gallivm_state
*gallivm,
zs_dst_ptr = LLVMBuildGEP(builder, depth_ptr, depth_offset1, 1, );
zs_dst_ptr = LLVMBuildBitCast(builder, zs_dst_ptr, load_ptr_type, );
zs_dst1 = LLVMBuildLoad(builder, zs_dst_ptr, );
- zs_dst_ptr = LLVMBuildGEP(builder, depth_ptr, depth_offset2, 1, );
- zs_dst_ptr = LLVMBuildBitCast(builder, zs_dst_ptr, load_ptr_type, );
- zs_dst2 = LLVMBuildLoad(builder, zs_dst_ptr, );
+ if (is_1d) {
+ zs_dst2 = lp_build_undef(gallivm, zs_load_type);
+ }
+ else {
+ zs_dst_ptr = LLVMBuildGEP(builder, depth_ptr, depth_offset2, 1, );
+ zs_dst_ptr = LLVMBuildBitCast(builder, zs_dst_ptr, load_ptr_type, );
+ zs_dst2 = LLVMBuildLoad(builder, zs_dst_ptr, );
+ }
*z_fb = LLVMBuildShuffleVector(builder, zs_dst1, zs_dst2,
LLVMConstVector(shuffles, zs_type.length),
);
@@ -648,6 +655,7 @@ lp_build_depth_stencil_load_swizzled(struct gallivm_state
*gallivm,
*
* \param type the data type of the fragment depth/stencil values
* \param format_desc description of the depth/stencil surface
+ * \param is_1d whether this resource has only one dimension
* \param mask the alive/dead pixel mask for the quad (vector)
* \param z_fb z values read from fb (with padding)
* \param s_fb s values read from fb (with padding)
@@ -661,6 +669,7 @@ void
lp_build_depth_stencil_write_swizzled(struct gallivm_state *gallivm,
struct lp_type z_src_type,
const struct util_format_description
*format_desc,
+ boolean is_1d,
struct lp_build_mask_context *mask,
LLVMValueRef z_fb,
LLVMValueRef s_fb,
@@ -791,7 +800,9 @@ lp_build_depth_stencil_write_swizzled(struct gallivm_state
*gallivm,
}
[Mesa-dev] [PATCH 2/2] Add test case for recently fixed loop-control underflow bug.
To trigger the bug, it suffices to have a line-continuation followed by a newline and then a non-line-continuation backslash. --- ...117-line-continuation-and-non-continuation-backslash.c | 12 ...continuation-and-non-continuation-backslash.c.expected | 13 + 2 files changed, 25 insertions(+) create mode 100644 src/glsl/glcpp/tests/117-line-continuation-and-non-continuation-backslash.c create mode 100644 src/glsl/glcpp/tests/117-line-continuation-and-non-continuation-backslash.c.expected diff --git a/src/glsl/glcpp/tests/117-line-continuation-and-non-continuation-backslash.c b/src/glsl/glcpp/tests/117-line-continuation-and-non-continuation-backslash.c new file mode 100644 index 000..6a6f282 --- /dev/null +++ b/src/glsl/glcpp/tests/117-line-continuation-and-non-continuation-backslash.c @@ -0,0 +1,12 @@ +/* This test case is the minimal case to replicate the bug reported here: + * + * https://bugs.freedesktop.org/show_bug.cgi?id=65112 + * + * To trigger the bug, there must be a line-continuation sequence + * (backslash newline), then an additional newline character, and + * finally another backslash that is not part of a line-continuation + * sequence. + */ +\ + +/* \ */ diff --git a/src/glsl/glcpp/tests/117-line-continuation-and-non-continuation-backslash.c.expected b/src/glsl/glcpp/tests/117-line-continuation-and-non-continuation-backslash.c.expected new file mode 100644 index 000..9b3eb67 --- /dev/null +++ b/src/glsl/glcpp/tests/117-line-continuation-and-non-continuation-backslash.c.expected @@ -0,0 +1,13 @@ + + + + + + + + + + + + + -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] glcpp: Fix post-decrement underflow in loop-control variable
This loop-control condition with a post-decrement operator would lead to
an underflow of collapsed_newlines. This in turn would cause a subsequent
execution of the loop to labor inordinately trying to return the loop-control
variable to a value of 0 again.
Fix this by dis-intertwining the test and the decrement.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65112
---
src/glsl/glcpp/pp.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/glsl/glcpp/pp.c b/src/glsl/glcpp/pp.c
index 789f7f9..7e1b6c6 100644
--- a/src/glsl/glcpp/pp.c
+++ b/src/glsl/glcpp/pp.c
@@ -97,8 +97,10 @@ remove_line_continuations(glcpp_parser_t *ctx, const char
*shader)
{
ralloc_strncat(clean, shader,
newline - shader + 1);
- while (collapsed_newlines--)
+ while (collapsed_newlines) {
ralloc_strcat(clean, \n);
+ collapsed_newlines--;
+ }
shader = newline + 1;
search_start = shader;
}
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Fix glColorPointer(GL_FIXED)
Chad Versace chad.vers...@linux.intel.com writes: When a gl_client_array is created with glColorPointer, gl_client_array::Normalized is true. This caused the translation from the gl_client_array's type to a BRW_SURFACEFORMAT to assertion fail. Fixes the spinning cube's color in Android 4.2's ApiDemos.apk, Graphics OpenGL ES. Fixes assertion failure in mesa-demos/src/egl/opengles1/tri_x11 on Haswell and Ivybridge: brw_draw_upload.c:287: get_surface_type: Assertion `0' failed. No Piglit regressions on Haswell. We seriously need a piglit test for this. I'm only very reluctangly offering a: Reviewed-by: Eric Anholt e...@anholt.net pgprbJm_nah0n.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 2/2] Add test case for recently fixed loop-control underflow bug.
On 06/03/2013 12:51 PM, Carl Worth wrote: To trigger the bug, it suffices to have a line-continuation followed by a newline and then a non-line-continuation backslash. --- ...117-line-continuation-and-non-continuation-backslash.c | 12 ...continuation-and-non-continuation-backslash.c.expected | 13 + 2 files changed, 25 insertions(+) create mode 100644 src/glsl/glcpp/tests/117-line-continuation-and-non-continuation-backslash.c create mode 100644 src/glsl/glcpp/tests/117-line-continuation-and-non-continuation-backslash.c.expected Both are: 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] Do we support front buffer rendering with EGL? Do we want to?
I don't think we should implement front buffer rendering for EGL unless someone presents a compelling use case. In my mind, front buffer rendering is only something used historically...it has all kinds of caveats about synchronization, doesn't fit well into a world with compositing, and virtually everyone wants double buffering anyway so they can present perfect frames. --Ken ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Fix glColorPointer(GL_FIXED)
On 06/03/2013 01:02 PM, Eric Anholt wrote: Chad Versace chad.vers...@linux.intel.com writes: When a gl_client_array is created with glColorPointer, gl_client_array::Normalized is true. This caused the translation from the gl_client_array's type to a BRW_SURFACEFORMAT to assertion fail. Fixes the spinning cube's color in Android 4.2's ApiDemos.apk, Graphics OpenGL ES. Fixes assertion failure in mesa-demos/src/egl/opengles1/tri_x11 on Haswell and Ivybridge: brw_draw_upload.c:287: get_surface_type: Assertion `0' failed. No Piglit regressions on Haswell. We seriously need a piglit test for this. I'm only very reluctangly offering a: Reviewed-by: Eric Anholt e...@anholt.net Piglit test is now coming soon. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/5] glsl/linker: Use correct array length when linking inter-stage uniforms and varyings.
Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
---
src/glsl/linker.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 982fe46..7395ed5 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -1147,7 +1147,7 @@ update_array_sizes(struct gl_shader_program *prog)
}
}
-if (size + 1 != var-type-fields.array-length) {
+if (size + 1 != var-type-length) {
/* If this is a built-in uniform (i.e., it's backed by some
* fixed-function state), adjust the number of state slots to
* match the new array size. The number of slots per array entry
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/5] glsl: Only call mark_whole_array_access for arrays.
Otherwise the max_array_access field of scalar variables is set to 0x.
This doesn't lead to any errors since that field isn't used for scalar
variables but leaving it at zero is probably better.
Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
---
src/glsl/ast_to_hir.cpp | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index e918ade..f14a5b1 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -656,6 +656,8 @@ validate_assignment(struct _mesa_glsl_parse_state *state,
static void
mark_whole_array_access(ir_rvalue *access)
{
+ assert(access-type-is_array());
+
ir_dereference_variable *deref = access-as_dereference_variable();
if (deref deref-var) {
@@ -763,8 +765,10 @@ do_assignment(exec_list *instructions, struct
_mesa_glsl_parse_state *state,
rhs-type-array_size());
d-type = var-type;
}
- mark_whole_array_access(rhs);
- mark_whole_array_access(lhs);
+ if (rhs-type-is_array()) {
+mark_whole_array_access(rhs);
+mark_whole_array_access(lhs);
+ }
}
/* Most callers of do_assignment (assign, add_assign, pre_inc/dec,
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/5] glsl: Return error_type instead of NULL if element_type() is called on non array type.
This matches the behavior of field_type() and other get_*_type() methods.
I looked through the calls to element_type() and didn't find a caller that
depends on the old behavior.
Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
---
src/glsl/glsl_types.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/glsl/glsl_types.h b/src/glsl/glsl_types.h
index 31e3dd2..362c970 100644
--- a/src/glsl/glsl_types.h
+++ b/src/glsl/glsl_types.h
@@ -213,12 +213,12 @@ struct glsl_type {
* Query the type of elements in an array
*
* \return
-* Pointer to the type of elements in the array for array types, or \c NULL
-* for non-array types.
+* Pointer to the type of elements in the array for array types, or
+* \c glsl_type::error_type for non-array types.
*/
const glsl_type *element_type() const
{
- return is_array() ? fields.array : NULL;
+ return is_array() ? fields.array : error_type;
}
/**
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/5] glsl: Don't copy array of sampler parameters when inlining functions.
Remove The parameter from the list of parameters and replace the derefs in the
function body with the deref of the argument.
This is the way scalar sampler variables are handled already.
Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
---
src/glsl/opt_function_inlining.cpp | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/glsl/opt_function_inlining.cpp
b/src/glsl/opt_function_inlining.cpp
index 0733d51..25a8ff8 100644
--- a/src/glsl/opt_function_inlining.cpp
+++ b/src/glsl/opt_function_inlining.cpp
@@ -123,7 +123,7 @@ ir_call::generate_inline(ir_instruction *next_ir)
ir_rvalue *param = (ir_rvalue *) param_iter.get();
/* Generate a new variable for the parameter. */
- if (sig_param-type-base_type == GLSL_TYPE_SAMPLER) {
+ if (sig_param-type-get_scalar_type()-is_sampler()) {
/* For samplers, we want the inlined sampler references
* referencing the passed in sampler variable, since that
* will have the location information, which an assignment of
@@ -178,7 +178,7 @@ ir_call::generate_inline(ir_instruction *next_ir)
ir_instruction *const param = (ir_instruction *) param_iter.get();
ir_variable *sig_param = (ir_variable *) sig_param_iter.get();
- if (sig_param-type-base_type == GLSL_TYPE_SAMPLER) {
+ if (sig_param-type-get_scalar_type()-is_sampler()) {
ir_dereference *deref = param-as_dereference();
assert(deref);
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/5] glsl: Update array access tracker of function parameters.
Uniform arrays are subject to beeing shrunk if higher members were not accessed.
Update the max_array_access flag so array members that were only accessed in
the function are not optimized away.
This fixes Piglit test
spec/glsl-1.10/execution/samplers/in-parameter-array.shader_test.
Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
---
src/glsl/ast_function.cpp | 12
1 file changed, 12 insertions(+)
diff --git a/src/glsl/ast_function.cpp b/src/glsl/ast_function.cpp
index 00e0c05..9378894 100644
--- a/src/glsl/ast_function.cpp
+++ b/src/glsl/ast_function.cpp
@@ -322,6 +322,18 @@ generate_call(exec_list *instructions,
ir_function_signature *sig,
assert (!Illegal formal parameter mode);
break;
}
+ } else if (formal-type-is_array()) {
+/* Update the max_array_access field for array parameters.
+ * If the max_array_access of the formal parameter is zero, chances
+ * are we haven't parsed the function yet. Just set the array access
+ * to the whole array in that case.
+ */
+const unsigned max_array_access = (formal-max_array_access != 0)
+ ? formal-max_array_access : (formal-type-array_size() - 1);
+ir_variable *var = actual-whole_variable_referenced();
+if (var)
+ var-max_array_access =
+ MAX2(var-max_array_access, max_array_access);
}
actual_iter.next();
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] llvmpipe: reduce alignment requirement for 1d resources from 4x4 to 4x1
Jose, I'm actually seeing sort-of-a failure with wgf11rendertargets, but only with vector size 128. After much head scratching, I can guess what might be happening but not sure. What happens it hat wgf11rendertargest terminates (getting the dreaded windows app crash notice, however it does not trigger gdb but even if it would I'm not sure I'd see anything as I don't think it happens somewhere in our code). I do see Invalid parameter passed to C runtime function though in the console. Seems to happen with r10g10b10a2 format only (or maybe more such oddities but that's the first it crashes). It is actually fixable by using lp_build_zero instead of lp_build_undef for the undefined fs outputs in the blend function. This however doesn't make much sense to me, I see no way that those undef values actually can get used (not for this format), that is llvm should have completely dropped them anyway. Roland Am 03.06.2013 22:00, schrieb srol...@vmware.com: From: Roland Scheidegger srol...@vmware.com For rendering to buffers, we cannot have any y alignment. So make sure that tile clear commands only clear up to the fb width/height, not more (do this for all resources actually as clearing more seems pointless for other resources too). For the jit fs function, skip execution of the lower half of the fragment shader for the 4x4 stamp completely, for depth/stencil only load/store the values from the first row (replace other row with undef). For the blend function, also only load half the values from fs output, replace the rest with undefs so that everything still operates on the full 4x4 block to keep code the same between 4x1 and 4x4 (except for load/store of course which also needs to skip (store) or replace these values with undefs (load))., at the cost of slightly less optimal code being produced in some cases. Also reduce 1d and 1d array alignment too, because they can be handled the same as buffers so don't need to waste memory. v2: don't try to run special blend code for 4x1, (very) slightly less complexity if we just use the same code as for 4x4 which may or may not make it easier to optimize in the future (as we care a lot more about 4x4 performance than 1d) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel: Fix copying of separate stencil data in glCopyTexSubImage().
Jordan Justen jljus...@gmail.com writes:
On Thu, May 30, 2013 at 3:47 PM, Eric Anholt e...@anholt.net wrote:
We were copying the source stencil data onto the destination depth data.
Fixes piglit copyteximage other than 1D_ARRAY.
---
src/mesa/drivers/dri/i965/brw_blorp_blit.cpp | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
index c3ef054..67c40a7 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
@@ -375,10 +375,16 @@ brw_blorp_copytexsubimage(struct intel_context *intel,
if (_mesa_get_format_bits(dst_image-TexFormat, GL_STENCIL_BITS) 0
src_rb != NULL) {
src_irb = intel_renderbuffer(src_rb);
- if (src_irb-mt != src_mt)
Was this previous 'if' a mistake? I see the brw_blorp_blit_miptrees
call was not indented previously, and it was separated by a line.
Good catch! It wasn't a mistake -- if one was to copy a real packed
depth/stencil to packed depth/stencil, you wouldn't want to copy it
twice. Bad indentation on my part in the previous code made me lose
track of what was going on.
+ src_mt = src_irb-mt;
+
+ if (src_mt-stencil_mt)
+ src_mt = src_mt-stencil_mt;
else
src_mt = src_irb-mt;
?
The previous pattern is common, so I'll leave it.
pgp5GqbBSC232.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] r600g: fix mega_fetch_count
According to ISA docs, the range is 1..64, so effectively bytes_to_fetch-1. --- src/gallium/drivers/r600/r600_shader.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/r600/r600_shader.c b/src/gallium/drivers/r600/r600_shader.c index 81ed3ce..0444579 100644 --- a/src/gallium/drivers/r600/r600_shader.c +++ b/src/gallium/drivers/r600/r600_shader.c @@ -814,7 +814,7 @@ static int tgsi_fetch_rel_const(struct r600_shader_ctx *ctx, unsigned int cb_idx vtx.buffer_id = cb_idx; vtx.fetch_type = 2; /* VTX_FETCH_NO_INDEX_OFFSET */ vtx.src_gpr = ar_reg; - vtx.mega_fetch_count = 16; + vtx.mega_fetch_count = 15; vtx.dst_gpr = dst_reg; vtx.dst_sel_x = 0; /* SEL_X */ vtx.dst_sel_y = 1; /* SEL_Y */ @@ -3695,7 +3695,7 @@ static int do_vtx_fetch_inst(struct r600_shader_ctx *ctx, boolean src_requires_l vtx.buffer_id = id + R600_MAX_CONST_BUFFERS; vtx.fetch_type = 2; /* VTX_FETCH_NO_INDEX_OFFSET */ vtx.src_gpr = src_gpr; - vtx.mega_fetch_count = 16; + vtx.mega_fetch_count = 15; vtx.dst_gpr = ctx-file_offset[inst-Dst[0].Register.File] + inst-Dst[0].Register.Index; vtx.dst_sel_x = (inst-Dst[0].Register.WriteMask 1) ? 0 : 7; /* SEL_X */ vtx.dst_sel_y = (inst-Dst[0].Register.WriteMask 2) ? 1 : 7; /* SEL_Y */ -- 1.8.1.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
