Re: [Mesa-dev] [PATCH 13/25] compiler: make uses_sample_qualifier a bitfield and add uses_centroid_qualifier

[Kenneth Graunke]

On Tuesday, October 18, 2016 5:12:16 PM PDT Timothy Arceri wrote:
> These need to be bitfields for use with gallium.
> ---
>  src/compiler/glsl/glsl_to_nir.cpp |  2 +-
>  src/compiler/shader_info.h| 12 +---
>  2 files changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/src/compiler/glsl/glsl_to_nir.cpp 
> b/src/compiler/glsl/glsl_to_nir.cpp
> index de76651..a2284e2 100644
> --- a/src/compiler/glsl/glsl_to_nir.cpp
> +++ b/src/compiler/glsl/glsl_to_nir.cpp
> @@ -185,7 +185,7 @@ glsl_to_nir(const struct gl_shader_program *shader_prog,
>   (struct gl_fragment_program *)sh->Program;
>  
>shader->info->fs.uses_discard = fp->UsesKill;
> -  shader->info->fs.uses_sample_qualifier = fp->IsSample != 0;
> +  shader->info->fs.uses_sample_qualifier = fp->IsSample;
>shader->info->fs.early_fragment_tests = sh->info.EarlyFragmentTests;
>shader->info->fs.depth_layout = fp->FragDepthLayout;
>break;
> diff --git a/src/compiler/shader_info.h b/src/compiler/shader_info.h
> index 66e06ad..dde36f5 100644
> --- a/src/compiler/shader_info.h
> +++ b/src/compiler/shader_info.h
> @@ -95,12 +95,18 @@ typedef struct shader_info {
>} gs;
>  
>struct {
> - bool uses_discard;
> + /**
> +  * A bitfield of input locations declared with the "sample" 
> qualifier
> +  */
> + uint64_t uses_sample_qualifier;

I would expect to see the initialization/usage of this updated to be a
proper bitfield rather than a boolean.  It looks like even by the end
of the series there's still a bit of boolean going on here.

>  
>   /**
> -  * Whether any inputs are declared with the "sample" qualifier.
> +  * A bitfield of input locations declared with the "centroid"
> +  * qualifier.
>*/
> - bool uses_sample_qualifier;
> + uint64_t uses_centroid_qualifier;

uses_centroid_qualifier doesn't appear to be used anywhere in the whole
series?

> +
> + bool uses_discard;
>  
>   /**
>* Whether early fragment tests are enabled as defined by
> 



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] [PATCH] configure.ac: don't require DRM and GBM for surfaceless egl platform

[Michel Dänzer]

On 18/10/16 01:47 AM, Marek Olšák wrote:

From: Deepak Sharma 

This allows building radeonsi driver for surfaceless platform.

Signed-off-by: Deepak Sharma 
Signed-off-by: Marek Olšák 
---
 configure.ac | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index b414edd..05e4bdc 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2345,27 +2345,30 @@ gallium_require_llvm() {
 esac
 fi
 }

 gallium_require_drm_loader() {
 if test "x$need_pci_id$have_pci_id" = xyesno; then
 AC_MSG_ERROR([Gallium drm loader requires libudev >= $LIBUDEV_REQUIRED 
or sysfs])
 fi
 }

-dnl This is for Glamor. Skip this if OpenGL is disabled.
+dnl This is for Glamor. Skip this if OpenGL is disabled or surfaceless EGL 
platform is enabled.
 require_egl_drm() {


The function name should be updated to reflect what it does now.


--
Earthling Michel Dänzer|  http://www.amd.com
Libre software enthusiast  |Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] drivers/meta: Accept GL_TEXTURE_3D as target for tex image decompression

[Eduardo Lima Mitev]

An assert is currently raised, preventing decompression of a texture image into
a GL_TEXTURE_3D target. I have not found any spec wording that would explain
this, or implementation detail that would prevent it. And in any case, the
driver should not cause a crash upon user input arguments.

Fixes most failing subcases in CTS tests:
* GL44-CTS.gtf32.GL3Tests.packed_pixels.packed_pixels_pixelstore
* GL45-CTS.gtf32.GL3Tests.packed_pixels.packed_pixels_pixelstore

These tests were crashing the driver before. Now they just fail, but due
to an unrelated issue affecting 2 out of the 45 test subcases.

No regressions observed against piglit or CTS-GL.
---
 src/mesa/drivers/common/meta.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index 890e98a..0d8c667 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -3026,10 +3026,6 @@ decompress_texture_image(struct gl_context *ctx,
   assert(!"No compressed 1D textures.");
   return false;
 
-   case GL_TEXTURE_3D:
-  assert(!"No compressed 3D textures.");
-  return false;
-
case GL_TEXTURE_CUBE_MAP_ARRAY:
   faceTarget = GL_TEXTURE_CUBE_MAP_POSITIVE_X + (slice % 6);
   break;
-- 
2.8.1

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

Re: [Mesa-dev] [PATCH 02/16] loader: slim down loader_get_pci_id_for_fd implementation(s)

[Nicolai Hähnle]

On 11.10.2016 20:31, Emil Velikov wrote:

From: Emil Velikov 

Currently mesa has three code paths in the loader - libudev, manual
sysfs and drm ioctl one.

Considering the issues we had with libudev - strip those down in favour
of the libdrm drm device API. The latter can be implemented in any way
depending on the platform and can be reused by others.

Cc: Jonathan Gray 
Cc: Jean-Sébastien Pédron 
Signed-off-by: Emil Velikov 
---
Jonathan, Jean-Sébastien I believe I've prodded you guys for a *BSD
implementation of the drm*Device API a while back. With this commit
you'll be 'forced' to prep some ;-)

About the implementation itself feel free to use libudev/equivalent (we
cannot do so on Linux, since due to fun interactions with Steam's one)
or any other means available on your platform. Fwiw I would strongly
suggest _against_ adding DRM specific ioctls just for this purpose but
at the end of the day it's your code/userbase.

On the FreeBSD/DragonFly side this means that you no londer require a
handful of patches for mesa, which is always a plus.
---
 src/loader/loader.c | 172 +---
 1 file changed, 16 insertions(+), 156 deletions(-)

diff --git a/src/loader/loader.c b/src/loader/loader.c
index 3e60e4c..41ea016 100644
--- a/src/loader/loader.c
+++ b/src/loader/loader.c

[snip]

 static int
 drm_get_pci_id_for_fd(int fd, int *vendor_id, int *chip_id)
 {
-   drmVersionPtr version;
-
-   *chip_id = -1;
-
-   version = drmGetVersion(fd);
-   if (!version) {
-  log_(_LOADER_WARNING, "MESA-LOADER: invalid drm fd\n");
-  return 0;
-   }
-   if (!version->name) {
-  log_(_LOADER_WARNING, "MESA-LOADER: unable to determine the driver 
name\n");
-  drmFreeVersion(version);
-  return 0;
-   }
-
-   if (strcmp(version->name, "i915") == 0) {
-  struct drm_i915_getparam gp;
-  int ret;
-
-  *vendor_id = 0x8086;
-
-  memset(&gp, 0, sizeof(gp));
-  gp.param = I915_PARAM_CHIPSET_ID;
-  gp.value = chip_id;
-  ret = drmCommandWriteRead(fd, DRM_I915_GETPARAM, &gp, sizeof(gp));
-  if (ret) {
- log_(_LOADER_WARNING, "MESA-LOADER: failed to get param for i915\n");
-*chip_id = -1;
+   drmDevicePtr device;
+   int ret;
+
+   if (drmGetDevice(fd, &device) == 0) {
+  if (device->bustype == DRM_BUS_PCI) {
+ *vendor_id = device->deviceinfo.pci->vendor_id;
+ *chip_id = device->deviceinfo.pci->device_id;
+ ret = 1;
   }
-   }
-   else if (strcmp(version->name, "radeon") == 0) {
-  struct drm_radeon_info info;
-  int ret;
-
-  *vendor_id = 0x1002;
-
-  memset(&info, 0, sizeof(info));
-  info.request = RADEON_INFO_DEVICE_ID;
-  info.value = (unsigned long) chip_id;
-  ret = drmCommandWriteRead(fd, DRM_RADEON_INFO, &info, sizeof(info));
-  if (ret) {
- log_(_LOADER_WARNING, "MESA-LOADER: failed to get info for radeon\n");
-*chip_id = -1;
+  else {
+ log_(_LOADER_WARNING, "MESA-LOADER: device is not located on the PCI 
bus\n");
+ ret = 0;
   }
+  drmFreeDevice(&device);
}
-   else if (strcmp(version->name, "nouveau") == 0) {
-  *vendor_id = 0x10de;
-  /* not used */
-  *chip_id = 0;
-   }
-   else if (strcmp(version->name, "vmwgfx") == 0) {
-  *vendor_id = 0x15ad;
-  /* assume SVGA II */
-  *chip_id = 0x0405;
+   else {
+  log_(_LOADER_WARNING, "MESA-LOADER: device is not located on the PCI 
bus\n");
+  ret = 0;
}


This should probably be a different error/warning message.

Nicolai



-   drmFreeVersion(version);
-
-   return (*chip_id >= 0);
+   return ret;
 }
 #endif

@@ -585,14 +453,6 @@ drm_get_pci_id_for_fd(int fd, int *vendor_id, int *chip_id)
 int
 loader_get_pci_id_for_fd(int fd, int *vendor_id, int *chip_id)
 {
-#if HAVE_LIBUDEV
-   if (libudev_get_pci_id_for_fd(fd, vendor_id, chip_id))
-  return 1;
-#endif
-#if HAVE_SYSFS
-   if (sysfs_get_pci_id_for_fd(fd, vendor_id, chip_id))
-  return 1;
-#endif
 #if HAVE_LIBDRM
if (drm_get_pci_id_for_fd(fd, vendor_id, chip_id))
   return 1;


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

Re: [Mesa-dev] [PATCH v2 05/16] loader: reimplement loader_get_user_preferred_fd via libdrm

[Nicolai Hähnle]

On 14.10.2016 20:21, Emil Velikov wrote:

From: Emil Velikov 

Currently not everyone has libudev and with follow-up patches we'll
completely remove the divergent codepaths.

Use the libdrm drm device API to construct the required ID_PATH_TAG-like
string, to preserve the current functionality for libudev users and
allow others to benefit from it as well.

v2: Drop ranty comments, pick the correct device

Cc: Axel Davy 
Signed-off-by: Emil Velikov 
---
 src/loader/loader.c | 247 ++--
 1 file changed, 106 insertions(+), 141 deletions(-)

diff --git a/src/loader/loader.c b/src/loader/loader.c
index ad4f946..06df05b 100644
--- a/src/loader/loader.c
+++ b/src/loader/loader.c

[snip]

@@ -321,17 +232,60 @@ static char *loader_get_dri_config_device_id(void)
 }
 #endif

+static char *drm_construct_id_path_tag(drmDevicePtr device)
+{
+/* Length of "pci-_xx_xx_x\n" */
+#define PCI_ID_PATH_TAG_LENGTH 17
+   char *tag = NULL;
+
+   if (device->bustype == DRM_BUS_PCI) {
+tag = calloc(PCI_ID_PATH_TAG_LENGTH, sizeof(char));
+if (tag == NULL)
+return NULL;
+
+sprintf(tag, "pci-%04x_%02x_%02x_%1u", device->businfo.pci->domain,
+device->businfo.pci->bus, device->businfo.pci->dev,
+device->businfo.pci->func);


Defensive programming would suggest to use snprintf.

[snip]

@@ -345,55 +299,66 @@ int loader_get_user_preferred_fd(int default_fd, int 
*different_device)
   return default_fd;
}

-   udev = udev_new();
-   if (!udev)
-  goto prime_clean;
+   default_tag = drm_get_id_path_tag_for_fd(default_fd);
+   if (default_tag == NULL)
+  goto err;

-   default_device_id_path_tag = get_id_path_tag_from_fd(udev, default_fd);
-   if (!default_device_id_path_tag)
-  goto udev_clean;
+   num_devices = drmGetDevices(devices, MAX_DRM_DEVICES);
+   if (num_devices < 0)
+  goto err;

-   is_different_device = 1;
/* two format are supported:
 * "1": choose any other card than the card used by default.
 * id_path_tag: (for example "pci-_02_00_0") choose the card
 * with this id_path_tag.
 */
if (!strcmp(prime,"1")) {
-  free(prime);
-  prime = strdup(default_device_id_path_tag);
-  /* request a card with a different card than the default card */
-  another_tag = 1;
-   } else if (!strcmp(default_device_id_path_tag, prime))
-  /* we are to get a new fd (render-node) of the same device */
-  is_different_device = 0;
-
-   device_name = get_render_node_from_id_path_tag(udev,
-  prime,
-  another_tag);
-   if (device_name == NULL) {
-  is_different_device = 0;
-  goto default_device_clean;
+  /* Hmm... detection for 2-7 seems to be broken. Oh well ...
+   * Pick the first render device that is not our own.
+   */
+  for (i = 0; i < num_devices; i++) {
+ if (devices[i]->available_nodes & 1 << DRM_NODE_RENDER &&
+ !drm_device_matches_tag(devices[i], default_tag)) {
+
+found = true;
+break;
+ }
+  }
+   } else {
+  for (i = 0; i < num_devices; i++) {
+ if (devices[i]->available_nodes & 1 << DRM_NODE_RENDER &&
+drm_device_matches_tag(devices[i], prime)) {
+
+found = true;
+break;
+ }
+  }


I feel like it would be helpful to have a warning here if the device was 
not found. This could avoid some confusion when people inevitably typo 
their prime setting.


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

Re: [Mesa-dev] [PATCH] st/va: force to flush the last p frame in idr period

[Christian König]

Am 17.10.2016 um 22:31 schrieb Alex Deucher:

On Mon, Oct 17, 2016 at 4:16 PM,   wrote:

From: Boyuan Zhang 

During dual instance encoding submission, if the second encode task and first
encode task have no reference dependency, e.g. p following with idr-frame,
there is a chance the second task will use for its reconstructed picture
buffer the same buffer used by first task for its reference/reconstructed
picture. In this case, buffer corruption may occur depending on encoding
speed. Fix is to force flush these two tasks separately to avoid race condition

Please reference the bug when this is committed.
https://bugs.freedesktop.org/show_bug.cgi?id=98005


Yeah, add a line like "Fixes: 
https://bugs.freedesktop.org/show_bug.cgi?id=98005";.


With that done the patch is Reviewed-by: Christian König 
.


Regards,
Christian.


Alex


Signed-off-by: Boyuan Zhang 
---
  src/gallium/state_trackers/va/picture.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/src/gallium/state_trackers/va/picture.c 
b/src/gallium/state_trackers/va/picture.c
index 7f3d96d..eae5dc4 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -578,6 +578,9 @@ vlVaEndPicture(VADriverContextP ctx, VAContextID context_id)
 }

 context->decoder->end_frame(context->decoder, context->target, 
&context->desc.base);
+   if (context->decoder->entrypoint == PIPE_VIDEO_ENTRYPOINT_ENCODE &&
+   context->desc.h264enc.p_remain == 1)
+  context->decoder->flush(context->decoder);
 pipe_mutex_unlock(drv->mutex);
 return VA_STATUS_SUCCESS;
  }
--
2.7.4

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

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



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

Re: [Mesa-dev] [PATCH] gm107/ir: fix texturing with indirect samplers

[Samuel Pitoiset]

On 10/18/2016 05:53 AM, Ilia Mirkin wrote:

The indirect handle has to come right after the coordinates, so if there
was a sample/bias/depth compare/offset, everything would end up being
shifted by one argument position.

Signed-off-by: Ilia Mirkin 
Cc: mesa-sta...@lists.freedesktop.org
---
 src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
index dab3e2d..83154c1 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
@@ -751,6 +751,16 @@ NVC0LoweringPass::handleTEX(TexInstruction *i)
  i->tex.rIndirectSrc = 0;
  i->tex.sIndirectSrc = -1;
   }
+  // Move the indirect reference to right after the coords
+  else if (i->tex.rIndirectSrc >= 0 && chipset >= NVISA_GM107_CHIPSET) {
+ Value *hnd = i->getIndirectR();
+
+ i->setIndirectR(NULL);
+ i->moveSources(arg, 1);
+ i->setSrc(arg, hnd);
+ i->tex.rIndirectSrc = 0;
+ i->tex.sIndirectSrc = -1;
+  }


This looks (a bit) redundant with the loop above, but texture arguments 
are insane, so... :)


