[Mesa-dev] [PATCH] vl/dri3: fix warning about incompatible pointer type

[Nayan Deshmukh]

Signed-off-by: Nayan Deshmukh 
---
 src/gallium/auxiliary/vl/vl_winsys_dri3.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c 
b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
index 191a64b..2929928 100644
--- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
+++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
@@ -85,7 +85,7 @@ struct vl_dri3_screen
int64_t last_ust, ns_frame, last_msc, next_msc;
 
bool flushed;
-   bool is_different_gpu;
+   int is_different_gpu;
 };
 
 static void
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH 1/5] st/mesa: simplify some code in get_texture_format_swizzle()

[Edward O'Callaghan]

This series is,
Reviewed-by: Edward O'Callaghan 

On 10/01/2016 08:53 AM, Brian Paul wrote:
> There's no need to cast to st_texture_image.  Just use gl_texture_image.
> ---
>  src/mesa/state_tracker/st_atom_texture.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/src/mesa/state_tracker/st_atom_texture.c 
> b/src/mesa/state_tracker/st_atom_texture.c
> index efc8c90..113c0ed 100644
> --- a/src/mesa/state_tracker/st_atom_texture.c
> +++ b/src/mesa/state_tracker/st_atom_texture.c
> @@ -211,11 +211,11 @@ get_texture_format_swizzle(const struct st_context *st,
> */
>if (_mesa_is_gles3(st->ctx) &&
>util_format_is_depth_or_stencil(stObj->pt->format)) {
> - const struct st_texture_image *firstImage =
> -st_texture_image_const(_mesa_base_tex_image(>base));
> - if (firstImage->base.InternalFormat != GL_DEPTH_COMPONENT &&
> - firstImage->base.InternalFormat != GL_DEPTH_STENCIL &&
> - firstImage->base.InternalFormat != GL_STENCIL_INDEX)
> + const struct gl_texture_image *firstImage =
> +_mesa_base_tex_image(>base);
> + if (firstImage->InternalFormat != GL_DEPTH_COMPONENT &&
> + firstImage->InternalFormat != GL_DEPTH_STENCIL &&
> + firstImage->InternalFormat != GL_STENCIL_INDEX)
>  depth_mode = GL_RED;
>}
>tex_swizzle = compute_texture_format_swizzle(baseFormat,
> 



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] vl/dri3: handle the case of different GPU(v4.1)

[Nayan Deshmukh]

Hi Axel,
On 1 Oct 2016 02:34, "Axel Davy"  wrote:
>
> On 16/09/2016 14:51, Nayan Deshmukh wrote:
>>
>>
>> bool flushed;
>> +   bool is_different_gpu;
>>  };
>>
>
> I get a warning when I build about incompatible pointer type at the line
>
> fd = loader_get_user_preferred_fd(fd, >is_different_gpu);
>
> When compiling on 32 bits.
>
> I get this should be int.
>
Yes you are right it should be int. I will submit a patch later today.

Regards,
Nayan
>
> Axel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] glsl: add missing headers to blob.h

[Timothy Arceri]

---
 src/compiler/glsl/blob.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/compiler/glsl/blob.h b/src/compiler/glsl/blob.h
index ec903ec..0765bf3 100644
--- a/src/compiler/glsl/blob.h
+++ b/src/compiler/glsl/blob.h
@@ -29,6 +29,8 @@
 extern "C" {
 #endif
 
+#include 
+#include 
 #include 
 
 /* The blob functions implement a simple, low-level API for serializing and
-- 
2.7.4

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

Re: [Mesa-dev] mesa/llvmpipe select alpha visual

[Roland Scheidegger]

Am 30.09.2016 um 01:49 schrieb Thomas Søndergaard:
> My application window becomes transparent when I run my application with
> llvmpipe by setting LD_LIBRARY_PATH instead of the proprietary NVIDIA
> driver that I otherwise use. I've come to the understanding, after
> digging into the code for a few hours, that mesa selects this Visual
> even though my application hasn't asked for an alpha channel:
> 
> Visual ID: 23  depth=32  class=TrueColor, type=(none)
> bufferSize=32 level=0 renderType=rgba doubleBuffer=1 stereo=0
> rgba: redSize=8 greenSize=8 blueSize=8 alphaSize=8 float=N sRGB=N
> auxBuffers=0 depthSize=24 stencilSize=8
> accum: redSize=16 greenSize=16 blueSize=16 alphaSize=0
> multiSample=0  multiSampleBuffers=0
> visualCaveat=None
> 
> My application uses Qt-5 and if I modify it to not set
> 
> GLX_RED_SIZE=1
> GLX_GREEN_SIZE=1
> GLX_BLUE_SIZE=1
> 
> Then I get the following visual instead and my window is no longer
> blended with the background based on the alpha values in the framebuffer.
> 
> Visual ID: 21  depth=24  class=TrueColor, type=(none)
> bufferSize=24 level=0 renderType=rgba doubleBuffer=1 stereo=0
> rgba: redSize=8 greenSize=8 blueSize=8 alphaSize=8 float=N sRGB=N
> auxBuffers=0 depthSize=24 stencilSize=8
> accum: redSize=16 greenSize=16 blueSize=16 alphaSize=16
> multiSample=0  multiSampleBuffers=0
> visualCaveat=None
> Opaque.
> 
> I've digged a little in the mesa code and I can see that if either of
> GLX_RED_SIZE, GLX_GREEN_SIZE and GLX_BLUE_SIZE is set then
> choose_x_visual() in mesa/src/gallium/state_trackers/glx/xlib/glx_api.c
> starts the search for a visual from the deep end, where-as if none of
> them are set it starts from the shallow end when searching for visuals?
> 
> Why does it do that?
> 
> The consequence is that I get a 32-bit visual visual with an alpha
> channel, even though I haven't asked for an alpha channel.
> 
> I've found out that I can set XLIB_SKIP_ARGB_VISUALS=1 as a workaround,
> but it would be nice with a real fix. Is there anything I can do to help?
> 
> Would it make sense to simply always search from the shallow end? Or to
> only search from 24-bit and down if GLX_ALPHA_SIZE is 0? I saw a comment
> in rc/gallium/state_trackers/glx/xlib/glx_api.cc that mesa is limited to
> 8-bit per channel, so there doesn't seem to be any point in looking for
> a visual with higher depth if we don't want alpha.
> 
> That was a long mail - if you got this far, I thank you for your
> patience :-)
> 

I'm not familiar with this code but presumably the xlib code is less
tested than dri one, so if it differs there changing it probably
wouldn't hurt.
IIRC in the past there were actually apps which were quite sensitive to
this stuff (for instance, things like not requesting depth buffer and
still expecting one and similar), albeit the apps were buggy in this case.
I'm not actually even sure that even with visual which has alpha this
should actually be visible in the end? Totally not my area of expertise,
unfortunately...

Roland


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

Re: [Mesa-dev] [PATCH 6/9] anv/gen7_pipeline: Set few missing fields in 3DSTATE_VS

[Jason Ekstrand]

On Sep 30, 2016 3:56 PM, "Jason Ekstrand"  wrote:
>
> Flyby comments...
>
> On Sep 30, 2016 3:34 PM, "Anuj Phogat"  wrote:
> >
> > Signed-off-by: Anuj Phogat 
> > ---
> >  src/intel/vulkan/gen7_pipeline.c | 6 ++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/src/intel/vulkan/gen7_pipeline.c
b/src/intel/vulkan/gen7_pipeline.c
> > index 8d133b6..f98aef5 100644
> > --- a/src/intel/vulkan/gen7_pipeline.c
> > +++ b/src/intel/vulkan/gen7_pipeline.c
> > @@ -121,6 +121,12 @@ genX(graphics_pipeline_create)(
> >   };
> >   vs.PerThreadScratchSpace  =
scratch_space(_prog_data->base.base);
> >
> > + vs.FloatingPointMode  =
vs_prog_data->base.base.use_alt_mode ?
> > + Alternate : IEEE754;
>
> I'm pretty sure we only use alt mode for ARB programs do it doesn't
really apply to Vulkan.  Explicitly setting it to IEEE seems reasonable
though.
>
> > + vs.SamplerCount   = 0;
> > + vs.BindingTableEntryCount =
> > +vs_prog_data->base.base.binding_table.size_bytes / 4;
>
> We don't set the binding table size field in the Vulkan driver so I don't
think this actually does anything.  Maybe we should actually set sampler
and surface state counts to something reasonable?  It might have a
performance impact but I don't know if we've ever measured it.

Thinking a bit more, I think we can get both the sampler count and the
binding table entry count from the anv_bind_map data structure associated
with the stage.  We should either use that directly or plumb it through
prog_data somewhere. (I don't believe we fill of those prog_data fields
today.)

> > +
> >   vs.DispatchGRFStartRegisterforURBData=
> >  vs_prog_data->base.base.dispatch_grf_start_reg;
> >
> > --
> > 2.5.5
> >
> > ___
> > 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

Re: [Mesa-dev] [PATCH 1/9] intel/genxml: Fix typo in gen75.xml

[Jason Ekstrand]

Patches 1, 2, 3, 5, and 7 are

Reviewed-by: Jason Ekstrand 

On Sep 30, 2016 3:33 PM, "Anuj Phogat"  wrote:

> Signed-off-by: Anuj Phogat 
> ---
>  src/intel/genxml/gen75.xml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/intel/genxml/gen75.xml b/src/intel/genxml/gen75.xml
> index 1debc3a..8e18007 100644
> --- a/src/intel/genxml/gen75.xml
> +++ b/src/intel/genxml/gen75.xml
> @@ -1571,7 +1571,7 @@
>
>  
>  
> -  
> +  
>
>  
>  
> --
> 2.5.5
>
> ___
> 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

Re: [Mesa-dev] [PATCH 9/9] anv/gen7_pipeline: Check for ksp0 when setting BarycentricInterpolationMode in 3DSTATE_WM

[Jason Ekstrand]

On Sep 30, 2016 3:34 PM, "Anuj Phogat"  wrote:
>
> Signed-off-by: Anuj Phogat 
> ---
>  src/intel/vulkan/gen7_pipeline.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/intel/vulkan/gen7_pipeline.c
b/src/intel/vulkan/gen7_pipeline.c
> index 4bab0bc..e804002 100644
> --- a/src/intel/vulkan/gen7_pipeline.c
> +++ b/src/intel/vulkan/gen7_pipeline.c
> @@ -273,7 +273,8 @@ genX(graphics_pipeline_create)(
>  wm.EarlyDepthStencilControl = EDSC_NORMAL;
>   }
>
> - wm.BarycentricInterpolationMode=
wm_prog_data->barycentric_interp_modes;
> + wm.BarycentricInterpolationMode= pipeline->ps_ksp0 ==
NO_KERNEL ?
> +  0 :
wm_prog_data->barycentric_interp_modes;

I believe this code is in a block that is already protected.

>
>   wm.MultisampleRasterizationMode= samples > 1 ?
>MSRASTMODE_ON_PATTERN
: MSRASTMODE_OFF_PIXEL;
> --
> 2.5.5
>
> ___
> 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

Re: [Mesa-dev] [PATCH 8/9] anv/gen7_pipeline: Set few missing fields in 3DSTATE_PS

[Jason Ekstrand]

On Sep 30, 2016 3:34 PM, "Anuj Phogat"  wrote:
>
> Signed-off-by: Anuj Phogat 
> ---
>  src/intel/vulkan/gen7_pipeline.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/src/intel/vulkan/gen7_pipeline.c
b/src/intel/vulkan/gen7_pipeline.c
> index 9411631..4bab0bc 100644
> --- a/src/intel/vulkan/gen7_pipeline.c
> +++ b/src/intel/vulkan/gen7_pipeline.c
> @@ -243,6 +243,10 @@ genX(graphics_pipeline_create)(
>   /* Haswell requires the sample mask to be set in this packet as
well as
>* in 3DSTATE_SAMPLE_MASK; the values should match. */
>   /* _NEW_BUFFERS, _NEW_MULTISAMPLE */
> +#if (GEN_IS_HASWELL)

There is some code that uses this #if style but I think the "official"
style is to not indent and not use the parens.

> + ps.SampleMask= 0xff;
> +#endif
> + ps.SamplerCount  = 1;

Of we're going to add code to set sampler count, it should be accurate.
It's probably best to drop this line and have a later patch which actually
sets it correctly.

>}
>
>uint32_t samples = pCreateInfo->pMultisampleState ?
> --
> 2.5.5
>
> ___
> 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

Re: [Mesa-dev] [PATCH] mesa: use uint32_t rather than unsigned for xfb struct members

[Jason Ekstrand]

Seems reasonable. I'm generally a fan of explicitly sized types anyway. R-B

On Sep 30, 2016 4:20 PM, "Timothy Arceri" 
wrote:

> These structs will be written to disk as part of the shader cache
> so use uint32_t just to be safe.
> ---
>  src/mesa/main/mtypes.h | 20 ++--
>  1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
> index d1b0560..efcd50e 100644
> --- a/src/mesa/main/mtypes.h
> +++ b/src/mesa/main/mtypes.h
> @@ -1643,40 +1643,40 @@ struct gl_transform_feedback_varying_info
>   */
>  struct gl_transform_feedback_output
>  {
> -   unsigned OutputRegister;
> -   unsigned OutputBuffer;
> -   unsigned NumComponents;
> -   unsigned StreamId;
> +   uint32_t OutputRegister;
> +   uint32_t OutputBuffer;
> +   uint32_t NumComponents;
> +   uint32_t StreamId;
>
> /** offset (in DWORDs) of this output within the interleaved structure
> */
> -   unsigned DstOffset;
> +   uint32_t DstOffset;
>
> /**
>  * Offset into the output register of the data to output.  For example,
>  * if NumComponents is 2 and ComponentOffset is 1, then the data to
>  * offset is in the y and z components of the output register.
>  */
> -   unsigned ComponentOffset;
> +   uint32_t ComponentOffset;
>  };
>
>
>  struct gl_transform_feedback_buffer
>  {
> -   unsigned Binding;
> +   uint32_t Binding;
>
> -   unsigned NumVaryings;
> +   uint32_t NumVaryings;
>
> /**
>  * Total number of components stored in each buffer.  This may be used
> by
>  * hardware back-ends to determine the correct stride when interleaving
>  * multiple transform feedback outputs in the same buffer.
>  */
> -   unsigned Stride;
> +   uint32_t Stride;
>
> /**
>  * Which transform feedback stream this buffer binding is associated
> with.
>  */
> -   unsigned Stream;
> +   uint32_t Stream;
>  };
>
>
> --
> 2.7.4
>
> ___
> 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] [PATCH mesa] egl: add missing error-checking to eglReleaseTexImage()

[Eric Engestrom]

Signed-off-by: Eric Engestrom 
---
 src/egl/main/eglsurface.c | 43 ---
 1 file changed, 40 insertions(+), 3 deletions(-)

diff --git a/src/egl/main/eglsurface.c b/src/egl/main/eglsurface.c
index 231a5f0..2762503 100644
--- a/src/egl/main/eglsurface.c
+++ b/src/egl/main/eglsurface.c
@@ -521,14 +521,51 @@ _eglBindTexImage(_EGLDriver *drv, _EGLDisplay *dpy, 
_EGLSurface *surface,
 }
 
 EGLBoolean
-_eglReleaseTexImage(_EGLDriver *drv, _EGLDisplay *disp, _EGLSurface *surf,
+_eglReleaseTexImage(_EGLDriver *drv, _EGLDisplay *dpy, _EGLSurface *surf,
 EGLint buffer)
 {
-   /* TODO: do basic error checking and return success/fail.
+   /* Just do basic error checking and return success/fail.
 * Drivers must implement the real stuff.
 */
 
+   EGLint texture_type = EGL_PBUFFER_BIT;
+
+   if (surf == EGL_NO_SURFACE)
+   {
+  _eglError(EGL_BAD_SURFACE, "eglReleaseTexImage");
+  return EGL_FALSE;
+   }
+
+   if (!surf->BoundToTexture)
+   {
+  /* Not an error, simply nothing to do */
+  return EGL_TRUE;
+   }
+
+   if (surf->TextureFormat == EGL_NO_TEXTURE)
+   {
+  _eglError(EGL_BAD_MATCH, "eglReleaseTexImage");
+  return EGL_FALSE;
+   }
+
+   if (buffer != EGL_BACK_BUFFER)
+   {
+  _eglError(EGL_BAD_PARAMETER, "eglReleaseTexImage");
+  return EGL_FALSE;
+   }
+
+   if (dpy->Extensions.NOK_texture_from_pixmap)
+  texture_type |= EGL_PIXMAP_BIT;
+
+   if (!(surf->Type & texture_type))
+   {
+  _eglError(EGL_BAD_SURFACE, "eglReleaseTexImage");
+  return EGL_FALSE;
+   }
+
+   surf->BoundToTexture = EGL_FALSE;
+
-  return EGL_TRUE;
+   return EGL_TRUE;
 }
 
 
-- 
Cheers,
  Eric

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

[Mesa-dev] [PATCH] mesa: use uint32_t rather than unsigned for xfb struct members

[Timothy Arceri]

These structs will be written to disk as part of the shader cache
so use uint32_t just to be safe.
---
 src/mesa/main/mtypes.h | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index d1b0560..efcd50e 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -1643,40 +1643,40 @@ struct gl_transform_feedback_varying_info
  */
 struct gl_transform_feedback_output
 {
-   unsigned OutputRegister;
-   unsigned OutputBuffer;
-   unsigned NumComponents;
-   unsigned StreamId;
+   uint32_t OutputRegister;
+   uint32_t OutputBuffer;
+   uint32_t NumComponents;
+   uint32_t StreamId;
 
/** offset (in DWORDs) of this output within the interleaved structure */
-   unsigned DstOffset;
+   uint32_t DstOffset;
 
/**
 * Offset into the output register of the data to output.  For example,
 * if NumComponents is 2 and ComponentOffset is 1, then the data to
 * offset is in the y and z components of the output register.
 */
-   unsigned ComponentOffset;
+   uint32_t ComponentOffset;
 };
 
 
 struct gl_transform_feedback_buffer
 {
-   unsigned Binding;
+   uint32_t Binding;
 
-   unsigned NumVaryings;
+   uint32_t NumVaryings;
 
/**
 * Total number of components stored in each buffer.  This may be used by
 * hardware back-ends to determine the correct stride when interleaving
 * multiple transform feedback outputs in the same buffer.
 */
-   unsigned Stride;
+   uint32_t Stride;
 
/**
 * Which transform feedback stream this buffer binding is associated with.
 */
-   unsigned Stream;
+   uint32_t Stream;
 };
 
 
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH] anv/formats: Fix build on gcc-4 and earlier

[Jason Ekstrand]

I remember the first tone you fixed this but when I was going the
ISL_SWIZZLE stuff, I couldn't find it in the git log so I went ahead and
pushed the change. Thanks for fixing it again.

Reviewed-by: Jason Ekstrand 

On Sep 30, 2016 1:00 PM,  wrote:

> From: Ville Syrjälä 
>
> gcc-4 and earlier don't allow compound literals where a constant
> is required in -std=c99/gnu99 mode, so we can't use ISL_SWIZZLE()
> when populating the anv_formats[] array. There are a few ways around
> it: First one would be -std=c89/gnu89, but the rest of the code
> depends on c99 so it's not really an option. The second option
> would be to upgrade to gcc-5+ where the compiler behaviour was relaxed
> a bit [1]. And the third option is just to avoid using compound
> literals. I chose the last option since it keeps gcc-4 and earlier
> working.
>
> [1] https://gcc.gnu.org/gcc-5/porting_to.html
>
> Cc: Jason Ekstrand 
> Cc: Topi Pohjolainen 
> Fixes: 7ddb21708c80 ("intel/isl: Add an isl_swizzle structure and use it
> for isl_view swizzles")
> Signed-off-by: Ville Syrjälä 
> ---
>  src/intel/vulkan/anv_formats.c | 23 +++
>  1 file changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/src/intel/vulkan/anv_formats.c b/src/intel/vulkan/anv_
> formats.c
> index 7341d725cd0a..f6915540fb3d 100644
> --- a/src/intel/vulkan/anv_formats.c
> +++ b/src/intel/vulkan/anv_formats.c
> @@ -24,9 +24,24 @@
>  #include "anv_private.h"
>  #include "vk_format_info.h"
>
> -#define RGBA ISL_SWIZZLE(RED, GREEN, BLUE, ALPHA)
> -#define BGRA ISL_SWIZZLE(BLUE, GREEN, RED, ALPHA)
> -#define RGB1 ISL_SWIZZLE(RED, GREEN, BLUE, ONE)
> +/*
> + * gcc-4 and earlier don't allow compound literals where a constant
> + * is required in -std=c99/gnu99 mode, so we can't use ISL_SWIZZLE()
> + * here. -std=c89/gnu89 would allow it, but we depend on c99 features
> + * so using -std=c89/gnu89 is not an option. Starting from gcc-5
> + * compound literals can also be considered constant in -std=c99/gnu99
> + * mode.
> + */
> +#define _ISL_SWIZZLE(r, g, b, a) { \
> +  ISL_CHANNEL_SELECT_##r, \
> +  ISL_CHANNEL_SELECT_##g, \
> +  ISL_CHANNEL_SELECT_##b, \
> +  ISL_CHANNEL_SELECT_##a, \
> +}
> +
> +#define RGBA _ISL_SWIZZLE(RED, GREEN, BLUE, ALPHA)
> +#define BGRA _ISL_SWIZZLE(BLUE, GREEN, RED, ALPHA)
> +#define RGB1 _ISL_SWIZZLE(RED, GREEN, BLUE, ONE)
>
>  #define swiz_fmt(__vk_fmt, __hw_fmt, __swizzle) \
> [__vk_fmt] = { \
> @@ -276,7 +291,7 @@ anv_get_format(const struct gen_device_info *devinfo,
> VkFormat vk_format,
>   format.isl_format = rgbx;
>} else {
>   format.isl_format = isl_format_rgb_to_rgba(format.isl_format);
> - format.swizzle = RGB1;
> + format.swizzle = ISL_SWIZZLE(RED, GREEN, BLUE, ONE);
>}
> }
>
> --
> 2.7.4
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 6/9] anv/gen7_pipeline: Set few missing fields in 3DSTATE_VS

[Jason Ekstrand]

Flyby comments...

On Sep 30, 2016 3:34 PM, "Anuj Phogat"  wrote:
>
> Signed-off-by: Anuj Phogat 
> ---
>  src/intel/vulkan/gen7_pipeline.c | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/src/intel/vulkan/gen7_pipeline.c
b/src/intel/vulkan/gen7_pipeline.c
> index 8d133b6..f98aef5 100644
> --- a/src/intel/vulkan/gen7_pipeline.c
> +++ b/src/intel/vulkan/gen7_pipeline.c
> @@ -121,6 +121,12 @@ genX(graphics_pipeline_create)(
>   };
>   vs.PerThreadScratchSpace  =
scratch_space(_prog_data->base.base);
>
> + vs.FloatingPointMode  =
vs_prog_data->base.base.use_alt_mode ?
> + Alternate : IEEE754;

I'm pretty sure we only use alt mode for ARB programs do it doesn't really
apply to Vulkan.  Explicitly setting it to IEEE seems reasonable though.

> + vs.SamplerCount   = 0;
> + vs.BindingTableEntryCount =
> +vs_prog_data->base.base.binding_table.size_bytes / 4;

We don't set the binding table size field in the Vulkan driver so I don't
think this actually does anything.  Maybe we should actually set sampler
and surface state counts to something reasonable?  It might have a
performance impact but I don't know if we've ever measured it.

> +
>   vs.DispatchGRFStartRegisterforURBData=
>  vs_prog_data->base.base.dispatch_grf_start_reg;
>
> --
> 2.5.5
>
> ___
> 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] [PATCH 1/5] st/mesa: simplify some code in get_texture_format_swizzle()

[Brian Paul]

There's no need to cast to st_texture_image.  Just use gl_texture_image.
---
 src/mesa/state_tracker/st_atom_texture.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/mesa/state_tracker/st_atom_texture.c 
