[Mesa-dev] (no subject)
___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] (no subject)
___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] (no subject)
Hi! Could you please review changes? And could you also merge changes if it is ok. First patch is already reviewed by Bruce Cherniak and does not have any changes. Second patch contains updates for docs/features.txt for status bptc support. [PATCH v2 1/2] gallium/swr: Enable support bptc format. [PATCH v2 2/2] docs/features: mark GL_ARB_texture_compression_bptc as done ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] (no subject)
I had some discussions with Timothy Arceri earlier in the week about some old r100 patches that I had written. That led me to re-discover this series that enables NV_fog_distance on platforms that have vertex shader hardware. Tests will be out on the piglit list momentarily. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] (no subject)
V6 address Samuel's comments on v5 (including the ones I missed in v4 whoops). I also added some missing error checks for buffer storage and made a few other tidy-up that I noticed. There is now so a very basic piglit api error test [1] which depends on a gl.xml update which is stuck in moderation. [1] https://patchwork.freedesktop.org/patch/170263/ Series available at: https://github.com/tarceri/Mesa.git (memobj4) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] (no subject)
Hi; Take a look at Piglit test "ext_image_dma_buf_import-sample_yuv", (https://cgit.freedesktop.org/piglit). Test creates EGLImage from dma buf, binds to a texture and then samples this in a shader with samplerExternalOES type from GL_OES_EGL_image_external extension. On 05/09/2017 01:57 AM, Volker Vogelhuber wrote: I'm currently trying to render a V4L2 image with OpenGL on an Intel Apollo Lake using Linux 4.10 and Mesa 13. Supprisingly I noticed that importing a DMABUF with format DRM_FORMAT_YUYV into OpenGL using eglCreateImage/glEGLImageTargetTexture2DOES worked out of the box. But I noticed that there seem to be a split into two textures when importing the buffer. At least the nplanes variable in the __DRIimage's planar_format is set to 2 and in the intel_screen.c there is a comment for __DRI_IMAGE_FOURCC_YUYV: "For YUYV buffers, we set up two overlapping DRI images and treat them as planar buffers in the compositors." So far so good, but how do I access the second texture in the GLSL shader. I only created one texture object before calling glEGLImageTargetTexture2DOES with the EGLImage I got from eglCreateImage. And using the GLSL function texture( source, texCoord ) on this texture samples only the Y and U channel, what seems obvious as the first plane's texture is created as GL_RG texture. Can anyone explain to me, how one accesses the second plane. And if there is an example somewhere how the two planes have to be sampled to convert the values back to RGB, it would be nice if someone can send a link to such an example. Thanks ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] (no subject)
I'm currently trying to render a V4L2 image with OpenGL on an Intel Apollo Lake using Linux 4.10 and Mesa 13. Supprisingly I noticed that importing a DMABUF with format DRM_FORMAT_YUYV into OpenGL using eglCreateImage/glEGLImageTargetTexture2DOES worked out of the box. But I noticed that there seem to be a split into two textures when importing the buffer. At least the nplanes variable in the __DRIimage's planar_format is set to 2 and in the intel_screen.c there is a comment for __DRI_IMAGE_FOURCC_YUYV: "For YUYV buffers, we set up two overlapping DRI images and treat them as planar buffers in the compositors." So far so good, but how do I access the second texture in the GLSL shader. I only created one texture object before calling glEGLImageTargetTexture2DOES with the EGLImage I got from eglCreateImage. And using the GLSL function texture( source, texCoord ) on this texture samples only the Y and U channel, what seems obvious as the first plane's texture is created as GL_RG texture. Can anyone explain to me, how one accesses the second plane. And if there is an example somewhere how the two planes have to be sampled to convert the values back to RGB, it would be nice if someone can send a link to such an example. Thanks ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] (no subject)
https://www.facebook.com/messages/13832670320 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] (no subject)
https://www.facebook.com/beatrix.beres.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] (no subject)
id=13832670320, lacika.pacus, viktorio.balogh. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] (no subject)
Thanks for the heads-up. I only found one other place where a similar leak occurs -- and in the case of xm_api.c, I figure that XMesaDestroyVisual() is an "client-facing" call, so in the interest of maintaining layering I've just made the appropriate free() call. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] (no subject)
On 9 March 2016 at 01:28, Dongwon Kim wrote: > This patch enables an EGL extension, EGL_KHR_reusable_sync. > This new extension basically provides a way for multiple APIs or > threads to be excuted synchronously via a "reusable sync" "executed" > primitive shared by those threads/API calls. > > This was implemented based on the specification at > > https://www.khronos.org/registry/egl/extensions/KHR/EGL_KHR_reusable_sync.txt > Fiww, I almost nuked the infrastructure for this extension yesterday. Guess I'll put that patch on hold. Out of curiosity how did you test the implementation ? We don't have any piglit tests for it - care to send a few :-) Thanks Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] (no subject)
Hi, This is the new amdgpu winsys and Mesa support for GCN version 3 (VI) chips. The winsys requires libdrm_amdgpu: http://cgit.freedesktop.org/~agd5f/drm/log/?h=amdgpu The 3D support should be on the same level as Sea Islands (CIK). There is also UVD and VCE support. LLVM 3.6 is required, though LLVM 3.7 is recommended for stability. We'll probably make LLVM 3.6.1 with all the fixes cherry-picked from LLVM 3.7. If some patches don't make it to the list because they are too big (e.g. the addrlib patch), you can also find them here: http://cgit.freedesktop.org/~mareko/mesa/log/?h=amdgpu Please review. Thanks, Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] (no subject)
With the removal of unused colormac.h macros 2ad8af1a0c319c83e4a8e00db3a9b9cb0ae029eb, several unused includes were eliminated. This patch set removes the remaining places where colormac.h is included but not used. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] (no subject)
Hi. When I watch netflix it crashes with this: err:d3d:wined3d_debug_callback 0x10972478: "GL_OUT_OF_MEMORY in glTexSubImage". err:d3d_surface:surface_upload_data > GL_OUT_OF_MEMORY (0x505) from glTexSubImage2D @ surface.c / 1559 err:d3d:wined3d_debug_callback 0x10972478: "GL_OUT_OF_MEMORY in glTexSubImage". err:d3d_surface:surface_upload_data > GL_OUT_OF_MEMORY (0x505) from glTexSubImage2D @ surface.c / 1559 err:d3d:wined3d_debug_callback 0x10972478: "GL_OUT_OF_MEMORY in glTexSubImage". err:d3d_surface:surface_upload_data > GL_OUT_OF_MEMORY (0x505) from glTexSubImage2D @ surface.c / 1559 err:d3d:wined3d_debug_callback 0x10972478: "GL_OUT_OF_MEMORY in glTexSubImage". err:d3d_surface:surface_upload_data > GL_OUT_OF_MEMORY (0x505) from glTexSubImage2D @ surface.c / 1559 wine: Unhandled page fault on write access to 0x at address 0x7d151a37 (thread 0023), starting debugger... Unhandled exception: page fault on write access to 0x in 32-bit code (0x7d146a37). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:7d146a37 ESP:015ee3f0 EBP:c000 EFLAGS:00210202( R- -- I - - - ) EAX: EBX:7d379000 ECX: EDX:0004 ESI:7bd1f588 EDI: Stack dump: 0x015ee3f0: 7bd0047c 0004 0004 7bd1f590 0x015ee400: 7bd1f594 0021 7d379000 0x015ee410: 7bd0047c 7bd0047c 7bd0047c 7d1675da 0x015ee420: 7bd0047c 7bd1f588 0004 0004 0x015ee430: 7bd1f590 7bd1f594 7d379000 0x015ee440: 7bd0047c 7bd0047c 7d379000 7d167606 Backtrace: =>0 0x7d146a37 in i965_dri.so (+0x337a37) (0xc000) 1 0x7d1675da in i965_dri.so (+0x3585d9) (0xc000) 2 0x7d167606 in i965_dri.so (+0x358605) (0xc000) 3 0x7d1b5226 in i965_dri.so (+0x3a6225) (0xc000) 4 0x7d16576c in i965_dri.so (+0x35676b) (0x7bd0047c) 5 0x7d1a1b91 in i965_dri.so (+0x392b90) (0x7bd2e218) 6 0x7d1a24a7 in i965_dri.so (+0x3934a6) (0x7bd2e218) 7 0x7d1533dc in i965_dri.so (+0x3443db) (0x0100) 8 0x7ce4c567 in i965_dri.so (+0x3d566) (0x0004) 9 0x7e069fe0 in wined3d (+0x39fdf) (0x015ee818) 10 0x7e066d16 in wined3d (+0x36d15) (0x015ee868) 11 0x7e06632b in wined3d (+0x3632a) (0x015ee888) 12 0x7e066eab in wined3d (+0x36eaa) (0x015ee8a8) I have Ubuntu 14.04, FF and Oibaf ppa installed. It was working fine about a week ago and FF wasn't updated since then. So I suspect it's mesa or Intel driver. What would be best way to debug this? Thanks! -- Martynov Nikolay. Email: mar.ko...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] (no subject)
On 08/21/2013 08:46 PM, Maxence Le Doré wrote: As ARB_seamless_cubemap_per_texture is word-to-word same as AMD_seamless_cubemap_per_texture and this last already implemented we can enable the ARB extension. This patch is a candidate for it : Since the extensions are identical, we should expose both strings from a single flag. This should be a one-line change to extensions.c. There are a few other extensions that behave this way (e.g., GL_NV_texture_rectangle). From eb2cf312a7c7ba70f22f8eb8d66aab8a1d78b6d9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Maxence=20Le=20Dor=C3=A9?= Date: Thu, 22 Aug 2013 05:38:15 +0200 Subject: [PATCH] enable ARB_seamless_cubemap_per_texture --- src/gallium/docs/source/resources.rst |3 ++- src/mesa/main/extensions.c |1 + src/mesa/main/mtypes.h |3 ++- src/mesa/main/samplerobj.c | 15 ++- src/mesa/main/texparam.c |5 - src/mesa/state_tracker/st_extensions.c |1 + 6 files changed, 20 insertions(+), 8 deletions(-) diff --git a/src/gallium/docs/source/resources.rst b/src/gallium/docs/source/resources.rst index 56a86d6..a7f45a3 100644 --- a/src/gallium/docs/source/resources.rst +++ b/src/gallium/docs/source/resources.rst @@ -174,7 +174,8 @@ resulting in filtering taking samples from multiple surfaces near to the edge. OpenGL: GL_TEXTURE_CUBE_MAP in GL 1.3 or EXT_texture_cube_map - PIPE_CAP_NPOT_TEXTURES is equivalent to GL 2.0 or GL_ARB_texture_non_power_of_two -- Seamless cube maps require GL 3.2 or GL_ARB_seamless_cube_map or GL_AMD_seamless_cubemap_per_texture +- Seamless cube maps require GL 3.2 or GL_ARB_seamless_cube_map or GL_ARB_seamless_cubemap_per_texture + or GL_AMD_seamless_cubemap_per_texture - Cube map arrays require GL 4.0 or GL_ARB_texture_cube_map_array D3D11: 2D array textures with the D3D11_RESOURCE_MISC_TEXTURECUBE flag diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c index 1a040ee..6b02b9b 100644 --- a/src/mesa/main/extensions.c +++ b/src/mesa/main/extensions.c @@ -120,6 +120,7 @@ static const struct extension extension_table[] = { { "GL_ARB_robustness", o(dummy_true), GL, 2010 }, { "GL_ARB_sampler_objects", o(dummy_true), GL, 2009 }, { "GL_ARB_seamless_cube_map", o(ARB_seamless_cube_map), GL, 2009 }, + { "GL_ARB_seamless_cubemap_per_texture", o(ARB_seamless_cubemap_per_texture),GL, 2013 }, { "GL_ARB_shader_bit_encoding", o(ARB_shader_bit_encoding), GL, 2010 }, { "GL_ARB_shader_objects", o(dummy_true), GL, 2002 }, { "GL_ARB_shader_stencil_export", o(ARB_shader_stencil_export), GL, 2009 }, diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h index 5f9b7f9..641e5a9 100644 --- a/src/mesa/main/mtypes.h +++ b/src/mesa/main/mtypes.h @@ -1142,7 +1142,7 @@ struct gl_sampler_object GLenum CompareMode; /**< GL_ARB_shadow */ GLenum CompareFunc; /**< GL_ARB_shadow */ GLenum sRGBDecode; /**< GL_DECODE_EXT or GL_SKIP_DECODE_EXT */ - GLboolean CubeMapSeamless; /**< GL_AMD_seamless_cubemap_per_texture */ + GLboolean CubeMapSeamless; /**< GL_{ARB,AMD}_seamless_cubemap_per_texture */ }; @@ -3056,6 +3056,7 @@ struct gl_extensions GLboolean ARB_occlusion_query2; GLboolean ARB_point_sprite; GLboolean ARB_seamless_cube_map; + GLboolean ARB_seamless_cubemap_per_texture; GLboolean ARB_shader_bit_encoding; GLboolean ARB_shader_stencil_export; GLboolean ARB_shader_texture_lod; diff --git a/src/mesa/main/samplerobj.c b/src/mesa/main/samplerobj.c index 3857eda..0182531 100644 --- a/src/mesa/main/samplerobj.c +++ b/src/mesa/main/samplerobj.c @@ -568,7 +568,8 @@ static GLuint set_sampler_cube_map_seamless(struct gl_context *ctx, struct gl_sampler_object *samp, GLboolean param) { - if (!ctx->Extensions.AMD_seamless_cubemap_per_texture) + if (!ctx->Extensions.AMD_seamless_cubemap_per_texture || + !ctx->Extensions.ARB_seamless_cubemap_per_texture) return INVALID_PNAME; if (samp->CubeMapSeamless == param) @@ -1176,7 +1177,8 @@ _mesa_GetSamplerParameteriv(GLuint sampler, GLenum pname, GLint *params) params[3] = FLOAT_TO_INT(sampObj->BorderColor.f[3]); break; case GL_TEXTURE_CUBE_MAP_SEAMLESS: - if (!ctx->Extensions.AMD_seamless_cubemap_per_texture) + if (!ctx->Extensions.AMD_seamless_cubemap_per_texture || + !ctx->Extensions.ARB_seamless_cubemap_per_texture) goto invalid_pname; *params = sampObj->CubeMapSeamless; break; @@ -1254,7 +1256,8 @@ _mesa_GetSamplerParameterfv(GLuint sampler, GLenum pname, GLfloat *params) params[3] = sampObj->
Re: [Mesa-dev] (no subject)
Your mail client line wrapped the patch, so it can't be applied. Please resend with git send-email. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] (no subject)
As ARB_seamless_cubemap_per_texture is word-to-word same as AMD_seamless_cubemap_per_texture and this last already implemented we can enable the ARB extension. This patch is a candidate for it : >From eb2cf312a7c7ba70f22f8eb8d66aab8a1d78b6d9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Maxence=20Le=20Dor=C3=A9?= Date: Thu, 22 Aug 2013 05:38:15 +0200 Subject: [PATCH] enable ARB_seamless_cubemap_per_texture --- src/gallium/docs/source/resources.rst |3 ++- src/mesa/main/extensions.c |1 + src/mesa/main/mtypes.h |3 ++- src/mesa/main/samplerobj.c | 15 ++- src/mesa/main/texparam.c |5 - src/mesa/state_tracker/st_extensions.c |1 + 6 files changed, 20 insertions(+), 8 deletions(-) diff --git a/src/gallium/docs/source/resources.rst b/src/gallium/docs/source/resources.rst index 56a86d6..a7f45a3 100644 --- a/src/gallium/docs/source/resources.rst +++ b/src/gallium/docs/source/resources.rst @@ -174,7 +174,8 @@ resulting in filtering taking samples from multiple surfaces near to the edge. OpenGL: GL_TEXTURE_CUBE_MAP in GL 1.3 or EXT_texture_cube_map - PIPE_CAP_NPOT_TEXTURES is equivalent to GL 2.0 or GL_ARB_texture_non_power_of_two -- Seamless cube maps require GL 3.2 or GL_ARB_seamless_cube_map or GL_AMD_seamless_cubemap_per_texture +- Seamless cube maps require GL 3.2 or GL_ARB_seamless_cube_map or GL_ARB_seamless_cubemap_per_texture + or GL_AMD_seamless_cubemap_per_texture - Cube map arrays require GL 4.0 or GL_ARB_texture_cube_map_array D3D11: 2D array textures with the D3D11_RESOURCE_MISC_TEXTURECUBE flag diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c index 1a040ee..6b02b9b 100644 --- a/src/mesa/main/extensions.c +++ b/src/mesa/main/extensions.c @@ -120,6 +120,7 @@ static const struct extension extension_table[] = { { "GL_ARB_robustness", o(dummy_true), GL, 2010 }, { "GL_ARB_sampler_objects", o(dummy_true), GL, 2009 }, { "GL_ARB_seamless_cube_map", o(ARB_seamless_cube_map), GL, 2009 }, + { "GL_ARB_seamless_cubemap_per_texture", o(ARB_seamless_cubemap_per_texture),GL, 2013 }, { "GL_ARB_shader_bit_encoding", o(ARB_shader_bit_encoding), GL, 2010 }, { "GL_ARB_shader_objects", o(dummy_true), GL, 2002 }, { "GL_ARB_shader_stencil_export", o(ARB_shader_stencil_export), GL, 2009 }, diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h index 5f9b7f9..641e5a9 100644 --- a/src/mesa/main/mtypes.h +++ b/src/mesa/main/mtypes.h @@ -1142,7 +1142,7 @@ struct gl_sampler_object GLenum CompareMode; /**< GL_ARB_shadow */ GLenum CompareFunc; /**< GL_ARB_shadow */ GLenum sRGBDecode; /**< GL_DECODE_EXT or GL_SKIP_DECODE_EXT */ - GLboolean CubeMapSeamless; /**< GL_AMD_seamless_cubemap_per_texture */ + GLboolean CubeMapSeamless; /**< GL_{ARB,AMD}_seamless_cubemap_per_texture */ }; @@ -3056,6 +3056,7 @@ struct gl_extensions GLboolean ARB_occlusion_query2; GLboolean ARB_point_sprite; GLboolean ARB_seamless_cube_map; + GLboolean ARB_seamless_cubemap_per_texture; GLboolean ARB_shader_bit_encoding; GLboolean ARB_shader_stencil_export; GLboolean ARB_shader_texture_lod; diff --git a/src/mesa/main/samplerobj.c b/src/mesa/main/samplerobj.c index 3857eda..0182531 100644 --- a/src/mesa/main/samplerobj.c +++ b/src/mesa/main/samplerobj.c @@ -568,7 +568,8 @@ static GLuint set_sampler_cube_map_seamless(struct gl_context *ctx, struct gl_sampler_object *samp, GLboolean param) { - if (!ctx->Extensions.AMD_seamless_cubemap_per_texture) + if (!ctx->Extensions.AMD_seamless_cubemap_per_texture || + !ctx->Extensions.ARB_seamless_cubemap_per_texture) return INVALID_PNAME; if (samp->CubeMapSeamless == param) @@ -1176,7 +1177,8 @@ _mesa_GetSamplerParameteriv(GLuint sampler, GLenum pname, GLint *params) params[3] = FLOAT_TO_INT(sampObj->BorderColor.f[3]); break; case GL_TEXTURE_CUBE_MAP_SEAMLESS: - if (!ctx->Extensions.AMD_seamless_cubemap_per_texture) + if (!ctx->Extensions.AMD_seamless_cubemap_per_texture || + !ctx->Extensions.ARB_seamless_cubemap_per_texture) goto invalid_pname; *params = sampObj->CubeMapSeamless; break; @@ -1254,7 +1256,8 @@ _mesa_GetSamplerParameterfv(GLuint sampler, GLenum pname, GLfloat *params) params[3] = sampObj->BorderColor.f[3]; break; case GL_TEXTURE_CUBE_MAP_SEAMLESS: - if (!ctx->Extensions.AMD_seamless_cubemap_per_texture) + if (!ctx->Extensions.AMD_seamless_cubemap_per_texture || + !ctx->Extensions.ARB_seamless_cubemap_per_texture) goto invalid_pname; *params = (GLfloat) sampObj
Re: [Mesa-dev] (no subject)
On Sat, Apr 13, 2013 at 11:22:51AM -0500, Aaron Watry wrote: > Implements the min() OpenCL built-in in 2 stages. > 1) Implement min() where the two argument types match > 2) Make changes to support min(vec,scalar) > For the series: Reviewed-by: Tom Stellard > ___ > 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] (no subject)
Implements the min() OpenCL built-in in 2 stages. 1) Implement min() where the two argument types match 2) Make changes to support min(vec,scalar) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] (no subject)
This mini-series fixes some bugs I discovered with INTEL_DEBUG=shader_time. Patch 1 is critical: without it, enabling shader time caused GPU hangs on Haswell because we were sending the wrong message to the wrong shared function. Patches 2 and 3 are less clear cut. From my reading of the BSpec/PRM's Data Port / Messages / Atomic Operations sections, it's illegal to use SURFTYPE_BUFFER and R32G32B32A32_FLOAT. It looks like untyped atomic operations require the surface format to be RAW. Oddly, shader time works fine on both Ivybridge and Haswell without these two patches. However, running them in the simulator causes assertion failures, which doesn't instill confidence. It also looks like atomic operations only use the first component, so using a four component buffer was wasting a lot of space. As part of converting it to RAW, I also convert it to a single component buffer. I believe we also computed the size incorrectly. I'd really appreciate careful review and a quick sanity test. It appears to produce similar numbers before and after my patches, suggesting they work, but double checking would be great. The cut and paste of create constant surface is kind of rubbish, too. The alternative of adding format and stride to create_constant_surface might be preferable...not sure. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] (no subject)
On Tue, Aug 14, 2012 at 8:45 PM, Maxim Levitsky wrote: > > Hi, I have this backported patch here for more that an year, and forgot all > about it. > It just makes gallium drivers use driver name instread of 'dri' in driconf > parser, thus making it compatable with 'driconf' GUI. Sounds reasonable. Can you post it? Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] (no subject)
Hi, I have this backported patch here for more that an year, and forgot all about it. It just makes gallium drivers use driver name instread of 'dri' in driconf parser, thus making it compatable with 'driconf' GUI. Can you merge it? Best regards, Maxim Levitsky ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] (no subject)
Hi, This is the second verion of the clipping/interpolation patches. Main differences: - I tried to take all of Paul's remarks into account - I exploded the first patch in 4 independant ones - I've added a patch to ensure that integers pass through unscathed Patch 4/9 is (slightly) controversial. There may be better ways to do it, or at least more general ones. But it's simple, it works, and it allows to validate the other 8. It's an easy one to revert if we build an alternative. Best, OG. [PATCH 1/9] intel gen4-5: fix the vue view in the fs. [PATCH 2/9] intel gen4-5: simplify the bfc copy in the sf. [PATCH 3/9] intel gen4-5: fix GL_VERTEX_PROGRAM_TWO_SIDE selection. [PATCH 4/9] intel gen4-5: Fix backface/frontface selection when one [PATCH 5/9] intel gen4-5: Compute the interpolation status for every [PATCH 6/9] intel gen4-5: Correctly setup the parameters in the sf. [PATCH 7/9] intel gen4-5: Correctly handle flat vs. non-flat in the [PATCH 8/9] intel gen4-5: Make noperspective clipping work. [PATCH 9/9] intel gen4-5: Don't touch flatshaded values when ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] (no subject)
This patch does pack some simple varyings in shader object. It tested it against mandelbrot mesa-demos and nexuiz-glx (where there are varying packing opportunities) and I didn't notice any visual change. I didn't see any noticeable performance improvement either, but I did not benchmark this patch accuratly. I guess however that it depends on the hardware and the complexity and the "well writteness" of the executed shaders. It should on theory not decrease performance if swizzle is cost free on hardware. I put this pass in assign_varying_locations but there might be better location for it to be executed. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] (no subject)
On 08/07/2011 01:49 PM, Vincent Lejeune wrote: This new patch fix an issue with some shader (mandelbrot demo) Are you referring to your var packing patch? Is the mandelbrot demo not working with a particular driver? Which one? -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] (no subject)
This new patch fix an issue with some shader (mandelbrot demo) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] (no subject)
2010/6/11 Kristian Høgsberg : > 2010/6/10 Chia-I Wu : >> Hi Kristian, >> >> 2010/6/4 Kristian Høgsberg : >>> Here's an update on the EGL/DRM integration extensions and patches. >>> I've updated the patches with the feedback from the discussions on the >>> list to the extent that I think is feasible. I think we're pretty >>> close to consensus on how to do this, but let me know what you think. >>> There's also a new extension in the series, the EGL_INTEL_no_surface >>> extension, which lets us make a context current without a surface. >> The summary looks fine to me. Please go ahead with your changes. I have one >> comment below regarding the first patch. It is fine to ignore it unless you >> feel convinced. > > Cool, thanks. > >>> I updated the eglkms.c test case, and it now compiles and runs against >>> this patch series: >>> >>> http://cgit.freedesktop.org/~krh/mesa-demos/tree/src/egl/opengl/eglkms.c >>> >>> [PATCH 1/6] egl: Add MESA_typed_display infrastructure >>> This is the updated version of the alternative eglGetDisplay >>> extension. I've incorporated the feedback from Chia-I regarding >>> naming of the entry point and tokens, and Jakobs suggestion that we >>> add tokens for the existing platforms (Win32 and X11). >>> It's still a new entrypoint, not separate .so's as Chia-I suggested. >>> I don't think it's a terrible idea to have separate .so's with >>> different names, but I still like this better, and with separate >>> .so's we'll have to compile libEGL several times to output the >>> different libraries, which is awkward and a pain for distributions. >>> I dropped the XCB display for now. >> As the extension cannot be tested, it looks like a hack to me, only with a >> spec. Having separating libraries allows the issue to be resolved in the >> build >> systems (of apps), instead of in the code. Say, wayland is adopted by a >> mobile >> device where there is DRM but no X server. It is natural that eglGetDisplay >> on >> that platform takes a DRM fd, and the extension becomes redundant. If >> wayland >> linked to libEGL-drm.so, whose eglGetDisplay expects a DRM fd, on a common >> desktop, building wayland to the platform would require only a change to the >> build rules. > > The typed_display isn't regular extension, you're right. It's > something between an extension and an implementation specific > entrypoint (or as hack as you say :). But I was actually sold on your > libEGL-drm.so idea and went as far as implementing it: > > http://cgit.freedesktop.org/~krh/mesa/log/?h=egl-kms-4 > > This branch make the src/egl/main makefiles build two libraries: > libEGL-x11.so and libEGL-drm.so, it generates egl-drm.pc and > egl-x11.pc and symlinks libEGL.so to libEGL-x11.so and egl.pc to > egl-x11.pc. I was pretty happy with this until I tried using > cairo-gl. cairo-gl uses EGL to be able to save the users current > context before it draws and then restore it when it's done. It > doesn't use any window specific entry points. However, with the > libEGL-drm.so approach, we would have to make cairo-gl choose to link > to either libEGL-drm.so or libEGL-x11.so. And then you would either > have to have a libcairo-drm.so and a libcairo-x11.so, or install cairo > in different prefixes. And while we may some day have a system with > only wayland and no X, wayland and X will have to coexist forever on > other systems (running rootless X applications on a wayland server, > for example) > > Now, the typed display has a few problems of its own. For > applications that don't use X, eglplatform.h still pulls in X headers. > I worked around this in this commit: > > http://cgit.freedesktop.org/~krh/mesa/commit/?h=egl-kms-3&id=55a59223be7cbb935ebbeee08fe25117210181a4 > > but that's not good either, since we could have apps depending on > eglplatform.h pulling the X headers. And it relies on Display being a > typedef of struct _XDisplay. We could make this conditional on a > #define, such as > > #ifndef _MESA_EGL_NO_X11_HEADERS > /* X11 (tentative) */ > #include > #include > > typedef Display *EGLNativeDisplayType; > typedef Pixmap EGLNativePixmapType; > typedef Window EGLNativeWindowType; > #else > struct _XDisplay; > typedef void *EGLNativeDisplayType; > typedef khronos_uint32_t EGLNativePixmapType; > typedef khronos_uint32_t EGLNativeWindowType; > #endif > > and it's probably better to just use a void * instead of the struct > _XDisplay *, which is an implementation detail of Xlib (but a very > public one, of course). This has the benefit that one can add > -D_MESA_EGL_NO_X11_HEADERS=1 to the compiler flags in the build system > and avoid changing existing code. > > Finally, I'm thinking that instead of the generic typed_display > mechanism, we could just go with a simple, typesafe: > > EGLDisplay eglGetDRMDisplayMESA(int fd); > > and declare that in eglplatform.h. Using eglGetProcAddress() to look > it up is a bit silly if your application only runs on drm.
Re: [Mesa-dev] (no subject)
2010/6/10 Chia-I Wu : > Hi Kristian, > > 2010/6/4 Kristian Høgsberg : >> Here's an update on the EGL/DRM integration extensions and patches. >> I've updated the patches with the feedback from the discussions on the >> list to the extent that I think is feasible. I think we're pretty >> close to consensus on how to do this, but let me know what you think. >> There's also a new extension in the series, the EGL_INTEL_no_surface >> extension, which lets us make a context current without a surface. > The summary looks fine to me. Please go ahead with your changes. I have one > comment below regarding the first patch. It is fine to ignore it unless you > feel convinced. Cool, thanks. >> I updated the eglkms.c test case, and it now compiles and runs against >> this patch series: >> >> http://cgit.freedesktop.org/~krh/mesa-demos/tree/src/egl/opengl/eglkms.c >> >> [PATCH 1/6] egl: Add MESA_typed_display infrastructure >> This is the updated version of the alternative eglGetDisplay >> extension. I've incorporated the feedback from Chia-I regarding >> naming of the entry point and tokens, and Jakobs suggestion that we >> add tokens for the existing platforms (Win32 and X11). >> It's still a new entrypoint, not separate .so's as Chia-I suggested. >> I don't think it's a terrible idea to have separate .so's with >> different names, but I still like this better, and with separate >> .so's we'll have to compile libEGL several times to output the >> different libraries, which is awkward and a pain for distributions. >> I dropped the XCB display for now. > As the extension cannot be tested, it looks like a hack to me, only with a > spec. Having separating libraries allows the issue to be resolved in the > build > systems (of apps), instead of in the code. Say, wayland is adopted by a > mobile > device where there is DRM but no X server. It is natural that eglGetDisplay > on > that platform takes a DRM fd, and the extension becomes redundant. If wayland > linked to libEGL-drm.so, whose eglGetDisplay expects a DRM fd, on a common > desktop, building wayland to the platform would require only a change to the > build rules. The typed_display isn't regular extension, you're right. It's something between an extension and an implementation specific entrypoint (or as hack as you say :). But I was actually sold on your libEGL-drm.so idea and went as far as implementing it: http://cgit.freedesktop.org/~krh/mesa/log/?h=egl-kms-4 This branch make the src/egl/main makefiles build two libraries: libEGL-x11.so and libEGL-drm.so, it generates egl-drm.pc and egl-x11.pc and symlinks libEGL.so to libEGL-x11.so and egl.pc to egl-x11.pc. I was pretty happy with this until I tried using cairo-gl. cairo-gl uses EGL to be able to save the users current context before it draws and then restore it when it's done. It doesn't use any window specific entry points. However, with the libEGL-drm.so approach, we would have to make cairo-gl choose to link to either libEGL-drm.so or libEGL-x11.so. And then you would either have to have a libcairo-drm.so and a libcairo-x11.so, or install cairo in different prefixes. And while we may some day have a system with only wayland and no X, wayland and X will have to coexist forever on other systems (running rootless X applications on a wayland server, for example) Now, the typed display has a few problems of its own. For applications that don't use X, eglplatform.h still pulls in X headers. I worked around this in this commit: http://cgit.freedesktop.org/~krh/mesa/commit/?h=egl-kms-3&id=55a59223be7cbb935ebbeee08fe25117210181a4 but that's not good either, since we could have apps depending on eglplatform.h pulling the X headers. And it relies on Display being a typedef of struct _XDisplay. We could make this conditional on a #define, such as #ifndef _MESA_EGL_NO_X11_HEADERS /* X11 (tentative) */ #include #include typedef Display *EGLNativeDisplayType; typedef Pixmap EGLNativePixmapType; typedef Window EGLNativeWindowType; #else struct _XDisplay; typedef void *EGLNativeDisplayType; typedef khronos_uint32_t EGLNativePixmapType; typedef khronos_uint32_t EGLNativeWindowType; #endif and it's probably better to just use a void * instead of the struct _XDisplay *, which is an implementation detail of Xlib (but a very public one, of course). This has the benefit that one can add -D_MESA_EGL_NO_X11_HEADERS=1 to the compiler flags in the build system and avoid changing existing code. Finally, I'm thinking that instead of the generic typed_display mechanism, we could just go with a simple, typesafe: EGLDisplay eglGetDRMDisplayMESA(int fd); and declare that in eglplatform.h. Using eglGetProcAddress() to look it up is a bit silly if your application only runs on drm. In that case, getting a linker error up front if you're using the wrong libEGL.so is preferrable. If you're writing an application that can run on both drm and X11, you can
Re: [Mesa-dev] (no subject)
Hi Kristian, 2010/6/4 Kristian Høgsberg : > Here's an update on the EGL/DRM integration extensions and patches. > I've updated the patches with the feedback from the discussions on the > list to the extent that I think is feasible. I think we're pretty > close to consensus on how to do this, but let me know what you think. > There's also a new extension in the series, the EGL_INTEL_no_surface > extension, which lets us make a context current without a surface. The summary looks fine to me. Please go ahead with your changes. I have one comment below regarding the first patch. It is fine to ignore it unless you feel convinced. > I updated the eglkms.c test case, and it now compiles and runs against > this patch series: > > http://cgit.freedesktop.org/~krh/mesa-demos/tree/src/egl/opengl/eglkms.c > > [PATCH 1/6] egl: Add MESA_typed_display infrastructure > This is the updated version of the alternative eglGetDisplay > extension. I've incorporated the feedback from Chia-I regarding > naming of the entry point and tokens, and Jakobs suggestion that we > add tokens for the existing platforms (Win32 and X11). > It's still a new entrypoint, not separate .so's as Chia-I suggested. > I don't think it's a terrible idea to have separate .so's with > different names, but I still like this better, and with separate > .so's we'll have to compile libEGL several times to output the > different libraries, which is awkward and a pain for distributions. > I dropped the XCB display for now. As the extension cannot be tested, it looks like a hack to me, only with a spec. Having separating libraries allows the issue to be resolved in the build systems (of apps), instead of in the code. Say, wayland is adopted by a mobile device where there is DRM but no X server. It is natural that eglGetDisplay on that platform takes a DRM fd, and the extension becomes redundant. If wayland linked to libEGL-drm.so, whose eglGetDisplay expects a DRM fd, on a common desktop, building wayland to the platform would require only a change to the build rules. > [PATCH 2/6] egl_dri2: Support EGL_DISPLAY_TYPE_DRM_MESA > > This one just adds support to egl_dri2, should be pretty harmless. > > [PATCH 3/6] egl: EGL_INTEL_no_surface extension > > The new extension mentioned above. It adds a new config attribute > to inidicate the APIs that support making a context current with > that config and no surfaces. Previous discussion on this have > stalled on the problem that not all client APIs have a meaningful > way to make a context current without surfaces. By specifying the > supported APIs in the config we solve this problem. See the spec in > the patch for details. > > [PATCH 4/6] egl: MESA_image_drm extension > > This is the extension to create drm images from nothing using > eglCreateDRMImageMESA, share them using eglShareDRMImageMesa, and > import them using the EGL_DRM_BUFFER_MESA target with > eglCreateImageKHR. Sharing an image is a separate entrypoint > because a drm buffer doesn't necesarily have a global name and > creating one is an extra step that we don't always want to incur. > [PATCH 5/6] egl_dri2: Add support for MESA_image_drm > > Nothing to see here, just the implementation. Some of the > attrib_list checking could be lifted to egl/main. > > [PATCH 6/6] intel: Add support for MESA_drm_image > > The intel dri driver side of things. > > Kristian > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > -- o...@lunarg.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] (no subject)
Hi, Here's an update on the EGL/DRM integration extensions and patches. I've updated the patches with the feedback from the discussions on the list to the extent that I think is feasible. I think we're pretty close to consensus on how to do this, but let me know what you think. There's also a new extension in the series, the EGL_INTEL_no_surface extension, which lets us make a context current without a surface. I updated the eglkms.c test case, and it now compiles and runs against this patch series: http://cgit.freedesktop.org/~krh/mesa-demos/tree/src/egl/opengl/eglkms.c [PATCH 1/6] egl: Add MESA_typed_display infrastructure This is the updated version of the alternative eglGetDisplay extension. I've incorporated the feedback from Chia-I regarding naming of the entry point and tokens, and Jakobs suggestion that we add tokens for the existing platforms (Win32 and X11). It's still a new entrypoint, not separate .so's as Chia-I suggested. I don't think it's a terrible idea to have separate .so's with different names, but I still like this better, and with separate .so's we'll have to compile libEGL several times to output the different libraries, which is awkward and a pain for distributions. I dropped the XCB display for now. [PATCH 2/6] egl_dri2: Support EGL_DISPLAY_TYPE_DRM_MESA This one just adds support to egl_dri2, should be pretty harmless. [PATCH 3/6] egl: EGL_INTEL_no_surface extension The new extension mentioned above. It adds a new config attribute to inidicate the APIs that support making a context current with that config and no surfaces. Previous discussion on this have stalled on the problem that not all client APIs have a meaningful way to make a context current without surfaces. By specifying the supported APIs in the config we solve this problem. See the spec in the patch for details. [PATCH 4/6] egl: MESA_image_drm extension This is the extension to create drm images from nothing using eglCreateDRMImageMESA, share them using eglShareDRMImageMesa, and import them using the EGL_DRM_BUFFER_MESA target with eglCreateImageKHR. Sharing an image is a separate entrypoint because a drm buffer doesn't necesarily have a global name and creating one is an extra step that we don't always want to incur. [PATCH 5/6] egl_dri2: Add support for MESA_image_drm Nothing to see here, just the implementation. Some of the attrib_list checking could be lifted to egl/main. [PATCH 6/6] intel: Add support for MESA_drm_image The intel dri driver side of things. Kristian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev