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

[Ben Widawsky]

On 17-01-31 11:40:04, Jason Ekstrand wrote:

On Mon, Jan 23, 2017 at 10:19 PM, 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)

Signed-off-by: Ben Widawsky 
Reviewed-by: Eric Engestrom 
Acked-by: Daniel Stone 
---
 src/gbm/backends/dri/gbm_dri.c | 36 
 src/gbm/gbm-symbols-check  |  1 +
 src/gbm/main/gbm.c | 15 +++
 src/gbm/main/gbm.h |  3 +++
 src/gbm/main/gbmint.h  |  1 +
 5 files changed, 56 insertions(+)

diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_
dri.c
index 395f78e851..43f8e15e62 100644
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/dri/gbm_dri.c
@@ -697,6 +697,41 @@ gbm_dri_bo_get_stride(struct gbm_bo *_bo, int plane)
return (uint32_t)stride;
 }

+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 0;
+   }
+
+   if (plane >= get_number_planes(dri, bo->image)) {
+  errno = EINVAL;
+  return 0;
+   }
+
+/* Dumb images have no offset */
+   if (!bo->image)
+  return 0;
+
+   __DRIimage *image = dri->image->fromPlanar(bo->image, plane, NULL);
+   if (!image) {
+  /* Use the parent offset */
+  image = bo->image;
+   }
+
+   dri->image->queryImage(image, __DRI_IMAGE_ATTRIB_OFFSET, );
+
+   if (image != bo->image)
+  dri->image->destroyImage(image);



It's a bit unclear to me how this if is related to the one above.  Is it
possible for fromPlanar to return bo->image or does fromPlanar always
create a new image?  Would this be more clear:

__DRIimage *plane_image = dri->image->fromPlanar(bo->image, plane, NULL);
if (plane_image) {
  dri->image->queryImage(plane_image, __DRI_IMAGE_ATTRIB_OFFSET, );
  dri->image->destroyImage(plane_image);
} else {
  dri->image->queryImage(bo->image, __DRI_IMAGE_ATTRIB_OFFSET, );
}

It appears to me as if that's what you're trying to accomplish but I don't
really understand the ownership semantics of fromPlanar.



Yeah, that looks better to me too. Thanks.


This question also applies to the previous patch.



Oops. I realized I didn't cleanup the new DRIimage in the previous patch.




+
+   return (uint32_t)offset;
+}
+
 static void
 gbm_dri_bo_destroy(struct gbm_bo *_bo)
 {
@@ -1157,6 +1192,7 @@ dri_device_create(int fd)
dri->base.base.bo_get_planes = gbm_dri_bo_get_planes;
dri->base.base.bo_get_handle = gbm_dri_bo_get_handle_for_plane;
dri->base.base.bo_get_stride = gbm_dri_bo_get_stride;
+   dri->base.base.bo_get_offset = gbm_dri_bo_get_offset;
dri->base.base.bo_destroy = gbm_dri_bo_destroy;
dri->base.base.destroy = dri_destroy;
dri->base.base.surface_create = gbm_dri_surface_create;
diff --git a/src/gbm/gbm-symbols-check b/src/gbm/gbm-symbols-check
index 459006a63f..7ff78ab400 100755
--- a/src/gbm/gbm-symbols-check
+++ b/src/gbm/gbm-symbols-check
@@ -16,6 +16,7 @@ gbm_bo_get_height
 gbm_bo_get_stride
 gbm_bo_get_stride_for_plane
 gbm_bo_get_format
+gbm_bo_get_offset
 gbm_bo_get_device
 gbm_bo_get_handle
 gbm_bo_get_fd
diff --git a/src/gbm/main/gbm.c b/src/gbm/main/gbm.c
index 0a9f0bef7e..295f6894eb 100644
--- a/src/gbm/main/gbm.c
+++ b/src/gbm/main/gbm.c
@@ -194,6 +194,21 @@ gbm_bo_get_format(struct gbm_bo *bo)
return bo->format;
 }

+/** Get the offset for the data of the specified plane
+ *
+ * Extra planes, and even the first plane, may have an offset from the
start of
+ * the buffer object. This function will provide the offset for the given
plane
+ * to be used in various KMS APIs.
+ *
+ * \param bo The buffer object
+ * \return The offset
+ */
+GBM_EXPORT uint32_t
+gbm_bo_get_offset(struct gbm_bo *bo, int plane)
+{
+   return bo->gbm->bo_get_offset(bo, plane);
+}
+
 /** Get the gbm device used to create the buffer object
  *
  * \param bo The buffer object
diff --git a/src/gbm/main/gbm.h b/src/gbm/main/gbm.h
index 1719c5312a..b089359b01 100644
--- a/src/gbm/main/gbm.h
+++ b/src/gbm/main/gbm.h
@@ -309,6 +309,9 @@ gbm_bo_get_stride_for_plane(struct gbm_bo *bo, int
plane);
 uint32_t
 gbm_bo_get_format(struct gbm_bo *bo);

+uint32_t
+gbm_bo_get_offset(struct gbm_bo *bo, int plane);
+
 struct gbm_device *
 gbm_bo_get_device(struct gbm_bo *bo);

diff --git a/src/gbm/main/gbmint.h b/src/gbm/main/gbmint.h
index 26d18bab6b..ac6078361a 100644
--- a/src/gbm/main/gbmint.h
+++ b/src/gbm/main/gbmint.h
@@ -79,6 +79,7 @@ struct gbm_device {
int (*bo_get_planes)(struct gbm_bo *bo);

Re: [Mesa-dev] [PATCH 06/34] gbm: Export a per plane getter for stride

[Ben Widawsky]

On 17-01-31 11:33:39, Jason Ekstrand wrote:

On Mon, Jan 23, 2017 at 10:19 PM, Ben Widawsky  wrote:


v2: Preserve legacy behavior when plane is 0 (Jason Ekstrand)
EINVAL when input plane is greater than total planes (Jason Ekstrand)
Don't leak the image after fromPlanar (Daniel)
Move bo->image check below plane count preventing bad index succeeding
(Daniel)

Signed-off-by: Ben Widawsky 
Reviewed-by: Eric Engestrom  (v1)
Acked-by: Daniel Stone 
---
 src/gbm/backends/dri/gbm_dri.c | 35 ++-
 src/gbm/gbm-symbols-check  |  1 +
 src/gbm/main/gbm.c | 15 ++-
 src/gbm/main/gbm.h |  3 +++
 4 files changed, 52 insertions(+), 2 deletions(-)

diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_
dri.c
index f055a665db..395f78e851 100644
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/dri/gbm_dri.c
@@ -661,7 +661,40 @@ gbm_dri_bo_get_handle_for_plane(struct gbm_bo *_bo,
int plane)
 static uint32_t
 gbm_dri_bo_get_stride(struct gbm_bo *_bo, int plane)
 {
-   return _bo->stride;
+   struct gbm_dri_device *dri = gbm_dri_device(_bo->gbm);
+   struct gbm_dri_bo *bo = gbm_dri_bo(_bo);
+   __DRIimage *image;
+   int stride = 0;
+
+   /* Preserve legacy behavior if plane is 0 */
+   if (plane == 0)
+  return _bo->stride;



This implies that, for multi-planar images, you have to have the BO stride
be the same as the image stride.  Do we want this or do we only want to
return bo->stride if we don't have enough DRI stuff (in the if below) to
use the image?  I think it's probably ok either way.



The biggest problem is if I change it (see hunk below) is that it potentially
doesn't match the old behavior, and I don't really have a great way to test this
outside of our environment. I went with the path of least risk, however you do
raise a good point.

Daniel, do you have an opinion here?


diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
index 7c5723f0d8..9c24eab24f 100644
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/dri/gbm_dri.c
@@ -666,11 +666,11 @@ gbm_dri_bo_get_stride(struct gbm_bo *_bo, int plane)
   __DRIimage *image;
   int stride = 0;

-   /* Preserve legacy behavior if plane is 0 */
-   if (plane == 0)
-  return _bo->stride;
-
   if (!dri->image || dri->image->base.version < 11 || !dri->image->fromPlanar) 
{
+  /* Preserve legacy behavior if plane is 0 */
+  if (plane == 0)
+ return _bo->stride;
+
  errno = ENOSYS;
  return 0;
   }





+
+   if (!dri->image || dri->image->base.version < 11 ||
!dri->image->fromPlanar) {
+  errno = ENOSYS;
+  return 0;
+   }
+
+   if (plane >= get_number_planes(dri, bo->image)) {
+  errno = EINVAL;
+  return 0;
+   }
+
+   if (bo->image == NULL)
+  return _bo->stride;
+
+   image = dri->image->fromPlanar(bo->image, plane, NULL);
+   if (!image) {
+  /* Use the parent stride */
+  image = bo->image;
+   }
+
+   dri->image->queryImage(image, __DRI_IMAGE_ATTRIB_STRIDE, );
+
+   if (image != bo->image)
+  dri->image->destroyImage(image);
+
+   return (uint32_t)stride;
 }

 static void
diff --git a/src/gbm/gbm-symbols-check b/src/gbm/gbm-symbols-check
index 1e6dd4d3ec..459006a63f 100755
--- a/src/gbm/gbm-symbols-check
+++ b/src/gbm/gbm-symbols-check
@@ -14,6 +14,7 @@ gbm_bo_unmap
 gbm_bo_get_width
 gbm_bo_get_height
 gbm_bo_get_stride
+gbm_bo_get_stride_for_plane
 gbm_bo_get_format
 gbm_bo_get_device
 gbm_bo_get_handle
