Re: [Mesa-dev] [PATCH v2 2/5] intel: Move tools/decoder.[ch] to common/gen_decoder.[ch].

[Rob Clark]

On Thu, Mar 23, 2017 at 6:32 PM, Matt Turner  wrote:
> On Wed, Mar 22, 2017 at 12:53 PM, Rob Herring  wrote:
>> On Wed, Mar 22, 2017 at 6:50 AM, Emil Velikov  
>> wrote:
>>> n 21 March 2017 at 20:58, Kenneth Graunke  wrote:
 On Tuesday, March 21, 2017 4:40:26 AM PDT Emil Velikov wrote:
> On 21 March 2017 at 11:14, Emil Velikov  wrote:
> > On 20 March 2017 at 22:04, Kenneth Graunke  
> > wrote:
> >> This way they become part of libintel_common.la so I can use them in
> >> the i965 driver.
> >> ---
> >>  src/intel/Makefile.sources  | 2 ++
> >>  src/intel/Makefile.tools.am | 2 --
> >>  src/intel/{tools/decoder.c => common/gen_decoder.c} | 2 +-
> >>  src/intel/{tools/decoder.h => common/gen_decoder.h} | 6 +++---
> >>  src/intel/tools/aubinator.c | 2 +-
> >>  5 files changed, 7 insertions(+), 7 deletions(-)
> >>  rename src/intel/{tools/decoder.c => common/gen_decoder.c} (99%)
> >>  rename src/intel/{tools/decoder.h => common/gen_decoder.h} (98%)
> >>
> >> I'd forgotten than I still had my gross symlinking hack in the first
> >> version of this series.  Here's a new spin which does this "properly" 
> >> :)
> >>
> > You can do the symlink if you want to - I don't mind. This approach
> > will "bloat" every binary that links with libintel_common, since we
> > don't ask the linker to garbage collect.
> > Admittedly we only care about the ANV case, so I'll just follow-up and
> > add the GC toggle ;-)
> >
> Scratch that we do enabled it for ANV ;-)
>
> You really nicely reworked [in 3/5] making the code "debug only", so
> perhaps can we guard the code in gen_decoder.c the same way ? ... But
> that may interact badly with aubinator :-\
> Another option would be to guard the code in ifndef ANDROID - like toggle.
>
> Otherwise one will need to copy the _xml.h rules in Android, alongside
> a dummy libmesa_genxml-like library. The latter of which will need to
> be added as LOCAL_WHOLE_STATIC_LIBRARIES [for libmesa_intel_common] to
> pull/generate the headers. At the same time none of it is used since
> Android never defines DEBUG ... nor does it use the linker garbage
> collector (GC_SECTIONS)
> Tapani feel free to grep mesa for GC_SECTIONS and use in Android.

 Ugh, good point - I forgot about Android (and SCons, but thankfully we
 don't care about SCons here).  I don't have any clue how to test Android
 builds, so I'm going to go ahead and land it as is (sorry!).

>>> No need to apologise - I'm not expecting !Android people to have the
>>> setup and/or do Android builds.
>>
>> Could we at least expect the !Android people to not commit things that
>> are known to break Android until the issue is solved?
>>
>> I can't keep up with the breakage on Intel, so I guess I'll stop caring.
>
> Is it easier for you to fix things before they're in the tree, vs after?
>
> We've got Jenkins doing a scons build to make sure that keeps working,
> but I'm not sure if it's reasonably possible to do the same for
> Android.
>
> Is your suggestion for Mesa developers to gate their patches on
> updating the Android build system?

to be fair, I guess not *every* patch is touching the build system..

That said, I guess intel has folks actually focusing on doing android
(judging by drm-hwc gerrit) so I guess in the intel case, Rob ignoring
it and different intel folks fixing the android build on their own
schedule seems like a valid option..

(although if somehow meson provided some magic way that more could be
shared between android and linux build systems, that would certainly
be a good thing.. building android isn't something I'd want to inflict
on any mesa dev who had the audacity to move a bit of code around..
but in the current state I also don't envy the task of keeping AOSP
master + mesa master working together)

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

Re: [Mesa-dev] [PATCH 0/4] Code style fixes

[Ilia Mirkin]

Series is:

Reviewed-by: Ilia Mirkin 

On Wed, Mar 22, 2017 at 8:51 PM, Lyude  wrote:
> While working on adding NV_fill_polygon support for mesa, I noticed a good
> number of parts of mesa that had somewhat broken indenting, trailing
> whitespace, etc. So I decided to fix up anything close to the code I was
> touching.
>
> This series contains no functional changes, only minor style fixes.
>
> Lyude (4):
>   vc4: Fix indenting in vc4_screen_get_param()
>   r300: Fix indenting in r300_get_param()
>   mesa: Fix gross indenting in _mesa_PolygonMode()
>   mesa: Fix trailing whitespace in polygon.c
>
>  src/gallium/drivers/r300/r300_screen.c |  6 +++---
>  src/gallium/drivers/vc4/vc4_screen.c   |  6 +++---
>  src/mesa/main/polygon.c| 15 +++
>  3 files changed, 13 insertions(+), 14 deletions(-)
>
> --
> 2.9.3
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/6] mesa: don't use _NEW_TEXTURE mainly in mesa/main

[Timothy Arceri]

On 24/03/17 10:42, Marek Olšák wrote:

From: Marek Olšák 

---
 src/mesa/drivers/dri/i965/brw_state_upload.c |  3 ++-
 src/mesa/main/attrib.c   |  2 +-
 src/mesa/main/debug.c|  3 ++-
 src/mesa/main/state.c| 10 +-
 src/mesa/main/texstate.c | 11 ++-
 5 files changed, 16 insertions(+), 13 deletions(-)






diff --git a/src/mesa/main/debug.c b/src/mesa/main/debug.c
index 3471b26..f909f83 100644
--- a/src/mesa/main/debug.c
+++ b/src/mesa/main/debug.c
@@ -84,23 +84,24 @@ _mesa_print_state( const char *msg, GLuint state )
   (state & _NEW_FOG) ? "ctx->Fog, " : "",
   (state & _NEW_HINT)? "ctx->Hint, " : "",
   (state & _NEW_LIGHT)   ? "ctx->Light, " : "",
   (state & _NEW_LINE)? "ctx->Line, " : "",
   (state & _NEW_PIXEL)   ? "ctx->Pixel, " : "",
   (state & _NEW_POINT)   ? "ctx->Point, " : "",
   (state & _NEW_POLYGON) ? "ctx->Polygon, " : "",
   (state & _NEW_POLYGONSTIPPLE)  ? "ctx->PolygonStipple, " : "",
   (state & _NEW_SCISSOR) ? "ctx->Scissor, " : "",
   (state & _NEW_STENCIL) ? "ctx->Stencil, " : "",
-  (state & _NEW_TEXTURE) ? "ctx->Texture, " : "",
+  (state & _NEW_TEXTURE_OBJECT)  ? "ctx->Texture(Object), " : "",
   (state & _NEW_TRANSFORM)   ? "ctx->Transform, " : "",
   (state & _NEW_VIEWPORT)? "ctx->Viewport, " : "",
+   (state & _NEW_TEXTURE_STATE)   ? "ctx->Texture(State), " : "",
   (state & _NEW_ARRAY)   ? "ctx->Array, " : "",
   (state & _NEW_RENDERMODE)  ? "ctx->RenderMode, " : "",
   (state & _NEW_BUFFERS) ? "ctx->Visual, ctx->DrawBuffer,, " : 
"");
 }



You need to add an extra %s to the format here.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 3/4] mesa: Fix gross indenting in _mesa_PolygonMode()

[Lyude]

Signed-off-by: Lyude 
---
 src/mesa/main/polygon.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/src/mesa/main/polygon.c b/src/mesa/main/polygon.c
index 60af88f..46673ee 100644
--- a/src/mesa/main/polygon.c
+++ b/src/mesa/main/polygon.c
@@ -143,14 +143,13 @@ _mesa_PolygonMode( GLenum face, GLenum mode )
  return;
   }
   if (ctx->Polygon.FrontMode == mode)
-return;
+ return;
   FLUSH_VERTICES(ctx, _NEW_POLYGON);
   ctx->Polygon.FrontMode = mode;
   break;
case GL_FRONT_AND_BACK:
-  if (ctx->Polygon.FrontMode == mode &&
- ctx->Polygon.BackMode == mode)
-return;
+  if (ctx->Polygon.FrontMode == mode && ctx->Polygon.BackMode == mode)
+ return;
   FLUSH_VERTICES(ctx, _NEW_POLYGON);
   ctx->Polygon.FrontMode = mode;
   ctx->Polygon.BackMode = mode;
@@ -161,7 +160,7 @@ _mesa_PolygonMode( GLenum face, GLenum mode )
  return;
   }
   if (ctx->Polygon.BackMode == mode)
-return;
+ return;
   FLUSH_VERTICES(ctx, _NEW_POLYGON);
   ctx->Polygon.BackMode = mode;
   break;
-- 
2.9.3

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

[Mesa-dev] [PATCH 0/4] Code style fixes

[Lyude]

While working on adding NV_fill_polygon support for mesa, I noticed a good
number of parts of mesa that had somewhat broken indenting, trailing
whitespace, etc. So I decided to fix up anything close to the code I was
touching.

This series contains no functional changes, only minor style fixes.

Lyude (4):
  vc4: Fix indenting in vc4_screen_get_param()
  r300: Fix indenting in r300_get_param()
  mesa: Fix gross indenting in _mesa_PolygonMode()
  mesa: Fix trailing whitespace in polygon.c

 src/gallium/drivers/r300/r300_screen.c |  6 +++---
 src/gallium/drivers/vc4/vc4_screen.c   |  6 +++---
 src/mesa/main/polygon.c| 15 +++
 3 files changed, 13 insertions(+), 14 deletions(-)

-- 
2.9.3

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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Colin Cross]

On Thu, Mar 23, 2017 at 4:56 PM, Dylan Baker  wrote:
> Quoting Colin Cross (2017-03-23 15:14:16)
>> On Thu, Mar 23, 2017 at 2:56 PM, Greg Hackmann  wrote:
>> > On 03/22/2017 02:48 PM, Rob Clark wrote:
>> >>
>> >> On Wed, Mar 22, 2017 at 4:10 PM, Dylan Baker  wrote:
>> >>>
>> >>> Quoting Rob Clark (2017-03-22 10:07:54)
>> 
>>  I guess an interesting question (from someone who doesn't know meson
>>  yet) would be whether meson could slurp in the Makefile.sources type
>>  stuff that we have, which are shared so far between
>>  android/scons/autotools (and for the most part, kept developers from
>>  having to care *too* much about the different build systems)
>> >>>
>> >>>
>> >>> Jason and I have talked about that too. I'd suggested that we could write
>> >>> a
>> >>> module for meson to read makefile.sources (since we're surely not the
>> >>> only
>> >>> project that would benefit from such a module), except that android is
>> >>> moving to
>> >>> blueprint[1] instead of android.mk files. As far as I can tell blueprint
>> >>> doesn't
>> >>> support using makefile.sources, so it seems somewhat moot in a world of
>> >>> blueprint for android, meson for *.
>> >>
>> >>
>> >> I guess even if it is only a temporary thing, something that could
>> >> slurp in Makefile.sources seems like it would be useful for a
>> >> transition period.
>> >>
>> >> I'm not totally up to speed on android/blueprint stuff.. but even some
>> >> simplified or different "here-are-my-sources" type file that could be
>> >> shared across build systems would be useful.  Meson sounds a bit more
>> >> extensible so maybe there is some potential to adapt to whatever
>> >> android forces on us ;-)
>> >
>> >
>> > +ccross from the Android build team can hopefully provide some input here.
>>
>> For cases like this, we generally add a python script that translates
>> the build files into something Blueprint understands, and rerun it
>> each time we import into the project.
>>
>> Alternatively, Blueprint efficiently supports globbing for sources, so
>> if all the source files are always listed in Makefile.sources (which
>> seems to be true in our copy of libdrm except for intel/test_decode.c)
>> then we could use globs and ignore the makefiles, possibly manually
>> excluding a few files.
>
> I'm hoping you can clarify a couple of questions I have about blueprint:
> 1) android is moving to blueprint from android.mk files?

Yes, in a phased transition.  We support both for now.

> 2) is there a publicly available project that uses blueprint I could look at?
>The documentation I've been able to find is pretty sparse.

Blueprint is a framework for writing build systems, and Soong is
AOSP's Blueprint build system.  See
https://android.googlesource.com/platform/build/soong/+/master/README.md
for documentation on Soong.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Colin Cross]

On Thu, Mar 23, 2017 at 2:56 PM, Greg Hackmann  wrote:
> On 03/22/2017 02:48 PM, Rob Clark wrote:
>>
>> On Wed, Mar 22, 2017 at 4:10 PM, Dylan Baker  wrote:
>>>
>>> Quoting Rob Clark (2017-03-22 10:07:54)

 I guess an interesting question (from someone who doesn't know meson
 yet) would be whether meson could slurp in the Makefile.sources type
 stuff that we have, which are shared so far between
 android/scons/autotools (and for the most part, kept developers from
 having to care *too* much about the different build systems)
>>>
>>>
>>> Jason and I have talked about that too. I'd suggested that we could write
>>> a
>>> module for meson to read makefile.sources (since we're surely not the
>>> only
>>> project that would benefit from such a module), except that android is
>>> moving to
>>> blueprint[1] instead of android.mk files. As far as I can tell blueprint
>>> doesn't
>>> support using makefile.sources, so it seems somewhat moot in a world of
>>> blueprint for android, meson for *.
>>
>>
>> I guess even if it is only a temporary thing, something that could
>> slurp in Makefile.sources seems like it would be useful for a
>> transition period.
>>
>> I'm not totally up to speed on android/blueprint stuff.. but even some
>> simplified or different "here-are-my-sources" type file that could be
>> shared across build systems would be useful.  Meson sounds a bit more
>> extensible so maybe there is some potential to adapt to whatever
>> android forces on us ;-)
>
>
> +ccross from the Android build team can hopefully provide some input here.

For cases like this, we generally add a python script that translates
the build files into something Blueprint understands, and rerun it
each time we import into the project.

Alternatively, Blueprint efficiently supports globbing for sources, so
if all the source files are always listed in Makefile.sources (which
seems to be true in our copy of libdrm except for intel/test_decode.c)
then we could use globs and ignore the makefiles, possibly manually
excluding a few files.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/4] vc4: Fix indenting in vc4_screen_get_param()

[Lyude]

Signed-off-by: Lyude 
---
 src/gallium/drivers/vc4/vc4_screen.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/vc4/vc4_screen.c 
b/src/gallium/drivers/vc4/vc4_screen.c
index b53e71d..46229a7 100644
--- a/src/gallium/drivers/vc4/vc4_screen.c
+++ b/src/gallium/drivers/vc4/vc4_screen.c
@@ -225,8 +225,8 @@ vc4_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
 case PIPE_CAP_STRING_MARKER:
 case PIPE_CAP_SURFACE_REINTERPRET_BLOCKS:
 case PIPE_CAP_QUERY_BUFFER_OBJECT:
-   case PIPE_CAP_QUERY_MEMORY_INFO:
-   case PIPE_CAP_PCI_GROUP:
+case PIPE_CAP_QUERY_MEMORY_INFO:
+case PIPE_CAP_PCI_GROUP:
 case PIPE_CAP_PCI_BUS:
 case PIPE_CAP_PCI_DEVICE:
 case PIPE_CAP_PCI_FUNCTION:
@@ -246,7 +246,7 @@ vc4_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
 case PIPE_CAP_DOUBLES:
 case PIPE_CAP_INT64:
 case PIPE_CAP_INT64_DIVMOD:
-   case PIPE_CAP_TGSI_TEX_TXF_LZ:
+case PIPE_CAP_TGSI_TEX_TXF_LZ:
 return 0;
 
 /* Stream output. */
-- 
2.9.3

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

[Mesa-dev] [PATCH 2/4] r300: Fix indenting in r300_get_param()

[Lyude]

Signed-off-by: Lyude 
---
 src/gallium/drivers/r300/r300_screen.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/r300/r300_screen.c 
b/src/gallium/drivers/r300/r300_screen.c
index 07a09d5..752cf82 100644
--- a/src/gallium/drivers/r300/r300_screen.c
+++ b/src/gallium/drivers/r300/r300_screen.c
@@ -216,7 +216,7 @@ static int r300_get_param(struct pipe_screen* pscreen, enum 
pipe_cap param)
 case PIPE_CAP_QUERY_BUFFER_OBJECT:
 case PIPE_CAP_QUERY_MEMORY_INFO:
 case PIPE_CAP_FRAMEBUFFER_NO_ATTACHMENT:
-   case PIPE_CAP_ROBUST_BUFFER_ACCESS_BEHAVIOR:
+case PIPE_CAP_ROBUST_BUFFER_ACCESS_BEHAVIOR:
 case PIPE_CAP_CULL_DISTANCE:
 case PIPE_CAP_PRIMITIVE_RESTART_FOR_PATCHES:
 case PIPE_CAP_TGSI_VOTE:
@@ -246,7 +246,7 @@ static int r300_get_param(struct pipe_screen* pscreen, enum 
pipe_cap param)
 case PIPE_CAP_VERTEX_BUFFER_STRIDE_4BYTE_ALIGNED_ONLY:
 case PIPE_CAP_VERTEX_ELEMENT_SRC_OFFSET_4BYTE_ALIGNED_ONLY:
 return r300screen->caps.has_tcl;
-   case PIPE_CAP_TGSI_TEXCOORD:
+case PIPE_CAP_TGSI_TEXCOORD:
 return 0;
 
 /* Texturing. */
@@ -259,7 +259,7 @@ static int r300_get_param(struct pipe_screen* pscreen, enum 
pipe_cap param)
 /* Render targets. */
 case PIPE_CAP_MAX_RENDER_TARGETS:
 return 4;
-   case PIPE_CAP_ENDIANNESS:
+case PIPE_CAP_ENDIANNESS:
 return PIPE_ENDIAN_LITTLE;
 
 case PIPE_CAP_MAX_VIEWPORTS:
-- 
2.9.3

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

[Mesa-dev] [PATCH 4/4] mesa: Fix trailing whitespace in polygon.c

[Lyude]

Signed-off-by: Lyude 
---
 src/mesa/main/polygon.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/mesa/main/polygon.c b/src/mesa/main/polygon.c
index 46673ee..4caf62a 100644
--- a/src/mesa/main/polygon.c
+++ b/src/mesa/main/polygon.c
@@ -75,7 +75,7 @@ _mesa_CullFace( GLenum mode )
 
 
 /**
- * Define front- and back-facing 
+ * Define front- and back-facing
  *
  * \param mode orientation of front-facing polygons.
  *
@@ -115,8 +115,8 @@ _mesa_FrontFace( GLenum mode )
  * \param face the polygons which \p mode applies to.
  * \param mode how polygons should be rasterized.
  *
- * \sa glPolygonMode(). 
- * 
+ * \sa glPolygonMode().
+ *
  * Verifies the parameters and updates gl_polygon_attrib::FrontMode and
  * gl_polygon_attrib::BackMode. On change flushes the vertices and notifies the
  * driver via the dd_function_table::PolygonMode callback.
-- 
2.9.3

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

[Mesa-dev] [PATCH] radeon/vce: add firmware support for version 53.14.3

[boyuan.zhang]

From: Boyuan Zhang 

Signed-off-by: Boyuan Zhang 
---
 src/gallium/drivers/radeon/radeon_vce.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/gallium/drivers/radeon/radeon_vce.c 
b/src/gallium/drivers/radeon/radeon_vce.c
index dcd56ea..b7b309c 100644
--- a/src/gallium/drivers/radeon/radeon_vce.c
+++ b/src/gallium/drivers/radeon/radeon_vce.c
@@ -52,6 +52,7 @@
 #define FW_52_0_3 ((52 << 24) | (0 << 16) | (3 << 8))
 #define FW_52_4_3 ((52 << 24) | (4 << 16) | (3 << 8))
 #define FW_52_8_3 ((52 << 24) | (8 << 16) | (3 << 8))
+#define FW_53_14_3 ((53 << 24) | (14 << 16) | (3 << 8))
 
 /**
  * flush commands to the hardware
@@ -492,6 +493,7 @@ struct pipe_video_codec *rvce_create_encoder(struct 
pipe_context *context,
case FW_52_0_3:
case FW_52_4_3:
case FW_52_8_3:
+   case FW_53_14_3:
radeon_vce_52_init(enc);
get_pic_param = radeon_vce_52_get_param;
break;
@@ -527,6 +529,7 @@ bool rvce_is_fw_version_supported(struct r600_common_screen 
*rscreen)
case FW_52_0_3:
case FW_52_4_3:
case FW_52_8_3:
+   case FW_53_14_3:
return true;
default:
return false;
-- 
2.7.4

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

[Mesa-dev] [Bug 100091] Failure to create folder for on-disk shader cache

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #29 from Timothy Arceri  ---
Should be fixed by:

commit feb716239e1a318eb844fd3bcaca1ffd6903067c
Author: Grazvydas Ignotas 
Date:   Thu Mar 16 01:09:29 2017 +0200

util/disk_cache: hash timestamps into the cache keys

Instead of using a directory, hash the timestamps into the cache keys
themselves. Since there is no more timestamp directory, there is no more
need for deleting the cache of other mesa versions and we rely on
eviction to clean up the old cache entries. This solves the problem of
using several incarnations of disk_cache at the same time, where one
deletes a directory belonging to the other, like when both OpenGL and
gallium nine are used simultaneously (or several different mesa
installations).

v2: using additional blob instead of trying to clone sha1 state

v3: (Timothy Arceri) don't use an opaque data type to store
timestamp.

V4: (Timothy Arceri) use blob to store driver keys just make sure
to store null terminator for strings, and make sure blob is
defined by disk_cache and not it's users.

Signed-off-by: Grazvydas Ignotas 
Reviewed-by: Nicolai Hähnle 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100091

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

Re: [Mesa-dev] [PATCH v2] anv: add support for allocating more than 1 block of memory

[Jason Ekstrand]

On Thu, Mar 23, 2017 at 1:50 PM, Jason Ekstrand 
wrote:

> On Wed, Mar 22, 2017 at 4:14 AM, Juan A. Suarez Romero <
> jasua...@igalia.com> wrote:
>
>> On Wed, 2017-03-15 at 13:05 +0100, Juan A. Suarez Romero wrote:
>> > Current Anv allocator assign memory in terms of a fixed block size.
>> >
>> > But there can be cases where this block is not enough for a memory
>> > request, and thus several blocks must be assigned in a row.
>> >
>> > This commit adds support for specifying how many blocks of memory must
>> > be assigned.
>> >
>> > This fixes a number dEQP-VK.pipeline.render_to_image.* tests that
>> crash.
>> >
>> > v2: lock-free free-list is not handled correctly (Jason)
>> > ---
>>
>> Gently ping to get feedback/review O:)
>>
>
> Yup.  I took a break from e-mail so I could write some of my own patches
> for once. :-)
>

I'll try to get to it tomorrow.  Sorry about the delay.  This stuff is
hairy enough that I have to carve out some serious brain-space to review
it.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/6] mesa: inline _mesa_update_texture

[Timothy Arceri]

There are some nice cleanups here.

Series:

Reviewed-by: Timothy Arceri 

On 24/03/17 10:42, Marek Olšák wrote:

From: Marek Olšák 

---
 src/mesa/main/state.c|  7 +--
 src/mesa/main/texstate.c | 22 --
 src/mesa/main/texstate.h |  7 +--
 3 files changed, 14 insertions(+), 22 deletions(-)

diff --git a/src/mesa/main/state.c b/src/mesa/main/state.c
index 5cb58a4..71265a5 100644
--- a/src/mesa/main/state.c
+++ b/src/mesa/main/state.c
@@ -399,22 +399,25 @@ _mesa_update_state_locked( struct gl_context *ctx )
/*
 * Now update derived state info
 */

if (new_state & prog_flags)
   update_program_enables( ctx );

if (new_state & (_NEW_MODELVIEW|_NEW_PROJECTION))
   _mesa_update_modelview_project( ctx, new_state );

-   if (new_state & (_NEW_PROGRAM|_NEW_TEXTURE|_NEW_TEXTURE_MATRIX))
-  _mesa_update_texture( ctx, new_state );
+   if (new_state & _NEW_TEXTURE_MATRIX)
+  _mesa_update_texture_matrices(ctx);
+
+   if (new_state & (_NEW_TEXTURE | _NEW_PROGRAM))
+  _mesa_update_texture_state(ctx);

if (new_state & _NEW_POLYGON)
   update_frontbit( ctx );

if (new_state & _NEW_BUFFERS)
   _mesa_update_framebuffer(ctx, ctx->ReadBuffer, ctx->DrawBuffer);

if (new_state & (_NEW_SCISSOR | _NEW_BUFFERS | _NEW_VIEWPORT))
   _mesa_update_draw_buffer_bounds(ctx, ctx->DrawBuffer);

diff --git a/src/mesa/main/texstate.c b/src/mesa/main/texstate.c
index be73fc3..70e014c 100644
--- a/src/mesa/main/texstate.c
+++ b/src/mesa/main/texstate.c
@@ -348,22 +348,22 @@ _mesa_ClientActiveTexture(GLenum texture)


 /**
  * \note This routine refers to derived texture attribute values to
  * compute the ENABLE_TEXMAT flags, but is only called on
  * _NEW_TEXTURE_MATRIX.  On changes to _NEW_TEXTURE, the ENABLE_TEXMAT
  * flags are updated by _mesa_update_textures(), below.
  *
  * \param ctx GL context.
  */
