Re: [Mesa-dev] [PATCH 09/10] mesa: Factor out struct gl_vertex_format.

[Mathias Fröhlich]

Hi Brian,

On Sunday, 18 November 2018 20:54:50 CET Brian Paul wrote:
> The series looks great.  Just a few minor things below.
> 
> Reviewed-by: Brian Paul 
Thank you!

For reference, the requested changes in the following mail.
I have also used GLubyte for Patch #10 then.

best

Mathias 




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

[Mesa-dev] [PATCH 09/10] mesa: Factor out struct gl_vertex_format.

[Mathias . Froehlich]

From: Mathias Fröhlich 

Factor out struct gl_vertex_format from array attributes.
The data type is supposed to describe the type of a vertex
element. At this current stage the data type is only used
with the VAO, but actually is useful in various other places.
Due to the bitfields being used, special care needs to be
taken for the glGet code paths.

v2: Change unsigned char -> GLubyte.
Use struct assignment for struct gl_vertex_format.

Reviewed-by: Brian Paul 
Signed-off-by: Mathias Fröhlich 
---
 src/mesa/drivers/dri/i965/brw_context.h   |  2 +-
 src/mesa/drivers/dri/i965/brw_draw.c  | 14 ++---
 src/mesa/drivers/dri/i965/brw_draw_upload.c   | 60 +-
 src/mesa/drivers/dri/i965/genX_state_upload.c | 14 ++---
 src/mesa/drivers/dri/nouveau/nouveau_vbo_t.c  | 10 +--
 src/mesa/main/api_arrayelt.c  | 34 +-
 src/mesa/main/arrayobj.c  | 21 +++
 src/mesa/main/draw.c  | 13 ++--
 src/mesa/main/get.c   | 15 -
 src/mesa/main/get_hash_params.py  | 20 +++---
 src/mesa/main/mtypes.h| 27 +---
 src/mesa/main/varray.c| 62 ++-
 src/mesa/main/varray.h|  6 ++
 src/mesa/state_tracker/st_atom.h  |  2 +-
 src/mesa/state_tracker/st_atom_array.c| 28 -
 src/mesa/state_tracker/st_draw_feedback.c |  2 +-
 src/mesa/tnl/t_draw.c | 22 +++
 src/mesa/tnl/t_split_copy.c   | 18 ++
 src/mesa/vbo/vbo_context.c|  5 +-
 src/mesa/vbo/vbo_exec_api.c   | 13 ++--
 src/mesa/vbo/vbo_private.h| 10 +++
 src/mesa/vbo/vbo_save_api.c   | 12 ++--
 src/mesa/vbo/vbo_save_draw.c  | 14 ++---
 src/mesa/vbo/vbo_save_loopback.c  |  2 +-
 24 files changed, 224 insertions(+), 202 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index 7fd15669eb..e5d57dd8df 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1493,7 +1493,7 @@ gl_clip_plane *brw_select_clip_planes(struct gl_context 
*ctx);
 
 /* brw_draw_upload.c */
 unsigned brw_get_vertex_surface_type(struct brw_context *brw,
- const struct gl_array_attributes *glattr);
+ const struct gl_vertex_format *glformat);
 
 static inline unsigned
 brw_get_index_type(unsigned index_size)