diff --git a/src/gbm/main/gbm.c b/src/gbm/main/gbm.c
index 7462e90c4c..0a9f0bef7e 100644
--- a/src/gbm/main/gbm.c
+++ b/src/gbm/main/gbm.c
@@ -165,7 +165,20 @@ gbm_bo_get_height(struct gbm_bo *bo)
 GBM_EXPORT uint32_t
 gbm_bo_get_stride(struct gbm_bo *bo)
 {
-   return bo->gbm->bo_get_stride(bo, 0);
+   return gbm_bo_get_stride_for_plane(bo, 0);
+}
+
+/** Get the stride for the given plane
+ *
+ * \param bo The buffer object
+ * \param plane for which you want the stride
+ *
+ * \sa gbm_bo_get_stride()
+ */
+GBM_EXPORT uint32_t
+gbm_bo_get_stride_for_plane(struct gbm_bo *bo, int plane)
+{
+   return bo->gbm->bo_get_stride(bo, plane);
 }

 /** Get the format of the buffer object
diff --git a/src/gbm/main/gbm.h b/src/gbm/main/gbm.h
index 67548206c4..1719c5312a 100644
--- a/src/gbm/main/gbm.h
+++ b/src/gbm/main/gbm.h
@@ -304,6 +304,9 @@ uint32_t
 gbm_bo_get_stride(struct gbm_bo *bo);

 uint32_t
+gbm_bo_get_stride_for_plane(struct gbm_bo *bo, int plane);
+
+uint32_t
 gbm_bo_get_format(struct gbm_bo *bo);

 struct gbm_device *
--
2.11.0

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



--
Ben Widawsky, Intel Open Source Technology Center
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org

[Mesa-dev] [Bug 99467] [radv] DOOM 2016 + wine. Green screen everywhere (but can be started)

[bugzilla-daemon]

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

--- Comment #12 from Grazvydas Ignotas  ---
No improvement here compared to radv-wip-doom-wine from Dec 23, still suffering
random fog/glare.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
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] [RFC PATCH 1/1] st/dri: add a new driconf option override_glsl_version for ARK games

[Edward O'Callaghan]

On 02/04/2017 05:48 AM, Bas Nieuwenhuizen wrote:
> 
> On Fri, Feb 3, 2017, at 19:24, Jason Ekstrand wrote:
>> On Fri, Feb 3, 2017 at 9:23 AM, Samuel Pitoiset
>> > wrote:
>>
>> This is similar to the MESA_GLSL_VERSION_OVERRIDE envvar (mainly
>> for developers). But this one has the advantage to be configured
>> for specific apps which require a context with an explicit version.
>>
>> For example, when an app requires a 3.2 core context, RadeonSI
>> will return a 4.5 context but this might fail (eg. ARK games).
>>
>>
>> Why is returning a 4.5 context a problem?  It's supposed to be
>> more-or-less backwards compatible.
>> I'm also a bit concerned about making this driconf option be global
>> across drivers without it being just a maximum.  Suppose someone sets
>> it to 4.3 for some app that doesn't like 4.5.  What happens if they
>> try to run that app on hardware that doesn't support 4.3?  Do they get
>> a 4.3 context that just doesn't work?
> 
> As far as I can see[1], when the game detects GL 4.3+, the engine tries
> to load a different set of shaders from disk, but the game developers
> have not enabled the right flag during building, so the shaders for
> GL4.3+ are not actually distributed with the game, which results in a
> failure to load the game. From my POV this is entirely the fault of the
> game.
> 
> That said, the bug contains a report from someone else that it works on
> intel with GL4.3+. I never got to test that or look deeper into this, so
> it could very well be that I overlooked something during this analysis.

Yes I heard similar reports. I just can't see why the game can't be
simply fixed?

Kindly,
Edward.

> 
> - Bas
> 
> [1]: https://bugs.freedesktop.org/show_bug.cgi?id=95374
> 
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 



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

Re: [Mesa-dev] [PATCH 1/3] main/framebuffer: refactor _mesa_get_color_read_format/type

[Anuj Phogat]

On Thu, Feb 2, 2017 at 10:51 AM, Alejandro Piñeiro  wrote:
> Current implementation returns the value for the currently bound read
> framebuffer. GetNamedFramebufferParameteriv allows to get it for any
> given framebuffer. GetFramebufferParameteriv would be also interested
> on that method
>
> It was refactored by allowing to pass a given framebuffer. If NULL is
> passed, it used the currently bound framebuffer.
>
> It also adds a call to _mesa_update_state. When used only by
> GetIntegerv, this one was called as part of the extra checks defined
> at get_hash. But now that the method is used by more methods, and the
> update is needed, it makes sense (and it is safer) just calling it on
> the method itself, instead of rely on the caller.
> ---
>
> I also updated the spec quotes, as now there is a quote that justifies
> INVALID_OPERATION when readbuffer is not available with GetIntegerv
>
> As mentioned on the patch, there is no equivalent for 
> GetFramebufferParameteriv
> or GetNamedFramebufferParameteriv, but there is another quote that links
> the value of those with GetIntegerv, so I think that makes sense that in
> the situations that GetIntegerv raises INVALID_OPERATION the other two too.
>
> If the patch is accepted, I would open a spec bug.
>
>
>  src/mesa/main/framebuffer.c | 77 
> +++--
>  src/mesa/main/framebuffer.h |  8 +++--
>  src/mesa/main/get.c |  4 +--
>  src/mesa/main/readpix.c |  4 +--
>  4 files changed, 71 insertions(+), 22 deletions(-)
>
> diff --git a/src/mesa/main/framebuffer.c b/src/mesa/main/framebuffer.c
> index c06130d..9002020 100644
> --- a/src/mesa/main/framebuffer.c
> +++ b/src/mesa/main/framebuffer.c
> @@ -44,6 +44,7 @@
>  #include "renderbuffer.h"
>  #include "texobj.h"
>  #include "glformats.h"
> +#include "state.h"
>
>
>
> @@ -835,22 +836,54 @@ _mesa_dest_buffer_exists(struct gl_context *ctx, GLenum 
> format)
>
>
>  /**
> - * Used to answer the GL_IMPLEMENTATION_COLOR_READ_FORMAT_OES query.
> + * Used to answer the GL_IMPLEMENTATION_COLOR_READ_FORMAT_OES queries (using
> + * GetIntegerv, GetFramebufferParameteriv, etc)
> + *
> + * If @fb is NULL, the method returns the value for the current bound
> + * framebuffer.
>   */
>  GLenum
> -_mesa_get_color_read_format(struct gl_context *ctx)
> +_mesa_get_color_read_format(struct gl_context *ctx,
> +struct gl_framebuffer *fb,
> +const char *caller)
>  {
> -   if (!ctx->ReadBuffer || !ctx->ReadBuffer->_ColorReadBuffer) {
> -  /* The spec is unclear how to handle this case, but NVIDIA's
> -   * driver generates GL_INVALID_OPERATION.
> +   if (ctx->NewState)
> +  _mesa_update_state(ctx);
> +
> +   if (fb == NULL)
> +  fb = ctx->ReadBuffer;
> +
> +   if (!fb || !fb->_ColorReadBuffer) {
> +  /*
> +   * From OpenGL 4.5 spec, section 18.2.2 "ReadPixels":
> +   *
> +   *"An INVALID_OPERATION error is generated by GetIntegerv if pname
> +   * is IMPLEMENTATION_COLOR_READ_FORMAT or IMPLEMENTATION_COLOR_-
> +   * READ_TYPE and any of:
> +   *  * the read framebuffer is not framebuffer complete.
> +   *  * the read framebuffer is a framebuffer object, and the 
> selected
> +   *read buffer (see section 18.2.1) has no image attached.
> +   *  * the selected read buffer is NONE."
> +   *
> +   * There is not equivalent quote for GetFramebufferParameteriv or
> +   * GetNamedFramebufferParameteriv, but from section 9.2.3 "Framebuffer
> +   * Object Queries":
> +   *
> +   *"Values of framebuffer-dependent state are identical to those 
> that
> +   * would be obtained were the framebuffer object bound and queried
> +   * using the simple state queries in that table."
> +   *
> +   * Where "using the simple state queries" refer to use GetIntegerv. So
> +   * we will assume that on that situation the same error should be
> +   * triggered too.
> */
>_mesa_error(ctx, GL_INVALID_OPERATION,
> -  "glGetIntegerv(GL_IMPLEMENTATION_COLOR_READ_FORMAT: "
> -  "no GL_READ_BUFFER)");
> +  "%s(GL_IMPLEMENTATION_COLOR_READ_FORMAT: no 
> GL_READ_BUFFER)",
> +  caller);
>return GL_NONE;
> }
> else {
> -  const mesa_format format = ctx->ReadBuffer->_ColorReadBuffer->Format;
> +  const mesa_format format = fb->_ColorReadBuffer->Format;
>const GLenum data_type = _mesa_get_format_datatype(format);
>
>if (format == MESA_FORMAT_B8G8R8A8_UNORM)
> @@ -872,22 +905,34 @@ _mesa_get_color_read_format(struct gl_context *ctx)
>
>
>  /**
> - * Used to answer the GL_IMPLEMENTATION_COLOR_READ_TYPE_OES query.
> + * Used to answer the GL_IMPLEMENTATION_COLOR_READ_TYPE_OES queries (using
> + * GetIntegerv, GetFramebufferParameteriv, etc)
> + *
> + * If @fb is NULL, the method returns the 

[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 98263, which changed state.

Bug 98263 Summary: [radv] The Talos Principle fails to launch with "Fatal 
error: Cannot set display mode."
https://bugs.freedesktop.org/show_bug.cgi?id=98263

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

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

[Mesa-dev] [Bug 98263] [radv] The Talos Principle fails to launch with "Fatal error: Cannot set display mode."

[bugzilla-daemon]

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

Rene Lindsay  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #7 from Rene Lindsay  ---
I'm not sure expanding this message is a good idea, in fact, I'm looking for a
way to turn it off:

When I enumerate physical devices on Ubuntu 16.04, Vulkan shows I have 2 GPU's
available: Intel HD, and NVidia GTX.  (Sometimes the order is reversed.)

Now I'm trying to determine which one the desktop is currently running on, by
calling vkGetPhysicalDeviceSurfaceSupportKHR on each GPU's queue-families.

If the desktop is running on Intel, the query returns true for Intel,
but when running on NVidia, it returns true for Nvidia and false for Intel, but
also prints:

"no DRI3 support"

I DO have DRI3 enabled for Intel, but this setting is irrelevant and ignored
when running on NVidia, so the error message is not really applicable.

Is there some way to turn off this error message, or a better way to determine
the currently active GPU, without triggering this error?

-- 
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 PATCH] gallium: add a common uploader to pipe_context

[Marek Olšák]

On Fri, Feb 3, 2017 at 9:45 PM, Brian Paul  wrote:
> On 02/01/2017 02:23 PM, Brian Paul wrote:
>>
>> On 01/27/2017 04:00 AM, Marek Olšák wrote:
>>>
>>> On Fri, Jan 27, 2017 at 10:05 AM, Nicolai Hähnle 
>>> wrote:

 On 27.01.2017 00:51, Marek Olšák wrote:
>
>
> From: Marek Olšák 
>
> For lower memory usage and more efficient updates of the buffer
> residency
> list. (e.g. if drivers keep seeing the same buffer for many consecutive
> "add" calls, the calls can be turned into no-ops trivially)



 This makes sense to me, but how are you planning to deal with the bind
 flags? They are currently set differently for different upload mgrs. We
 should probably do away with them entirely anyway.
>>>
>>>
>>> Drivers can set the bind flags they need. Some drivers will set all 3
>>> bind flags. Other drivers don't have to set any.
>>
>>
>> I need to look into this part more closely.  I think we may have trouble
>> mixing constants with index/vertex data in our VMware driver...
>
>
> Marek,
>
> Your patch series, as-is, did indeed cause trouble with our VMware driver.
> We need to keep constants in a separate buffer.
>
> The good news is I don't think this is a huge problem and I've updated (a
> subset of) your patches to accommodate both your needs and ours.
>
> The basic idea is to add a pipe_context::get_stream_uploader() hook that
> allows drivers to use just one or separate uploaders for
> vertex/index/constant data.  Plus, I added a
> pipe_context::unmap_stream_uploaders() helper, but this isn't strictly
> necessary.
>
> WIP patch attached (only lightly tested).  Let me know what you think.

Can we simply add these 2 fields into pipe_context instead of the callback?

pipe_context::stream_uploader // vertex + index
pipe_context::const_uploader

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

Re: [Mesa-dev] [PATCH 2/2] anv: Implement the Sky Lake stencil PMA optimization

[Nanley Chery]

On Fri, Feb 03, 2017 at 12:27:18PM -0800, Jason Ekstrand wrote:
> On Thu, Feb 2, 2017 at 1:45 PM, Nanley Chery  wrote:
> 
> > On Thu, Feb 02, 2017 at 01:37:56PM -0800, Nanley Chery wrote:
> > > On Thu, Feb 02, 2017 at 12:53:33PM -0800, Jason Ekstrand wrote:
> > > > On Thu, Feb 2, 2017 at 10:55 AM, Nanley Chery 
> > wrote:
> > > >
> > > > > On Wed, Feb 01, 2017 at 10:11:42PM -0800, Jason Ekstrand wrote:
> > > > > > This improves the performance of Dota 2 on my Sky Lake Skull Canyon
> > > > > > machine by about 2-3%.
> > > > > > ---
> > > > > >  src/intel/vulkan/anv_private.h |   1 +
> > > > > >  src/intel/vulkan/gen8_cmd_buffer.c | 155
> > ++
> > > > > ++-
> > > > > >  src/intel/vulkan/genX_pipeline.c   |   6 +-
> > > > > >  3 files changed, 156 insertions(+), 6 deletions(-)
> > > > > >
> > > > > > diff --git a/src/intel/vulkan/anv_private.h
> > > > > b/src/intel/vulkan/anv_private.h
> > > > > > index 5fe4dd8..e7ad351 100644
> > > > > > --- a/src/intel/vulkan/anv_private.h
> > > > > > +++ b/src/intel/vulkan/anv_private.h
> > > > > > @@ -1475,6 +1475,7 @@ struct anv_pipeline {
> > > > > > bool writes_depth;
> > > > > > bool depth_test_enable;
> > > > > > bool writes_stencil;
> > > > > > +   bool
> >  stencil_test_enable;
> > > > > > bool
> >  depth_clamp_enable;
> > > > > > bool kill_pixel;
> > > > > >
> > > > > > diff --git a/src/intel/vulkan/gen8_cmd_buffer.c
> > > > > b/src/intel/vulkan/gen8_cmd_buffer.c
> > > > > > index b877e27..553f0c3 100644
> > > > > > --- a/src/intel/vulkan/gen8_cmd_buffer.c
> > > > > > +++ b/src/intel/vulkan/gen8_cmd_buffer.c
> > > > > > @@ -157,16 +157,39 @@ __emit_sf_state(struct anv_cmd_buffer
> > *cmd_buffer)
> > > > > >  void
> > > > > >  genX(cmd_buffer_enable_pma_fix)(struct anv_cmd_buffer
> > *cmd_buffer,
> > > > > bool enable)
> > > > > >  {
> > > > > > -#if GEN_GEN == 8
> > > > > > if (cmd_buffer->state.pma_fix_enabled == enable)
> > > > > >return;
> > > > > >
> > > > > > +   cmd_buffer->state.pma_fix_enabled = enable;
> > > > > > +
> > > > > > +   /* According to the Broadwell PIPE_CONTROL documentation,
> > software
> > > > > should
> > > > > > +* emit a PIPE_CONTROL with the CS Stall and Depth Cache Flush
> > bits
> > > > > set
> > > > > > +* prior to the LRI.  If stencil buffer writes are enabled,
> > then a
> > > > > Render
> > > > > > +* Cache Flush is also necessary.
> > > > > > +*
> > > > > > +* The Sky Lake docs say to use a depth stall rather than a
> > command
> > > > > > +* streamer stall.  However, the hardware seems to violently
> > > > > disagree.
> > > > > > +* A full command streamer stall seems to be needed in both
> > cases.
> > > > > > +*/
> > > > > > anv_batch_emit(_buffer->batch, GENX(PIPE_CONTROL), pc) {
> > > > > >pc.DepthCacheFlushEnable = true;
> > > > > >pc.CommandStreamerStallEnable = true;
> > > > > >pc.RenderTargetCacheFlushEnable = true;
> > > > > > }
> > > > > >
> > > > > > +#if GEN_GEN == 9
> > > > > > +
> > > > > > +   uint32_t cache_mode;
> > > > > > +   anv_pack_struct(_mode, GENX(CACHE_MODE_0),
> > > > > > +   .STCPMAOptimizationEnable = enable,
> > > > > > +   .STCPMAOptimizationEnableMask = true);
> > > > > > +   anv_batch_emit(_buffer->batch,
> > GENX(MI_LOAD_REGISTER_IMM), lri)
> > > > > {
> > > > > > +  lri.RegisterOffset   = GENX(CACHE_MODE_0_num);
> > > > > > +  lri.DataDWord= cache_mode;
> > > > > > +   }
> > > > > > +
> > > > > > +#elif GEN_GEN == 8
> > > > > > +
> > > > > > uint32_t cache_mode;
> > > > > > anv_pack_struct(_mode, GENX(CACHE_MODE_1),
> > > > > > .NPPMAFixEnable = enable,
> > > > > > @@ -178,18 +201,20 @@ genX(cmd_buffer_enable_pma_fix)(struct
> > > > > anv_cmd_buffer *cmd_buffer, bool enable)
> > > > > >lri.DataDWord= cache_mode;
> > > > > > }
> > > > > >
> > > > > > +#endif /* GEN_GEN == 8 */
> > > > > > +
> > > > > > /* After the LRI, a PIPE_CONTROL with both the Depth Stall and
> > Depth
> > > > > Cache
> > > > > >  * Flush bits is often necessary.  We do it regardless because
> > it's
> > > > > easier.
> > > > > >  * The render cache flush is also necessary if stencil writes
> > are
> > > > > enabled.
> > > > > > +*
> > > > > > +* Again, the Sky Lake docs give a different set of flushes
> > but the
> > > > > BDW
> > > > > > +* flushes seem to work just as well.
> > > > > >  */
> > > > > > anv_batch_emit(_buffer->batch, GENX(PIPE_CONTROL), pc) {
> > > > > >pc.DepthStallEnable = true;
> > > > > >pc.DepthCacheFlushEnable = true;
> > > > > >pc.RenderTargetCacheFlushEnable = true;
> > > > > > }
> > > > > > -
> > > > > > -   

Re: [Mesa-dev] [RFC PATCH] gallium: add a common uploader to pipe_context

[Brian Paul]

On 02/01/2017 02:23 PM, Brian Paul wrote:

On 01/27/2017 04:00 AM, Marek Olšák wrote:

On Fri, Jan 27, 2017 at 10:05 AM, Nicolai Hähnle 
wrote:

On 27.01.2017 00:51, Marek Olšák wrote:


From: Marek Olšák 

For lower memory usage and more efficient updates of the buffer
residency
list. (e.g. if drivers keep seeing the same buffer for many consecutive
"add" calls, the calls can be turned into no-ops trivially)



This makes sense to me, but how are you planning to deal with the bind
flags? They are currently set differently for different upload mgrs. We
should probably do away with them entirely anyway.


Drivers can set the bind flags they need. Some drivers will set all 3
bind flags. Other drivers don't have to set any.


I need to look into this part more closely.  I think we may have trouble
mixing constants with index/vertex data in our VMware driver...


Marek,

Your patch series, as-is, did indeed cause trouble with our VMware 
driver.  We need to keep constants in a separate buffer.


The good news is I don't think this is a huge problem and I've updated 
(a subset of) your patches to accommodate both your needs and ours.


The basic idea is to add a pipe_context::get_stream_uploader() hook that 
allows drivers to use just one or separate uploaders for 
vertex/index/constant data.  Plus, I added a 
pipe_context::unmap_stream_uploaders() helper, but this isn't strictly 
necessary.


WIP patch attached (only lightly tested).  Let me know what you think.

-Brian

diff --git a/src/gallium/auxiliary/util/u_upload_mgr.c b/src/gallium/auxiliary/util/u_upload_mgr.c
index cfef1f0..11662e7 100644
--- a/src/gallium/auxiliary/util/u_upload_mgr.c
+++ b/src/gallium/auxiliary/util/u_upload_mgr.c
@@ -86,6 +86,15 @@ u_upload_create(struct pipe_context *pipe, unsigned default_size,
return upload;
 }
 
+struct u_upload_mgr *
+u_upload_create_default(struct pipe_context *pipe)
+{
+   return u_upload_create(pipe, 1024 * 1024,
+  PIPE_BIND_VERTEX_BUFFER |
+  PIPE_BIND_INDEX_BUFFER |
+  PIPE_BIND_CONSTANT_BUFFER,
+  PIPE_USAGE_STREAM);
+}
 
 static void upload_unmap_internal(struct u_upload_mgr *upload, boolean destroying)
 {
diff --git a/src/gallium/auxiliary/util/u_upload_mgr.h b/src/gallium/auxiliary/util/u_upload_mgr.h
index b36e9e5..fcd6235 100644
--- a/src/gallium/auxiliary/util/u_upload_mgr.h
+++ b/src/gallium/auxiliary/util/u_upload_mgr.h
@@ -52,6 +52,13 @@ u_upload_create(struct pipe_context *pipe, unsigned default_size,
 unsigned bind, enum pipe_resource_usage usage);
 
 /**
+ * Create the default uploader for pipe_context. Only pipe_context::screen
+ * needs to be set for this to succeed.
+ */
+struct u_upload_mgr *
+u_upload_create_default(struct pipe_context *pipe);
+
+/**
  * Destroy the upload manager.
  */
 void u_upload_destroy( struct u_upload_mgr *upload );
diff --git a/src/gallium/auxiliary/util/u_vbuf.c b/src/gallium/auxiliary/util/u_vbuf.c
index 532e7c0..a16045c 100644
--- a/src/gallium/auxiliary/util/u_vbuf.c
+++ b/src/gallium/auxiliary/util/u_vbuf.c
@@ -146,7 +146,8 @@ struct u_vbuf {
struct pipe_context *pipe;
struct translate_cache *translate_cache;
struct cso_cache *cso_cache;
-   struct u_upload_mgr *uploader;
+   struct u_upload_mgr *index_uploader;
+   struct u_upload_mgr *vertex_uploader;
 
/* This is what was set in set_vertex_buffers.
 * May contain user buffers. */
@@ -314,9 +315,10 @@ u_vbuf_create(struct pipe_context *pipe,
mgr->translate_cache = translate_cache_create();
memset(mgr->fallback_vbs, ~0, sizeof(mgr->fallback_vbs));
 
-   mgr->uploader = u_upload_create(pipe, 1024 * 1024,
-   PIPE_BIND_VERTEX_BUFFER,
-   PIPE_USAGE_STREAM);
+   mgr->vertex_uploader =
+  pipe->get_stream_uploader(pipe, PIPE_BIND_VERTEX_BUFFER);
+   mgr->index_uploader =
+  pipe->get_stream_uploader(pipe, PIPE_BIND_INDEX_BUFFER);
 
return mgr;
 }
@@ -390,7 +392,6 @@ void u_vbuf_destroy(struct u_vbuf *mgr)
pipe_resource_reference(>aux_vertex_buffer_saved.buffer, NULL);
 
translate_cache_destroy(mgr->translate_cache);
-   u_upload_destroy(mgr->uploader);
cso_cache_delete(mgr->cso_cache);
FREE(mgr);
 }
@@ -454,7 +455,7 @@ u_vbuf_translate_buffers(struct u_vbuf *mgr, struct translate_key *key,
   assert((ib->buffer || ib->user_buffer) && ib->index_size);
 
   /* Create and map the output buffer. */
-  u_upload_alloc(mgr->uploader, 0,
+  u_upload_alloc(mgr->index_uploader, 0,
  key->output_stride * num_indices, 4,
  _offset, _buffer,
  (void**)_map);
@@ -486,7 +487,7 @@ u_vbuf_translate_buffers(struct u_vbuf *mgr, struct translate_key *key,
   }
} else {
   /* Create and map the output buffer. */
-  u_upload_alloc(mgr->uploader,
+  

Re: [Mesa-dev] [PATCH 2/2] anv: Implement the Sky Lake stencil PMA optimization

[Jason Ekstrand]

On Thu, Feb 2, 2017 at 1:45 PM, Nanley Chery  wrote:

> On Thu, Feb 02, 2017 at 01:37:56PM -0800, Nanley Chery wrote:
> > On Thu, Feb 02, 2017 at 12:53:33PM -0800, Jason Ekstrand wrote:
> > > On Thu, Feb 2, 2017 at 10:55 AM, Nanley Chery 
> wrote:
> > >
> > > > On Wed, Feb 01, 2017 at 10:11:42PM -0800, Jason Ekstrand wrote:
> > > > > This improves the performance of Dota 2 on my Sky Lake Skull Canyon
> > > > > machine by about 2-3%.
> > > > > ---
> > > > >  src/intel/vulkan/anv_private.h |   1 +
> > > > >  src/intel/vulkan/gen8_cmd_buffer.c | 155
> ++
> > > > ++-
> > > > >  src/intel/vulkan/genX_pipeline.c   |   6 +-
> > > > >  3 files changed, 156 insertions(+), 6 deletions(-)
> > > > >
> > > > > diff --git a/src/intel/vulkan/anv_private.h
> > > > b/src/intel/vulkan/anv_private.h
> > > > > index 5fe4dd8..e7ad351 100644
> > > > > --- a/src/intel/vulkan/anv_private.h
> > > > > +++ b/src/intel/vulkan/anv_private.h
> > > > > @@ -1475,6 +1475,7 @@ struct anv_pipeline {
> > > > > bool writes_depth;
> > > > > bool depth_test_enable;
> > > > > bool writes_stencil;
> > > > > +   bool
>  stencil_test_enable;
> > > > > bool
>  depth_clamp_enable;
> > > > > bool kill_pixel;
> > > > >
> > > > > diff --git a/src/intel/vulkan/gen8_cmd_buffer.c
> > > > b/src/intel/vulkan/gen8_cmd_buffer.c
> > > > > index b877e27..553f0c3 100644
> > > > > --- a/src/intel/vulkan/gen8_cmd_buffer.c
> > > > > +++ b/src/intel/vulkan/gen8_cmd_buffer.c
> > > > > @@ -157,16 +157,39 @@ __emit_sf_state(struct anv_cmd_buffer
> *cmd_buffer)
> > > > >  void
> > > > >  genX(cmd_buffer_enable_pma_fix)(struct anv_cmd_buffer
> *cmd_buffer,
> > > > bool enable)
> > > > >  {
> > > > > -#if GEN_GEN == 8
> > > > > if (cmd_buffer->state.pma_fix_enabled == enable)
> > > > >return;
> > > > >
> > > > > +   cmd_buffer->state.pma_fix_enabled = enable;
> > > > > +
> > > > > +   /* According to the Broadwell PIPE_CONTROL documentation,
> software
> > > > should
> > > > > +* emit a PIPE_CONTROL with the CS Stall and Depth Cache Flush
> bits
> > > > set
> > > > > +* prior to the LRI.  If stencil buffer writes are enabled,
> then a
> > > > Render
> > > > > +* Cache Flush is also necessary.
> > > > > +*
> > > > > +* The Sky Lake docs say to use a depth stall rather than a
> command
> > > > > +* streamer stall.  However, the hardware seems to violently
> > > > disagree.
> > > > > +* A full command streamer stall seems to be needed in both
> cases.
> > > > > +*/
> > > > > anv_batch_emit(_buffer->batch, GENX(PIPE_CONTROL), pc) {
> > > > >pc.DepthCacheFlushEnable = true;
> > > > >pc.CommandStreamerStallEnable = true;
> > > > >pc.RenderTargetCacheFlushEnable = true;
> > > > > }
> > > > >
> > > > > +#if GEN_GEN == 9
> > > > > +
> > > > > +   uint32_t cache_mode;
> > > > > +   anv_pack_struct(_mode, GENX(CACHE_MODE_0),
> > > > > +   .STCPMAOptimizationEnable = enable,
> > > > > +   .STCPMAOptimizationEnableMask = true);
> > > > > +   anv_batch_emit(_buffer->batch,
> GENX(MI_LOAD_REGISTER_IMM), lri)
> > > > {
> > > > > +  lri.RegisterOffset   = GENX(CACHE_MODE_0_num);
> > > > > +  lri.DataDWord= cache_mode;
> > > > > +   }
> > > > > +
> > > > > +#elif GEN_GEN == 8
> > > > > +
> > > > > uint32_t cache_mode;
> > > > > anv_pack_struct(_mode, GENX(CACHE_MODE_1),
> > > > > .NPPMAFixEnable = enable,
> > > > > @@ -178,18 +201,20 @@ genX(cmd_buffer_enable_pma_fix)(struct
> > > > anv_cmd_buffer *cmd_buffer, bool enable)
> > > > >lri.DataDWord= cache_mode;
> > > > > }
> > > > >
> > > > > +#endif /* GEN_GEN == 8 */
> > > > > +
> > > > > /* After the LRI, a PIPE_CONTROL with both the Depth Stall and
> Depth
> > > > Cache
> > > > >  * Flush bits is often necessary.  We do it regardless because
> it's
> > > > easier.
> > > > >  * The render cache flush is also necessary if stencil writes
> are
> > > > enabled.
> > > > > +*
> > > > > +* Again, the Sky Lake docs give a different set of flushes
> but the
> > > > BDW
> > > > > +* flushes seem to work just as well.
> > > > >  */
> > > > > anv_batch_emit(_buffer->batch, GENX(PIPE_CONTROL), pc) {
> > > > >pc.DepthStallEnable = true;
> > > > >pc.DepthCacheFlushEnable = true;
> > > > >pc.RenderTargetCacheFlushEnable = true;
> > > > > }
> > > > > -
> > > > > -   cmd_buffer->state.pma_fix_enabled = enable;
> > > > > -#endif /* GEN_GEN == 8 */
> > > > >  }
> > > > >
> > > > >  static inline bool
> > > > > @@ -289,6 +314,124 @@ want_depth_pma_fix(struct anv_cmd_buffer
> > > > *cmd_buffer)
> > > > >wm_prog_data->computed_depth_mode != PSCDEPTH_OFF;
> > > > >  

Re: [Mesa-dev] [PATCH 2/3] loader: Add an environment variable to override driver name choice.

[Eric Anholt]

Emil Velikov  writes:

> On 3 February 2017 at 19:13, Eric Anholt  wrote:
>> My vc4 simulator has been implemented so far by having an entrypoint
>> claiming to be i965, which was a bit gross.  The simulator would be a lot
>> less special if we entered through the vc4 entrypoint like normal, so add
>> a loader environment variable to allow the i965 fd to probe as vc4.
>> ---
>>  src/loader/loader.c | 11 +++
>>  1 file changed, 11 insertions(+)
>>
>> diff --git a/src/loader/loader.c b/src/loader/loader.c
>> index 449ff54d1377..4825151ad5e5 100644
>> --- a/src/loader/loader.c
>> +++ b/src/loader/loader.c
>> @@ -345,6 +345,17 @@ loader_get_driver_for_fd(int fd)
>> int vendor_id, chip_id, i, j;
>> char *driver = NULL;
>>
>> +   /* Allow an environment variable to force choosing a different driver
>> +* binary.  If that driver binary can't survive on this FD, that's the
>> +* user's problem, but this allows vc4 simulator to run on an i965 host,
>> +* and may be useful for some touch testing of i915 on an i965 host.
>> +*/
>> +   if (geteuid() == getuid()) {
>> +  driver = getenv("MESA_LOADER_DRIVER_OVERRIDE");
> Having the override is quite useful even outside the context of vc4.
>
> With this in place we could drop a few other workarounds like
>
> 64a005e3eef2e12b11b2837dc7253020bb5c0e60
> c3b5afbd4e682f76e16ea85883af571165bd24ee
> and perhaps even
> 91681302d0308a70aece883c3b56a18f9a44041f
>
> We can do that another day, so the series is
> Reviewed-by: Emil Velikov 

Thanks!  I just remembered that I missed this junk in 3/3:

--- a/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
+++ b/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
@@ -93,17 +93,6 @@ static const struct drm_driver_descriptor 
driver_descriptors[] = {
 .create_screen = pipe_i915_create_screen,
 .configuration = configuration_query,
 },
-#ifdef USE_VC4_SIMULATOR
-/* VC4 simulator and ILO (i965) are mutually exclusive (error at
- * configure). As the latter is unconditionally added, keep this one above
- * it.
- */
-{
-.driver_name = "i965",
-.create_screen = pipe_vc4_create_screen,
-.configuration = configuration_query,
-},
-#endif
 {
 .driver_name = "nouveau",
 .create_screen = pipe_nouveau_create_screen,

so it gets even better.  I'll give others a chance to get feedback in,
but I'm glad to hear it might be useful for other drivers.


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] radeon/ac: move common llvm build functions to a separate file.

[Marek Olšák]

Thanks!

Reviewed-by: Marek Olšák 

Marek

On Fri, Feb 3, 2017 at 1:05 AM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> Suggested by Marek.
>
> Signed-off-by: Dave Airlie 
> ---
>  src/amd/Makefile.sources  |   2 +
>  src/amd/common/ac_llvm_build.c| 752 
> ++
>  src/amd/common/ac_llvm_build.h| 177 +
>  src/amd/common/ac_llvm_util.c | 717 +
>  src/amd/common/ac_llvm_util.h | 135 
>  src/amd/common/ac_nir_to_llvm.c   |   1 +
>  src/gallium/drivers/radeonsi/si_shader_internal.h |   1 +
>  7 files changed, 934 insertions(+), 851 deletions(-)
>  create mode 100644 src/amd/common/ac_llvm_build.c
>  create mode 100644 src/amd/common/ac_llvm_build.h
>
> diff --git a/src/amd/Makefile.sources b/src/amd/Makefile.sources
> index d981453..7aaa90a 100644
> --- a/src/amd/Makefile.sources
> +++ b/src/amd/Makefile.sources
> @@ -29,6 +29,8 @@ ADDRLIB_FILES = \
>  AMD_COMPILER_FILES = \
> common/ac_binary.c \
> common/ac_binary.h \
> +   common/ac_llvm_build.c \
> +   common/ac_llvm_build.h \
> common/ac_llvm_helper.cpp \
> common/ac_llvm_util.c \
> common/ac_llvm_util.h
> diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
> new file mode 100644
> index 000..afcbf31
> --- /dev/null
> +++ b/src/amd/common/ac_llvm_build.c
> @@ -0,0 +1,752 @@
> +/*
> + * Copyright 2014 Advanced Micro Devices, Inc.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the
> + * "Software"), to deal in the Software without restriction, including
> + * without limitation the rights to use, copy, modify, merge, publish,
> + * distribute, sub license, and/or sell copies of the Software, and to
> + * permit persons to whom the Software is furnished to do so, subject to
> + * the following conditions:
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
> + * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY 
> CLAIM,
> + * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
> + * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
> + * USE OR OTHER DEALINGS IN THE SOFTWARE.
> + *
> + * The above copyright notice and this permission notice (including the
> + * next paragraph) shall be included in all copies or substantial portions
> + * of the Software.
> + *
> + */
> +/* based on pieces from si_pipe.c and radeon_llvm_emit.c */
> +#include "ac_llvm_build.h"
> +
> +#include 
> +
> +#include "c11/threads.h"
> +
> +#include 
> +#include 
> +
> +#include "ac_llvm_util.h"
> +
> +#include "util/bitscan.h"
> +#include "util/macros.h"
> +#include "sid.h"
> +
> +/* Initialize module-independent parts of the context.
> + *
> + * The caller is responsible for initializing ctx::module and ctx::builder.
> + */
> +void
> +ac_llvm_context_init(struct ac_llvm_context *ctx, LLVMContextRef context)
> +{
> +   LLVMValueRef args[1];
> +
> +   ctx->context = context;
> +   ctx->module = NULL;
> +   ctx->builder = NULL;
> +
> +   ctx->voidt = LLVMVoidTypeInContext(ctx->context);
> +   ctx->i1 = LLVMInt1TypeInContext(ctx->context);
> +   ctx->i8 = LLVMInt8TypeInContext(ctx->context);
> +   ctx->i32 = LLVMIntTypeInContext(ctx->context, 32);
> +   ctx->f32 = LLVMFloatTypeInContext(ctx->context);
> +   ctx->v4i32 = LLVMVectorType(ctx->i32, 4);
> +   ctx->v4f32 = LLVMVectorType(ctx->f32, 4);
> +   ctx->v16i8 = LLVMVectorType(ctx->i8, 16);
> +
> +   ctx->range_md_kind = LLVMGetMDKindIDInContext(ctx->context,
> +"range", 5);
> +
> +   ctx->invariant_load_md_kind = LLVMGetMDKindIDInContext(ctx->context,
> +  
> "invariant.load", 14);
> +
> +   ctx->fpmath_md_kind = LLVMGetMDKindIDInContext(ctx->context, 
> "fpmath", 6);
> +
> +   args[0] = LLVMConstReal(ctx->f32, 2.5);
> +   ctx->fpmath_md_2p5_ulp = LLVMMDNodeInContext(ctx->context, args, 1);
> +
> +   ctx->uniform_md_kind = LLVMGetMDKindIDInContext(ctx->context,
> +   "amdgpu.uniform", 14);
> +
> +   ctx->empty_md = LLVMMDNodeInContext(ctx->context, NULL, 0);
> +}
> +
> +LLVMValueRef
> +ac_emit_llvm_intrinsic(struct ac_llvm_context *ctx, const char *name,
> +  LLVMTypeRef return_type, LLVMValueRef *params,
> +  unsigned param_count, unsigned attrib_mask)
> +{
> +   LLVMValueRef function;
> 

Re: [Mesa-dev] [PATCH] configure.ac: describe what all the LIBDRM_*REQUIRED macros mean

[Emil Velikov]

On 2 February 2017 at 17:26, Kenneth Graunke  wrote:
> On Thursday, February 2, 2017 9:15:47 AM PST Chad Versace wrote:
>> On Thu 02 Feb 2017, Emil Velikov wrote:
>> > From: Emil Velikov 
>> >
>> > They are versions of the respective libdrm package. They are _not_ the
>> > version of libdrm[.so] required for driver X.
>> >
>> > Doing the latter will lead to combinatoric explosion and in all fairness
>> > things will likely be broken most of the time.
>> >
>> > To make things even more confusing the kernel UAPI is provided by libdrm
>> > itself.
>> >
>> > Cc: Vinson Lee 
>> > Cc: Kenneth Graunke 
>> > Signed-off-by: Emil Velikov 
>> > ---
>> > Ken, you/Chad have things spot on. Yet semes like other people struggle
>> > deeply with these.
>>
>> Actually, I agree with airlied and imirkin. I made a mistake when
>> I bumped LIBDRM_REQUIRED.
>
> Me too...
Fwiw the patch was correct, just that the behaviour did no match the
expectations ;-)
But that was fixed so, everything is back to normal.

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

Re: [Mesa-dev] [PATCH] glsl: correct compute shader checks for memoryBarrier functions

[Anuj Phogat]

On Fri, Feb 3, 2017 at 7:25 AM, Marc Di Luzio
 wrote:
> As per the spec -
> "The functions memoryBarrierShared() and groupMemoryBarrier() are
> available only in compute shaders; the other functions are available
> in all shader types."
>
> Conform to this by adding another delegate to check for compute
> shader support instead of only whether the current stage is compute
>
> This allows some fragment shaders in Dirt Rally to compile
> ---
>  src/compiler/glsl/builtin_functions.cpp | 18 --
>  1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/src/compiler/glsl/builtin_functions.cpp 
> b/src/compiler/glsl/builtin_functions.cpp
> index 6d3b950..ac74636 100644
> --- a/src/compiler/glsl/builtin_functions.cpp
> +++ b/src/compiler/glsl/builtin_functions.cpp
> @@ -538,6 +538,12 @@ compute_shader(const _mesa_glsl_parse_state *state)
>  }
>
>  static bool
> +compute_shader_supported(const _mesa_glsl_parse_state *state)
> +{
> +   return state->has_compute_shader();
> +}
> +
> +static bool
>  buffer_atomics_supported(const _mesa_glsl_parse_state *state)
>  {
> return compute_shader(state) || shader_storage_buffer_object(state);
> @@ -1098,15 +1104,15 @@ builtin_builder::create_intrinsics()
>ir_intrinsic_group_memory_barrier),
>  NULL);
> add_function("__intrinsic_memory_barrier_atomic_counter",
> -_memory_barrier_intrinsic(compute_shader,
> +_memory_barrier_intrinsic(compute_shader_supported,
>
> ir_intrinsic_memory_barrier_atomic_counter),
>  NULL);
> add_function("__intrinsic_memory_barrier_buffer",
> -_memory_barrier_intrinsic(compute_shader,
> +_memory_barrier_intrinsic(compute_shader_supported,
>
> ir_intrinsic_memory_barrier_buffer),
>  NULL);
> add_function("__intrinsic_memory_barrier_image",
> -_memory_barrier_intrinsic(compute_shader,
> +_memory_barrier_intrinsic(compute_shader_supported,
>ir_intrinsic_memory_barrier_image),
>  NULL);
> add_function("__intrinsic_memory_barrier_shared",
> @@ -2958,15 +2964,15 @@ builtin_builder::create_builtins()
>  NULL);
> add_function("memoryBarrierAtomicCounter",
>  _memory_barrier("__intrinsic_memory_barrier_atomic_counter",
> -compute_shader),
> +compute_shader_supported),
>  NULL);
> add_function("memoryBarrierBuffer",
>  _memory_barrier("__intrinsic_memory_barrier_buffer",
> -compute_shader),
> +compute_shader_supported),
>  NULL);
> add_function("memoryBarrierImage",
>  _memory_barrier("__intrinsic_memory_barrier_image",
> -compute_shader),
> +compute_shader_supported),
>  NULL);
> add_function("memoryBarrierShared",
>  _memory_barrier("__intrinsic_memory_barrier_shared",
> --
> 2.9.3
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Cross checked the GLSL 4.5 spec. Please add:
Cc: 17.0 

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

Re: [Mesa-dev] [PATCH 1/3] ilo: EOL unplumb unmaintained gallium drv from winsys

[Emil Velikov]

Hi Edward,

On 2 February 2017 at 08:15, Edward O'Callaghan
 wrote:
> This is no longer actively maintained and is just
> accumulating bitrot.
>
> Signed-off-by: Edward O'Callaghan 
> ---
>  .../auxiliary/pipe-loader/pipe_loader_drm.c|  5 ---
>  src/gallium/auxiliary/target-helpers/drm_helper.h  | 29 -
>  src/gallium/targets/dri/target.c   |  3 --
>  src/gallium/targets/pipe-loader/pipe_i965.c| 47 
> --
>  src/gallium/winsys/intel/drm/intel_drm_winsys.c|  1 -
>  5 files changed, 85 deletions(-)
>  delete mode 100644 src/gallium/targets/pipe-loader/pipe_i965.c
>
Was there any problems with keeping this patch as 2/3 ? As-is this
causes interment 'breakage', since as we enable ilo one won't be able
to use it.
Not a huge deal, but still.

> --- a/src/gallium/winsys/intel/drm/intel_drm_winsys.c
> +++ b/src/gallium/winsys/intel/drm/intel_drm_winsys.c
> @@ -41,7 +41,6 @@
>  #include "util/u_inlines.h"
>  #include "util/u_memory.h"
>  #include "util/u_debug.h"
> -#include "ilo/core/intel_winsys.h"
>  #include "intel_drm_public.h"
>
Completely forgot that we can/should nuke the winsys as well. Can you
send a final patch 4/3 that does so ?

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

Re: [Mesa-dev] [PATCH 2/3] loader: Add an environment variable to override driver name choice.

[Emil Velikov]

On 3 February 2017 at 19:13, Eric Anholt  wrote:
> My vc4 simulator has been implemented so far by having an entrypoint
> claiming to be i965, which was a bit gross.  The simulator would be a lot
> less special if we entered through the vc4 entrypoint like normal, so add
> a loader environment variable to allow the i965 fd to probe as vc4.
> ---
>  src/loader/loader.c | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/src/loader/loader.c b/src/loader/loader.c
> index 449ff54d1377..4825151ad5e5 100644
> --- a/src/loader/loader.c
> +++ b/src/loader/loader.c
> @@ -345,6 +345,17 @@ loader_get_driver_for_fd(int fd)
> int vendor_id, chip_id, i, j;
> char *driver = NULL;
>
> +   /* Allow an environment variable to force choosing a different driver
> +* binary.  If that driver binary can't survive on this FD, that's the
> +* user's problem, but this allows vc4 simulator to run on an i965 host,
> +* and may be useful for some touch testing of i915 on an i965 host.
> +*/
> +   if (geteuid() == getuid()) {
> +  driver = getenv("MESA_LOADER_DRIVER_OVERRIDE");
Having the override is quite useful even outside the context of vc4.

With this in place we could drop a few other workarounds like

64a005e3eef2e12b11b2837dc7253020bb5c0e60
c3b5afbd4e682f76e16ea85883af571165bd24ee
and perhaps even
91681302d0308a70aece883c3b56a18f9a44041f

We can do that another day, so the series is
Reviewed-by: Emil Velikov 

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

[Mesa-dev] [PATCH 1/3] targets: Use a macro to reduce cut and paste in driver setup.

[Eric Anholt]

All the replicated prototypes/function bodies obfuscated the interesting
logic of the file: the mapping from driver enable macros to entrypoints we
expose, and the way that the swrast entrypoints are special compared to
the DRM entrypoints.
---
 src/gallium/targets/dri/target.c | 133 +++
 1 file changed, 22 insertions(+), 111 deletions(-)

diff --git a/src/gallium/targets/dri/target.c b/src/gallium/targets/dri/target.c
index dba18cce65cc..df93c94ea832 100644
--- a/src/gallium/targets/dri/target.c
+++ b/src/gallium/targets/dri/target.c
@@ -3,6 +3,14 @@
 
 #include "dri_screen.h"
 
+#define DEFINE_LOADER_DRM_ENTRYPOINT(drivername)  \
+const __DRIextension **__driDriverGetExtensions_##drivername(void);   \
+PUBLIC const __DRIextension **__driDriverGetExtensions_##drivername(void) \
+{ \
+   globalDriverAPI = _driver_api;  \
+   return galliumdrm_driver_extensions;   \
+}
+
 #if defined(GALLIUM_SOFTPIPE)
 
 const __DRIextension **__driDriverGetExtensions_swrast(void);
@@ -27,154 +35,57 @@ PUBLIC const __DRIextension 
**__driDriverGetExtensions_kms_swrast(void)
 #endif
 
 #if defined(GALLIUM_I915)
-
-const __DRIextension **__driDriverGetExtensions_i915(void);
-
-PUBLIC const __DRIextension **__driDriverGetExtensions_i915(void)
-{
-   globalDriverAPI = _driver_api;
-   return galliumdrm_driver_extensions;
-}
+DEFINE_LOADER_DRM_ENTRYPOINT(i915)
 #endif
 
 #if defined(GALLIUM_ILO)
-
-const __DRIextension **__driDriverGetExtensions_i965(void);
-
-PUBLIC const __DRIextension **__driDriverGetExtensions_i965(void)
-{
-   globalDriverAPI = _driver_api;
-   return galliumdrm_driver_extensions;
-}
+DEFINE_LOADER_DRM_ENTRYPOINT(i965)
 #endif
 
 #if defined(GALLIUM_NOUVEAU)
-
-const __DRIextension **__driDriverGetExtensions_nouveau(void);
-
-PUBLIC const __DRIextension **__driDriverGetExtensions_nouveau(void)
-{
-   globalDriverAPI = _driver_api;
-   return galliumdrm_driver_extensions;
-}
+DEFINE_LOADER_DRM_ENTRYPOINT(nouveau)
 #endif
 
 #if defined(GALLIUM_R300)
-
-const __DRIextension **__driDriverGetExtensions_r300(void);
-
-PUBLIC const __DRIextension **__driDriverGetExtensions_r300(void)
-{
-   globalDriverAPI = _driver_api;
-   return galliumdrm_driver_extensions;
-}
+DEFINE_LOADER_DRM_ENTRYPOINT(r300)
 #endif
 
 #if defined(GALLIUM_R600)
-
-const __DRIextension **__driDriverGetExtensions_r600(void);
-
-PUBLIC const __DRIextension **__driDriverGetExtensions_r600(void)
-{
-   globalDriverAPI = _driver_api;
-   return galliumdrm_driver_extensions;
-}
+DEFINE_LOADER_DRM_ENTRYPOINT(r600)
 #endif
 
 #if defined(GALLIUM_RADEONSI)
-
-const __DRIextension **__driDriverGetExtensions_radeonsi(void);
-
-PUBLIC const __DRIextension **__driDriverGetExtensions_radeonsi(void)
-{
-   globalDriverAPI = _driver_api;
-   return galliumdrm_driver_extensions;
-}
+DEFINE_LOADER_DRM_ENTRYPOINT(radeonsi)
 #endif
 
 #if defined(GALLIUM_VMWGFX)
-
-const __DRIextension **__driDriverGetExtensions_vmwgfx(void);
-
-PUBLIC const __DRIextension **__driDriverGetExtensions_vmwgfx(void)
-{
-   globalDriverAPI = _driver_api;
-   return galliumdrm_driver_extensions;
-}
+DEFINE_LOADER_DRM_ENTRYPOINT(vmwgfx)
 #endif
 
 #if defined(GALLIUM_FREEDRENO)
-
-const __DRIextension **__driDriverGetExtensions_msm(void);
-
-PUBLIC const __DRIextension **__driDriverGetExtensions_msm(void)
-{
-   globalDriverAPI = _driver_api;
-   return galliumdrm_driver_extensions;
-}
-
-const __DRIextension **__driDriverGetExtensions_kgsl(void);
-
-PUBLIC const __DRIextension **__driDriverGetExtensions_kgsl(void)
-{
-   globalDriverAPI = _driver_api;
-   return galliumdrm_driver_extensions;
-}
+DEFINE_LOADER_DRM_ENTRYPOINT(msm)
+DEFINE_LOADER_DRM_ENTRYPOINT(kgsl)
 #endif
 
 #if defined(GALLIUM_VIRGL)
-
-const __DRIextension **__driDriverGetExtensions_virtio_gpu(void);
-
-PUBLIC const __DRIextension **__driDriverGetExtensions_virtio_gpu(void)
-{
-   globalDriverAPI = _driver_api;
-   return galliumdrm_driver_extensions;
-}
+DEFINE_LOADER_DRM_ENTRYPOINT(virtio_gpu)
 #endif
 
 #if defined(GALLIUM_VC4)
-
-const __DRIextension **__driDriverGetExtensions_vc4(void);
-
-PUBLIC const __DRIextension **__driDriverGetExtensions_vc4(void)
-{
-   globalDriverAPI = _driver_api;
-   return galliumdrm_driver_extensions;
-}
+DEFINE_LOADER_DRM_ENTRYPOINT(vc4)
 
 #if defined(USE_VC4_SIMULATOR)
-const __DRIextension **__driDriverGetExtensions_i965(void);
-
 /**
  * When building using the simulator (on x86), we advertise ourselves as the
  * i965 driver so that you can just make a directory with a link from
  * i965_dri.so to the built vc4_dri.so, and point LIBGL_DRIVERS_PATH to that
  * on your i965-using host to run the driver under simulation.
  */
-PUBLIC const __DRIextension **__driDriverGetExtensions_i965(void)
-{
-   globalDriverAPI = _driver_api;
-   return galliumdrm_driver_extensions;
-}

[Mesa-dev] [PATCH 3/3] targets: Remove vc4 simulator hack.

[Eric Anholt]

Now that there's MESA_LOADER_DRIVER_OVERRIDE for choosing the driver name
we load, we don't need this any more.
---
 src/gallium/targets/dri/target.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/src/gallium/targets/dri/target.c b/src/gallium/targets/dri/target.c
index df93c94ea832..d24a61d1563d 100644
--- a/src/gallium/targets/dri/target.c
+++ b/src/gallium/targets/dri/target.c
@@ -73,16 +73,6 @@ DEFINE_LOADER_DRM_ENTRYPOINT(virtio_gpu)
 
 #if defined(GALLIUM_VC4)
 DEFINE_LOADER_DRM_ENTRYPOINT(vc4)
-
-#if defined(USE_VC4_SIMULATOR)
-/**
- * When building using the simulator (on x86), we advertise ourselves as the
- * i965 driver so that you can just make a directory with a link from
- * i965_dri.so to the built vc4_dri.so, and point LIBGL_DRIVERS_PATH to that
- * on your i965-using host to run the driver under simulation.
- */
-DEFINE_LOADER_DRM_ENTRYPOINT(i965)
-#endif
 #endif
 
 #if defined(GALLIUM_ETNAVIV)
-- 
2.11.0

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

[Mesa-dev] [PATCH 2/3] loader: Add an environment variable to override driver name choice.

[Eric Anholt]

My vc4 simulator has been implemented so far by having an entrypoint
claiming to be i965, which was a bit gross.  The simulator would be a lot
less special if we entered through the vc4 entrypoint like normal, so add
a loader environment variable to allow the i965 fd to probe as vc4.
---
 src/loader/loader.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/src/loader/loader.c b/src/loader/loader.c
index 449ff54d1377..4825151ad5e5 100644
--- a/src/loader/loader.c
+++ b/src/loader/loader.c
@@ -345,6 +345,17 @@ loader_get_driver_for_fd(int fd)
int vendor_id, chip_id, i, j;
char *driver = NULL;
 
+   /* Allow an environment variable to force choosing a different driver
+* binary.  If that driver binary can't survive on this FD, that's the
+* user's problem, but this allows vc4 simulator to run on an i965 host,
+* and may be useful for some touch testing of i915 on an i965 host.
+*/
+   if (geteuid() == getuid()) {
+  driver = getenv("MESA_LOADER_DRIVER_OVERRIDE");
+  if (driver)
+ return strdup(driver);
+   }
+
if (!loader_get_pci_id_for_fd(fd, _id, _id)) {
 
 #if HAVE_LIBDRM
-- 
2.11.0

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

Re: [Mesa-dev] [PATCH] docs: replace URL in features.txt

[Kenneth Graunke]

On Friday, February 3, 2017 11:48:50 AM PST Brian Paul wrote:
> Replace unmaintained http://dri.freedesktop.org/wiki/MissingFunctionality
> URL with http://mesamatrix.net/
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95460
> ---
>  docs/features.txt | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/docs/features.txt b/docs/features.txt
> index 55b1fbb..2f2d41d 100644
> --- a/docs/features.txt
> +++ b/docs/features.txt
> @@ -333,5 +333,6 @@ we DO NOT WANT implementations of these extensions for 
> Mesa.
>GL_ARB_shadow_ambient Superseded by 
> GL_ARB_fragment_program
>GL_ARB_vertex_blend   Superseded by 
> GL_ARB_vertex_program
>  
> -More info about these features and the work involved can be found at
> -http://dri.freedesktop.org/wiki/MissingFunctionality
> +
> +A graphical representation of this information can be found at
> +http://mesamatrix.net/
> 

Yeah, we haven't used that page in years...

Acked-by: Kenneth Graunke 


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

[Mesa-dev] [PATCH] docs: replace URL in features.txt

[Brian Paul]

Replace unmaintained http://dri.freedesktop.org/wiki/MissingFunctionality
URL with http://mesamatrix.net/

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95460
---
 docs/features.txt | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/docs/features.txt b/docs/features.txt
index 55b1fbb..2f2d41d 100644
--- a/docs/features.txt
+++ b/docs/features.txt
@@ -333,5 +333,6 @@ we DO NOT WANT implementations of these extensions for Mesa.
   GL_ARB_shadow_ambient Superseded by 
GL_ARB_fragment_program
   GL_ARB_vertex_blend   Superseded by 
GL_ARB_vertex_program
 
-More info about these features and the work involved can be found at
-http://dri.freedesktop.org/wiki/MissingFunctionality
+
+A graphical representation of this information can be found at
+http://mesamatrix.net/
-- 
1.9.1

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

Re: [Mesa-dev] [RFC PATCH 1/1] st/dri: add a new driconf option override_glsl_version for ARK games

[Bas Nieuwenhuizen]

On Fri, Feb 3, 2017, at 19:24, Jason Ekstrand wrote:

> On Fri, Feb 3, 2017 at 9:23 AM, Samuel Pitoiset
>  wrote:
>> This is similar to the MESA_GLSL_VERSION_OVERRIDE envvar (mainly

>> for developers). But this one has the advantage to be configured

>> for specific apps which require a context with an explicit version.

>> 

>> For example, when an app requires a 3.2 core context, RadeonSI

>> will return a 4.5 context but this might fail (eg. ARK games).

> 

> Why is returning a 4.5 context a problem?  It's supposed to be more-or-
> less backwards compatible.
> I'm also a bit concerned about making this driconf option be global
> across drivers without it being just a maximum.  Suppose someone sets
> it to 4.3 for some app that doesn't like 4.5.  What happens if they
> try to run that app on hardware that doesn't support 4.3?  Do they get
> a 4.3 context that just doesn't work?


As far as I can see[1], when the game detects GL 4.3+, the engine
tries to load a different set of shaders from disk, but the game
developers have not enabled the right flag during building, so the
shaders for GL4.3+ are not actually distributed with the game, which
results in a failure to load the game. From my POV this is entirely
the fault of the game.


That said, the bug contains a report from someone else that it works on
intel with GL4.3+. I never got to test that or look deeper into this, so
it could very well be that I overlooked something during this analysis.


- Bas



[1]: https://bugs.freedesktop.org/show_bug.cgi?id=95374
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC PATCH 1/1] st/dri: add a new driconf option override_glsl_version for ARK games

[Jason Ekstrand]

On Fri, Feb 3, 2017 at 9:23 AM, Samuel Pitoiset 
wrote:

> This is similar to the MESA_GLSL_VERSION_OVERRIDE envvar (mainly
> for developers). But this one has the advantage to be configured
> for specific apps which require a context with an explicit version.
>
> For example, when an app requires a 3.2 core context, RadeonSI
> will return a 4.5 context but this might fail (eg. ARK games).
>

Why is returning a 4.5 context a problem?  It's supposed to be more-or-less
backwards compatible.

I'm also a bit concerned about making this driconf option be global across
drivers without it being just a maximum.  Suppose someone sets it to 4.3
for some app that doesn't like 4.5.  What happens if they try to run that
app on hardware that doesn't support 4.3?  Do they get a 4.3 context that
just doesn't work?


> No need to add both "ARK: Survival Evolved" and "ARK: Survival
> Of The Fittest" because the executable name is the same.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/gallium/include/state_tracker/st_api.h  | 1 +
>  src/gallium/state_trackers/dri/dri_screen.c | 3 +++
>  src/gallium/state_trackers/osmesa/osmesa.c  | 1 +
>  src/mesa/drivers/dri/common/drirc   | 4 
>  src/mesa/drivers/dri/common/xmlpool/t_options.h | 5 +
>  src/mesa/drivers/dri/i965/brw_context.c | 3 +++
>  src/mesa/state_tracker/st_extensions.c  | 3 +++
>  7 files changed, 20 insertions(+)
>
> diff --git a/src/gallium/include/state_tracker/st_api.h
> b/src/gallium/include/state_tracker/st_api.h
> index a2e37d2e48..e0a73d74ad 100644
> --- a/src/gallium/include/state_tracker/st_api.h
> +++ b/src/gallium/include/state_tracker/st_api.h
> @@ -246,6 +246,7 @@ struct st_config_options
> boolean force_s3tc_enable;
> boolean allow_glsl_extension_directive_midshader;
> boolean glsl_zero_init;
> +   unsigned override_glsl_version;
>  };
>
>  /**
> diff --git a/src/gallium/state_trackers/dri/dri_screen.c
> b/src/gallium/state_trackers/dri/dri_screen.c
> index a950f5241d..a1fa0a3be3 100644
> --- a/src/gallium/state_trackers/dri/dri_screen.c
> +++ b/src/gallium/state_trackers/dri/dri_screen.c
> @@ -70,6 +70,7 @@ const __DRIconfigOptionsExtension gallium_config_options
> = {
>   DRI_CONF_DISABLE_SHADER_BIT_ENCODING("false")
>   DRI_CONF_FORCE_GLSL_VERSION(0)
>   DRI_CONF_ALLOW_GLSL_EXTENSION_DIRECTIVE_MIDSHADER("false")
> + DRI_CONF_OVERRIDE_GLSL_VERSION(0)
>DRI_CONF_SECTION_END
>
>DRI_CONF_SECTION_MISCELLANEOUS
> @@ -100,6 +101,8 @@ dri_fill_st_options(struct st_config_options *options,
> options->allow_glsl_extension_directive_midshader =
>driQueryOptionb(optionCache, "allow_glsl_extension_
> directive_midshader");
> options->glsl_zero_init = driQueryOptionb(optionCache,
> "glsl_zero_init");
> +   options->override_glsl_version =
> +  driQueryOptioni(optionCache, "override_glsl_version");
>  }
>
>  static const __DRIconfig **
> diff --git a/src/gallium/state_trackers/osmesa/osmesa.c
> b/src/gallium/state_trackers/osmesa/osmesa.c
> index 18f1b88128..8102be14ed 100644
> --- a/src/gallium/state_trackers/osmesa/osmesa.c
> +++ b/src/gallium/state_trackers/osmesa/osmesa.c
> @@ -679,6 +679,7 @@ OSMesaCreateContextAttribs(const int *attribList,
> OSMesaContext sharelist)
> attribs.options.disable_shader_bit_encoding = FALSE;
> attribs.options.force_s3tc_enable = FALSE;
> attribs.options.force_glsl_version = 0;
> +   attribs.options.override_glsl_version = 0;
>
> osmesa_init_st_visual(,
>   PIPE_FORMAT_R8G8B8A8_UNORM,
> diff --git a/src/mesa/drivers/dri/common/drirc
> b/src/mesa/drivers/dri/common/drirc
> index 20fd8123e4..52c121a064 100644
> --- a/src/mesa/drivers/dri/common/drirc
> +++ b/src/mesa/drivers/dri/common/drirc
> @@ -104,5 +104,9 @@ TODO: document the other workarounds.
>   executable="EoCApp">
>   value="true" />
>  
> +
> + executable="ShooterGame">
> +
> +
>  
>  
> diff --git a/src/mesa/drivers/dri/common/xmlpool/t_options.h
> b/src/mesa/drivers/dri/common/xmlpool/t_options.h
> index a189bbedec..fb9ecbe3e7 100644
> --- a/src/mesa/drivers/dri/common/xmlpool/t_options.h
> +++ b/src/mesa/drivers/dri/common/xmlpool/t_options.h
> @@ -110,6 +110,11 @@ DRI_CONF_OPT_BEGIN_V(force_glsl_version, int, def,
> "0:999") \
>  DRI_CONF_DESC(en,gettext("Force a default GLSL version for
> shaders that lack an explicit #version line")) \
>  DRI_CONF_OPT_END
>
> +#define DRI_CONF_OVERRIDE_GLSL_VERSION(def) \
> +DRI_CONF_OPT_BEGIN_V(override_glsl_version, int, def, "0:999") \
> +DRI_CONF_DESC(en,gettext("Override the GLSL version for apps
> that require an explicit version")) \
> +DRI_CONF_OPT_END
> +
>  #define DRI_CONF_ALLOW_GLSL_EXTENSION_DIRECTIVE_MIDSHADER(def) \
>  DRI_CONF_OPT_BEGIN_B(allow_glsl_extension_directive_midshader, def) \
>  

Re: [Mesa-dev] [RFC PATCH 1/1] st/dri: add a new driconf option override_glsl_version for ARK games

[Samuel Pitoiset]

On 02/03/2017 06:29 PM, Ilia Mirkin wrote:

On Fri, Feb 3, 2017 at 12:23 PM, Samuel Pitoiset
 wrote:

This is similar to the MESA_GLSL_VERSION_OVERRIDE envvar (mainly
for developers). But this one has the advantage to be configured
for specific apps which require a context with an explicit version.

For example, when an app requires a 3.2 core context, RadeonSI
will return a 4.5 context but this might fail (eg. ARK games).

No need to add both "ARK: Survival Evolved" and "ARK: Survival
Of The Fittest" because the executable name is the same.



You're talking about these things in a manner that confuses me. You
talk about GLSL version overrides, and that's what your patch does.
However what you're really trying to do is limit the GL version of the
resulting context. My guess specifically is that you want to turn off
the context version upgrade logic. Either limit ctx->Version or try to
adjust that logic.


That seems better. But it was easier to re-use the same logic as 
MESA_GLSL_VERSION_OVERRIDE.




I don't see what this has to do with GLSL versions.

Side-note - there's no GLSL version 320. Perhaps you meant 150 (the
GLSL version associated with GL 3.2).


My mistake. It will fallback to GL 3.2 anyway but that's wrong.



  -ilia


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

[Mesa-dev] [PATCH] swr: [rasterizer core] Removed unused clip code.

[Bruce Cherniak]

Removed unused Clip() and FRUSTUM_CLIP_MASK define.
---
 src/gallium/drivers/swr/rasterizer/core/clip.cpp | 22 --
 src/gallium/drivers/swr/rasterizer/core/clip.h   |  4 
 2 files changed, 26 deletions(-)

diff --git a/src/gallium/drivers/swr/rasterizer/core/clip.cpp 
b/src/gallium/drivers/swr/rasterizer/core/clip.cpp
index 7b1e09d..0a6afe5 100644
--- a/src/gallium/drivers/swr/rasterizer/core/clip.cpp
+++ b/src/gallium/drivers/swr/rasterizer/core/clip.cpp
@@ -157,28 +157,6 @@ int ClipTriToPlane( const float *pInPts, int numInPts,
 return i;
 }
 
-
-
-void Clip(const float *pTriangle, const float *pAttribs, int numAttribs, float 
*pOutTriangles, int *numVerts, float *pOutAttribs)
-{
-// temp storage to hold at least 6 sets of vertices, the max number that 
can be created during clipping
-OSALIGNSIMD(float) tempPts[6 * 4];
-OSALIGNSIMD(float) tempAttribs[6 * KNOB_NUM_ATTRIBUTES * 4];
-
-// we opt to clip to viewport frustum to produce smaller triangles for 
rasterization precision
-int NumOutPts = ClipTriToPlane(pTriangle, 3, pAttribs, 
numAttribs, tempPts, tempAttribs);
-NumOutPts = ClipTriToPlane(tempPts, NumOutPts, tempAttribs, 
numAttribs, pOutTriangles, pOutAttribs);
-NumOutPts = ClipTriToPlane(pOutTriangles, NumOutPts, 
pOutAttribs, numAttribs, tempPts, tempAttribs);
-NumOutPts = ClipTriToPlane(tempPts, NumOutPts, tempAttribs, 
numAttribs, pOutTriangles, pOutAttribs);
-NumOutPts = ClipTriToPlane(pOutTriangles, NumOutPts, 
pOutAttribs, numAttribs, tempPts, tempAttribs);
-NumOutPts = ClipTriToPlane(tempPts, NumOutPts, tempAttribs, 
numAttribs, pOutTriangles, pOutAttribs);
-
-SWR_ASSERT(NumOutPts <= 6);
-
-*numVerts = NumOutPts;
-return;
-}
-
 void ClipTriangles(DRAW_CONTEXT *pDC, PA_STATE& pa, uint32_t workerId, 
simdvector prims[], uint32_t primMask, simdscalari primId, simdscalari 
viewportIdx)
 {
 SWR_CONTEXT *pContext = pDC->pContext;
diff --git a/src/gallium/drivers/swr/rasterizer/core/clip.h 
b/src/gallium/drivers/swr/rasterizer/core/clip.h
index f19858f..23a768f 100644
--- a/src/gallium/drivers/swr/rasterizer/core/clip.h
+++ b/src/gallium/drivers/swr/rasterizer/core/clip.h
@@ -56,12 +56,8 @@ enum SWR_CLIPCODES
 GUARDBAND_BOTTOM = (0x80 << CLIPCODE_SHIFT | 0x8)
 };
 
-#define FRUSTUM_CLIP_MASK 
(FRUSTUM_LEFT|FRUSTUM_TOP|FRUSTUM_RIGHT|FRUSTUM_BOTTOM|FRUSTUM_NEAR|FRUSTUM_FAR)
 #define GUARDBAND_CLIP_MASK 
(FRUSTUM_NEAR|FRUSTUM_FAR|GUARDBAND_LEFT|GUARDBAND_TOP|GUARDBAND_RIGHT|GUARDBAND_BOTTOM|NEGW)
 
-void Clip(const float *pTriangle, const float *pAttribs, int numAttribs, float 
*pOutTriangles, 
-  int *numVerts, float *pOutAttribs);
-
 INLINE
 void ComputeClipCodes(const API_STATE& state, const simdvector& vertex, 
simdscalar& clipCodes, simdscalari viewportIndexes)
 {
-- 
2.7.4

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

Re: [Mesa-dev] [RFC PATCH 1/1] st/dri: add a new driconf option override_glsl_version for ARK games

[Ilia Mirkin]

On Fri, Feb 3, 2017 at 12:23 PM, Samuel Pitoiset
 wrote:
> This is similar to the MESA_GLSL_VERSION_OVERRIDE envvar (mainly
> for developers). But this one has the advantage to be configured
> for specific apps which require a context with an explicit version.
>
> For example, when an app requires a 3.2 core context, RadeonSI
> will return a 4.5 context but this might fail (eg. ARK games).
>
> No need to add both "ARK: Survival Evolved" and "ARK: Survival
> Of The Fittest" because the executable name is the same.
>

You're talking about these things in a manner that confuses me. You
talk about GLSL version overrides, and that's what your patch does.
However what you're really trying to do is limit the GL version of the
resulting context. My guess specifically is that you want to turn off
the context version upgrade logic. Either limit ctx->Version or try to
adjust that logic.

I don't see what this has to do with GLSL versions.

Side-note - there's no GLSL version 320. Perhaps you meant 150 (the
GLSL version associated with GL 3.2).

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

[Mesa-dev] [RFC PATCH 0/1] New driconf option for ARK games

[Samuel Pitoiset]

Hi,

This patch adds a new driconf option override_glsl_version for launching ARK
games without the MESA_GLSL_VERSION_OVERRIDE hack which should be only for
developers.

This sounds redundant with force_glsl_version but that one is only for shaders
that lack an explicit #version line. while this one will change the version of
the core context. And this is especially useful for returning the version
requested by the given app and not a more recent version.

This option is for the ARK games which "explicitely" [1] require a 3.2 context,
and fail if the version is > 3.2. Presumably, "ShellShock Live" [2] will also
need but I don't have that game yet (though I will be able to test in the next
few days).

Although some users know how to launch the ARK games with that envvar, I think
it would be really much better to be able to launch them "natively". And "ARK:
Survival Evolved" is one of the most played game... [3]

I'm open to any suggestions if you don't really like this option.

Comments are welcome!

Thaknks.

[1] https://bugs.freedesktop.org/show_bug.cgi?id=95374
[2] https://www.gamingonlinux.com/wiki/Games_broken_on_Mesa
[3] https://steamdb.info/graph/?category=999

Samuel Pitoiset (1):
  st/dri: add a new driconf option override_glsl_version for ARK games

 src/gallium/include/state_tracker/st_api.h  | 1 +
 src/gallium/state_trackers/dri/dri_screen.c | 3 +++
 src/gallium/state_trackers/osmesa/osmesa.c  | 1 +
 src/mesa/drivers/dri/common/drirc   | 4 
 src/mesa/drivers/dri/common/xmlpool/t_options.h | 5 +
 src/mesa/drivers/dri/i965/brw_context.c | 3 +++
 src/mesa/state_tracker/st_extensions.c  | 3 +++
 7 files changed, 20 insertions(+)

-- 
2.11.0

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

[Mesa-dev] [RFC PATCH 1/1] st/dri: add a new driconf option override_glsl_version for ARK games

[Samuel Pitoiset]

This is similar to the MESA_GLSL_VERSION_OVERRIDE envvar (mainly
for developers). But this one has the advantage to be configured
for specific apps which require a context with an explicit version.

For example, when an app requires a 3.2 core context, RadeonSI
will return a 4.5 context but this might fail (eg. ARK games).

No need to add both "ARK: Survival Evolved" and "ARK: Survival
Of The Fittest" because the executable name is the same.

Signed-off-by: Samuel Pitoiset 
---
 src/gallium/include/state_tracker/st_api.h  | 1 +
 src/gallium/state_trackers/dri/dri_screen.c | 3 +++
 src/gallium/state_trackers/osmesa/osmesa.c  | 1 +
 src/mesa/drivers/dri/common/drirc   | 4 
 src/mesa/drivers/dri/common/xmlpool/t_options.h | 5 +
 src/mesa/drivers/dri/i965/brw_context.c | 3 +++
 src/mesa/state_tracker/st_extensions.c  | 3 +++
 7 files changed, 20 insertions(+)

diff --git a/src/gallium/include/state_tracker/st_api.h 
b/src/gallium/include/state_tracker/st_api.h
index a2e37d2e48..e0a73d74ad 100644
--- a/src/gallium/include/state_tracker/st_api.h
+++ b/src/gallium/include/state_tracker/st_api.h
@@ -246,6 +246,7 @@ struct st_config_options
boolean force_s3tc_enable;
boolean allow_glsl_extension_directive_midshader;
boolean glsl_zero_init;
+   unsigned override_glsl_version;
 };
 
 /**
diff --git a/src/gallium/state_trackers/dri/dri_screen.c 
b/src/gallium/state_trackers/dri/dri_screen.c
index a950f5241d..a1fa0a3be3 100644
--- a/src/gallium/state_trackers/dri/dri_screen.c
+++ b/src/gallium/state_trackers/dri/dri_screen.c
@@ -70,6 +70,7 @@ const __DRIconfigOptionsExtension gallium_config_options = {
  DRI_CONF_DISABLE_SHADER_BIT_ENCODING("false")
  DRI_CONF_FORCE_GLSL_VERSION(0)
  DRI_CONF_ALLOW_GLSL_EXTENSION_DIRECTIVE_MIDSHADER("false")
+ DRI_CONF_OVERRIDE_GLSL_VERSION(0)
   DRI_CONF_SECTION_END
 
   DRI_CONF_SECTION_MISCELLANEOUS
@@ -100,6 +101,8 @@ dri_fill_st_options(struct st_config_options *options,
options->allow_glsl_extension_directive_midshader =
   driQueryOptionb(optionCache, "allow_glsl_extension_directive_midshader");
options->glsl_zero_init = driQueryOptionb(optionCache, "glsl_zero_init");
+   options->override_glsl_version =
+  driQueryOptioni(optionCache, "override_glsl_version");
 }
 
 static const __DRIconfig **
diff --git a/src/gallium/state_trackers/osmesa/osmesa.c 
b/src/gallium/state_trackers/osmesa/osmesa.c
index 18f1b88128..8102be14ed 100644
--- a/src/gallium/state_trackers/osmesa/osmesa.c
+++ b/src/gallium/state_trackers/osmesa/osmesa.c
@@ -679,6 +679,7 @@ OSMesaCreateContextAttribs(const int *attribList, 
OSMesaContext sharelist)
attribs.options.disable_shader_bit_encoding = FALSE;
attribs.options.force_s3tc_enable = FALSE;
attribs.options.force_glsl_version = 0;
+   attribs.options.override_glsl_version = 0;
 
osmesa_init_st_visual(,
  PIPE_FORMAT_R8G8B8A8_UNORM,
diff --git a/src/mesa/drivers/dri/common/drirc 
b/src/mesa/drivers/dri/common/drirc
index 20fd8123e4..52c121a064 100644
--- a/src/mesa/drivers/dri/common/drirc
+++ b/src/mesa/drivers/dri/common/drirc
@@ -104,5 +104,9 @@ TODO: document the other workarounds.
 
 
 
+
+
+
+
 
 
diff --git a/src/mesa/drivers/dri/common/xmlpool/t_options.h 
b/src/mesa/drivers/dri/common/xmlpool/t_options.h
index a189bbedec..fb9ecbe3e7 100644
--- a/src/mesa/drivers/dri/common/xmlpool/t_options.h
+++ b/src/mesa/drivers/dri/common/xmlpool/t_options.h
@@ -110,6 +110,11 @@ DRI_CONF_OPT_BEGIN_V(force_glsl_version, int, def, 
"0:999") \
 DRI_CONF_DESC(en,gettext("Force a default GLSL version for shaders 
that lack an explicit #version line")) \
 DRI_CONF_OPT_END
 
+#define DRI_CONF_OVERRIDE_GLSL_VERSION(def) \
+DRI_CONF_OPT_BEGIN_V(override_glsl_version, int, def, "0:999") \
+DRI_CONF_DESC(en,gettext("Override the GLSL version for apps that 
require an explicit version")) \
+DRI_CONF_OPT_END
+
 #define DRI_CONF_ALLOW_GLSL_EXTENSION_DIRECTIVE_MIDSHADER(def) \
 DRI_CONF_OPT_BEGIN_B(allow_glsl_extension_directive_midshader, def) \
 DRI_CONF_DESC(en,gettext("Allow GLSL #extension directives in the 
middle of shaders")) \
diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
b/src/mesa/drivers/dri/i965/brw_context.c
index 7240b1f445..373985ceb8 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -910,6 +910,9 @@ brw_process_driconf_options(struct brw_context *brw)
ctx->Const.ForceGLSLVersion =
   driQueryOptioni(options, "force_glsl_version");
 
+   ctx->Const.GLSLVersion =
+  driQueryOptioni(options, "override_glsl_version");
+
ctx->Const.DisableGLSLLineContinuations =
   driQueryOptionb(options, "disable_glsl_line_continuations");
 
diff --git a/src/mesa/state_tracker/st_extensions.c 
b/src/mesa/state_tracker/st_extensions.c

Re: [Mesa-dev] [PATCH 5/5] travis: use both cores for make/make check

[Chad Versace]

On Thu 02 Feb 2017, Emil Velikov wrote:
> On 2 February 2017 at 01:27, Eric Anholt  wrote:
> > Emil Velikov  writes:
> >
> >> From: Emil Velikov 
> >>
> >> The instance offers 2 cores, so use them to speed things up.
> >>
> >> Signed-off-by: Emil Velikov 
> >
> > They don't just set MAKEFLAGS in the environment?  That's weird.
> >
> From what I've read they don't, plus they do not provide a accurate
> way to get the information.
> 
> > Looks like an alternative would be to set - MAKEFLAGS=-j2 in the "env:"
> > section, but this also works.  Series is:
> >
> MAKEFLAGS would be better indeed. If it works I'll just go ahead with it.

FWIW, I query the number of CPUs when setting MAKEFLAGS in my ~/.profile.
It's worked for me across many Linux distros.

export MAKEFLAGS="-j$(getconf _NPROCESSORS_ONLN)"
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 2/2] anv: Implement the Sky Lake stencil PMA optimization

[Matt Turner]

On Fri, Feb 3, 2017 at 5:37 PM, Jason Ekstrand  wrote:
> On Thu, Feb 2, 2017 at 11:18 PM, Ben Widawsky  wrote:
>> s/Sky Lake/Skylake/g
>
>
> I can never figure out which it's supposed to be.  The PRM says "Skylake"
> but I thought ARC said "Sky Lake" but, now that I look, it says "Skylake"
> too.  I know I saw some official thing that said "Sky Lake".  Oh well.  I'll
> change it.

Indeed. It's inconsistent that it's Skylake with no space, but Kaby
Lake and Apollo Lake with spaces...
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/5] configure.ac: list all the dri-drivers in the help string

[Chad Versace]

On Thu 02 Feb 2017, Andres Gomez wrote:
> On Wed, 2017-02-01 at 22:30 +, Emil Velikov wrote:
> > From: Emil Velikov 
> > 
> > It's unlikely that any of the additions come as a suprise to anyone
> > i915, nouveau, radeon, r200). Regardless, state clearly what's
> Opening parenthesis? ^
> 
> Otherwise, LGTM.
> 
> Reviewed-by: Andres Gomez 

Same here.
Reviewed-by: Chad Versace 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: Don't crash when destroying contexts created with no visual.

[Chad Versace]

On Fri 03 Feb 2017, Samuel Iglesias Gonsálvez wrote:
> Reviewed-by: Samuel Iglesias Gonsálvez 

> 
> On Thu, 2017-02-02 at 13:14 -0800, Kenneth Graunke wrote:
> > dEQP-EGL.functional.create_context.no_config tries to create a
> > context
> > with no config, then immediately destroys it.  The drawbuffer is
> > never
> > set up, so we can't dereference it asking if it's double buffered, or
> > we'll crash on a null pointer dereference.
> > 
> > Just bail early.

Reviewed-by: Chad Versace 

Also, Mesa supports EGL_KHR_no_config_context. So this fix is probably
needed for realworld cases, not just for deqp.

> > 
> > Signed-off-by: Kenneth Graunke 
> > ---
> >  src/mesa/main/context.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
> > index 7ecd241e6eb..76763489b9f 100644
> > --- a/src/mesa/main/context.c
> > +++ b/src/mesa/main/context.c
> > @@ -1550,7 +1550,7 @@ _mesa_check_init_viewport(struct gl_context
> > *ctx, GLuint width, GLuint height)
> >  static void
> >  handle_first_current(struct gl_context *ctx)
> >  {
> > -   if (ctx->Version == 0) {
> > +   if (ctx->Version == 0 || !ctx->DrawBuffer) {
> >    /* probably in the process of tearing down the context */
> >    return;
> > }
> ___
> 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/2] anv: Implement the Sky Lake stencil PMA optimization

[Jason Ekstrand]

On Thu, Feb 2, 2017 at 11:18 PM, Ben Widawsky  wrote:

> On 17-02-02 13:27:05, Jason Ekstrand wrote:
>
>> This improves the performance of Dota 2 on my Sky Lake Skull Canyon
>> machine by about 2-3%.
>>
>> Reviewed-by: Lionel Landwerlin 
>> ---
>> src/intel/vulkan/anv_private.h |   1 +
>> src/intel/vulkan/gen8_cmd_buffer.c | 157 ++
>> ++-
>> src/intel/vulkan/genX_pipeline.c   |   6 +-
>> 3 files changed, 158 insertions(+), 6 deletions(-)
>>
>> diff --git a/src/intel/vulkan/anv_private.h
>> b/src/intel/vulkan/anv_private.h
>> index 6efe4ea..9f88aef 100644
>> --- a/src/intel/vulkan/anv_private.h
>> +++ b/src/intel/vulkan/anv_private.h
>> @@ -1482,6 +1482,7 @@ struct anv_pipeline {
>>bool writes_depth;
>>bool depth_test_enable;
>>bool writes_stencil;
>> +   bool stencil_test_enable;
>>bool depth_clamp_enable;
>>bool kill_pixel;
>>
>> diff --git a/src/intel/vulkan/gen8_cmd_buffer.c
>> b/src/intel/vulkan/gen8_cmd_buffer.c
>> index 271ab3f..6e44bd6 100644
>> --- a/src/intel/vulkan/gen8_cmd_buffer.c
>> +++ b/src/intel/vulkan/gen8_cmd_buffer.c
>> @@ -157,16 +157,39 @@ __emit_sf_state(struct anv_cmd_buffer *cmd_buffer)
>> void
>> genX(cmd_buffer_enable_pma_fix)(struct anv_cmd_buffer *cmd_buffer, bool
>> enable)
>> {
>> -#if GEN_GEN == 8
>>if (cmd_buffer->state.pma_fix_enabled == enable)
>>   return;
>>
>> +   cmd_buffer->state.pma_fix_enabled = enable;
>> +
>> +   /* According to the Broadwell PIPE_CONTROL documentation, software
>> should
>> +* emit a PIPE_CONTROL with the CS Stall and Depth Cache Flush bits
>> set
>> +* prior to the LRI.  If stencil buffer writes are enabled, then a
>> Render
>> +* Cache Flush is also necessary.
>> +*
>> +* The Sky Lake docs say to use a depth stall rather than a command
>> +* streamer stall.  However, the hardware seems to violently disagree.
>> +* A full command streamer stall seems to be needed in both cases.
>> +*/
>>anv_batch_emit(_buffer->batch, GENX(PIPE_CONTROL), pc) {
>>   pc.DepthCacheFlushEnable = true;
>>   pc.CommandStreamerStallEnable = true;
>>   pc.RenderTargetCacheFlushEnable = true;
>>}
>>
>> +#if GEN_GEN == 9
>> +
>> +   uint32_t cache_mode;
>> +   anv_pack_struct(_mode, GENX(CACHE_MODE_0),
>> +   .STCPMAOptimizationEnable = enable,
>> +   .STCPMAOptimizationEnableMask = true);
>> +   anv_batch_emit(_buffer->batch, GENX(MI_LOAD_REGISTER_IMM), lri) {
>> +  lri.RegisterOffset   = GENX(CACHE_MODE_0_num);
>> +  lri.DataDWord= cache_mode;
>> +   }
>> +
>> +#elif GEN_GEN == 8
>> +
>>uint32_t cache_mode;
>>anv_pack_struct(_mode, GENX(CACHE_MODE_1),
>>.NPPMAFixEnable = enable,
>> @@ -178,18 +201,20 @@ genX(cmd_buffer_enable_pma_fix)(struct
>> anv_cmd_buffer *cmd_buffer, bool enable)
>>   lri.DataDWord= cache_mode;
>>}
>>
>> +#endif /* GEN_GEN == 8 */
>> +
>>/* After the LRI, a PIPE_CONTROL with both the Depth Stall and Depth
>> Cache
>> * Flush bits is often necessary.  We do it regardless because it's
>> easier.
>> * The render cache flush is also necessary if stencil writes are
>> enabled.
>> +*
>> +* Again, the Sky Lake docs give a different set of flushes but the
>> BDW
>> +* flushes seem to work just as well.
>> */
>>anv_batch_emit(_buffer->batch, GENX(PIPE_CONTROL), pc) {
>>   pc.DepthStallEnable = true;
>>   pc.DepthCacheFlushEnable = true;
>>   pc.RenderTargetCacheFlushEnable = true;
>>}
>> -
>> -   cmd_buffer->state.pma_fix_enabled = enable;
>> -#endif /* GEN_GEN == 8 */
>> }
>>
>> static inline bool
>> @@ -283,6 +308,126 @@ want_depth_pma_fix(struct anv_cmd_buffer
>> *cmd_buffer)
>>   wm_prog_data->computed_depth_mode != PSCDEPTH_OFF;
>> }
>>
>> +static inline bool
>> +want_stencil_pma_fix(struct anv_cmd_buffer *cmd_buffer)
>> +{
>> +   assert(GEN_GEN == 9);
>> +
>> +   /* From the Sky Lake PRM Vol. 2c CACHE_MODE_1::STC PMA Optimization
>> Enable:
>> +*
>> +*Clearing this bit will force the STC cache to wait for pending
>> +*retirement of pixels at the HZ-read stage and do the STC-test
>> for
>> +*Non-promoted, R-computed and Computed depth modes instead of
>> +*postponing the STC-test to RCPFE.
>> +*
>> +*STC_TEST_EN = 3DSTATE_STENCIL_BUFFER::STENCIL_BUFFER_ENABLE &&
>> +*  3DSTATE_WM_DEPTH_STENCIL::StencilTestEnable
>> +*
>> +*STC_WRITE_EN = 3DSTATE_STENCIL_BUFFER::STENCIL_BUFFER_ENABLE &&
>> +*   (3DSTATE_WM_DEPTH_STENCIL::Stencil Buffer Write
>> Enable &&
>> +*

Re: [Mesa-dev] [PATCH] anv/pipeline: set ThreadDispatchEnable conditionally

[Kenneth Graunke]

On Friday, February 3, 2017 1:19:16 PM PST Juan A. Suarez Romero wrote:
> Set 3DSTATE_WM/ThreadDispatchEnable bit on/off based on the same
> conditions as used in the GL version.
> 
> Signed-off-by: Juan A. Suarez Romero 
> ---
>  src/intel/vulkan/genX_pipeline.c | 49 
> +---
>  1 file changed, 26 insertions(+), 23 deletions(-)

looks good to me.

Reviewed-by: Kenneth Graunke 


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] Question about handling RGBA/BGRA in etnaviv driver

[Erik Faye-Lund]

On Fri, Feb 3, 2017 at 11:06 AM, Wladimir  wrote:
> Yes, but it seems suboptimal, incurring overhead on every rendered pixel.

Why would this incur overhead? Can't the etnaviv-hardware perform
swizzles for free? I'd assume you could just remap writes to
gl_FragColor-compoents...

>
> Another way that I just realized would be to convert a texture to BGRA the
> first time it's rendered to.
>
> In contrast to the shader solution that has only a one-time overhead. Is
> this a stupid idea for any reason?
>
> Wladimir
>
> On Feb 3, 2017 11:00, "Christian Gmeiner" 
> wrote:
>>
>> Hi,
>>
>> 2017-02-03 10:56 GMT+01:00 Wladimir J. van der Laan :
>> > Hello,
>> >
>> > With the Etnaviv driver we're running into an issue: The GPU can only
>> > render *to*
>> > BGRA formats. It can however render *from* BGRA as well as RGBA
>> > textures.
>> >
>> > I know that the OpenGL ES standard allows drivers to choose what order
>> > is most
>> > appropriate when being asked for "GL_RGBA" textures. So back when
>> > etnaviv supported
>> > only BGRA, Mesa automatically picked that and everything was okay.
>> >
>> > However a recent patch added support for RGBA formats in
>> > etnaviv_format.c.
>> >
>> > Now, Mesa creates a real GL_RGBA texture when this is requested. This is
>> > all
>> > and well for rendering, however for anything using FBO to render to
>> > textures
>> > this is a problem.
>> >
>> > Qt, for example, is assuming it can attach the GL_RGBA texture to a FBO.
>> > This
>> > fails now that GL_RGBA textures are really GL_RGBA, and it doesn't
>> > handle that
>> > error to fall back to something else so rendering issues ensue.
>> >
>> > I'm not sure how to handle this:
>> >
>> > - The quick fix would be to revert the RGBA formats patch, but the
>> > hardware
>> >   supports rendering *from* RGBA textures fine so this would be throwing
>> > away a
>> >   feature.
>> >
>> > - Another way would be to try to fix Qt to cope with this, and try e.g.
>> > GL_BGRA_EXT
>> >   when it wants to render to a texture. Burdening the client code with
>> > this seems
>> >   unintuitive to me.
>> >
>> > - Another hack would be to implement shader variants, and swap R/B in
>> > the pixel
>> >   shader to emulate rendering to RGBA.
>> >
>>
>> In my opinion shader variants are the way to go - almost every driver
>> make use of them to
>> 'fix' such issues.
>>
>> greets
>> --
>> Christian Gmeiner, MSc
>>
>> https://www.youtube.com/user/AloryOFFICIAL
>> https://soundcloud.com/christian-gmeiner
>
>
> ___
> 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 2/3] ilo: EOL drop unmaintained gallium drv from buildsys

[Emil Velikov]

On 2 February 2017 at 08:15, Edward O'Callaghan
 wrote:

>  AM_CONDITIONAL(HAVE_LIBDRM, test "x$have_libdrm" = xyes)
>  AM_CONDITIONAL(HAVE_OSMESA, test "x$enable_osmesa" = xyes)
> @@ -2616,7 +2607,6 @@ AC_CONFIG_FILES([Makefile
> src/gallium/drivers/freedreno/Makefile
> src/gallium/drivers/ddebug/Makefile
> src/gallium/drivers/i915/Makefile
> -   src/gallium/drivers/ilo/Makefile
Ideally we'll drop the winsys/intel/drm one as well, but that could be
done with 4/3 [remove the ilo winsys].

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

[Mesa-dev] [PATCH] glsl: correct compute shader checks for memoryBarrier functions

[Marc Di Luzio]

As per the spec -
"The functions memoryBarrierShared() and groupMemoryBarrier() are
available only in compute shaders; the other functions are available
in all shader types."

Conform to this by adding another delegate to check for compute
shader support instead of only whether the current stage is compute

This allows some fragment shaders in Dirt Rally to compile
---
 src/compiler/glsl/builtin_functions.cpp | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/src/compiler/glsl/builtin_functions.cpp 
b/src/compiler/glsl/builtin_functions.cpp
index 6d3b950..ac74636 100644
--- a/src/compiler/glsl/builtin_functions.cpp
+++ b/src/compiler/glsl/builtin_functions.cpp
@@ -538,6 +538,12 @@ compute_shader(const _mesa_glsl_parse_state *state)
 }
 
 static bool
+compute_shader_supported(const _mesa_glsl_parse_state *state)
+{
+   return state->has_compute_shader();
+}
+
+static bool
 buffer_atomics_supported(const _mesa_glsl_parse_state *state)
 {
return compute_shader(state) || shader_storage_buffer_object(state);
@@ -1098,15 +1104,15 @@ builtin_builder::create_intrinsics()
   ir_intrinsic_group_memory_barrier),
 NULL);
add_function("__intrinsic_memory_barrier_atomic_counter",
-_memory_barrier_intrinsic(compute_shader,
+_memory_barrier_intrinsic(compute_shader_supported,
   
ir_intrinsic_memory_barrier_atomic_counter),
 NULL);
add_function("__intrinsic_memory_barrier_buffer",
-_memory_barrier_intrinsic(compute_shader,
+_memory_barrier_intrinsic(compute_shader_supported,
   ir_intrinsic_memory_barrier_buffer),
 NULL);
add_function("__intrinsic_memory_barrier_image",
-_memory_barrier_intrinsic(compute_shader,
+_memory_barrier_intrinsic(compute_shader_supported,
   ir_intrinsic_memory_barrier_image),
 NULL);
add_function("__intrinsic_memory_barrier_shared",
@@ -2958,15 +2964,15 @@ builtin_builder::create_builtins()
 NULL);
add_function("memoryBarrierAtomicCounter",
 _memory_barrier("__intrinsic_memory_barrier_atomic_counter",
-compute_shader),
+compute_shader_supported),
 NULL);
add_function("memoryBarrierBuffer",
 _memory_barrier("__intrinsic_memory_barrier_buffer",
-compute_shader),
+compute_shader_supported),
 NULL);
add_function("memoryBarrierImage",
 _memory_barrier("__intrinsic_memory_barrier_image",
-compute_shader),
+compute_shader_supported),
 NULL);
add_function("memoryBarrierShared",
 _memory_barrier("__intrinsic_memory_barrier_shared",
-- 
2.9.3

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

Re: [Mesa-dev] [Mesa-stable] [PATCH v2 4/4] dri/common: clear the loaderPrivate pointer in driDestroyDrawable

[Marek Olšák]

Rb for the series. Posting from phone.

Marek

On Feb 2, 2017 6:20 PM, "Nicolai Hähnle"  wrote:

> From: Nicolai Hähnle 
>
> The GLX specification says about glXDestroyPixmap:
>
> "The storage for the GLX pixmap will be freed when it is not current
>  to any client."
>
> We're not really following this language to the letter: some of the storage
> is freed immediately (in particular, the dri3_drawable, which contains both
> GLXDRIdrawable and loader_dri3_drawable). So we NULL out the pointers to
> that freed storage; the previous patches added the corresponding
> NULL-pointer
> checks.
>
> This fixes memory corruption in piglit
> ./bin/glx-visuals-depth/stencil -pixmap -auto
>
> Cc: 17.0 
> Reviewed-by: Marek Olšák 
> ---
>  src/mesa/drivers/dri/common/dri_util.c | 12 
>  1 file changed, 12 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/common/dri_util.c
> b/src/mesa/drivers/dri/common/dri_util.c
> index f92eee9..d18c458 100644
> --- a/src/mesa/drivers/dri/common/dri_util.c
> +++ b/src/mesa/drivers/dri/common/dri_util.c
> @@ -638,20 +638,22 @@ static void dri_put_drawable(__DRIdrawable *pdp)
>  }
>  }
>
>  static __DRIdrawable *
>  driCreateNewDrawable(__DRIscreen *screen,
>   const __DRIconfig *config,
>   void *data)
>  {
>  __DRIdrawable *pdraw;
>
> +assert(data != NULL);
> +
>  pdraw = malloc(sizeof *pdraw);
>  if (!pdraw)
> return NULL;
>
>  pdraw->loaderPrivate = data;
>
>  pdraw->driScreenPriv = screen;
>  pdraw->driContextPriv = NULL;
>  pdraw->refcount = 0;
>  pdraw->lastStamp = 0;
> @@ -667,20 +669,30 @@ driCreateNewDrawable(__DRIscreen *screen,
>  }
>
>  pdraw->dri2.stamp = pdraw->lastStamp + 1;
>
>  return pdraw;
>  }
>
>  static void
>  driDestroyDrawable(__DRIdrawable *pdp)
>  {
> +/*
> + * The loader's data structures are going away, even if pdp itself
> stays
> + * around for the time being because it is currently bound. This
> happens
> + * when a currently bound GLX pixmap is destroyed.
> + *
> + * Clear out the pointer back into the loader's data structures to
> avoid
> + * accessing an outdated pointer.
> + */
> +pdp->loaderPrivate = NULL;
> +
>  dri_put_drawable(pdp);
>  }
>
>  static __DRIbuffer *
>  dri2AllocateBuffer(__DRIscreen *screen,
>unsigned int attachment, unsigned int format,
>int width, int height)
>  {
>  return screen->driver->AllocateBuffer(screen, attachment, format,
>width, height);
> --
> 2.9.3
>
> ___
> mesa-stable mailing list
> mesa-sta...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-stable
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Freedreno] WebProcess crash on DB410c

[Rob Clark]

Hmm, could be that westeros is doing something wrong that causes the
pbuffer path to be hit.  I'm not entirely sure why pbuffer is not
supported in wayland (other than just that these days there are better
ways to do things than pbuffer), although I thought I remembered
seeing a fallback to surfaceless in webkit..

BR,
-R

On Fri, Feb 3, 2017 at 1:05 AM, Sivasubramanian Patchaiperumal
 wrote:
> One more point is westeros always return null window for offscreen target,
> that why WPE falls back to pbuffer on HiKey and DB410c cases.
>
> On 3 February 2017 at 11:30, Sivasubramanian Patchaiperumal
>  wrote:
>>
>> Thanks Rob for your inputs. Yes, you are looking at the right place. But
>> the HiKey which takes same pbuffer path and it working with Mali is the
>> reference now. I'm trying to write a simple egl app that uses pbuffer to
>> confirm the support with Mesa. Does it sounds correct or you have any
>> suggestions?
>>
>> On 3 February 2017 at 02:06, Rob Clark  wrote:
>>>
>>> btw, where exactly is it crashing?  I grabbed the WebKitForWayland
>>> tree.. if I'm looking at the right thing, the only place where it
>>> should try to create a pbuffer is in
>>> Source/WebCore/platform/graphics/egl/GLContextEGL.cpp and that looks
>>> like it should only be a fallback after createWaylandContext() fails??
>>>
>>> I suspect pbuffer is not the root problem, that looks like a fallback
>>> path that shouldn't be hit..
>>>
>>> BR,
>>> -R
>>>
>>> On Thu, Feb 2, 2017 at 9:55 AM, Rob Clark  wrote:
>>> > hmm, just looking at dri2_wl_display_vtbl:
>>> >
>>> >.create_pbuffer_surface = dri2_fallback_create_pbuffer_surface,
>>> >
>>> > which just returns null.. so I guess pbuffers are not supported under
>>> > wayland.
>>> >
>>> > Bit of google search reveals:
>>> >
>>> >
>>> > https://lists.freedesktop.org/archives/wayland-devel/2012-April/002928.html
>>> >
>>> > so I think the answer is don't use pbuffers.
>>> >
>>> > BR,
>>> > -R
>>> >
>>> > On Thu, Feb 2, 2017 at 9:50 AM, Rob Clark  wrote:
>>> >> hmm, tons of older stuff uses pbuffers w/ x11.. although a quick look
>>> >> at mesa/demos.git and it doesn't look like any of them that build for
>>> >> wayland do.  I don't think pbuffers are used much anymore.  But I
>>> >> would expect there should be some piglit tests which do.
>>> >>
>>> >> (Plus, firefox and chromium have been ported to wayland.. and quite a
>>> >> lot of other sw.  And a lot of us are using wayland on our
>>> >> laptops/desktops these days.)
>>> >>
>>> >> BR,
>>> >> -R
>>> >>
>>> >> On Thu, Feb 2, 2017 at 9:39 AM, Sivasubramanian Patchaiperumal
>>> >>  wrote:
>>> >>> Yes, WebProcess(in WebKit) is crashing on DB410c. Any client that
>>> >>> uses
>>> >>> pbuffer surfaces will crash I suspect. Is there is any simple egl
>>> >>> application that uses pixel buffer to verify and confirm?
>>> >>>
>>> >>> On 2 February 2017 at 19:00, Rob Clark  wrote:
>>> 
>>>  hmm, ok, so it is a *client* process that is crashing?  The wayland
>>>  winsys (used by client processes, as opposed to gbm/drm winsys used
>>>  by
>>>  compositor) does support pbuffers.
>>> 
>>>  BR,
>>>  -R
>>> 
>>>  On Thu, Feb 2, 2017 at 7:43 AM, Sivasubramanian Patchaiperumal
>>>   wrote:
>>>  > Westeros code uses EGL window surface only, but the WPE code (at
>>>  > https://github.com/Metrological/WebKitForWayland/) which uses
>>>  > pbuffer
>>>  > works
>>>  > on HiKey and RPI as mentioned.
>>>  >
>>>  > On 2 February 2017 at 17:38, Rob Clark 
>>>  > wrote:
>>>  >>
>>>  >> On Thu, Feb 2, 2017 at 2:13 AM, Sivasubramanian Patchaiperumal
>>>  >>  wrote:
>>>  >> > Hi,
>>>  >> > I'm trying to port WPE on DB410c with Westeros compositor, but
>>>  >> > the
>>>  >> > webprocess crashes due to null sharingcontext. Webprocess fails
>>>  >> > to
>>>  >> > create gl
>>>  >> > context as eglChooseConfig fails when the surface type
>>>  >> > attribute is
>>>  >> > pbuffer.
>>>  >> > Also, Westeros sample app works fine and the issue is only when
>>>  >> > surface
>>>  >> > type
>>>  >> > attribute is pbuffer. But the same issue is not observed on
>>>  >> > similar
>>>  >> > scenerios, HiKey and RPI with westeros. Is there something to
>>>  >> > do with
>>>  >> > db410c
>>>  >> > for eglChooseConfig failure when surface type is pbuffer?
>>>  >>
>>>  >> Can you point me at the code?  Not 100% sure but possibly gbm/drm
>>>  >> egl
>>>  >> implementation does not support pbuffer surfaces.  I don't see
>>>  >> weston
>>>  >> using pbuffer's, for example.
>>>  >>
>>> 

[Mesa-dev] [PATCH] anv/pipeline: set ThreadDispatchEnable conditionally

[Juan A. Suarez Romero]

Set 3DSTATE_WM/ThreadDispatchEnable bit on/off based on the same
conditions as used in the GL version.

Signed-off-by: Juan A. Suarez Romero 
---
 src/intel/vulkan/genX_pipeline.c | 49 +---
 1 file changed, 26 insertions(+), 23 deletions(-)

diff --git a/src/intel/vulkan/genX_pipeline.c b/src/intel/vulkan/genX_pipeline.c
index e8cbd3c..55d1e55 100644
--- a/src/intel/vulkan/genX_pipeline.c
+++ b/src/intel/vulkan/genX_pipeline.c
@@ -1174,6 +1174,26 @@ emit_3dstate_gs(struct anv_pipeline *pipeline)
}
 }
 
+static inline bool
+has_color_buffer_write_enabled(const struct anv_pipeline *pipeline)
+{
+   const struct anv_shader_bin *shader_bin =
+  pipeline->shaders[MESA_SHADER_FRAGMENT];
+   if (!shader_bin)
+  return false;
+
+   const struct anv_pipeline_bind_map *bind_map = _bin->bind_map;
+   for (int i = 0; i < bind_map->surface_count; i++) {
+  if (bind_map->surface_to_descriptor[i].set !=
+  ANV_DESCRIPTOR_SET_COLOR_ATTACHMENTS)
+ continue;
+  if (bind_map->surface_to_descriptor[i].index != UINT8_MAX)
+ return true;
+   }
+
+   return false;
+}
+
 static void
 emit_3dstate_wm(struct anv_pipeline *pipeline, struct anv_subpass *subpass,
 const VkPipelineMultisampleStateCreateInfo *multisample)
@@ -1202,9 +1222,6 @@ emit_3dstate_wm(struct anv_pipeline *pipeline, struct 
anv_subpass *subpass,
 wm_prog_data->barycentric_interp_modes;
 
 #if GEN_GEN < 8
- /* FIXME: This needs a lot more work, cf gen7 upload_wm_state(). */
- wm.ThreadDispatchEnable  = true;
-
  wm.PixelShaderComputedDepthMode  = wm_prog_data->computed_depth_mode;
  wm.PixelShaderUsesSourceDepth= wm_prog_data->uses_src_depth;
  wm.PixelShaderUsesSourceW= wm_prog_data->uses_src_w;
@@ -1220,6 +1237,12 @@ emit_3dstate_wm(struct anv_pipeline *pipeline, struct 
anv_subpass *subpass,
  wm.PixelShaderKillsPixel = subpass->has_ds_self_dep ||
 wm_prog_data->uses_kill;
 
+ if (wm.PixelShaderComputedDepthMode != PSCDEPTH_OFF ||
+ wm_prog_data->has_side_effects ||
+ wm.PixelShaderKillsPixel ||
+ has_color_buffer_write_enabled(pipeline))
+wm.ThreadDispatchEnable = true;
+
  if (samples > 1) {
 wm.MultisampleRasterizationMode = MSRASTMODE_ON_PATTERN;
 if (wm_prog_data->persample_dispatch) {
@@ -1338,26 +1361,6 @@ emit_3dstate_ps(struct anv_pipeline *pipeline,
}
 }
 
-static inline bool
-has_color_buffer_write_enabled(const struct anv_pipeline *pipeline)
-{
-   const struct anv_shader_bin *shader_bin =
-  pipeline->shaders[MESA_SHADER_FRAGMENT];
-   if (!shader_bin)
-  return false;
-
-   const struct anv_pipeline_bind_map *bind_map = _bin->bind_map;
-   for (int i = 0; i < bind_map->surface_count; i++) {
-  if (bind_map->surface_to_descriptor[i].set !=
-  ANV_DESCRIPTOR_SET_COLOR_ATTACHMENTS)
- continue;
-  if (bind_map->surface_to_descriptor[i].index != UINT8_MAX)
- return true;
-   }
-
-   return false;
-}
-
 #if GEN_GEN >= 8
 static void
 emit_3dstate_ps_extra(struct anv_pipeline *pipeline,
-- 
2.9.3

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

Re: [Mesa-dev] [Mesa-stable] [PATCH] mesa: call DrawBuffer(s) driver hook in update_framebuffer for windows-system FB

[Boyan Ding]

2017-02-02 7:58 GMT+08:00 Brian Paul :
> This makes three places in the code where we call ctx->Driver.DrawBuffers()
> or ctx->Driver.DrawBuffer() like this.  I think some refactoring would be
> good.
>
> Perhaps these calls can go into _mesa_drawbuffers().  I'll try to look into
> that in a few days.
>
> -Brian

Yeah, I've been thinking about the same thing when writing this patch.
There exist some places in which _mesa_drawbuffers() call isn't
followed by ctx->Driver.Drawbuffers() (or DrawBuffer) and that is
wrapped into _mesa_update_draw_buffers(). Maybe we can create a new
wrapper for this, but I'm not sure about the naming.

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

Re: [Mesa-dev] [PATCH 1/2] configure: libdrm is a single package, no split different versions

[Emil Velikov]

On 3 February 2017 at 01:41, Ilia Mirkin  wrote:
> On Wed, Feb 1, 2017 at 9:36 PM, Emil Velikov  wrote:
>> On 2 February 2017 at 02:33, Ilia Mirkin  wrote:
>>> The intent of the libdrm_driver version limits has always been to not
>>> burden the "other" drivers with updating their libdrm unless really
>>> necessary. Unfortunately the configure script erroneously only checked
>>> the driver-specific bit and not the generic bit of libdrm as well. Fix
>>> this.
>>>
>> Haven't checked this explicitly, but I'm leaning that at least one
>> piece is broken.
>> If you are to change this, you must ensure that things build with the
>> numbers provided.
>
> I'm still not 100% sure what you're referring to. On the off chance
> that this change breaks some legitimate situation, we can revert it,
> or fix it up for the situation in question. Note that definition of
> "legitimate" isn't always going to be "it used to work" - sometimes
> things work but aren't worth supporting. (And sometimes they are.)
> Given Chad and Dave's reviews, and I believe some on-irc support for
> this approach, I'm going ahead and pushing this.
>
Above all: thank you Ilia and Dave for keeping up with our chat the other day.

This in combination combined with Dave's patch, would make 2/2 correct
- the order [things got in] is a bit iffy, but meh.

The change of approach here will break [although not so often] the
build for less commonly used/developed drivers.
Namely: as new libdrm API/ABI is used in the core/common parts, the
LIBDRM_REQUIRED bump will fall through the cracks.

Either way, let's cross that bridge if/when that happens.

Ilia, please add a comment above the LIBDRM_.*REQUIRED=2... lines
which describes things up a bit. I'm thinking of the following, but
I'd imagine you can improve on it:.

LIBDRM_REQUIRED is the libdrm version required by common/shared code.
LIBDRM_$HW_REQUIRED indicate is the required libdrm + libdrm_$hw used
for the specific $HW driver(s).

With some/any inline comment the patch is
Reviewed-by: Emil Velikov 

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

Re: [Mesa-dev] [PATCH] configure: Only require libdrm 2.4.75 for intel.

[Emil Velikov]

On 2 February 2017 at 03:22, Dave Airlie  wrote:
> On 2 February 2017 at 13:09, Emil Velikov  wrote:
>> On 2 February 2017 at 02:58, Michel Dänzer  wrote:
>>> On 02/02/17 09:10 AM, Emil Velikov wrote:
 On 1 February 2017 at 23:28, Vinson Lee  wrote:
> Fixes: b8acb6b17981 ("configure: Require libdrm >= 2.4.75")
> Signed-off-by: Vinson Lee 
 Are you sure that's correct ?

 Afaict the follow-up commits make use of updated i915_drm.h which
 should be provided by your distro's libdrm-dev package.
>>>
>>> This seems to be at the heart of the confusion here: Is i915_drm.h part
>>> of libdrm or of libdrm_intel? I'd argue it's the latter, and the fact
>>> that some or even all downstreams ship a single package with all libdrm*
>>> headers is irrelevant. That package also contains all the libdrm_*.pc
>>> files, so Vinson's patch works as intended either way.
>>>
>> Are you saying that there's a single -dev package [libdrm-dev] for
>> everything libdrm* related ?
>> That sounds like a broken distro package... which would explain some
>> of the assumptions/discussions on #dri-devel :-)
>
> That is how all distros ship it.
>
Agreed. Seemingly I'm one of the few (the only) person silly enough
not to follow the broken(?) approach used by distros.
Either way - I'll add locals hacks to be compatible :-)

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

Re: [Mesa-dev] [PATCH] configure.ac: explicitly require libdrm for dri classic drivers.

[Emil Velikov]

On 2 February 2017 at 20:12, Dave Airlie  wrote:

> We need both to be sure.
>
We need this regardless of 1/2. Thanks Dave.
Reviewed-by: Emil Velikov 

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

Re: [Mesa-dev] [Mesa-stable] [PATCH v2 1/4] glx/dri3: handle NULL pointers in loader-to-DRI3 drawable conversion

[Emil Velikov]

On 2 February 2017 at 17:19, Nicolai Hähnle  wrote:
> From: Nicolai Hähnle 
>
> With a subsequent patch, we might see NULL loaderPrivates, e.g. when
> a DRIdrawable is flushed whose corresponding GLXDRIdrawable was destroyed.
> This resulted in a crash, since the loader vs. DRI3 drawable structures
> have a non-zero offset.
>
> Fixes glx-visuals-{depth,stencil} -pixmap
>
Thanks for the extra fixes and reorder Nicolai.

For the series:
Reviewed-by: Emil Velikov 

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

Re: [Mesa-dev] Question about handling RGBA/BGRA in etnaviv driver

[Christian Gmeiner]

Hi Wladimir,

2017-02-03 11:06 GMT+01:00 Wladimir :
> Yes, but it seems suboptimal, incurring overhead on every rendered pixel.
>
> Another way that I just realized would be to convert a texture to BGRA the
> first time it's rendered to.
>
> In contrast to the shader solution that has only a one-time overhead. Is
> this a stupid idea for any reason?
>

We are doing something similar to convert sampled textures to the
correct tiling format
for the multi-pipe GPUs. (sampler can read only from tiled formats but
the multi-pipe GPU
can only render to multi-tiled or super-tiled resources). Have a look where
etna_copy_resource(..) gets used.

So this idea sound even better to me.

> Wladimir
>
> On Feb 3, 2017 11:00, "Christian Gmeiner" 
> wrote:
>>
>> Hi,
>>
>> 2017-02-03 10:56 GMT+01:00 Wladimir J. van der Laan :
>> > Hello,
>> >
>> > With the Etnaviv driver we're running into an issue: The GPU can only
>> > render *to*
>> > BGRA formats. It can however render *from* BGRA as well as RGBA
>> > textures.
>> >
>> > I know that the OpenGL ES standard allows drivers to choose what order
>> > is most
>> > appropriate when being asked for "GL_RGBA" textures. So back when
>> > etnaviv supported
>> > only BGRA, Mesa automatically picked that and everything was okay.
>> >
>> > However a recent patch added support for RGBA formats in
>> > etnaviv_format.c.
>> >
>> > Now, Mesa creates a real GL_RGBA texture when this is requested. This is
>> > all
>> > and well for rendering, however for anything using FBO to render to
>> > textures
>> > this is a problem.
>> >
>> > Qt, for example, is assuming it can attach the GL_RGBA texture to a FBO.
>> > This
>> > fails now that GL_RGBA textures are really GL_RGBA, and it doesn't
>> > handle that
>> > error to fall back to something else so rendering issues ensue.
>> >
>> > I'm not sure how to handle this:
>> >
>> > - The quick fix would be to revert the RGBA formats patch, but the
>> > hardware
>> >   supports rendering *from* RGBA textures fine so this would be throwing
>> > away a
>> >   feature.
>> >
>> > - Another way would be to try to fix Qt to cope with this, and try e.g.
>> > GL_BGRA_EXT
>> >   when it wants to render to a texture. Burdening the client code with
>> > this seems
>> >   unintuitive to me.
>> >
>> > - Another hack would be to implement shader variants, and swap R/B in
>> > the pixel
>> >   shader to emulate rendering to RGBA.
>> >
>>
>> In my opinion shader variants are the way to go - almost every driver
>> make use of them to
>> 'fix' such issues.
>>


greets
--
Christian Gmeiner, MSc

https://www.youtube.com/user/AloryOFFICIAL
https://soundcloud.com/christian-gmeiner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Question about handling RGBA/BGRA in etnaviv driver

[Lucas Stach]

Hi Wladimir,

this is about the userspace component of the driver, so dri-devel isn't
the correct list for this question, you should instead CC the MESA dev
list, even if mostly the same people hang out on those lists.

Done that for you now. 

Regards,
Lucas 

Am Freitag, den 03.02.2017, 10:56 +0100 schrieb Wladimir J. van der
Laan:
> Hello,
> 
> With the Etnaviv driver we're running into an issue: The GPU can only render 
> *to*
> BGRA formats. It can however render *from* BGRA as well as RGBA textures.
> 
> I know that the OpenGL ES standard allows drivers to choose what order is most
> appropriate when being asked for "GL_RGBA" textures. So back when etnaviv 
> supported
> only BGRA, Mesa automatically picked that and everything was okay.
> 
> However a recent patch added support for RGBA formats in etnaviv_format.c.
> 
> Now, Mesa creates a real GL_RGBA texture when this is requested. This is all
> and well for rendering, however for anything using FBO to render to textures
> this is a problem.
> 
> Qt, for example, is assuming it can attach the GL_RGBA texture to a FBO. This
> fails now that GL_RGBA textures are really GL_RGBA, and it doesn't handle that
> error to fall back to something else so rendering issues ensue.
> 
> I'm not sure how to handle this:
> 
> - The quick fix would be to revert the RGBA formats patch, but the hardware
>   supports rendering *from* RGBA textures fine so this would be throwing away 
> a
>   feature.
> 
> - Another way would be to try to fix Qt to cope with this, and try e.g. 
> GL_BGRA_EXT
>   when it wants to render to a texture. Burdening the client code with this 
> seems
>   unintuitive to me.
> 
> - Another hack would be to implement shader variants, and swap R/B in the 
> pixel
>   shader to emulate rendering to RGBA.
> 
> Neither seems great. Does anyone have suggestions, do any of the other
> (gallium) drivers have this problem?
> 
> Regards,
> Wladimir
> ___
> etnaviv mailing list
> etna...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/etnaviv


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

[Mesa-dev] Fwd: Question about handling RGBA/BGRA in etnaviv driver

[Wladimir]

Sorry for getting the list wrong again. Please reply to mesa-dev not
dri-dev .

-- Forwarded message --
From: "Wladimir J. van der Laan" 
Date: Feb 3, 2017 10:56
Subject: Question about handling RGBA/BGRA in etnaviv driver
To: , 
Cc: "Chris Healy" 

Hello,

With the Etnaviv driver we're running into an issue: The GPU can only
render *to*
BGRA formats. It can however render *from* BGRA as well as RGBA textures.

I know that the OpenGL ES standard allows drivers to choose what order is
most
appropriate when being asked for "GL_RGBA" textures. So back when etnaviv
supported
only BGRA, Mesa automatically picked that and everything was okay.

However a recent patch added support for RGBA formats in etnaviv_format.c.

Now, Mesa creates a real GL_RGBA texture when this is requested. This is all
and well for rendering, however for anything using FBO to render to textures
this is a problem.

Qt, for example, is assuming it can attach the GL_RGBA texture to a FBO.
This
fails now that GL_RGBA textures are really GL_RGBA, and it doesn't handle
that
error to fall back to something else so rendering issues ensue.

I'm not sure how to handle this:

- The quick fix would be to revert the RGBA formats patch, but the hardware
  supports rendering *from* RGBA textures fine so this would be throwing
away a
  feature.

- Another way would be to try to fix Qt to cope with this, and try e.g.
GL_BGRA_EXT
  when it wants to render to a texture. Burdening the client code with this
seems
  unintuitive to me.

- Another hack would be to implement shader variants, and swap R/B in the
pixel
  shader to emulate rendering to RGBA.

Neither seems great. Does anyone have suggestions, do any of the other
(gallium) drivers have this problem?

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

Re: [Mesa-dev] Question about handling RGBA/BGRA in etnaviv driver

[Wladimir]

Yes, but it seems suboptimal, incurring overhead on every rendered pixel.

Another way that I just realized would be to convert a texture to BGRA the
first time it's rendered to.

In contrast to the shader solution that has only a one-time overhead. Is
this a stupid idea for any reason?

Wladimir

On Feb 3, 2017 11:00, "Christian Gmeiner" 
wrote:

> Hi,
>
> 2017-02-03 10:56 GMT+01:00 Wladimir J. van der Laan :
> > Hello,
> >
> > With the Etnaviv driver we're running into an issue: The GPU can only
> render *to*
> > BGRA formats. It can however render *from* BGRA as well as RGBA textures.
> >
> > I know that the OpenGL ES standard allows drivers to choose what order
> is most
> > appropriate when being asked for "GL_RGBA" textures. So back when
> etnaviv supported
> > only BGRA, Mesa automatically picked that and everything was okay.
> >
> > However a recent patch added support for RGBA formats in
> etnaviv_format.c.
> >
> > Now, Mesa creates a real GL_RGBA texture when this is requested. This is
> all
> > and well for rendering, however for anything using FBO to render to
> textures
> > this is a problem.
> >
> > Qt, for example, is assuming it can attach the GL_RGBA texture to a FBO.
> This
> > fails now that GL_RGBA textures are really GL_RGBA, and it doesn't
> handle that
> > error to fall back to something else so rendering issues ensue.
> >
> > I'm not sure how to handle this:
> >
> > - The quick fix would be to revert the RGBA formats patch, but the
> hardware
> >   supports rendering *from* RGBA textures fine so this would be throwing
> away a
> >   feature.
> >
> > - Another way would be to try to fix Qt to cope with this, and try e.g.
> GL_BGRA_EXT
> >   when it wants to render to a texture. Burdening the client code with
> this seems
> >   unintuitive to me.
> >
> > - Another hack would be to implement shader variants, and swap R/B in
> the pixel
> >   shader to emulate rendering to RGBA.
> >
>
> In my opinion shader variants are the way to go - almost every driver
> make use of them to
> 'fix' such issues.
>
> greets
> --
> Christian Gmeiner, MSc
>
> https://www.youtube.com/user/AloryOFFICIAL
> https://soundcloud.com/christian-gmeiner
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radv/ac: correctly size shared memory usage.

[Bas Nieuwenhuizen]

Reviewed-by: Bas Nieuwenhuizen 

On Fri, Feb 3, 2017, at 04:30, Dave Airlie wrote:
> From: Dave Airlie 
> 
> We count the number of slots used, but slots are vec4 sized,
> so we have to scale by 16 not 4.
> 
> Signed-off-by: Dave Airlie 
> ---
>  src/amd/common/ac_nir_to_llvm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/amd/common/ac_nir_to_llvm.c
> b/src/amd/common/ac_nir_to_llvm.c
> index ddec74f..9be6e77 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -4812,7 +4812,7 @@ LLVMModuleRef
> ac_translate_nir_to_llvm(LLVMTargetMachineRef tm,
>   idx++;
>   }
>  
> -   shared_size *= 4;
> +   shared_size *= 16;
>   var = LLVMAddGlobalInAddressSpace(ctx.module,
> LLVMArrayType(ctx.i8, 
> shared_size),
> "compute_lds",
> -- 
> 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] radv: fix shared memory load/stores.

[Bas Nieuwenhuizen]

On Fri, Feb 3, 2017, at 06:33, Dave Airlie wrote:
> On 3 February 2017 at 13:35, Dave Airlie  wrote:
> > From: Dave Airlie 
> >
> > If we have an indirect index here we need to scale it by attribute slots
> > e.g. is this is vec2[256] then we get an indir_index in the 0.255 range
> > but the vec2 are aligned inside vec4 slots. So scale the indir index,
> > then extract the channels.
> >
> > This appears to fix DOOM for me.
> 
> Looks like appearances were deceiving, doom isn't fully fixed by this.
> 

You are not the only one that has been down that rabbit hole :(

Reviewed-by: Bas Nieuwenhuizen 
> Dave.
> 
> >
> > Signed-off-by: Dave Airlie 
> > ---
> >  src/amd/common/ac_nir_to_llvm.c | 7 +++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/src/amd/common/ac_nir_to_llvm.c 
> > b/src/amd/common/ac_nir_to_llvm.c
> > index 9be6e77..566516f 100644
> > --- a/src/amd/common/ac_nir_to_llvm.c
> > +++ b/src/amd/common/ac_nir_to_llvm.c
> > @@ -2237,6 +2237,9 @@ static LLVMValueRef visit_load_var(struct 
> > nir_to_llvm_context *ctx,
> > LLVMValueRef ptr = get_shared_memory_ptr(ctx, idx, 
> > ctx->i32);
> > LLVMValueRef derived_ptr;
> >
> > +   if (indir_index)
> > +   indir_index = LLVMBuildMul(ctx->builder, 
> > indir_index, LLVMConstInt(ctx->i32, 4, false), "");
> > +
> > for (unsigned chan = 0; chan < ve; chan++) {
> > LLVMValueRef index = LLVMConstInt(ctx->i32, chan, 
> > false);
> > if (indir_index)
> > @@ -2343,6 +2346,10 @@ visit_store_var(struct nir_to_llvm_context *ctx,
> > break;
> > case nir_var_shared: {
> > LLVMValueRef ptr = get_shared_memory_ptr(ctx, idx, 
> > ctx->i32);
> > +
> > +   if (indir_index)
> > +   indir_index = LLVMBuildMul(ctx->builder, 
> > indir_index, LLVMConstInt(ctx->i32, 4, false), "");
> > +
> > for (unsigned chan = 0; chan < 8; chan++) {
> > if (!(writemask & (1 << chan)))
> > continue;
> > --
> > 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 mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radv: fix compute shared memory stores since 64-bit.

[Bas Nieuwenhuizen]

Reviewed-by: Bas Nieuwenhuizen 

On Fri, Feb 3, 2017, at 02:04, Dave Airlie wrote:
> From: Dave Airlie 
> 
> These regressed and caused doom to stop loading.
> 
> Fixes:
> 03724af26 radv/ac: Implement Float64 load/store var.
> 
> Signed-off-by: Dave Airlie 
> ---
>  src/amd/common/ac_nir_to_llvm.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/src/amd/common/ac_nir_to_llvm.c
> b/src/amd/common/ac_nir_to_llvm.c
> index 728294c..ddec74f 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -2351,9 +2351,11 @@ visit_store_var(struct nir_to_llvm_context *ctx,
>  
>   if (indir_index)
>   index = LLVMBuildAdd(ctx->builder, index, 
> indir_index, "");
> +
> +   value = llvm_extract_elem(ctx, src, chan);
>   derived_ptr = LLVMBuildGEP(ctx->builder, ptr, , 
> 1, "");
>   LLVMBuildStore(ctx->builder,
> -  to_integer(ctx, src),
> derived_ptr);
> +  to_integer(ctx, value),
> derived_ptr);
>   }
>   break;
>   }
> -- 
> 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