[Mesa-dev] (no subject)

[Tesdy Pounds]

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] (no subject)

[Tesdy Pounds]

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] (no subject)

[Denis Pauk]

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)

[Ian Romanick]

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)

[Timothy Arceri]

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)

[Tapani Pälli]

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)

[Volker Vogelhuber]

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)

[Andras Schwartz]

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)

[Andras Schwartz]

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)

[Andras Schwartz]

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] [PATCH] *** SUBJECT HERE ***

[Youry Metlitsky]

*** BLURB HERE ***

Youry Metlitsky (1):
  mesa: Build EGL without X11 headers after interop patchset

 include/GL/mesa_glinterop.h | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

-- 
2.8.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] (no subject)

[John Sheu]

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)

[Emil Velikov]

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)

[Marek Olšák]

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)

[Mark Janes]

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)

[Nikolay Martynov]

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

[Mesa-dev] (no subject)

[Maxence Le Doré]

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?= maxence.led...@gmail.com
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) 

Re: [Mesa-dev] (no subject)

[Matt Turner]

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

Re: [Mesa-dev] (no subject)

[Ian Romanick]

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?= maxence.led...@gmail.com
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] = 

Re: [Mesa-dev] (no subject)

[Tom Stellard]

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 thomas.stell...@amd.com

 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] (no subject)

[Aaron Watry]

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)

[Kenneth Graunke]

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)

[Alex Deucher]

On Tue, Aug 14, 2012 at 8:45 PM, Maxim Levitsky maximlevit...@gmail.com 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)

[Maxim Levitsky]

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)

[Olivier Galibert]

  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

Re: [Mesa-dev] (no subject)

[Brian Paul]

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)

[Vincent Lejeune]

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)

[Kristian Høgsberg]

2010/6/10 Chia-I Wu olva...@gmail.com:
 Hi Kristian,

 2010/6/4 Kristian Høgsberg k...@bitplanet.net:
 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-3id=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 X11/Xlib.h
  #include X11/Xutil.h

  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 still 

Re: [Mesa-dev] (no subject)

[Chia-I Wu]

2010/6/11 Kristian Høgsberg k...@bitplanet.net:
 2010/6/10 Chia-I Wu olva...@gmail.com:
 Hi Kristian,

 2010/6/4 Kristian Høgsberg k...@bitplanet.net:
 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-3id=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 X11/Xlib.h
  #include X11/Xutil.h

  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 

Re: [Mesa-dev] (no subject)

[Chia-I Wu]

Hi Kristian,

2010/6/4 Kristian Høgsberg k...@bitplanet.net:
 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)

[Kristian Høgsberg]

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