b/src/mesa/state_tracker/st_atom_texture.c
index efc8c90..113c0ed 100644
--- a/src/mesa/state_tracker/st_atom_texture.c
+++ b/src/mesa/state_tracker/st_atom_texture.c
@@ -211,11 +211,11 @@ get_texture_format_swizzle(const struct st_context *st,
*/
   if (_mesa_is_gles3(st->ctx) &&
   util_format_is_depth_or_stencil(stObj->pt->format)) {
- const struct st_texture_image *firstImage =
-st_texture_image_const(_mesa_base_tex_image(>base));
- if (firstImage->base.InternalFormat != GL_DEPTH_COMPONENT &&
- firstImage->base.InternalFormat != GL_DEPTH_STENCIL &&
- firstImage->base.InternalFormat != GL_STENCIL_INDEX)
+ const struct gl_texture_image *firstImage =
+_mesa_base_tex_image(>base);
+ if (firstImage->InternalFormat != GL_DEPTH_COMPONENT &&
+ firstImage->InternalFormat != GL_DEPTH_STENCIL &&
+ firstImage->InternalFormat != GL_STENCIL_INDEX)
 depth_mode = GL_RED;
   }
   tex_swizzle = compute_texture_format_swizzle(baseFormat,
-- 
1.9.1

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

[Mesa-dev] [PATCH 5/5] st/mesa: move all sampler view code into new st_sampler_view.[ch] files

[Brian Paul]

Previously, the sampler view code was scattered across several different
files.

Note, the previous REALLOC(), FREE() for st_texture_object::sampler_views
are replaced by realloc(), free() to avoid conflicting macros in Mesa vs.
Gallium.
---
 src/mesa/Makefile.sources  |   2 +
 src/mesa/state_tracker/st_atom_pixeltransfer.c |   1 +
 src/mesa/state_tracker/st_atom_texture.c   | 358 +-
 src/mesa/state_tracker/st_cb_bitmap.c  |   1 +
 src/mesa/state_tracker/st_cb_drawpixels.c  |   1 +
 src/mesa/state_tracker/st_cb_eglimage.c|   2 +
 src/mesa/state_tracker/st_cb_texture.c |   1 +
 src/mesa/state_tracker/st_context.c|   1 +
 src/mesa/state_tracker/st_sampler_view.c   | 487 +
 src/mesa/state_tracker/st_sampler_view.h   |  83 +
 src/mesa/state_tracker/st_texture.c|  93 -
 src/mesa/state_tracker/st_texture.h|  34 --
 12 files changed, 580 insertions(+), 484 deletions(-)
 create mode 100644 src/mesa/state_tracker/st_sampler_view.c
 create mode 100644 src/mesa/state_tracker/st_sampler_view.h

diff --git a/src/mesa/Makefile.sources b/src/mesa/Makefile.sources
index fbe5861..410a61a 100644
--- a/src/mesa/Makefile.sources
+++ b/src/mesa/Makefile.sources
@@ -510,6 +510,8 @@ STATETRACKER_FILES = \
state_tracker/st_pbo.h \
state_tracker/st_program.c \
state_tracker/st_program.h \
+   state_tracker/st_sampler_view.c \
+   state_tracker/st_sampler_view.h \
state_tracker/st_scissor.c \
state_tracker/st_scissor.h \
state_tracker/st_texture.c \
diff --git a/src/mesa/state_tracker/st_atom_pixeltransfer.c 
b/src/mesa/state_tracker/st_atom_pixeltransfer.c
index 26d8ade..a2951a1 100644
--- a/src/mesa/state_tracker/st_atom_pixeltransfer.c
+++ b/src/mesa/state_tracker/st_atom_pixeltransfer.c
@@ -30,6 +30,7 @@
  */
 
 #include "st_context.h"
+#include "st_sampler_view.h"
 #include "st_texture.h"
 
 #include "util/u_inlines.h"
diff --git a/src/mesa/state_tracker/st_atom_texture.c 
b/src/mesa/state_tracker/st_atom_texture.c
index e5574bd..c8ae62c 100644
--- a/src/mesa/state_tracker/st_atom_texture.c
+++ b/src/mesa/state_tracker/st_atom_texture.c
@@ -42,6 +42,7 @@
 
 #include "st_context.h"
 #include "st_atom.h"
+#include "st_sampler_view.h"
 #include "st_texture.h"
 #include "st_format.h"
 #include "st_cb_texture.h"
@@ -51,363 +52,6 @@
 #include "cso_cache/cso_context.h"
 
 
-/**
- * Return swizzle1(swizzle2)
- */
-static unsigned
-swizzle_swizzle(unsigned swizzle1, unsigned swizzle2)
-{
-   unsigned i, swz[4];
-
-   if (swizzle1 == SWIZZLE_XYZW) {
-  /* identity swizzle, no change to swizzle2 */
-  return swizzle2;
-   }
-
-   for (i = 0; i < 4; i++) {
-  unsigned s = GET_SWZ(swizzle1, i);
-  switch (s) {
-  case SWIZZLE_X:
-  case SWIZZLE_Y:
-  case SWIZZLE_Z:
-  case SWIZZLE_W:
- swz[i] = GET_SWZ(swizzle2, s);
- break;
-  case SWIZZLE_ZERO:
- swz[i] = SWIZZLE_ZERO;
- break;
-  case SWIZZLE_ONE:
- swz[i] = SWIZZLE_ONE;
- break;
-  default:
- assert(!"Bad swizzle term");
- swz[i] = SWIZZLE_X;
-  }
-   }
-
-   return MAKE_SWIZZLE4(swz[0], swz[1], swz[2], swz[3]);
-}
-
-
-/**
- * Given a user-specified texture base format, the actual gallium texture
- * format and the current GL_DEPTH_MODE, return a texture swizzle.
- *
- * Consider the case where the user requests a GL_RGB internal texture
- * format the driver actually uses an RGBA format.  The A component should
- * be ignored and sampling from the texture should always return (r,g,b,1).
- * But if we rendered to the texture we might have written A values != 1.
- * By sampling the texture with a ".xyz1" swizzle we'll get the expected A=1.
- * This function computes the texture swizzle needed to get the expected
- * values.
- *
- * In the case of depth textures, the GL_DEPTH_MODE state determines the
- * texture swizzle.
- *
- * This result must be composed with the user-specified swizzle to get
- * the final swizzle.
- */
-static unsigned
-compute_texture_format_swizzle(GLenum baseFormat, GLenum depthMode,
-   enum pipe_format actualFormat,
-   unsigned glsl_version)
-{
-   switch (baseFormat) {
-   case GL_RGBA:
-  return SWIZZLE_XYZW;
-   case GL_RGB:
-  if (util_format_has_alpha(actualFormat))
- return MAKE_SWIZZLE4(SWIZZLE_X, SWIZZLE_Y, SWIZZLE_Z, SWIZZLE_ONE);
-  else
- return SWIZZLE_XYZW;
-   case GL_RG:
-  if (util_format_get_nr_components(actualFormat) > 2)
- return MAKE_SWIZZLE4(SWIZZLE_X, SWIZZLE_Y, SWIZZLE_ZERO, SWIZZLE_ONE);
-  else
- return SWIZZLE_XYZW;
-   case GL_RED:
-  if (util_format_get_nr_components(actualFormat) > 1)
- return MAKE_SWIZZLE4(SWIZZLE_X, SWIZZLE_ZERO,
-  SWIZZLE_ZERO, SWIZZLE_ONE);
-  else
-  

[Mesa-dev] [PATCH 2/5] st/mesa: add some const qualifiers in st_atom_texture.c

[Brian Paul]

And minor code reformatting.
---
 src/mesa/state_tracker/st_atom_texture.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/src/mesa/state_tracker/st_atom_texture.c 
b/src/mesa/state_tracker/st_atom_texture.c
index 113c0ed..86f1c62 100644
--- a/src/mesa/state_tracker/st_atom_texture.c
+++ b/src/mesa/state_tracker/st_atom_texture.c
@@ -241,7 +241,7 @@ get_texture_format_swizzle(const struct st_context *st,
 static boolean
 check_sampler_swizzle(const struct st_context *st,
   const struct st_texture_object *stObj,
- struct pipe_sampler_view *sv, unsigned glsl_version)
+ const struct pipe_sampler_view *sv, unsigned glsl_version)
 {
unsigned swizzle = get_texture_format_swizzle(st, stObj, glsl_version);
 
@@ -252,7 +252,8 @@ check_sampler_swizzle(const struct st_context *st,
 }
 
 
-static unsigned last_level(struct st_texture_object *stObj)
+static unsigned
+last_level(const struct st_texture_object *stObj)
 {
unsigned ret = MIN2(stObj->base.MinLevel + stObj->base._MaxLevel,
stObj->pt->last_level);
@@ -261,7 +262,8 @@ static unsigned last_level(struct st_texture_object *stObj)
return ret;
 }
 
-static unsigned last_layer(struct st_texture_object *stObj)
+static unsigned
+last_layer(const struct st_texture_object *stObj)
 {
if (stObj->base.Immutable && stObj->pt->array_size > 1)
   return MIN2(stObj->base.MinLayer + stObj->base.NumLayers - 1,
-- 
1.9.1

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

[Mesa-dev] [PATCH 3/5] st/mesa: consolidate view format setup code

[Brian Paul]

Before, we had code to compute the sampler view's format spread across two
different functions: in update_single_texture() and
st_get_texture_sampler_view_from_stobj().  Now it's all in one new function.

Also, use _mesa_texture_base_format() to simplify the code.
---
 src/mesa/state_tracker/st_atom_texture.c | 88 
 1 file changed, 54 insertions(+), 34 deletions(-)

diff --git a/src/mesa/state_tracker/st_atom_texture.c 
b/src/mesa/state_tracker/st_atom_texture.c
index 86f1c62..bfa16dc 100644
--- a/src/mesa/state_tracker/st_atom_texture.c
+++ b/src/mesa/state_tracker/st_atom_texture.c
@@ -271,6 +271,58 @@ last_layer(const struct st_texture_object *stObj)
return stObj->pt->array_size - 1;
 }
 
+
+/**
+ * Determine the format for the texture sampler view.
+ */
+static enum pipe_format
+get_sampler_view_format(struct st_context *st,
+const struct st_texture_object *stObj,
+const struct gl_sampler_object *samp)
+{
+   enum pipe_format format;
+
+   if (stObj->base.Target == GL_TEXTURE_BUFFER) {
+  format =
+ st_mesa_format_to_pipe_format(st, stObj->base._BufferObjectFormat);
+   }
+   else {
+  format =
+ stObj->surface_based ? stObj->surface_format : stObj->pt->format;
+
+  if (util_format_is_depth_and_stencil(format)) {
+ if (stObj->base.StencilSampling) {
+format = util_format_stencil_only(format);
+ }
+ else {
+GLenum baseFormat = _mesa_texture_base_format(>base);
+if (baseFormat == GL_STENCIL_INDEX) {
+   format = util_format_stencil_only(format);
+}
+ }
+  }
+  else {
+ /* If sRGB decoding is off, use the linear format */
+ if (samp->sRGBDecode == GL_SKIP_DECODE_EXT) {
+format = util_format_linear(format);
+ }
+
+ /* Use R8_UNORM for video formats */
+ switch (format) {
+ case PIPE_FORMAT_NV12:
+ case PIPE_FORMAT_IYUV:
+format = PIPE_FORMAT_R8_UNORM;
+break;
+ default:
+break;
+ }
+  }
+   }
+
+   return format;
+}
+
+
 static struct pipe_sampler_view *
 st_create_texture_sampler_view_from_stobj(struct st_context *st,
  struct st_texture_object *stObj,
@@ -322,23 +374,13 @@ st_get_texture_sampler_view_from_stobj(struct st_context 
*st,
unsigned glsl_version)
 {
struct pipe_sampler_view **sv;
-   const struct st_texture_image *firstImage;
+
if (!stObj || !stObj->pt) {
   return NULL;
}
 
sv = st_texture_get_sampler_view(st, stObj);
 
-   if (util_format_is_depth_and_stencil(format)) {
-  if (stObj->base.StencilSampling)
- format = util_format_stencil_only(format);
-  else {
- firstImage = 
st_texture_image_const(_mesa_base_tex_image(>base));
- if (firstImage->base._BaseFormat == GL_STENCIL_INDEX)
-format = util_format_stencil_only(format);
-  }
-   }
-
/* if sampler view has changed dereference it */
if (*sv) {
   if (check_sampler_swizzle(st, stObj, *sv, glsl_version) ||
@@ -395,29 +437,7 @@ update_single_texture(struct st_context *st,
   return GL_FALSE;
}
 
-   /* Determine the format of the texture sampler view */
-   if (texObj->Target == GL_TEXTURE_BUFFER) {
-  view_format =
- st_mesa_format_to_pipe_format(st, stObj->base._BufferObjectFormat);
-   }
-   else {
-  view_format =
- stObj->surface_based ? stObj->surface_format : stObj->pt->format;
-
-  /* If sRGB decoding is off, use the linear format */
-  if (samp->sRGBDecode == GL_SKIP_DECODE_EXT) {
- view_format = util_format_linear(view_format);
-  }
-   }
-
-   switch (view_format) {
-   case PIPE_FORMAT_NV12:
-   case PIPE_FORMAT_IYUV:
-  view_format = PIPE_FORMAT_R8_UNORM;
-  break;
-   default:
-  break;
-   }
+   view_format = get_sampler_view_format(st, stObj, samp);
 
*sampler_view =
   st_get_texture_sampler_view_from_stobj(st, stObj, view_format,
-- 
1.9.1

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

[Mesa-dev] [PATCH 4/5] st/mesa: optimize pipe_sampler_view validation

[Brian Paul]

Before, st_get_texture_sampler_view_from_stobj() did a lot of work to
check if the texture parameters matched the sampler view (format,
swizzle, min/max lod, first/last layer, etc).  We did this every time
we validated the texture state.

Now, we use a ctx->Driver.TexParameter() callback and a couple other
checks to proactively release texture views when we know that
view-related parameters have changed.  Then, the validation step is
simplified:
- Search the texture's list of sampler views (just match the context).
- If found, we're done.
- Else, create a new sampler view.

There will never be old, out-of-date sampler views attached to texture
objects that we have to test.

Most apps create textures and set the texture parameters once.  This
make sampler view validation much cheaper for that case.

Note that the old texture/sampler comparison code has been converted
into a set of assertions to verify that the sampler view is in fact
consistent with the texture parameters.  This should help to spot any
potential regressions.
---
 src/mesa/state_tracker/st_atom_texture.c | 51 ++--
 src/mesa/state_tracker/st_cb_texture.c   | 50 +++
 src/mesa/state_tracker/st_texture.c  | 16 +-
 src/mesa/state_tracker/st_texture.h  |  5 
 4 files changed, 91 insertions(+), 31 deletions(-)

diff --git a/src/mesa/state_tracker/st_atom_texture.c 
b/src/mesa/state_tracker/st_atom_texture.c
index bfa16dc..e5574bd 100644
--- a/src/mesa/state_tracker/st_atom_texture.c
+++ b/src/mesa/state_tracker/st_atom_texture.c
@@ -370,7 +370,7 @@ st_create_texture_sampler_view_from_stobj(struct st_context 
*st,
 static struct pipe_sampler_view *
 st_get_texture_sampler_view_from_stobj(struct st_context *st,
struct st_texture_object *stObj,
-  enum pipe_format format,
+   const struct gl_sampler_object *samp,
unsigned glsl_version)
 {
struct pipe_sampler_view **sv;
@@ -381,34 +381,33 @@ st_get_texture_sampler_view_from_stobj(struct st_context 
*st,
 
sv = st_texture_get_sampler_view(st, stObj);
 
-   /* if sampler view has changed dereference it */
if (*sv) {
-  if (check_sampler_swizzle(st, stObj, *sv, glsl_version) ||
- (format != (*sv)->format) ||
-  gl_target_to_pipe(stObj->base.Target) != (*sv)->target ||
-  stObj->base.MinLevel + stObj->base.BaseLevel != 
(*sv)->u.tex.first_level ||
-  last_level(stObj) != (*sv)->u.tex.last_level ||
-  stObj->base.MinLayer != (*sv)->u.tex.first_layer ||
-  last_layer(stObj) != (*sv)->u.tex.last_layer) {
-pipe_sampler_view_reference(sv, NULL);
-  }
+  /* Debug check: make sure that the sampler view's parameters are
+   * what they're supposed to be.
+   */
+  struct pipe_sampler_view *view = *sv;
+  assert(!check_sampler_swizzle(st, stObj, view, glsl_version));
+  assert(get_sampler_view_format(st, stObj, samp) == view->format);
+  assert(gl_target_to_pipe(stObj->base.Target) == view->target);
+  assert(stObj->base.MinLevel + stObj->base.BaseLevel ==
+ view->u.tex.first_level);
+  assert(last_level(stObj) == view->u.tex.last_level);
+  assert(stObj->base.MinLayer == view->u.tex.first_layer);
+  assert(last_layer(stObj) == view->u.tex.last_layer);
}
+   else {
+  /* create new sampler view */
+  enum pipe_format format = get_sampler_view_format(st, stObj, samp);
 
-   if (!*sv) {
   *sv = st_create_texture_sampler_view_from_stobj(st, stObj,
   format, glsl_version);
 
-   } else if ((*sv)->context != st->pipe) {
-  /* Recreate view in correct context, use existing view as template */
-  struct pipe_sampler_view *new_sv =
- st->pipe->create_sampler_view(st->pipe, stObj->pt, *sv);
-  pipe_sampler_view_reference(sv, NULL);
-  *sv = new_sv;
}
 
return *sv;
 }
 
+
 static GLboolean
 update_single_texture(struct st_context *st,
   struct pipe_sampler_view **sampler_view,
@@ -418,7 +417,6 @@ update_single_texture(struct st_context *st,
const struct gl_sampler_object *samp;
struct gl_texture_object *texObj;
struct st_texture_object *stObj;
-   enum pipe_format view_format;
GLboolean retval;
 
samp = _mesa_get_samplerobj(ctx, texUnit);
@@ -437,11 +435,20 @@ update_single_texture(struct st_context *st,
   return GL_FALSE;
}
 
-   view_format = get_sampler_view_format(st, stObj, samp);
+   /* Check a few pieces of state outside the texture object to see if we
+* need to force revalidation.
+*/
+   if (stObj->prev_glsl_version != glsl_version ||
+   stObj->prev_sRGBDecode != samp->sRGBDecode) {
+
+  st_texture_release_all_sampler_views(st, stObj);
+
+  stObj->prev_glsl_version = glsl_version;
+  

Re: [Mesa-dev] [PATCH 3/3] mesa: make _mesa_texture_buffer_range() static

[Anuj Phogat]

On Fri, Sep 30, 2016 at 3:37 PM, Brian Paul  wrote:
>
> Not called from any other file.  Also, add a comment.
> ---
>  src/mesa/main/teximage.c | 34 +++---
>  src/mesa/main/teximage.h |  8 
>  2 files changed, 19 insertions(+), 23 deletions(-)
>
> diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
> index 1d0a6a2..df8f0bc 100644
> --- a/src/mesa/main/teximage.c
> +++ b/src/mesa/main/teximage.c
> @@ -5034,13 +5034,17 @@ _mesa_validate_texbuffer_format(const struct 
> gl_context *ctx,
>  }
>
>
> -void
> -_mesa_texture_buffer_range(struct gl_context *ctx,
> -   struct gl_texture_object *texObj,
> -   GLenum internalFormat,
> -   struct gl_buffer_object *bufObj,
> -   GLintptr offset, GLsizeiptr size,
> -   const char *caller)
> +/**
> + * Do work common to glTexBuffer, glTexBufferRange, glTextureBuffer
> + * and glTextureBufferRange, including some error checking.
> + */
> +static void
> +texture_buffer_range(struct gl_context *ctx,
> + struct gl_texture_object *texObj,
> + GLenum internalFormat,
> + struct gl_buffer_object *bufObj,
> + GLintptr offset, GLsizeiptr size,
> + const char *caller)
>  {
> mesa_format format;
>
> @@ -5177,8 +5181,8 @@ _mesa_TexBuffer(GLenum target, GLenum internalFormat, 
> GLuint buffer)
> if (!texObj)
>return;
>
> -   _mesa_texture_buffer_range(ctx, texObj, internalFormat, bufObj, 0,
> -  buffer ? -1 : 0, "glTexBuffer");
> +   texture_buffer_range(ctx, texObj, internalFormat, bufObj, 0,
> +buffer ? -1 : 0, "glTexBuffer");
>  }
>
>
> @@ -5224,8 +5228,8 @@ _mesa_TexBufferRange(GLenum target, GLenum 
> internalFormat, GLuint buffer,
> if (!texObj)
>return;
>
> -   _mesa_texture_buffer_range(ctx, texObj, internalFormat, bufObj,
> -  offset, size, "glTexBufferRange");
> +   texture_buffer_range(ctx, texObj, internalFormat, bufObj,
> +offset, size, "glTexBufferRange");
>  }
>
>  void GLAPIENTRY
> @@ -5251,8 +5255,8 @@ _mesa_TextureBuffer(GLuint texture, GLenum 
> internalFormat, GLuint buffer)
> if (!check_texture_buffer_target(ctx, texObj->Target, "glTextureBuffer"))
>return;
>
> -   _mesa_texture_buffer_range(ctx, texObj, internalFormat,
> -  bufObj, 0, buffer ? -1 : 0, "glTextureBuffer");
> +   texture_buffer_range(ctx, texObj, internalFormat,
> +bufObj, 0, buffer ? -1 : 0, "glTextureBuffer");
>  }
>
>  void GLAPIENTRY
> @@ -5296,8 +5300,8 @@ _mesa_TextureBufferRange(GLuint texture, GLenum 
> internalFormat, GLuint buffer,
> "glTextureBufferRange"))
>return;
>
> -   _mesa_texture_buffer_range(ctx, texObj, internalFormat,
> -  bufObj, offset, size, "glTextureBufferRange");
> +   texture_buffer_range(ctx, texObj, internalFormat,
> +bufObj, offset, size, "glTextureBufferRange");
>  }
>
>  GLboolean
> diff --git a/src/mesa/main/teximage.h b/src/mesa/main/teximage.h
> index c52a780..05fa00d 100644
> --- a/src/mesa/main/teximage.h
> +++ b/src/mesa/main/teximage.h
> @@ -250,14 +250,6 @@ _mesa_copy_texture_sub_image(struct gl_context *ctx, 
> GLuint dims,
>   GLsizei width, GLsizei height,
>   const char *caller);
>
> -extern void
> -_mesa_texture_buffer_range(struct gl_context *ctx,
> -   struct gl_texture_object *texObj,
> -   GLenum internalFormat,
> -   struct gl_buffer_object *bufObj,
> -   GLintptr offset, GLsizeiptr size,
> -   const char *caller);
> -
>  bool
>  _mesa_is_cube_map_texture(GLenum target);
>
> --
> 1.9.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Series is:
Reviewed-by: Anuj Phogat 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/3] mesa: add const qualifier, comment on can_avoid_reallocation()

[Brian Paul]

---
 src/mesa/main/teximage.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 3f3d430..1d0a6a2 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -3571,8 +3571,15 @@ formats_differ_in_component_sizes(mesa_format f1, 
mesa_format f2)
return GL_FALSE;
 }
 
+
+/**
+ * Check if the given texture format and size arguments match those
+ * of the texture image.
+ * \param return true if arguments match, false otherwise.
+ */
 static bool
-can_avoid_reallocation(struct gl_texture_image *texImage, GLenum 
internalFormat,
+can_avoid_reallocation(const struct gl_texture_image *texImage,
+   GLenum internalFormat,
mesa_format texFormat, GLint x, GLint y, GLsizei width,
GLsizei height, GLint border)
 {
-- 
1.9.1

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

[Mesa-dev] [PATCH 1/3] mesa: add comment/assertion on get_tex_level_parameter_buffer()

[Brian Paul]

---
 src/mesa/main/texparam.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/mesa/main/texparam.c b/src/mesa/main/texparam.c
index bdd3fcb..a814778 100644
--- a/src/mesa/main/texparam.c
+++ b/src/mesa/main/texparam.c
@@ -1486,6 +1486,9 @@ invalid_pname:
 }
 
 
+/**
+ * Handle a glGetTexLevelParamteriv() call for a texture buffer.
+ */
 static void
 get_tex_level_parameter_buffer(struct gl_context *ctx,
const struct gl_texture_object *texObj,
@@ -1498,6 +1501,8 @@ get_tex_level_parameter_buffer(struct gl_context *ctx,
GLenum baseFormat = _mesa_get_format_base_format(texFormat);
const char *suffix = dsa ? "ture" : "";
 
+   assert(texObj->Target == GL_TEXTURE_BUFFER);
+
if (!bo) {
   /* undefined texture buffer object */
   switch (pname) {
-- 
1.9.1

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

[Mesa-dev] [PATCH 3/3] mesa: make _mesa_texture_buffer_range() static

[Brian Paul]

Not called from any other file.  Also, add a comment.
---
 src/mesa/main/teximage.c | 34 +++---
 src/mesa/main/teximage.h |  8 
 2 files changed, 19 insertions(+), 23 deletions(-)

diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 1d0a6a2..df8f0bc 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -5034,13 +5034,17 @@ _mesa_validate_texbuffer_format(const struct gl_context 
*ctx,
 }
 
 
-void
-_mesa_texture_buffer_range(struct gl_context *ctx,
-   struct gl_texture_object *texObj,
-   GLenum internalFormat,
-   struct gl_buffer_object *bufObj,
-   GLintptr offset, GLsizeiptr size,
-   const char *caller)
+/**
+ * Do work common to glTexBuffer, glTexBufferRange, glTextureBuffer
+ * and glTextureBufferRange, including some error checking.
+ */
+static void
+texture_buffer_range(struct gl_context *ctx,
+ struct gl_texture_object *texObj,
+ GLenum internalFormat,
+ struct gl_buffer_object *bufObj,
+ GLintptr offset, GLsizeiptr size,
+ const char *caller)
 {
mesa_format format;
 
@@ -5177,8 +5181,8 @@ _mesa_TexBuffer(GLenum target, GLenum internalFormat, 
GLuint buffer)
if (!texObj)
   return;
 
-   _mesa_texture_buffer_range(ctx, texObj, internalFormat, bufObj, 0,
-  buffer ? -1 : 0, "glTexBuffer");
+   texture_buffer_range(ctx, texObj, internalFormat, bufObj, 0,
+buffer ? -1 : 0, "glTexBuffer");
 }
 
 
@@ -5224,8 +5228,8 @@ _mesa_TexBufferRange(GLenum target, GLenum 
internalFormat, GLuint buffer,
if (!texObj)
   return;
 
-   _mesa_texture_buffer_range(ctx, texObj, internalFormat, bufObj,
-  offset, size, "glTexBufferRange");
+   texture_buffer_range(ctx, texObj, internalFormat, bufObj,
+offset, size, "glTexBufferRange");
 }
 
 void GLAPIENTRY
@@ -5251,8 +5255,8 @@ _mesa_TextureBuffer(GLuint texture, GLenum 
internalFormat, GLuint buffer)
if (!check_texture_buffer_target(ctx, texObj->Target, "glTextureBuffer"))
   return;
 
-   _mesa_texture_buffer_range(ctx, texObj, internalFormat,
-  bufObj, 0, buffer ? -1 : 0, "glTextureBuffer");
+   texture_buffer_range(ctx, texObj, internalFormat,
+bufObj, 0, buffer ? -1 : 0, "glTextureBuffer");
 }
 
 void GLAPIENTRY
@@ -5296,8 +5300,8 @@ _mesa_TextureBufferRange(GLuint texture, GLenum 
internalFormat, GLuint buffer,
"glTextureBufferRange"))
   return;
 
-   _mesa_texture_buffer_range(ctx, texObj, internalFormat,
-  bufObj, offset, size, "glTextureBufferRange");
+   texture_buffer_range(ctx, texObj, internalFormat,
+bufObj, offset, size, "glTextureBufferRange");
 }
 
 GLboolean
diff --git a/src/mesa/main/teximage.h b/src/mesa/main/teximage.h
index c52a780..05fa00d 100644
--- a/src/mesa/main/teximage.h
+++ b/src/mesa/main/teximage.h
@@ -250,14 +250,6 @@ _mesa_copy_texture_sub_image(struct gl_context *ctx, 
GLuint dims,
  GLsizei width, GLsizei height,
  const char *caller);
 
-extern void
-_mesa_texture_buffer_range(struct gl_context *ctx,
-   struct gl_texture_object *texObj,
-   GLenum internalFormat,
-   struct gl_buffer_object *bufObj,
-   GLintptr offset, GLsizeiptr size,
-   const char *caller);
-
 bool
 _mesa_is_cube_map_texture(GLenum target);
 
-- 
1.9.1

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

[Mesa-dev] [PATCH 4/9] anv/gen8_pipeline: Use Alternate floating point mode when use_alt_mode is set in prog_data

[Anuj Phogat]

Signed-off-by: Anuj Phogat 
---
 src/intel/vulkan/gen8_pipeline.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/intel/vulkan/gen8_pipeline.c b/src/intel/vulkan/gen8_pipeline.c
index 1abb97c..7a9a3cf 100644
--- a/src/intel/vulkan/gen8_pipeline.c
+++ b/src/intel/vulkan/gen8_pipeline.c
@@ -197,7 +197,8 @@ genX(graphics_pipeline_create)(
 vs_prog_data->base.base.binding_table.size_bytes / 4;
 
  vs.ThreadDispatchPriority= false;
- vs.FloatingPointMode = IEEE754;
+ vs.FloatingPointMode = 
vs_prog_data->base.base.use_alt_mode ?
+Alternate : IEEE754;
  vs.IllegalOpcodeExceptionEnable  = false;
  vs.AccessesUAV   = false;
  vs.SoftwareExceptionEnable   = false;
-- 
2.5.5

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

[Mesa-dev] [PATCH 8/9] anv/gen7_pipeline: Set few missing fields in 3DSTATE_PS

[Anuj Phogat]

Signed-off-by: Anuj Phogat 
---
 src/intel/vulkan/gen7_pipeline.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/intel/vulkan/gen7_pipeline.c b/src/intel/vulkan/gen7_pipeline.c
index 9411631..4bab0bc 100644
--- a/src/intel/vulkan/gen7_pipeline.c
+++ b/src/intel/vulkan/gen7_pipeline.c
@@ -243,6 +243,10 @@ genX(graphics_pipeline_create)(
  /* Haswell requires the sample mask to be set in this packet as well 
as
   * in 3DSTATE_SAMPLE_MASK; the values should match. */
  /* _NEW_BUFFERS, _NEW_MULTISAMPLE */
+#if (GEN_IS_HASWELL)
+ ps.SampleMask= 0xff;
+#endif
+ ps.SamplerCount  = 1;
   }
 
   uint32_t samples = pCreateInfo->pMultisampleState ?
-- 
2.5.5

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

[Mesa-dev] [PATCH 9/9] anv/gen7_pipeline: Check for ksp0 when setting BarycentricInterpolationMode in 3DSTATE_WM

[Anuj Phogat]

Signed-off-by: Anuj Phogat 
---
 src/intel/vulkan/gen7_pipeline.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/intel/vulkan/gen7_pipeline.c b/src/intel/vulkan/gen7_pipeline.c
index 4bab0bc..e804002 100644
--- a/src/intel/vulkan/gen7_pipeline.c
+++ b/src/intel/vulkan/gen7_pipeline.c
@@ -273,7 +273,8 @@ genX(graphics_pipeline_create)(
 wm.EarlyDepthStencilControl = EDSC_NORMAL;
  }
 
- wm.BarycentricInterpolationMode= 
wm_prog_data->barycentric_interp_modes;
+ wm.BarycentricInterpolationMode= pipeline->ps_ksp0 == 
NO_KERNEL ?
+  0 : 
wm_prog_data->barycentric_interp_modes;
 
  wm.MultisampleRasterizationMode= samples > 1 ?
   MSRASTMODE_ON_PATTERN : 
MSRASTMODE_OFF_PIXEL;
-- 
2.5.5

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

[Mesa-dev] [PATCH 7/9] anv/gen7_pipeline: Move ksp{1, 2} state setting next to ksp0

[Anuj Phogat]

Signed-off-by: Anuj Phogat 
---
 src/intel/vulkan/gen7_pipeline.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/src/intel/vulkan/gen7_pipeline.c b/src/intel/vulkan/gen7_pipeline.c
index f98aef5..9411631 100644
--- a/src/intel/vulkan/gen7_pipeline.c
+++ b/src/intel/vulkan/gen7_pipeline.c
@@ -208,6 +208,8 @@ genX(graphics_pipeline_create)(
 
   anv_batch_emit(>batch, GENX(3DSTATE_PS), ps) {
  ps.KernelStartPointer0   = pipeline->ps_ksp0;
+ ps.KernelStartPointer1   = 0;
+ ps.KernelStartPointer2   = pipeline->ps_ksp0 + 
wm_prog_data->prog_offset_2;
 
  ps.ScratchSpaceBasePointer = (struct anv_address) {
 .bo = anv_scratch_pool_alloc(device, >scratch_pool,
@@ -241,9 +243,6 @@ genX(graphics_pipeline_create)(
  /* Haswell requires the sample mask to be set in this packet as well 
as
   * in 3DSTATE_SAMPLE_MASK; the values should match. */
  /* _NEW_BUFFERS, _NEW_MULTISAMPLE */
-
- ps.KernelStartPointer1   = 0;
- ps.KernelStartPointer2   = pipeline->ps_ksp0 + 
wm_prog_data->prog_offset_2;
   }
 
   uint32_t samples = pCreateInfo->pMultisampleState ?
-- 
2.5.5

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

[Mesa-dev] [PATCH 1/9] intel/genxml: Fix typo in gen75.xml

[Anuj Phogat]

Signed-off-by: Anuj Phogat 
---
 src/intel/genxml/gen75.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/genxml/gen75.xml b/src/intel/genxml/gen75.xml
index 1debc3a..8e18007 100644
--- a/src/intel/genxml/gen75.xml
+++ b/src/intel/genxml/gen75.xml
@@ -1571,7 +1571,7 @@
   
 
 
-  
+  
   
 
 
-- 
2.5.5

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

[Mesa-dev] [PATCH 6/9] anv/gen7_pipeline: Set few missing fields in 3DSTATE_VS

[Anuj Phogat]

Signed-off-by: Anuj Phogat 
---
 src/intel/vulkan/gen7_pipeline.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/intel/vulkan/gen7_pipeline.c b/src/intel/vulkan/gen7_pipeline.c
index 8d133b6..f98aef5 100644
--- a/src/intel/vulkan/gen7_pipeline.c
+++ b/src/intel/vulkan/gen7_pipeline.c
@@ -121,6 +121,12 @@ genX(graphics_pipeline_create)(
  };
  vs.PerThreadScratchSpace  = 
scratch_space(_prog_data->base.base);
 
+ vs.FloatingPointMode  = vs_prog_data->base.base.use_alt_mode ?
+ Alternate : IEEE754;
+ vs.SamplerCount   = 0;
+ vs.BindingTableEntryCount =
+vs_prog_data->base.base.binding_table.size_bytes / 4;
+
  vs.DispatchGRFStartRegisterforURBData=
 vs_prog_data->base.base.dispatch_grf_start_reg;
 
-- 
2.5.5

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

[Mesa-dev] [PATCH 5/9] anv/gen7: Make use of local variable prog_data

[Anuj Phogat]

Signed-off-by: Anuj Phogat 
---
 src/mesa/drivers/dri/i965/gen7_vs_state.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/gen7_vs_state.c 
b/src/mesa/drivers/dri/i965/gen7_vs_state.c
index 57e0419..d3bd9fd 100644
--- a/src/mesa/drivers/dri/i965/gen7_vs_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_vs_state.c
@@ -42,7 +42,7 @@ upload_vs_state(struct brw_context *brw)
if (!brw->is_haswell && !brw->is_baytrail)
   gen7_emit_vs_workaround_flush(brw);
 
-   if (brw->vs.prog_data->base.base.use_alt_mode)
+   if (prog_data->base.use_alt_mode)
   floating_point_mode = GEN6_VS_FLOATING_POINT_MODE_ALT;
 
BEGIN_BATCH(6);
@@ -51,7 +51,7 @@ upload_vs_state(struct brw_context *brw)
OUT_BATCH(floating_point_mode |
 ((ALIGN(stage_state->sampler_count, 4)/4) <<
   GEN6_VS_SAMPLER_COUNT_SHIFT) |
- ((brw->vs.prog_data->base.base.binding_table.size_bytes / 4) <<
+ ((prog_data->base.binding_table.size_bytes / 4) <<
   GEN6_VS_BINDING_TABLE_ENTRY_COUNT_SHIFT));
 
if (prog_data->base.total_scratch) {
-- 
2.5.5

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

[Mesa-dev] [PATCH 3/9] anv/gen8_pipeline: Fix typo in semicolon

[Anuj Phogat]

Signed-off-by: Anuj Phogat 
---
 src/intel/vulkan/gen8_pipeline.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/vulkan/gen8_pipeline.c b/src/intel/vulkan/gen8_pipeline.c
index 030f71e..1abb97c 100644
--- a/src/intel/vulkan/gen8_pipeline.c
+++ b/src/intel/vulkan/gen8_pipeline.c
@@ -194,7 +194,7 @@ genX(graphics_pipeline_create)(
  vs.SamplerCount  = 0;
 
  vs.BindingTableEntryCount =
-vs_prog_data->base.base.binding_table.size_bytes / 4,
+vs_prog_data->base.base.binding_table.size_bytes / 4;
 
  vs.ThreadDispatchPriority= false;
  vs.FloatingPointMode = IEEE754;
-- 
2.5.5

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

[Mesa-dev] [PATCH 2/9] intel/genxml: Keep the value name 'Alternate' uniform across gen75.xml

[Anuj Phogat]

Signed-off-by: Anuj Phogat 
---
 src/intel/genxml/gen75.xml | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/intel/genxml/gen75.xml b/src/intel/genxml/gen75.xml
index 8e18007..b8f5a14 100644
--- a/src/intel/genxml/gen75.xml
+++ b/src/intel/genxml/gen75.xml
@@ -1365,7 +1365,7 @@
 
 
   
-  
+  
 
 
 
@@ -1436,7 +1436,7 @@
 
 
   
-  
+  
 
 
 
@@ -1572,7 +1572,7 @@
 
 
   
-  
+  
 
 
   
-- 
2.5.5

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

Re: [Mesa-dev] [PATCH] Revert "st/vdpau: use linear layout for output surfaces"

[Marek Olšák]

On Fri, Sep 30, 2016 at 11:23 PM, Dave Airlie  wrote:
> On 1 October 2016 at 06:11, Marek Olšák  wrote:
>> On Fri, Sep 30, 2016 at 4:42 PM, Ilia Mirkin  wrote:
>>> So is this getting pushed, or should I push my "don't build vdpau for
>>> nouveau" patch?
>>
>> Please wait.
>>
>> Christian, your commit says it fixes a radeonsi issue, but Ilia says
>> it breaks nouveau.
>>
>> Can we do something to accommodate both drivers? Should we add a CAP
>> for whether to use a linear layout for output surfaces?
>
> I think we need a flag that isn't SHARED/LINEAR that is more SHARED_OTHER_GPU.

That would be useless. Most OpenGL textures can be shared with other
GPUs and processes via the EGL dmabuf extensions. Relying on
PIPE_BIND_SHARED is a bug by itself and no driver should do that.

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

Re: [Mesa-dev] [PATCH] mesa: move _mesa_valid_to_render() to api_validate.c

[Anuj Phogat]

On Fri, Sep 30, 2016 at 2:21 PM, Brian Paul  wrote:

> Almost all of the other drawing validation code is in api_validate.c
> so put this function there as well.
> ---
>  src/mesa/main/api_validate.c | 191 ++
> -
>  src/mesa/main/api_validate.h |   3 +
>  src/mesa/main/context.c  | 188 +-
> 
>  src/mesa/main/context.h  |   3 -
>  src/mesa/main/drawpix.c  |   1 +
>  5 files changed, 195 insertions(+), 191 deletions(-)
>
> diff --git a/src/mesa/main/api_validate.c b/src/mesa/main/api_validate.c
> index 6cb626a..05691d2 100644
> --- a/src/mesa/main/api_validate.c
> +++ b/src/mesa/main/api_validate.c
> @@ -30,9 +30,198 @@
>  #include "context.h"
>  #include "imports.h"
>  #include "mtypes.h"
> +#include "pipelineobj.h"
>  #include "enums.h"
> -#include "vbo/vbo.h"
> +#include "state.h"
>  #include "transformfeedback.h"
> +#include "uniforms.h"
> +#include "vbo/vbo.h"
> +#include "program/prog_print.h"
> +
> +
> +static bool
> +check_blend_func_error(struct gl_context *ctx)
> +{
> +   /* The ARB_blend_func_extended spec's ERRORS section says:
> +*
> +*"The error INVALID_OPERATION is generated by Begin or any
> procedure
> +* that implicitly calls Begin if any draw buffer has a blend
> function
> +* requiring the second color input (SRC1_COLOR,
> ONE_MINUS_SRC1_COLOR,
> +* SRC1_ALPHA or ONE_MINUS_SRC1_ALPHA), and a framebuffer is bound
> that
> +* has more than the value of MAX_DUAL_SOURCE_DRAW_BUFFERS-1 active
> +* color attachements."
> +*/
> +   for (unsigned i = ctx->Const.MaxDualSourceDrawBuffers;
> +   i < ctx->DrawBuffer->_NumColorDrawBuffers;
> +   i++) {
> +  if (ctx->Color.Blend[i]._UsesDualSrc) {
> +_mesa_error(ctx, GL_INVALID_OPERATION,
> +"dual source blend on illegal attachment");
> +return false;
> +  }
> +   }
> +
> +   if (ctx->Color.BlendEnabled && ctx->Color._AdvancedBlendMode) {
> +  /* The KHR_blend_equation_advanced spec says:
> +   *
> +   *"If any non-NONE draw buffer uses a blend equation found in
> table
> +   * X.1 or X.2, the error INVALID_OPERATION is generated by
> Begin or
> +   * any operation that implicitly calls Begin (such as
> DrawElements)
> +   * if:
> +   *
> +   *   * the draw buffer for color output zero selects multiple
> color
> +   * buffers (e.g., FRONT_AND_BACK in the default
> framebuffer); or
> +   *
> +   *   * the draw buffer for any other color output is not NONE."
> +   */
> +  if (ctx->DrawBuffer->ColorDrawBuffer[0] == GL_FRONT_AND_BACK) {
> + _mesa_error(ctx, GL_INVALID_OPERATION,
> + "advanced blending is active and draw buffer for
> color "
> + "output zero selects multiple color buffers");
> + return false;
> +  }
> +
> +  for (unsigned i = 1; i < ctx->DrawBuffer->_NumColorDrawBuffers;
> i++) {
> + if (ctx->DrawBuffer->ColorDrawBuffer[i] != GL_NONE) {
> +_mesa_error(ctx, GL_INVALID_OPERATION,
> +"advanced blending is active with multiple color "
> +"draw buffers");
> +return false;
> + }
> +  }
> +
> +  /* The KHR_blend_equation_advanced spec says:
> +   *
> +   *"Advanced blending equations require the use of a fragment
> shader
> +   * with a matching "blend_support" layout qualifier.  If the
> current
> +   * blend equation is found in table X.1 or X.2, and the active
> +   * fragment shader does not include the layout qualifier
> matching
> +   * the blend equation or "blend_support_all_equations", the
> error
> +   * INVALID_OPERATION is generated [...]"
> +   */
> +  const struct gl_shader_program *sh_prog =
> + ctx->_Shader->_CurrentFragmentProgram;
> +  const GLbitfield blend_support = !sh_prog ? 0 :
> + sh_prog->_LinkedShaders[MESA_SHADER_FRAGMENT]->info.
> BlendSupport;
> +
> +  if ((blend_support & ctx->Color._AdvancedBlendMode) == 0) {
> + _mesa_error(ctx, GL_INVALID_OPERATION,
> + "fragment shader does not allow advanced blending
> mode "
> + "(%s)",
> +  _mesa_enum_to_string(ctx->
> Color.Blend[0].EquationRGB));
> +  }
> +   }
> +
> +   return true;
> +}
> +
> +
> +/**
> + * Prior to drawing anything with glBegin, glDrawArrays, etc. this
> function
> + * is called to see if it's valid to render.  This involves checking that
> + * the current shader is valid and the framebuffer is complete.
> + * It also check the current pipeline object is valid if any.
> + * If an error is detected it'll be recorded here.
> + * \return GL_TRUE if OK to render, GL_FALSE if not
> + */
> +GLboolean
> +_mesa_valid_to_render(struct gl_context *ctx, const 

Re: [Mesa-dev] [PATCH] Revert "st/vdpau: use linear layout for output surfaces"

[Dave Airlie]

On 1 October 2016 at 06:11, Marek Olšák  wrote:
> On Fri, Sep 30, 2016 at 4:42 PM, Ilia Mirkin  wrote:
>> So is this getting pushed, or should I push my "don't build vdpau for
>> nouveau" patch?
>
> Please wait.
>
> Christian, your commit says it fixes a radeonsi issue, but Ilia says
> it breaks nouveau.
>
> Can we do something to accommodate both drivers? Should we add a CAP
> for whether to use a linear layout for output surfaces?

I think we need a flag that isn't SHARED/LINEAR that is more SHARED_OTHER_GPU.

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

Re: [Mesa-dev] [PATCH v2 4/5] gallium/radeon: emit relocations for query fences

[Dieter Nützel]

Fixed all Blender issues on r600g/NI/Turks XT.

Apart from that that it's already committed you have my

Tb

Thank you Nicolai!

Dieter.

Am 30.09.2016 11:52, schrieb Nicolai Hähnle:

From: Nicolai Hähnle 

This is only needed for r600 which doesn't have ARB_query_buffer_object 
and
therefore wouldn't really need the fences, but let's be optimistic 
about

filling in this feature gap eventually.

Cc: Dieter Nützel 
---
 src/gallium/drivers/radeon/r600_pipe_common.c |  7 ++-
 src/gallium/drivers/radeon/r600_pipe_common.h |  2 +-
 src/gallium/drivers/radeon/r600_query.c   | 13 +++--
 src/gallium/drivers/radeonsi/si_perfcounter.c |  2 +-
 4 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c
b/src/gallium/drivers/radeon/r600_pipe_common.c
index e9377b2..6dc92cb 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.c
+++ b/src/gallium/drivers/radeon/r600_pipe_common.c
@@ -73,21 +73,21 @@ void radeon_shader_binary_clean(struct
radeon_shader_binary *b)
FREE(b->global_symbol_offsets);
FREE(b->relocs);
FREE(b->disasm_string);
FREE(b->llvm_ir_string);
 }

 /*
  * pipe_context
  */

-void r600_gfx_write_fence(struct r600_common_context *ctx,
+void r600_gfx_write_fence(struct r600_common_context *ctx, struct
r600_resource *buf,
  uint64_t va, uint32_t old_value, uint32_t new_value)
 {
struct radeon_winsys_cs *cs = ctx->gfx.cs;

if (ctx->chip_class == CIK) {
/* Two EOP events are required to make all engines go idle
 * (and optional cache flushes executed) before the timestamp
 * is written.
 */
radeon_emit(cs, PKT3(PKT3_EVENT_WRITE_EOP, 4, 0));
@@ -99,29 +99,34 @@ void r600_gfx_write_fence(struct 
r600_common_context *ctx,

radeon_emit(cs, 0); /* unused */
}

radeon_emit(cs, PKT3(PKT3_EVENT_WRITE_EOP, 4, 0));
radeon_emit(cs, EVENT_TYPE(EVENT_TYPE_BOTTOM_OF_PIPE_TS) |
EVENT_INDEX(5));
radeon_emit(cs, va);
radeon_emit(cs, (va >> 32) | EOP_DATA_SEL(1));
radeon_emit(cs, new_value); /* immediate data */
radeon_emit(cs, 0); /* unused */
+
+	r600_emit_reloc(ctx, >gfx, buf, RADEON_USAGE_WRITE, 
RADEON_PRIO_QUERY);

 }

 unsigned r600_gfx_write_fence_dwords(struct r600_common_screen 
*screen)

 {
unsigned dwords = 6;

if (screen->chip_class == CIK)
dwords *= 2;

+   if (!screen->info.has_virtual_memory)
+   dwords += 2;
+
return dwords;
 }

 void r600_gfx_wait_fence(struct r600_common_context *ctx,
 uint64_t va, uint32_t ref, uint32_t mask)
 {
struct radeon_winsys_cs *cs = ctx->gfx.cs;

radeon_emit(cs, PKT3(PKT3_WAIT_REG_MEM, 5, 0));
radeon_emit(cs, WAIT_REG_MEM_EQUAL | WAIT_REG_MEM_MEM_SPACE(1));
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.h
b/src/gallium/drivers/radeon/r600_pipe_common.h
index ec7f7c0..cdcc80b 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.h
+++ b/src/gallium/drivers/radeon/r600_pipe_common.h
@@ -696,21 +696,21 @@ struct pipe_resource *
r600_aligned_buffer_create(struct pipe_screen *screen,
  unsigned alignment);
 struct pipe_resource *
 r600_buffer_from_user_memory(struct pipe_screen *screen,
 const struct pipe_resource *templ,
 void *user_memory);
 void
 r600_invalidate_resource(struct pipe_context *ctx,
 struct pipe_resource *resource);

 /* r600_common_pipe.c */
-void r600_gfx_write_fence(struct r600_common_context *ctx,
+void r600_gfx_write_fence(struct r600_common_context *ctx, struct
r600_resource *buf,
  uint64_t va, uint32_t old_value, uint32_t new_value);
 unsigned r600_gfx_write_fence_dwords(struct r600_common_screen 
*screen);

 void r600_gfx_wait_fence(struct r600_common_context *ctx,
 uint64_t va, uint32_t ref, uint32_t mask);
 void r600_draw_rectangle(struct blitter_context *blitter,
 int x1, int y1, int x2, int y2, float depth,
 enum blitter_attrib_type type,
 const union pipe_color_union *attrib);
 bool r600_common_screen_init(struct r600_common_screen *rscreen,
 struct radeon_winsys *ws);
diff --git a/src/gallium/drivers/radeon/r600_query.c
b/src/gallium/drivers/radeon/r600_query.c
index 0908a6c..925c950 100644
--- a/src/gallium/drivers/radeon/r600_query.c
+++ b/src/gallium/drivers/radeon/r600_query.c
@@ -609,32 +609,32 @@ static void r600_query_hw_emit_start(struct
r600_common_context *ctx,

ctx->num_cs_dw_queries_suspend += query->num_cs_dw_end;
 }

 static void r600_query_hw_do_emit_stop(struct r600_common_context 

[Mesa-dev] [PATCH] mesa: move _mesa_valid_to_render() to api_validate.c

[Brian Paul]

Almost all of the other drawing validation code is in api_validate.c
so put this function there as well.
---
 src/mesa/main/api_validate.c | 191 ++-
 src/mesa/main/api_validate.h |   3 +
 src/mesa/main/context.c  | 188 +-
 src/mesa/main/context.h  |   3 -
 src/mesa/main/drawpix.c  |   1 +
 5 files changed, 195 insertions(+), 191 deletions(-)

diff --git a/src/mesa/main/api_validate.c b/src/mesa/main/api_validate.c
index 6cb626a..05691d2 100644
--- a/src/mesa/main/api_validate.c
+++ b/src/mesa/main/api_validate.c
@@ -30,9 +30,198 @@
 #include "context.h"
 #include "imports.h"
 #include "mtypes.h"
+#include "pipelineobj.h"
 #include "enums.h"
-#include "vbo/vbo.h"
+#include "state.h"
 #include "transformfeedback.h"
+#include "uniforms.h"
+#include "vbo/vbo.h"
+#include "program/prog_print.h"
+
+
+static bool
+check_blend_func_error(struct gl_context *ctx)
+{
+   /* The ARB_blend_func_extended spec's ERRORS section says:
+*
+*"The error INVALID_OPERATION is generated by Begin or any procedure
+* that implicitly calls Begin if any draw buffer has a blend function
+* requiring the second color input (SRC1_COLOR, ONE_MINUS_SRC1_COLOR,
+* SRC1_ALPHA or ONE_MINUS_SRC1_ALPHA), and a framebuffer is bound that
+* has more than the value of MAX_DUAL_SOURCE_DRAW_BUFFERS-1 active
+* color attachements."
+*/
+   for (unsigned i = ctx->Const.MaxDualSourceDrawBuffers;
+   i < ctx->DrawBuffer->_NumColorDrawBuffers;
+   i++) {
+  if (ctx->Color.Blend[i]._UsesDualSrc) {
+_mesa_error(ctx, GL_INVALID_OPERATION,
+"dual source blend on illegal attachment");
+return false;
+  }
+   }
+
+   if (ctx->Color.BlendEnabled && ctx->Color._AdvancedBlendMode) {
+  /* The KHR_blend_equation_advanced spec says:
+   *
+   *"If any non-NONE draw buffer uses a blend equation found in table
+   * X.1 or X.2, the error INVALID_OPERATION is generated by Begin or
+   * any operation that implicitly calls Begin (such as DrawElements)
+   * if:
+   *
+   *   * the draw buffer for color output zero selects multiple color
+   * buffers (e.g., FRONT_AND_BACK in the default framebuffer); or
+   *
+   *   * the draw buffer for any other color output is not NONE."
+   */
+  if (ctx->DrawBuffer->ColorDrawBuffer[0] == GL_FRONT_AND_BACK) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ "advanced blending is active and draw buffer for color "
+ "output zero selects multiple color buffers");
+ return false;
+  }
+
+  for (unsigned i = 1; i < ctx->DrawBuffer->_NumColorDrawBuffers; i++) {
+ if (ctx->DrawBuffer->ColorDrawBuffer[i] != GL_NONE) {
+_mesa_error(ctx, GL_INVALID_OPERATION,
+"advanced blending is active with multiple color "
+"draw buffers");
+return false;
+ }
+  }
+
+  /* The KHR_blend_equation_advanced spec says:
+   *
+   *"Advanced blending equations require the use of a fragment shader
+   * with a matching "blend_support" layout qualifier.  If the current
+   * blend equation is found in table X.1 or X.2, and the active
+   * fragment shader does not include the layout qualifier matching
+   * the blend equation or "blend_support_all_equations", the error
+   * INVALID_OPERATION is generated [...]"
+   */
+  const struct gl_shader_program *sh_prog =
+ ctx->_Shader->_CurrentFragmentProgram;
+  const GLbitfield blend_support = !sh_prog ? 0 :
+ sh_prog->_LinkedShaders[MESA_SHADER_FRAGMENT]->info.BlendSupport;
+
+  if ((blend_support & ctx->Color._AdvancedBlendMode) == 0) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ "fragment shader does not allow advanced blending mode "
+ "(%s)",
+  _mesa_enum_to_string(ctx->Color.Blend[0].EquationRGB));
+  }
+   }
+
+   return true;
+}
+
+
+/**
+ * Prior to drawing anything with glBegin, glDrawArrays, etc. this function
+ * is called to see if it's valid to render.  This involves checking that
+ * the current shader is valid and the framebuffer is complete.
+ * It also check the current pipeline object is valid if any.
+ * If an error is detected it'll be recorded here.
+ * \return GL_TRUE if OK to render, GL_FALSE if not
+ */
+GLboolean
+_mesa_valid_to_render(struct gl_context *ctx, const char *where)
+{
+   /* This depends on having up to date derived state (shaders) */
+   if (ctx->NewState)
+  _mesa_update_state(ctx);
+
+   if (ctx->API == API_OPENGL_COMPAT) {
+  /* Any shader stages that are not supplied by the GLSL shader and have
+   * assembly shaders enabled must now be validated.
+   */
+  if 

Re: [Mesa-dev] [PATCH] vl/dri3: handle the case of different GPU(v4.1)

[Axel Davy]

On 16/09/2016 14:51, Nayan Deshmukh wrote:
  
 bool flushed;

+   bool is_different_gpu;
  };
  


I get a warning when I build about incompatible pointer type at the line

fd = loader_get_user_preferred_fd(fd, >is_different_gpu);

When compiling on 32 bits.

I get this should be int.


Axel

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

Re: [Mesa-dev] [PATCH] Revert "st/vdpau: use linear layout for output surfaces"

[Marek Olšák]

On Fri, Sep 30, 2016 at 4:42 PM, Ilia Mirkin  wrote:
> So is this getting pushed, or should I push my "don't build vdpau for
> nouveau" patch?

Please wait.

Christian, your commit says it fixes a radeonsi issue, but Ilia says
it breaks nouveau.

Can we do something to accommodate both drivers? Should we add a CAP
for whether to use a linear layout for output surfaces?

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

[Mesa-dev] [PATCH] anv/formats: Fix build on gcc-4 and earlier

[ville . syrjala]

From: Ville Syrjälä 

gcc-4 and earlier don't allow compound literals where a constant
is required in -std=c99/gnu99 mode, so we can't use ISL_SWIZZLE()
when populating the anv_formats[] array. There are a few ways around
it: First one would be -std=c89/gnu89, but the rest of the code
depends on c99 so it's not really an option. The second option
would be to upgrade to gcc-5+ where the compiler behaviour was relaxed
a bit [1]. And the third option is just to avoid using compound
literals. I chose the last option since it keeps gcc-4 and earlier
working.

[1] https://gcc.gnu.org/gcc-5/porting_to.html

Cc: Jason Ekstrand 
Cc: Topi Pohjolainen 
Fixes: 7ddb21708c80 ("intel/isl: Add an isl_swizzle structure and use it for 
isl_view swizzles")
Signed-off-by: Ville Syrjälä 
---
 src/intel/vulkan/anv_formats.c | 23 +++
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/src/intel/vulkan/anv_formats.c b/src/intel/vulkan/anv_formats.c
index 7341d725cd0a..f6915540fb3d 100644
--- a/src/intel/vulkan/anv_formats.c
+++ b/src/intel/vulkan/anv_formats.c
@@ -24,9 +24,24 @@
 #include "anv_private.h"
 #include "vk_format_info.h"
 
-#define RGBA ISL_SWIZZLE(RED, GREEN, BLUE, ALPHA)
-#define BGRA ISL_SWIZZLE(BLUE, GREEN, RED, ALPHA)
-#define RGB1 ISL_SWIZZLE(RED, GREEN, BLUE, ONE)
+/*
+ * gcc-4 and earlier don't allow compound literals where a constant
+ * is required in -std=c99/gnu99 mode, so we can't use ISL_SWIZZLE()
+ * here. -std=c89/gnu89 would allow it, but we depend on c99 features
+ * so using -std=c89/gnu89 is not an option. Starting from gcc-5
+ * compound literals can also be considered constant in -std=c99/gnu99
+ * mode.
+ */
+#define _ISL_SWIZZLE(r, g, b, a) { \
+  ISL_CHANNEL_SELECT_##r, \
+  ISL_CHANNEL_SELECT_##g, \
+  ISL_CHANNEL_SELECT_##b, \
+  ISL_CHANNEL_SELECT_##a, \
+}
+
+#define RGBA _ISL_SWIZZLE(RED, GREEN, BLUE, ALPHA)
+#define BGRA _ISL_SWIZZLE(BLUE, GREEN, RED, ALPHA)
+#define RGB1 _ISL_SWIZZLE(RED, GREEN, BLUE, ONE)
 
 #define swiz_fmt(__vk_fmt, __hw_fmt, __swizzle) \
[__vk_fmt] = { \
@@ -276,7 +291,7 @@ anv_get_format(const struct gen_device_info *devinfo, 
VkFormat vk_format,
  format.isl_format = rgbx;
   } else {
  format.isl_format = isl_format_rgb_to_rgba(format.isl_format);
- format.swizzle = RGB1;
+ format.swizzle = ISL_SWIZZLE(RED, GREEN, BLUE, ONE);
   }
}
 
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH] Revert "gallium/hud: automatically print % if max_value == 100"

[Brian Paul]

On 09/30/2016 12:17 PM, Marek Olšák wrote:

From: Marek Olšák 

This reverts commit dbfeb0ec12d6550e68de1bcd164e422e79bccf2d.

With max_value being rounded to 100, it's often wrong.


Yeah, I noticed that too.

Reviewed-by: Brian Paul 


---
  src/gallium/auxiliary/hud/hud_context.c | 18 ++
  1 file changed, 6 insertions(+), 12 deletions(-)

diff --git a/src/gallium/auxiliary/hud/hud_context.c 
b/src/gallium/auxiliary/hud/hud_context.c
index 3445488..31e81f0 100644
--- a/src/gallium/auxiliary/hud/hud_context.c
+++ b/src/gallium/auxiliary/hud/hud_context.c
@@ -238,22 +238,22 @@ hud_draw_string(struct hud_context *hud, unsigned x, 
unsigned y,
vertices[num++] = (float) ty1;

x += hud->font.glyph_width;
s++;
 }

 hud->text.num_vertices += num/4;
  }

  static void
-number_to_human_readable(uint64_t num, uint64_t max_value,
- enum pipe_driver_query_type type, char *out)
+number_to_human_readable(uint64_t num, enum pipe_driver_query_type type,
+ char *out)
  {
 static const char *byte_units[] =
{" B", " KB", " MB", " GB", " TB", " PB", " EB"};
 static const char *metric_units[] =
{"", " k", " M", " G", " T", " P", " E"};
 static const char *time_units[] =
{" us", " ms", " s"};  /* based on microseconds */
 static const char *hz_units[] =
{" Hz", " KHz", " MHz", " GHz"};
 static const char *percent_units[] = {"%"};
@@ -300,27 +300,22 @@ number_to_human_readable(uint64_t num, uint64_t max_value,
break;
 case PIPE_DRIVER_QUERY_TYPE_HZ:
max_unit = ARRAY_SIZE(hz_units)-1;
units = hz_units;
break;
 case PIPE_DRIVER_QUERY_TYPE_WATTS:
max_unit = ARRAY_SIZE(watt_units)-1;
units = watt_units;
break;
 default:
-  if (max_value == 100) {
- max_unit = ARRAY_SIZE(percent_units)-1;
- units = percent_units;
-  } else {
- max_unit = ARRAY_SIZE(metric_units)-1;
- units = metric_units;
-  }
+  max_unit = ARRAY_SIZE(metric_units)-1;
+  units = metric_units;
 }

 while (d > divisor && unit < max_unit) {
d /= divisor;
unit++;
 }

 /* Round to 3 decimal places so as not to print trailing zeros. */
 if (d*1000 != (int)(d*1000))
d = round(d * 1000) / 1000;
@@ -376,33 +371,32 @@ hud_pane_accumulate_vertices(struct hud_context *hud,
  pane->x1, pane->y1,
  pane->x2, pane->y2);

 /* draw numbers on the right-hand side */
 for (i = 0; i <= last_line; i++) {
unsigned x = pane->x2 + 2;
unsigned y = pane->inner_y1 +
 pane->inner_height * (last_line - i) / last_line -
 hud->font.glyph_height / 2;

-  number_to_human_readable(pane->max_value * i / last_line, 
pane->max_value,
+  number_to_human_readable(pane->max_value * i / last_line,
 pane->type, str);
hud_draw_string(hud, x, y, "%s", str);
 }

 /* draw info below the pane */
 i = 0;
 LIST_FOR_EACH_ENTRY(gr, >graph_list, head) {
unsigned x = pane->x1 + 2;
unsigned y = pane->y2 + 2 + i*hud->font.glyph_height;

-  number_to_human_readable(gr->current_value, pane->max_value,
-   pane->type, str);
+  number_to_human_readable(gr->current_value, pane->type, str);
hud_draw_string(hud, x, y, "  %s: %s", gr->name, str);
i++;
 }

 /* draw border */
 assert(hud->whitelines.num_vertices + num/2 + 8 <= 
hud->whitelines.max_num_vertices);
 line_verts[num++] = (float) pane->x1;
 line_verts[num++] = (float) pane->y1;
 line_verts[num++] = (float) pane->x2;
 line_verts[num++] = (float) pane->y1;



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

Re: [Mesa-dev] [Mesa-stable] [PATCH v2] egl: stop claiming support for pbuffer + msaa

[Ian Romanick]

On 09/30/2016 06:00 AM, Emil Velikov wrote:
> On 30 September 2016 at 07:32, Tapani Pälli  wrote:
>> This fixes a crash in egl-create-msaa-pbuffer-surface Piglit test
>> and same crash in many dEQP EGL tests.
>>
>> I also found that some Qt example did a workaround because of this
>> crash: https://bugreports.qt.io/browse/QTBUG-47509
>>
>> v2: Ian pointed out that v1 removed support for all multisample
>> configs, including window ones. This one removes pbuffer bit
>> when adding configs, now only pbuffer+msaa gets rejected and
>> window+msaa continues to work. Fixed also comment (Emil)
>>
>> Signed-off-by: Tapani Pälli 
>> Cc: mesa-sta...@lists.freedesktop.org
>> ---
>>  src/egl/drivers/dri2/egl_dri2.c | 9 +
>>  1 file changed, 9 insertions(+)
>>
>> diff --git a/src/egl/drivers/dri2/egl_dri2.c 
>> b/src/egl/drivers/dri2/egl_dri2.c
>> index 8e376e3..803627d 100644
>> --- a/src/egl/drivers/dri2/egl_dri2.c
>> +++ b/src/egl/drivers/dri2/egl_dri2.c
>> @@ -320,6 +320,15 @@ dri2_add_config(_EGLDisplay *disp, const __DRIconfig 
>> *dri_config, int id,
>>surface_type &= ~EGL_PIXMAP_BIT;
>> }
>>
>> +   /* No support for pbuffer + MSAA for now.
>> +*
>> +* XXX TODO: pbuffer + MSAA does not work and causes crashes.
>> +* See QT bugreport: https://bugreports.qt.io/browse/QTBUG-47509
>> +*/
>> +   if (base.Samples) {
>> +  surface_type &= ~EGL_PBUFFER_BIT;
>> +   }
>> +
> I'm slightly cautious if this won't cause unexpected side effects (due
> to _eglFilterArray() and/or other interaction), so let's have this
> soak in master for a bit before picking to stable.

That's sensible.

> That aside the patch is (for real this time)
> Reviewed-by: Emil Velikov 

Also

Reviewed-by: Ian Romanick 

> Before pushing please double-check that piglit/deqp/cts doesn't get upset.
> 
> Thanks
> Emil
> ___
> mesa-stable mailing list
> mesa-sta...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-stable

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

[Mesa-dev] [PATCH] autoconf: Make header install distinct for various APIs

[Chuck Atkins]

This fixes a problem where GL headers would only get installed if
glx was enabled.  So if osmesa was enabled but not glx, then the
GL headers required by osmesa would be missing from the install.

Signed-off-by: Chuck Atkins 
---
 configure.ac|  2 ++
 src/Makefile.am | 30 ++
 src/gallium/Makefile.am |  2 ++
 src/mesa/Makefile.am| 12 ++--
 4 files changed, 36 insertions(+), 10 deletions(-)

diff --git a/configure.ac b/configure.ac
index 1bfac3b..c7be735 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2641,6 +2641,8 @@ fi
 AM_CONDITIONAL(HAVE_LIBDRM, test "x$have_libdrm" = xyes)
 AM_CONDITIONAL(HAVE_OSMESA, test "x$enable_osmesa" = xyes)
 AM_CONDITIONAL(HAVE_GALLIUM_OSMESA, test "x$enable_gallium_osmesa" = xyes)
+AM_CONDITIONAL(HAVE_COMMON_OSMESA, test "x$enable_osmesa" = xyes -o \
+"x$enable_gallium_osmesa" = xyes)
 
 AM_CONDITIONAL(HAVE_X86_ASM, test "x$asm_arch" = xx86 -o "x$asm_arch" = 
xx86_64)
 AM_CONDITIONAL(HAVE_X86_64_ASM, test "x$asm_arch" = xx86_64)
diff --git a/src/Makefile.am b/src/Makefile.am
index 551f431..c04ee1b 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -47,6 +47,36 @@ CLEANFILES = $(BUILT_SOURCES)
 
 SUBDIRS = . gtest util mapi/glapi/gen mapi
 
+if HAVE_OPENGL
+gldir = $(includedir)/GL
+gl_HEADERS = \
+  $(top_srcdir)/include/GL/gl.h \
+  $(top_srcdir)/include/GL/glext.h \
+  $(top_srcdir)/include/GL/glcorearb.h \
+  $(top_srcdir)/include/GL/gl_mangle.h
+endif
+
+if HAVE_GLX
+glxdir = $(includedir)/GL
+glx_HEADERS = \
+  $(top_srcdir)/include/GL/glx.h \
+  $(top_srcdir)/include/GL/glxext.h \
+  $(top_srcdir)/include/GL/glx_mangle.h \
+  $(top_srcdir)/include/GL/mesa_glinterop.h
+pkgconfigdir = $(libdir)/pkgconfig
+pkgconfig_DATA = mesa/gl.pc
+else
+if HAVE_EGL
+eglinteropdir = $(includedir)/GL
+eglinterop_HEADERS = $(top_srcdir)/include/GL/mesa_glinterop.h
+endif
+endif
+
+if HAVE_COMMON_OSMESA
+osmesadir = $(includedir)/GL
+osmesa_HEADERS = $(top_srcdir)/include/GL/osmesa.h
+endif
+
 # include only conditionally ?
 SUBDIRS += compiler
 
diff --git a/src/gallium/Makefile.am b/src/gallium/Makefile.am
index 34671ca..caf5fd8 100644
--- a/src/gallium/Makefile.am
+++ b/src/gallium/Makefile.am
@@ -148,6 +148,8 @@ endif
 
 if HAVE_GALLIUM_OSMESA
 SUBDIRS += state_trackers/osmesa targets/osmesa
+osmesadir = $(includedir)/GL
+osmesa_HEADERS = $(top_srcdir)/include/GL/osmesa.h
 endif
 
 if HAVE_ST_VA
diff --git a/src/mesa/Makefile.am b/src/mesa/Makefile.am
index 037384a..22db400 100644
--- a/src/mesa/Makefile.am
+++ b/src/mesa/Makefile.am
@@ -31,11 +31,8 @@ endif
 
 if HAVE_OSMESA
 SUBDIRS += drivers/osmesa
-endif
-
-if HAVE_GLX
-gldir = $(includedir)/GL
-gl_HEADERS = $(top_srcdir)/include/GL/*.h
+osmesadir = $(includedir)/GL
+osmesa_HEADERS = $(top_srcdir)/include/GL/osmesa.h
 endif
 
 include Makefile.sources
@@ -161,11 +158,6 @@ libmesa_sse41_la_SOURCES = \
 
 libmesa_sse41_la_CFLAGS = $(AM_CFLAGS) $(SSE41_CFLAGS)
 
-if HAVE_GLX
-pkgconfigdir = $(libdir)/pkgconfig
-pkgconfig_DATA = gl.pc
-endif
-
 MKDIR_GEN = $(AM_V_at)$(MKDIR_P) $(@D)
 YACC_GEN = $(AM_V_GEN)$(YACC) $(YFLAGS)
 LEX_GEN = $(AM_V_GEN)$(LEX) $(LFLAGS)
-- 
2.7.4

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

[Mesa-dev] [PATCH] Revert "gallium/hud: automatically print % if max_value == 100"

[Marek Olšák]

From: Marek Olšák 

This reverts commit dbfeb0ec12d6550e68de1bcd164e422e79bccf2d.

With max_value being rounded to 100, it's often wrong.
---
 src/gallium/auxiliary/hud/hud_context.c | 18 ++
 1 file changed, 6 insertions(+), 12 deletions(-)

diff --git a/src/gallium/auxiliary/hud/hud_context.c 
b/src/gallium/auxiliary/hud/hud_context.c
index 3445488..31e81f0 100644
--- a/src/gallium/auxiliary/hud/hud_context.c
+++ b/src/gallium/auxiliary/hud/hud_context.c
@@ -238,22 +238,22 @@ hud_draw_string(struct hud_context *hud, unsigned x, 
unsigned y,
   vertices[num++] = (float) ty1;
 
   x += hud->font.glyph_width;
   s++;
}
 
hud->text.num_vertices += num/4;
 }
 
 static void
-number_to_human_readable(uint64_t num, uint64_t max_value,
- enum pipe_driver_query_type type, char *out)
+number_to_human_readable(uint64_t num, enum pipe_driver_query_type type,
+ char *out)
 {
static const char *byte_units[] =
   {" B", " KB", " MB", " GB", " TB", " PB", " EB"};
static const char *metric_units[] =
   {"", " k", " M", " G", " T", " P", " E"};
static const char *time_units[] =
   {" us", " ms", " s"};  /* based on microseconds */
static const char *hz_units[] =
   {" Hz", " KHz", " MHz", " GHz"};
static const char *percent_units[] = {"%"};
@@ -300,27 +300,22 @@ number_to_human_readable(uint64_t num, uint64_t max_value,
   break;
case PIPE_DRIVER_QUERY_TYPE_HZ:
   max_unit = ARRAY_SIZE(hz_units)-1;
   units = hz_units;
   break;
case PIPE_DRIVER_QUERY_TYPE_WATTS:
   max_unit = ARRAY_SIZE(watt_units)-1;
   units = watt_units;
   break;
default:
-  if (max_value == 100) {
- max_unit = ARRAY_SIZE(percent_units)-1;
- units = percent_units;
-  } else {
- max_unit = ARRAY_SIZE(metric_units)-1;
- units = metric_units;
-  }
+  max_unit = ARRAY_SIZE(metric_units)-1;
+  units = metric_units;
}
 
while (d > divisor && unit < max_unit) {
   d /= divisor;
   unit++;
}
 
/* Round to 3 decimal places so as not to print trailing zeros. */
if (d*1000 != (int)(d*1000))
   d = round(d * 1000) / 1000;
@@ -376,33 +371,32 @@ hud_pane_accumulate_vertices(struct hud_context *hud,
 pane->x1, pane->y1,
 pane->x2, pane->y2);
 
/* draw numbers on the right-hand side */
for (i = 0; i <= last_line; i++) {
   unsigned x = pane->x2 + 2;
   unsigned y = pane->inner_y1 +
pane->inner_height * (last_line - i) / last_line -
hud->font.glyph_height / 2;
 
-  number_to_human_readable(pane->max_value * i / last_line, 
pane->max_value,
+  number_to_human_readable(pane->max_value * i / last_line,
pane->type, str);
   hud_draw_string(hud, x, y, "%s", str);
}
 
/* draw info below the pane */
i = 0;
LIST_FOR_EACH_ENTRY(gr, >graph_list, head) {
   unsigned x = pane->x1 + 2;
   unsigned y = pane->y2 + 2 + i*hud->font.glyph_height;
 
-  number_to_human_readable(gr->current_value, pane->max_value,
-   pane->type, str);
+  number_to_human_readable(gr->current_value, pane->type, str);
   hud_draw_string(hud, x, y, "  %s: %s", gr->name, str);
   i++;
}
 
/* draw border */
assert(hud->whitelines.num_vertices + num/2 + 8 <= 
hud->whitelines.max_num_vertices);
line_verts[num++] = (float) pane->x1;
line_verts[num++] = (float) pane->y1;
line_verts[num++] = (float) pane->x2;
line_verts[num++] = (float) pane->y1;
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH] swr: Removed stalling SwrWaitForIdle from queries.

[Kyriazis, George]

Reviewed-by: George Kyriazis 
>



From: Bruce Cherniak >
Subject: [PATCH] swr: Removed stalling SwrWaitForIdle from queries.
Date: September 27, 2016 at 1:27:08 PM CDT
To: >
Cc: Bruce Cherniak >

Previous fundamental change in stats gathering added a temporary
SwrWaitForIdle to begin_query and end_query.  Code has been reworked to
remove stall.
---
src/gallium/drivers/swr/swr_context.cpp |  33 +++
src/gallium/drivers/swr/swr_context.h   |  11 ++-
src/gallium/drivers/swr/swr_query.cpp   | 152 +---
src/gallium/drivers/swr/swr_query.h |  10 +--
4 files changed, 87 insertions(+), 119 deletions(-)

diff --git a/src/gallium/drivers/swr/swr_context.cpp 
b/src/gallium/drivers/swr/swr_context.cpp
index 15e60cd..cbc60e0 100644
--- a/src/gallium/drivers/swr/swr_context.cpp
+++ b/src/gallium/drivers/swr/swr_context.cpp
@@ -24,6 +24,7 @@
#include "util/u_memory.h"
#include "util/u_inlines.h"
#include "util/u_format.h"
+#include "util/u_atomic.h"

extern "C" {
#include "util/u_transfer.h"
@@ -352,9 +353,9 @@ swr_UpdateStats(HANDLE hPrivateContext, const SWR_STATS 
*pStats)
   if (!pDC)
  return;

-   struct swr_context *ctx = (struct swr_context *)pDC->swr_ctx;
+   struct swr_query_result *pqr = (struct swr_query_result *)pDC->pStats;

-   SWR_STATS *pSwrStats = >stats;
+   SWR_STATS *pSwrStats = >core;

   pSwrStats->DepthPassCount += pStats->DepthPassCount;
   pSwrStats->PsInvocations += pStats->PsInvocations;
@@ -369,22 +370,24 @@ swr_UpdateStatsFE(HANDLE hPrivateContext, const 
SWR_STATS_FE *pStats)
   if (!pDC)
  return;

-   struct swr_context *ctx = (struct swr_context *)pDC->swr_ctx;
+   struct swr_query_result *pqr = (struct swr_query_result *)pDC->pStats;

-   SWR_STATS_FE *pSwrStats = >statsFE;
-   pSwrStats->IaVertices += pStats->IaVertices;
-   pSwrStats->IaPrimitives += pStats->IaPrimitives;
-   pSwrStats->VsInvocations += pStats->VsInvocations;
-   pSwrStats->HsInvocations += pStats->HsInvocations;
-   pSwrStats->DsInvocations += pStats->DsInvocations;
-   pSwrStats->GsInvocations += pStats->GsInvocations;
-   pSwrStats->CInvocations += pStats->CInvocations;
-   pSwrStats->CPrimitives += pStats->CPrimitives;
-   pSwrStats->GsPrimitives += pStats->GsPrimitives;
+   SWR_STATS_FE *pSwrStats = >coreFE;
+   p_atomic_add(>IaVertices, pStats->IaVertices);
+   p_atomic_add(>IaPrimitives, pStats->IaPrimitives);
+   p_atomic_add(>VsInvocations, pStats->VsInvocations);
+   p_atomic_add(>HsInvocations, pStats->HsInvocations);
+   p_atomic_add(>DsInvocations, pStats->DsInvocations);
+   p_atomic_add(>GsInvocations, pStats->GsInvocations);
+   p_atomic_add(>CInvocations, pStats->CInvocations);
+   p_atomic_add(>CPrimitives, pStats->CPrimitives);
+   p_atomic_add(>GsPrimitives, pStats->GsPrimitives);

   for (unsigned i = 0; i < 4; i++) {
-  pSwrStats->SoPrimStorageNeeded[i] += pStats->SoPrimStorageNeeded[i];
-  pSwrStats->SoNumPrimsWritten[i] += pStats->SoNumPrimsWritten[i];
+  p_atomic_add(>SoPrimStorageNeeded[i],
+pStats->SoPrimStorageNeeded[i]);
+  p_atomic_add(>SoNumPrimsWritten[i],
+pStats->SoNumPrimsWritten[i]);
   }
}

diff --git a/src/gallium/drivers/swr/swr_context.h 
b/src/gallium/drivers/swr/swr_context.h
index 6854d69..eecfe0d 100644
--- a/src/gallium/drivers/swr/swr_context.h
+++ b/src/gallium/drivers/swr/swr_context.h
@@ -92,7 +92,7 @@ struct swr_draw_context {
   float userClipPlanes[PIPE_MAX_CLIP_PLANES][4];

   SWR_SURFACE_STATE renderTargets[SWR_NUM_ATTACHMENTS];
-   void *swr_ctx;
+   void *pStats;
};

/* gen_llvm_types FINI */
@@ -159,9 +159,6 @@ struct swr_context {
   /* SWR private state - draw context */
   struct swr_draw_context swrDC;

-   SWR_STATS stats;
-   SWR_STATS_FE statsFE;
-
   unsigned dirty; /**< Mask of SWR_NEW_x flags */
};

@@ -172,11 +169,13 @@ swr_context(struct pipe_context *pipe)
}

static INLINE void
-swr_update_draw_context(struct swr_context *ctx)
+swr_update_draw_context(struct swr_context *ctx,
+  struct swr_query_result *pqr = nullptr)
{
   swr_draw_context *pDC =
  (swr_draw_context *)SwrGetPrivateContextState(ctx->swrContext);
-   ctx->swrDC.swr_ctx = ctx;
+   if (pqr)
+  ctx->swrDC.pStats = pqr;
   memcpy(pDC, >swrDC, sizeof(swr_draw_context));
}

diff --git a/src/gallium/drivers/swr/swr_query.cpp 
b/src/gallium/drivers/swr/swr_query.cpp
index c51c529..8bb0b16 100644
--- a/src/gallium/drivers/swr/swr_query.cpp
+++ b/src/gallium/drivers/swr/swr_query.cpp
@@ -71,48 +71,6 @@ swr_destroy_query(struct pipe_context *pipe, struct 
pipe_query *q)
}


-static void
-swr_gather_stats(struct pipe_context *pipe, struct swr_query *pq)
-{
-   struct swr_context *ctx = swr_context(pipe);
-
-   assert(pq->result);
-   struct swr_query_result 

Re: [Mesa-dev] [PATCH] HUD: Add support for block I/O, network I/O and lmsensor stats

[Steven Toth]

Hello Emil,

>> +AC_ARG_ENABLE([gallium-extra-hud],
>> +[AS_HELP_STRING([--enable-gallium-extra-hud],
>> +[enable HUD block/NIC I/O HUD stats support 
>> @<:@default=disabled@:>@])],
>> +[enable_gallium_extra_hud="$enableval"],
>> +[enable_gallium_extra_hud=no])
> Looking at some of your other patches makes me wonder. Is it worth
> having this as a list - (maybe?) rename it to s/enable/with/ and have
> the user provide a list of required parts - sensors, cpu freq, etc.
>
> I'm thinking of cases where extra deps come to play and having a
> toggle for each one will be insane :-\

Thank you for raising this.

Today we have something that's OK for now. I'm happy to adapt/adopt whatever
you think makes better sense.

> If having X separate bits in the extra-hud sounds like and overkill,
> how do you feel if we do
> --with/enable-gallium-extra-hud={all,without-sensors}

I'm OK with both extra bits AND all. However, while I prefer enable
extras by name, (block-io, network-io, sensors), in practice, because
these are largely non-default performance profiling tools, any
developer concerned with performance will simply compile with = all
(or the default - none). So, extra bits starts to feel redundant.

all = everything, and an opt-out for sensors? I'm good with this.

>
>> +AM_CONDITIONAL(HAVE_GALLIUM_EXTRA_HUD, test "x$enable_gallium_extra_hud" = 
>> xyes)
>> +if test "x$enable_gallium_extra_hud" = xyes ; then
>> +DEFINES="${DEFINES} -DHAVE_GALLIUM_EXTRA_HUD=1"
>> +fi
>> +
>> +#TODO: no pkgconfig .pc available for libsensors.
>> +#PKG_CHECK_MODULES([LIBSENSORS], [libsensors >= $LIBSENSORS_REQUIRED], 
>> [enable_lmsensors=yes], [enable_lmsensors=no])
>> +AC_ARG_ENABLE([lmsensors],
>> +[AS_HELP_STRING([--enable-lmsensors],
>> +[enable HUD lmsensor support @<:@default=disabled@:>@])],
>> +[enable_lmsensors="$enableval"],
>> +[enable_lmsensors=no])
>> +AM_CONDITIONAL(HAVE_LIBSENSORS, test "x$enable_lmsensors" = xyes)
>> +if test "x$enable_lmsensors" = xyes ; then
>> +DEFINES="${DEFINES} -DHAVE_LIBSENSORS=1"
>> +LIBSENSORS_LDFLAGS="-lsensors"
>> +else
>> +LIBSENSORS_LDFLAGS=""
>> +fi
>> +AC_SUBST(LIBSENSORS_LDFLAGS)
> You want the LIBS variable, LDFLAGS is something else.

Ahh. hmm, OK. I'll look into this.

>
>
>>  endif
>>
>> +libgallium_la_LDFLAGS = $(LIBSENSORS_LDFLAGS)
>> +
> Please add the new variable to GALLIUM_COMMON_LIB_DEPS (in
> src/gallium/Automake.inc)

OK.

>
>
>> +
>> +#define LOCAL_DEBUG 0
>> +
> This and the related debugging code does not seem too useful past the
> development stage. Can we nuke it, please ?

Agreed.

-- 
Steven Toth - Kernel Labs
http://www.kernellabs.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] glx: rename choose_visual(), drop const argument

[Ian Romanick]

On 09/30/2016 03:01 AM, Emil Velikov wrote:
> From: Emil Velikov 
> 
> The function deals with fb (style) configs, thus using "visual"
> in the name is misleading. Which in itself had led to the use of
> fbconfig_style_tags argument.
> 
> Rename the function to reflect what it does and drop the unneeded
> argument.
> 
> Signed-off-by: Emil Velikov 
> ---
>  src/glx/glxcmds.c | 26 +++---
>  1 file changed, 11 insertions(+), 15 deletions(-)
> 
> diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
> index 8191da0..21fdd7a 100644
> --- a/src/glx/glxcmds.c
> +++ b/src/glx/glxcmds.c
> @@ -1162,8 +1162,8 @@ fbconfig_compare(struct glx_config **a, struct 
> glx_config **b)
>  
>  /**
>   * Selects and sorts a subset of the supplied configs based on the 
> attributes.
> - * This function forms to basis of \c glXChooseVisual, \c glXChooseFBConfig,
> - * and \c glXChooseFBConfigSGIX.
> + * This function forms to basis of \c glXChooseFBConfig and
> + * \c glXChooseFBConfigSGIX.
>   *
>   * \param configs   Array of pointers to possible configs.  The elements of
>   *  this array that do not meet the criteria will be set to
> @@ -1171,20 +1171,16 @@ fbconfig_compare(struct glx_config **a, struct 
> glx_config **b)
>   *  the various visual / FBConfig selection rules.
>   * \param num_configs  Number of elements in the \c configs array.
>   * \param attribList   Attributes used select from \c configs.  This array is
> - * terminated by a \c None tag.  The array can either 
> take
> - * the form expected by \c glXChooseVisual (where boolean
> - * tags do not have a value) or by \c glXChooseFBConfig
> - * (where every tag has a value).
> - * \param fbconfig_style_tags  Selects whether \c attribList is in
> - * \c glXChooseVisual style or
> - * \c glXChooseFBConfig style.

That is weird.  I did a lot of archaeology on this... and I can't see
that this parameter was *ever* passed anything other than GL_TRUE.  The
other places that call init_fbconfig_for_chooser and
__GlXInitializeVisualConfigFromTags also pass literal values for the
last parameter.  Not sure what I was thinking when I wrote that code...

Series is

Reviewed-by: Ian Romanick 

I'd also review a series that converts a bunch of the GLboolean nonsense
to bool. :)

> + * terminated by a \c None tag.  The array is of the form
> + * expected by \c glXChooseFBConfig (where every tag has 
> a
> + * value).
>   * \returns The number of valid elements left in \c configs.
>   *
> - * \sa glXChooseVisual, glXChooseFBConfig, glXChooseFBConfigSGIX
> + * \sa glXChooseFBConfig, glXChooseFBConfigSGIX
>   */
>  static int
> -choose_visual(struct glx_config ** configs, int num_configs,
> -  const int *attribList, GLboolean fbconfig_style_tags)
> +choose_fbconfig(struct glx_config ** configs, int num_configs,
> +  const int *attribList)
>  {
> struct glx_config test_config;
> int base;
> @@ -1196,10 +1192,10 @@ choose_visual(struct glx_config ** configs, int 
> num_configs,
>  * list.
>  */
>  
> -   init_fbconfig_for_chooser(_config, fbconfig_style_tags);
> +   init_fbconfig_for_chooser(_config, GL_TRUE);
> __glXInitializeVisualConfigFromTags(_config, 512,
> (const INT32 *) attribList,
> -   GL_TRUE, fbconfig_style_tags);
> +   GL_TRUE, GL_TRUE);
>  
> base = 0;
> for (i = 0; i < num_configs; i++) {
> @@ -1613,7 +1609,7 @@ glXChooseFBConfig(Display * dpy, int screen,
>glXGetFBConfigs(dpy, screen, _size);
>  
> if ((config_list != NULL) && (list_size > 0) && (attribList != NULL)) {
> -  list_size = choose_visual(config_list, list_size, attribList, GL_TRUE);
> +  list_size = choose_fbconfig(config_list, list_size, attribList);
>if (list_size == 0) {
>   free(config_list);
>   config_list = NULL;
> 

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

Re: [Mesa-dev] Mesa 13.0.0 release plan (Was Re: Mesa 12.1.0 release plan (Was Re: Next Mesa release, anyone?))

[Jason Ekstrand]

On Sep 30, 2016 7:57 AM, "Ian Romanick"  wrote:
>
> On 09/30/2016 06:23 AM, Brian Paul wrote:
> > On 09/30/2016 04:59 AM, Emil Velikov wrote:
> >> On 30 September 2016 at 03:31, Timothy Arceri
> >>  wrote:
> >>> On Thu, 2016-09-29 at 19:17 -0700, Jason Ekstrand wrote:
> >>>
> >>> On Sep 29, 2016 5:14 PM, "Timothy Arceri" <
timothy.arc...@collabora.com>
> >>> wrote:
> 
>  On Thu, 2016-09-29 at 15:56 +0100, Emil Velikov wrote:
> > On 28 September 2016 at 19:53, Marek Olšák  wrote:
> >>
> >> Hi,
> >>
> >> It's been almost 4 months since the 12.0 branch was created, and
> >> soon
> >> it will have been 3 months since Mesa 12.0 was released.
> >>
> >> Is there any reason we haven't created the stable branch yet?
> >>
> >> Ideally, we would time the release so that it's 1-2 months before
> >> fall
> >> distribution releases.
> >>
> >
> > Thanks Marek !
> >
> > In all honesty I was secretly hoping that we'll get Dave/Bas RADV
for
> > 12.1.
> 
>  I believe the release should be 13?? Core Mesa and the Intel driver
>  have reached 4.4 this release also core Mesa is now at 4.5 despite
not
>  being enabled anywhere.
> >>>
> >>> My personal preference, for whatever it's worth, would be to call it
> >>> 12.1.
> >>> The 12.0 release was the biggest release we've had in a long time and
it
> >>> seems odd to me to jump to 13.0 right away when we really haven't
> >>> done much
> >>> at all in terms of new features. (I think it's only 2 or 3 desktop
> >>> features
> >>> in the case of Intel.  A bit more on the ES side I guess).
> >>>
> >>>
> >>> My understanding is the major version has only ever been bumped when
> >>> full
> >>> support for a new desktop OpenGL version has been reached regardless
> >>> of the
> >>> number of extensions enabled. We did the same thing going from 8.0 >
9.0
> >>> were as the 7 release went all the way to 7.11 over a 4 year period.
It
> >>> seems odd to change the way we bump versions at this point in time,
> >>> although
> >>> in future maybe it will need to be based on Vulkin versions also.
> >>>
> >> Brain freeze - seem to miss-remember that enhanced layouts (thus 4.4)
> >> landed after the branch point.
> >> That plus the ES3.1/ES3.2, compat for the desktop GL, (by Ilia/Ken)
> >> does take us to 13.0.
> >>
> >> At the end of the day it's just a number albeit being the "unlucky"
one.
> >>
> >> If we get a consensus amongst the majority of devs we can change the
> >> versioning scheme. But for that let's do so in a ~weeks time - after
> >> the branchpoint.
> >
> > I'd say to go to 13.0 if we're now supporting GL 4.4.  That'd follow the
> > general pattern.
>
> I agree.  The only question is what we do after GL 4.5 bumps us to 14.0.
>  There is a distinct possibility (spoiler alert) that there won't be any
> new OpenGL version for a long time, if ever.  Will we be stuck at 14.x
> forever? :)

I think at dune point we probably just want to move to some other scheme
for when to do major releases.  The real question is when and to what do we
switch.  I've already argued that the jump from 4.4 to 4.3 is fairly
artificial since the only part of 4.4 we were missing in 12.0 was a part of
one extension (enhanced layouts).  The jump from 4.4 to 4.5 is even more
artificial since we already have all the 4.5 features and just haven't
bumped the number.

Here's some options on the "what" part of the question:

1) We should do a time-based scheme like the kernel uses.  Release minor
versions every 3 months and major versions every N years.

2) Keep with the current scheme and throw Vulkan into the mix.  Mesa 15.0
will be when we add support for Vulkan 1.1.  We could also throw in ES but
that doesn't help since we just turned on 3.2 and ES is about as likely to
get a 3.3 as desktop is to get 4.6.

3) Just do minor releases and let developers nominate any release to be a
major one based on some major event in their driver.  This is quite
arbitrary but at least gives is the chance to try and make a new major
release actually mean something major happened.

4) Do what chromium, Firefox, and some other projects have done and just
get rid of major/minor all together.

I think I actually like (4) the best.  It's not like we're a library that's
going to break ABI ever and needs a major version boundary to do it on.  I
think it also better represents the actual development model of the project
going forward where each release is a bit better than the others but most
aren't that much more major then the others.

> > I'm updating docs/intro.html with version 10.x - 12.x info.
> >
> > -Brian
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
> ___
> mesa-dev mailing list
> 

Re: [Mesa-dev] [PATCH] gallium/hud: Add support for CPU frequency monitoring

[Brian Paul]

Looks OK to me.

Reviewed-by: Brian Paul 

Will push soon.

-Brian

On 09/30/2016 05:58 AM, Steven Toth wrote:

Detect all of the CPUs in the system. Expose metrics
for min, max and current frequency in Hz.

Signed-off-by: Steven Toth 
---
  src/gallium/auxiliary/Makefile.sources  |   1 +
  src/gallium/auxiliary/hud/hud_context.c |  13 ++
  src/gallium/auxiliary/hud/hud_cpufreq.c | 266 
  src/gallium/auxiliary/hud/hud_private.h |   6 +
  4 files changed, 286 insertions(+)
  create mode 100644 src/gallium/auxiliary/hud/hud_cpufreq.c

diff --git a/src/gallium/auxiliary/Makefile.sources 
b/src/gallium/auxiliary/Makefile.sources
index 3d728ae..3fda2eb 100644
--- a/src/gallium/auxiliary/Makefile.sources
+++ b/src/gallium/auxiliary/Makefile.sources
@@ -63,6 +63,7 @@ C_SOURCES := \
hud/hud_context.h \
hud/hud_cpu.c \
hud/hud_nic.c \
+   hud/hud_cpufreq.c \
hud/hud_diskstat.c \
hud/hud_sensors_temp.c \
hud/hud_driver_query.c \
diff --git a/src/gallium/auxiliary/hud/hud_context.c 
b/src/gallium/auxiliary/hud/hud_context.c
index 3445488..5aee30a 100644
--- a/src/gallium/auxiliary/hud/hud_context.c
+++ b/src/gallium/auxiliary/hud/hud_context.c
@@ -1050,6 +1050,18 @@ hud_parse_env_var(struct hud_context *hud, const char 
*env)
   hud_diskstat_graph_install(pane, arg_name, DISKSTAT_WR);
   pane->type = PIPE_DRIVER_QUERY_TYPE_BYTES;
}
+  else if (sscanf(name, "cpufreq-min-cpu%u", ) == 1) {
+ hud_cpufreq_graph_install(pane, i, CPUFREQ_MINIMUM);
+ pane->type = PIPE_DRIVER_QUERY_TYPE_HZ;
+  }
+  else if (sscanf(name, "cpufreq-cur-cpu%u", ) == 1) {
+ hud_cpufreq_graph_install(pane, i, CPUFREQ_CURRENT);
+ pane->type = PIPE_DRIVER_QUERY_TYPE_HZ;
+  }
+  else if (sscanf(name, "cpufreq-max-cpu%u", ) == 1) {
+ hud_cpufreq_graph_install(pane, i, CPUFREQ_MAXIMUM);
+ pane->type = PIPE_DRIVER_QUERY_TYPE_HZ;
+  }
  #endif
  #if HAVE_LIBSENSORS
else if (sscanf(name, "sensors_temp_cu-%s", arg_name) == 1) {
@@ -1290,6 +1302,7 @@ print_help(struct pipe_screen *screen)
  #if HAVE_GALLIUM_EXTRA_HUD
 hud_get_num_disks(1);
 hud_get_num_nics(1);
+   hud_get_num_cpufreq(1);
  #endif
  #if HAVE_LIBSENSORS
 hud_get_num_sensors(1);
diff --git a/src/gallium/auxiliary/hud/hud_cpufreq.c 
b/src/gallium/auxiliary/hud/hud_cpufreq.c
new file mode 100644
index 000..1296ece
--- /dev/null
+++ b/src/gallium/auxiliary/hud/hud_cpufreq.c
@@ -0,0 +1,266 @@
+/**
+ *
+ * Copyright (C) 2016 Steven Toth 
+ * Copyright (C) 2016 Zodiac Inflight Innovations
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
+ * IN NO EVENT SHALL THE AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR
+ * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
+ * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
+ * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ **/
+
+#if HAVE_GALLIUM_EXTRA_HUD
+
+/* Purpose:
+ * Reading /sys/devices/system/cpu/cpu?/cpufreq/scaling_???_freq
+ * cpu frequency (KHz), displaying on the HUD in Hz.
+ */
+
+#include "hud/hud_private.h"
+#include "util/list.h"
+#include "os/os_time.h"
+#include "util/u_memory.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define LOCAL_DEBUG 0
+
+struct cpufreq_info
+{
+   struct list_head list;
+   int mode; /* CPUFREQ_MINIMUM, CPUFREQ_CURRENT, CPUFREQ_MAXIMUM */
+   char name[16]; /* EG. cpu0 */
+   int cpu_index;
+
+   /* EG. /sys/devices/system/cpu/cpu?/cpufreq/scaling_cur_freq */
+   char sysfs_filename[128];
+   uint64_t KHz;
+   uint64_t last_time;
+};
+
+static int gcpufreq_count = 0;
+static struct list_head gcpufreq_list;
+
+static struct cpufreq_info *
+find_cfi_by_index(int cpu_index, int mode)
+{
+   list_for_each_entry(struct cpufreq_info, cfi, _list, list) {
+  if (cfi->mode != mode)
+ 

Re: [Mesa-dev] Mesa 13.0.0 release plan (Was Re: Mesa 12.1.0 release plan (Was Re: Next Mesa release, anyone?))

[Emil Velikov]

On 30 September 2016 at 15:57, Ian Romanick  wrote:
> On 09/30/2016 06:23 AM, Brian Paul wrote:
>> On 09/30/2016 04:59 AM, Emil Velikov wrote:
>>> On 30 September 2016 at 03:31, Timothy Arceri
>>>  wrote:
 On Thu, 2016-09-29 at 19:17 -0700, Jason Ekstrand wrote:

 On Sep 29, 2016 5:14 PM, "Timothy Arceri" 
 wrote:
>
> On Thu, 2016-09-29 at 15:56 +0100, Emil Velikov wrote:
>> On 28 September 2016 at 19:53, Marek Olšák  wrote:
>>>
>>> Hi,
>>>
>>> It's been almost 4 months since the 12.0 branch was created, and
>>> soon
>>> it will have been 3 months since Mesa 12.0 was released.
>>>
>>> Is there any reason we haven't created the stable branch yet?
>>>
>>> Ideally, we would time the release so that it's 1-2 months before
>>> fall
>>> distribution releases.
>>>
>>
>> Thanks Marek !
>>
>> In all honesty I was secretly hoping that we'll get Dave/Bas RADV for
>> 12.1.
>
> I believe the release should be 13?? Core Mesa and the Intel driver
> have reached 4.4 this release also core Mesa is now at 4.5 despite not
> being enabled anywhere.

 My personal preference, for whatever it's worth, would be to call it
 12.1.
 The 12.0 release was the biggest release we've had in a long time and it
 seems odd to me to jump to 13.0 right away when we really haven't
 done much
 at all in terms of new features. (I think it's only 2 or 3 desktop
 features
 in the case of Intel.  A bit more on the ES side I guess).


 My understanding is the major version has only ever been bumped when
 full
 support for a new desktop OpenGL version has been reached regardless
 of the
 number of extensions enabled. We did the same thing going from 8.0 > 9.0
 were as the 7 release went all the way to 7.11 over a 4 year period. It
 seems odd to change the way we bump versions at this point in time,
 although
 in future maybe it will need to be based on Vulkin versions also.

>>> Brain freeze - seem to miss-remember that enhanced layouts (thus 4.4)
>>> landed after the branch point.
>>> That plus the ES3.1/ES3.2, compat for the desktop GL, (by Ilia/Ken)
>>> does take us to 13.0.
>>>
>>> At the end of the day it's just a number albeit being the "unlucky" one.
>>>
>>> If we get a consensus amongst the majority of devs we can change the
>>> versioning scheme. But for that let's do so in a ~weeks time - after
>>> the branchpoint.
>>
>> I'd say to go to 13.0 if we're now supporting GL 4.4.  That'd follow the
>> general pattern.
>
> I agree.  The only question is what we do after GL 4.5 bumps us to 14.0.
>  There is a distinct possibility (spoiler alert) that there won't be any
> new OpenGL version for a long time, if ever.  Will we be stuck at 14.x
> forever? :)
>
Question being: what's bad with using 13/14/666(jk) as version number ?

We could easily change things, if we get 'bored' with the same major.
Although let's think about this if/when it happens ?

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

Re: [Mesa-dev] Mesa 13.0.0 release plan (Was Re: Mesa 12.1.0 release plan (Was Re: Next Mesa release, anyone?))

[Marek Olšák]

On Fri, Sep 30, 2016 at 5:14 PM, Karol Herbst  wrote:
> 2016-09-30 16:57 GMT+02:00 Ian Romanick :
>> On 09/30/2016 06:23 AM, Brian Paul wrote:
>>> On 09/30/2016 04:59 AM, Emil Velikov wrote:
 On 30 September 2016 at 03:31, Timothy Arceri
  wrote:
> On Thu, 2016-09-29 at 19:17 -0700, Jason Ekstrand wrote:
>
> On Sep 29, 2016 5:14 PM, "Timothy Arceri" 
> wrote:
>>
>> On Thu, 2016-09-29 at 15:56 +0100, Emil Velikov wrote:
>>> On 28 September 2016 at 19:53, Marek Olšák  wrote:

 Hi,

 It's been almost 4 months since the 12.0 branch was created, and
 soon
 it will have been 3 months since Mesa 12.0 was released.

 Is there any reason we haven't created the stable branch yet?

 Ideally, we would time the release so that it's 1-2 months before
 fall
 distribution releases.

>>>
>>> Thanks Marek !
>>>
>>> In all honesty I was secretly hoping that we'll get Dave/Bas RADV for
>>> 12.1.
>>
>> I believe the release should be 13?? Core Mesa and the Intel driver
>> have reached 4.4 this release also core Mesa is now at 4.5 despite not
>> being enabled anywhere.
>
> My personal preference, for whatever it's worth, would be to call it
> 12.1.
> The 12.0 release was the biggest release we've had in a long time and it
> seems odd to me to jump to 13.0 right away when we really haven't
> done much
> at all in terms of new features. (I think it's only 2 or 3 desktop
> features
> in the case of Intel.  A bit more on the ES side I guess).
>
>
> My understanding is the major version has only ever been bumped when
> full
> support for a new desktop OpenGL version has been reached regardless
> of the
> number of extensions enabled. We did the same thing going from 8.0 > 9.0
> were as the 7 release went all the way to 7.11 over a 4 year period. It
> seems odd to change the way we bump versions at this point in time,
> although
> in future maybe it will need to be based on Vulkin versions also.
>
 Brain freeze - seem to miss-remember that enhanced layouts (thus 4.4)
 landed after the branch point.
 That plus the ES3.1/ES3.2, compat for the desktop GL, (by Ilia/Ken)
 does take us to 13.0.

 At the end of the day it's just a number albeit being the "unlucky" one.

 If we get a consensus amongst the majority of devs we can change the
 versioning scheme. But for that let's do so in a ~weeks time - after
 the branchpoint.
>>>
>>> I'd say to go to 13.0 if we're now supporting GL 4.4.  That'd follow the
>>> general pattern.
>>
>> I agree.  The only question is what we do after GL 4.5 bumps us to 14.0.
>>  There is a distinct possibility (spoiler alert) that there won't be any
>> new OpenGL version for a long time, if ever.  Will we be stuck at 14.x
>> forever? :)
>>
>
> why not a new release bump after implementing those "OpenGL 2015" extensions 
> ;)

That might never happen either.

I prefer a versioning scheme that is not based on features.

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

Re: [Mesa-dev] [PATCH] docs: update the list of Mesa major versions and API support

[Brian Paul]

On 09/30/2016 07:47 AM, Emil Velikov wrote:

On 30 September 2016 at 14:23, Brian Paul  wrote:

---
  docs/intro.html | 25 +
  1 file changed, 25 insertions(+)

diff --git a/docs/intro.html b/docs/intro.html
index 4b36562..6c91e3f 100644
--- a/docs/intro.html
+++ b/docs/intro.html
@@ -173,6 +173,27 @@ of the OpenGL specification is implemented.
  


+Version 12.x features
+
+Version 12.x of Mesa implements the OpenGL 4.3 API, but not all drivers
+support OpenGL 4.3.
+
+
+
+Version 11.x features
+
+Version 11.x of Mesa implements the OpenGL 4.1 API, but not all drivers
+support OpenGL 4.1.
+
+
+
+Version 10.x features
+
+Version 10.x of Mesa implements the OpenGL 3.3 API, but not all drivers
+support OpenGL 3.3.
+
+
+
  Version 9.x features
  
  Version 9.x of Mesa implements the OpenGL 3.1 API.
@@ -182,6 +203,10 @@ community contributed features required for OpenGL 3.1.  
The primary
  features added since the Mesa 8.0 release are
  GL_ARB_texture_buffer_object and GL_ARB_uniform_buffer_object.
  
+
+Version 9.0 of Mesa also included the first release of the Clover state
+tracker for OpenCL.
+


Mentioning Clover whist omitting VDPAU/OMX and others is a bit meh.


I invite others to add more details.  I just took a quick stab at the 
update.




Either way, thanks for the update Brian.

Reviewed-by: Emil Velikov 


Thanks.

-Brian


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

Re: [Mesa-dev] Mesa 13.0.0 release plan (Was Re: Mesa 12.1.0 release plan (Was Re: Next Mesa release, anyone?))

[Karol Herbst]

2016-09-30 16:57 GMT+02:00 Ian Romanick :
> On 09/30/2016 06:23 AM, Brian Paul wrote:
>> On 09/30/2016 04:59 AM, Emil Velikov wrote:
>>> On 30 September 2016 at 03:31, Timothy Arceri
>>>  wrote:
 On Thu, 2016-09-29 at 19:17 -0700, Jason Ekstrand wrote:

 On Sep 29, 2016 5:14 PM, "Timothy Arceri" 
 wrote:
>
> On Thu, 2016-09-29 at 15:56 +0100, Emil Velikov wrote:
>> On 28 September 2016 at 19:53, Marek Olšák  wrote:
>>>
>>> Hi,
>>>
>>> It's been almost 4 months since the 12.0 branch was created, and
>>> soon
>>> it will have been 3 months since Mesa 12.0 was released.
>>>
>>> Is there any reason we haven't created the stable branch yet?
>>>
>>> Ideally, we would time the release so that it's 1-2 months before
>>> fall
>>> distribution releases.
>>>
>>
>> Thanks Marek !
>>
>> In all honesty I was secretly hoping that we'll get Dave/Bas RADV for
>> 12.1.
>
> I believe the release should be 13?? Core Mesa and the Intel driver
> have reached 4.4 this release also core Mesa is now at 4.5 despite not
> being enabled anywhere.

 My personal preference, for whatever it's worth, would be to call it
 12.1.
 The 12.0 release was the biggest release we've had in a long time and it
 seems odd to me to jump to 13.0 right away when we really haven't
 done much
 at all in terms of new features. (I think it's only 2 or 3 desktop
 features
 in the case of Intel.  A bit more on the ES side I guess).


 My understanding is the major version has only ever been bumped when
 full
 support for a new desktop OpenGL version has been reached regardless
 of the
 number of extensions enabled. We did the same thing going from 8.0 > 9.0
 were as the 7 release went all the way to 7.11 over a 4 year period. It
 seems odd to change the way we bump versions at this point in time,
 although
 in future maybe it will need to be based on Vulkin versions also.

>>> Brain freeze - seem to miss-remember that enhanced layouts (thus 4.4)
>>> landed after the branch point.
>>> That plus the ES3.1/ES3.2, compat for the desktop GL, (by Ilia/Ken)
>>> does take us to 13.0.
>>>
>>> At the end of the day it's just a number albeit being the "unlucky" one.
>>>
>>> If we get a consensus amongst the majority of devs we can change the
>>> versioning scheme. But for that let's do so in a ~weeks time - after
>>> the branchpoint.
>>
>> I'd say to go to 13.0 if we're now supporting GL 4.4.  That'd follow the
>> general pattern.
>
> I agree.  The only question is what we do after GL 4.5 bumps us to 14.0.
>  There is a distinct possibility (spoiler alert) that there won't be any
> new OpenGL version for a long time, if ever.  Will we be stuck at 14.x
> forever? :)
>

why not a new release bump after implementing those "OpenGL 2015" extensions ;)

>> I'm updating docs/intro.html with version 10.x - 12.x info.
>>
>> -Brian
>>
>> ___
>> 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 mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v3] glsl: optimize copy_propagation_elements pass

[Ian Romanick]

From: Tapani Pälli 

Changes make copy_propagation_elements pass faster, reducing link
time spent in test case of bug 94477. Does not fix the actual issue
but brings down the total time. No regressions seen in CI.

v2 (idr): Formatting / whitespace fixes.  Embed the acp_ref in the
acp_entry.

v3 (idr): Delete unused copy constructor.  Use while(pop_head) instead
of foreach() { remove }.

Signed-off-by: Tapani Pälli 
Signed-off-by: Ian Romanick 
---
Ugh... I had these uncommitted changes sitting in my tree when I sent
the other patch out.  Sorry for the chaos.

 .../glsl/opt_copy_propagation_elements.cpp | 198 +++--
 1 file changed, 148 insertions(+), 50 deletions(-)

diff --git a/src/compiler/glsl/opt_copy_propagation_elements.cpp 
b/src/compiler/glsl/opt_copy_propagation_elements.cpp
index e4237cc..be89116 100644
--- a/src/compiler/glsl/opt_copy_propagation_elements.cpp
+++ b/src/compiler/glsl/opt_copy_propagation_elements.cpp
@@ -46,15 +46,32 @@
 #include "ir_basic_block.h"
 #include "ir_optimization.h"
 #include "compiler/glsl_types.h"
+#include "util/hash_table.h"
 
 static bool debug = false;
 
 namespace {
 
+class acp_entry;
+
+/* Class that refers to acp_entry in another exec_list. Used
+ * when making removals based on rhs.
+ */
+class acp_ref : public exec_node
+{
+public:
+   acp_ref(acp_entry *e)
+   {
+  entry = e;
+   }
+   acp_entry *entry;
+};
+
 class acp_entry : public exec_node
 {
 public:
acp_entry(ir_variable *lhs, ir_variable *rhs, int write_mask, int 
swizzle[4])
+  : rhs_node(this)
{
   this->lhs = lhs;
   this->rhs = rhs;
@@ -62,18 +79,11 @@ public:
   memcpy(this->swizzle, swizzle, sizeof(this->swizzle));
}
 
-   acp_entry(acp_entry *a)
-   {
-  this->lhs = a->lhs;
-  this->rhs = a->rhs;
-  this->write_mask = a->write_mask;
-  memcpy(this->swizzle, a->swizzle, sizeof(this->swizzle));
-   }
-
ir_variable *lhs;
ir_variable *rhs;
unsigned int write_mask;
int swizzle[4];
+   acp_ref rhs_node;
 };
 
 
@@ -98,14 +108,42 @@ public:
   this->killed_all = false;
   this->mem_ctx = ralloc_context(NULL);
   this->shader_mem_ctx = NULL;
-  this->acp = new(mem_ctx) exec_list;
   this->kills = new(mem_ctx) exec_list;
+
+  create_acp();
}
~ir_copy_propagation_elements_visitor()
{
   ralloc_free(mem_ctx);
}
 
+   void create_acp()
+   {
+  lhs_ht = _mesa_hash_table_create(mem_ctx, _mesa_hash_pointer,
+   _mesa_key_pointer_equal);
+  rhs_ht = _mesa_hash_table_create(mem_ctx, _mesa_hash_pointer,
+   _mesa_key_pointer_equal);
+   }
+
+   void destroy_acp()
+   {
+  _mesa_hash_table_destroy(lhs_ht, NULL);
+  _mesa_hash_table_destroy(rhs_ht, NULL);
+   }
+
+   void populate_acp(hash_table *lhs, hash_table *rhs)
+   {
+  struct hash_entry *entry;
+
+  hash_table_foreach(lhs, entry) {
+ _mesa_hash_table_insert(lhs_ht, entry->key, entry->data);
+  }
+
+  hash_table_foreach(rhs, entry) {
+ _mesa_hash_table_insert(rhs_ht, entry->key, entry->data);
+  }
+   }
+
void handle_loop(ir_loop *, bool keep_acp);
virtual ir_visitor_status visit_enter(class ir_loop *);
virtual ir_visitor_status visit_enter(class ir_function_signature *);
@@ -120,8 +158,10 @@ public:
void kill(kill_entry *k);
void handle_if_block(exec_list *instructions);
 
-   /** List of acp_entry: The available copies to propagate */
-   exec_list *acp;
+   /** Hash of acp_entry: The available copies to propagate */
+   hash_table *lhs_ht;
+   hash_table *rhs_ht;
+
/**
 * List of kill_entry: The variables whose values were killed in this
 * block.
@@ -147,23 +187,29 @@ 
ir_copy_propagation_elements_visitor::visit_enter(ir_function_signature *ir)
 * block.  Any instructions at global scope will be shuffled into
 * main() at link time, so they're irrelevant to us.
 */
-   exec_list *orig_acp = this->acp;
exec_list *orig_kills = this->kills;
bool orig_killed_all = this->killed_all;
 
-   this->acp = new(mem_ctx) exec_list;
+   hash_table *orig_lhs_ht = lhs_ht;
+   hash_table *orig_rhs_ht = rhs_ht;
+
this->kills = new(mem_ctx) exec_list;
this->killed_all = false;
 
+   create_acp();
+
visit_list_elements(this, >body);
 
-   ralloc_free(this->acp);
ralloc_free(this->kills);
 
+   destroy_acp();
+
this->kills = orig_kills;
-   this->acp = orig_acp;
this->killed_all = orig_killed_all;
 
+   lhs_ht = orig_lhs_ht;
+   rhs_ht = orig_rhs_ht;
+
return visit_continue_with_parent;
 }
 
@@ -249,17 +295,19 @@ 
ir_copy_propagation_elements_visitor::handle_rvalue(ir_rvalue **ir)
/* Try to find ACP entries covering swizzle_chan[], hoping they're
 * the same source variable.
 */
-   foreach_in_list(acp_entry, entry, this->acp) {
-  if (var == 

Re: [Mesa-dev] [PATCH] i915/i965: remove commented out warning

[Ian Romanick]

Reviewed-by: Ian Romanick 

On 09/29/2016 11:37 PM, Timothy Arceri wrote:
> The warning was also the wrong location, it should have been
> in the else.
> ---
>  src/mesa/drivers/dri/i915/intel_fbo.h | 4 +---
>  src/mesa/drivers/dri/i965/intel_fbo.h | 4 +---
>  2 files changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i915/intel_fbo.h 
> b/src/mesa/drivers/dri/i915/intel_fbo.h
> index 114dd68..769dab8 100644
> --- a/src/mesa/drivers/dri/i915/intel_fbo.h
> +++ b/src/mesa/drivers/dri/i915/intel_fbo.h
> @@ -89,10 +89,8 @@ static inline struct intel_renderbuffer *
>  intel_renderbuffer(struct gl_renderbuffer *rb)
>  {
> struct intel_renderbuffer *irb = (struct intel_renderbuffer *) rb;
> -   if (irb && irb->Base.Base.ClassID == INTEL_RB_CLASS) {
> -  /*_mesa_warning(NULL, "Returning non-intel Rb\n");*/
> +   if (irb && irb->Base.Base.ClassID == INTEL_RB_CLASS)
>return irb;
> -   }
> else
>return NULL;
>  }
> diff --git a/src/mesa/drivers/dri/i965/intel_fbo.h 
> b/src/mesa/drivers/dri/i965/intel_fbo.h
> index 89894cd..e6f6156 100644
> --- a/src/mesa/drivers/dri/i965/intel_fbo.h
> +++ b/src/mesa/drivers/dri/i965/intel_fbo.h
> @@ -130,10 +130,8 @@ static inline struct intel_renderbuffer *
>  intel_renderbuffer(struct gl_renderbuffer *rb)
>  {
> struct intel_renderbuffer *irb = (struct intel_renderbuffer *) rb;
> -   if (irb && irb->Base.Base.ClassID == INTEL_RB_CLASS) {
> -  /*_mesa_warning(NULL, "Returning non-intel Rb\n");*/
> +   if (irb && irb->Base.Base.ClassID == INTEL_RB_CLASS)
>return irb;
> -   }
> else
>return NULL;
>  }
> 

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

[Mesa-dev] [PATCH] glsl: optimize copy_propagation_elements pass

[Ian Romanick]

From: Tapani Pälli 

Changes make copy_propagation_elements pass faster, reducing link
time spent in test case of bug 94477. Does not fix the actual issue
but brings down the total time. No regressions seen in CI.

v2 (idr): Formatting / whitespace fixes.  Embed the acp_ref in the
acp_entry.

Signed-off-by: Tapani Pälli 
Signed-off-by: Ian Romanick 
---
This is tested with shader-db.  There's a bit more cleaning and testing
to do.  I was going to send this out last night but, long story short,
my desk collapsed, and I had to deal with that instead. :(

 .../glsl/opt_copy_propagation_elements.cpp | 193 -
 1 file changed, 150 insertions(+), 43 deletions(-)

diff --git a/src/compiler/glsl/opt_copy_propagation_elements.cpp 
b/src/compiler/glsl/opt_copy_propagation_elements.cpp
index e4237cc..7d0b4cc 100644
--- a/src/compiler/glsl/opt_copy_propagation_elements.cpp
+++ b/src/compiler/glsl/opt_copy_propagation_elements.cpp
@@ -46,15 +46,32 @@
 #include "ir_basic_block.h"
 #include "ir_optimization.h"
 #include "compiler/glsl_types.h"
+#include "util/hash_table.h"
 
 static bool debug = false;
 
 namespace {
 
+class acp_entry;
+
+/* Class that refers to acp_entry in another exec_list. Used
+ * when making removals based on rhs.
+ */
+class acp_ref : public exec_node
+{
+public:
+   acp_ref(acp_entry *e)
+   {
+  entry = e;
+   }
+   acp_entry *entry;
+};
+
 class acp_entry : public exec_node
 {
 public:
acp_entry(ir_variable *lhs, ir_variable *rhs, int write_mask, int 
swizzle[4])
+  : rhs_node(this)
{
   this->lhs = lhs;
   this->rhs = rhs;
@@ -63,6 +80,7 @@ public:
}
 
acp_entry(acp_entry *a)
+  : rhs_node(this)
{
   this->lhs = a->lhs;
   this->rhs = a->rhs;
@@ -74,9 +92,9 @@ public:
ir_variable *rhs;
unsigned int write_mask;
int swizzle[4];
+   acp_ref rhs_node;
 };
 
-
 class kill_entry : public exec_node
 {
 public:
@@ -98,14 +116,42 @@ public:
   this->killed_all = false;
   this->mem_ctx = ralloc_context(NULL);
   this->shader_mem_ctx = NULL;
-  this->acp = new(mem_ctx) exec_list;
   this->kills = new(mem_ctx) exec_list;
+
+  create_acp();
}
~ir_copy_propagation_elements_visitor()
{
   ralloc_free(mem_ctx);
}
 
+   void create_acp()
+   {
+  lhs_ht = _mesa_hash_table_create(mem_ctx, _mesa_hash_pointer,
+   _mesa_key_pointer_equal);
+  rhs_ht = _mesa_hash_table_create(mem_ctx, _mesa_hash_pointer,
+   _mesa_key_pointer_equal);
+   }
+
+   void destroy_acp()
+   {
+  _mesa_hash_table_destroy(lhs_ht, NULL);
+  _mesa_hash_table_destroy(rhs_ht, NULL);
+   }
+
+   void populate_acp(hash_table *lhs, hash_table *rhs)
+   {
+  struct hash_entry *entry;
+
+  hash_table_foreach(lhs, entry) {
+ _mesa_hash_table_insert(lhs_ht, entry->key, entry->data);
+  }
+
+  hash_table_foreach(rhs, entry) {
+ _mesa_hash_table_insert(rhs_ht, entry->key, entry->data);
+  }
+   }
+
void handle_loop(ir_loop *, bool keep_acp);
virtual ir_visitor_status visit_enter(class ir_loop *);
virtual ir_visitor_status visit_enter(class ir_function_signature *);
@@ -120,8 +166,10 @@ public:
void kill(kill_entry *k);
void handle_if_block(exec_list *instructions);
 
-   /** List of acp_entry: The available copies to propagate */
-   exec_list *acp;
+   /** Hash of acp_entry: The available copies to propagate */
+   hash_table *lhs_ht;
+   hash_table *rhs_ht;
+
/**
 * List of kill_entry: The variables whose values were killed in this
 * block.
@@ -147,23 +195,29 @@ 
ir_copy_propagation_elements_visitor::visit_enter(ir_function_signature *ir)
 * block.  Any instructions at global scope will be shuffled into
 * main() at link time, so they're irrelevant to us.
 */
-   exec_list *orig_acp = this->acp;
exec_list *orig_kills = this->kills;
bool orig_killed_all = this->killed_all;
 
-   this->acp = new(mem_ctx) exec_list;
+   hash_table *orig_lhs_ht = lhs_ht;
+   hash_table *orig_rhs_ht = rhs_ht;
+
this->kills = new(mem_ctx) exec_list;
this->killed_all = false;
 
+   create_acp();
+
visit_list_elements(this, >body);
 
-   ralloc_free(this->acp);
ralloc_free(this->kills);
 
+   destroy_acp();
+
this->kills = orig_kills;
-   this->acp = orig_acp;
this->killed_all = orig_killed_all;
 
+   lhs_ht = orig_lhs_ht;
+   rhs_ht = orig_rhs_ht;
+
return visit_continue_with_parent;
 }
 
@@ -249,17 +303,19 @@ 
ir_copy_propagation_elements_visitor::handle_rvalue(ir_rvalue **ir)
/* Try to find ACP entries covering swizzle_chan[], hoping they're
 * the same source variable.
 */
-   foreach_in_list(acp_entry, entry, this->acp) {
-  if (var == entry->lhs) {
-for (int c = 0; c < chans; c++) {
-   if (entry->write_mask & (1 << 

Re: [Mesa-dev] Mesa 13.0.0 release plan (Was Re: Mesa 12.1.0 release plan (Was Re: Next Mesa release, anyone?))

[Ian Romanick]

On 09/30/2016 06:23 AM, Brian Paul wrote:
> On 09/30/2016 04:59 AM, Emil Velikov wrote:
>> On 30 September 2016 at 03:31, Timothy Arceri
>>  wrote:
>>> On Thu, 2016-09-29 at 19:17 -0700, Jason Ekstrand wrote:
>>>
>>> On Sep 29, 2016 5:14 PM, "Timothy Arceri" 
>>> wrote:

 On Thu, 2016-09-29 at 15:56 +0100, Emil Velikov wrote:
> On 28 September 2016 at 19:53, Marek Olšák  wrote:
>>
>> Hi,
>>
>> It's been almost 4 months since the 12.0 branch was created, and
>> soon
>> it will have been 3 months since Mesa 12.0 was released.
>>
>> Is there any reason we haven't created the stable branch yet?
>>
>> Ideally, we would time the release so that it's 1-2 months before
>> fall
>> distribution releases.
>>
>
> Thanks Marek !
>
> In all honesty I was secretly hoping that we'll get Dave/Bas RADV for
> 12.1.

 I believe the release should be 13?? Core Mesa and the Intel driver
 have reached 4.4 this release also core Mesa is now at 4.5 despite not
 being enabled anywhere.
>>>
>>> My personal preference, for whatever it's worth, would be to call it
>>> 12.1.
>>> The 12.0 release was the biggest release we've had in a long time and it
>>> seems odd to me to jump to 13.0 right away when we really haven't
>>> done much
>>> at all in terms of new features. (I think it's only 2 or 3 desktop
>>> features
>>> in the case of Intel.  A bit more on the ES side I guess).
>>>
>>>
>>> My understanding is the major version has only ever been bumped when
>>> full
>>> support for a new desktop OpenGL version has been reached regardless
>>> of the
>>> number of extensions enabled. We did the same thing going from 8.0 > 9.0
>>> were as the 7 release went all the way to 7.11 over a 4 year period. It
>>> seems odd to change the way we bump versions at this point in time,
>>> although
>>> in future maybe it will need to be based on Vulkin versions also.
>>>
>> Brain freeze - seem to miss-remember that enhanced layouts (thus 4.4)
>> landed after the branch point.
>> That plus the ES3.1/ES3.2, compat for the desktop GL, (by Ilia/Ken)
>> does take us to 13.0.
>>
>> At the end of the day it's just a number albeit being the "unlucky" one.
>>
>> If we get a consensus amongst the majority of devs we can change the
>> versioning scheme. But for that let's do so in a ~weeks time - after
>> the branchpoint.
> 
> I'd say to go to 13.0 if we're now supporting GL 4.4.  That'd follow the
> general pattern.

I agree.  The only question is what we do after GL 4.5 bumps us to 14.0.
 There is a distinct possibility (spoiler alert) that there won't be any
new OpenGL version for a long time, if ever.  Will we be stuck at 14.x
forever? :)

> I'm updating docs/intro.html with version 10.x - 12.x info.
> 
> -Brian
> 
> ___
> 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

Re: [Mesa-dev] [PATCH] Revert "st/vdpau: use linear layout for output surfaces"

[Ilia Mirkin]

So is this getting pushed, or should I push my "don't build vdpau for
nouveau" patch?

On Wed, Sep 14, 2016 at 11:58 PM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> This reverts commit d180de35320eafa3df3d76f0e82b332656530126.
>
> This is a radeon specific hack that causes problems on nouveau
> when combined with the SHARED flag later. If radeonsi needs a fix
> for this, please fix it in the driver.
>
> Signed-off-by: Dave Airlie 
> ---
>  src/gallium/state_trackers/vdpau/output.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/state_trackers/vdpau/output.c 
> b/src/gallium/state_trackers/vdpau/output.c
> index 85751ea..09a1517 100644
> --- a/src/gallium/state_trackers/vdpau/output.c
> +++ b/src/gallium/state_trackers/vdpau/output.c
> @@ -82,7 +82,7 @@ vlVdpOutputSurfaceCreate(VdpDevice device,
> res_tmpl.depth0 = 1;
> res_tmpl.array_size = 1;
> res_tmpl.bind = PIPE_BIND_SAMPLER_VIEW | PIPE_BIND_RENDER_TARGET |
> -   PIPE_BIND_LINEAR | PIPE_BIND_SHARED;
> +   PIPE_BIND_SHARED;
> res_tmpl.usage = PIPE_USAGE_DEFAULT;
>
> pipe_mutex_lock(dev->mutex);
> --
> 2.5.5
>
> ___
> 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

Re: [Mesa-dev] [PATCH] HUD: Add support for block I/O, network I/O and lmsensor stats

[Emil Velikov]

Hi Steven,

On 28 September 2016 at 19:58, Steven Toth  wrote:
> V8: Feedback based on peer review
> convert if block into a switch
> Constify some func args
>
> V7: Increase precision when measuring lmsensors volts
> Flatten patch series.
>
> V6: Feedback based on peer review
> Simplify sensor initialization (arg passing).
> Constify some func args
>
> V5: Feedback based on peer review
> Convert sprintf to snprintf
> Convert char * to const char *
> int arg converted to bool
> Func changes to take a filename vs a larger struct.
> Omit the space between '*' and the param name.
>
> V4: Merged with master as of 2016/9/27 6pm
>
> V3: Flatten the entire patchset ready for the ML
>
> V2: Additional seperate patches based on feedback
> a) configure.ac: Add a comment related to libsensors
>
> b) HUD: Disable Block/NIC I/O stats by default.
> Implement configuration option --enable-gallium-extra-hud=yes
> and enable both statistics when this option is enabled.
>
> c) Configure.ac: Minor cleanup to user visible configuration settings
>
> d) Configure.ac: HUD stats - build system improvements
> Move the -lsensors out of a deeper Makefile, bring it into the configure.ac.
> Also, rename a compiler directive to more closely follow the standard.
>
> V1: Initial release to the ML
> Three new features:
> 1. Disk/block I/O device read/write stats MB/ps.
> 2. Network Interface RX/TX transfer statistics as a percentage
>of the overall NIC speed.
> 3. lmsensor power, voltage and temperature sensors.
>
While I'm in favour of keeping a brief changelog within the summary
the actual commit message is getting lost in here :-\

> The lmsensor changes makes a dependency on libsensors so support
> for the change is opt out by default.
>
> Signed-off-by: Steven Toth 
> ---
>  configure.ac |  42 +++
>  src/gallium/auxiliary/Makefile.am|   2 +
>  src/gallium/auxiliary/Makefile.sources   |   3 +
>  src/gallium/auxiliary/hud/hud_context.c  |  73 +
>  src/gallium/auxiliary/hud/hud_diskstat.c | 337 
>  src/gallium/auxiliary/hud/hud_nic.c  | 446 
> +++
>  src/gallium/auxiliary/hud/hud_private.h  |  25 ++
>  src/gallium/auxiliary/hud/hud_sensors_temp.c | 374 ++
>  src/gallium/include/pipe/p_defines.h |   4 +
>  9 files changed, 1306 insertions(+)
>  create mode 100644 src/gallium/auxiliary/hud/hud_diskstat.c
>  create mode 100644 src/gallium/auxiliary/hud/hud_nic.c
>  create mode 100644 src/gallium/auxiliary/hud/hud_sensors_temp.c
>
> diff --git a/configure.ac b/configure.ac
> index c702b53..1bfac3b 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -91,6 +91,7 @@ XCBGLX_REQUIRED=1.8.1
>  XSHMFENCE_REQUIRED=1.1
>  XVMC_REQUIRED=1.0.6
>  PYTHON_MAKO_REQUIRED=0.8.0
> +LIBSENSORS_REQUIRED=4.0.0
>
>  dnl Check for progs
>  AC_PROG_CPP
> @@ -871,6 +872,32 @@ AC_ARG_ENABLE([dri],
>  [enable_dri="$enableval"],
>  [enable_dri=yes])
>
> +AC_ARG_ENABLE([gallium-extra-hud],
> +[AS_HELP_STRING([--enable-gallium-extra-hud],
> +[enable HUD block/NIC I/O HUD stats support 
> @<:@default=disabled@:>@])],
> +[enable_gallium_extra_hud="$enableval"],
> +[enable_gallium_extra_hud=no])
Looking at some of your other patches makes me wonder. Is it worth
having this as a list - (maybe?) rename it to s/enable/with/ and have
the user provide a list of required parts - sensors, cpu freq, etc.

I'm thinking of cases where extra deps come to play and having a
toggle for each one will be insane :-\

If having X separate bits in the extra-hud sounds like and overkill,
how do you feel if we do
--with/enable-gallium-extra-hud={all,without-sensors}

> +AM_CONDITIONAL(HAVE_GALLIUM_EXTRA_HUD, test "x$enable_gallium_extra_hud" = 
> xyes)
> +if test "x$enable_gallium_extra_hud" = xyes ; then
> +DEFINES="${DEFINES} -DHAVE_GALLIUM_EXTRA_HUD=1"
> +fi
> +
> +#TODO: no pkgconfig .pc available for libsensors.
> +#PKG_CHECK_MODULES([LIBSENSORS], [libsensors >= $LIBSENSORS_REQUIRED], 
> [enable_lmsensors=yes], [enable_lmsensors=no])
> +AC_ARG_ENABLE([lmsensors],
> +[AS_HELP_STRING([--enable-lmsensors],
> +[enable HUD lmsensor support @<:@default=disabled@:>@])],
> +[enable_lmsensors="$enableval"],
> +[enable_lmsensors=no])
> +AM_CONDITIONAL(HAVE_LIBSENSORS, test "x$enable_lmsensors" = xyes)
> +if test "x$enable_lmsensors" = xyes ; then
> +DEFINES="${DEFINES} -DHAVE_LIBSENSORS=1"
> +LIBSENSORS_LDFLAGS="-lsensors"
> +else
> +LIBSENSORS_LDFLAGS=""
> +fi
> +AC_SUBST(LIBSENSORS_LDFLAGS)
You want the LIBS variable, LDFLAGS is something else.


>  endif
>
> +libgallium_la_LDFLAGS = $(LIBSENSORS_LDFLAGS)
> +
Please add the new variable to GALLIUM_COMMON_LIB_DEPS (in
src/gallium/Automake.inc)


> +
> +#define LOCAL_DEBUG 0
> +
This and the related debugging code does not seem too useful past the

Re: [Mesa-dev] [PATCH v2] util/slab: re-design to allow migration between pools (v2)

[Marek Olšák]

On Fri, Sep 30, 2016 at 3:08 PM, Bas Nieuwenhuizen
 wrote:
> On Fri, Sep 30, 2016 at 2:13 PM, Marek Olšák  wrote:
>> intptr_t reads and writes aren't atomic. p_atomic_set and
>> p_atomic_read functions don't do anything for atomicity. See:
>>
>> #define p_atomic_set(_v, _i) (*(_v) = (_i))
>> #define p_atomic_read(_v) (*(_v))
>
> That implementation seems bogus to me, as the compiler sees none of
> them as atomic and therefore the compiler can do strange stuff.
>
> why are intptr_t reads/writes less atomic than int32_t? IIRC on x86_64
> aligned 64-bit accesses are atomic, and on x86 intptr_t is just 32
> bits.

Really? Thanks, I didn't know that.

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

Re: [Mesa-dev] [PATCH] docs: update the list of Mesa major versions and API support

[Emil Velikov]

On 30 September 2016 at 14:23, Brian Paul  wrote:
> ---
>  docs/intro.html | 25 +
>  1 file changed, 25 insertions(+)
>
> diff --git a/docs/intro.html b/docs/intro.html
> index 4b36562..6c91e3f 100644
> --- a/docs/intro.html
> +++ b/docs/intro.html
> @@ -173,6 +173,27 @@ of the OpenGL specification is implemented.
>  
>
>
> +Version 12.x features
> +
> +Version 12.x of Mesa implements the OpenGL 4.3 API, but not all drivers
> +support OpenGL 4.3.
> +
> +
> +
> +Version 11.x features
> +
> +Version 11.x of Mesa implements the OpenGL 4.1 API, but not all drivers
> +support OpenGL 4.1.
> +
> +
> +
> +Version 10.x features
> +
> +Version 10.x of Mesa implements the OpenGL 3.3 API, but not all drivers
> +support OpenGL 3.3.
> +
> +
> +
>  Version 9.x features
>  
>  Version 9.x of Mesa implements the OpenGL 3.1 API.
> @@ -182,6 +203,10 @@ community contributed features required for OpenGL 3.1.  
> The primary
>  features added since the Mesa 8.0 release are
>  GL_ARB_texture_buffer_object and GL_ARB_uniform_buffer_object.
>  
> +
> +Version 9.0 of Mesa also included the first release of the Clover state
> +tracker for OpenCL.
> +
>
Mentioning Clover whist omitting VDPAU/OMX and others is a bit meh.
Either way, thanks for the update Brian.

Reviewed-by: Emil Velikov 

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

Re: [Mesa-dev] [PATCH 7/7] radeonsi: optionally run the LLVM IR verifier pass

[Marek Olšák]

I'm not so familiar with the LLVM basic block API, but this series
makes sense to me. For the series:

Reviewed-by: Marek Olšák 

Marek

On Thu, Sep 29, 2016 at 3:15 PM, Nicolai Hähnle  wrote:
> From: Nicolai Hähnle 
>
> This is enabled automatically if shader printing is enabled, or separately
> by R600_DEBUG=checkir. Catch mal-formed IR before it crashes in a later
> pass.
> ---
>  src/gallium/drivers/radeon/r600_pipe_common.c  |  7 ++
>  src/gallium/drivers/radeon/r600_pipe_common.h  |  3 +++
>  src/gallium/drivers/radeon/radeon_llvm.h   |  3 ++-
>  .../drivers/radeon/radeon_setup_tgsi_llvm.c|  6 -
>  src/gallium/drivers/radeonsi/si_shader.c   | 28 
> --
>  5 files changed, 38 insertions(+), 9 deletions(-)
>
> diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c 
> b/src/gallium/drivers/radeon/r600_pipe_common.c
> index 5b1ce04..e7bf7f2 100644
> --- a/src/gallium/drivers/radeon/r600_pipe_common.c
> +++ b/src/gallium/drivers/radeon/r600_pipe_common.c
> @@ -632,20 +632,21 @@ static const struct debug_named_value 
> common_debug_options[] = {
> { "vs", DBG_VS, "Print vertex shaders" },
> { "gs", DBG_GS, "Print geometry shaders" },
> { "ps", DBG_PS, "Print pixel shaders" },
> { "cs", DBG_CS, "Print compute shaders" },
> { "tcs", DBG_TCS, "Print tessellation control shaders" },
> { "tes", DBG_TES, "Print tessellation evaluation shaders" },
> { "noir", DBG_NO_IR, "Don't print the LLVM IR"},
> { "notgsi", DBG_NO_TGSI, "Don't print the TGSI"},
> { "noasm", DBG_NO_ASM, "Don't print disassembled shaders"},
> { "preoptir", DBG_PREOPT_IR, "Print the LLVM IR before initial 
> optimizations" },
> +   { "checkir", DBG_CHECK_IR, "Enable additional sanity checks on shader 
> IR" },
>
> { "testdma", DBG_TEST_DMA, "Invoke SDMA tests and exit." },
>
> /* features */
> { "nodma", DBG_NO_ASYNC_DMA, "Disable asynchronous DMA" },
> { "nohyperz", DBG_NO_HYPERZ, "Disable Hyper-Z" },
> /* GL uses the word INVALIDATE, gallium uses the word DISCARD */
> { "noinvalrange", DBG_NO_DISCARD_RANGE, "Disable handling of 
> INVALIDATE_RANGE map flags" },
> { "no2d", DBG_NO_2D_TILING, "Disable 2D tiling" },
> { "notiling", DBG_NO_TILING, "Disable tiling" },
> @@ -1276,20 +1277,26 @@ bool r600_can_dump_shader(struct r600_common_screen 
> *rscreen,
> return (rscreen->debug_flags & DBG_GS) != 0;
> case PIPE_SHADER_FRAGMENT:
> return (rscreen->debug_flags & DBG_PS) != 0;
> case PIPE_SHADER_COMPUTE:
> return (rscreen->debug_flags & DBG_CS) != 0;
> default:
> return false;
> }
>  }
>
> +bool r600_extra_shader_checks(struct r600_common_screen *rscreen, unsigned 
> processor)
> +{
> +   return (rscreen->debug_flags & DBG_CHECK_IR) ||
> +  r600_can_dump_shader(rscreen, processor);
> +}
> +
>  void r600_screen_clear_buffer(struct r600_common_screen *rscreen, struct 
> pipe_resource *dst,
>   uint64_t offset, uint64_t size, unsigned value,
>   enum r600_coherency coher)
>  {
> struct r600_common_context *rctx = (struct 
> r600_common_context*)rscreen->aux_context;
>
> pipe_mutex_lock(rscreen->aux_context_lock);
> rctx->clear_buffer(>b, dst, offset, size, value, coher);
> rscreen->aux_context->flush(rscreen->aux_context, NULL, 0);
> pipe_mutex_unlock(rscreen->aux_context_lock);
> diff --git a/src/gallium/drivers/radeon/r600_pipe_common.h 
> b/src/gallium/drivers/radeon/r600_pipe_common.h
> index f23f1c4..c836ab1 100644
> --- a/src/gallium/drivers/radeon/r600_pipe_common.h
> +++ b/src/gallium/drivers/radeon/r600_pipe_common.h
> @@ -71,20 +71,21 @@
>  #define DBG_VS (1 << 6)
>  #define DBG_GS (1 << 7)
>  #define DBG_PS (1 << 8)
>  #define DBG_CS (1 << 9)
>  #define DBG_TCS(1 << 10)
>  #define DBG_TES(1 << 11)
>  #define DBG_NO_IR  (1 << 12)
>  #define DBG_NO_TGSI(1 << 13)
>  #define DBG_NO_ASM (1 << 14)
>  #define DBG_PREOPT_IR  (1 << 15)
> +#define DBG_CHECK_IR   (1 << 16)
>  /* gaps */
>  #define DBG_TEST_DMA   (1 << 20)
>  /* Bits 21-31 are reserved for the r600g driver. */
>  /* features */
>  #define DBG_NO_ASYNC_DMA   (1llu << 32)
>  #define DBG_NO_HYPERZ  (1llu << 33)
>  #define DBG_NO_DISCARD_RANGE   (1llu << 34)
>  #define DBG_NO_2D_TILING   (1llu << 35)
>  #define DBG_NO_TILING  (1llu << 36)
>  #define DBG_SWITCH_ON_EOP  (1llu << 37)
> @@ -714,20 +715,22 @@ bool r600_common_screen_init(struct r600_common_screen 
> *rscreen,
>  void r600_destroy_common_screen(struct 

Re: [Mesa-dev] [Mesa-stable] [PATCH] egl/drm, gallium: replace all calls to dup(2) with fcntl(F_DUPFD_CLOEXEC)

[Emil Velikov]

On 30 September 2016 at 06:47, Matt Whitlock
 wrote:
> Without this fix, duplicated file descriptors leak into child processes.
> See commit aaac913e901229d11a1894f6aaf646de6b1a542c for one instance
> where the same fix was employed.
>
> Cc: 
> Signed-off-by: Matt Whitlock 
> ---
>  src/egl/drivers/dri2/platform_android.c | 3 ++-
>  src/gallium/auxiliary/vl/vl_winsys_drm.c| 3 ++-
>  src/gallium/state_trackers/dri/dri2.c   | 5 +++--
>  src/gallium/state_trackers/xa/xa_tracker.c  | 3 ++-
>  src/gallium/winsys/nouveau/drm/nouveau_drm_winsys.c | 3 ++-
>  src/gallium/winsys/radeon/drm/radeon_drm_winsys.c   | 3 ++-
>  src/gallium/winsys/svga/drm/vmw_screen.c| 3 ++-
>  src/gallium/winsys/vc4/drm/vc4_drm_winsys.c | 3 ++-
>  src/gallium/winsys/virgl/drm/virgl_drm_winsys.c | 2 +-
>  9 files changed, 18 insertions(+), 10 deletions(-)
>
Being the author of some of these - thanks for correction.
Out of curiosity - did you notice some of these by inspection or you
were hit my the leak ?

As the above list, and lengthy one-line summary, indicates this
could/should be split up a bit, even though it's quite trivial fix.
Please do either - one per subsystem (file effectively) or egl,
gallium/auxiliary, st/dri, st/xa & gallium/winsys ?

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

Re: [Mesa-dev] [PATCH 6/6] virgl: use the new parent/child pools for transfers

[Marek Olšák]

On Fri, Sep 30, 2016 at 3:00 PM, Nicolai Hähnle  wrote:
> On 30.09.2016 14:58, Marek Olšák wrote:
>>
>> For patches 2-6:
>>
>> Reviewed-by: Marek Olšák 
>
>
> Thanks.
>
>> For patch 1, you'll have to decide whether atomicity is necessary, but
>> at least p_atomic_read and p_atomic_set shouldn't be used on intptr_t.
>
>
> I do believe atomicity is necessary. Maybe the right solution is to change
> u_atomic so that p_atomic_read/set do what they advertise?

Yes if you know how to do that.

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

Re: [Mesa-dev] [Mesa-announce] Mesa 13.0.0 release plan (Was Re: Mesa 12.1.0 release plan (Was Re: Next Mesa release, anyone?))

[Marek Olšák]

On Fri, Sep 30, 2016 at 3:23 PM, Brian Paul  wrote:
> On 09/30/2016 04:59 AM, Emil Velikov wrote:
>>
>> On 30 September 2016 at 03:31, Timothy Arceri
>>  wrote:
>>>
>>> On Thu, 2016-09-29 at 19:17 -0700, Jason Ekstrand wrote:
>>>
>>> On Sep 29, 2016 5:14 PM, "Timothy Arceri" 
>>> wrote:


 On Thu, 2016-09-29 at 15:56 +0100, Emil Velikov wrote:
>
> On 28 September 2016 at 19:53, Marek Olšák  wrote:
>>
>>
>> Hi,
>>
>> It's been almost 4 months since the 12.0 branch was created, and
>> soon
>> it will have been 3 months since Mesa 12.0 was released.
>>
>> Is there any reason we haven't created the stable branch yet?
>>
>> Ideally, we would time the release so that it's 1-2 months before
>> fall
>> distribution releases.
>>
>
> Thanks Marek !
>
> In all honesty I was secretly hoping that we'll get Dave/Bas RADV for
> 12.1.


 I believe the release should be 13?? Core Mesa and the Intel driver
 have reached 4.4 this release also core Mesa is now at 4.5 despite not
 being enabled anywhere.
>>>
>>>
>>> My personal preference, for whatever it's worth, would be to call it
>>> 12.1.
>>> The 12.0 release was the biggest release we've had in a long time and it
>>> seems odd to me to jump to 13.0 right away when we really haven't done
>>> much
>>> at all in terms of new features. (I think it's only 2 or 3 desktop
>>> features
>>> in the case of Intel.  A bit more on the ES side I guess).
>>>
>>>
>>> My understanding is the major version has only ever been bumped when full
>>> support for a new desktop OpenGL version has been reached regardless of
>>> the
>>> number of extensions enabled. We did the same thing going from 8.0 > 9.0
>>> were as the 7 release went all the way to 7.11 over a 4 year period. It
>>> seems odd to change the way we bump versions at this point in time,
>>> although
>>> in future maybe it will need to be based on Vulkin versions also.
>>>
>> Brain freeze - seem to miss-remember that enhanced layouts (thus 4.4)
>> landed after the branch point.
>> That plus the ES3.1/ES3.2, compat for the desktop GL, (by Ilia/Ken)
>> does take us to 13.0.
>>
>> At the end of the day it's just a number albeit being the "unlucky" one.
>>
>> If we get a consensus amongst the majority of devs we can change the
>> versioning scheme. But for that let's do so in a ~weeks time - after
>> the branchpoint.
>
>
> I'd say to go to 13.0 if we're now supporting GL 4.4.  That'd follow the
> general pattern.

Intel support all features for GL 4.5, but I don't know if they expose
it. That would mean we would be stuck with number 13 forever if GL 4.5
were to be the last GL spec. We clearly need a new versioning scheme.

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

Re: [Mesa-dev] Mesa 12.1.0 release plan (Was Re: Next Mesa release, anyone?)

[Bas Nieuwenhuizen]

On Fri, Sep 30, 2016 at 3:31 AM, Dave Airlie  wrote:
> On 30 September 2016 at 01:07, Jason Ekstrand  wrote:
>> On Sep 29, 2016 7:56 AM, "Emil Velikov"  wrote:
>>>
>>> On 28 September 2016 at 19:53, Marek Olšák  wrote:
>>> > Hi,
>>> >
>>> > It's been almost 4 months since the 12.0 branch was created, and soon
>>> > it will have been 3 months since Mesa 12.0 was released.
>>> >
>>> > Is there any reason we haven't created the stable branch yet?
>>> >
>>> > Ideally, we would time the release so that it's 1-2 months before fall
>>> > distribution releases.
>>> >
>>>
>>> Thanks Marek !
>>>
>>> In all honesty I was secretly hoping that we'll get Dave/Bas RADV for
>>> 12.1. With the topic of which would be 'the default' Vulkan driver for
>>> ATI/AMD hardware to be considered at a later stage.
>>
>> If they have even close to the amount of work we had to get it merged, I
>> don't think that's at all realistic.  Then again, Dave is the one who wants
>> to have a Vulkan driver for AMD hardware that he can package and ship so
>> I'll let him decide how badly he wants it in this release.
>>
>>> That said here are the tentative dates:
>>>
>>> Oct 7/14 2016 - Feature freeze/Release candidate 1
>>> Oct 14/21 2016 - Release candidate 2
>>> Oct 21/28 2016 - Release candidate 3/final release
>>>
>>> Fwiw I'm still in favour of getting RADV in even if it's not
>>> perfect/feature complete. Devs, let me know if there's a "must have"
>>> feature that we want in 12.1.
>
> The main problem I have with merging radv is the whole conformance testing
> end of it.
>
> It's probably fine if I just make a big printf on device creation that RADV
> isn't a conformant vulkan implementation yet. Sorta like what Intel do on the
> older GPUs.
>
> Otherwise I don't think merging it is a big job, it's 30,000 lines of 
> standalone
> code, I've already merged the prereq patches, and I think any code sharing
> should happen in tree.

I think we also need to improve the configure.ac changes a bit before
merging. I think I used the llvm version check before definition or
something and haven't gotten around to fixing that yet.

- Bas

>
> Dave.
> ___
> 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

Re: [Mesa-dev] Mesa 13.0.0 release plan (Was Re: Mesa 12.1.0 release plan (Was Re: Next Mesa release, anyone?))

[Brian Paul]

On 09/30/2016 04:59 AM, Emil Velikov wrote:

On 30 September 2016 at 03:31, Timothy Arceri
 wrote:

On Thu, 2016-09-29 at 19:17 -0700, Jason Ekstrand wrote:

On Sep 29, 2016 5:14 PM, "Timothy Arceri" 
wrote:


On Thu, 2016-09-29 at 15:56 +0100, Emil Velikov wrote:

On 28 September 2016 at 19:53, Marek Olšák  wrote:


Hi,

It's been almost 4 months since the 12.0 branch was created, and
soon
it will have been 3 months since Mesa 12.0 was released.

Is there any reason we haven't created the stable branch yet?

Ideally, we would time the release so that it's 1-2 months before
fall
distribution releases.



Thanks Marek !

In all honesty I was secretly hoping that we'll get Dave/Bas RADV for
12.1.


I believe the release should be 13?? Core Mesa and the Intel driver
have reached 4.4 this release also core Mesa is now at 4.5 despite not
being enabled anywhere.


My personal preference, for whatever it's worth, would be to call it 12.1.
The 12.0 release was the biggest release we've had in a long time and it
seems odd to me to jump to 13.0 right away when we really haven't done much
at all in terms of new features. (I think it's only 2 or 3 desktop features
in the case of Intel.  A bit more on the ES side I guess).


My understanding is the major version has only ever been bumped when full
support for a new desktop OpenGL version has been reached regardless of the
number of extensions enabled. We did the same thing going from 8.0 > 9.0
were as the 7 release went all the way to 7.11 over a 4 year period. It
seems odd to change the way we bump versions at this point in time, although
in future maybe it will need to be based on Vulkin versions also.


Brain freeze - seem to miss-remember that enhanced layouts (thus 4.4)
landed after the branch point.
That plus the ES3.1/ES3.2, compat for the desktop GL, (by Ilia/Ken)
does take us to 13.0.

At the end of the day it's just a number albeit being the "unlucky" one.

If we get a consensus amongst the majority of devs we can change the
versioning scheme. But for that let's do so in a ~weeks time - after
the branchpoint.


I'd say to go to 13.0 if we're now supporting GL 4.4.  That'd follow the 
general pattern.


I'm updating docs/intro.html with version 10.x - 12.x info.

-Brian

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

[Mesa-dev] [PATCH] docs: update the list of Mesa major versions and API support

[Brian Paul]

---
 docs/intro.html | 25 +
 1 file changed, 25 insertions(+)

diff --git a/docs/intro.html b/docs/intro.html
index 4b36562..6c91e3f 100644
--- a/docs/intro.html
+++ b/docs/intro.html
@@ -173,6 +173,27 @@ of the OpenGL specification is implemented.
 
 
 
+Version 12.x features
+
+Version 12.x of Mesa implements the OpenGL 4.3 API, but not all drivers
+support OpenGL 4.3.
+
+
+
+Version 11.x features
+
+Version 11.x of Mesa implements the OpenGL 4.1 API, but not all drivers
+support OpenGL 4.1.
+
+
+
+Version 10.x features
+
+Version 10.x of Mesa implements the OpenGL 3.3 API, but not all drivers
+support OpenGL 3.3.
+
+
+
 Version 9.x features
 
 Version 9.x of Mesa implements the OpenGL 3.1 API.
@@ -182,6 +203,10 @@ community contributed features required for OpenGL 3.1.  
The primary
 features added since the Mesa 8.0 release are
 GL_ARB_texture_buffer_object and GL_ARB_uniform_buffer_object.
 
+
+Version 9.0 of Mesa also included the first release of the Clover state
+tracker for OpenCL.
+
 
 
 Version 8.x features
-- 
1.9.1

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

Re: [Mesa-dev] [PATCH v2] util/slab: re-design to allow migration between pools (v2)

[Bas Nieuwenhuizen]

On Fri, Sep 30, 2016 at 2:13 PM, Marek Olšák  wrote:
> intptr_t reads and writes aren't atomic. p_atomic_set and
> p_atomic_read functions don't do anything for atomicity. See:
>
> #define p_atomic_set(_v, _i) (*(_v) = (_i))
> #define p_atomic_read(_v) (*(_v))

That implementation seems bogus to me, as the compiler sees none of
them as atomic and therefore the compiler can do strange stuff.

why are intptr_t reads/writes less atomic than int32_t? IIRC on x86_64
aligned 64-bit accesses are atomic, and on x86 intptr_t is just 32
bits.

- Bas

>
> Marek
>
> On Wed, Sep 28, 2016 at 9:47 AM, Nicolai Hähnle  wrote:
>> From: Nicolai Hähnle 
>>
>> This is basically a re-write of the slab allocator into a design where
>> multiple child pools are linked to a parent pool. The intention is that
>> every (GL, pipe) context has its own child pool, while the corresponding
>> parent pool is held by the winsys or screen, or possibly the GL share group.
>>
>> The fast path is still used when objects are freed by the same child pool
>> that allocated them. However, it is now also possible to free an object in a
>> different pool, as long as they belong to the same parent. Objects also
>> survive the destruction of the (child) pool from which they were allocated.
>>
>> The slow path will return freed objects to the child pool from which they
>> were originally allocated. If that child pool was destroyed, the 
>> corresponding
>> page is considered an orphan and will be freed once all objects in it have
>> been freed.
>>
>> This allocation pattern is required for pipe_transfers that correspond to
>> (GL) buffer object mappings when the mapping is created in one context
>> which is later destroyed while other contexts of the same share group live
>> on -- see the bug report referenced below.
>>
>> Note that individual drivers do need to migrate to the new interface in
>> order to benefit and fix the bug.
>>
>> v2: use singly-linked lists everywhere
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97894
>> ---
>>  src/util/slab.c | 285 
>> +---
>>  src/util/slab.h |  62 +---
>>  2 files changed, 258 insertions(+), 89 deletions(-)
>>
>> diff --git a/src/util/slab.c b/src/util/slab.c
>> index af75152..35540bd 100644
>> --- a/src/util/slab.c
>> +++ b/src/util/slab.c
>> @@ -16,166 +16,303 @@
>>   * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
>> OR
>>   * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
>>   * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
>>   * THE AUTHOR(S) AND/OR THEIR SUPPLIERS BE LIABLE FOR ANY CLAIM,
>>   * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
>>   * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
>>   * USE OR OTHER DEALINGS IN THE SOFTWARE. */
>>
>>  #include "slab.h"
>>  #include "macros.h"
>> -#include "simple_list.h"
>> +#include "u_atomic.h"
>>  #include 
>>  #include 
>>  #include 
>>
>>  #define ALIGN(value, align) (((value) + (align) - 1) & ~((align) - 1))
>>
>> +#define SLAB_MAGIC_ALLOCATED 0xcafe4321
>> +#define SLAB_MAGIC_FREE 0x7ee01234
>> +
>>  #ifdef DEBUG
>> -#define SLAB_MAGIC 0xcafe4321
>> -#define SET_MAGIC(element)   (element)->magic = SLAB_MAGIC
>> -#define CHECK_MAGIC(element) assert((element)->magic == SLAB_MAGIC)
>> +#define SET_MAGIC(element, value)   (element)->magic = (value)
>> +#define CHECK_MAGIC(element, value) assert((element)->magic == (value))
>>  #else
>> -#define SET_MAGIC(element)
>> -#define CHECK_MAGIC(element)
>> +#define SET_MAGIC(element, value)
>> +#define CHECK_MAGIC(element, value)
>>  #endif
>>
>>  /* One array element within a big buffer. */
>>  struct slab_element_header {
>> -   /* The next free element. */
>> -   struct slab_element_header *next_free;
>> +   /* The next element in the free or migrated list. */
>> +   struct slab_element_header *next;
>> +
>> +   /* This is either
>> +* - a pointer to the child pool to which this element belongs, or
>> +* - a pointer to the orphaned page of the element, with the least
>> +*   significant bit set to 1.
>> +*/
>> +   intptr_t owner;
>>
>>  #ifdef DEBUG
>> -   /* Use intptr_t to keep the header aligned to a pointer size. */
>> intptr_t magic;
>>  #endif
>>  };
>>
>> +/* The page is an array of allocations in one block. */
>> +struct slab_page_header {
>> +   union {
>> +  /* Next page in the same child pool. */
>> +  struct slab_page_header *next;
>> +
>> +  /* Number of remaining, non-freed elements (for orphaned pages). */
>> +  unsigned num_remaining;
>> +   } u;
>> +   /* Memory after the last member is dedicated to the page itself.
>> +* The allocated size is always larger than this structure.
>> +*/
>> +};
>> +
>> +
>>  static struct slab_element_header *
>> -slab_get_element(struct slab_mempool 

[Mesa-dev] [Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=97879

Vedran Rodic  changed:

   What|Removed |Added

 CC||vro...@gmail.com

-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 6/6] virgl: use the new parent/child pools for transfers

[Nicolai Hähnle]

On 30.09.2016 14:58, Marek Olšák wrote:

For patches 2-6:

Reviewed-by: Marek Olšák 


Thanks.


For patch 1, you'll have to decide whether atomicity is necessary, but
at least p_atomic_read and p_atomic_set shouldn't be used on intptr_t.


I do believe atomicity is necessary. Maybe the right solution is to 
change u_atomic so that p_atomic_read/set do what they advertise?


Cheers,
Nicolai



Marek



On Tue, Sep 27, 2016 at 8:21 PM, Nicolai Hähnle  wrote:

From: Nicolai Hähnle 

---
 src/gallium/drivers/virgl/virgl_buffer.c  | 4 ++--
 src/gallium/drivers/virgl/virgl_context.c | 5 ++---
 src/gallium/drivers/virgl/virgl_context.h | 2 +-
 src/gallium/drivers/virgl/virgl_screen.c  | 4 
 src/gallium/drivers/virgl/virgl_screen.h  | 3 +++
 src/gallium/drivers/virgl/virgl_texture.c | 4 ++--
 6 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/src/gallium/drivers/virgl/virgl_buffer.c 
b/src/gallium/drivers/virgl/virgl_buffer.c
index de99796..2e63aeb 100644
--- a/src/gallium/drivers/virgl/virgl_buffer.c
+++ b/src/gallium/drivers/virgl/virgl_buffer.c
@@ -55,21 +55,21 @@ static void *virgl_buffer_transfer_map(struct pipe_context 
*ctx,
bool doflushwait = false;

if ((usage & PIPE_TRANSFER_READ) && (vbuf->on_list == TRUE))
   doflushwait = true;
else
   doflushwait = virgl_res_needs_flush_wait(vctx, >base, usage);

if (doflushwait)
   ctx->flush(ctx, NULL, 0);

-   trans = slab_alloc_st(>texture_transfer_pool);
+   trans = slab_alloc(>texture_transfer_pool);
if (!trans)
   return NULL;

trans->base.resource = resource;
trans->base.level = level;
trans->base.usage = usage;
trans->base.box = *box;
trans->base.stride = 0;
trans->base.layer_stride = 0;

@@ -107,21 +107,21 @@ static void virgl_buffer_transfer_unmap(struct 
pipe_context *ctx,
   if (!(transfer->usage & PIPE_TRANSFER_FLUSH_EXPLICIT)) {
  struct virgl_screen *vs = virgl_screen(ctx->screen);
  vbuf->base.clean = FALSE;
  vctx->num_transfers++;
  vs->vws->transfer_put(vs->vws, vbuf->base.hw_res,
>box, trans->base.stride, 
trans->base.layer_stride, trans->offset, transfer->level);

   }
}

-   slab_free_st(>texture_transfer_pool, trans);
+   slab_free(>texture_transfer_pool, trans);
 }

 static void virgl_buffer_transfer_flush_region(struct pipe_context *ctx,
struct pipe_transfer *transfer,
const struct pipe_box *box)
 {
struct virgl_context *vctx = virgl_context(ctx);
struct virgl_buffer *vbuf = virgl_buffer(transfer->resource);

if (!vbuf->on_list) {
diff --git a/src/gallium/drivers/virgl/virgl_context.c 
b/src/gallium/drivers/virgl/virgl_context.c
index a6c0597..e693a73 100644
--- a/src/gallium/drivers/virgl/virgl_context.c
+++ b/src/gallium/drivers/virgl/virgl_context.c
@@ -855,21 +855,21 @@ virgl_context_destroy( struct pipe_context *ctx )
vctx->framebuffer.zsbuf = NULL;
vctx->framebuffer.nr_cbufs = 0;
virgl_encoder_destroy_sub_ctx(vctx, vctx->hw_sub_ctx_id);
virgl_flush_eq(vctx, vctx);

rs->vws->cmd_buf_destroy(vctx->cbuf);
if (vctx->uploader)
   u_upload_destroy(vctx->uploader);
util_primconvert_destroy(vctx->primconvert);

-   slab_destroy(>texture_transfer_pool);
+   slab_destroy_child(>texture_transfer_pool);
FREE(vctx);
 }

 struct pipe_context *virgl_context_create(struct pipe_screen *pscreen,
   void *priv,
   unsigned flags)
 {
struct virgl_context *vctx;
struct virgl_screen *rs = virgl_screen(pscreen);
vctx = CALLOC_STRUCT(virgl_context);
@@ -936,22 +936,21 @@ struct pipe_context *virgl_context_create(struct 
pipe_screen *pscreen,

vctx->base.resource_copy_region = virgl_resource_copy_region;
vctx->base.flush_resource = virgl_flush_resource;
vctx->base.blit =  virgl_blit;

virgl_init_context_resource_functions(>base);
virgl_init_query_functions(vctx);
virgl_init_so_functions(vctx);

list_inithead(>to_flush_bufs);
-   slab_create(>texture_transfer_pool, sizeof(struct virgl_transfer),
-16);
+   slab_create_child(>texture_transfer_pool, rs->texture_transfer_pool);

vctx->primconvert = util_primconvert_create(>base, 
rs->caps.caps.v1.prim_mask);
vctx->uploader = u_upload_create(>base, 1024 * 1024,
  PIPE_BIND_INDEX_BUFFER, 
PIPE_USAGE_STREAM);
if (!vctx->uploader)
goto fail;

vctx->hw_sub_ctx_id = rs->sub_ctx_id++;
virgl_encoder_create_sub_ctx(vctx, vctx->hw_sub_ctx_id);

diff --git a/src/gallium/drivers/virgl/virgl_context.h 
b/src/gallium/drivers/virgl/virgl_context.h
index 3b9901f..597ed49 100644
--- a/src/gallium/drivers/virgl/virgl_context.h
+++ 

Re: [Mesa-dev] [PATCH v2] egl: stop claiming support for pbuffer + msaa

[Emil Velikov]

On 30 September 2016 at 07:32, Tapani Pälli  wrote:
> This fixes a crash in egl-create-msaa-pbuffer-surface Piglit test
> and same crash in many dEQP EGL tests.
>
> I also found that some Qt example did a workaround because of this
> crash: https://bugreports.qt.io/browse/QTBUG-47509
>
> v2: Ian pointed out that v1 removed support for all multisample
> configs, including window ones. This one removes pbuffer bit
> when adding configs, now only pbuffer+msaa gets rejected and
> window+msaa continues to work. Fixed also comment (Emil)
>
> Signed-off-by: Tapani Pälli 
> Cc: mesa-sta...@lists.freedesktop.org
> ---
>  src/egl/drivers/dri2/egl_dri2.c | 9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
> index 8e376e3..803627d 100644
> --- a/src/egl/drivers/dri2/egl_dri2.c
> +++ b/src/egl/drivers/dri2/egl_dri2.c
> @@ -320,6 +320,15 @@ dri2_add_config(_EGLDisplay *disp, const __DRIconfig 
> *dri_config, int id,
>surface_type &= ~EGL_PIXMAP_BIT;
> }
>
> +   /* No support for pbuffer + MSAA for now.
> +*
> +* XXX TODO: pbuffer + MSAA does not work and causes crashes.
> +* See QT bugreport: https://bugreports.qt.io/browse/QTBUG-47509
> +*/
> +   if (base.Samples) {
> +  surface_type &= ~EGL_PBUFFER_BIT;
> +   }
> +
I'm slightly cautious if this won't cause unexpected side effects (due
to _eglFilterArray() and/or other interaction), so let's have this
soak in master for a bit before picking to stable.

That aside the patch is (for real this time)
Reviewed-by: Emil Velikov 

Before pushing please double-check that piglit/deqp/cts doesn't get upset.

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

Re: [Mesa-dev] [PATCH 6/6] virgl: use the new parent/child pools for transfers

[Marek Olšák]

For patches 2-6:

Reviewed-by: Marek Olšák 

For patch 1, you'll have to decide whether atomicity is necessary, but
at least p_atomic_read and p_atomic_set shouldn't be used on intptr_t.

Marek



On Tue, Sep 27, 2016 at 8:21 PM, Nicolai Hähnle  wrote:
> From: Nicolai Hähnle 
>
> ---
>  src/gallium/drivers/virgl/virgl_buffer.c  | 4 ++--
>  src/gallium/drivers/virgl/virgl_context.c | 5 ++---
>  src/gallium/drivers/virgl/virgl_context.h | 2 +-
>  src/gallium/drivers/virgl/virgl_screen.c  | 4 
>  src/gallium/drivers/virgl/virgl_screen.h  | 3 +++
>  src/gallium/drivers/virgl/virgl_texture.c | 4 ++--
>  6 files changed, 14 insertions(+), 8 deletions(-)
>
> diff --git a/src/gallium/drivers/virgl/virgl_buffer.c 
> b/src/gallium/drivers/virgl/virgl_buffer.c
> index de99796..2e63aeb 100644
> --- a/src/gallium/drivers/virgl/virgl_buffer.c
> +++ b/src/gallium/drivers/virgl/virgl_buffer.c
> @@ -55,21 +55,21 @@ static void *virgl_buffer_transfer_map(struct 
> pipe_context *ctx,
> bool doflushwait = false;
>
> if ((usage & PIPE_TRANSFER_READ) && (vbuf->on_list == TRUE))
>doflushwait = true;
> else
>doflushwait = virgl_res_needs_flush_wait(vctx, >base, usage);
>
> if (doflushwait)
>ctx->flush(ctx, NULL, 0);
>
> -   trans = slab_alloc_st(>texture_transfer_pool);
> +   trans = slab_alloc(>texture_transfer_pool);
> if (!trans)
>return NULL;
>
> trans->base.resource = resource;
> trans->base.level = level;
> trans->base.usage = usage;
> trans->base.box = *box;
> trans->base.stride = 0;
> trans->base.layer_stride = 0;
>
> @@ -107,21 +107,21 @@ static void virgl_buffer_transfer_unmap(struct 
> pipe_context *ctx,
>if (!(transfer->usage & PIPE_TRANSFER_FLUSH_EXPLICIT)) {
>   struct virgl_screen *vs = virgl_screen(ctx->screen);
>   vbuf->base.clean = FALSE;
>   vctx->num_transfers++;
>   vs->vws->transfer_put(vs->vws, vbuf->base.hw_res,
> >box, trans->base.stride, 
> trans->base.layer_stride, trans->offset, transfer->level);
>
>}
> }
>
> -   slab_free_st(>texture_transfer_pool, trans);
> +   slab_free(>texture_transfer_pool, trans);
>  }
>
>  static void virgl_buffer_transfer_flush_region(struct pipe_context *ctx,
> struct pipe_transfer 
> *transfer,
> const struct pipe_box *box)
>  {
> struct virgl_context *vctx = virgl_context(ctx);
> struct virgl_buffer *vbuf = virgl_buffer(transfer->resource);
>
> if (!vbuf->on_list) {
> diff --git a/src/gallium/drivers/virgl/virgl_context.c 
> b/src/gallium/drivers/virgl/virgl_context.c
> index a6c0597..e693a73 100644
> --- a/src/gallium/drivers/virgl/virgl_context.c
> +++ b/src/gallium/drivers/virgl/virgl_context.c
> @@ -855,21 +855,21 @@ virgl_context_destroy( struct pipe_context *ctx )
> vctx->framebuffer.zsbuf = NULL;
> vctx->framebuffer.nr_cbufs = 0;
> virgl_encoder_destroy_sub_ctx(vctx, vctx->hw_sub_ctx_id);
> virgl_flush_eq(vctx, vctx);
>
> rs->vws->cmd_buf_destroy(vctx->cbuf);
> if (vctx->uploader)
>u_upload_destroy(vctx->uploader);
> util_primconvert_destroy(vctx->primconvert);
>
> -   slab_destroy(>texture_transfer_pool);
> +   slab_destroy_child(>texture_transfer_pool);
> FREE(vctx);
>  }
>
>  struct pipe_context *virgl_context_create(struct pipe_screen *pscreen,
>void *priv,
>unsigned flags)
>  {
> struct virgl_context *vctx;
> struct virgl_screen *rs = virgl_screen(pscreen);
> vctx = CALLOC_STRUCT(virgl_context);
> @@ -936,22 +936,21 @@ struct pipe_context *virgl_context_create(struct 
> pipe_screen *pscreen,
>
> vctx->base.resource_copy_region = virgl_resource_copy_region;
> vctx->base.flush_resource = virgl_flush_resource;
> vctx->base.blit =  virgl_blit;
>
> virgl_init_context_resource_functions(>base);
> virgl_init_query_functions(vctx);
> virgl_init_so_functions(vctx);
>
> list_inithead(>to_flush_bufs);
> -   slab_create(>texture_transfer_pool, sizeof(struct virgl_transfer),
> -16);
> +   slab_create_child(>texture_transfer_pool, 
> rs->texture_transfer_pool);
>
> vctx->primconvert = util_primconvert_create(>base, 
> rs->caps.caps.v1.prim_mask);
> vctx->uploader = u_upload_create(>base, 1024 * 1024,
>   PIPE_BIND_INDEX_BUFFER, 
> PIPE_USAGE_STREAM);
> if (!vctx->uploader)
> goto fail;
>
> vctx->hw_sub_ctx_id = rs->sub_ctx_id++;
> virgl_encoder_create_sub_ctx(vctx, vctx->hw_sub_ctx_id);
>
> diff --git a/src/gallium/drivers/virgl/virgl_context.h 
> b/src/gallium/drivers/virgl/virgl_context.h
> index 3b9901f..597ed49 100644
> --- a/src/gallium/drivers/virgl/virgl_context.h
> +++ 

[Mesa-dev] [PATCH] egl: remove explicit config_id management from dri2_add_config()

[Emil Velikov]

From: Emil Velikov 

Currently we only saved the id to memcpy the whole _EGLConfig to write
back the exact same id value.

Remove the unneeded and confusing/misleading code.

Signed-off-by: Emil Velikov 
---
 src/egl/drivers/dri2/egl_dri2.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 1659af6..39e6244 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -166,7 +166,6 @@ dri2_add_config(_EGLDisplay *disp, const __DRIconfig 
*dri_config, int id,
unsigned int dri_masks[4] = { 0, 0, 0, 0 };
_EGLConfig *matching_config;
EGLint num_configs = 0;
-   EGLint config_id;
int i;
 
dri2_dpy = disp->DriverData;
@@ -278,7 +277,6 @@ dri2_add_config(_EGLDisplay *disp, const __DRIconfig 
*dri_config, int id,
   return NULL;
}
 
-   config_id = base.ConfigID;
base.ConfigID= EGL_DONT_CARE;
base.SurfaceType = EGL_DONT_CARE;
num_configs = _eglFilterArray(disp->Configs, (void **) _config, 1,
@@ -307,7 +305,6 @@ dri2_add_config(_EGLDisplay *disp, const __DRIconfig 
*dri_config, int id,
 
   memcpy(>base, , sizeof base);
   conf->base.SurfaceType = 0;
-  conf->base.ConfigID = config_id;
 
   _eglLinkConfig(>base);
}
-- 
2.9.3

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

Re: [Mesa-dev] [PATCH v2] util/slab: re-design to allow migration between pools (v2)

[Marek Olšák]

intptr_t reads and writes aren't atomic. p_atomic_set and
p_atomic_read functions don't do anything for atomicity. See:

#define p_atomic_set(_v, _i) (*(_v) = (_i))
#define p_atomic_read(_v) (*(_v))

Marek

On Wed, Sep 28, 2016 at 9:47 AM, Nicolai Hähnle  wrote:
> From: Nicolai Hähnle 
>
> This is basically a re-write of the slab allocator into a design where
> multiple child pools are linked to a parent pool. The intention is that
> every (GL, pipe) context has its own child pool, while the corresponding
> parent pool is held by the winsys or screen, or possibly the GL share group.
>
> The fast path is still used when objects are freed by the same child pool
> that allocated them. However, it is now also possible to free an object in a
> different pool, as long as they belong to the same parent. Objects also
> survive the destruction of the (child) pool from which they were allocated.
>
> The slow path will return freed objects to the child pool from which they
> were originally allocated. If that child pool was destroyed, the corresponding
> page is considered an orphan and will be freed once all objects in it have
> been freed.
>
> This allocation pattern is required for pipe_transfers that correspond to
> (GL) buffer object mappings when the mapping is created in one context
> which is later destroyed while other contexts of the same share group live
> on -- see the bug report referenced below.
>
> Note that individual drivers do need to migrate to the new interface in
> order to benefit and fix the bug.
>
> v2: use singly-linked lists everywhere
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97894
> ---
>  src/util/slab.c | 285 
> +---
>  src/util/slab.h |  62 +---
>  2 files changed, 258 insertions(+), 89 deletions(-)
>
> diff --git a/src/util/slab.c b/src/util/slab.c
> index af75152..35540bd 100644
> --- a/src/util/slab.c
> +++ b/src/util/slab.c
> @@ -16,166 +16,303 @@
>   * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
>   * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
>   * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
>   * THE AUTHOR(S) AND/OR THEIR SUPPLIERS BE LIABLE FOR ANY CLAIM,
>   * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
>   * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
>   * USE OR OTHER DEALINGS IN THE SOFTWARE. */
>
>  #include "slab.h"
>  #include "macros.h"
> -#include "simple_list.h"
> +#include "u_atomic.h"
>  #include 
>  #include 
>  #include 
>
>  #define ALIGN(value, align) (((value) + (align) - 1) & ~((align) - 1))
>
> +#define SLAB_MAGIC_ALLOCATED 0xcafe4321
> +#define SLAB_MAGIC_FREE 0x7ee01234
> +
>  #ifdef DEBUG
> -#define SLAB_MAGIC 0xcafe4321
> -#define SET_MAGIC(element)   (element)->magic = SLAB_MAGIC
> -#define CHECK_MAGIC(element) assert((element)->magic == SLAB_MAGIC)
> +#define SET_MAGIC(element, value)   (element)->magic = (value)
> +#define CHECK_MAGIC(element, value) assert((element)->magic == (value))
>  #else
> -#define SET_MAGIC(element)
> -#define CHECK_MAGIC(element)
> +#define SET_MAGIC(element, value)
> +#define CHECK_MAGIC(element, value)
>  #endif
>
>  /* One array element within a big buffer. */
>  struct slab_element_header {
> -   /* The next free element. */
> -   struct slab_element_header *next_free;
> +   /* The next element in the free or migrated list. */
> +   struct slab_element_header *next;
> +
> +   /* This is either
> +* - a pointer to the child pool to which this element belongs, or
> +* - a pointer to the orphaned page of the element, with the least
> +*   significant bit set to 1.
> +*/
> +   intptr_t owner;
>
>  #ifdef DEBUG
> -   /* Use intptr_t to keep the header aligned to a pointer size. */
> intptr_t magic;
>  #endif
>  };
>
> +/* The page is an array of allocations in one block. */
> +struct slab_page_header {
> +   union {
> +  /* Next page in the same child pool. */
> +  struct slab_page_header *next;
> +
> +  /* Number of remaining, non-freed elements (for orphaned pages). */
> +  unsigned num_remaining;
> +   } u;
> +   /* Memory after the last member is dedicated to the page itself.
> +* The allocated size is always larger than this structure.
> +*/
> +};
> +
> +
>  static struct slab_element_header *
> -slab_get_element(struct slab_mempool *pool,
> +slab_get_element(struct slab_parent_pool *parent,
>   struct slab_page_header *page, unsigned index)
>  {
> return (struct slab_element_header*)
> -  ((uint8_t*)[1] + (pool->element_size * index));
> +  ((uint8_t*)[1] + (parent->element_size * index));
> +}
> +
> +/* The given object/element belongs to an orphaned page (i.e. the owning 
> child
> + * pool has been destroyed). Mark the element as freed and free the whole 
> page
> + * when no 

Re: [Mesa-dev] [PATCH] gallium/hud: Add power sensor support

[Steven Toth]

>
> Reviewed-by: Brian Paul 
>
> and pushed to master.  Thanks.

Thank you Brian.

-- 
Steven Toth - Kernel Labs
http://www.kernellabs.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] gallium/hud: Add support for CPU frequency monitoring

[Steven Toth]

Detect all of the CPUs in the system. Expose metrics
for min, max and current frequency in Hz.

Signed-off-by: Steven Toth 
---
 src/gallium/auxiliary/Makefile.sources  |   1 +
 src/gallium/auxiliary/hud/hud_context.c |  13 ++
 src/gallium/auxiliary/hud/hud_cpufreq.c | 266 
 src/gallium/auxiliary/hud/hud_private.h |   6 +
 4 files changed, 286 insertions(+)
 create mode 100644 src/gallium/auxiliary/hud/hud_cpufreq.c

diff --git a/src/gallium/auxiliary/Makefile.sources 
b/src/gallium/auxiliary/Makefile.sources
index 3d728ae..3fda2eb 100644
--- a/src/gallium/auxiliary/Makefile.sources
+++ b/src/gallium/auxiliary/Makefile.sources
@@ -63,6 +63,7 @@ C_SOURCES := \
hud/hud_context.h \
hud/hud_cpu.c \
hud/hud_nic.c \
+   hud/hud_cpufreq.c \
hud/hud_diskstat.c \
hud/hud_sensors_temp.c \
hud/hud_driver_query.c \
diff --git a/src/gallium/auxiliary/hud/hud_context.c 
b/src/gallium/auxiliary/hud/hud_context.c
index 3445488..5aee30a 100644
--- a/src/gallium/auxiliary/hud/hud_context.c
+++ b/src/gallium/auxiliary/hud/hud_context.c
@@ -1050,6 +1050,18 @@ hud_parse_env_var(struct hud_context *hud, const char 
*env)
  hud_diskstat_graph_install(pane, arg_name, DISKSTAT_WR);
  pane->type = PIPE_DRIVER_QUERY_TYPE_BYTES;
   }
+  else if (sscanf(name, "cpufreq-min-cpu%u", ) == 1) {
+ hud_cpufreq_graph_install(pane, i, CPUFREQ_MINIMUM);
+ pane->type = PIPE_DRIVER_QUERY_TYPE_HZ;
+  }
+  else if (sscanf(name, "cpufreq-cur-cpu%u", ) == 1) {
+ hud_cpufreq_graph_install(pane, i, CPUFREQ_CURRENT);
+ pane->type = PIPE_DRIVER_QUERY_TYPE_HZ;
+  }
+  else if (sscanf(name, "cpufreq-max-cpu%u", ) == 1) {
+ hud_cpufreq_graph_install(pane, i, CPUFREQ_MAXIMUM);
+ pane->type = PIPE_DRIVER_QUERY_TYPE_HZ;
+  }
 #endif
 #if HAVE_LIBSENSORS
   else if (sscanf(name, "sensors_temp_cu-%s", arg_name) == 1) {
@@ -1290,6 +1302,7 @@ print_help(struct pipe_screen *screen)
 #if HAVE_GALLIUM_EXTRA_HUD
hud_get_num_disks(1);
hud_get_num_nics(1);
+   hud_get_num_cpufreq(1);
 #endif
 #if HAVE_LIBSENSORS
hud_get_num_sensors(1);
diff --git a/src/gallium/auxiliary/hud/hud_cpufreq.c 
b/src/gallium/auxiliary/hud/hud_cpufreq.c
new file mode 100644
index 000..1296ece
--- /dev/null
+++ b/src/gallium/auxiliary/hud/hud_cpufreq.c
@@ -0,0 +1,266 @@
+/**
+ *
+ * Copyright (C) 2016 Steven Toth 
+ * Copyright (C) 2016 Zodiac Inflight Innovations
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
+ * IN NO EVENT SHALL THE AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR
+ * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
+ * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
+ * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ **/
+
+#if HAVE_GALLIUM_EXTRA_HUD
+
+/* Purpose:
+ * Reading /sys/devices/system/cpu/cpu?/cpufreq/scaling_???_freq
+ * cpu frequency (KHz), displaying on the HUD in Hz.
+ */
+
+#include "hud/hud_private.h"
+#include "util/list.h"
+#include "os/os_time.h"
+#include "util/u_memory.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define LOCAL_DEBUG 0
+
+struct cpufreq_info
+{
+   struct list_head list;
+   int mode; /* CPUFREQ_MINIMUM, CPUFREQ_CURRENT, CPUFREQ_MAXIMUM */
+   char name[16]; /* EG. cpu0 */
+   int cpu_index;
+
+   /* EG. /sys/devices/system/cpu/cpu?/cpufreq/scaling_cur_freq */
+   char sysfs_filename[128];
+   uint64_t KHz;
+   uint64_t last_time;
+};
+
+static int gcpufreq_count = 0;
+static struct list_head gcpufreq_list;
+
+static struct cpufreq_info *
+find_cfi_by_index(int cpu_index, int mode)
+{
+   list_for_each_entry(struct cpufreq_info, cfi, _list, list) {
+  if (cfi->mode != mode)
+ continue;
+  if (cfi->cpu_index == cpu_index)
+ return cfi;
+   }
+   return 0;
+}
+
+static int
+get_file_value(const char *fn, uint64_t *KHz)

Re: [Mesa-dev] [PATCH] glsl: optimize copy_propagation_elements pass

[Tapani Pälli]

On 09/30/2016 03:18 AM, Ian Romanick wrote:

On 09/29/2016 12:17 AM, Tapani Pälli wrote:


On 09/28/2016 06:14 PM, Ian Romanick wrote:

On 09/16/2016 06:21 PM, Tapani Pälli wrote:

Changes make copy_propagation_elements pass faster, reducing link
time spent in test case of bug 94477. Does not fix the actual issue
but brings down the total time. No regressions seen in CI.


How does this affect the time of a full shader-db run?


Almost none at all, this is the open-source shaders (100 runs):

Difference at 95.0% confidence
0.0312 +/- 0.00502746
1.72566% +/- 0.278068%
(Student's t, pooled s = 0.0181375)

(testing with DOTA-2 shaders gave very similar result)

My assumption is that this really helps only the most pathological cases
like in the bug where list size becomes enormous (thousands of entries).
With just few entries, list is 'fast enough' to walk through anyway (?)

BTW Eric was proposing to just remove this pass. However when testing
what happens on removal I noticed there's functional failures
(arb_gpu_shader5-interpolateAtSample-dynamically-nonuniform starts to
fail), so it seems we are currently dependent on this pass.


There are a bunch of bits of this that are confusing to me.  I think
some high-level explanation about which hash tables the acp_ref can be
in, which lists it can be in, and how they relate would help.  I've
pointed out a couple of the confusing bits below.


Signed-off-by: Tapani Pälli 
---

For performance measurements, Martina reported in the bug 8x speedup
to the test case shader link time when using this patch together with
commit 2cd02e30d2e1677762d34f1831b8e609970ef0f3

 .../glsl/opt_copy_propagation_elements.cpp | 187
-
 1 file changed, 145 insertions(+), 42 deletions(-)

diff --git a/src/compiler/glsl/opt_copy_propagation_elements.cpp
b/src/compiler/glsl/opt_copy_propagation_elements.cpp
index e4237cc..1c5060a 100644
--- a/src/compiler/glsl/opt_copy_propagation_elements.cpp
+++ b/src/compiler/glsl/opt_copy_propagation_elements.cpp
@@ -46,6 +46,7 @@
 #include "ir_basic_block.h"
 #include "ir_optimization.h"
 #include "compiler/glsl_types.h"
+#include "util/hash_table.h"

 static bool debug = false;

@@ -76,6 +77,18 @@ public:
int swizzle[4];
 };

+/* Class that refers to acp_entry in another exec_list. Used
+ * when making removals based on rhs.
+ */
+class acp_ref : public exec_node


This pattern is called a box, so maybe acp_box would be a better name.
I'm not too hung up on it.

With this change, can the acp_entry itself still be in a list?


The idea here is a class that only refers to a acp_entry but does not
take any ownership .. so it's really just a list of pointers. I'm OK
with renaming it.


If only a boxed acp_entry can be in a list, then acp_entry doesn't need
to derive from exec_node.  That's why I was asking.  I looked at the
rest of the code again, and I now see that the acp_entry is in the lhs list.

Correct me if I'm wrong, but an entry will effectively be in two lists
at all times: the lhs list and the rhs list.

Assuming that previous assumption is correct, I might suggest a
different structure that makes it all less confusing.  Don't make
acp_entry drive from exec_node.  Instead, embed two acp_ref (or whatever
it ends up being called) nodes in the acp_entry:

acp_ref lhs_node;
acp_ref rhs_node;

When adding an entry to the lhs list, use

lhs_list->push_tail(>lhs_node);

Similar for rhs list:

rhs_list->push_tail(>rhs_node);

Walk the lists like:

   foreach_in_list_safe(acp_ref, ref, rhs_list) {
  acp_entry *entry = ref->entry;

  ...
   }

I think this would be a lot more clear because both lists are handled in
the same way.  It also avoids the overhead of allocating the boxes.


TBH I'm not sure at this point if this will make end implementation 
simpler or more complex but I'll give this change a try :)



+{
+public:
+   acp_ref(acp_entry *e)
+   {
+  entry = e;
+   }
+   acp_entry *entry;
+};

 class kill_entry : public exec_node
 {
@@ -98,14 +111,42 @@ public:
   this->killed_all = false;
   this->mem_ctx = ralloc_context(NULL);
   this->shader_mem_ctx = NULL;
-  this->acp = new(mem_ctx) exec_list;
   this->kills = new(mem_ctx) exec_list;
+
+  create_acp();
}
~ir_copy_propagation_elements_visitor()
{
   ralloc_free(mem_ctx);
}

+   void create_acp()
+   {
+  lhs_ht = _mesa_hash_table_create(mem_ctx, _mesa_hash_pointer,
+   _mesa_key_pointer_equal);
+  rhs_ht = _mesa_hash_table_create(mem_ctx, _mesa_hash_pointer,
+   _mesa_key_pointer_equal);
+   }
+
+   void destroy_acp()
+   {
+  _mesa_hash_table_destroy(lhs_ht, NULL);
+  _mesa_hash_table_destroy(rhs_ht, NULL);
+   }
+
+   void populate_acp(hash_table *lhs, hash_table *rhs)
+   {
+  struct hash_entry *entry;
+  hash_table_foreach(lhs, entry)
+  {

Re: [Mesa-dev] [PATCH 88/88] i965: handle 32bit and 64bit version of shader cache objects

[Timothy Arceri]

On Wed, 2016-09-28 at 11:42 -0700, Kenneth Graunke wrote:
> On Wednesday, September 28, 2016 9:00:50 AM PDT Eric Anholt wrote:
> > 
> > Timothy Arceri  writes:
> > 
> > > 
> > > On Sun, 2016-09-25 at 19:51 -0700, Kenneth Graunke wrote:
> > > > 
> > > > On Saturday, September 24, 2016 3:26:09 PM PDT Timothy Arceri
> > > > wrote:
> > > > > 
> > > > > 
> > > > > Pointers will have different lengths so we simple create a
> > > > > different
> > > > > sha1 for each platform.
> > > > 
> > > > I don't understand...you're putting pointers in the blob?  How
> > > > can
> > > > that
> > > > work?  You obviously can't reload things from the cache as
> > > > actual
> > > > pointers, so you've got to be doing some kind of remapping from
> > > > a
> > > > "pointer" in the blob to a real pointer.
> > > > 
> > > > At that point, can't you just make the blob always use a
> > > > uint64_t for
> > > > pointers, and just pad with zeroes on 32-bit systems?  Then we
> > > > could
> > > > use the same copy for both...
> > > 
> > > We probably could but we are currently using intptr_t for
> > > storing/restoring pointers and ptrdiff_t during remapping as we
> > > probably should be. Thoughts?
> > 
> > Use consistent uint64_t on disk and remap to 32/64 on the way back
> > in,
> > imo.
> 
> I agree...we should use explicitly sized types for anything on disk,
> rather than ones which can vary based on architecture.

Hi Ken/Eric,

The intention of this patch was to try avoid the whole problem of
varying sizes based on architecture. I guess it could still cause
problems if a compiler was to redefine sizes or someone compiled Mesa
with a different compiler that has different sizes but these scenarios
seem unlikely.

I've made the changes based on your initial suggestion but I've hit
more complications and I'm starting to feel like this patch is a
simpler and safer way to go.

When remapping the uniform remap tables for example I was making use of
the size_of(gl_uniform_storage) where gl_uniform_storage itself
contains pointers that vary in size on different platforms. This can be
solved by storing an offest that is a multiple of
size_of(gl_uniform_storage) itself but it becomes more complicated when
restoring something like the parameter lists which contain pointers to
different types. I'm feeling like doing things this way opens us up to
the possiblity of future bugs that users would find difficult to report
accurately for little gain.

Remap table restore code: 

   for (unsigned i = 0; i < prog->NumUniformRemapTable; i++) {
  uint64_t uni_ptr = blob_read_uint64(metadata);
  if (uni_ptr == (uint64_t) INACTIVE_UNIFORM_EXPLICIT_LOCATION ||
  uni_ptr == (uint64_t) NULL) {
 prog->UniformRemapTable[i] = (gl_uniform_storage *) uni_ptr;
  } else {
 intptr_t uni_offset =
(uni_ptr - uni_store_base) / sizeof(gl_uniform_storage);
 prog->UniformRemapTable[i] = prog->UniformStorage + uni_offset;
  }
   }

Then there is there is the other problem of writing/restoring whole
structs for example:

   blob_copy_bytes(metadata, (uint8_t *) ltf->Buffers,
   sizeof(struct gl_transform_feedback_buffer) *
  MAX_FEEDBACK_BUFFERS);

Mostly this shouldn't be a problem but since we don't use uint32_t etc
everywhere it's not guaranteed to be so.

If you guys still think this is the best way to go I'll rework the
remap table restore code. I just thought I'd get more feedback before
going too far forward.

Thanks,
Tim


> 
> --Ken
> ___
> 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

Re: [Mesa-dev] Mesa 13.0.0 release plan (Was Re: Mesa 12.1.0 release plan (Was Re: Next Mesa release, anyone?))

[Emil Velikov]

On 30 September 2016 at 03:31, Timothy Arceri
 wrote:
> On Thu, 2016-09-29 at 19:17 -0700, Jason Ekstrand wrote:
>
> On Sep 29, 2016 5:14 PM, "Timothy Arceri" 
> wrote:
>>
>> On Thu, 2016-09-29 at 15:56 +0100, Emil Velikov wrote:
>> > On 28 September 2016 at 19:53, Marek Olšák  wrote:
>> > >
>> > > Hi,
>> > >
>> > > It's been almost 4 months since the 12.0 branch was created, and
>> > > soon
>> > > it will have been 3 months since Mesa 12.0 was released.
>> > >
>> > > Is there any reason we haven't created the stable branch yet?
>> > >
>> > > Ideally, we would time the release so that it's 1-2 months before
>> > > fall
>> > > distribution releases.
>> > >
>> >
>> > Thanks Marek !
>> >
>> > In all honesty I was secretly hoping that we'll get Dave/Bas RADV for
>> > 12.1.
>>
>> I believe the release should be 13?? Core Mesa and the Intel driver
>> have reached 4.4 this release also core Mesa is now at 4.5 despite not
>> being enabled anywhere.
>
> My personal preference, for whatever it's worth, would be to call it 12.1.
> The 12.0 release was the biggest release we've had in a long time and it
> seems odd to me to jump to 13.0 right away when we really haven't done much
> at all in terms of new features. (I think it's only 2 or 3 desktop features
> in the case of Intel.  A bit more on the ES side I guess).
>
>
> My understanding is the major version has only ever been bumped when full
> support for a new desktop OpenGL version has been reached regardless of the
> number of extensions enabled. We did the same thing going from 8.0 > 9.0
> were as the 7 release went all the way to 7.11 over a 4 year period. It
> seems odd to change the way we bump versions at this point in time, although
> in future maybe it will need to be based on Vulkin versions also.
>
Brain freeze - seem to miss-remember that enhanced layouts (thus 4.4)
landed after the branch point.
That plus the ES3.1/ES3.2, compat for the desktop GL, (by Ilia/Ken)
does take us to 13.0.

At the end of the day it's just a number albeit being the "unlucky" one.

If we get a consensus amongst the majority of devs we can change the
versioning scheme. But for that let's do so in a ~weeks time - after
the branchpoint.

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

Re: [Mesa-dev] Mesa 12.1.0 release plan (Was Re: Next Mesa release, anyone?)

[Emil Velikov]

On 30 September 2016 at 02:31, Dave Airlie  wrote:
> On 30 September 2016 at 01:07, Jason Ekstrand  wrote:
>> On Sep 29, 2016 7:56 AM, "Emil Velikov"  wrote:
>>>
>>> On 28 September 2016 at 19:53, Marek Olšák  wrote:
>>> > Hi,
>>> >
>>> > It's been almost 4 months since the 12.0 branch was created, and soon
>>> > it will have been 3 months since Mesa 12.0 was released.
>>> >
>>> > Is there any reason we haven't created the stable branch yet?
>>> >
>>> > Ideally, we would time the release so that it's 1-2 months before fall
>>> > distribution releases.
>>> >
>>>
>>> Thanks Marek !
>>>
>>> In all honesty I was secretly hoping that we'll get Dave/Bas RADV for
>>> 12.1. With the topic of which would be 'the default' Vulkan driver for
>>> ATI/AMD hardware to be considered at a later stage.
>>
>> If they have even close to the amount of work we had to get it merged, I
>> don't think that's at all realistic.  Then again, Dave is the one who wants
>> to have a Vulkan driver for AMD hardware that he can package and ship so
>> I'll let him decide how badly he wants it in this release.
>>
>>> That said here are the tentative dates:
>>>
>>> Oct 7/14 2016 - Feature freeze/Release candidate 1
>>> Oct 14/21 2016 - Release candidate 2
>>> Oct 21/28 2016 - Release candidate 3/final release
>>>
>>> Fwiw I'm still in favour of getting RADV in even if it's not
>>> perfect/feature complete. Devs, let me know if there's a "must have"
>>> feature that we want in 12.1.
>
> The main problem I have with merging radv is the whole conformance testing
> end of it.
>
> It's probably fine if I just make a big printf on device creation that RADV
> isn't a conformant vulkan implementation yet. Sorta like what Intel do on the
> older GPUs.
>
That and/or having the install/setup stage require manual intervention
- similar to what we have for ilo/i965g.
Just throwing some ideas - whichever works for you really.

How well is RADV doing on the conformance side - mostly there or ?

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

Re: [Mesa-dev] [PATCH v2 1/5] radeon/video: don't use sub-allocated buffers

[Nicolai Hähnle]

Well, it depends on both the size and the type. Sub-allocation can be 
used up to 16KB with the current setting, but the override is clearly 
the right solution here :)


Cheers,
Nicolai

On 30.09.2016 12:24, Christian König wrote:

Oh, so you use the allocation type instead of the size to determine if a
buffer can be sub-allocated or not?

I wasn't expecting that, in this case even the DPB would have ended up
in the sub-allocator and that would clearly blow up immediately.

Good that we stumbled over this.

Regards,
Christian.

Am 30.09.2016 um 11:54 schrieb Nicolai Hähnle:

I should add that textures are already never sub-allocated, so with
this patch all the buffers used with UVD and VCE should be covered.

Nicolai

On 30.09.2016 11:52, Nicolai Hähnle wrote:

From: Nicolai Hähnle 

Cc: Christian König 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97976
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97969
---
 src/gallium/drivers/radeon/r600_buffer_common.c | 3 +++
 src/gallium/drivers/radeon/radeon_video.c   | 8 +++-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c
b/src/gallium/drivers/radeon/r600_buffer_common.c
index 9414920..4e1af92 100644
--- a/src/gallium/drivers/radeon/r600_buffer_common.c
+++ b/src/gallium/drivers/radeon/r600_buffer_common.c
@@ -524,20 +524,23 @@ r600_alloc_buffer_struct(struct pipe_screen
*screen,

 struct pipe_resource *r600_buffer_create(struct pipe_screen *screen,
  const struct pipe_resource *templ,
  unsigned alignment)
 {
 struct r600_common_screen *rscreen = (struct
r600_common_screen*)screen;
 struct r600_resource *rbuffer = r600_alloc_buffer_struct(screen,
templ);

 r600_init_resource_fields(rscreen, rbuffer, templ->width0,
alignment);

+if (templ->bind & PIPE_BIND_SHARED)
+rbuffer->flags |= RADEON_FLAG_HANDLE;
+
 if (!r600_alloc_resource(rscreen, rbuffer)) {
 FREE(rbuffer);
 return NULL;
 }
 return >b.b;
 }

 struct pipe_resource *r600_aligned_buffer_create(struct pipe_screen
*screen,
  unsigned bind,
  unsigned usage,
diff --git a/src/gallium/drivers/radeon/radeon_video.c
b/src/gallium/drivers/radeon/radeon_video.c
index d7c5a16..de8e11c 100644
--- a/src/gallium/drivers/radeon/radeon_video.c
+++ b/src/gallium/drivers/radeon/radeon_video.c
@@ -59,22 +59,28 @@ unsigned rvid_alloc_stream_handle()
 stream_handle ^= ++counter;
 return stream_handle;
 }

 /* create a buffer in the winsys */
 bool rvid_create_buffer(struct pipe_screen *screen, struct
rvid_buffer *buffer,
 unsigned size, unsigned usage)
 {
 memset(buffer, 0, sizeof(*buffer));
 buffer->usage = usage;
+
+/* Hardware buffer placement restrictions require the kernel to be
+ * able to move buffers around individually, so request a
+ * non-sub-allocated buffer.
+ */
 buffer->res = (struct r600_resource *)
-pipe_buffer_create(screen, PIPE_BIND_CUSTOM, usage, size);
+pipe_buffer_create(screen, PIPE_BIND_CUSTOM | PIPE_BIND_SHARED,
+   usage, size);

 return buffer->res != NULL;
 }

 /* destroy a buffer */
 void rvid_destroy_buffer(struct rvid_buffer *buffer)
 {
 r600_resource_reference(>res, NULL);
 }





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

Re: [Mesa-dev] [PATCH v2 1/5] radeon/video: don't use sub-allocated buffers

[Christian König]

Oh, so you use the allocation type instead of the size to determine if a 
buffer can be sub-allocated or not?


I wasn't expecting that, in this case even the DPB would have ended up 
in the sub-allocator and that would clearly blow up immediately.


Good that we stumbled over this.

Regards,
Christian.

Am 30.09.2016 um 11:54 schrieb Nicolai Hähnle:
I should add that textures are already never sub-allocated, so with 
this patch all the buffers used with UVD and VCE should be covered.


Nicolai

On 30.09.2016 11:52, Nicolai Hähnle wrote:

From: Nicolai Hähnle 

Cc: Christian König 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97976
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97969
---
 src/gallium/drivers/radeon/r600_buffer_common.c | 3 +++
 src/gallium/drivers/radeon/radeon_video.c   | 8 +++-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c 
b/src/gallium/drivers/radeon/r600_buffer_common.c

index 9414920..4e1af92 100644
--- a/src/gallium/drivers/radeon/r600_buffer_common.c
+++ b/src/gallium/drivers/radeon/r600_buffer_common.c
@@ -524,20 +524,23 @@ r600_alloc_buffer_struct(struct pipe_screen 
*screen,


 struct pipe_resource *r600_buffer_create(struct pipe_screen *screen,
  const struct pipe_resource *templ,
  unsigned alignment)
 {
 struct r600_common_screen *rscreen = (struct 
r600_common_screen*)screen;
 struct r600_resource *rbuffer = r600_alloc_buffer_struct(screen, 
templ);


 r600_init_resource_fields(rscreen, rbuffer, templ->width0, 
alignment);


+if (templ->bind & PIPE_BIND_SHARED)
+rbuffer->flags |= RADEON_FLAG_HANDLE;
+
 if (!r600_alloc_resource(rscreen, rbuffer)) {
 FREE(rbuffer);
 return NULL;
 }
 return >b.b;
 }

 struct pipe_resource *r600_aligned_buffer_create(struct pipe_screen 
*screen,

  unsigned bind,
  unsigned usage,
diff --git a/src/gallium/drivers/radeon/radeon_video.c 
b/src/gallium/drivers/radeon/radeon_video.c

index d7c5a16..de8e11c 100644
--- a/src/gallium/drivers/radeon/radeon_video.c
+++ b/src/gallium/drivers/radeon/radeon_video.c
@@ -59,22 +59,28 @@ unsigned rvid_alloc_stream_handle()
 stream_handle ^= ++counter;
 return stream_handle;
 }

 /* create a buffer in the winsys */
 bool rvid_create_buffer(struct pipe_screen *screen, struct 
rvid_buffer *buffer,

 unsigned size, unsigned usage)
 {
 memset(buffer, 0, sizeof(*buffer));
 buffer->usage = usage;
+
+/* Hardware buffer placement restrictions require the kernel to be
+ * able to move buffers around individually, so request a
+ * non-sub-allocated buffer.
+ */
 buffer->res = (struct r600_resource *)
-pipe_buffer_create(screen, PIPE_BIND_CUSTOM, usage, size);
+pipe_buffer_create(screen, PIPE_BIND_CUSTOM | PIPE_BIND_SHARED,
+   usage, size);

 return buffer->res != NULL;
 }

 /* destroy a buffer */
 void rvid_destroy_buffer(struct rvid_buffer *buffer)
 {
 r600_resource_reference(>res, NULL);
 }




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

Re: [Mesa-dev] [PATCH 3/3] glx: rename choose_visual(), drop const argument

[Marek Olšák]

For the series:

Reviewed-by: Marek Olšák 

Marek

On Fri, Sep 30, 2016 at 12:01 PM, Emil Velikov  wrote:
> From: Emil Velikov 
>
> The function deals with fb (style) configs, thus using "visual"
> in the name is misleading. Which in itself had led to the use of
> fbconfig_style_tags argument.
>
> Rename the function to reflect what it does and drop the unneeded
> argument.
>
> Signed-off-by: Emil Velikov 
> ---
>  src/glx/glxcmds.c | 26 +++---
>  1 file changed, 11 insertions(+), 15 deletions(-)
>
> diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
> index 8191da0..21fdd7a 100644
> --- a/src/glx/glxcmds.c
> +++ b/src/glx/glxcmds.c
> @@ -1162,8 +1162,8 @@ fbconfig_compare(struct glx_config **a, struct 
> glx_config **b)
>
>  /**
>   * Selects and sorts a subset of the supplied configs based on the 
> attributes.
> - * This function forms to basis of \c glXChooseVisual, \c glXChooseFBConfig,
> - * and \c glXChooseFBConfigSGIX.
> + * This function forms to basis of \c glXChooseFBConfig and
> + * \c glXChooseFBConfigSGIX.
>   *
>   * \param configs   Array of pointers to possible configs.  The elements of
>   *  this array that do not meet the criteria will be set to
> @@ -1171,20 +1171,16 @@ fbconfig_compare(struct glx_config **a, struct 
> glx_config **b)
>   *  the various visual / FBConfig selection rules.
>   * \param num_configs  Number of elements in the \c configs array.
>   * \param attribList   Attributes used select from \c configs.  This array is
> - * terminated by a \c None tag.  The array can either 
> take
> - * the form expected by \c glXChooseVisual (where boolean
> - * tags do not have a value) or by \c glXChooseFBConfig
> - * (where every tag has a value).
> - * \param fbconfig_style_tags  Selects whether \c attribList is in
> - * \c glXChooseVisual style or
> - * \c glXChooseFBConfig style.
> + * terminated by a \c None tag.  The array is of the form
> + * expected by \c glXChooseFBConfig (where every tag has 
> a
> + * value).
>   * \returns The number of valid elements left in \c configs.
>   *
> - * \sa glXChooseVisual, glXChooseFBConfig, glXChooseFBConfigSGIX
> + * \sa glXChooseFBConfig, glXChooseFBConfigSGIX
>   */
>  static int
> -choose_visual(struct glx_config ** configs, int num_configs,
> -  const int *attribList, GLboolean fbconfig_style_tags)
> +choose_fbconfig(struct glx_config ** configs, int num_configs,
> +  const int *attribList)
>  {
> struct glx_config test_config;
> int base;
> @@ -1196,10 +1192,10 @@ choose_visual(struct glx_config ** configs, int 
> num_configs,
>  * list.
>  */
>
> -   init_fbconfig_for_chooser(_config, fbconfig_style_tags);
> +   init_fbconfig_for_chooser(_config, GL_TRUE);
> __glXInitializeVisualConfigFromTags(_config, 512,
> (const INT32 *) attribList,
> -   GL_TRUE, fbconfig_style_tags);
> +   GL_TRUE, GL_TRUE);
>
> base = 0;
> for (i = 0; i < num_configs; i++) {
> @@ -1613,7 +1609,7 @@ glXChooseFBConfig(Display * dpy, int screen,
>glXGetFBConfigs(dpy, screen, _size);
>
> if ((config_list != NULL) && (list_size > 0) && (attribList != NULL)) {
> -  list_size = choose_visual(config_list, list_size, attribList, GL_TRUE);
> +  list_size = choose_fbconfig(config_list, list_size, attribList);
>if (list_size == 0) {
>   free(config_list);
>   config_list = NULL;
> --
> 2.9.3
>
> ___
> 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

Re: [Mesa-dev] [PATCH v2 1/5] radeon/video: don't use sub-allocated buffers

[Christian König]

Patches #1-#3 of this series are Reviewed-by: Christian König 
.


Regards,
Christian.

Am 30.09.2016 um 11:52 schrieb Nicolai Hähnle:

From: Nicolai Hähnle 

Cc: Christian König 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97976
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97969
---
  src/gallium/drivers/radeon/r600_buffer_common.c | 3 +++
  src/gallium/drivers/radeon/radeon_video.c   | 8 +++-
  2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c 
b/src/gallium/drivers/radeon/r600_buffer_common.c
index 9414920..4e1af92 100644
--- a/src/gallium/drivers/radeon/r600_buffer_common.c
+++ b/src/gallium/drivers/radeon/r600_buffer_common.c
@@ -524,20 +524,23 @@ r600_alloc_buffer_struct(struct pipe_screen *screen,
  
  struct pipe_resource *r600_buffer_create(struct pipe_screen *screen,

 const struct pipe_resource *templ,
 unsigned alignment)
  {
struct r600_common_screen *rscreen = (struct r600_common_screen*)screen;
struct r600_resource *rbuffer = r600_alloc_buffer_struct(screen, templ);
  
  	r600_init_resource_fields(rscreen, rbuffer, templ->width0, alignment);
  
+	if (templ->bind & PIPE_BIND_SHARED)

+   rbuffer->flags |= RADEON_FLAG_HANDLE;
+
if (!r600_alloc_resource(rscreen, rbuffer)) {
FREE(rbuffer);
return NULL;
}
return >b.b;
  }
  
  struct pipe_resource *r600_aligned_buffer_create(struct pipe_screen *screen,

 unsigned bind,
 unsigned usage,
diff --git a/src/gallium/drivers/radeon/radeon_video.c 
b/src/gallium/drivers/radeon/radeon_video.c
index d7c5a16..de8e11c 100644
--- a/src/gallium/drivers/radeon/radeon_video.c
+++ b/src/gallium/drivers/radeon/radeon_video.c
@@ -59,22 +59,28 @@ unsigned rvid_alloc_stream_handle()
stream_handle ^= ++counter;
return stream_handle;
  }
  
  /* create a buffer in the winsys */

  bool rvid_create_buffer(struct pipe_screen *screen, struct rvid_buffer 
*buffer,
unsigned size, unsigned usage)
  {
memset(buffer, 0, sizeof(*buffer));
buffer->usage = usage;
+
+   /* Hardware buffer placement restrictions require the kernel to be
+* able to move buffers around individually, so request a
+* non-sub-allocated buffer.
+*/
buffer->res = (struct r600_resource *)
-   pipe_buffer_create(screen, PIPE_BIND_CUSTOM, usage, size);
+   pipe_buffer_create(screen, PIPE_BIND_CUSTOM | PIPE_BIND_SHARED,
+  usage, size);
  
  	return buffer->res != NULL;

  }
  
  /* destroy a buffer */

  void rvid_destroy_buffer(struct rvid_buffer *buffer)
  {
r600_resource_reference(>res, NULL);
  }
  



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

Re: [Mesa-dev] [PATCH] gallium/radeon: fix crash/regression in performance counters

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Fri, Sep 30, 2016 at 12:04 PM, Nicolai Hähnle  wrote:
> From: Nicolai Hähnle 
>
> Cc: Michel Dänzer 
> ---
>  src/gallium/drivers/radeon/r600_perfcounter.c | 9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/src/gallium/drivers/radeon/r600_perfcounter.c 
> b/src/gallium/drivers/radeon/r600_perfcounter.c
> index f8dfda0..0c55fc2 100644
> --- a/src/gallium/drivers/radeon/r600_perfcounter.c
> +++ b/src/gallium/drivers/radeon/r600_perfcounter.c
> @@ -108,20 +108,28 @@ static void r600_pc_query_destroy(struct 
> r600_common_context *ctx,
> struct r600_pc_group *group = query->groups;
> query->groups = group->next;
> FREE(group);
> }
>
> FREE(query->counters);
>
> r600_query_hw_destroy(ctx, rquery);
>  }
>
> +static bool r600_pc_query_prepare_buffer(struct r600_common_context *ctx,
> +struct r600_query_hw *hwquery,
> +struct r600_resource *buffer)
> +{
> +   /* no-op */
> +   return true;
> +}
> +
>  static void r600_pc_query_emit_start(struct r600_common_context *ctx,
>  struct r600_query_hw *hwquery,
>  struct r600_resource *buffer, uint64_t 
> va)
>  {
> struct r600_perfcounters *pc = ctx->screen->perfcounters;
> struct r600_query_pc *query = (struct r600_query_pc *)hwquery;
> struct r600_pc_group *group;
> int current_se = -1;
> int current_instance = -1;
>
> @@ -208,20 +216,21 @@ static void r600_pc_query_add_result(struct 
> r600_common_context *ctx,
>  }
>
>  static struct r600_query_ops batch_query_ops = {
> .destroy = r600_pc_query_destroy,
> .begin = r600_query_hw_begin,
> .end = r600_query_hw_end,
> .get_result = r600_query_hw_get_result
>  };
>
>  static struct r600_query_hw_ops batch_query_hw_ops = {
> +   .prepare_buffer = r600_pc_query_prepare_buffer,
> .emit_start = r600_pc_query_emit_start,
> .emit_stop = r600_pc_query_emit_stop,
> .clear_result = r600_pc_query_clear_result,
> .add_result = r600_pc_query_add_result,
>  };
>
>  static struct r600_pc_group *get_group_state(struct r600_common_screen 
> *screen,
>  struct r600_query_pc *query,
>  struct r600_perfcounter_block 
> *block,
>  unsigned sub_gid)
> --
> 2.7.4
>
> ___
> 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

Re: [Mesa-dev] Mesa 12.1.0 release plan (Was Re: Next Mesa release, anyone?)

[Nicolai Hähnle]

On 30.09.2016 03:31, Dave Airlie wrote:

On 30 September 2016 at 01:07, Jason Ekstrand  wrote:

On Sep 29, 2016 7:56 AM, "Emil Velikov"  wrote:


On 28 September 2016 at 19:53, Marek Olšák  wrote:

Hi,

It's been almost 4 months since the 12.0 branch was created, and soon
it will have been 3 months since Mesa 12.0 was released.

Is there any reason we haven't created the stable branch yet?

Ideally, we would time the release so that it's 1-2 months before fall
distribution releases.



Thanks Marek !

In all honesty I was secretly hoping that we'll get Dave/Bas RADV for
12.1. With the topic of which would be 'the default' Vulkan driver for
ATI/AMD hardware to be considered at a later stage.


If they have even close to the amount of work we had to get it merged, I
don't think that's at all realistic.  Then again, Dave is the one who wants
to have a Vulkan driver for AMD hardware that he can package and ship so
I'll let him decide how badly he wants it in this release.


That said here are the tentative dates:

Oct 7/14 2016 - Feature freeze/Release candidate 1
Oct 14/21 2016 - Release candidate 2
Oct 21/28 2016 - Release candidate 3/final release

Fwiw I'm still in favour of getting RADV in even if it's not
perfect/feature complete. Devs, let me know if there's a "must have"
feature that we want in 12.1.


The main problem I have with merging radv is the whole conformance testing
end of it.

It's probably fine if I just make a big printf on device creation that RADV
isn't a conformant vulkan implementation yet. Sorta like what Intel do on the
older GPUs.

Otherwise I don't think merging it is a big job, it's 30,000 lines of standalone
code, I've already merged the prereq patches, and I think any code sharing
should happen in tree.


FWIW, I think that plan works fine.

Nicolai



Dave.
___
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] [PATCH] gallium/radeon: fix crash/regression in performance counters

[Nicolai Hähnle]

From: Nicolai Hähnle 

Cc: Michel Dänzer 
---
 src/gallium/drivers/radeon/r600_perfcounter.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/src/gallium/drivers/radeon/r600_perfcounter.c 
b/src/gallium/drivers/radeon/r600_perfcounter.c
index f8dfda0..0c55fc2 100644
--- a/src/gallium/drivers/radeon/r600_perfcounter.c
+++ b/src/gallium/drivers/radeon/r600_perfcounter.c
@@ -108,20 +108,28 @@ static void r600_pc_query_destroy(struct 
r600_common_context *ctx,
struct r600_pc_group *group = query->groups;
query->groups = group->next;
FREE(group);
}
 
FREE(query->counters);
 
r600_query_hw_destroy(ctx, rquery);
 }
 
+static bool r600_pc_query_prepare_buffer(struct r600_common_context *ctx,
+struct r600_query_hw *hwquery,
+struct r600_resource *buffer)
+{
+   /* no-op */
+   return true;
+}
+
 static void r600_pc_query_emit_start(struct r600_common_context *ctx,
 struct r600_query_hw *hwquery,
 struct r600_resource *buffer, uint64_t va)
 {
struct r600_perfcounters *pc = ctx->screen->perfcounters;
struct r600_query_pc *query = (struct r600_query_pc *)hwquery;
struct r600_pc_group *group;
int current_se = -1;
int current_instance = -1;
 
@@ -208,20 +216,21 @@ static void r600_pc_query_add_result(struct 
r600_common_context *ctx,
 }
 
 static struct r600_query_ops batch_query_ops = {
.destroy = r600_pc_query_destroy,
.begin = r600_query_hw_begin,
.end = r600_query_hw_end,
.get_result = r600_query_hw_get_result
 };
 
 static struct r600_query_hw_ops batch_query_hw_ops = {
+   .prepare_buffer = r600_pc_query_prepare_buffer,
.emit_start = r600_pc_query_emit_start,
.emit_stop = r600_pc_query_emit_stop,
.clear_result = r600_pc_query_clear_result,
.add_result = r600_pc_query_add_result,
 };
 
 static struct r600_pc_group *get_group_state(struct r600_common_screen *screen,
 struct r600_query_pc *query,
 struct r600_perfcounter_block 
*block,
 unsigned sub_gid)
-- 
2.7.4

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

[Mesa-dev] [PATCH 3/3] glx: rename choose_visual(), drop const argument

[Emil Velikov]

From: Emil Velikov 

The function deals with fb (style) configs, thus using "visual"
in the name is misleading. Which in itself had led to the use of
fbconfig_style_tags argument.

Rename the function to reflect what it does and drop the unneeded
argument.

Signed-off-by: Emil Velikov 
---
 src/glx/glxcmds.c | 26 +++---
 1 file changed, 11 insertions(+), 15 deletions(-)

diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
index 8191da0..21fdd7a 100644
--- a/src/glx/glxcmds.c
+++ b/src/glx/glxcmds.c
@@ -1162,8 +1162,8 @@ fbconfig_compare(struct glx_config **a, struct glx_config 
**b)
 
 /**
  * Selects and sorts a subset of the supplied configs based on the attributes.
- * This function forms to basis of \c glXChooseVisual, \c glXChooseFBConfig,
- * and \c glXChooseFBConfigSGIX.
+ * This function forms to basis of \c glXChooseFBConfig and
+ * \c glXChooseFBConfigSGIX.
  *
  * \param configs   Array of pointers to possible configs.  The elements of
  *  this array that do not meet the criteria will be set to
@@ -1171,20 +1171,16 @@ fbconfig_compare(struct glx_config **a, struct 
glx_config **b)
  *  the various visual / FBConfig selection rules.
  * \param num_configs  Number of elements in the \c configs array.
  * \param attribList   Attributes used select from \c configs.  This array is
- * terminated by a \c None tag.  The array can either take
- * the form expected by \c glXChooseVisual (where boolean
- * tags do not have a value) or by \c glXChooseFBConfig
- * (where every tag has a value).
- * \param fbconfig_style_tags  Selects whether \c attribList is in
- * \c glXChooseVisual style or
- * \c glXChooseFBConfig style.
+ * terminated by a \c None tag.  The array is of the form
+ * expected by \c glXChooseFBConfig (where every tag has a
+ * value).
  * \returns The number of valid elements left in \c configs.
  *
- * \sa glXChooseVisual, glXChooseFBConfig, glXChooseFBConfigSGIX
+ * \sa glXChooseFBConfig, glXChooseFBConfigSGIX
  */
 static int
-choose_visual(struct glx_config ** configs, int num_configs,
-  const int *attribList, GLboolean fbconfig_style_tags)
+choose_fbconfig(struct glx_config ** configs, int num_configs,
+  const int *attribList)
 {
struct glx_config test_config;
int base;
@@ -1196,10 +1192,10 @@ choose_visual(struct glx_config ** configs, int 
num_configs,
 * list.
 */
 
-   init_fbconfig_for_chooser(_config, fbconfig_style_tags);
+   init_fbconfig_for_chooser(_config, GL_TRUE);
__glXInitializeVisualConfigFromTags(_config, 512,
(const INT32 *) attribList,
-   GL_TRUE, fbconfig_style_tags);
+   GL_TRUE, GL_TRUE);
 
base = 0;
for (i = 0; i < num_configs; i++) {
@@ -1613,7 +1609,7 @@ glXChooseFBConfig(Display * dpy, int screen,
   glXGetFBConfigs(dpy, screen, _size);
 
if ((config_list != NULL) && (list_size > 0) && (attribList != NULL)) {
-  list_size = choose_visual(config_list, list_size, attribList, GL_TRUE);
+  list_size = choose_fbconfig(config_list, list_size, attribList);
   if (list_size == 0) {
  free(config_list);
  config_list = NULL;
-- 
2.9.3

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

[Mesa-dev] [PATCH 2/3] glx: return GL_FALSE from glx_screen_init where applicable.

[Emil Velikov]

From: Emil Velikov 

Return GL_FALSE if we fail to find any fb/visual configs, otherwise we
end up with all sorts of chaos further down the GLX stack.

Signed-off-by: Emil Velikov 
---
 src/glx/glxext.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/src/glx/glxext.c b/src/glx/glxext.c
index 4c03011..869e1a6 100644
--- a/src/glx/glxext.c
+++ b/src/glx/glxext.c
@@ -741,8 +741,11 @@ glx_screen_init(struct glx_screen *psc,
psc->dpy = priv->dpy;
psc->display = priv;
 
-   getVisualConfigs(psc, priv, screen);
-   getFBConfigs(psc, priv, screen);
+   if (!getVisualConfigs(psc, priv, screen))
+  return GL_FALSE;
+
+   if (!getFBConfigs(psc, priv, screen))
+  return GL_FALSE;
 
return GL_TRUE;
 }
-- 
2.9.3

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

[Mesa-dev] [PATCH 1/3] glx: correctly mask the drawableType for GLX_ARB_fbconfig_float

[Emil Velikov]

From: Emil Velikov 

The comment/spec says - only for pbuffer drawables, while the code
clears the window/pixmap bit. Practise what you preach and apply the
trivial tweak. In practise this should not cause functional change.

Signed-off-by: Emil Velikov 
---
 src/glx/glxext.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/glx/glxext.c b/src/glx/glxext.c
index dc87fb9..4c03011 100644
--- a/src/glx/glxext.c
+++ b/src/glx/glxext.c
@@ -592,7 +592,7 @@ __glXInitializeVisualConfigFromTags(struct glx_config * 
config, int count,
 * GLXPbuffer drawables."
 */
if (config->floatMode)
-  config->drawableType &= ~(GLX_WINDOW_BIT|GLX_PIXMAP_BIT);
+  config->drawableType &= GLX_PBUFFER_BIT;
 }
 
 static struct glx_config *
-- 
2.9.3

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

Re: [Mesa-dev] [PATCH v2 4/5] gallium/radeon: emit relocations for query fences

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Fri, Sep 30, 2016 at 11:52 AM, Nicolai Hähnle  wrote:
> From: Nicolai Hähnle 
>
> This is only needed for r600 which doesn't have ARB_query_buffer_object and
> therefore wouldn't really need the fences, but let's be optimistic about
> filling in this feature gap eventually.
>
> Cc: Dieter Nützel 
> ---
>  src/gallium/drivers/radeon/r600_pipe_common.c |  7 ++-
>  src/gallium/drivers/radeon/r600_pipe_common.h |  2 +-
>  src/gallium/drivers/radeon/r600_query.c   | 13 +++--
>  src/gallium/drivers/radeonsi/si_perfcounter.c |  2 +-
>  4 files changed, 15 insertions(+), 9 deletions(-)
>
> diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c 
> b/src/gallium/drivers/radeon/r600_pipe_common.c
> index e9377b2..6dc92cb 100644
> --- a/src/gallium/drivers/radeon/r600_pipe_common.c
> +++ b/src/gallium/drivers/radeon/r600_pipe_common.c
> @@ -73,21 +73,21 @@ void radeon_shader_binary_clean(struct 
> radeon_shader_binary *b)
> FREE(b->global_symbol_offsets);
> FREE(b->relocs);
> FREE(b->disasm_string);
> FREE(b->llvm_ir_string);
>  }
>
>  /*
>   * pipe_context
>   */
>
> -void r600_gfx_write_fence(struct r600_common_context *ctx,
> +void r600_gfx_write_fence(struct r600_common_context *ctx, struct 
> r600_resource *buf,
>   uint64_t va, uint32_t old_value, uint32_t new_value)
>  {
> struct radeon_winsys_cs *cs = ctx->gfx.cs;
>
> if (ctx->chip_class == CIK) {
> /* Two EOP events are required to make all engines go idle
>  * (and optional cache flushes executed) before the timestamp
>  * is written.
>  */
> radeon_emit(cs, PKT3(PKT3_EVENT_WRITE_EOP, 4, 0));
> @@ -99,29 +99,34 @@ void r600_gfx_write_fence(struct r600_common_context *ctx,
> radeon_emit(cs, 0); /* unused */
> }
>
> radeon_emit(cs, PKT3(PKT3_EVENT_WRITE_EOP, 4, 0));
> radeon_emit(cs, EVENT_TYPE(EVENT_TYPE_BOTTOM_OF_PIPE_TS) |
> EVENT_INDEX(5));
> radeon_emit(cs, va);
> radeon_emit(cs, (va >> 32) | EOP_DATA_SEL(1));
> radeon_emit(cs, new_value); /* immediate data */
> radeon_emit(cs, 0); /* unused */
> +
> +   r600_emit_reloc(ctx, >gfx, buf, RADEON_USAGE_WRITE, 
> RADEON_PRIO_QUERY);
>  }
>
>  unsigned r600_gfx_write_fence_dwords(struct r600_common_screen *screen)
>  {
> unsigned dwords = 6;
>
> if (screen->chip_class == CIK)
> dwords *= 2;
>
> +   if (!screen->info.has_virtual_memory)
> +   dwords += 2;
> +
> return dwords;
>  }
>
>  void r600_gfx_wait_fence(struct r600_common_context *ctx,
>  uint64_t va, uint32_t ref, uint32_t mask)
>  {
> struct radeon_winsys_cs *cs = ctx->gfx.cs;
>
> radeon_emit(cs, PKT3(PKT3_WAIT_REG_MEM, 5, 0));
> radeon_emit(cs, WAIT_REG_MEM_EQUAL | WAIT_REG_MEM_MEM_SPACE(1));
> diff --git a/src/gallium/drivers/radeon/r600_pipe_common.h 
> b/src/gallium/drivers/radeon/r600_pipe_common.h
> index ec7f7c0..cdcc80b 100644
> --- a/src/gallium/drivers/radeon/r600_pipe_common.h
> +++ b/src/gallium/drivers/radeon/r600_pipe_common.h
> @@ -696,21 +696,21 @@ struct pipe_resource * 
> r600_aligned_buffer_create(struct pipe_screen *screen,
>   unsigned alignment);
>  struct pipe_resource *
>  r600_buffer_from_user_memory(struct pipe_screen *screen,
>  const struct pipe_resource *templ,
>  void *user_memory);
>  void
>  r600_invalidate_resource(struct pipe_context *ctx,
>  struct pipe_resource *resource);
>
>  /* r600_common_pipe.c */
> -void r600_gfx_write_fence(struct r600_common_context *ctx,
> +void r600_gfx_write_fence(struct r600_common_context *ctx, struct 
> r600_resource *buf,
>   uint64_t va, uint32_t old_value, uint32_t 
> new_value);
>  unsigned r600_gfx_write_fence_dwords(struct r600_common_screen *screen);
>  void r600_gfx_wait_fence(struct r600_common_context *ctx,
>  uint64_t va, uint32_t ref, uint32_t mask);
>  void r600_draw_rectangle(struct blitter_context *blitter,
>  int x1, int y1, int x2, int y2, float depth,
>  enum blitter_attrib_type type,
>  const union pipe_color_union *attrib);
>  bool r600_common_screen_init(struct r600_common_screen *rscreen,
>  struct radeon_winsys *ws);
> diff --git a/src/gallium/drivers/radeon/r600_query.c 
> b/src/gallium/drivers/radeon/r600_query.c
> index 0908a6c..925c950 100644
> --- a/src/gallium/drivers/radeon/r600_query.c
> +++ b/src/gallium/drivers/radeon/r600_query.c
> @@ -609,32 +609,32 @@ static void 

Re: [Mesa-dev] [PATCH v2 1/5] radeon/video: don't use sub-allocated buffers

[Nicolai Hähnle]

I should add that textures are already never sub-allocated, so with this 
patch all the buffers used with UVD and VCE should be covered.


Nicolai

On 30.09.2016 11:52, Nicolai Hähnle wrote:

From: Nicolai Hähnle 

Cc: Christian König 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97976
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97969
---
 src/gallium/drivers/radeon/r600_buffer_common.c | 3 +++
 src/gallium/drivers/radeon/radeon_video.c   | 8 +++-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c 
b/src/gallium/drivers/radeon/r600_buffer_common.c
index 9414920..4e1af92 100644
--- a/src/gallium/drivers/radeon/r600_buffer_common.c
+++ b/src/gallium/drivers/radeon/r600_buffer_common.c
@@ -524,20 +524,23 @@ r600_alloc_buffer_struct(struct pipe_screen *screen,

 struct pipe_resource *r600_buffer_create(struct pipe_screen *screen,
 const struct pipe_resource *templ,
 unsigned alignment)
 {
struct r600_common_screen *rscreen = (struct r600_common_screen*)screen;
struct r600_resource *rbuffer = r600_alloc_buffer_struct(screen, templ);

r600_init_resource_fields(rscreen, rbuffer, templ->width0, alignment);

+   if (templ->bind & PIPE_BIND_SHARED)
+   rbuffer->flags |= RADEON_FLAG_HANDLE;
+
if (!r600_alloc_resource(rscreen, rbuffer)) {
FREE(rbuffer);
return NULL;
}
return >b.b;
 }

 struct pipe_resource *r600_aligned_buffer_create(struct pipe_screen *screen,
 unsigned bind,
 unsigned usage,
diff --git a/src/gallium/drivers/radeon/radeon_video.c 
b/src/gallium/drivers/radeon/radeon_video.c
index d7c5a16..de8e11c 100644
--- a/src/gallium/drivers/radeon/radeon_video.c
+++ b/src/gallium/drivers/radeon/radeon_video.c
@@ -59,22 +59,28 @@ unsigned rvid_alloc_stream_handle()
stream_handle ^= ++counter;
return stream_handle;
 }

 /* create a buffer in the winsys */
 bool rvid_create_buffer(struct pipe_screen *screen, struct rvid_buffer *buffer,
unsigned size, unsigned usage)
 {
memset(buffer, 0, sizeof(*buffer));
buffer->usage = usage;
+
+   /* Hardware buffer placement restrictions require the kernel to be
+* able to move buffers around individually, so request a
+* non-sub-allocated buffer.
+*/
buffer->res = (struct r600_resource *)
-   pipe_buffer_create(screen, PIPE_BIND_CUSTOM, usage, size);
+   pipe_buffer_create(screen, PIPE_BIND_CUSTOM | PIPE_BIND_SHARED,
+  usage, size);

return buffer->res != NULL;
 }

 /* destroy a buffer */
 void rvid_destroy_buffer(struct rvid_buffer *buffer)
 {
r600_resource_reference(>res, NULL);
 }



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

[Mesa-dev] [PATCH v2 4/5] gallium/radeon: emit relocations for query fences

[Nicolai Hähnle]

From: Nicolai Hähnle 

This is only needed for r600 which doesn't have ARB_query_buffer_object and
therefore wouldn't really need the fences, but let's be optimistic about
filling in this feature gap eventually.

Cc: Dieter Nützel 
---
 src/gallium/drivers/radeon/r600_pipe_common.c |  7 ++-
 src/gallium/drivers/radeon/r600_pipe_common.h |  2 +-
 src/gallium/drivers/radeon/r600_query.c   | 13 +++--
 src/gallium/drivers/radeonsi/si_perfcounter.c |  2 +-
 4 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c 
b/src/gallium/drivers/radeon/r600_pipe_common.c
index e9377b2..6dc92cb 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.c
+++ b/src/gallium/drivers/radeon/r600_pipe_common.c
@@ -73,21 +73,21 @@ void radeon_shader_binary_clean(struct radeon_shader_binary 
*b)
FREE(b->global_symbol_offsets);
FREE(b->relocs);
FREE(b->disasm_string);
FREE(b->llvm_ir_string);
 }
 
 /*
  * pipe_context
  */
 
-void r600_gfx_write_fence(struct r600_common_context *ctx,
+void r600_gfx_write_fence(struct r600_common_context *ctx, struct 
r600_resource *buf,
  uint64_t va, uint32_t old_value, uint32_t new_value)
 {
struct radeon_winsys_cs *cs = ctx->gfx.cs;
 
if (ctx->chip_class == CIK) {
/* Two EOP events are required to make all engines go idle
 * (and optional cache flushes executed) before the timestamp
 * is written.
 */
radeon_emit(cs, PKT3(PKT3_EVENT_WRITE_EOP, 4, 0));
@@ -99,29 +99,34 @@ void r600_gfx_write_fence(struct r600_common_context *ctx,
radeon_emit(cs, 0); /* unused */
}
 
radeon_emit(cs, PKT3(PKT3_EVENT_WRITE_EOP, 4, 0));
radeon_emit(cs, EVENT_TYPE(EVENT_TYPE_BOTTOM_OF_PIPE_TS) |
EVENT_INDEX(5));
radeon_emit(cs, va);
radeon_emit(cs, (va >> 32) | EOP_DATA_SEL(1));
radeon_emit(cs, new_value); /* immediate data */
radeon_emit(cs, 0); /* unused */
+
+   r600_emit_reloc(ctx, >gfx, buf, RADEON_USAGE_WRITE, 
RADEON_PRIO_QUERY);
 }
 
 unsigned r600_gfx_write_fence_dwords(struct r600_common_screen *screen)
 {
unsigned dwords = 6;
 
if (screen->chip_class == CIK)
dwords *= 2;
 
+   if (!screen->info.has_virtual_memory)
+   dwords += 2;
+
return dwords;
 }
 
 void r600_gfx_wait_fence(struct r600_common_context *ctx,
 uint64_t va, uint32_t ref, uint32_t mask)
 {
struct radeon_winsys_cs *cs = ctx->gfx.cs;
 
radeon_emit(cs, PKT3(PKT3_WAIT_REG_MEM, 5, 0));
radeon_emit(cs, WAIT_REG_MEM_EQUAL | WAIT_REG_MEM_MEM_SPACE(1));
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.h 
b/src/gallium/drivers/radeon/r600_pipe_common.h
index ec7f7c0..cdcc80b 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.h
+++ b/src/gallium/drivers/radeon/r600_pipe_common.h
@@ -696,21 +696,21 @@ struct pipe_resource * r600_aligned_buffer_create(struct 
pipe_screen *screen,
  unsigned alignment);
 struct pipe_resource *
 r600_buffer_from_user_memory(struct pipe_screen *screen,
 const struct pipe_resource *templ,
 void *user_memory);
 void
 r600_invalidate_resource(struct pipe_context *ctx,
 struct pipe_resource *resource);
 
 /* r600_common_pipe.c */
-void r600_gfx_write_fence(struct r600_common_context *ctx,
+void r600_gfx_write_fence(struct r600_common_context *ctx, struct 
r600_resource *buf,
  uint64_t va, uint32_t old_value, uint32_t new_value);
 unsigned r600_gfx_write_fence_dwords(struct r600_common_screen *screen);
 void r600_gfx_wait_fence(struct r600_common_context *ctx,
 uint64_t va, uint32_t ref, uint32_t mask);
 void r600_draw_rectangle(struct blitter_context *blitter,
 int x1, int y1, int x2, int y2, float depth,
 enum blitter_attrib_type type,
 const union pipe_color_union *attrib);
 bool r600_common_screen_init(struct r600_common_screen *rscreen,
 struct radeon_winsys *ws);
diff --git a/src/gallium/drivers/radeon/r600_query.c 
b/src/gallium/drivers/radeon/r600_query.c
index 0908a6c..925c950 100644
--- a/src/gallium/drivers/radeon/r600_query.c
+++ b/src/gallium/drivers/radeon/r600_query.c
@@ -609,32 +609,32 @@ static void r600_query_hw_emit_start(struct 
r600_common_context *ctx,
 
ctx->num_cs_dw_queries_suspend += query->num_cs_dw_end;
 }
 
 static void r600_query_hw_do_emit_stop(struct r600_common_context *ctx,
   struct r600_query_hw *query,
   struct r600_resource *buffer,
   

[Mesa-dev] [PATCH v2 3/5] radeon/uvd: adjust the buffer offset when relocation is used

[Nicolai Hähnle]

From: Nicolai Hähnle 

We don't plan to use sub-allocated buffers with UVD, but just in case one
slips through, this increases the chances of things working out anyway.
---
 src/gallium/drivers/radeon/radeon_uvd.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/drivers/radeon/radeon_uvd.c 
b/src/gallium/drivers/radeon/radeon_uvd.c
index 3ae0eaa..9c376cb 100644
--- a/src/gallium/drivers/radeon/radeon_uvd.c
+++ b/src/gallium/drivers/radeon/radeon_uvd.c
@@ -116,20 +116,21 @@ static void send_cmd(struct ruvd_decoder *dec, unsigned 
cmd,
reloc_idx = dec->ws->cs_add_buffer(dec->cs, buf, usage | 
RADEON_USAGE_SYNCHRONIZED,
   domain,
  RADEON_PRIO_UVD);
if (!dec->use_legacy) {
uint64_t addr;
addr = dec->ws->buffer_get_virtual_address(buf);
addr = addr + off;
set_reg(dec, RUVD_GPCOM_VCPU_DATA0, addr);
set_reg(dec, RUVD_GPCOM_VCPU_DATA1, addr >> 32);
} else {
+   off += dec->ws->buffer_get_virtual_address(buf);
set_reg(dec, RUVD_GPCOM_VCPU_DATA0, off);
set_reg(dec, RUVD_GPCOM_VCPU_DATA1, reloc_idx * 4);
}
set_reg(dec, RUVD_GPCOM_VCPU_CMD, cmd << 1);
 }
 
 /* do the codec needs an IT buffer ?*/
 static bool have_it(struct ruvd_decoder *dec)
 {
return dec->stream_type == RUVD_CODEC_H264_PERF ||
-- 
2.7.4

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

[Mesa-dev] [PATCH v2 2/5] radeon/vce: adjust the buffer offset when relocation is used

[Nicolai Hähnle]

From: Nicolai Hähnle 

We don't plan to use sub-allocated buffers with VCE, but just in case one
slips through, this increases the chances of things working out anyway.
---
 src/gallium/drivers/radeon/radeon_vce.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/drivers/radeon/radeon_vce.c 
b/src/gallium/drivers/radeon/radeon_vce.c
index 10c5a78..30705c1 100644
--- a/src/gallium/drivers/radeon/radeon_vce.c
+++ b/src/gallium/drivers/radeon/radeon_vce.c
@@ -542,14 +542,15 @@ void rvce_add_buffer(struct rvce_encoder *enc, struct 
pb_buffer *buf,
 
reloc_idx = enc->ws->cs_add_buffer(enc->cs, buf, usage | 
RADEON_USAGE_SYNCHRONIZED,
   domain, RADEON_PRIO_VCE);
if (enc->use_vm) {
uint64_t addr;
addr = enc->ws->buffer_get_virtual_address(buf);
addr = addr + offset;
RVCE_CS(addr >> 32);
RVCE_CS(addr);
} else {
+   offset += enc->ws->buffer_get_virtual_address(buf);
RVCE_CS(reloc_idx * 4);
RVCE_CS(offset);
}
 }
-- 
2.7.4

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

[Mesa-dev] [PATCH v2 1/5] radeon/video: don't use sub-allocated buffers

[Nicolai Hähnle]

From: Nicolai Hähnle 

Cc: Christian König 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97976
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97969
---
 src/gallium/drivers/radeon/r600_buffer_common.c | 3 +++
 src/gallium/drivers/radeon/radeon_video.c   | 8 +++-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c 
b/src/gallium/drivers/radeon/r600_buffer_common.c
index 9414920..4e1af92 100644
--- a/src/gallium/drivers/radeon/r600_buffer_common.c
+++ b/src/gallium/drivers/radeon/r600_buffer_common.c
@@ -524,20 +524,23 @@ r600_alloc_buffer_struct(struct pipe_screen *screen,
 
 struct pipe_resource *r600_buffer_create(struct pipe_screen *screen,
 const struct pipe_resource *templ,
 unsigned alignment)
 {
struct r600_common_screen *rscreen = (struct r600_common_screen*)screen;
struct r600_resource *rbuffer = r600_alloc_buffer_struct(screen, templ);
 
r600_init_resource_fields(rscreen, rbuffer, templ->width0, alignment);
 
+   if (templ->bind & PIPE_BIND_SHARED)
+   rbuffer->flags |= RADEON_FLAG_HANDLE;
+
if (!r600_alloc_resource(rscreen, rbuffer)) {
FREE(rbuffer);
return NULL;
}
return >b.b;
 }
 
 struct pipe_resource *r600_aligned_buffer_create(struct pipe_screen *screen,
 unsigned bind,
 unsigned usage,
diff --git a/src/gallium/drivers/radeon/radeon_video.c 
b/src/gallium/drivers/radeon/radeon_video.c
index d7c5a16..de8e11c 100644
--- a/src/gallium/drivers/radeon/radeon_video.c
+++ b/src/gallium/drivers/radeon/radeon_video.c
@@ -59,22 +59,28 @@ unsigned rvid_alloc_stream_handle()
stream_handle ^= ++counter;
return stream_handle;
 }
 
 /* create a buffer in the winsys */
 bool rvid_create_buffer(struct pipe_screen *screen, struct rvid_buffer *buffer,
unsigned size, unsigned usage)
 {
memset(buffer, 0, sizeof(*buffer));
buffer->usage = usage;
+
+   /* Hardware buffer placement restrictions require the kernel to be
+* able to move buffers around individually, so request a
+* non-sub-allocated buffer.
+*/
buffer->res = (struct r600_resource *)
-   pipe_buffer_create(screen, PIPE_BIND_CUSTOM, usage, size);
+   pipe_buffer_create(screen, PIPE_BIND_CUSTOM | PIPE_BIND_SHARED,
+  usage, size);
 
return buffer->res != NULL;
 }
 
 /* destroy a buffer */
 void rvid_destroy_buffer(struct rvid_buffer *buffer)
 {
r600_resource_reference(>res, NULL);
 }
 
-- 
2.7.4

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

[Mesa-dev] [PATCH v2 5/5] gallium/radeon: update documentation of buffer_get_virtual_address

[Nicolai Hähnle]

From: Nicolai Hähnle 

Reviewed-by: Marek Olšák 
---
 src/gallium/drivers/radeon/radeon_winsys.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/gallium/drivers/radeon/radeon_winsys.h 
b/src/gallium/drivers/radeon/radeon_winsys.h
index dcbebe0..d248004 100644
--- a/src/gallium/drivers/radeon/radeon_winsys.h
+++ b/src/gallium/drivers/radeon/radeon_winsys.h
@@ -500,20 +500,23 @@ struct radeon_winsys {
  * \return  true on success.
  */
 bool (*buffer_get_handle)(struct pb_buffer *buf,
   unsigned stride, unsigned offset,
   unsigned slice_size,
   struct winsys_handle *whandle);
 
 /**
  * Return the virtual address of a buffer.
  *
+ * When virtual memory is not in use, this is the offset relative to the
+ * relocation base (non-zero for sub-allocated buffers).
+ *
  * \param buf   A winsys buffer object
  * \return  virtual address
  */
 uint64_t (*buffer_get_virtual_address)(struct pb_buffer *buf);
 
 /**
  * Query the initial placement of the buffer from the kernel driver.
  */
 enum radeon_bo_domain (*buffer_get_initial_domain)(struct pb_buffer *buf);
 
-- 
2.7.4

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

Re: [Mesa-dev] Mesa 13.0.0 release plan (Was Re: Mesa 12.1.0 release plan (Was Re: Next Mesa release, anyone?))

[Marek Olšák]

On Fri, Sep 30, 2016 at 4:17 AM, Jason Ekstrand  wrote:
> On Sep 29, 2016 5:14 PM, "Timothy Arceri" 
> wrote:
>>
>> On Thu, 2016-09-29 at 15:56 +0100, Emil Velikov wrote:
>> > On 28 September 2016 at 19:53, Marek Olšák  wrote:
>> > >
>> > > Hi,
>> > >
>> > > It's been almost 4 months since the 12.0 branch was created, and
>> > > soon
>> > > it will have been 3 months since Mesa 12.0 was released.
>> > >
>> > > Is there any reason we haven't created the stable branch yet?
>> > >
>> > > Ideally, we would time the release so that it's 1-2 months before
>> > > fall
>> > > distribution releases.
>> > >
>> >
>> > Thanks Marek !
>> >
>> > In all honesty I was secretly hoping that we'll get Dave/Bas RADV for
>> > 12.1.
>>
>> I believe the release should be 13?? Core Mesa and the Intel driver
>> have reached 4.4 this release also core Mesa is now at 4.5 despite not
>> being enabled anywhere.
>
> My personal preference, for whatever it's worth, would be to call it 12.1.
> The 12.0 release was the biggest release we've had in a long time and it
> seems odd to me to jump to 13.0 right away when we really haven't done much
> at all in terms of new features. (I think it's only 2 or 3 desktop features
> in the case of Intel.  A bit more on the ES side I guess).

The rule is that the major version must be bumped when the desktop GL
version increases, but we can change that to "bump the major version
after XX.9", i.e. after 10 releases.

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

Re: [Mesa-dev] [PATCH v2] egl: stop claiming support for pbuffer + msaa

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Fri, Sep 30, 2016 at 8:32 AM, Tapani Pälli  wrote:
> This fixes a crash in egl-create-msaa-pbuffer-surface Piglit test
> and same crash in many dEQP EGL tests.
>
> I also found that some Qt example did a workaround because of this
> crash: https://bugreports.qt.io/browse/QTBUG-47509
>
> v2: Ian pointed out that v1 removed support for all multisample
> configs, including window ones. This one removes pbuffer bit
> when adding configs, now only pbuffer+msaa gets rejected and
> window+msaa continues to work. Fixed also comment (Emil)
>
> Signed-off-by: Tapani Pälli 
> Cc: mesa-sta...@lists.freedesktop.org
> ---
>  src/egl/drivers/dri2/egl_dri2.c | 9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
> index 8e376e3..803627d 100644
> --- a/src/egl/drivers/dri2/egl_dri2.c
> +++ b/src/egl/drivers/dri2/egl_dri2.c
> @@ -320,6 +320,15 @@ dri2_add_config(_EGLDisplay *disp, const __DRIconfig 
> *dri_config, int id,
>surface_type &= ~EGL_PIXMAP_BIT;
> }
>
> +   /* No support for pbuffer + MSAA for now.
> +*
> +* XXX TODO: pbuffer + MSAA does not work and causes crashes.
> +* See QT bugreport: https://bugreports.qt.io/browse/QTBUG-47509
> +*/
> +   if (base.Samples) {
> +  surface_type &= ~EGL_PBUFFER_BIT;
> +   }
> +
> conf->base.SurfaceType |= surface_type;
>
> return conf;
> --
> 2.7.4
>
> ___
> 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