I'm going to run piglit.


} else
// (nvc0) generate and move the tsc/tic/array source to the front
if (i->tex.target.isArray() || i->tex.rIndirectSrc >= 0 || i->tex.sIndirectSrc 
>= 0) {



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

Re: [Mesa-dev] [PATCH 13/25] compiler: make uses_sample_qualifier a bitfield and add uses_centroid_qualifier

[Timothy Arceri]

On Tue, 2016-10-18 at 00:08 -0700, Kenneth Graunke wrote:
> On Tuesday, October 18, 2016 5:12:16 PM PDT Timothy Arceri wrote:
> > 
> > These need to be bitfields for use with gallium.
> > ---
> >  src/compiler/glsl/glsl_to_nir.cpp |  2 +-
> >  src/compiler/shader_info.h| 12 +---
> >  2 files changed, 10 insertions(+), 4 deletions(-)
> > 
> > diff --git a/src/compiler/glsl/glsl_to_nir.cpp
> > b/src/compiler/glsl/glsl_to_nir.cpp
> > index de76651..a2284e2 100644
> > --- a/src/compiler/glsl/glsl_to_nir.cpp
> > +++ b/src/compiler/glsl/glsl_to_nir.cpp
> > @@ -185,7 +185,7 @@ glsl_to_nir(const struct gl_shader_program
> > *shader_prog,
> >   (struct gl_fragment_program *)sh->Program;
> >  
> >    shader->info->fs.uses_discard = fp->UsesKill;
> > -  shader->info->fs.uses_sample_qualifier = fp->IsSample != 0;
> > +  shader->info->fs.uses_sample_qualifier = fp->IsSample;
> >    shader->info->fs.early_fragment_tests = sh-
> > >info.EarlyFragmentTests;
> >    shader->info->fs.depth_layout = fp->FragDepthLayout;
> >    break;
> > diff --git a/src/compiler/shader_info.h
> > b/src/compiler/shader_info.h
> > index 66e06ad..dde36f5 100644
> > --- a/src/compiler/shader_info.h
> > +++ b/src/compiler/shader_info.h
> > @@ -95,12 +95,18 @@ typedef struct shader_info {
> >    } gs;
> >  
> >    struct {
> > - bool uses_discard;
> > + /**
> > +  * A bitfield of input locations declared with the
> > "sample" qualifier
> > +  */
> > + uint64_t uses_sample_qualifier;
> 
> I would expect to see the initialization/usage of this updated to be
> a
> proper bitfield rather than a boolean.  It looks like even by the end
> of the series there's still a bit of boolean going on here.

Yeah sorry I meant to drop this patch. I worked out that I could get
rid of the bitfields, see patch 18.

> 
> > 
> >  
> >   /**
> > -  * Whether any inputs are declared with the "sample"
> > qualifier.
> > +  * A bitfield of input locations declared with the
> > "centroid"
> > +  * qualifier.
> >    */
> > - bool uses_sample_qualifier;
> > + uint64_t uses_centroid_qualifier;
> 
> uses_centroid_qualifier doesn't appear to be used anywhere in the
> whole
> series?
> 
> > 
> > +
> > + bool uses_discard;
> >  
> >   /**
> >    * Whether early fragment tests are enabled as defined by
> > 
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 00/16] loader: unify loader codepaths

[Nicolai Hähnle]

On 11.10.2016 20:31, Emil Velikov wrote:

Hi all,

I've been 'threatening' to do this for a while, so here it is:

Remove the three separate code paths that we have in the loader giving
is a since cleanup and consistent/predictable runtime behaviour across
the board. Not to mention some 100 lines removed from configure.ac and
an extra ~400 lines removed throughout the tree.


Hooray for code removal :)

I sent some simple comments on patches 2 & 5. Apart from that, while I'm 
not super familiar with this code it does all look reasonable to me, so 
for the series:


Reviewed-by: Nicolai Hähnle 


What this series does:
 - Changes/unifies how we retrieve the vendor/device pci id.
Namely:
 Removes the ioctl, libudev and sysfs codepaths in favour of using the
libdrm drm*Device API effectively adding "PRIME support" for non-libudev
users ;-) We also get one configure toggle less in the process.

What it does _not_ do:
 - Any changes on the mapping process between the fd/device id and the
device/driver name.
Namely:
 Stuff such as hwdb, platform devices and respective mapping between the
lot is _not_ touched/covered.

I've been touch using it, on an off for about a week, but any extra
testing, review and input is appreciated.

Emil

Emil Velikov (16):
  configure.ac: mark libdrm as have_pci_id provider
  loader: slim down loader_get_pci_id_for_fd implementation(s)
  loader: separate USE_DRICONF code into separate function
  loader: annotate __driConfigOptionsLoader as static
  loader: reimplement loader_get_user_preferred_fd via libdrm
  loader: remove libudev_get_device_name_for_fd and related code
  automake: remove all the libudev references
  gbm: remove superfluous/incorrect udev comment
  scons: loader: use libdrm when available
  scons: remove all libudev references
  travis: remove no longer needed liudev-dev dependency
  loader: remove final sysfs codepath in loader_get_device_name_for_fd()
  loader: remove loader_get_driver_for_fd() driver_type
  loader: cleanup copyright section
  configure.ac: remove no longer needed *_pci_id logic
  configure.ac: use a single require_libdrm helper

 .travis.yml|   1 -
 configure.ac   | 112 +---
 scons/gallium.py   |   1 -
 src/egl/drivers/dri2/platform_android.c|   2 +-
 src/egl/drivers/dri2/platform_surfaceless.c|   2 +-
 src/egl/drivers/dri2/platform_wayland.c|   2 +-
 src/egl/drivers/dri2/platform_x11.c|   2 +-
 src/egl/drivers/dri2/platform_x11_dri3.c   |   2 +-
 .../auxiliary/pipe-loader/pipe_loader_drm.c|   2 +-
 src/gbm/backends/dri/gbm_dri.c |   2 +-
 src/gbm/main/gbm.c |   1 -
 src/glx/dri2_glx.c |   2 +-
 src/glx/dri3_glx.c |   2 +-
 src/loader/Makefile.am |   3 +-
 src/loader/SConscript  |   6 +-
 src/loader/loader.c| 622 -
 src/loader/loader.h|   5 +-
 src/loader/pci_id_driver_map.h |  23 +-
 18 files changed, 150 insertions(+), 642 deletions(-)


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

[Mesa-dev] [Bug 98271] [radeonsi]Playing videos with vdpau or vaapi hardware acceleration crashes my pc

[bugzilla-daemon]

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

--- Comment #13 from Christian König  ---
John, please double check that you are actually correctly installing VDPAU.

E.g. add something like "while(1);" into the VDPAU driver create function or
something like this. vdp_imp_device_create_x11() would be a good place for
that.

That it's a kernel issue came to my mind as well, but we haven't changed
anything on UVD in the radeon module in quite a while. So this is a bit
unlikely.

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

Re: [Mesa-dev] [PATCH] gm107/ir: fix bit offset of tex lod setting for indirect texturing

[Samuel Pitoiset]

On 10/18/2016 06:22 AM, Ilia Mirkin wrote:

Signed-off-by: Ilia Mirkin 
Cc: mesa-sta...@lists.freedesktop.org
---
 src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
index 3fedafd..5ed2ad4 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
@@ -2560,7 +2560,7 @@ CodeEmitterGM107::emitTEX()

if (insn->tex.rIndirectSrc >= 0) {
   emitInsn (0xdeb8);
-  emitField(0x35, 2, lodm);
+  emitField(0x25, 2, lodm);


The length should be 3, but as we don't use lba/lla, it's fine.

Reviewed-by: Samuel Pitoiset 


   emitField(0x24, 1, insn->tex.useOffsets == 1);
} else {
   emitInsn (0xc038);



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

Re: [Mesa-dev] [PATCH] st/va: set default rt formats when calling vaCreateConfig

[Christian König]

Am 17.10.2016 um 21:40 schrieb Julien Isorce:



On Monday, 17 October 2016, Mark Thompson > wrote:


On 17/10/16 17:33, Julien Isorce wrote:
> As specified in va.h, default value should be set on attributes
> not present in the input list.
>
> Signed-off-by: Julien Isorce >
> ---
>  src/gallium/state_trackers/va/config.c  | 9 +
>  src/gallium/state_trackers/va/surface.c | 5 +++--
>  2 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/state_trackers/va/config.c
b/src/gallium/state_trackers/va/config.c
> index 2f96eb6..fb236f1 100644
> --- a/src/gallium/state_trackers/va/config.c
> +++ b/src/gallium/state_trackers/va/config.c
> @@ -195,6 +195,11 @@ vlVaCreateConfig(VADriverContextP ctx,
VAProfile profile, VAEntrypoint entrypoin
>  }
>   }
>}
> +
> +  /* Default value if not specified in the input attributes. */
> +  if (!config->rt_format)
> +config->rt_format = VA_RT_FORMAT_YUV420 |
VA_RT_FORMAT_RGB32;

Indent should be three spaces.

> +
>pipe_mutex_lock(drv->mutex);
>*config_id = handle_table_add(drv->htab, config);
>pipe_mutex_unlock(drv->mutex);
> @@ -256,6 +261,10 @@ vlVaCreateConfig(VADriverContextP ctx,
VAProfile profile, VAEntrypoint entrypoin
>}
> }
>
> +   /* Default value if not specified in the input attributes. */
> +   if (!config->rt_format)
> + config->rt_format = VA_RT_FORMAT_YUV420;

And here.


Oh I forgot :) , cheers.


> +
> pipe_mutex_lock(drv->mutex);
> *config_id = handle_table_add(drv->htab, config);
> pipe_mutex_unlock(drv->mutex);
> diff --git a/src/gallium/state_trackers/va/surface.c
b/src/gallium/state_trackers/va/surface.c
> index 5e92980..f8513d9 100644
> --- a/src/gallium/state_trackers/va/surface.c
> +++ b/src/gallium/state_trackers/va/surface.c
> @@ -419,7 +419,7 @@ vlVaQuerySurfaceAttributes(VADriverContextP
ctx, VAConfigID config_id,
> /* vlVaCreateConfig returns PIPE_VIDEO_PROFILE_UNKNOWN
>  * only for VAEntrypointVideoProc. */
> if (config->profile == PIPE_VIDEO_PROFILE_UNKNOWN) {
> -  if (config->rt_format == VA_RT_FORMAT_RGB32) {
> +  if (config->rt_format & VA_RT_FORMAT_RGB32) {
>   for (j = 0; j < ARRAY_SIZE(vpp_surface_formats); ++j) {
>  attribs[i].type = VASurfaceAttribPixelFormat;
>  attribs[i].value.type = VAGenericValueTypeInteger;
> @@ -427,7 +427,8 @@ vlVaQuerySurfaceAttributes(VADriverContextP
ctx, VAConfigID config_id,
>  attribs[i].value.value.i =
PipeFormatToVaFourcc(vpp_surface_formats[j]);
>  i++;
>   }
> -  } else if (config->rt_format == VA_RT_FORMAT_YUV420) {
> +  }
> +  if (config->rt_format & VA_RT_FORMAT_YUV420) {
>   attribs[i].type = VASurfaceAttribPixelFormat;
>   attribs[i].value.type = VAGenericValueTypeInteger;
>   attribs[i].flags = VA_SURFACE_ATTRIB_GETTABLE |
VA_SURFACE_ATTRIB_SETTABLE;
>

Actual code LGTM, and tested.

Reviewed-by: Mark Thompson >


Thx, will push it soon.


If you haven't already pushed it with the fixes Mark mentioned the patch 
is Reviewed-by: Christian König  as well.


Regards,
Christian.


Julien


Thanks,

- Mark

___
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] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

[bugzilla-daemon]

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

--- Comment #24 from Marek Olšák  ---
Hm. Probably none. The patch looks good.

BTW, the patch won't apply on master, because the fence_finish function is
slightly different there.

-- 
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] [PATCH 06/15] ralloc: add a linear allocator as a child node of ralloc

[Nicolai Hähnle]

Reviewed-by: Nicolai Hähnle 

On 17.10.2016 19:50, Marek Olšák wrote:

From: Marek Olšák 

v2: remove goto, cosmetic changes

Tested-by: Edmondo Tommasina  (v1)
---
 src/util/ralloc.c | 353 ++
 src/util/ralloc.h |  84 -
 2 files changed, 433 insertions(+), 4 deletions(-)

diff --git a/src/util/ralloc.c b/src/util/ralloc.c
index b202753..980e4e4 100644
--- a/src/util/ralloc.c
+++ b/src/util/ralloc.c
@@ -521,10 +521,363 @@ ralloc_vasprintf_rewrite_tail(char **str, size_t *start, 
const char *fmt,

ptr = resize(*str, *start + new_length + 1);
if (unlikely(ptr == NULL))
   return false;

vsnprintf(ptr + *start, new_length + 1, fmt, args);
*str = ptr;
*start += new_length;
return true;
 }
+
+/***
+ * Linear allocator for short-lived allocations.
+ ***
+ *
+ * The allocator consists of a parent node (2K buffer), which requires
+ * a ralloc parent, and child nodes (allocations). Child nodes can't be freed
+ * directly, because the parent doesn't track them. You have to release
+ * the parent node in order to release all its children.
+ *
+ * The allocator uses a fixed-sized buffer with a monotonically increasing
+ * offset after each allocation. If the buffer is all used, another buffer
+ * is allocated, sharing the same ralloc parent, so all buffers are at
+ * the same level in the ralloc hierarchy.
+ *
+ * The linear parent node is always the first buffer and keeps track of all
+ * other buffers.
+ */
+
+#define ALIGN_POT(x, y) (((x) + (y) - 1) & ~((y) - 1))
+
+#define MIN_LINEAR_BUFSIZE 2048
+#define SUBALLOC_ALIGNMENT sizeof(uintptr_t)
+#define LMAGIC 0x87b9c7d3
+
+struct linear_header {
+#ifdef DEBUG
+   unsigned magic;   /* for debugging */
+#endif
+   unsigned offset;  /* points to the first unused byte in the buffer */
+   unsigned size;/* size of the buffer */
+   void *ralloc_parent;  /* new buffers will use this */
+   struct linear_header *next;   /* next buffer if we have more */
+   struct linear_header *latest; /* the only buffer that has free space */
+
+   /* After this structure, the buffer begins.
+* Each suballocation consists of linear_size_chunk as its header followed
+* by the suballocation, so it goes:
+*
+* - linear_size_chunk
+* - allocated space
+* - linear_size_chunk
+* - allocated space
+* etc.
+*
+* linear_size_chunk is only needed by linear_realloc.
+*/
+};
+
+struct linear_size_chunk {
+   unsigned size; /* for realloc */
+   unsigned _padding;
+};
+
+typedef struct linear_header linear_header;
+typedef struct linear_size_chunk linear_size_chunk;
+
+#define LINEAR_PARENT_TO_HEADER(parent) \
+   (linear_header*) \
+   ((char*)(parent) - sizeof(linear_size_chunk) - sizeof(linear_header))
+
+/* Allocate the linear buffer with its header. */
+static linear_header *
+create_linear_node(void *ralloc_ctx, unsigned min_size)
+{
+   linear_header *node;
+
+   min_size += sizeof(linear_size_chunk);
+
+   if (likely(min_size < MIN_LINEAR_BUFSIZE))
+  min_size = MIN_LINEAR_BUFSIZE;
+
+   node = ralloc_size(ralloc_ctx, sizeof(linear_header) + min_size);
+   if (unlikely(!node))
+  return NULL;
+
+#ifdef DEBUG
+   node->magic = LMAGIC;
+#endif
+   node->offset = 0;
+   node->size = min_size;
+   node->ralloc_parent = ralloc_ctx;
+   node->next = NULL;
+   node->latest = node;
+   return node;
+}
+
+void *
+linear_alloc_child(void *parent, unsigned size)
+{
+   linear_header *first = LINEAR_PARENT_TO_HEADER(parent);
+   linear_header *latest = first->latest;
+   linear_header *new_node;
+   linear_size_chunk *ptr;
+   unsigned full_size;
+
+   assert(first->magic == LMAGIC);
+   assert(!latest->next);
+
+   size = ALIGN_POT(size, SUBALLOC_ALIGNMENT);
+   full_size = sizeof(linear_size_chunk) + size;
+
+   if (unlikely(latest->offset + full_size > latest->size)) {
+  /* allocate a new node */
+  new_node = create_linear_node(latest->ralloc_parent, size);
+  if (unlikely(!new_node))
+ return NULL;
+
+  first->latest = new_node;
+  latest->latest = new_node;
+  latest->next = new_node;
+  latest = new_node;
+   }
+
+   ptr = (linear_size_chunk *)((char*)&latest[1] + latest->offset);
+   ptr->size = size;
+   latest->offset += full_size;
+   return &ptr[1];
+}
+
+void *
+linear_alloc_parent(void *ralloc_ctx, unsigned size)
+{
+   linear_header *node;
+
+   if (unlikely(!ralloc_ctx))
+  return NULL;
+
+   size = ALIGN_POT(size, SUBALLOC_ALIGNMENT);
+
+   node = create_linear_node(ralloc_ctx, size);
+   if (unlikely(!node))
+  return NULL;
+
+   return linear_alloc_child((char*)node +
+ sizeof(linear_header) +
+ sizeof(linear_size_chunk), size);
+}
+
+void *
+linear_zalloc_child(void *parent, unsigned size)
+

Re: [Mesa-dev] [PATCH shader-db 2/2] si-report.py: print more regressed and bad shaders

[Nicolai Hähnle]

Both are:

Reviewed-by: Nicolai Hähnle 

On 17.10.2016 22:03, Marek Olšák wrote:

From: Marek Olšák 

---
 si-report.py | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/si-report.py b/si-report.py
index 144a229..620b3bd 100755
--- a/si-report.py
+++ b/si-report.py
@@ -535,20 +535,21 @@ def get_shader_name(list, orig):
 assert False
 return "(error)"


 def print_yellow(str):
 print set_yellow + str + set_normal

 def print_tables(before_all_results, after_all_results):
 re_app = re.compile(r"^.*/([^/]+)/[^/]+$")

+num_listed = 20
 apps = defaultdict(grouped_stats)
 shaders = defaultdict(grouped_stats)
 total = grouped_stats()
 total_affected = grouped_stats()

 all_files = set(itertools.chain(before_all_results.keys(),
 after_all_results.keys()))

 for file in all_files:
 # get the application name (inner-most directory)
@@ -587,41 +588,41 @@ def print_tables(before_all_results, after_all_results):

 # worst VGPR spills
 num = 0
 sort_key = lambda v: -v[1].after.scratch_vgprs
 for name, stats in sorted(shaders.items(), key = sort_key):
 if num == 0:
 print_yellow(" WORST VGPR SPILLS (not deltas)" + (" " * 40) +
  "VGPRs SpillVGPR ScratchVGPR")
 stats.print_one_shader_vgpr_spill(name)
 num += 1
-if num == 10:
+if num == num_listed:
 break
 if num > 0:
 print

 # VGPR spilling apps
 print_yellow(" VGPR SPILLING APPS   Shaders SpillVGPR ScratchVGPR")
 for name, stats in sorted(apps.items()):
 stats.print_vgpr_spilling_app(name)
 print

 # worst SGPR spills
 num = 0
 sort_key = lambda v: -v[1].after.spilled_sgprs
 for name, stats in sorted(shaders.items(), key = sort_key):
 if num == 0:
 print_yellow(" WORST SGPR SPILLS (not deltas)" + (" " * 40) +
  "SGPRs SpillSGPR")
 stats.print_one_shader_sgpr_spill(name)
 num += 1
-if num == 10:
+if num == num_listed:
 break
 if num > 0:
 print

 # SGPR spilling apps
 print_yellow(" SGPR SPILLING APPS   Shaders SpillSGPR AvgPerSh")
 for name, stats in sorted(apps.items()):
 stats.print_sgpr_spilling_app(name)
 print

@@ -643,21 +644,21 @@ def print_tables(before_all_results, after_all_results):
 continue
 else:
 if stats.diff.__dict__[field] <= 0:
 continue

 if num == 0:
 print_yellow(" WORST REGRESSIONS - 
{:49}".format(metrics[i][1]) +
  "Before After Delta Percentage")
 stats.print_regression(name, field)
 num += 1
-if num == 10:
+if num == num_listed:
 break
 if num > 0:
 print

 # percentages
 legend = "Shaders SGPRs VGPRs SpillSGPR SpillVGPR   Scratch  CodeSize  
MaxWaves Waits"
 print_yellow(" PERCENTAGE DELTAS" + legend)
 for name, stats in sorted(apps.items()):
 stats.print_percentages(name)
 print " " + ("-" * (21 + len(legend)))


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

Re: [Mesa-dev] [PATCH] gallium/tgsi: add missing #include

[Nicolai Hähnle]

Reviewed-by: Nicolai Hähnle 

On 17.10.2016 15:40, Marek Olšák wrote:

From: Marek Olšák 

---
 src/gallium/auxiliary/tgsi/tgsi_util.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_util.h 
b/src/gallium/auxiliary/tgsi/tgsi_util.h
index ca07bfd..83a930b 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_util.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_util.h
@@ -25,20 +25,22 @@
  *
  **/

 #ifndef TGSI_UTIL_H
 #define TGSI_UTIL_H

 #if defined __cplusplus
 extern "C" {
 #endif

+#include "pipe/p_shader_tokens.h"
+
 struct tgsi_src_register;
 struct tgsi_full_src_register;
 struct tgsi_full_instruction;

 void *
 tgsi_align_128bit(
void *unaligned );

 unsigned
 tgsi_util_get_src_register_swizzle(


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

Re: [Mesa-dev] [PATCH] st/va: disable cabac for h264 baseline profile

[Andy Furniss]

boyuan.zh...@amd.com wrote:

From: Boyuan Zhang 

cabac is only supported in the h264 main and higher profiles


So shouldn't there be code allows it if the user space doesn't
set baseline?

I don't know how in gstreamer as it seems to try to use b-frames
if you use other than baseline which doesn't work.

With avconv it is possible to call main/high and set b-frames to 0.

I know it's technically correct spec wise, but seems a shame as it
costs a fair bit in "free" efficiency.

On Windows the raptor game recording app produces files flagged as
high with cabac - but without b-frames.


Signed-off-by: Boyuan Zhang 
---
  src/gallium/state_trackers/va/picture.c | 1 -
  1 file changed, 1 deletion(-)

diff --git a/src/gallium/state_trackers/va/picture.c 
b/src/gallium/state_trackers/va/picture.c
index eae5dc4..db08a3c 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -110,7 +110,6 @@ getEncParamPreset(vlVaContext *context)
 context->desc.h264enc.motion_est.enc_ime2_search_range_y = 0x0004;

 //pic control preset
-   context->desc.h264enc.pic_ctrl.enc_cabac_enable = 0x0001;
 context->desc.h264enc.pic_ctrl.enc_constraint_set_flags = 0x0040;

 //rate control



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

Re: [Mesa-dev] [PATCH 01/14] glsl_to_tgsi: use array_id for temp arrays instead of hacking high bits

[Nicolai Hähnle]

On 17.10.2016 15:39, Marek Olšák wrote:

From: Marek Olšák 

---
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 31 ++
 1 file changed, 19 insertions(+), 12 deletions(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index fd2485d..5bc2661 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp

[snip]

@@ -2488,33 +2495,35 @@ glsl_to_tgsi_visitor::visit(ir_dereference_variable *ir)
   }
   case ir_var_system_value:
  entry = new(mem_ctx) variable_storage(var,
PROGRAM_SYSTEM_VALUE,
var->data.location);
  break;
   case ir_var_auto:
   case ir_var_temporary:
  st_src_reg src = get_temp(var->type);

- entry = new(mem_ctx) variable_storage(var, src.file, src.index);
+ entry = new(mem_ctx) variable_storage(var, src.file, src.index,
+   src.array_id);
  this->variables.push_tail(entry);

  break;
   }

   if (!entry) {
  printf("Failed to make storage for %s\n", var->name);
  exit(1);
   }
}

-   this->result = st_src_reg(entry->file, entry->index, var->type, 
entry->component);
+   this->result = st_src_reg(entry->file, entry->index, var->type,
+ entry->component, entry->array_id);
this->result.array_id = entry->array_id;


This assignment can be removed now.

Apart from that, this patch is

Reviewed-by: Nicolai Hähnle 


if (this->shader->Stage == MESA_SHADER_VERTEX && var->data.mode == ir_var_shader_in 
&& var->type->is_double())
   this->result.is_double_vertex_input = true;
if (!native_integers)
   this->result.type = GLSL_TYPE_FLOAT;
 }

 static void
 shrink_array_declarations(struct inout_decl *decls, unsigned count,
   GLbitfield64* usage_mask,
@@ -5489,30 +5498,28 @@ dst_register(struct st_translate *t, gl_register_file 
file, unsigned index,
  memset(t->temps + t->temps_size, 0, inc * sizeof(struct ureg_dst));
  t->temps_size += inc;
   }

   if (ureg_dst_is_undef(t->temps[index]))
  t->temps[index] = ureg_DECL_local_temporary(t->ureg);

   return t->temps[index];

case PROGRAM_ARRAY:
-  array = index >> 16;
-
-  assert(array < t->num_temp_arrays);
+  assert(array_id && array_id <= t->num_temp_arrays);
+  array = array_id - 1;

   if (ureg_dst_is_undef(t->arrays[array]))
  t->arrays[array] = ureg_DECL_array_temporary(
 t->ureg, t->array_sizes[array], TRUE);

-  return ureg_dst_array_offset(t->arrays[array],
-   (int)(index & 0x) - 0x8000);
+  return ureg_dst_array_offset(t->arrays[array], index);

case PROGRAM_OUTPUT:
   if (!array_id) {
  if (t->procType == PIPE_SHADER_FRAGMENT)
 assert(index < 2 * FRAG_RESULT_MAX);
  else if (t->procType == PIPE_SHADER_TESS_CTRL ||
   t->procType == PIPE_SHADER_TESS_EVAL)
 assert(index < VARYING_SLOT_TESS_MAX);
  else
 assert(index < VARYING_SLOT_MAX);


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

Re: [Mesa-dev] [PATCH 04/14] glsl_to_tgsi: reduce the size of st_dst_reg and st_src_reg

[Nicolai Hähnle]

On 17.10.2016 15:39, Marek Olšák wrote:

From: Marek Olšák 

I noticed that glsl_to_tgsi_instruction is too huge.

sizeof(glsl_to_tgsi_instruction): 752 -> 464 (-38%)
---
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 71 +-
 1 file changed, 40 insertions(+), 31 deletions(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 93673fa..78d9409 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -152,37 +152,38 @@ public:
   this->reladdr = NULL;
   this->reladdr2 = NULL;
   this->has_index2 = false;
   this->double_reg2 = false;
   this->array_id = 0;
   this->is_double_vertex_input = false;
}

explicit st_src_reg(st_dst_reg reg);

-   gl_register_file file; /**< PROGRAM_* from Mesa */
-   int index; /**< temporary index, VERT_ATTRIB_*, VARYING_SLOT_*, etc. */
-   int index2D;
-   GLuint swizzle; /**< SWIZZLE_XYZWONEZERO swizzles from Mesa. */
-   int negate; /**< NEGATE_XYZW mask from mesa */
-   enum glsl_base_type type; /** GLSL_TYPE_* from GLSL IR (enum 
glsl_base_type) */
-   /** Register index should be offset by the integer in this reg. */
-   st_src_reg *reladdr;
-   st_src_reg *reladdr2;
-   bool has_index2;
+   int16_t index; /**< temporary index, VERT_ATTRIB_*, VARYING_SLOT_*, etc. */
+   int16_t index2D;


This reminds me that we really should have proper error handling for 
when these various numbers overflow. Anyway, patches 2-4:


Reviewed-by: Nicolai Hähnle 


+   uint16_t swizzle; /**< SWIZZLE_XYZWONEZERO swizzles from Mesa. */
+   int negate:4; /**< NEGATE_XYZW mask from mesa */
+   enum glsl_base_type type:4; /** GLSL_TYPE_* from GLSL IR (enum 
glsl_base_type) */
+   unsigned has_index2:1;
+   gl_register_file file:5; /**< PROGRAM_* from Mesa */
/*
 * Is this the second half of a double register pair?
 * currently used for input mapping only.
 */
-   bool double_reg2;
-   unsigned array_id;
-   bool is_double_vertex_input;
+   unsigned double_reg2:1;
+   unsigned is_double_vertex_input:1;
+   unsigned array_id:10;
+
+   /** Register index should be offset by the integer in this reg. */
+   st_src_reg *reladdr;
+   st_src_reg *reladdr2;
 };

 class st_dst_reg {
 public:
st_dst_reg(gl_register_file file, int writemask, enum glsl_base_type type, 
int index)
{
   assert(file != PROGRAM_ARRAY); /* need array_id > 0 */
   this->file = file;
   this->index = index;
   this->index2D = 0;
@@ -216,30 +217,31 @@ public:
   this->index2D = 0;
   this->writemask = 0;
   this->reladdr = NULL;
   this->reladdr2 = NULL;
   this->has_index2 = false;
   this->array_id = 0;
}

explicit st_dst_reg(st_src_reg reg);

-   gl_register_file file; /**< PROGRAM_* from Mesa */
-   int index; /**< temporary index, VERT_ATTRIB_*, VARYING_SLOT_*, etc. */
-   int index2D;
-   int writemask; /**< Bitfield of WRITEMASK_[XYZW] */
-   enum glsl_base_type type; /** GLSL_TYPE_* from GLSL IR (enum 
glsl_base_type) */
+   int16_t index; /**< temporary index, VERT_ATTRIB_*, VARYING_SLOT_*, etc. */
+   int16_t index2D;
+   gl_register_file file:5; /**< PROGRAM_* from Mesa */
+   unsigned writemask:4; /**< Bitfield of WRITEMASK_[XYZW] */
+   enum glsl_base_type type:4; /** GLSL_TYPE_* from GLSL IR (enum 
glsl_base_type) */
+   unsigned has_index2:1;
+   unsigned array_id:10;
+
/** Register index should be offset by the integer in this reg. */
st_src_reg *reladdr;
st_src_reg *reladdr2;
-   bool has_index2;
-   unsigned array_id;
 };

 st_src_reg::st_src_reg(st_dst_reg reg)
 {
this->type = reg.type;
this->file = reg.file;
this->index = reg.index;
this->swizzle = SWIZZLE_XYZW;
this->negate = 0;
this->reladdr = reg.reladdr;
@@ -445,21 +447,21 @@ public:

int glsl_version;
bool native_integers;
bool have_sqrt;
bool have_fma;
bool use_shared_memory;

variable_storage *find_variable_storage(ir_variable *var);

int add_constant(gl_register_file file, gl_constant_value values[8],
-int size, int datatype, GLuint *swizzle_out);
+int size, int datatype, uint16_t *swizzle_out);

function_entry *get_function_signature(ir_function_signature *sig);

st_src_reg get_temp(const glsl_type *type);
void reladdr_to_temp(ir_instruction *ir, st_src_reg *reg, int *num_reladdr);

st_src_reg st_src_reg_for_double(double val);
st_src_reg st_src_reg_for_float(float val);
st_src_reg st_src_reg_for_int(int val);
st_src_reg st_src_reg_for_type(enum glsl_base_type type, int val);
@@ -549,25 +551,25 @@ public:
 st_dst_reg dst, st_src_reg src0);

void emit_scalar(ir_instruction *ir, unsigned op,
 st_dst_reg dst, st_src_reg src0, st_src_reg src1);

void emit_arl(ir_instruction *ir, st_dst_reg dst, st_src_reg src0);

void get_deref_offsets(ir_deref

Re: [Mesa-dev] [PATCH] glsl: optimize list handling in opt_dead_code

[Eero Tamminen]

Hi,

On 18.10.2016 01:07, Jan Ziak wrote:

This patch replaces the ir_variable_refcount_entry's linked-list
with an array-list.

The array-list has local storage which does not require ANY additional
allocations if the list has small number of elements. The size of this
storage is configurable for each variable.

Benchmark results for "./run -1 shaders" from shader-db[1]:

- The total number of executed instructions goes down from 64.184 to 63.797
  giga-instructions when Mesa is compiled with "gcc -O0 ..."


Please don't do performance related decisions based on data from 
compiling code with optimizations disabled.  Use -O2 or -O3 (or even 
better, check both).




- In the call tree starting at function do_dead_code():
  - the number of calls to malloc() is reduced by about 10%
  - the number of calls to free() is reduced by about 30%

[1] git://anongit.freedesktop.org/mesa/shader-db



- Eero

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

Re: [Mesa-dev] [PATCH] st/va: disable cabac for h264 baseline profile

[Christian König]

Am 18.10.2016 um 11:19 schrieb Andy Furniss:

boyuan.zh...@amd.com wrote:

From: Boyuan Zhang 

cabac is only supported in the h264 main and higher profiles


So shouldn't there be code allows it if the user space doesn't
set baseline?

I don't know how in gstreamer as it seems to try to use b-frames
if you use other than baseline which doesn't work.

With avconv it is possible to call main/high and set b-frames to 0.

I know it's technically correct spec wise, but seems a shame as it
costs a fair bit in "free" efficiency.

On Windows the raptor game recording app produces files flagged as
high with cabac - but without b-frames.


The problem is that it can easily break decoders. CABAC is simply not 
allowed in a stream flagged as baseline compliant.


It's a pity that we don't support B-frames any more. With that in place 
we could easily advertise support for mainline profile.


Christian.




Signed-off-by: Boyuan Zhang 
---
  src/gallium/state_trackers/va/picture.c | 1 -
  1 file changed, 1 deletion(-)

diff --git a/src/gallium/state_trackers/va/picture.c 
b/src/gallium/state_trackers/va/picture.c

index eae5dc4..db08a3c 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -110,7 +110,6 @@ getEncParamPreset(vlVaContext *context)
 context->desc.h264enc.motion_est.enc_ime2_search_range_y = 
0x0004;


 //pic control preset
-   context->desc.h264enc.pic_ctrl.enc_cabac_enable = 0x0001;
 context->desc.h264enc.pic_ctrl.enc_constraint_set_flags = 
0x0040;


 //rate control



___
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 14/14] mesa: remove gl_shader_compiler_options::EmitNoNoise

[Nicolai Hähnle]

Patches 5-12, 14 are

Reviewed-by: Nicolai Hähnle 

Those inline-explosion tests have been bugging me as well, but 
realistically speaking, the compiler needs to be at least robust enough 
to just not blow up and instead refuse compilation before any work on 
proper subroutines.


Cheers,
Nicolai

On 17.10.2016 15:39, Marek Olšák wrote:

From: Marek Olšák 

it's always true
---
 src/mesa/drivers/dri/i915/i915_context.c | 1 -
 src/mesa/drivers/dri/i965/brw_compiler.c | 1 -
 src/mesa/main/mtypes.h   | 1 -
 src/mesa/program/ir_to_mesa.cpp  | 3 +--
 src/mesa/state_tracker/st_extensions.c   | 2 --
 5 files changed, 1 insertion(+), 7 deletions(-)

diff --git a/src/mesa/drivers/dri/i915/i915_context.c 
b/src/mesa/drivers/dri/i915/i915_context.c
index a7604a1..05a2ad1 100644
--- a/src/mesa/drivers/dri/i915/i915_context.c
+++ b/src/mesa/drivers/dri/i915/i915_context.c
@@ -253,21 +253,20 @@ i915CreateContext(int api,

/* FINISHME: Are there other options that should be enabled for software
 * FINISHME: vertex shaders?
 */
ctx->Const.ShaderCompilerOptions[MESA_SHADER_VERTEX].EmitNoIndirectSampler =
   true;

struct gl_shader_compiler_options *const fs_options =
   & ctx->Const.ShaderCompilerOptions[MESA_SHADER_FRAGMENT];
fs_options->MaxIfDepth = 0;
-   fs_options->EmitNoNoise = true;
fs_options->EmitNoPow = true;
fs_options->EmitNoIndirectInput = true;
fs_options->EmitNoIndirectOutput = true;
fs_options->EmitNoIndirectUniform = true;
fs_options->EmitNoIndirectTemp = true;
fs_options->EmitNoIndirectSampler = true;

ctx->Const.MaxDrawBuffers = 1;
ctx->Const.QueryCounterBits.SamplesPassed = 0;

diff --git a/src/mesa/drivers/dri/i965/brw_compiler.c 
b/src/mesa/drivers/dri/i965/brw_compiler.c
index 27cbd40..4fcc51b 100644
--- a/src/mesa/drivers/dri/i965/brw_compiler.c
+++ b/src/mesa/drivers/dri/i965/brw_compiler.c
@@ -116,21 +116,20 @@ brw_compiler_create(void *mem_ctx, const struct 
gen_device_info *devinfo)
   devinfo->gen >= 8 && env_var_as_boolean("INTEL_SCALAR_GS", true);
compiler->scalar_stage[MESA_SHADER_FRAGMENT] = true;
compiler->scalar_stage[MESA_SHADER_COMPUTE] = true;

/* We want the GLSL compiler to emit code that uses condition codes */
for (int i = 0; i < MESA_SHADER_STAGES; i++) {
   compiler->glsl_compiler_options[i].MaxUnrollIterations = 32;
   compiler->glsl_compiler_options[i].MaxIfDepth =
  devinfo->gen < 6 ? 16 : UINT_MAX;

-  compiler->glsl_compiler_options[i].EmitNoNoise = true;
   compiler->glsl_compiler_options[i].EmitNoIndirectInput = true;
   compiler->glsl_compiler_options[i].EmitNoIndirectUniform = false;
   compiler->glsl_compiler_options[i].LowerCombinedClipCullDistance = true;

   bool is_scalar = compiler->scalar_stage[i];

   compiler->glsl_compiler_options[i].EmitNoIndirectOutput = is_scalar;
   compiler->glsl_compiler_options[i].EmitNoIndirectTemp = is_scalar;
   compiler->glsl_compiler_options[i].OptimizeForAOS = !is_scalar;

diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 701f055..f2ecd6e 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -2990,21 +2990,20 @@ struct gl_pipeline_shader_state
 };

 /**
  * Compiler options for a single GLSL shaders type
  */
 struct gl_shader_compiler_options
 {
/** Driver-selectable options: */
GLboolean EmitNoLoops;
GLboolean EmitNoCont;  /**< Emit CONT opcode? */
-   GLboolean EmitNoNoise; /**< Emit NOISE opcodes? */
GLboolean EmitNoPow;   /**< Emit POW opcodes? */
GLboolean EmitNoSat;   /**< Emit SAT opcodes? */
GLboolean LowerCombinedClipCullDistance; /** Lower gl_ClipDistance and
   * gl_CullDistance together from
   * float[8] to vec4[2]
   **/

/**
 * \name Forms of indirect addressing the driver cannot do.
 */
diff --git a/src/mesa/program/ir_to_mesa.cpp b/src/mesa/program/ir_to_mesa.cpp
index d0e83cc..be10432 100644
--- a/src/mesa/program/ir_to_mesa.cpp
+++ b/src/mesa/program/ir_to_mesa.cpp
@@ -2989,22 +2989,21 @@ _mesa_ir_link_shader(struct gl_context *ctx, struct 
gl_shader_program *prog)
options, ctx->Const.NativeIntegers)
   || progress;

 progress = lower_quadop_vector(ir, true) || progress;

 if (options->MaxIfDepth == 0)
progress = lower_discard(ir) || progress;

 progress = lower_if_to_cond_assign(ir, options->MaxIfDepth) || 
progress;

-if (options->EmitNoNoise)
-   progress = lower_noise(ir) || progress;
+ progress = lower_noise(ir) || progress;

 /* If there are forms of indirect addressing that the driver
  * cannot handle, perform the lowering pass.
  */
 if (options->Emi

Re: [Mesa-dev] [PATCH 6/6] radeonsi: rename prefixes from radeon to si

[Nicolai Hähnle]

Makes sense as a cleanup. At some point it would make sense to look into 
sharing some stuff with radv instead. There's probably not a huge amount 
because of the NIR/TGSI split, but still.


Patches 1 & 4:

Acked-by: Nicolai Hähnle 

Patches 2, 3, 5, 6:

Reviewed-by: Nicolai Hähnle 

On 17.10.2016 15:44, Marek Olšák wrote:

From: Marek Olšák 

---
 src/gallium/drivers/radeonsi/si_pipe.c |   2 +-
 src/gallium/drivers/radeonsi/si_shader.c   |  96 ++---
 src/gallium/drivers/radeonsi/si_shader_internal.h  |  70 +-
 .../drivers/radeonsi/si_shader_tgsi_setup.c| 150 ++---
 4 files changed, 159 insertions(+), 159 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_pipe.c 
b/src/gallium/drivers/radeonsi/si_pipe.c
index 7924375..a9faa75 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -119,21 +119,21 @@ static void si_emit_string_marker(struct pipe_context 
*ctx,
struct si_context *sctx = (struct si_context *)ctx;

dd_parse_apitrace_marker(string, len, &sctx->apitrace_call_number);
 }

 static LLVMTargetMachineRef
 si_create_llvm_target_machine(struct si_screen *sscreen)
 {
const char *triple = "amdgcn--";

-   return LLVMCreateTargetMachine(radeon_llvm_get_r600_target(triple), 
triple,
+   return LLVMCreateTargetMachine(si_llvm_get_amdgpu_target(triple), 
triple,
   
r600_get_llvm_processor_name(sscreen->b.family),
 #if HAVE_LLVM >= 0x0308
   sscreen->b.debug_flags & DBG_SI_SCHED ?
   SI_LLVM_DEFAULT_FEATURES 
",+si-scheduler" :
 #endif
   SI_LLVM_DEFAULT_FEATURES,
   LLVMCodeGenLevelDefault,
   LLVMRelocDefault,
   LLVMCodeModelDefault);
 }
diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
b/src/gallium/drivers/radeonsi/si_shader.c
index bca07ac..cbf2090 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -478,21 +478,21 @@ static LLVMValueRef get_bounded_indirect_index(struct 
si_shader_context *ctx,
 {
LLVMValueRef result = get_indirect_index(ctx, ind, rel_index);

/* LLVM 3.8: If indirect resource indexing is used:
 * - SI & CIK hang
 * - VI crashes
 */
if (HAVE_LLVM <= 0x0308)
return LLVMGetUndef(ctx->i32);

-   return radeon_llvm_bound_index(ctx, result, num);
+   return si_llvm_bound_index(ctx, result, num);
 }


 /**
  * Calculate a dword address given an input or output register and a stride.
  */
 static LLVMValueRef get_dw_address(struct si_shader_context *ctx,
   const struct tgsi_full_dst_register *dst,
   const struct tgsi_full_src_register *src,
   LLVMValueRef vertex_dw_stride,
@@ -869,21 +869,21 @@ static LLVMValueRef buffer_load(struct 
lp_build_tgsi_context *bld_base,
return LLVMBuildExtractElement(gallivm->builder, value,
lp_build_const_int32(gallivm, swizzle), "");
}

value = build_buffer_load(ctx, buffer, 1, NULL, base, offset,
  swizzle * 4, 1, 0);

value2 = build_buffer_load(ctx, buffer, 1, NULL, base, offset,
   swizzle * 4 + 4, 1, 0);

-   return radeon_llvm_emit_fetch_64bit(bld_base, type, value, value2);
+   return si_llvm_emit_fetch_64bit(bld_base, type, value, value2);
 }

 /**
  * Load from LDS.
  *
  * \param type output value type
  * \param swizzle  offset (typically 0..3); it can be ~0, which loads a 
vec4
  * \param dw_addr  address in dwords
  */
 static LLVMValueRef lds_load(struct lp_build_tgsi_context *bld_base,
@@ -906,21 +906,21 @@ static LLVMValueRef lds_load(struct lp_build_tgsi_context 
*bld_base,

dw_addr = lp_build_add(&bld_base->uint_bld, dw_addr,
lp_build_const_int32(gallivm, swizzle));

value = build_indexed_load(ctx, ctx->lds, dw_addr, false);
if (tgsi_type_is_64bit(type)) {
LLVMValueRef value2;
dw_addr = lp_build_add(&bld_base->uint_bld, dw_addr,
   lp_build_const_int32(gallivm, swizzle + 
1));
value2 = build_indexed_load(ctx, ctx->lds, dw_addr, false);
-   return radeon_llvm_emit_fetch_64bit(bld_base, type, value, 
value2);
+   return si_llvm_emit_fetch_64bit(bld_base, type, value, value2);
}

return LLVMBuildBitCast(gallivm->builder, value,
tgsi2llvmtype(bld_base, type), "");
 }

 /**
  * Store to LDS.
  *
  * \param swizzle  offset (typically 0..3)
@@ -1008,21 

Re: [Mesa-dev] [PATCH] st/va: disable cabac for h264 baseline profile

[Andy Furniss]

Christian König wrote:

Am 18.10.2016 um 11:19 schrieb Andy Furniss:

boyuan.zh...@amd.com wrote:

From: Boyuan Zhang 

cabac is only supported in the h264 main and higher profiles


So shouldn't there be code allows it if the user space doesn't
set baseline?

I don't know how in gstreamer as it seems to try to use b-frames
if you use other than baseline which doesn't work.

With avconv it is possible to call main/high and set b-frames to 0.

I know it's technically correct spec wise, but seems a shame as it
costs a fair bit in "free" efficiency.

On Windows the raptor game recording app produces files flagged as
high with cabac - but without b-frames.


The problem is that it can easily break decoders. CABAC is simply not
allowed in a stream flagged as baseline compliant.


But with ffmpeg/avconv I can make a stream flagged as main/high even
if it's really baseline + CABAC. I guess Windows may vary but the test
I did seems to take this pragmatic approach, as it seems do other h/w
encoders eg. smartphone output.


It's a pity that we don't support B-frames any more.


Anymore? Now I am curious, seems to work with omx (cqp single instance)



With that in place
we could easily advertise support for mainline profile.


MBAFF/PAFF?


Christian.




Signed-off-by: Boyuan Zhang 
---
  src/gallium/state_trackers/va/picture.c | 1 -
  1 file changed, 1 deletion(-)

diff --git a/src/gallium/state_trackers/va/picture.c
b/src/gallium/state_trackers/va/picture.c
index eae5dc4..db08a3c 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -110,7 +110,6 @@ getEncParamPreset(vlVaContext *context)
 context->desc.h264enc.motion_est.enc_ime2_search_range_y =
0x0004;

 //pic control preset
-   context->desc.h264enc.pic_ctrl.enc_cabac_enable = 0x0001;
 context->desc.h264enc.pic_ctrl.enc_constraint_set_flags =
0x0040;

 //rate control



___
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] [Bug 98271] [radeonsi]Playing videos with vdpau or vaapi hardware acceleration crashes my pc

[bugzilla-daemon]

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

--- Comment #14 from John  ---
> John, please double check that you are actually correctly installing VDPAU.
> E.g. add something like "while(1);" into the VDPAU driver create function or 
> something like this. vdp_imp_device_create_x11() would be a good place for 
> that.

Alright, I've just tried that and mpv seems to be waiting, no error in output
nor in dmesg, which should be as expected I guess.
Please tell me if you can think of any other thing I can test.


> That it's a kernel issue came to my mind as well, but we haven't changed 
> anything on UVD in the radeon module in quite a while. So this is a bit 
> unlikely.

I looked at radeon_uvd.c's history quickly and there were a few in the time
period I'd think of.
Based on the date I'd guess possibly either of the kernel commits on
2016-05-05, probably nothing later, and before is so far away.

Is amdgpu using the same firmware as radeon for SI? if not maybe that's another
option for the culprit.

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

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

[bugzilla-daemon]

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

--- Comment #25 from Suzuki, Shinji  ---
Thank you for your comments.
Patches attached here by me are against 11.2.
 I'll base on maser when posting diff to the mailing list.

-- 
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] [PATCH] st/va: set default rt formats when calling vaCreateConfig

[Julien Isorce]

Hi Christian,

I pushed it before already.  I can try to add a git notes if you want.
In any case thx for the review.

Cheers
Julien


On 18 October 2016 at 10:09, Christian König 
wrote:

> Am 17.10.2016 um 21:40 schrieb Julien Isorce:
>
>
>
> On Monday, 17 October 2016, Mark Thompson  wrote:
>
>> On 17/10/16 17:33, Julien Isorce wrote:
>> > As specified in va.h, default value should be set on attributes
>> > not present in the input list.
>> >
>> > Signed-off-by: Julien Isorce 
>> > ---
>> >  src/gallium/state_trackers/va/config.c  | 9 +
>> >  src/gallium/state_trackers/va/surface.c | 5 +++--
>> >  2 files changed, 12 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/src/gallium/state_trackers/va/config.c
>> b/src/gallium/state_trackers/va/config.c
>> > index 2f96eb6..fb236f1 100644
>> > --- a/src/gallium/state_trackers/va/config.c
>> > +++ b/src/gallium/state_trackers/va/config.c
>> > @@ -195,6 +195,11 @@ vlVaCreateConfig(VADriverContextP ctx, VAProfile
>> profile, VAEntrypoint entrypoin
>> >  }
>> >   }
>> >}
>> > +
>> > +  /* Default value if not specified in the input attributes. */
>> > +  if (!config->rt_format)
>> > +config->rt_format = VA_RT_FORMAT_YUV420 | VA_RT_FORMAT_RGB32;
>>
>> Indent should be three spaces.
>>
>> > +
>> >pipe_mutex_lock(drv->mutex);
>> >*config_id = handle_table_add(drv->htab, config);
>> >pipe_mutex_unlock(drv->mutex);
>> > @@ -256,6 +261,10 @@ vlVaCreateConfig(VADriverContextP ctx, VAProfile
>> profile, VAEntrypoint entrypoin
>> >}
>> > }
>> >
>> > +   /* Default value if not specified in the input attributes. */
>> > +   if (!config->rt_format)
>> > + config->rt_format = VA_RT_FORMAT_YUV420;
>>
>> And here.
>
>
> Oh I forgot :) , cheers.
>
>
>> > +
>> > pipe_mutex_lock(drv->mutex);
>> > *config_id = handle_table_add(drv->htab, config);
>> > pipe_mutex_unlock(drv->mutex);
>> > diff --git a/src/gallium/state_trackers/va/surface.c
>> b/src/gallium/state_trackers/va/surface.c
>> > index 5e92980..f8513d9 100644
>> > --- a/src/gallium/state_trackers/va/surface.c
>> > +++ b/src/gallium/state_trackers/va/surface.c
>> > @@ -419,7 +419,7 @@ vlVaQuerySurfaceAttributes(VADriverContextP ctx,
>> VAConfigID config_id,
>> > /* vlVaCreateConfig returns PIPE_VIDEO_PROFILE_UNKNOWN
>> >  * only for VAEntrypointVideoProc. */
>> > if (config->profile == PIPE_VIDEO_PROFILE_UNKNOWN) {
>> > -  if (config->rt_format == VA_RT_FORMAT_RGB32) {
>> > +  if (config->rt_format & VA_RT_FORMAT_RGB32) {
>> >   for (j = 0; j < ARRAY_SIZE(vpp_surface_formats); ++j) {
>> >  attribs[i].type = VASurfaceAttribPixelFormat;
>> >  attribs[i].value.type = VAGenericValueTypeInteger;
>> > @@ -427,7 +427,8 @@ vlVaQuerySurfaceAttributes(VADriverContextP ctx,
>> VAConfigID config_id,
>> >  attribs[i].value.value.i = PipeFormatToVaFourcc(vpp_surfa
>> ce_formats[j]);
>> >  i++;
>> >   }
>> > -  } else if (config->rt_format == VA_RT_FORMAT_YUV420) {
>> > +  }
>> > +  if (config->rt_format & VA_RT_FORMAT_YUV420) {
>> >   attribs[i].type = VASurfaceAttribPixelFormat;
>> >   attribs[i].value.type = VAGenericValueTypeInteger;
>> >   attribs[i].flags = VA_SURFACE_ATTRIB_GETTABLE |
>> VA_SURFACE_ATTRIB_SETTABLE;
>> >
>>
>> Actual code LGTM, and tested.
>>
>> Reviewed-by: Mark Thompson 
>
>
> Thx, will push it soon.
>
>
> If you haven't already pushed it with the fixes Mark mentioned the patch
> is Reviewed-by: Christian König 
>  as well.
>
> Regards,
> Christian.
>
> Julien
>
>
>>
>> Thanks,
>>
>> - Mark
>>
>> ___
>> 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] gm107/ir: fix texturing with indirect samplers

[Samuel Pitoiset]

On 10/18/2016 10:50 AM, Samuel Pitoiset wrote:



On 10/18/2016 05:53 AM, Ilia Mirkin wrote:

The indirect handle has to come right after the coordinates, so if there
was a sample/bias/depth compare/offset, everything would end up being
shifted by one argument position.

Signed-off-by: Ilia Mirkin 
Cc: mesa-sta...@lists.freedesktop.org
---
 src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 10
++
 1 file changed, 10 insertions(+)

diff --git
a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
index dab3e2d..83154c1 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
@@ -751,6 +751,16 @@ NVC0LoweringPass::handleTEX(TexInstruction *i)
  i->tex.rIndirectSrc = 0;
  i->tex.sIndirectSrc = -1;
   }
+  // Move the indirect reference to right after the coords
+  else if (i->tex.rIndirectSrc >= 0 && chipset >=
NVISA_GM107_CHIPSET) {
+ Value *hnd = i->getIndirectR();
+
+ i->setIndirectR(NULL);
+ i->moveSources(arg, 1);
+ i->setSrc(arg, hnd);
+ i->tex.rIndirectSrc = 0;
+ i->tex.sIndirectSrc = -1;
+  }


This looks (a bit) redundant with the loop above, but texture arguments
are insane, so... :)

I'm going to run piglit.


Confirmed, this fixes a bunch of dEQP tests with indirect samplers.
No regressions with full piglit on GM206.
Thanks!




} else
// (nvc0) generate and move the tsc/tic/array source to the front
if (i->tex.target.isArray() || i->tex.rIndirectSrc >= 0 ||
i->tex.sIndirectSrc >= 0) {





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

Re: [Mesa-dev] [PATCH] gm107/ir: fix texturing with indirect samplers

[Samuel Pitoiset]

On 10/18/2016 12:33 PM, Samuel Pitoiset wrote:



On 10/18/2016 10:50 AM, Samuel Pitoiset wrote:



On 10/18/2016 05:53 AM, Ilia Mirkin wrote:

The indirect handle has to come right after the coordinates, so if there
was a sample/bias/depth compare/offset, everything would end up being
shifted by one argument position.

Signed-off-by: Ilia Mirkin 
Cc: mesa-sta...@lists.freedesktop.org
---
 src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 10
++
 1 file changed, 10 insertions(+)

diff --git
a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
index dab3e2d..83154c1 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
@@ -751,6 +751,16 @@ NVC0LoweringPass::handleTEX(TexInstruction *i)
  i->tex.rIndirectSrc = 0;
  i->tex.sIndirectSrc = -1;
   }
+  // Move the indirect reference to right after the coords
+  else if (i->tex.rIndirectSrc >= 0 && chipset >=
NVISA_GM107_CHIPSET) {
+ Value *hnd = i->getIndirectR();
+
+ i->setIndirectR(NULL);
+ i->moveSources(arg, 1);
+ i->setSrc(arg, hnd);
+ i->tex.rIndirectSrc = 0;
+ i->tex.sIndirectSrc = -1;
+  }


This looks (a bit) redundant with the loop above, but texture arguments
are insane, so... :)

I'm going to run piglit.


Confirmed, this fixes a bunch of dEQP tests with indirect samplers.
No regressions with full piglit on GM206.
Thanks!


Reviewed-by: Samuel Pitoiset 






} else
// (nvc0) generate and move the tsc/tic/array source to the front
if (i->tex.target.isArray() || i->tex.rIndirectSrc >= 0 ||
i->tex.sIndirectSrc >= 0) {







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

[Mesa-dev] [Bug 98275] Segmentation fault when using VAAPI acceleration in VLC after installing oibaf's optimized drivers

[bugzilla-daemon]

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

--- Comment #4 from Andy Furniss  ---
(In reply to lesserbrute from comment #0)

> libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/gallium_drv_video.so

If obiaf uses recent mesa then the driver name was changed to
radeonsi_drv_video.so.

Check if that's in in that dir as well and if it is set 

LIBVA_DRIVER_NAME=radeonsi

Maybe gallium_drv_video.so is left over from older install or something.

I know nothing about how obiaf/distro stuff works so may me talking rubbish.

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

[Mesa-dev] [Bug 98275] Segmentation fault when using VAAPI acceleration in VLC after installing oibaf's optimized drivers

[bugzilla-daemon]

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

--- Comment #5 from Andy Furniss  ---
Another random observation = If you are only concerned with
decode/display/deinterlace it's currently best to use vdpau anyway.

There are bugs with vaapi that don't affect vdpau.

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

[Mesa-dev] [PATCH] glsl: Indirect array indexing on non-last SSBO member must fail compilation

[Iago Toral Quiroga]

After the changes in comit 5b2675093e863a52, we moved this check to the
linker, but the spec expects this to be checked at compile-time. There are
dEQP tests that expect an error at compile time and the spec seems to confirm
that expectation:

"Except for the last declared member of a shader storage block (section 4.3.9
 “Interface Blocks”), the size of an array must be declared (explicitly sized)
 before it is indexed with anything other than an integral constant expression.
 The size of any array must be declared before passing it as an argument to a
 function. Violation of any of these rules result in compile-time errors. It
 is legal to declare an array without a size (unsized) and then later
 redeclare the same name as an array of the same type and specify a size, or
 index it only with integral constant expressions (implicitly sized)."

Commit 5b2675093e863a52 tries to take care of the case where we have implicitly
sized arrays in SSBOs and it does so by checking the max_array_access field
in ir_variable during linking. In this patch we change the approach: we look
for indirect access on SSBO arrays, and when we find one, we emit a
compile-time error if the accessed member is not the last in the SSBO
definition.

There is a corner case that the specs do not address directly though and that
dEQP checks for: the case of an unsized array in an SSBO definition that is
not defined last but is never used in the shader code either. The following
dEQP tests expect a compile-time error in this scenario:

dEQP-GLES31.functional.debug.negative_coverage.callbacks.shader.compile_compute_shader
dEQP-GLES31.functional.debug.negative_coverage.get_error.shader.compile_compute_shader
dEQP-GLES31.functional.debug.negative_coverage.log.shader.compile_compute_shader

However, since the unsized array is never used it is never indexed with a
non-constant expression, so by the spec quotation above, it should be valid and
the tests are probably incorrect.
---
 src/compiler/glsl/ast_array_index.cpp | 14 ++
 src/compiler/glsl/link_uniform_blocks.cpp |  8 +---
 2 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/src/compiler/glsl/ast_array_index.cpp 
b/src/compiler/glsl/ast_array_index.cpp
index e29dafb..dfa44b7 100644
--- a/src/compiler/glsl/ast_array_index.cpp
+++ b/src/compiler/glsl/ast_array_index.cpp
@@ -233,6 +233,20 @@ _mesa_ast_array_index_to_hir(void *mem_ctx,
  else if (array->variable_referenced()->data.mode !=
   ir_var_shader_storage) {
 _mesa_glsl_error(&loc, state, "unsized array index must be 
constant");
+ } else {
+/* Unsized array non-constant indexing on SSBO is allowed only for
+ * the last member of the SSBO definition.
+ */
+ir_variable *var = array->variable_referenced();
+const glsl_type *iface_type = var->get_interface_type();
+int field_index = iface_type->field_index(var->name);
+/* Field index can be < 0 for instance arrays */
+if (field_index >= 0 &&
+field_index != (int) iface_type->length - 1) {
+   _mesa_glsl_error(&loc, state, "Indirect access on unsized "
+"array is limited to the last member of "
+"SSBO.");
+}
  }
   } else if (array->type->without_array()->is_interface()
  && ((array->variable_referenced()->data.mode == ir_var_uniform
diff --git a/src/compiler/glsl/link_uniform_blocks.cpp 
b/src/compiler/glsl/link_uniform_blocks.cpp
index 5b0dff6..bb423c5 100644
--- a/src/compiler/glsl/link_uniform_blocks.cpp
+++ b/src/compiler/glsl/link_uniform_blocks.cpp
@@ -150,13 +150,7 @@ private:
*/
   const glsl_type *type_for_size = type;
   if (type->is_unsized_array()) {
- if (!last_field) {
-linker_error(prog, "unsized array `%s' definition: "
- "only last member of a shader storage block "
- "can be defined as unsized array",
- name);
- }
-
+ assert(last_field);
  type_for_size = type->without_array();
   }
 
-- 
2.7.4

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

[Mesa-dev] [Bug 98132] #version 300 es compute shaders should not be possible

[bugzilla-daemon]

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

--- Comment #3 from Iago Toral  ---
(In reply to Iago Toral from comment #2)
> I have sent a couple of patches for review that fix these tests:
> 
> https://lists.freedesktop.org/archives/mesa-dev/2016-October/131942.html

This patch has been reviewed and merged. It fixes the problem with the GLSL
version.

> https://lists.freedesktop.org/archives/mesa-dev/2016-October/131943.html

This second patch addressed a different subcase of the same tests, related to
unsized arrays in SSBOs.

The original patch I sent for this subcase fixed the tests but it had some
issues that I describe in my reply to it in the mailing list. I have sent a new
version of the patch that should be correct:

https://lists.freedesktop.org/archives/mesa-dev/2016-October/132359.html

But this patch won't fix the dEQP tests, because for the reasons I explain in
the patch, I think this dEQP subcase is bogus.

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

Re: [Mesa-dev] [PATCH] glsl: optimize list handling in opt_dead_code

[Jan Ziak]

On Tue Oct 18 09:29:59 UTC 2016, Eero Tamminen wrote:
> On 18.10.2016 01:07, Jan Ziak wrote:
>> - The total number of executed instructions goes down from 64.184 to 63.797
>>   giga-instructions when Mesa is compiled with "gcc -O0 ..."
>
>Please don't do performance related decisions based on data from
>compiling code with optimizations disabled.  Use -O2 or -O3 (or even
>better, check both).

Options -O2 and -O3 interfere with profiling tools.

I will try using -Og the next time.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glsl: optimize list handling in opt_dead_code

[Nicolai Hähnle]

On 18.10.2016 15:07, Jan Ziak wrote:

On Tue Oct 18 09:29:59 UTC 2016, Eero Tamminen wrote:

On 18.10.2016 01:07, Jan Ziak wrote:

- The total number of executed instructions goes down from 64.184 to 63.797
  giga-instructions when Mesa is compiled with "gcc -O0 ..."


Please don't do performance related decisions based on data from
compiling code with optimizations disabled.  Use -O2 or -O3 (or even
better, check both).


Options -O2 and -O3 interfere with profiling tools.

>

I will try using -Og the next time.


Just stop and use proper profiling tools like perf that can work with 
optimized tools. You may have to compile with -fno-omit-frame-pointer, 
but anything more than that is going to distort your measurement results 
so much that they're worthless.


Nicolai


___
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] glsl: optimize list handling in opt_dead_code

[Jan Ziak]

On Tue, Oct 18, 2016 at 3:12 PM, Nicolai Hähnle  wrote:
> On 18.10.2016 15:07, Jan Ziak wrote:
>>
>> On Tue Oct 18 09:29:59 UTC 2016, Eero Tamminen wrote:
>>>
>>> On 18.10.2016 01:07, Jan Ziak wrote:

 - The total number of executed instructions goes down from 64.184 to
 63.797
   giga-instructions when Mesa is compiled with "gcc -O0 ..."
>>>
>>>
>>> Please don't do performance related decisions based on data from
>>> compiling code with optimizations disabled.  Use -O2 or -O3 (or even
>>> better, check both).
>>
>>
>> Options -O2 and -O3 interfere with profiling tools.
>
>>
>>
>> I will try using -Og the next time.
>
>
> Just stop and use proper profiling tools like perf that can work with
> optimized tools. You may have to compile with -fno-omit-frame-pointer, but
> anything more than that is going to distort your measurement results so much
> that they're worthless.
>
> Nicolai

The function from -O0, -O1, -O2 to number-of-instructions (or to
number-of-cycles) is in the vast majority of cases a monotonically
decreasing function.

Are you saying that this rule does not hold in the case of this patch?

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

[Mesa-dev] [Bug 98271] [radeonsi]Playing videos with vdpau or vaapi hardware acceleration crashes my pc

[bugzilla-daemon]

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

--- Comment #16 from John  ---
I actually had to use -vo vdpau when I tried against mesa 11.0 (somehow mpv
didn't work with ogl-hq on that version) so I know it is problematic.

But the bug you link is still interesting to me, as I was wondering why my
movies looked aliased lately, so thanks for that!

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

[Mesa-dev] [Bug 98271] [radeonsi]Playing videos with vdpau or vaapi hardware acceleration crashes my pc

[bugzilla-daemon]

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

--- Comment #15 from Andy Furniss  ---
(In reply to John from comment #10)
> Correct, I have an mpv config with:
> 
> hwdec=vdpau
> hwdec-codecs=all
> vo=opengl-hq
> 
> The rest shouldn't matter I believe.

If your mpv is not too old then there is an issue with vo=opengl-hq + hwdec
that means you only get half vrez.

May or may not affect this issue - I don't know.

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

Do you crash with vo=vdpau with radeon?

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

Re: [Mesa-dev] [PATCH] gallivm: Use native packs and unpacks for the lerps

[Jose Fonseca]

On 18/10/16 02:38, srol...@vmware.com wrote:

From: Roland Scheidegger 

For the texturing packs, things looked pretty terrible. For every
lerp, we were repacking the values, and while those look sort of cheap
with 128bit, with 256bit we end up with 2 of them instead of just 1 but
worse, plus 2 extracts too (the unpack, however, works fine with a
single instruction, albeit only with llvm 3.8 - the vpmovzxbw).

Ideally we'd use more clever pack for llvmpipe backend conversion too
since we actually use the "wrong" shuffle (which is more work) when doing
the fs twiddle just so we end up with the wrong order for being able to
do native pack when converting from 2x8f -> 1x16b. But this requires some
refactoring, since the untwiddle is separate from conversion.

This is only used for avx2 256bit pack/unpack for now.

Improves openarena scores by 8% or so, though overall it's still pretty
disappointing how much faster 256bit vectors are even with avx2 (or
rather, aren't...). And, of course, eliminating the needless
packs/unpacks in the first place would eliminate most of that advantage
(not quite all) from this patch.
---
 src/gallium/auxiliary/gallivm/lp_bld_arit.c |  14 +--
 src/gallium/auxiliary/gallivm/lp_bld_pack.c | 139 ++--
 src/gallium/auxiliary/gallivm/lp_bld_pack.h |  16 
 3 files changed, 156 insertions(+), 13 deletions(-)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_arit.c 
b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
index f5cacc4..3ea0734 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_arit.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
@@ -1046,14 +1046,14 @@ lp_build_mul(struct lp_build_context *bld,
   struct lp_type wide_type = lp_wider_type(type);
   LLVMValueRef al, ah, bl, bh, abl, abh, ab;

-  lp_build_unpack2(bld->gallivm, type, wide_type, a, &al, &ah);
-  lp_build_unpack2(bld->gallivm, type, wide_type, b, &bl, &bh);
+  lp_build_unpack2_native(bld->gallivm, type, wide_type, a, &al, &ah);
+  lp_build_unpack2_native(bld->gallivm, type, wide_type, b, &bl, &bh);

   /* PMULLW, PSRLW, PADDW */
   abl = lp_build_mul_norm(bld->gallivm, wide_type, al, bl);
   abh = lp_build_mul_norm(bld->gallivm, wide_type, ah, bh);

-  ab = lp_build_pack2(bld->gallivm, wide_type, type, abl, abh);
+  ab = lp_build_pack2_native(bld->gallivm, wide_type, type, abl, abh);

   return ab;
}
@@ -1350,9 +1350,9 @@ lp_build_lerp(struct lp_build_context *bld,

   lp_build_context_init(&wide_bld, bld->gallivm, wide_type);

-  lp_build_unpack2(bld->gallivm, type, wide_type, x,  &xl,  &xh);
-  lp_build_unpack2(bld->gallivm, type, wide_type, v0, &v0l, &v0h);
-  lp_build_unpack2(bld->gallivm, type, wide_type, v1, &v1l, &v1h);
+  lp_build_unpack2_native(bld->gallivm, type, wide_type, x,  &xl,  &xh);
+  lp_build_unpack2_native(bld->gallivm, type, wide_type, v0, &v0l, &v0h);
+  lp_build_unpack2_native(bld->gallivm, type, wide_type, v1, &v1l, &v1h);

   /*
* Lerp both halves.
@@ -1363,7 +1363,7 @@ lp_build_lerp(struct lp_build_context *bld,
   resl = lp_build_lerp_simple(&wide_bld, xl, v0l, v1l, flags);
   resh = lp_build_lerp_simple(&wide_bld, xh, v0h, v1h, flags);

-  res = lp_build_pack2(bld->gallivm, wide_type, type, resl, resh);
+  res = lp_build_pack2_native(bld->gallivm, wide_type, type, resl, resh);
} else {
   res = lp_build_lerp_simple(bld, x, v0, v1, flags);
}
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_pack.c 
b/src/gallium/auxiliary/gallivm/lp_bld_pack.c
index b0e76e6..e8d4fcd 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_pack.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_pack.c
@@ -346,10 +346,10 @@ lp_build_interleave2(struct gallivm_state *gallivm,
  */
 LLVMValueRef
 lp_build_interleave2_half(struct gallivm_state *gallivm,
- struct lp_type type,
- LLVMValueRef a,
- LLVMValueRef b,
- unsigned lo_hi)
+  struct lp_type type,
+  LLVMValueRef a,
+  LLVMValueRef b,
+  unsigned lo_hi)
 {
if (type.length * type.width == 256) {
   LLVMValueRef shuffle = lp_build_const_unpack_shuffle_half(gallivm, 
type.length, lo_hi);
@@ -359,11 +359,13 @@ lp_build_interleave2_half(struct gallivm_state *gallivm,
}
 }

+
 /**
  * Double the bit width.
  *
  * This will only change the number of bits the values are represented, not the
  * values themselves.
+ *
  */
 void
 lp_build_unpack2(struct gallivm_state *gallivm,
@@ -394,6 +396,65 @@ lp_build_unpack2(struct gallivm_state *gallivm,
 #ifdef PIPE_ARCH_LITTLE_ENDIAN
*dst_lo = lp_build_interleave2(gallivm, src_type, src, msb, 0);
*dst_hi = lp_build_interleave2(gallivm, src_type, src, msb, 1);
+
+#else
+   *dst_lo = lp_build_interleave2(gallivm, src_type, msb, src, 0);
+   *dst_hi = lp_build_interleave2(gallivm, src_type, msb, src,

[Mesa-dev] [PATCH] glsl: optimize list handling in opt_dead_code

[Jan Ziak]

This patch replaces the ir_variable_refcount_entry's linked-list
with an array-list.

The array-list has local storage which does not require ANY additional
allocations if the list has small number of elements. The size of this
storage is configurable for each variable.

Benchmark results for "./run -1 shaders" from shader-db[1]:

- The total number of executed instructions goes down from 64.184 to 63.797
  giga-instructions when Mesa is compiled with "gcc -O0 ..."
- In the call tree starting at function do_dead_code():
  - the number of calls to malloc() is reduced by about 10%
  - the number of calls to free() is reduced by about 30%

The layout of the source code in the new file fast_list.h has been
formatted by NetBeans.

[1] git://anongit.freedesktop.org/mesa/shader-db

Signed-off-by: Jan Ziak (http://atom-symbol.net) <0xe2.0x9a.0...@gmail.com>
---
 src/compiler/glsl/ir_variable_refcount.cpp |  14 +-
 src/compiler/glsl/ir_variable_refcount.h   |   8 +-
 src/compiler/glsl/opt_dead_code.cpp|  19 +--
 src/util/fast_list.h   | 215 +
 4 files changed, 224 insertions(+), 32 deletions(-)

diff --git a/src/compiler/glsl/ir_variable_refcount.cpp 
b/src/compiler/glsl/ir_variable_refcount.cpp
index 8306be1..94d6edc 100644
--- a/src/compiler/glsl/ir_variable_refcount.cpp
+++ b/src/compiler/glsl/ir_variable_refcount.cpp
@@ -46,15 +46,6 @@ static void
 free_entry(struct hash_entry *entry)
 {
ir_variable_refcount_entry *ivre = (ir_variable_refcount_entry *) 
entry->data;
-
-   /* Free assignment list */
-   exec_node *n;
-   while ((n = ivre->assign_list.pop_head()) != NULL) {
-  struct assignment_entry *assignment_entry =
- exec_node_data(struct assignment_entry, n, link);
-  free(assignment_entry);
-   }
-
delete ivre;
 }
 
@@ -142,10 +133,7 @@ ir_variable_refcount_visitor::visit_leave(ir_assignment 
*ir)
*/
   assert(entry->referenced_count >= entry->assigned_count);
   if (entry->referenced_count == entry->assigned_count) {
- struct assignment_entry *assignment_entry =
-(struct assignment_entry *)calloc(1, sizeof(*assignment_entry));
- assignment_entry->assign = ir;
- entry->assign_list.push_head(&assignment_entry->link);
+ entry->assign_list.add(ir);
   }
}
 
diff --git a/src/compiler/glsl/ir_variable_refcount.h 
b/src/compiler/glsl/ir_variable_refcount.h
index 08a11c0..c3ec5fe 100644
--- a/src/compiler/glsl/ir_variable_refcount.h
+++ b/src/compiler/glsl/ir_variable_refcount.h
@@ -32,11 +32,7 @@
 #include "ir.h"
 #include "ir_visitor.h"
 #include "compiler/glsl_types.h"
-
-struct assignment_entry {
-   exec_node link;
-   ir_assignment *assign;
-};
+#include "util/fast_list.h"
 
 class ir_variable_refcount_entry
 {
@@ -50,7 +46,7 @@ public:
 * This is intended to be used for dead code optimisation and may
 * not be a complete list.
 */
-   exec_list assign_list;
+   arraylist assign_list;
 
/** Number of times the variable is referenced, including assignments. */
unsigned referenced_count;
diff --git a/src/compiler/glsl/opt_dead_code.cpp 
b/src/compiler/glsl/opt_dead_code.cpp
index 75e668a..8e395697 100644
--- a/src/compiler/glsl/opt_dead_code.cpp
+++ b/src/compiler/glsl/opt_dead_code.cpp
@@ -52,7 +52,7 @@ do_dead_code(exec_list *instructions, bool 
uniform_locations_assigned)
 
struct hash_entry *e;
hash_table_foreach(v.ht, e) {
-  ir_variable_refcount_entry *entry = (ir_variable_refcount_entry 
*)e->data;
+  ir_variable_refcount_entry *const entry = (ir_variable_refcount_entry 
*)e->data;
 
   /* Since each assignment is a reference, the refereneced count must be
* greater than or equal to the assignment count.  If they are equal,
@@ -89,7 +89,7 @@ do_dead_code(exec_list *instructions, bool 
uniform_locations_assigned)
   if (entry->var->data.always_active_io)
  continue;
 
-  if (!entry->assign_list.is_empty()) {
+  if (!entry->assign_list.empty()) {
 /* Remove all the dead assignments to the variable we found.
  * Don't do so if it's a shader or function output, though.
  */
@@ -98,26 +98,19 @@ do_dead_code(exec_list *instructions, bool 
uniform_locations_assigned)
  entry->var->data.mode != ir_var_shader_out &&
  entry->var->data.mode != ir_var_shader_storage) {
 
-while (!entry->assign_list.is_empty()) {
-   struct assignment_entry *assignment_entry =
-  exec_node_data(struct assignment_entry,
- entry->assign_list.get_head_raw(), link);
-
-  assignment_entry->assign->remove();
-
+for (ir_assignment *assign : entry->assign_list) {
+  assign->remove();
   if (debug) {
  printf("Removed assignment to %s@%p\n",
 entry->var->name, (void *) entry->var);
}
-
-   assign

Re: [Mesa-dev] [PATCH] glsl: optimize list handling in opt_dead_code

[Emil Velikov]

On 17 October 2016 at 23:07, Jan Ziak <0xe2.0x9a.0...@gmail.com> wrote:

> -   exec_list assign_list;
> +   arraylist assign_list;
>
Just an FYI - when people started using C++ for glsl there was an
agreement that templating is not to be used.

Not sure if it still holds true, nowadays.
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 98271] [radeonsi]Playing videos with vdpau or vaapi hardware acceleration crashes my pc

[bugzilla-daemon]

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

--- Comment #17 from Alex Deucher  ---
amdgpu does not support UVD or VCE on SI parts yet.

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

[Mesa-dev] [Bug 98271] [radeonsi]Playing videos with vdpau or vaapi hardware acceleration crashes my pc

[bugzilla-daemon]

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

--- Comment #18 from John  ---
> amdgpu does not support UVD or VCE on SI parts yet.
oh, I should have verified in dmesg.
Sorry about that.

What should I try next?

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

Re: [Mesa-dev] [PATCH] glsl: optimize list handling in opt_dead_code

[Jan Ziak]

On Tue, Oct 18, 2016 at 3:32 PM, Emil Velikov  wrote:
> On 17 October 2016 at 23:07, Jan Ziak <0xe2.0x9a.0...@gmail.com> wrote:
>
>> -   exec_list assign_list;
>> +   arraylist assign_list;
>>
> Just an FYI - when people started using C++ for glsl there was an
> agreement that templating is not to be used.

In my opinion, avoiding templates for the very basic datatypes (such
as lists, sets and maps) in a language supporting templates is highly
unusual and counter-productive.

I can agree with Mesa not wanting to use templates in other cases.

> Not sure if it still holds true, nowadays.
> Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/va: disable cabac for h264 baseline profile

[Andy Furniss]

Andy Furniss wrote:

Christian König wrote:

Am 18.10.2016 um 11:19 schrieb Andy Furniss:

boyuan.zh...@amd.com wrote:

From: Boyuan Zhang 

cabac is only supported in the h264 main and higher profiles


So shouldn't there be code allows it if the user space doesn't
set baseline?

I don't know how in gstreamer as it seems to try to use b-frames
if you use other than baseline which doesn't work.

With avconv it is possible to call main/high and set b-frames to 0.

I know it's technically correct spec wise, but seems a shame as it
costs a fair bit in "free" efficiency.

On Windows the raptor game recording app produces files flagged as
high with cabac - but without b-frames.


The problem is that it can easily break decoders. CABAC is simply not
allowed in a stream flagged as baseline compliant.


But with ffmpeg/avconv I can make a stream flagged as main/high even
if it's really baseline + CABAC. I guess Windows may vary but the test
I did seems to take this pragmatic approach, as it seems do other h/w
encoders eg. smartphone output.


It's a pity that we don't support B-frames any more.


Anymore? Now I am curious, seems to work with omx (cqp single instance)



With that in place
we could easily advertise support for mainline profile.


MBAFF/PAFF?


Sorry if that came over as being pedantic, silly as I think pragmatism
is the way to go and I know intel advertise main/high, but doubt they
do interlaced.

In fact vce vaapi is currently advertising them as well (I did mention
it in some thread). Good for letting ffmpeg flag as such while not using
b-frames, not so good for gstreamer as they have changed the default to
high so old command lines will not explicitly fail, but will produce junk.

I see va.h has a cabac switch and gstreamer exposes it - though it's not
read by the driver. Maybe if that were hooked up then users could turn
it on and profit :-).





Christian.




Signed-off-by: Boyuan Zhang 
---
  src/gallium/state_trackers/va/picture.c | 1 -
  1 file changed, 1 deletion(-)

diff --git a/src/gallium/state_trackers/va/picture.c
b/src/gallium/state_trackers/va/picture.c
index eae5dc4..db08a3c 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -110,7 +110,6 @@ getEncParamPreset(vlVaContext *context)
 context->desc.h264enc.motion_est.enc_ime2_search_range_y =
0x0004;

 //pic control preset
-   context->desc.h264enc.pic_ctrl.enc_cabac_enable = 0x0001;
 context->desc.h264enc.pic_ctrl.enc_constraint_set_flags =
0x0040;

 //rate control



___
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] glsl: optimize list handling in opt_dead_code

[Jan Ziak]

Hi Michael,

thanks for the suggestions about code formatting. I formatted the
whole fast_list.h file in the Netbeans editor and uploaded a new
revision of the patch.

Jan

On Tue, Oct 18, 2016 at 1:42 PM, Michael Schellenberger Costa
 wrote:
> Hi Jan,
>
> On 18.10.2016 00:07, Jan Ziak wrote:
>>
>> This patch replaces the ir_variable_refcount_entry's linked-list
>> with an array-list.
>>
>> The array-list has local storage which does not require ANY additional
>> allocations if the list has small number of elements. The size of this
>> storage is configurable for each variable.
>>
>> Benchmark results for "./run -1 shaders" from shader-db[1]:
>>
>> - The total number of executed instructions goes down from 64.184 to
>> 63.797
>>giga-instructions when Mesa is compiled with "gcc -O0 ..."
>> - In the call tree starting at function do_dead_code():
>>- the number of calls to malloc() is reduced by about 10%
>>- the number of calls to free() is reduced by about 30%
>>
>> [1] git://anongit.freedesktop.org/mesa/shader-db
>>
>> Signed-off-by: Jan Ziak (http://atom-symbol.net)
>> <0xe2.0x9a.0...@gmail.com>
>> ---
>>   src/compiler/glsl/ir_variable_refcount.cpp |  14 +--
>>   src/compiler/glsl/ir_variable_refcount.h   |   8 +-
>>   src/compiler/glsl/opt_dead_code.cpp|  19 ++--
>>   src/util/fast_list.h   | 167
>> +
>>   4 files changed, 176 insertions(+), 32 deletions(-)
>>
>> diff --git a/src/compiler/glsl/ir_variable_refcount.cpp
>> b/src/compiler/glsl/ir_variable_refcount.cpp
>> index 8306be1..94d6edc 100644
>> --- a/src/compiler/glsl/ir_variable_refcount.cpp
>> +++ b/src/compiler/glsl/ir_variable_refcount.cpp
>> @@ -46,15 +46,6 @@ static void
>>   free_entry(struct hash_entry *entry)
>>   {
>>  ir_variable_refcount_entry *ivre = (ir_variable_refcount_entry *)
>> entry->data;
>> -
>> -   /* Free assignment list */
>> -   exec_node *n;
>> -   while ((n = ivre->assign_list.pop_head()) != NULL) {
>> -  struct assignment_entry *assignment_entry =
>> - exec_node_data(struct assignment_entry, n, link);
>> -  free(assignment_entry);
>> -   }
>> -
>>  delete ivre;
>>   }
>>   @@ -142,10 +133,7 @@
>> ir_variable_refcount_visitor::visit_leave(ir_assignment *ir)
>>  */
>> assert(entry->referenced_count >= entry->assigned_count);
>> if (entry->referenced_count == entry->assigned_count) {
>> - struct assignment_entry *assignment_entry =
>> -(struct assignment_entry *)calloc(1,
>> sizeof(*assignment_entry));
>> - assignment_entry->assign = ir;
>> - entry->assign_list.push_head(&assignment_entry->link);
>> + entry->assign_list.add(ir);
>> }
>>  }
>>   diff --git a/src/compiler/glsl/ir_variable_refcount.h
>> b/src/compiler/glsl/ir_variable_refcount.h
>> index 08a11c0..c3ec5fe 100644
>> --- a/src/compiler/glsl/ir_variable_refcount.h
>> +++ b/src/compiler/glsl/ir_variable_refcount.h
>> @@ -32,11 +32,7 @@
>>   #include "ir.h"
>>   #include "ir_visitor.h"
>>   #include "compiler/glsl_types.h"
>> -
>> -struct assignment_entry {
>> -   exec_node link;
>> -   ir_assignment *assign;
>> -};
>> +#include "util/fast_list.h"
>> class ir_variable_refcount_entry
>>   {
>> @@ -50,7 +46,7 @@ public:
>>   * This is intended to be used for dead code optimisation and may
>>   * not be a complete list.
>>   */
>> -   exec_list assign_list;
>> +   arraylist assign_list;
>>/** Number of times the variable is referenced, including
>> assignments. */
>>  unsigned referenced_count;
>> diff --git a/src/compiler/glsl/opt_dead_code.cpp
>> b/src/compiler/glsl/opt_dead_code.cpp
>> index 75e668a..06e8c3d 100644
>> --- a/src/compiler/glsl/opt_dead_code.cpp
>> +++ b/src/compiler/glsl/opt_dead_code.cpp
>> @@ -52,7 +52,7 @@ do_dead_code(exec_list *instructions, bool
>> uniform_locations_assigned)
>>struct hash_entry *e;
>>  hash_table_foreach(v.ht, e) {
>> -  ir_variable_refcount_entry *entry = (ir_variable_refcount_entry
>> *)e->data;
>> +  ir_variable_refcount_entry *const entry =
>> (ir_variable_refcount_entry *)e->data;
>>   /* Since each assignment is a reference, the refereneced count
>> must be
>>  * greater than or equal to the assignment count.  If they are
>> equal,
>> @@ -89,7 +89,7 @@ do_dead_code(exec_list *instructions, bool
>> uniform_locations_assigned)
>> if (entry->var->data.always_active_io)
>>continue;
>>   -  if (!entry->assign_list.is_empty()) {
>> +  if (!entry->assign_list.empty()) {
>>  /* Remove all the dead assignments to the variable we found.
>>   * Don't do so if it's a shader or function output, though.
>>   */
>> @@ -98,26 +98,19 @@ do_dead_code(exec_list *instructions, bool
>> uniform_locations_assigned)
>>entry->var->data.mode != ir_var_shader_out &&
>>entry->var->data.mode != ir_var_shader_storage) {
>>   - 

[Mesa-dev] [PATCH] configure.ac: don't require DRM and GBM for surfaceless egl platform

[Marek Olšák]

From: Deepak Sharma 

This allows building radeonsi driver for surfaceless platform.
If we get any other requirements, we'll fix them in the function.
Removing the function isn't a solution.

v2: cosmetic changes - Marek

Signed-off-by: Deepak Sharma  (v1)
Signed-off-by: Marek Olšák 
---
 configure.ac | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/configure.ac b/configure.ac
index b414edd..30cac19 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2345,30 +2345,33 @@ gallium_require_llvm() {
 esac
 fi
 }
 
 gallium_require_drm_loader() {
 if test "x$need_pci_id$have_pci_id" = xyesno; then
 AC_MSG_ERROR([Gallium drm loader requires libudev >= $LIBUDEV_REQUIRED 
or sysfs])
 fi
 }
 
-dnl This is for Glamor. Skip this if OpenGL is disabled.
-require_egl_drm() {
+# Check valid combinations of EGL platforms with GBM.
+check_glamor_requirements() {
 if test "x$enable_opengl" = xno; then
 return 0
 fi
 
 case "$with_egl_platforms" in
+surfaceless)
+return 0 # the user doesn't use Glamor and GBM.
+;;
 *drm*)
 ;;
- *)
+*)
 AC_MSG_ERROR([--with-egl-platforms=drm is required to build the $1 
driver.])
 ;;
 esac
 if test "x$enable_gbm" != xyes; then
 AC_MSG_ERROR([--enable-gbm is required to build the $1 driver.])
 fi
 }
 
 radeon_llvm_check() {
 if test ${LLVM_VERSION_INT} -lt 307; then
@@ -2482,21 +2485,21 @@ if test -n "$with_gallium_drivers"; then
 LLVM_COMPONENTS="${LLVM_COMPONENTS} bitreader asmparser"
 fi
 ;;
 xradeonsi)
 HAVE_GALLIUM_RADEONSI=yes
 PKG_CHECK_MODULES([RADEON], [libdrm_radeon >= 
$LIBDRM_RADEON_REQUIRED])
 PKG_CHECK_MODULES([AMDGPU], [libdrm_amdgpu >= 
$LIBDRM_AMDGPU_REQUIRED])
 gallium_require_drm "radeonsi"
 gallium_require_drm_loader
 radeon_gallium_llvm_check "radeonsi" "3" "6" "0"
-require_egl_drm "radeonsi"
+check_glamor_requirements "radeonsi"
 ;;
 xnouveau)
 HAVE_GALLIUM_NOUVEAU=yes
 PKG_CHECK_MODULES([NOUVEAU], [libdrm_nouveau >= 
$LIBDRM_NOUVEAU_REQUIRED])
 gallium_require_drm "nouveau"
 gallium_require_drm_loader
 ;;
 xfreedreno)
 HAVE_GALLIUM_FREEDRENO=yes
 PKG_CHECK_MODULES([FREEDRENO], [libdrm_freedreno >= 
$LIBDRM_FREEDRENO_REQUIRED])
@@ -2537,21 +2540,21 @@ if test -n "$with_gallium_drivers"; then
 
 PKG_CHECK_MODULES([SIMPENROSE], [simpenrose],
   [USE_VC4_SIMULATOR=yes;
DEFINES="$DEFINES -DUSE_VC4_SIMULATOR"],
   [USE_VC4_SIMULATOR=no])
 ;;
 xvirgl)
 HAVE_GALLIUM_VIRGL=yes
 gallium_require_drm "virgl"
 gallium_require_drm_loader
-require_egl_drm "virgl"
+check_glamor_requirements "virgl"
 ;;
 *)
 AC_MSG_ERROR([Unknown Gallium driver: $driver])
 ;;
 esac
 done
 fi
 
 if test "x$HAVE_RADEON_VULKAN" = "xyes"; then
 radeon_llvm_check "radv" "3" "9" "0"
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH] glsl: optimize list handling in opt_dead_code

[Eero Tamminen]

Hi,

On 18.10.2016 16:25, Jan Ziak wrote:

On Tue, Oct 18, 2016 at 3:12 PM, Nicolai Hähnle  wrote:

On 18.10.2016 15:07, Jan Ziak wrote:

On Tue Oct 18 09:29:59 UTC 2016, Eero Tamminen wrote:

On 18.10.2016 01:07, Jan Ziak wrote:

- The total number of executed instructions goes down from 64.184 to
63.797
  giga-instructions when Mesa is compiled with "gcc -O0 ..."


Please don't do performance related decisions based on data from
compiling code with optimizations disabled.  Use -O2 or -O3 (or even
better, check both).


Options -O2 and -O3 interfere with profiling tools.

I will try using -Og the next time.


Just stop and use proper profiling tools like perf that can work with
optimized tools.


Valgrind/callgrind/cachegrind works also fine with optimized binaries.

All profiling tools lie, at least a bit. It's better to know their 
strengths and weaknesses so that one knows which ones complement each 
other. Perf is e.g. good at finding hotspots, Valgrind (callgrind) is 
more reliable in telling how they get called.


One may also needs GCC version from this decade.  Really old GCC 
versions didn't inlude all debug info needed for debugging optimized 
binaries.




You may have to compile with -fno-omit-frame-pointer, but
anything more than that is going to distort your measurement results so much
that they're worthless.

>

The function from -O0, -O1, -O2 to number-of-instructions (or to
number-of-cycles) is in the vast majority of cases a monotonically
decreasing function.

>
> Are you saying that this rule does not hold in the case of this patch?

-O1 puts variables into registers instead of using them directly from 
stack like -O0 does.  -O3 adds things like inlining and aliasing 
analysis.  Only higher optimization levels do dead code analysis. 
Whether these increase or decrease code side, depends on the code.



- Eero

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

[Mesa-dev] [Bug 98308] llvmpipe crashes with glxgears

[bugzilla-daemon]

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

Bug ID: 98308
   Summary: llvmpipe crashes with glxgears
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: marvi...@gmx.de
QA Contact: mesa-dev@lists.freedesktop.org

llvm 3.8.1 on openSUSE, Mesa from today:

# LIBGL_ALWAYS_SOFTWARE=1 gdb glxgears
GNU gdb (GDB; openSUSE Tumbleweed) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-suse-linux".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from glxgears...(no debugging symbols found)...done.
Missing separate debuginfos, use: zypper install
Mesa-demo-x-debuginfo-8.3.0-1.4.x86_64
(gdb) run
Starting program: /usr/bin/glxgears 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7fffe342d700 (LWP 539)]
[New Thread 0x7fffe2c2c700 (LWP 540)]
[New Thread 0x7fffe242b700 (LWP 541)]
[New Thread 0x7fffe1c2a700 (LWP 542)]

Thread 2 "llvmpipe-0" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe342d700 (LWP 539)]
lp_scene_begin_rasterization (scene=scene@entry=0x0) at lp_scene.c:157
157 lp_scene.c: Datei oder Verzeichnis nicht gefunden.
(gdb) bt full
#0  lp_scene_begin_rasterization (scene=scene@entry=0x0) at lp_scene.c:157
fb = 0x2f8
i = 0
#1  0x73b98b92 in lp_rast_begin.isra.10 (scene=) at
lp_rast.c:71
No locals.
#2  thread_function.lto_priv.937 (init_data=0x7438a018) at lp_rast.c:815
task = 0x7438a018
rast = 0x7438a000
thread_name = "llvmpipe-0\000\343\377\177\000"
fpstate = 
#3  0x73b7c597 in impl_thrd_routine.lto_priv.935.lto_priv () at
lp_rast.c:531
funcs_linear_aniso = {relative_level = 0x739ace80
, 
  filter = 0x739b3f00 }
lp_rast_32_tri_tab = {0, 18, 19, 20, 21, 22, 23, 24, 25}
states = {0x73d0efc3 "FLUSHED", 0x73d0f0c0 "CLEARED",
0x73d0f0c8 "ACTIVE "}
lp_rast_tri_tab = {0, 2, 3, 4, 5, 6, 7, 8, 9}
funcs_linear = {relative_level = 0x739ace00
, filter = 0x739afbe0
}
face_array = {{4, 5, 2, 3}, {5, 4, 2, 3}, {1, 0, 5, 4}, {1, 0, 4, 5},
{1, 0, 2, 3}, {0, 1, 2, 3}}
funcs_nearest = {relative_level = 0x739acd40
, filter = 0x739ae540
}
dispatch = {0x73b94240 , 0x73b93d20
, 0x73b89be0 , 
  0x73b88e60 , 0x73b881c0
, 0x73b87520 , 
  0x73b868a0 , 0x73b85c20
, 0x73b84f80 , 
  0x73b842e0 , 0x73b88e20
, 0x73b88e40 , 
  0x73b881a0 , 0x73b93740
, 0x73b93cc0 , 
  0x73b7b280 , 0x73b7c4a0
, 0x73b7aa20 , 
  0x73b83780 , 0x73b82ac0
, 0x73b81ec0 , 
  0x73b81300 , 0x73b804c0
, 0x73b7f8e0 , 
  0x73b7ece0 , 0x73b7e0e0
, 0x73b8a7a0 , 
  0x73b8a9c0 , 0x73b81080
}
funcs_none_no_filter_select = {relative_level = 0x739acd20
, 
  filter = 0x739acc40
}
funcs_none = {relative_level = 0x739acd00
, filter = 0x739ae220
}
weightLut.lto_priv.1689 = 0x0
#4  0x76d07454 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#5  0x770063ff in clone () from /lib64/libc.so.6
No sym

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

Re: [Mesa-dev] [PATCH] configure.ac: don't require DRM and GBM for surfaceless egl platform

[Emil Velikov]

On 17 October 2016 at 19:07, Marek Olšák  wrote:
> On Mon, Oct 17, 2016 at 7:10 PM, Emil Velikov  
> wrote:
>> On 17 October 2016 at 17:47, Marek Olšák  wrote:
>>> From: Deepak Sharma 
>>>
>>> This allows building radeonsi driver for surfaceless platform.
>>>
>>> Signed-off-by: Deepak Sharma 
>>> Signed-off-by: Marek Olšák 
>> As I "predicted" from the beginning adding require_egl_drm() is a hack
>> which will inspire even more hacks.
>>
>> For example 98cebc913cd7ad07ce9699b5f63d72fe3969c851 and now this one.
>> Please _drop_ these all together.
>>
>> I realise what you're trying to be extra careful on behalf of the
>> user, but this is not the way to do it. Let's drop the "interesting"
>> enable-gbm auto-detection enabling it by default or toggling it on
>> supported platforms - !cygwin/windows and add the drm egl-platform if
>> gbm is enabled. This way your worries will be resolved, plus things
>> will be shorter and easier to untangle :-)
>
> While I understand where your criticism is coming from, this is not a
> hack to me. It's really just an improvement to already-good code. ;)
>
As a person who's been staring at this and similar pieces for far too
long, I can guarantee you it _is_ a hack. If you want to call it any
other way, so be it.
The rule is that you cannot enforce runtime specifics at compile time.
Similar to the LLVM topic.

NACK

If you want to go forward proceed with the earlier suggestion or
propose an alternative one, please ?

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

Re: [Mesa-dev] [PATCH v3 25/25] configure.ac: Add required LLVM versions to the top

[Emil Velikov]

On 17 October 2016 at 08:56, Michel Dänzer  wrote:
> On 14/10/16 07:02 PM, Emil Velikov wrote:
>> On 14 October 2016 at 09:45, Michel Dänzer  wrote:
>>> On 14/10/16 05:14 PM, Emil Velikov wrote:
 On 14 October 2016 at 01:45, Michel Dänzer  wrote:
> On 13/10/16 07:14 PM, Emil Velikov wrote:
>> On 13 October 2016 at 04:07, Michel Dänzer  wrote:
>>> On 13/10/16 03:37 AM, Tobias Droste wrote:
 Am Mittwoch, 12. Oktober 2016, 11:53:50 CEST schrieb Emil Velikov:
>>
>> +LLVM_VERSION_REQUIRED_OPENCL=3.6.0
>> +LLVM_VERSION_REQUIRED_R600=3.6.0
>> +LLVM_VERSION_REQUIRED_RADEONSI=3.6.0
>
> There's a small related gotcha: as-is at build time we get the
> different codepaths thus, as people build against shared LLVM (hello
> Archlinux, I'm looking at you) and update their LLVM without
> rebuilding mesa (Arch I'm looking at you again) things go funny.
>>>
>>> What exactly happened there? LLVM upstream generates shared libraries
>>> named libLLVM-..so*, so it shouldn't be possible for a
>>> simple LLVM package update to break Mesa, unless Arch did something
>>> really stupid.
>>>
>> The issue is not specific to Arch, but anyone who links against shared 
>> LLVM.
>>
>> Here is another take on it:
>> At least swr and r600/radeonsi depend at _build_ time on the _patch_
>> version of LLVM. The latter of which is not part of the DSO name. Thus
>> at runtime as you change your LLVM (3.9.x>3.9.y) you'll execute the
>> "3.9.x" codepath even though you are be using "3.9.y" LLVM.
>
> That should be fine, since 3.9.y is backwards compatible with 3.9.x.
>
> Debian doesn't automatically recompile Mesa in such cases either, and I
> haven't seen any problems there because of that.
>
> So, what exactly was the problem?
>
 Just grep through for LLVM_.*PATCH and you'll see it. Portable code
 should not check that at compile time.
>>>
>>> This is getting a bit annoying... Please explicitly say what you think
>>> is a problem, especially after being asked to do so multiple times.
>>>
>> AFAICT picking on like an old bat can be annoying, so I've tried to avoid it.
>> Regardless, as per your request:
>
> Thank you.
>
>
>> * src/gallium/drivers/radeon/r600_pipe_common.c
>> No actual bug, yet misleading.
>
> If you want to call it that... I'd say this can be useful for detecting
> the problems you're thinking of. :)
>
>
On the contrary, for example:
Building against shared llvm 3.6.0, later one updates to 3.6.2.

Mesa is not rebuild, thus the above message says "3.6.0" and they
don't get any tessellation.
Then they check with their package/install - Why is Mesa showing
3.6.0, I have 3.6.2 installed. Should I reinstall LLVM, are there any
parts of 3.6.0 still around ?"

This in itself is because people don't expect that one should rebuild
package X when one its dependencies gets a patch version change.

>> * src/gallium/drivers/radeonsi/si_pipe.c
>> Update to 3.6.2+, still missing tessellation unless you rebuild mesa.
>
> Right, exactly the same as with static linking.
>
>> The latter bug in itself.
>
> Not sure what you mean by that.
>
>
>> Downgrade - TBD, depending on the (fixed) LLVM bugs.
>
> Building against one version of LLVM and then downgrading the shared
> library to an older version is indeed the only case we're currently not
> handling gracefully. It should be rather rare though.
>
>
>> src/gallium/drivers/swr/rasterizer/jitter/scripts/gen_llvm_ir_macros.py
>> Reversed argument order. No issues if the whole things gets inlined
>> into mesa, fun experience otherwise.
>
> If the newer LLVM version doesn't work with code compiled for the older
> version, I'd consider that an LLVM bug.
>
>
>> Using a runtime check for shared libs [...] the "better" choice, imho.
>
> Right, that would probably be the best solution. Any volunteers to make
> it happen?
>
More than happy to make it work on mesa side. Since my LLVM experience
is virtually not there, perhaps we can bribe someone who already knows
their way around  ;-)

Tom, can you forward the request to fellow LLVM developers:
Since LLVM has the feature to provide a shared library/ies, it would
be great to have an API which provides the major/minor/patch version.
The last one being the one we really want here.
This way user which links against the shared lib(s) can query the
version and act accordingly - be that apply local workarounds or
disable certain functionality.

>
>> That or just bump the requirement ?
>
> That wouldn't protect against the shared library being downgraded to an
> older version.
>
Almost. AFAICT Mesa has (had for a long time) the implicit agreement
that the build-time requirements are identical to the run-time ones.

If people use a lower [runtime] versions, things will explode in many
places. This is not specific/isolated to LLVM.

Thanks
Emil
__

[Mesa-dev] [Bug 98310] GLES context returned by OpenGL API

[bugzilla-daemon]

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

Bug ID: 98310
   Summary: GLES context returned by OpenGL API
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: major
  Priority: medium
 Component: EGL
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: man...@openmail.cc
QA Contact: mesa-dev@lists.freedesktop.org

The ultimate consequence of this bug is that EPoxy thinks that the current
context is OpenGL, although it is GLES2. It reports this up to GTK/GDK which
then abandones GLES2 rendering (because it thinks OpenGL is being used).

EPoxy tests whether the current context is OpenGL by

epoxy_egl_get_current_gl_context_api( )

in two steps, by first binding the API which is being tested for:

eglBindAPI( EGL_OPENGL_API );

and subsequently testing for a context

if( eglGetCurrentContext( ) ) ...

I don't know whether this is actually a proper way of testing this (or why this
is required by further up in the first place), but I can definitely say I do
NOT have OpenGL (simply because of the lack of X11 libraries and I built Mesa
only with GLES2) but that call, after the OPENGL_API was bound, returns a
context. Which in turn makes Epoxy think that the context is OpenGL.

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

[Mesa-dev] [Bug 98310] GLES context returned by OpenGL API

[bugzilla-daemon]

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

ajax at nwnk dot net  changed:

   What|Removed |Added

 Resolution|--- |NOTOURBUG
 Status|NEW |RESOLVED

--- Comment #1 from ajax at nwnk dot net  ---
Mesa is right, epoxy is wrong:

https://github.com/anholt/libepoxy/pull/90

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

Re: [Mesa-dev] [PATCH 07/25] mesa/i965: eliminate gl_tess_ctrl_program and use new shared shader_info

[Jason Ekstrand]

I want to make a few comments on how this series is structured.  This is
not the way I would have done it and I think the way you structured it
makes it substantially less rebasable than it could be and a bit harder to
review.  The way *I* would have done this would be something like the
following:

 1) Move shader_info to common code (patches 1-2)
 2) Add a shader_info pointer to gl_program (patch 6), break the fill
shader_info stuff from glsl_to_nir into its own function, and call it from
somewhere such that it always gets filled out.
 3) Add new fields to shader_info *and* make sure they get filled out from
other GLSL information
 4) Convert i965 over to the new shader_info
 5) Convert gallium over to the new shader_info
 6) Make GLSL fill out shader_info directly and nuke the old shader
metadata.
 7) Delete the shader_info fill-out function.

Something along these lines would go a long way towards avoiding the "mega
patch" problem where each patch touches 4 or 5 different components.  It
also makes it clearer to review because you don't add fields and then the
reviewer goes "Wait, where does this get set?  Oh, in another patch".  I'm
not necessarily saying that you have to go back and change your patches.
It's more a suggestion for if you end up doing a v3 or another refactor
along these lines in the future.

On Mon, Oct 17, 2016 at 11:12 PM, Timothy Arceri <
timothy.arc...@collabora.com> wrote:

> ---
>  src/mesa/drivers/dri/i965/brw_context.h   |  6 ++---
>  src/mesa/drivers/dri/i965/brw_draw.c  |  2 +-
>  src/mesa/drivers/dri/i965/brw_program.c   |  2 +-
>  src/mesa/drivers/dri/i965/brw_tcs.c   | 32
> ++-
>  src/mesa/drivers/dri/i965/brw_tcs_surface_state.c |  2 +-
>  src/mesa/drivers/dri/i965/brw_tes.c   | 20 +++---
>  src/mesa/drivers/dri/i965/gen7_hs_state.c |  4 +--
>  src/mesa/main/context.c   |  2 +-
>  src/mesa/main/mtypes.h| 12 +
>  src/mesa/main/shaderapi.c |  4 +--
>  src/mesa/main/state.c | 11 
>  src/mesa/program/prog_statevars.c |  2 +-
>  src/mesa/program/program.c|  4 +--
>  src/mesa/program/program.h| 23 
>  src/mesa/state_tracker/st_atom.c  |  2 +-
>  src/mesa/state_tracker/st_atom_constbuf.c |  2 +-
>  src/mesa/state_tracker/st_atom_sampler.c  |  2 +-
>  src/mesa/state_tracker/st_atom_shader.c   |  2 +-
>  src/mesa/state_tracker/st_atom_texture.c  |  2 +-
>  src/mesa/state_tracker/st_cb_program.c| 10 +++
>  src/mesa/state_tracker/st_program.c   |  6 ++---
>  src/mesa/state_tracker/st_program.h   |  6 ++---
>  22 files changed, 58 insertions(+), 100 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_context.h
> b/src/mesa/drivers/dri/i965/brw_context.h
> index c92bb9f..9b7e184 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.h
> +++ b/src/mesa/drivers/dri/i965/brw_context.h
> @@ -337,7 +337,7 @@ struct brw_vertex_program {
>
>  /** Subclass of Mesa tessellation control program */
>  struct brw_tess_ctrl_program {
> -   struct gl_tess_ctrl_program program;
> +   struct gl_program program;
> unsigned id;  /**< serial no. to identify tess ctrl progs, never
> re-used */
>  };
>
> @@ -1008,7 +1008,7 @@ struct brw_context
>  */
> const struct gl_vertex_program *vertex_program;
> const struct gl_geometry_program *geometry_program;
> -   const struct gl_tess_ctrl_program *tess_ctrl_program;
> +   const struct gl_program *tess_ctrl_program;
> const struct gl_tess_eval_program *tess_eval_program;
> const struct gl_fragment_program *fragment_program;
> const struct gl_compute_program *compute_program;
> @@ -1730,7 +1730,7 @@ brw_vertex_program_const(const struct
> gl_vertex_program *p)
>  }
>
>  static inline struct brw_tess_ctrl_program *
> -brw_tess_ctrl_program(struct gl_tess_ctrl_program *p)
> +brw_tess_ctrl_program(struct gl_program *p)
>  {
> return (struct brw_tess_ctrl_program *) p;
>  }
> diff --git a/src/mesa/drivers/dri/i965/brw_draw.c
> b/src/mesa/drivers/dri/i965/brw_draw.c
> index 5d176ef..5485de3 100644
> --- a/src/mesa/drivers/dri/i965/brw_draw.c
> +++ b/src/mesa/drivers/dri/i965/brw_draw.c
> @@ -458,7 +458,7 @@ brw_try_draw_prims(struct gl_context *ctx,
> brw->tes.base.sampler_count = ctx->TessEvalProgram._Current ?
>util_last_bit(ctx->TessEvalProgram._Current->Base.SamplersUsed) :
> 0;
> brw->tcs.base.sampler_count = ctx->TessCtrlProgram._Current ?
> -  util_last_bit(ctx->TessCtrlProgram._Current->Base.SamplersUsed) :
> 0;
> +  util_last_bit(ctx->TessCtrlProgram._Current->SamplersUsed) : 0;
> brw->vs.base.sampler_count =
>util_last_bit(ctx->VertexProgram._Current->Base.SamplersUsed);
>
> diff --git a/src/mesa/drivers/dri/i965/b

[Mesa-dev] [Bug 98310] GLES context returned by OpenGL API

[bugzilla-daemon]

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

--- Comment #2 from Chad Versace  ---
Related bug on the real libepoxy bugtracker:
https://github.com/anholt/libepoxy/issues/25

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

Re: [Mesa-dev] [PATCH 07/25] mesa/i965: eliminate gl_tess_ctrl_program and use new shared shader_info

[Jason Ekstrand]

On Mon, Oct 17, 2016 at 11:12 PM, Timothy Arceri <
timothy.arc...@collabora.com> wrote:

> ---
>  src/mesa/drivers/dri/i965/brw_context.h   |  6 ++---
>  src/mesa/drivers/dri/i965/brw_draw.c  |  2 +-
>  src/mesa/drivers/dri/i965/brw_program.c   |  2 +-
>  src/mesa/drivers/dri/i965/brw_tcs.c   | 32
> ++-
>  src/mesa/drivers/dri/i965/brw_tcs_surface_state.c |  2 +-
>  src/mesa/drivers/dri/i965/brw_tes.c   | 20 +++---
>  src/mesa/drivers/dri/i965/gen7_hs_state.c |  4 +--
>  src/mesa/main/context.c   |  2 +-
>  src/mesa/main/mtypes.h| 12 +
>  src/mesa/main/shaderapi.c |  4 +--
>  src/mesa/main/state.c | 11 
>  src/mesa/program/prog_statevars.c |  2 +-
>  src/mesa/program/program.c|  4 +--
>  src/mesa/program/program.h| 23 
>  src/mesa/state_tracker/st_atom.c  |  2 +-
>  src/mesa/state_tracker/st_atom_constbuf.c |  2 +-
>  src/mesa/state_tracker/st_atom_sampler.c  |  2 +-
>  src/mesa/state_tracker/st_atom_shader.c   |  2 +-
>  src/mesa/state_tracker/st_atom_texture.c  |  2 +-
>  src/mesa/state_tracker/st_cb_program.c| 10 +++
>  src/mesa/state_tracker/st_program.c   |  6 ++---
>  src/mesa/state_tracker/st_program.h   |  6 ++---
>  22 files changed, 58 insertions(+), 100 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_context.h
> b/src/mesa/drivers/dri/i965/brw_context.h
> index c92bb9f..9b7e184 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.h
> +++ b/src/mesa/drivers/dri/i965/brw_context.h
> @@ -337,7 +337,7 @@ struct brw_vertex_program {
>
>  /** Subclass of Mesa tessellation control program */
>  struct brw_tess_ctrl_program {
> -   struct gl_tess_ctrl_program program;
> +   struct gl_program program;
> unsigned id;  /**< serial no. to identify tess ctrl progs, never
> re-used */
>  };
>
> @@ -1008,7 +1008,7 @@ struct brw_context
>  */
> const struct gl_vertex_program *vertex_program;
> const struct gl_geometry_program *geometry_program;
> -   const struct gl_tess_ctrl_program *tess_ctrl_program;
> +   const struct gl_program *tess_ctrl_program;
> const struct gl_tess_eval_program *tess_eval_program;
> const struct gl_fragment_program *fragment_program;
> const struct gl_compute_program *compute_program;
> @@ -1730,7 +1730,7 @@ brw_vertex_program_const(const struct
> gl_vertex_program *p)
>  }
>
>  static inline struct brw_tess_ctrl_program *
> -brw_tess_ctrl_program(struct gl_tess_ctrl_program *p)
> +brw_tess_ctrl_program(struct gl_program *p)
>  {
> return (struct brw_tess_ctrl_program *) p;
>  }
> diff --git a/src/mesa/drivers/dri/i965/brw_draw.c
> b/src/mesa/drivers/dri/i965/brw_draw.c
> index 5d176ef..5485de3 100644
> --- a/src/mesa/drivers/dri/i965/brw_draw.c
> +++ b/src/mesa/drivers/dri/i965/brw_draw.c
> @@ -458,7 +458,7 @@ brw_try_draw_prims(struct gl_context *ctx,
> brw->tes.base.sampler_count = ctx->TessEvalProgram._Current ?
>util_last_bit(ctx->TessEvalProgram._Current->Base.SamplersUsed) :
> 0;
> brw->tcs.base.sampler_count = ctx->TessCtrlProgram._Current ?
> -  util_last_bit(ctx->TessCtrlProgram._Current->Base.SamplersUsed) :
> 0;
> +  util_last_bit(ctx->TessCtrlProgram._Current->SamplersUsed) : 0;
> brw->vs.base.sampler_count =
>util_last_bit(ctx->VertexProgram._Current->Base.SamplersUsed);
>
> diff --git a/src/mesa/drivers/dri/i965/brw_program.c
> b/src/mesa/drivers/dri/i965/brw_program.c
> index a41f36e..4e0df5a 100644
> --- a/src/mesa/drivers/dri/i965/brw_program.c
> +++ b/src/mesa/drivers/dri/i965/brw_program.c
> @@ -168,7 +168,7 @@ static struct gl_program *brwNewProgram( struct
> gl_context *ctx,
>if (prog) {
>   prog->id = get_new_program_id(brw->screen);
>
> - return _mesa_init_gl_program(&prog->program.Base, target, id);
> + return _mesa_init_gl_program(&prog->program, target, id);
>} else {
>   return NULL;
>}
> diff --git a/src/mesa/drivers/dri/i965/brw_tcs.c
> b/src/mesa/drivers/dri/i965/brw_tcs.c
> index 0f03fab..08cf413 100644
> --- a/src/mesa/drivers/dri/i965/brw_tcs.c
> +++ b/src/mesa/drivers/dri/i965/brw_tcs.c
> @@ -178,7 +178,7 @@ brw_codegen_tcs_prog(struct brw_context *brw,
> double start_time = 0;
>
> if (tcp) {
> -  nir = tcp->program.Base.nir;
> +  nir = tcp->program.nir;
> } else {
>/* Create a dummy nir_shader.  We won't actually use NIR code to
> * generate assembly (it's easier to generate assembly directly),
> @@ -211,14 +211,14 @@ brw_codegen_tcs_prog(struct brw_context *brw,
>
> if (tcs) {
>brw_assign_common_binding_table_offsets(MESA_SHADER_TESS_CTRL,
> devinfo,
> -  

Re: [Mesa-dev] [PATCH] egl/dri2: add a libname to dlopen for OpenBSD

[Emil Velikov]

On 18 October 2016 at 00:58, Jonathan Gray  wrote:
> On Mon, Oct 17, 2016 at 05:34:02PM +0100, Emil Velikov wrote:
>> On 17 October 2016 at 16:39, Eric Engestrom  
>> wrote:
>> > On Monday, 2016-10-17 22:53:20 +1100, Jonathan Gray wrote:
>> >> On Mon, Oct 17, 2016 at 12:39:11PM +0100, Emil Velikov wrote:
>> >> > On 17 October 2016 at 10:53, Eric Engestrom  
>> >> > wrote:
>> >> > > On Sunday, 2016-10-16 16:38:35 +1100, Jonathan Gray wrote:
>> >> > >> On OpenBSD try to dlopen 'libglapi.so', ld.so will find
>> >> > >> the highest major/minor version and open it in this case.
>> >> > >>
>> >> > >> Avoids '#error Unknown glapi provider for this platform' at build 
>> >> > >> time.
>> >> > >>
>> >> > >> Signed-off-by: Jonathan Gray 
>> >> > >
>> >> > > LGTM, and I guess the other *BSD will want the same since 7a9c92d0 
>> >> > > broke
>> >> > > them too.
>> >> > >
>> >> > I'm not 100% sure about that. OpenBSD (unlike other BSD) did bump the
>> >> > major when the ABI breaks due to 'internal' changes - think of
>> >> > off_t/time_t on 32 vs 64bit systems and alike.
>> >> >
>> >> > Unlike Linux kernel/distros, BSDs tend to be more relaxed when in
>> >> > comes to ABI, I believe. Don't quote me on that one ;-)
>> >>
>> >> OpenBSD tends to favour simplified interfaces over backwards compatiblity
>> >> and is more like a research system in that respect.  As the kernel
>> >> and userland are one source tree ioctl compat largely doesn't exist.
>> >> System calls get deprecated and removed over the course of a few releases.
>> >> So we didn't go through the pain of duplicated systems calls for off_t
>> >> as mentioned, and don't go in for symbol versioning.  Just major.minor
>> >> library versioning, which is roughly symbol removals, major crank,
>> >> symbol additions minor crank.
>> >>
>> >> I believe FreeBSD tends to go in for backwards compatibility more
>> >> but am not familiar with the details.  They also have a different ld.so.
>> >>
>> >> Perhaps an else case for 'libglapi.so.0' would be appropriate for all
>> >> the other various unices instead of the #error ?
>> >
>> > Yeah actually, I'm thinking reverting this hunk of 7a9c92d0 might be a 
>> > better,
>> > to avoid the potentially huge list of every *BSD and other Unix:
>> >
>> Fwiw I've intentionally added the hunk since I was a bit lazy to check
>> if the BSD(s?)/Solaris/others have bumped the major locally. Having a
>> closer look that's not the case, so indeed we can add revert to
>> libglapi.so.0 in the else statement.
>>
>> Jonathan, how about we with the above instead ?
>
> At the moment OpenBSD has libglapi.so.0.2 for Mesa 11.2.2.
> New versions of Mesa add new shared_dispatch_stub_* symbols,
> which the minor would crank for.
>
Don't think we [intentionally] added any symbols for a long while.

> I'd prefer the diff I mailed for OpenBSD for if the major version
> should crank for some reason.
Let's worry about that if/when it happens ?

Emil
/me lands the rest of the patches
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 92198] eglCreateWindowSurface ERROR

[bugzilla-daemon]

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

ajax at nwnk dot net  changed:

   What|Removed |Added

Product|epoxy   |Mesa
 QA Contact|airl...@freedesktop.org |mesa-dev@lists.freedesktop.
   ||org
   Assignee|e...@anholt.net |mesa-dev@lists.freedesktop.
   ||org
  Component|general |EGL

-- 
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] [PATCH 07/25] mesa/i965: eliminate gl_tess_ctrl_program and use new shared shader_info

[Jason Ekstrand]

On Tue, Oct 18, 2016 at 8:14 AM, Jason Ekstrand 
wrote:

> I want to make a few comments on how this series is structured.  This is
> not the way I would have done it and I think the way you structured it
> makes it substantially less rebasable than it could be and a bit harder to
> review.  The way *I* would have done this would be something like the
> following:
>
>  1) Move shader_info to common code (patches 1-2)
>  2) Add a shader_info pointer to gl_program (patch 6), break the fill
> shader_info stuff from glsl_to_nir into its own function, and call it from
> somewhere such that it always gets filled out.
>  3) Add new fields to shader_info *and* make sure they get filled out from
> other GLSL information
>  4) Convert i965 over to the new shader_info
>  5) Convert gallium over to the new shader_info
>  6) Make GLSL fill out shader_info directly and nuke the old shader
> metadata.
>  7) Delete the shader_info fill-out function.
>
> Something along these lines would go a long way towards avoiding the "mega
> patch" problem where each patch touches 4 or 5 different components.  It
> also makes it clearer to review because you don't add fields and then the
> reviewer goes "Wait, where does this get set?  Oh, in another patch".  I'm
> not necessarily saying that you have to go back and change your patches.
> It's more a suggestion for if you end up doing a v3 or another refactor
> along these lines in the future.
>

On the review side, splitting out as I described above would make it much
easier to review since it would be more-or-less one type of refactor per
patch.  In this patch, we have several different kinds of refactors:

 1) Move consumers over to reading shader_info
 2) Remove gl_tess_ctrl_program and related refactors
 3) Move producer over to writing shader_info

Normally, when reviewing, I would just skim (2) and give (1) a (3) more
effort.  Having them mixed together means I have to pay constant attention
to what's going on.  Also, having (2) mixed in makes it harder to verify
(3) because there's a lot of code motion only some of which matters.


>
>
> On Mon, Oct 17, 2016 at 11:12 PM, Timothy Arceri <
> timothy.arc...@collabora.com> wrote:
>
>> ---
>>  src/mesa/drivers/dri/i965/brw_context.h   |  6 ++---
>>  src/mesa/drivers/dri/i965/brw_draw.c  |  2 +-
>>  src/mesa/drivers/dri/i965/brw_program.c   |  2 +-
>>  src/mesa/drivers/dri/i965/brw_tcs.c   | 32
>> ++-
>>  src/mesa/drivers/dri/i965/brw_tcs_surface_state.c |  2 +-
>>  src/mesa/drivers/dri/i965/brw_tes.c   | 20 +++---
>>  src/mesa/drivers/dri/i965/gen7_hs_state.c |  4 +--
>>  src/mesa/main/context.c   |  2 +-
>>  src/mesa/main/mtypes.h| 12 +
>>  src/mesa/main/shaderapi.c |  4 +--
>>  src/mesa/main/state.c | 11 
>>  src/mesa/program/prog_statevars.c |  2 +-
>>  src/mesa/program/program.c|  4 +--
>>  src/mesa/program/program.h| 23 
>>  src/mesa/state_tracker/st_atom.c  |  2 +-
>>  src/mesa/state_tracker/st_atom_constbuf.c |  2 +-
>>  src/mesa/state_tracker/st_atom_sampler.c  |  2 +-
>>  src/mesa/state_tracker/st_atom_shader.c   |  2 +-
>>  src/mesa/state_tracker/st_atom_texture.c  |  2 +-
>>  src/mesa/state_tracker/st_cb_program.c| 10 +++
>>  src/mesa/state_tracker/st_program.c   |  6 ++---
>>  src/mesa/state_tracker/st_program.h   |  6 ++---
>>  22 files changed, 58 insertions(+), 100 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_context.h
>> b/src/mesa/drivers/dri/i965/brw_context.h
>> index c92bb9f..9b7e184 100644
>> --- a/src/mesa/drivers/dri/i965/brw_context.h
>> +++ b/src/mesa/drivers/dri/i965/brw_context.h
>> @@ -337,7 +337,7 @@ struct brw_vertex_program {
>>
>>  /** Subclass of Mesa tessellation control program */
>>  struct brw_tess_ctrl_program {
>> -   struct gl_tess_ctrl_program program;
>> +   struct gl_program program;
>> unsigned id;  /**< serial no. to identify tess ctrl progs, never
>> re-used */
>>  };
>>
>> @@ -1008,7 +1008,7 @@ struct brw_context
>>  */
>> const struct gl_vertex_program *vertex_program;
>> const struct gl_geometry_program *geometry_program;
>> -   const struct gl_tess_ctrl_program *tess_ctrl_program;
>> +   const struct gl_program *tess_ctrl_program;
>> const struct gl_tess_eval_program *tess_eval_program;
>> const struct gl_fragment_program *fragment_program;
>> const struct gl_compute_program *compute_program;
>> @@ -1730,7 +1730,7 @@ brw_vertex_program_const(const struct
>> gl_vertex_program *p)
>>  }
>>
>>  static inline struct brw_tess_ctrl_program *
>> -brw_tess_ctrl_program(struct gl_tess_ctrl_program *p)
>> +brw_tess_ctrl_program(struct gl_program *p)
>>  {
>> return (struct br

[Mesa-dev] [Bug 98271] [radeonsi]Playing videos with vdpau or vaapi hardware acceleration crashes my pc

[bugzilla-daemon]

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

--- Comment #19 from Christian König  ---
(In reply to John from comment #18)
> What should I try next?

Installing an older kernel, see if that works with 12.0 mesa.

If yes we have narrowed it down to the kernel, if not we need to stick a bit
more into mesa.

Another possibility which came to my mind is that this might not we an issue
with UVD decoding, but rather presenting it.

E.g. install both VDPAU and OpenGL from a certain Mesa version *AND* make sure
that you restart X after that so that the X acceleration uses the new library
versions as well.

-- 
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] [PATCH] st/va: disable cabac for h264 baseline profile

[Christian König]

Am 18.10.2016 um 15:42 schrieb Andy Furniss:

Andy Furniss wrote:

Christian König wrote:

Am 18.10.2016 um 11:19 schrieb Andy Furniss:

boyuan.zh...@amd.com wrote:

From: Boyuan Zhang 

cabac is only supported in the h264 main and higher profiles


So shouldn't there be code allows it if the user space doesn't
set baseline?

I don't know how in gstreamer as it seems to try to use b-frames
if you use other than baseline which doesn't work.

With avconv it is possible to call main/high and set b-frames to 0.

I know it's technically correct spec wise, but seems a shame as it
costs a fair bit in "free" efficiency.

On Windows the raptor game recording app produces files flagged as
high with cabac - but without b-frames.


The problem is that it can easily break decoders. CABAC is simply not
allowed in a stream flagged as baseline compliant.


But with ffmpeg/avconv I can make a stream flagged as main/high even
if it's really baseline + CABAC. I guess Windows may vary but the test
I did seems to take this pragmatic approach, as it seems do other h/w
encoders eg. smartphone output.


It's a pity that we don't support B-frames any more.


Anymore? Now I am curious, seems to work with omx (cqp single instance)



With that in place
we could easily advertise support for mainline profile.


MBAFF/PAFF?


Sorry if that came over as being pedantic, silly as I think pragmatism
is the way to go and I know intel advertise main/high, but doubt they
do interlaced.


Exactly, I mean we are talking about features to support encoding into 
interlaced format. Is anybody still actively doing that?


But even then, it's not so much of a problem advertising mainline 
profile and then not using MBAFF/PAFF.


But when you advertise B-frames and then can't encode it you got a 
serious problem because your frames are not in the right order any more :)



In fact vce vaapi is currently advertising them as well (I did mention
it in some thread). Good for letting ffmpeg flag as such while not using
b-frames, not so good for gstreamer as they have changed the default to
high so old command lines will not explicitly fail, but will produce 
junk.


I see va.h has a cabac switch and gstreamer exposes it - though it's not
read by the driver. Maybe if that were hooked up then users could turn
it on and profit :-).


Yeah, but again turning it on while the SPS/PPS only advertise the 
stream to be baseline compliant is a clear violation of the codec 
standard. (Is that actually encodeable in the stream? or does the 
encoder switch to some higher level automatically if you use it?).


Regards,
Christian.







Christian.




Signed-off-by: Boyuan Zhang 
---
  src/gallium/state_trackers/va/picture.c | 1 -
  1 file changed, 1 deletion(-)

diff --git a/src/gallium/state_trackers/va/picture.c
b/src/gallium/state_trackers/va/picture.c
index eae5dc4..db08a3c 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -110,7 +110,6 @@ getEncParamPreset(vlVaContext *context)
context->desc.h264enc.motion_est.enc_ime2_search_range_y =
0x0004;

 //pic control preset
-   context->desc.h264enc.pic_ctrl.enc_cabac_enable = 0x0001;
context->desc.h264enc.pic_ctrl.enc_constraint_set_flags =
0x0040;

 //rate control



___
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] [Bug 92198] eglCreateWindowSurface ERROR

[bugzilla-daemon]

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

Emil Velikov  changed:

   What|Removed |Added

 Resolution|--- |NOTABUG
 Status|NEW |RESOLVED

--- Comment #2 from Emil Velikov  ---
There's a few things here:

- The kernel module name is i915 for backwards compatibility reasons, yet on
userspace side there are two drivers - i915 and i965. You can skim
through/compare with $mesa_top/include/pci_ids/i9[16]5_pci_ids.h

- Using eglGetDisplay is implementation specific - don't use that since it
depends on hacks such as EGL_PLATFORM/EGL_DISPLAY and alike. Use
EGL_EXT_platform_base or the EGL 1.5 equivalent.

- Mesa has dropped support for fbdev platform a long time ago. Use drm instead
- see kmscube for a simple example (iirc it uses the eglGetDisplay API so
ignore that part).

- ATM you're building the gallium drivers, which seemingly you don't need. Pass
to configure --without-gallium-drivers

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

Re: [Mesa-dev] [PATCH 10/25] mesa/nir/radv/anv: add shader_info param to nir_shader builder

[Jason Ekstrand]

On Mon, Oct 17, 2016 at 11:12 PM, Timothy Arceri <
timothy.arc...@collabora.com> wrote:

> And pass in a pointer to the shader info in gl_program for ARB programs.
> ---
>  src/amd/vulkan/radv_meta_blit.c   | 12 
>  src/amd/vulkan/radv_meta_blit2d.c | 12 
>  src/amd/vulkan/radv_meta_buffer.c |  6 --
>  src/amd/vulkan/radv_meta_bufimage.c   |  3 ++-
>  src/amd/vulkan/radv_meta_clear.c  | 12 
>  src/amd/vulkan/radv_meta_decompress.c |  6 --
>  src/amd/vulkan/radv_meta_fast_clear.c |  6 --
>  src/amd/vulkan/radv_meta_resolve.c|  6 --
>  src/amd/vulkan/radv_meta_resolve_cs.c |  2 +-
>  src/amd/vulkan/radv_pipeline.c|  2 +-
>  src/compiler/nir/nir_builder.h|  5 +++--
>  src/compiler/nir/tests/control_flow_tests.cpp |  3 ++-
>  src/gallium/auxiliary/nir/tgsi_to_nir.c   |  2 +-
>  src/intel/blorp/blorp_blit.c  |  2 +-
>  src/intel/blorp/blorp_clear.c |  2 +-
>  src/mesa/drivers/dri/i965/brw_program.c   |  2 +-
>  src/mesa/drivers/dri/i965/brw_program.h   |  2 +-
>  src/mesa/drivers/dri/i965/brw_tcs.c   |  3 ++-
>  src/mesa/program/prog_to_nir.c|  5 +++--
>  src/mesa/program/prog_to_nir.h|  2 +-
>  20 files changed, 60 insertions(+), 35 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_meta_blit.c
> b/src/amd/vulkan/radv_meta_blit.c
> index bfbf880..3eda43e 100644
> --- a/src/amd/vulkan/radv_meta_blit.c
> +++ b/src/amd/vulkan/radv_meta_blit.c
> @@ -37,7 +37,8 @@ build_nir_vertex_shader(void)
> const struct glsl_type *vec4 = glsl_vec4_type();
> nir_builder b;
>
> -   nir_builder_init_simple_shader(&b, NULL, MESA_SHADER_VERTEX,
> NULL);
> +   nir_builder_init_simple_shader(&b, NULL, MESA_SHADER_VERTEX, NULL,
> +  NULL);
> b.shader->info->name = ralloc_strdup(b.shader, "meta_blit_vs");
>
> nir_variable *pos_in = nir_variable_create(b.shader,
> nir_var_shader_in,
> @@ -67,7 +68,8 @@ build_nir_copy_fragment_shader(enum glsl_sampler_dim
> tex_dim)
> const struct glsl_type *vec4 = glsl_vec4_type();
> nir_builder b;
>
> -   nir_builder_init_simple_shader(&b, NULL, MESA_SHADER_FRAGMENT,
> NULL);
> +   nir_builder_init_simple_shader(&b, NULL, MESA_SHADER_FRAGMENT,
> NULL,
> +  NULL);
>
> sprintf(shader_name, "meta_blit_fs.%d", tex_dim);
> b.shader->info->name = ralloc_strdup(b.shader, shader_name);
> @@ -121,7 +123,8 @@ build_nir_copy_fragment_shader_depth(enum
> glsl_sampler_dim tex_dim)
> const struct glsl_type *vec4 = glsl_vec4_type();
> nir_builder b;
>
> -   nir_builder_init_simple_shader(&b, NULL, MESA_SHADER_FRAGMENT,
> NULL);
> +   nir_builder_init_simple_shader(&b, NULL, MESA_SHADER_FRAGMENT,
> NULL,
> +  NULL);
>
> sprintf(shader_name, "meta_blit_depth_fs.%d", tex_dim);
> b.shader->info->name = ralloc_strdup(b.shader, shader_name);
> @@ -175,7 +178,8 @@ build_nir_copy_fragment_shader_stencil(enum
> glsl_sampler_dim tex_dim)
> const struct glsl_type *vec4 = glsl_vec4_type();
> nir_builder b;
>
> -   nir_builder_init_simple_shader(&b, NULL, MESA_SHADER_FRAGMENT,
> NULL);
> +   nir_builder_init_simple_shader(&b, NULL, MESA_SHADER_FRAGMENT,
> NULL,
> +  NULL);
>
> sprintf(shader_name, "meta_blit_stencil_fs.%d", tex_dim);
> b.shader->info->name = ralloc_strdup(b.shader, shader_name);
> diff --git a/src/amd/vulkan/radv_meta_blit2d.c
> b/src/amd/vulkan/radv_meta_blit2d.c
> index 6e92f80..bed03a3 100644
> --- a/src/amd/vulkan/radv_meta_blit2d.c
> +++ b/src/amd/vulkan/radv_meta_blit2d.c
> @@ -438,7 +438,8 @@ build_nir_vertex_shader(void)
> const struct glsl_type *vec2 = glsl_vector_type(GLSL_TYPE_FLOAT,
> 2);
> nir_builder b;
>
> -   nir_builder_init_simple_shader(&b, NULL, MESA_SHADER_VERTEX,
> NULL);
> +   nir_builder_init_simple_shader(&b, NULL, MESA_SHADER_VERTEX, NULL,
> +  NULL);
> b.shader->info->name = ralloc_strdup(b.shader, "meta_blit_vs");
>
> nir_variable *pos_in = nir_variable_create(b.shader,
> nir_var_shader_in,
> @@ -573,7 +574,8 @@ build_nir_copy_fragment_shader(struct radv_device
> *device,
> const struct glsl_type *vec2 = glsl_vector_type(GLSL_TYPE_FLOAT,
> 2);
> nir_builder b;
>
> -   nir_builder_init_simple_shader(&b, NULL, MESA_SHADER_FRAGMENT,
> NULL);
> +   nir_builder_init_simple_shader(&b, NULL, MESA_SHADER_FRAGMENT,
> NULL,
> +  NULL);
> b.shader->info->name = ralloc_strdup(b.shader, name);
>
> nir_variable *tex_pos_in = nir_variable_create(b.shader,
> nir_var_shader_in,
> @@ -602,7 +604,8 @@ b

Re: [Mesa-dev] [PATCH v2 05/16] loader: reimplement loader_get_user_preferred_fd via libdrm

[Emil Velikov]

On 18 October 2016 at 09:49, Nicolai Hähnle  wrote:
> On 14.10.2016 20:21, Emil Velikov wrote:
>>
>> From: Emil Velikov 
>>
>> Currently not everyone has libudev and with follow-up patches we'll
>> completely remove the divergent codepaths.
>>
>> Use the libdrm drm device API to construct the required ID_PATH_TAG-like
>> string, to preserve the current functionality for libudev users and
>> allow others to benefit from it as well.
>>
>> v2: Drop ranty comments, pick the correct device
>>
>> Cc: Axel Davy 
>> Signed-off-by: Emil Velikov 
>> ---
>>  src/loader/loader.c | 247
>> ++--
>>  1 file changed, 106 insertions(+), 141 deletions(-)
>>
>> diff --git a/src/loader/loader.c b/src/loader/loader.c
>> index ad4f946..06df05b 100644
>> --- a/src/loader/loader.c
>> +++ b/src/loader/loader.c
>
> [snip]
>>
>> @@ -321,17 +232,60 @@ static char *loader_get_dri_config_device_id(void)
>>  }
>>  #endif
>>
>> +static char *drm_construct_id_path_tag(drmDevicePtr device)
>> +{
>> +/* Length of "pci-_xx_xx_x\n" */
>> +#define PCI_ID_PATH_TAG_LENGTH 17
>> +   char *tag = NULL;
>> +
>> +   if (device->bustype == DRM_BUS_PCI) {
>> +tag = calloc(PCI_ID_PATH_TAG_LENGTH, sizeof(char));
>> +if (tag == NULL)
>> +return NULL;
>> +
>> +sprintf(tag, "pci-%04x_%02x_%02x_%1u",
>> device->businfo.pci->domain,
>> +device->businfo.pci->bus, device->businfo.pci->dev,
>> +device->businfo.pci->func);
>
>
> Defensive programming would suggest to use snprintf.
>
Correct. It's more like extra defensive in this case but will fix.

> [snip]
>
>> @@ -345,55 +299,66 @@ int loader_get_user_preferred_fd(int default_fd, int
>> *different_device)
>>return default_fd;
>> }
>>
>> -   udev = udev_new();
>> -   if (!udev)
>> -  goto prime_clean;
>> +   default_tag = drm_get_id_path_tag_for_fd(default_fd);
>> +   if (default_tag == NULL)
>> +  goto err;
>>
>> -   default_device_id_path_tag = get_id_path_tag_from_fd(udev,
>> default_fd);
>> -   if (!default_device_id_path_tag)
>> -  goto udev_clean;
>> +   num_devices = drmGetDevices(devices, MAX_DRM_DEVICES);
>> +   if (num_devices < 0)
>> +  goto err;
>>
>> -   is_different_device = 1;
>> /* two format are supported:
>>  * "1": choose any other card than the card used by default.
>>  * id_path_tag: (for example "pci-_02_00_0") choose the card
>>  * with this id_path_tag.
>>  */
>> if (!strcmp(prime,"1")) {
>> -  free(prime);
>> -  prime = strdup(default_device_id_path_tag);
>> -  /* request a card with a different card than the default card */
>> -  another_tag = 1;
>> -   } else if (!strcmp(default_device_id_path_tag, prime))
>> -  /* we are to get a new fd (render-node) of the same device */
>> -  is_different_device = 0;
>> -
>> -   device_name = get_render_node_from_id_path_tag(udev,
>> -  prime,
>> -  another_tag);
>> -   if (device_name == NULL) {
>> -  is_different_device = 0;
>> -  goto default_device_clean;
>> +  /* Hmm... detection for 2-7 seems to be broken. Oh well ...
>> +   * Pick the first render device that is not our own.
>> +   */
>> +  for (i = 0; i < num_devices; i++) {
>> + if (devices[i]->available_nodes & 1 << DRM_NODE_RENDER &&
>> + !drm_device_matches_tag(devices[i], default_tag)) {
>> +
>> +found = true;
>> +break;
>> + }
>> +  }
>> +   } else {
>> +  for (i = 0; i < num_devices; i++) {
>> + if (devices[i]->available_nodes & 1 << DRM_NODE_RENDER &&
>> +drm_device_matches_tag(devices[i], prime)) {
>> +
>> +found = true;
>> +break;
>> + }
>> +  }
>
>
> I feel like it would be helpful to have a warning here if the device was not
> found. This could avoid some confusion when people inevitably typo their
> prime setting.
>
Original code does not have such a message, so let's add it as follow-up ?

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

Re: [Mesa-dev] [PATCH 00/16] loader: unify loader codepaths

[Emil Velikov]

On 18 October 2016 at 09:57, Nicolai Hähnle  wrote:
> On 11.10.2016 20:31, Emil Velikov wrote:
>>
>> Hi all,
>>
>> I've been 'threatening' to do this for a while, so here it is:
>>
>> Remove the three separate code paths that we have in the loader giving
>> is a since cleanup and consistent/predictable runtime behaviour across
>> the board. Not to mention some 100 lines removed from configure.ac and
>> an extra ~400 lines removed throughout the tree.
>
>
> Hooray for code removal :)
>
> I sent some simple comments on patches 2 & 5. Apart from that, while I'm not
> super familiar with this code it does all look reasonable to me, so for the
> series:
>
Wasn't expecting for anyone to look at these and nearly pushed the lot
w/o your comments.
All done barring the extra (new) warning/debug message.

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

[Mesa-dev] [PATCH] st/glsl_to_tgsi: sort input and output decls by TGSI index

[Nicolai Hähnle]

From: Nicolai Hähnle 

Fixes a regression introduced by commit 777dcf81b.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98307
--
Using std::sort here is quite a bit C++-ier than most parts of Mesa.
I used it because the standard C library is being its usual lame self.
If people think using qsort_r is fine from a portability point of view
(it's a glibc-ism), I'd be happy to use that instead.
---
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 28 
 1 file changed, 28 insertions(+)

diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index f49a873..406f4d5 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -48,20 +48,21 @@
 #include "tgsi/tgsi_ureg.h"
 #include "tgsi/tgsi_info.h"
 #include "util/u_math.h"
 #include "util/u_memory.h"
 #include "st_program.h"
 #include "st_mesa_to_tgsi.h"
 #include "st_format.h"
 #include "st_glsl_types.h"
 #include "st_nir.h"
 
+#include 
 
 #define PROGRAM_ANY_CONST ((1 << PROGRAM_STATE_VAR) |\
(1 << PROGRAM_CONSTANT) | \
(1 << PROGRAM_UNIFORM))
 
 #define MAX_GLSL_TEXTURE_OFFSET 4
 
 class st_src_reg;
 class st_dst_reg;
 
@@ -6092,20 +6093,43 @@ emit_compute_block_size(const struct gl_program 
*program,
   (const struct gl_compute_program *)program;
 
ureg_property(ureg, TGSI_PROPERTY_CS_FIXED_BLOCK_WIDTH,
cp->LocalSize[0]);
ureg_property(ureg, TGSI_PROPERTY_CS_FIXED_BLOCK_HEIGHT,
cp->LocalSize[1]);
ureg_property(ureg, TGSI_PROPERTY_CS_FIXED_BLOCK_DEPTH,
cp->LocalSize[2]);
 }
 
+struct sort_inout_decls {
+   bool operator()(const struct inout_decl &a, const struct inout_decl &b) 
const {
+  return mapping[a.mesa_index] < mapping[b.mesa_index];
+   }
+
+   const GLuint *mapping;
+};
+
+/* Sort the given array of decls by the corresponding slot (TGSI file index).
+ *
+ * This is for the benefit of older drivers which are broken when the
+ * declarations aren't sorted in this way.
+ */
+static void
+sort_inout_decls_by_slot(struct inout_decl *decls,
+ unsigned count,
+ const GLuint mapping[])
+{
+   sort_inout_decls sorter;
+   sorter.mapping = mapping;
+   std::sort(decls, decls + count, sorter);
+}
+
 /**
  * Translate intermediate IR (glsl_to_tgsi_instruction) to TGSI format.
  * \param program  the program to translate
  * \param numInputs  number of input registers used
  * \param inputMapping  maps Mesa fragment program inputs to TGSI generic
  *  input indexes
  * \param inputSemanticName  the TGSI_SEMANTIC flag for each input
  * \param inputSemanticIndex  the semantic index (ex: which texcoord) for
  *each input
  * \param interpMode  the TGSI_INTERPOLATE_LINEAR/PERSP mode for each input
@@ -6164,20 +6188,22 @@ st_translate_program(
   calloc(t->num_temp_arrays, sizeof(t->arrays[0]));
 
/*
 * Declare input attributes.
 */
switch (procType) {
case PIPE_SHADER_FRAGMENT:
case PIPE_SHADER_GEOMETRY:
case PIPE_SHADER_TESS_EVAL:
case PIPE_SHADER_TESS_CTRL:
+  sort_inout_decls_by_slot(program->inputs, program->num_inputs, 
inputMapping);
+
   for (i = 0; i < program->num_inputs; ++i) {
  struct inout_decl *decl = &program->inputs[i];
  unsigned slot = inputMapping[decl->mesa_index];
  struct ureg_src src;
  ubyte tgsi_usage_mask = decl->usage_mask;
 
  if (glsl_base_type_is_64bit(decl->base_type)) {
 if (tgsi_usage_mask == 1)
tgsi_usage_mask = TGSI_WRITEMASK_XY;
 else if (tgsi_usage_mask == 2)
@@ -6216,20 +6242,22 @@ st_translate_program(
 * Declare output attributes.
 */
switch (procType) {
case PIPE_SHADER_FRAGMENT:
case PIPE_SHADER_COMPUTE:
   break;
case PIPE_SHADER_GEOMETRY:
case PIPE_SHADER_TESS_EVAL:
case PIPE_SHADER_TESS_CTRL:
case PIPE_SHADER_VERTEX:
+  sort_inout_decls_by_slot(program->outputs, program->num_outputs, 
outputMapping);
+
   for (i = 0; i < program->num_outputs; ++i) {
  struct inout_decl *decl = &program->outputs[i];
  unsigned slot = outputMapping[decl->mesa_index];
  struct ureg_dst dst;
  ubyte tgsi_usage_mask = decl->usage_mask;
 
  if (glsl_base_type_is_64bit(decl->base_type)) {
 if (tgsi_usage_mask == 1)
tgsi_usage_mask = TGSI_WRITEMASK_XY;
 else if (tgsi_usage_mask == 2)
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH] glsl: optimize list handling in opt_dead_code

[Marek Olšák]

On Tue, Oct 18, 2016 at 3:55 PM, Eero Tamminen
 wrote:
> Hi,
>
> On 18.10.2016 16:25, Jan Ziak wrote:
>>
>> On Tue, Oct 18, 2016 at 3:12 PM, Nicolai Hähnle 
>> wrote:
>>>
>>> On 18.10.2016 15:07, Jan Ziak wrote:

 On Tue Oct 18 09:29:59 UTC 2016, Eero Tamminen wrote:
>
> On 18.10.2016 01:07, Jan Ziak wrote:
>>
>> - The total number of executed instructions goes down from 64.184 to
>> 63.797
>>   giga-instructions when Mesa is compiled with "gcc -O0 ..."
>
>
> Please don't do performance related decisions based on data from
> compiling code with optimizations disabled.  Use -O2 or -O3 (or even
> better, check both).


 Options -O2 and -O3 interfere with profiling tools.

 I will try using -Og the next time.
>>>
>>>
>>> Just stop and use proper profiling tools like perf that can work with
>>> optimized tools.
>
>
> Valgrind/callgrind/cachegrind works also fine with optimized binaries.
>
> All profiling tools lie, at least a bit. It's better to know their strengths
> and weaknesses so that one knows which ones complement each other. Perf is
> e.g. good at finding hotspots, Valgrind (callgrind) is more reliable in
> telling how they get called.
>
> One may also needs GCC version from this decade.  Really old GCC versions
> didn't inlude all debug info needed for debugging optimized binaries.

Regarding C++ templates, the compiler doesn't use them. If u_vector
(Dave Airlie?) provides the same functionality as your array, I
suggest we use u_vector instead. If you can't use u_vector, you should
ask for approval from GLSL compiler leads (e.g. Ian Romanick or
Kenneth Graunke) to use C++ templates.


I'll repeat some stuff about profiling here but also explain my perspective.

Never profile with -O0 or disabled function inlining. Mesa uses -g -O2
with --enable-debug, so that's what you should use too. Don't use any
other -O* variants.

The only profiling tools reporting correct results are perf and
sysprof. (both use the same mechanism) If you don't enable dwarf in
perf (also sysprof can't use dwarf), you have to build Mesa with
-fno-omit-frame-pointer to see call trees. The only reason you would
want to enable dwarf-based call trees is when you want to see libc
calls. Otherwise, they won't be displayed or counted as part of call
trees. For Mesa developers who do profiling often,
-fno-omit-frame-pointer should be your default.

Callgrind counts calls (that one you can trust), but the reported time
is incorrect, because it uses its own virtual model of a CPU. Avoid it
if you want to measure time spent in functions.

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

[Mesa-dev] [PATCH] radeonsi: eliminate trivial constant VS outputs

[Marek Olšák]

From: Marek Olšák 

These constant value VS PARAM exports:
- 0,0,0,0
- 0,0,0,1
- 1,1,1,0
- 1,1,1,1
can be loaded into PS inputs using the DEFAULT_VAL field, and the VS exports
can be removed from the IR to save export & parameter memory.

After LLVM optimizations, analyze the IR to see which exports are equal to
the ones listed above (or undef) and remove them if they are.

Targeted use cases:
- All DX9 eON ports always clear 10 VS outputs to 0.0 even if most of them
  are unused by PS (such as Witcher 2 below).
- VS output arrays with unused elements that the GLSL compiler can't
  eliminate (such as Batman below).

The shader-db deltas are quite interesting:
(not from upstream si-report.py, it won't be upstreamed)

PERCENTAGE DELTASShaders PARAM exports (affected only)
batman_arkham_origins589  -67.17 %
bioshock-infinite   1769   -0.47 %
dirt-showdown548   -2.68 %
dota2   1747   -3.36 %
f1-2015  776   -4.94 %
left_4_dead_2   1762   -0.07 %
metro_2033_redux2670   -0.43 %
portal   474   -0.22 %
talos_principle  324   -3.63 %
warsow   176   -2.20 %
witcher21040  -73.78 %

All affected 991  -65.37 %  ... 9681 -> 3353

Total  26725  -10.82 %  ... 58490 -> 52162
---
 src/gallium/drivers/radeonsi/si_shader.c| 154 
 src/gallium/drivers/radeonsi/si_shader.h|  11 ++
 src/gallium/drivers/radeonsi/si_state_shaders.c |  17 ++-
 3 files changed, 180 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
b/src/gallium/drivers/radeonsi/si_shader.c
index a361418..7fc1df4 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -6593,20 +6593,167 @@ static void si_init_shader_ctx(struct 
si_shader_context *ctx,
bld_base->op_actions[TGSI_OPCODE_EMIT].emit = si_llvm_emit_vertex;
bld_base->op_actions[TGSI_OPCODE_ENDPRIM].emit = si_llvm_emit_primitive;
bld_base->op_actions[TGSI_OPCODE_BARRIER].emit = si_llvm_emit_barrier;
 
bld_base->op_actions[TGSI_OPCODE_MAX].emit = build_tgsi_intrinsic_nomem;
bld_base->op_actions[TGSI_OPCODE_MAX].intr_name = "llvm.maxnum.f32";
bld_base->op_actions[TGSI_OPCODE_MIN].emit = build_tgsi_intrinsic_nomem;
bld_base->op_actions[TGSI_OPCODE_MIN].intr_name = "llvm.minnum.f32";
 }
 
+/* Return true if the PARAM export has been eliminated. */
+static bool si_eliminate_const_output(struct si_shader_context *ctx,
+ LLVMValueRef inst, unsigned offset)
+{
+   struct si_shader *shader = ctx->shader;
+   unsigned num_outputs = shader->selector->info.num_outputs;
+   double v[4];
+   unsigned i, default_val; /* SPI_PS_INPUT_CNTL_i.DEFAULT_VAL */
+
+   for (i = 0; i < 4; i++) {
+   LLVMBool loses_info;
+   LLVMValueRef p = LLVMGetOperand(inst, 5 + i);
+   if (!LLVMIsConstant(p))
+   return false;
+
+   /* It's a constant expression. Undef outputs are eliminated 
too. */
+   if (LLVMIsUndef(p))
+   v[i] = 0;
+   else
+   v[i] = LLVMConstRealGetDouble(p, &loses_info);
+
+   if (v[i] != 0 && v[i] != 1)
+   return false;
+   }
+
+   /* Only certain combinations of 0 and 1 can be eliminated. */
+   if (v[0] == 0 && v[1] == 0 && v[2] == 0)
+   default_val = v[3] == 0 ? 0 : 1;
+   else if (v[0] == 1 && v[1] == 1 && v[2] == 1)
+   default_val = v[3] == 0 ? 2 : 3;
+   else
+   return false;
+
+   /* The PARAM export can be represented as DEFAULT_VAL. Kill it. */
+   LLVMInstructionEraseFromParent(inst);
+
+   /* Change OFFSET to DEFAULT_VAL. */
+   for (i = 0; i < num_outputs; i++) {
+   if (shader->info.vs_output_param_offset[i] == offset) {
+   shader->info.vs_output_param_offset[i] =
+   EXP_PARAM_DEFAULT_VAL_ + default_val;
+   break;
+   }
+   }
+   return true;
+}
+
+struct si_vs_exports {
+   unsigned num;
+   unsigned offset[SI_MAX_VS_OUTPUTS];
+   LLVMValueRef inst[SI_MAX_VS_OUTPUTS];
+};
+
+static void si_eliminate_const_vs_outputs(struct si_shader_context *ctx)
+{
+   struct si_shader *shader = ctx->shader;
+   struct tgsi_shader_info *info = &shader->selector->info;
+   LLVMBasicBlockRef bb;
+   struct si_vs_exports exports;
+   bool removed_any = false;
+
+   exports.num = 0;
+
+   if ((ctx->type == PIPE_SHADER_VERTEX &&
+(shader->key.vs.as_es || shader->key.vs.as_ls)) ||
+   (ctx->type == PIPE_SHADER_TESS_EVAL && shader->key.tes.as_es))
+   retu

Re: [Mesa-dev] [PATCH 6/6] radeonsi: rename prefixes from radeon to si

[Emil Velikov]

On 17 October 2016 at 14:44, Marek Olšák  wrote:
> From: Marek Olšák 
>
> ---
>  src/gallium/drivers/radeonsi/si_pipe.c |   2 +-
>  src/gallium/drivers/radeonsi/si_shader.c   |  96 ++---
>  src/gallium/drivers/radeonsi/si_shader_internal.h  |  70 +-
>  .../drivers/radeonsi/si_shader_tgsi_setup.c| 150 
> ++---
>  4 files changed, 159 insertions(+), 159 deletions(-)
>
From build POV everything is perfect thanks Marek ! For those
Reviewed-by: Emil Velikov 

Humble suggestion - set the following for friendlier patches ;-)
$ git config --global diff.renames true

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

Re: [Mesa-dev] [PATCH 6/6] radeonsi: rename prefixes from radeon to si

[Marek Olšák]

On Tue, Oct 18, 2016 at 6:28 PM, Emil Velikov  wrote:
> On 17 October 2016 at 14:44, Marek Olšák  wrote:
>> From: Marek Olšák 
>>
>> ---
>>  src/gallium/drivers/radeonsi/si_pipe.c |   2 +-
>>  src/gallium/drivers/radeonsi/si_shader.c   |  96 ++---
>>  src/gallium/drivers/radeonsi/si_shader_internal.h  |  70 +-
>>  .../drivers/radeonsi/si_shader_tgsi_setup.c| 150 
>> ++---
>>  4 files changed, 159 insertions(+), 159 deletions(-)
>>
> From build POV everything is perfect thanks Marek ! For those
> Reviewed-by: Emil Velikov 

Thanks.

>
> Humble suggestion - set the following for friendlier patches ;-)
> $ git config --global diff.renames true

I forgot to remove one (almost empty) file, so a rename wasn't
detected properly. I do send all my Mesa patches with git send-email
-M.

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

[Mesa-dev] [PATCH] svga: minor code improvements in svga_validate_pipe_sampler_view()

[Brian Paul]

Use the 'texture' local var in more places.
Rename 'pFormat' to 'viewFormat'.
---
 src/gallium/drivers/svga/svga_state_sampler.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/src/gallium/drivers/svga/svga_state_sampler.c 
b/src/gallium/drivers/svga/svga_state_sampler.c
index 53bb80f..445afcc 100644
--- a/src/gallium/drivers/svga/svga_state_sampler.c
+++ b/src/gallium/drivers/svga/svga_state_sampler.c
@@ -135,21 +135,21 @@ svga_validate_pipe_sampler_view(struct svga_context *svga,
   SVGA3dSurfaceFormat format;
   SVGA3dResourceType resourceDim;
   SVGA3dShaderResourceViewDesc viewDesc;
-  enum pipe_format pformat = sv->base.format;
+  enum pipe_format viewFormat = sv->base.format;
 
   /* vgpu10 cannot create a BGRX view for a BGRA resource, so force it to
* create a BGRA view (and vice versa).
*/
-  if (pformat == PIPE_FORMAT_B8G8R8X8_UNORM &&
-  sv->base.texture->format == PIPE_FORMAT_B8G8R8A8_UNORM) {
- pformat = PIPE_FORMAT_B8G8R8A8_UNORM;
+  if (viewFormat == PIPE_FORMAT_B8G8R8X8_UNORM &&
+  texture->format == PIPE_FORMAT_B8G8R8A8_UNORM) {
+ viewFormat = PIPE_FORMAT_B8G8R8A8_UNORM;
   }
-  else if (pformat == PIPE_FORMAT_B8G8R8A8_UNORM &&
-  sv->base.texture->format == PIPE_FORMAT_B8G8R8X8_UNORM) {
- pformat = PIPE_FORMAT_B8G8R8X8_UNORM;
+  else if (viewFormat == PIPE_FORMAT_B8G8R8A8_UNORM &&
+  texture->format == PIPE_FORMAT_B8G8R8X8_UNORM) {
+ viewFormat = PIPE_FORMAT_B8G8R8X8_UNORM;
   }
 
-  format = svga_translate_format(ss, pformat,
+  format = svga_translate_format(ss, viewFormat,
  PIPE_BIND_SAMPLER_VIEW);
   assert(format != SVGA3D_FORMAT_INVALID);
 
-- 
1.9.1

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

[Mesa-dev] [PATCH] egl/surfaceless: Fix segfault in eglSwapBuffers

[Chad Versace]

Since commit 63c5d5c6c46c8472ee7a8241a0f80f13d79cb8cd, the surfaceless
platform has allowed creation of pbuffer surfaces. But the vtable entry
for eglSwapBuffers has remained NULL.

Discovered by running a little pbuffer test.

Cc: Gurchetan Singh 
---
 src/egl/drivers/dri2/platform_surfaceless.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/src/egl/drivers/dri2/platform_surfaceless.c 
b/src/egl/drivers/dri2/platform_surfaceless.c
index fcf7d69..a55c5f1 100644
--- a/src/egl/drivers/dri2/platform_surfaceless.c
+++ b/src/egl/drivers/dri2/platform_surfaceless.c
@@ -178,6 +178,17 @@ dri2_surfaceless_create_pbuffer_surface(_EGLDriver *drv, 
_EGLDisplay *disp,
 }
 
 static EGLBoolean
+surfaceless_swap_buffers(_EGLDriver *drv, _EGLDisplay *disp, _EGLSurface *surf)
+{
+   assert(!surf || surf->Type == EGL_PBUFFER_BIT);
+
+   /* From the EGL 1.5 spec:
+*If surface is a [...] pbuffer surface, eglSwapBuffers has no effect.
+*/
+   return EGL_TRUE;
+}
+
+static EGLBoolean
 surfaceless_add_configs_for_visuals(_EGLDriver *drv, _EGLDisplay *dpy)
 {
struct dri2_egl_display *dri2_dpy = dri2_egl_display(dpy);
@@ -223,6 +234,7 @@ static struct dri2_egl_display_vtbl 
dri2_surfaceless_display_vtbl = {
.destroy_surface = surfaceless_destroy_surface,
.create_image = dri2_create_image_khr,
.swap_interval = dri2_fallback_swap_interval,
+   .swap_buffers = surfaceless_swap_buffers,
.swap_buffers_with_damage = dri2_fallback_swap_buffers_with_damage,
.swap_buffers_region = dri2_fallback_swap_buffers_region,
.post_sub_buffer = dri2_fallback_post_sub_buffer,
-- 
2.10.0

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

Re: [Mesa-dev] [PATCH v2 05/16] loader: reimplement loader_get_user_preferred_fd via libdrm

[Nicolai Hähnle]

On 18.10.2016 18:01, Emil Velikov wrote:

On 18 October 2016 at 09:49, Nicolai Hähnle  wrote:

On 14.10.2016 20:21, Emil Velikov wrote:


From: Emil Velikov 

Currently not everyone has libudev and with follow-up patches we'll
completely remove the divergent codepaths.

Use the libdrm drm device API to construct the required ID_PATH_TAG-like
string, to preserve the current functionality for libudev users and
allow others to benefit from it as well.

v2: Drop ranty comments, pick the correct device

Cc: Axel Davy 
Signed-off-by: Emil Velikov 
---
 src/loader/loader.c | 247
++--
 1 file changed, 106 insertions(+), 141 deletions(-)

diff --git a/src/loader/loader.c b/src/loader/loader.c
index ad4f946..06df05b 100644
--- a/src/loader/loader.c
+++ b/src/loader/loader.c


[snip]


@@ -321,17 +232,60 @@ static char *loader_get_dri_config_device_id(void)
 }
 #endif

+static char *drm_construct_id_path_tag(drmDevicePtr device)
+{
+/* Length of "pci-_xx_xx_x\n" */
+#define PCI_ID_PATH_TAG_LENGTH 17
+   char *tag = NULL;
+
+   if (device->bustype == DRM_BUS_PCI) {
+tag = calloc(PCI_ID_PATH_TAG_LENGTH, sizeof(char));
+if (tag == NULL)
+return NULL;
+
+sprintf(tag, "pci-%04x_%02x_%02x_%1u",
device->businfo.pci->domain,
+device->businfo.pci->bus, device->businfo.pci->dev,
+device->businfo.pci->func);



Defensive programming would suggest to use snprintf.


Correct. It's more like extra defensive in this case but will fix.


Thanks :)



[snip]


@@ -345,55 +299,66 @@ int loader_get_user_preferred_fd(int default_fd, int
*different_device)
   return default_fd;
}

-   udev = udev_new();
-   if (!udev)
-  goto prime_clean;
+   default_tag = drm_get_id_path_tag_for_fd(default_fd);
+   if (default_tag == NULL)
+  goto err;

-   default_device_id_path_tag = get_id_path_tag_from_fd(udev,
default_fd);
-   if (!default_device_id_path_tag)
-  goto udev_clean;
+   num_devices = drmGetDevices(devices, MAX_DRM_DEVICES);
+   if (num_devices < 0)
+  goto err;

-   is_different_device = 1;
/* two format are supported:
 * "1": choose any other card than the card used by default.
 * id_path_tag: (for example "pci-_02_00_0") choose the card
 * with this id_path_tag.
 */
if (!strcmp(prime,"1")) {
-  free(prime);
-  prime = strdup(default_device_id_path_tag);
-  /* request a card with a different card than the default card */
-  another_tag = 1;
-   } else if (!strcmp(default_device_id_path_tag, prime))
-  /* we are to get a new fd (render-node) of the same device */
-  is_different_device = 0;
-
-   device_name = get_render_node_from_id_path_tag(udev,
-  prime,
-  another_tag);
-   if (device_name == NULL) {
-  is_different_device = 0;
-  goto default_device_clean;
+  /* Hmm... detection for 2-7 seems to be broken. Oh well ...
+   * Pick the first render device that is not our own.
+   */
+  for (i = 0; i < num_devices; i++) {
+ if (devices[i]->available_nodes & 1 << DRM_NODE_RENDER &&
+ !drm_device_matches_tag(devices[i], default_tag)) {
+
+found = true;
+break;
+ }
+  }
+   } else {
+  for (i = 0; i < num_devices; i++) {
+ if (devices[i]->available_nodes & 1 << DRM_NODE_RENDER &&
+drm_device_matches_tag(devices[i], prime)) {
+
+found = true;
+break;
+ }
+  }



I feel like it would be helpful to have a warning here if the device was not
found. This could avoid some confusion when people inevitably typo their
prime setting.


Original code does not have such a message, so let's add it as follow-up ?


Fine by me.

Cheers,
Nicolai



Emil


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

Re: [Mesa-dev] [PATCH 2/2] st/glsl_to_tgsi: fix block copies of arrays of structs

[Marek Olšák]

For the series:

Reviewed-by: Marek Olšák 

Marek

On Mon, Oct 17, 2016 at 7:25 PM, Nicolai Hähnle  wrote:
> From: Nicolai Hähnle 
>
> Use a full writemask in this case. This is relevant e.g. when a function
> has an inout argument which is an array of structs.
> ---
>  src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
> b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> index 1662f7f..b91ebaf 100644
> --- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> +++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> @@ -2964,24 +2964,26 @@ glsl_to_tgsi_visitor::visit(ir_assignment *ir)
>
>   if (variable->data.location == FRAG_RESULT_DEPTH)
>  l.writemask = WRITEMASK_Z;
>   else {
>  assert(variable->data.location == FRAG_RESULT_STENCIL);
>  l.writemask = WRITEMASK_Y;
>   }
>} else if (ir->write_mask == 0) {
>   assert(!ir->lhs->type->is_scalar() && !ir->lhs->type->is_vector());
>
> - if (ir->lhs->type->is_array() || ir->lhs->type->is_matrix()) {
> -unsigned num_elements = 
> ir->lhs->type->without_array()->vector_elements;
> + unsigned num_elements = 
> ir->lhs->type->without_array()->vector_elements;
> +
> + if (num_elements) {
>  l.writemask = u_bit_consecutive(0, num_elements);
>   } else {
> +// The type is a struct or an array of (array of) structs.
>  l.writemask = WRITEMASK_XYZW;
>   }
>} else {
>   l.writemask = ir->write_mask;
>}
>
>for (int i = 0; i < 4; i++) {
>   if (l.writemask & (1 << i)) {
>  first_enabled_chan = GET_SWZ(r.swizzle, i);
>  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

Re: [Mesa-dev] [PATCH] glsl: optimize list handling in opt_dead_code

[Jan Ziak]

> Regarding C++ templates, the compiler doesn't use them. If u_vector
> (Dave Airlie?) provides the same functionality as your array, I
> suggest we use u_vector instead.

Let me repeat what you just wrote, because it is unbelievable: You are
advising the use of non-templated collection types in C++ code.

> If you can't use u_vector, you should
> ask for approval from GLSL compiler leads (e.g. Ian Romanick or
> Kenneth Graunke) to use C++ templates.

- You are talking about coding rules some Mesa developers agreed upon
and didn't bother writing down for other developers to read

- I am not willing to use u_vector in C++ code

> I'll repeat some stuff about profiling here but also explain my perspective.

So far (which may be a year or so), there is no indication that you
are better at optimizing code than me.

> Never profile with -O0 or disabled function inlining.

Seriously?

> Mesa uses -g -O2
> with --enable-debug, so that's what you should use too. Don't use any
> other -O* variants.

What if I find a case where -O2 prevents me from easily seeing
information necessary to optimize the source code?

> The only profiling tools reporting correct results are perf and
> sysprof.

I used perf on Metro 2033 Redux and saw do_dead_code() there. Then I
used callgrind to see some more code.

> (both use the same mechanism) If you don't enable dwarf in
> perf (also sysprof can't use dwarf), you have to build Mesa with
> -fno-omit-frame-pointer to see call trees. The only reason you would
> want to enable dwarf-based call trees is when you want to see libc
> calls. Otherwise, they won't be displayed or counted as part of call
> trees. For Mesa developers who do profiling often,
> -fno-omit-frame-pointer should be your default.

> Callgrind counts calls (that one you can trust), but the reported time
> is incorrect,

Are you nuts? You cannot be seriously be assuming that I didn't know about that.

> because it uses its own virtual model of a CPU. Avoid it
> if you want to measure time spent in functions.

I will *NOT* avoid callgrind because I know how to use it to optimize code.

>Marek

As usual, I would like to notify reviewers&mergers of this path that I
am not willing to wait months to learn whether the code will be merged
or rejected.

If it isn't merged by Thursday (2016-oct-20) I will mark it as
rejected (rejected based on personal rather than scientific grounds).

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

Re: [Mesa-dev] [PATCH 08/11] anv: move to using vk_alloc helpers.

[Emil Velikov]

Hi Dave,

On 17 October 2016 at 03:07, Dave Airlie  wrote:
> From: Dave Airlie 
>
> This moves all the alloc/free in anv to the generic helpers.
>
> Signed-off-by: Dave Airlie 
> ---
>  src/intel/vulkan/anv_batch_chain.c| 40 +++---
>  src/intel/vulkan/anv_cmd_buffer.c | 22 -
>  src/intel/vulkan/anv_descriptor_set.c | 12 -
>  src/intel/vulkan/anv_device.c | 26 ++--
>  src/intel/vulkan/anv_image.c  | 14 +--
>  src/intel/vulkan/anv_intel.c  |  4 +--
>  src/intel/vulkan/anv_pass.c   | 10 
>  src/intel/vulkan/anv_pipeline.c   |  6 ++---
>  src/intel/vulkan/anv_pipeline_cache.c |  8 +++---
>  src/intel/vulkan/anv_private.h| 46 
> +--
>  src/intel/vulkan/anv_query.c  |  6 ++---
>  src/intel/vulkan/anv_wsi.c|  2 +-
>  src/intel/vulkan/anv_wsi_wayland.c| 16 ++--
>  src/intel/vulkan/anv_wsi_x11.c| 22 -
>  src/intel/vulkan/gen7_pipeline.c  |  4 +--
>  src/intel/vulkan/gen8_pipeline.c  |  4 +--
>  src/intel/vulkan/genX_pipeline.c  |  6 ++---
>  src/intel/vulkan/genX_state.c |  2 +-
>  18 files changed, 103 insertions(+), 147 deletions(-)
>
Wondering we one shouldn't include the new header only where needed ?
Quick grep shows 33 files which include anv_private.h of which (as per
above) ~half only need vk_alloc.h.

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

Re: [Mesa-dev] [PATCH 3/3] [Bug 38970] [bisected]piglit glx/glx-pixmap-multi failed

[Ian Romanick]

On 09/29/2016 01:55 PM, Anutex wrote:
> I tried to debug this issue with changing the condition to check only bad 
> magic and Error.
> And the test passed.
> 
> Though i am not sure what is the correct behaviour if we are in this 
> condition.
> May be we should make some  other condition if the Hash Table have the bucket 
> data.
> ---
>  src/glx/dri2_glx.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
> index af388d9..a1fd9ff 100644
> --- a/src/glx/dri2_glx.c
> +++ b/src/glx/dri2_glx.c
> @@ -411,12 +411,13 @@ dri2CreateDrawable(struct glx_screen *base, XID 
> xDrawable,
>return NULL;
> }
>  
> -   if (__glxHashInsert(pdp->dri2Hash, xDrawable, pdraw)) {
> +   if (__glxHashInsert(pdp->dri2Hash, xDrawable, pdraw) == -1) {

I'm not 100% sure the existing code is wrong.  __glxHashInsert returns
-1 for an error, and it returns 1 if the key is already in the hash
table.  In that case we'll leak the memory for the new pdraw, right?
That also seems bad.

It seems like instead the code should look up xDrawable in the hash
table and return the value that's already there.  Maybe.  I haven't
looked at this code in years, so I may be forgetting some subtlety.

>(*psc->core->destroyDrawable) (pdraw->driDrawable);
>DRI2DestroyDrawable(psc->base.dpy, xDrawable);
>free(pdraw);
>return None;
> }
> + 
>  

Spurious whitespace change.

> /*
>  * Make sure server has the same swap interval we do for the new
> 

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

Re: [Mesa-dev] [PATCH 11/11] anv: drop pointless struct decl.

[Emil Velikov]

On 17 October 2016 at 03:07, Dave Airlie  wrote:
> From: Dave Airlie 
>
> Signed-off-by: Dave Airlie 
Seems like a typo from the development stage - anv_wsi_inter_a_face

10 and 11 are independent so feel free to land whenever possible.
Reviewed-by: Emil Velikov 

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

Re: [Mesa-dev] [PATCH 01/22] radv/anv/wsi: drop uneeded parameter

[Emil Velikov]

Typo in the summary - s/uneeded/unneeded/

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

Re: [Mesa-dev] [PATCH 07/25] mesa/i965: eliminate gl_tess_ctrl_program and use new shared shader_info

[Jason Ekstrand]

On Tue, Oct 18, 2016 at 8:28 AM, Jason Ekstrand 
wrote:

> On Tue, Oct 18, 2016 at 8:14 AM, Jason Ekstrand 
> wrote:
>
>> I want to make a few comments on how this series is structured.  This is
>> not the way I would have done it and I think the way you structured it
>> makes it substantially less rebasable than it could be and a bit harder to
>> review.  The way *I* would have done this would be something like the
>> following:
>>
>>  1) Move shader_info to common code (patches 1-2)
>>  2) Add a shader_info pointer to gl_program (patch 6), break the fill
>> shader_info stuff from glsl_to_nir into its own function, and call it from
>> somewhere such that it always gets filled out.
>>  3) Add new fields to shader_info *and* make sure they get filled out
>> from other GLSL information
>>  4) Convert i965 over to the new shader_info
>>  5) Convert gallium over to the new shader_info
>>  6) Make GLSL fill out shader_info directly and nuke the old shader
>> metadata.
>>  7) Delete the shader_info fill-out function.
>>
>
Oh, and one more step:

 8) Refactor to get rid of all of the gl_foo_program stuff.  (Maybe
multiple patches?)


>
>> Something along these lines would go a long way towards avoiding the
>> "mega patch" problem where each patch touches 4 or 5 different components.
>> It also makes it clearer to review because you don't add fields and then
>> the reviewer goes "Wait, where does this get set?  Oh, in another patch".
>> I'm not necessarily saying that you have to go back and change your
>> patches.  It's more a suggestion for if you end up doing a v3 or another
>> refactor along these lines in the future.
>>
>
> On the review side, splitting out as I described above would make it much
> easier to review since it would be more-or-less one type of refactor per
> patch.  In this patch, we have several different kinds of refactors:
>
>  1) Move consumers over to reading shader_info
>  2) Remove gl_tess_ctrl_program and related refactors
>  3) Move producer over to writing shader_info
>
> Normally, when reviewing, I would just skim (2) and give (1) a (3) more
> effort.  Having them mixed together means I have to pay constant attention
> to what's going on.  Also, having (2) mixed in makes it harder to verify
> (3) because there's a lot of code motion only some of which matters.
>
>
>>
>>
>> On Mon, Oct 17, 2016 at 11:12 PM, Timothy Arceri <
>> timothy.arc...@collabora.com> wrote:
>>
>>> ---
>>>  src/mesa/drivers/dri/i965/brw_context.h   |  6 ++---
>>>  src/mesa/drivers/dri/i965/brw_draw.c  |  2 +-
>>>  src/mesa/drivers/dri/i965/brw_program.c   |  2 +-
>>>  src/mesa/drivers/dri/i965/brw_tcs.c   | 32
>>> ++-
>>>  src/mesa/drivers/dri/i965/brw_tcs_surface_state.c |  2 +-
>>>  src/mesa/drivers/dri/i965/brw_tes.c   | 20 +++---
>>>  src/mesa/drivers/dri/i965/gen7_hs_state.c |  4 +--
>>>  src/mesa/main/context.c   |  2 +-
>>>  src/mesa/main/mtypes.h| 12 +
>>>  src/mesa/main/shaderapi.c |  4 +--
>>>  src/mesa/main/state.c | 11 
>>>  src/mesa/program/prog_statevars.c |  2 +-
>>>  src/mesa/program/program.c|  4 +--
>>>  src/mesa/program/program.h| 23 
>>>  src/mesa/state_tracker/st_atom.c  |  2 +-
>>>  src/mesa/state_tracker/st_atom_constbuf.c |  2 +-
>>>  src/mesa/state_tracker/st_atom_sampler.c  |  2 +-
>>>  src/mesa/state_tracker/st_atom_shader.c   |  2 +-
>>>  src/mesa/state_tracker/st_atom_texture.c  |  2 +-
>>>  src/mesa/state_tracker/st_cb_program.c| 10 +++
>>>  src/mesa/state_tracker/st_program.c   |  6 ++---
>>>  src/mesa/state_tracker/st_program.h   |  6 ++---
>>>  22 files changed, 58 insertions(+), 100 deletions(-)
>>>
>>> diff --git a/src/mesa/drivers/dri/i965/brw_context.h
>>> b/src/mesa/drivers/dri/i965/brw_context.h
>>> index c92bb9f..9b7e184 100644
>>> --- a/src/mesa/drivers/dri/i965/brw_context.h
>>> +++ b/src/mesa/drivers/dri/i965/brw_context.h
>>> @@ -337,7 +337,7 @@ struct brw_vertex_program {
>>>
>>>  /** Subclass of Mesa tessellation control program */
>>>  struct brw_tess_ctrl_program {
>>> -   struct gl_tess_ctrl_program program;
>>> +   struct gl_program program;
>>> unsigned id;  /**< serial no. to identify tess ctrl progs, never
>>> re-used */
>>>  };
>>>
>>> @@ -1008,7 +1008,7 @@ struct brw_context
>>>  */
>>> const struct gl_vertex_program *vertex_program;
>>> const struct gl_geometry_program *geometry_program;
>>> -   const struct gl_tess_ctrl_program *tess_ctrl_program;
>>> +   const struct gl_program *tess_ctrl_program;
>>> const struct gl_tess_eval_program *tess_eval_program;
>>> const struct gl_fragment_program *fragment_program;
>>> const struct gl_compute_program *compute_program

Re: [Mesa-dev] [PATCH 07/22] anv/wsi/x11: abstract WSI interface from internals.

[Emil Velikov]

On 17 October 2016 at 05:24, Dave Airlie  wrote:
> From: Dave Airlie 
>
> This allows the API and the internals to be split, and the
> internals shared.
> ---
>  src/intel/vulkan/anv_wsi_x11.c | 33 -
>  1 file changed, 24 insertions(+), 9 deletions(-)
>
> diff --git a/src/intel/vulkan/anv_wsi_x11.c b/src/intel/vulkan/anv_wsi_x11.c
> index ccaabea..6eb06c3 100644
> --- a/src/intel/vulkan/anv_wsi_x11.c
> +++ b/src/intel/vulkan/anv_wsi_x11.c
> @@ -233,16 +233,15 @@ visual_has_alpha(xcb_visualtype_t *visual, unsigned 
> depth)
> return (all_mask & ~rgb_mask) != 0;
>  }
>
> -VkBool32 anv_GetPhysicalDeviceXcbPresentationSupportKHR(
> -VkPhysicalDevicephysicalDevice,
> +static VkBool32 anv_get_physical_device_xcb_presentation_support(
> +struct anv_wsi_device *wsi_device,
> +VkAllocationCallbacks *alloc,
Nit: indentation (here and below) seems off.

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

Re: [Mesa-dev] [PATCH 07/25] mesa/i965: eliminate gl_tess_ctrl_program and use new shared shader_info

[Kenneth Graunke]

On Tuesday, October 18, 2016 8:28:02 AM PDT Jason Ekstrand wrote:
> On Tue, Oct 18, 2016 at 8:14 AM, Jason Ekstrand 
> wrote:
> 
> > I want to make a few comments on how this series is structured.  This is
> > not the way I would have done it and I think the way you structured it
> > makes it substantially less rebasable than it could be and a bit harder to
> > review.  The way *I* would have done this would be something like the
> > following:
> >
> >  1) Move shader_info to common code (patches 1-2)
> >  2) Add a shader_info pointer to gl_program (patch 6), break the fill
> > shader_info stuff from glsl_to_nir into its own function, and call it from
> > somewhere such that it always gets filled out.
> >  3) Add new fields to shader_info *and* make sure they get filled out from
> > other GLSL information
> >  4) Convert i965 over to the new shader_info
> >  5) Convert gallium over to the new shader_info
> >  6) Make GLSL fill out shader_info directly and nuke the old shader
> > metadata.
> >  7) Delete the shader_info fill-out function.
> >
> > Something along these lines would go a long way towards avoiding the "mega
> > patch" problem where each patch touches 4 or 5 different components.  It
> > also makes it clearer to review because you don't add fields and then the
> > reviewer goes "Wait, where does this get set?  Oh, in another patch".  I'm
> > not necessarily saying that you have to go back and change your patches.
> > It's more a suggestion for if you end up doing a v3 or another refactor
> > along these lines in the future.
> >
> 
> On the review side, splitting out as I described above would make it much
> easier to review since it would be more-or-less one type of refactor per
> patch.  In this patch, we have several different kinds of refactors:
> 
>  1) Move consumers over to reading shader_info
>  2) Remove gl_tess_ctrl_program and related refactors
>  3) Move producer over to writing shader_info
> 
> Normally, when reviewing, I would just skim (2) and give (1) a (3) more
> effort.  Having them mixed together means I have to pay constant attention
> to what's going on.  Also, having (2) mixed in makes it harder to verify
> (3) because there's a lot of code motion only some of which matters.

I agree with Jason.  This could be structured a lot more cleanly, and it
would make it much easier to review.

For example, patches 3-5 add a bunch of new structure fields.  But they
aren't populated by anything.  The CS local_size_variable field finally
gets populated in patch 12 (a whole 7 patches later!)...and by the end
of the series...I don't see a single consumer of that field.

So, the field is useless.  But I had to use 'git log -p' on a branch and
search through your entire series to determine that.  There's far too
much context to keep in my head while reading, and it means I have to
abandon my usual read-emails-mostly-in-order review process.

I actually added TES shader info a little while back (but hadn't sent
them out yet as Vulkan tessellation isn't quite ready yet).  Here's what
my patches looked like:

1) Convert spacing from GLenums to a TESS_SPACING_* enum
https://cgit.freedesktop.org/~kwg/mesa/commit/?h=vktess&id=8b49a8485dd37eb405efcaaecd55244a8f63f213
   (simple cleanup I did across the whole codebase)

2) Introduce nir_shader_info fields and populate them in glsl_to_nir and
   spirv_to_nir.
https://cgit.freedesktop.org/~kwg/mesa/commit/?h=vktess&id=3142efa913965324ad21c3cefc792ab83e1a1390
   (fields are at least populated in all frontends, but may be useless)

3) Convert i965 over to use nir_shader_info for fields
https://cgit.freedesktop.org/~kwg/mesa/commit/?h=vktess&id=a518388acc7a6db88c7e21829e7a15b15b9304ad
   (now the fields are used.  admittedly I did some bonus code motion in
this patch...if I'm being pedantic, I should have made that a fourth
patch to make the prog_data fields be populated in Vulkan paths)

The first patch stands alone, and patches 2-3 stand together.  All are
very small.  You need no additional context to answer questions, and can
say "those look good" and move on rather quickly.

With that in mind, I'd like to ask you to please try and rework this
series along the lines that Jason suggested.  I know it's a bunch of
work, but being disciplined in how we organize our code is a really
useful skill that pays off in the long run.  When reviewers can look
at your code and quickly give a thumbs up, you get to land your patches
a lot more quickly, and that extra effort ultimately saves you (and
others) a whole lot of time.

Sorry, Tim :(

--Ken


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] [PATCH] egl/surfaceless: Fix segfault in eglSwapBuffers

[Anuj Phogat]

On Tue, Oct 18, 2016 at 9:43 AM, Chad Versace  wrote:
> Since commit 63c5d5c6c46c8472ee7a8241a0f80f13d79cb8cd, the surfaceless
> platform has allowed creation of pbuffer surfaces. But the vtable entry
> for eglSwapBuffers has remained NULL.
>
> Discovered by running a little pbuffer test.
>
> Cc: Gurchetan Singh 
> ---
>  src/egl/drivers/dri2/platform_surfaceless.c | 12 
>  1 file changed, 12 insertions(+)
>
> diff --git a/src/egl/drivers/dri2/platform_surfaceless.c 
> b/src/egl/drivers/dri2/platform_surfaceless.c
> index fcf7d69..a55c5f1 100644
> --- a/src/egl/drivers/dri2/platform_surfaceless.c
> +++ b/src/egl/drivers/dri2/platform_surfaceless.c
> @@ -178,6 +178,17 @@ dri2_surfaceless_create_pbuffer_surface(_EGLDriver *drv, 
> _EGLDisplay *disp,
>  }
>
>  static EGLBoolean
> +surfaceless_swap_buffers(_EGLDriver *drv, _EGLDisplay *disp, _EGLSurface 
> *surf)
> +{
> +   assert(!surf || surf->Type == EGL_PBUFFER_BIT);
> +
> +   /* From the EGL 1.5 spec:
> +*If surface is a [...] pbuffer surface, eglSwapBuffers has no effect.
> +*/
> +   return EGL_TRUE;
> +}
> +
> +static EGLBoolean
>  surfaceless_add_configs_for_visuals(_EGLDriver *drv, _EGLDisplay *dpy)
>  {
> struct dri2_egl_display *dri2_dpy = dri2_egl_display(dpy);
> @@ -223,6 +234,7 @@ static struct dri2_egl_display_vtbl 
> dri2_surfaceless_display_vtbl = {
> .destroy_surface = surfaceless_destroy_surface,
> .create_image = dri2_create_image_khr,
> .swap_interval = dri2_fallback_swap_interval,
> +   .swap_buffers = surfaceless_swap_buffers,
> .swap_buffers_with_damage = dri2_fallback_swap_buffers_with_damage,
> .swap_buffers_region = dri2_fallback_swap_buffers_region,
> .post_sub_buffer = dri2_fallback_post_sub_buffer,
> --
> 2.10.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Mesa-dev] [PATCH] st/mesa: disable alpha-test, alpha-to-coverage, alpha-to-one for integer FBs

[Marek Olšák]

From: Marek Olšák 

v2: rebased
---
 src/mesa/state_tracker/st_atom_blend.c | 3 ++-
 src/mesa/state_tracker/st_atom_depth.c | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/mesa/state_tracker/st_atom_blend.c 
b/src/mesa/state_tracker/st_atom_blend.c
index 76d6a644..b8d65bd 100644
--- a/src/mesa/state_tracker/st_atom_blend.c
+++ b/src/mesa/state_tracker/st_atom_blend.c
@@ -259,21 +259,22 @@ update_blend( struct st_context *st )
  blend->rt[i].colormask |= PIPE_MASK_G;
   if (ctx->Color.ColorMask[i][2])
  blend->rt[i].colormask |= PIPE_MASK_B;
   if (ctx->Color.ColorMask[i][3])
  blend->rt[i].colormask |= PIPE_MASK_A;
}
 
blend->dither = ctx->Color.DitherFlag;
 
if (ctx->Multisample.Enabled &&
-   ctx->DrawBuffer->Visual.sampleBuffers > 0) {
+   ctx->DrawBuffer->Visual.sampleBuffers > 0 &&
+   !(ctx->DrawBuffer->_IntegerBuffers & 0x1)) {
   /* Unlike in gallium/d3d10 these operations are only performed
* if both msaa is enabled and we have a multisample buffer.
*/
   blend->alpha_to_coverage = ctx->Multisample.SampleAlphaToCoverage;
   blend->alpha_to_one = ctx->Multisample.SampleAlphaToOne;
}
 
cso_set_blend(st->cso_context, blend);
 
{
diff --git a/src/mesa/state_tracker/st_atom_depth.c 
b/src/mesa/state_tracker/st_atom_depth.c
index 267b42c..7092c3f 100644
--- a/src/mesa/state_tracker/st_atom_depth.c
+++ b/src/mesa/state_tracker/st_atom_depth.c
@@ -142,21 +142,22 @@ update_depth_stencil_alpha(struct st_context *st)
   else {
  /* This should be unnecessary. Drivers must not expect this to
   * contain valid data, except the enabled bit
   */
  dsa->stencil[1] = dsa->stencil[0];
  dsa->stencil[1].enabled = 0;
  sr.ref_value[1] = sr.ref_value[0];
   }
}
 
-   if (ctx->Color.AlphaEnabled) {
+   if (ctx->Color.AlphaEnabled &&
+   !(ctx->DrawBuffer->_IntegerBuffers & 0x1)) {
   dsa->alpha.enabled = 1;
   dsa->alpha.func = st_compare_func_to_pipe(ctx->Color.AlphaFunc);
   dsa->alpha.ref_value = ctx->Color.AlphaRefUnclamped;
}
 
cso_set_depth_stencil_alpha(st->cso_context, dsa);
cso_set_stencil_ref(st->cso_context, &sr);
 }
 
 
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH] st/mesa: disable alpha-test, alpha-to-coverage, alpha-to-one for integer FBs

[Brian Paul]

Reviewed-by: Brian Paul 


On 10/18/2016 11:48 AM, Marek Olšák wrote:

From: Marek Olšák 

v2: rebased
---
  src/mesa/state_tracker/st_atom_blend.c | 3 ++-
  src/mesa/state_tracker/st_atom_depth.c | 3 ++-
  2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/mesa/state_tracker/st_atom_blend.c 
b/src/mesa/state_tracker/st_atom_blend.c
index 76d6a644..b8d65bd 100644
--- a/src/mesa/state_tracker/st_atom_blend.c
+++ b/src/mesa/state_tracker/st_atom_blend.c
@@ -259,21 +259,22 @@ update_blend( struct st_context *st )
   blend->rt[i].colormask |= PIPE_MASK_G;
if (ctx->Color.ColorMask[i][2])
   blend->rt[i].colormask |= PIPE_MASK_B;
if (ctx->Color.ColorMask[i][3])
   blend->rt[i].colormask |= PIPE_MASK_A;
 }

 blend->dither = ctx->Color.DitherFlag;

 if (ctx->Multisample.Enabled &&
-   ctx->DrawBuffer->Visual.sampleBuffers > 0) {
+   ctx->DrawBuffer->Visual.sampleBuffers > 0 &&
+   !(ctx->DrawBuffer->_IntegerBuffers & 0x1)) {
/* Unlike in gallium/d3d10 these operations are only performed
 * if both msaa is enabled and we have a multisample buffer.
 */
blend->alpha_to_coverage = ctx->Multisample.SampleAlphaToCoverage;
blend->alpha_to_one = ctx->Multisample.SampleAlphaToOne;
 }

 cso_set_blend(st->cso_context, blend);

 {
diff --git a/src/mesa/state_tracker/st_atom_depth.c 
b/src/mesa/state_tracker/st_atom_depth.c
index 267b42c..7092c3f 100644
--- a/src/mesa/state_tracker/st_atom_depth.c
+++ b/src/mesa/state_tracker/st_atom_depth.c
@@ -142,21 +142,22 @@ update_depth_stencil_alpha(struct st_context *st)
else {
   /* This should be unnecessary. Drivers must not expect this to
* contain valid data, except the enabled bit
*/
   dsa->stencil[1] = dsa->stencil[0];
   dsa->stencil[1].enabled = 0;
   sr.ref_value[1] = sr.ref_value[0];
}
 }

-   if (ctx->Color.AlphaEnabled) {
+   if (ctx->Color.AlphaEnabled &&
+   !(ctx->DrawBuffer->_IntegerBuffers & 0x1)) {
dsa->alpha.enabled = 1;
dsa->alpha.func = st_compare_func_to_pipe(ctx->Color.AlphaFunc);
dsa->alpha.ref_value = ctx->Color.AlphaRefUnclamped;
 }

 cso_set_depth_stencil_alpha(st->cso_context, dsa);
 cso_set_stencil_ref(st->cso_context, &sr);
  }





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

[Mesa-dev] [PATCH] nv50/ir: silent TGSI_PROPERTY_FS_DEPTH_LAYOUT

[Samuel Pitoiset]

Found that information message while replaying a trace from
Metro 2033 Redux. Mark that property as useless for now.

Signed-off-by: Samuel Pitoiset 
---
 src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
index db03281..0c98744 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
@@ -1093,6 +1093,7 @@ void Source::scanProperty(const struct tgsi_full_property 
*prop)
   break;
case TGSI_PROPERTY_FS_COORD_ORIGIN:
case TGSI_PROPERTY_FS_COORD_PIXEL_CENTER:
+   case TGSI_PROPERTY_FS_DEPTH_LAYOUT:
   // we don't care
   break;
case TGSI_PROPERTY_VS_PROHIBIT_UCPS:
-- 
2.10.0

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

Re: [Mesa-dev] [PATCH] nv50/ir: silent TGSI_PROPERTY_FS_DEPTH_LAYOUT

[Ilia Mirkin]

Reviewed-by: Ilia Mirkin 

This comes into play with Zcull, I think. But since we don't do Zcull
yet, wtvr. I had a patch to convert it into a
layout(early_fragment_tests) effectively if the various settings
matched, but ultimately it didn't seem worthwhile.

  -ilia


On Tue, Oct 18, 2016 at 1:59 PM, Samuel Pitoiset
 wrote:
> Found that information message while replaying a trace from
> Metro 2033 Redux. Mark that property as useless for now.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp 
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
> index db03281..0c98744 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
> @@ -1093,6 +1093,7 @@ void Source::scanProperty(const struct 
> tgsi_full_property *prop)
>break;
> case TGSI_PROPERTY_FS_COORD_ORIGIN:
> case TGSI_PROPERTY_FS_COORD_PIXEL_CENTER:
> +   case TGSI_PROPERTY_FS_DEPTH_LAYOUT:
>// we don't care
>break;
> case TGSI_PROPERTY_VS_PROHIBIT_UCPS:
> --
> 2.10.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] nv50/ir: Split 64-bit integer MAD/MUL operations

[Pierre Moreau]

Hello Ian,

Since I am working on a direct SPIR-V to NV50 IR translator, ultimately to be
used for OpenCL kernels, I will still need the patch for that work. (I even
wrote that patch because I needed it when handling 64-bit addresses. :-) )
But thanks for the heads-up!

Pierre


On 02:07 pm - Oct 17 2016, Ian Romanick wrote:
> I know know if it will make this patch unnecessary, but I have a GLSL
> IR-level lowering pass for 64-bit multiplication.  I'm going to send
> that out with the rest of the GL_ARB_gpu_shader_int64 series within the
> next day or so.
> 
> On 10/15/2016 03:24 PM, Pierre Moreau wrote:
> > Hardware does not support 64-bit integers MAD and MUL operations, so we need
> > to transform them in 32-bit operations.
> > 
> > Signed-off-by: Pierre Moreau 
> > ---
> >  .../drivers/nouveau/codegen/nv50_ir_peephole.cpp   | 121 
> > +
> >  1 file changed, 121 insertions(+)
> > 
> > Tested with (the GPU result was compared to the CPU result):
> > * 0xfff3lu * 0xfff2lu + 0x80070002lu
> > * 0xfff3lu * 0x80070002lu + 0x80070002lu
> > * 0x80010003lu * 0xfff2lu + 0x80070002lu
> > * 0x80010003lu * 0x80070002lu + 0x80070002lu
> > 
> > * -523456791234l * 929835793793l + -15793793l
> > *  523456791234l * 929835793793l + -15793793l
> > * -523456791234l * -929835793793l + -15793793l
> > *  523456791234l * -929835793793l + -15793793l
> > 
> > v2:
> > * Completely re-write the patch, as it was completely flawed (Ilia Mirkin)
> > * Move pass prior to Register Allocation, as some temporaries need to
> >   be created.
> > 
> > diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp 
> > b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
> > index d88bb34..a610eb5 100644
> > --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
> > +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
> > @@ -2218,6 +2218,126 @@ LateAlgebraicOpt::visit(Instruction *i)
> >  
> >  // 
> > =
> >  
> > +// Split 64-bit MUL and MAD
> > +class Split64BitOpPreRA : public Pass
> > +{
> > +private:
> > +   virtual bool visit(BasicBlock *);
> > +   void split64BitReg(Function *, Instruction *, Instruction *,
> > +  Instruction *, Value *, int);
> > +   void split64MulMad(Function *, Instruction *, DataType);
> > +
> > +   BuildUtil bld;
> > +};
> > +
> > +bool
> > +Split64BitOpPreRA::visit(BasicBlock *bb)
> > +{
> > +   Instruction *i, *next;
> > +   Modifier mod;
> > +
> > +   for (i = bb->getEntry(); i; i = next) {
> > +  next = i->next;
> > +
> > +  if (typeSizeof(i->dType) != 8)
> > + continue;
> > +
> > +  DataType hTy;
> > +  switch (i->dType) {
> > +  case TYPE_U64: hTy = TYPE_U32; break;
> > +  case TYPE_S64: hTy = TYPE_S32; break;
> > +  default:
> > + continue;
> > +  }
> > +
> > +  if (i->op == OP_MAD || i->op == OP_MUL)
> > + split64MulMad(bb->getFunction(), i, hTy);
> > +   }
> > +
> > +   return true;
> > +}
> > +
> > +void
> > +Split64BitOpPreRA::split64MulMad(Function *fn, Instruction *i, DataType 
> > hTy)
> > +{
> > +   assert(i->op == OP_MAD || i->op == OP_MUL);
> > +   if (isFloatType(i->dType) || isFloatType(i->sType))
> > +  return;
> > +
> > +   bld.setPosition(i, true);
> > +
> > +   Value *zero = bld.mkImm(0u);
> > +   Value *carry = bld.getSSA(1, FILE_FLAGS);
> > +
> > +   // We want to compute `d = a * b (+ c)?`, where a, b, c and d are 64-bit
> > +   // values (a, b and c might be 32-bit values), using 32-bit operations. 
> > This
> > +   // gives the following operations:
> > +   // * `d.low = low(a.low * b.low) (+ c.low)?`
> > +   // * `d.high = low(a.high * b.low) + low(a.low * b.high)
> > +   //   + high(a.low * b.low) (+ c.high)?`
> > +   //
> > +   // To compute the high bits, we can split in the following operations:
> > +   // * `tmp1   = low(a.high * b.low) (+ c.high)?`
> > +   // * `tmp2   = low(a.low * b.high) + tmp1`
> > +   // * `d.high = high(a.low * b.low) + tmp2`
> > +   //
> > +   // mkSplit put lower bits at index 0 and higher bits at index 1
> > +
> > +   Value *op1[2];
> > +   if (i->getSrc(0)->reg.size == 8)
> > +  bld.mkSplit(op1, typeSizeof(hTy), i->getSrc(0));
> > +   else {
> > +  op1[0] = i->getSrc(0);
> > +  op1[1] = zero;
> > +   }
> > +   Value *op2[2];
> > +   if (i->getSrc(1)->reg.size == 8)
> > +  bld.mkSplit(op2, typeSizeof(hTy), i->getSrc(1));
> > +   else {
> > +  op2[0] = i->getSrc(1);
> > +  op2[1] = zero;
> > +   }
> > +
> > +   Value *op3[2] = { NULL, NULL };
> > +   if (i->op == OP_MAD) {
> > +  if (i->getSrc(2)->reg.size == 8)
> > + bld.mkSplit(op3, typeSizeof(hTy), i->getSrc(2));
> > +  else {
> > + op3[0] = i->getSrc(2);
> > + op3[1] = zero;
> > +  }
> > +   }
> > +

Re: [Mesa-dev] [PATCH] glsl: optimize list handling in opt_dead_code

[Marek Olšák]

On Tue, Oct 18, 2016 at 7:12 PM, Jan Ziak <0xe2.0x9a.0...@gmail.com> wrote:
>> Regarding C++ templates, the compiler doesn't use them. If u_vector
>> (Dave Airlie?) provides the same functionality as your array, I
>> suggest we use u_vector instead.
>
> Let me repeat what you just wrote, because it is unbelievable: You are
> advising the use of non-templated collection types in C++ code.

Absolutely.

>
>> If you can't use u_vector, you should
>> ask for approval from GLSL compiler leads (e.g. Ian Romanick or
>> Kenneth Graunke) to use C++ templates.
>
> - You are talking about coding rules some Mesa developers agreed upon
> and didn't bother writing down for other developers to read
>
> - I am not willing to use u_vector in C++ code
>
>> I'll repeat some stuff about profiling here but also explain my perspective.
>
> So far (which may be a year or so), there is no indication that you
> are better at optimizing code than me.

Good one.

>
>> Never profile with -O0 or disabled function inlining.
>
> Seriously?

Absolutely.

>
>> Mesa uses -g -O2
>> with --enable-debug, so that's what you should use too. Don't use any
>> other -O* variants.
>
> What if I find a case where -O2 prevents me from easily seeing
> information necessary to optimize the source code?

There are several ways to get useful data from optimized code (using
the frame pointer, using dwarf, etc.) -O0 is too distorted.

>
>> The only profiling tools reporting correct results are perf and
>> sysprof.
>
> I used perf on Metro 2033 Redux and saw do_dead_code() there. Then I
> used callgrind to see some more code.

I recommend building Mesa with the frame pointer enabled, or enabling
dwarf in perf. Otherwise you won't see call trees.

>
>> (both use the same mechanism) If you don't enable dwarf in
>> perf (also sysprof can't use dwarf), you have to build Mesa with
>> -fno-omit-frame-pointer to see call trees. The only reason you would
>> want to enable dwarf-based call trees is when you want to see libc
>> calls. Otherwise, they won't be displayed or counted as part of call
>> trees. For Mesa developers who do profiling often,
>> -fno-omit-frame-pointer should be your default.
>
>> Callgrind counts calls (that one you can trust), but the reported time
>> is incorrect,
>
> Are you nuts? You cannot be seriously be assuming that I didn't know about 
> that.
>
>> because it uses its own virtual model of a CPU. Avoid it
>> if you want to measure time spent in functions.
>
> I will *NOT* avoid callgrind because I know how to use it to optimize code.

I didn't suggest avoiding callgrind in all cases.

>
>>Marek
>
> As usual, I would like to notify reviewers&mergers of this path that I
> am not willing to wait months to learn whether the code will be merged
> or rejected.
>
> If it isn't merged by Thursday (2016-oct-20) I will mark it as
> rejected (rejected based on personal rather than scientific grounds).

Relax. Things tend to move slowly when people are on conferences,
vacations, or just busy with corporate stuff they have to deal with
every day etc. and you can't predict those.

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

Re: [Mesa-dev] [PATCH] svga: minor code improvements in svga_validate_pipe_sampler_view()

[Charmaine Lee]

Reviewed-by: Charmaine Lee 


From: Brian Paul 
Sent: Tuesday, October 18, 2016 9:36 AM
To: mesa-dev@lists.freedesktop.org
Cc: Charmaine Lee
Subject: [PATCH] svga: minor code improvements in 
svga_validate_pipe_sampler_view()

Use the 'texture' local var in more places.
Rename 'pFormat' to 'viewFormat'.
---
 src/gallium/drivers/svga/svga_state_sampler.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/src/gallium/drivers/svga/svga_state_sampler.c 
b/src/gallium/drivers/svga/svga_state_sampler.c
index 53bb80f..445afcc 100644
--- a/src/gallium/drivers/svga/svga_state_sampler.c
+++ b/src/gallium/drivers/svga/svga_state_sampler.c
@@ -135,21 +135,21 @@ svga_validate_pipe_sampler_view(struct svga_context *svga,
   SVGA3dSurfaceFormat format;
   SVGA3dResourceType resourceDim;
   SVGA3dShaderResourceViewDesc viewDesc;
-  enum pipe_format pformat = sv->base.format;
+  enum pipe_format viewFormat = sv->base.format;

   /* vgpu10 cannot create a BGRX view for a BGRA resource, so force it to
* create a BGRA view (and vice versa).
*/
-  if (pformat == PIPE_FORMAT_B8G8R8X8_UNORM &&
-  sv->base.texture->format == PIPE_FORMAT_B8G8R8A8_UNORM) {
- pformat = PIPE_FORMAT_B8G8R8A8_UNORM;
+  if (viewFormat == PIPE_FORMAT_B8G8R8X8_UNORM &&
+  texture->format == PIPE_FORMAT_B8G8R8A8_UNORM) {
+ viewFormat = PIPE_FORMAT_B8G8R8A8_UNORM;
   }
-  else if (pformat == PIPE_FORMAT_B8G8R8A8_UNORM &&
-  sv->base.texture->format == PIPE_FORMAT_B8G8R8X8_UNORM) {
- pformat = PIPE_FORMAT_B8G8R8X8_UNORM;
+  else if (viewFormat == PIPE_FORMAT_B8G8R8A8_UNORM &&
+  texture->format == PIPE_FORMAT_B8G8R8X8_UNORM) {
+ viewFormat = PIPE_FORMAT_B8G8R8X8_UNORM;
   }

-  format = svga_translate_format(ss, pformat,
+  format = svga_translate_format(ss, viewFormat,
  PIPE_BIND_SAMPLER_VIEW);
   assert(format != SVGA3D_FORMAT_INVALID);

--
1.9.1

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

Re: [Mesa-dev] [PATCH 18/22] anv: move common wsi code to x11/wayland common files.

[Emil Velikov]

On 17 October 2016 at 05:24, Dave Airlie  wrote:

> diff --git a/src/intel/vulkan/Makefile.sources 
> b/src/intel/vulkan/Makefile.sources
> index 85df8a5..bd3afc0 100644
> --- a/src/intel/vulkan/Makefile.sources
> +++ b/src/intel/vulkan/Makefile.sources
> @@ -43,14 +43,17 @@ VULKAN_FILES := \
> anv_util.c \
> anv_wsi.c \
> anv_wsi.h \
> +   wsi_common.h \
> genX_pipeline_util.h \
> vk_format_info.h
>
>  VULKAN_WSI_WAYLAND_FILES := \
> -   anv_wsi_wayland.c
> +   anv_wsi_wayland.c \
> +   wsi_common_wayland.c
>
>  VULKAN_WSI_X11_FILES := \
> -   anv_wsi_x11.c
> +   anv_wsi_x11.c \
> +   wsi_common_x11.c
Please include the relevant headers in the lists above.

Also do copy the license from the current source. Obviously you can
add yourself/Redhat if interested.

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

Re: [Mesa-dev] [PATCH] glsl: optimize list handling in opt_dead_code

[Jan Ziak]

Perf stat results for shader-db:

This is measured on an AMD Kaveri CPU.

gcc-6.2.0 -fno-omit-frame-pointer -g -O2

 Unpatched:

$ cd shader-db
$ ../run-upstream perfstat-u --repeat=5 -- ./run -1 shaders >/dev/null

 Performance counter stats for './run -1 shaders' (5 runs):

  13689.962374  task-clock (msec) #1.000 CPUs utilized
   ( +-  0.29% )
   138  context-switches  #0.010 K/sec
   ( +- 17.82% )
 6  cpu-migrations#0.000 K/sec
   ( +- 13.36% )
78,559  page-faults   #0.006 M/sec
   ( +-  0.24% )
53,578,642,861  cycles:u  #3.914 GHz
   ( +-  0.29% )
44,813,859,985  instructions:u#0.84  insn per cycle
  ( +-  0.01% )
 1,069,586,875  cache-references:u#   78.129 M/sec
   ( +-  0.65% )
51,295,256  cache-misses:u#4.796 % of all cache
refs  ( +-  0.56% )
 9,508,996,305  branches:u#  694.596 M/sec
   ( +-  0.01% )
   453,237,236  branch-misses:u   #4.77% of all
branches  ( +-  0.84% )

  13.692494394 seconds time elapsed
 ( +-  0.29% )

 Patched:

$ cd shader-db
$ ../run-upstream-patched perfstat-u --repeat=5 -- ./run -1 shaders
>/dev/null

 Performance counter stats for './run -1 shaders' (5 runs):

  13602.106171  task-clock (msec) #1.000 CPUs utilized
   ( +-  0.14% )
86  context-switches  #0.006 K/sec
   ( +- 13.95% )
 6  cpu-migrations#0.000 K/sec
   ( +- 26.35% )
78,271  page-faults   #0.006 M/sec
   ( +-  0.82% )
53,299,046,681  cycles:u  #3.918 GHz
   ( +-  0.13% )
44,577,707,063  instructions:u#0.84  insn per cycle
  ( +-  0.01% )
 1,078,158,307  cache-references:u#   79.264 M/sec
   ( +-  0.70% )
51,521,287  cache-misses:u#4.779 % of all cache
refs  ( +-  1.03% )
 9,459,962,609  branches:u#  695.478 M/sec
   ( +-  0.01% )
   456,593,871  branch-misses:u   #4.83% of all
branches  ( +-  0.27% )

  13.603795247 seconds time elapsed
 ( +-  0.14% )
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 04/11] util: move min/max/clamp macros to util macros.h

[Jason Ekstrand]

THANK YOU!  I've been wanting to see this happen for a long time.

On Sun, Oct 16, 2016 at 7:07 PM, Dave Airlie  wrote:

> From: Dave Airlie 
>
> Although the vulkan drivers include mesa macros.h, for
> radv I'd like to move away from that.
>
> Signed-off-by: Dave Airlie 
> ---
>  src/mesa/main/macros.h | 13 -
>  src/util/macros.h  | 13 +
>  2 files changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/src/mesa/main/macros.h b/src/mesa/main/macros.h
> index ed207d4..03a228b 100644
> --- a/src/mesa/main/macros.h
> +++ b/src/mesa/main/macros.h
> @@ -660,19 +660,6 @@ INTERP_4F(GLfloat t, GLfloat dst[4], const GLfloat
> out[4], const GLfloat in[4])
>
>
>
> -/** Clamp X to [MIN,MAX] */
> -#define CLAMP( X, MIN, MAX )  ( (X)<(MIN) ? (MIN) : ((X)>(MAX) ? (MAX) :
> (X)) )
> -
> -/** Minimum of two values: */
> -#define MIN2( A, B )   ( (A)<(B) ? (A) : (B) )
> -
> -/** Maximum of two values: */
> -#define MAX2( A, B )   ( (A)>(B) ? (A) : (B) )
> -
> -/** Minimum and maximum of three values: */
> -#define MIN3( A, B, C ) ((A) < (B) ? MIN2(A, C) : MIN2(B, C))
> -#define MAX3( A, B, C ) ((A) > (B) ? MAX2(A, C) : MAX2(B, C))
> -
>  static inline unsigned
>  minify(unsigned value, unsigned levels)
>  {
> diff --git a/src/util/macros.h b/src/util/macros.h
> index 9dea2a0..27d1b62 100644
> --- a/src/util/macros.h
> +++ b/src/util/macros.h
> @@ -229,4 +229,17 @@ do {   \
>  /** Compute ceiling of integer quotient of A divided by B. */
>  #define DIV_ROUND_UP( A, B )  ( (A) % (B) == 0 ? (A)/(B) : (A)/(B)+1 )
>
> +/** Clamp X to [MIN,MAX] */
> +#define CLAMP( X, MIN, MAX )  ( (X)<(MIN) ? (MIN) : ((X)>(MAX) ? (MAX) :
> (X)) )
> +
> +/** Minimum of two values: */
> +#define MIN2( A, B )   ( (A)<(B) ? (A) : (B) )
> +
> +/** Maximum of two values: */
> +#define MAX2( A, B )   ( (A)>(B) ? (A) : (B) )
> +
> +/** Minimum and maximum of three values: */
> +#define MIN3( A, B, C ) ((A) < (B) ? MIN2(A, C) : MIN2(B, C))
> +#define MAX3( A, B, C ) ((A) > (B) ? MAX2(A, C) : MAX2(B, C))
> +
>  #endif /* UTIL_MACROS_H */
> --
> 2.5.5
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glsl: optimize list handling in opt_dead_code

[Jan Ziak]

On Tue, Oct 18, 2016 at 8:04 PM, Marek Olšák  wrote:

> On Tue, Oct 18, 2016 at 7:12 PM, Jan Ziak <0xe2.0x9a.0...@gmail.com>
> wrote:
> >> Regarding C++ templates, the compiler doesn't use them. If u_vector
> >> (Dave Airlie?) provides the same functionality as your array, I
> >> suggest we use u_vector instead.
> >
> > Let me repeat what you just wrote, because it is unbelievable: You are
> > advising the use of non-templated collection types in C++ code.
>
> Absolutely.
>

I don't believe what my own eyes are seeing.


> > If it isn't merged by Thursday (2016-oct-20) I will mark it as
> > rejected (rejected based on personal rather than scientific grounds).
>
> Relax. Things tend to move slowly when people are on conferences,
> vacations, or just busy with corporate stuff they have to deal with
> every day etc. and you can't predict those.
>
> Marek
>

Ok. Let's relax.

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

Re: [Mesa-dev] [PATCH 07/11] vulkan: add vk_alloc.h shared allocation inlines.

[Jason Ekstrand]

We already talked on IRC about putting vk_alloc.h in src/util.  Assuming
that's done, the series is

Acked-by: Jason Ekstrand 

Please make sure you do a fairly complete (fedora config?) build test.  I
don't want those MIN/MAX macros to cause problems.

--Jason

On Sun, Oct 16, 2016 at 7:07 PM, Dave Airlie  wrote:

> From: Dave Airlie 
>
> vulkan allocation allows for overriding the allocator used,
> add some macros for anv/radv to share for this.
>
> Signed-off-by: Dave Airlie 
> ---
>  configure.ac |  5 ++-
>  src/Makefile.am  |  4 +++
>  src/vulkan/Makefile.am   | 26 +++
>  src/vulkan/Makefile.sources  |  2 ++
>  src/vulkan/common/vk_alloc.h | 75 ++
> ++
>  5 files changed, 111 insertions(+), 1 deletion(-)
>  create mode 100644 src/vulkan/Makefile.am
>  create mode 100644 src/vulkan/Makefile.sources
>  create mode 100644 src/vulkan/common/vk_alloc.h
>
> diff --git a/configure.ac b/configure.ac
> index b414edd..37cc306 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -2693,6 +2693,8 @@ VA_MINOR=`$PKG_CONFIG --modversion libva | $SED -n
> 's/.*\.\(.*\)\..*$/\1/p'`
>  AC_SUBST([VA_MAJOR], $VA_MAJOR)
>  AC_SUBST([VA_MINOR], $VA_MINOR)
>
> +AM_CONDITIONAL(HAVE_VULKAN_COMMON, test "x$VULKAN_DRIVERS" != "x")
> +
>  AC_SUBST([XVMC_MAJOR], 1)
>  AC_SUBST([XVMC_MINOR], 0)
>
> @@ -2851,7 +2853,8 @@ AC_CONFIG_FILES([Makefile
> src/mesa/drivers/x11/Makefile
> src/mesa/main/tests/Makefile
> src/util/Makefile
> -   src/util/tests/hash_table/Makefile])
> +   src/util/tests/hash_table/Makefile
> +   src/vulkan/Makefile])
>
>  AC_OUTPUT
>
> diff --git a/src/Makefile.am b/src/Makefile.am
> index 17c8798..10e0826 100644
> --- a/src/Makefile.am
> +++ b/src/Makefile.am
> @@ -74,6 +74,10 @@ endif
>  # include only conditionally ?
>  SUBDIRS += compiler
>
> +if HAVE_VULKAN_COMMON
> +SUBDIRS += vulkan
> +endif
> +
>  if HAVE_AMD_DRIVERS
>  SUBDIRS += amd
>  endif
> diff --git a/src/vulkan/Makefile.am b/src/vulkan/Makefile.am
> new file mode 100644
> index 000..abe8404
> --- /dev/null
> +++ b/src/vulkan/Makefile.am
> @@ -0,0 +1,26 @@
> +# Copyright © 2016 Red Hat.
> +#
> +# Permission is hereby granted, free of charge, to any person obtaining a
> +# copy of this software and associated documentation files (the
> "Software"),
> +# to deal in the Software without restriction, including without
> limitation
> +# the rights to use, copy, modify, merge, publish, distribute, sublicense,
> +# and/or sell copies of the Software, and to permit persons to whom the
> +# Software is furnished to do so, subject to the following conditions:
> +#
> +# The above copyright notice and this permission notice (including the
> next
> +# paragraph) shall be included in all copies or substantial portions of
> the
> +# Software.
> +#
> +# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
> OR
> +# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> +# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> +# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
> OTHER
> +# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> +# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> DEALINGS
> +# IN THE SOFTWARE.
> +
> +include Makefile.sources
> +
> +noinst_LTLIBRARIES =
> +
> +EXTRA_DIST = $(COMMON_HEADER_FILES)
> diff --git a/src/vulkan/Makefile.sources b/src/vulkan/Makefile.sources
> new file mode 100644
> index 000..a73bf99
> --- /dev/null
> +++ b/src/vulkan/Makefile.sources
> @@ -0,0 +1,2 @@
> +COMMON_HEADER_FILES = \
> +   common/vk_alloc.h
> diff --git a/src/vulkan/common/vk_alloc.h b/src/vulkan/common/vk_alloc.h
> new file mode 100644
> index 000..a8e21ca
> --- /dev/null
> +++ b/src/vulkan/common/vk_alloc.h
> @@ -0,0 +1,75 @@
> +/*
> + * Copyright © 2015 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the
> "Software"),
> + * to deal in the Software without restriction, including without
> limitation
> + * the rights to use, copy, modify, merge, publish, distribute,
> sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the
> next
> + * paragraph) shall be included in all copies or substantial portions of
> the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT
> SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES O

Re: [Mesa-dev] [PATCH 20/22] anv: move to using shared wsi code

[Emil Velikov]

Hi Dave,

Thanks for doing this. It'll be great to get an Ack from the Intel
devs, on the idea.

Afaics with 22/22 in place you can drop the vk_alloc2/vk_free2
functions since they are no longer used.

Just an extra (small) suggestion below:

On 17 October 2016 at 05:24, Dave Airlie  wrote:

>  delete mode 100644 src/intel/vulkan/wsi_common.h
>  delete mode 100644 src/intel/vulkan/wsi_common_wayland.c
>  delete mode 100644 src/intel/vulkan/wsi_common_wayland.h
>  delete mode 100644 src/intel/vulkan/wsi_common_x11.c
>  delete mode 100644 src/intel/vulkan/wsi_common_x11.h
>  create mode 100644 src/vulkan/wsi/Makefile.am
>  create mode 100644 src/vulkan/wsi/Makefile.sources
>  create mode 100644 src/vulkan/wsi/wsi_common.h
>  create mode 100644 src/vulkan/wsi/wsi_common_wayland.c
>  create mode 100644 src/vulkan/wsi/wsi_common_wayland.h
>  create mode 100644 src/vulkan/wsi/wsi_common_x11.c
>  create mode 100644 src/vulkan/wsi/wsi_common_x11.h
>
Can you use git format-patch -M (or $git config --global diff.renames
true) so that the diff is friendlier.


> diff --git a/configure.ac b/configure.ac
> index 37cc306..688459b 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -2854,7 +2854,8 @@ AC_CONFIG_FILES([Makefile
> src/mesa/main/tests/Makefile
> src/util/Makefile
> src/util/tests/hash_table/Makefile
> -   src/vulkan/Makefile])
> +   src/vulkan/Makefile
> +   src/vulkan/wsi/Makefile])
>
Just fold the new Makefile into the existing one ? In should be as
simple as adding wsi/ prefix to files.
Alternatively we can do that as a follow-up.

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

Re: [Mesa-dev] [PATCH] st/glsl_to_tgsi: sort input and output decls by TGSI index

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Tue, Oct 18, 2016 at 6:06 PM, Nicolai Hähnle  wrote:
> From: Nicolai Hähnle 
>
> Fixes a regression introduced by commit 777dcf81b.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98307
> --
> Using std::sort here is quite a bit C++-ier than most parts of Mesa.
> I used it because the standard C library is being its usual lame self.
> If people think using qsort_r is fine from a portability point of view
> (it's a glibc-ism), I'd be happy to use that instead.
> ---
>  src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 28 
>  1 file changed, 28 insertions(+)
>
> diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
> b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> index f49a873..406f4d5 100644
> --- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> +++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> @@ -48,20 +48,21 @@
>  #include "tgsi/tgsi_ureg.h"
>  #include "tgsi/tgsi_info.h"
>  #include "util/u_math.h"
>  #include "util/u_memory.h"
>  #include "st_program.h"
>  #include "st_mesa_to_tgsi.h"
>  #include "st_format.h"
>  #include "st_glsl_types.h"
>  #include "st_nir.h"
>
> +#include 
>
>  #define PROGRAM_ANY_CONST ((1 << PROGRAM_STATE_VAR) |\
> (1 << PROGRAM_CONSTANT) | \
> (1 << PROGRAM_UNIFORM))
>
>  #define MAX_GLSL_TEXTURE_OFFSET 4
>
>  class st_src_reg;
>  class st_dst_reg;
>
> @@ -6092,20 +6093,43 @@ emit_compute_block_size(const struct gl_program 
> *program,
>(const struct gl_compute_program *)program;
>
> ureg_property(ureg, TGSI_PROPERTY_CS_FIXED_BLOCK_WIDTH,
> cp->LocalSize[0]);
> ureg_property(ureg, TGSI_PROPERTY_CS_FIXED_BLOCK_HEIGHT,
> cp->LocalSize[1]);
> ureg_property(ureg, TGSI_PROPERTY_CS_FIXED_BLOCK_DEPTH,
> cp->LocalSize[2]);
>  }
>
> +struct sort_inout_decls {
> +   bool operator()(const struct inout_decl &a, const struct inout_decl &b) 
> const {
> +  return mapping[a.mesa_index] < mapping[b.mesa_index];
> +   }
> +
> +   const GLuint *mapping;
> +};
> +
> +/* Sort the given array of decls by the corresponding slot (TGSI file index).
> + *
> + * This is for the benefit of older drivers which are broken when the
> + * declarations aren't sorted in this way.
> + */
> +static void
> +sort_inout_decls_by_slot(struct inout_decl *decls,
> + unsigned count,
> + const GLuint mapping[])
> +{
> +   sort_inout_decls sorter;
> +   sorter.mapping = mapping;
> +   std::sort(decls, decls + count, sorter);
> +}
> +
>  /**
>   * Translate intermediate IR (glsl_to_tgsi_instruction) to TGSI format.
>   * \param program  the program to translate
>   * \param numInputs  number of input registers used
>   * \param inputMapping  maps Mesa fragment program inputs to TGSI generic
>   *  input indexes
>   * \param inputSemanticName  the TGSI_SEMANTIC flag for each input
>   * \param inputSemanticIndex  the semantic index (ex: which texcoord) for
>   *each input
>   * \param interpMode  the TGSI_INTERPOLATE_LINEAR/PERSP mode for each input
> @@ -6164,20 +6188,22 @@ st_translate_program(
>calloc(t->num_temp_arrays, sizeof(t->arrays[0]));
>
> /*
>  * Declare input attributes.
>  */
> switch (procType) {
> case PIPE_SHADER_FRAGMENT:
> case PIPE_SHADER_GEOMETRY:
> case PIPE_SHADER_TESS_EVAL:
> case PIPE_SHADER_TESS_CTRL:
> +  sort_inout_decls_by_slot(program->inputs, program->num_inputs, 
> inputMapping);
> +
>for (i = 0; i < program->num_inputs; ++i) {
>   struct inout_decl *decl = &program->inputs[i];
>   unsigned slot = inputMapping[decl->mesa_index];
>   struct ureg_src src;
>   ubyte tgsi_usage_mask = decl->usage_mask;
>
>   if (glsl_base_type_is_64bit(decl->base_type)) {
>  if (tgsi_usage_mask == 1)
> tgsi_usage_mask = TGSI_WRITEMASK_XY;
>  else if (tgsi_usage_mask == 2)
> @@ -6216,20 +6242,22 @@ st_translate_program(
>  * Declare output attributes.
>  */
> switch (procType) {
> case PIPE_SHADER_FRAGMENT:
> case PIPE_SHADER_COMPUTE:
>break;
> case PIPE_SHADER_GEOMETRY:
> case PIPE_SHADER_TESS_EVAL:
> case PIPE_SHADER_TESS_CTRL:
> case PIPE_SHADER_VERTEX:
> +  sort_inout_decls_by_slot(program->outputs, program->num_outputs, 
> outputMapping);
> +
>for (i = 0; i < program->num_outputs; ++i) {
>   struct inout_decl *decl = &program->outputs[i];
>   unsigned slot = outputMapping[decl->mesa_index];
>   struct ureg_dst dst;
>   ubyte tgsi_usage_mask = decl->usage_mask;
>
>   if (glsl_base_type_is_64bit(decl->base_type)) {
>  if (tgsi_usage_mask == 1)
> tgsi_usage_mask = TGSI_WRITEMASK_XY;
>  else if (tgsi_usage_mask == 2

Re: [Mesa-dev] [PATCH 11/25] mesa/i965/i915/r200: eliminate gl_vertex_program

[Ian Romanick]

I'd like to see two tiny changes:

1. A comment for the IsPositionInvariant field that it can only be true
for vertex programs.

2. An assertion or two like

assert(p->Target == GL_VERTEX_PROGRAM_ARB ||
   !p->IsPositionInvariant);

   in reasonable places.  I'm thinking:

   - Where it's assigned in src/mesa/program/arbprogparse.c

   - Where it's used in src/mesa/state_tracker/st_program.c,
 src/mesa/drivers/dri/i965/brw_program.c, and
 src/mesa/tnl/t_vb_program.c (both places).

I'd also support a follow-up patch that converts IsPositionInvariant
from GLboolean to bool. :)

On 10/17/2016 11:12 PM, Timothy Arceri wrote:
> Here we move the only field in gl_vertex_program to the
> ARB program fields in gl_program.
> ---
>  src/mesa/drivers/common/meta.c   | 10 +--
>  src/mesa/drivers/common/meta.h   |  2 +-
>  src/mesa/drivers/dri/i915/i915_fragprog.c|  4 +-
>  src/mesa/drivers/dri/i965/brw_context.h  |  8 +--
>  src/mesa/drivers/dri/i965/brw_curbe.c|  2 +-
>  src/mesa/drivers/dri/i965/brw_draw.c |  4 +-
>  src/mesa/drivers/dri/i965/brw_program.c  |  5 +-
>  src/mesa/drivers/dri/i965/brw_vs.c   | 41 ++--
>  src/mesa/drivers/dri/i965/brw_vs_surface_state.c |  2 +-
>  src/mesa/drivers/dri/i965/gen6_vs_state.c|  4 +-
>  src/mesa/drivers/dri/r200/r200_context.h |  2 +-
>  src/mesa/drivers/dri/r200/r200_state_init.c  |  4 +-
>  src/mesa/drivers/dri/r200/r200_tcl.c |  2 +-
>  src/mesa/drivers/dri/r200/r200_vertprog.c| 82 
> 
>  src/mesa/main/arbprogram.c   | 19 +++---
>  src/mesa/main/context.c  |  8 +--
>  src/mesa/main/ff_fragment_shader.cpp |  2 +-
>  src/mesa/main/ffvertex_prog.c| 72 ++---
>  src/mesa/main/ffvertex_prog.h|  2 +-
>  src/mesa/main/mtypes.h   | 17 ++---
>  src/mesa/main/shared.c   |  5 +-
>  src/mesa/main/state.c| 26 
>  src/mesa/main/state.h|  2 +-
>  src/mesa/program/arbprogparse.c  | 46 ++---
>  src/mesa/program/arbprogparse.h  |  2 +-
>  src/mesa/program/prog_statevars.c|  8 +--
>  src/mesa/program/program.c   | 15 ++---
>  src/mesa/program/program.h   | 26 
>  src/mesa/program/programopt.c| 42 ++--
>  src/mesa/program/programopt.h|  2 +-
>  src/mesa/state_tracker/st_atom.c |  4 +-
>  src/mesa/state_tracker/st_atom_constbuf.c|  2 +-
>  src/mesa/state_tracker/st_atom_rasterizer.c  |  8 +--
>  src/mesa/state_tracker/st_atom_sampler.c |  2 +-
>  src/mesa/state_tracker/st_atom_shader.c  |  4 +-
>  src/mesa/state_tracker/st_atom_texture.c |  2 +-
>  src/mesa/state_tracker/st_cb_feedback.c  |  2 +-
>  src/mesa/state_tracker/st_cb_program.c   |  2 +-
>  src/mesa/state_tracker/st_debug.c|  4 +-
>  src/mesa/state_tracker/st_program.c  | 35 +-
>  src/mesa/state_tracker/st_program.h  |  4 +-
>  src/mesa/tnl/t_context.c |  4 +-
>  src/mesa/tnl/t_vb_program.c  | 24 +++
>  src/mesa/tnl/t_vp_build.c|  4 +-
>  src/mesa/vbo/vbo_exec_draw.c |  4 +-
>  src/mesa/vbo/vbo_save_draw.c |  4 +-
>  46 files changed, 264 insertions(+), 311 deletions(-)
> 
> diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
> index 890e98a..ab81eed 100644
> --- a/src/mesa/drivers/common/meta.c
> +++ b/src/mesa/drivers/common/meta.c
> @@ -566,8 +566,8 @@ _mesa_meta_begin(struct gl_context *ctx, GLbitfield state)
>  
>if (ctx->Extensions.ARB_vertex_program) {
>   save->VertexProgramEnabled = ctx->VertexProgram.Enabled;
> - _mesa_reference_vertprog(ctx, &save->VertexProgram,
> -   ctx->VertexProgram.Current);
> + _mesa_reference_program(ctx, &save->VertexProgram,
> +  ctx->VertexProgram.Current);
>   _mesa_set_enable(ctx, GL_VERTEX_PROGRAM_ARB, GL_FALSE);
>}
>  
> @@ -945,9 +945,9 @@ _mesa_meta_end(struct gl_context *ctx)
>if (ctx->Extensions.ARB_vertex_program) {
>   _mesa_set_enable(ctx, GL_VERTEX_PROGRAM_ARB,
>save->VertexProgramEnabled);
> - _mesa_reference_vertprog(ctx, &ctx->VertexProgram.Current, 
> -  save->VertexProgram);
> -  _mesa_reference_vertprog(ctx, &save->VertexProgram, NULL);
> + _mesa_reference_program(ctx, &ctx->VertexProgram.Current,
> + save->VertexProgram);
> +  _mesa_reference_progra

[Mesa-dev] [Bug 98308] llvmpipe crashes with glxgears

[bugzilla-daemon]

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

Marc Dietrich  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTABUG

--- Comment #1 from Marc Dietrich  ---
This crash was causes by using (unsupported) compilation with LTO. Sorry for
the noise.

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

[Mesa-dev] [Bug 98308] llvmpipe crashes with glxgears

[bugzilla-daemon]

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

--- Comment #2 from Roland Scheidegger  ---
I'd be interested to know though why it fails, I don't think LTO should cause
such failures? Seems like it might be related to the threads created by
llvmpipe but I don't really see how.

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