-static void
-update_texture_matrices( struct gl_context *ctx )
+void
+_mesa_update_texture_matrices(struct gl_context *ctx)
 {
GLuint u;

ctx->Texture._TexMatEnabled = 0x0;

for (u = 0; u < ctx->Const.MaxTextureCoordUnits; u++) {
   assert(u < ARRAY_SIZE(ctx->TextureMatrixStack));
   if (_math_matrix_is_dirty(ctx->TextureMatrixStack[u].Top)) {
 _math_matrix_analyse( ctx->TextureMatrixStack[u].Top );

@@ -684,22 +684,22 @@ update_ff_texture_state(struct gl_context *ctx,
 }

 /**
  * \note This routine refers to derived texture matrix values to
  * compute the ENABLE_TEXMAT flags, but is only called on
  * _NEW_TEXTURE.  On changes to _NEW_TEXTURE_MATRIX, the ENABLE_TEXMAT
  * flags are updated by _mesa_update_texture_matrices, above.
  *
  * \param ctx GL context.
  */
-static void
-update_texture_state( struct gl_context *ctx )
+void
+_mesa_update_texture_state(struct gl_context *ctx)
 {
struct gl_program *prog[MESA_SHADER_STAGES];
int i;
int old_max_unit = ctx->Texture._MaxEnabledTexImageUnit;
BITSET_DECLARE(enabled_texture_units, MAX_COMBINED_TEXTURE_IMAGE_UNITS);

for (i = 0; i < MESA_SHADER_STAGES; i++) {
   if (ctx->_Shader->CurrentProgram[i]) {
  prog[i] = ctx->_Shader->CurrentProgram[i];
   } else {
@@ -740,34 +740,20 @@ update_texture_state( struct gl_context *ctx )
}
for (i = ctx->Texture._MaxEnabledTexImageUnit + 1; i <= old_max_unit; i++) {
   _mesa_reference_texobj(>Texture.Unit[i]._Current, NULL);
}

if (!prog[MESA_SHADER_FRAGMENT] || !prog[MESA_SHADER_VERTEX])
   update_texgen(ctx);
 }


-/**
- * Update texture-related derived state.
- */
-void
-_mesa_update_texture( struct gl_context *ctx, GLuint new_state )
-{
-   if (new_state & _NEW_TEXTURE_MATRIX)
-  update_texture_matrices( ctx );
-
-   if (new_state & (_NEW_TEXTURE | _NEW_PROGRAM))
-  update_texture_state( ctx );
-}
-
-
 /**/
 /*  Initialization*/
 /**/

 /**
  * Allocate the proxy textures for the given context.
  *
  * \param ctx the context to allocate proxies for.
  *
  * \return GL_TRUE on success, or GL_FALSE on failure
diff --git a/src/mesa/main/texstate.h b/src/mesa/main/texstate.h
index 52fe602..cb329b0 100644
--- a/src/mesa/main/texstate.h
+++ b/src/mesa/main/texstate.h
@@ -84,22 +84,25 @@ extern void GLAPIENTRY
 _mesa_ClientActiveTexture( GLenum target );

 /*@}*/


 /**
  * \name Initialization, state maintenance
  */
 /*@{*/

-extern void
-_mesa_update_texture( struct gl_context *ctx, GLuint new_state );
+extern void
+_mesa_update_texture_matrices(struct gl_context *ctx);
+
+extern void
+_mesa_update_texture_state(struct gl_context *ctx);

 extern GLboolean
 _mesa_init_texture( struct gl_context *ctx );

 extern void
 _mesa_free_texture_data( struct gl_context *ctx );

 extern void
 _mesa_update_default_objects_texture(struct gl_context 

Re: [Mesa-dev] [PATCH 1/3] radeonsi: don't hang on shader compile failure

[Samuel Pitoiset]

Patches 1 & 2 are:

Reviewed-by: Samuel Pitoiset 

No clue about about 3.

On 03/24/2017 01:00 AM, Marek Olšák wrote:

From: Marek Olšák 

Cc: 17.0 
---
 src/gallium/drivers/radeonsi/si_state_shaders.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c 
b/src/gallium/drivers/radeonsi/si_state_shaders.c
index 30856b0..e1286b8 100644
--- a/src/gallium/drivers/radeonsi/si_state_shaders.c
+++ b/src/gallium/drivers/radeonsi/si_state_shaders.c
@@ -1239,21 +1239,21 @@ static int si_shader_select_with_key(struct si_screen 
*sscreen,

 again:
/* Check if we don't need to change anything.
 * This path is also used for most shaders that don't need multiple
 * variants, it will cost just a computation of the key and this
 * test. */
if (likely(current &&
   memcmp(>key, key, sizeof(*key)) == 0 &&
   (!current->is_optimized ||
util_queue_fence_is_signalled(>optimized_ready
-   return 0;
+   return current->compilation_failed ? -1 : 0;

/* This must be done before the mutex is locked, because async GS
 * compilation calls this function too, and therefore must enter
 * the mutex first.
 *
 * Only wait if we are in a draw call. Don't wait if we are
 * in a compiler thread.
 */
if (thread_index < 0)
util_queue_fence_wait(>ready);


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

Re: [Mesa-dev] [PATCH 1/6] mesa: inline _mesa_update_texture

[Edward O'Callaghan]

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

On 03/24/2017 10:42 AM, Marek Olšák wrote:
> From: Marek Olšák 
> 
> ---
>  src/mesa/main/state.c|  7 +--
>  src/mesa/main/texstate.c | 22 --
>  src/mesa/main/texstate.h |  7 +--
>  3 files changed, 14 insertions(+), 22 deletions(-)
> 
> diff --git a/src/mesa/main/state.c b/src/mesa/main/state.c
> index 5cb58a4..71265a5 100644
> --- a/src/mesa/main/state.c
> +++ b/src/mesa/main/state.c
> @@ -399,22 +399,25 @@ _mesa_update_state_locked( struct gl_context *ctx )
> /*
>  * Now update derived state info
>  */
>  
> if (new_state & prog_flags)
>update_program_enables( ctx );
>  
> if (new_state & (_NEW_MODELVIEW|_NEW_PROJECTION))
>_mesa_update_modelview_project( ctx, new_state );
>  
> -   if (new_state & (_NEW_PROGRAM|_NEW_TEXTURE|_NEW_TEXTURE_MATRIX))
> -  _mesa_update_texture( ctx, new_state );
> +   if (new_state & _NEW_TEXTURE_MATRIX)
> +  _mesa_update_texture_matrices(ctx);
> +
> +   if (new_state & (_NEW_TEXTURE | _NEW_PROGRAM))
> +  _mesa_update_texture_state(ctx);
>  
> if (new_state & _NEW_POLYGON)
>update_frontbit( ctx );
>  
> if (new_state & _NEW_BUFFERS)
>_mesa_update_framebuffer(ctx, ctx->ReadBuffer, ctx->DrawBuffer);
>  
> if (new_state & (_NEW_SCISSOR | _NEW_BUFFERS | _NEW_VIEWPORT))
>_mesa_update_draw_buffer_bounds(ctx, ctx->DrawBuffer);
>  
> diff --git a/src/mesa/main/texstate.c b/src/mesa/main/texstate.c
> index be73fc3..70e014c 100644
> --- a/src/mesa/main/texstate.c
> +++ b/src/mesa/main/texstate.c
> @@ -348,22 +348,22 @@ _mesa_ClientActiveTexture(GLenum texture)
>  
>  
>  /**
>   * \note This routine refers to derived texture attribute values to
>   * compute the ENABLE_TEXMAT flags, but is only called on
>   * _NEW_TEXTURE_MATRIX.  On changes to _NEW_TEXTURE, the ENABLE_TEXMAT
>   * flags are updated by _mesa_update_textures(), below.
>   *
>   * \param ctx GL context.
>   */
> -static void
> -update_texture_matrices( struct gl_context *ctx )
> +void
> +_mesa_update_texture_matrices(struct gl_context *ctx)
>  {
> GLuint u;
>  
> ctx->Texture._TexMatEnabled = 0x0;
>  
> for (u = 0; u < ctx->Const.MaxTextureCoordUnits; u++) {
>assert(u < ARRAY_SIZE(ctx->TextureMatrixStack));
>if (_math_matrix_is_dirty(ctx->TextureMatrixStack[u].Top)) {
>_math_matrix_analyse( ctx->TextureMatrixStack[u].Top );
>  
> @@ -684,22 +684,22 @@ update_ff_texture_state(struct gl_context *ctx,
>  }
>  
>  /**
>   * \note This routine refers to derived texture matrix values to
>   * compute the ENABLE_TEXMAT flags, but is only called on
>   * _NEW_TEXTURE.  On changes to _NEW_TEXTURE_MATRIX, the ENABLE_TEXMAT
>   * flags are updated by _mesa_update_texture_matrices, above.
>   *
>   * \param ctx GL context.
>   */
> -static void
> -update_texture_state( struct gl_context *ctx )
> +void
> +_mesa_update_texture_state(struct gl_context *ctx)
>  {
> struct gl_program *prog[MESA_SHADER_STAGES];
> int i;
> int old_max_unit = ctx->Texture._MaxEnabledTexImageUnit;
> BITSET_DECLARE(enabled_texture_units, MAX_COMBINED_TEXTURE_IMAGE_UNITS);
>  
> for (i = 0; i < MESA_SHADER_STAGES; i++) {
>if (ctx->_Shader->CurrentProgram[i]) {
>   prog[i] = ctx->_Shader->CurrentProgram[i];
>} else {
> @@ -740,34 +740,20 @@ update_texture_state( struct gl_context *ctx )
> }
> for (i = ctx->Texture._MaxEnabledTexImageUnit + 1; i <= old_max_unit; 
> i++) {
>_mesa_reference_texobj(>Texture.Unit[i]._Current, NULL);
> }
>  
> if (!prog[MESA_SHADER_FRAGMENT] || !prog[MESA_SHADER_VERTEX])
>update_texgen(ctx);
>  }
>  
>  
> -/**
> - * Update texture-related derived state.
> - */
> -void
> -_mesa_update_texture( struct gl_context *ctx, GLuint new_state )
> -{
> -   if (new_state & _NEW_TEXTURE_MATRIX)
> -  update_texture_matrices( ctx );
> -
> -   if (new_state & (_NEW_TEXTURE | _NEW_PROGRAM))
> -  update_texture_state( ctx );
> -}
> -
> -
>  /**/
>  /*  Initialization*/
>  /**/
>  
>  /**
>   * Allocate the proxy textures for the given context.
>   *
>   * \param ctx the context to allocate proxies for.
>   *
>   * \return GL_TRUE on success, or GL_FALSE on failure
> diff --git a/src/mesa/main/texstate.h b/src/mesa/main/texstate.h
> index 52fe602..cb329b0 100644
> --- a/src/mesa/main/texstate.h
> +++ b/src/mesa/main/texstate.h
> @@ -84,22 +84,25 @@ extern void GLAPIENTRY
>  _mesa_ClientActiveTexture( GLenum target );
>  
>  /*@}*/
>  
>  
>  /**
>   * \name Initialization, state maintenance
>   */
>  /*@{*/
>  
> -extern void 
> -_mesa_update_texture( struct gl_context *ctx, GLuint new_state );
> +extern void
> 

[Mesa-dev] [PATCH 3/3] targets/va: export radeon winsys_create functions

[Marek Olšák]

From: Marek Olšák 

This should fix this radeonsi error:
  "mesa: for the -simplifycfg-sink-common option: may only occur zero or one
   times!"
---
 src/gallium/targets/va/va.sym | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/gallium/targets/va/va.sym b/src/gallium/targets/va/va.sym
index c925b2e..b19bc36 100644
--- a/src/gallium/targets/va/va.sym
+++ b/src/gallium/targets/va/va.sym
@@ -1,6 +1,8 @@
 {
global:
__vaDriverInit_*_*;
+   radeon_drm_winsys_create;
+   amdgpu_winsys_create;
local:
*;
 };
-- 
2.7.4

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

[Mesa-dev] [PATCH 1/3] radeonsi: don't hang on shader compile failure

[Marek Olšák]

From: Marek Olšák 

Cc: 17.0 
---
 src/gallium/drivers/radeonsi/si_state_shaders.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c 
b/src/gallium/drivers/radeonsi/si_state_shaders.c
index 30856b0..e1286b8 100644
--- a/src/gallium/drivers/radeonsi/si_state_shaders.c
+++ b/src/gallium/drivers/radeonsi/si_state_shaders.c
@@ -1239,21 +1239,21 @@ static int si_shader_select_with_key(struct si_screen 
*sscreen,
 
 again:
/* Check if we don't need to change anything.
 * This path is also used for most shaders that don't need multiple
 * variants, it will cost just a computation of the key and this
 * test. */
if (likely(current &&
   memcmp(>key, key, sizeof(*key)) == 0 &&
   (!current->is_optimized ||
util_queue_fence_is_signalled(>optimized_ready
-   return 0;
+   return current->compilation_failed ? -1 : 0;
 
/* This must be done before the mutex is locked, because async GS
 * compilation calls this function too, and therefore must enter
 * the mutex first.
 *
 * Only wait if we are in a draw call. Don't wait if we are
 * in a compiler thread.
 */
if (thread_index < 0)
util_queue_fence_wait(>ready);
-- 
2.7.4

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

[Mesa-dev] [PATCH 2/3] radeonsi: don't crash on compute shader compiler failure

[Marek Olšák]

From: Marek Olšák 

---
 src/gallium/drivers/radeonsi/si_compute.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_compute.c 
b/src/gallium/drivers/radeonsi/si_compute.c
index 19a9189..46476b6 100644
--- a/src/gallium/drivers/radeonsi/si_compute.c
+++ b/src/gallium/drivers/radeonsi/si_compute.c
@@ -739,23 +739,27 @@ static void si_launch_grid(
bool cs_regalloc_hang =
(sctx->b.chip_class == SI ||
 sctx->b.family == CHIP_BONAIRE ||
 sctx->b.family == CHIP_KABINI) &&
info->block[0] * info->block[1] * info->block[2] > 256;
 
if (cs_regalloc_hang)
sctx->b.flags |= SI_CONTEXT_PS_PARTIAL_FLUSH |
 SI_CONTEXT_CS_PARTIAL_FLUSH;
 
-   if (program->ir_type == PIPE_SHADER_IR_TGSI)
+   if (program->ir_type == PIPE_SHADER_IR_TGSI) {
util_queue_fence_wait(>ready);
 
+   if (program->shader.compilation_failed)
+   return;
+   }
+
si_decompress_compute_textures(sctx);
 
/* Add buffer sizes for memory checking in need_cs_space. */
r600_context_add_resource_size(ctx, >shader.bo->b.b);
/* TODO: add the scratch buffer */
 
if (info->indirect) {
r600_context_add_resource_size(ctx, info->indirect);
 
/* The hw doesn't read the indirect buffer via TC L2. */
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH] radeonsi: disable sinking common instructions down to the end block

[Marek Olšák]

I'll send a fix.

Marek

On Thu, Mar 23, 2017 at 12:38 PM, Nicolai Hähnle  wrote:
> On 22.03.2017 21:00, Andy Furniss wrote:
>>
>> Samuel Pitoiset wrote:
>>
>> This patch has a minor issue for me using radeonsi on tonga.
>>
>> ffmpeg vaapi hwdecode by cli or via mpv now produces the message
>>
>> mesa: for the -simplifycfg-sink-common option: may only occur zero or
>> one times!
>
>
> I guess that setup ends up loading both radeonsi_dri.so and
> radeonsi_drv_video.so, and so the command line is set twice despite the use
> of a once_flag. Any ideas?
>
> Cheers,
> Nicolai
>
>
>>
>>>
>>> On 03/15/2017 02:01 PM, Marek Olšák wrote:

 On Wed, Mar 15, 2017 at 1:56 PM, Samuel Pitoiset
  wrote:
>
>
>
> On 03/15/2017 01:51 PM, Marek Olšák wrote:
>>
>>
>> On Wed, Mar 15, 2017 at 1:21 AM, Samuel Pitoiset
>>  wrote:
>>>
>>>
>>> Initially this was a workaround for a bug introduced in LLVM 4.0
>>> in the SimplifyCFG pass that caused image instrinsics to disappear
>>> (because they were badly sunk). Finally, this is a win because it
>>> decreases SGPR spilling and increases the number of waves a bit.
>>>
>>> Although, shader-db results are good I think we might want to
>>> remove it in the future once the issue is fixed. For now, enable
>>> it for LLVM >= 4.0.
>>>
>>> This also fixes a rendering issue with the speedometer in Dirt Rally.
>>>
>>> More information can be found here https://reviews.llvm.org/D26348.
>>>
>>> Thanks to Dave Airlie for the patch.
>>>
>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99484
>>> Signed-off-by: Samuel Pitoiset 
>>> ---
>>>
>>> For those interested, here's the full shader-db report:
>>>
>>> https://hastebin.com/osepehehat.pas
>>>
>>>  src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c | 6 ++
>>>  1 file changed, 6 insertions(+)
>>>
>>> diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c
>>> b/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c
>>> index 5c63b732b3..4fb7a126e4 100644
>>> --- a/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c
>>> +++ b/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c
>>> @@ -40,6 +40,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>
>>>  /* Data for if/else/endif and bgnloop/endloop control flow
>>> structures.
>>>   */
>>> @@ -124,6 +125,11 @@ static void init_amdgpu_target()
>>> LLVMInitializeAMDGPUTarget();
>>> LLVMInitializeAMDGPUTargetMC();
>>> LLVMInitializeAMDGPUAsmPrinter();
>>> +
>>> +#if HAVE_LLVM >= 0x0400
>>> +   const char *argv[2] = {"mesa",
>>> "-simplifycfg-sink-common=false"};
>>> +   LLVMParseCommandLineOptions(2, argv, NULL);
>>> +#endif
>>
>>
>>
>> Would it possible to do:
>> if (HAVE_LLVM >= 0x0400) {
>> ...
>> }
>>
>> Also, Cc stable?
>
>
>
> Your call. But if the issue is fixed at some point in 4.0.1 or 5.0 we
> will
> need to backport one more patch.


 Since this only disables the problematic optimization, we can keep it
 in stable and we won't have to backport anything else. (optimizations
 are usually not accepted in stable)
>>>
>>>
>>> Fine by me. I will add the cc tag and the FIXME comment before pushing.
>>> Thanks.
>>>

 Marek

>>> ___
>>> 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
>
>
>
> --
> Lerne, wie die Welt wirklich ist,
> Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Quoting Colin Cross (2017-03-23 15:14:16)
> On Thu, Mar 23, 2017 at 2:56 PM, Greg Hackmann  wrote:
> > On 03/22/2017 02:48 PM, Rob Clark wrote:
> >>
> >> On Wed, Mar 22, 2017 at 4:10 PM, Dylan Baker  wrote:
> >>>
> >>> Quoting Rob Clark (2017-03-22 10:07:54)
> 
>  I guess an interesting question (from someone who doesn't know meson
>  yet) would be whether meson could slurp in the Makefile.sources type
>  stuff that we have, which are shared so far between
>  android/scons/autotools (and for the most part, kept developers from
>  having to care *too* much about the different build systems)
> >>>
> >>>
> >>> Jason and I have talked about that too. I'd suggested that we could write
> >>> a
> >>> module for meson to read makefile.sources (since we're surely not the
> >>> only
> >>> project that would benefit from such a module), except that android is
> >>> moving to
> >>> blueprint[1] instead of android.mk files. As far as I can tell blueprint
> >>> doesn't
> >>> support using makefile.sources, so it seems somewhat moot in a world of
> >>> blueprint for android, meson for *.
> >>
> >>
> >> I guess even if it is only a temporary thing, something that could
> >> slurp in Makefile.sources seems like it would be useful for a
> >> transition period.
> >>
> >> I'm not totally up to speed on android/blueprint stuff.. but even some
> >> simplified or different "here-are-my-sources" type file that could be
> >> shared across build systems would be useful.  Meson sounds a bit more
> >> extensible so maybe there is some potential to adapt to whatever
> >> android forces on us ;-)
> >
> >
> > +ccross from the Android build team can hopefully provide some input here.
> 
> For cases like this, we generally add a python script that translates
> the build files into something Blueprint understands, and rerun it
> each time we import into the project.
> 
> Alternatively, Blueprint efficiently supports globbing for sources, so
> if all the source files are always listed in Makefile.sources (which
> seems to be true in our copy of libdrm except for intel/test_decode.c)
> then we could use globs and ignore the makefiles, possibly manually
> excluding a few files.

I'm hoping you can clarify a couple of questions I have about blueprint:
1) android is moving to blueprint from android.mk files?
2) is there a publicly available project that uses blueprint I could look at?
   The documentation I've been able to find is pretty sparse.

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] cso: store sampler views for all shader stages

[Samuel Pitoiset]

On 03/23/2017 08:53 PM, Marek Olšák wrote:

NAK.

I wouldn't like more overhead in cso_context when better solutions are
available. There are several ways of dealing with texture update
overhead:

1) Split _NEW_TEXTURE into multiple flags, each covering a disjoint
set of states smaller than _NEW_TEXTURE.

2) Use a stage-specific flag (e.g. _NEW_VS_TEXTURE) instead of
_NEW_TEXTURE. glBindTexture can look at current shaders to know where
the texture is being used.

3) Threaded Gallium dispatch:
https://cgit.freedesktop.org/~mareko/mesa/log/?h=gallium-threaded
(missing: DISCARD_RANGE, deferred fences, bug fixes)

4) glthread


Okay, no worries about that patch because 1) and 2) look better to me, 
thanks for the pointers.


I will provide some benchmarks for that patch just for curiosity. But 
yeah, it seems like we can do a better thing in that codepath without 
adding overhead in cso.




Marek



On Thu, Mar 23, 2017 at 7:44 PM, Samuel Pitoiset
 wrote:

Sampler views were only cached for the fragment shader stage, but
this might help other stages.

This is a small opt which should help civ6 a little bit.

Signed-off-by: Samuel Pitoiset 
---
 src/gallium/auxiliary/cso_cache/cso_context.c | 101 ++
 1 file changed, 55 insertions(+), 46 deletions(-)

diff --git a/src/gallium/auxiliary/cso_cache/cso_context.c 
b/src/gallium/auxiliary/cso_cache/cso_context.c
index 3d3c44cf81..cac1b4e8a5 100644
--- a/src/gallium/auxiliary/cso_cache/cso_context.c
+++ b/src/gallium/auxiliary/cso_cache/cso_context.c
@@ -61,6 +61,14 @@ struct sampler_info
 };


+/**
+ * Per-shader sampler view information.
+ */
+struct view_info {
+   struct pipe_sampler_view *views[PIPE_MAX_SHADER_SAMPLER_VIEWS];
+   unsigned nr_views;
+};
+

 struct cso_context {
struct pipe_context *pipe;
@@ -74,11 +82,8 @@ struct cso_context {

unsigned saved_state;  /**< bitmask of CSO_BIT_x flags */

-   struct pipe_sampler_view *fragment_views[PIPE_MAX_SHADER_SAMPLER_VIEWS];
-   unsigned nr_fragment_views;
-
-   struct pipe_sampler_view 
*fragment_views_saved[PIPE_MAX_SHADER_SAMPLER_VIEWS];
-   unsigned nr_fragment_views_saved;
+   struct view_info fragment_views_saved;
+   struct view_info views[PIPE_SHADER_TYPES];

struct sampler_info fragment_samplers_saved;
struct sampler_info samplers[PIPE_SHADER_TYPES];
@@ -346,7 +351,7 @@ out:
  */
 void cso_destroy_context( struct cso_context *ctx )
 {
-   unsigned i;
+   unsigned i, j;

if (ctx->pipe) {
   ctx->pipe->set_index_buffer(ctx->pipe, NULL);
@@ -400,9 +405,14 @@ void cso_destroy_context( struct cso_context *ctx )
  ctx->pipe->set_stream_output_targets(ctx->pipe, 0, NULL, NULL);
}

+   for (i = 0; i < PIPE_SHADER_TYPES; i++) {
+  for (j = 0; j < PIPE_MAX_SHADER_SAMPLER_VIEWS; j++) {
+ pipe_sampler_view_reference(>views[i].views[j], NULL);
+  }
+   }
+
for (i = 0; i < PIPE_MAX_SHADER_SAMPLER_VIEWS; i++) {
-  pipe_sampler_view_reference(>fragment_views[i], NULL);
-  pipe_sampler_view_reference(>fragment_views_saved[i], NULL);
+  pipe_sampler_view_reference(>fragment_views_saved.views[i], NULL);
}

util_unreference_framebuffer_state(>fb);
@@ -1348,46 +1358,43 @@ cso_set_sampler_views(struct cso_context *ctx,
   unsigned count,
   struct pipe_sampler_view **views)
 {
-   if (shader_stage == PIPE_SHADER_FRAGMENT) {
-  unsigned i;
-  boolean any_change = FALSE;
-
-  /* reference new views */
-  for (i = 0; i < count; i++) {
- any_change |= ctx->fragment_views[i] != views[i];
- pipe_sampler_view_reference(>fragment_views[i], views[i]);
-  }
-  /* unref extra old views, if any */
-  for (; i < ctx->nr_fragment_views; i++) {
- any_change |= ctx->fragment_views[i] != NULL;
- pipe_sampler_view_reference(>fragment_views[i], NULL);
-  }
+   struct view_info *info = >views[shader_stage];
+   boolean any_change = FALSE;
+   unsigned i;

-  /* bind the new sampler views */
-  if (any_change) {
- ctx->pipe->set_sampler_views(ctx->pipe, shader_stage, 0,
-  MAX2(ctx->nr_fragment_views, count),
-  ctx->fragment_views);
-  }
+   /* reference new views */
+   for (i = 0; i < count; i++) {
+  any_change |= info->views[i] != views[i];
+  pipe_sampler_view_reference(>views[i], views[i]);
+   }
+   /* unref extra old views, if any */
+   for (; i < info->nr_views; i++) {
+  any_change |= info->views[i] != NULL;
+  pipe_sampler_view_reference(>views[i], NULL);
+   }

-  ctx->nr_fragment_views = count;
+   /* bind the new sampler views */
+   if (any_change) {
+  ctx->pipe->set_sampler_views(ctx->pipe, shader_stage, 0,
+   MAX2(info->nr_views, count), info->views);
}
-   else
-  ctx->pipe->set_sampler_views(ctx->pipe, 

[Mesa-dev] [PATCH 1/6] mesa: inline _mesa_update_texture

[Marek Olšák]

From: Marek Olšák 

---
 src/mesa/main/state.c|  7 +--
 src/mesa/main/texstate.c | 22 --
 src/mesa/main/texstate.h |  7 +--
 3 files changed, 14 insertions(+), 22 deletions(-)

diff --git a/src/mesa/main/state.c b/src/mesa/main/state.c
index 5cb58a4..71265a5 100644
--- a/src/mesa/main/state.c
+++ b/src/mesa/main/state.c
@@ -399,22 +399,25 @@ _mesa_update_state_locked( struct gl_context *ctx )
/*
 * Now update derived state info
 */
 
if (new_state & prog_flags)
   update_program_enables( ctx );
 
if (new_state & (_NEW_MODELVIEW|_NEW_PROJECTION))
   _mesa_update_modelview_project( ctx, new_state );
 
-   if (new_state & (_NEW_PROGRAM|_NEW_TEXTURE|_NEW_TEXTURE_MATRIX))
-  _mesa_update_texture( ctx, new_state );
+   if (new_state & _NEW_TEXTURE_MATRIX)
+  _mesa_update_texture_matrices(ctx);
+
+   if (new_state & (_NEW_TEXTURE | _NEW_PROGRAM))
+  _mesa_update_texture_state(ctx);
 
if (new_state & _NEW_POLYGON)
   update_frontbit( ctx );
 
if (new_state & _NEW_BUFFERS)
   _mesa_update_framebuffer(ctx, ctx->ReadBuffer, ctx->DrawBuffer);
 
if (new_state & (_NEW_SCISSOR | _NEW_BUFFERS | _NEW_VIEWPORT))
   _mesa_update_draw_buffer_bounds(ctx, ctx->DrawBuffer);
 
diff --git a/src/mesa/main/texstate.c b/src/mesa/main/texstate.c
index be73fc3..70e014c 100644
--- a/src/mesa/main/texstate.c
+++ b/src/mesa/main/texstate.c
@@ -348,22 +348,22 @@ _mesa_ClientActiveTexture(GLenum texture)
 
 
 /**
  * \note This routine refers to derived texture attribute values to
  * compute the ENABLE_TEXMAT flags, but is only called on
  * _NEW_TEXTURE_MATRIX.  On changes to _NEW_TEXTURE, the ENABLE_TEXMAT
  * flags are updated by _mesa_update_textures(), below.
  *
  * \param ctx GL context.
  */
-static void
-update_texture_matrices( struct gl_context *ctx )
+void
+_mesa_update_texture_matrices(struct gl_context *ctx)
 {
GLuint u;
 
ctx->Texture._TexMatEnabled = 0x0;
 
for (u = 0; u < ctx->Const.MaxTextureCoordUnits; u++) {
   assert(u < ARRAY_SIZE(ctx->TextureMatrixStack));
   if (_math_matrix_is_dirty(ctx->TextureMatrixStack[u].Top)) {
 _math_matrix_analyse( ctx->TextureMatrixStack[u].Top );
 
@@ -684,22 +684,22 @@ update_ff_texture_state(struct gl_context *ctx,
 }
 
 /**
  * \note This routine refers to derived texture matrix values to
  * compute the ENABLE_TEXMAT flags, but is only called on
  * _NEW_TEXTURE.  On changes to _NEW_TEXTURE_MATRIX, the ENABLE_TEXMAT
  * flags are updated by _mesa_update_texture_matrices, above.
  *
  * \param ctx GL context.
  */
-static void
-update_texture_state( struct gl_context *ctx )
+void
+_mesa_update_texture_state(struct gl_context *ctx)
 {
struct gl_program *prog[MESA_SHADER_STAGES];
int i;
int old_max_unit = ctx->Texture._MaxEnabledTexImageUnit;
BITSET_DECLARE(enabled_texture_units, MAX_COMBINED_TEXTURE_IMAGE_UNITS);
 
for (i = 0; i < MESA_SHADER_STAGES; i++) {
   if (ctx->_Shader->CurrentProgram[i]) {
  prog[i] = ctx->_Shader->CurrentProgram[i];
   } else {
@@ -740,34 +740,20 @@ update_texture_state( struct gl_context *ctx )
}
for (i = ctx->Texture._MaxEnabledTexImageUnit + 1; i <= old_max_unit; i++) {
   _mesa_reference_texobj(>Texture.Unit[i]._Current, NULL);
}
 
if (!prog[MESA_SHADER_FRAGMENT] || !prog[MESA_SHADER_VERTEX])
   update_texgen(ctx);
 }
 
 
-/**
- * Update texture-related derived state.
- */
-void
-_mesa_update_texture( struct gl_context *ctx, GLuint new_state )
-{
-   if (new_state & _NEW_TEXTURE_MATRIX)
-  update_texture_matrices( ctx );
-
-   if (new_state & (_NEW_TEXTURE | _NEW_PROGRAM))
-  update_texture_state( ctx );
-}
-
-
 /**/
 /*  Initialization*/
 /**/
 
 /**
  * Allocate the proxy textures for the given context.
  *
  * \param ctx the context to allocate proxies for.
  *
  * \return GL_TRUE on success, or GL_FALSE on failure
diff --git a/src/mesa/main/texstate.h b/src/mesa/main/texstate.h
index 52fe602..cb329b0 100644
--- a/src/mesa/main/texstate.h
+++ b/src/mesa/main/texstate.h
@@ -84,22 +84,25 @@ extern void GLAPIENTRY
 _mesa_ClientActiveTexture( GLenum target );
 
 /*@}*/
 
 
 /**
  * \name Initialization, state maintenance
  */
 /*@{*/
 
-extern void 
-_mesa_update_texture( struct gl_context *ctx, GLuint new_state );
+extern void
+_mesa_update_texture_matrices(struct gl_context *ctx);
+
+extern void
+_mesa_update_texture_state(struct gl_context *ctx);
 
 extern GLboolean
 _mesa_init_texture( struct gl_context *ctx );
 
 extern void 
 _mesa_free_texture_data( struct gl_context *ctx );
 
 extern void
 _mesa_update_default_objects_texture(struct gl_context *ctx);
 
-- 
2.7.4

___
mesa-dev mailing list

[Mesa-dev] [PATCH 5/6] r200: remove BindProgram

[Marek Olšák]

From: Marek Olšák 

---
 src/mesa/drivers/dri/r200/r200_state.c|  5 +
 src/mesa/drivers/dri/r200/r200_vertprog.c | 16 
 2 files changed, 5 insertions(+), 16 deletions(-)

diff --git a/src/mesa/drivers/dri/r200/r200_state.c 
b/src/mesa/drivers/dri/r200/r200_state.c
index 4a248d2..86733a8 100644
--- a/src/mesa/drivers/dri/r200/r200_state.c
+++ b/src/mesa/drivers/dri/r200/r200_state.c
@@ -2272,26 +2272,31 @@ GLboolean r200ValidateState( struct gl_context *ctx )
   else TCL_FALLBACK(ctx, R200_TCL_FALLBACK_VERTEX_PROGRAM, 0);
}
 
rmesa->radeon.NewGLState = 0;
return GL_TRUE;
 }
 
 
 static void r200InvalidateState( struct gl_context *ctx, GLuint new_state )
 {
+   r200ContextPtr rmesa = R200_CONTEXT(ctx);
+
_swrast_InvalidateState( ctx, new_state );
_swsetup_InvalidateState( ctx, new_state );
_vbo_InvalidateState( ctx, new_state );
_tnl_InvalidateState( ctx, new_state );
_ae_invalidate_state( ctx, new_state );
R200_CONTEXT(ctx)->radeon.NewGLState |= new_state;
+
+   if (new_state & _NEW_PROGRAM)
+  rmesa->curr_vp_hw = NULL;
 }
 
 /* A hack.  The r200 can actually cope just fine with materials
  * between begin/ends, so fix this.
  * Should map to inputs just like the generic vertex arrays for vertex progs.
  * In theory there could still be too many and we'd still need a fallback.
  */
 static GLboolean check_material( struct gl_context *ctx )
 {
TNLcontext *tnl = TNL_CONTEXT(ctx);
diff --git a/src/mesa/drivers/dri/r200/r200_vertprog.c 
b/src/mesa/drivers/dri/r200/r200_vertprog.c
index 0a3e984..100b715 100644
--- a/src/mesa/drivers/dri/r200/r200_vertprog.c
+++ b/src/mesa/drivers/dri/r200/r200_vertprog.c
@@ -1176,35 +1176,20 @@ void r200SetupVertexProg( struct gl_context *ctx ) {
 rmesa->hw.vpi[1].cmd_size = 1 + 4 * (count - 64);
 tmp.i = rmesa->hw.vpi[1].cmd[VPI_CMD_0];
 tmp.veclinear.count = count - 64;
 rmesa->hw.vpi[1].cmd[VPI_CMD_0] = tmp.i;
   }
   rmesa->curr_vp_hw = vp;
}
 }
 
 
-static void
-r200BindProgram(struct gl_context *ctx, GLenum target, struct gl_program *prog)
-{
-   r200ContextPtr rmesa = R200_CONTEXT(ctx);
-
-   switch(target){
-   case GL_VERTEX_PROGRAM_ARB:
-  rmesa->curr_vp_hw = NULL;
-  break;
-   default:
-  _mesa_problem(ctx, "Target not supported yet!");
-  break;
-   }
-}
-
 static struct gl_program *
 r200NewProgram(struct gl_context *ctx, GLenum target, GLuint id,
bool is_arb_asm)
 {
switch(target){
case GL_VERTEX_PROGRAM_ARB: {
   struct r200_vertex_program *vp = rzalloc(NULL,
struct r200_vertex_program);
   return _mesa_init_gl_program(>mesa_program, target, id, is_arb_asm);
}
@@ -1264,15 +1249,14 @@ r200IsProgramNative(struct gl_context *ctx, GLenum 
target, struct gl_program *pr
   return vp->native;
default:
   _mesa_problem(ctx, "Bad target in r200NewProgram");
}
return 0;
 }
 
 void r200InitShaderFuncs(struct dd_function_table *functions)
 {
functions->NewProgram = r200NewProgram;
-   functions->BindProgram = r200BindProgram;
functions->DeleteProgram = r200DeleteProgram;
functions->ProgramStringNotify = r200ProgramStringNotify;
functions->IsProgramNative = r200IsProgramNative;
 }
-- 
2.7.4

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

[Mesa-dev] [PATCH 6/6] mesa: remove dd_function_table::BindProgram

[Marek Olšák]

From: Marek Olšák 

---
 src/mesa/drivers/common/driverfuncs.c |  1 -
 src/mesa/main/arbprogram.c|  3 --
 src/mesa/main/atifragshader.c |  3 --
 src/mesa/main/dd.h|  3 --
 src/mesa/main/state.c | 55 +--
 src/mesa/tnl/t_vp_build.c |  8 -
 6 files changed, 7 insertions(+), 66 deletions(-)

diff --git a/src/mesa/drivers/common/driverfuncs.c 
b/src/mesa/drivers/common/driverfuncs.c
index 642cd91..db0a107 100644
--- a/src/mesa/drivers/common/driverfuncs.c
+++ b/src/mesa/drivers/common/driverfuncs.c
@@ -106,21 +106,20 @@ _mesa_init_driver_functions(struct dd_function_table 
*driver)
driver->DeleteTexture = _mesa_delete_texture_object;
driver->NewTextureImage = _swrast_new_texture_image;
driver->DeleteTextureImage = _swrast_delete_texture_image;
driver->AllocTextureImageBuffer = _swrast_alloc_texture_image_buffer;
driver->FreeTextureImageBuffer = _swrast_free_texture_image_buffer;
driver->MapTextureImage = _swrast_map_teximage;
driver->UnmapTextureImage = _swrast_unmap_teximage;
driver->DrawTex = _mesa_meta_DrawTex;
 
/* Vertex/fragment programs */
-   driver->BindProgram = NULL;
driver->NewProgram = _mesa_new_program;
driver->DeleteProgram = _mesa_delete_program;
 
/* ATI_fragment_shader */
driver->NewATIfs = NULL;
 
/* simple state commands */
driver->AlphaFunc = NULL;
driver->BlendColor = NULL;
driver->BlendEquationSeparate = NULL;
diff --git a/src/mesa/main/arbprogram.c b/src/mesa/main/arbprogram.c
index 2c60310..f3a0a54c 100644
--- a/src/mesa/main/arbprogram.c
+++ b/src/mesa/main/arbprogram.c
@@ -111,23 +111,20 @@ _mesa_BindProgramARB(GLenum target, GLuint id)
if (target == GL_VERTEX_PROGRAM_ARB) {
   _mesa_reference_program(ctx, >VertexProgram.Current, newProg);
}
else if (target == GL_FRAGMENT_PROGRAM_ARB) {
   _mesa_reference_program(ctx, >FragmentProgram.Current, newProg);
}
 
/* Never null pointers */
assert(ctx->VertexProgram.Current);
assert(ctx->FragmentProgram.Current);
-
-   if (ctx->Driver.BindProgram)
-  ctx->Driver.BindProgram(ctx, target, newProg);
 }
 
 
 /**
  * Delete a list of programs.
  * \note Not compiled into display lists.
  * \note Called by both glDeleteProgramsNV and glDeleteProgramsARB.
  */
 void GLAPIENTRY 
 _mesa_DeleteProgramsARB(GLsizei n, const GLuint *ids)
diff --git a/src/mesa/main/atifragshader.c b/src/mesa/main/atifragshader.c
index 83a449a..27d8b86 100644
--- a/src/mesa/main/atifragshader.c
+++ b/src/mesa/main/atifragshader.c
@@ -257,23 +257,20 @@ _mesa_BindFragmentShaderATI(GLuint id)
   }
 
}
 
/* do actual bind */
ctx->ATIFragmentShader.Current = newProg;
 
assert(ctx->ATIFragmentShader.Current);
if (newProg)
   newProg->RefCount++;
-
-   /*if (ctx->Driver.BindProgram)
-  ctx->Driver.BindProgram(ctx, target, prog); */
 }
 
 void GLAPIENTRY
 _mesa_DeleteFragmentShaderATI(GLuint id)
 {
GET_CURRENT_CONTEXT(ctx);
 
if (ctx->ATIFragmentShader.Compiling) {
   _mesa_error(ctx, GL_INVALID_OPERATION, 
"glDeleteFragmentShaderATI(insideShader)");
   return;
diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
index f300ad6..b3a85f1 100644
--- a/src/mesa/main/dd.h
+++ b/src/mesa/main/dd.h
@@ -462,23 +462,20 @@ struct dd_function_table {
GLboolean (*BindRenderbufferTexImage)(struct gl_context *ctx,
  struct gl_renderbuffer *rb,
  struct gl_texture_image *texImage);
/*@}*/
 
 
/**
 * \name Vertex/fragment program functions
 */
/*@{*/
-   /** Bind a vertex/fragment program */
-   void (*BindProgram)(struct gl_context *ctx, GLenum target,
-   struct gl_program *prog);
/** Allocate a new program */
struct gl_program * (*NewProgram)(struct gl_context *ctx, GLenum target,
  GLuint id, bool is_arb_asm);
/** Delete a program */
void (*DeleteProgram)(struct gl_context *ctx, struct gl_program *prog);   
/**
 * Allocate a program to associate with the new ATI fragment shader 
(optional)
 */
struct gl_program * (*NewATIfs)(struct gl_context *ctx,
struct ati_fragment_shader *curProg);
diff --git a/src/mesa/main/state.c b/src/mesa/main/state.c
index 07629d8..5a760f5 100644
--- a/src/mesa/main/state.c
+++ b/src/mesa/main/state.c
@@ -73,22 +73,21 @@ update_program_enables(struct gl_context *ctx)
   && ctx->VertexProgram.Current->arb.Instructions;
ctx->FragmentProgram._Enabled = ctx->FragmentProgram.Enabled
   && ctx->FragmentProgram.Current->arb.Instructions;
ctx->ATIFragmentShader._Enabled = ctx->ATIFragmentShader.Enabled
   && ctx->ATIFragmentShader.Current->Instructions[0];
 }
 
 
 /**
  * Update the ctx->*Program._Current pointers to point to the
- * current/active 

[Mesa-dev] [PATCH 3/6] mesa: don't use _NEW_TEXTURE mainly in mesa/main

[Marek Olšák]

From: Marek Olšák 

---
 src/mesa/drivers/dri/i965/brw_state_upload.c |  3 ++-
 src/mesa/main/attrib.c   |  2 +-
 src/mesa/main/debug.c|  3 ++-
 src/mesa/main/state.c| 10 +-
 src/mesa/main/texstate.c | 11 ++-
 5 files changed, 16 insertions(+), 13 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_state_upload.c 
b/src/mesa/drivers/dri/i965/brw_state_upload.c
index f22567d..9c0b82c 100644
--- a/src/mesa/drivers/dri/i965/brw_state_upload.c
+++ b/src/mesa/drivers/dri/i965/brw_state_upload.c
@@ -578,23 +578,24 @@ static struct dirty_bit_map mesa_bits[] = {
DEFINE_BIT(_NEW_FOG),
DEFINE_BIT(_NEW_HINT),
DEFINE_BIT(_NEW_LIGHT),
DEFINE_BIT(_NEW_LINE),
DEFINE_BIT(_NEW_PIXEL),
DEFINE_BIT(_NEW_POINT),
DEFINE_BIT(_NEW_POLYGON),
DEFINE_BIT(_NEW_POLYGONSTIPPLE),
DEFINE_BIT(_NEW_SCISSOR),
DEFINE_BIT(_NEW_STENCIL),
-   DEFINE_BIT(_NEW_TEXTURE),
+   DEFINE_BIT(_NEW_TEXTURE_OBJECT),
DEFINE_BIT(_NEW_TRANSFORM),
DEFINE_BIT(_NEW_VIEWPORT),
+   DEFINE_BIT(_NEW_TEXTURE_STATE),
DEFINE_BIT(_NEW_ARRAY),
DEFINE_BIT(_NEW_RENDERMODE),
DEFINE_BIT(_NEW_BUFFERS),
DEFINE_BIT(_NEW_CURRENT_ATTRIB),
DEFINE_BIT(_NEW_MULTISAMPLE),
DEFINE_BIT(_NEW_TRACK_MATRIX),
DEFINE_BIT(_NEW_PROGRAM),
DEFINE_BIT(_NEW_PROGRAM_CONSTANTS),
DEFINE_BIT(_NEW_BUFFER_OBJECT),
DEFINE_BIT(_NEW_FRAG_CLAMP),
diff --git a/src/mesa/main/attrib.c b/src/mesa/main/attrib.c
index ada2203..8e738c9 100644
--- a/src/mesa/main/attrib.c
+++ b/src/mesa/main/attrib.c
@@ -1378,21 +1378,21 @@ _mesa_PopAttrib(void)
ctx->Transform.DepthClamp);
if (ctx->Extensions.ARB_clip_control)
   _mesa_ClipControl(xform->ClipOrigin, xform->ClipDepthMode);
 }
 break;
  case GL_TEXTURE_BIT:
 {
struct texture_state *texstate
   = (struct texture_state *) attr->data;
pop_texture_group(ctx, texstate);
-  ctx->NewState |= _NEW_TEXTURE;
+  ctx->NewState |= _NEW_TEXTURE_OBJECT | _NEW_TEXTURE_STATE;
 }
 break;
  case GL_VIEWPORT_BIT:
 {
unsigned i;
const struct gl_viewport_attrib *vp;
vp = (const struct gl_viewport_attrib *) attr->data;
 
for (i = 0; i < ctx->Const.MaxViewports; i++) {
   _mesa_set_viewport(ctx, i, vp[i].X, vp[i].Y, vp[i].Width,
diff --git a/src/mesa/main/debug.c b/src/mesa/main/debug.c
index 3471b26..f909f83 100644
--- a/src/mesa/main/debug.c
+++ b/src/mesa/main/debug.c
@@ -84,23 +84,24 @@ _mesa_print_state( const char *msg, GLuint state )
   (state & _NEW_FOG) ? "ctx->Fog, " : "",
   (state & _NEW_HINT)? "ctx->Hint, " : "",
   (state & _NEW_LIGHT)   ? "ctx->Light, " : "",
   (state & _NEW_LINE)? "ctx->Line, " : "",
   (state & _NEW_PIXEL)   ? "ctx->Pixel, " : "",
   (state & _NEW_POINT)   ? "ctx->Point, " : "",
   (state & _NEW_POLYGON) ? "ctx->Polygon, " : "",
   (state & _NEW_POLYGONSTIPPLE)  ? "ctx->PolygonStipple, " : "",
   (state & _NEW_SCISSOR) ? "ctx->Scissor, " : "",
   (state & _NEW_STENCIL) ? "ctx->Stencil, " : "",
-  (state & _NEW_TEXTURE) ? "ctx->Texture, " : "",
+  (state & _NEW_TEXTURE_OBJECT)  ? "ctx->Texture(Object), " : "",
   (state & _NEW_TRANSFORM)   ? "ctx->Transform, " : "",
   (state & _NEW_VIEWPORT)? "ctx->Viewport, " : "",
+   (state & _NEW_TEXTURE_STATE)   ? "ctx->Texture(State), " : "",
   (state & _NEW_ARRAY)   ? "ctx->Array, " : "",
   (state & _NEW_RENDERMODE)  ? "ctx->RenderMode, " : "",
   (state & _NEW_BUFFERS) ? "ctx->Visual, ctx->DrawBuffer,, " : 
"");
 }
 
 
 
 /**
  * Print information about this Mesa version and build options.
  */
diff --git a/src/mesa/main/state.c b/src/mesa/main/state.c
index 71265a5..07629d8 100644
--- a/src/mesa/main/state.c
+++ b/src/mesa/main/state.c
@@ -377,46 +377,46 @@ _mesa_update_state_locked( struct gl_context *ctx )
 * state matches one or more bits in 'computed_states'.
 */
if ((new_state & computed_states) == 0)
   goto out;
 
if (MESA_VERBOSE & VERBOSE_STATE)
   _mesa_print_state("_mesa_update_state", new_state);
 
/* Determine which state flags effect vertex/fragment program state */
if (ctx->FragmentProgram._MaintainTexEnvProgram) {
-  prog_flags |= (_NEW_BUFFERS | _NEW_TEXTURE | _NEW_FOG |
+  prog_flags |= (_NEW_BUFFERS | _NEW_TEXTURE_OBJECT | _NEW_FOG |
 _NEW_VARYING_VP_INPUTS | _NEW_LIGHT | _NEW_POINT |
 _NEW_RENDERMODE | _NEW_PROGRAM | _NEW_FRAG_CLAMP |

[Mesa-dev] [PATCH 2/6] mesa: split _NEW_TEXTURE into _NEW_TEXTURE_OBJECT & _NEW_TEXTURE_STATE

[Marek Olšák]

From: Marek Olšák 

No performance testing has been done, because it makes sense to make this
change regardless of that. Also, _NEW_TEXTURE is still used in many places,
but the obvious occurences are replaced here.

It's now possible to split _NEW_TEXTURE_OBJECT further.
---
 src/mesa/main/enable.c   |  8 
 src/mesa/main/ff_fragment_shader.cpp |  4 ++--
 src/mesa/main/mipmap.c   |  2 +-
 src/mesa/main/mtypes.h   |  8 +---
 src/mesa/main/samplerobj.c   | 10 +-
 src/mesa/main/shaderimage.h  |  2 +-
 src/mesa/main/texenv.c   | 18 +-
 src/mesa/main/texgen.c   |  6 +++---
 src/mesa/main/teximage.c |  6 +++---
 src/mesa/main/texobj.c   | 14 +++---
 src/mesa/main/texparam.c | 10 +-
 src/mesa/main/texstate.c |  2 +-
 src/mesa/main/uniform_query.cpp  |  2 +-
 src/mesa/program/prog_statevars.c|  4 ++--
 src/mesa/state_tracker/st_context.c  |  2 +-
 15 files changed, 50 insertions(+), 48 deletions(-)

diff --git a/src/mesa/main/enable.c b/src/mesa/main/enable.c
index f0c5bb7..d9d63a6 100644
--- a/src/mesa/main/enable.c
+++ b/src/mesa/main/enable.c
@@ -219,21 +219,21 @@ get_texcoord_unit(struct gl_context *ctx)
 static GLboolean
 enable_texture(struct gl_context *ctx, GLboolean state, GLbitfield texBit)
 {
struct gl_texture_unit *texUnit = _mesa_get_current_tex_unit(ctx);
const GLbitfield newenabled = state
   ? (texUnit->Enabled | texBit) : (texUnit->Enabled & ~texBit);
 
if (texUnit->Enabled == newenabled)
return GL_FALSE;
 
-   FLUSH_VERTICES(ctx, _NEW_TEXTURE);
+   FLUSH_VERTICES(ctx, _NEW_TEXTURE_STATE);
texUnit->Enabled = newenabled;
return GL_TRUE;
 }
 
 
 /**
  * Helper function to enable or disable GL_MULTISAMPLE, skipping the check for
  * whether the API supports it (GLES doesn't).
  */
 void
@@ -711,42 +711,42 @@ _mesa_set_enable(struct gl_context *ctx, GLenum cap, 
GLboolean state)
 if (ctx->API != API_OPENGL_COMPAT)
goto invalid_enum_error;
 
 if (texUnit) {
GLbitfield coordBit = S_BIT << (cap - GL_TEXTURE_GEN_S);
GLbitfield newenabled = texUnit->TexGenEnabled & ~coordBit;
if (state)
   newenabled |= coordBit;
if (texUnit->TexGenEnabled == newenabled)
   return;
-   FLUSH_VERTICES(ctx, _NEW_TEXTURE);
+   FLUSH_VERTICES(ctx, _NEW_TEXTURE_STATE);
texUnit->TexGenEnabled = newenabled;
 }
  }
  break;
 
   case GL_TEXTURE_GEN_STR_OES:
 /* disable S, T, and R at the same time */
 {
 struct gl_texture_unit *texUnit = get_texcoord_unit(ctx);
 
 if (ctx->API != API_OPENGLES)
goto invalid_enum_error;
 
 if (texUnit) {
GLuint newenabled =
  texUnit->TexGenEnabled & ~STR_BITS;
if (state)
   newenabled |= STR_BITS;
if (texUnit->TexGenEnabled == newenabled)
   return;
-   FLUSH_VERTICES(ctx, _NEW_TEXTURE);
+   FLUSH_VERTICES(ctx, _NEW_TEXTURE_STATE);
texUnit->TexGenEnabled = newenabled;
 }
  }
  break;
 
   /* client-side state */
   case GL_VERTEX_ARRAY:
   case GL_NORMAL_ARRAY:
   case GL_COLOR_ARRAY:
   case GL_TEXTURE_COORD_ARRAY:
@@ -951,21 +951,21 @@ _mesa_set_enable(struct gl_context *ctx, GLenum cap, 
GLboolean state)
  return;
FLUSH_VERTICES(ctx, _NEW_PROGRAM);
ctx->ATIFragmentShader.Enabled = state;
 break;
 
   case GL_TEXTURE_CUBE_MAP_SEAMLESS:
  if (!_mesa_is_desktop_gl(ctx))
 goto invalid_enum_error;
 CHECK_EXTENSION(ARB_seamless_cube_map, cap);
 if (ctx->Texture.CubeMapSeamless != state) {
-   FLUSH_VERTICES(ctx, _NEW_TEXTURE);
+   FLUSH_VERTICES(ctx, _NEW_TEXTURE_OBJECT);
ctx->Texture.CubeMapSeamless = state;
 }
 break;
 
   case GL_RASTERIZER_DISCARD:
  if (!_mesa_is_desktop_gl(ctx) && !_mesa_is_gles3(ctx))
 goto invalid_enum_error;
 CHECK_EXTENSION(EXT_transform_feedback, cap);
  if (ctx->RasterDiscard != state) {
 FLUSH_VERTICES(ctx, 0);
diff --git a/src/mesa/main/ff_fragment_shader.cpp 
b/src/mesa/main/ff_fragment_shader.cpp
index be382fa..f007ac3 100644
--- a/src/mesa/main/ff_fragment_shader.cpp
+++ b/src/mesa/main/ff_fragment_shader.cpp
@@ -331,21 +331,21 @@ static GLbitfield get_fp_input_mask( struct gl_context 
*ctx )
* vertex program:
*/
   /* _NEW_LIGHT */
   if (ctx->Light.Enabled) {
  fp_inputs |= VARYING_BIT_COL0;
 
  if (texenv_doing_secondary_color(ctx))
 fp_inputs |= VARYING_BIT_COL1;
 

[Mesa-dev] [PATCH 4/6] i915: remove BindProgram

[Marek Olšák]

From: Marek Olšák 

The same thing is done in i915_update_program called by i915InvalidateState.
Why do it twice.
---
 src/mesa/drivers/dri/i915/i915_fragprog.c | 25 -
 1 file changed, 25 deletions(-)

diff --git a/src/mesa/drivers/dri/i915/i915_fragprog.c 
b/src/mesa/drivers/dri/i915/i915_fragprog.c
index fce649d..0fad2c3 100644
--- a/src/mesa/drivers/dri/i915/i915_fragprog.c
+++ b/src/mesa/drivers/dri/i915/i915_fragprog.c
@@ -1112,44 +1112,20 @@ track_params(struct i915_fragment_program *p)
 
for (i = 0; i < p->nr_params; i++) {
   GLint reg = p->param[i].reg;
   COPY_4V(p->constant[reg], p->param[i].values);
}
 
p->params_uptodate = 1;
p->on_hardware = 0;  /* overkill */
 }
 
-
-static void
-i915BindProgram(struct gl_context * ctx, GLenum target, struct gl_program 
*prog)
-{
-   if (target == GL_FRAGMENT_PROGRAM_ARB) {
-  struct i915_context *i915 = I915_CONTEXT(ctx);
-  struct i915_fragment_program *p = (struct i915_fragment_program *) prog;
-
-  if (i915->current_program == p)
- return;
-
-  if (i915->current_program) {
- i915->current_program->on_hardware = 0;
- i915->current_program->params_uptodate = 0;
-  }
-
-  i915->current_program = p;
-
-  assert(p->on_hardware == 0);
-  assert(p->params_uptodate == 0);
-
-   }
-}
-
 static struct gl_program *
 i915NewProgram(struct gl_context * ctx, GLenum target, GLuint id,
bool is_arb_asm)
 {
switch (target) {
case GL_VERTEX_PROGRAM_ARB: {
   struct gl_program *prog = rzalloc(NULL, struct gl_program);
   return _mesa_init_gl_program(prog, target, id, is_arb_asm);
}
 
@@ -1365,17 +1341,16 @@ i915ValidateFragmentProgram(struct i915_context *i915)
 
if (INTEL_DEBUG & DEBUG_WM) {
   printf("i915:\n");
   i915_disassemble_program(i915->state.Program, i915->state.ProgramSize);
}
 }
 
 void
 i915InitFragProgFuncs(struct dd_function_table *functions)
 {
-   functions->BindProgram = i915BindProgram;
functions->NewProgram = i915NewProgram;
functions->DeleteProgram = i915DeleteProgram;
functions->IsProgramNative = i915IsProgramNative;
functions->ProgramStringNotify = i915ProgramStringNotify;
functions->SamplerUniformChange = i915SamplerUniformChange;
 }
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH] glsl_to_tgsi: don't rely on glsl types when visiting tex instructions

[Samuel Pitoiset]

On 03/23/2017 08:30 PM, Nicolai Hähnle wrote:

On 23.03.2017 20:17, Samuel Pitoiset wrote:

Instead add is_cube_shadow like is_cube_array.


I'm curious: why? Anyway, looks fine, so


Preliminary work for ARB_bindless_texture. I will introduce new types 
like sampler2DBindless_type.




Reviewed-by: Nicolai Hähnle 



Signed-off-by: Samuel Pitoiset 
---
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 5bfcc73a3b..63de74adcb 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -4133,13 +4133,13 @@ glsl_to_tgsi_visitor::visit(ir_texture *ir)
const glsl_type *sampler_type = ir->sampler->type;
unsigned sampler_array_size = 1, sampler_base = 0;
uint16_t sampler_index = 0;
-   bool is_cube_array = false;
+   bool is_cube_array = false, is_cube_shadow = false;
unsigned i;

-   /* if we are a cube array sampler */
-   if ((sampler_type->sampler_dimensionality == GLSL_SAMPLER_DIM_CUBE &&
-sampler_type->sampler_array)) {
-  is_cube_array = true;
+   /* if we are a cube array sampler or a cube shadow */
+   if (sampler_type->sampler_dimensionality == GLSL_SAMPLER_DIM_CUBE) {
+  is_cube_array = sampler_type->sampler_array;
+  is_cube_shadow = sampler_type->sampler_shadow;
}

if (ir->coordinate) {
@@ -4177,8 +4177,7 @@ glsl_to_tgsi_visitor::visit(ir_texture *ir)
   }
   break;
case ir_txb:
-  if (is_cube_array ||
-  sampler_type == glsl_type::samplerCubeShadow_type) {
+  if (is_cube_array || is_cube_shadow) {
  opcode = TGSI_OPCODE_TXB2;
   }
   else {





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

Re: [Mesa-dev] [PATCH] mesa: set thread name for glthread

[Timothy Arceri]

On 24/03/17 09:47, Miklós Máté wrote:

Thank you for the review. Could someone please commit this? I have no
access.

MM


Pushed. Thanks!



On 20/03/17 17:36, Marek Olšák wrote:

Reviewed-by: Marek Olšák 

Marek

On Sat, Mar 18, 2017 at 10:55 PM, Miklós Máté  wrote:

Signed-off-by: Miklós Máté 
---
  src/mesa/main/glthread.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/src/mesa/main/glthread.c b/src/mesa/main/glthread.c
index 623266f484..06115b916d 100644
--- a/src/mesa/main/glthread.c
+++ b/src/mesa/main/glthread.c
@@ -36,6 +36,7 @@
  #include "main/glthread.h"
  #include "main/marshal.h"
  #include "main/marshal_generated.h"
+#include "util/u_thread.h"

  #ifdef HAVE_PTHREAD

@@ -75,6 +76,8 @@ glthread_worker(void *data)
 ctx->Driver.SetBackgroundContext(ctx);
 _glapi_set_context(ctx);

+   u_thread_setname("mesa_glthread");
+
 pthread_mutex_lock(>mutex);

 while (true) {
--
2.11.0

___
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] mesa: set thread name for glthread

[Miklós Máté]

Thank you for the review. Could someone please commit this? I have no 
access.


MM

On 20/03/17 17:36, Marek Olšák wrote:

Reviewed-by: Marek Olšák 

Marek

On Sat, Mar 18, 2017 at 10:55 PM, Miklós Máté  wrote:

Signed-off-by: Miklós Máté 
---
  src/mesa/main/glthread.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/src/mesa/main/glthread.c b/src/mesa/main/glthread.c
index 623266f484..06115b916d 100644
--- a/src/mesa/main/glthread.c
+++ b/src/mesa/main/glthread.c
@@ -36,6 +36,7 @@
  #include "main/glthread.h"
  #include "main/marshal.h"
  #include "main/marshal_generated.h"
+#include "util/u_thread.h"

  #ifdef HAVE_PTHREAD

@@ -75,6 +76,8 @@ glthread_worker(void *data)
 ctx->Driver.SetBackgroundContext(ctx);
 _glapi_set_context(ctx);

+   u_thread_setname("mesa_glthread");
+
 pthread_mutex_lock(>mutex);

 while (true) {
--
2.11.0

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



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

Re: [Mesa-dev] [PATCH v2 2/5] intel: Move tools/decoder.[ch] to common/gen_decoder.[ch].

[Matt Turner]

On Wed, Mar 22, 2017 at 12:53 PM, Rob Herring  wrote:
> On Wed, Mar 22, 2017 at 6:50 AM, Emil Velikov  
> wrote:
>> n 21 March 2017 at 20:58, Kenneth Graunke  wrote:
>>> On Tuesday, March 21, 2017 4:40:26 AM PDT Emil Velikov wrote:
 On 21 March 2017 at 11:14, Emil Velikov  wrote:
 > On 20 March 2017 at 22:04, Kenneth Graunke  wrote:
 >> This way they become part of libintel_common.la so I can use them in
 >> the i965 driver.
 >> ---
 >>  src/intel/Makefile.sources  | 2 ++
 >>  src/intel/Makefile.tools.am | 2 --
 >>  src/intel/{tools/decoder.c => common/gen_decoder.c} | 2 +-
 >>  src/intel/{tools/decoder.h => common/gen_decoder.h} | 6 +++---
 >>  src/intel/tools/aubinator.c | 2 +-
 >>  5 files changed, 7 insertions(+), 7 deletions(-)
 >>  rename src/intel/{tools/decoder.c => common/gen_decoder.c} (99%)
 >>  rename src/intel/{tools/decoder.h => common/gen_decoder.h} (98%)
 >>
 >> I'd forgotten than I still had my gross symlinking hack in the first
 >> version of this series.  Here's a new spin which does this "properly" :)
 >>
 > You can do the symlink if you want to - I don't mind. This approach
 > will "bloat" every binary that links with libintel_common, since we
 > don't ask the linker to garbage collect.
 > Admittedly we only care about the ANV case, so I'll just follow-up and
 > add the GC toggle ;-)
 >
 Scratch that we do enabled it for ANV ;-)

 You really nicely reworked [in 3/5] making the code "debug only", so
 perhaps can we guard the code in gen_decoder.c the same way ? ... But
 that may interact badly with aubinator :-\
 Another option would be to guard the code in ifndef ANDROID - like toggle.

 Otherwise one will need to copy the _xml.h rules in Android, alongside
 a dummy libmesa_genxml-like library. The latter of which will need to
 be added as LOCAL_WHOLE_STATIC_LIBRARIES [for libmesa_intel_common] to
 pull/generate the headers. At the same time none of it is used since
 Android never defines DEBUG ... nor does it use the linker garbage
 collector (GC_SECTIONS)
 Tapani feel free to grep mesa for GC_SECTIONS and use in Android.
>>>
>>> Ugh, good point - I forgot about Android (and SCons, but thankfully we
>>> don't care about SCons here).  I don't have any clue how to test Android
>>> builds, so I'm going to go ahead and land it as is (sorry!).
>>>
>> No need to apologise - I'm not expecting !Android people to have the
>> setup and/or do Android builds.
>
> Could we at least expect the !Android people to not commit things that
> are known to break Android until the issue is solved?
>
> I can't keep up with the breakage on Intel, so I guess I'll stop caring.

Is it easier for you to fix things before they're in the tree, vs after?

We've got Jenkins doing a scons build to make sure that keeps working,
but I'm not sure if it's reasonably possible to do the same for
Android.

Is your suggestion for Mesa developers to gate their patches on
updating the Android build system?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/6] Add support for GL_NV_fill_rectangle

[Marek Olšák]

On Thu, Mar 23, 2017 at 9:59 PM, Ilia Mirkin  wrote:
> On Thu, Mar 23, 2017 at 3:33 PM, Marek Olšák  wrote:
>> On Thu, Mar 23, 2017 at 7:45 PM, Lyude Paul  wrote:
>>> On Thu, 2017-03-23 at 14:22 -0400, Alex Deucher wrote:
 On Thu, Mar 23, 2017 at 2:18 PM, Marek Olšák 
 wrote:
 > Is there any user of this extension?

 Based on the spec, it seems like it would be useful for glamor.  No
 idea is anyone has code to use it yet.
>>> Actually me, robclark and airlied were talking specifically about using
>>> this for glamor and trying to implement it on other platforms using
>>> rectangular primitives. No idea if that'll work (especially since I'm
>>> new here), but it sounds promising enough to try :).
>>>
>>> Once I get this patch series upstream I'll probably look into writing
>>> an implementation for softpipe and some other drivers
>>
>> Well radeons can't support or emulate the NV extension, so this is all
>> just for nouveau. I doubt that airlied would want a nouveau-only
>> codepath in glamor.
>>
>> Below is my definition of what a hypothetical MESA_rectangle_primitive
>> should specify. It takes into account all we know about existing
>> desktop hardware (AMD - we have the hw spec; Intel - I talked with
>> them; NV - I read the NV fill extension).
>>
>>
>> Definition and behavior:
>> - The rectangle primitive is defined by its first 3 vertices.
>> - The 4th vertex is derived (extrapolated) during rasterization.
>> - It's treated as a triangle by all stages before rasterization.
>> - The rectangle edges must be parallel or perpendicular to X and Y
>> axes, i.e. the rectangle can only be rotated in 90-degree increments
>> and flipped over.
>> - It must be rasterized as a rectangle (no diagonal tearing allowed,
>> no artifacts on the diagonal allowed)
>> - The content of gl_FrontFacing is undefined.
>
> Might want to mention something about smooth-interpolated varyings.
> (See what NV_fill_rectangle has to say about it.)
>
>>
>> Return a GL error:
>> - if clip planes, clip distances, or cull distances are enabled.
>> - if face culling is enabled. (face determination is undefined)
>> - if polygon mode is not fill
>> - if primitive restart is enabled
>> - if geometry or tessellation shaders are enabled
>>
>> The behavior is undefined:
>> - if the rectangle edges are not axis-aligned.
>> - if Z coordinates of all 3 vertices are not equal.
>> - if the rectangle intersects the clip space boundaries. (all options
>> are allowed: clip, cull, or accept the primitive)
>> - if two-sided lighting is enabled and the colors are not the same for
>> both sides.
>>
>> TODO:
>> - Add piglit to verify that the order of vertices doesn't matter on Intel.
>
> A few things to note:
>  - NV_fill_rectangle is only supported on the newest GPUs
>  - Software other than glamor (which I personally don't care much
> about in the context of NV hardware) may start using NV_fill_rectangle
>
> Are you objecting to the implementation of this nvidia-hw-only
> extension? Or just mentioning that there's another way of specifying
> this that will make it implementable on other hardware?
>
> I don't have a killer use case for this extension, it's not like we
> MUST start providing it for some piece of software to work well.
> However irrespective of other extensions that may be added that work
> well across a range of hw, I think it's worthwhile supporting this one
> in nouveau.

My objection was only about Glamor, and the other use cases were for
my curiosity, as I think we are all guilty of doing things that are
"interesting" without any use case, but you could have said that the
goal was to get familiar with the code. :)

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

[Mesa-dev] [Bug 99817] [softpipe] piglit glsl-fs-tan-1 regression

[bugzilla-daemon]

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

Vinson Lee  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Vinson Lee  ---
commit e6469ec43b25898e99766a30aa8f54cc64c3bc04
Author: Francisco Jerez 
Date:   Mon Mar 13 17:31:39 2017 -0700

gallium/tgsi: Treat UCMP sources as floats to match the GLSL-to-TGSI pass
expectations.

Currently the GLSL-to-TGSI translation pass assumes it can use
floating point source modifiers on the UCMP instruction.  See the bug
report linked below for an example where an unrelated change in the
GLSL built-in lowering code for atan2 (e9ffd12827ac11a2d2002a42fa8eb1)
caused the generation of floating-point ir_unop_neg instructions
followed by ir_triop_csel, which is translated into UCMP with a negate
modifier on back-ends with native integer support.

Allowing floating-point source modifiers on an integer instruction
seems like rather dubious design for a transport IR, since the same
semantics could be represented as a sequence of MOV+UCMP instructions
instead, but supposedly this matches the expectations of TGSI
back-ends other than tgsi_exec, and the expectations of the DX10 API.
I take no responsibility for future headaches caused by this
inconsistency.

Fixes a regression of piglit glsl-fs-tan-1 on softpipe introduced by
the above-mentioned glsl front-end commit.  Even though the commit
that triggered the regression doesn't seem to have made it to any
stable branches yet, this might be worth back-porting since I don't
see any reason why the bug couldn't have been reproduced before that
point.

Suggested-by: Roland Scheidegger 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99817
Reviewed-by: Roland Scheidegger 

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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Greg Hackmann]

On 03/22/2017 02:48 PM, Rob Clark wrote:

On Wed, Mar 22, 2017 at 4:10 PM, Dylan Baker  wrote:

Quoting Rob Clark (2017-03-22 10:07:54)

I guess an interesting question (from someone who doesn't know meson
yet) would be whether meson could slurp in the Makefile.sources type
stuff that we have, which are shared so far between
android/scons/autotools (and for the most part, kept developers from
having to care *too* much about the different build systems)


Jason and I have talked about that too. I'd suggested that we could write a
module for meson to read makefile.sources (since we're surely not the only
project that would benefit from such a module), except that android is moving to
blueprint[1] instead of android.mk files. As far as I can tell blueprint doesn't
support using makefile.sources, so it seems somewhat moot in a world of
blueprint for android, meson for *.


I guess even if it is only a temporary thing, something that could
slurp in Makefile.sources seems like it would be useful for a
transition period.

I'm not totally up to speed on android/blueprint stuff.. but even some
simplified or different "here-are-my-sources" type file that could be
shared across build systems would be useful.  Meson sounds a bit more
extensible so maybe there is some potential to adapt to whatever
android forces on us ;-)


+ccross from the Android build team can hopefully provide some input here.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/6] Add support for GL_NV_fill_rectangle

[Ilia Mirkin]

On Thu, Mar 23, 2017 at 3:33 PM, Marek Olšák  wrote:
> On Thu, Mar 23, 2017 at 7:45 PM, Lyude Paul  wrote:
>> On Thu, 2017-03-23 at 14:22 -0400, Alex Deucher wrote:
>>> On Thu, Mar 23, 2017 at 2:18 PM, Marek Olšák 
>>> wrote:
>>> > Is there any user of this extension?
>>>
>>> Based on the spec, it seems like it would be useful for glamor.  No
>>> idea is anyone has code to use it yet.
>> Actually me, robclark and airlied were talking specifically about using
>> this for glamor and trying to implement it on other platforms using
>> rectangular primitives. No idea if that'll work (especially since I'm
>> new here), but it sounds promising enough to try :).
>>
>> Once I get this patch series upstream I'll probably look into writing
>> an implementation for softpipe and some other drivers
>
> Well radeons can't support or emulate the NV extension, so this is all
> just for nouveau. I doubt that airlied would want a nouveau-only
> codepath in glamor.
>
> Below is my definition of what a hypothetical MESA_rectangle_primitive
> should specify. It takes into account all we know about existing
> desktop hardware (AMD - we have the hw spec; Intel - I talked with
> them; NV - I read the NV fill extension).
>
>
> Definition and behavior:
> - The rectangle primitive is defined by its first 3 vertices.
> - The 4th vertex is derived (extrapolated) during rasterization.
> - It's treated as a triangle by all stages before rasterization.
> - The rectangle edges must be parallel or perpendicular to X and Y
> axes, i.e. the rectangle can only be rotated in 90-degree increments
> and flipped over.
> - It must be rasterized as a rectangle (no diagonal tearing allowed,
> no artifacts on the diagonal allowed)
> - The content of gl_FrontFacing is undefined.

Might want to mention something about smooth-interpolated varyings.
(See what NV_fill_rectangle has to say about it.)

>
> Return a GL error:
> - if clip planes, clip distances, or cull distances are enabled.
> - if face culling is enabled. (face determination is undefined)
> - if polygon mode is not fill
> - if primitive restart is enabled
> - if geometry or tessellation shaders are enabled
>
> The behavior is undefined:
> - if the rectangle edges are not axis-aligned.
> - if Z coordinates of all 3 vertices are not equal.
> - if the rectangle intersects the clip space boundaries. (all options
> are allowed: clip, cull, or accept the primitive)
> - if two-sided lighting is enabled and the colors are not the same for
> both sides.
>
> TODO:
> - Add piglit to verify that the order of vertices doesn't matter on Intel.

A few things to note:
 - NV_fill_rectangle is only supported on the newest GPUs
 - Software other than glamor (which I personally don't care much
about in the context of NV hardware) may start using NV_fill_rectangle

Are you objecting to the implementation of this nvidia-hw-only
extension? Or just mentioning that there's another way of specifying
this that will make it implementable on other hardware?

I don't have a killer use case for this extension, it's not like we
MUST start providing it for some piece of software to work well.
However irrespective of other extensions that may be added that work
well across a range of hw, I think it's worthwhile supporting this one
in nouveau.

Cheers,

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

Re: [Mesa-dev] [PATCH] i965: Replace OPT_V() with OPT().

[Matt Turner]

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

[Mesa-dev] [PATCH] i965: Replace OPT_V() with OPT().

[Matt Turner]

We want to be able to check the progress of each pass and dump the NIR
for debugging purposes if it changed.

Reviewed-by: Jason Ekstrand 
---
 src/intel/compiler/brw_nir.c | 42 +++---
 1 file changed, 19 insertions(+), 23 deletions(-)

diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
index f863085..36ccdf3 100644
--- a/src/intel/compiler/brw_nir.c
+++ b/src/intel/compiler/brw_nir.c
@@ -452,8 +452,6 @@ brw_nir_lower_cs_shared(nir_shader *nir)
this_progress;  \
 })
 
-#define OPT_V(pass, ...) NIR_PASS_V(nir, pass, ##__VA_ARGS__)
-
 static nir_shader *
 nir_optimize(nir_shader *nir, const struct brw_compiler *compiler,
  bool is_scalar)
@@ -469,7 +467,7 @@ nir_optimize(nir_shader *nir, const struct brw_compiler 
*compiler,
bool progress;
do {
   progress = false;
-  OPT_V(nir_lower_vars_to_ssa);
+  OPT(nir_lower_vars_to_ssa);
   OPT(nir_opt_copy_prop_vars);
 
   if (is_scalar) {
@@ -503,16 +501,16 @@ nir_optimize(nir_shader *nir, const struct brw_compiler 
*compiler,
   }
   OPT(nir_opt_remove_phis);
   OPT(nir_opt_undef);
-  OPT_V(nir_lower_doubles, nir_lower_drcp |
-   nir_lower_dsqrt |
-   nir_lower_drsq |
-   nir_lower_dtrunc |
-   nir_lower_dfloor |
-   nir_lower_dceil |
-   nir_lower_dfract |
-   nir_lower_dround_even |
-   nir_lower_dmod);
-  OPT_V(nir_lower_64bit_pack);
+  OPT(nir_lower_doubles, nir_lower_drcp |
+ nir_lower_dsqrt |
+ nir_lower_drsq |
+ nir_lower_dtrunc |
+ nir_lower_dfloor |
+ nir_lower_dceil |
+ nir_lower_dfract |
+ nir_lower_dround_even |
+ nir_lower_dmod);
+  OPT(nir_lower_64bit_pack);
} while (progress);
 
return nir;
@@ -531,8 +529,7 @@ nir_shader *
 brw_preprocess_nir(const struct brw_compiler *compiler, nir_shader *nir)
 {
const struct gen_device_info *devinfo = compiler->devinfo;
-   bool progress; /* Written by OPT and OPT_V */
-   (void)progress;
+   UNUSED bool progress; /* Written by OPT */
 
const bool is_scalar = compiler->scalar_stage[nir->stage];
 
@@ -561,13 +558,13 @@ brw_preprocess_nir(const struct brw_compiler *compiler, 
nir_shader *nir)
nir = nir_optimize(nir, compiler, is_scalar);
 
if (is_scalar) {
-  OPT_V(nir_lower_load_const_to_scalar);
+  OPT(nir_lower_load_const_to_scalar);
}
 
/* Lower a bunch of stuff */
-   OPT_V(nir_lower_var_copies);
+   OPT(nir_lower_var_copies);
 
-   OPT_V(nir_lower_clip_cull_distance_arrays);
+   OPT(nir_lower_clip_cull_distance_arrays);
 
nir_variable_mode indirect_mask = 0;
if (compiler->glsl_compiler_options[nir->stage].EmitNoIndirectInput)
@@ -606,8 +603,7 @@ brw_postprocess_nir(nir_shader *nir, const struct 
brw_compiler *compiler,
bool debug_enabled =
   (INTEL_DEBUG & intel_debug_flag_for_shader_stage(nir->stage));
 
-   bool progress; /* Written by OPT and OPT_V */
-   (void)progress;
+   UNUSED bool progress; /* Written by OPT */
 
nir = nir_optimize(nir, compiler, is_scalar);
 
@@ -618,7 +614,7 @@ brw_postprocess_nir(nir_shader *nir, const struct 
brw_compiler *compiler,
 
OPT(nir_opt_algebraic_late);
 
-   OPT_V(nir_lower_to_source_mods);
+   OPT(nir_lower_to_source_mods);
OPT(nir_copy_prop);
OPT(nir_opt_dce);
OPT(nir_opt_move_comparisons);
@@ -637,10 +633,10 @@ brw_postprocess_nir(nir_shader *nir, const struct 
brw_compiler *compiler,
   nir_print_shader(nir, stderr);
}
 
-   OPT_V(nir_convert_from_ssa, true);
+   OPT(nir_convert_from_ssa, true);
 
if (!is_scalar) {
-  OPT_V(nir_move_vec_src_uses_to_dest);
+  OPT(nir_move_vec_src_uses_to_dest);
   OPT(nir_lower_vec_to_movs);
}
 
-- 
2.10.2

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

Re: [Mesa-dev] [PATCH v2] anv: add support for allocating more than 1 block of memory

[Jason Ekstrand]

On Wed, Mar 22, 2017 at 4:14 AM, Juan A. Suarez Romero 
wrote:

> On Wed, 2017-03-15 at 13:05 +0100, Juan A. Suarez Romero wrote:
> > Current Anv allocator assign memory in terms of a fixed block size.
> >
> > But there can be cases where this block is not enough for a memory
> > request, and thus several blocks must be assigned in a row.
> >
> > This commit adds support for specifying how many blocks of memory must
> > be assigned.
> >
> > This fixes a number dEQP-VK.pipeline.render_to_image.* tests that crash.
> >
> > v2: lock-free free-list is not handled correctly (Jason)
> > ---
>
> Gently ping to get feedback/review O:)
>

Yup.  I took a break from e-mail so I could write some of my own patches
for once. :-)

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

[Mesa-dev] [PATCH] i965/fs: Don't emit SEL instructions for type-converting MOVs.

[Matt Turner]

SEL can only convert between a few integer types, which we basically
never do.

Fixes fs/vs-double-uniform-array-direct-indirect-non-uniform-control-flow
Cc: mesa-sta...@lists.freedesktop.org
---
 src/intel/compiler/brw_fs_sel_peephole.cpp | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/intel/compiler/brw_fs_sel_peephole.cpp 
b/src/intel/compiler/brw_fs_sel_peephole.cpp
index 8cd897f..4c1c160 100644
--- a/src/intel/compiler/brw_fs_sel_peephole.cpp
+++ b/src/intel/compiler/brw_fs_sel_peephole.cpp
@@ -165,6 +165,8 @@ fs_visitor::opt_peephole_sel()
  then_mov[i]->exec_size != else_mov[i]->exec_size ||
  then_mov[i]->group != else_mov[i]->group ||
  then_mov[i]->force_writemask_all != 
else_mov[i]->force_writemask_all ||
+ then_mov[i]->dst.type != then_mov[i]->src[0].type ||
+ else_mov[i]->dst.type != else_mov[i]->src[0].type ||
  then_mov[i]->is_partial_write() ||
  else_mov[i]->is_partial_write() ||
  then_mov[i]->conditional_mod != BRW_CONDITIONAL_NONE ||
-- 
2.10.2

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

Re: [Mesa-dev] [PATCH] cso: store sampler views for all shader stages

[Marek Olšák]

NAK.

I wouldn't like more overhead in cso_context when better solutions are
available. There are several ways of dealing with texture update
overhead:

1) Split _NEW_TEXTURE into multiple flags, each covering a disjoint
set of states smaller than _NEW_TEXTURE.

2) Use a stage-specific flag (e.g. _NEW_VS_TEXTURE) instead of
_NEW_TEXTURE. glBindTexture can look at current shaders to know where
the texture is being used.

3) Threaded Gallium dispatch:
https://cgit.freedesktop.org/~mareko/mesa/log/?h=gallium-threaded
(missing: DISCARD_RANGE, deferred fences, bug fixes)

4) glthread

Marek



On Thu, Mar 23, 2017 at 7:44 PM, Samuel Pitoiset
 wrote:
> Sampler views were only cached for the fragment shader stage, but
> this might help other stages.
>
> This is a small opt which should help civ6 a little bit.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/gallium/auxiliary/cso_cache/cso_context.c | 101 
> ++
>  1 file changed, 55 insertions(+), 46 deletions(-)
>
> diff --git a/src/gallium/auxiliary/cso_cache/cso_context.c 
> b/src/gallium/auxiliary/cso_cache/cso_context.c
> index 3d3c44cf81..cac1b4e8a5 100644
> --- a/src/gallium/auxiliary/cso_cache/cso_context.c
> +++ b/src/gallium/auxiliary/cso_cache/cso_context.c
> @@ -61,6 +61,14 @@ struct sampler_info
>  };
>
>
> +/**
> + * Per-shader sampler view information.
> + */
> +struct view_info {
> +   struct pipe_sampler_view *views[PIPE_MAX_SHADER_SAMPLER_VIEWS];
> +   unsigned nr_views;
> +};
> +
>
>  struct cso_context {
> struct pipe_context *pipe;
> @@ -74,11 +82,8 @@ struct cso_context {
>
> unsigned saved_state;  /**< bitmask of CSO_BIT_x flags */
>
> -   struct pipe_sampler_view *fragment_views[PIPE_MAX_SHADER_SAMPLER_VIEWS];
> -   unsigned nr_fragment_views;
> -
> -   struct pipe_sampler_view 
> *fragment_views_saved[PIPE_MAX_SHADER_SAMPLER_VIEWS];
> -   unsigned nr_fragment_views_saved;
> +   struct view_info fragment_views_saved;
> +   struct view_info views[PIPE_SHADER_TYPES];
>
> struct sampler_info fragment_samplers_saved;
> struct sampler_info samplers[PIPE_SHADER_TYPES];
> @@ -346,7 +351,7 @@ out:
>   */
>  void cso_destroy_context( struct cso_context *ctx )
>  {
> -   unsigned i;
> +   unsigned i, j;
>
> if (ctx->pipe) {
>ctx->pipe->set_index_buffer(ctx->pipe, NULL);
> @@ -400,9 +405,14 @@ void cso_destroy_context( struct cso_context *ctx )
>   ctx->pipe->set_stream_output_targets(ctx->pipe, 0, NULL, NULL);
> }
>
> +   for (i = 0; i < PIPE_SHADER_TYPES; i++) {
> +  for (j = 0; j < PIPE_MAX_SHADER_SAMPLER_VIEWS; j++) {
> + pipe_sampler_view_reference(>views[i].views[j], NULL);
> +  }
> +   }
> +
> for (i = 0; i < PIPE_MAX_SHADER_SAMPLER_VIEWS; i++) {
> -  pipe_sampler_view_reference(>fragment_views[i], NULL);
> -  pipe_sampler_view_reference(>fragment_views_saved[i], NULL);
> +  pipe_sampler_view_reference(>fragment_views_saved.views[i], NULL);
> }
>
> util_unreference_framebuffer_state(>fb);
> @@ -1348,46 +1358,43 @@ cso_set_sampler_views(struct cso_context *ctx,
>unsigned count,
>struct pipe_sampler_view **views)
>  {
> -   if (shader_stage == PIPE_SHADER_FRAGMENT) {
> -  unsigned i;
> -  boolean any_change = FALSE;
> -
> -  /* reference new views */
> -  for (i = 0; i < count; i++) {
> - any_change |= ctx->fragment_views[i] != views[i];
> - pipe_sampler_view_reference(>fragment_views[i], views[i]);
> -  }
> -  /* unref extra old views, if any */
> -  for (; i < ctx->nr_fragment_views; i++) {
> - any_change |= ctx->fragment_views[i] != NULL;
> - pipe_sampler_view_reference(>fragment_views[i], NULL);
> -  }
> +   struct view_info *info = >views[shader_stage];
> +   boolean any_change = FALSE;
> +   unsigned i;
>
> -  /* bind the new sampler views */
> -  if (any_change) {
> - ctx->pipe->set_sampler_views(ctx->pipe, shader_stage, 0,
> -  MAX2(ctx->nr_fragment_views, count),
> -  ctx->fragment_views);
> -  }
> +   /* reference new views */
> +   for (i = 0; i < count; i++) {
> +  any_change |= info->views[i] != views[i];
> +  pipe_sampler_view_reference(>views[i], views[i]);
> +   }
> +   /* unref extra old views, if any */
> +   for (; i < info->nr_views; i++) {
> +  any_change |= info->views[i] != NULL;
> +  pipe_sampler_view_reference(>views[i], NULL);
> +   }
>
> -  ctx->nr_fragment_views = count;
> +   /* bind the new sampler views */
> +   if (any_change) {
> +  ctx->pipe->set_sampler_views(ctx->pipe, shader_stage, 0,
> +   MAX2(info->nr_views, count), info->views);
> }
> -   else
> -  ctx->pipe->set_sampler_views(ctx->pipe, shader_stage, 0, count, views);
> +
> +   info->nr_views = count;
>  }
>
>
>  static void
>  

Re: [Mesa-dev] [PATCH 2/4] r300: Fix indenting in r300_get_param()

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Thu, Mar 23, 2017 at 1:51 AM, Lyude  wrote:
> Signed-off-by: Lyude 
> ---
>  src/gallium/drivers/r300/r300_screen.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/src/gallium/drivers/r300/r300_screen.c 
> b/src/gallium/drivers/r300/r300_screen.c
> index 07a09d5..752cf82 100644
> --- a/src/gallium/drivers/r300/r300_screen.c
> +++ b/src/gallium/drivers/r300/r300_screen.c
> @@ -216,7 +216,7 @@ static int r300_get_param(struct pipe_screen* pscreen, 
> enum pipe_cap param)
>  case PIPE_CAP_QUERY_BUFFER_OBJECT:
>  case PIPE_CAP_QUERY_MEMORY_INFO:
>  case PIPE_CAP_FRAMEBUFFER_NO_ATTACHMENT:
> -   case PIPE_CAP_ROBUST_BUFFER_ACCESS_BEHAVIOR:
> +case PIPE_CAP_ROBUST_BUFFER_ACCESS_BEHAVIOR:
>  case PIPE_CAP_CULL_DISTANCE:
>  case PIPE_CAP_PRIMITIVE_RESTART_FOR_PATCHES:
>  case PIPE_CAP_TGSI_VOTE:
> @@ -246,7 +246,7 @@ static int r300_get_param(struct pipe_screen* pscreen, 
> enum pipe_cap param)
>  case PIPE_CAP_VERTEX_BUFFER_STRIDE_4BYTE_ALIGNED_ONLY:
>  case PIPE_CAP_VERTEX_ELEMENT_SRC_OFFSET_4BYTE_ALIGNED_ONLY:
>  return r300screen->caps.has_tcl;
> -   case PIPE_CAP_TGSI_TEXCOORD:
> +case PIPE_CAP_TGSI_TEXCOORD:
>  return 0;
>
>  /* Texturing. */
> @@ -259,7 +259,7 @@ static int r300_get_param(struct pipe_screen* pscreen, 
> enum pipe_cap param)
>  /* Render targets. */
>  case PIPE_CAP_MAX_RENDER_TARGETS:
>  return 4;
> -   case PIPE_CAP_ENDIANNESS:
> +case PIPE_CAP_ENDIANNESS:
>  return PIPE_ENDIAN_LITTLE;
>
>  case PIPE_CAP_MAX_VIEWPORTS:
> --
> 2.9.3
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] cso: store sampler views for all shader stages

[Nicolai Hähnle]

On 23.03.2017 19:44, Samuel Pitoiset wrote:

Sampler views were only cached for the fragment shader stage, but
this might help other stages.

This is a small opt which should help civ6 a little bit.


Do you have benchmarks? This might help if we don't manage to filter out 
redundant state changes earlier, but it might also hurt by always doing 
more work and touching more memory.


The fragment views _must_ be tracked, because we need the ability to 
save and restore them.


Cheers,
Nicolai



Signed-off-by: Samuel Pitoiset 
---
 src/gallium/auxiliary/cso_cache/cso_context.c | 101 ++
 1 file changed, 55 insertions(+), 46 deletions(-)

diff --git a/src/gallium/auxiliary/cso_cache/cso_context.c 
b/src/gallium/auxiliary/cso_cache/cso_context.c
index 3d3c44cf81..cac1b4e8a5 100644
--- a/src/gallium/auxiliary/cso_cache/cso_context.c
+++ b/src/gallium/auxiliary/cso_cache/cso_context.c
@@ -61,6 +61,14 @@ struct sampler_info
 };


+/**
+ * Per-shader sampler view information.
+ */
+struct view_info {
+   struct pipe_sampler_view *views[PIPE_MAX_SHADER_SAMPLER_VIEWS];
+   unsigned nr_views;
+};
+

 struct cso_context {
struct pipe_context *pipe;
@@ -74,11 +82,8 @@ struct cso_context {

unsigned saved_state;  /**< bitmask of CSO_BIT_x flags */

-   struct pipe_sampler_view *fragment_views[PIPE_MAX_SHADER_SAMPLER_VIEWS];
-   unsigned nr_fragment_views;
-
-   struct pipe_sampler_view 
*fragment_views_saved[PIPE_MAX_SHADER_SAMPLER_VIEWS];
-   unsigned nr_fragment_views_saved;
+   struct view_info fragment_views_saved;
+   struct view_info views[PIPE_SHADER_TYPES];

struct sampler_info fragment_samplers_saved;
struct sampler_info samplers[PIPE_SHADER_TYPES];
@@ -346,7 +351,7 @@ out:
  */
 void cso_destroy_context( struct cso_context *ctx )
 {
-   unsigned i;
+   unsigned i, j;

if (ctx->pipe) {
   ctx->pipe->set_index_buffer(ctx->pipe, NULL);
@@ -400,9 +405,14 @@ void cso_destroy_context( struct cso_context *ctx )
  ctx->pipe->set_stream_output_targets(ctx->pipe, 0, NULL, NULL);
}

+   for (i = 0; i < PIPE_SHADER_TYPES; i++) {
+  for (j = 0; j < PIPE_MAX_SHADER_SAMPLER_VIEWS; j++) {
+ pipe_sampler_view_reference(>views[i].views[j], NULL);
+  }
+   }
+
for (i = 0; i < PIPE_MAX_SHADER_SAMPLER_VIEWS; i++) {
-  pipe_sampler_view_reference(>fragment_views[i], NULL);
-  pipe_sampler_view_reference(>fragment_views_saved[i], NULL);
+  pipe_sampler_view_reference(>fragment_views_saved.views[i], NULL);
}

util_unreference_framebuffer_state(>fb);
@@ -1348,46 +1358,43 @@ cso_set_sampler_views(struct cso_context *ctx,
   unsigned count,
   struct pipe_sampler_view **views)
 {
-   if (shader_stage == PIPE_SHADER_FRAGMENT) {
-  unsigned i;
-  boolean any_change = FALSE;
-
-  /* reference new views */
-  for (i = 0; i < count; i++) {
- any_change |= ctx->fragment_views[i] != views[i];
- pipe_sampler_view_reference(>fragment_views[i], views[i]);
-  }
-  /* unref extra old views, if any */
-  for (; i < ctx->nr_fragment_views; i++) {
- any_change |= ctx->fragment_views[i] != NULL;
- pipe_sampler_view_reference(>fragment_views[i], NULL);
-  }
+   struct view_info *info = >views[shader_stage];
+   boolean any_change = FALSE;
+   unsigned i;

-  /* bind the new sampler views */
-  if (any_change) {
- ctx->pipe->set_sampler_views(ctx->pipe, shader_stage, 0,
-  MAX2(ctx->nr_fragment_views, count),
-  ctx->fragment_views);
-  }
+   /* reference new views */
+   for (i = 0; i < count; i++) {
+  any_change |= info->views[i] != views[i];
+  pipe_sampler_view_reference(>views[i], views[i]);
+   }
+   /* unref extra old views, if any */
+   for (; i < info->nr_views; i++) {
+  any_change |= info->views[i] != NULL;
+  pipe_sampler_view_reference(>views[i], NULL);
+   }

-  ctx->nr_fragment_views = count;
+   /* bind the new sampler views */
+   if (any_change) {
+  ctx->pipe->set_sampler_views(ctx->pipe, shader_stage, 0,
+   MAX2(info->nr_views, count), info->views);
}
-   else
-  ctx->pipe->set_sampler_views(ctx->pipe, shader_stage, 0, count, views);
+
+   info->nr_views = count;
 }


 static void
 cso_save_fragment_sampler_views(struct cso_context *ctx)
 {
+   struct view_info *info = >views[PIPE_SHADER_FRAGMENT];
+   struct view_info *saved = >fragment_views_saved;
unsigned i;

-   ctx->nr_fragment_views_saved = ctx->nr_fragment_views;
+   saved->nr_views = info->nr_views;

-   for (i = 0; i < ctx->nr_fragment_views; i++) {
-  assert(!ctx->fragment_views_saved[i]);
-  pipe_sampler_view_reference(>fragment_views_saved[i],
-  ctx->fragment_views[i]);
+   for (i = 0; i < info->nr_views; i++) {
+  

Re: [Mesa-dev] [PATCH 0/6] Add support for GL_NV_fill_rectangle

[Marek Olšák]

On Thu, Mar 23, 2017 at 7:45 PM, Lyude Paul  wrote:
> On Thu, 2017-03-23 at 14:22 -0400, Alex Deucher wrote:
>> On Thu, Mar 23, 2017 at 2:18 PM, Marek Olšák 
>> wrote:
>> > Is there any user of this extension?
>>
>> Based on the spec, it seems like it would be useful for glamor.  No
>> idea is anyone has code to use it yet.
> Actually me, robclark and airlied were talking specifically about using
> this for glamor and trying to implement it on other platforms using
> rectangular primitives. No idea if that'll work (especially since I'm
> new here), but it sounds promising enough to try :).
>
> Once I get this patch series upstream I'll probably look into writing
> an implementation for softpipe and some other drivers

Well radeons can't support or emulate the NV extension, so this is all
just for nouveau. I doubt that airlied would want a nouveau-only
codepath in glamor.

Below is my definition of what a hypothetical MESA_rectangle_primitive
should specify. It takes into account all we know about existing
desktop hardware (AMD - we have the hw spec; Intel - I talked with
them; NV - I read the NV fill extension).


Definition and behavior:
- The rectangle primitive is defined by its first 3 vertices.
- The 4th vertex is derived (extrapolated) during rasterization.
- It's treated as a triangle by all stages before rasterization.
- The rectangle edges must be parallel or perpendicular to X and Y
axes, i.e. the rectangle can only be rotated in 90-degree increments
and flipped over.
- It must be rasterized as a rectangle (no diagonal tearing allowed,
no artifacts on the diagonal allowed)
- The content of gl_FrontFacing is undefined.

Return a GL error:
- if clip planes, clip distances, or cull distances are enabled.
- if face culling is enabled. (face determination is undefined)
- if polygon mode is not fill
- if primitive restart is enabled
- if geometry or tessellation shaders are enabled

The behavior is undefined:
- if the rectangle edges are not axis-aligned.
- if Z coordinates of all 3 vertices are not equal.
- if the rectangle intersects the clip space boundaries. (all options
are allowed: clip, cull, or accept the primitive)
- if two-sided lighting is enabled and the colors are not the same for
both sides.

TODO:
- Add piglit to verify that the order of vertices doesn't matter on Intel.


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

Re: [Mesa-dev] [PATCH] glsl_to_tgsi: don't rely on glsl types when visiting tex instructions

[Nicolai Hähnle]

On 23.03.2017 20:17, Samuel Pitoiset wrote:

Instead add is_cube_shadow like is_cube_array.


I'm curious: why? Anyway, looks fine, so

Reviewed-by: Nicolai Hähnle 



Signed-off-by: Samuel Pitoiset 
---
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 5bfcc73a3b..63de74adcb 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -4133,13 +4133,13 @@ glsl_to_tgsi_visitor::visit(ir_texture *ir)
const glsl_type *sampler_type = ir->sampler->type;
unsigned sampler_array_size = 1, sampler_base = 0;
uint16_t sampler_index = 0;
-   bool is_cube_array = false;
+   bool is_cube_array = false, is_cube_shadow = false;
unsigned i;

-   /* if we are a cube array sampler */
-   if ((sampler_type->sampler_dimensionality == GLSL_SAMPLER_DIM_CUBE &&
-sampler_type->sampler_array)) {
-  is_cube_array = true;
+   /* if we are a cube array sampler or a cube shadow */
+   if (sampler_type->sampler_dimensionality == GLSL_SAMPLER_DIM_CUBE) {
+  is_cube_array = sampler_type->sampler_array;
+  is_cube_shadow = sampler_type->sampler_shadow;
}

if (ir->coordinate) {
@@ -4177,8 +4177,7 @@ glsl_to_tgsi_visitor::visit(ir_texture *ir)
   }
   break;
case ir_txb:
-  if (is_cube_array ||
-  sampler_type == glsl_type::samplerCubeShadow_type) {
+  if (is_cube_array || is_cube_shadow) {
  opcode = TGSI_OPCODE_TXB2;
   }
   else {




--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 6/9] isl: Validate the calculated row pitch (v2)

[Jason Ekstrand]

On Wed, Mar 22, 2017 at 6:04 PM, Chad Versace 
wrote:

> Validate that isl_surf::row_pitch fits in the below bitfields,
> if applicable based on isl_surf::usage.
>
> RENDER_SURFACE_STATE::SurfacePitch
> RENDER_SURFACE_STATE::AuxiliarySurfacePitch
> 3DSTATE_DEPTH_BUFFER::SurfacePitch
> 3DSTATE_HIER_DEPTH_BUFFER::SurfacePitch
>
> v2: Add a Makefile dependency on generated header genX_bits.h.
> ---
>  src/intel/Makefile.isl.am |  3 ++
>  src/intel/isl/isl.c   | 72 ++
> +
>  2 files changed, 69 insertions(+), 6 deletions(-)
>
> diff --git a/src/intel/Makefile.isl.am b/src/intel/Makefile.isl.am
> index ee2215df1d1..09a10281b45 100644
> --- a/src/intel/Makefile.isl.am
> +++ b/src/intel/Makefile.isl.am
> @@ -63,6 +63,9 @@ isl/isl_format_layout.c: isl/gen_format_layout.py \
> $(PYTHON_GEN) $(srcdir)/isl/gen_format_layout.py \
> --csv $(srcdir)/isl/isl_format_layout.csv --out $@
>
> +# Dependencies on generated files
> +$(builddir)/isl/isl.o: $(srcdir)/genxml/genX_bits.h
> +
>  # 
> 
>  #  Tests
>  # 
> 
> diff --git a/src/intel/isl/isl.c b/src/intel/isl/isl.c
> index 81f40b6a6fb..f86ca4f9212 100644
> --- a/src/intel/isl/isl.c
> +++ b/src/intel/isl/isl.c
> @@ -25,6 +25,8 @@
>  #include 
>  #include 
>
> +#include "genxml/genX_bits.h"
> +
>  #include "isl.h"
>  #include "isl_gen4.h"
>  #include "isl_gen6.h"
> @@ -1089,18 +1091,74 @@ isl_calc_min_row_pitch(const struct isl_device
> *dev,
> }
>  }
>
> -static uint32_t
> +/**
> + * Is `pitch` in the valid range for a hardware bitfield, if the
> bitfield's
> + * size is `bits` bits?
> + *
> + * Hardware pitch fields are offset by 1. For example, if the size of
> + * RENDER_SURFACE_STATE::SurfacePitch is B bits, then the range of valid
> + * pitches is [1, 2^b] inclusive.  If the surface pitch is N, then
> + * RENDER_SURFACE_STATE::SurfacePitch must be set to N-1.
> + */
> +static bool
> +pitch_in_range(uint32_t n, uint32_t bits)
> +{
> +   assert(n != 0);
> +   return likely(bits != 0 && 1 <= n && n <= (1 << bits));
> +}
> +
> +static bool
>  isl_calc_row_pitch(const struct isl_device *dev,
> const struct isl_surf_init_info *surf_info,
> const struct isl_tile_info *tile_info,
> enum isl_dim_layout dim_layout,
> -   const struct isl_extent2d *phys_slice0_sa)
> +   const struct isl_extent2d *phys_slice0_sa,
> +   uint32_t *out_row_pitch)
>  {
> +   const int gen_10x = gen_get_version_10x(dev->info);
> +
> const uint32_t alignment =
>isl_calc_row_pitch_alignment(surf_info, tile_info);
>
> -   return isl_calc_min_row_pitch(dev, surf_info, tile_info,
> phys_slice0_sa,
> - alignment);
> +   const uint32_t row_pitch =
> +  isl_calc_min_row_pitch(dev, surf_info, tile_info, phys_slice0_sa,
> + alignment);
> +
> +   const uint32_t row_pitch_tiles = row_pitch / tile_info->phys_extent_B.
> width;
> +
> +   if (row_pitch == 0)
> +  return false;
> +
> +   if (dim_layout == ISL_DIM_LAYOUT_GEN9_1D) {
> +  /* SurfacePitch is ignored for this layout.How should we validate
> it? */
> +  isl_finishme("validate row pitch for ISL_DIM_LAYOUT_GEN9_1D");
> +  goto done;
> +   }
> +
> +   if (((surf_info->usage & ISL_SURF_USAGE_RENDER_TARGET_BIT) ||
> +(surf_info->usage & ISL_SURF_USAGE_TEXTURE_BIT)) &&
>

We also want to handle STORAGE_BIT


> +   !pitch_in_range(row_pitch, RENDER_SURFACE_STATE_
> SurfacePitch_bits(gen_10x)))
> +  return false;
> +
> +   if (((surf_info->usage & ISL_SURF_USAGE_CCS_BIT) ||
> +(surf_info->usage & ISL_SURF_USAGE_MCS_BIT)) &&
> +   !pitch_in_range(row_pitch_tiles, RENDER_SURFACE_STATE_
> AuxiliarySurfacePitch_bits(gen_10x)))
> +  return false;
> +
> +   if ((surf_info->usage & ISL_SURF_USAGE_DEPTH_BIT) &&
> +   !pitch_in_range(row_pitch, _3DSTATE_DEPTH_BUFFER_
> SurfacePitch_bits(gen_10x)))
> +  return false;
> +
> +   if ((surf_info->usage & ISL_SURF_USAGE_HIZ_BIT) &&
> +   !pitch_in_range(row_pitch, _3DSTATE_HIER_DEPTH_BUFFER_
> SurfacePitch_bits(gen_10x)))
> +  return false;
> +
> +   if (surf_info->usage & ISL_SURF_USAGE_STENCIL_BIT)
> +  isl_finishme("validate row pitch of stencil surfaces");
>

How hard is this?  I assume it's not trivial or you would have done it.


> +
> + done:
> +   *out_row_pitch = row_pitch;
> +   return true;
>  }
>
>  /**
> @@ -1275,8 +1333,10 @@ isl_surf_init_s(const struct isl_device *dev,
> uint32_t pad_bytes;
> isl_apply_surface_padding(dev, info, _info, _h_el,
> _bytes);
>
> -   const uint32_t row_pitch = isl_calc_row_pitch(dev, info, _info,
> - dim_layout,
> 

Re: [Mesa-dev] [PATCH v4 19/28] i965/vec4: fix SIMD-width lowering for VEC4_OPCODE_FROM_DOUBLE

[Francisco Jerez]

Samuel Iglesias Gonsálvez  writes:

> On Wed, 2017-03-22 at 15:55 -0700, Francisco Jerez wrote:
>> Samuel Iglesias Gonsálvez  writes:
>> 
>> > Now the VEC4_OPCODE_FROM_DOUBLE's destination data is written with
>> > stride 2. We need to take into account this when doing the split
>> > so we don't overwrite data.
>> > 
>> 
>> You should probably fix the destination type of your
>> VEC4_OPCODE_FROM_DOUBLE instructions in PATCH 17 instead so you don't
>> need to special-case VEC4_OPCODE_FROM_DOUBLE in this lowering pass.
>> 
>
> I don't think this would work. Do you mean to set the destination type
> to double, so horiz_offset() works fine here without any change?
>

Yes, double (or 64-bit integer) would be more appropriate than float,
because the opcode writes 64 bit-wide components, so using F as
destination type will inevitably confuse the optimizer.

> Then in the generator's code for VEC4_OPCODE_FROM_DOUBLE, I would need
> to retype the destination to... I don't know to which type because it
> was lost.
>
It would make a lot more sense to rename these after the destination
type (e.g. VEC4_OPCODE_TO_F32), since the conversion origin type is
fully determined by the source type encoded in the IR instruction, but
the destination type is not.

> Sam
>
>> > Signed-off-by: Samuel Iglesias Gonsálvez 
>> > ---
>> >  src/intel/compiler/brw_vec4.cpp | 7 ++-
>> >  1 file changed, 6 insertions(+), 1 deletion(-)
>> > 
>> > diff --git a/src/intel/compiler/brw_vec4.cpp
>> > b/src/intel/compiler/brw_vec4.cpp
>> > index b26f8035811..f4eea954404 100644
>> > --- a/src/intel/compiler/brw_vec4.cpp
>> > +++ b/src/intel/compiler/brw_vec4.cpp
>> > @@ -2198,6 +2198,7 @@ vec4_visitor::lower_simd_width()
>> >   linst->group = channel_offset;
>> >   linst->size_written = size_written;
>> >  
>> > + bool d2f_pass = (inst->opcode == VEC4_OPCODE_FROM_DOUBLE
>> > && n > 0);
>> >   /* Compute split dst region */
>> >   dst_reg dst;
>> >   if (needs_temp) {
>> > @@ -2212,7 +2213,11 @@ vec4_visitor::lower_simd_width()
>> > inst->insert_before(block, copy);
>> >  }
>> >   } else {
>> > -dst = horiz_offset(inst->dst, channel_offset);
>> > +/* d2x conversion is done with a destination's stride
>> > of 2. We need
>> > + * to take into account when splitting it.
>> > + */
>> > +unsigned stride = d2f_pass ? 2 : 1;
>> > +dst = horiz_offset(inst->dst, stride *
>> > channel_offset);
>> >   }
>> >   linst->dst = dst;
>> >  
>> > -- 
>> > 2.11.0
>> > 
>> > ___
>> > mesa-dev mailing list
>> > mesa-dev@lists.freedesktop.org
>> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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 4/9] genxml: Add 3DSTATE_DEPTH_BUFFER to gen5.xml

[Jason Ekstrand]

Matches the docs.

Reviewed-by: Jason Ekstrand 

On Wed, Mar 22, 2017 at 6:03 PM, Chad Versace 
wrote:

> isl will use this for validating the depth buffer pitch.
> ---
>  src/intel/genxml/gen5.xml | 56 ++
> +
>  1 file changed, 56 insertions(+)
>
> diff --git a/src/intel/genxml/gen5.xml b/src/intel/genxml/gen5.xml
> index 39fec3723f6..97c13699673 100644
> --- a/src/intel/genxml/gen5.xml
> +++ b/src/intel/genxml/gen5.xml
> @@ -54,4 +54,60 @@
>  
>  
>
> +
> +  
> +
> +
> + default="3"/>
> + default="3"/>
> + default="1"/>
> + default="5"/>
> +
> +
> +
> +  
> +  
> +  
> +  
> +  
> +
> +
> +
> +  
> +
> + type="uint">
> +  
> +  
> +  
> +
> + type="bool"/>
> + type="bool"/>
> +
> +  
> +  
> +  
> +  
> +  
> +
> +
> +
> + type="address"/>
> +
> +
> +
> +
> +
> +  
> +  
> +
> +
> +
> + type="uint"/>
> + type="uint"/>
> +
> + type="int"/>
> + type="int"/>
> +
> +
> +  
>  
> --
> 2.12.0
>
> ___
> 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] glsl_to_tgsi: don't rely on glsl types when visiting tex instructions

[Samuel Pitoiset]

Instead add is_cube_shadow like is_cube_array.

Signed-off-by: Samuel Pitoiset 
---
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 5bfcc73a3b..63de74adcb 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -4133,13 +4133,13 @@ glsl_to_tgsi_visitor::visit(ir_texture *ir)
const glsl_type *sampler_type = ir->sampler->type;
unsigned sampler_array_size = 1, sampler_base = 0;
uint16_t sampler_index = 0;
-   bool is_cube_array = false;
+   bool is_cube_array = false, is_cube_shadow = false;
unsigned i;
 
-   /* if we are a cube array sampler */
-   if ((sampler_type->sampler_dimensionality == GLSL_SAMPLER_DIM_CUBE &&
-sampler_type->sampler_array)) {
-  is_cube_array = true;
+   /* if we are a cube array sampler or a cube shadow */
+   if (sampler_type->sampler_dimensionality == GLSL_SAMPLER_DIM_CUBE) {
+  is_cube_array = sampler_type->sampler_array;
+  is_cube_shadow = sampler_type->sampler_shadow;
}
 
if (ir->coordinate) {
@@ -4177,8 +4177,7 @@ glsl_to_tgsi_visitor::visit(ir_texture *ir)
   }
   break;
case ir_txb:
-  if (is_cube_array ||
-  sampler_type == glsl_type::samplerCubeShadow_type) {
+  if (is_cube_array || is_cube_shadow) {
  opcode = TGSI_OPCODE_TXB2;
   }
   else {
-- 
2.12.0

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

Re: [Mesa-dev] [PATCH v4 08/28] i965/fs: rename lower_d2x to lower_narrow_conversions

[Francisco Jerez]

Samuel Iglesias Gonsálvez  writes:

> On Wed, 2017-03-22 at 15:49 -0700, Francisco Jerez wrote:
>> I'd rename this to lower_conversions instead since after your
>> previous
>> patch it's going to take care of handling unsupported conversions
>> which
>> aren't necessarily to a narrower type.
>> 
>
> OK. Does this patch get your R-b then?
>

Reviewed-by: Francisco Jerez 

> Sam
>
>> Samuel Iglesias Gonsálvez  writes:
>> 
>> > Signed-off-by: Samuel Iglesias Gonsálvez 
>> > ---
>> >  src/intel/Makefile.sources
>> >   | 2 +-
>> >  src/intel/compiler/brw_fs.cpp 
>> >   | 2 +-
>> >  src/intel/compiler/brw_fs.h   
>> >   | 2 +-
>> >  .../{brw_fs_lower_d2x.cpp =>
>> > brw_fs_lower_narrow_conversions.cpp}   | 2 +-
>> >  4 files changed, 4 insertions(+), 4 deletions(-)
>> >  rename src/intel/compiler/{brw_fs_lower_d2x.cpp =>
>> > brw_fs_lower_narrow_conversions.cpp} (99%)
>> > 
>> > diff --git a/src/intel/Makefile.sources
>> > b/src/intel/Makefile.sources
>> > index 4eaf380492f..a9810887f80 100644
>> > --- a/src/intel/Makefile.sources
>> > +++ b/src/intel/Makefile.sources
>> > @@ -42,7 +42,7 @@ COMPILER_FILES = \
>> >    compiler/brw_fs.h \
>> >    compiler/brw_fs_live_variables.cpp \
>> >    compiler/brw_fs_live_variables.h \
>> > -  compiler/brw_fs_lower_d2x.cpp \
>> > +  compiler/brw_fs_lower_narrow_conversions.cpp \
>> >    compiler/brw_fs_lower_pack.cpp \
>> >    compiler/brw_fs_nir.cpp \
>> >    compiler/brw_fs_reg_allocate.cpp \
>> > diff --git a/src/intel/compiler/brw_fs.cpp
>> > b/src/intel/compiler/brw_fs.cpp
>> > index 8612a83805d..61ac981842e 100644
>> > --- a/src/intel/compiler/brw_fs.cpp
>> > +++ b/src/intel/compiler/brw_fs.cpp
>> > @@ -5740,7 +5740,7 @@ fs_visitor::optimize()
>> >    OPT(dead_code_eliminate);
>> > }
>> >  
>> > -   if (OPT(lower_d2x)) {
>> > +   if (OPT(lower_narrow_conversions)) {
>> >    OPT(opt_copy_propagation);
>> >    OPT(dead_code_eliminate);
>> >    OPT(lower_simd_width);
>> > diff --git a/src/intel/compiler/brw_fs.h
>> > b/src/intel/compiler/brw_fs.h
>> > index f3d36848e54..416397fabcd 100644
>> > --- a/src/intel/compiler/brw_fs.h
>> > +++ b/src/intel/compiler/brw_fs.h
>> > @@ -160,7 +160,7 @@ public:
>> > void lower_uniform_pull_constant_loads();
>> > bool lower_load_payload();
>> > bool lower_pack();
>> > -   bool lower_d2x();
>> > +   bool lower_narrow_conversions();
>> > bool lower_logical_sends();
>> > bool lower_integer_multiplication();
>> > bool lower_minmax();
>> > diff --git a/src/intel/compiler/brw_fs_lower_d2x.cpp
>> > b/src/intel/compiler/brw_fs_lower_narrow_conversions.cpp
>> > similarity index 99%
>> > rename from src/intel/compiler/brw_fs_lower_d2x.cpp
>> > rename to src/intel/compiler/brw_fs_lower_narrow_conversions.cpp
>> > index fa25d313dcd..02a60b07eec 100644
>> > --- a/src/intel/compiler/brw_fs_lower_d2x.cpp
>> > +++ b/src/intel/compiler/brw_fs_lower_narrow_conversions.cpp
>> > @@ -44,7 +44,7 @@ supports_type_conversion(fs_inst *inst) {
>> >  }
>> >  
>> >  bool
>> > -fs_visitor::lower_d2x()
>> > +fs_visitor::lower_narrow_conversions()
>> >  {
>> > bool progress = false;
>> >  
>> > -- 
>> > 2.11.0
>> > 
>> > ___
>> > mesa-dev mailing list
>> > mesa-dev@lists.freedesktop.org
>> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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 v4 07/28] i965/fs: generalize the legalization d2x pass

[Francisco Jerez]

Samuel Iglesias Gonsálvez  writes:

> On Wed, 2017-03-22 at 15:47 -0700, Francisco Jerez wrote:
>> Samuel Iglesias Gonsálvez  writes:
>> 
>> > Generalize it to lower any unsupported narrower conversion.
>> > 
>> > v2 (Curro):
>> > - Add supports_type_conversion()
>> > - Reuse existing intruction instead of cloning it.
>> > - Generalize d2x to narrower and equal size conversions.
>> > 
>> > Signed-off-by: Samuel Iglesias Gonsálvez 
>> > ---
>> >  src/intel/compiler/brw_fs.cpp   | 11 ++--
>> >  src/intel/compiler/brw_fs_lower_d2x.cpp | 97
>> > -
>> >  2 files changed, 77 insertions(+), 31 deletions(-)
>> > 
>> > diff --git a/src/intel/compiler/brw_fs.cpp
>> > b/src/intel/compiler/brw_fs.cpp
>> > index 6da23b17107..8612a83805d 100644
>> > --- a/src/intel/compiler/brw_fs.cpp
>> > +++ b/src/intel/compiler/brw_fs.cpp
>> > @@ -5694,11 +5694,6 @@ fs_visitor::optimize()
>> >    OPT(dead_code_eliminate);
>> > }
>> >  
>> > -   if (OPT(lower_d2x)) {
>> > -  OPT(opt_copy_propagation);
>> > -  OPT(dead_code_eliminate);
>> > -   }
>> > -
>> > OPT(lower_simd_width);
>> >  
>> > /* After SIMD lowering just in case we had to unroll the EOT
>> > send. */
>> > @@ -5745,6 +5740,12 @@ fs_visitor::optimize()
>> >    OPT(dead_code_eliminate);
>> > }
>> >  
>> > +   if (OPT(lower_d2x)) {
>> > +  OPT(opt_copy_propagation);
>> > +  OPT(dead_code_eliminate);
>> > +  OPT(lower_simd_width);
>> > +   }
>> > +
>> > lower_uniform_pull_constant_loads();
>> >  
>> > validate();
>> > diff --git a/src/intel/compiler/brw_fs_lower_d2x.cpp
>> > b/src/intel/compiler/brw_fs_lower_d2x.cpp
>> > index a2db1154615..fa25d313dcd 100644
>> > --- a/src/intel/compiler/brw_fs_lower_d2x.cpp
>> > +++ b/src/intel/compiler/brw_fs_lower_d2x.cpp
>> > @@ -27,47 +27,92 @@
>> >  
>> >  using namespace brw;
>> >  
>> > +static bool
>> > +supports_type_conversion(fs_inst *inst) {
>> 
>> Pointer should be marked const.
>> 
>> > +   switch(inst->opcode) {
>> > +   case BRW_OPCODE_MOV:
>> > +   case SHADER_OPCODE_MOV_INDIRECT:
>> > +  return true;
>> > +   case BRW_OPCODE_SEL:
>> > +  return false;
>> 
>> I suggest you return 'inst->dst.type == get_exec_type_size(inst)'
>> here
>> in order to simplify the logic below and restructure things in a way
>> that allows you to make opcode-specific decisions here based on the
>> actual execution and destination types.
>
> I guess you meant:
>'type_sz(inst->dst.type) == get_exec_type_size(inst)'
>

Uhm, not really, you really want to compare the destination type with
the execution type of the instruction.

> This would make it simpler but we then allow f2d conversion which is
> not allowed for SEL.
>
>> 
>> > +   default:
>> > +  /* FIXME: We assume the opcodes don't explicitly mentioned
>> > +   * before just work fine with arbitrary conversions.
>> > +   */
>> > +  return true;
>> > +   }
>> > +}
>> > +
>> >  bool
>> >  fs_visitor::lower_d2x()
>> >  {
>> > bool progress = false;
>> >  
>> > foreach_block_and_inst_safe(block, fs_inst, inst, cfg) {
>> > -  if (inst->opcode != BRW_OPCODE_MOV)
>> > - continue;
>> > +  bool inst_support_conversion =
>> > supports_type_conversion(inst);
>> > +  bool supported_conversion =
>> > + inst_support_conversion &&
>> > + (get_exec_type_size(inst) != 8 ||
>> > +  type_sz(inst->dst.type) > 4 ||
>> > +  type_sz(inst->dst.type) >= get_exec_type_size(inst));
>> > 
>> > -  if (inst->dst.type != BRW_REGISTER_TYPE_F &&
>> > -  inst->dst.type != BRW_REGISTER_TYPE_D &&
>> > -  inst->dst.type != BRW_REGISTER_TYPE_UD)
>> > +  /* If the conversion is supported or there is no conversion
>> > then
>> > +   * do nothing.
>> > +   */
>> > +  if (supported_conversion ||
>> > +  (!inst_support_conversion && inst->dst.type == inst-
>> > >src[0].type) ||
>> 
>> You should be using the execution type here (and below where you
>> allocate the temp0 and temp1 vgrfs) instead of assuming it matches
>> the
>> type of the first source.  Also I'm not 100% certain that the
>> combination of this conditional continue, the one below, the if/else
>> branches below and the supported_conversion definitions above catch
>> the
>> exact set of cases where you need to apply lowering.  This would be a
>> lot easier to follow (most of the above goes away) if you did
>> something
>> along the lines of:
>> 
>
> OK, thanks.
>
>> > if (supports_type_conversion(inst)) {
>> >    if (get_exec_type_size(inst) == 8 && type_sz(inst->dst.type) <
>> > 8) {
>> >   // Apply strided move workaround...
>> >   progress = true;
>> >    }
>> > } else {
>> >    // Apply general conversion workaround...
>> >    progress = true;
>> > }
>> > +  inst->dst.file == BAD_FILE || inst->src[0].file ==
>> > BAD_FILE)
>> 
>> I don't think the 'inst->dst.file == 

Re: [Mesa-dev] [PATCH 0/6] Add support for GL_NV_fill_rectangle

[Alex Deucher]

On Thu, Mar 23, 2017 at 2:57 PM, Ilia Mirkin  wrote:
> On Thu, Mar 23, 2017 at 2:45 PM, Lyude Paul  wrote:
>> On Thu, 2017-03-23 at 14:22 -0400, Alex Deucher wrote:
>>> On Thu, Mar 23, 2017 at 2:18 PM, Marek Olšák 
>>> wrote:
>>> > Is there any user of this extension?
>>>
>>> Based on the spec, it seems like it would be useful for glamor.  No
>>> idea is anyone has code to use it yet.
>> Actually me, robclark and airlied were talking specifically about using
>> this for glamor and trying to implement it on other platforms using
>> rectangular primitives. No idea if that'll work (especially since I'm
>> new here), but it sounds promising enough to try :).
>>
>> Once I get this patch series upstream I'll probably look into writing
>> an implementation for softpipe and some other drivers
>
> Seems like there are a bunch of ways of achieving the same thing,
> namely a rectangle being drawn:
>  - new rectangle primitive

Didn't Marek send out an RFC for a rectangle interface, at least in
gallium at some point recently?

Alex

>  - NV_fill_rectangle
>  - EXT_window_rectangles or scissors + overdrawn triangle
>
> The latter only works for a single rectangle, but I doubt it's too
> useful to have multiple ones drawn anyways.
>
> I've already implemented EXT_window_rectangles on nouveau, and my
> understanding is that it should be easy on SI+. This support goes back
> to nv50, and with minor modifications to the ext, could go as far back
> as nv30, if not earlier. (As-is it requires something semi-silly which
> prevents implementation there.)
>
> NV_fill_rectangle functionality is only available on GM200+, which are
> quite recent GPUs (GTX 950+). I'm not aware of a way to do rectangle
> primitives on NVIDIA GPUs (i.e. specifying them as 3 points) without
> NV_fill_rectangle functionality. All NVIDIA GPUs do support QUADS, but
> I'm not sure if they're rasterized in one go or two.
>
> None of this is for or against any particular approach, merely
> providing some information.
>
> Cheers,
>
>   -ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/6] Add support for GL_NV_fill_rectangle

[Ilia Mirkin]

On Thu, Mar 23, 2017 at 2:45 PM, Lyude Paul  wrote:
> On Thu, 2017-03-23 at 14:22 -0400, Alex Deucher wrote:
>> On Thu, Mar 23, 2017 at 2:18 PM, Marek Olšák 
>> wrote:
>> > Is there any user of this extension?
>>
>> Based on the spec, it seems like it would be useful for glamor.  No
>> idea is anyone has code to use it yet.
> Actually me, robclark and airlied were talking specifically about using
> this for glamor and trying to implement it on other platforms using
> rectangular primitives. No idea if that'll work (especially since I'm
> new here), but it sounds promising enough to try :).
>
> Once I get this patch series upstream I'll probably look into writing
> an implementation for softpipe and some other drivers

Seems like there are a bunch of ways of achieving the same thing,
namely a rectangle being drawn:
 - new rectangle primitive
 - NV_fill_rectangle
 - EXT_window_rectangles or scissors + overdrawn triangle

The latter only works for a single rectangle, but I doubt it's too
useful to have multiple ones drawn anyways.

I've already implemented EXT_window_rectangles on nouveau, and my
understanding is that it should be easy on SI+. This support goes back
to nv50, and with minor modifications to the ext, could go as far back
as nv30, if not earlier. (As-is it requires something semi-silly which
prevents implementation there.)

NV_fill_rectangle functionality is only available on GM200+, which are
quite recent GPUs (GTX 950+). I'm not aware of a way to do rectangle
primitives on NVIDIA GPUs (i.e. specifying them as 3 points) without
NV_fill_rectangle functionality. All NVIDIA GPUs do support QUADS, but
I'm not sure if they're rasterized in one go or two.

None of this is for or against any particular approach, merely
providing some information.

Cheers,

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

[Mesa-dev] [Bug 77449] Tracker bug for all bugs related to Steam titles

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=77449
Bug 77449 depends on bug 93528, which changed state.

Bug 93528 Summary: GPU hang with Borderlands 2 on X1C3
https://bugs.freedesktop.org/show_bug.cgi?id=93528

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

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

Re: [Mesa-dev] [PATCH 3/9] genxml: New generated header genX_bits.h (v2)

[Jason Ekstrand]

I'm not going to ask you to rewrite it in mako but that's what we should do
in the future. :-)  Someone can rewrite later.  I want things to land. :-)

On Wed, Mar 22, 2017 at 6:03 PM, Chad Versace 
wrote:

> genX_bits.h contains the sizes of bitfields in genxml instructions,
> structures, and registers. It also defines some functions to query those
> sizes.
>
> isl_surf_init() will use the new header to validate that requested
> pitches fit in their destination bitfields.
>
> What's currently in genX_bits.h:
>
>   - For each CONTAINER::Field in gen{n}.xml whose name matches
> /.*Surface(Q?)Pitch_bits$/, genX_bits.h contains the line:
>
>   #define GEN{n}_CONTAINER_Field_bits {number of bits in field}
>
> STREAMOUT fields are omitted because isl doesn't care about them.
>
>   - For each set of macros whose name, after stripping the GEN prefix,
> is the same, genX_bits.h contains the query function:
>
>   static inline uint32_t __attribute__((const))
>   CONTAINER_Field_bits(int gen_10x)
>

If it's practical, I would much rather they just take a devinfo.  The
GENx10 thing is a hack that I don't think we can trust to work
indefinitely.  Also, it makes it much easier for the caller to deal with.

I think Dylan is going to see if he can quickly cook up a mako version and
I'll see how hard devinfo is.  Don't spend time on this yet.

--Jason


>   {
>  switch (gen_10x) {
>  case {n0}: return GEN{n0}_CONTAINER_Field_bits;
>  case {n1}: return GEN{n1}_CONTAINER_Field_bits;
>  ...
>  default: return 0;
>   }
>
> v2: Parse the XML instead of scraping the generated gen*_pack.h headers.
> [for jekstrand]
>
> Jason and I tentatively agreed that I should just hand-write the
> header. But my conscience refused. The XML way is the right way.
> Anyway, the generator script are about the same number of lines (259
> vs 222), so the generator is the clear winner in my opinion.
> ---
>  src/intel/Makefile.genxml.am|   6 +-
>  src/intel/Makefile.sources  |   6 +-
>  src/intel/genxml/.gitignore |   1 +
>  src/intel/genxml/gen_bits_header.py | 259 ++
> ++
>  4 files changed, 270 insertions(+), 2 deletions(-)
>  create mode 100644 src/intel/genxml/gen_bits_header.py
>
> diff --git a/src/intel/Makefile.genxml.am b/src/intel/Makefile.genxml.am
> index 01a02b63b44..4e59a918618 100644
> --- a/src/intel/Makefile.genxml.am
> +++ b/src/intel/Makefile.genxml.am
> @@ -30,7 +30,7 @@ EXTRA_DIST += \
>
>  SUFFIXES = _pack.h _xml.h .xml
>
> -$(GENXML_GENERATED_FILES): genxml/gen_pack_header.py
> +$(GENXML_GENERATED_PACK_FILES): genxml/gen_pack_header.py
>
>  .xml_pack.h:
> $(MKDIR_GEN)
> @@ -42,6 +42,10 @@ $(AUBINATOR_GENERATED_FILES): genxml/gen_zipped_file.py
> $(MKDIR_GEN)
> $(AM_V_GEN) $(PYTHON2) $(srcdir)/genxml/gen_zipped_file.py $< >
> $@ || ($(RM) $@; false)
>
> +genxml/genX_bits.h: genxml/gen_bits_header.py $(GENXML_XML_FILES)
> +   $(MKDIR_GEN)
> +   $(PYTHON_GEN) $< -o $@ $(GENXML_XML_FILES)
> +
>  EXTRA_DIST += \
> genxml/genX_pack.h \
> genxml/gen_macros.h \
> diff --git a/src/intel/Makefile.sources b/src/intel/Makefile.sources
> index 801797d2768..ec43f06a495 100644
> --- a/src/intel/Makefile.sources
> +++ b/src/intel/Makefile.sources
> @@ -117,7 +117,7 @@ GENXML_XML_FILES = \
> genxml/gen8.xml \
> genxml/gen9.xml
>
> -GENXML_GENERATED_FILES = \
> +GENXML_GENERATED_PACK_FILES = \
> genxml/gen4_pack.h \
> genxml/gen45_pack.h \
> genxml/gen5_pack.h \
> @@ -127,6 +127,10 @@ GENXML_GENERATED_FILES = \
> genxml/gen8_pack.h \
> genxml/gen9_pack.h
>
> +GENXML_GENERATED_FILES = \
> +   $(GENXML_GENERATED_PACK_FILES) \
> +   genxml/genX_bits.h
> +
>  AUBINATOR_GENERATED_FILES = \
> genxml/gen6_xml.h \
> genxml/gen7_xml.h \
> diff --git a/src/intel/genxml/.gitignore b/src/intel/genxml/.gitignore
> index c5672b5595c..3e2f1cfa9f0 100644
> --- a/src/intel/genxml/.gitignore
> +++ b/src/intel/genxml/.gitignore
> @@ -1,2 +1,3 @@
> +gen*_bits.h
>  gen*_pack.h
>  gen*_xml.h
> diff --git a/src/intel/genxml/gen_bits_header.py
> b/src/intel/genxml/gen_bits_header.py
> new file mode 100644
> index 000..0315c6251e7
> --- /dev/null
> +++ b/src/intel/genxml/gen_bits_header.py
> @@ -0,0 +1,259 @@
> +#encoding=utf-8
> +
> +from __future__ import (
> +absolute_import, division, print_function, unicode_literals
> +)
> +
> +import argparse
> +import io
> +import os
> +import os.path
> +import re
> +import sys
> +from sys import stdout, stderr
> +from textwrap import dedent
> +import xml.parsers.expat
> +
> +def safe_token(t):
> +t = t.replace(' ', '')
> +if t[0].isdigit():
> +t = '_' + t
> +return t
> +
> +class Gen(object):
> +
> +def __init__(self, z):
> +# Convert potential "major.minor" string
> +z = 

Re: [Mesa-dev] [PATCH 0/6] Add support for GL_NV_fill_rectangle

[Lyude Paul]

On Thu, 2017-03-23 at 14:22 -0400, Alex Deucher wrote:
> On Thu, Mar 23, 2017 at 2:18 PM, Marek Olšák 
> wrote:
> > Is there any user of this extension?
> 
> Based on the spec, it seems like it would be useful for glamor.  No
> idea is anyone has code to use it yet.
Actually me, robclark and airlied were talking specifically about using
this for glamor and trying to implement it on other platforms using
rectangular primitives. No idea if that'll work (especially since I'm
new here), but it sounds promising enough to try :).

Once I get this patch series upstream I'll probably look into writing
an implementation for softpipe and some other drivers
> 
> Alex
> 
> > 
> > Marek
> > 
> > On Thu, Mar 23, 2017 at 4:27 PM, Lyude  wrote:
> > > This adds basic support for GL_NV_fill_rectangle in Gallium,
> > > along with
> > > enabling it for the GM200+ in nouveau. It should be noted this
> > > only
> > > implements the OpenGL 4.3 bits, since we don't have the features
> > > required
> > > yet to add this for OpenGLES.
> > > 
> > > Lyude (6):
> > >   glapi: Add GL_NV_fill_rectangle
> > >   gallium: Add a cap to check if the driver supports
> > > fill_rectangle
> > >   mesa: Add support for GL_NV_fill_rectangle
> > >   gallium/auxiliary: Add NV_fill_rectangle to pipe state
> > >   mesa/st: Add support for NV_fill_rectangle
> > >   nvc0: Add support for NV_fill_rectangle for the GM200+
> > > 
> > >  src/gallium/docs/source/screen.rst   |  4 
> > >  src/gallium/drivers/i915/i915_screen.c   |  1 +
> > >  src/gallium/drivers/llvmpipe/lp_screen.c |  1 +
> > >  src/gallium/drivers/nouveau/nv30/nv30_screen.c   |  1 +
> > >  src/gallium/drivers/nouveau/nv50/nv50_screen.c   |  1 +
> > >  src/gallium/drivers/nouveau/nvc0/nvc0_3d.xml.h   |  3 +++
> > >  src/gallium/drivers/nouveau/nvc0/nvc0_screen.c   |  2 ++
> > >  src/gallium/drivers/nouveau/nvc0/nvc0_state.c|  4 
> > >  src/gallium/drivers/nouveau/nvc0/nvc0_stateobj.h |  2 +-
> > >  src/gallium/drivers/r300/r300_screen.c   |  1 +
> > >  src/gallium/drivers/r600/r600_pipe.c |  1 +
> > >  src/gallium/drivers/radeonsi/si_pipe.c   |  1 +
> > >  src/gallium/drivers/softpipe/sp_screen.c |  1 +
> > >  src/gallium/drivers/svga/svga_screen.c   |  1 +
> > >  src/gallium/drivers/vc4/vc4_screen.c |  1 +
> > >  src/gallium/include/pipe/p_defines.h |  2 ++
> > >  src/gallium/include/pipe/p_state.h   |  4 ++--
> > >  src/mapi/glapi/gen/gl_API.xml|  4 
> > >  src/mesa/main/api_validate.c | 13
> > > +
> > >  src/mesa/main/extensions_table.h |  1 +
> > >  src/mesa/main/mtypes.h   |  1 +
> > >  src/mesa/main/polygon.c  | 15
> > > +--
> > >  src/mesa/state_tracker/st_atom_rasterizer.c  |  2 ++
> > >  src/mesa/state_tracker/st_extensions.c   |  1 +
> > >  24 files changed, 63 insertions(+), 5 deletions(-)
> > > 
> > > --
> > > 2.9.3
> > > 
> > > ___
> > > mesa-dev mailing list
> > > mesa-dev@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> > 
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] cso: store sampler views for all shader stages

[Samuel Pitoiset]

Sampler views were only cached for the fragment shader stage, but
this might help other stages.

This is a small opt which should help civ6 a little bit.

Signed-off-by: Samuel Pitoiset 
---
 src/gallium/auxiliary/cso_cache/cso_context.c | 101 ++
 1 file changed, 55 insertions(+), 46 deletions(-)

diff --git a/src/gallium/auxiliary/cso_cache/cso_context.c 
b/src/gallium/auxiliary/cso_cache/cso_context.c
index 3d3c44cf81..cac1b4e8a5 100644
--- a/src/gallium/auxiliary/cso_cache/cso_context.c
+++ b/src/gallium/auxiliary/cso_cache/cso_context.c
@@ -61,6 +61,14 @@ struct sampler_info
 };
 
 
+/**
+ * Per-shader sampler view information.
+ */
+struct view_info {
+   struct pipe_sampler_view *views[PIPE_MAX_SHADER_SAMPLER_VIEWS];
+   unsigned nr_views;
+};
+
 
 struct cso_context {
struct pipe_context *pipe;
@@ -74,11 +82,8 @@ struct cso_context {
 
unsigned saved_state;  /**< bitmask of CSO_BIT_x flags */
 
-   struct pipe_sampler_view *fragment_views[PIPE_MAX_SHADER_SAMPLER_VIEWS];
-   unsigned nr_fragment_views;
-
-   struct pipe_sampler_view 
*fragment_views_saved[PIPE_MAX_SHADER_SAMPLER_VIEWS];
-   unsigned nr_fragment_views_saved;
+   struct view_info fragment_views_saved;
+   struct view_info views[PIPE_SHADER_TYPES];
 
struct sampler_info fragment_samplers_saved;
struct sampler_info samplers[PIPE_SHADER_TYPES];
@@ -346,7 +351,7 @@ out:
  */
 void cso_destroy_context( struct cso_context *ctx )
 {
-   unsigned i;
+   unsigned i, j;
 
if (ctx->pipe) {
   ctx->pipe->set_index_buffer(ctx->pipe, NULL);
@@ -400,9 +405,14 @@ void cso_destroy_context( struct cso_context *ctx )
  ctx->pipe->set_stream_output_targets(ctx->pipe, 0, NULL, NULL);
}
 
+   for (i = 0; i < PIPE_SHADER_TYPES; i++) {
+  for (j = 0; j < PIPE_MAX_SHADER_SAMPLER_VIEWS; j++) {
+ pipe_sampler_view_reference(>views[i].views[j], NULL);
+  }
+   }
+
for (i = 0; i < PIPE_MAX_SHADER_SAMPLER_VIEWS; i++) {
-  pipe_sampler_view_reference(>fragment_views[i], NULL);
-  pipe_sampler_view_reference(>fragment_views_saved[i], NULL);
+  pipe_sampler_view_reference(>fragment_views_saved.views[i], NULL);
}
 
util_unreference_framebuffer_state(>fb);
@@ -1348,46 +1358,43 @@ cso_set_sampler_views(struct cso_context *ctx,
   unsigned count,
   struct pipe_sampler_view **views)
 {
-   if (shader_stage == PIPE_SHADER_FRAGMENT) {
-  unsigned i;
-  boolean any_change = FALSE;
-
-  /* reference new views */
-  for (i = 0; i < count; i++) {
- any_change |= ctx->fragment_views[i] != views[i];
- pipe_sampler_view_reference(>fragment_views[i], views[i]);
-  }
-  /* unref extra old views, if any */
-  for (; i < ctx->nr_fragment_views; i++) {
- any_change |= ctx->fragment_views[i] != NULL;
- pipe_sampler_view_reference(>fragment_views[i], NULL);
-  }
+   struct view_info *info = >views[shader_stage];
+   boolean any_change = FALSE;
+   unsigned i;
 
-  /* bind the new sampler views */
-  if (any_change) {
- ctx->pipe->set_sampler_views(ctx->pipe, shader_stage, 0,
-  MAX2(ctx->nr_fragment_views, count),
-  ctx->fragment_views);
-  }
+   /* reference new views */
+   for (i = 0; i < count; i++) {
+  any_change |= info->views[i] != views[i];
+  pipe_sampler_view_reference(>views[i], views[i]);
+   }
+   /* unref extra old views, if any */
+   for (; i < info->nr_views; i++) {
+  any_change |= info->views[i] != NULL;
+  pipe_sampler_view_reference(>views[i], NULL);
+   }
 
-  ctx->nr_fragment_views = count;
+   /* bind the new sampler views */
+   if (any_change) {
+  ctx->pipe->set_sampler_views(ctx->pipe, shader_stage, 0,
+   MAX2(info->nr_views, count), info->views);
}
-   else
-  ctx->pipe->set_sampler_views(ctx->pipe, shader_stage, 0, count, views);
+
+   info->nr_views = count;
 }
 
 
 static void
 cso_save_fragment_sampler_views(struct cso_context *ctx)
 {
+   struct view_info *info = >views[PIPE_SHADER_FRAGMENT];
+   struct view_info *saved = >fragment_views_saved;
unsigned i;
 
-   ctx->nr_fragment_views_saved = ctx->nr_fragment_views;
+   saved->nr_views = info->nr_views;
 
-   for (i = 0; i < ctx->nr_fragment_views; i++) {
-  assert(!ctx->fragment_views_saved[i]);
-  pipe_sampler_view_reference(>fragment_views_saved[i],
-  ctx->fragment_views[i]);
+   for (i = 0; i < info->nr_views; i++) {
+  assert(!saved->views[i]);
+  pipe_sampler_view_reference(>views[i], info->views[i]);
}
 }
 
@@ -1395,27 +1402,29 @@ cso_save_fragment_sampler_views(struct cso_context *ctx)
 static void
 cso_restore_fragment_sampler_views(struct cso_context *ctx)
 {
-   unsigned i, nr_saved = ctx->nr_fragment_views_saved;
+   struct view_info *info = 

[Mesa-dev] [PATCH] anv: automake: ensure that the destination directory is created

[Emil Velikov]

From: Emil Velikov 

Some versions of autotools will not create the output directory for
generated sources. Do the safe thing and create it anywhere.

Cc: Dylan Baker 
Cc: Steven Newbury 
Reported-by: Steven Newbury  Fixes:
Fixes: 1610b3dede1 ("anv: don't pass xmlfile via stdin anv_entrypoints_gen.py")
Signed-off-by: Emil Velikov 
---
 src/intel/Makefile.vulkan.am | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/intel/Makefile.vulkan.am b/src/intel/Makefile.vulkan.am
index da1ee93d91c..ba6ab4fc93f 100644
--- a/src/intel/Makefile.vulkan.am
+++ b/src/intel/Makefile.vulkan.am
@@ -25,6 +25,7 @@
 vulkan_api_xml = $(top_srcdir)/src/vulkan/registry/vk.xml
 
 vulkan/anv_entrypoints.c: vulkan/anv_entrypoints_gen.py $(vulkan_api_xml)
+   $(MKDIR_GEN)
$(AM_V_GEN)$(PYTHON2) $(srcdir)/vulkan/anv_entrypoints_gen.py \
--xml $(vulkan_api_xml) --outdir $(builddir)/vulkan
 vulkan/anv_entrypoints.h: vulkan/anv_entrypoints.c
-- 
2.11.1

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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Emil Velikov]

On 21 March 2017 at 05:00, Jonathan Gray  wrote:
> On Tue, Mar 21, 2017 at 08:28:22AM +1100, Timothy Arceri wrote:
>>
>>
>> On 21/03/17 06:39, Emil Velikov wrote:
>> > On 20 March 2017 at 18:30, Matt Turner  wrote:
>> > > On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov  
>> > > wrote:
>> > > > Seems like we ended up all over the place, so let me try afresh.
>> > > >
>> > > > Above all:
>> > > >  - Saying "I don't care" about your users is arrogant - let us _not_
>> > > > do that, please ?
>> > >
>> > > Let's be honest, the OpenBSD is subjecting itself to some pretty
>> > > arbitrary restrictions caused including Mesa in its core: 10+ year old
>> > > GCC,
>> > IIRC Brian was using old MinGW GCC, which was one of the blockers - it
>> > wasn't OpenBSD to blame here ;-)
>>
>> Sorry Emil I probably wasn't clear in our discussion. I sent out patches to
>> switch to GCC 4.8 last Sept (I believe this was needed by RHEL6) [1].
>>
>> Brain jumped in and said "I'm still using the MinGW gcc 4.6 compiler. I'd
>> rather not go through the upgrade hassle if I don't have to."
>>
>> Followed by Jose "We're internally building and shipping Mesa compiled with
>> GCC 4.4 (more specifically 4.4.3).
>>
>> It's fine if you require GCC 4.8 on automake, but please leave support
>> for GCC 4.4.x in SCons."
>>
>> By this point I got bored and moved on. But OpenBSDs GCC is a fork with
>> various features backported, from what I understand Mesa would not build on
>> a real GCC 4.2 release and we should not be using it as a min version. IMO
>> if OpenBSD want to maintain a GCC fork they can handle a patch to downgrade
>> the min GCC version.
>>
>> I believe Jonathan would like us to stick with 4.2 as min but is prepared to
>> deal with it if we move on.
>
> I would like to see Mesa test features it uses in configure rather than
> arbitary versions that are what a certain linux distribution ships with.
> The zlib change for instance didn't reference any specific problems with
> older versions or interfaces required from newer versions.
>
> We have one platform using clang/lld now (arm64) and are likely to move
> others in future where possible.  libtool has to be patched and the Mesa
> configure script regenerated to make this work or Mesa won't build due
> to libtool.m4 looking for specific strings in ld -v produced by bfd
> binutils or gold...
>
> And yes if you change the configure script to check for a newer version
> I'll revert it locally like I did with the zlib one.
>
> As I get the impression no one cares about patches for older GCC I've
> not being sending them to the list, ie
>
> commit d3d340d6026e516cc405a2eb1d925a7a7a467480
> Author: Jonathan Gray 
> Date:   Thu Mar 16 00:30:07 2017 +1100
>
> i965: don't use designated array initialisation
>
> Don't use a form of designated array initialisation that breaks gcc 4.2.1.
>
Jonathan, I think you meant to say:
Using C99 designated initializers is not allowed in C++ code, thus the
compiler may warn or even fail.

>
> Signed-off-by: Jonathan Gray 
>
> diff --git a/src/intel/compiler/brw_vec4_gs_visitor.cpp 
> b/src/intel/compiler/brw_vec4_gs_visitor.cpp
> index 4a8b5be30e..e7a502306e 100644
> --- a/src/intel/compiler/brw_vec4_gs_visitor.cpp
> +++ b/src/intel/compiler/brw_vec4_gs_visitor.cpp
> @@ -585,23 +585,6 @@ vec4_gs_visitor::gs_end_primitive()
> emit(OR(dst_reg(this->control_data_bits), this->control_data_bits, mask));
>  }
>
> -static const GLuint gl_prim_to_hw_prim[GL_TRIANGLE_STRIP_ADJACENCY+1] = {
We already have C helper get_hw_prim_for_gl_prim that we can use instead.
I'll send a patch in a minute.

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

Re: [Mesa-dev] [PATCH 0/6] Add support for GL_NV_fill_rectangle

[Alex Deucher]

On Thu, Mar 23, 2017 at 2:18 PM, Marek Olšák  wrote:
> Is there any user of this extension?

Based on the spec, it seems like it would be useful for glamor.  No
idea is anyone has code to use it yet.

Alex

>
> Marek
>
> On Thu, Mar 23, 2017 at 4:27 PM, Lyude  wrote:
>> This adds basic support for GL_NV_fill_rectangle in Gallium, along with
>> enabling it for the GM200+ in nouveau. It should be noted this only
>> implements the OpenGL 4.3 bits, since we don't have the features required
>> yet to add this for OpenGLES.
>>
>> Lyude (6):
>>   glapi: Add GL_NV_fill_rectangle
>>   gallium: Add a cap to check if the driver supports fill_rectangle
>>   mesa: Add support for GL_NV_fill_rectangle
>>   gallium/auxiliary: Add NV_fill_rectangle to pipe state
>>   mesa/st: Add support for NV_fill_rectangle
>>   nvc0: Add support for NV_fill_rectangle for the GM200+
>>
>>  src/gallium/docs/source/screen.rst   |  4 
>>  src/gallium/drivers/i915/i915_screen.c   |  1 +
>>  src/gallium/drivers/llvmpipe/lp_screen.c |  1 +
>>  src/gallium/drivers/nouveau/nv30/nv30_screen.c   |  1 +
>>  src/gallium/drivers/nouveau/nv50/nv50_screen.c   |  1 +
>>  src/gallium/drivers/nouveau/nvc0/nvc0_3d.xml.h   |  3 +++
>>  src/gallium/drivers/nouveau/nvc0/nvc0_screen.c   |  2 ++
>>  src/gallium/drivers/nouveau/nvc0/nvc0_state.c|  4 
>>  src/gallium/drivers/nouveau/nvc0/nvc0_stateobj.h |  2 +-
>>  src/gallium/drivers/r300/r300_screen.c   |  1 +
>>  src/gallium/drivers/r600/r600_pipe.c |  1 +
>>  src/gallium/drivers/radeonsi/si_pipe.c   |  1 +
>>  src/gallium/drivers/softpipe/sp_screen.c |  1 +
>>  src/gallium/drivers/svga/svga_screen.c   |  1 +
>>  src/gallium/drivers/vc4/vc4_screen.c |  1 +
>>  src/gallium/include/pipe/p_defines.h |  2 ++
>>  src/gallium/include/pipe/p_state.h   |  4 ++--
>>  src/mapi/glapi/gen/gl_API.xml|  4 
>>  src/mesa/main/api_validate.c | 13 +
>>  src/mesa/main/extensions_table.h |  1 +
>>  src/mesa/main/mtypes.h   |  1 +
>>  src/mesa/main/polygon.c  | 15 +--
>>  src/mesa/state_tracker/st_atom_rasterizer.c  |  2 ++
>>  src/mesa/state_tracker/st_extensions.c   |  1 +
>>  24 files changed, 63 insertions(+), 5 deletions(-)
>>
>> --
>> 2.9.3
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/omx/enc: use PIPE_USAGE_STAGING for output buffer

[Marek Olšák]

Please add a comment into the code that PIPE_USAGE_STAGING is used
because the buffer is mapped for read. With that:

Reviewed-by: Marek Olšák 

Marek

On Thu, Mar 23, 2017 at 3:35 PM, Leo Liu  wrote:
> Workaround an unknown bug with inside the transfer_map for certain
> ASIC, also tested with un-affected ASICs, the performance actually
> improved slightly.
>
> Signed-off-by: Leo Liu 
> ---
>  src/gallium/state_trackers/omx/vid_enc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/state_trackers/omx/vid_enc.c 
> b/src/gallium/state_trackers/omx/vid_enc.c
> index b58063e..d40f54e 100644
> --- a/src/gallium/state_trackers/omx/vid_enc.c
> +++ b/src/gallium/state_trackers/omx/vid_enc.c
> @@ -1093,7 +1093,7 @@ static void enc_HandleTask(omx_base_PortType *port, 
> struct encode_task *task,
>
> /* -- allocate output buffer - */
> task->bitstream = pipe_buffer_create(priv->s_pipe->screen, 
> PIPE_BIND_VERTEX_BUFFER,
> -PIPE_USAGE_STREAM, size);
> +PIPE_USAGE_STAGING, size);
>
> picture.picture_type = picture_type;
> picture.pic_order_cnt = task->pic_order_cnt;
> --
> 2.9.3
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/6] Add support for GL_NV_fill_rectangle

[Marek Olšák]

Is there any user of this extension?

Marek

On Thu, Mar 23, 2017 at 4:27 PM, Lyude  wrote:
> This adds basic support for GL_NV_fill_rectangle in Gallium, along with
> enabling it for the GM200+ in nouveau. It should be noted this only
> implements the OpenGL 4.3 bits, since we don't have the features required
> yet to add this for OpenGLES.
>
> Lyude (6):
>   glapi: Add GL_NV_fill_rectangle
>   gallium: Add a cap to check if the driver supports fill_rectangle
>   mesa: Add support for GL_NV_fill_rectangle
>   gallium/auxiliary: Add NV_fill_rectangle to pipe state
>   mesa/st: Add support for NV_fill_rectangle
>   nvc0: Add support for NV_fill_rectangle for the GM200+
>
>  src/gallium/docs/source/screen.rst   |  4 
>  src/gallium/drivers/i915/i915_screen.c   |  1 +
>  src/gallium/drivers/llvmpipe/lp_screen.c |  1 +
>  src/gallium/drivers/nouveau/nv30/nv30_screen.c   |  1 +
>  src/gallium/drivers/nouveau/nv50/nv50_screen.c   |  1 +
>  src/gallium/drivers/nouveau/nvc0/nvc0_3d.xml.h   |  3 +++
>  src/gallium/drivers/nouveau/nvc0/nvc0_screen.c   |  2 ++
>  src/gallium/drivers/nouveau/nvc0/nvc0_state.c|  4 
>  src/gallium/drivers/nouveau/nvc0/nvc0_stateobj.h |  2 +-
>  src/gallium/drivers/r300/r300_screen.c   |  1 +
>  src/gallium/drivers/r600/r600_pipe.c |  1 +
>  src/gallium/drivers/radeonsi/si_pipe.c   |  1 +
>  src/gallium/drivers/softpipe/sp_screen.c |  1 +
>  src/gallium/drivers/svga/svga_screen.c   |  1 +
>  src/gallium/drivers/vc4/vc4_screen.c |  1 +
>  src/gallium/include/pipe/p_defines.h |  2 ++
>  src/gallium/include/pipe/p_state.h   |  4 ++--
>  src/mapi/glapi/gen/gl_API.xml|  4 
>  src/mesa/main/api_validate.c | 13 +
>  src/mesa/main/extensions_table.h |  1 +
>  src/mesa/main/mtypes.h   |  1 +
>  src/mesa/main/polygon.c  | 15 +--
>  src/mesa/state_tracker/st_atom_rasterizer.c  |  2 ++
>  src/mesa/state_tracker/st_extensions.c   |  1 +
>  24 files changed, 63 insertions(+), 5 deletions(-)
>
> --
> 2.9.3
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radeonsi: fix dvec[34] attributes sourced from current attribute state

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Thu, Mar 23, 2017 at 6:14 PM, Nicolai Hähnle  wrote:
> From: Nicolai Hähnle 
>
> The state tracker no longer uploads those attributes for us,
> so we must conservatively upload the size of the largest
> attribute, which is a dvec4.
>
> Fixes a regression of GL45-CTS.gpu_shader_fp64.varyings and
> GL45-CTS.vertex_attrib_64bit.limits_test.
>
> Fixes: 9b91e0b54cc2 ("radeonsi: allow unaligned vertex buffer offsets and 
> strides on CIK-VI")
> ---
>  src/gallium/drivers/radeonsi/si_state.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_state.c 
> b/src/gallium/drivers/radeonsi/si_state.c
> index 6948a74..0ee4af3 100644
> --- a/src/gallium/drivers/radeonsi/si_state.c
> +++ b/src/gallium/drivers/radeonsi/si_state.c
> @@ -3525,26 +3525,27 @@ static void si_set_vertex_buffers(struct pipe_context 
> *ctx,
>
> if (buffers) {
> for (i = 0; i < count; i++) {
> const struct pipe_vertex_buffer *src = buffers + i;
> struct pipe_vertex_buffer *dsti = dst + i;
>
> if (unlikely(src->user_buffer)) {
> /* Zero-stride attribs only. */
> assert(src->stride == 0);
>
> -   /* Assume the attrib has 4 dwords like the vbo
> -* module. This is also a good upper bound.
> +   /* Assume that the user_buffer comes from
> +* gl_current_attrib, which implies it has
> +* 4 * 8 bytes (for dvec4 attributes).
>  *
>  * Use const_uploader to upload into VRAM 
> directly.
>  */
> -   u_upload_data(sctx->b.b.const_uploader, 0, 
> 16, 16,
> +   u_upload_data(sctx->b.b.const_uploader, 0, 
> 32, 32,
>   src->user_buffer,
>   >buffer_offset,
>   >buffer);
> dsti->stride = 0;
> } else {
> struct pipe_resource *buf = src->buffer;
>
> pipe_resource_reference(>buffer, buf);
> dsti->buffer_offset = src->buffer_offset;
> dsti->stride = src->stride;
> --
> 2.9.3
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] anv: enable sampling from fast-cleared images on SKL

[Nanley Chery]

On Thu, Mar 23, 2017 at 12:25:28PM +0100, Samuel Iglesias Gonsálvez wrote:
> A resolve is not needed on Skylake in this case. We were forcing
> a resolve because we set the input_aux_usage to ISL_AUX_USAGE_NONE.
> 
> Signed-off-by: Samuel Iglesias Gonsálvez 
> ---
> 
> This doesn't fix the problem with BDW but I found it while reviewing
> the code.
> 
>  src/intel/vulkan/genX_cmd_buffer.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
> b/src/intel/vulkan/genX_cmd_buffer.c
> index e2364dbfd52..39856b9af7c 100644
> --- a/src/intel/vulkan/genX_cmd_buffer.c
> +++ b/src/intel/vulkan/genX_cmd_buffer.c
> @@ -305,8 +305,8 @@ color_attachment_compute_aux_usage(struct anv_device 
> *device,
>* doesn't also support color compression.
>*/
>   att_state->input_aux_usage = ISL_AUX_USAGE_NONE;
> -  } else if (GEN_GEN == 8) {
> - /* Broadwell can sample from fast-cleared images */
> +  } else if (GEN_GEN >= 8) {
> + /* Broadwell/Skylake can sample from fast-cleared images */
>   att_state->input_aux_usage = ISL_AUX_USAGE_CCS_D;

This doesn't work in all cases. SKL can only sample from CCS_D if the
format is supported for CCS_E.

By the way, I actually have a work-in-progress branch that has a patch to do 
this:
https://cgit.freedesktop.org/~nchery/mesa/commit/?h=ccs-layouts/1-ccsd-layout=e428f44e1835cb00f52848d09350957ef6f73495
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] anv out-of-tree build broken

[Steven Newbury]

The recent changes to anv_entrypoints_gen.py seem to have broken out-of 
-tree builds:

Traceback (most recent call last):
  File 
"/var/tmp/portage/media-libs/mesa--r1/work/Mesa-/src/intel/vulkan/anv_entrypoints_gen.py",
 line 381, in 
main()
  File 
"/var/tmp/portage/media-libs/mesa--r1/work/Mesa-/src/intel/vulkan/anv_entrypoints_gen.py",
 line 373, in main

with open(os.path.join(args.outdir, 'anv_entrypoints.h'), 'wb') as f:
IOError: [Errno 2] No such file or directory: './vulkan/anv_entrypoints.h'

There is no prerequisite before anv_entrypoints.{h,c} is made to create
the vulkan directory in the $(builddir) and the python script doesn't
do so either.

Creating the "vulkan" directory in $(builddir) as the Android makefile
does is sufficient to make it work but it is a bit hacky.


signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Quoting Emil Velikov (2017-03-23 04:39:50)
> On 22 March 2017 at 20:10, Dylan Baker  wrote:
> 
> The more frustrating part is that atm autotools build is "bug-free"
> and with meson will have to go through the same route again :-\

Sure, but if it's easier to get right (which I'm asserting it is), then meson
should pay off in the long run by needing less maintenance to remain "bug-free",
since fewer bugs will be introduced.

> Slightly off-topic - 3 days to write the build script for ~10 [nearly]
> identical libraries which do not do anything fancy, seems a lot.
> Which was the most time consuming part ?

Mostly talking with Matt about which patterns from autotools don't make sense to
port to meson. Also in those 3-4 days were a stab at mesa that made me realize
it was too big a of project for the first go, and picking a smaller, simpler
first project made sense. Honestly the about half of that time was spent reading
autotools documentation to figure out what some of the macros did, and then
reading meson bugs to figure out what the meson equivalent is. I have
familiarity with cmake, but this was the first major work with autotools I've
done. At this point working on Mesa the meson is just coming and I spend a lot
more time reading autotools documentation and asking Matt "What does X do, and
does it have side effects?"

> 
> I'm concerned that we would have to enforce the same time penalty onto
> dozens of developers unfamiliar with meson.

Eric (who as done a lot more autotools than me) said it took him 2 days to
become a more comfortable with meson than autotools, having written autotools
for 10 years. Asking Eric, Daniel Stone, or Peter Hutterer, who all have much
more autotools experience than me, would probably be more useful to answer that
question. I can say this, it took me significantly less time to become fluent
with meson than to become passable with cmake.

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] radeonsi: fix dvec[34] attributes sourced from current attribute state

[Ilia Mirkin]

Ah I see. So we still get 2 vertex attributes, good. This was just
tripping some assumptions in your code about how attributes are laid
out in a constant vertex buffer. I guess I should double-check nouveau
as well, but I think we should be good. I always forget about the
disconnect between attributes and buffers :)

On Thu, Mar 23, 2017 at 1:29 PM, Nicolai Hähnle  wrote:
> On 23.03.2017 18:19, Ilia Mirkin wrote:
>>
>> Wait, you can have constant attribs that are dvec4's? Those don't get
>> split up into multiple constant attribs (2x dvec2, as it would for a
>> regular VBO)? Or am I misunderstanding the circumstances?
>
>
> The draw call will have one vertex buffer for each GL attribute, but the
> attribute is split into two vertex elements, i.e. it occupies two slots in
> the vertex array.
>
> E.g. the CTS has a test where there are 9 vertex buffers and I believe 15
> attributes at the Gallium interface level.
>
> Cheers,
> Nicolai
>
>
>>
>> On Thu, Mar 23, 2017 at 1:14 PM, Nicolai Hähnle 
>> wrote:
>>>
>>> From: Nicolai Hähnle 
>>>
>>> The state tracker no longer uploads those attributes for us,
>>> so we must conservatively upload the size of the largest
>>> attribute, which is a dvec4.
>>>
>>> Fixes a regression of GL45-CTS.gpu_shader_fp64.varyings and
>>> GL45-CTS.vertex_attrib_64bit.limits_test.
>>>
>>> Fixes: 9b91e0b54cc2 ("radeonsi: allow unaligned vertex buffer offsets and
>>> strides on CIK-VI")
>>> ---
>>>  src/gallium/drivers/radeonsi/si_state.c | 7 ---
>>>  1 file changed, 4 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/src/gallium/drivers/radeonsi/si_state.c
>>> b/src/gallium/drivers/radeonsi/si_state.c
>>> index 6948a74..0ee4af3 100644
>>> --- a/src/gallium/drivers/radeonsi/si_state.c
>>> +++ b/src/gallium/drivers/radeonsi/si_state.c
>>> @@ -3525,26 +3525,27 @@ static void si_set_vertex_buffers(struct
>>> pipe_context *ctx,
>>>
>>> if (buffers) {
>>> for (i = 0; i < count; i++) {
>>> const struct pipe_vertex_buffer *src = buffers +
>>> i;
>>> struct pipe_vertex_buffer *dsti = dst + i;
>>>
>>> if (unlikely(src->user_buffer)) {
>>> /* Zero-stride attribs only. */
>>> assert(src->stride == 0);
>>>
>>> -   /* Assume the attrib has 4 dwords like
>>> the vbo
>>> -* module. This is also a good upper
>>> bound.
>>> +   /* Assume that the user_buffer comes from
>>> +* gl_current_attrib, which implies it
>>> has
>>> +* 4 * 8 bytes (for dvec4 attributes).
>>>  *
>>>  * Use const_uploader to upload into VRAM
>>> directly.
>>>  */
>>> -   u_upload_data(sctx->b.b.const_uploader,
>>> 0, 16, 16,
>>> +   u_upload_data(sctx->b.b.const_uploader,
>>> 0, 32, 32,
>>>   src->user_buffer,
>>>   >buffer_offset,
>>>   >buffer);
>>> dsti->stride = 0;
>>> } else {
>>> struct pipe_resource *buf = src->buffer;
>>>
>>> pipe_resource_reference(>buffer,
>>> buf);
>>> dsti->buffer_offset = src->buffer_offset;
>>> dsti->stride = src->stride;
>>> --
>>> 2.9.3
>>>
>>> ___
>>> mesa-dev mailing list
>>> mesa-dev@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
>
> --
> Lerne, wie die Welt wirklich ist,
> Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radeonsi: fix dvec[34] attributes sourced from current attribute state

[Nicolai Hähnle]

On 23.03.2017 18:19, Ilia Mirkin wrote:

Wait, you can have constant attribs that are dvec4's? Those don't get
split up into multiple constant attribs (2x dvec2, as it would for a
regular VBO)? Or am I misunderstanding the circumstances?


The draw call will have one vertex buffer for each GL attribute, but the 
attribute is split into two vertex elements, i.e. it occupies two slots 
in the vertex array.


E.g. the CTS has a test where there are 9 vertex buffers and I believe 
15 attributes at the Gallium interface level.


Cheers,
Nicolai



On Thu, Mar 23, 2017 at 1:14 PM, Nicolai Hähnle  wrote:

From: Nicolai Hähnle 

The state tracker no longer uploads those attributes for us,
so we must conservatively upload the size of the largest
attribute, which is a dvec4.

Fixes a regression of GL45-CTS.gpu_shader_fp64.varyings and
GL45-CTS.vertex_attrib_64bit.limits_test.

Fixes: 9b91e0b54cc2 ("radeonsi: allow unaligned vertex buffer offsets and strides on 
CIK-VI")
---
 src/gallium/drivers/radeonsi/si_state.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_state.c 
b/src/gallium/drivers/radeonsi/si_state.c
index 6948a74..0ee4af3 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -3525,26 +3525,27 @@ static void si_set_vertex_buffers(struct pipe_context 
*ctx,

if (buffers) {
for (i = 0; i < count; i++) {
const struct pipe_vertex_buffer *src = buffers + i;
struct pipe_vertex_buffer *dsti = dst + i;

if (unlikely(src->user_buffer)) {
/* Zero-stride attribs only. */
assert(src->stride == 0);

-   /* Assume the attrib has 4 dwords like the vbo
-* module. This is also a good upper bound.
+   /* Assume that the user_buffer comes from
+* gl_current_attrib, which implies it has
+* 4 * 8 bytes (for dvec4 attributes).
 *
 * Use const_uploader to upload into VRAM 
directly.
 */
-   u_upload_data(sctx->b.b.const_uploader, 0, 16, 
16,
+   u_upload_data(sctx->b.b.const_uploader, 0, 32, 
32,
  src->user_buffer,
  >buffer_offset,
  >buffer);
dsti->stride = 0;
} else {
struct pipe_resource *buf = src->buffer;

pipe_resource_reference(>buffer, buf);
dsti->buffer_offset = src->buffer_offset;
dsti->stride = src->stride;
--
2.9.3

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



--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radeonsi: fix dvec[34] attributes sourced from current attribute state

[Ilia Mirkin]

Wait, you can have constant attribs that are dvec4's? Those don't get
split up into multiple constant attribs (2x dvec2, as it would for a
regular VBO)? Or am I misunderstanding the circumstances?

On Thu, Mar 23, 2017 at 1:14 PM, Nicolai Hähnle  wrote:
> From: Nicolai Hähnle 
>
> The state tracker no longer uploads those attributes for us,
> so we must conservatively upload the size of the largest
> attribute, which is a dvec4.
>
> Fixes a regression of GL45-CTS.gpu_shader_fp64.varyings and
> GL45-CTS.vertex_attrib_64bit.limits_test.
>
> Fixes: 9b91e0b54cc2 ("radeonsi: allow unaligned vertex buffer offsets and 
> strides on CIK-VI")
> ---
>  src/gallium/drivers/radeonsi/si_state.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_state.c 
> b/src/gallium/drivers/radeonsi/si_state.c
> index 6948a74..0ee4af3 100644
> --- a/src/gallium/drivers/radeonsi/si_state.c
> +++ b/src/gallium/drivers/radeonsi/si_state.c
> @@ -3525,26 +3525,27 @@ static void si_set_vertex_buffers(struct pipe_context 
> *ctx,
>
> if (buffers) {
> for (i = 0; i < count; i++) {
> const struct pipe_vertex_buffer *src = buffers + i;
> struct pipe_vertex_buffer *dsti = dst + i;
>
> if (unlikely(src->user_buffer)) {
> /* Zero-stride attribs only. */
> assert(src->stride == 0);
>
> -   /* Assume the attrib has 4 dwords like the vbo
> -* module. This is also a good upper bound.
> +   /* Assume that the user_buffer comes from
> +* gl_current_attrib, which implies it has
> +* 4 * 8 bytes (for dvec4 attributes).
>  *
>  * Use const_uploader to upload into VRAM 
> directly.
>  */
> -   u_upload_data(sctx->b.b.const_uploader, 0, 
> 16, 16,
> +   u_upload_data(sctx->b.b.const_uploader, 0, 
> 32, 32,
>   src->user_buffer,
>   >buffer_offset,
>   >buffer);
> dsti->stride = 0;
> } else {
> struct pipe_resource *buf = src->buffer;
>
> pipe_resource_reference(>buffer, buf);
> dsti->buffer_offset = src->buffer_offset;
> dsti->stride = src->stride;
> --
> 2.9.3
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] radeonsi: fix dvec[34] attributes sourced from current attribute state

[Nicolai Hähnle]

From: Nicolai Hähnle 

The state tracker no longer uploads those attributes for us,
so we must conservatively upload the size of the largest
attribute, which is a dvec4.

Fixes a regression of GL45-CTS.gpu_shader_fp64.varyings and
GL45-CTS.vertex_attrib_64bit.limits_test.

Fixes: 9b91e0b54cc2 ("radeonsi: allow unaligned vertex buffer offsets and 
strides on CIK-VI")
---
 src/gallium/drivers/radeonsi/si_state.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_state.c 
b/src/gallium/drivers/radeonsi/si_state.c
index 6948a74..0ee4af3 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -3525,26 +3525,27 @@ static void si_set_vertex_buffers(struct pipe_context 
*ctx,
 
if (buffers) {
for (i = 0; i < count; i++) {
const struct pipe_vertex_buffer *src = buffers + i;
struct pipe_vertex_buffer *dsti = dst + i;
 
if (unlikely(src->user_buffer)) {
/* Zero-stride attribs only. */
assert(src->stride == 0);
 
-   /* Assume the attrib has 4 dwords like the vbo
-* module. This is also a good upper bound.
+   /* Assume that the user_buffer comes from
+* gl_current_attrib, which implies it has
+* 4 * 8 bytes (for dvec4 attributes).
 *
 * Use const_uploader to upload into VRAM 
directly.
 */
-   u_upload_data(sctx->b.b.const_uploader, 0, 16, 
16,
+   u_upload_data(sctx->b.b.const_uploader, 0, 32, 
32,
  src->user_buffer,
  >buffer_offset,
  >buffer);
dsti->stride = 0;
} else {
struct pipe_resource *buf = src->buffer;
 
pipe_resource_reference(>buffer, buf);
dsti->buffer_offset = src->buffer_offset;
dsti->stride = src->stride;
-- 
2.9.3

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

Re: [Mesa-dev] [PATCH 4/6] gallium/auxiliary: Add NV_fill_rectangle to pipe state

[Brian Paul]

On 03/23/2017 09:27 AM, Lyude wrote:

Signed-off-by: Lyude 
---
  src/gallium/include/pipe/p_defines.h | 1 +
  src/gallium/include/pipe/p_state.h   | 4 ++--
  2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/gallium/include/pipe/p_defines.h 
b/src/gallium/include/pipe/p_defines.h
index 0f0e260..7f781c4 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -133,6 +133,7 @@ enum {
 PIPE_POLYGON_MODE_FILL,
 PIPE_POLYGON_MODE_LINE,
 PIPE_POLYGON_MODE_POINT,
+   PIPE_POLYGON_MODE_FILL_RECTANGLE,
  };

  /** Polygon face specification, eg for culling */
diff --git a/src/gallium/include/pipe/p_state.h 
b/src/gallium/include/pipe/p_state.h
index ce19b92..9591d05 100644
--- a/src/gallium/include/pipe/p_state.h
+++ b/src/gallium/include/pipe/p_state.h
@@ -90,8 +90,8 @@ struct pipe_rasterizer_state
 unsigned clamp_fragment_color:1;
 unsigned front_ccw:1;
 unsigned cull_face:2;  /**< PIPE_FACE_x */
-   unsigned fill_front:2; /**< PIPE_POLYGON_MODE_x */
-   unsigned fill_back:2;  /**< PIPE_POLYGON_MODE_x */
+   unsigned fill_front:3; /**< PIPE_POLYGON_MODE_x */
+   unsigned fill_back:3;  /**< PIPE_POLYGON_MODE_x */
 unsigned offset_point:1;
 unsigned offset_line:1;
 unsigned offset_tri:1;



Are you sure the bitfields need to be widened?  There's four possible 
values for the fill mode now, 0..3 which should fit in two bits.


-Brian

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

Re: [Mesa-dev] [PATCH 3/6] mesa: Add support for GL_NV_fill_rectangle

[Brian Paul]

On 03/23/2017 09:27 AM, Lyude wrote:

Since we don't have the bits required to support this in OpenGLES yet,
this only enables support for OpenGL 4.3.

Signed-off-by: Lyude 
---
  src/mesa/main/api_validate.c | 13 +
  src/mesa/main/extensions_table.h |  1 +
  src/mesa/main/mtypes.h   |  1 +
  src/mesa/main/polygon.c  | 15 +--
  4 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/src/mesa/main/api_validate.c b/src/mesa/main/api_validate.c
index 44d164a..bec6407 100644
--- a/src/mesa/main/api_validate.c
+++ b/src/mesa/main/api_validate.c
@@ -609,6 +609,19 @@ _mesa_valid_prim_mode(struct gl_context *ctx, GLenum mode, 
const char *name)
}
 }

+   /* From the GL_NV_fill_rectangle spec:
+*
+* An INVALID_OPERATION error is generated by Begin or any Draw command if
+* only one of the front and back polygon mode is FILL_RECTANGLE_NV.
+*/
+   if ((ctx->Polygon.FrontMode == GL_FILL_RECTANGLE_NV) !=
+   (ctx->Polygon.BackMode == GL_FILL_RECTANGLE_NV)) {
+  _mesa_error(ctx, GL_INVALID_OPERATION,
+  "GL_NV_fill_rectangle can only be used on both the front "
+  "and back polygon mode, not one or the other");
+  return GL_FALSE;
+   }
+
 return GL_TRUE;
  }

diff --git a/src/mesa/main/extensions_table.h b/src/mesa/main/extensions_table.h
index ec71791..f2eac2b 100644
--- a/src/mesa/main/extensions_table.h
+++ b/src/mesa/main/extensions_table.h
@@ -320,6 +320,7 @@ EXT(NV_conditional_render   , 
NV_conditional_render
  EXT(NV_depth_clamp  , ARB_depth_clamp 
   , GLL, GLC,  x ,  x , 2001)
  EXT(NV_draw_buffers , dummy_true  
   ,  x ,  x ,  x , ES2, 2011)
  EXT(NV_fbo_color_attachments, dummy_true  
   ,  x ,  x ,  x , ES2, 2010)
+EXT(NV_fill_rectangle   , NV_fill_rectangle
  , GLL, GLC,  x ,  x , 2015)
  EXT(NV_fog_distance , NV_fog_distance 
   , GLL,  x ,  x ,  x , 2001)
  EXT(NV_image_formats, ARB_shader_image_load_store 
   ,  x ,  x ,  x ,  31, 2014)
  EXT(NV_light_max_exponent   , dummy_true  
   , GLL,  x ,  x ,  x , 1999)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index be78b96..88b8e2b 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -4016,6 +4016,7 @@ struct gl_extensions
 GLboolean MESA_shader_integer_functions;
 GLboolean MESA_ycbcr_texture;
 GLboolean NV_conditional_render;
+   GLboolean NV_fill_rectangle;
 GLboolean NV_fog_distance;
 GLboolean NV_point_sprite;
 GLboolean NV_primitive_restart;
diff --git a/src/mesa/main/polygon.c b/src/mesa/main/polygon.c
index 60af88f..2b57f36 100644
--- a/src/mesa/main/polygon.c
+++ b/src/mesa/main/polygon.c
@@ -131,8 +131,19 @@ _mesa_PolygonMode( GLenum face, GLenum mode )
_mesa_enum_to_string(face),
_mesa_enum_to_string(mode));

-   if (mode!=GL_POINT && mode!=GL_LINE && mode!=GL_FILL) {
-  _mesa_error( ctx, GL_INVALID_ENUM, "glPolygonMode(mode)" );
+   switch (mode) {
+   case GL_POINT:
+   case GL_LINE:
+   case GL_FILL:
+  break;
+   case GL_FILL_RECTANGLE_NV:
+  if (!ctx->Extensions.NV_fill_rectangle) {
+ _mesa_error(ctx, GL_INVALID_ENUM, "glPolygonMode(mode)");
+ return;
+  }
+  break;
+   default:
+  _mesa_error(ctx, GL_INVALID_ENUM, "glPolygonMode(mode)");
return;
 }


I think that could be simplified a bit:

   switch (mode) {
   case GL_POINT:
   case GL_LINE:
   case GL_FILL:
  break;
   case GL_FILL_RECTANGLE_NV:
  if (ctx->Extensions.NV_fill_rectangle)
 break;
  /* fall-through */
   default:
  _mesa_error(ctx, GL_INVALID_ENUM, "glPolygonMode(mode)");
  return;
   }

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

Re: [Mesa-dev] [PATCH 5/6] mesa/st: Add support for NV_fill_rectangle

[Samuel Pitoiset]

mesa/st -> st/mesa

On 03/23/2017 04:27 PM, Lyude wrote:

Signed-off-by: Lyude 
---
 src/mesa/state_tracker/st_atom_rasterizer.c | 2 ++
 src/mesa/state_tracker/st_extensions.c  | 1 +
 2 files changed, 3 insertions(+)

diff --git a/src/mesa/state_tracker/st_atom_rasterizer.c 
b/src/mesa/state_tracker/st_atom_rasterizer.c
index 50be7b6..0b0e045 100644
--- a/src/mesa/state_tracker/st_atom_rasterizer.c
+++ b/src/mesa/state_tracker/st_atom_rasterizer.c
@@ -50,6 +50,8 @@ static GLuint translate_fill( GLenum mode )
   return PIPE_POLYGON_MODE_LINE;
case GL_FILL:
   return PIPE_POLYGON_MODE_FILL;
+   case GL_FILL_RECTANGLE_NV:
+  return PIPE_POLYGON_MODE_FILL_RECTANGLE;
default:
   assert(0);
   return 0;
diff --git a/src/mesa/state_tracker/st_extensions.c 
b/src/mesa/state_tracker/st_extensions.c
index 16f8685..eefd21d 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -637,6 +637,7 @@ void st_init_extensions(struct pipe_screen *screen,
   { o(ATI_separate_stencil), PIPE_CAP_TWO_SIDED_STENCIL
},
   { o(ATI_texture_mirror_once),  PIPE_CAP_TEXTURE_MIRROR_CLAMP 
},
   { o(NV_conditional_render),PIPE_CAP_CONDITIONAL_RENDER   
},
+  { o(NV_fill_rectangle),
PIPE_CAP_POLYGON_MODE_FILL_RECTANGLE  },
   { o(NV_primitive_restart), PIPE_CAP_PRIMITIVE_RESTART
},
   { o(NV_texture_barrier),   PIPE_CAP_TEXTURE_BARRIER  
},
   { o(NVX_gpu_memory_info),  PIPE_CAP_QUERY_MEMORY_INFO
},


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

Re: [Mesa-dev] [PATCH 0/6] Add support for GL_NV_fill_rectangle

[Samuel Pitoiset]

Nice work!

Usually, gallium bits come *after* mesa ones, like:

mesa:
gallium:
st/mesa:

On 03/23/2017 04:27 PM, Lyude wrote:

This adds basic support for GL_NV_fill_rectangle in Gallium, along with
enabling it for the GM200+ in nouveau. It should be noted this only
implements the OpenGL 4.3 bits, since we don't have the features required
yet to add this for OpenGLES.

Lyude (6):
  glapi: Add GL_NV_fill_rectangle
  gallium: Add a cap to check if the driver supports fill_rectangle
  mesa: Add support for GL_NV_fill_rectangle
  gallium/auxiliary: Add NV_fill_rectangle to pipe state
  mesa/st: Add support for NV_fill_rectangle
  nvc0: Add support for NV_fill_rectangle for the GM200+

 src/gallium/docs/source/screen.rst   |  4 
 src/gallium/drivers/i915/i915_screen.c   |  1 +
 src/gallium/drivers/llvmpipe/lp_screen.c |  1 +
 src/gallium/drivers/nouveau/nv30/nv30_screen.c   |  1 +
 src/gallium/drivers/nouveau/nv50/nv50_screen.c   |  1 +
 src/gallium/drivers/nouveau/nvc0/nvc0_3d.xml.h   |  3 +++
 src/gallium/drivers/nouveau/nvc0/nvc0_screen.c   |  2 ++
 src/gallium/drivers/nouveau/nvc0/nvc0_state.c|  4 
 src/gallium/drivers/nouveau/nvc0/nvc0_stateobj.h |  2 +-
 src/gallium/drivers/r300/r300_screen.c   |  1 +
 src/gallium/drivers/r600/r600_pipe.c |  1 +
 src/gallium/drivers/radeonsi/si_pipe.c   |  1 +
 src/gallium/drivers/softpipe/sp_screen.c |  1 +
 src/gallium/drivers/svga/svga_screen.c   |  1 +
 src/gallium/drivers/vc4/vc4_screen.c |  1 +
 src/gallium/include/pipe/p_defines.h |  2 ++
 src/gallium/include/pipe/p_state.h   |  4 ++--
 src/mapi/glapi/gen/gl_API.xml|  4 
 src/mesa/main/api_validate.c | 13 +
 src/mesa/main/extensions_table.h |  1 +
 src/mesa/main/mtypes.h   |  1 +
 src/mesa/main/polygon.c  | 15 +--
 src/mesa/state_tracker/st_atom_rasterizer.c  |  2 ++
 src/mesa/state_tracker/st_extensions.c   |  1 +
 24 files changed, 63 insertions(+), 5 deletions(-)


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

Re: [Mesa-dev] [PATCH 3/6] mesa: Add support for GL_NV_fill_rectangle

[Samuel Pitoiset]

On 03/23/2017 04:27 PM, Lyude wrote:

Since we don't have the bits required to support this in OpenGLES yet,
this only enables support for OpenGL 4.3.

Signed-off-by: Lyude 
---
 src/mesa/main/api_validate.c | 13 +
 src/mesa/main/extensions_table.h |  1 +
 src/mesa/main/mtypes.h   |  1 +
 src/mesa/main/polygon.c  | 15 +--
 4 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/src/mesa/main/api_validate.c b/src/mesa/main/api_validate.c
index 44d164a..bec6407 100644
--- a/src/mesa/main/api_validate.c
+++ b/src/mesa/main/api_validate.c
@@ -609,6 +609,19 @@ _mesa_valid_prim_mode(struct gl_context *ctx, GLenum mode, 
const char *name)
   }
}

+   /* From the GL_NV_fill_rectangle spec:
+*
+* An INVALID_OPERATION error is generated by Begin or any Draw command if
+* only one of the front and back polygon mode is FILL_RECTANGLE_NV.
+*/


I think usually we do:

/* The GL_NV_fill_rectangle spec says:
 *
 * "And INVALID_OPERATION ...
 *  only one "
 */

Note the extra space. :)


+   if ((ctx->Polygon.FrontMode == GL_FILL_RECTANGLE_NV) !=
+   (ctx->Polygon.BackMode == GL_FILL_RECTANGLE_NV)) {
+  _mesa_error(ctx, GL_INVALID_OPERATION,
+  "GL_NV_fill_rectangle can only be used on both the front "
+  "and back polygon mode, not one or the other");
+  return GL_FALSE;
+   }
+
return GL_TRUE;
 }

diff --git a/src/mesa/main/extensions_table.h b/src/mesa/main/extensions_table.h
index ec71791..f2eac2b 100644
--- a/src/mesa/main/extensions_table.h
+++ b/src/mesa/main/extensions_table.h
@@ -320,6 +320,7 @@ EXT(NV_conditional_render   , 
NV_conditional_render
 EXT(NV_depth_clamp  , ARB_depth_clamp  
  , GLL, GLC,  x ,  x , 2001)
 EXT(NV_draw_buffers , dummy_true   
  ,  x ,  x ,  x , ES2, 2011)
 EXT(NV_fbo_color_attachments, dummy_true   
  ,  x ,  x ,  x , ES2, 2010)
+EXT(NV_fill_rectangle   , NV_fill_rectangle
  , GLL, GLC,  x ,  x , 2015)
 EXT(NV_fog_distance , NV_fog_distance  
  , GLL,  x ,  x ,  x , 2001)
 EXT(NV_image_formats, ARB_shader_image_load_store  
  ,  x ,  x ,  x ,  31, 2014)
 EXT(NV_light_max_exponent   , dummy_true   
  , GLL,  x ,  x ,  x , 1999)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index be78b96..88b8e2b 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -4016,6 +4016,7 @@ struct gl_extensions
GLboolean MESA_shader_integer_functions;
GLboolean MESA_ycbcr_texture;
GLboolean NV_conditional_render;
+   GLboolean NV_fill_rectangle;
GLboolean NV_fog_distance;
GLboolean NV_point_sprite;
GLboolean NV_primitive_restart;
diff --git a/src/mesa/main/polygon.c b/src/mesa/main/polygon.c
index 60af88f..2b57f36 100644
--- a/src/mesa/main/polygon.c
+++ b/src/mesa/main/polygon.c
@@ -131,8 +131,19 @@ _mesa_PolygonMode( GLenum face, GLenum mode )
   _mesa_enum_to_string(face),
   _mesa_enum_to_string(mode));

-   if (mode!=GL_POINT && mode!=GL_LINE && mode!=GL_FILL) {
-  _mesa_error( ctx, GL_INVALID_ENUM, "glPolygonMode(mode)" );
+   switch (mode) {
+   case GL_POINT:
+   case GL_LINE:
+   case GL_FILL:
+  break;
+   case GL_FILL_RECTANGLE_NV:
+  if (!ctx->Extensions.NV_fill_rectangle) {
+ _mesa_error(ctx, GL_INVALID_ENUM, "glPolygonMode(mode)");
+ return;
+  }
+  break;
+   default:
+  _mesa_error(ctx, GL_INVALID_ENUM, "glPolygonMode(mode)");
   return;
}



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

Re: [Mesa-dev] [PATCH 6/6] nvc0: Add support for NV_fill_rectangle for the GM200+

[Ilia Mirkin]

On Thu, Mar 23, 2017 at 11:27 AM, Lyude  wrote:
> This enables support for the GL_NV_fill_rectangle extension on the
> GM200+ for OpenGL 4.3.

For desktop GL. Also please add a note in docs/17.1.0/relnotes.html.

>
> Signed-off-by: Lyude 
> ---
>  src/gallium/drivers/nouveau/nvc0/nvc0_3d.xml.h   | 3 +++
>  src/gallium/drivers/nouveau/nvc0/nvc0_screen.c   | 3 ++-
>  src/gallium/drivers/nouveau/nvc0/nvc0_state.c| 4 
>  src/gallium/drivers/nouveau/nvc0/nvc0_stateobj.h | 2 +-
>  4 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_3d.xml.h 
> b/src/gallium/drivers/nouveau/nvc0/nvc0_3d.xml.h
> index 1be5952..accde94 100644
> --- a/src/gallium/drivers/nouveau/nvc0/nvc0_3d.xml.h
> +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_3d.xml.h
> @@ -772,6 +772,9 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
> SOFTWARE.
>  #define NVC0_3D_VTX_ATTR_MASK_UNK0DD0_ALT__ESIZE   0x0004
>  #define NVC0_3D_VTX_ATTR_MASK_UNK0DD0_ALT__LEN 0x0004
>
> +#define NVC0_3D_FILL_RECTANGLE 0x113c
> +#define NVC0_3D_FILL_RECTANGLE_ENABLE  0x0002
> +
>  #define NVC0_3D_UNK11400x1140
>
>  #define NVC0_3D_UNK11440x1144
> diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c 
> b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
> index 945101b..f0e4e12 100644
> --- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
> +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
> @@ -256,6 +256,8 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum 
> pipe_cap param)
>return nouveau_screen(pscreen)->vram_domain & NOUVEAU_BO_VRAM ? 1 : 0;
> case PIPE_CAP_TGSI_FS_FBFETCH:
>return class_3d >= NVE4_3D_CLASS; /* needs testing on fermi */
> +   case PIPE_CAP_POLYGON_MODE_FILL_RECTANGLE:
> +  return (class_3d >= GM200_3D_CLASS);

Unnecessary parens.

>
> /* unsupported caps */
> case PIPE_CAP_TGSI_FS_COORD_ORIGIN_LOWER_LEFT:
> @@ -285,7 +287,6 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum 
> pipe_cap param)
> case PIPE_CAP_NATIVE_FENCE_FD:
> case PIPE_CAP_GLSL_OPTIMIZE_CONSERVATIVELY:
> case PIPE_CAP_INT64_DIVMOD:
> -   case PIPE_CAP_POLYGON_MODE_FILL_RECTANGLE:
>return 0;
>
> case PIPE_CAP_VENDOR_ID:
> diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_state.c 
> b/src/gallium/drivers/nouveau/nvc0/nvc0_state.c
> index 32233a5..803843b 100644
> --- a/src/gallium/drivers/nouveau/nvc0/nvc0_state.c
> +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_state.c
> @@ -261,6 +261,10 @@ nvc0_rasterizer_state_create(struct pipe_context *pipe,
>  SB_IMMED_3D(so, POINT_SPRITE_ENABLE, cso->point_quad_rasterization);
>  SB_IMMED_3D(so, POINT_SMOOTH_ENABLE, cso->point_smooth);
>
> +SB_IMMED_3D(so, FILL_RECTANGLE,
> +cso->fill_front == PIPE_POLYGON_MODE_FILL_RECTANGLE ?
> +NVC0_3D_FILL_RECTANGLE_ENABLE : 0);
> +

Well *that* was easy :)

>  SB_BEGIN_3D(so, MACRO_POLYGON_MODE_FRONT, 1);
>  SB_DATA(so, nvgl_polygon_mode(cso->fill_front));
>  SB_BEGIN_3D(so, MACRO_POLYGON_MODE_BACK, 1);
> diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_stateobj.h 
> b/src/gallium/drivers/nouveau/nvc0/nvc0_stateobj.h
> index 054b1e7..3006ed6 100644
> --- a/src/gallium/drivers/nouveau/nvc0/nvc0_stateobj.h
> +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_stateobj.h
> @@ -23,7 +23,7 @@ struct nvc0_blend_stateobj {
>  struct nvc0_rasterizer_stateobj {
> struct pipe_rasterizer_state pipe;
> int size;
> -   uint32_t state[42];
> +   uint32_t state[43];
>  };
>
>  struct nvc0_zsa_stateobj {
> --
> 2.9.3
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/6] gallium/auxiliary: Add NV_fill_rectangle to pipe state

[Ilia Mirkin]

On Thu, Mar 23, 2017 at 11:27 AM, Lyude  wrote:
> Signed-off-by: Lyude 
> ---
>  src/gallium/include/pipe/p_defines.h | 1 +
>  src/gallium/include/pipe/p_state.h   | 4 ++--
>  2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/include/pipe/p_defines.h 
> b/src/gallium/include/pipe/p_defines.h
> index 0f0e260..7f781c4 100644
> --- a/src/gallium/include/pipe/p_defines.h
> +++ b/src/gallium/include/pipe/p_defines.h
> @@ -133,6 +133,7 @@ enum {
> PIPE_POLYGON_MODE_FILL,
> PIPE_POLYGON_MODE_LINE,
> PIPE_POLYGON_MODE_POINT,
> +   PIPE_POLYGON_MODE_FILL_RECTANGLE,
>  };
>
>  /** Polygon face specification, eg for culling */
> diff --git a/src/gallium/include/pipe/p_state.h 
> b/src/gallium/include/pipe/p_state.h
> index ce19b92..9591d05 100644
> --- a/src/gallium/include/pipe/p_state.h
> +++ b/src/gallium/include/pipe/p_state.h
> @@ -90,8 +90,8 @@ struct pipe_rasterizer_state
> unsigned clamp_fragment_color:1;
> unsigned front_ccw:1;
> unsigned cull_face:2;  /**< PIPE_FACE_x */
> -   unsigned fill_front:2; /**< PIPE_POLYGON_MODE_x */
> -   unsigned fill_back:2;  /**< PIPE_POLYGON_MODE_x */
> +   unsigned fill_front:3; /**< PIPE_POLYGON_MODE_x */
> +   unsigned fill_back:3;  /**< PIPE_POLYGON_MODE_x */

It's been a while since I've done math, but 4 values should be able to
fit into a 2-bit integer, no?

Also, for the subject, should just be gallium:

> unsigned offset_point:1;
> unsigned offset_line:1;
> unsigned offset_tri:1;
> --
> 2.9.3
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/6] mesa: Add support for GL_NV_fill_rectangle

[Ilia Mirkin]

On Thu, Mar 23, 2017 at 11:27 AM, Lyude  wrote:
> Since we don't have the bits required to support this in OpenGLES yet,
> this only enables support for OpenGL 4.3.

I think the reference to GL 4.3 isn't quite right. Probably meant to
say "Desktop OpenGL". Also, one usually writes it as "OpenGL ES", with
the space.

>
> Signed-off-by: Lyude 
> ---
>  src/mesa/main/api_validate.c | 13 +
>  src/mesa/main/extensions_table.h |  1 +
>  src/mesa/main/mtypes.h   |  1 +
>  src/mesa/main/polygon.c  | 15 +--
>  4 files changed, 28 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/main/api_validate.c b/src/mesa/main/api_validate.c
> index 44d164a..bec6407 100644
> --- a/src/mesa/main/api_validate.c
> +++ b/src/mesa/main/api_validate.c
> @@ -609,6 +609,19 @@ _mesa_valid_prim_mode(struct gl_context *ctx, GLenum 
> mode, const char *name)
>}
> }
>
> +   /* From the GL_NV_fill_rectangle spec:
> +*
> +* An INVALID_OPERATION error is generated by Begin or any Draw command if
> +* only one of the front and back polygon mode is FILL_RECTANGLE_NV.
> +*/
> +   if ((ctx->Polygon.FrontMode == GL_FILL_RECTANGLE_NV) !=
> +   (ctx->Polygon.BackMode == GL_FILL_RECTANGLE_NV)) {
> +  _mesa_error(ctx, GL_INVALID_OPERATION,
> +  "GL_NV_fill_rectangle can only be used on both the front "
> +  "and back polygon mode, not one or the other");
> +  return GL_FALSE;
> +   }

Why is this in the valid_prim_mode check? I don't think this has much
to do with the prim mode. (As an aside, what's supposed to happen if
you draw lines with this polygon mode set... I'm guessing nothing.
Would be good to have a test for that.) Either a separate function or
_mesa_valid_to_render() seem like better candidates.

> +
> return GL_TRUE;
>  }
>
> diff --git a/src/mesa/main/extensions_table.h 
> b/src/mesa/main/extensions_table.h
> index ec71791..f2eac2b 100644
> --- a/src/mesa/main/extensions_table.h
> +++ b/src/mesa/main/extensions_table.h
> @@ -320,6 +320,7 @@ EXT(NV_conditional_render   , 
> NV_conditional_render
>  EXT(NV_depth_clamp  , ARB_depth_clamp
> , GLL, GLC,  x ,  x , 2001)
>  EXT(NV_draw_buffers , dummy_true 
> ,  x ,  x ,  x , ES2, 2011)
>  EXT(NV_fbo_color_attachments, dummy_true 
> ,  x ,  x ,  x , ES2, 2010)
> +EXT(NV_fill_rectangle   , NV_fill_rectangle  
> , GLL, GLC,  x ,  x , 2015)
>  EXT(NV_fog_distance , NV_fog_distance
> , GLL,  x ,  x ,  x , 2001)
>  EXT(NV_image_formats, ARB_shader_image_load_store
> ,  x ,  x ,  x ,  31, 2014)
>  EXT(NV_light_max_exponent   , dummy_true 
> , GLL,  x ,  x ,  x , 1999)
> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
> index be78b96..88b8e2b 100644
> --- a/src/mesa/main/mtypes.h
> +++ b/src/mesa/main/mtypes.h
> @@ -4016,6 +4016,7 @@ struct gl_extensions
> GLboolean MESA_shader_integer_functions;
> GLboolean MESA_ycbcr_texture;
> GLboolean NV_conditional_render;
> +   GLboolean NV_fill_rectangle;
> GLboolean NV_fog_distance;
> GLboolean NV_point_sprite;
> GLboolean NV_primitive_restart;
> diff --git a/src/mesa/main/polygon.c b/src/mesa/main/polygon.c
> index 60af88f..2b57f36 100644
> --- a/src/mesa/main/polygon.c
> +++ b/src/mesa/main/polygon.c
> @@ -131,8 +131,19 @@ _mesa_PolygonMode( GLenum face, GLenum mode )
>_mesa_enum_to_string(face),
>_mesa_enum_to_string(mode));
>
> -   if (mode!=GL_POINT && mode!=GL_LINE && mode!=GL_FILL) {
> -  _mesa_error( ctx, GL_INVALID_ENUM, "glPolygonMode(mode)" );
> +   switch (mode) {
> +   case GL_POINT:
> +   case GL_LINE:
> +   case GL_FILL:
> +  break;
> +   case GL_FILL_RECTANGLE_NV:
> +  if (!ctx->Extensions.NV_fill_rectangle) {
> + _mesa_error(ctx, GL_INVALID_ENUM, "glPolygonMode(mode)");
> + return;
> +  }

Or you could be all sneaky-like and do something like

if (ctx->Extensions.NV_fill_rectangle)
  break;
/* fallthrough */

> +  break;
> +   default:
> +  _mesa_error(ctx, GL_INVALID_ENUM, "glPolygonMode(mode)");
>return;
> }
>
> --
> 2.9.3
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/6] gallium: Add a cap to check if the driver supports fill_rectangle

[Ilia Mirkin]

This misses etnaviv, freedreno, swr, and virgl.

On Thu, Mar 23, 2017 at 11:27 AM, Lyude  wrote:
> Signed-off-by: Lyude 
> ---
>  src/gallium/docs/source/screen.rst | 4 
>  src/gallium/drivers/i915/i915_screen.c | 1 +
>  src/gallium/drivers/llvmpipe/lp_screen.c   | 1 +
>  src/gallium/drivers/nouveau/nv30/nv30_screen.c | 1 +
>  src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 +
>  src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 1 +
>  src/gallium/drivers/r300/r300_screen.c | 1 +
>  src/gallium/drivers/r600/r600_pipe.c   | 1 +
>  src/gallium/drivers/radeonsi/si_pipe.c | 1 +
>  src/gallium/drivers/softpipe/sp_screen.c   | 1 +
>  src/gallium/drivers/svga/svga_screen.c | 1 +
>  src/gallium/drivers/vc4/vc4_screen.c   | 1 +
>  src/gallium/include/pipe/p_defines.h   | 1 +
>  13 files changed, 16 insertions(+)
>
> diff --git a/src/gallium/docs/source/screen.rst 
> b/src/gallium/docs/source/screen.rst
> index 00c9503..c103194 100644
> --- a/src/gallium/docs/source/screen.rst
> +++ b/src/gallium/docs/source/screen.rst
> @@ -376,6 +376,10 @@ The integer capabilities:
>operations are supported.
>  * ``PIPE_CAP_TGSI_TEX_TXF_LZ``: Whether TEX_LZ and TXF_LZ opcodes are
>supported.
> +* ``PIPE_CAP_POLYGON_MODE_FILL_RECTANGLE``: Whether the
> +  PIPE_POLYGON_MODE_FILL_RECTANGLE mode is supported for
> +  ``pipe_rasterizer_state::fill_front`` and
> +  ``pipe_rasterizer_state::fill_back``.
>
>
>  .. _pipe_capf:
> diff --git a/src/gallium/drivers/i915/i915_screen.c 
> b/src/gallium/drivers/i915/i915_screen.c
> index d25c2b3..28be7a9 100644
> --- a/src/gallium/drivers/i915/i915_screen.c
> +++ b/src/gallium/drivers/i915/i915_screen.c
> @@ -278,6 +278,7 @@ i915_get_param(struct pipe_screen *screen, enum pipe_cap 
> cap)
> case PIPE_CAP_MAX_WINDOW_RECTANGLES:
> case PIPE_CAP_POLYGON_OFFSET_UNITS_UNSCALED:
> case PIPE_CAP_TGSI_ARRAY_COMPONENTS:
> +   case PIPE_CAP_POLYGON_MODE_FILL_RECTANGLE:
>return 0;
>
> case PIPE_CAP_MAX_DUAL_SOURCE_RENDER_TARGETS:
> diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c 
> b/src/gallium/drivers/llvmpipe/lp_screen.c
> index f6ac9b6..d4d04d4 100644
> --- a/src/gallium/drivers/llvmpipe/lp_screen.c
> +++ b/src/gallium/drivers/llvmpipe/lp_screen.c
> @@ -347,6 +347,7 @@ llvmpipe_get_param(struct pipe_screen *screen, enum 
> pipe_cap param)
> case PIPE_CAP_GLSL_OPTIMIZE_CONSERVATIVELY:
> case PIPE_CAP_TGSI_FS_FBFETCH:
> case PIPE_CAP_TGSI_MUL_ZERO_WINS:
> +   case PIPE_CAP_POLYGON_MODE_FILL_RECTANGLE:
>return 0;
> }
> /* should only get here on unhandled cases */
> diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c 
> b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
> index 5c7ae24..be73cf0 100644
> --- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
> +++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
> @@ -211,6 +211,7 @@ nv30_screen_get_param(struct pipe_screen *pscreen, enum 
> pipe_cap param)
> case PIPE_CAP_INT64:
> case PIPE_CAP_INT64_DIVMOD:
> case PIPE_CAP_TGSI_TEX_TXF_LZ:
> +   case PIPE_CAP_POLYGON_MODE_FILL_RECTANGLE:
>return 0;
>
> case PIPE_CAP_VENDOR_ID:
> diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.c 
> b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
> index 249947a..ee33936 100644
> --- a/src/gallium/drivers/nouveau/nv50/nv50_screen.c
> +++ b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
> @@ -263,6 +263,7 @@ nv50_screen_get_param(struct pipe_screen *pscreen, enum 
> pipe_cap param)
> case PIPE_CAP_DOUBLES:
> case PIPE_CAP_INT64:
> case PIPE_CAP_INT64_DIVMOD:
> +   case PIPE_CAP_POLYGON_MODE_FILL_RECTANGLE:
>return 0;
>
> case PIPE_CAP_VENDOR_ID:
> diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c 
> b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
> index cfe4f67..945101b 100644
> --- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
> +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
> @@ -285,6 +285,7 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum 
> pipe_cap param)
> case PIPE_CAP_NATIVE_FENCE_FD:
> case PIPE_CAP_GLSL_OPTIMIZE_CONSERVATIVELY:
> case PIPE_CAP_INT64_DIVMOD:
> +   case PIPE_CAP_POLYGON_MODE_FILL_RECTANGLE:
>return 0;
>
> case PIPE_CAP_VENDOR_ID:
> diff --git a/src/gallium/drivers/r300/r300_screen.c 
> b/src/gallium/drivers/r300/r300_screen.c
> index 07a09d5..9138091 100644
> --- a/src/gallium/drivers/r300/r300_screen.c
> +++ b/src/gallium/drivers/r300/r300_screen.c
> @@ -233,6 +233,7 @@ static int r300_get_param(struct pipe_screen* pscreen, 
> enum pipe_cap param)
>  case PIPE_CAP_INT64:
>  case PIPE_CAP_INT64_DIVMOD:
>  case PIPE_CAP_TGSI_TEX_TXF_LZ:
> +case PIPE_CAP_POLYGON_MODE_FILL_RECTANGLE:
>  return 0;
>
>  /* SWTCL-only features. */
> diff --git a/src/gallium/drivers/r600/r600_pipe.c 
> 

Re: [Mesa-dev] [RFC 00/11] GL_ARB_gpu_shader_fp64

[Alex Deucher]

On Thu, Mar 23, 2017 at 11:51 AM, tournier.elie  wrote:
> Hello,
>
> It's seems impossible to expose all the drivers to soft fp64 with one
> piece of code.
> So what do you think about landing this series (with some fix) for r600?
>
> The other drivers will use the NIR version of soft fp64.
> BTW, an "alpha RFC" series is coming on the ML soonish.

Sounds good to me.

Thanks,

Alex


>
> Elie
>
> On 13 March 2017 at 17:00, tournier.elie  wrote:
>> To resume, using NIR resolve some troubles: fp64 can be use by Intel,
>> no autogen code, SPIR-V on OpenGL.
>> So if nobody opposes (too hard), i will start implement fp64 in NIR.
>>
>> But NIR doesn't solve everything. How to handle drivers without NIR
>> support like r600? Should we land the GLSL IR version of fp64 for
>> that?
>> I know this imply code duplication but at least GL_ARB_gpu_shader_fp64
>> will be available for r600.
>>
>> On 11 March 2017 at 18:51, Jason Ekstrand  wrote:
>>> On Sat, Mar 11, 2017 at 9:50 AM, Jason Ekstrand 
>>> wrote:


 As I said at the top, I'm really not going for NIR or nothing.  I agree
 that GLSL has advantages for chips like r600 which badly needs emulation 
 and
 isn't moving to NIR any time soon.  Also, fp64 isn't a requirement in 
 Vulkan
 and, given that Vulkan covers both desktop and mobile, likely won't be any
 time soon.  (In fact, if someone wanted Vulkan FP64 on hardware that didn't
 support it, I'd be tempted to tell them to pay someone to write a layer.)
 However, *if* we decide that emulated fp64 is better on, for instance Ivy
 Bridge, *and* we had customers that cared about it (I don't know of any),
 then doing it in NIR could yield substantially better results (depending on
 initial shader quality) due to being able to run nir_opt_algebraic first.
 Those are a lot of ifs so maybe I'm suggesting we design for a 
 non-use-case,
 but I really don't want to paint ourselves into a corner that we have to
 crawl out of 2 years from now.
>>>
>>>
>>> Chatting with people on IRC this morning, I realized there's a killer
>>> argument for why we *need* NIR support: SPIR-V on OpenGL.  As soon as you
>>> expose the GL_ARB_spirv extension on an OpenGL 4.0+ driver, you must support
>>> fp64.  If we ever need emulated fp64 in such a driver, the lowering has to
>>> be done in NIR because there is no GLSL IR in the path.
> ___
> 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] [RFC 00/11] GL_ARB_gpu_shader_fp64

[tournier.elie]

Hello,

It's seems impossible to expose all the drivers to soft fp64 with one
piece of code.
So what do you think about landing this series (with some fix) for r600?

The other drivers will use the NIR version of soft fp64.
BTW, an "alpha RFC" series is coming on the ML soonish.

Elie

On 13 March 2017 at 17:00, tournier.elie  wrote:
> To resume, using NIR resolve some troubles: fp64 can be use by Intel,
> no autogen code, SPIR-V on OpenGL.
> So if nobody opposes (too hard), i will start implement fp64 in NIR.
>
> But NIR doesn't solve everything. How to handle drivers without NIR
> support like r600? Should we land the GLSL IR version of fp64 for
> that?
> I know this imply code duplication but at least GL_ARB_gpu_shader_fp64
> will be available for r600.
>
> On 11 March 2017 at 18:51, Jason Ekstrand  wrote:
>> On Sat, Mar 11, 2017 at 9:50 AM, Jason Ekstrand 
>> wrote:
>>>
>>>
>>> As I said at the top, I'm really not going for NIR or nothing.  I agree
>>> that GLSL has advantages for chips like r600 which badly needs emulation and
>>> isn't moving to NIR any time soon.  Also, fp64 isn't a requirement in Vulkan
>>> and, given that Vulkan covers both desktop and mobile, likely won't be any
>>> time soon.  (In fact, if someone wanted Vulkan FP64 on hardware that didn't
>>> support it, I'd be tempted to tell them to pay someone to write a layer.)
>>> However, *if* we decide that emulated fp64 is better on, for instance Ivy
>>> Bridge, *and* we had customers that cared about it (I don't know of any),
>>> then doing it in NIR could yield substantially better results (depending on
>>> initial shader quality) due to being able to run nir_opt_algebraic first.
>>> Those are a lot of ifs so maybe I'm suggesting we design for a non-use-case,
>>> but I really don't want to paint ourselves into a corner that we have to
>>> crawl out of 2 years from now.
>>
>>
>> Chatting with people on IRC this morning, I realized there's a killer
>> argument for why we *need* NIR support: SPIR-V on OpenGL.  As soon as you
>> expose the GL_ARB_spirv extension on an OpenGL 4.0+ driver, you must support
>> fp64.  If we ever need emulated fp64 in such a driver, the lowering has to
>> be done in NIR because there is no GLSL IR in the path.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 5/6] mesa/st: Add support for NV_fill_rectangle

[Lyude]

Signed-off-by: Lyude 
---
 src/mesa/state_tracker/st_atom_rasterizer.c | 2 ++
 src/mesa/state_tracker/st_extensions.c  | 1 +
 2 files changed, 3 insertions(+)

diff --git a/src/mesa/state_tracker/st_atom_rasterizer.c 
b/src/mesa/state_tracker/st_atom_rasterizer.c
index 50be7b6..0b0e045 100644
--- a/src/mesa/state_tracker/st_atom_rasterizer.c
+++ b/src/mesa/state_tracker/st_atom_rasterizer.c
@@ -50,6 +50,8 @@ static GLuint translate_fill( GLenum mode )
   return PIPE_POLYGON_MODE_LINE;
case GL_FILL:
   return PIPE_POLYGON_MODE_FILL;
+   case GL_FILL_RECTANGLE_NV:
+  return PIPE_POLYGON_MODE_FILL_RECTANGLE;
default:
   assert(0);
   return 0;
diff --git a/src/mesa/state_tracker/st_extensions.c 
b/src/mesa/state_tracker/st_extensions.c
index 16f8685..eefd21d 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -637,6 +637,7 @@ void st_init_extensions(struct pipe_screen *screen,
   { o(ATI_separate_stencil), PIPE_CAP_TWO_SIDED_STENCIL
},
   { o(ATI_texture_mirror_once),  PIPE_CAP_TEXTURE_MIRROR_CLAMP 
},
   { o(NV_conditional_render),PIPE_CAP_CONDITIONAL_RENDER   
},
+  { o(NV_fill_rectangle),
PIPE_CAP_POLYGON_MODE_FILL_RECTANGLE  },
   { o(NV_primitive_restart), PIPE_CAP_PRIMITIVE_RESTART
},
   { o(NV_texture_barrier),   PIPE_CAP_TEXTURE_BARRIER  
},
   { o(NVX_gpu_memory_info),  PIPE_CAP_QUERY_MEMORY_INFO
},
-- 
2.9.3

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

[Mesa-dev] [PATCH 6/6] nvc0: Add support for NV_fill_rectangle for the GM200+

[Lyude]

This enables support for the GL_NV_fill_rectangle extension on the
GM200+ for OpenGL 4.3.

Signed-off-by: Lyude 
---
 src/gallium/drivers/nouveau/nvc0/nvc0_3d.xml.h   | 3 +++
 src/gallium/drivers/nouveau/nvc0/nvc0_screen.c   | 3 ++-
 src/gallium/drivers/nouveau/nvc0/nvc0_state.c| 4 
 src/gallium/drivers/nouveau/nvc0/nvc0_stateobj.h | 2 +-
 4 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_3d.xml.h 
b/src/gallium/drivers/nouveau/nvc0/nvc0_3d.xml.h
index 1be5952..accde94 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_3d.xml.h
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_3d.xml.h
@@ -772,6 +772,9 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
SOFTWARE.
 #define NVC0_3D_VTX_ATTR_MASK_UNK0DD0_ALT__ESIZE   0x0004
 #define NVC0_3D_VTX_ATTR_MASK_UNK0DD0_ALT__LEN 0x0004
 
+#define NVC0_3D_FILL_RECTANGLE 0x113c
+#define NVC0_3D_FILL_RECTANGLE_ENABLE  0x0002
+
 #define NVC0_3D_UNK11400x1140
 
 #define NVC0_3D_UNK11440x1144
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
index 945101b..f0e4e12 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
@@ -256,6 +256,8 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
   return nouveau_screen(pscreen)->vram_domain & NOUVEAU_BO_VRAM ? 1 : 0;
case PIPE_CAP_TGSI_FS_FBFETCH:
   return class_3d >= NVE4_3D_CLASS; /* needs testing on fermi */
+   case PIPE_CAP_POLYGON_MODE_FILL_RECTANGLE:
+  return (class_3d >= GM200_3D_CLASS);
 
/* unsupported caps */
case PIPE_CAP_TGSI_FS_COORD_ORIGIN_LOWER_LEFT:
@@ -285,7 +287,6 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
case PIPE_CAP_NATIVE_FENCE_FD:
case PIPE_CAP_GLSL_OPTIMIZE_CONSERVATIVELY:
case PIPE_CAP_INT64_DIVMOD:
-   case PIPE_CAP_POLYGON_MODE_FILL_RECTANGLE:
   return 0;
 
case PIPE_CAP_VENDOR_ID:
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_state.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_state.c
index 32233a5..803843b 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_state.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_state.c
@@ -261,6 +261,10 @@ nvc0_rasterizer_state_create(struct pipe_context *pipe,
 SB_IMMED_3D(so, POINT_SPRITE_ENABLE, cso->point_quad_rasterization);
 SB_IMMED_3D(so, POINT_SMOOTH_ENABLE, cso->point_smooth);
 
+SB_IMMED_3D(so, FILL_RECTANGLE,
+cso->fill_front == PIPE_POLYGON_MODE_FILL_RECTANGLE ?
+NVC0_3D_FILL_RECTANGLE_ENABLE : 0);
+
 SB_BEGIN_3D(so, MACRO_POLYGON_MODE_FRONT, 1);
 SB_DATA(so, nvgl_polygon_mode(cso->fill_front));
 SB_BEGIN_3D(so, MACRO_POLYGON_MODE_BACK, 1);
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_stateobj.h 
b/src/gallium/drivers/nouveau/nvc0/nvc0_stateobj.h
index 054b1e7..3006ed6 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_stateobj.h
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_stateobj.h
@@ -23,7 +23,7 @@ struct nvc0_blend_stateobj {
 struct nvc0_rasterizer_stateobj {
struct pipe_rasterizer_state pipe;
int size;
-   uint32_t state[42];
+   uint32_t state[43];
 };
 
 struct nvc0_zsa_stateobj {
-- 
2.9.3

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

[Mesa-dev] [PATCH 4/6] gallium/auxiliary: Add NV_fill_rectangle to pipe state

[Lyude]

Signed-off-by: Lyude 
---
 src/gallium/include/pipe/p_defines.h | 1 +
 src/gallium/include/pipe/p_state.h   | 4 ++--
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/gallium/include/pipe/p_defines.h 
b/src/gallium/include/pipe/p_defines.h
index 0f0e260..7f781c4 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -133,6 +133,7 @@ enum {
PIPE_POLYGON_MODE_FILL,
PIPE_POLYGON_MODE_LINE,
PIPE_POLYGON_MODE_POINT,
+   PIPE_POLYGON_MODE_FILL_RECTANGLE,
 };
 
 /** Polygon face specification, eg for culling */
diff --git a/src/gallium/include/pipe/p_state.h 
b/src/gallium/include/pipe/p_state.h
index ce19b92..9591d05 100644
--- a/src/gallium/include/pipe/p_state.h
+++ b/src/gallium/include/pipe/p_state.h
@@ -90,8 +90,8 @@ struct pipe_rasterizer_state
unsigned clamp_fragment_color:1;
unsigned front_ccw:1;
unsigned cull_face:2;  /**< PIPE_FACE_x */
-   unsigned fill_front:2; /**< PIPE_POLYGON_MODE_x */
-   unsigned fill_back:2;  /**< PIPE_POLYGON_MODE_x */
+   unsigned fill_front:3; /**< PIPE_POLYGON_MODE_x */
+   unsigned fill_back:3;  /**< PIPE_POLYGON_MODE_x */
unsigned offset_point:1;
unsigned offset_line:1;
unsigned offset_tri:1;
-- 
2.9.3

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

[Mesa-dev] [PATCH 3/6] mesa: Add support for GL_NV_fill_rectangle

[Lyude]

Since we don't have the bits required to support this in OpenGLES yet,
this only enables support for OpenGL 4.3.

Signed-off-by: Lyude 
---
 src/mesa/main/api_validate.c | 13 +
 src/mesa/main/extensions_table.h |  1 +
 src/mesa/main/mtypes.h   |  1 +
 src/mesa/main/polygon.c  | 15 +--
 4 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/src/mesa/main/api_validate.c b/src/mesa/main/api_validate.c
index 44d164a..bec6407 100644
--- a/src/mesa/main/api_validate.c
+++ b/src/mesa/main/api_validate.c
@@ -609,6 +609,19 @@ _mesa_valid_prim_mode(struct gl_context *ctx, GLenum mode, 
const char *name)
   }
}
 
+   /* From the GL_NV_fill_rectangle spec:
+*
+* An INVALID_OPERATION error is generated by Begin or any Draw command if
+* only one of the front and back polygon mode is FILL_RECTANGLE_NV.
+*/
+   if ((ctx->Polygon.FrontMode == GL_FILL_RECTANGLE_NV) !=
+   (ctx->Polygon.BackMode == GL_FILL_RECTANGLE_NV)) {
+  _mesa_error(ctx, GL_INVALID_OPERATION,
+  "GL_NV_fill_rectangle can only be used on both the front "
+  "and back polygon mode, not one or the other");
+  return GL_FALSE;
+   }
+
return GL_TRUE;
 }
 
diff --git a/src/mesa/main/extensions_table.h b/src/mesa/main/extensions_table.h
index ec71791..f2eac2b 100644
--- a/src/mesa/main/extensions_table.h
+++ b/src/mesa/main/extensions_table.h
@@ -320,6 +320,7 @@ EXT(NV_conditional_render   , 
NV_conditional_render
 EXT(NV_depth_clamp  , ARB_depth_clamp  
  , GLL, GLC,  x ,  x , 2001)
 EXT(NV_draw_buffers , dummy_true   
  ,  x ,  x ,  x , ES2, 2011)
 EXT(NV_fbo_color_attachments, dummy_true   
  ,  x ,  x ,  x , ES2, 2010)
+EXT(NV_fill_rectangle   , NV_fill_rectangle
  , GLL, GLC,  x ,  x , 2015)
 EXT(NV_fog_distance , NV_fog_distance  
  , GLL,  x ,  x ,  x , 2001)
 EXT(NV_image_formats, ARB_shader_image_load_store  
  ,  x ,  x ,  x ,  31, 2014)
 EXT(NV_light_max_exponent   , dummy_true   
  , GLL,  x ,  x ,  x , 1999)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index be78b96..88b8e2b 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -4016,6 +4016,7 @@ struct gl_extensions
GLboolean MESA_shader_integer_functions;
GLboolean MESA_ycbcr_texture;
GLboolean NV_conditional_render;
+   GLboolean NV_fill_rectangle;
GLboolean NV_fog_distance;
GLboolean NV_point_sprite;
GLboolean NV_primitive_restart;
diff --git a/src/mesa/main/polygon.c b/src/mesa/main/polygon.c
index 60af88f..2b57f36 100644
--- a/src/mesa/main/polygon.c
+++ b/src/mesa/main/polygon.c
@@ -131,8 +131,19 @@ _mesa_PolygonMode( GLenum face, GLenum mode )
   _mesa_enum_to_string(face),
   _mesa_enum_to_string(mode));
 
-   if (mode!=GL_POINT && mode!=GL_LINE && mode!=GL_FILL) {
-  _mesa_error( ctx, GL_INVALID_ENUM, "glPolygonMode(mode)" );
+   switch (mode) {
+   case GL_POINT:
+   case GL_LINE:
+   case GL_FILL:
+  break;
+   case GL_FILL_RECTANGLE_NV:
+  if (!ctx->Extensions.NV_fill_rectangle) {
+ _mesa_error(ctx, GL_INVALID_ENUM, "glPolygonMode(mode)");
+ return;
+  }
+  break;
+   default:
+  _mesa_error(ctx, GL_INVALID_ENUM, "glPolygonMode(mode)");
   return;
}
 
-- 
2.9.3

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

[Mesa-dev] [PATCH 2/6] gallium: Add a cap to check if the driver supports fill_rectangle

[Lyude]

Signed-off-by: Lyude 
---
 src/gallium/docs/source/screen.rst | 4 
 src/gallium/drivers/i915/i915_screen.c | 1 +
 src/gallium/drivers/llvmpipe/lp_screen.c   | 1 +
 src/gallium/drivers/nouveau/nv30/nv30_screen.c | 1 +
 src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 +
 src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 1 +
 src/gallium/drivers/r300/r300_screen.c | 1 +
 src/gallium/drivers/r600/r600_pipe.c   | 1 +
 src/gallium/drivers/radeonsi/si_pipe.c | 1 +
 src/gallium/drivers/softpipe/sp_screen.c   | 1 +
 src/gallium/drivers/svga/svga_screen.c | 1 +
 src/gallium/drivers/vc4/vc4_screen.c   | 1 +
 src/gallium/include/pipe/p_defines.h   | 1 +
 13 files changed, 16 insertions(+)

diff --git a/src/gallium/docs/source/screen.rst 
b/src/gallium/docs/source/screen.rst
index 00c9503..c103194 100644
--- a/src/gallium/docs/source/screen.rst
+++ b/src/gallium/docs/source/screen.rst
@@ -376,6 +376,10 @@ The integer capabilities:
   operations are supported.
 * ``PIPE_CAP_TGSI_TEX_TXF_LZ``: Whether TEX_LZ and TXF_LZ opcodes are
   supported.
+* ``PIPE_CAP_POLYGON_MODE_FILL_RECTANGLE``: Whether the
+  PIPE_POLYGON_MODE_FILL_RECTANGLE mode is supported for
+  ``pipe_rasterizer_state::fill_front`` and
+  ``pipe_rasterizer_state::fill_back``.
 
 
 .. _pipe_capf:
diff --git a/src/gallium/drivers/i915/i915_screen.c 
b/src/gallium/drivers/i915/i915_screen.c
index d25c2b3..28be7a9 100644
--- a/src/gallium/drivers/i915/i915_screen.c
+++ b/src/gallium/drivers/i915/i915_screen.c
@@ -278,6 +278,7 @@ i915_get_param(struct pipe_screen *screen, enum pipe_cap 
cap)
case PIPE_CAP_MAX_WINDOW_RECTANGLES:
case PIPE_CAP_POLYGON_OFFSET_UNITS_UNSCALED:
case PIPE_CAP_TGSI_ARRAY_COMPONENTS:
+   case PIPE_CAP_POLYGON_MODE_FILL_RECTANGLE:
   return 0;
 
case PIPE_CAP_MAX_DUAL_SOURCE_RENDER_TARGETS:
diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c 
b/src/gallium/drivers/llvmpipe/lp_screen.c
index f6ac9b6..d4d04d4 100644
--- a/src/gallium/drivers/llvmpipe/lp_screen.c
+++ b/src/gallium/drivers/llvmpipe/lp_screen.c
@@ -347,6 +347,7 @@ llvmpipe_get_param(struct pipe_screen *screen, enum 
pipe_cap param)
case PIPE_CAP_GLSL_OPTIMIZE_CONSERVATIVELY:
case PIPE_CAP_TGSI_FS_FBFETCH:
case PIPE_CAP_TGSI_MUL_ZERO_WINS:
+   case PIPE_CAP_POLYGON_MODE_FILL_RECTANGLE:
   return 0;
}
/* should only get here on unhandled cases */
diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c 
b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
index 5c7ae24..be73cf0 100644
--- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
+++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
@@ -211,6 +211,7 @@ nv30_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
case PIPE_CAP_INT64:
case PIPE_CAP_INT64_DIVMOD:
case PIPE_CAP_TGSI_TEX_TXF_LZ:
+   case PIPE_CAP_POLYGON_MODE_FILL_RECTANGLE:
   return 0;
 
case PIPE_CAP_VENDOR_ID:
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.c 
b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
index 249947a..ee33936 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_screen.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
@@ -263,6 +263,7 @@ nv50_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
case PIPE_CAP_DOUBLES:
case PIPE_CAP_INT64:
case PIPE_CAP_INT64_DIVMOD:
+   case PIPE_CAP_POLYGON_MODE_FILL_RECTANGLE:
   return 0;
 
case PIPE_CAP_VENDOR_ID:
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
index cfe4f67..945101b 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
@@ -285,6 +285,7 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
case PIPE_CAP_NATIVE_FENCE_FD:
case PIPE_CAP_GLSL_OPTIMIZE_CONSERVATIVELY:
case PIPE_CAP_INT64_DIVMOD:
+   case PIPE_CAP_POLYGON_MODE_FILL_RECTANGLE:
   return 0;
 
case PIPE_CAP_VENDOR_ID:
diff --git a/src/gallium/drivers/r300/r300_screen.c 
b/src/gallium/drivers/r300/r300_screen.c
index 07a09d5..9138091 100644
--- a/src/gallium/drivers/r300/r300_screen.c
+++ b/src/gallium/drivers/r300/r300_screen.c
@@ -233,6 +233,7 @@ static int r300_get_param(struct pipe_screen* pscreen, enum 
pipe_cap param)
 case PIPE_CAP_INT64:
 case PIPE_CAP_INT64_DIVMOD:
 case PIPE_CAP_TGSI_TEX_TXF_LZ:
+case PIPE_CAP_POLYGON_MODE_FILL_RECTANGLE:
 return 0;
 
 /* SWTCL-only features. */
diff --git a/src/gallium/drivers/r600/r600_pipe.c 
b/src/gallium/drivers/r600/r600_pipe.c
index 869f941..cf39a8a 100644
--- a/src/gallium/drivers/r600/r600_pipe.c
+++ b/src/gallium/drivers/r600/r600_pipe.c
@@ -381,6 +381,7 @@ static int r600_get_param(struct pipe_screen* pscreen, enum 
pipe_cap param)
case PIPE_CAP_INT64:
case PIPE_CAP_INT64_DIVMOD:
case PIPE_CAP_TGSI_TEX_TXF_LZ:
+ 

[Mesa-dev] [PATCH 1/6] glapi: Add GL_NV_fill_rectangle

[Lyude]

Signed-off-by: Lyude 
---
 src/mapi/glapi/gen/gl_API.xml | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml
index c1f0f8f..42d28f7 100644
--- a/src/mapi/glapi/gen/gl_API.xml
+++ b/src/mapi/glapi/gen/gl_API.xml
@@ -12840,6 +12840,10 @@
 
 
 
+
+
+
+
 
   
 
-- 
2.9.3

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

[Mesa-dev] [PATCH 0/6] Add support for GL_NV_fill_rectangle

[Lyude]

This adds basic support for GL_NV_fill_rectangle in Gallium, along with
enabling it for the GM200+ in nouveau. It should be noted this only
implements the OpenGL 4.3 bits, since we don't have the features required
yet to add this for OpenGLES.

Lyude (6):
  glapi: Add GL_NV_fill_rectangle
  gallium: Add a cap to check if the driver supports fill_rectangle
  mesa: Add support for GL_NV_fill_rectangle
  gallium/auxiliary: Add NV_fill_rectangle to pipe state
  mesa/st: Add support for NV_fill_rectangle
  nvc0: Add support for NV_fill_rectangle for the GM200+

 src/gallium/docs/source/screen.rst   |  4 
 src/gallium/drivers/i915/i915_screen.c   |  1 +
 src/gallium/drivers/llvmpipe/lp_screen.c |  1 +
 src/gallium/drivers/nouveau/nv30/nv30_screen.c   |  1 +
 src/gallium/drivers/nouveau/nv50/nv50_screen.c   |  1 +
 src/gallium/drivers/nouveau/nvc0/nvc0_3d.xml.h   |  3 +++
 src/gallium/drivers/nouveau/nvc0/nvc0_screen.c   |  2 ++
 src/gallium/drivers/nouveau/nvc0/nvc0_state.c|  4 
 src/gallium/drivers/nouveau/nvc0/nvc0_stateobj.h |  2 +-
 src/gallium/drivers/r300/r300_screen.c   |  1 +
 src/gallium/drivers/r600/r600_pipe.c |  1 +
 src/gallium/drivers/radeonsi/si_pipe.c   |  1 +
 src/gallium/drivers/softpipe/sp_screen.c |  1 +
 src/gallium/drivers/svga/svga_screen.c   |  1 +
 src/gallium/drivers/vc4/vc4_screen.c |  1 +
 src/gallium/include/pipe/p_defines.h |  2 ++
 src/gallium/include/pipe/p_state.h   |  4 ++--
 src/mapi/glapi/gen/gl_API.xml|  4 
 src/mesa/main/api_validate.c | 13 +
 src/mesa/main/extensions_table.h |  1 +
 src/mesa/main/mtypes.h   |  1 +
 src/mesa/main/polygon.c  | 15 +--
 src/mesa/state_tracker/st_atom_rasterizer.c  |  2 ++
 src/mesa/state_tracker/st_extensions.c   |  1 +
 24 files changed, 63 insertions(+), 5 deletions(-)

-- 
2.9.3

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

Re: [Mesa-dev] [PATCH] gbm: Use unsigned for BO offset getter

[Daniel Stone]

Hi,

On 23 March 2017 at 15:24, Jason Ekstrand  wrote:
> Reviewed-by: Jason Ekstrand 
>
> Please land soon so the old API can exist for as short a time as possible.
> :-)

Landed with such haste that I forgot to change the two of your Cc tags
to R-b. :( Sorry. At least that API unexists now.

To ssh://git.freedesktop.org/git/mesa/mesa
   ec0313fd58..378025ca8b  push -> master

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

Re: [Mesa-dev] [PATCH] gbm: Use unsigned for BO offset getter

[Jason Ekstrand]

Reviewed-by: Jason Ekstrand 

Please land soon so the old API can exist for as short a time as possible.
:-)

On Thu, Mar 23, 2017 at 8:14 AM, Daniel Stone  wrote:

> The actual offset returned is uint32_t, however int64_t was used as the
> return type from gbm_bo_get_offset to allow negative returns to signal
> errors to the caller.
>
> In case of an error getting the offset, the user will also be unable to
> get the handle/FD, and thus have nothing to offset into. This means that
> returning 0 as an error value is harmless, allowing us to change the
> return type to uint32_t in order to avoid signed/unsigned confusion in
> callers.
>
> Signed-off-by: Daniel Stone 
> Cc: Ben Widawsky 
> Cc: Jason Ekstrand 
> ---
>  src/gbm/backends/dri/gbm_dri.c | 18 +-
>  src/gbm/main/gbm.c |  2 +-
>  src/gbm/main/gbm.h |  2 +-
>  src/gbm/main/gbmint.h  |  2 +-
>  4 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_
> dri.c
> index 84b4dd8853..f8c005c15b 100644
> --- a/src/gbm/backends/dri/gbm_dri.c
> +++ b/src/gbm/backends/dri/gbm_dri.c
> @@ -710,22 +710,22 @@ gbm_dri_bo_get_stride(struct gbm_bo *_bo, int plane)
> return (uint32_t)stride;
>  }
>
> -static int64_t
> +static uint32_t
>  gbm_dri_bo_get_offset(struct gbm_bo *_bo, int plane)
>  {
> struct gbm_dri_device *dri = gbm_dri_device(_bo->gbm);
> struct gbm_dri_bo *bo = gbm_dri_bo(_bo);
> int offset = 0;
>
> -   if (!dri->image || dri->image->base.version < 13 ||
> !dri->image->fromPlanar) {
> -  errno = ENOSYS;
> -  return -1;
> -   }
> +   /* These error cases do not actually return an error code, as the user
> +* will also fail to obtain the handle/FD from the BO. In that case,
> the
> +* offset is irrelevant, as they have no buffer to offset into, so
> +* returning 0 is harmless. */
> +   if (!dri->image || dri->image->base.version < 13 ||
> !dri->image->fromPlanar)
> +  return 0;
>
> -   if (plane >= get_number_planes(dri, bo->image)) {
> -  errno = EINVAL;
> -  return -2;
> -   }
> +   if (plane >= get_number_planes(dri, bo->image))
> +  return 0;
>
>  /* Dumb images have no offset */
> if (bo->image == NULL) {
> diff --git a/src/gbm/main/gbm.c b/src/gbm/main/gbm.c
> index 19dc5db901..79d78b763e 100644
> --- a/src/gbm/main/gbm.c
> +++ b/src/gbm/main/gbm.c
> @@ -203,7 +203,7 @@ gbm_bo_get_format(struct gbm_bo *bo)
>   * \param bo The buffer object
>   * \return The offset
>   */
> -GBM_EXPORT int64_t
> +GBM_EXPORT uint32_t
>  gbm_bo_get_offset(struct gbm_bo *bo, int plane)
>  {
> return bo->gbm->bo_get_offset(bo, plane);
> diff --git a/src/gbm/main/gbm.h b/src/gbm/main/gbm.h
> index a774b50951..b52137ed01 100644
> --- a/src/gbm/main/gbm.h
> +++ b/src/gbm/main/gbm.h
> @@ -315,7 +315,7 @@ gbm_bo_get_stride_for_plane(struct gbm_bo *bo, int
> plane);
>  uint32_t
>  gbm_bo_get_format(struct gbm_bo *bo);
>
> -int64_t
> +uint32_t
>  gbm_bo_get_offset(struct gbm_bo *bo, int plane);
>
>  struct gbm_device *
> diff --git a/src/gbm/main/gbmint.h b/src/gbm/main/gbmint.h
> index 5ad85cc80f..c27a7a560a 100644
> --- a/src/gbm/main/gbmint.h
> +++ b/src/gbm/main/gbmint.h
> @@ -81,7 +81,7 @@ struct gbm_device {
> int (*bo_get_planes)(struct gbm_bo *bo);
> union gbm_bo_handle (*bo_get_handle)(struct gbm_bo *bo, int plane);
> uint32_t (*bo_get_stride)(struct gbm_bo *bo, int plane);
> -   int64_t (*bo_get_offset)(struct gbm_bo *bo, int plane);
> +   uint32_t (*bo_get_offset)(struct gbm_bo *bo, int plane);
> uint64_t (*bo_get_modifier)(struct gbm_bo *bo);
> void (*bo_destroy)(struct gbm_bo *bo);
>
> --
> 2.12.1
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] anv: return VK_ERROR_DEVICE_LOST immeditely when device is known to be lost

[Jason Ekstrand]

Series is

Reviewed-by: Jason Ekstrand 

On Thu, Mar 23, 2017 at 2:32 AM, Iago Toral Quiroga 
wrote:

> If we know the device has been lost we should return this error code for
> any command that can report it before we attempt to do anything with the
> device.
> ---
>  src/intel/vulkan/anv_device.c | 22 +-
>  src/intel/vulkan/genX_query.c |  3 +++
>  2 files changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
> index 19bac84..6e1ef77 100644
> --- a/src/intel/vulkan/anv_device.c
> +++ b/src/intel/vulkan/anv_device.c
> @@ -1273,6 +1273,9 @@ VkResult anv_QueueSubmit(
> ANV_FROM_HANDLE(anv_queue, queue, _queue);
> ANV_FROM_HANDLE(anv_fence, fence, _fence);
> struct anv_device *device = queue->device;
> +   if (unlikely(device->lost))
> +  return VK_ERROR_DEVICE_LOST;
> +
> VkResult result = VK_SUCCESS;
>
> /* We lock around QueueSubmit for three main reasons:
> @@ -1371,6 +1374,9 @@ VkResult anv_DeviceWaitIdle(
>  VkDevice_device)
>  {
> ANV_FROM_HANDLE(anv_device, device, _device);
> +   if (unlikely(device->lost))
> +  return VK_ERROR_DEVICE_LOST;
> +
> struct anv_batch batch;
>
> uint32_t cmds[8];
> @@ -1676,11 +1682,15 @@ VkResult anv_BindBufferMemory(
>  }
>
>  VkResult anv_QueueBindSparse(
> -VkQueue queue,
> +VkQueue _queue,
>  uint32_tbindInfoCount,
>  const VkBindSparseInfo* pBindInfo,
>  VkFence fence)
>  {
> +   ANV_FROM_HANDLE(anv_queue, queue, _queue);
> +   if (unlikely(queue->device->lost))
> +  return VK_ERROR_DEVICE_LOST;
> +
> return vk_error(VK_ERROR_FEATURE_NOT_PRESENT);
>  }
>
> @@ -1788,6 +1798,10 @@ VkResult anv_GetFenceStatus(
>  {
> ANV_FROM_HANDLE(anv_device, device, _device);
> ANV_FROM_HANDLE(anv_fence, fence, _fence);
> +
> +   if (unlikely(device->lost))
> +  return VK_ERROR_DEVICE_LOST;
> +
> int64_t t = 0;
> int ret;
>
> @@ -1827,6 +1841,9 @@ VkResult anv_WaitForFences(
> ANV_FROM_HANDLE(anv_device, device, _device);
> int ret;
>
> +   if (unlikely(device->lost))
> +  return VK_ERROR_DEVICE_LOST;
> +
> /* DRM_IOCTL_I915_GEM_WAIT uses a signed 64 bit timeout and is supposed
>  * to block indefinitely timeouts <= 0.  Unfortunately, this was broken
>  * for a couple of kernel releases.  Since there's no way to know
> @@ -2018,6 +2035,9 @@ VkResult anv_GetEventStatus(
> ANV_FROM_HANDLE(anv_device, device, _device);
> ANV_FROM_HANDLE(anv_event, event, _event);
>
> +   if (unlikely(device->lost))
> +  return VK_ERROR_DEVICE_LOST;
> +
> if (!device->info.has_llc) {
>/* Invalidate read cache before reading event written by GPU. */
>__builtin_ia32_clflush(event);
> diff --git a/src/intel/vulkan/genX_query.c b/src/intel/vulkan/genX_query.c
> index 2bbca66..b1ed4d3 100644
> --- a/src/intel/vulkan/genX_query.c
> +++ b/src/intel/vulkan/genX_query.c
> @@ -150,6 +150,9 @@ VkResult genX(GetQueryPoolResults)(
>pool->type == VK_QUERY_TYPE_PIPELINE_STATISTICS ||
>pool->type == VK_QUERY_TYPE_TIMESTAMP);
>
> +   if (unlikely(device->lost))
> +  return VK_ERROR_DEVICE_LOST;
> +
> if (pData == NULL)
>return VK_SUCCESS;
>
> --
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] gbm: Use unsigned for BO offset getter

[Daniel Stone]

The actual offset returned is uint32_t, however int64_t was used as the
return type from gbm_bo_get_offset to allow negative returns to signal
errors to the caller.

In case of an error getting the offset, the user will also be unable to
get the handle/FD, and thus have nothing to offset into. This means that
returning 0 as an error value is harmless, allowing us to change the
return type to uint32_t in order to avoid signed/unsigned confusion in
callers.

Signed-off-by: Daniel Stone 
Cc: Ben Widawsky 
Cc: Jason Ekstrand 
---
 src/gbm/backends/dri/gbm_dri.c | 18 +-
 src/gbm/main/gbm.c |  2 +-
 src/gbm/main/gbm.h |  2 +-
 src/gbm/main/gbmint.h  |  2 +-
 4 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
index 84b4dd8853..f8c005c15b 100644
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/dri/gbm_dri.c
@@ -710,22 +710,22 @@ gbm_dri_bo_get_stride(struct gbm_bo *_bo, int plane)
return (uint32_t)stride;
 }
 
-static int64_t
+static uint32_t
 gbm_dri_bo_get_offset(struct gbm_bo *_bo, int plane)
 {
struct gbm_dri_device *dri = gbm_dri_device(_bo->gbm);
struct gbm_dri_bo *bo = gbm_dri_bo(_bo);
int offset = 0;
 
-   if (!dri->image || dri->image->base.version < 13 || 
!dri->image->fromPlanar) {
-  errno = ENOSYS;
-  return -1;
-   }
+   /* These error cases do not actually return an error code, as the user
+* will also fail to obtain the handle/FD from the BO. In that case, the
+* offset is irrelevant, as they have no buffer to offset into, so
+* returning 0 is harmless. */
+   if (!dri->image || dri->image->base.version < 13 || !dri->image->fromPlanar)
+  return 0;
 
-   if (plane >= get_number_planes(dri, bo->image)) {
-  errno = EINVAL;
-  return -2;
-   }
+   if (plane >= get_number_planes(dri, bo->image))
+  return 0;
 
 /* Dumb images have no offset */
if (bo->image == NULL) {
diff --git a/src/gbm/main/gbm.c b/src/gbm/main/gbm.c
index 19dc5db901..79d78b763e 100644
--- a/src/gbm/main/gbm.c
+++ b/src/gbm/main/gbm.c
@@ -203,7 +203,7 @@ gbm_bo_get_format(struct gbm_bo *bo)
  * \param bo The buffer object
  * \return The offset
  */
-GBM_EXPORT int64_t
+GBM_EXPORT uint32_t
 gbm_bo_get_offset(struct gbm_bo *bo, int plane)
 {
return bo->gbm->bo_get_offset(bo, plane);
diff --git a/src/gbm/main/gbm.h b/src/gbm/main/gbm.h
index a774b50951..b52137ed01 100644
--- a/src/gbm/main/gbm.h
+++ b/src/gbm/main/gbm.h
@@ -315,7 +315,7 @@ gbm_bo_get_stride_for_plane(struct gbm_bo *bo, int plane);
 uint32_t
 gbm_bo_get_format(struct gbm_bo *bo);
 
-int64_t
+uint32_t
 gbm_bo_get_offset(struct gbm_bo *bo, int plane);
 
 struct gbm_device *
diff --git a/src/gbm/main/gbmint.h b/src/gbm/main/gbmint.h
index 5ad85cc80f..c27a7a560a 100644
--- a/src/gbm/main/gbmint.h
+++ b/src/gbm/main/gbmint.h
@@ -81,7 +81,7 @@ struct gbm_device {
int (*bo_get_planes)(struct gbm_bo *bo);
union gbm_bo_handle (*bo_get_handle)(struct gbm_bo *bo, int plane);
uint32_t (*bo_get_stride)(struct gbm_bo *bo, int plane);
-   int64_t (*bo_get_offset)(struct gbm_bo *bo, int plane);
+   uint32_t (*bo_get_offset)(struct gbm_bo *bo, int plane);
uint64_t (*bo_get_modifier)(struct gbm_bo *bo);
void (*bo_destroy)(struct gbm_bo *bo);
 
-- 
2.12.1

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

Re: [Mesa-dev] [PATCH 2/3] anv/device: keep track of 'device lost' state

[Jason Ekstrand]

On Thu, Mar 23, 2017 at 2:32 AM, Iago Toral Quiroga 
wrote:

> The Vulkan specs say:
>
>"A logical device may become lost because of hardware errors, execution
> timeouts, power management events and/or platform-specific events. This
> may cause pending and future command execution to fail and cause
> hardware
> resources to be corrupted. When this happens, certain commands will
> return VK_ERROR_DEVICE_LOST (see Error Codes for a list of such
> commands).
> After any such event, the logical device is considered lost. It is not
> possible to reset the logical device to a non-lost state, however the
> lost
> state is specific to a logical device (VkDevice), and the corresponding
> physical device (VkPhysicalDevice) may be otherwise unaffected. In some
> cases, the physical device may also be lost, and attempting to create a
> new logical device will fail, returning VK_ERROR_DEVICE_LOST."
>
> This means that we need to track if a logical device has been lost so we
> can
> have the commands referenced by the spec return VK_ERROR_DEVICE_LOST
> immediately.
> ---
>  src/intel/vulkan/anv_device.c  | 5 +
>  src/intel/vulkan/anv_private.h | 1 +
>  2 files changed, 6 insertions(+)
>
> diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
> index a11cb32..19bac84 100644
> --- a/src/intel/vulkan/anv_device.c
> +++ b/src/intel/vulkan/anv_device.c
> @@ -929,6 +929,7 @@ anv_device_submit_simple_batch(struct anv_device
> *device,
> ret = anv_gem_wait(device, bo.gem_handle, );
> if (ret != 0) {
>/* We don't know the real error. */
> +  device->lost = true;
>result = vk_errorf(VK_ERROR_DEVICE_LOST, "execbuf2 failed: %m");
>goto fail;
> }
> @@ -973,6 +974,7 @@ VkResult anv_CreateDevice(
> device->_loader_data.loaderMagic = ICD_LOADER_MAGIC;
> device->instance = physical_device->instance;
> device->chipset_id = physical_device->chipset_id;
> +   device->lost = false;
>
> if (pAllocator)
>device->alloc = *pAllocator;
> @@ -1250,6 +1252,7 @@ anv_device_execbuf(struct anv_device *device,
> int ret = anv_gem_execbuffer(device, execbuf);
> if (ret != 0) {
>/* We don't know the real error. */
> +  device->lost = true;
>return vk_errorf(VK_ERROR_DEVICE_LOST, "execbuf2 failed: %m");
> }
>
> @@ -1339,6 +1342,7 @@ out:
> * submit the same job again to this device.
> */
>result = VK_ERROR_DEVICE_LOST;
> +  device->lost = true;
>
>/* If we return VK_ERROR_DEVICE LOST here, we need to ensure that
> * vkWaitForFences() and vkGetFenceStatus() return a valid result
> @@ -1865,6 +1869,7 @@ VkResult anv_WaitForFences(
> return VK_TIMEOUT;
>  } else if (ret == -1) {
> /* We don't know the real error. */
> +device->lost = true;
> return vk_errorf(VK_ERROR_DEVICE_LOST, "gem wait failed:
> %m");
>  } else {
> fence->state = ANV_FENCE_STATE_SIGNALED;
> diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_
> private.h
> index fd82ce9..68f7359 100644
> --- a/src/intel/vulkan/anv_private.h
> +++ b/src/intel/vulkan/anv_private.h
> @@ -619,6 +619,7 @@ struct anv_device {
>
>  pthread_mutex_t mutex;
>  pthread_cond_t  queue_submit;
> +boollost;
>  };
>
>  static void inline
> --
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 5/5] [v2] gbm: Export a per plane getter for offset

[Daniel Stone]

Hi,

On 23 March 2017 at 14:47, Jason Ekstrand  wrote:
> On Thu, Mar 23, 2017 at 6:16 AM, Daniel Stone  wrote:
>> Returning int64_t is annoying because the relevant interface demands
>> we need uint32_t, so we need to do casts in users. Given that the
>> offset is useless without the handle/fd, and we have real error values
>> for those (0 for handle, -1 for fd) which don't require casts, I'd
>> much rather this was just a uint32_t returning 0 on failure.
>>
>> Oh well. If it's too late to change then fine, but if we could change
>> it, it would make life a little easier.
>
> I'm ok with changing it given that we know there are zero users and it's
> been in-tree for all of a week.
>
> The only problem is that 0 is a perfectly valid offset.  I think we could
> use (uint32_t)-1 and that would probably be safe.

0 is a valid offset, but you need to query the handle or fd for the
plane first, so you have something to offset into. Both of the checks
which would cause the offset query to fail, would also fail for the
handle lookup. So returning 0 is harmless, because without a
handle/fd, you won't be able to create a FB anyway.

Anyway, GCC was less violent with warnings than I expected, so it's a
minor quibble really.

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

Re: [Mesa-dev] [PATCH] st/omx/enc: use PIPE_USAGE_STAGING for output buffer

[Christian König]

Am 23.03.2017 um 15:35 schrieb Leo Liu:

Workaround an unknown bug with inside the transfer_map for certain
ASIC, also tested with un-affected ASICs, the performance actually
improved slightly.

Signed-off-by: Leo Liu 


Reviewed-by: Christian König 


---
  src/gallium/state_trackers/omx/vid_enc.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/omx/vid_enc.c 
b/src/gallium/state_trackers/omx/vid_enc.c
index b58063e..d40f54e 100644
--- a/src/gallium/state_trackers/omx/vid_enc.c
+++ b/src/gallium/state_trackers/omx/vid_enc.c
@@ -1093,7 +1093,7 @@ static void enc_HandleTask(omx_base_PortType *port, 
struct encode_task *task,
  
 /* -- allocate output buffer - */

 task->bitstream = pipe_buffer_create(priv->s_pipe->screen, 
PIPE_BIND_VERTEX_BUFFER,
-PIPE_USAGE_STREAM, size);
+PIPE_USAGE_STAGING, size);
  
 picture.picture_type = picture_type;

 picture.pic_order_cnt = task->pic_order_cnt;



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

[Mesa-dev] [PATCH] st/omx/enc: use PIPE_USAGE_STAGING for output buffer

[Leo Liu]

Workaround an unknown bug with inside the transfer_map for certain
ASIC, also tested with un-affected ASICs, the performance actually
improved slightly.

Signed-off-by: Leo Liu 
---
 src/gallium/state_trackers/omx/vid_enc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/omx/vid_enc.c 
b/src/gallium/state_trackers/omx/vid_enc.c
index b58063e..d40f54e 100644
--- a/src/gallium/state_trackers/omx/vid_enc.c
+++ b/src/gallium/state_trackers/omx/vid_enc.c
@@ -1093,7 +1093,7 @@ static void enc_HandleTask(omx_base_PortType *port, 
struct encode_task *task,
 
/* -- allocate output buffer - */
task->bitstream = pipe_buffer_create(priv->s_pipe->screen, 
PIPE_BIND_VERTEX_BUFFER,
-PIPE_USAGE_STREAM, size);
+PIPE_USAGE_STAGING, size);
 
picture.picture_type = picture_type;
picture.pic_order_cnt = task->pic_order_cnt;
-- 
2.9.3

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

Re: [Mesa-dev] [PATCH mesa 2/2] REVIEWERS: add autogen.sh to the autoconf group

[Emil Velikov]

On 23 March 2017 at 00:21, Eric Engestrom  wrote:
> Signed-off-by: Eric Engestrom 
> ---
>  REVIEWERS | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/REVIEWERS b/REVIEWERS
> index 40db33f67f..0b5d9a4fd3 100644
> --- a/REVIEWERS
> +++ b/REVIEWERS
> @@ -85,6 +85,7 @@ F: src/gallium/targets/
>
>  AUTOCONF BUILD
>  R: Emil Velikov 
> +F: autogen.sh

Acked-by: Emil Velikov 

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

Re: [Mesa-dev] [PATCH 2/3] anv/pipeline: add a sample_shading_enable field to anv_pipeline

[Jason Ekstrand]

I don't think this patch is needed.  Just roll it into patch 3.  With that,
the other two are

Reviewed-by: Jason Ekstrand 

On Thu, Mar 23, 2017 at 5:55 AM, Iago Toral Quiroga 
wrote:

> We need to know if sample shading has been requested during shader
> compilation since that affects the way fragment coordinates are
> computed.
>
> Notice that the semantics of fragment coordinates only depend on
> whether sample shading has been requested, not on whether more
> than one sample will actually be produced (that is,
> minSampleShading and rasterizationSamples do not affect this
> behavior).
> ---
>  src/intel/vulkan/anv_pipeline.c | 3 +++
>  src/intel/vulkan/anv_private.h  | 1 +
>  2 files changed, 4 insertions(+)
>
> diff --git a/src/intel/vulkan/anv_pipeline.c b/src/intel/vulkan/anv_
> pipeline.c
> index 8ad2d48..ce9c889 100644
> --- a/src/intel/vulkan/anv_pipeline.c
> +++ b/src/intel/vulkan/anv_pipeline.c
> @@ -1207,6 +1207,9 @@ anv_pipeline_init(struct anv_pipeline *pipeline,
> pipeline->depth_clamp_enable = pCreateInfo->pRasterizationState &&
>pCreateInfo->pRasterizationState->
> depthClampEnable;
>
> +   pipeline->sample_shading_enable = pCreateInfo->pMultisampleState &&
> + pCreateInfo->pMultisampleState->
> sampleShadingEnable;
> +
> pipeline->needs_data_cache = false;
>
> /* When we free the pipeline, we detect stages based on the NULL status
> diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_
> private.h
> index fd82ce9..675c557 100644
> --- a/src/intel/vulkan/anv_private.h
> +++ b/src/intel/vulkan/anv_private.h
> @@ -1632,6 +1632,7 @@ struct anv_pipeline {
> bool writes_stencil;
> bool stencil_test_enable;
> bool depth_clamp_enable;
> +   bool sample_shading_enable;
> bool kill_pixel;
>
> struct {
> --
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 5/5] [v2] gbm: Export a per plane getter for offset

[Jason Ekstrand]

On Thu, Mar 23, 2017 at 6:16 AM, Daniel Stone  wrote:

> Hi,
>
> On 8 March 2017 at 05:31, Ben Widawsky  wrote:
> > Unlike stride, there was no previous offset getter, so it can be right
> > on the first try.
> >
> > v2: Return EINVAL when plane is greater than total planes to make it
> > match the similar APIs.
> > Avoid leak after fromPlanar (Daniel)
> > Make sure when getting offsets we consider dumb images (Daniel)
> >
> > v3: Use Jason's recommendation for handling the non-planar case.
> >
> > v4: Return int64_t so we can get real errors
>
> I really wish I'd caught this earlier. :(
>
> Returning int64_t is annoying because the relevant interface demands
> we need uint32_t, so we need to do casts in users. Given that the
> offset is useless without the handle/fd, and we have real error values
> for those (0 for handle, -1 for fd) which don't require casts, I'd
> much rather this was just a uint32_t returning 0 on failure.
>
> Oh well. If it's too late to change then fine, but if we could change
> it, it would make life a little easier.
>

I'm ok with changing it given that we know there are zero users and it's
been in-tree for all of a week.

The only problem is that 0 is a perfectly valid offset.  I think we could
use (uint32_t)-1 and that would probably be safe.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 26/34] i965: Pretend that CCS modified images are two planes

[Daniel Stone]

Hi Ben,

On 24 January 2017 at 06:21, Ben Widawsky  wrote:
> @@ -1018,9 +1018,18 @@ intel_from_planar(__DRIimage *parent, int plane, void 
> *loaderPrivate)
>  int width, height, offset, stride, dri_format, index;
>  struct intel_image_format *f;
>  __DRIimage *image;
> -
> -if (parent == NULL || parent->planar_format == NULL)
> -return NULL;
> +bool is_aux = parent->aux_offset && plane == 1;
> +
> +if (parent == NULL || parent->planar_format == NULL) {
> +   if (is_aux) {
> +  offset = parent->aux_offset;
> +  stride = ALIGN(parent->pitch / 32, 128);
> +  height = ALIGN(DIV_ROUND_UP(parent->height, 16), 32);
> +  dri_format = parent->dri_format;
> +  goto done;

The non-goto version in modifiersv9 now throws a warning for 'width'
being uninitialised. I assume this should just be ALIGN(parent->width
/ 32, 32), or ... ?

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