diff --git a/src/mesa/drivers/dri/i965/brw_draw.c 
b/src/mesa/drivers/dri/i965/brw_draw.c
index 8536c04010..f080a9fefc 100644
--- a/src/mesa/drivers/dri/i965/brw_draw.c
+++ b/src/mesa/drivers/dri/i965/brw_draw.c
@@ -303,16 +303,16 @@ brw_merge_inputs(struct brw_context *brw)
* 2_10_10_10_REV vertex formats.  Set appropriate workaround flags.
*/
   while (mask) {
- const struct gl_array_attributes *glattrib;
+ const struct gl_vertex_format *glformat;
  uint8_t wa_flags = 0;
 
  i = u_bit_scan64(&mask);
- glattrib = brw->vb.inputs[i].glattrib;
+ glformat = &brw->vb.inputs[i].glattrib->Format;
 
- switch (glattrib->Type) {
+ switch (glformat->Type) {
 
  case GL_FIXED:
-wa_flags = glattrib->Size;
+wa_flags = glformat->Size;
 break;
 
  case GL_INT_2_10_10_10_REV:
@@ -320,12 +320,12 @@ brw_merge_inputs(struct brw_context *brw)
 /* fallthough */
 
  case GL_UNSIGNED_INT_2_10_10_10_REV:
-if (glattrib->Format == GL_BGRA)
+if (glformat->Format == GL_BGRA)
wa_flags |= BRW_ATTRIB_WA_BGRA;
 
-if (glattrib->Normalized)
+if (glformat->Normalized)
wa_flags |= BRW_ATTRIB_WA_NORMALIZE;
-else if (!glattrib->Integer)
+else if (!glformat->Integer)
wa_flags |= BRW_ATTRIB_WA_SCALE;
 
 break;
diff --git a/src/mesa/drivers/dri/i965/brw_draw_upload.c 
b/src/mesa/drivers/dri/i965/brw_draw_upload.c
index dc3022bc41..dfbc45fe93 100644
--- a/src/mesa/drivers/dri/i965/brw_draw_upload.c
+++ b/src/mesa/drivers/dri/i965/brw_draw_upload.c
@@ -249,21 +249,21 @@ double_types(int size, GLboolean doubles)
  */
 unsigned
 brw_get_vertex_surface_type(struct brw_context *brw,
-const struct gl_array_attributes *glattrib)
+const struct gl_vertex_format *glformat)
 {
-   int size = glattrib->Size;
+   int size = glformat->Size;
const struct gen_device_info *devinfo = &brw->screen->devinfo;
const bool is_ivybridge_or_older =
   devinfo->gen <= 7 && !devinfo->is_baytrail && !devinfo->is_haswell;
 
if (unlikely(INTEL_DEBUG & DEBUG_VERTS))
   fprintf(stderr, "type %s size %d normalized %d\n",
-  _mesa_enum_to_string(glattrib->Type

[Mesa-dev] [PATCH 10/10] mesa: Remove unneeded bitfield widths from the VAO.

[Mathias . Froehlich]

From: Mathias Fröhlich 

With the current VAO layout we do not need to make these
fields a bitfield. We get a tight struct layout with this change
for VAO attributes.

v2: Change unsigned char -> GLubyte.

Reviewed-by: Brian Paul 
Signed-off-by: Mathias Fröhlich 
---
 src/mesa/main/mtypes.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 62d3b75a36..157d45bc0b 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -1439,7 +1439,7 @@ struct gl_array_attributes
/** Stride as specified with gl*Pointer() */
GLshort Stride;
/** Index into gl_vertex_array_object::BufferBinding[] array */
-   unsigned BufferBindingIndex:6;
+   GLubyte BufferBindingIndex;
 
/**
 * Derived effective buffer binding index
@@ -1454,7 +1454,7 @@ struct gl_array_attributes
 * Note that _mesa_update_vao_derived_arrays is called when binding
 * the VAO to Array._DrawVAO.
 */
-   unsigned _EffBufferBindingIndex:6;
+   GLubyte _EffBufferBindingIndex;
/**
 * Derived effective relative offset.
 *
-- 
2.17.2

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

Re: [Mesa-dev] [PATCH 2/2] amd/addrlib: update Mesa's copy of addrlib

[Marek Olšák]

On Tue, Nov 20, 2018 at 12:08 AM Dave Airlie  wrote:

> On Tue, 20 Nov 2018 at 14:42, Marek Olšák  wrote:
> >
> > On Mon, Nov 19, 2018 at 7:15 PM Bas Nieuwenhuizen <
> b...@basnieuwenhuizen.nl> wrote:
> >>
> >> So I tried to test this with radv and got a bunch of crashes in CTS,
> >> mostly around 3d image support:
> >>
> >> #3  0x771a9396 in __assert_fail () from /usr/lib/libc.so.6
> >> #4  0x769da3b4 in
> >> Addr::V2::Gfx9Lib::HwlGetPreferredSurfaceSetting (this=0x57661b30,
> >> pIn=0x7fffd5f0, pOut=0x7fffd5d0)
> >> at ../mesa/src/amd/addrlib/src/gfx9/gfx9addrlib.cpp:3684
> >> #5  0x769cf331 in
> >> Addr::V2::Lib::Addr2GetPreferredSurfaceSetting (this=0x57661b30,
> >> pIn=0x7fffd5f0, pOut=0x7fffd5d0)
> >> at ../mesa/src/amd/addrlib/src/core/addrlib2.cpp:1742
> >> #6  0x769c4e87 in Addr2GetPreferredSurfaceSetting
> >> (hLib=0x57661b30, pIn=0x7fffd5f0, pOut=0x7fffd5d0)
> >> at ../mesa/src/amd/addrlib/src/addrinterface.cpp:1697
> >> #7  0x769bf8d4 in gfx9_get_preferred_swizzle_mode
> >> (addrlib=0x57661b30, in=0x7fffd690, is_fmask=false,
> >> flags=33555202, swizzle_mode=0x7fffd698)
> >>
> >> It seems to be caused by the explicit swizzle mode override that we do
> with
> >>
> >> commit b64b7125586ce48232658cd860f549a6139b6ddd
> >> Author: Marek Olšák 
> >> Date:   Mon Apr 2 12:54:52 2018 -0400
> >>
> >> ac/surface/gfx9: request desired micro tile mode explicitly
> >>
> >> Tested-by: Dieter Nützel 
> >>
> >>
> >> Since we never got a reason to have it (the commit message above is
> >> not descriptive and the patch not reviewed) and this is the second
> >> time already that this breaks stuff (The other was allowing S tiling
> >> for raven displayable surfaces, per 7eff8d7d3564), maybe revert it and
> >> let addrlib make the decision?
> >
> >
> > Yes, my commits are mostly unreviewed. It's the norm now. Willing
> reviewers don't exist anymore. I don't really mind that my patches are not
> reviewed, but whoever complains that I push unreviewed commits should ask
> himself why he didn't review them in their review period. That applies to
> everybody. Either review regularly or accept that unreviewed commits are
> normal.
> >
> > Secondly, past commits can't break future commits, so don't say it
> breaks stuff again. It's illogical.
> >
> > There may be multiple reasons why the commit exists. As long as
> reverting it doesn't break piglit / radeonsi, I'm OK with the reverting.
>
> Marek,
>
> There is no way anybody could review this commit, the commit log
> contains 0 information on why or what the commit is doing or what it
> fixes, there is nothing to say what the reviewer is looking out for.
>

It's something you could have mentioned on the review though. Instead you
decided to be silent. I'm not blaming you. I understand that you probably
had no time to review radv-related patches at that time. There however has
to be some reviewer if you care about the long-term outcome whether you
personally have time or not. 0 information is not an excuse not to review.
Had there been any explanation in the commit, it wouldn't have made any
difference on the current situation, other than perhaps preventing this
pointless discussion that doesn't help anybody.

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

Re: [Mesa-dev] [PATCH 30/30] mesa/st: require linear interpolation for ARB_texture_float

[Marek Olšák]

I'd like to keep ARB_texture_float enabled on drivers that don't support
linear interpolation. ARB_texture_float is required by DX9, which doesn't
require linear interpolation. If you pushed this, you would break DX9 games
for r300, which is de-facto reference DX9 hardware.

Marek

On Mon, Nov 19, 2018 at 7:15 AM Erik Faye-Lund 
wrote:

> There's nothing in the ARB_texture_float specification that limits
> filterability for floating-point textures, so we need to ensure that
> this is required to enable this extension. Luckily, we have just the
> right bits ready.
>
> Signed-off-by: Erik Faye-Lund 
> ---
>  src/mesa/state_tracker/st_extensions.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/state_tracker/st_extensions.c
> b/src/mesa/state_tracker/st_extensions.c
> index b0fc824e30c..244934f7588 100644
> --- a/src/mesa/state_tracker/st_extensions.c
> +++ b/src/mesa/state_tracker/st_extensions.c
> @@ -1459,7 +1459,9 @@ void st_init_extensions(struct pipe_screen *screen,
>
> extensions->ARB_texture_float =
>extensions->OES_texture_half_float &&
> -  extensions->OES_texture_float;
> +  extensions->OES_texture_half_float_linear &&
> +  extensions->OES_texture_float &&
> +  extensions->OES_texture_float_linear;
>
> if (extensions->EXT_texture_filter_anisotropic &&
> screen->get_paramf(screen, PIPE_CAPF_MAX_TEXTURE_ANISOTROPY) >=
> 16.0)
> --
> 2.19.1
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] amd/addrlib: update Mesa's copy of addrlib

[Marek Olšák]

On Tue, Nov 20, 2018 at 12:08 AM Dave Airlie  wrote:

> On Tue, 20 Nov 2018 at 14:42, Marek Olšák  wrote:
> >
> > On Mon, Nov 19, 2018 at 7:15 PM Bas Nieuwenhuizen <
> b...@basnieuwenhuizen.nl> wrote:
> >>
> >> So I tried to test this with radv and got a bunch of crashes in CTS,
> >> mostly around 3d image support:
> >>
> >> #3  0x771a9396 in __assert_fail () from /usr/lib/libc.so.6
> >> #4  0x769da3b4 in
> >> Addr::V2::Gfx9Lib::HwlGetPreferredSurfaceSetting (this=0x57661b30,
> >> pIn=0x7fffd5f0, pOut=0x7fffd5d0)
> >> at ../mesa/src/amd/addrlib/src/gfx9/gfx9addrlib.cpp:3684
> >> #5  0x769cf331 in
> >> Addr::V2::Lib::Addr2GetPreferredSurfaceSetting (this=0x57661b30,
> >> pIn=0x7fffd5f0, pOut=0x7fffd5d0)
> >> at ../mesa/src/amd/addrlib/src/core/addrlib2.cpp:1742
> >> #6  0x769c4e87 in Addr2GetPreferredSurfaceSetting
> >> (hLib=0x57661b30, pIn=0x7fffd5f0, pOut=0x7fffd5d0)
> >> at ../mesa/src/amd/addrlib/src/addrinterface.cpp:1697
> >> #7  0x769bf8d4 in gfx9_get_preferred_swizzle_mode
> >> (addrlib=0x57661b30, in=0x7fffd690, is_fmask=false,
> >> flags=33555202, swizzle_mode=0x7fffd698)
> >>
> >> It seems to be caused by the explicit swizzle mode override that we do
> with
> >>
> >> commit b64b7125586ce48232658cd860f549a6139b6ddd
> >> Author: Marek Olšák 
> >> Date:   Mon Apr 2 12:54:52 2018 -0400
> >>
> >> ac/surface/gfx9: request desired micro tile mode explicitly
> >>
> >> Tested-by: Dieter Nützel 
> >>
> >>
> >> Since we never got a reason to have it (the commit message above is
> >> not descriptive and the patch not reviewed) and this is the second
> >> time already that this breaks stuff (The other was allowing S tiling
> >> for raven displayable surfaces, per 7eff8d7d3564), maybe revert it and
> >> let addrlib make the decision?
> >
> >
> > Yes, my commits are mostly unreviewed. It's the norm now. Willing
> reviewers don't exist anymore. I don't really mind that my patches are not
> reviewed, but whoever complains that I push unreviewed commits should ask
> himself why he didn't review them in their review period. That applies to
> everybody. Either review regularly or accept that unreviewed commits are
> normal.
> >
> > Secondly, past commits can't break future commits, so don't say it
> breaks stuff again. It's illogical.
> >
> > There may be multiple reasons why the commit exists. As long as
> reverting it doesn't break piglit / radeonsi, I'm OK with the reverting.
>
> Marek,
>
> There is no way anybody could review this commit, the commit log
> contains 0 information on why or what the commit is doing or what it
> fixes, there is nothing to say what the reviewer is looking out for.
>
> So maybe in future if you are pushing unreviewed commits in you could
> add the multiple reasons to the commit log? clearly you wrote the
> patch for a reason, adding the reason to the changelog shouldn't be a
> major burden.
>

Yes, I can try to do that.

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

Re: [Mesa-dev] [PATCH RFC] egl: Add a 565 pbuffer-only EGL config under X11.

[Eric Anholt]

Adam Jackson  writes:

> On Tue, 2018-10-30 at 16:38 -0700, Eric Anholt wrote:
>> Eric Anholt  writes:
>> 
>> > The CTS requires a 565-no-depth-no-stencil config for ES 3.0, but at depth
>> > 24 of X11 we wouldn't do so.  We can satisfy that bad requirement using a
>> > pbuffer-only visual with whatever other buffers the driver happens to have
>> > given us.
>> 
>> Anyone?  Still concerned about getting Mesa to pass the current
>> conformance suite.
>
> I'm not thrilled with the CTS requiring R5G6B5 tbh. Do we know if
> there's some rationale for that? Maybe something along the lines of,
> "GLES target devices are likely to only support low depths, so even a
> workstation GLES needs to implement low depths because otherwise how do
> you know it works". Not that I'd endorse such reasoning.
>
> To the patch itself:
>
>> +   /* Add a 565 pbuffer-only config.  If X11 is depth 24, we wouldn't have 
>> 565
>> +* avialable, which the CTS demands.
>^^
> Typo.
>
>> +*/
>> +   for (int j = 0; dri2_dpy->driver_configs[j]; j++) {
>> +  const __DRIconfig *config = dri2_dpy->driver_configs[j];
>> +  const EGLint config_attrs[] = {
>> + EGL_NATIVE_VISUAL_ID,0,
>> + EGL_NATIVE_VISUAL_TYPE,  EGL_NONE,
>> + EGL_NONE
>> +  };
>
> The commit message says you need no-depth and no-stencil, but you don't
> enforce that here. Are we sure we don't need to?
>
>> +  EGLint surface_type = EGL_PBUFFER_BIT;
>> +  unsigned int rgba_masks[4] = {
>> + 0x1f << 11,
>> + 0x3f << 5,
>> + 0x1f << 0,
>> + 0,
>> +  };
>> +  if (dri2_add_config(disp, config, config_count + 1, surface_type,
>> +  config_attrs, rgba_masks)) {
>> + config_count++;
>> + break;
>> +  }
>> +   }
>
> This seems like it introduces a subtle dependency on how driver_configs
> is ordered. I'm not sure you'd want your lone 565 pbuffer config to be
> sRGB or multisampled. In fact in the latter case you'd end up with an
> EGLConfig with zero bits set for EGL_SURFACE_TYPE, which is a bug in
> dri2_add_config() I suppose.
>
> That's probably not how driver_configs is sorted in reality, and
> passing CTS is a valid thing to want, so with the above addressed:
>
> Reviewed-by: Adam Jackson 
>
> But if CTS can be fixed, let's do that too.

OK, let's try that route first.

https://gitlab.khronos.org/Tracker/vk-gl-cts/issues/1474


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

Re: [Mesa-dev] [PATCH 2/2] amd/addrlib: update Mesa's copy of addrlib

[Dave Airlie]

On Tue, 20 Nov 2018 at 14:42, Marek Olšák  wrote:
>
> On Mon, Nov 19, 2018 at 7:15 PM Bas Nieuwenhuizen  
> wrote:
>>
>> So I tried to test this with radv and got a bunch of crashes in CTS,
>> mostly around 3d image support:
>>
>> #3  0x771a9396 in __assert_fail () from /usr/lib/libc.so.6
>> #4  0x769da3b4 in
>> Addr::V2::Gfx9Lib::HwlGetPreferredSurfaceSetting (this=0x57661b30,
>> pIn=0x7fffd5f0, pOut=0x7fffd5d0)
>> at ../mesa/src/amd/addrlib/src/gfx9/gfx9addrlib.cpp:3684
>> #5  0x769cf331 in
>> Addr::V2::Lib::Addr2GetPreferredSurfaceSetting (this=0x57661b30,
>> pIn=0x7fffd5f0, pOut=0x7fffd5d0)
>> at ../mesa/src/amd/addrlib/src/core/addrlib2.cpp:1742
>> #6  0x769c4e87 in Addr2GetPreferredSurfaceSetting
>> (hLib=0x57661b30, pIn=0x7fffd5f0, pOut=0x7fffd5d0)
>> at ../mesa/src/amd/addrlib/src/addrinterface.cpp:1697
>> #7  0x769bf8d4 in gfx9_get_preferred_swizzle_mode
>> (addrlib=0x57661b30, in=0x7fffd690, is_fmask=false,
>> flags=33555202, swizzle_mode=0x7fffd698)
>>
>> It seems to be caused by the explicit swizzle mode override that we do with
>>
>> commit b64b7125586ce48232658cd860f549a6139b6ddd
>> Author: Marek Olšák 
>> Date:   Mon Apr 2 12:54:52 2018 -0400
>>
>> ac/surface/gfx9: request desired micro tile mode explicitly
>>
>> Tested-by: Dieter Nützel 
>>
>>
>> Since we never got a reason to have it (the commit message above is
>> not descriptive and the patch not reviewed) and this is the second
>> time already that this breaks stuff (The other was allowing S tiling
>> for raven displayable surfaces, per 7eff8d7d3564), maybe revert it and
>> let addrlib make the decision?
>
>
> Yes, my commits are mostly unreviewed. It's the norm now. Willing reviewers 
> don't exist anymore. I don't really mind that my patches are not reviewed, 
> but whoever complains that I push unreviewed commits should ask himself why 
> he didn't review them in their review period. That applies to everybody. 
> Either review regularly or accept that unreviewed commits are normal.
>
> Secondly, past commits can't break future commits, so don't say it breaks 
> stuff again. It's illogical.
>
> There may be multiple reasons why the commit exists. As long as reverting it 
> doesn't break piglit / radeonsi, I'm OK with the reverting.

Marek,

There is no way anybody could review this commit, the commit log
contains 0 information on why or what the commit is doing or what it
fixes, there is nothing to say what the reviewer is looking out for.

So maybe in future if you are pushing unreviewed commits in you could
add the multiple reasons to the commit log? clearly you wrote the
patch for a reason, adding the reason to the changelog shouldn't be a
major burden.

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

Re: [Mesa-dev] [PATCH 2/2] amd/addrlib: update Mesa's copy of addrlib

[Marek Olšák]

On Mon, Nov 19, 2018 at 7:15 PM Bas Nieuwenhuizen 
wrote:

> So I tried to test this with radv and got a bunch of crashes in CTS,
> mostly around 3d image support:
>
> #3  0x771a9396 in __assert_fail () from /usr/lib/libc.so.6
> #4  0x769da3b4 in
> Addr::V2::Gfx9Lib::HwlGetPreferredSurfaceSetting (this=0x57661b30,
> pIn=0x7fffd5f0, pOut=0x7fffd5d0)
> at ../mesa/src/amd/addrlib/src/gfx9/gfx9addrlib.cpp:3684
> #5  0x769cf331 in
> Addr::V2::Lib::Addr2GetPreferredSurfaceSetting (this=0x57661b30,
> pIn=0x7fffd5f0, pOut=0x7fffd5d0)
> at ../mesa/src/amd/addrlib/src/core/addrlib2.cpp:1742
> #6  0x769c4e87 in Addr2GetPreferredSurfaceSetting
> (hLib=0x57661b30, pIn=0x7fffd5f0, pOut=0x7fffd5d0)
> at ../mesa/src/amd/addrlib/src/addrinterface.cpp:1697
> #7  0x769bf8d4 in gfx9_get_preferred_swizzle_mode
> (addrlib=0x57661b30, in=0x7fffd690, is_fmask=false,
> flags=33555202, swizzle_mode=0x7fffd698)
>
> It seems to be caused by the explicit swizzle mode override that we do with
>
> commit b64b7125586ce48232658cd860f549a6139b6ddd
> Author: Marek Olšák 
> Date:   Mon Apr 2 12:54:52 2018 -0400
>
> ac/surface/gfx9: request desired micro tile mode explicitly
>
> Tested-by: Dieter Nützel 
>
>
> Since we never got a reason to have it (the commit message above is
> not descriptive and the patch not reviewed) and this is the second
> time already that this breaks stuff (The other was allowing S tiling
> for raven displayable surfaces, per 7eff8d7d3564), maybe revert it and
> let addrlib make the decision?
>

Yes, my commits are mostly unreviewed. It's the norm now. Willing reviewers
don't exist anymore. I don't really mind that my patches are not reviewed,
but whoever complains that I push unreviewed commits should ask himself why
he didn't review them in their review period. That applies to everybody.
Either review regularly or accept that unreviewed commits are normal.

Secondly, past commits can't break future commits, so don't say it breaks
stuff again. It's illogical.

There may be multiple reasons why the commit exists. As long as reverting
it doesn't break piglit / radeonsi, I'm OK with the reverting.

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

[Mesa-dev] [PATCH 5/6] radeonsi/nir: parse more information about bindless usage

[Marek Olšák]

From: Marek Olšák 

---
 src/gallium/drivers/radeonsi/si_shader_nir.c | 36 +---
 1 file changed, 32 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c 
b/src/gallium/drivers/radeonsi/si_shader_nir.c
index 87ca0161b45..e7ba282b075 100644
--- a/src/gallium/drivers/radeonsi/si_shader_nir.c
+++ b/src/gallium/drivers/radeonsi/si_shader_nir.c
@@ -136,43 +136,71 @@ static void scan_instruction(struct tgsi_shader_info 
*info,
case nir_intrinsic_load_primitive_id:
info->uses_primid = 1;
break;
case nir_intrinsic_load_sample_mask_in:
info->reads_samplemask = true;
break;
case nir_intrinsic_load_tess_level_inner:
case nir_intrinsic_load_tess_level_outer:
info->reads_tess_factors = true;
break;
-   case nir_intrinsic_image_deref_load:
+   case nir_intrinsic_image_deref_load: {
+   nir_variable *var = intrinsic_get_var(intr);
+   if (var->data.bindless) {
+   info->uses_bindless_images = true;
+
+   if (glsl_get_sampler_dim(var->type) == 
GLSL_SAMPLER_DIM_BUF)
+   info->uses_bindless_buffer_load = true;
+   else
+   info->uses_bindless_image_load = true;
+   }
+   break;
+   }
case nir_intrinsic_image_deref_size:
case nir_intrinsic_image_deref_samples: {
nir_variable *var = intrinsic_get_var(intr);
if (var->data.bindless)
info->uses_bindless_images = true;
+   break;
+   }
+   case nir_intrinsic_image_deref_store: {
+   nir_variable *var = intrinsic_get_var(intr);
+   if (var->data.bindless) {
+   info->uses_bindless_images = true;
 
+   if (glsl_get_sampler_dim(var->type) == 
GLSL_SAMPLER_DIM_BUF)
+   info->uses_bindless_buffer_store = true;
+   else
+   info->uses_bindless_image_store = true;
+   }
+   info->writes_memory = true;
break;
}
-   case nir_intrinsic_image_deref_store:
case nir_intrinsic_image_deref_atomic_add:
case nir_intrinsic_image_deref_atomic_min:
case nir_intrinsic_image_deref_atomic_max:
case nir_intrinsic_image_deref_atomic_and:
case nir_intrinsic_image_deref_atomic_or:
case nir_intrinsic_image_deref_atomic_xor:
case nir_intrinsic_image_deref_atomic_exchange:
case nir_intrinsic_image_deref_atomic_comp_swap: {
nir_variable *var = intrinsic_get_var(intr);
-   if (var->data.bindless)
+   if (var->data.bindless) {
info->uses_bindless_images = true;
 
-   /* fall-through */
+   if (glsl_get_sampler_dim(var->type) == 
GLSL_SAMPLER_DIM_BUF)
+   info->uses_bindless_buffer_atomic = 
true;
+   else
+   info->uses_bindless_image_atomic = true;
+   }
+   info->writes_memory = true;
+   break;
}
case nir_intrinsic_store_ssbo:
case nir_intrinsic_ssbo_atomic_add:
case nir_intrinsic_ssbo_atomic_imin:
case nir_intrinsic_ssbo_atomic_umin:
case nir_intrinsic_ssbo_atomic_imax:
case nir_intrinsic_ssbo_atomic_umax:
case nir_intrinsic_ssbo_atomic_and:
case nir_intrinsic_ssbo_atomic_or:
case nir_intrinsic_ssbo_atomic_xor:
-- 
2.17.1

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

[Mesa-dev] [PATCH 6/6] radeonsi: fix is_oneway_access_only for bindless images

[Marek Olšák]

From: Marek Olšák 

---
 .../drivers/radeonsi/si_shader_tgsi_mem.c | 29 +++
 1 file changed, 23 insertions(+), 6 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c 
b/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
index 979e47d3cc4..6decedc4cce 100644
--- a/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
+++ b/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
@@ -389,25 +389,29 @@ static void load_emit_memory(
 }
 
 /**
  * Return true if the memory accessed by a LOAD or STORE instruction is
  * read-only or write-only, respectively.
  *
  * \param shader_buffers_reverse_access_mask
  * For LOAD, set this to (store | atomic) slot usage in the shader.
  * For STORE, set this to (load | atomic) slot usage in the shader.
  * \param images_reverse_access_mask  Same as above, but for images.
+ * \param bindless_buffer_reverse_access_mask  Same as above, but for bindless 
image buffers.
+ * \param bindless_image_reverse_access_mask   Same as above, but for bindless 
images.
  */
 static bool is_oneway_access_only(const struct tgsi_full_instruction *inst,
  const struct tgsi_shader_info *info,
  unsigned shader_buffers_reverse_access_mask,
- unsigned images_reverse_access_mask)
+ unsigned images_reverse_access_mask,
+ bool bindless_buffer_reverse_access_mask,
+ bool bindless_image_reverse_access_mask)
 {
enum tgsi_file_type resource_file;
unsigned resource_index;
bool resource_indirect;
 
if (inst->Instruction.Opcode == TGSI_OPCODE_STORE) {
resource_file = inst->Dst[0].Register.File;
resource_index = inst->Dst[0].Register.Index;
resource_indirect = inst->Dst[0].Register.Indirect;
} else {
@@ -421,25 +425,28 @@ static bool is_oneway_access_only(const struct 
tgsi_full_instruction *inst,
   /* bindless image */
   resource_file == TGSI_FILE_INPUT ||
   resource_file == TGSI_FILE_OUTPUT ||
   resource_file == TGSI_FILE_CONSTANT ||
   resource_file == TGSI_FILE_TEMPORARY ||
   resource_file == TGSI_FILE_IMMEDIATE);
 
assert(resource_file != TGSI_FILE_BUFFER ||
   inst->Memory.Texture == TGSI_TEXTURE_BUFFER);
 
+   bool bindless = resource_file != TGSI_FILE_BUFFER &&
+   resource_file != TGSI_FILE_IMAGE;
+
/* RESTRICT means NOALIAS.
 * If there are no writes, we can assume the accessed memory is 
read-only.
 * If there are no reads, we can assume the accessed memory is 
write-only.
 */
-   if (inst->Memory.Qualifier & TGSI_MEMORY_RESTRICT) {
+   if (inst->Memory.Qualifier & TGSI_MEMORY_RESTRICT && !bindless) {
unsigned reverse_access_mask;
 
if (resource_file == TGSI_FILE_BUFFER) {
reverse_access_mask = 
shader_buffers_reverse_access_mask;
} else if (inst->Memory.Texture == TGSI_TEXTURE_BUFFER) {
reverse_access_mask = info->images_buffers &
  images_reverse_access_mask;
} else {
reverse_access_mask = ~info->images_buffers &
  images_reverse_access_mask;
@@ -459,24 +466,26 @@ static bool is_oneway_access_only(const struct 
tgsi_full_instruction *inst,
 * buffers), it implies that buffer memory is read-only.
 * If there are no buffer reads (for both shader buffers & image
 * buffers), it implies that buffer memory is write-only.
 *
 * Same for the case when there are no writes/reads for non-buffer
 * images.
 */
if (resource_file == TGSI_FILE_BUFFER ||
inst->Memory.Texture == TGSI_TEXTURE_BUFFER) {
if (!shader_buffers_reverse_access_mask &&
-   !(info->images_buffers & images_reverse_access_mask))
+   !(info->images_buffers & images_reverse_access_mask) &&
+   !bindless_buffer_reverse_access_mask)
return true;
} else {
-   if (!(~info->images_buffers & images_reverse_access_mask))
+   if (!(~info->images_buffers & images_reverse_access_mask) &&
+   !bindless_image_reverse_access_mask)
return true;
}
return false;
 }
 
 static void load_emit(
const struct lp_build_tgsi_action *action,
struct lp_build_tgsi_context *bld_base,
struct lp_build_emit_data *emit_data)
 {
@@ -515,21 +524,25 @@ static void load_emit(
}
 
if (inst->Memory.Qualifier & TGSI_MEMORY_VOLATILE)
ac_build_waitcnt(&ctx->ac, V

[Mesa-dev] [PATCH 2/6] radeonsi: fix is_oneway_access_only for image stores

[Marek Olšák]

From: Marek Olšák 

---
 .../drivers/radeonsi/si_shader_tgsi_mem.c | 49 ++-
 1 file changed, 37 insertions(+), 12 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c 
b/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
index 2ba3f251ff8..81df73ea9b1 100644
--- a/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
+++ b/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
@@ -395,59 +395,83 @@ static void load_emit_memory(
  * \param shader_buffers_reverse_access_mask
  * For LOAD, set this to (store | atomic) slot usage in the shader.
  * For STORE, set this to (load | atomic) slot usage in the shader.
  * \param images_reverse_access_mask  Same as above, but for images.
  */
 static bool is_oneway_access_only(const struct tgsi_full_instruction *inst,
  const struct tgsi_shader_info *info,
  unsigned shader_buffers_reverse_access_mask,
  unsigned images_reverse_access_mask)
 {
+   enum tgsi_file_type resource_file;
+   unsigned resource_index;
+   bool resource_indirect;
+
+   if (inst->Instruction.Opcode == TGSI_OPCODE_STORE) {
+   resource_file = inst->Dst[0].Register.File;
+   resource_index = inst->Dst[0].Register.Index;
+   resource_indirect = inst->Dst[0].Register.Indirect;
+   } else {
+   resource_file = inst->Src[0].Register.File;
+   resource_index = inst->Src[0].Register.Index;
+   resource_indirect = inst->Src[0].Register.Indirect;
+   }
+
+   assert(resource_file == TGSI_FILE_BUFFER ||
+  resource_file == TGSI_FILE_IMAGE ||
+  /* bindless image */
+  resource_file == TGSI_FILE_INPUT ||
+  resource_file == TGSI_FILE_OUTPUT ||
+  resource_file == TGSI_FILE_CONSTANT ||
+  resource_file == TGSI_FILE_TEMPORARY ||
+  resource_file == TGSI_FILE_IMMEDIATE);
+
+   assert(resource_file != TGSI_FILE_BUFFER ||
+  inst->Memory.Texture == TGSI_TEXTURE_BUFFER);
+
/* RESTRICT means NOALIAS.
 * If there are no writes, we can assume the accessed memory is 
read-only.
 * If there are no reads, we can assume the accessed memory is 
write-only.
 */
if (inst->Memory.Qualifier & TGSI_MEMORY_RESTRICT) {
unsigned reverse_access_mask;
 
-   if (inst->Src[0].Register.File == TGSI_FILE_BUFFER) {
+   if (resource_file == TGSI_FILE_BUFFER) {
reverse_access_mask = 
shader_buffers_reverse_access_mask;
} else if (inst->Memory.Texture == TGSI_TEXTURE_BUFFER) {
reverse_access_mask = info->images_buffers &
  images_reverse_access_mask;
} else {
reverse_access_mask = ~info->images_buffers &
  images_reverse_access_mask;
}
 
-   if (inst->Src[0].Register.Indirect) {
+   if (resource_indirect) {
if (!reverse_access_mask)
return true;
} else {
if (!(reverse_access_mask &
- (1u << inst->Src[0].Register.Index)))
+ (1u << resource_index)))
return true;
}
}
 
/* If there are no buffer writes (for both shader buffers & image
 * buffers), it implies that buffer memory is read-only.
 * If there are no buffer reads (for both shader buffers & image
 * buffers), it implies that buffer memory is write-only.
 *
 * Same for the case when there are no writes/reads for non-buffer
 * images.
 */
-   if (inst->Src[0].Register.File == TGSI_FILE_BUFFER ||
-   (inst->Memory.Texture == TGSI_TEXTURE_BUFFER &&
-(inst->Src[0].Register.File == TGSI_FILE_IMAGE ||
- tgsi_is_bindless_image_file(inst->Src[0].Register.File {
+   if (resource_file == TGSI_FILE_BUFFER ||
+   inst->Memory.Texture == TGSI_TEXTURE_BUFFER) {
if (!shader_buffers_reverse_access_mask &&
!(info->images_buffers & images_reverse_access_mask))
return true;
} else {
if (!(~info->images_buffers & images_reverse_access_mask))
return true;
}
return false;
 }
 
@@ -643,37 +667,38 @@ static void store_emit(
const struct lp_build_tgsi_action *action,
struct lp_build_tgsi_context *bld_base,
struct lp_build_emit_data *emit_data)
 {
struct si_shader_context *ctx = si_shader_context(bld_base);
const struct tgsi_full_instruction * inst = emit_data->inst;
   

[Mesa-dev] [PATCH 3/6] radeonsi: small cleanup for memory opcodes

[Marek Olšák]

From: Marek Olšák 

---
 src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c | 13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c 
b/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
index 81df73ea9b1..979e47d3cc4 100644
--- a/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
+++ b/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
@@ -491,22 +491,21 @@ static void load_emit(
if (inst->Src[0].Register.File == TGSI_FILE_MEMORY) {
load_emit_memory(ctx, emit_data);
return;
}
 
if (inst->Src[0].Register.File == TGSI_FILE_BUFFER ||
inst->Src[0].Register.File == TGSI_FILE_CONSTBUF) {
bool ubo = inst->Src[0].Register.File == TGSI_FILE_CONSTBUF;
args.resource = shader_buffer_fetch_rsrc(ctx, &inst->Src[0], 
ubo);
voffset = ac_to_integer(&ctx->ac, lp_build_emit_fetch(bld_base, 
inst, 1, 0));
-   } else if (inst->Src[0].Register.File == TGSI_FILE_IMAGE ||
-  tgsi_is_bindless_image_file(inst->Src[0].Register.File)) {
+   } else {
unsigned target = inst->Memory.Texture;
 
image_fetch_rsrc(bld_base, &inst->Src[0], false, target, 
&args.resource);
image_fetch_coords(bld_base, inst, 1, args.resource, 
args.coords);
vindex = args.coords[0]; /* for buffers only */
}
 
if (inst->Src[0].Register.File == TGSI_FILE_CONSTBUF) {
emit_data->output[emit_data->chan] =
ac_build_buffer_load(&ctx->ac, args.resource,
@@ -678,46 +677,43 @@ static void store_emit(
if (inst->Dst[0].Register.File == TGSI_FILE_MEMORY) {
store_emit_memory(ctx, emit_data);
return;
}
 
bool writeonly_memory = is_oneway_access_only(inst, info,
  info->shader_buffers_load 
|
  
info->shader_buffers_atomic,
  info->images_load |
  info->images_atomic);
-   bool is_image = inst->Dst[0].Register.File == TGSI_FILE_IMAGE ||
-   tgsi_is_bindless_image_file(inst->Dst[0].Register.File);
LLVMValueRef chans[4], value;
LLVMValueRef vindex = ctx->i32_0;
LLVMValueRef voffset = ctx->i32_0;
struct ac_image_args args = {};
 
for (unsigned chan = 0; chan < 4; ++chan)
chans[chan] = lp_build_emit_fetch(bld_base, inst, 1, chan);
 
value = ac_build_gather_values(&ctx->ac, chans, 4);
 
if (inst->Dst[0].Register.File == TGSI_FILE_BUFFER) {
args.resource = shader_buffer_fetch_rsrc(ctx, &resource_reg, 
false);
voffset = ac_to_integer(&ctx->ac, lp_build_emit_fetch(bld_base, 
inst, 0, 0));
-   } else if (is_image) {
+   } else {
image_fetch_rsrc(bld_base, &resource_reg, true, target, 
&args.resource);
image_fetch_coords(bld_base, inst, 0, args.resource, 
args.coords);
vindex = args.coords[0]; /* for buffers only */
-   } else {
-   unreachable("unexpected register file");
}
 
if (inst->Memory.Qualifier & TGSI_MEMORY_VOLATILE)
ac_build_waitcnt(&ctx->ac, VM_CNT);
 
+   bool is_image = inst->Dst[0].Register.File != TGSI_FILE_BUFFER;
args.cache_policy = get_cache_policy(ctx, inst,
 false, /* atomic */
 is_image, /* may_store_unaligned */
 writeonly_memory);
 
if (inst->Dst[0].Register.File == TGSI_FILE_BUFFER) {
store_emit_buffer(ctx, args.resource, 
inst->Dst[0].Register.WriteMask,
  value, voffset, args.cache_policy, 
writeonly_memory);
return;
}
@@ -848,22 +844,21 @@ static void atomic_emit(
ac_to_integer(&ctx->ac, lp_build_emit_fetch(bld_base, 
inst, 3, 0));
}
 
args.data[num_data++] =
ac_to_integer(&ctx->ac, lp_build_emit_fetch(bld_base, inst, 2, 
0));
args.cache_policy = get_cache_policy(ctx, inst, true, false, false);
 
if (inst->Src[0].Register.File == TGSI_FILE_BUFFER) {
args.resource = shader_buffer_fetch_rsrc(ctx, &inst->Src[0], 
false);
voffset = ac_to_integer(&ctx->ac, lp_build_emit_fetch(bld_base, 
inst, 1, 0));
-   } else if (inst->Src[0].Register.File == TGSI_FILE_IMAGE ||
-  tgsi_is_bindless_image_file(inst->Src[0].Register.File)) {
+   } else {
image_fetch_rsrc(bld_base, &inst->Src[0], true,
inst->Memory.Texture, &args.resource);
image_fetch_coords(bld

[Mesa-dev] [PATCH 1/6] radeonsi: use structured buffer intrinsics for image views

[Marek Olšák]

From: Marek Olšák 

---
 .../drivers/radeonsi/si_shader_tgsi_mem.c | 45 ---
 src/gallium/drivers/radeonsi/si_state.c   |  7 +--
 2 files changed, 42 insertions(+), 10 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c 
b/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
index 8c44831bccb..2ba3f251ff8 100644
--- a/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
+++ b/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
@@ -691,31 +691,39 @@ static void store_emit(
 is_image, /* may_store_unaligned */
 writeonly_memory);
 
if (inst->Dst[0].Register.File == TGSI_FILE_BUFFER) {
store_emit_buffer(ctx, args.resource, 
inst->Dst[0].Register.WriteMask,
  value, voffset, args.cache_policy, 
writeonly_memory);
return;
}
 
if (target == TGSI_TEXTURE_BUFFER) {
-   LLVMValueRef buf_args[] = {
+   LLVMValueRef buf_args[6] = {
value,
args.resource,
vindex,
ctx->i32_0, /* voffset */
-   LLVMConstInt(ctx->i1, !!(args.cache_policy & ac_glc), 
0),
-   LLVMConstInt(ctx->i1, !!(args.cache_policy & ac_slc), 
0),
};
 
+   if (HAVE_LLVM >= 0x0800) {
+   buf_args[4] = ctx->i32_0; /* soffset */
+   buf_args[5] = LLVMConstInt(ctx->i1, args.cache_policy, 
0);
+   } else {
+   buf_args[4] = LLVMConstInt(ctx->i1, 
!!(args.cache_policy & ac_glc), 0);
+   buf_args[5] = LLVMConstInt(ctx->i1, 
!!(args.cache_policy & ac_slc), 0);
+   }
+
emit_data->output[emit_data->chan] = ac_build_intrinsic(
-   &ctx->ac, "llvm.amdgcn.buffer.store.format.v4f32",
+   &ctx->ac,
+   HAVE_LLVM >= 0x0800 ? 
"llvm.amdgcn.struct.buffer.store.format.v4f32" :
+ 
"llvm.amdgcn.buffer.store.format.v4f32",
ctx->voidt, buf_args, 6,
ac_get_store_intr_attribs(writeonly_memory));
} else {
args.opcode = ac_image_store;
args.data[0] = value;
args.dim = ac_image_dim_from_tgsi_target(ctx->screen, 
inst->Memory.Texture);
args.attributes = ac_get_store_intr_attribs(writeonly_memory);
args.dmask = 0xf;
 
emit_data->output[emit_data->chan] =
@@ -823,25 +831,52 @@ static void atomic_emit(
args.resource = shader_buffer_fetch_rsrc(ctx, &inst->Src[0], 
false);
voffset = ac_to_integer(&ctx->ac, lp_build_emit_fetch(bld_base, 
inst, 1, 0));
} else if (inst->Src[0].Register.File == TGSI_FILE_IMAGE ||
   tgsi_is_bindless_image_file(inst->Src[0].Register.File)) {
image_fetch_rsrc(bld_base, &inst->Src[0], true,
inst->Memory.Texture, &args.resource);
image_fetch_coords(bld_base, inst, 1, args.resource, 
args.coords);
vindex = args.coords[0]; /* for buffers only */
}
 
-   if (inst->Src[0].Register.File == TGSI_FILE_BUFFER ||
+   if (HAVE_LLVM >= 0x0800 &&
+   inst->Src[0].Register.File != TGSI_FILE_BUFFER &&
inst->Memory.Texture == TGSI_TEXTURE_BUFFER) {
LLVMValueRef buf_args[7];
unsigned num_args = 0;
 
+   buf_args[num_args++] = args.data[0];
+   if (inst->Instruction.Opcode == TGSI_OPCODE_ATOMCAS)
+   buf_args[num_args++] = args.data[1];
+
+   buf_args[num_args++] = args.resource;
+   buf_args[num_args++] = vindex;
+   buf_args[num_args++] = voffset;
+   buf_args[num_args++] = ctx->i32_0; /* soffset */
+   buf_args[num_args++] = LLVMConstInt(ctx->i32, args.cache_policy 
& ac_slc, 0);
+
+   char intrinsic_name[64];
+   snprintf(intrinsic_name, sizeof(intrinsic_name),
+"llvm.amdgcn.struct.buffer.atomic.%s", 
action->intr_name);
+   emit_data->output[emit_data->chan] =
+   ac_to_float(&ctx->ac,
+   ac_build_intrinsic(&ctx->ac, intrinsic_name,
+  ctx->i32, buf_args, 
num_args, 0));
+   return;
+   }
+
+   if (inst->Src[0].Register.File == TGSI_FILE_BUFFER ||
+   (HAVE_LLVM < 0x0800 &&
+inst->Memory.Texture == TGSI_TEXTURE_BUFFER)) {
+   LLVMValueRef buf_args[7];
+   unsigned num_args = 0;
+
buf_args[num_args++] = args.data[0];
if (inst->Instruction.Opcode == TGS

[Mesa-dev] [PATCH 4/6] tgsi/scan: add more information about bindless usage

[Marek Olšák]

From: Marek Olšák 

---
 src/gallium/auxiliary/tgsi/tgsi_scan.c | 28 --
 src/gallium/auxiliary/tgsi/tgsi_scan.h |  7 +++
 2 files changed, 33 insertions(+), 2 deletions(-)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_scan.c 
b/src/gallium/auxiliary/tgsi/tgsi_scan.c
index e13500a7f7b..4ca84902dd4 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_scan.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_scan.c
@@ -361,37 +361,61 @@ scan_instruction(struct tgsi_shader_info *info,
case TGSI_OPCODE_TEX2:
case TGSI_OPCODE_TXB2:
case TGSI_OPCODE_TXL2:
case TGSI_OPCODE_TG4:
case TGSI_OPCODE_LODQ:
   sampler_src = fullinst->Instruction.NumSrcRegs - 1;
   if (fullinst->Src[sampler_src].Register.File != TGSI_FILE_SAMPLER)
  info->uses_bindless_samplers = true;
   break;
case TGSI_OPCODE_RESQ:
+  if (tgsi_is_bindless_image_file(fullinst->Src[0].Register.File))
+ info->uses_bindless_images = true;
+  break;
case TGSI_OPCODE_LOAD:
+  if (tgsi_is_bindless_image_file(fullinst->Src[0].Register.File)) {
+ info->uses_bindless_images = true;
+
+ if (fullinst->Memory.Texture == TGSI_TEXTURE_BUFFER)
+info->uses_bindless_buffer_load = true;
+ else
+info->uses_bindless_image_load = true;
+  }
+  break;
case TGSI_OPCODE_ATOMUADD:
case TGSI_OPCODE_ATOMXCHG:
case TGSI_OPCODE_ATOMCAS:
case TGSI_OPCODE_ATOMAND:
case TGSI_OPCODE_ATOMOR:
case TGSI_OPCODE_ATOMXOR:
case TGSI_OPCODE_ATOMUMIN:
case TGSI_OPCODE_ATOMUMAX:
case TGSI_OPCODE_ATOMIMIN:
case TGSI_OPCODE_ATOMIMAX:
-  if (tgsi_is_bindless_image_file(fullinst->Src[0].Register.File))
+  if (tgsi_is_bindless_image_file(fullinst->Src[0].Register.File)) {
  info->uses_bindless_images = true;
+
+ if (fullinst->Memory.Texture == TGSI_TEXTURE_BUFFER)
+info->uses_bindless_buffer_atomic = true;
+ else
+info->uses_bindless_image_atomic = true;
+  }
   break;
case TGSI_OPCODE_STORE:
-  if (tgsi_is_bindless_image_file(fullinst->Dst[0].Register.File))
+  if (tgsi_is_bindless_image_file(fullinst->Dst[0].Register.File)) {
  info->uses_bindless_images = true;
+
+ if (fullinst->Memory.Texture == TGSI_TEXTURE_BUFFER)
+info->uses_bindless_buffer_store = true;
+ else
+info->uses_bindless_image_store = true;
+  }
   break;
default:
   break;
}
 
if (fullinst->Instruction.Opcode == TGSI_OPCODE_INTERP_CENTROID ||
fullinst->Instruction.Opcode == TGSI_OPCODE_INTERP_OFFSET ||
fullinst->Instruction.Opcode == TGSI_OPCODE_INTERP_SAMPLE) {
   const struct tgsi_full_src_register *src0 = &fullinst->Src[0];
   unsigned input;
diff --git a/src/gallium/auxiliary/tgsi/tgsi_scan.h 
b/src/gallium/auxiliary/tgsi/tgsi_scan.h
index 1887ff342de..64f2598a259 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_scan.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_scan.h
@@ -146,20 +146,27 @@ struct tgsi_shader_info
 * Bitmask indicating which declared image is a buffer.
 */
unsigned images_buffers;
unsigned images_load; /**< bitmask of images using loads */
unsigned images_store; /**< bitmask of images using stores */
unsigned images_atomic; /**< bitmask of images using atomics */
unsigned shader_buffers_declared; /**< bitmask of declared shader buffers */
unsigned shader_buffers_load; /**< bitmask of shader buffers using loads */
unsigned shader_buffers_store; /**< bitmask of shader buffers using stores 
*/
unsigned shader_buffers_atomic; /**< bitmask of shader buffers using 
atomics */
+   bool uses_bindless_buffer_load;
+   bool uses_bindless_buffer_store;
+   bool uses_bindless_buffer_atomic;
+   bool uses_bindless_image_load;
+   bool uses_bindless_image_store;
+   bool uses_bindless_image_atomic;
+
/**
 * Bitmask indicating which register files are accessed with
 * indirect addressing.  The bits are (1 << TGSI_FILE_x), etc.
 */
unsigned indirect_files;
/**
 * Bitmask indicating which register files are read / written with
 * indirect addressing.  The bits are (1 << TGSI_FILE_x).
 */
unsigned indirect_files_read;
-- 
2.17.1

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

Re: [Mesa-dev] [PATCH 2/2] amd/addrlib: update Mesa's copy of addrlib

[Bas Nieuwenhuizen]

So I tried to test this with radv and got a bunch of crashes in CTS,
mostly around 3d image support:

#3  0x771a9396 in __assert_fail () from /usr/lib/libc.so.6
#4  0x769da3b4 in
Addr::V2::Gfx9Lib::HwlGetPreferredSurfaceSetting (this=0x57661b30,
pIn=0x7fffd5f0, pOut=0x7fffd5d0)
at ../mesa/src/amd/addrlib/src/gfx9/gfx9addrlib.cpp:3684
#5  0x769cf331 in
Addr::V2::Lib::Addr2GetPreferredSurfaceSetting (this=0x57661b30,
pIn=0x7fffd5f0, pOut=0x7fffd5d0)
at ../mesa/src/amd/addrlib/src/core/addrlib2.cpp:1742
#6  0x769c4e87 in Addr2GetPreferredSurfaceSetting
(hLib=0x57661b30, pIn=0x7fffd5f0, pOut=0x7fffd5d0)
at ../mesa/src/amd/addrlib/src/addrinterface.cpp:1697
#7  0x769bf8d4 in gfx9_get_preferred_swizzle_mode
(addrlib=0x57661b30, in=0x7fffd690, is_fmask=false,
flags=33555202, swizzle_mode=0x7fffd698)

It seems to be caused by the explicit swizzle mode override that we do with

commit b64b7125586ce48232658cd860f549a6139b6ddd
Author: Marek Olšák 
Date:   Mon Apr 2 12:54:52 2018 -0400

ac/surface/gfx9: request desired micro tile mode explicitly

Tested-by: Dieter Nützel 


Since we never got a reason to have it (the commit message above is
not descriptive and the patch not reviewed) and this is the second
time already that this breaks stuff (The other was allowing S tiling
for raven displayable surfaces, per 7eff8d7d3564), maybe revert it and
let addrlib make the decision?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Partial loop unrolling support

[Jason Ekstrand]

On Mon, Nov 19, 2018 at 5:31 PM Timothy Arceri 
wrote:

> On 20/11/18 2:46 am, Jason Ekstrand wrote:
> > I also saw a case last week where the induction variable is <=
> > imax(thing, 4) and it'd be nice to unroll those too.
>
> That is an interesting one. It means we could do a simple unroll for the
> first 4 iterations i.e no if statements required, which is a bit of a
> different use case from the new functions introduced in this series but
> shouldn't bee too hard to do.
>

Actually, I think it was imin(thing, 4) so we would do a conditional unroll
of 4 iterations.  Still, it's potentially similar.  Mostly that was to
point out that more creative loop unrolling is a good thing.

--Jason


> >
> > --Jason
> >
> > On Mon, Nov 19, 2018 at 12:18 AM Timothy Arceri  > > wrote:
> >
> > This series add support for partial loop unrolling for loops with an
> > unknown trip count. The new partial_unroll function allows the caller
> > to specifiy how may times the loop should be unrolled and then the
> > loop is inserted in the innermost continue branch of the unrolled
> loop.
> >
> > For now we only do partial unrolling for loops where we can guess the
> > iteration count based on array access that uses an induction variable
> > as its index (see patch 7).
> >
> > Patches 1-6 are tidy-ups/refactors.
> >
> > Patch 7 adds a method for guessing the trip count for the loop.
> >
> > Patch 8 adds partial unrolling support and also support for removing
> > redundant load/stores from the remaining loop when considering if
> > we would be accessing an array out bounds.
> >
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org  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] Partial loop unrolling support

[Timothy Arceri]

On 20/11/18 2:46 am, Jason Ekstrand wrote:
I also saw a case last week where the induction variable is <= 
imax(thing, 4) and it'd be nice to unroll those too.


That is an interesting one. It means we could do a simple unroll for the 
first 4 iterations i.e no if statements required, which is a bit of a 
different use case from the new functions introduced in this series but 
shouldn't bee too hard to do.




--Jason

On Mon, Nov 19, 2018 at 12:18 AM Timothy Arceri > wrote:


This series add support for partial loop unrolling for loops with an
unknown trip count. The new partial_unroll function allows the caller
to specifiy how may times the loop should be unrolled and then the
loop is inserted in the innermost continue branch of the unrolled loop.

For now we only do partial unrolling for loops where we can guess the
iteration count based on array access that uses an induction variable
as its index (see patch 7).

Patches 1-6 are tidy-ups/refactors.

Patch 7 adds a method for guessing the trip count for the loop.

Patch 8 adds partial unrolling support and also support for removing
redundant load/stores from the remaining loop when considering if
we would be accessing an array out bounds.


___
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/2] winsys/amdgpu: fix a buffer leak in amdgpu_bo_from_handle

[Marek Olšák]

From: Marek Olšák 

Cc: 18.2 18.3 
---
 src/gallium/winsys/amdgpu/drm/amdgpu_bo.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c 
b/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
index f49fb47b80e..3ee38b8a79f 100644
--- a/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
+++ b/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
@@ -1303,20 +1303,26 @@ static struct pb_buffer *amdgpu_bo_from_handle(struct 
radeon_winsys *rws,
 
simple_mtx_lock(&ws->bo_export_table_lock);
bo = util_hash_table_get(ws->bo_export_table, result.buf_handle);
 
/* If the amdgpu_winsys_bo instance already exists, bump the reference
 * counter and return it.
 */
if (bo) {
   p_atomic_inc(&bo->base.reference.count);
   simple_mtx_unlock(&ws->bo_export_table_lock);
+
+  /* Release the buffer handle, because we don't need it anymore.
+   * This function is returning an existing buffer, which has its own
+   * handle.
+   */
+  amdgpu_bo_free(result.buf_handle);
   return &bo->base;
}
 
/* Get initial domains. */
r = amdgpu_bo_query_info(result.buf_handle, &info);
if (r)
   goto error;
 
r = amdgpu_va_range_alloc(ws->dev, amdgpu_gpu_va_range_general,
  result.alloc_size, 1 << 20, 0, &va, &va_handle,
-- 
2.17.1

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

[Mesa-dev] [PATCH 2/2] winsys/amdgpu: fix a device handle leak in amdgpu_winsys_create

[Marek Olšák]

From: Marek Olšák 

Cc: 18.2 18.3 
---
 src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c 
b/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c
index f32bbd9d086..b20d702670d 100644
--- a/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c
+++ b/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c
@@ -273,20 +273,26 @@ amdgpu_winsys_create(int fd, const struct 
pipe_screen_config *config,
   simple_mtx_unlock(&dev_tab_mutex);
   fprintf(stderr, "amdgpu: amdgpu_device_initialize failed.\n");
   return NULL;
}
 
/* Lookup a winsys if we have already created one for this device. */
ws = util_hash_table_get(dev_tab, dev);
if (ws) {
   pipe_reference(NULL, &ws->reference);
   simple_mtx_unlock(&dev_tab_mutex);
+
+  /* Release the device handle, because we don't need it anymore.
+   * This function is returning an existing winsys instance, which
+   * has its own device handle.
+   */
+  amdgpu_device_deinitialize(dev);
   return &ws->base;
}
 
/* Create a new winsys. */
ws = CALLOC_STRUCT(amdgpu_winsys);
if (!ws)
   goto fail;
 
ws->dev = dev;
ws->info.drm_major = drm_major;
-- 
2.17.1

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

Re: [Mesa-dev] Lets talk about autotools

[Timothy Arceri]

One thing I always go to the autoconfig webpage for is to copy and paste 
the line for a 32bit cross-compiled mesa build.


It would be good if someone could document the method for cross 
compiling on the meson page before we remove autotools.


[1] https://www.mesa3d.org/autoconf.html

On 18/9/18 2:44 am, Dylan Baker wrote:

I feel like for !windows meson is in good enough shape at this point that we
can start having the discussion about deleting the autotools build. So, is there
anything left that autotools can do that meson cannot (that we actually want to
implement)? And, what is a reasonable time-table to remove the autotools build?
I think we could reasonably remove it as soon as 18.3 if others felt confident
that it would work for them.

Dylan


___
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 V2 1/4] i965/icl: Fix L3 configurations

[Anuj Phogat]

Use L3 configuration specified in h/w specification.

V2: Drop configs which do under allocation of l3 cache.
Bump up the comment above table.

Signed-off-by: Anuj Phogat 
Cc: Kenneth Graunke 
Cc: Francisco Jerez 
---
 src/intel/common/gen_l3_config.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/intel/common/gen_l3_config.c b/src/intel/common/gen_l3_config.c
index b977c6ab136..32264394fb6 100644
--- a/src/intel/common/gen_l3_config.c
+++ b/src/intel/common/gen_l3_config.c
@@ -134,15 +134,15 @@ static const struct gen_l3_config cnl_l3_configs[] = {
 
 /**
  * ICL validated L3 configurations.  \sa icl_l3_configs.
+ * Zeroth entry in below table has been commented out intentionally
+ * due to known issues with this configuration. Many other entries
+ * suggested by h/w specification aren't added here because they
+ * do under allocation of L3 cache with below partitioning.
  */
 static const struct gen_l3_config icl_l3_configs[] = {
/* SLM URB ALL DC  RO  IS   C   T */
-   {{  0, 64, 64,  0,  0,  0,  0,  0 }},
-   {{  0, 64,  0, 16, 48,  0,  0,  0 }},
-   {{  0, 48,  0, 16, 64,  0,  0,  0 }},
-   {{  0, 32,  0,  0, 96,  0,  0,  0 }},
-   {{  0, 32, 96,  0,  0,  0,  0,  0 }},
-   {{  0, 32,  0, 16, 80,  0,  0,  0 }},
+   /*{{  0, 16, 80,  0,  0,  0,  0,  0 }},*/
+   {{  0, 32, 64,  0,  0,  0,  0,  0 }},
{{  0 }}
 };
 
-- 
2.17.1

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

Re: [Mesa-dev] [PATCH 4/5] i965/icl: Set config#9 as default config

[Anuj Phogat]

Dropping this patch.
On Tue, Nov 13, 2018 at 2:34 PM Anuj Phogat  wrote:
>
> Config#6 recommended by h/w specification causes multiple piglit
> regressions. Use config#9 instead which works well. Setting a weight
> here so that we get the desired config.
>
> Signed-off-by: Anuj Phogat 
> Cc: Kenneth Graunke 
> Cc: Francisco Jerez 
> Cc: Lionel Landwerlin 
> ---
>  src/intel/common/gen_l3_config.c | 13 ++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/src/intel/common/gen_l3_config.c 
> b/src/intel/common/gen_l3_config.c
> index de16ad23017..52c1cdd32f4 100644
> --- a/src/intel/common/gen_l3_config.c
> +++ b/src/intel/common/gen_l3_config.c
> @@ -257,7 +257,13 @@ gen_get_default_l3_weights(const struct gen_device_info 
> *devinfo,
> w.w[GEN_L3P_SLM] = devinfo->gen < 11 && needs_slm;
> w.w[GEN_L3P_URB] = 1.0;
>
> -   if (devinfo->gen >= 8) {
> +   if (devinfo->gen == 11) {
> +  /* Config#6 recommended by h/w specification causes multiple piglit
> +   * regressions. Use config#9 instead which works well. Setting a weight
> +   * here so that we get the desired config.
> +  */
> +  w.w[GEN_L3P_ALL] = 2.0;
> +   } else if (devinfo->gen >= 8) {
>w.w[GEN_L3P_ALL] = 1.0;
> } else {
>w.w[GEN_L3P_DC] = needs_dc ? 0.1 : 0;
> @@ -277,8 +283,9 @@ gen_get_default_l3_config(const struct gen_device_info 
> *devinfo)
>  * default configuration.
>  */
> const struct gen_l3_config *const cfg = get_l3_configs(devinfo);
> -   assert(cfg == gen_get_l3_config(devinfo,
> -gen_get_default_l3_weights(devinfo, false, false)));
> +   assert(devinfo->gen == 11 ||
> +  cfg == gen_get_l3_config(devinfo,
> +  gen_get_default_l3_weights(devinfo, false, false)));
> return cfg;
>  }
>
> --
> 2.17.1
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/4] freedreno: a2xx: add partial lower_scalar pass for ir2

[Eric Anholt]

Jonathan Marek  writes:

> some instructions can only be scalar on a2xx, lower these only

Could we have the core ALU scalar lowering take an optional bitmask or
something of ALU ops that need scalar lowering?


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

Re: [Mesa-dev] [PATCH 1/5] i965/icl: Fix L3 configurations

[Anuj Phogat]

On Fri, Nov 16, 2018 at 2:52 PM Francisco Jerez  wrote:
>
> Anuj Phogat  writes:
>
> > On Fri, Nov 16, 2018 at 6:21 AM Eero Tamminen  
> > wrote:
> >>
> >> Hi,
> >>
> >> On 16.11.2018 10.33, Francisco Jerez wrote:
> >> > Kenneth Graunke  writes:
> >> [...]
> >> >> Perhaps we'll get both configs working, and then will want to be able
> >> >> to select between them.  I question whether the additional URB is truly
> >> >> that valuable - how large are the actual gains? - considering that we
> >> >> have to stall in order to reconfigure everything anyway...
> >>
> >> It's more about value of additional space for caching textures.
> >>
> >> One can calculate required max URB space when GS/TS isn't used, whereas
> >> textures can fill all available cache.  For example, if draw does just a
> >> single quad, L3 is better utilized with minimal URB space and leaving
> >> rest for texture caching.
> >>
> > Right. URB (16) and ALL (80) config is the one with minimum URB allocation.
> > But, it's not working probably because of a hardware bug. Inferring from 
> > above
> > comments by ken and Eero, If we ever get it working, we should always be 
> > using
> > just that one config and that's the config which h/w documentation 
> > recommends
> > as well. Correct me if that's not what you meant.
>
> I don't think anybody said that.  There is a use-case for the 32/64
> configuration even after we get thee other configuration working, that's
> why the hardware even gives you the choice.
>
> > In that case, I would prefer to bypass all this code and do it in
> > brw_upload_initial_gpu_state().
> >
>
> There is no real benefit from that.  It would be more complexity than
> using the exact same codepath for all platforms.  It won't improve
> runtime performance measurably.  And it will close the door to several
> performance optimizations which are still valuable on ICL.
>
ok. I don't see an agreement on the changes proposed by Ken. So, I propose
to go ahead with current way of uploading l3 config on ICL and make further
changes on top of it when we have more information. I think programming the
right config is more important atm.

> >>
> >> > That just means that the update frequency needs to be low enough for the
> >> > stall overhead to be negligible -- E.g. at batch buffer boundaries or
> >> > wherever we're getting stalled anyway.
> >>
> >>
> >> - Eero
> >> ___
> >> 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 2/4] freedreno: a2xx: add partial lower_scalar pass for ir2

[Jonathan Marek]

some instructions can only be scalar on a2xx, lower these only

Signed-off-by: Jonathan Marek 
---
 .../drivers/freedreno/Makefile.sources|   1 +
 src/gallium/drivers/freedreno/a2xx/ir2_nir.c  |   3 +
 .../freedreno/a2xx/ir2_nir_lower_scalar.c | 174 ++
 .../drivers/freedreno/a2xx/ir2_private.h  |   1 +
 src/gallium/drivers/freedreno/meson.build |   1 +
 5 files changed, 180 insertions(+)
 create mode 100644 src/gallium/drivers/freedreno/a2xx/ir2_nir_lower_scalar.c

diff --git a/src/gallium/drivers/freedreno/Makefile.sources 
b/src/gallium/drivers/freedreno/Makefile.sources
index 9061b26ba7..7f2b8e7b7d 100644
--- a/src/gallium/drivers/freedreno/Makefile.sources
+++ b/src/gallium/drivers/freedreno/Makefile.sources
@@ -87,6 +87,7 @@ a2xx_SOURCES := \
a2xx/instr-a2xx.h \
a2xx/ir2.c \
a2xx/ir2_nir.c \
+   a2xx/ir2_nir_lower_scalar.c \
a2xx/ir2_substitutions.c \
a2xx/ir2_ra.c \
a2xx/ir2_assemble.c \
diff --git a/src/gallium/drivers/freedreno/a2xx/ir2_nir.c 
b/src/gallium/drivers/freedreno/a2xx/ir2_nir.c
index f24debf140..12d4ee6653 100644
--- a/src/gallium/drivers/freedreno/a2xx/ir2_nir.c
+++ b/src/gallium/drivers/freedreno/a2xx/ir2_nir.c
@@ -1112,6 +1112,9 @@ ir2_nir_compile(struct ir2_context *ctx, unsigned variant)
/* postprocess */
OPT_V(ctx->nir, nir_opt_algebraic_late);
 
+   /* lower to scalar instructions that can only be scalar on a2xx */
+   OPT_V(ctx->nir, ir2_nir_lower_scalar);
+
OPT_V(ctx->nir, nir_lower_to_source_mods);
OPT_V(ctx->nir, nir_copy_prop);
OPT_V(ctx->nir, nir_opt_dce);
diff --git a/src/gallium/drivers/freedreno/a2xx/ir2_nir_lower_scalar.c 
b/src/gallium/drivers/freedreno/a2xx/ir2_nir_lower_scalar.c
new file mode 100644
index 00..2b72a86b3e
--- /dev/null
+++ b/src/gallium/drivers/freedreno/a2xx/ir2_nir_lower_scalar.c
@@ -0,0 +1,174 @@
+/*
+ * Copyright (C) 2018 Jonathan Marek 
+ *
+ * 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, sublicense,
+ * 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 NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS 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.
+ *
+ * Authors:
+ *Jonathan Marek 
+ */
+
+/* some operations can only be scalar on a2xx:
+ *  rsq, rcp, log2, exp2, cos, sin, sqrt
+ * mostly copy-pasted from nir_lower_alu_to_scalar.c
+ */
+
+#include "ir2_private.h"
+#include "compiler/nir/nir_builder.h"
+
+static void
+nir_alu_ssa_dest_init(nir_alu_instr * instr, unsigned num_components,
+ unsigned bit_size)
+{
+   nir_ssa_dest_init(&instr->instr, &instr->dest.dest, num_components,
+ bit_size, NULL);
+   instr->dest.write_mask = (1 << num_components) - 1;
+}
+
+static void
+lower_reduction(nir_alu_instr * instr, nir_op chan_op, nir_op merge_op,
+   nir_builder * builder)
+{
+   unsigned num_components = nir_op_infos[instr->op].input_sizes[0];
+
+   nir_ssa_def *last = NULL;
+   for (unsigned i = 0; i < num_components; i++) {
+   nir_alu_instr *chan =
+   nir_alu_instr_create(builder->shader, chan_op);
+   nir_alu_ssa_dest_init(chan, 1, instr->dest.dest.ssa.bit_size);
+   nir_alu_src_copy(&chan->src[0], &instr->src[0], chan);
+   chan->src[0].swizzle[0] = chan->src[0].swizzle[i];
+   if (nir_op_infos[chan_op].num_inputs > 1) {
+   assert(nir_op_infos[chan_op].num_inputs == 2);
+   nir_alu_src_copy(&chan->src[1], &instr->src[1], chan);
+   chan->src[1].swizzle[0] = chan->src[1].swizzle[i];
+   }
+   chan->exact = instr->exact;
+
+   nir_builder_instr_insert(builder, &chan->instr);
+
+   if (i == 0) {
+   last = &chan->dest.dest.ssa;
+   } else {
+   last = nir_build_alu(builder, merge_op,
+  

[Mesa-dev] [PATCH 3/4] freedreno: implement a20x hw binning

[Jonathan Marek]

Not in this patch: emitting the hw binning variant and filling the
"draw_patches". That is part of the ir2 patch.

Signed-off-by: Jonathan Marek 
---
 src/gallium/drivers/freedreno/a2xx/fd2_draw.c |  51 ++--
 src/gallium/drivers/freedreno/a2xx/fd2_emit.c |   8 +-
 src/gallium/drivers/freedreno/a2xx/fd2_emit.h |   3 +-
 src/gallium/drivers/freedreno/a2xx/fd2_gmem.c | 118 ++
 .../drivers/freedreno/freedreno_gmem.c|  29 +++--
 .../drivers/freedreno/freedreno_gmem.h|   1 +
 6 files changed, 190 insertions(+), 20 deletions(-)

diff --git a/src/gallium/drivers/freedreno/a2xx/fd2_draw.c 
b/src/gallium/drivers/freedreno/a2xx/fd2_draw.c
index 6945a1dc3d..cab20d0295 100644
--- a/src/gallium/drivers/freedreno/a2xx/fd2_draw.c
+++ b/src/gallium/drivers/freedreno/a2xx/fd2_draw.c
@@ -75,19 +75,29 @@ emit_vertexbufs(struct fd_context *ctx)
// CONST(20,0) (or CONST(26,0) in soliv_vp)
 
fd2_emit_vertex_bufs(ctx->batch->draw, 0x78, bufs, vtx->num_elements);
+   fd2_emit_vertex_bufs(ctx->batch->binning, 0x78, bufs, 
vtx->num_elements);
 }
 
 static void
 draw_impl(struct fd_context *ctx, const struct pipe_draw_info *info,
-  struct fd_ringbuffer *ring, unsigned index_offset)
+  struct fd_ringbuffer *ring, unsigned index_offset,
+  bool binning)
 {
+   enum pc_di_vis_cull_mode vismode;
+
OUT_PKT3(ring, CP_SET_CONSTANT, 2);
OUT_RING(ring, CP_REG(REG_A2XX_VGT_INDX_OFFSET));
OUT_RING(ring, info->index_size ? 0 : info->start);
 
-   OUT_PKT3(ring, CP_SET_CONSTANT, 2);
-   OUT_RING(ring, CP_REG(REG_A2XX_VGT_VERTEX_REUSE_BLOCK_CNTL));
-   OUT_RING(ring, is_a20x(ctx->screen) ? 0x0002 : 0x003b);
+   /* in the binning batch, this value is set once in fd2_emit_tile_init */
+   if (!binning) {
+   OUT_PKT3(ring, CP_SET_CONSTANT, 2);
+   OUT_RING(ring, CP_REG(REG_A2XX_VGT_VERTEX_REUSE_BLOCK_CNTL));
+   /* XXX do this for every REG_A2XX_VGT_VERTEX_REUSE_BLOCK_CNTL 
write ?
+* if set to 0x3b on a20x, clipping is broken
+*/
+   OUT_RING(ring, is_a20x(ctx->screen) ? 0x0002 : 0x003b);
+   }
 
OUT_PKT0(ring, REG_A2XX_TC_CNTL_STATUS, 1);
OUT_RING(ring, A2XX_TC_CNTL_STATUS_L2_INVALIDATE);
@@ -123,8 +133,26 @@ draw_impl(struct fd_context *ctx, const struct 
pipe_draw_info *info,
OUT_RING(ring, info->min_index);/* VGT_MIN_VTX_INDX */
}
 
+   /* binning shader will take offset from C64 */
+   if (binning && is_a20x(ctx->screen)) {
+   OUT_PKT3(ring, CP_SET_CONSTANT, 5);
+   OUT_RING(ring, 0x0180);
+   OUT_RING(ring, fui(ctx->batch->num_vertices));
+   OUT_RING(ring, fui(0.0f));
+   OUT_RING(ring, fui(0.0f));
+   OUT_RING(ring, fui(0.0f));
+   }
+
+   vismode = binning ? IGNORE_VISIBILITY : USE_VISIBILITY;
+   /* a22x hw binning not implemented */
+   if (binning || !is_a20x(ctx->screen) || (fd_mesa_debug & FD_DBG_NOBIN))
+   vismode = IGNORE_VISIBILITY;
+
+   if (info->mode == PIPE_PRIM_POINTS)
+   vismode = IGNORE_VISIBILITY;
+
fd_draw_emit(ctx->batch, ring, ctx->primtypes[info->mode],
-IGNORE_VISIBILITY, info, index_offset);
+vismode, info, index_offset);
 
if (is_a20x(ctx->screen)) {
/* not sure why this is required, but it fixes some hangs */
@@ -149,7 +177,8 @@ fd2_draw_vbo(struct fd_context *ctx, const struct 
pipe_draw_info *pinfo,
if (ctx->dirty & FD_DIRTY_VTXBUF)
emit_vertexbufs(ctx);
 
-   fd2_emit_state(ctx, ctx->dirty);
+   fd2_emit_state(ctx, ctx->batch->draw, ctx->dirty);
+   fd2_emit_state(ctx, ctx->batch->binning, ctx->dirty);
 
/* a2xx can draw only 65535 vertices at once
 * on a22x the field in the draw command is 32bits but seems limited too
@@ -170,17 +199,23 @@ fd2_draw_vbo(struct fd_context *ctx, const struct 
pipe_draw_info *pinfo,
struct pipe_draw_info info = *pinfo;
unsigned count = info.count;
unsigned step = step_tbl[info.mode];
+   unsigned num_vertices = ctx->batch->num_vertices;
 
if (!step)
return false;
 
for (; count + step > 32766; count -= step) {
info.count = MIN2(count, 32766);
-   draw_impl(ctx, &info, ctx->batch->draw, index_offset);
+   draw_impl(ctx, &info, ctx->batch->draw, index_offset, 
false);
+   draw_impl(ctx, &info, ctx->batch->binning, 
index_offset, true);
info.start += step;
+   ctx->batch->num_vertices += step;
}
+   /* changing this value is a hack, restore it */
+ 

[Mesa-dev] [PATCH 4/4] freedreno: use MSM_BO_SCANOUT with scanout buffers

[Jonathan Marek]

Signed-off-by: Jonathan Marek 
---
 src/gallium/drivers/freedreno/drm/freedreno_drmif.h | 1 +
 src/gallium/drivers/freedreno/drm/msm_bo.c  | 3 +++
 src/gallium/drivers/freedreno/freedreno_resource.c  | 4 +++-
 3 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/freedreno/drm/freedreno_drmif.h 
b/src/gallium/drivers/freedreno/drm/freedreno_drmif.h
index 6468eac4a0..e12ab970c8 100644
--- a/src/gallium/drivers/freedreno/drm/freedreno_drmif.h
+++ b/src/gallium/drivers/freedreno/drm/freedreno_drmif.h
@@ -63,6 +63,7 @@ enum fd_param_id {
 #define DRM_FREEDRENO_GEM_CACHE_WBACKWA   0x0080
 #define DRM_FREEDRENO_GEM_CACHE_MASK  0x00f0
 #define DRM_FREEDRENO_GEM_GPUREADONLY 0x0100
+#define DRM_FREEDRENO_GEM_SCANOUT 0x0200
 
 /* bo access flags: (keep aligned to MSM_PREP_x) */
 #define DRM_FREEDRENO_PREP_READ   0x01
diff --git a/src/gallium/drivers/freedreno/drm/msm_bo.c 
b/src/gallium/drivers/freedreno/drm/msm_bo.c
index da3315c9ab..d93dfbeab2 100644
--- a/src/gallium/drivers/freedreno/drm/msm_bo.c
+++ b/src/gallium/drivers/freedreno/drm/msm_bo.c
@@ -142,6 +142,9 @@ int msm_bo_new_handle(struct fd_device *dev,
};
int ret;
 
+   if (flags & DRM_FREEDRENO_GEM_SCANOUT)
+   req.flags |= MSM_BO_SCANOUT;
+
ret = drmCommandWriteRead(dev->fd, DRM_MSM_GEM_NEW,
&req, sizeof(req));
if (ret)
diff --git a/src/gallium/drivers/freedreno/freedreno_resource.c 
b/src/gallium/drivers/freedreno/freedreno_resource.c
index 54d7385896..bd7be94c85 100644
--- a/src/gallium/drivers/freedreno/freedreno_resource.c
+++ b/src/gallium/drivers/freedreno/freedreno_resource.c
@@ -99,7 +99,9 @@ realloc_bo(struct fd_resource *rsc, uint32_t size)
 {
struct fd_screen *screen = fd_screen(rsc->base.screen);
uint32_t flags = DRM_FREEDRENO_GEM_CACHE_WCOMBINE |
-   DRM_FREEDRENO_GEM_TYPE_KMEM; /* TODO */
+   DRM_FREEDRENO_GEM_TYPE_KMEM |
+   COND(rsc->base.bind & PIPE_BIND_SCANOUT, 
DRM_FREEDRENO_GEM_SCANOUT);
+   /* TODO other flags? */
 
/* if we start using things other than write-combine,
 * be sure to check for PIPE_RESOURCE_FLAG_MAP_COHERENT
-- 
2.17.1

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

[Mesa-dev] [PATCH] meson: Add tests to suites

[Dylan Baker]

Meson test has a concepts of suites, which allow tests to be grouped
together. This allows for a subtest of tests to be run only (say only
the tests for nir). A test can be added to more than one suite, but for
the most part I've only added a test to a single suite, though I've
added a compiler group that includes nir, glsl, and glcpp tests.

To use this you'll need to invoke meson test directly, instead of ninja
test (which always runs all targets). it can be invoked as:
`meson test -C builddir --suite $suitename` (meson test has addition
options that are pretty useful).
---
 src/broadcom/qpu/meson.build  |  3 ++-
 src/compiler/glsl/glcpp/meson.build   |  1 +
 src/compiler/glsl/tests/meson.build   | 18 +-
 src/compiler/nir/meson.build  |  7 +--
 src/egl/meson.build   |  6 --
 src/gallium/drivers/llvmpipe/meson.build  |  3 ++-
 src/gallium/drivers/r300/meson.build  |  3 ++-
 src/gbm/meson.build   |  3 ++-
 src/glx/tests/meson.build |  3 ++-
 src/intel/compiler/meson.build|  3 ++-
 src/intel/isl/meson.build |  3 ++-
 src/intel/vulkan/meson.build  |  3 ++-
 src/mapi/es1api/meson.build   |  3 ++-
 src/mapi/es2api/meson.build   |  3 ++-
 src/mapi/glapi/meson.build|  3 ++-
 src/mapi/shared-glapi/meson.build |  3 ++-
 src/mesa/main/tests/meson.build   |  3 ++-
 src/mesa/state_tracker/tests/meson.build  |  8 +---
 src/util/meson.build  |  9 ++---
 src/util/tests/fast_idiv_by_const/meson.build |  3 ++-
 src/util/tests/hash_table/meson.build |  3 ++-
 src/util/tests/set/meson.build|  3 ++-
 src/util/tests/string_buffer/meson.build  |  3 ++-
 src/util/tests/vma/meson.build|  3 ++-
 24 files changed, 70 insertions(+), 33 deletions(-)

diff --git a/src/broadcom/qpu/meson.build b/src/broadcom/qpu/meson.build
index 8a40016064d..279b09cb95a 100644
--- a/src/broadcom/qpu/meson.build
+++ b/src/broadcom/qpu/meson.build
@@ -41,5 +41,6 @@ test(
 'qpu_disasm', 'tests/qpu_disasm.c',
 link_with: [libbroadcom_qpu, libmesa_util],
 include_directories: inc_common
-  )
+  ),
+  suite : ['broadcom'],
 )
diff --git a/src/compiler/glsl/glcpp/meson.build 
b/src/compiler/glsl/glcpp/meson.build
index a03d589b370..677baf1df10 100644
--- a/src/compiler/glsl/glcpp/meson.build
+++ b/src/compiler/glsl/glcpp/meson.build
@@ -70,6 +70,7 @@ if with_any_opengl and with_tests
 glcpp, join_paths(meson.current_source_dir(), 'tests'),
 '--@0@'.format(m),
   ],
+  suite : ['compiler', 'glcpp'],
 )
   endforeach
 endif
diff --git a/src/compiler/glsl/tests/meson.build 
b/src/compiler/glsl/tests/meson.build
index 2a41e30a28d..02f3355c43c 100644
--- a/src/compiler/glsl/tests/meson.build
+++ b/src/compiler/glsl/tests/meson.build
@@ -26,7 +26,8 @@ test(
 c_args : [c_vis_args, c_msvc_compat_args, no_override_init_args],
 include_directories : [inc_common, inc_compiler],
 link_with : [libglsl],
-  )
+  ),
+  suite : ['compiler', 'glsl'],
 )
 
 test(
@@ -38,7 +39,8 @@ test(
 include_directories : [inc_common, inc_glsl],
 link_with : [libglsl],
 dependencies : [dep_clock, dep_thread],
-  )
+  ),
+  suite : ['compiler', 'glsl'],
 )
 
 
@@ -54,7 +56,8 @@ test(
 include_directories : [inc_common, inc_glsl],
 link_with : [libglsl, libglsl_standalone, libglsl_util],
 dependencies : [dep_clock, dep_thread, idep_gtest],
-  )
+  ),
+  suite : ['compiler', 'glsl'],
 )
 
 test(
@@ -68,7 +71,8 @@ test(
 include_directories : [inc_common, inc_glsl],
 link_with : [libglsl, libglsl_util],
 dependencies : [dep_thread, idep_gtest],
-  )
+  ),
+  suite : ['compiler', 'glsl'],
 )
 
 test(
@@ -80,7 +84,8 @@ test(
 include_directories : [inc_common, inc_glsl],
 link_with : [libglsl, libglsl_util],
 dependencies : [dep_thread, idep_gtest],
-  )
+  ),
+  suite : ['compiler', 'glsl'],
 )
 
 test(
@@ -93,7 +98,9 @@ test(
   meson.source_root(), 'src', 'compiler', 'glsl', 'tests', 'warnings'
 ),
   ],
+  suite : ['compiler', 'glsl'],
 )
+
 test(
   'glsl optimization',
   prog_python,
@@ -101,4 +108,5 @@ test(
 join_paths(meson.current_source_dir(), 'optimization_test.py'),
 '--test-runner', glsl_test
   ],
+  suite : ['compiler', 'glsl'],
 )
diff --git a/src/compiler/nir/meson.build b/src/compiler/nir/meson.build
index b0c3a7feb31..61f61f0a34b 100644
--- a/src/compiler/nir/meson.build
+++ b/src/compiler/nir/meson.build
@@ -246,8 +246,10 @@ if with_tests
   include_directories : [inc_common],
   dependencies : [dep_thread, idep_gtest, idep_nir],
   link_with : libmesa_util,
-)
+), 
+suite : ['compiler', 'nir'],
   )
+
   test(
 'nir_vars',
 executable(
@@ -257,6 +259,7 @@ if with_tests
   

[Mesa-dev] [PATCH v2] radv: remove dependency on addrlib gfx9_enum.h

[Nicolai Hähnle]

From: Nicolai Hähnle 

v2:
- use SI_CONTEXT_REG_OFFSET

Reviewed-by: Dave Airlie 
---
 src/amd/common/sid.h | 3 +++
 src/amd/vulkan/radv_cmd_buffer.c | 6 ++
 src/amd/vulkan/radv_device.c | 9 -
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/src/amd/common/sid.h b/src/amd/common/sid.h
index 35782046dd5..49683f1aa5a 100644
--- a/src/amd/common/sid.h
+++ b/src/amd/common/sid.h
@@ -2429,20 +2429,23 @@
 #define   C_008F30_ANISO_BIAS 
0xF81F
 #define   S_008F30_TRUNC_COORD(x) 
(((unsigned)(x) & 0x1) << 27)
 #define   G_008F30_TRUNC_COORD(x) (((x) >> 
27) & 0x1)
 #define   C_008F30_TRUNC_COORD
0xF7FF
 #define   S_008F30_DISABLE_CUBE_WRAP(x)   
(((unsigned)(x) & 0x1) << 28)
 #define   G_008F30_DISABLE_CUBE_WRAP(x)   (((x) >> 
28) & 0x1)
 #define   C_008F30_DISABLE_CUBE_WRAP  
0xEFFF
 #define   S_008F30_FILTER_MODE(x) 
(((unsigned)(x) & 0x03) << 29)
 #define   G_008F30_FILTER_MODE(x) (((x) >> 
29) & 0x03)
 #define   C_008F30_FILTER_MODE
0x9FFF
+#define V_008F30_SQ_IMG_FILTER_MODE_BLEND   0x00
+#define V_008F30_SQ_IMG_FILTER_MODE_MIN 0x01
+#define V_008F30_SQ_IMG_FILTER_MODE_MAX 0x02
 /* VI */
 #define   S_008F30_COMPAT_MODE(x) 
(((unsigned)(x) & 0x1) << 31)
 #define   G_008F30_COMPAT_MODE(x) (((x) >> 
31) & 0x1)
 #define   C_008F30_COMPAT_MODE
0x7FFF
 /**/
 #define R_008F34_SQ_IMG_SAMP_WORD1  
0x008F34
 #define   S_008F34_MIN_LOD(x) 
(((unsigned)(x) & 0xFFF) << 0)
 #define   G_008F34_MIN_LOD(x) (((x) >> 
0) & 0xFFF)
 #define   C_008F34_MIN_LOD
0xF000
 #define   S_008F34_MAX_LOD(x) 
(((unsigned)(x) & 0xFFF) << 12)
diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 8e0ed284d65..efec0424349 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -30,22 +30,20 @@
 #include "radv_shader.h"
 #include "radv_cs.h"
 #include "sid.h"
 #include "gfx9d.h"
 #include "vk_format.h"
 #include "radv_debug.h"
 #include "radv_meta.h"
 
 #include "ac_debug.h"
 
-#include "addrlib/gfx9/chip/gfx9_enum.h"
-
 enum {
RADV_PREFETCH_VBO_DESCRIPTORS   = (1 << 0),
RADV_PREFETCH_VS= (1 << 1),
RADV_PREFETCH_TCS   = (1 << 2),
RADV_PREFETCH_TES   = (1 << 3),
RADV_PREFETCH_GS= (1 << 4),
RADV_PREFETCH_PS= (1 << 5),
RADV_PREFETCH_SHADERS   = (RADV_PREFETCH_VS  |
   RADV_PREFETCH_TCS |
   RADV_PREFETCH_TES |
@@ -1314,21 +1312,21 @@ radv_load_ds_clear_metadata(struct radv_cmd_buffer 
*cmd_buffer,
}
if (aspects & VK_IMAGE_ASPECT_DEPTH_BIT)
++reg_count;
 
uint32_t reg = R_028028_DB_STENCIL_CLEAR + 4 * reg_offset;
 
if (cmd_buffer->device->physical_device->rad_info.chip_class >= VI) {
radeon_emit(cs, PKT3(PKT3_LOAD_CONTEXT_REG, 3, 0));
radeon_emit(cs, va);
radeon_emit(cs, va >> 32);
-   radeon_emit(cs, (reg >> 2) - CONTEXT_SPACE_START);
+   radeon_emit(cs, (reg - SI_CONTEXT_REG_OFFSET) >> 2);
radeon_emit(cs, reg_count);
} else {
radeon_emit(cs, PKT3(PKT3_COPY_DATA, 4, 0));
radeon_emit(cs, COPY_DATA_SRC_SEL(COPY_DATA_SRC_MEM) |
COPY_DATA_DST_SEL(COPY_DATA_REG) |
(reg_count == 2 ? COPY_DATA_COUNT_SEL : 0));
radeon_emit(cs, va);
radeon_emit(cs, va >> 32);
radeon_emit(cs, reg >> 2);
radeon_emit(cs, 0);
@@ -1452,21 +1450,21 @@ radv_load_color_clear_metadata(struct radv_cmd_buffer 
*cmd_buffer,
 
if (!radv_image_has_cmask(image) && !radv_image_has_dcc(image))
return;
 
uint32_t reg = R_028C8C_CB_COLOR0_CLEAR_WORD0 + cb_idx * 0x3c;
 
if (cmd_buffer->device->physical_device->rad_info.chip_class >= VI) {
radeon_emit(cs, PKT3(PKT3_LOAD_CONTEXT_REG, 3, 
cmd_buffer->state.predicating));
radeon_emit(cs, va);
radeon_emit(cs, va >> 32);
-   radeon_emit(cs, (reg >> 2) - CONTEXT_SPACE_START);
+   

[Mesa-dev] [PATCH 2/2] i965: add missing rollback of a xfb zero_offsets flag

[asimiklit . work]

From: Andrii Simiklit 

This patch is needed to avoid incorrect value of StreamOffset flag
in 3DSTATE_SO_BUFFER command after rollback operation.

To be able to test easily this issue
the following workaround is necessary:
-if (!brw_batch_has_aperture_space(brw, 0)) {
by:
+if (true) {
in brw_draw_single_prim function.

This workaround forces a rollback for each batch.
The "gl-3.2-adj-prims pv-first -fbo" piglit test with this workaround failed
(when URB requirements was fixed this test started to fail instead of a hang).
Investigation of this failure helped to find that some batches have a different
Stream Offset in the 3D STATE_SO_BUFFER command in compare to batches which were
generated without this workaround.

Reported-by: Kenneth Graunke 
Signed-off-by: Andrii Simiklit 
---
 src/mesa/drivers/dri/i965/brw_context.h   |  3 +++
 src/mesa/drivers/dri/i965/intel_batchbuffer.c | 10 ++
 2 files changed, 13 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index 4e1682ba5c..86c9bf0a5c 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -521,6 +521,9 @@ struct intel_batchbuffer {
   int batch_reloc_count;
   int state_reloc_count;
   int exec_count;
+  struct {
+ bool zero_offsets;
+  } xfb;
   struct {
  GLuint vsize;
  GLuint gsize;
diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c 
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
index bae9f2ffed..85e5f64123 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
@@ -295,10 +295,15 @@ intel_batchbuffer_reset_and_clear_render_cache(struct 
brw_context *brw)
 void
 intel_batchbuffer_save_state(struct brw_context *brw)
 {
+   struct brw_transform_feedback_object *brw_xfb_obj =
+   (struct brw_transform_feedback_object *)
+brw->ctx.TransformFeedback.CurrentObject;
+
brw->batch.saved.map_next = brw->batch.map_next;
brw->batch.saved.batch_reloc_count = brw->batch.batch_relocs.reloc_count;
brw->batch.saved.state_reloc_count = brw->batch.state_relocs.reloc_count;
brw->batch.saved.exec_count = brw->batch.exec_count;
+   brw->batch.saved.xfb.zero_offsets = brw_xfb_obj->zero_offsets;
brw->batch.saved.urb.vsize = brw->urb.vsize;
brw->batch.saved.urb.gs_present = brw->urb.gs_present;
brw->batch.saved.urb.gsize = brw->urb.gsize;
@@ -310,6 +315,10 @@ intel_batchbuffer_save_state(struct brw_context *brw)
 void
 intel_batchbuffer_reset_to_saved(struct brw_context *brw)
 {
+   struct brw_transform_feedback_object *brw_xfb_obj =
+   (struct brw_transform_feedback_object *)
+brw->ctx.TransformFeedback.CurrentObject;
+
for (int i = brw->batch.saved.exec_count;
 i < brw->batch.exec_count; i++) {
   brw_bo_unreference(brw->batch.exec_bos[i]);
@@ -319,6 +328,7 @@ intel_batchbuffer_reset_to_saved(struct brw_context *brw)
brw->batch.exec_count = brw->batch.saved.exec_count;
 
brw->batch.map_next = brw->batch.saved.map_next;
+   brw_xfb_obj->zero_offsets = brw->batch.saved.xfb.zero_offsets;
brw->urb.vsize = brw->batch.saved.urb.vsize;
brw->urb.gs_present = brw->batch.saved.urb.gs_present;
brw->urb.gsize = brw->batch.saved.urb.gsize;
-- 
2.17.1

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

[Mesa-dev] [PATCH 1/2] i965: add missing rollback of URB requirements

[asimiklit . work]

From: Andrii Simiklit 

This patch is needed to avoid missing 3DSTATE_URB_* commands in a batch after
rollback operation.

To be able to test easily this issue
the following workaround is necessary:
-if (!brw_batch_has_aperture_space(brw, 0)) {
by:
+if (true) {
in brw_draw_single_prim function.

This workaround forces a rollback for each batch.
The "gl-3.2-adj-prims pv-first -auto -fbo" piglit test with this workaround
led to a hung. The hung investigation helped to find that some batches
didn't have the 3DSTATE_URB_* commands in compare to batches which were
generated without this workaround.

Reported-by: Kenneth Graunke 
Signed-off-by: Andrii Simiklit 
---
 src/mesa/drivers/dri/i965/brw_context.h   |  8 
 src/mesa/drivers/dri/i965/intel_batchbuffer.c | 12 
 2 files changed, 20 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index 7fd15669eb..4e1682ba5c 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -521,6 +521,14 @@ struct intel_batchbuffer {
   int batch_reloc_count;
   int state_reloc_count;
   int exec_count;
+  struct {
+ GLuint vsize;
+ GLuint gsize;
+ GLuint hsize;
+ GLuint dsize;
+ bool gs_present;
+ bool tess_present;
+  } urb;
} saved;
 
/** Map from batch offset to brw_state_batch data (with DEBUG_BATCH) */
diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c 
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
index 353fcba18f..bae9f2ffed 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
@@ -299,6 +299,12 @@ intel_batchbuffer_save_state(struct brw_context *brw)
brw->batch.saved.batch_reloc_count = brw->batch.batch_relocs.reloc_count;
brw->batch.saved.state_reloc_count = brw->batch.state_relocs.reloc_count;
brw->batch.saved.exec_count = brw->batch.exec_count;
+   brw->batch.saved.urb.vsize = brw->urb.vsize;
+   brw->batch.saved.urb.gs_present = brw->urb.gs_present;
+   brw->batch.saved.urb.gsize = brw->urb.gsize;
+   brw->batch.saved.urb.tess_present = brw->urb.tess_present;
+   brw->batch.saved.urb.hsize = brw->urb.hsize;
+   brw->batch.saved.urb.dsize = brw->urb.dsize;
 }
 
 void
@@ -313,6 +319,12 @@ intel_batchbuffer_reset_to_saved(struct brw_context *brw)
brw->batch.exec_count = brw->batch.saved.exec_count;
 
brw->batch.map_next = brw->batch.saved.map_next;
+   brw->urb.vsize = brw->batch.saved.urb.vsize;
+   brw->urb.gs_present = brw->batch.saved.urb.gs_present;
+   brw->urb.gsize = brw->batch.saved.urb.gsize;
+   brw->urb.tess_present = brw->batch.saved.urb.tess_present;
+   brw->urb.hsize = brw->batch.saved.urb.hsize;
+   brw->urb.dsize = brw->batch.saved.urb.dsize;
if (USED_BATCH(brw->batch) == 0)
   brw_new_batch(brw);
 }
-- 
2.17.1

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

Re: [Mesa-dev] [PATCH 1/3] nir: add fceil lowering

[Rob Clark]

On Mon, Nov 19, 2018 at 3:15 PM Christian Gmeiner
 wrote:
>
> Am Mo., 12. Nov. 2018 um 19:17 Uhr schrieb Jonathan Marek :
> >
> > lowers ceil(x) as -floor(-x)
> >
> > Signed-off-by: Jonathan Marek 
>
> Do you have push rights? As I am interested in this one I would push
> it for you if needed.
>

I have it queued up to push sometime in the next couple of days, but
if you have need for it sooner feel free to push it yourself

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

Re: [Mesa-dev] Lets talk about autotools

[Kai Wasserbäch]

Hey Dylan,
Dylan Baker wrote on 19.11.18 20:02:
> Sorry, cell phones are really bad for responding to email...

no worries.

> The file has the same rules as cross files, it can be a local file, passed as 
> an
> absolute path, or read from $XDG directories (local files will be read before
> XDG ones).

That sounds workable then. I might have preferred a simple option/flag on the
CLI, but this works as well.

Cheers,
Kai



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 1/3] nir: add fceil lowering

[Christian Gmeiner]

Am Mo., 19. Nov. 2018 um 21:17 Uhr schrieb Jonathan marek :
>
> I don't have push rights, but robclark added this patch to his staging
> branch so I imagine he will push it soon.
>

Great..

> On 11/19/2018 03:15 PM, Christian Gmeiner wrote:
> > Am Mo., 12. Nov. 2018 um 19:17 Uhr schrieb Jonathan Marek 
> > :
> >>
> >> lowers ceil(x) as -floor(-x)
> >>
> >> Signed-off-by: Jonathan Marek 
> >
> > Do you have push rights? As I am interested in this one I would push
> > it for you if needed.
> >



-- 
greets
--
Christian Gmeiner, MSc

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

Re: [Mesa-dev] [PATCH 4/4] i965: Add support for and expose EXT_texture_sRGB_R8

[Mark Janes]

Eric Engestrom  writes:

> On Thursday, 2018-11-15 19:01:24 +0100, Gert Wollny wrote:
>> Emulate MESA_FORMAT_R_SRGB8 by using L8_UNORM_SRGB. This is possible
>> because component swizzling is handled based on the mesa format and,
>> hence, the a r001 swizzling can be used to correct the components.
>> 
>> Enables and makes pass (tested on Kabylake)
>> 
>>   dEQP-GLES31.functional.srgb_texture_decode.skip_decode.sr8.*
>>   dEQP-GLES31.functional.texture.filtering.cube_array.formats.sr8*
>> 
>> Signed-off-by: Gert Wollny 
>
> Patches 1-3 are:
> Reviewed-by: Eric Engestrom 
>
> Patch 4 is:
> Acked-by: Eric Engestrom 

For external contributors, patches like this should not be R-B or Acked
unless they have been tested in the i965 CI.

This series failed to build when pushed, and regressed many tests when
the compilation error was corrected.

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

Gert, we can set up a CI build for you if you feel like it would be
helpful to your work.  Eric can also test your patches by pushing them
to his CI project.

>> ---
>>  src/mesa/drivers/dri/i965/brw_surface_formats.c | 1 +
>>  src/mesa/drivers/dri/i965/intel_extensions.c| 1 +
>>  2 files changed, 2 insertions(+)
>> 
>> diff --git a/src/mesa/drivers/dri/i965/brw_surface_formats.c 
>> b/src/mesa/drivers/dri/i965/brw_surface_formats.c
>> index 879cb42453..77476a8c7e 100644
>> --- a/src/mesa/drivers/dri/i965/brw_surface_formats.c
>> +++ b/src/mesa/drivers/dri/i965/brw_surface_formats.c
>> @@ -67,6 +67,7 @@ brw_isl_format_for_mesa_format(mesa_format mesa_format)
>>[MESA_FORMAT_B8G8R8A8_SRGB] = ISL_FORMAT_B8G8R8A8_UNORM_SRGB,
>>[MESA_FORMAT_R8G8B8A8_SRGB] = ISL_FORMAT_R8G8B8A8_UNORM_SRGB,
>>[MESA_FORMAT_B8G8R8X8_SRGB] = ISL_FORMAT_B8G8R8X8_UNORM_SRGB,
>> +  [MESA_FORMAT_R_SRGB8] = ISL_FORMAT_L8_UNORM_SRGB,
>>[MESA_FORMAT_L_SRGB8] = ISL_FORMAT_L8_UNORM_SRGB,
>>[MESA_FORMAT_L8A8_SRGB] = ISL_FORMAT_L8A8_UNORM_SRGB,
>>[MESA_FORMAT_SRGB_DXT1] = ISL_FORMAT_BC1_UNORM_SRGB,
>> diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c 
>> b/src/mesa/drivers/dri/i965/intel_extensions.c
>> index d7e02efb54..6ec6248a70 100644
>> --- a/src/mesa/drivers/dri/i965/intel_extensions.c
>> +++ b/src/mesa/drivers/dri/i965/intel_extensions.c
>> @@ -113,6 +113,7 @@ intelInitExtensions(struct gl_context *ctx)
>> ctx->Extensions.EXT_texture_snorm = true;
>> ctx->Extensions.EXT_texture_sRGB = true;
>> ctx->Extensions.EXT_texture_sRGB_decode = true;
>> +   ctx->Extensions.EXT_texture_sRGB_R8 = true;
>> ctx->Extensions.EXT_texture_swizzle = true;
>> ctx->Extensions.EXT_texture_type_2_10_10_10_REV = true;
>> ctx->Extensions.EXT_vertex_array_bgra = true;
>> -- 
>> 2.19.1
>> 
>> ___
>> 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

Re: [Mesa-dev] [PATCH 1/3] nir: add fceil lowering

[Jonathan marek]

I don't have push rights, but robclark added this patch to his staging 
branch so I imagine he will push it soon.


On 11/19/2018 03:15 PM, Christian Gmeiner wrote:

Am Mo., 12. Nov. 2018 um 19:17 Uhr schrieb Jonathan Marek :


lowers ceil(x) as -floor(-x)

Signed-off-by: Jonathan Marek 


Do you have push rights? As I am interested in this one I would push
it for you if needed.


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

[Mesa-dev] [PATCH 3/3] ac: handle cast derefs

[Dave Airlie]

From: Dave Airlie 

Just give back the same value for now.
---
 src/amd/common/ac_nir_to_llvm.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index cc795324cc5..d7296a4617e 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -3715,6 +3715,9 @@ static void visit_deref(struct ac_nir_context *ctx,
result = ac_build_gep0(&ctx->ac, get_src(ctx, instr->parent),
   get_src(ctx, instr->arr.index));
break;
+   case nir_deref_type_cast:
+   result = get_src(ctx, instr->parent);
+   break;
default:
unreachable("Unhandled deref_instr deref type");
}
-- 
2.17.2

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

[Mesa-dev] [PATCH 1/3] ac: avoid casting pointers on bcsel and stores

[Dave Airlie]

From: Dave Airlie 

For variable pointers we really don't want to case the pointers to int
without a good reason, just add a wrapper for bcsel loading and result
storing.
---
 src/amd/common/ac_llvm_build.c  | 9 +
 src/amd/common/ac_llvm_build.h  | 1 +
 src/amd/common/ac_nir_to_llvm.c | 7 ---
 3 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index 1392ec0f238..ba5edd6cd93 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -229,6 +229,15 @@ ac_to_integer(struct ac_llvm_context *ctx, LLVMValueRef v)
return LLVMBuildBitCast(ctx->builder, v, ac_to_integer_type(ctx, type), 
"");
 }
 
+LLVMValueRef
+ac_to_integer_or_pointer(struct ac_llvm_context *ctx, LLVMValueRef v)
+{
+   LLVMTypeRef type = LLVMTypeOf(v);
+   if (LLVMGetTypeKind(type) == LLVMPointerTypeKind)
+   return v;
+   return ac_to_integer(ctx, v);
+}
+
 static LLVMTypeRef to_float_type_scalar(struct ac_llvm_context *ctx, 
LLVMTypeRef t)
 {
if (t == ctx->i16 || t == ctx->f16)
diff --git a/src/amd/common/ac_llvm_build.h b/src/amd/common/ac_llvm_build.h
index 1275e4fb698..e90c8c21ad4 100644
--- a/src/amd/common/ac_llvm_build.h
+++ b/src/amd/common/ac_llvm_build.h
@@ -128,6 +128,7 @@ unsigned ac_get_type_size(LLVMTypeRef type);
 
 LLVMTypeRef ac_to_integer_type(struct ac_llvm_context *ctx, LLVMTypeRef t);
 LLVMValueRef ac_to_integer(struct ac_llvm_context *ctx, LLVMValueRef v);
+LLVMValueRef ac_to_integer_or_pointer(struct ac_llvm_context *ctx, 
LLVMValueRef v);
 LLVMTypeRef ac_to_float_type(struct ac_llvm_context *ctx, LLVMTypeRef t);
 LLVMValueRef ac_to_float(struct ac_llvm_context *ctx, LLVMValueRef v);
 
diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index c950b81dca2..f24b63bb158 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -270,8 +270,9 @@ static LLVMValueRef emit_bcsel(struct ac_llvm_context *ctx,
 {
LLVMValueRef v = LLVMBuildICmp(ctx->builder, LLVMIntNE, src0,
   ctx->i32_0, "");
-   return LLVMBuildSelect(ctx->builder, v, ac_to_integer(ctx, src1),
-  ac_to_integer(ctx, src2), "");
+   return LLVMBuildSelect(ctx->builder, v,
+  ac_to_integer_or_pointer(ctx, src1),
+  ac_to_integer_or_pointer(ctx, src2), "");
 }
 
 static LLVMValueRef emit_minmax_int(struct ac_llvm_context *ctx,
@@ -1095,7 +1096,7 @@ static void visit_alu(struct ac_nir_context *ctx, const 
nir_alu_instr *instr)
 
if (result) {
assert(instr->dest.dest.is_ssa);
-   result = ac_to_integer(&ctx->ac, result);
+   result = ac_to_integer_or_pointer(&ctx->ac, result);
ctx->ssa_defs[instr->dest.dest.ssa.index] = result;
}
 }
-- 
2.17.2

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

[Mesa-dev] [PATCH 2/3] radv: handle loading from shared pointers

[Dave Airlie]

From: Dave Airlie 

We won't have a var to load from, so don't try to the processing
required if we don't need it.

This avoids crashes in:
dEQP-VK.spirv_assembly.instruction.compute.variable_pointers.compute.workgroup_two_buffers

Signed-off-by: Dave Airlie 
---
 src/amd/common/ac_nir_to_llvm.c | 27 ++-
 1 file changed, 18 insertions(+), 9 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index f24b63bb158..cc795324cc5 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -1861,23 +1861,32 @@ static LLVMValueRef visit_load_var(struct 
ac_nir_context *ctx,
nir_variable *var = 
nir_deref_instr_get_variable(nir_instr_as_deref(instr->src[0].ssa->parent_instr));
 
LLVMValueRef values[8];
-   int idx = var->data.driver_location;
+   int idx = 0;
int ve = instr->dest.ssa.num_components;
-   unsigned comp = var->data.location_frac;
+   unsigned comp = 0;
LLVMValueRef indir_index;
LLVMValueRef ret;
unsigned const_index;
-   unsigned stride = var->data.compact ? 1 : 4;
-   bool vs_in = ctx->stage == MESA_SHADER_VERTEX &&
-var->data.mode == nir_var_shader_in;
-
-   get_deref_offset(ctx, 
nir_instr_as_deref(instr->src[0].ssa->parent_instr), vs_in, NULL, NULL,
-&const_index, &indir_index);
+   unsigned stride = 4;
+   int mode = nir_var_shared;
+   
+   if (var) {
+   bool vs_in = ctx->stage == MESA_SHADER_VERTEX &&
+   var->data.mode == nir_var_shader_in;
+   if (var->data.compact)
+   stride = 1;
+   idx = var->data.driver_location;
+   comp = var->data.location_frac;
+   mode = var->data.mode;
+
+   get_deref_offset(ctx, 
nir_instr_as_deref(instr->src[0].ssa->parent_instr), vs_in, NULL, NULL,
+&const_index, &indir_index);
+   }
 
if (instr->dest.ssa.bit_size == 64)
ve *= 2;
 
-   switch (var->data.mode) {
+   switch (mode) {
case nir_var_shader_in:
if (ctx->stage == MESA_SHADER_TESS_CTRL ||
ctx->stage == MESA_SHADER_TESS_EVAL) {
-- 
2.17.2

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

[Mesa-dev] radv variable pointer precursors

[Dave Airlie]

Variable pointer support still needs another NIR patch, but
these are the 3 ac/radv patches needed to make the tests pass,
apart from the final enable patch.

Dave.

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

Re: [Mesa-dev] [PATCH 1/3] nir: add fceil lowering

[Christian Gmeiner]

Am Mo., 12. Nov. 2018 um 19:17 Uhr schrieb Jonathan Marek :
>
> lowers ceil(x) as -floor(-x)
>
> Signed-off-by: Jonathan Marek 

Do you have push rights? As I am interested in this one I would push
it for you if needed.

-- 
greets
--
Christian Gmeiner, MSc

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

[Mesa-dev] [PATCH 3/3] nir: combine fmul and fadd across ffma operations

[Jonathan Marek]

This works by moving the fadd up across the ffma operations, so that it
can eventually can be combined with a fmul. I'm not sure it works in all
cases, but it works in all the common cases.

This will only affect freedreno since it is the only driver using the
fuse_ffma option.

Example:
matrix * vec4(coord, 1.0)
is compiled as:
fmul, ffma, ffma, fadd
and with this patch:
ffma, ffma, ffma

Signed-off-by: Jonathan Marek 
---
 src/compiler/nir/nir_opt_algebraic.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/compiler/nir/nir_opt_algebraic.py 
b/src/compiler/nir/nir_opt_algebraic.py
index 8f4df891b8..8d7c30e04a 100644
--- a/src/compiler/nir/nir_opt_algebraic.py
+++ b/src/compiler/nir/nir_opt_algebraic.py
@@ -133,6 +133,7 @@ optimizations = [
(('~fadd@64', a, ('fmul', c , ('fadd', b, ('fneg', a, ('flrp', 
a, b, c), '!options->lower_flrp64'),
(('ffma', a, b, c), ('fadd', ('fmul', a, b), c), 'options->lower_ffma'),
(('~fadd', ('fmul', a, b), c), ('ffma', a, b, c), 'options->fuse_ffma'),
+   (('~fadd', ('ffma', a, b, c), d), ('ffma', a, b, ('fadd', c, d)), 
'options->fuse_ffma'),
 
(('fdot4', ('vec4', a, b,   c,   1.0), d), ('fdph',  ('vec3', a, b, c), d)),
(('fdot4', ('vec4', a, 0.0, 0.0, 0.0), b), ('fmul', a, b)),
-- 
2.17.1

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

[Mesa-dev] [PATCH 2/3] glsl/nir: ftrunc for native_integers=false float to int cast

[Jonathan Marek]

out_type is always GLSL_TYPE_FLOAT, so we don't get the ftrunc otherwise

since there are no other conversions needed, use fmov for the other cases
(there is the f2b case, but the 1-bit bool patches should fix that)

Signed-off-by: Jonathan Marek 
---
 src/compiler/glsl/glsl_to_nir.cpp | 13 +
 1 file changed, 13 insertions(+)

diff --git a/src/compiler/glsl/glsl_to_nir.cpp 
b/src/compiler/glsl/glsl_to_nir.cpp
index 22863c072f..5d1ae85924 100644
--- a/src/compiler/glsl/glsl_to_nir.cpp
+++ b/src/compiler/glsl/glsl_to_nir.cpp
@@ -1560,6 +1560,19 @@ nir_visitor::visit(ir_expression *ir)
case ir_unop_u2i:
case ir_unop_i642u64:
case ir_unop_u642i64: {
+  if (!supports_ints) {
+ switch (ir->operation) {
+ case ir_unop_f2i:
+ case ir_unop_f2u:
+result = nir_ftrunc(&b, srcs[0]);
+break;
+ default:
+result = nir_fmov(&b, srcs[0]);
+break;
+ }
+ break;
+  }
+
   nir_alu_type src_type = nir_get_nir_type_for_glsl_base_type(types[0]);
   nir_alu_type dst_type = nir_get_nir_type_for_glsl_base_type(out_type);
   result = nir_build_alu(&b, nir_type_conversion_op(src_type, dst_type,
-- 
2.17.1

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

[Mesa-dev] [PATCH 1/3] glsl/nir: int constants as float for native_integers=false

[Jonathan Marek]

Note: the backend must take care that uniform index is now a float

Signed-off-by: Jonathan Marek 
---
 src/compiler/glsl/glsl_to_nir.cpp | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/src/compiler/glsl/glsl_to_nir.cpp 
b/src/compiler/glsl/glsl_to_nir.cpp
index 0479f8fcfe..22863c072f 100644
--- a/src/compiler/glsl/glsl_to_nir.cpp
+++ b/src/compiler/glsl/glsl_to_nir.cpp
@@ -93,6 +93,8 @@ private:
 
nir_deref_instr *evaluate_deref(ir_instruction *ir);
 
+   nir_constant *constant_copy(ir_constant *ir, void *mem_ctx);
+
/* most recent deref instruction created */
nir_deref_instr *deref;
 
@@ -196,8 +198,8 @@ nir_visitor::evaluate_deref(ir_instruction *ir)
return this->deref;
 }
 
-static nir_constant *
-constant_copy(ir_constant *ir, void *mem_ctx)
+nir_constant *
+nir_visitor::constant_copy(ir_constant *ir, void *mem_ctx)
 {
if (ir == NULL)
   return NULL;
@@ -215,7 +217,10 @@ constant_copy(ir_constant *ir, void *mem_ctx)
   assert(cols == 1);
 
   for (unsigned r = 0; r < rows; r++)
- ret->values[0].u32[r] = ir->value.u[r];
+ if (supports_ints)
+ret->values[0].u32[r] = ir->value.u[r];
+ else
+ret->values[0].f32[r] = ir->value.u[r];
 
   break;
 
@@ -224,7 +229,10 @@ constant_copy(ir_constant *ir, void *mem_ctx)
   assert(cols == 1);
 
   for (unsigned r = 0; r < rows; r++)
- ret->values[0].i32[r] = ir->value.i[r];
+ if (supports_ints)
+ret->values[0].i32[r] = ir->value.i[r];
+ else
+ret->values[0].f32[r] = ir->value.i[r];
 
   break;
 
-- 
2.17.1

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

Re: [Mesa-dev] Lets talk about autotools

[Dylan Baker]

Quoting Gert Wollny (2018-11-18 02:56:00)
> Am Freitag, den 16.11.2018, 20:04 -0800 schrieb Dylan Baker:
> > 
> > Is there anything else we're missing in meson to be able to drop
> > autotools?
> 
> One thing that I notes is that it seems to be impossible to run the
> test suite for just one subdirectory because the only way to run the
> build is from the binary root directory. With autotools, when I do some
> work on a sub-module (like I did with mesa/st) I can just go there and
> run make check on the few tests that are there where I actually change
> code, with meson/ninja this doesn't seem to be possible and I have to
> either run the  full test suite, or run the test executables manually. 
> 
> One workaround I found on stack overflow [1] would be to give the
> test suites in these subdirectories different names so that one can
> then run e.g. 'ninja test.mesa.st' (the example there is using cmake as
> a basis to create the build.ninja file though). 
> 
> Another think I noted  - and I'm not sure  whether this is a feature or
> a bug - is that if CFLAG or CXXFLAGS are set in the environment, then
> it seems that the flags that should be added by the buildtype are
> ignored (Usually it turns out that -DDEBUG is missing, even though I
> selected debug or debugoptimized as build type).

That seems bad, I'll look into that very soon.

Dylan


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

Re: [Mesa-dev] Lets talk about autotools

[Dylan Baker]

Quoting Gert Wollny (2018-11-18 02:56:00)
> Am Freitag, den 16.11.2018, 20:04 -0800 schrieb Dylan Baker:
> > 
> > Is there anything else we're missing in meson to be able to drop
> > autotools?
> 
> One thing that I notes is that it seems to be impossible to run the
> test suite for just one subdirectory because the only way to run the
> build is from the binary root directory. With autotools, when I do some
> work on a sub-module (like I did with mesa/st) I can just go there and
> run make check on the few tests that are there where I actually change
> code, with meson/ninja this doesn't seem to be possible and I have to
> either run the  full test suite, or run the test executables manually. 
> 
> One workaround I found on stack overflow [1] would be to give the
> test suites in these subdirectories different names so that one can
> then run e.g. 'ninja test.mesa.st' (the example there is using cmake as
> a basis to create the build.ninja file though). 

meson supports test suites, I'll send a patch to add them. You don't get quite
as nice of a target name, but you can use `meson test -C builddir --suite
$suite` to run just tests from a specfic suite. I'll send out a patch to add
our tests to suites.

> 
> Another think I noted  - and I'm not sure  whether this is a feature or
> a bug - is that if CFLAG or CXXFLAGS are set in the environment, then
> it seems that the flags that should be added by the buildtype are
> ignored (Usually it turns out that -DDEBUG is missing, even though I
> selected debug or debugoptimized as build type).
> 
> Best, 
> Gert
> 
> https://stackoverflow.com/questions/28636295/ninja-equivalent-of-makes-
> build-from-this-directory-down-feature-with-cmake
> 
> 
> 
> 
> 
> 
> > 
> > Dylan
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

Re: [Mesa-dev] [PATCH v2 26/32] intel/isl: Add support for computing offsets with miptails

[Jason Ekstrand]

On Mon, Nov 19, 2018 at 12:30 PM Pohjolainen, Topi <
topi.pohjolai...@gmail.com> wrote:

> On Fri, Oct 12, 2018 at 01:46:56PM -0500, Jason Ekstrand wrote:
> > Unfortunately, there is no nice way to calculate miptail offsets in
> > closed form.  Instead, we just copy the tables from the PRM directly
> > verbatim.
> > ---
> >  src/intel/isl/isl.c | 217 +++-
> >  1 file changed, 213 insertions(+), 4 deletions(-)
> >
> > diff --git a/src/intel/isl/isl.c b/src/intel/isl/isl.c
> > index 3657b11ee00..c86390bf851 100644
> > --- a/src/intel/isl/isl.c
> > +++ b/src/intel/isl/isl.c
> > @@ -863,6 +863,169 @@ isl_calc_phys_level0_extent_sa(const struct
> isl_device *dev,
> > }
> >  }
> >
> > +static const uint16_t std_y_1d_miptail_offset_el[] = {
> > +/* 128 bpb */
> > +   2048,
> > +   1024,
> > +   512,
> > +   256,
> > +   128,
> > +   64,
> > +   48,
> > +   32,
> > +   28,
> > +   24,
> > +   20,
> > +   16,
> > +   12,
> > +   8,
> > +   4,
> > +   0,
> > +};
> > +
> > +static const uint8_t gen9_std_y_2d_miptail_offset_el[][5][2] = {
> > +/*   128 bpb64 bpb32 bpb16 bpb  8 bpb */
> > +   { {32,  0}, {64,  0}, {64,  0}, {128,  0}, {128,  0} },
> > +   { { 0, 32}, { 0, 32}, { 0, 64}, {  0, 64}, {  0,128} },
> > +   { {16,  0}, {32,  0}, {32,  0}, { 64,  0}, { 64,  0} },
> > +   { { 0, 16}, { 0, 16}, { 0, 32}, {  0, 32}, {  0, 64} },
> > +   { { 8,  0}, {16,  0}, {16,  0}, { 32,  0}, { 32,  0} },
> > +   { { 4,  8}, { 8,  8}, { 8, 16}, { 16, 16}, { 16, 32} },
> > +   { { 0, 12}, { 0, 12}, { 0, 24}, {  0, 24}, {  0, 48} },
> > +   { { 0,  8}, { 0,  8}, { 0, 16}, {  0, 16}, {  0, 32} },
> > +   { { 4,  4}, { 8,  4}, { 8,  8}, { 16,  8}, { 16, 16} },
> > +   { { 4,  0}, { 8,  0}, { 8,  0}, { 16,  0}, { 16,  0} },
> > +   { { 0,  4}, { 0,  4}, { 0,  8}, {  0,  8}, {  0, 16} },
> > +   { { 3,  0}, { 6,  0}, { 4,  4}, {  8,  4}, {  0, 12} },
> > +   { { 2,  0}, { 4,  0}, { 4,  0}, {  8,  0}, {  0,  8} },
> > +   { { 1,  0}, { 2,  0}, { 0,  4}, {  0,  4}, {  0,  4} },
> > +   { { 0,  0}, { 0,  0}, { 0,  0}, {  0,  0}, {  0,  0} },
> > +};
> > +
> > +static const uint8_t gen10_std_y_2d_miptail_offset_el[][5][2] = {
> > +/*   128 bpb64 bpb32 bpb16 bpb  8 bpb */
> > +   { {32,  0}, {64,  0}, {64,  0}, {128,  0}, {128,   0} },
> > +   { { 0, 32}, { 0, 32}, { 0, 64}, {  0, 64}, {  0, 128} },
> > +   { {16,  0}, {32,  0}, {32,  0}, { 64,  0}, { 64,   0} },
> > +   { { 0, 16}, { 0, 16}, { 0, 32}, {  0, 32}, {  0,  64} },
> > +   { { 8,  0}, {16,  0}, {16,  0}, { 32,  0}, { 32,   0} },
> > +   { { 4,  8}, { 8,  8}, { 8, 16}, { 16, 16}, { 16,  32} },
> > +   { { 0, 12}, { 0, 12}, { 0, 24}, {  0, 24}, {  0,  48} },
> > +   { { 0,  8}, { 0,  8}, { 0, 16}, {  0, 16}, {  0,  32} },
> > +   { { 4,  4}, { 8,  4}, { 8,  8}, { 16,  8}, { 16,  16} },
> > +   { { 4,  0}, { 8,  0}, { 8,  0}, { 16,  0}, { 16,   0} },
> > +   { { 0,  4}, { 0,  4}, { 0,  8}, {  0,  8}, {  0,  16} },
> > +   { { 0,  0}, { 0,  0}, { 0,  0}, {  0,  0}, {  0,   0} },
> > +   { { 1,  0}, { 2,  0}, { 0,  4}, {  0,  4}, {  0,   4} },
> > +   { { 2,  0}, { 4,  0}, { 4,  0}, {  8,  0}, {  0,   8} },
> > +   { { 3,  0}, { 6,  0}, { 4,  4}, {  8,  4}, {  0,  12} },
> > +};
> > +
> > +static const uint8_t gen9_std_y_3d_miptail_offset_el[][5][3] = {
> > +/*128 bpb 64 bpb  32 bpb16 bpb8 bpb  */
> > +   { {8, 0, 0}, {16, 0, 0}, {16,  0, 0}, {16,  0,  0}, {32,  0,  0} },
> > +   { {0, 8, 0}, { 0, 8, 0}, { 0, 16, 0}, { 0, 16,  0}, { 0, 16,  0} },
> > +   { {0, 0, 8}, { 0, 0, 8}, { 0,  0, 8}, { 0,  0, 16}, { 0,  0, 16} },
> > +   { {4, 0, 0}, { 8, 0, 0}, { 8,  0, 0}, { 8,  0,  0}, {16,  0,  0} },
> > +   { {0, 4, 0}, { 0, 4, 0}, { 0,  8, 0}, { 0,  8,  0}, { 0,  8,  0} },
> > +   { {0, 0, 4}, { 0, 0, 4}, { 0,  0, 4}, { 0,  0,  8}, { 0,  0,  8} },
> > +   { {3, 0, 0}, { 6, 0, 0}, { 4,  4, 0}, { 0,  4,  4}, { 0,  4,  4} },
> > +   { {2, 0, 0}, { 4, 0, 0}, { 0,  4, 0}, { 0,  4,  0}, { 0,  4,  0} },
> > +   { {1, 0, 3}, { 2, 0, 3}, { 4,  0, 3}, { 0,  0,  7}, { 0,  0,  7} },
> > +   { {1, 0, 2}, { 2, 0, 2}, { 4,  0, 2}, { 0,  0,  6}, { 0,  0,  6} },
> > +   { {1, 0, 1}, { 2, 0, 1}, { 4,  0, 1}, { 0,  0,  5}, { 0,  0,  5} },
> > +   { {1, 0, 0}, { 2, 0, 0}, { 4,  0, 0}, { 0,  0,  4}, { 0,  0,  4} },
> > +   { {0, 0, 3}, { 0, 0, 3}, { 0,  0, 3}, { 0,  0,  3}, { 0,  0,  3} },
> > +   { {0, 0, 2}, { 0, 0, 2}, { 0,  0, 2}, { 0,  0,  2}, { 0,  0,  2} },
> > +   { {0, 0, 1}, { 0, 0, 1}, { 0,  0, 1}, { 0,  0,  1}, { 0,  0,  1} },
> > +   { {0, 0, 0}, { 0, 0, 0}, { 0,  0, 0}, { 0,  0,  0}, { 0,  0,  0} },
> > +};
> > +
> > +static const uint8_t gen10_std_y_3d_miptail_offset_el[][5][3] = {
> > +/*128 bpb 64 bpb  32 bpb16 bpb8 bpb  */
> > +   { {8, 0, 0}, {16, 0, 0}, {16,  0, 0}, {16,  0,  0}, {32,  0,  0} },
> > +   { {0, 8, 0}, { 0, 8, 0}, { 0, 16, 0}, { 0, 16,  0}, { 0, 16,  0} },
> > +   { {0, 0, 8}, { 0, 0, 8}, { 0,  0, 8}, { 0,  0, 16}, { 0,  0, 

Re: [Mesa-dev] [PATCH 16/28] Replace IROUND_POS with _mesa_roundevenf

[Roland Scheidegger]

Although I'm not sure we actually really wanted that rounding behavior in the 
first place - it's possible the only reason it was used is just because it had 
an easy implementation...


From: Matt Turner 
Sent: Friday, November 16, 2018 8:02:00 PM
To: Dylan Baker
Cc: Roland Scheidegger; ML mesa-dev; erik.faye-l...@collabora.com
Subject: Re: [Mesa-dev] [PATCH 16/28] Replace IROUND_POS with _mesa_roundevenf

On Fri, Nov 16, 2018 at 10:34 AM Dylan Baker  wrote:
>
> Quoting Roland Scheidegger (2018-11-13 18:41:00)
> > Am 14.11.18 um 03:21 schrieb Matt Turner:
> > > On Tue, Nov 13, 2018 at 6:03 PM Roland Scheidegger  
> > > wrote:
> > >>
> > >> Am 13.11.18 um 23:49 schrieb Dylan Baker:
> > >>> Quoting Roland Scheidegger (2018-11-13 14:13:00)
> >  Am 13.11.18 um 18:00 schrieb Dylan Baker:
> > > Quoting Erik Faye-Lund (2018-11-13 01:34:53)
> > >> On Mon, 2018-11-12 at 09:22 -0800, Dylan Baker wrote:
> > >>> Quoting Erik Faye-Lund (2018-11-12 04:51:47)
> >  On Fri, 2018-11-09 at 10:40 -0800, Dylan Baker wrote:
> > > Which has the same behavior.
> > 
> >  Does it? I'm not so sure... IROUND_POS seems to round to nearest
> >  integer depending on the FPU rounding mode, _mesa_roundevenf rounds
> >  to
> >  the nearest *even* value regardless of the FPU rounding mode, no?
> > 
> >  I'm not sure if it matters or not, but *at least* point that out in
> >  the
> >  commit message. Unless I'm missing something, of course...
> > >>>
> > >>> I should put it in the commit message, but there is a comment in
> > >>> rounding.h that
> > >>> if you change the rounding mode you get to keep the pieces.
> > >>
> > >> Well, this might regress performance pretty badly. Especially in the
> > >> swrast code, this could be bad...
> > >>
> > >
> > > Why? we have the assumption that you don't change the rounding mode 
> > > already in
> > > core mesa and many of the drivers.
> > >
> > > For performance, I measured a simple 1000 loops of rounding, and 
> > > found that the
> > > only way the rounding.h function was slower is if you used the 
> > > __SSE4_1__
> > > path... (It was the same performance as the int cast +0.5 
> > > implementation)
> >  FWIW I'm not entirely sure it's useful to have a sse41 implementation -
> >  since all sse2 capable cpus can natively do rintf. Although maybe it
> >  should be pointed out that the sse41 implementation will use a defined
> >  rounding mode, whereas rintf will use current rounding mode. But I 
> >  don't
> >  think anyone ever cares for the results if a different rounding mode
> >  would be set. Although of course rint and its variant do not actually
> >  guarantee the even part of it (but well if it's a sse41 capable box we
> >  pretty much know it would do just that anyway)... (And technically
> >  nearbyintf would probably be an even better solution, since we never
> >  want to get involved with the clunky exceptions, otherwise it's
> >  identical. But there might be reasons why it isn't used.)
> > 
> >  Roland
> > >>>
> > >>> I'm not convinced we want it either, since it seems to be slower than 
> > >>> glibc's
> > >>> rintf. I guess it probably does make sense to use the nearbyintf 
> > >>> instead.
> > >>>
> > >>> As an aside (since I know 0 about assembly), does 
> > >>> _MM_FROUND_CUR_DIRECTION not
> > >>> check the rounding mode?
> > >> Oh indeed, I didn't check the code too closely (I was just assuming
> > >> _mm_round_ss() was used because it is possible to use round-to-nearest
> > >> regardless the actual rounding mode, but that's not the case).
> > >>
> > >> But actually I misread this code: the point of mesa_roundevenf is to
> > >> round to float WITHOUT conversion to int. In which case it makes more
> > >> sense at least at first look...
> > >>
> > >> But if you want to round to nearest integer WITH conversion to int, you
> > >> probably really want to use something else. nearbyint family doesn't
> > >> have variants which give you ints. There's rint functions which give you
> > >> ints directly, but they are likely a very bad idea (aside from exception
> > >
> > > Why?
> > Not sure what the why refers to here?
> >
> >
> > >
> > >> handling, not quite sure if this really causes the compiler to do
> > >> something different) because of giving you long (or long long) results -
> > >> meaning that you can't use the simple cpu instructions giving you 32bit
> > >> results (because conversion to 64bit long + trunc to 32bit will give you
> > >> defined (although meaningless) results in some cases where direct
> > >> conversion to 32bit int wouldn't).
> > >> So ideally you'd pick a variant where the compiler is smart enough to
> > >> recognize it can be done with a single instruction. I would guess
> > >> nearbyintf +

Re: [Mesa-dev] [PATCH 2/3] nir: move getting deref from var after we check deref type.

[Jason Ekstrand]

Patches 1 and 2 are

Reviewed-by: Jason Ekstrand 

As I commented on IRC, I'd recommend we also review and land my emit
pointers on-the-fly patch.  I don't know that it's strictly necessary but I
do think it's better.

On Sun, Nov 18, 2018 at 9:57 PM Dave Airlie  wrote:

> From: Dave Airlie 
>
> I posted a load of hacks before to do this, Jason suggested this,
> just check the deref mode, not the variable mode and delay getting
> the variable until we know the type.
>
> avoids crashes when derefing shared memory pointers.
> ---
>  src/compiler/nir/nir_gather_info.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/src/compiler/nir/nir_gather_info.c
> b/src/compiler/nir/nir_gather_info.c
> index 15d38f036b5..7eaa4c27c1f 100644
> --- a/src/compiler/nir/nir_gather_info.c
> +++ b/src/compiler/nir/nir_gather_info.c
> @@ -210,10 +210,9 @@ gather_intrinsic_info(nir_intrinsic_instr *instr,
> nir_shader *shader,
> case nir_intrinsic_load_deref:
> case nir_intrinsic_store_deref:{
>nir_deref_instr *deref = nir_src_as_deref(instr->src[0]);
> -  nir_variable *var = nir_deref_instr_get_variable(deref);
> -
> -  if (var->data.mode == nir_var_shader_in ||
> -  var->data.mode == nir_var_shader_out) {
> +  if (deref->mode == nir_var_shader_in ||
> +  deref->mode == nir_var_shader_out) {
> + nir_variable *var = nir_deref_instr_get_variable(deref);
>   bool is_output_read = false;
>   if (var->data.mode == nir_var_shader_out &&
>   instr->intrinsic == nir_intrinsic_load_deref)
> --
> 2.17.2
>
> ___
> 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 3/3] nir: handle shared pointers in lowering indirect derefs.

[Jason Ekstrand]

On Sun, Nov 18, 2018 at 9:57 PM Dave Airlie  wrote:

> From: Dave Airlie 
>
> Check if the base ends up with no variable, and continue
> if we see that case outside the loop.
> ---
>  src/compiler/nir/nir_lower_indirect_derefs.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/src/compiler/nir/nir_lower_indirect_derefs.c
> b/src/compiler/nir/nir_lower_indirect_derefs.c
> index 897a0620872..3d6452ac847 100644
> --- a/src/compiler/nir/nir_lower_indirect_derefs.c
> +++ b/src/compiler/nir/nir_lower_indirect_derefs.c
> @@ -141,8 +141,12 @@ lower_indirect_derefs_block(nir_block *block,
> nir_builder *b,
>  has_indirect = true;
>
>   base = nir_deref_instr_parent(base);
> + if (base == NULL)
> +break;
>}
>
> +  if (base == NULL)
> + continue;
>if (!has_indirect)
>

My version of this patch did "while (base &&" and "if (!base ||
!has_indirect)" which makes the code a bit smaller.  Doesn't matter much.
Either way,

Reviewed-by: Jason Ekstrand 


>   continue;
>
> --
> 2.17.2
>
> ___
> 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/2] radv: remove dependency on addrlib gfx9_enum.h

[Samuel Pitoiset]

On 11/19/18 7:37 PM, Dave Airlie wrote:

On Tue, 20 Nov 2018 at 04:30, Nicolai Hähnle  wrote:


From: Nicolai Hähnle 

---
  src/amd/common/sid.h | 3 +++
  src/amd/vulkan/radv_cmd_buffer.c | 6 ++
  src/amd/vulkan/radv_device.c | 9 -
  3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/src/amd/common/sid.h b/src/amd/common/sid.h
index 35782046dd5..49683f1aa5a 100644
--- a/src/amd/common/sid.h
+++ b/src/amd/common/sid.h
@@ -2429,20 +2429,23 @@
  #define   C_008F30_ANISO_BIAS 
0xF81F
  #define   S_008F30_TRUNC_COORD(x) (((unsigned)(x) 
& 0x1) << 27)
  #define   G_008F30_TRUNC_COORD(x) (((x) >> 
27) & 0x1)
  #define   C_008F30_TRUNC_COORD
0xF7FF
  #define   S_008F30_DISABLE_CUBE_WRAP(x)   (((unsigned)(x) 
& 0x1) << 28)
  #define   G_008F30_DISABLE_CUBE_WRAP(x)   (((x) >> 
28) & 0x1)
  #define   C_008F30_DISABLE_CUBE_WRAP  
0xEFFF
  #define   S_008F30_FILTER_MODE(x) (((unsigned)(x) 
& 0x03) << 29)
  #define   G_008F30_FILTER_MODE(x) (((x) >> 
29) & 0x03)
  #define   C_008F30_FILTER_MODE
0x9FFF
+#define V_008F30_SQ_IMG_FILTER_MODE_BLEND   0x00
+#define V_008F30_SQ_IMG_FILTER_MODE_MIN 0x01
+#define V_008F30_SQ_IMG_FILTER_MODE_MAX 0x02
  /* VI */
  #define   S_008F30_COMPAT_MODE(x) (((unsigned)(x) 
& 0x1) << 31)
  #define   G_008F30_COMPAT_MODE(x) (((x) >> 
31) & 0x1)
  #define   C_008F30_COMPAT_MODE
0x7FFF
  /**/
  #define R_008F34_SQ_IMG_SAMP_WORD1  
0x008F34
  #define   S_008F34_MIN_LOD(x) (((unsigned)(x) 
& 0xFFF) << 0)
  #define   G_008F34_MIN_LOD(x) (((x) >> 0) 
& 0xFFF)
  #define   C_008F34_MIN_LOD
0xF000
  #define   S_008F34_MAX_LOD(x) (((unsigned)(x) 
& 0xFFF) << 12)
diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 8e0ed284d65..6424c3a8d9e 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -30,22 +30,20 @@
  #include "radv_shader.h"
  #include "radv_cs.h"
  #include "sid.h"
  #include "gfx9d.h"
  #include "vk_format.h"
  #include "radv_debug.h"
  #include "radv_meta.h"

  #include "ac_debug.h"

-#include "addrlib/gfx9/chip/gfx9_enum.h"
-
  enum {
 RADV_PREFETCH_VBO_DESCRIPTORS   = (1 << 0),
 RADV_PREFETCH_VS= (1 << 1),
 RADV_PREFETCH_TCS   = (1 << 2),
 RADV_PREFETCH_TES   = (1 << 3),
 RADV_PREFETCH_GS= (1 << 4),
 RADV_PREFETCH_PS= (1 << 5),
 RADV_PREFETCH_SHADERS   = (RADV_PREFETCH_VS  |
RADV_PREFETCH_TCS |
RADV_PREFETCH_TES |
@@ -1314,21 +1312,21 @@ radv_load_ds_clear_metadata(struct radv_cmd_buffer 
*cmd_buffer,
 }
 if (aspects & VK_IMAGE_ASPECT_DEPTH_BIT)
 ++reg_count;

 uint32_t reg = R_028028_DB_STENCIL_CLEAR + 4 * reg_offset;

 if (cmd_buffer->device->physical_device->rad_info.chip_class >= VI) {
 radeon_emit(cs, PKT3(PKT3_LOAD_CONTEXT_REG, 3, 0));
 radeon_emit(cs, va);
 radeon_emit(cs, va >> 32);
-   radeon_emit(cs, (reg >> 2) - CONTEXT_SPACE_START);
+   radeon_emit(cs, (reg >> 2) - 0xa000);


(SI_REG_CONTEXT_OFFSET >> 2) ??

At least tie it to a value we know has meaning.



Agreed.


Otherwise
Reviewed-by: Dave Airlie 
___
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 30/30] mesa/st: require linear interpolation for ARB_texture_float

[Roland Scheidegger]

FWIW this looks like a rather similar incident to me what happened when mesa 
began to verify the max vertex stride (which needs to be 2048 with GL 4.4 
whereas r600 can only do 2047) where I argued it's a much better idea to lie 
about the GL version there rather than the specific vertex stride bit, but I 
was rather unsuccessful and not everybody apparently shares this view...


From: mesa-dev  on behalf of Ilia 
Mirkin 
Sent: Monday, November 19, 2018 5:37:58 PM
To: Erik Faye-Lund
Cc: ML Mesa-dev; Timothy Arceri; Emil Velikov
Subject: Re: [Mesa-dev] [PATCH 30/30] mesa/st: require linear interpolation for 
ARB_texture_float

On Mon, Nov 19, 2018 at 11:30 AM Erik Faye-Lund
 wrote:
>
> On Mon, 2018-11-19 at 11:13 -0500, Ilia Mirkin wrote:
> > On Mon, Nov 19, 2018 at 10:40 AM Erik Faye-Lund
> >  wrote:
> > > On Mon, 2018-11-19 at 10:02 -0500, Ilia Mirkin wrote:
> > > > Unfortunately this will drop GL 3.0 from Adreno A3xx. I think
> > > > we'd
> > > > rather fake linear interpolation with F32 textures which are
> > > > never
> > > > used than lose GL 3.0 there...
> > >
> > > Right...
> > >
> > > I guess this means that this GPU never really did support OpenGL
> > > 3.0,
> > > and will make some applications misbehave. There's definately
> > > applications out there that will lead to surprisingly bad problems
> > > when
> > > features like these are not supported.
> > >
> > > For instance if an application tries to take a local gradient by
> > > sampling a texture twice with a tiny epsilon (a common trick in
> > > tangent-free normal mapping, for instance), it will essentially get
> > > garbage, which can cause close to useless rendering.
> > >
> > > I've worked on applications that would have had problems like these
> > > if
> > > drivers report the wrong version, but could work correctly if they
> > > report the right version.
> > >
> > > Either way, I don't believe faking like that belongs in core Mesa.
> > > So
> > > if the Freedreno developers really want this kind of behavior,
> > > perhaps
> > > something like this could be a better move?
> > >
> > > ---8<---
> > > diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c
> > > b/src/gallium/drivers/freedreno/freedreno_screen.c
> > > index 88d91a91234..de811371f05 100644
> > > --- a/src/gallium/drivers/freedreno/freedreno_screen.c
> > > +++ b/src/gallium/drivers/freedreno/freedreno_screen.c
> > > @@ -260,6 +260,11 @@ fd_screen_get_param(struct pipe_screen
> > > *pscreen,
> > > enum pipe_cap param)
> > > return 0;
> > >
> > > case PIPE_CAP_TEXTURE_FLOAT_LINEAR:
> > > +   /* HACK: A330 doesn't support linear interpolation
> > > of
> > > FP32 textures, but
> > > +* to keep OpenGL 3.0 support, we lie about it
> > > here.
> > > +*/
> > > +   return is_a3xx(screen) || is_a4xx(screen) ||
> > > is_a5xx(screen) || is_a6xx(screen);
> > > +
> > > case PIPE_CAP_CUBE_MAP_ARRAY:
> > > case PIPE_CAP_SAMPLER_VIEW_TARGET:
> > > case PIPE_CAP_TEXTURE_QUERY_LOD:
> > > ---8<---
> > >
> > > Alternatively, they could ask users to override the GL-version for
> > > applications that need GL 3.0, but doesn't have problems with the
> > > lack
> > > of FP32-interpolation...
> >
> > GL 3.0 brings SO much stuff in though, and GL 3.1 brings core
> > profiles.
> >
> > Your proposed solution will also expose the OES_bla ext, which we
> > definitely don't want to do. I'd instead keep it loose. The hardware
> > that doesn't support this stuff is generally targeted at ES. However
> > it's convenient to have desktop GL both for test coverage (piglit) as
> > well as regular use.
> >
> > Tons of desktop stuff doesn't work in Adreno. Starting with different
> > cull modes for front and back. Setting polygon mode for quads to
> > lines
> > shows you the internal line. Edge mode isn't supported. Probably
> > 1
> > other things.
> >
> > But it's still very useful to have GL 3.x advertised.
>
> As I tried to point out, that's only useful from one point of view.
> From an application developer's point of view, it's *worse* to expose
> GL 3.0 when it's not really supported. There's no way for applications
> to tell if filtering will work or not. When the correct version is
> reported, the application can provide a fallback path for the features
> it need, or fall back to lower quality rendering.
>
> When you're outside the spec, you kinda have to pick your poison. But I
> don't think a single driver wanting to fake the support should affect
> all other drivers regardless.

You're looking at this as some hypothetical driver which supports a
random smattering of extension enables, and trying to make mesa
resilient against such an adversarial opponent.

But that's not what's going on here. Features come in packs. I think
that a3xx on adreno is the only hardware affected by this change in
practice.

>
> And with the other legacy GL features that Adren

Re: [Mesa-dev] [PATCH v2 29/32] intel/isl: Disallow CCS on 3D surfaces with miptails

[Pohjolainen, Topi]

On Fri, Oct 12, 2018 at 01:46:59PM -0500, Jason Ekstrand wrote:
> ---
>  src/intel/isl/isl.c | 19 +++
>  1 file changed, 19 insertions(+)

Reviewed-by: Topi Pohjolainen 

> 
> diff --git a/src/intel/isl/isl.c b/src/intel/isl/isl.c
> index df4fb94a6fe..2513d2e73d1 100644
> --- a/src/intel/isl/isl.c
> +++ b/src/intel/isl/isl.c
> @@ -2006,6 +2006,25 @@ isl_surf_get_ccs_surf(const struct isl_device *dev,
> if (isl_format_is_compressed(surf->format))
>return false;
>  
> +   /* From the workarounds section in the SKL PRM:
> +*
> +*"RCC cacheline is composed of X-adjacent 64B fragments instead of
> +*memory adjacent. This causes a single 128B cacheline to straddle
> +*multiple LODs inside the TYF MIPtail for 3D surfaces (beyond a
> +*certain slot number), leading to corruption when CCS is enabled for
> +*these LODs and RT is later bound as texture.  WA: If
> +*RENDER_SURFACE_STATE.Surface Type = 3D and
> +*RENDER_SURFACE_STATE.Auxiliary Surface Mode != AUX_NONE and
> +*RENDER_SURFACE_STATE.Tiled ResourceMode is TYF or TYS, Set the value
> +*of RENDER_SURFACE_STATE.Mip Tail Start LOD to a mip that larger than
> +*those present in the surface (i.e. 15)"
> +*
> +* We simply disallow CCS on 3D surfaces with miptails.
> +*/
> +   if (surf->dim == ISL_SURF_DIM_3D &&
> +   surf->miptail_start_level < surf->levels)
> +  return false;
> +
> /* TODO: More conditions where it can fail. */
>  
> enum isl_format ccs_format;
> -- 
> 2.19.1
> 
> ___
> 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] Lets talk about autotools

[Dylan Baker]

Sorry, cell phones are really bad for responding to email...

The file has the same rules as cross files, it can be a local file, passed as an
absolute path, or read from $XDG directories (local files will be read before
XDG ones).

Dylan

Quoting Dylan Baker (2018-11-18 09:01:27)
> That file can live anywhere and can be referenced by absolute path.
> 
> On November 17, 2018 9:15:20 AM PST, "Kai Wasserbäch"
>  wrote:
> 
> Hey Dylan,
> Dylan Baker wrote on 17.11.18 05:04:
> Quoting Dylan Baker (2018-09-17 09:44:07)
>  I feel like for !windows meson is in good enough shape at this 
> point that we
>  can start having the discussion about deleting the autotools 
> build. So, is there
>  anything left that autotools can do that meson cannot (that we 
> actually want to
>  implement)? And, what is a reasonable time-table to remove the 
> autotools build?
>  I think we could reasonably remove it as soon as 18.3 if others 
> felt confident
>  that it would work for them.
> 
>  Dylan
> 
> Okay, time for an update on things and a chance to talk about what 
> else we need.
> 
> Support for llvm-config (and any binary, actually) overriding has 
> landed in
> meson, and will be present in the 0.49.0 release, which is due out 
> December 9th.
> support for ICC has improved a great deal already, and I have a 
> series here:
> https://github.com/mesonbuild/meson/pull/4359 (which may 
> unfortunately not
> land until after 0.49) which should get ICC into pretty good shape on 
> Linux and
> Mac, including actually checking that arguments are understood (which 
> should
> allow us to drop the prefix test from SWR). I have some ideas on how 
> we might
> remove auto options, some of them can already use meson's "feature"
> https://mesonbuild.com/Build-options.html#features option (which 
> should make
> distro packagers happy too), for arch and OS specific options I have 
> some ideas
> and I'll continue following up with those upstream.
> 
> For those interested in llvm-config overriding, with meson out of git 
> you can
> add a files like:
> 
> $ cat ~/.local/share/meson/native/llvm-6.0
> [binaries]
> llvm-conifg = '/usr/local/lib/llvm-6/bin/llvm-config'
> 
> and invoke meson with:
> meson builddir --native-file llvm-6.0
> 
> which will configure with the specified llvm-config, and remember the
> llvm-config used on subsequent reconfigurations. You can override all 
> binaries
> from a native file as well, so if you want to use a specific python3 
> or
> compiler you can do that, and you can load multiple native files in a 
> single
> invocation.
> 
> do I understand that correctly as "there is no way to set this on the 
> command
> line"? Ie. something like
>   meson 
> --override-native="llvm-config=/usr/local/lib/llvm-6/bin/llvm-config"
> or something similar? I need to have a file in 
> $XDG_DATA_HOME/meson/native? That
> would be really ugly for (automatic) package build environments IMHO, 
> especially
> if you want to have reproducible builds. Could these files at least be 
> put in
> eg. the debian directory of a source package and then I could pass some 
> option
> to meson to look there for these overrides?
> 
> Cheers,
> Kai
> 
> 


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

Re: [Mesa-dev] [PATCH v2 28/32] intel/isl: Support miptails in isl_surf_get_uncompressed_surf

[Pohjolainen, Topi]

On Fri, Oct 12, 2018 at 01:46:58PM -0500, Jason Ekstrand wrote:
> ---
>  src/intel/isl/isl.c | 45 +++--
>  1 file changed, 35 insertions(+), 10 deletions(-)

Reviewed-by: Topi Pohjolainen 

> 
> diff --git a/src/intel/isl/isl.c b/src/intel/isl/isl.c
> index 88de1407375..df4fb94a6fe 100644
> --- a/src/intel/isl/isl.c
> +++ b/src/intel/isl/isl.c
> @@ -2657,11 +2657,22 @@ isl_surf_get_uncompressed_surf(const struct 
> isl_device *dev,
> const uint32_t view_height_el = isl_align_div_npot(view_height_px, 
> fmtl->bh);
>  
> if (isl_tiling_is_std_y(surf->tiling)) {
> -  /* Offset to the given miplevel.  Because we're using standard tilings
> -   * with no miptail, arrays and 3D textures should just work so long as
> -   * we have the right array stride in the end.
> +  /* If the requested level is not part of the miptail, we just ofset to
> +   * the requested level.  Because we're using standard tilings and 
> aren't
> +   * in the miptail, arrays and 3D textures should just work so long as 
> we
> +   * have the right array stride in the end.
> +   *
> +   * If the requested level is in the miptail, we instead offset to the
> +   * base of the miptail.  Because offsets into the miptail are fixed by
> +   * the tiling and don't depend on the actual size of the image, we can
> +   * set the level in the view to offset into the miptail regardless of
> +   * the fact minification yields different results for the compressed 
> and
> +   * uncompressed surface.
> */
> -  isl_surf_get_image_offset_B_tile_el(surf, view->base_level, 0, 0,
> +  const uint32_t base_level =
> + MIN(view->base_level, surf->miptail_start_level);
> +
> +  isl_surf_get_image_offset_B_tile_el(surf, base_level, 0, 0,
>offset_B, x_offset_el, 
> y_offset_el);
>/* Ys and Yf should have no intratile X or Y offset */
>assert(*x_offset_el == 0 && *y_offset_el == 0);
> @@ -2674,16 +2685,31 @@ isl_surf_get_uncompressed_surf(const struct 
> isl_device *dev,
>const uint32_t view_depth_el =
>   isl_align_div_npot(view_depth_px, fmtl->bd);
>  
> +  /* We need to compute the size of the uncompressed surface we will
> +   * create.  If we're not in the miptail, it is just the view size in
> +   * surface elements.  If we are in a miptail, we need a size that will
> +   * minify to the view size in surface elements.  This may not be the
> +   * same as the size of base_level.
> +   */
> +  const uint32_t ucompr_level = view->base_level - base_level;
> +  struct isl_extent3d ucompr_surf_extent_el = {
> + .w = (view_width_el > 1) ? view_width_el << ucompr_level : 1,
> + .h = (view_height_el > 1) ? view_height_el << ucompr_level : 1,
> + .d = (view_depth_el > 1) ? view_depth_el << ucompr_level : 1,
> +  };
> +
>bool ok UNUSED;
>ok = isl_surf_init(dev, ucompr_surf,
>   .dim = surf->dim,
>   .format = view->format,
> - .width = view_width_el,
> - .height = view_height_el,
> - .depth = view_depth_el,
> - .levels = 1,
> + .width = ucompr_surf_extent_el.width,
> + .height = ucompr_surf_extent_el.height,
> + .depth = ucompr_surf_extent_el.depth,
> + .levels = view->base_level - base_level + 1,
>   .array_len = surf->logical_level0_px.array_len,
>   .samples = surf->samples,
> + .min_miptail_start_level =
> + surf->miptail_start_level - base_level,
>   .row_pitch_B = surf->row_pitch_B,
>   .usage = surf->usage,
>   .tiling_flags = (1u << surf->tiling));
> @@ -2692,7 +2718,6 @@ isl_surf_get_uncompressed_surf(const struct isl_device 
> *dev,
>/* Use the array pitch from the original surface.  This way 2D arrays
> * and 3D textures should work properly, just with one LOD.
> */
> -  assert(ucompr_surf->array_pitch_el_rows <= array_pitch_el_rows);
>ucompr_surf->array_pitch_el_rows = array_pitch_el_rows;
>  
>/* The newly created image represents only the one miplevel so we
> @@ -2701,7 +2726,7 @@ isl_surf_get_uncompressed_surf(const struct isl_device 
> *dev,
> * left alone.
> */
>*ucompr_view = *view;
> -  ucompr_view->base_level = 0;
> +  ucompr_view->base_level -= base_level;
> } else {
>/* For legacy tilings, we just make a new 2D surface which represents
> * the single slice of the main surface.  Due to hardware restrictions
> -- 
> 2.19.1
> 
> ___

Re: [Mesa-dev] [PATCH 1/2] radv: remove dependency on addrlib gfx9_enum.h

[Dave Airlie]

On Tue, 20 Nov 2018 at 04:30, Nicolai Hähnle  wrote:
>
> From: Nicolai Hähnle 
>
> ---
>  src/amd/common/sid.h | 3 +++
>  src/amd/vulkan/radv_cmd_buffer.c | 6 ++
>  src/amd/vulkan/radv_device.c | 9 -
>  3 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/src/amd/common/sid.h b/src/amd/common/sid.h
> index 35782046dd5..49683f1aa5a 100644
> --- a/src/amd/common/sid.h
> +++ b/src/amd/common/sid.h
> @@ -2429,20 +2429,23 @@
>  #define   C_008F30_ANISO_BIAS 
> 0xF81F
>  #define   S_008F30_TRUNC_COORD(x) 
> (((unsigned)(x) & 0x1) << 27)
>  #define   G_008F30_TRUNC_COORD(x) (((x) 
> >> 27) & 0x1)
>  #define   C_008F30_TRUNC_COORD
> 0xF7FF
>  #define   S_008F30_DISABLE_CUBE_WRAP(x)   
> (((unsigned)(x) & 0x1) << 28)
>  #define   G_008F30_DISABLE_CUBE_WRAP(x)   (((x) 
> >> 28) & 0x1)
>  #define   C_008F30_DISABLE_CUBE_WRAP  
> 0xEFFF
>  #define   S_008F30_FILTER_MODE(x) 
> (((unsigned)(x) & 0x03) << 29)
>  #define   G_008F30_FILTER_MODE(x) (((x) 
> >> 29) & 0x03)
>  #define   C_008F30_FILTER_MODE
> 0x9FFF
> +#define V_008F30_SQ_IMG_FILTER_MODE_BLEND   0x00
> +#define V_008F30_SQ_IMG_FILTER_MODE_MIN 0x01
> +#define V_008F30_SQ_IMG_FILTER_MODE_MAX 0x02
>  /* VI */
>  #define   S_008F30_COMPAT_MODE(x) 
> (((unsigned)(x) & 0x1) << 31)
>  #define   G_008F30_COMPAT_MODE(x) (((x) 
> >> 31) & 0x1)
>  #define   C_008F30_COMPAT_MODE
> 0x7FFF
>  /**/
>  #define R_008F34_SQ_IMG_SAMP_WORD1  
> 0x008F34
>  #define   S_008F34_MIN_LOD(x) 
> (((unsigned)(x) & 0xFFF) << 0)
>  #define   G_008F34_MIN_LOD(x) (((x) 
> >> 0) & 0xFFF)
>  #define   C_008F34_MIN_LOD
> 0xF000
>  #define   S_008F34_MAX_LOD(x) 
> (((unsigned)(x) & 0xFFF) << 12)
> diff --git a/src/amd/vulkan/radv_cmd_buffer.c 
> b/src/amd/vulkan/radv_cmd_buffer.c
> index 8e0ed284d65..6424c3a8d9e 100644
> --- a/src/amd/vulkan/radv_cmd_buffer.c
> +++ b/src/amd/vulkan/radv_cmd_buffer.c
> @@ -30,22 +30,20 @@
>  #include "radv_shader.h"
>  #include "radv_cs.h"
>  #include "sid.h"
>  #include "gfx9d.h"
>  #include "vk_format.h"
>  #include "radv_debug.h"
>  #include "radv_meta.h"
>
>  #include "ac_debug.h"
>
> -#include "addrlib/gfx9/chip/gfx9_enum.h"
> -
>  enum {
> RADV_PREFETCH_VBO_DESCRIPTORS   = (1 << 0),
> RADV_PREFETCH_VS= (1 << 1),
> RADV_PREFETCH_TCS   = (1 << 2),
> RADV_PREFETCH_TES   = (1 << 3),
> RADV_PREFETCH_GS= (1 << 4),
> RADV_PREFETCH_PS= (1 << 5),
> RADV_PREFETCH_SHADERS   = (RADV_PREFETCH_VS  |
>RADV_PREFETCH_TCS |
>RADV_PREFETCH_TES |
> @@ -1314,21 +1312,21 @@ radv_load_ds_clear_metadata(struct radv_cmd_buffer 
> *cmd_buffer,
> }
> if (aspects & VK_IMAGE_ASPECT_DEPTH_BIT)
> ++reg_count;
>
> uint32_t reg = R_028028_DB_STENCIL_CLEAR + 4 * reg_offset;
>
> if (cmd_buffer->device->physical_device->rad_info.chip_class >= VI) {
> radeon_emit(cs, PKT3(PKT3_LOAD_CONTEXT_REG, 3, 0));
> radeon_emit(cs, va);
> radeon_emit(cs, va >> 32);
> -   radeon_emit(cs, (reg >> 2) - CONTEXT_SPACE_START);
> +   radeon_emit(cs, (reg >> 2) - 0xa000);

(SI_REG_CONTEXT_OFFSET >> 2) ??

At least tie it to a value we know has meaning.

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

Re: [Mesa-dev] [PATCH v2 27/32] intel/isl: Add units to view dimensions in isl_surf_get_uncompressed_surf

[Pohjolainen, Topi]

On Fri, Oct 12, 2018 at 01:46:57PM -0500, Jason Ekstrand wrote:
> ---
>  src/intel/isl/isl.c | 27 ++-
>  1 file changed, 14 insertions(+), 13 deletions(-)

Reviewed-by: Topi Pohjolainen 

> 
> diff --git a/src/intel/isl/isl.c b/src/intel/isl/isl.c
> index c86390bf851..88de1407375 100644
> --- a/src/intel/isl/isl.c
> +++ b/src/intel/isl/isl.c
> @@ -2648,13 +2648,13 @@ isl_surf_get_uncompressed_surf(const struct 
> isl_device *dev,
> assert(isl_format_get_layout(view->format)->bpb == fmtl->bpb);
> assert(view->levels == 1);
>  
> -   const uint32_t view_width =
> +   const uint32_t view_width_px =
>isl_minify(surf->logical_level0_px.width, view->base_level);
> -   const uint32_t view_height =
> +   const uint32_t view_height_px =
>isl_minify(surf->logical_level0_px.height, view->base_level);
>  
> -   const uint32_t ucompr_width = isl_align_div_npot(view_width, fmtl->bw);
> -   const uint32_t ucompr_height = isl_align_div_npot(view_height, fmtl->bh);
> +   const uint32_t view_width_el = isl_align_div_npot(view_width_px, 
> fmtl->bw);
> +   const uint32_t view_height_el = isl_align_div_npot(view_height_px, 
> fmtl->bh);
>  
> if (isl_tiling_is_std_y(surf->tiling)) {
>/* Offset to the given miplevel.  Because we're using standard tilings
> @@ -2669,17 +2669,18 @@ isl_surf_get_uncompressed_surf(const struct 
> isl_device *dev,
>/* Save off the array pitch */
>const uint32_t array_pitch_el_rows = surf->array_pitch_el_rows;
>  
> -  const uint32_t view_depth =
> +  const uint32_t view_depth_px =
>   isl_minify(surf->logical_level0_px.depth, view->base_level);
> -  const uint32_t ucompr_depth = isl_align_div_npot(view_depth, fmtl->bd);
> +  const uint32_t view_depth_el =
> + isl_align_div_npot(view_depth_px, fmtl->bd);
>  
>bool ok UNUSED;
>ok = isl_surf_init(dev, ucompr_surf,
>   .dim = surf->dim,
>   .format = view->format,
> - .width = ucompr_width,
> - .height = ucompr_height,
> - .depth = ucompr_depth,
> + .width = view_width_el,
> + .height = view_height_el,
> + .depth = view_depth_el,
>   .levels = 1,
>   .array_len = surf->logical_level0_px.array_len,
>   .samples = surf->samples,
> @@ -2723,12 +2724,12 @@ isl_surf_get_uncompressed_surf(const struct 
> isl_device *dev,
>/* We're making an uncompressed view here.  The image dimensions
> * need to be scaled down by the block size.
> */
> -  assert(ucompr_surf->logical_level0_px.width == view_width);
> -  assert(ucompr_surf->logical_level0_px.height == view_height);
> +  assert(ucompr_surf->logical_level0_px.width == view_width_px);
> +  assert(ucompr_surf->logical_level0_px.height == view_height_px);
>assert(ucompr_surf->logical_level0_px.depth == 1);
>assert(ucompr_surf->logical_level0_px.array_len = 1);
> -  ucompr_surf->logical_level0_px.width = ucompr_width;
> -  ucompr_surf->logical_level0_px.height = ucompr_height;
> +  ucompr_surf->logical_level0_px.width = view_width_el;
> +  ucompr_surf->logical_level0_px.height = view_height_el;
>  
>assert(ucompr_surf->phys_level0_sa.width % fmtl->bw == 0);
>assert(ucompr_surf->phys_level0_sa.height % fmtl->bh == 0);
> -- 
> 2.19.1
> 
> ___
> 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] nir/derefs: Add a nir_derefs_do_not_alias enum value

[Jason Ekstrand]

This makes some of the code more clear.
---
 src/compiler/nir/nir_deref.c | 8 
 src/compiler/nir/nir_deref.h | 1 +
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/src/compiler/nir/nir_deref.c b/src/compiler/nir/nir_deref.c
index 59b36a7f255..68a3aad5c70 100644
--- a/src/compiler/nir/nir_deref.c
+++ b/src/compiler/nir/nir_deref.c
@@ -289,7 +289,7 @@ nir_compare_deref_paths(nir_deref_path *a_path,
 nir_deref_path *b_path)
 {
if (!modes_may_alias(b_path->path[0]->mode, a_path->path[0]->mode))
-  return 0;
+  return nir_derefs_do_not_alias;
 
if (a_path->path[0]->deref_type != b_path->path[0]->deref_type)
   return nir_derefs_may_alias_bit;
@@ -299,7 +299,7 @@ nir_compare_deref_paths(nir_deref_path *a_path,
* they're not the same variable, we know they can't possibly alias.
*/
   if (a_path->path[0]->var != b_path->path[0]->var)
- return 0;
+ return nir_derefs_do_not_alias;
} else {
   assert(a_path->path[0]->deref_type == nir_deref_type_cast);
   /* If they're not exactly the same cast, we can't compare them so we
@@ -357,7 +357,7 @@ nir_compare_deref_paths(nir_deref_path *a_path,
 */
if (nir_src_as_uint(a_tail->arr.index) !=
nir_src_as_uint(b_tail->arr.index))
-  return 0;
+  return nir_derefs_do_not_alias;
 } else if (a_tail->arr.index.ssa == b_tail->arr.index.ssa) {
/* They're the same indirect, continue on */
 } else {
@@ -373,7 +373,7 @@ nir_compare_deref_paths(nir_deref_path *a_path,
   case nir_deref_type_struct: {
  /* If they're different struct members, they don't even alias */
  if (a_tail->strct.index != b_tail->strct.index)
-return 0;
+return nir_derefs_do_not_alias;
  break;
   }
 
diff --git a/src/compiler/nir/nir_deref.h b/src/compiler/nir/nir_deref.h
index c61c3f9366f..20d40377e6e 100644
--- a/src/compiler/nir/nir_deref.h
+++ b/src/compiler/nir/nir_deref.h
@@ -55,6 +55,7 @@ nir_ssa_def *nir_build_deref_offset(nir_builder *b, 
nir_deref_instr *deref,
 glsl_type_size_align_func size_align);
 
 typedef enum {
+   nir_derefs_do_not_alias = 0,
nir_derefs_equal_bit= (1 << 0),
nir_derefs_may_alias_bit= (1 << 1),
nir_derefs_a_contains_b_bit = (1 << 2),
-- 
2.19.1

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

Re: [Mesa-dev] [PATCH v2 26/32] intel/isl: Add support for computing offsets with miptails

[Pohjolainen, Topi]

On Fri, Oct 12, 2018 at 01:46:56PM -0500, Jason Ekstrand wrote:
> Unfortunately, there is no nice way to calculate miptail offsets in
> closed form.  Instead, we just copy the tables from the PRM directly
> verbatim.
> ---
>  src/intel/isl/isl.c | 217 +++-
>  1 file changed, 213 insertions(+), 4 deletions(-)
> 
> diff --git a/src/intel/isl/isl.c b/src/intel/isl/isl.c
> index 3657b11ee00..c86390bf851 100644
> --- a/src/intel/isl/isl.c
> +++ b/src/intel/isl/isl.c
> @@ -863,6 +863,169 @@ isl_calc_phys_level0_extent_sa(const struct isl_device 
> *dev,
> }
>  }
>  
> +static const uint16_t std_y_1d_miptail_offset_el[] = {
> +/* 128 bpb */
> +   2048,
> +   1024,
> +   512,
> +   256,
> +   128,
> +   64,
> +   48,
> +   32,
> +   28,
> +   24,
> +   20,
> +   16,
> +   12,
> +   8,
> +   4,
> +   0,
> +};
> +
> +static const uint8_t gen9_std_y_2d_miptail_offset_el[][5][2] = {
> +/*   128 bpb64 bpb32 bpb16 bpb  8 bpb */
> +   { {32,  0}, {64,  0}, {64,  0}, {128,  0}, {128,  0} },
> +   { { 0, 32}, { 0, 32}, { 0, 64}, {  0, 64}, {  0,128} },
> +   { {16,  0}, {32,  0}, {32,  0}, { 64,  0}, { 64,  0} },
> +   { { 0, 16}, { 0, 16}, { 0, 32}, {  0, 32}, {  0, 64} },
> +   { { 8,  0}, {16,  0}, {16,  0}, { 32,  0}, { 32,  0} },
> +   { { 4,  8}, { 8,  8}, { 8, 16}, { 16, 16}, { 16, 32} },
> +   { { 0, 12}, { 0, 12}, { 0, 24}, {  0, 24}, {  0, 48} },
> +   { { 0,  8}, { 0,  8}, { 0, 16}, {  0, 16}, {  0, 32} },
> +   { { 4,  4}, { 8,  4}, { 8,  8}, { 16,  8}, { 16, 16} },
> +   { { 4,  0}, { 8,  0}, { 8,  0}, { 16,  0}, { 16,  0} },
> +   { { 0,  4}, { 0,  4}, { 0,  8}, {  0,  8}, {  0, 16} },
> +   { { 3,  0}, { 6,  0}, { 4,  4}, {  8,  4}, {  0, 12} },
> +   { { 2,  0}, { 4,  0}, { 4,  0}, {  8,  0}, {  0,  8} },
> +   { { 1,  0}, { 2,  0}, { 0,  4}, {  0,  4}, {  0,  4} },
> +   { { 0,  0}, { 0,  0}, { 0,  0}, {  0,  0}, {  0,  0} },
> +};
> +
> +static const uint8_t gen10_std_y_2d_miptail_offset_el[][5][2] = {
> +/*   128 bpb64 bpb32 bpb16 bpb  8 bpb */
> +   { {32,  0}, {64,  0}, {64,  0}, {128,  0}, {128,   0} },
> +   { { 0, 32}, { 0, 32}, { 0, 64}, {  0, 64}, {  0, 128} },
> +   { {16,  0}, {32,  0}, {32,  0}, { 64,  0}, { 64,   0} },
> +   { { 0, 16}, { 0, 16}, { 0, 32}, {  0, 32}, {  0,  64} },
> +   { { 8,  0}, {16,  0}, {16,  0}, { 32,  0}, { 32,   0} },
> +   { { 4,  8}, { 8,  8}, { 8, 16}, { 16, 16}, { 16,  32} },
> +   { { 0, 12}, { 0, 12}, { 0, 24}, {  0, 24}, {  0,  48} },
> +   { { 0,  8}, { 0,  8}, { 0, 16}, {  0, 16}, {  0,  32} },
> +   { { 4,  4}, { 8,  4}, { 8,  8}, { 16,  8}, { 16,  16} },
> +   { { 4,  0}, { 8,  0}, { 8,  0}, { 16,  0}, { 16,   0} },
> +   { { 0,  4}, { 0,  4}, { 0,  8}, {  0,  8}, {  0,  16} },
> +   { { 0,  0}, { 0,  0}, { 0,  0}, {  0,  0}, {  0,   0} },
> +   { { 1,  0}, { 2,  0}, { 0,  4}, {  0,  4}, {  0,   4} },
> +   { { 2,  0}, { 4,  0}, { 4,  0}, {  8,  0}, {  0,   8} },
> +   { { 3,  0}, { 6,  0}, { 4,  4}, {  8,  4}, {  0,  12} },
> +};
> +
> +static const uint8_t gen9_std_y_3d_miptail_offset_el[][5][3] = {
> +/*128 bpb 64 bpb  32 bpb16 bpb8 bpb  */
> +   { {8, 0, 0}, {16, 0, 0}, {16,  0, 0}, {16,  0,  0}, {32,  0,  0} },
> +   { {0, 8, 0}, { 0, 8, 0}, { 0, 16, 0}, { 0, 16,  0}, { 0, 16,  0} },
> +   { {0, 0, 8}, { 0, 0, 8}, { 0,  0, 8}, { 0,  0, 16}, { 0,  0, 16} },
> +   { {4, 0, 0}, { 8, 0, 0}, { 8,  0, 0}, { 8,  0,  0}, {16,  0,  0} },
> +   { {0, 4, 0}, { 0, 4, 0}, { 0,  8, 0}, { 0,  8,  0}, { 0,  8,  0} },
> +   { {0, 0, 4}, { 0, 0, 4}, { 0,  0, 4}, { 0,  0,  8}, { 0,  0,  8} },
> +   { {3, 0, 0}, { 6, 0, 0}, { 4,  4, 0}, { 0,  4,  4}, { 0,  4,  4} },
> +   { {2, 0, 0}, { 4, 0, 0}, { 0,  4, 0}, { 0,  4,  0}, { 0,  4,  0} },
> +   { {1, 0, 3}, { 2, 0, 3}, { 4,  0, 3}, { 0,  0,  7}, { 0,  0,  7} },
> +   { {1, 0, 2}, { 2, 0, 2}, { 4,  0, 2}, { 0,  0,  6}, { 0,  0,  6} },
> +   { {1, 0, 1}, { 2, 0, 1}, { 4,  0, 1}, { 0,  0,  5}, { 0,  0,  5} },
> +   { {1, 0, 0}, { 2, 0, 0}, { 4,  0, 0}, { 0,  0,  4}, { 0,  0,  4} },
> +   { {0, 0, 3}, { 0, 0, 3}, { 0,  0, 3}, { 0,  0,  3}, { 0,  0,  3} },
> +   { {0, 0, 2}, { 0, 0, 2}, { 0,  0, 2}, { 0,  0,  2}, { 0,  0,  2} },
> +   { {0, 0, 1}, { 0, 0, 1}, { 0,  0, 1}, { 0,  0,  1}, { 0,  0,  1} },
> +   { {0, 0, 0}, { 0, 0, 0}, { 0,  0, 0}, { 0,  0,  0}, { 0,  0,  0} },
> +};
> +
> +static const uint8_t gen10_std_y_3d_miptail_offset_el[][5][3] = {
> +/*128 bpb 64 bpb  32 bpb16 bpb8 bpb  */
> +   { {8, 0, 0}, {16, 0, 0}, {16,  0, 0}, {16,  0,  0}, {32,  0,  0} },
> +   { {0, 8, 0}, { 0, 8, 0}, { 0, 16, 0}, { 0, 16,  0}, { 0, 16,  0} },
> +   { {0, 0, 8}, { 0, 0, 8}, { 0,  0, 8}, { 0,  0, 16}, { 0,  0, 16} },
> +   { {4, 0, 0}, { 8, 0, 0}, { 8,  0, 0}, { 8,  0,  0}, {16,  0,  0} },
> +   { {0, 4, 0}, { 0, 4, 0}, { 0,  8, 0}, { 0,  8,  0}, { 0,  8,  0} },
> +   { {2, 0, 4}, { 4, 0, 4}, { 4,  0, 4}, { 4,  0,  8}, { 8,  0,  8} },
> +   { {0, 2, 4}, { 0, 2, 4}, { 0,  4, 4}, { 0,  4,  

[Mesa-dev] [PATCH 0/2] amd/addrlib: update Mesa's copy of addrlib

[Nicolai Hähnle]

Hi all,

nothing special here, just updating addrlib from the internal version.

This is bigger than usual because they decided to reorganize the source
a bit. It does make a bit more sense this way.

There's also a whole lot of churn in whitespace because for the first
time I've used the same tooling that is used for AMDVLK. Hopefully
that will make things simpler going forward.

Since the main patch is pretty big, I've also put it here:
https://gitlab.freedesktop.org/nh/mesa/tree/addrlib-update-20181119

Please review!
Thanks,
Nicolai


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

[Mesa-dev] [PATCH 1/2] radv: remove dependency on addrlib gfx9_enum.h

[Nicolai Hähnle]

From: Nicolai Hähnle 

---
 src/amd/common/sid.h | 3 +++
 src/amd/vulkan/radv_cmd_buffer.c | 6 ++
 src/amd/vulkan/radv_device.c | 9 -
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/src/amd/common/sid.h b/src/amd/common/sid.h
index 35782046dd5..49683f1aa5a 100644
--- a/src/amd/common/sid.h
+++ b/src/amd/common/sid.h
@@ -2429,20 +2429,23 @@
 #define   C_008F30_ANISO_BIAS 
0xF81F
 #define   S_008F30_TRUNC_COORD(x) 
(((unsigned)(x) & 0x1) << 27)
 #define   G_008F30_TRUNC_COORD(x) (((x) >> 
27) & 0x1)
 #define   C_008F30_TRUNC_COORD
0xF7FF
 #define   S_008F30_DISABLE_CUBE_WRAP(x)   
(((unsigned)(x) & 0x1) << 28)
 #define   G_008F30_DISABLE_CUBE_WRAP(x)   (((x) >> 
28) & 0x1)
 #define   C_008F30_DISABLE_CUBE_WRAP  
0xEFFF
 #define   S_008F30_FILTER_MODE(x) 
(((unsigned)(x) & 0x03) << 29)
 #define   G_008F30_FILTER_MODE(x) (((x) >> 
29) & 0x03)
 #define   C_008F30_FILTER_MODE
0x9FFF
+#define V_008F30_SQ_IMG_FILTER_MODE_BLEND   0x00
+#define V_008F30_SQ_IMG_FILTER_MODE_MIN 0x01
+#define V_008F30_SQ_IMG_FILTER_MODE_MAX 0x02
 /* VI */
 #define   S_008F30_COMPAT_MODE(x) 
(((unsigned)(x) & 0x1) << 31)
 #define   G_008F30_COMPAT_MODE(x) (((x) >> 
31) & 0x1)
 #define   C_008F30_COMPAT_MODE
0x7FFF
 /**/
 #define R_008F34_SQ_IMG_SAMP_WORD1  
0x008F34
 #define   S_008F34_MIN_LOD(x) 
(((unsigned)(x) & 0xFFF) << 0)
 #define   G_008F34_MIN_LOD(x) (((x) >> 
0) & 0xFFF)
 #define   C_008F34_MIN_LOD
0xF000
 #define   S_008F34_MAX_LOD(x) 
(((unsigned)(x) & 0xFFF) << 12)
diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 8e0ed284d65..6424c3a8d9e 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -30,22 +30,20 @@
 #include "radv_shader.h"
 #include "radv_cs.h"
 #include "sid.h"
 #include "gfx9d.h"
 #include "vk_format.h"
 #include "radv_debug.h"
 #include "radv_meta.h"
 
 #include "ac_debug.h"
 
-#include "addrlib/gfx9/chip/gfx9_enum.h"
-
 enum {
RADV_PREFETCH_VBO_DESCRIPTORS   = (1 << 0),
RADV_PREFETCH_VS= (1 << 1),
RADV_PREFETCH_TCS   = (1 << 2),
RADV_PREFETCH_TES   = (1 << 3),
RADV_PREFETCH_GS= (1 << 4),
RADV_PREFETCH_PS= (1 << 5),
RADV_PREFETCH_SHADERS   = (RADV_PREFETCH_VS  |
   RADV_PREFETCH_TCS |
   RADV_PREFETCH_TES |
@@ -1314,21 +1312,21 @@ radv_load_ds_clear_metadata(struct radv_cmd_buffer 
*cmd_buffer,
}
if (aspects & VK_IMAGE_ASPECT_DEPTH_BIT)
++reg_count;
 
uint32_t reg = R_028028_DB_STENCIL_CLEAR + 4 * reg_offset;
 
if (cmd_buffer->device->physical_device->rad_info.chip_class >= VI) {
radeon_emit(cs, PKT3(PKT3_LOAD_CONTEXT_REG, 3, 0));
radeon_emit(cs, va);
radeon_emit(cs, va >> 32);
-   radeon_emit(cs, (reg >> 2) - CONTEXT_SPACE_START);
+   radeon_emit(cs, (reg >> 2) - 0xa000);
radeon_emit(cs, reg_count);
} else {
radeon_emit(cs, PKT3(PKT3_COPY_DATA, 4, 0));
radeon_emit(cs, COPY_DATA_SRC_SEL(COPY_DATA_SRC_MEM) |
COPY_DATA_DST_SEL(COPY_DATA_REG) |
(reg_count == 2 ? COPY_DATA_COUNT_SEL : 0));
radeon_emit(cs, va);
radeon_emit(cs, va >> 32);
radeon_emit(cs, reg >> 2);
radeon_emit(cs, 0);
@@ -1452,21 +1450,21 @@ radv_load_color_clear_metadata(struct radv_cmd_buffer 
*cmd_buffer,
 
if (!radv_image_has_cmask(image) && !radv_image_has_dcc(image))
return;
 
uint32_t reg = R_028C8C_CB_COLOR0_CLEAR_WORD0 + cb_idx * 0x3c;
 
if (cmd_buffer->device->physical_device->rad_info.chip_class >= VI) {
radeon_emit(cs, PKT3(PKT3_LOAD_CONTEXT_REG, 3, 
cmd_buffer->state.predicating));
radeon_emit(cs, va);
radeon_emit(cs, va >> 32);
-   radeon_emit(cs, (reg >> 2) - CONTEXT_SPACE_START);
+   radeon_emit(cs, (reg >> 2) - 0xa000);
radeon_e

[Mesa-dev] [PATCH] nir/deref: Support casts in comparisons

[Jason Ekstrand]

The code which constructs deref paths already gives you the path
starting at the nearest deref_cast or deref_var.  All we need to do is
handle the case where the start of the path isn't a deref_var.

Cc: Karol Herbst 
Cc: Dave Airlie 
---
 src/compiler/nir/nir_deref.c | 42 +---
 1 file changed, 39 insertions(+), 3 deletions(-)

diff --git a/src/compiler/nir/nir_deref.c b/src/compiler/nir/nir_deref.c
index 4a2e81956d1..59b36a7f255 100644
--- a/src/compiler/nir/nir_deref.c
+++ b/src/compiler/nir/nir_deref.c
@@ -272,13 +272,51 @@ nir_fixup_deref_modes(nir_shader *shader)
}
 }
 
+static bool
+modes_may_alias(nir_variable_mode a, nir_variable_mode b)
+{
+   /* Two pointers can only alias if they have the same mode.
+*
+* NOTE: In future, with things like OpenCL generic pointers, this may not
+* be true and will have to be re-evaluated.  However, with graphics only,
+* it should be safe.
+*/
+   return a == b;
+}
+
 nir_deref_compare_result
 nir_compare_deref_paths(nir_deref_path *a_path,
 nir_deref_path *b_path)
 {
-   if (a_path->path[0]->var != b_path->path[0]->var)
+   if (!modes_may_alias(b_path->path[0]->mode, a_path->path[0]->mode))
   return 0;
 
+   if (a_path->path[0]->deref_type != b_path->path[0]->deref_type)
+  return nir_derefs_may_alias_bit;
+
+   if (a_path->path[0]->deref_type == nir_deref_type_var) {
+  /* If we can chase the deref all the way back to the variable and
+   * they're not the same variable, we know they can't possibly alias.
+   */
+  if (a_path->path[0]->var != b_path->path[0]->var)
+ return 0;
+   } else {
+  assert(a_path->path[0]->deref_type == nir_deref_type_cast);
+  /* If they're not exactly the same cast, we can't compare them so we
+   * have to assume they alias.  Comparing casts is tricky as there are
+   * lots of things such as mode, type, etc. to make sure work out; for
+   * now, we just assume CSE will combine them and compare the deref
+   * instructions.
+   *
+   * TODO: At some point in the future, we could be clever and understand
+   * that a float[] and int[] have the same layout and aliasing structure
+   * but double[] and vec3[] do not and we could potentially be a bit
+   * smarter here.
+   */
+  if (a_path->path[0] != b_path->path[0])
+ return nir_derefs_may_alias_bit;
+   }
+
/* Start off assuming they fully compare.  We ignore equality for now.  In
 * the end, we'll determine that by containment.
 */
@@ -368,8 +406,6 @@ nir_compare_derefs(nir_deref_instr *a, nir_deref_instr *b)
nir_deref_path a_path, b_path;
nir_deref_path_init(&a_path, a, NULL);
nir_deref_path_init(&b_path, b, NULL);
-   assert(a_path.path[0]->deref_type == nir_deref_type_var);
-   assert(b_path.path[0]->deref_type == nir_deref_type_var);
 
nir_deref_compare_result result = nir_compare_deref_paths(&a_path, &b_path);
 
-- 
2.19.1

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

Re: [Mesa-dev] [PATCH 25/30] mesa/main: split float-texture support checking in two

[Erik Faye-Lund]

On Mon, 2018-11-19 at 18:43 +0100, Francesco Ansanelli wrote:
> Hi Eric,
> 
> While checking this patch I noticed an extra semicolon in this
> function:
> +static inline bool
> +_mesa_has_half_float_textures(const struct gl_context *ctx)
> +{
> +   return _mesa_has_ARB_texture_float(ctx) ||
> +  _mesa_has_OES_texture_half_float(ctx) ||
> _mesa_is_gles3(ctx);;
> +}

Whoops, good catch. Thanks for noticing :)

> I'm also wondering about the new default below:
> +  default:
> + ; /* fallthrough */
> It's not exactly a fall through case IMHO, but I understand what you
> mean with it... I'd evaluate to put the second switch under the
> default instead, but probably it's just a matter of taste and can
> lead to an unwanted bigger patch.

Yeah, this is a bit confusing, I agree. The comment and the default-
block seems to be needless, but they were already there and I copied it
for the second version. I don't think it's *wrong*, but I don't think
it solves anything either. The default-handling and comment should just
go away, I think.

> Sorry the bothering..
> Cheers,
> Francesco

No bother at all, thanks for the input :)

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

Re: [Mesa-dev] [PATCH mesa 3/3] meson: fix wayland-less builds

[Eric Engestrom]

On Monday, 2018-11-19 16:15:24 +0100, Juan A. Suarez Romero wrote:
> On Thu, 2018-10-11 at 16:36 +0100, Eric Engestrom wrote:
> > Those empty variables in the !wayland case are useless and running that
> > meson.build with them breaks the build:
> > 
> >   [287/850] Generating wayland-drm-client-protocol.h with a custom command.
> >   FAILED: src/egl/wayland/wayland-drm/wayland-drm-client-protocol.h
> >   client-header ../src/egl/wayland/wayland-drm/wayland-drm.xml 
> > src/egl/wayland/wayland-drm/wayland-drm-client-protocol.h
> >   /bin/sh: client-header: command not found
> >   ninja: build stopped: subcommand failed.
> > 
> > Fixes: d1992255bb29054fa5176 "meson: Add build Intel "anv" vulkan driver"
> > Signed-off-by: Eric Engestrom 
> > ---
> > Kind of amazed that no one has tried to build with wayland disabled
> > since meson was introduced, but I guess it's a good thing ^^'
> 
> Hi.
> 
> 
> This patch has been selected for next 18.2 release.
> 
> Nevertheless, a trivial conflict was resolved when applying on the stable
> branch.
> 
> You can find the fixed commit at 
> 
> https://gitlab.freedesktop.org/mesa/mesa/commit/865a97472a10aeb126f69e29a9459e2bc9922f70

Looks all good to me, thanks!

> 
> 
>   J.A.
> 
> > ---
> >  meson.build | 7 ---
> >  src/meson.build | 4 +++-
> >  2 files changed, 3 insertions(+), 8 deletions(-)
> > 
> > diff --git a/meson.build b/meson.build
> > index 0276b11e9cf003f6ebde..fcde41387ac2581ccad0 100644
> > --- a/meson.build
> > +++ b/meson.build
> > @@ -1315,13 +1315,6 @@ if with_platform_wayland
> >  'linux-dmabuf', 'linux-dmabuf-unstable-v1.xml'
> >)
> >pre_args += ['-DHAVE_WAYLAND_PLATFORM', '-DWL_HIDE_DEPRECATED']
> > -else
> > -  prog_wl_scanner = []
> > -  wl_scanner_arg = ''
> > -  dep_wl_protocols = null_dep
> > -  dep_wayland_client = null_dep
> > -  dep_wayland_server = null_dep
> > -  wayland_dmabuf_xml = ''
> >  endif
> >  
> >  dep_x11 = null_dep
> > diff --git a/src/meson.build b/src/meson.build
> > index 2b8fcc36be5b0b1688ec..75f642018f03ecfef562 100644
> > --- a/src/meson.build
> > +++ b/src/meson.build
> > @@ -56,7 +56,9 @@ if with_gles1 or with_gles2 or with_shared_glapi
> >  endif
> >  # TODO: opengl
> >  subdir('compiler')
> > -subdir('egl/wayland/wayland-drm')
> > +if with_platform_wayland
> > +  subdir('egl/wayland/wayland-drm')
> > +endif
> >  if with_any_vk
> >subdir('vulkan')
> >  endif
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] meson: Don't set -Wall

[Dylan Baker]

Quoting Juan A. Suarez Romero (2018-11-19 07:17:14)
> On Fri, 2018-11-09 at 13:28 -0800, Dylan Baker wrote:
> > meson does this for you with it's warn levels, so we don't need to set
> > it ourselves.
> > 
> > Fixes: d1992255bb29054fa51763376d125183a9f602f3
> >("meson: Add build Intel "anv" vulkan driver")
> 
> 
> Hi.
> 
> I've cherry-picked this commit for next 18.2 release, after solving a trivial
> conflict:
> 
> https://gitlab.freedesktop.org/mesa/mesa/commit/93b2a277ab61e1de5946745f9a33bf07982fbd30
> 
> 
> J.A.
> 

Looks good, thanks!

Dylan


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

Re: [Mesa-dev] [PATCH 30/30] mesa/st: require linear interpolation for ARB_texture_float

[Erik Faye-Lund]

On Mon, 2018-11-19 at 11:37 -0500, Ilia Mirkin wrote:
> On Mon, Nov 19, 2018 at 11:30 AM Erik Faye-Lund
>  wrote:
> > On Mon, 2018-11-19 at 11:13 -0500, Ilia Mirkin wrote:
> > > On Mon, Nov 19, 2018 at 10:40 AM Erik Faye-Lund
> > >  wrote:
> > > > On Mon, 2018-11-19 at 10:02 -0500, Ilia Mirkin wrote:
> > > > > Unfortunately this will drop GL 3.0 from Adreno A3xx. I think
> > > > > we'd
> > > > > rather fake linear interpolation with F32 textures which are
> > > > > never
> > > > > used than lose GL 3.0 there...
> > > > 
> > > > Right...
> > > > 
> > > > I guess this means that this GPU never really did support
> > > > OpenGL
> > > > 3.0,
> > > > and will make some applications misbehave. There's definately
> > > > applications out there that will lead to surprisingly bad
> > > > problems
> > > > when
> > > > features like these are not supported.
> > > > 
> > > > For instance if an application tries to take a local gradient
> > > > by
> > > > sampling a texture twice with a tiny epsilon (a common trick in
> > > > tangent-free normal mapping, for instance), it will essentially
> > > > get
> > > > garbage, which can cause close to useless rendering.
> > > > 
> > > > I've worked on applications that would have had problems like
> > > > these
> > > > if
> > > > drivers report the wrong version, but could work correctly if
> > > > they
> > > > report the right version.
> > > > 
> > > > Either way, I don't believe faking like that belongs in core
> > > > Mesa.
> > > > So
> > > > if the Freedreno developers really want this kind of behavior,
> > > > perhaps
> > > > something like this could be a better move?
> > > > 
> > > > ---8<---
> > > > diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c
> > > > b/src/gallium/drivers/freedreno/freedreno_screen.c
> > > > index 88d91a91234..de811371f05 100644
> > > > --- a/src/gallium/drivers/freedreno/freedreno_screen.c
> > > > +++ b/src/gallium/drivers/freedreno/freedreno_screen.c
> > > > @@ -260,6 +260,11 @@ fd_screen_get_param(struct pipe_screen
> > > > *pscreen,
> > > > enum pipe_cap param)
> > > > return 0;
> > > > 
> > > > case PIPE_CAP_TEXTURE_FLOAT_LINEAR:
> > > > +   /* HACK: A330 doesn't support linear
> > > > interpolation
> > > > of
> > > > FP32 textures, but
> > > > +* to keep OpenGL 3.0 support, we lie about it
> > > > here.
> > > > +*/
> > > > +   return is_a3xx(screen) || is_a4xx(screen) ||
> > > > is_a5xx(screen) || is_a6xx(screen);
> > > > +
> > > > case PIPE_CAP_CUBE_MAP_ARRAY:
> > > > case PIPE_CAP_SAMPLER_VIEW_TARGET:
> > > > case PIPE_CAP_TEXTURE_QUERY_LOD:
> > > > ---8<---
> > > > 
> > > > Alternatively, they could ask users to override the GL-version
> > > > for
> > > > applications that need GL 3.0, but doesn't have problems with
> > > > the
> > > > lack
> > > > of FP32-interpolation...
> > > 
> > > GL 3.0 brings SO much stuff in though, and GL 3.1 brings core
> > > profiles.
> > > 
> > > Your proposed solution will also expose the OES_bla ext, which we
> > > definitely don't want to do. I'd instead keep it loose. The
> > > hardware
> > > that doesn't support this stuff is generally targeted at ES.
> > > However
> > > it's convenient to have desktop GL both for test coverage
> > > (piglit) as
> > > well as regular use.
> > > 
> > > Tons of desktop stuff doesn't work in Adreno. Starting with
> > > different
> > > cull modes for front and back. Setting polygon mode for quads to
> > > lines
> > > shows you the internal line. Edge mode isn't supported. Probably
> > > 1
> > > other things.
> > > 
> > > But it's still very useful to have GL 3.x advertised.
> > 
> > As I tried to point out, that's only useful from one point of view.
> > From an application developer's point of view, it's *worse* to
> > expose
> > GL 3.0 when it's not really supported. There's no way for
> > applications
> > to tell if filtering will work or not. When the correct version is
> > reported, the application can provide a fallback path for the
> > features
> > it need, or fall back to lower quality rendering.
> > 
> > When you're outside the spec, you kinda have to pick your poison.
> > But I
> > don't think a single driver wanting to fake the support should
> > affect
> > all other drivers regardless.
> 
> You're looking at this as some hypothetical driver which supports a
> random smattering of extension enables, and trying to make mesa
> resilient against such an adversarial opponent.

Why are you making assumptions about my motivations or point of view?
I'm not doing what you claim. I'm trying to make it easier to reason
about what features are required for which versions. The way extensions
are handled are currently a mess, and this patch-series is about trying
to make that a bit better.

That being said, I'm not going to insist on this patch getting merged
with the series; it's not a particularly important patch to me, it was
just something I noticed while fi

Re: [Mesa-dev] [PATCH 30/30] mesa/st: require linear interpolation for ARB_texture_float

[Ilia Mirkin]

On Mon, Nov 19, 2018 at 11:30 AM Erik Faye-Lund
 wrote:
>
> On Mon, 2018-11-19 at 11:13 -0500, Ilia Mirkin wrote:
> > On Mon, Nov 19, 2018 at 10:40 AM Erik Faye-Lund
> >  wrote:
> > > On Mon, 2018-11-19 at 10:02 -0500, Ilia Mirkin wrote:
> > > > Unfortunately this will drop GL 3.0 from Adreno A3xx. I think
> > > > we'd
> > > > rather fake linear interpolation with F32 textures which are
> > > > never
> > > > used than lose GL 3.0 there...
> > >
> > > Right...
> > >
> > > I guess this means that this GPU never really did support OpenGL
> > > 3.0,
> > > and will make some applications misbehave. There's definately
> > > applications out there that will lead to surprisingly bad problems
> > > when
> > > features like these are not supported.
> > >
> > > For instance if an application tries to take a local gradient by
> > > sampling a texture twice with a tiny epsilon (a common trick in
> > > tangent-free normal mapping, for instance), it will essentially get
> > > garbage, which can cause close to useless rendering.
> > >
> > > I've worked on applications that would have had problems like these
> > > if
> > > drivers report the wrong version, but could work correctly if they
> > > report the right version.
> > >
> > > Either way, I don't believe faking like that belongs in core Mesa.
> > > So
> > > if the Freedreno developers really want this kind of behavior,
> > > perhaps
> > > something like this could be a better move?
> > >
> > > ---8<---
> > > diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c
> > > b/src/gallium/drivers/freedreno/freedreno_screen.c
> > > index 88d91a91234..de811371f05 100644
> > > --- a/src/gallium/drivers/freedreno/freedreno_screen.c
> > > +++ b/src/gallium/drivers/freedreno/freedreno_screen.c
> > > @@ -260,6 +260,11 @@ fd_screen_get_param(struct pipe_screen
> > > *pscreen,
> > > enum pipe_cap param)
> > > return 0;
> > >
> > > case PIPE_CAP_TEXTURE_FLOAT_LINEAR:
> > > +   /* HACK: A330 doesn't support linear interpolation
> > > of
> > > FP32 textures, but
> > > +* to keep OpenGL 3.0 support, we lie about it
> > > here.
> > > +*/
> > > +   return is_a3xx(screen) || is_a4xx(screen) ||
> > > is_a5xx(screen) || is_a6xx(screen);
> > > +
> > > case PIPE_CAP_CUBE_MAP_ARRAY:
> > > case PIPE_CAP_SAMPLER_VIEW_TARGET:
> > > case PIPE_CAP_TEXTURE_QUERY_LOD:
> > > ---8<---
> > >
> > > Alternatively, they could ask users to override the GL-version for
> > > applications that need GL 3.0, but doesn't have problems with the
> > > lack
> > > of FP32-interpolation...
> >
> > GL 3.0 brings SO much stuff in though, and GL 3.1 brings core
> > profiles.
> >
> > Your proposed solution will also expose the OES_bla ext, which we
> > definitely don't want to do. I'd instead keep it loose. The hardware
> > that doesn't support this stuff is generally targeted at ES. However
> > it's convenient to have desktop GL both for test coverage (piglit) as
> > well as regular use.
> >
> > Tons of desktop stuff doesn't work in Adreno. Starting with different
> > cull modes for front and back. Setting polygon mode for quads to
> > lines
> > shows you the internal line. Edge mode isn't supported. Probably
> > 1
> > other things.
> >
> > But it's still very useful to have GL 3.x advertised.
>
> As I tried to point out, that's only useful from one point of view.
> From an application developer's point of view, it's *worse* to expose
> GL 3.0 when it's not really supported. There's no way for applications
> to tell if filtering will work or not. When the correct version is
> reported, the application can provide a fallback path for the features
> it need, or fall back to lower quality rendering.
>
> When you're outside the spec, you kinda have to pick your poison. But I
> don't think a single driver wanting to fake the support should affect
> all other drivers regardless.

You're looking at this as some hypothetical driver which supports a
random smattering of extension enables, and trying to make mesa
resilient against such an adversarial opponent.

But that's not what's going on here. Features come in packs. I think
that a3xx on adreno is the only hardware affected by this change in
practice.

>
> And with the other legacy GL features that Adreno miss, those are IMO
> completely different, exactly because these don't force other drivers
> to like about their feature-set. So, I agree that it's not ideal, but
> there's not really anything to do about those missing features.
>
> But if you want to keep the behavior the same, perhaps you could setenv
> MESA_GL_VERSION_OVERRIDE when creating the screen for A3xx?

But that should be the default behavior - the desktop support is
imperfect there. Nobody really cares. Why make users jump through
hoops?

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

Re: [Mesa-dev] [PATCH 30/30] mesa/st: require linear interpolation for ARB_texture_float

[Erik Faye-Lund]

On Mon, 2018-11-19 at 11:13 -0500, Ilia Mirkin wrote:
> On Mon, Nov 19, 2018 at 10:40 AM Erik Faye-Lund
>  wrote:
> > On Mon, 2018-11-19 at 10:02 -0500, Ilia Mirkin wrote:
> > > Unfortunately this will drop GL 3.0 from Adreno A3xx. I think
> > > we'd
> > > rather fake linear interpolation with F32 textures which are
> > > never
> > > used than lose GL 3.0 there...
> > 
> > Right...
> > 
> > I guess this means that this GPU never really did support OpenGL
> > 3.0,
> > and will make some applications misbehave. There's definately
> > applications out there that will lead to surprisingly bad problems
> > when
> > features like these are not supported.
> > 
> > For instance if an application tries to take a local gradient by
> > sampling a texture twice with a tiny epsilon (a common trick in
> > tangent-free normal mapping, for instance), it will essentially get
> > garbage, which can cause close to useless rendering.
> > 
> > I've worked on applications that would have had problems like these
> > if
> > drivers report the wrong version, but could work correctly if they
> > report the right version.
> > 
> > Either way, I don't believe faking like that belongs in core Mesa.
> > So
> > if the Freedreno developers really want this kind of behavior,
> > perhaps
> > something like this could be a better move?
> > 
> > ---8<---
> > diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c
> > b/src/gallium/drivers/freedreno/freedreno_screen.c
> > index 88d91a91234..de811371f05 100644
> > --- a/src/gallium/drivers/freedreno/freedreno_screen.c
> > +++ b/src/gallium/drivers/freedreno/freedreno_screen.c
> > @@ -260,6 +260,11 @@ fd_screen_get_param(struct pipe_screen
> > *pscreen,
> > enum pipe_cap param)
> > return 0;
> > 
> > case PIPE_CAP_TEXTURE_FLOAT_LINEAR:
> > +   /* HACK: A330 doesn't support linear interpolation
> > of
> > FP32 textures, but
> > +* to keep OpenGL 3.0 support, we lie about it
> > here.
> > +*/
> > +   return is_a3xx(screen) || is_a4xx(screen) ||
> > is_a5xx(screen) || is_a6xx(screen);
> > +
> > case PIPE_CAP_CUBE_MAP_ARRAY:
> > case PIPE_CAP_SAMPLER_VIEW_TARGET:
> > case PIPE_CAP_TEXTURE_QUERY_LOD:
> > ---8<---
> > 
> > Alternatively, they could ask users to override the GL-version for
> > applications that need GL 3.0, but doesn't have problems with the
> > lack
> > of FP32-interpolation...
> 
> GL 3.0 brings SO much stuff in though, and GL 3.1 brings core
> profiles.
> 
> Your proposed solution will also expose the OES_bla ext, which we
> definitely don't want to do. I'd instead keep it loose. The hardware
> that doesn't support this stuff is generally targeted at ES. However
> it's convenient to have desktop GL both for test coverage (piglit) as
> well as regular use.
> 
> Tons of desktop stuff doesn't work in Adreno. Starting with different
> cull modes for front and back. Setting polygon mode for quads to
> lines
> shows you the internal line. Edge mode isn't supported. Probably
> 1
> other things.
>
> But it's still very useful to have GL 3.x advertised.

As I tried to point out, that's only useful from one point of view.
From an application developer's point of view, it's *worse* to expose
GL 3.0 when it's not really supported. There's no way for applications
to tell if filtering will work or not. When the correct version is
reported, the application can provide a fallback path for the features
it need, or fall back to lower quality rendering.

When you're outside the spec, you kinda have to pick your poison. But I
don't think a single driver wanting to fake the support should affect
all other drivers regardless.

And with the other legacy GL features that Adreno miss, those are IMO
completely different, exactly because these don't force other drivers
to like about their feature-set. So, I agree that it's not ideal, but
there's not really anything to do about those missing features.

But if you want to keep the behavior the same, perhaps you could setenv
MESA_GL_VERSION_OVERRIDE when creating the screen for A3xx?

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

Re: [Mesa-dev] [PATCH 30/30] mesa/st: require linear interpolation for ARB_texture_float

[Ilia Mirkin]

On Mon, Nov 19, 2018 at 10:40 AM Erik Faye-Lund
 wrote:
>
> On Mon, 2018-11-19 at 10:02 -0500, Ilia Mirkin wrote:
> > Unfortunately this will drop GL 3.0 from Adreno A3xx. I think we'd
> > rather fake linear interpolation with F32 textures which are never
> > used than lose GL 3.0 there...
>
> Right...
>
> I guess this means that this GPU never really did support OpenGL 3.0,
> and will make some applications misbehave. There's definately
> applications out there that will lead to surprisingly bad problems when
> features like these are not supported.
>
> For instance if an application tries to take a local gradient by
> sampling a texture twice with a tiny epsilon (a common trick in
> tangent-free normal mapping, for instance), it will essentially get
> garbage, which can cause close to useless rendering.
>
> I've worked on applications that would have had problems like these if
> drivers report the wrong version, but could work correctly if they
> report the right version.
>
> Either way, I don't believe faking like that belongs in core Mesa. So
> if the Freedreno developers really want this kind of behavior, perhaps
> something like this could be a better move?
>
> ---8<---
> diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c
> b/src/gallium/drivers/freedreno/freedreno_screen.c
> index 88d91a91234..de811371f05 100644
> --- a/src/gallium/drivers/freedreno/freedreno_screen.c
> +++ b/src/gallium/drivers/freedreno/freedreno_screen.c
> @@ -260,6 +260,11 @@ fd_screen_get_param(struct pipe_screen *pscreen,
> enum pipe_cap param)
> return 0;
>
> case PIPE_CAP_TEXTURE_FLOAT_LINEAR:
> +   /* HACK: A330 doesn't support linear interpolation of
> FP32 textures, but
> +* to keep OpenGL 3.0 support, we lie about it here.
> +*/
> +   return is_a3xx(screen) || is_a4xx(screen) ||
> is_a5xx(screen) || is_a6xx(screen);
> +
> case PIPE_CAP_CUBE_MAP_ARRAY:
> case PIPE_CAP_SAMPLER_VIEW_TARGET:
> case PIPE_CAP_TEXTURE_QUERY_LOD:
> ---8<---
>
> Alternatively, they could ask users to override the GL-version for
> applications that need GL 3.0, but doesn't have problems with the lack
> of FP32-interpolation...

GL 3.0 brings SO much stuff in though, and GL 3.1 brings core profiles.

Your proposed solution will also expose the OES_bla ext, which we
definitely don't want to do. I'd instead keep it loose. The hardware
that doesn't support this stuff is generally targeted at ES. However
it's convenient to have desktop GL both for test coverage (piglit) as
well as regular use.

Tons of desktop stuff doesn't work in Adreno. Starting with different
cull modes for front and back. Setting polygon mode for quads to lines
shows you the internal line. Edge mode isn't supported. Probably 1
other things.

But it's still very useful to have GL 3.x advertised.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] vulkan: Update the XML and headers to 1.1.93

[Bas Nieuwenhuizen]

Reviewed-by: Bas Nieuwenhuizen 
On Mon, Nov 19, 2018 at 4:39 PM Jason Ekstrand  wrote:
>
> ---
>  include/vulkan/vulkan_core.h | 35 ---
>  src/vulkan/registry/vk.xml   | 84 +---
>  2 files changed, 98 insertions(+), 21 deletions(-)
>
> diff --git a/include/vulkan/vulkan_core.h b/include/vulkan/vulkan_core.h
> index 4cd8ed51dcd..35c06649aa5 100644
> --- a/include/vulkan/vulkan_core.h
> +++ b/include/vulkan/vulkan_core.h
> @@ -43,7 +43,7 @@ extern "C" {
>  #define VK_VERSION_MINOR(version) (((uint32_t)(version) >> 12) & 0x3ff)
>  #define VK_VERSION_PATCH(version) ((uint32_t)(version) & 0xfff)
>  // Version of this file
> -#define VK_HEADER_VERSION 91
> +#define VK_HEADER_VERSION 93
>
>
>  #define VK_NULL_HANDLE 0
> @@ -454,6 +454,8 @@ typedef enum VkStructureType {
>  VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VULKAN_MEMORY_MODEL_FEATURES_KHR = 
> 1000211000,
>  VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PCI_BUS_INFO_PROPERTIES_EXT = 
> 1000212000,
>  VK_STRUCTURE_TYPE_IMAGEPIPE_SURFACE_CREATE_INFO_FUCHSIA = 1000214000,
> +VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SCALAR_BLOCK_LAYOUT_FEATURES_EXT = 
> 1000221000,
> +VK_STRUCTURE_TYPE_IMAGE_STENCIL_USAGE_CREATE_INFO_EXT = 1000246000,
>  VK_STRUCTURE_TYPE_DEBUG_REPORT_CREATE_INFO_EXT = 
> VK_STRUCTURE_TYPE_DEBUG_REPORT_CALLBACK_CREATE_INFO_EXT,
>  VK_STRUCTURE_TYPE_RENDER_PASS_MULTIVIEW_CREATE_INFO_KHR = 
> VK_STRUCTURE_TYPE_RENDER_PASS_MULTIVIEW_CREATE_INFO,
>  VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTIVIEW_FEATURES_KHR = 
> VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTIVIEW_FEATURES,
> @@ -6101,9 +6103,10 @@ typedef enum VkDriverIdKHR {
>  VK_DRIVER_ID_IMAGINATION_PROPRIETARY_KHR = 7,
>  VK_DRIVER_ID_QUALCOMM_PROPRIETARY_KHR = 8,
>  VK_DRIVER_ID_ARM_PROPRIETARY_KHR = 9,
> +VK_DRIVER_ID_GOOGLE_PASTEL_KHR = 10,
>  VK_DRIVER_ID_BEGIN_RANGE_KHR = VK_DRIVER_ID_AMD_PROPRIETARY_KHR,
> -VK_DRIVER_ID_END_RANGE_KHR = VK_DRIVER_ID_ARM_PROPRIETARY_KHR,
> -VK_DRIVER_ID_RANGE_SIZE_KHR = (VK_DRIVER_ID_ARM_PROPRIETARY_KHR - 
> VK_DRIVER_ID_AMD_PROPRIETARY_KHR + 1),
> +VK_DRIVER_ID_END_RANGE_KHR = VK_DRIVER_ID_GOOGLE_PASTEL_KHR,
> +VK_DRIVER_ID_RANGE_SIZE_KHR = (VK_DRIVER_ID_GOOGLE_PASTEL_KHR - 
> VK_DRIVER_ID_AMD_PROPRIETARY_KHR + 1),
>  VK_DRIVER_ID_MAX_ENUM_KHR = 0x7FFF
>  } VkDriverIdKHR;
>
> @@ -7791,8 +7794,6 @@ typedef struct 
> VkPipelineCoverageModulationStateCreateInfoNV {
>
>
>  #define VK_EXT_image_drm_format_modifier 1
> -#define VK_EXT_EXTENSION_159_SPEC_VERSION 0
> -#define VK_EXT_EXTENSION_159_EXTENSION_NAME "VK_EXT_extension_159"
>  #define VK_EXT_IMAGE_DRM_FORMAT_MODIFIER_SPEC_VERSION 1
>  #define VK_EXT_IMAGE_DRM_FORMAT_MODIFIER_EXTENSION_NAME 
> "VK_EXT_image_drm_format_modifier"
>
> @@ -8806,6 +8807,18 @@ typedef struct VkPhysicalDevicePCIBusInfoPropertiesEXT 
> {
>
>
>
> +#define VK_EXT_scalar_block_layout 1
> +#define VK_EXT_SCALAR_BLOCK_LAYOUT_SPEC_VERSION 1
> +#define VK_EXT_SCALAR_BLOCK_LAYOUT_EXTENSION_NAME 
> "VK_EXT_scalar_block_layout"
> +
> +typedef struct VkPhysicalDeviceScalarBlockLayoutFeaturesEXT {
> +VkStructureTypesType;
> +void*  pNext;
> +VkBool32   scalarBlockLayout;
> +} VkPhysicalDeviceScalarBlockLayoutFeaturesEXT;
> +
> +
> +
>  #define VK_GOOGLE_hlsl_functionality1 1
>  #define VK_GOOGLE_HLSL_FUNCTIONALITY1_SPEC_VERSION 0
>  #define VK_GOOGLE_HLSL_FUNCTIONALITY1_EXTENSION_NAME 
> "VK_GOOGLE_hlsl_functionality1"
> @@ -8816,6 +8829,18 @@ typedef struct VkPhysicalDevicePCIBusInfoPropertiesEXT 
> {
>  #define VK_GOOGLE_DECORATE_STRING_EXTENSION_NAME "VK_GOOGLE_decorate_string"
>
>
> +#define VK_EXT_separate_stencil_usage 1
> +#define VK_EXT_SEPARATE_STENCIL_USAGE_SPEC_VERSION 1
> +#define VK_EXT_SEPARATE_STENCIL_USAGE_EXTENSION_NAME 
> "VK_EXT_separate_stencil_usage"
> +
> +typedef struct VkImageStencilUsageCreateInfoEXT {
> +VkStructureType  sType;
> +const void*  pNext;
> +VkImageUsageFlagsstencilUsage;
> +} VkImageStencilUsageCreateInfoEXT;
> +
> +
> +
>  #ifdef __cplusplus
>  }
>  #endif
> diff --git a/src/vulkan/registry/vk.xml b/src/vulkan/registry/vk.xml
> index 24cc3ce7872..6cfa256d3b3 100644
> --- a/src/vulkan/registry/vk.xml
> +++ b/src/vulkan/registry/vk.xml
> @@ -146,7 +146,7 @@ server.
>  // Vulkan 1.1 version number
>  #define VK_API_VERSION_1_1 VK_MAKE_VERSION(1, 1, 
> 0)// Patch version should always be set to 0
>  // Version of this file
> -#define VK_HEADER_VERSION 91
> +#define VK_HEADER_VERSION 93
>
>  
>  #define VK_DEFINE_HANDLE(object) typedef struct object##_T* 
> object;
> @@ -1253,7 +1253,7 @@ server.
>  VkFramebuffer  
> framebuffer
>  VkRect2D   
> renderArea
>  uint32_t   
> clearValueCount
> -const 
> VkClearValue*pClearValues
> +const VkClearValue*   
>  pClearValues
>  
>  
>  float  
> float32[4]

Re: [Mesa-dev] [PATCH 00/14] freedreno: move all the things

[Rob Clark]

On Mon, Nov 19, 2018 at 9:40 AM Bas Nieuwenhuizen  wrote:
>
> With my limited knowledge of the parts up till now, this is
>
> Reviewed-by: Bas Nieuwenhuizen 
>
> with the caveat that this might very well break the Android build.
> Have anyone to look at that or do I need to take a stab?

I'm pretty sure it will break the android build.. if you know anything
about the android build system and have some time to make an attempt,
I would appreciate that.  I don't really have an android build env
atm, nor the disk space to set one up..

BR,
-R

>
> On Mon, Nov 12, 2018 at 4:51 PM Rob Clark  wrote:
> >
> > Moves drm and the ir3 compiler to src/freedreno so it can be eventually
> > re-used by vulkan driver.
> >
> > I mostly just wanted to get the splitup and move of ir3 out of the way
> > now before I embark on some ir3 refactoring to handle some of the
> > instructions that use a different encoding on a6xx+ vs earlier gens.
> >
> > Rob Clark (14):
> >   freedreno/drm: remove dependency on gallium driver
> >   freedreno: move drm to common location
> >   freedreno/ir3: standalone compiler updates
> >   freedreno: shader_t -> gl_shader_stage
> >   freedreno: remove shader_stage_name()
> >   freedreno: FD_SHADER_DEBUG -> IR3_SHADER_DEBUG
> >   freedreno/ir3: move disasm and optmsgs debug flags
> >   util: env_var_as_unsigned() helper
> >   freedreno/ir3: use env_var_as_unsigned()
> >   freedreno/ir3: some header file cleanup
> >   freedreno/ir3: remove pipe_stream_output_info dependency
> >   freedreno/ir3: split up ir3_shader
> >   freedreno/ir3: remove u_inlines usage
> >   freedreno: move ir3 to common location
> >
> >  configure.ac  |   2 +
> >  src/Makefile.am   |   4 +
> >  src/freedreno/Makefile.am |  76 +++
> >  src/freedreno/Makefile.sources|  41 ++
> >  .../drivers => }/freedreno/drm/freedreno_bo.c |   0
> >  .../freedreno/drm/freedreno_bo_cache.c|   0
> >  .../freedreno/drm/freedreno_device.c  |   0
> >  .../freedreno/drm/freedreno_drmif.h   |   0
> >  .../freedreno/drm/freedreno_pipe.c|   0
> >  .../freedreno/drm/freedreno_priv.h|   0
> >  .../freedreno/drm/freedreno_ringbuffer.c  |   0
> >  .../freedreno/drm/freedreno_ringbuffer.h  |   0
> >  src/freedreno/drm/meson.build |  54 ++
> >  .../drivers => }/freedreno/drm/msm_bo.c   |   0
> >  .../drivers => }/freedreno/drm/msm_device.c   |   0
> >  .../drivers => }/freedreno/drm/msm_drm.h  |   0
> >  .../drivers => }/freedreno/drm/msm_pipe.c |  13 +-
> >  .../drivers => }/freedreno/drm/msm_priv.h |   0
> >  .../freedreno/drm/msm_ringbuffer.c|   0
> >  .../freedreno/drm/msm_ringbuffer_sp.c |   0
> >  .../drivers => }/freedreno/ir3/disasm-a3xx.c  |   7 +-
> >  .../drivers => }/freedreno/ir3/instr-a3xx.h   |   3 +
> >  src/{gallium/drivers => }/freedreno/ir3/ir3.c |   3 +-
> >  src/{gallium/drivers => }/freedreno/ir3/ir3.h |   5 +-
> >  .../drivers => }/freedreno/ir3/ir3_compiler.c |  15 +
> >  .../drivers => }/freedreno/ir3/ir3_compiler.h |  23 +
> >  .../freedreno/ir3/ir3_compiler_nir.c  | 103 ++--
> >  .../drivers => }/freedreno/ir3/ir3_cp.c   |   2 +-
> >  .../drivers => }/freedreno/ir3/ir3_depth.c|   0
> >  .../drivers => }/freedreno/ir3/ir3_group.c|   2 -
> >  .../drivers => }/freedreno/ir3/ir3_legalize.c |   3 +-
> >  .../drivers => }/freedreno/ir3/ir3_nir.c  |  21 +-
> >  .../drivers => }/freedreno/ir3/ir3_nir.h  |   1 -
> >  .../freedreno/ir3/ir3_nir_lower_tg4_to_tex.c  |   0
> >  .../freedreno/ir3/ir3_nir_trig.py |   0
> >  .../drivers => }/freedreno/ir3/ir3_print.c|   0
> >  .../drivers => }/freedreno/ir3/ir3_ra.c   |   8 +-
> >  .../drivers => }/freedreno/ir3/ir3_sched.c|   0
> >  src/freedreno/ir3/ir3_shader.c| 436 
> >  .../drivers => }/freedreno/ir3/ir3_shader.h   | 113 ++--
> >  src/freedreno/ir3/meson.build |  64 +++
> >  src/freedreno/meson.build |  24 +
> >  src/gallium/drivers/freedreno/Android.mk  |   1 -
> >  src/gallium/drivers/freedreno/Automake.inc|   2 +
> >  src/gallium/drivers/freedreno/Makefile.am |  37 +-
> >  .../drivers/freedreno/Makefile.sources|  40 +-
> >  .../drivers/freedreno/a2xx/disasm-a2xx.c  |  10 +-
> >  .../drivers/freedreno/a2xx/fd2_program.c  |  16 +-
> >  .../drivers/freedreno/a2xx/fd2_program.h  |   2 +-
> >  .../drivers/freedreno/a3xx/fd3_context.h  |   2 +-
> >  src/gallium/drivers/freedreno/a3xx/fd3_emit.c |   8 +-
> >  src/gallium/drivers/freedreno/a3xx/fd3_emit.h |   2 +-
> >  .../drivers/freedreno/a3xx/fd3_program.c  |   8 +-
> >  .../drivers/freedreno/a3xx/fd3_program.h  |   3 +-
> >  .../drivers/freedreno/a3xx/fd3_screen.c   |   3 +-
> >  .../drivers/freedreno/a4xx/fd4_context.h  |   2 +-
> >  src/gallium/drivers/freedreno/a4xx/fd4_emit.

Re: [Mesa-dev] Partial loop unrolling support

[Jason Ekstrand]

I also saw a case last week where the induction variable is <= imax(thing,
4) and it'd be nice to unroll those too.

--Jason

On Mon, Nov 19, 2018 at 12:18 AM Timothy Arceri 
wrote:

> This series add support for partial loop unrolling for loops with an
> unknown trip count. The new partial_unroll function allows the caller
> to specifiy how may times the loop should be unrolled and then the
> loop is inserted in the innermost continue branch of the unrolled loop.
>
> For now we only do partial unrolling for loops where we can guess the
> iteration count based on array access that uses an induction variable
> as its index (see patch 7).
>
> Patches 1-6 are tidy-ups/refactors.
>
> Patch 7 adds a method for guessing the trip count for the loop.
>
> Patch 8 adds partial unrolling support and also support for removing
> redundant load/stores from the remaining loop when considering if
> we would be accessing an array out bounds.
>
>
> ___
> 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] nir: fix an assertion for 16-bit integers in nir_imm_intN_t()

[Jason Ekstrand]

agreed.

On Mon, Nov 19, 2018 at 5:57 AM Connor Abbott  wrote:

> This will cause the assert to pass when it shouldn't in some cases
> with a 32-bit bitsize, and seems like a hack since it's subverting the
> point of the assert, which is guarantee that we won't lose any
> information by truncating the source. It would be better to fix the
> caller that's hitting the assert, and maybe change the argument to be
> a int64_t too.
> On Mon, Nov 19, 2018 at 10:38 AM Samuel Pitoiset
>  wrote:
> >
> > Fixes dEQP-VK.spirv_assembly.type.scalar.i16.*
> >
> > Fixes: 1f29f4db1e ("nir/builder: Assert that intN_t immediates fit")
> > Signed-off-by: Samuel Pitoiset 
> > ---
> >  src/compiler/nir/nir_builder.h | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/compiler/nir/nir_builder.h
> b/src/compiler/nir/nir_builder.h
> > index e37aba23dc..1f29209157 100644
> > --- a/src/compiler/nir/nir_builder.h
> > +++ b/src/compiler/nir/nir_builder.h
> > @@ -332,7 +332,8 @@ nir_imm_intN_t(nir_builder *build, uint64_t x,
> unsigned bit_size)
> >
> > assert(bit_size == 64 ||
> >(int64_t)x >> bit_size == 0 ||
> > -  (int64_t)x >> bit_size == -1);
> > +  (int64_t)x >> bit_size == -1 ||
> > +  (int64_t)x >> bit_size == 65535);
> >
> > memset(&v, 0, sizeof(v));
> > assert(bit_size <= 64);
> > --
> > 2.19.1
> >
> > ___
> > 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

Re: [Mesa-dev] [PATCH 30/30] mesa/st: require linear interpolation for ARB_texture_float

[Erik Faye-Lund]

On Mon, 2018-11-19 at 10:02 -0500, Ilia Mirkin wrote:
> Unfortunately this will drop GL 3.0 from Adreno A3xx. I think we'd
> rather fake linear interpolation with F32 textures which are never
> used than lose GL 3.0 there...

Right...

I guess this means that this GPU never really did support OpenGL 3.0,
and will make some applications misbehave. There's definately
applications out there that will lead to surprisingly bad problems when
features like these are not supported.

For instance if an application tries to take a local gradient by
sampling a texture twice with a tiny epsilon (a common trick in
tangent-free normal mapping, for instance), it will essentially get
garbage, which can cause close to useless rendering.

I've worked on applications that would have had problems like these if
drivers report the wrong version, but could work correctly if they
report the right version.

Either way, I don't believe faking like that belongs in core Mesa. So
if the Freedreno developers really want this kind of behavior, perhaps
something like this could be a better move?

---8<---
diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c
b/src/gallium/drivers/freedreno/freedreno_screen.c
index 88d91a91234..de811371f05 100644
--- a/src/gallium/drivers/freedreno/freedreno_screen.c
+++ b/src/gallium/drivers/freedreno/freedreno_screen.c
@@ -260,6 +260,11 @@ fd_screen_get_param(struct pipe_screen *pscreen,
enum pipe_cap param)
return 0;
 
case PIPE_CAP_TEXTURE_FLOAT_LINEAR:
+   /* HACK: A330 doesn't support linear interpolation of
FP32 textures, but
+* to keep OpenGL 3.0 support, we lie about it here.
+*/
+   return is_a3xx(screen) || is_a4xx(screen) ||
is_a5xx(screen) || is_a6xx(screen);
+
case PIPE_CAP_CUBE_MAP_ARRAY:
case PIPE_CAP_SAMPLER_VIEW_TARGET:
case PIPE_CAP_TEXTURE_QUERY_LOD:
---8<---

Alternatively, they could ask users to override the GL-version for
applications that need GL 3.0, but doesn't have problems with the lack
of FP32-interpolation...

> On Mon, Nov 19, 2018 at 7:16 AM Erik Faye-Lund
>  wrote:
> > There's nothing in the ARB_texture_float specification that limits
> > filterability for floating-point textures, so we need to ensure
> > that
> > this is required to enable this extension. Luckily, we have just
> > the
> > right bits ready.
> > 
> > Signed-off-by: Erik Faye-Lund 
> > ---
> >  src/mesa/state_tracker/st_extensions.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/src/mesa/state_tracker/st_extensions.c
> > b/src/mesa/state_tracker/st_extensions.c
> > index b0fc824e30c..244934f7588 100644
> > --- a/src/mesa/state_tracker/st_extensions.c
> > +++ b/src/mesa/state_tracker/st_extensions.c
> > @@ -1459,7 +1459,9 @@ void st_init_extensions(struct pipe_screen
> > *screen,
> > 
> > extensions->ARB_texture_float =
> >extensions->OES_texture_half_float &&
> > -  extensions->OES_texture_float;
> > +  extensions->OES_texture_half_float_linear &&
> > +  extensions->OES_texture_float &&
> > +  extensions->OES_texture_float_linear;
> > 
> > if (extensions->EXT_texture_filter_anisotropic &&
> > screen->get_paramf(screen,
> > PIPE_CAPF_MAX_TEXTURE_ANISOTROPY) >= 16.0)
> > --
> > 2.19.1
> > 
> > ___
> > 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/2] vulkan: Update the XML and headers to 1.1.93

[Jason Ekstrand]

---
 include/vulkan/vulkan_core.h | 35 ---
 src/vulkan/registry/vk.xml   | 84 +---
 2 files changed, 98 insertions(+), 21 deletions(-)

diff --git a/include/vulkan/vulkan_core.h b/include/vulkan/vulkan_core.h
index 4cd8ed51dcd..35c06649aa5 100644
--- a/include/vulkan/vulkan_core.h
+++ b/include/vulkan/vulkan_core.h
@@ -43,7 +43,7 @@ extern "C" {
 #define VK_VERSION_MINOR(version) (((uint32_t)(version) >> 12) & 0x3ff)
 #define VK_VERSION_PATCH(version) ((uint32_t)(version) & 0xfff)
 // Version of this file
-#define VK_HEADER_VERSION 91
+#define VK_HEADER_VERSION 93
 
 
 #define VK_NULL_HANDLE 0
@@ -454,6 +454,8 @@ typedef enum VkStructureType {
 VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VULKAN_MEMORY_MODEL_FEATURES_KHR = 
1000211000,
 VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PCI_BUS_INFO_PROPERTIES_EXT = 1000212000,
 VK_STRUCTURE_TYPE_IMAGEPIPE_SURFACE_CREATE_INFO_FUCHSIA = 1000214000,
+VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SCALAR_BLOCK_LAYOUT_FEATURES_EXT = 
1000221000,
+VK_STRUCTURE_TYPE_IMAGE_STENCIL_USAGE_CREATE_INFO_EXT = 1000246000,
 VK_STRUCTURE_TYPE_DEBUG_REPORT_CREATE_INFO_EXT = 
VK_STRUCTURE_TYPE_DEBUG_REPORT_CALLBACK_CREATE_INFO_EXT,
 VK_STRUCTURE_TYPE_RENDER_PASS_MULTIVIEW_CREATE_INFO_KHR = 
VK_STRUCTURE_TYPE_RENDER_PASS_MULTIVIEW_CREATE_INFO,
 VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTIVIEW_FEATURES_KHR = 
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTIVIEW_FEATURES,
@@ -6101,9 +6103,10 @@ typedef enum VkDriverIdKHR {
 VK_DRIVER_ID_IMAGINATION_PROPRIETARY_KHR = 7,
 VK_DRIVER_ID_QUALCOMM_PROPRIETARY_KHR = 8,
 VK_DRIVER_ID_ARM_PROPRIETARY_KHR = 9,
+VK_DRIVER_ID_GOOGLE_PASTEL_KHR = 10,
 VK_DRIVER_ID_BEGIN_RANGE_KHR = VK_DRIVER_ID_AMD_PROPRIETARY_KHR,
-VK_DRIVER_ID_END_RANGE_KHR = VK_DRIVER_ID_ARM_PROPRIETARY_KHR,
-VK_DRIVER_ID_RANGE_SIZE_KHR = (VK_DRIVER_ID_ARM_PROPRIETARY_KHR - 
VK_DRIVER_ID_AMD_PROPRIETARY_KHR + 1),
+VK_DRIVER_ID_END_RANGE_KHR = VK_DRIVER_ID_GOOGLE_PASTEL_KHR,
+VK_DRIVER_ID_RANGE_SIZE_KHR = (VK_DRIVER_ID_GOOGLE_PASTEL_KHR - 
VK_DRIVER_ID_AMD_PROPRIETARY_KHR + 1),
 VK_DRIVER_ID_MAX_ENUM_KHR = 0x7FFF
 } VkDriverIdKHR;
 
@@ -7791,8 +7794,6 @@ typedef struct 
VkPipelineCoverageModulationStateCreateInfoNV {
 
 
 #define VK_EXT_image_drm_format_modifier 1
-#define VK_EXT_EXTENSION_159_SPEC_VERSION 0
-#define VK_EXT_EXTENSION_159_EXTENSION_NAME "VK_EXT_extension_159"
 #define VK_EXT_IMAGE_DRM_FORMAT_MODIFIER_SPEC_VERSION 1
 #define VK_EXT_IMAGE_DRM_FORMAT_MODIFIER_EXTENSION_NAME 
"VK_EXT_image_drm_format_modifier"
 
@@ -8806,6 +8807,18 @@ typedef struct VkPhysicalDevicePCIBusInfoPropertiesEXT {
 
 
 
+#define VK_EXT_scalar_block_layout 1
+#define VK_EXT_SCALAR_BLOCK_LAYOUT_SPEC_VERSION 1
+#define VK_EXT_SCALAR_BLOCK_LAYOUT_EXTENSION_NAME "VK_EXT_scalar_block_layout"
+
+typedef struct VkPhysicalDeviceScalarBlockLayoutFeaturesEXT {
+VkStructureTypesType;
+void*  pNext;
+VkBool32   scalarBlockLayout;
+} VkPhysicalDeviceScalarBlockLayoutFeaturesEXT;
+
+
+
 #define VK_GOOGLE_hlsl_functionality1 1
 #define VK_GOOGLE_HLSL_FUNCTIONALITY1_SPEC_VERSION 0
 #define VK_GOOGLE_HLSL_FUNCTIONALITY1_EXTENSION_NAME 
"VK_GOOGLE_hlsl_functionality1"
@@ -8816,6 +8829,18 @@ typedef struct VkPhysicalDevicePCIBusInfoPropertiesEXT {
 #define VK_GOOGLE_DECORATE_STRING_EXTENSION_NAME "VK_GOOGLE_decorate_string"
 
 
+#define VK_EXT_separate_stencil_usage 1
+#define VK_EXT_SEPARATE_STENCIL_USAGE_SPEC_VERSION 1
+#define VK_EXT_SEPARATE_STENCIL_USAGE_EXTENSION_NAME 
"VK_EXT_separate_stencil_usage"
+
+typedef struct VkImageStencilUsageCreateInfoEXT {
+VkStructureType  sType;
+const void*  pNext;
+VkImageUsageFlagsstencilUsage;
+} VkImageStencilUsageCreateInfoEXT;
+
+
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/src/vulkan/registry/vk.xml b/src/vulkan/registry/vk.xml
index 24cc3ce7872..6cfa256d3b3 100644
--- a/src/vulkan/registry/vk.xml
+++ b/src/vulkan/registry/vk.xml
@@ -146,7 +146,7 @@ server.
 // Vulkan 1.1 version number
 #define VK_API_VERSION_1_1 VK_MAKE_VERSION(1, 1, 
0)// Patch version should always be set to 0
 // Version of this file
-#define VK_HEADER_VERSION 91
+#define VK_HEADER_VERSION 93
 
 
 #define VK_DEFINE_HANDLE(object) typedef struct object##_T* 
object;
@@ -1253,7 +1253,7 @@ server.
 VkFramebuffer  
framebuffer
 VkRect2D   
renderArea
 uint32_t   
clearValueCount
-const 
VkClearValue*pClearValues
+const VkClearValue*
pClearValues
 
 
 float  
float32[4]
@@ -1312,7 +1312,7 @@ server.
 
 VkStructureType 
sType
 const void*
pNext
-VkRenderPassCreateFlags
flags
+VkRenderPassCreateFlags
flags
 uint32_t   
attachmentCount
 const 
VkAttachmentDescription* pAttachments
 uint32_

[Mesa-dev] [PATCH 2/2] anv: Expose VK_EXT_scalar_block_layout

[Jason Ekstrand]

Our compile already splits UBO loads into scalars and the untyped
surface read messages we use for SSBO reads and writes only require
dword alignment.
---
 src/intel/vulkan/anv_device.c  | 7 +++
 src/intel/vulkan/anv_extensions.py | 1 +
 2 files changed, 8 insertions(+)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index ee35e013329..20533cb3cc0 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -922,6 +922,13 @@ void anv_GetPhysicalDeviceFeatures2(
  break;
   }
 
+  case VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SCALAR_BLOCK_LAYOUT_FEATURES_EXT: 
{
+ VkPhysicalDeviceScalarBlockLayoutFeaturesEXT *features =
+(VkPhysicalDeviceScalarBlockLayoutFeaturesEXT *)ext;
+ features->scalarBlockLayout = true;
+ break;
+  }
+
   case VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_DRAW_PARAMETER_FEATURES: {
  VkPhysicalDeviceShaderDrawParameterFeatures *features = (void *)ext;
  features->shaderDrawParameters = true;
diff --git a/src/intel/vulkan/anv_extensions.py 
b/src/intel/vulkan/anv_extensions.py
index e9afe06bb13..7c81228f705 100644
--- a/src/intel/vulkan/anv_extensions.py
+++ b/src/intel/vulkan/anv_extensions.py
@@ -122,6 +122,7 @@ EXTENSIONS = [
 Extension('VK_EXT_global_priority',   1,
   'device->has_context_priority'),
 Extension('VK_EXT_pci_bus_info',  1, True),
+Extension('VK_EXT_scalar_block_layout',   1, True),
 Extension('VK_EXT_shader_viewport_index_layer',   1, True),
 Extension('VK_EXT_shader_stencil_export', 1, 'device->info.gen 
>= 9'),
 Extension('VK_EXT_vertex_attribute_divisor',  3, True),
-- 
2.19.1

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

Re: [Mesa-dev] [PATCH] r600: clean up the GS ring buffers when the context is destroyed

[Roland Scheidegger]

Reviewed-by: Roland Scheidegger 


From: mesa-dev  on behalf of Gert 
Wollny 
Sent: Friday, November 16, 2018 6:06:15 PM
To: mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH] r600: clean up the GS ring buffers when the 
context is destroyed

I forgot:

Fixes: 1371d65a7fbd695d3516861fe733685569d890d0
   r600g: initial support for geometry shaders on evergreen (v2)

Am Freitag, den 16.11.2018, 12:48 +0100 schrieb Gert Wollny:
> From: Gert Wollny 
>
> This fixes two memory leaks reported by ASAN:
>
> Direct leak of 248 byte(s) in 1 object(s) allocated from:
>in malloc (/usr/lib64/gcc/x86_64-pc-linux-
> gnu/7.3.0/libasan.so+0xdb880)
>in r600_alloc_buffer_struct
> ../../samba/mesa/src/gallium/drivers/r600/r600_buffer_common.c:578
>in r600_buffer_create
> ../../samba/mesa/src/gallium/drivers/r600/r600_buffer_common.c:600
>in r600_resource_create_common
> ../../samba/mesa/src/gallium/drivers/r600/r600_pipe_common.c:1265
>in r600_resource_create
> ../../samba/mesa/src/gallium/drivers/r600/r600_pipe.c:725
>in pipe_buffer_create
> ../../samba/mesa/src/gallium/auxiliary/util/u_inlines.h:291
>in update_gs_block_state
> ../../samba/mesa/src/gallium/drivers/r600/r600_state_common.c:1482
>
> Direct leak of 248 byte(s) in 1 object(s) allocated from:
>in malloc (/usr/lib64/gcc/x86_64-pc-linux-
> gnu/7.3.0/libasan.so+0xdb880)
>in r600_alloc_buffer_struct
> ../../samba/mesa/src/gallium/drivers/r600/r600_buffer_common.c:578
>in r600_buffer_create
> ../../samba/mesa/src/gallium/drivers/r600/r600_buffer_common.c:600
>in r600_resource_create_common
> ../../samba/mesa/src/gallium/drivers/r600/r600_pipe_common.c:1265
>in r600_resource_create
> ../../samba/mesa/src/gallium/drivers/r600/r600_pipe.c:722
>in pipe_buffer_create
> ../../samba/mesa/src/gallium/auxiliary/util/u_inlines.h:291
>in update_gs_block_state
> ../../samba/mesa/src/gallium/drivers/r600/r600_state_common.c:1489
>
> Signed-off-by: Gert Wollny 
> ---
>  src/gallium/drivers/r600/r600_pipe.c | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/src/gallium/drivers/r600/r600_pipe.c
> b/src/gallium/drivers/r600/r600_pipe.c
> index 9e8501ff33..adf6ebc95f 100644
> --- a/src/gallium/drivers/r600/r600_pipe.c
> +++ b/src/gallium/drivers/r600/r600_pipe.c
> @@ -105,6 +105,12 @@ static void r600_destroy_context(struct
> pipe_context *context)
>   }
>   util_unreference_framebuffer_state(&rctx-
> >framebuffer.state);
>
> +if (rctx->gs_rings.gsvs_ring.buffer)
> +   pipe_resource_reference(&rctx->gs_rings.gsvs_ring.buffer,
> NULL);
> +
> +if (rctx->gs_rings.esgs_ring.buffer)
> +   pipe_resource_reference(&rctx->gs_rings.esgs_ring.buffer,
> NULL);
> +
>   for (sh = 0; sh < PIPE_SHADER_TYPES; ++sh)
>   for (i = 0; i < PIPE_MAX_CONSTANT_BUFFERS; ++i)
>   rctx->b.b.set_constant_buffer(context, sh,
> i, NULL);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-dev&data=02%7C01%7Csroland%40vmware.com%7Ce3131ecf338b44f2a84808d64be5e3bc%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636779848156025413&sdata=wNexMrKAnvcjOt9io9ZFRkrAJbziRMLzS2aTsixUO14%3D&reserved=0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] meson: Don't set -Wall

[Juan A. Suarez Romero]

On Fri, 2018-11-09 at 13:28 -0800, Dylan Baker wrote:
> meson does this for you with it's warn levels, so we don't need to set
> it ourselves.
> 
> Fixes: d1992255bb29054fa51763376d125183a9f602f3
>("meson: Add build Intel "anv" vulkan driver")


Hi.

I've cherry-picked this commit for next 18.2 release, after solving a trivial
conflict:

https://gitlab.freedesktop.org/mesa/mesa/commit/93b2a277ab61e1de5946745f9a33bf07982fbd30


J.A.

> ---
>  meson.build | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/meson.build b/meson.build
> index 18667988bac..dabfb9abddd 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -787,7 +787,7 @@ endif
>  
>  # Check for generic C arguments
>  c_args = []
> -foreach a : ['-Wall', '-Werror=implicit-function-declaration',
> +foreach a : ['-Werror=implicit-function-declaration',
>   '-Werror=missing-prototypes', '-Werror=return-type',
>   '-fno-math-errno',
>   '-fno-trapping-math', '-Qunused-arguments']
> @@ -809,7 +809,7 @@ endif
>  
>  # Check for generic C++ arguments
>  cpp_args = []
> -foreach a : ['-Wall', '-Werror=return-type',
> +foreach a : ['-Werror=return-type',
>   '-fno-math-errno', '-fno-trapping-math',
>   '-Qunused-arguments']
>if cpp.has_argument(a)

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

Re: [Mesa-dev] [PATCH mesa 3/3] meson: fix wayland-less builds

[Juan A. Suarez Romero]

On Thu, 2018-10-11 at 16:36 +0100, Eric Engestrom wrote:
> Those empty variables in the !wayland case are useless and running that
> meson.build with them breaks the build:
> 
>   [287/850] Generating wayland-drm-client-protocol.h with a custom command.
>   FAILED: src/egl/wayland/wayland-drm/wayland-drm-client-protocol.h
>   client-header ../src/egl/wayland/wayland-drm/wayland-drm.xml 
> src/egl/wayland/wayland-drm/wayland-drm-client-protocol.h
>   /bin/sh: client-header: command not found
>   ninja: build stopped: subcommand failed.
> 
> Fixes: d1992255bb29054fa5176 "meson: Add build Intel "anv" vulkan driver"
> Signed-off-by: Eric Engestrom 
> ---
> Kind of amazed that no one has tried to build with wayland disabled
> since meson was introduced, but I guess it's a good thing ^^'

Hi.


This patch has been selected for next 18.2 release.

Nevertheless, a trivial conflict was resolved when applying on the stable
branch.

You can find the fixed commit at 

https://gitlab.freedesktop.org/mesa/mesa/commit/865a97472a10aeb126f69e29a9459e2bc9922f70


J.A.

> ---
>  meson.build | 7 ---
>  src/meson.build | 4 +++-
>  2 files changed, 3 insertions(+), 8 deletions(-)
> 
> diff --git a/meson.build b/meson.build
> index 0276b11e9cf003f6ebde..fcde41387ac2581ccad0 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -1315,13 +1315,6 @@ if with_platform_wayland
>  'linux-dmabuf', 'linux-dmabuf-unstable-v1.xml'
>)
>pre_args += ['-DHAVE_WAYLAND_PLATFORM', '-DWL_HIDE_DEPRECATED']
> -else
> -  prog_wl_scanner = []
> -  wl_scanner_arg = ''
> -  dep_wl_protocols = null_dep
> -  dep_wayland_client = null_dep
> -  dep_wayland_server = null_dep
> -  wayland_dmabuf_xml = ''
>  endif
>  
>  dep_x11 = null_dep
> diff --git a/src/meson.build b/src/meson.build
> index 2b8fcc36be5b0b1688ec..75f642018f03ecfef562 100644
> --- a/src/meson.build
> +++ b/src/meson.build
> @@ -56,7 +56,9 @@ if with_gles1 or with_gles2 or with_shared_glapi
>  endif
>  # TODO: opengl
>  subdir('compiler')
> -subdir('egl/wayland/wayland-drm')
> +if with_platform_wayland
> +  subdir('egl/wayland/wayland-drm')
> +endif
>  if with_any_vk
>subdir('vulkan')
>  endif

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

Re: [Mesa-dev] [PATCH 30/30] mesa/st: require linear interpolation for ARB_texture_float

[Ilia Mirkin]

Unfortunately this will drop GL 3.0 from Adreno A3xx. I think we'd
rather fake linear interpolation with F32 textures which are never
used than lose GL 3.0 there...
On Mon, Nov 19, 2018 at 7:16 AM Erik Faye-Lund
 wrote:
>
> There's nothing in the ARB_texture_float specification that limits
> filterability for floating-point textures, so we need to ensure that
> this is required to enable this extension. Luckily, we have just the
> right bits ready.
>
> Signed-off-by: Erik Faye-Lund 
> ---
>  src/mesa/state_tracker/st_extensions.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/state_tracker/st_extensions.c 
> b/src/mesa/state_tracker/st_extensions.c
> index b0fc824e30c..244934f7588 100644
> --- a/src/mesa/state_tracker/st_extensions.c
> +++ b/src/mesa/state_tracker/st_extensions.c
> @@ -1459,7 +1459,9 @@ void st_init_extensions(struct pipe_screen *screen,
>
> extensions->ARB_texture_float =
>extensions->OES_texture_half_float &&
> -  extensions->OES_texture_float;
> +  extensions->OES_texture_half_float_linear &&
> +  extensions->OES_texture_float &&
> +  extensions->OES_texture_float_linear;
>
> if (extensions->EXT_texture_filter_anisotropic &&
> screen->get_paramf(screen, PIPE_CAPF_MAX_TEXTURE_ANISOTROPY) >= 16.0)
> --
> 2.19.1
>
> ___
> 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 00/14] freedreno: move all the things

[Bas Nieuwenhuizen]

With my limited knowledge of the parts up till now, this is

Reviewed-by: Bas Nieuwenhuizen 

with the caveat that this might very well break the Android build.
Have anyone to look at that or do I need to take a stab?

On Mon, Nov 12, 2018 at 4:51 PM Rob Clark  wrote:
>
> Moves drm and the ir3 compiler to src/freedreno so it can be eventually
> re-used by vulkan driver.
>
> I mostly just wanted to get the splitup and move of ir3 out of the way
> now before I embark on some ir3 refactoring to handle some of the
> instructions that use a different encoding on a6xx+ vs earlier gens.
>
> Rob Clark (14):
>   freedreno/drm: remove dependency on gallium driver
>   freedreno: move drm to common location
>   freedreno/ir3: standalone compiler updates
>   freedreno: shader_t -> gl_shader_stage
>   freedreno: remove shader_stage_name()
>   freedreno: FD_SHADER_DEBUG -> IR3_SHADER_DEBUG
>   freedreno/ir3: move disasm and optmsgs debug flags
>   util: env_var_as_unsigned() helper
>   freedreno/ir3: use env_var_as_unsigned()
>   freedreno/ir3: some header file cleanup
>   freedreno/ir3: remove pipe_stream_output_info dependency
>   freedreno/ir3: split up ir3_shader
>   freedreno/ir3: remove u_inlines usage
>   freedreno: move ir3 to common location
>
>  configure.ac  |   2 +
>  src/Makefile.am   |   4 +
>  src/freedreno/Makefile.am |  76 +++
>  src/freedreno/Makefile.sources|  41 ++
>  .../drivers => }/freedreno/drm/freedreno_bo.c |   0
>  .../freedreno/drm/freedreno_bo_cache.c|   0
>  .../freedreno/drm/freedreno_device.c  |   0
>  .../freedreno/drm/freedreno_drmif.h   |   0
>  .../freedreno/drm/freedreno_pipe.c|   0
>  .../freedreno/drm/freedreno_priv.h|   0
>  .../freedreno/drm/freedreno_ringbuffer.c  |   0
>  .../freedreno/drm/freedreno_ringbuffer.h  |   0
>  src/freedreno/drm/meson.build |  54 ++
>  .../drivers => }/freedreno/drm/msm_bo.c   |   0
>  .../drivers => }/freedreno/drm/msm_device.c   |   0
>  .../drivers => }/freedreno/drm/msm_drm.h  |   0
>  .../drivers => }/freedreno/drm/msm_pipe.c |  13 +-
>  .../drivers => }/freedreno/drm/msm_priv.h |   0
>  .../freedreno/drm/msm_ringbuffer.c|   0
>  .../freedreno/drm/msm_ringbuffer_sp.c |   0
>  .../drivers => }/freedreno/ir3/disasm-a3xx.c  |   7 +-
>  .../drivers => }/freedreno/ir3/instr-a3xx.h   |   3 +
>  src/{gallium/drivers => }/freedreno/ir3/ir3.c |   3 +-
>  src/{gallium/drivers => }/freedreno/ir3/ir3.h |   5 +-
>  .../drivers => }/freedreno/ir3/ir3_compiler.c |  15 +
>  .../drivers => }/freedreno/ir3/ir3_compiler.h |  23 +
>  .../freedreno/ir3/ir3_compiler_nir.c  | 103 ++--
>  .../drivers => }/freedreno/ir3/ir3_cp.c   |   2 +-
>  .../drivers => }/freedreno/ir3/ir3_depth.c|   0
>  .../drivers => }/freedreno/ir3/ir3_group.c|   2 -
>  .../drivers => }/freedreno/ir3/ir3_legalize.c |   3 +-
>  .../drivers => }/freedreno/ir3/ir3_nir.c  |  21 +-
>  .../drivers => }/freedreno/ir3/ir3_nir.h  |   1 -
>  .../freedreno/ir3/ir3_nir_lower_tg4_to_tex.c  |   0
>  .../freedreno/ir3/ir3_nir_trig.py |   0
>  .../drivers => }/freedreno/ir3/ir3_print.c|   0
>  .../drivers => }/freedreno/ir3/ir3_ra.c   |   8 +-
>  .../drivers => }/freedreno/ir3/ir3_sched.c|   0
>  src/freedreno/ir3/ir3_shader.c| 436 
>  .../drivers => }/freedreno/ir3/ir3_shader.h   | 113 ++--
>  src/freedreno/ir3/meson.build |  64 +++
>  src/freedreno/meson.build |  24 +
>  src/gallium/drivers/freedreno/Android.mk  |   1 -
>  src/gallium/drivers/freedreno/Automake.inc|   2 +
>  src/gallium/drivers/freedreno/Makefile.am |  37 +-
>  .../drivers/freedreno/Makefile.sources|  40 +-
>  .../drivers/freedreno/a2xx/disasm-a2xx.c  |  10 +-
>  .../drivers/freedreno/a2xx/fd2_program.c  |  16 +-
>  .../drivers/freedreno/a2xx/fd2_program.h  |   2 +-
>  .../drivers/freedreno/a3xx/fd3_context.h  |   2 +-
>  src/gallium/drivers/freedreno/a3xx/fd3_emit.c |   8 +-
>  src/gallium/drivers/freedreno/a3xx/fd3_emit.h |   2 +-
>  .../drivers/freedreno/a3xx/fd3_program.c  |   8 +-
>  .../drivers/freedreno/a3xx/fd3_program.h  |   3 +-
>  .../drivers/freedreno/a3xx/fd3_screen.c   |   3 +-
>  .../drivers/freedreno/a4xx/fd4_context.h  |   2 +-
>  src/gallium/drivers/freedreno/a4xx/fd4_emit.c |   4 +-
>  src/gallium/drivers/freedreno/a4xx/fd4_emit.h |   2 +-
>  .../drivers/freedreno/a4xx/fd4_program.c  |   6 +-
>  .../drivers/freedreno/a4xx/fd4_program.h  |   3 +-
>  .../drivers/freedreno/a4xx/fd4_screen.c   |   3 +-
>  .../drivers/freedreno/a5xx/fd5_context.h  |   2 +-
>  src/gallium/drivers/freedreno/a5xx/fd5_emit.c |   6 +-
>  src/gallium/drivers/freedreno/a5xx/fd5_emit.h |   2 +-
>  .../drivers/freedreno/a5xx/fd5_program.c  |  14 +-
>  .../drivers/fre

Re: [Mesa-dev] [PATCH] virgl: fix vtest regression since fencing changes.

[Robert Foss]

Hey Dave,

Thanks for catching this, pushed!

On 2018-11-19 06:47, Dave Airlie wrote:

From: Dave Airlie 

The in_fence_fd needs to be initialised to -1.

Fixes: d1a1c21e7 (virgl: native fence fd support)
---
  src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.c 
b/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.c
index bc7a8965be..a23f853924 100644
--- a/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.c
+++ b/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.c
@@ -427,6 +427,7 @@ static struct virgl_cmd_buf 
*virgl_vtest_cmd_buf_create(struct virgl_winsys *vws
 }
 cbuf->ws = vws;
 cbuf->base.buf = cbuf->buf;
+   cbuf->base.in_fence_fd = -1;
 return &cbuf->base;
  }
  


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

[Mesa-dev] [PATCH v2] configure/vulkan: linking issue of Vulkan

[Sergii Romantsov]

From: Sergii Romantsov 

Xcb-dri3 is installed into custom directory.
Installing of Vulkan on Ubuntu 16.04 fails during relinking.
Potential reason: seems during relinking a path to the custom
dri3-path is missed: glx.la depends on libloader_dri3_helper.la
which depends on XCB_DRI3_LIBS.
XCB_DRI3_LIBS contains a correct custom path, but its invisible
on lib@GL_LIB@_la_LIBADD stage.
Seems caught libtool-issue.
Solution: library-dependicies GL_LIB_DEPS moved upper.

CC: Dylan Baker 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107624
Signed-off-by: Sergii Romantsov 
---
 src/glx/Makefile.am | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/glx/Makefile.am b/src/glx/Makefile.am
index d208ce1..2a1fce3 100644
--- a/src/glx/Makefile.am
+++ b/src/glx/Makefile.am
@@ -175,10 +175,10 @@ endif
 # against the system one.
 GL_LIBS = \
$(LIBDRM_LIBS) \
+   $(GL_LIB_DEPS) \
libglx.la \
$(top_builddir)/src/mapi/glapi/libglapi.la \
-   $(top_builddir)/src/mapi/shared-glapi/libglapi.la \
-   $(GL_LIB_DEPS)
+   $(top_builddir)/src/mapi/shared-glapi/libglapi.la
 
 GL_LDFLAGS = \
-no-undefined \
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH] radv: don't force clearing the stencil aspect for LOAD_OP_DONT_CARE

[Samuel Pitoiset]

On 11/19/18 12:25 PM, Bas Nieuwenhuizen wrote:

On Mon, Nov 19, 2018 at 12:21 PM Samuel Pitoiset
 wrote:




On 11/19/18 11:56 AM, Bas Nieuwenhuizen wrote:

On Thu, Nov 15, 2018 at 10:51 AM Samuel Pitoiset
 wrote:


This has been initially added for a Sascha demo (ie. deferredshadows),
but as far I can tell this seems to no longer be needed.

No CTS changes on GFX9 and I didn't find a game that is affected.

Signed-off-by: Samuel Pitoiset 
---
   src/amd/vulkan/radv_cmd_buffer.c | 3 ---
   1 file changed, 3 deletions(-)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 8e0ed284d6..7940a8f128 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -2344,9 +2344,6 @@ radv_cmd_state_setup_attachments(struct radv_cmd_buffer 
*cmd_buffer,
  if ((att_aspects & VK_IMAGE_ASPECT_DEPTH_BIT) &&
  att->load_op == VK_ATTACHMENT_LOAD_OP_CLEAR) {
  clear_aspects |= VK_IMAGE_ASPECT_DEPTH_BIT;
-   if ((att_aspects & VK_IMAGE_ASPECT_STENCIL_BIT) 
&&
-   att->stencil_load_op == 
VK_ATTACHMENT_LOAD_OP_DONT_CARE)
-   clear_aspects |= 
VK_IMAGE_ASPECT_STENCIL_BIT;


I think we should keep it, since it still saves bandwidth, but maybe
we want to only do the clear if we do the fastpath?


What do you mean by "it saves bandwidth"?


If we do a depth-only fast clear on a d+s surface, we have to do
read+mask+or+write. If we do a d+s fast clear we can just do the
write?


With the new fast clear on GFX9 yes, otherwise we will always do a slow 
clear.









  }
  if ((att_aspects & VK_IMAGE_ASPECT_STENCIL_BIT) &&
  att->stencil_load_op == 
VK_ATTACHMENT_LOAD_OP_CLEAR) {
--
2.19.1

___
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 20/30] mesa/main: do not allow type_2_10_10_10_REV enums before gles3

[Erik Faye-Lund]

ctx->Extensions.EXT_texture_type_2_10_10_10_REV is set regardless of
the API that's used, so checking for those direcly will always enable
extensions when they are supported by the driver.

There's no corresponding extension for OpenGL ES 1.x/2.0, so we
shouldn't allow these enums there.

Signed-off-by: Erik Faye-Lund 
---
 src/mesa/main/context.h   | 7 +++
 src/mesa/main/glformats.c | 6 +++---
 2 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/src/mesa/main/context.h b/src/mesa/main/context.h
index 7db3b94e0b6..071bd5b0818 100644
--- a/src/mesa/main/context.h
+++ b/src/mesa/main/context.h
@@ -373,6 +373,13 @@ _mesa_has_texture_shared_exponent(const struct gl_context 
*ctx)
return _mesa_has_EXT_texture_shared_exponent(ctx) || _mesa_is_gles3(ctx);
 }
 
+static inline bool
+_mesa_has_texture_type_2_10_10_10_REV(const struct gl_context *ctx)
+{
+   return _mesa_is_desktop_gl(ctx) ||
+  _mesa_has_EXT_texture_type_2_10_10_10_REV(ctx);
+}
+
 /**
  * Checks if the context supports geometry shaders.
  */
diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
index 7b86c1db9d0..2ac3110187f 100644
--- a/src/mesa/main/glformats.c
+++ b/src/mesa/main/glformats.c
@@ -2194,7 +2194,7 @@ _mesa_es_error_check_format_and_type(const struct 
gl_context *ctx,
 || type == GL_UNSIGNED_SHORT_5_5_5_1
 || type == GL_FLOAT
 || type == GL_HALF_FLOAT_OES
-|| (ctx->Extensions.EXT_texture_type_2_10_10_10_REV &&
+|| (_mesa_has_texture_type_2_10_10_10_REV(ctx) &&
 type == GL_UNSIGNED_INT_2_10_10_10_REV));
   break;
 
@@ -2874,7 +2874,7 @@ _mesa_gles_error_check_format_and_type(const struct 
gl_context *ctx,
  case GL_RGBA:
  case GL_RGB10_A2:
  case GL_RGB5_A1:
-if (!ctx->Extensions.EXT_texture_type_2_10_10_10_REV)
+if (!_mesa_has_texture_type_2_10_10_10_REV(ctx))
return GL_INVALID_OPERATION;
 break;
  default:
@@ -3052,7 +3052,7 @@ _mesa_gles_error_check_format_and_type(const struct 
gl_context *ctx,
  * GLES3 doesn't, and GL_OES_required_internalformat extends that
  * to allow the sized RGB internalformats as well.
  */
-if (!ctx->Extensions.EXT_texture_type_2_10_10_10_REV)
+if (!_mesa_has_texture_type_2_10_10_10_REV(ctx))
return GL_INVALID_OPERATION;
 break;
  default:
-- 
2.19.1

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

[Mesa-dev] [PATCH 21/30] mesa/main: do not allow floating-point texture enums on gles1

[Erik Faye-Lund]

ctx->Extensions.OES_texture_float is set regardless of the API
that's used, so checking for those direcly will always allow the
enums from this extensions when they are supported by the driver.

There's no extension enabling floating-point textures for OpenGL
ES 1.x, so we shouldn't allow those enums there.

Signed-off-by: Erik Faye-Lund 
---
 src/mesa/main/glformats.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
index 2ac3110187f..453465fb1c8 100644
--- a/src/mesa/main/glformats.c
+++ b/src/mesa/main/glformats.c
@@ -2895,7 +2895,7 @@ _mesa_gles_error_check_format_and_type(const struct 
gl_context *ctx,
return GL_INVALID_OPERATION;
 break;
  case GL_RGBA:
-if (ctx->Extensions.OES_texture_float && internalFormat == format)
+if (_mesa_has_OES_texture_float(ctx) && internalFormat == format)
break;
  default:
 return GL_INVALID_OPERATION;
@@ -2903,7 +2903,7 @@ _mesa_gles_error_check_format_and_type(const struct 
gl_context *ctx,
  break;
 
   case GL_HALF_FLOAT_OES:
- if (ctx->Extensions.OES_texture_half_float && internalFormat == 
format)
+ if (_mesa_has_OES_texture_half_float(ctx) && internalFormat == format)
 break;
   default:
  return GL_INVALID_OPERATION;
@@ -3030,7 +3030,7 @@ _mesa_gles_error_check_format_and_type(const struct 
gl_context *ctx,
return GL_INVALID_OPERATION;
 break;
  case GL_RGB:
-if (ctx->Extensions.OES_texture_float && internalFormat == format)
+if (_mesa_has_OES_texture_float(ctx) && internalFormat == format)
break;
  default:
 return GL_INVALID_OPERATION;
@@ -3038,7 +3038,7 @@ _mesa_gles_error_check_format_and_type(const struct 
gl_context *ctx,
  break;
 
   case GL_HALF_FLOAT_OES:
- if (!ctx->Extensions.OES_texture_half_float || internalFormat != 
format)
+ if (!_mesa_has_OES_texture_half_float(ctx) || internalFormat != 
format)
 return GL_INVALID_OPERATION;
  break;
 
@@ -3138,7 +3138,7 @@ _mesa_gles_error_check_format_and_type(const struct 
gl_context *ctx,
break;
 case GL_RG:
if (_mesa_has_rg_textures(ctx) &&
-   ctx->Extensions.OES_texture_half_float)
+   _mesa_has_OES_texture_half_float(ctx))
   break;
 /* fallthrough */
 default:
@@ -3153,7 +3153,7 @@ _mesa_gles_error_check_format_and_type(const struct 
gl_context *ctx,
 break;
  case GL_RG:
 if (_mesa_has_rg_textures(ctx) &&
-ctx->Extensions.OES_texture_float)
+_mesa_has_OES_texture_float(ctx))
break;
 /* fallthrough */
  default:
@@ -3242,7 +3242,7 @@ _mesa_gles_error_check_format_and_type(const struct 
gl_context *ctx,
  case GL_RG:
  case GL_RED:
 if (_mesa_has_rg_textures(ctx) &&
-ctx->Extensions.OES_texture_half_float)
+_mesa_has_OES_texture_half_float(ctx))
break;
 /* fallthrough */
  default:
@@ -3257,7 +3257,7 @@ _mesa_gles_error_check_format_and_type(const struct 
gl_context *ctx,
 break;
  case GL_RED:
 if (_mesa_has_rg_textures(ctx) &&
-ctx->Extensions.OES_texture_float)
+_mesa_has_OES_texture_float(ctx))
break;
 /* fallthrough */
  default:
@@ -3369,11 +3369,11 @@ _mesa_gles_error_check_format_and_type(const struct 
gl_context *ctx,
case GL_LUMINANCE_ALPHA:
   switch (type) {
   case GL_FLOAT:
- if (!ctx->Extensions.OES_texture_float || internalFormat != format)
+ if (!_mesa_has_OES_texture_float(ctx) || internalFormat != format)
 return GL_INVALID_OPERATION;
  break;
   case GL_HALF_FLOAT_OES:
- if (!ctx->Extensions.OES_texture_half_float || internalFormat != 
format)
+ if (!_mesa_has_OES_texture_half_float(ctx) || internalFormat != 
format)
 return GL_INVALID_OPERATION;
  break;
   case GL_UNSIGNED_BYTE:
-- 
2.19.1

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

[Mesa-dev] [PATCH 09/30] mesa/main: do not allow etc2 enums on gles1

[Erik Faye-Lund]

ctx->Extensions.ARB_ES3_compatibility is set regardless of the API
that's used, so checking for those direcly will always enable
extensions when they are supported by the driver.

But there's no extension enabling ETC2 for OpenGL ES 1.x, so we
shouldn't allow those enums there.

Signed-off-by: Erik Faye-Lund 
---
 src/mesa/main/glformats.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
index 964235bb72f..2e2ef9a05bb 100644
--- a/src/mesa/main/glformats.c
+++ b/src/mesa/main/glformats.c
@@ -1385,7 +1385,7 @@ _mesa_is_compressed_format(const struct gl_context *ctx, 
GLenum format)
case MESA_FORMAT_LAYOUT_ETC1:
   return _mesa_has_OES_compressed_ETC1_RGB8_texture(ctx);
case MESA_FORMAT_LAYOUT_ETC2:
-  return _mesa_is_gles3(ctx) || ctx->Extensions.ARB_ES3_compatibility;
+  return _mesa_is_gles3(ctx) || _mesa_has_ARB_ES3_compatibility(ctx);
case MESA_FORMAT_LAYOUT_BPTC:
   return _mesa_has_ARB_texture_compression_bptc(ctx);
case MESA_FORMAT_LAYOUT_ASTC:
-- 
2.19.1

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

[Mesa-dev] [PATCH 16/30] mesa/main: do not allow EXT_packed_float enums before gles3

[Erik Faye-Lund]

EXT_packed_float isn't supported on OpenGL ES, we shouldn't allow
these enums there, before OpenGL ES 3.0 which also introduce support
for these enums.

Signed-off-by: Erik Faye-Lund 
---
 src/mesa/main/context.h   | 6 ++
 src/mesa/main/glformats.c | 6 +++---
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/src/mesa/main/context.h b/src/mesa/main/context.h
index 14f9a6b8987..84dbcb748c9 100644
--- a/src/mesa/main/context.h
+++ b/src/mesa/main/context.h
@@ -355,6 +355,12 @@ _mesa_has_float_depth_buffer(const struct gl_context *ctx)
return _mesa_has_ARB_depth_buffer_float(ctx) || _mesa_is_gles3(ctx);
 }
 
+static inline bool
+_mesa_has_packed_float(const struct gl_context *ctx)
+{
+   return _mesa_has_EXT_packed_float(ctx) || _mesa_is_gles3(ctx);
+}
+
 /**
  * Checks if the context supports geometry shaders.
  */
diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
index a26876b909a..7d79e14e248 100644
--- a/src/mesa/main/glformats.c
+++ b/src/mesa/main/glformats.c
@@ -1858,7 +1858,7 @@ _mesa_error_check_format_and_type(const struct gl_context 
*ctx,
   return GL_NO_ERROR;
 
case GL_UNSIGNED_INT_10F_11F_11F_REV:
-  if (!ctx->Extensions.EXT_packed_float) {
+  if (!_mesa_has_packed_float(ctx)) {
  return GL_INVALID_ENUM;
   }
   if (format != GL_RGB) {
@@ -1969,7 +1969,7 @@ _mesa_error_check_format_and_type(const struct gl_context 
*ctx,
return ctx->Extensions.EXT_texture_shared_exponent
   ? GL_NO_ERROR : GL_INVALID_ENUM;
 case GL_UNSIGNED_INT_10F_11F_11F_REV:
-   return ctx->Extensions.EXT_packed_float
+   return _mesa_has_packed_float(ctx)
   ? GL_NO_ERROR : GL_INVALID_ENUM;
 default:
return GL_INVALID_ENUM;
@@ -2598,7 +2598,7 @@ _mesa_base_tex_format(const struct gl_context *ctx, GLint 
internalFormat)
   }
}
 
-   if (ctx->Extensions.EXT_packed_float) {
+   if (_mesa_has_packed_float(ctx)) {
   switch (internalFormat) {
   case GL_R11F_G11F_B10F_EXT:
  return GL_RGB;
-- 
2.19.1

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

[Mesa-dev] [PATCH 18/30] mesa/main: do not allow EXT_texture_shared_exponent enums before gles3

[Erik Faye-Lund]

ctx->Extensions.EXT_texture_shared_exponent is set regardless of the
API that's used, so checking for those direcly will always allow the
enums from this extensions when they are supported by the driver.

We also need to make sure this is enabled on OpenGL ES 3. Because the
check is repeated, let's introduce a helper.

Signed-off-by: Erik Faye-Lund 
---
 src/mesa/main/context.h   | 6 ++
 src/mesa/main/glformats.c | 4 ++--
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/src/mesa/main/context.h b/src/mesa/main/context.h
index af81717d9bd..7db3b94e0b6 100644
--- a/src/mesa/main/context.h
+++ b/src/mesa/main/context.h
@@ -367,6 +367,12 @@ _mesa_has_rg_textures(const struct gl_context *ctx)
return _mesa_has_ARB_texture_rg(ctx) || _mesa_is_gles3(ctx);
 }
 
+static inline bool
+_mesa_has_texture_shared_exponent(const struct gl_context *ctx)
+{
+   return _mesa_has_EXT_texture_shared_exponent(ctx) || _mesa_is_gles3(ctx);
+}
+
 /**
  * Checks if the context supports geometry shaders.
  */
diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
index 33c2f6ce68d..9e63845f0e4 100644
--- a/src/mesa/main/glformats.c
+++ b/src/mesa/main/glformats.c
@@ -1966,7 +1966,7 @@ _mesa_error_check_format_and_type(const struct gl_context 
*ctx,
return (ctx->API == API_OPENGLES2)
   ? GL_NO_ERROR : GL_INVALID_ENUM;
 case GL_UNSIGNED_INT_5_9_9_9_REV:
-   return ctx->Extensions.EXT_texture_shared_exponent
+   return _mesa_has_texture_shared_exponent(ctx)
   ? GL_NO_ERROR : GL_INVALID_ENUM;
 case GL_UNSIGNED_INT_10F_11F_11F_REV:
return _mesa_has_packed_float(ctx)
@@ -2589,7 +2589,7 @@ _mesa_base_tex_format(const struct gl_context *ctx, GLint 
internalFormat)
   }
}
 
-   if (ctx->Extensions.EXT_texture_shared_exponent) {
+   if (_mesa_has_texture_shared_exponent(ctx)) {
   switch (internalFormat) {
   case GL_RGB9_E5_EXT:
  return GL_RGB;
-- 
2.19.1

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

[Mesa-dev] [PATCH 27/30] mesa/main: require EXT_texture_sRGB for gles3

[Erik Faye-Lund]

sRGB textures is a requirement for OpenGL ES 3.0, so let's make sure
we don't incorrectly enable a too high version.

Signed-off-by: Erik Faye-Lund 
---
 src/mesa/main/version.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index b3c68bb865c..210caad097e 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/version.c
@@ -517,6 +517,7 @@ compute_version_es2(const struct gl_extensions *extensions,
  extensions->EXT_packed_float &&
  extensions->EXT_texture_array &&
  extensions->EXT_texture_shared_exponent &&
+ extensions->EXT_texture_sRGB &&
  extensions->EXT_transform_feedback &&
  extensions->ARB_draw_instanced &&
  extensions->ARB_uniform_buffer_object &&
-- 
2.19.1

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

[Mesa-dev] [PATCH 25/30] mesa/main: split float-texture support checking in two

[Erik Faye-Lund]

On OpenGL ES 2.0, there's separate extensions adding support for
half-float and float textures. So we need to validate the enums
separately as well.

This also prevents these enums from incorrectly being allowed on
OpenGL ES 1.x, where there's no extension that enables this in the
first place.

Signed-off-by: Erik Faye-Lund 
---
 src/mesa/main/context.h   | 14 ++
 src/mesa/main/glformats.c | 39 +--
 2 files changed, 43 insertions(+), 10 deletions(-)

diff --git a/src/mesa/main/context.h b/src/mesa/main/context.h
index 071bd5b0818..bec9310db82 100644
--- a/src/mesa/main/context.h
+++ b/src/mesa/main/context.h
@@ -343,6 +343,20 @@ _mesa_has_integer_textures(const struct gl_context *ctx)
return _mesa_has_EXT_texture_integer(ctx) || _mesa_is_gles3(ctx);
 }
 
+static inline bool
+_mesa_has_half_float_textures(const struct gl_context *ctx)
+{
+   return _mesa_has_ARB_texture_float(ctx) ||
+  _mesa_has_OES_texture_half_float(ctx) || _mesa_is_gles3(ctx);;
+}
+
+static inline bool
+_mesa_has_float_textures(const struct gl_context *ctx)
+{
+   return _mesa_has_ARB_texture_float(ctx) ||
+  _mesa_has_OES_texture_float(ctx) || _mesa_is_gles3(ctx);
+ }
+
 static inline bool
 _mesa_has_texture_rgb10_a2ui(const struct gl_context *ctx)
 {
diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
index d79bcedffd9..d521b4aade5 100644
--- a/src/mesa/main/glformats.c
+++ b/src/mesa/main/glformats.c
@@ -2386,24 +2386,37 @@ _mesa_base_tex_format(const struct gl_context *ctx, 
GLint internalFormat)
  return GL_YCBCR_MESA;
}
 
-   if (ctx->Extensions.ARB_texture_float) {
+   if (_mesa_has_half_float_textures(ctx)) {
   switch (internalFormat) {
   case GL_ALPHA16F_ARB:
-  case GL_ALPHA32F_ARB:
  return GL_ALPHA;
   case GL_RGBA16F_ARB:
-  case GL_RGBA32F_ARB:
  return GL_RGBA;
   case GL_RGB16F_ARB:
-  case GL_RGB32F_ARB:
  return GL_RGB;
   case GL_INTENSITY16F_ARB:
-  case GL_INTENSITY32F_ARB:
  return GL_INTENSITY;
   case GL_LUMINANCE16F_ARB:
-  case GL_LUMINANCE32F_ARB:
  return GL_LUMINANCE;
   case GL_LUMINANCE_ALPHA16F_ARB:
+ return GL_LUMINANCE_ALPHA;
+  default:
+ ; /* fallthrough */
+  }
+   }
+
+   if (_mesa_has_float_textures(ctx)) {
+  switch (internalFormat) {
+  case GL_ALPHA32F_ARB:
+ return GL_ALPHA;
+  case GL_RGBA32F_ARB:
+ return GL_RGBA;
+  case GL_RGB32F_ARB:
+ return GL_RGB;
+  case GL_INTENSITY32F_ARB:
+ return GL_INTENSITY;
+  case GL_LUMINANCE32F_ARB:
+ return GL_LUMINANCE;
   case GL_LUMINANCE_ALPHA32F_ARB:
  return GL_LUMINANCE_ALPHA;
   default:
@@ -2546,9 +2559,12 @@ _mesa_base_tex_format(const struct gl_context *ctx, 
GLint internalFormat)
if (_mesa_has_rg_textures(ctx)) {
   switch (internalFormat) {
   case GL_R16F:
+ if (!_mesa_has_half_float_textures(ctx))
+break;
+ return GL_RED;
   case GL_R32F:
-if (!ctx->Extensions.ARB_texture_float)
-   break;
+ if (!_mesa_has_float_textures(ctx))
+break;
  return GL_RED;
   case GL_R8I:
   case GL_R8UI:
@@ -2566,9 +2582,12 @@ _mesa_base_tex_format(const struct gl_context *ctx, 
GLint internalFormat)
  return GL_RED;
 
   case GL_RG16F:
+ if (!_mesa_has_half_float_textures(ctx))
+break;
+ return GL_RG;
   case GL_RG32F:
-if (!ctx->Extensions.ARB_texture_float)
-   break;
+ if (!_mesa_has_float_textures(ctx))
+break;
  return GL_RG;
   case GL_RG8I:
   case GL_RG8UI:
-- 
2.19.1

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

[Mesa-dev] [PATCH 24/30] mesa/main: do not allow EXT_texture_sRGB_R8 enums before gles3

[Erik Faye-Lund]

ctx->Extensions.EXT_texture_sRGB_R8 is set regardless of the API
that's used, so checking for those direcly will always allow the
enums from this extensions when they are supported by the driver.

There's no extension adding support for this on OpenGL ES before
version 3.0, so let's tighten the check.

Signed-off-by: Erik Faye-Lund 
---
 src/mesa/main/glformats.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
index 6c9d8b88d79..d79bcedffd9 100644
--- a/src/mesa/main/glformats.c
+++ b/src/mesa/main/glformats.c
@@ -2473,7 +2473,7 @@ _mesa_base_tex_format(const struct gl_context *ctx, GLint 
internalFormat)
   }
}
 
-   if (ctx->Extensions.EXT_texture_sRGB_R8) {
+   if (_mesa_has_EXT_texture_sRGB_R8(ctx)) {
   switch (internalFormat) {
   case GL_SR8_EXT:
  return GL_RED;
@@ -3212,7 +3212,7 @@ _mesa_gles_error_check_format_and_type(const struct 
gl_context *ctx,
   case GL_UNSIGNED_BYTE:
  if (internalFormat == GL_R8 ||
  ((internalFormat == GL_SR8_EXT) &&
-  ctx->Extensions.EXT_texture_sRGB_R8))
+  _mesa_has_EXT_texture_sRGB_R8(ctx)))
 break;
  return GL_INVALID_OPERATION;
 
-- 
2.19.1

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

[Mesa-dev] [PATCH 23/30] mesa/main: do not allow sRGB texture enums before gles3

[Erik Faye-Lund]

ctx->Extensions.EXT_texture_sRGB is set regardless of the API that's
used, so checking for those direcly will always allow the enums from
this extensions when they are supported by the driver.

There's no extension adding support for this on OpenGL ES before
version 3.0, so let's tighten the check.

Signed-off-by: Erik Faye-Lund 
---
 src/mesa/main/glformats.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
index 0a42d3dd9a0..6c9d8b88d79 100644
--- a/src/mesa/main/glformats.c
+++ b/src/mesa/main/glformats.c
@@ -2450,7 +2450,7 @@ _mesa_base_tex_format(const struct gl_context *ctx, GLint 
internalFormat)
   }
}
 
-   if (ctx->Extensions.EXT_texture_sRGB) {
+   if (_mesa_has_EXT_texture_sRGB(ctx) || _mesa_is_gles3(ctx)) {
   switch (internalFormat) {
   case GL_SRGB_EXT:
   case GL_SRGB8_EXT:
-- 
2.19.1

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

[Mesa-dev] [PATCH 22/30] mesa/main: do not allow snorm-texture enums before gles3

[Erik Faye-Lund]

ctx->Extensions.EXT_texture_snorm is set regardless of the API
that's used, so checking for those direcly will always allow the
enums from this extensions when they are supported by the driver.

There's no extension adding support for this on OpenGL ES before
version 3.0, so let's tighten the check.

Signed-off-by: Erik Faye-Lund 
---
 src/mesa/main/glformats.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
index 453465fb1c8..0a42d3dd9a0 100644
--- a/src/mesa/main/glformats.c
+++ b/src/mesa/main/glformats.c
@@ -2411,7 +2411,7 @@ _mesa_base_tex_format(const struct gl_context *ctx, GLint 
internalFormat)
   }
}
 
-   if (ctx->Extensions.EXT_texture_snorm) {
+   if (_mesa_has_EXT_texture_snorm(ctx) || _mesa_is_gles3(ctx)) {
   switch (internalFormat) {
   case GL_RED_SNORM:
   case GL_R8_SNORM:
-- 
2.19.1

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

[Mesa-dev] [PATCH 30/30] mesa/st: require linear interpolation for ARB_texture_float

[Erik Faye-Lund]

There's nothing in the ARB_texture_float specification that limits
filterability for floating-point textures, so we need to ensure that
this is required to enable this extension. Luckily, we have just the
right bits ready.

Signed-off-by: Erik Faye-Lund 
---
 src/mesa/state_tracker/st_extensions.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/mesa/state_tracker/st_extensions.c 
b/src/mesa/state_tracker/st_extensions.c
index b0fc824e30c..244934f7588 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -1459,7 +1459,9 @@ void st_init_extensions(struct pipe_screen *screen,
 
extensions->ARB_texture_float =
   extensions->OES_texture_half_float &&
-  extensions->OES_texture_float;
+  extensions->OES_texture_half_float_linear &&
+  extensions->OES_texture_float &&
+  extensions->OES_texture_float_linear;
 
if (extensions->EXT_texture_filter_anisotropic &&
screen->get_paramf(screen, PIPE_CAPF_MAX_TEXTURE_ANISOTROPY) >= 16.0)
-- 
2.19.1

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

[Mesa-dev] [PATCH 26/30] mesa/main: require EXT_texture_type_2_10_10_10_REV for gles3

[Erik Faye-Lund]

OpenGL ES 3.0 require this functionality, so we should also test for it
to avoid incorrectly exposing a too high GLES version.

On desktop, this has been required since all the way back in OpenGL 1.2
anyway.

Signed-off-by: Erik Faye-Lund 
---
 src/mesa/main/version.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index 610ba2f08c5..b3c68bb865c 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/version.c
@@ -522,7 +522,8 @@ compute_version_es2(const struct gl_extensions *extensions,
  extensions->ARB_uniform_buffer_object &&
  extensions->EXT_texture_snorm &&
  extensions->NV_primitive_restart &&
- extensions->OES_depth_texture_cube_map);
+ extensions->OES_depth_texture_cube_map &&
+ extensions->EXT_texture_type_2_10_10_10_REV);
const bool es31_compute_shader =
   consts->MaxComputeWorkGroupInvocations >= 128;
const bool ver_3_1 = (ver_3_0 &&
-- 
2.19.1

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

[Mesa-dev] [PATCH 29/30] mesa/main: do not require float-texture filtering for es3

[Erik Faye-Lund]

The OpenGL ES 3.0 specification, table 3.13 lists half-float textures as
filterable, but not float textures. So we shouldn't depend on
ARB_float_texture, which requires full filtering support for both.

Signed-off-by: Erik Faye-Lund 
---
 src/mesa/main/version.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index 210caad097e..fb5e816db32 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/version.c
@@ -509,7 +509,9 @@ compute_version_es2(const struct gl_extensions *extensions,
  extensions->ARB_internalformat_query &&
  extensions->ARB_map_buffer_range &&
  extensions->ARB_shader_texture_lod &&
- extensions->ARB_texture_float &&
+ extensions->OES_texture_float &&
+ extensions->OES_texture_half_float &&
+ extensions->OES_texture_half_float_linear &&
  extensions->ARB_texture_rg &&
  extensions->ARB_depth_buffer_float &&
  /* extensions->ARB_framebuffer_object && */
-- 
2.19.1

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

[Mesa-dev] [PATCH 28/30] mesa/st: do not probe for the same texture-formats twice

[Erik Faye-Lund]

This should be equalent of what we did before.

Signed-off-by: Erik Faye-Lund 
---
 src/mesa/state_tracker/st_extensions.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/mesa/state_tracker/st_extensions.c 
b/src/mesa/state_tracker/st_extensions.c
index 16889074f66..b0fc824e30c 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -771,10 +771,6 @@ void st_init_extensions(struct pipe_screen *screen,
 
/* Required: render target and sampler support */
static const struct st_extension_format_mapping rendertarget_mapping[] = {
-  { { o(ARB_texture_float) },
-{ PIPE_FORMAT_R32G32B32A32_FLOAT,
-  PIPE_FORMAT_R16G16B16A16_FLOAT } },
-
   { { o(OES_texture_float) },
 { PIPE_FORMAT_R32G32B32A32_FLOAT } },
 
@@ -1461,6 +1457,10 @@ void st_init_extensions(struct pipe_screen *screen,
   }
}
 
+   extensions->ARB_texture_float =
+  extensions->OES_texture_half_float &&
+  extensions->OES_texture_float;
+
if (extensions->EXT_texture_filter_anisotropic &&
screen->get_paramf(screen, PIPE_CAPF_MAX_TEXTURE_ANISOTROPY) >= 16.0)
   extensions->ARB_texture_filter_anisotropic = GL_TRUE;
-- 
2.19.1

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

[Mesa-dev] [PATCH 19/30] mesa/main: do not allow MESA_ycbcr_texture enums on gles

[Erik Faye-Lund]

This extension requies OpenGL, and shouldn't be available on OpenGL ES.
So let's not allow the enums from it either.

Signed-off-by: Erik Faye-Lund 
---
 src/mesa/main/glformats.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
index 9e63845f0e4..7b86c1db9d0 100644
--- a/src/mesa/main/glformats.c
+++ b/src/mesa/main/glformats.c
@@ -2037,7 +2037,7 @@ _mesa_error_check_format_and_type(const struct gl_context 
*ctx,
  }
 
   case GL_YCBCR_MESA:
- if (!ctx->Extensions.MESA_ycbcr_texture)
+ if (!_mesa_has_MESA_ycbcr_texture(ctx))
 return GL_INVALID_ENUM;
  if (type == GL_UNSIGNED_SHORT_8_8_MESA ||
  type == GL_UNSIGNED_SHORT_8_8_REV_MESA)
@@ -2381,7 +2381,7 @@ _mesa_base_tex_format(const struct gl_context *ctx, GLint 
internalFormat)
 is_astc_3d_format(internalFormat)))
 return GL_RGBA;
 
-   if (ctx->Extensions.MESA_ycbcr_texture) {
+   if (!_mesa_has_MESA_ycbcr_texture(ctx)) {
   if (internalFormat == GL_YCBCR_MESA)
  return GL_YCBCR_MESA;
}
-- 
2.19.1

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