Re: [Mesa-dev] [PATCH v2 2/4] st/omx_tizonia: Add --enable-omx-tizonia flag and build files

[Gurkirpal Singh]

On Mon, Aug 14, 2017 at 10:05 PM, Leo Liu  wrote:

>
>
> On 08/14/2017 12:25 PM, Gurkirpal Singh wrote:
>
>
>
> On Mon, Aug 14, 2017 at 8:55 PM, Leo Liu  wrote:
>
>>
>>
>> On 08/14/2017 11:19 AM, Gurkirpal Singh wrote:
>>
>>
>>
>> On Mon, Aug 14, 2017 at 8:05 PM, Leo Liu  wrote:
>>
>>>
>>>
>>> On 08/14/2017 05:46 AM, Julien Isorce wrote:
>>>
>>> Hi Leo,
>>>
>>> >It would be better if you can extract the common code between bellagio
>>> and tizonia to avoid the duplication.
>>>
>>> This is something Gurkirpal and me discussed, like having
>>> state_trackers/omx/common, state_trackers/omx/bellagio,
>>> state_trackers/omx/tizonia. To anticipate that Gurkirpal sent an email
>>> https://www.mail-archive.com/mesa-dev@lists.freedeskto
>>> p.org/msg153562.html during the Community Bonding period in May (a few
>>> weeks from the date (early May) students are officially accepted to the
>>> date (end May) where student actually starts working)
>>>
>>> The problem with the directory layout above is that it would look like
>>> it will be built together in the same shared library. This is not good
>>> because it is suppose to export OMX_ComponentInit for each target. Of
>>> course this would still be possible to have 2 shared libs but I believe in
>>> state_trackers dir, all sub dir are for one target. Also we were afraid
>>> that there would be other limitations so we decided to go for a separate
>>> directory.
>>> And since there were no objections in Gurkirpal's mail above we went
>>> this way.
>>>
>>> Now if I look into state_trackers/omx_tizonia, in fact the common code
>>> with state_trackers/omx_bellagio does not have anything to do with omx. For
>>> example "slice_header". Maybe it can be moved to gallium/auxiliary/vl/ like
>>> it is done already for vl_rbsp_init. Same for omx_get_screen.
>>>
>>> So I suggest this 'factorization' to be not a blocker for merging
>>> state_trackers/omx_tizonia into usptream. But later on we can move
>>> gradually bits from state_trackers/omx_bellagio to gallium/auxiliary. And
>>> then make state_trackers/omx_tizonia use it as well.
>>> This way you will only bother about maintaining
>>> state_trackers/omx_bellagio the time being. This also allows to not slowly
>>> get its work lost.
>>>
>>> Of course we would have done differently if we knew advance. But as
>>> today Gurkirpal won't have enough time to do this factorization/move as the
>>> project ends in 1 week. Having all of this merged in upstream is not
>>> mandatory to succeed the project but Gurkirpal will need some rest after
>>> these 3 months of hard work. And who knows what happens after, whether he
>>> will still be around after sometimes or not. And this is entirely up to him.
>>>
>>> So again I suggest this factorization/move not to be a blocker for the
>>> reasons above. What do you think?
>>>
>>>
>>> When the whole project will be completed, as least same status as
>>> bellagio? Is there anyone keep working on this project after this step 1?
>>>
>> Hi, I plan on continuing working on this after the GSoC project ends.
>>
>>
>> Is the GSoC project done with your current patches?
>>
>> Apart from these patches, at least two more will be needed for the
> project. One for adding H.264 enc and other for adding EGLImage support to
> H.264 dec.
> Since I keep revising the commits quite frequently I'll give the link to
> the branch https://github.com/gpalsingh/mesa/commits/gsoc
>
> Good to see them, then why did you send them to review as well? not
> working well or other reason?
>
Indeed they still got a little bit of work. For instance the enc fails at
EOS https://github.com/gpalsingh/mesa/issues/4 and using EGLImage shows
wrong colours https://github.com/gpalsingh/mesa/issues/6
Also Julien suggested that we make it step by step i.e. Fix decoder and
then get it reviewed and then same steps for enc and EGLImage.

> And why don't you include mpeg2 and hevc to your project, and then after
> performance test, it could be replacing bellagio completely.
>
The major aim of this project was to add EGLImage support. Except the two
components adding other components was optional from the start. Also hasn't
been as straightforward as expected. Significant amount of time was spent
on making gst-omx OMX IL 1.2 conformant. Tizonia needed some work since it
was intended for mostly audio related uses. Each new component will need a
bit of work in these libs too.

Cheers

>
> Regards,
> Leo
>
>
>
>
> Cheers
>
>>
>> Regards,
>> Leo
>>
>>
>>
>>> The left stuff compared to bellagio are codecs of mpeg2 and hevc, and
>>> encoding that is more important, since the most usage for omx currently is
>>> to use transcoding from one codec to another.
>>>
>>> Other is the transcoding performance,  at least meet the performance of
>>> bellagio's.
>>>
>>> If the above could be addressed at early time,  we could remove Bellagio
>>> completely, then there is no need to do any refactor now.
>>>
>> The 

[Mesa-dev] [PATCH 4/5] radv/gfx9: handle GFX9 opaque metadata

[Dave Airlie]

From: David Airlie 

port the opaque metadata changes from radeonsi for gfx9.

Signed-off-by: Dave Airlie 
---
 src/amd/vulkan/radv_image.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/src/amd/vulkan/radv_image.c b/src/amd/vulkan/radv_image.c
index 8d3ff1a515..7a4b2d57a5 100644
--- a/src/amd/vulkan/radv_image.c
+++ b/src/amd/vulkan/radv_image.c
@@ -555,10 +555,11 @@ radv_query_opaque_metadata(struct radv_device *device,
memcpy(>metadata[2], desc, sizeof(desc));
 
/* Dwords [10:..] contain the mipmap level offsets. */
-   for (i = 0; i <= image->info.levels - 1; i++)
-   md->metadata[10+i] = image->surface.u.legacy.level[i].offset >> 
8;
-
-   md->size_metadata = (11 + image->info.levels - 1) * 4;
+   if (device->physical_device->rad_info.chip_class <= VI) {
+   for (i = 0; i <= image->info.levels - 1; i++)
+   md->metadata[10+i] = 
image->surface.u.legacy.level[i].offset >> 8;
+   md->size_metadata = (11 + image->info.levels - 1) * 4;
+   }
 }
 
 void
-- 
2.13.5

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

[Mesa-dev] radv: some initial gfx9 fixes

[Dave Airlie]

This is just a first batch of vega changes from today, some 
of the vulkan samples render (triangle, texture, gears), but nothing
too useful.

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

[Mesa-dev] [PATCH 5/5] radv/gfx9: fix tile swizzle handling for gfx9

[Dave Airlie]

From: David Airlie 

This sets the tile swizzle up properly for gfx9.

Signed-off-by: Dave Airlie 
---
 src/amd/vulkan/radv_device.c |  7 +++
 src/amd/vulkan/radv_image.c  | 12 +---
 2 files changed, 8 insertions(+), 11 deletions(-)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 85ba165b4c..9bdad6ad6f 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -2983,6 +2983,7 @@ radv_initialise_color_surface(struct radv_device *device,
S_028C74_PIPE_ALIGNED(meta.pipe_aligned);
 
cb->cb_color_base += iview->image->surface.u.gfx9.surf_offset 
>> 8;
+   cb->cb_color_base |= iview->image->surface.tile_swizzle;
} else {
const struct legacy_surf_level *level_info = 
>u.legacy.level[iview->base_mip];
unsigned pitch_tile_max, slice_tile_max, tile_mode_index;
@@ -3024,8 +3025,7 @@ radv_initialise_color_surface(struct radv_device *device,
va = device->ws->buffer_get_va(iview->bo) + iview->image->offset;
va += iview->image->dcc_offset;
cb->cb_dcc_base = va >> 8;
-   if (device->physical_device->rad_info.chip_class < GFX9)
-   cb->cb_dcc_base |= iview->image->surface.tile_swizzle;
+   cb->cb_dcc_base |= iview->image->surface.tile_swizzle;
 
uint32_t max_slice = radv_surface_layer_count(iview);
cb->cb_color_view = S_028C6C_SLICE_START(iview->base_layer) |
@@ -3041,8 +3041,7 @@ radv_initialise_color_surface(struct radv_device *device,
if (iview->image->fmask.size) {
va = device->ws->buffer_get_va(iview->bo) + 
iview->image->offset + iview->image->fmask.offset;
cb->cb_color_fmask = va >> 8;
-   if (device->physical_device->rad_info.chip_class < GFX9)
-   cb->cb_color_fmask |= iview->image->fmask.tile_swizzle;
+   cb->cb_color_fmask |= iview->image->fmask.tile_swizzle;
} else {
cb->cb_color_fmask = cb->cb_color_base;
}
diff --git a/src/amd/vulkan/radv_image.c b/src/amd/vulkan/radv_image.c
index 7a4b2d57a5..314964d64e 100644
--- a/src/amd/vulkan/radv_image.c
+++ b/src/amd/vulkan/radv_image.c
@@ -215,9 +215,9 @@ si_set_mutable_tex_desc_fields(struct radv_device *device,
va += base_level_info->offset;
 
state[0] = va >> 8;
-   if (chip_class < GFX9)
-   if (base_level_info->mode == RADEON_SURF_MODE_2D)
-   state[0] |= image->surface.tile_swizzle;
+   if (chip_class >= GFX9 ||
+   base_level_info->mode == RADEON_SURF_MODE_2D)
+   state[0] |= image->surface.tile_swizzle;
state[1] &= C_008F14_BASE_ADDRESS_HI;
state[1] |= S_008F14_BASE_ADDRESS_HI(va >> 40);
 
@@ -230,8 +230,7 @@ si_set_mutable_tex_desc_fields(struct radv_device *device,
meta_va += base_level_info->dcc_offset;
state[6] |= S_008F28_COMPRESSION_EN(1);
state[7] = meta_va >> 8;
-   if (chip_class < GFX9)
-   state[7] |= image->surface.tile_swizzle;
+   state[7] |= image->surface.tile_swizzle;
}
}
 
@@ -479,8 +478,7 @@ si_make_texture_descriptor(struct radv_device *device,
}
 
fmask_state[0] = va >> 8;
-   if (device->physical_device->rad_info.chip_class < GFX9)
-   fmask_state[0] |= image->fmask.tile_swizzle;
+   fmask_state[0] |= image->fmask.tile_swizzle;
fmask_state[1] = S_008F14_BASE_ADDRESS_HI(va >> 40) |
S_008F14_DATA_FORMAT_GFX6(fmask_format) |
S_008F14_NUM_FORMAT_GFX6(num_format);
-- 
2.13.5

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

[Mesa-dev] [PATCH 1/5] radv/gfx9: fix set predication packet.

[Dave Airlie]

From: Dave Airlie 

The predication packet changed format on GFX9, update the driver.

Signed-off-by: Dave Airlie 
---
 src/amd/vulkan/si_cmd_buffer.c | 21 -
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/src/amd/vulkan/si_cmd_buffer.c b/src/amd/vulkan/si_cmd_buffer.c
index 88616edfa2..913ec0e7d2 100644
--- a/src/amd/vulkan/si_cmd_buffer.c
+++ b/src/amd/vulkan/si_cmd_buffer.c
@@ -1133,15 +1133,18 @@ si_emit_cache_flush(struct radv_cmd_buffer *cmd_buffer)
 void
 si_emit_set_predication_state(struct radv_cmd_buffer *cmd_buffer, uint64_t va)
 {
-   uint32_t val = 0;
-
-   if (va)
-   val = (((va >> 32) & 0xff) |
-  PRED_OP(PREDICATION_OP_BOOL64)|
-  PREDICATION_DRAW_VISIBLE);
-   radeon_emit(cmd_buffer->cs, PKT3(PKT3_SET_PREDICATION, 1, 0));
-   radeon_emit(cmd_buffer->cs, va);
-   radeon_emit(cmd_buffer->cs, val);
+   uint32_t op = PRED_OP(PREDICATION_OP_BOOL64) | PREDICATION_DRAW_VISIBLE;
+
+   if (cmd_buffer->device->physical_device->rad_info.chip_class >= GFX9) {
+   radeon_emit(cmd_buffer->cs, PKT3(PKT3_SET_PREDICATION, 2, 0));
+   radeon_emit(cmd_buffer->cs, op);
+   radeon_emit(cmd_buffer->cs, va);
+   radeon_emit(cmd_buffer->cs, va >> 32);
+   } else {
+   radeon_emit(cmd_buffer->cs, PKT3(PKT3_SET_PREDICATION, 1, 0));
+   radeon_emit(cmd_buffer->cs, va);
+   radeon_emit(cmd_buffer->cs, op | ((va >> 32) & 0xFF));
+   }
 }
 
 /* Set this if you want the 3D engine to wait until CP DMA is done.
-- 
2.13.5

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

Re: [Mesa-dev] [PATCH 1/4] util/disk_cache: rename mesa cache dir and introduce cache versioning

[Dieter Nützel]

For the series:

Tested-by: Dieter Nützel 

on RX580

with Steam (wine-staging / Nine and CSMT)

Dieter

Am 15.08.2017 01:26, schrieb Timothy Arceri:

Steam is already analysing cache items, unfortunatly we did not
introduce a versioning mechanism for identifying structural changes
to cache entries earlier so the only way to do so is to rename the
cache directory.

Since we are renaming it we take the opportunity to give the directory
a more meaningful name.

Adding a version field to the header of cache entries will help us to
avoid having to rename the directory in future. Please note this is
versioning for the internal structure of the entries as defined in
disk_cache.{c,h} as opposed to the structure of the data provided to
the disk cache by the GLSL compiler and the various driver backends.
---
 src/compiler/glsl/tests/cache_test.c |  6 --
 src/util/disk_cache.c| 37 
+---

 2 files changed, 30 insertions(+), 13 deletions(-)

diff --git a/src/compiler/glsl/tests/cache_test.c
b/src/compiler/glsl/tests/cache_test.c
index af1b66fb3d..aa779e3985 100644
--- a/src/compiler/glsl/tests/cache_test.c
+++ b/src/compiler/glsl/tests/cache_test.c
@@ -178,38 +178,40 @@ test_disk_cache_create(void)
/* Test with XDG_CACHE_HOME set */
setenv("XDG_CACHE_HOME", CACHE_TEST_TMP "/xdg-cache-home", 1);
cache = disk_cache_create("test", "make_check", 0);
expect_null(cache, "disk_cache_create with XDG_CACHE_HOME set with"
"a non-existing parent directory");

mkdir(CACHE_TEST_TMP, 0755);
cache = disk_cache_create("test", "make_check", 0);
expect_non_null(cache, "disk_cache_create with XDG_CACHE_HOME 
set");


-   check_directories_created(CACHE_TEST_TMP "/xdg-cache-home/mesa");
+   check_directories_created(CACHE_TEST_TMP
+ "/xdg-cache-home/mesa_shader_cache");

disk_cache_destroy(cache);

/* Test with MESA_GLSL_CACHE_DIR set */
err = rmrf_local(CACHE_TEST_TMP);
expect_equal(err, 0, "Removing " CACHE_TEST_TMP);

setenv("MESA_GLSL_CACHE_DIR", CACHE_TEST_TMP 
"/mesa-glsl-cache-dir", 1);

cache = disk_cache_create("test", "make_check", 0);
expect_null(cache, "disk_cache_create with MESA_GLSL_CACHE_DIR set 
with"

"a non-existing parent directory");

mkdir(CACHE_TEST_TMP, 0755);
cache = disk_cache_create("test", "make_check", 0);
expect_non_null(cache, "disk_cache_create with MESA_GLSL_CACHE_DIR 
set");


-   check_directories_created(CACHE_TEST_TMP 
"/mesa-glsl-cache-dir/mesa");

+   check_directories_created(CACHE_TEST_TMP
+ 
"/mesa-glsl-cache-dir/mesa_shader_cache");


disk_cache_destroy(cache);
 }

 static bool
 does_cache_contain(struct disk_cache *cache, const cache_key key)
 {
void *result;

result = disk_cache_get(cache, key, NULL);
diff --git a/src/util/disk_cache.c b/src/util/disk_cache.c
index b2229874e0..283856b15c 100644
--- a/src/util/disk_cache.c
+++ b/src/util/disk_cache.c
@@ -51,20 +51,28 @@

 /* Number of bits to mask off from a cache key to get an index. */
 #define CACHE_INDEX_KEY_BITS 16

 /* Mask for computing an index from a key. */
 #define CACHE_INDEX_KEY_MASK ((1 << CACHE_INDEX_KEY_BITS) - 1)

 /* The number of keys that can be stored in the index. */
 #define CACHE_INDEX_MAX_KEYS (1 << CACHE_INDEX_KEY_BITS)

+#define CACHE_DIR_NAME "mesa_shader_cache"
+
+/* The cache version should be bumped whenever a change is made to the
+ * structure of cache entries or the index. This will give any 3rd 
party
+ * applications reading the cache entries a chance to adjust to the 
changes.

+ */
+#define CACHE_VERSION 1
+
 struct disk_cache {
/* The path to the cache directory. */
char *path;

/* Thread queue for compressing and writing cache entries to disk 
*/

struct util_queue cache_queue;

/* Seed for rand, which is used to pick a random directory */
uint64_t seed_xorshift128plus[2];

@@ -181,41 +189,41 @@ disk_cache_create(const char *gpu_name, const
char *timestamp,
if (local == NULL)
   goto fail;

/* At user request, disable shader cache entirely. */
if (getenv("MESA_GLSL_CACHE_DISABLE"))
   goto fail;

/* Determine path for cache based on the first defined name as 
follows:

 *
 *   $MESA_GLSL_CACHE_DIR
-*   $XDG_CACHE_HOME/mesa
-*   /.cache/mesa
+*   $XDG_CACHE_HOME/mesa_shader_cache
+*   /.cache/mesa_shader_cache
 */
path = getenv("MESA_GLSL_CACHE_DIR");
if (path) {
   if (mkdir_if_needed(path) == -1)
  goto fail;

-  path = concatenate_and_mkdir(local, path, "mesa");
+  path = concatenate_and_mkdir(local, path, CACHE_DIR_NAME);
   if (path == NULL)
  goto fail;
}

if (path == NULL) {
   char *xdg_cache_home = getenv("XDG_CACHE_HOME");

   if (xdg_cache_home) {
  if (mkdir_if_needed(xdg_cache_home) == -1)
 goto fail;

-  

[Mesa-dev] [PATCH] a2xx: add logicop support

[Ilia Mirkin]

This passes both gl-1.0-logicop and gl-1.1-xor piglits.

Signed-off-by: Ilia Mirkin 
---
 src/gallium/drivers/freedreno/a2xx/fd2_blend.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/freedreno/a2xx/fd2_blend.c 
b/src/gallium/drivers/freedreno/a2xx/fd2_blend.c
index f063ebed66a..d1187147c09 100644
--- a/src/gallium/drivers/freedreno/a2xx/fd2_blend.c
+++ b/src/gallium/drivers/freedreno/a2xx/fd2_blend.c
@@ -61,10 +61,10 @@ fd2_blend_state_create(struct pipe_context *pctx,
 {
const struct pipe_rt_blend_state *rt = >rt[0];
struct fd2_blend_stateobj *so;
+   unsigned rop = PIPE_LOGICOP_COPY;
 
if (cso->logicop_enable) {
-   DBG("Unsupported! logicop");
-   return NULL;
+   rop = cso->logicop_func;
}
 
if (cso->independent_blend_enable) {
@@ -78,7 +78,7 @@ fd2_blend_state_create(struct pipe_context *pctx,
 
so->base = *cso;
 
-   so->rb_colorcontrol = A2XX_RB_COLORCONTROL_ROP_CODE(12);
+   so->rb_colorcontrol = A2XX_RB_COLORCONTROL_ROP_CODE(rop);
 
so->rb_blendcontrol =

A2XX_RB_BLEND_CONTROL_COLOR_SRCBLEND(fd_blend_factor(rt->rgb_src_factor)) |
-- 
2.13.0

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

Re: [Mesa-dev] [PATCH] configure: Check llvm-config --shared-mode

[Michel Dänzer]

On 15/08/17 12:00 PM, Aaron Watry wrote:
> On Mon, Aug 14, 2017 at 7:54 PM, Michel Dänzer  wrote:
>> From: Michel Dänzer 
>>
>> https://bugs.llvm.org/show_bug.cgi?id=6823 still affects current LLVM.
>> llvm-config --libs only reports the single shared library if LLVM was
>> built with -DLLVM_LINK_LLVM_DYLIB=ON. llvm-config --shared-mode reports
>> "shared" in that case, "static" otherwise (even if LLVM was built with
>> -DLLVM_BUILD_LLVM_DYLIB=ON).
>>
>> Fixes: 3d8da1f678e1 ("configure: Trust LLVM >= 4.0 llvm-config --libs
>>   for shared libraries")
>> Signed-off-by: Michel Dänzer 
> 
> Thanks Michel,
> 
> Fixes a build error I've been encountering tonight with all of the
> combinations of llvm builds I've tried (VC_REV=on/off,
> shared_libraries=1/0, dylib=1/0
> 
> Tested-by: Aaron Watry 
> 
> FYI: I've settled for now on LLVM_APPEND_VC_REV=ON,
> BUILD_SHARED_LIBS=1 amongst the rest of my llvm build flags.
> Previously, I was able to get away with VC_REV=off,
> LLVM_BULID_LLVM_DYLIB=1.

The latter should work again with this patch. I'm using
LLVM_BULID_LLVM_DYLIB=ON LLVM_LINK_LLVM_DYLIB=ON, the latter removes the
need for LLVM_APPEND_VC_REV=OFF with my patches.


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

Re: [Mesa-dev] [PATCH v2 1/1] clover: Wait for requested operation if blocking flag is set

[Jan Vesely]

On Sat, 2017-08-12 at 20:14 -0700, Francisco Jerez wrote:
> Jan Vesely  writes:
> 
> > On Sat, 2017-08-05 at 12:34 -0700, Francisco Jerez wrote:
> > > Francisco Jerez  writes:
> > > 
> > > > Jan Vesely  writes:
> > > > 
> > > > > Hi,
> > > > > 
> > > > > thanks for detailed explanation. I indeed missed the writeBuffer part
> > > > > in specs.
> > > > > 
> > > > > On Wed, 2017-08-02 at 15:05 -0700, Francisco Jerez wrote:
> > > > > > These changes are somewhat redundant and potentially
> > > > > > performance-impacting, the reason is that in the OpenCL API,
> > > > > > clEnqueueWrite* commands are specified to block until the memory
> > > > > > provided by the application as origin can be reused safely (i.e. 
> > > > > > until
> > > > > > soft_copy_op()() runs), not necessarily until the transfer to 
> > > > > > graphics
> > > > > > memory has completed (which is what hard_event::wait() will wait 
> > > > > > for).
> > > > > > OTOH reads and maps as implemented by soft_copy_op and friends are
> > > > > > essentially blocking so the wait() call is redundant in most cases.
> > > > > 
> > > > > That explains a noticeable slowdown running piglit with these changes.
> > > > > I'm not sure about the read part though. I expected it to be basically
> > > > > a noop, but it changes behaviour.
> > > > 
> > > > I think this change would have slowed you down the most whenever the
> > > > mapping operation performed by soft_copy_op() is able to proceed
> > > > immediately, either because the buffer is idle (so the driver doesn't
> > > > stall on transfer_map()) *or* because the driver is trying to be smart
> > > > and creates a bounce buffer where data can be copied into immediately
> > > > without stalling, then inserts a pipelined GPU copy from the bounce
> > > > buffer into the real buffer.  With this patch you will stall on the GPU
> > > > copy regardless (and whatever other work was already on the command
> > > > stream which might be substantial), even though it wouldn't have been
> > > > necessary in any of these cases.
> > > > 
> > > > > Adding clGetEventInfo(CL_EVENT_COMMAND_EXECUTION_STATUS) after a
> > > > > blocking read in one of the piglit tests surprisingly returns
> > > > > CL_QUEUED.
> > > > > 
> > > > 
> > > > Hmm, yeah, that seems kind of debatable behaviour, although it's
> > > > definitely legit for writes, not quite sure for reads...  I believe the
> > > > reason why that happens is because the CPU copy proceeds very quickly
> > > > (due to the reasons mentioned in the last paragraph), but the hard_event
> > > > is still associated with a pipe_fence synchronous with the GPU's command
> > > > stream, so it won't get signalled until the GPU catches up.
> > 
> > Hi,
> > sorry for the delay, last week was submission week...
> > 
> 
> No worries.
> 
> > The part that I'm still missing is what kind of GPU work needs to be
> > done after clEnqueueRead*(). I assume all necessary work is completed
> > before I can access the data.
> > Also CL_QUEUED status was surprising. since we performed at least some
> > of the work (we got the data), I'd expect CL_RUNNING or CL_SUBMITTED at
> > least.
> > 
> 
> The lag is not due to GPU work that needs to be performed after the
> clEnqueueRead call, but due to GPU work that may precede it in the
> command stream: Because clover doesn't know when the last time was that
> the buffer was referenced by GPU work, the event is associated with a
> fence synchronous with the current batch (which obviously won't signal
> before any of the GPU work that actually referenced the buffer
> completes).  However the pipe driver has a more accurate idea of when
> the buffer was used last, so the transfer_map() operation is likely to
> complete more quickly than the CL event status changes to CL_COMPLETE.
> The reason you're seeing CL_QUEUED rather than CL_SUBMITTED is because
> the read operation didn't even need to flush the current batch, so
> there's no fence associated with the CL event object yet.

thanks. so the event is waiting for the current batch, even if the
buffer access is done out of order. The question is, why do we use the
fence at all? If I understood correctly mapping the buffer will be
delayed by the pipe driver if needed, so we don't really need the
fence. Am I missing something?

Jan

> 
> > > > 
> > > > > The specs don't mention use of events with blocking read, but it does
> > > > > say that "When the read command has completed, the contents of the
> > > > > buffer that ptr points to can be used by the application." in the non-
> > > > > blocking section. I'd say that the expectation is for the event to be
> > > > > CL_COMPLETE after blocking read (at least beignet/pocl/intel-cpu-sdk
> > > > > follow this).
> > > > > 
> > > > > > 
> > > > > > The only reason why it might be useful to behave differently on 
> > > > > > blocking
> > > > > > transfers is that the application may have specified a 

[Mesa-dev] [Bug 102227] Commit 26aee6f4d5 causes crash-loop on android-x86 (surfaceflinger to exit with status 1)

[bugzilla-daemon]

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

Mauro Rossi  changed:

   What|Removed |Added

   Priority|medium  |high

-- 
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 102227] Commit 26aee6f4d5 causes crash-loop on android-x86 (surfaceflinger to exit with status 1)

[bugzilla-daemon]

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

--- Comment #3 from Mauro Rossi  ---
Created attachment 133519
  --> https://bugs.freedesktop.org/attachment.cgi?id=133519=edit
Screenshot capture of mesa 17.3.0devel working on GT610 after revert of the two
commits

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

[Mesa-dev] [Bug 102227] Commit 26aee6f4d5 causes crash-loop on android-x86 (surfaceflinger to exit with status 1)

[bugzilla-daemon]

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

Mauro Rossi  changed:

   What|Removed |Added

 Attachment #133518|Screenshot capture of mesa  |Screenshot capture of mesa
description|17.2.0rc4 working on AMD|17.2.0rc4 working on AMD
   |Turks   |Turks
   ||after reverting the
   ||two commits

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

[Mesa-dev] [Bug 102227] Commit 26aee6f4d5 causes crash-loop on android-x86 (surfaceflinger to exit with status 1)

[bugzilla-daemon]

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

--- Comment #2 from Mauro Rossi  ---
Created attachment 133518
  --> https://bugs.freedesktop.org/attachment.cgi?id=133518=edit
Screenshot capture of mesa 17.2.0rc4 working on AMD Turks

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

[Mesa-dev] [Bug 102227] Commit 26aee6f4d5 causes crash-loop on android-x86 (surfaceflinger to exit with status 1)

[bugzilla-daemon]

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

--- Comment #1 from Mauro Rossi  ---
Created attachment 133517
  --> https://bugs.freedesktop.org/attachment.cgi?id=133517=edit
dmesg showing surfaceflinger is not working

-- 
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] clover/event: Include additional event statuses for clSetEventCallback

[Francisco Jerez]

Aaron Watry  writes:

> From CL 2.0 Section 5.11 (Event Objects):
>   clSetEventCallback returns CL_SUCCESS if the function is executed 
> successfully. Otherwise, it
>   returns one of the following errors:
> ...
> CL_INVALID_VALUE if pfn_event_notify is NULL or if 
> command_exec_callback_type is
> not CL_SUBMITTED , CL_RUNNING or CL_COMPLETE .
>
> Fixes: OpenCL CTS test_conformance/events/test_events callbacks
>
> Signed-off-by: Aaron Watry 
> Cc: Francisco Jerez 

Reviewed-by: Francisco Jerez 

> ---
>  src/gallium/state_trackers/clover/api/event.cpp | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/state_trackers/clover/api/event.cpp 
> b/src/gallium/state_trackers/clover/api/event.cpp
> index 5d1a0e52c5..3f89644d0a 100644
> --- a/src/gallium/state_trackers/clover/api/event.cpp
> +++ b/src/gallium/state_trackers/clover/api/event.cpp
> @@ -126,7 +126,8 @@ clSetEventCallback(cl_event d_ev, cl_int type,
> void *user_data) try {
> auto  = obj(d_ev);
>  
> -   if (!pfn_notify || type != CL_COMPLETE)
> +   if (!pfn_notify ||
> +   (type != CL_COMPLETE && type != CL_SUBMITTED && type != CL_RUNNING))
>throw error(CL_INVALID_VALUE);
>  
> // Create a temporary soft event that depends on ev, with
> -- 
> 2.11.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

[Mesa-dev] [PATCH v2 2/5] spirv: Support exporting viewport & layer from VS and TES.

[Bas Nieuwenhuizen]

Reviewed-by: Dave Airlie 
---
 src/compiler/spirv/vtn_variables.c | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/src/compiler/spirv/vtn_variables.c 
b/src/compiler/spirv/vtn_variables.c
index 4432e72e54a..599b9b11a59 100644
--- a/src/compiler/spirv/vtn_variables.c
+++ b/src/compiler/spirv/vtn_variables.c
@@ -1061,19 +1061,15 @@ vtn_get_builtin_location(struct vtn_builder *b,
   *location = VARYING_SLOT_LAYER;
   if (b->shader->stage == MESA_SHADER_FRAGMENT)
  *mode = nir_var_shader_in;
-  else if (b->shader->stage == MESA_SHADER_GEOMETRY)
- *mode = nir_var_shader_out;
   else
- unreachable("invalid stage for SpvBuiltInLayer");
+ *mode = nir_var_shader_out;
   break;
case SpvBuiltInViewportIndex:
   *location = VARYING_SLOT_VIEWPORT;
-  if (b->shader->stage == MESA_SHADER_GEOMETRY)
- *mode = nir_var_shader_out;
-  else if (b->shader->stage == MESA_SHADER_FRAGMENT)
+  if (b->shader->stage == MESA_SHADER_FRAGMENT)
  *mode = nir_var_shader_in;
   else
- unreachable("invalid stage for SpvBuiltInViewportIndex");
+ *mode = nir_var_shader_out;
   break;
case SpvBuiltInTessLevelOuter:
   *location = VARYING_SLOT_TESS_LEVEL_OUTER;
-- 
2.14.1

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

[Mesa-dev] [PATCH v2 4/5] radv: Add support for VK_EXT_shader_viewport_index_layer extension.

[Bas Nieuwenhuizen]

We were using it internally already.

v2: Add support for the spirv capability.
---
 src/amd/vulkan/radv_device.c   | 4 
 src/amd/vulkan/radv_entrypoints_gen.py | 1 +
 src/amd/vulkan/radv_pipeline.c | 1 +
 3 files changed, 6 insertions(+)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 85ba165b4c6..473db513c87 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -168,6 +168,10 @@ static const VkExtensionProperties 
common_device_extensions[] = {
.extensionName = VK_KHR_VARIABLE_POINTERS_EXTENSION_NAME,
.specVersion = 1,
},
+   {
+   .extensionName = 
VK_EXT_SHADER_VIEWPORT_INDEX_LAYER_EXTENSION_NAME,
+   .specVersion = 1,
+   },
 };
 static const VkExtensionProperties ext_sema_device_extensions[] = {
{
diff --git a/src/amd/vulkan/radv_entrypoints_gen.py 
b/src/amd/vulkan/radv_entrypoints_gen.py
index 9634f76fcd6..0411524d38c 100644
--- a/src/amd/vulkan/radv_entrypoints_gen.py
+++ b/src/amd/vulkan/radv_entrypoints_gen.py
@@ -57,6 +57,7 @@ SUPPORTED_EXTENSIONS = [
 'VK_KHR_external_semaphore_capabilities',
 'VK_KHR_external_semaphore',
 'VK_KHR_external_semaphore_fd',
+'VK_EXT_shader_viewport_index_layer',
 ]
 
 # We generate a static hash table for entry point lookup
diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index bd5eeb776c4..75b5ac5525f 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -231,6 +231,7 @@ radv_shader_compile_to_nir(struct radv_device *device,
.tessellation = true,
.int64 = true,
.variable_pointers = true,
+   .vs_tes_viewport_layer = true,
};
entry_point = spirv_to_nir(spirv, module->size / 4,
   spec_entries, num_spec_entries,
-- 
2.14.1

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

[Mesa-dev] [PATCH v2 1/5] vulkan: Import in the latest 1.0.58 header and XML from Khronos.

[Bas Nieuwenhuizen]

Reviewed-by: Dave Airlie 
---
 include/vulkan/vulkan.h| 11 ---
 src/vulkan/registry/vk.xml | 42 +++---
 2 files changed, 47 insertions(+), 6 deletions(-)

diff --git a/include/vulkan/vulkan.h b/include/vulkan/vulkan.h
index 3a74f5e3c87..23a92889ac5 100644
--- a/include/vulkan/vulkan.h
+++ b/include/vulkan/vulkan.h
@@ -43,7 +43,7 @@ extern "C" {
 #define VK_VERSION_MINOR(version) (((uint32_t)(version) >> 12) & 0x3ff)
 #define VK_VERSION_PATCH(version) ((uint32_t)(version) & 0xfff)
 // Version of this file
-#define VK_HEADER_VERSION 57
+#define VK_HEADER_VERSION 58
 
 
 #define VK_NULL_HANDLE 0
@@ -4827,7 +4827,7 @@ typedef struct VkPhysicalDeviceVariablePointerFeaturesKHR 
{
 
 
 #define VK_KHR_dedicated_allocation 1
-#define VK_KHR_DEDICATED_ALLOCATION_SPEC_VERSION 1
+#define VK_KHR_DEDICATED_ALLOCATION_SPEC_VERSION 3
 #define VK_KHR_DEDICATED_ALLOCATION_EXTENSION_NAME 
"VK_KHR_dedicated_allocation"
 
 typedef struct VkMemoryDedicatedRequirementsKHR {
@@ -5648,7 +5648,7 @@ VKAPI_ATTR VkResult VKAPI_CALL 
vkEnumeratePhysicalDeviceGroupsKHX(
 VK_DEFINE_NON_DISPATCHABLE_HANDLE(VkObjectTableNVX)
 VK_DEFINE_NON_DISPATCHABLE_HANDLE(VkIndirectCommandsLayoutNVX)
 
-#define VK_NVX_DEVICE_GENERATED_COMMANDS_SPEC_VERSION 1
+#define VK_NVX_DEVICE_GENERATED_COMMANDS_SPEC_VERSION 3
 #define VK_NVX_DEVICE_GENERATED_COMMANDS_EXTENSION_NAME 
"VK_NVX_device_generated_commands"
 
 
@@ -6440,6 +6440,11 @@ typedef struct 
VkPipelineCoverageModulationStateCreateInfoNV {
 #define VK_EXT_POST_DEPTH_COVERAGE_EXTENSION_NAME "VK_EXT_post_depth_coverage"
 
 
+#define VK_EXT_shader_viewport_index_layer 1
+#define VK_EXT_SHADER_VIEWPORT_INDEX_LAYER_SPEC_VERSION 1
+#define VK_EXT_SHADER_VIEWPORT_INDEX_LAYER_EXTENSION_NAME 
"VK_EXT_shader_viewport_index_layer"
+
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/src/vulkan/registry/vk.xml b/src/vulkan/registry/vk.xml
index 85a49afb701..7c5f258a173 100644
--- a/src/vulkan/registry/vk.xml
+++ b/src/vulkan/registry/vk.xml
@@ -106,7 +106,7 @@ private version is maintained in the 1.0 branch of the 
member gitlab server.
 // Vulkan 1.0 version number
 #define VK_API_VERSION_1_0 VK_MAKE_VERSION(1, 0, 
0)// Patch version should always be set to 0
 // Version of this file
-#define VK_HEADER_VERSION 57
+#define VK_HEADER_VERSION 58
 
 
 #define VK_DEFINE_HANDLE(object) typedef struct object##_T* 
object;
@@ -6218,7 +6218,7 @@ private version is maintained in the 1.0 branch of the 
member gitlab server.
 
 
 
-
+
 
 
 
@@ -6629,7 +6629,7 @@ private version is maintained in the 1.0 branch of the 
member gitlab server.
 
 
 
-
+
 
 
 
@@ -6922,5 +6922,41 @@ private version is maintained in the 1.0 branch of the 
member gitlab server.
 
 
 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
 
 
-- 
2.14.1

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

Re: [Mesa-dev] [PATCH] configure: Trust LLVM >= 4.0 llvm-config --libs for shared libraries

[Michel Dänzer]

On 15/08/17 07:55 AM, Grazvydas Ignotas wrote:
> On Mon, Aug 14, 2017 at 11:13 PM, Andy Furniss  wrote:
>> Michel Dänzer wrote:
>>>
>>> On 11/08/17 01:45 AM, Emil Velikov wrote:
>>>
>>> Thanks, pushed.
>>
>>
>> Don't know if this is expected or not, but llvm built like -
>>
>> cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release
>> -DLLVM_TARGETS_TO_BUILD="host;AMDGPU" -DLLVM_ENABLE_ASSERTIONS=ON
>> -DLLVM_APPEND_VC_REV=OFF -DLLVM_BUILD_LLVM_DYLIB=ON
>>
>> now fails to build mesa (I also tried without vulkan and it still fails
>> raseonsi IIRC).
>>
>>  CXXLDlibvulkan_radeon.la
>> /usr/lib/libLLVMSupport.a(Process.cpp.o): In function
>> `llvm::sys::Process::FileDescriptorHasColors(int)':
>> Process.cpp:(.text._ZN4llvm3sys7Process23FileDescriptorHasColorsEi+0x4d):
>> undefined reference to `setupterm'
>> Process.cpp:(.text._ZN4llvm3sys7Process23FileDescriptorHasColorsEi+0x78):
>> undefined reference to `tigetnum'
>> Process.cpp:(.text._ZN4llvm3sys7Process23FileDescriptorHasColorsEi+0x81):
>> undefined reference to `set_curterm'
>> Process.cpp:(.text._ZN4llvm3sys7Process23FileDescriptorHasColorsEi+0x89):
>> undefined reference to `del_curterm'
>> collect2: error: ld returned 1 exit status
>>
>> Haven't tried llvm with -DLLVM_APPEND_VC_REV=ON yet, mesa still builds OK
>> with this commit reverted.
> 
> Same problem here, using LLVM-6.0 from a week ago, my cmake is just
> -DCMAKE_INSTALL_PREFIX=/opt/xorg -DLLVM_TARGETS_TO_BUILD='AMDGPU;X86'
> -DCMAKE_BUILD_TYPE=Release -DLLVM_BUILD_LLVM_DYLIB=TRUE
> 
> llvm-config --libs
> seems to return tons of output like -lLLVMBitWriter -lLLVMAnalysis
> -lLLVMProfileData -lLLVMObject ... which seems to result in static
> linking that's supposedly not supported by mesa? The only .so I see is
> libLLVM.so , all others are .a files.
> 
> Meanwhile
> llvm-config --shared-mode
> returns "static", which implies it wants be statically linked. There
> is BUILD_SHARED_LIBS cmake option, but llvm documentation advices
> against using it and suggests LLVM_BUILD_LLVM_DYLIB instead.
> Confusing...
> 
> Also, llvm-config --version says "6.0.0git-f49c401", which means I had
> to manually hack configure.ac every time to "6.0.0svn" to get mesa
> building too :(

The patch was intended to fix that issue, but it only works if LLVM is
built with -DLLVM_LINK_LLVM_DYLIB=ON.

Thanks for the report, followup patch posted for review.


-- 
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 v2 5/5] radv: Update VK_KHR_dedicated_allocation spec version.

[Bas Nieuwenhuizen]

Update:
"Clarify that dedicated allocations do not allow aliasing in the
 flink:vkBindBufferMemory and flink:vkBindImageMemory valid usage
 statements."

Which is a noop in driver support.

Reviewed-by: Dave Airlie 
---
 src/amd/vulkan/radv_device.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 473db513c87..140a51c0b9a 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -150,7 +150,7 @@ static const VkExtensionProperties 
common_device_extensions[] = {
},
{
.extensionName = VK_KHR_DEDICATED_ALLOCATION_EXTENSION_NAME,
-   .specVersion = 1,
+   .specVersion = 3,
},
{
.extensionName = VK_KHR_EXTERNAL_MEMORY_EXTENSION_NAME,
-- 
2.14.1

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

Re: [Mesa-dev] [PATCH] clover/event: Include additional event statuses for clSetEventCallback

[Aaron Watry]

On Mon, Aug 14, 2017 at 7:42 PM, Aaron Watry  wrote:
> From CL 2.0 Section 5.11 (Event Objects):
>   clSetEventCallback returns CL_SUCCESS if the function is executed 
> successfully. Otherwise, it
>   returns one of the following errors:
> ...
> CL_INVALID_VALUE if pfn_event_notify is NULL or if 
> command_exec_callback_type is
> not CL_SUBMITTED , CL_RUNNING or CL_COMPLETE .
>
> Fixes: OpenCL CTS test_conformance/events/test_events callbacks
>
> Signed-off-by: Aaron Watry 
> Cc: Francisco Jerez 

Corrected Francisco's email locally after it bounced.

--Aaron

> ---
>  src/gallium/state_trackers/clover/api/event.cpp | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/state_trackers/clover/api/event.cpp 
> b/src/gallium/state_trackers/clover/api/event.cpp
> index 5d1a0e52c5..3f89644d0a 100644
> --- a/src/gallium/state_trackers/clover/api/event.cpp
> +++ b/src/gallium/state_trackers/clover/api/event.cpp
> @@ -126,7 +126,8 @@ clSetEventCallback(cl_event d_ev, cl_int type,
> void *user_data) try {
> auto  = obj(d_ev);
>
> -   if (!pfn_notify || type != CL_COMPLETE)
> +   if (!pfn_notify ||
> +   (type != CL_COMPLETE && type != CL_SUBMITTED && type != CL_RUNNING))
>throw error(CL_INVALID_VALUE);
>
> // Create a temporary soft event that depends on ev, with
> --
> 2.11.0
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] clover/event: Include additional event statuses for clSetEventCallback

[Aaron Watry]

From CL 2.0 Section 5.11 (Event Objects):
  clSetEventCallback returns CL_SUCCESS if the function is executed 
successfully. Otherwise, it
  returns one of the following errors:
...
CL_INVALID_VALUE if pfn_event_notify is NULL or if 
command_exec_callback_type is
not CL_SUBMITTED , CL_RUNNING or CL_COMPLETE .

Fixes: OpenCL CTS test_conformance/events/test_events callbacks

Signed-off-by: Aaron Watry 
Cc: Francisco Jerez 
---
 src/gallium/state_trackers/clover/api/event.cpp | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/clover/api/event.cpp 
b/src/gallium/state_trackers/clover/api/event.cpp
index 5d1a0e52c5..3f89644d0a 100644
--- a/src/gallium/state_trackers/clover/api/event.cpp
+++ b/src/gallium/state_trackers/clover/api/event.cpp
@@ -126,7 +126,8 @@ clSetEventCallback(cl_event d_ev, cl_int type,
void *user_data) try {
auto  = obj(d_ev);
 
-   if (!pfn_notify || type != CL_COMPLETE)
+   if (!pfn_notify ||
+   (type != CL_COMPLETE && type != CL_SUBMITTED && type != CL_RUNNING))
   throw error(CL_INVALID_VALUE);
 
// Create a temporary soft event that depends on ev, with
-- 
2.11.0

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

Re: [Mesa-dev] [PATCH v2 1/1] clover: Wait for requested operation if blocking flag is set

[Aaron Watry]

On Mon, Aug 14, 2017 at 4:29 PM, Aaron Watry  wrote:
> On Mon, Aug 14, 2017 at 1:53 PM, Francisco Jerez  
> wrote:
>> Aaron Watry  writes:
>>
>>> On Sat, Aug 12, 2017 at 10:14 PM, Francisco Jerez  
>>> wrote:
 Jan Vesely  writes:

> On Sat, 2017-08-05 at 12:34 -0700, Francisco Jerez wrote:
>> Francisco Jerez  writes:
>>
>> > Jan Vesely  writes:
>> >
>> > > Hi,
>> > >
>> > > thanks for detailed explanation. I indeed missed the writeBuffer part
>> > > in specs.
>> > >
>> > > On Wed, 2017-08-02 at 15:05 -0700, Francisco Jerez wrote:
>> > > > These changes are somewhat redundant and potentially
>> > > > performance-impacting, the reason is that in the OpenCL API,
>> > > > clEnqueueWrite* commands are specified to block until the memory
>> > > > provided by the application as origin can be reused safely (i.e. 
>> > > > until
>> > > > soft_copy_op()() runs), not necessarily until the transfer to 
>> > > > graphics
>> > > > memory has completed (which is what hard_event::wait() will wait 
>> > > > for).
>> > > > OTOH reads and maps as implemented by soft_copy_op and friends are
>> > > > essentially blocking so the wait() call is redundant in most cases.
>> > >
>> > > That explains a noticeable slowdown running piglit with these 
>> > > changes.
>> > > I'm not sure about the read part though. I expected it to be 
>> > > basically
>> > > a noop, but it changes behaviour.
>> >
>> > I think this change would have slowed you down the most whenever the
>> > mapping operation performed by soft_copy_op() is able to proceed
>> > immediately, either because the buffer is idle (so the driver doesn't
>> > stall on transfer_map()) *or* because the driver is trying to be smart
>> > and creates a bounce buffer where data can be copied into immediately
>> > without stalling, then inserts a pipelined GPU copy from the bounce
>> > buffer into the real buffer.  With this patch you will stall on the GPU
>> > copy regardless (and whatever other work was already on the command
>> > stream which might be substantial), even though it wouldn't have been
>> > necessary in any of these cases.
>> >
>> > > Adding clGetEventInfo(CL_EVENT_COMMAND_EXECUTION_STATUS) after a
>> > > blocking read in one of the piglit tests surprisingly returns
>> > > CL_QUEUED.
>> > >
>> >
>> > Hmm, yeah, that seems kind of debatable behaviour, although it's
>> > definitely legit for writes, not quite sure for reads...  I believe the
>> > reason why that happens is because the CPU copy proceeds very quickly
>> > (due to the reasons mentioned in the last paragraph), but the 
>> > hard_event
>> > is still associated with a pipe_fence synchronous with the GPU's 
>> > command
>> > stream, so it won't get signalled until the GPU catches up.
>
> Hi,
> sorry for the delay, last week was submission week...
>

 No worries.

> The part that I'm still missing is what kind of GPU work needs to be
> done after clEnqueueRead*(). I assume all necessary work is completed
> before I can access the data.
> Also CL_QUEUED status was surprising. since we performed at least some
> of the work (we got the data), I'd expect CL_RUNNING or CL_SUBMITTED at
> least.
>

 The lag is not due to GPU work that needs to be performed after the
 clEnqueueRead call, but due to GPU work that may precede it in the
 command stream: Because clover doesn't know when the last time was that
 the buffer was referenced by GPU work, the event is associated with a
 fence synchronous with the current batch (which obviously won't signal
 before any of the GPU work that actually referenced the buffer
 completes).  However the pipe driver has a more accurate idea of when
 the buffer was used last, so the transfer_map() operation is likely to
 complete more quickly than the CL event status changes to CL_COMPLETE.
 The reason you're seeing CL_QUEUED rather than CL_SUBMITTED is because
 the read operation didn't even need to flush the current batch, so
 there's no fence associated with the CL event object yet.
>>>
>>> Speaking of event status issues, I've been sitting on the attached
>>> patch (and some others) until my current series dealing with language
>>> versions is dealt with.
>>>
>>> Basically, our clSetEventCallback implementation is ignoring several
>>> event statuses that *should* be triggering the callbacks, and is
>>> instead generating errors which cause CTS failures.
>>>
>>> --Aaron
>>>

>> >
>> > > The specs don't mention use of events with blocking read, but it does
>> > > say that "When the read command has 

Re: [Mesa-dev] [PATCH 3/4] radv: Add support for VK_EXT_shader_viewport_index_layer extension.

[Ilia Mirkin]

Don't you also need to add support for the ShaderViewportIndexLayerEXT
spir-v capability somewhere?

On Mon, Aug 14, 2017 at 8:02 PM, Bas Nieuwenhuizen
 wrote:
> We were using it internally already.
> ---
>  src/amd/vulkan/radv_device.c   | 4 
>  src/amd/vulkan/radv_entrypoints_gen.py | 1 +
>  2 files changed, 5 insertions(+)
>
> diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
> index 85ba165b4c6..473db513c87 100644
> --- a/src/amd/vulkan/radv_device.c
> +++ b/src/amd/vulkan/radv_device.c
> @@ -168,6 +168,10 @@ static const VkExtensionProperties 
> common_device_extensions[] = {
> .extensionName = VK_KHR_VARIABLE_POINTERS_EXTENSION_NAME,
> .specVersion = 1,
> },
> +   {
> +   .extensionName = 
> VK_EXT_SHADER_VIEWPORT_INDEX_LAYER_EXTENSION_NAME,
> +   .specVersion = 1,
> +   },
>  };
>  static const VkExtensionProperties ext_sema_device_extensions[] = {
> {
> diff --git a/src/amd/vulkan/radv_entrypoints_gen.py 
> b/src/amd/vulkan/radv_entrypoints_gen.py
> index 9634f76fcd6..0411524d38c 100644
> --- a/src/amd/vulkan/radv_entrypoints_gen.py
> +++ b/src/amd/vulkan/radv_entrypoints_gen.py
> @@ -57,6 +57,7 @@ SUPPORTED_EXTENSIONS = [
>  'VK_KHR_external_semaphore_capabilities',
>  'VK_KHR_external_semaphore',
>  'VK_KHR_external_semaphore_fd',
> +'VK_EXT_shader_viewport_index_layer',
>  ]
>
>  # We generate a static hash table for entry point lookup
> --
> 2.14.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/4] spirv: Support exporting viewport & layer from VS and TES.

[Bas Nieuwenhuizen]

---
 src/compiler/spirv/vtn_variables.c | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/src/compiler/spirv/vtn_variables.c 
b/src/compiler/spirv/vtn_variables.c
index 4432e72e54a..599b9b11a59 100644
--- a/src/compiler/spirv/vtn_variables.c
+++ b/src/compiler/spirv/vtn_variables.c
@@ -1061,19 +1061,15 @@ vtn_get_builtin_location(struct vtn_builder *b,
   *location = VARYING_SLOT_LAYER;
   if (b->shader->stage == MESA_SHADER_FRAGMENT)
  *mode = nir_var_shader_in;
-  else if (b->shader->stage == MESA_SHADER_GEOMETRY)
- *mode = nir_var_shader_out;
   else
- unreachable("invalid stage for SpvBuiltInLayer");
+ *mode = nir_var_shader_out;
   break;
case SpvBuiltInViewportIndex:
   *location = VARYING_SLOT_VIEWPORT;
-  if (b->shader->stage == MESA_SHADER_GEOMETRY)
- *mode = nir_var_shader_out;
-  else if (b->shader->stage == MESA_SHADER_FRAGMENT)
+  if (b->shader->stage == MESA_SHADER_FRAGMENT)
  *mode = nir_var_shader_in;
   else
- unreachable("invalid stage for SpvBuiltInViewportIndex");
+ *mode = nir_var_shader_out;
   break;
case SpvBuiltInTessLevelOuter:
   *location = VARYING_SLOT_TESS_LEVEL_OUTER;
-- 
2.14.1

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

[Mesa-dev] [PATCH 4/4] radv: Update VK_KHR_dedicated_allocation spec version.

[Bas Nieuwenhuizen]

Update:
"Clarify that dedicated allocations do not allow aliasing in the
 flink:vkBindBufferMemory and flink:vkBindImageMemory valid usage
 statements."

Which is a noop in driver support.
---
 src/amd/vulkan/radv_device.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 473db513c87..140a51c0b9a 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -150,7 +150,7 @@ static const VkExtensionProperties 
common_device_extensions[] = {
},
{
.extensionName = VK_KHR_DEDICATED_ALLOCATION_EXTENSION_NAME,
-   .specVersion = 1,
+   .specVersion = 3,
},
{
.extensionName = VK_KHR_EXTERNAL_MEMORY_EXTENSION_NAME,
-- 
2.14.1

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

Re: [Mesa-dev] [PATCH] configure: Trust LLVM >= 4.0 llvm-config --libs for shared libraries

[Grazvydas Ignotas]

On Tue, Aug 15, 2017 at 1:55 AM, Grazvydas Ignotas  wrote:
>
> Also, llvm-config --version says "6.0.0git-f49c401", which means I had
> to manually hack configure.ac every time to "6.0.0svn" to get mesa
> building too :(

Nevermind about this one, -DLLVM_APPEND_VC_REV=OFF solves it. Would be
great to have a "how to configure llvm for mesa" section somewhere.

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

[Mesa-dev] [PATCH 3/4] glsl: pass shader source keys to the disk cache

[Timothy Arceri]

We don't actually write them to disk here. That will happen in the
following commit.
---
 src/compiler/glsl/shader_cache.cpp  | 20 +---
 src/compiler/glsl/tests/cache_test.c| 12 ++--
 src/gallium/drivers/radeonsi/si_state_shaders.c |  2 +-
 src/mesa/state_tracker/st_shader_cache.c|  2 +-
 src/util/disk_cache.c   |  8 +---
 src/util/disk_cache.h   |  6 --
 6 files changed, 34 insertions(+), 16 deletions(-)

diff --git a/src/compiler/glsl/shader_cache.cpp 
b/src/compiler/glsl/shader_cache.cpp
index cc4d24482d..7a97fb7cb8 100644
--- a/src/compiler/glsl/shader_cache.cpp
+++ b/src/compiler/glsl/shader_cache.cpp
@@ -1302,37 +1302,51 @@ shader_cache_write_program_metadata(struct gl_context 
*ctx,
write_uniform_remap_tables(metadata, prog);
 
write_atomic_buffers(metadata, prog);
 
write_buffer_blocks(metadata, prog);
 
write_subroutines(metadata, prog);
 
write_program_resource_list(metadata, prog);
 
+   struct cache_item_metadata cache_item_metadata;
+   cache_item_metadata.type = CACHE_ITEM_TYPE_GLSL;
+   cache_item_metadata.keys =
+  (cache_key *) malloc(prog->NumShaders * sizeof(cache_key));
+   cache_item_metadata.num_keys = prog->NumShaders;
+
+   if (!cache_item_metadata.keys)
+  goto fail;
+
char sha1_buf[41];
for (unsigned i = 0; i < prog->NumShaders; i++) {
   disk_cache_put_key(cache, prog->Shaders[i]->sha1);
+  memcpy(cache_item_metadata.keys[i], prog->Shaders[i]->sha1,
+ sizeof(cache_key));
   if (ctx->_Shader->Flags & GLSL_CACHE_INFO) {
  _mesa_sha1_format(sha1_buf, prog->Shaders[i]->sha1);
  fprintf(stderr, "marking shader: %s\n", sha1_buf);
   }
}
 
-   disk_cache_put(cache, prog->data->sha1, metadata->data, metadata->size);
-
-   blob_destroy(metadata);
+   disk_cache_put(cache, prog->data->sha1, metadata->data, metadata->size,
+  _item_metadata);
 
if (ctx->_Shader->Flags & GLSL_CACHE_INFO) {
   _mesa_sha1_format(sha1_buf, prog->data->sha1);
   fprintf(stderr, "putting program metadata in cache: %s\n", sha1_buf);
}
+
+fail:
+   free(cache_item_metadata.keys);
+   blob_destroy(metadata);
 }
 
 bool
 shader_cache_read_program_metadata(struct gl_context *ctx,
struct gl_shader_program *prog)
 {
/* Fixed function programs generated by Mesa are not cached. So don't
 * try to read metadata for them from the cache.
 */
if (prog->Name == 0)
diff --git a/src/compiler/glsl/tests/cache_test.c 
b/src/compiler/glsl/tests/cache_test.c
index aa779e3985..c6f306d069 100644
--- a/src/compiler/glsl/tests/cache_test.c
+++ b/src/compiler/glsl/tests/cache_test.c
@@ -261,36 +261,36 @@ test_put_and_get(void)
cache = disk_cache_create("test", "make_check", 0);
 
disk_cache_compute_key(cache, blob, sizeof(blob), blob_key);
 
/* Ensure that disk_cache_get returns nothing before anything is added. */
result = disk_cache_get(cache, blob_key, );
expect_null(result, "disk_cache_get with non-existent item (pointer)");
expect_equal(size, 0, "disk_cache_get with non-existent item (size)");
 
/* Simple test of put and get. */
-   disk_cache_put(cache, blob_key, blob, sizeof(blob));
+   disk_cache_put(cache, blob_key, blob, sizeof(blob), NULL);
 
/* disk_cache_put() hands things off to a thread give it some time to
 * finish.
 */
wait_until_file_written(cache, blob_key);
 
result = disk_cache_get(cache, blob_key, );
expect_equal_str(blob, result, "disk_cache_get of existing item (pointer)");
expect_equal(size, sizeof(blob), "disk_cache_get of existing item (size)");
 
free(result);
 
/* Test put and get of a second item. */
disk_cache_compute_key(cache, string, sizeof(string), string_key);
-   disk_cache_put(cache, string_key, string, sizeof(string));
+   disk_cache_put(cache, string_key, string, sizeof(string), NULL);
 
/* disk_cache_put() hands things off to a thread give it some time to
 * finish.
 */
wait_until_file_written(cache, string_key);
 
result = disk_cache_get(cache, string_key, );
expect_equal_str(result, string, "2nd disk_cache_get of existing item 
(pointer)");
expect_equal(size, sizeof(string), "2nd disk_cache_get of existing item 
(size)");
 
@@ -317,21 +317,21 @@ test_put_and_get(void)
 * That's actually expected given how the eviction code is
 * implemented, (which expects to only evict once things are more
 * interestingly full than that).
 *
 * For this test, we force this signature to land in the same
 * directory as the original blob first written to the cache.
 */
disk_cache_compute_key(cache, one_KB, 1024, one_KB_key);
one_KB_key[0] = blob_key[0];
 
-   disk_cache_put(cache, one_KB_key, one_KB, 1024);
+   disk_cache_put(cache, one_KB_key, one_KB, 1024, NULL);
 
free(one_KB);
 
/* 

[Mesa-dev] [PATCH 4/4] util/disk_cache: write cache item metadata to disk

[Timothy Arceri]

---
 src/util/disk_cache.c | 89 ++-
 1 file changed, 88 insertions(+), 1 deletion(-)

diff --git a/src/util/disk_cache.c b/src/util/disk_cache.c
index c5a7d1f98a..8077e0a500 100644
--- a/src/util/disk_cache.c
+++ b/src/util/disk_cache.c
@@ -99,20 +99,22 @@ struct disk_cache_put_job {
 
struct disk_cache *cache;
 
cache_key key;
 
/* Copy of cache data to be compressed and written. */
void *data;
 
/* Size of data to be compressed and written. */
size_t size;
+
+   struct cache_item_metadata cache_item_metadata;
 };
 
 /* Create a directory named 'path' if it does not already exist.
  *
  * Returns: 0 if path already exists as a directory or if created.
  * -1 in all other cases.
  */
 static int
 mkdir_if_needed(const char *path)
 {
@@ -764,29 +766,60 @@ create_put_job(struct disk_cache *cache, const cache_key 
key,
 {
struct disk_cache_put_job *dc_job = (struct disk_cache_put_job *)
   malloc(sizeof(struct disk_cache_put_job) + size);
 
if (dc_job) {
   dc_job->cache = cache;
   memcpy(dc_job->key, key, sizeof(cache_key));
   dc_job->data = dc_job + 1;
   memcpy(dc_job->data, data, size);
   dc_job->size = size;
+
+  /* Copy the cache item metadata */
+  if (cache_item_metadata) {
+ dc_job->cache_item_metadata.type = cache_item_metadata->type;
+ if (cache_item_metadata->type == CACHE_ITEM_TYPE_GLSL) {
+dc_job->cache_item_metadata.num_keys =
+   cache_item_metadata->num_keys;
+dc_job->cache_item_metadata.keys = (cache_key *)
+   malloc(cache_item_metadata->num_keys * sizeof(cache_key));
+
+if (!dc_job->cache_item_metadata.keys)
+   goto fail;
+
+for (unsigned i = 0; i < cache_item_metadata->num_keys; i++) {
+   memcpy(dc_job->cache_item_metadata.keys[i],
+  cache_item_metadata->keys[i], sizeof(cache_key));
+}
+ }
+  } else {
+ dc_job->cache_item_metadata.type = CACHE_ITEM_TYPE_UNKNOWN;
+ dc_job->cache_item_metadata.keys = NULL;
+  }
}
 
return dc_job;
+
+fail:
+   free(dc_job->cache_item_metadata.keys);
+   free(dc_job);
+
+   return NULL;
 }
 
 static void
 destroy_put_job(void *job, int thread_index)
 {
if (job) {
+  struct disk_cache_put_job *dc_job = (struct disk_cache_put_job *) job;
+  free(dc_job->cache_item_metadata.keys);
+
   free(job);
}
 }
 
 struct cache_entry_file_data {
uint32_t crc32;
uint32_t uncompressed_size;
 };
 
 static void
@@ -861,20 +894,48 @@ cache_put(void *job, int thread_index)
 * mesa version that produced the entry or deal with hash collisions,
 * should that ever become a real problem.
 */
ret = write_all(fd, dc_job->cache->driver_keys_blob,
dc_job->cache->driver_keys_blob_size);
if (ret == -1) {
   unlink(filename_tmp);
   goto done;
}
 
+   /* Write the cache item metadata. This data can be used to deal with
+* hash collisions, as well as providing useful information to 3rd party
+* tools reading the cache files.
+*/
+   ret = write_all(fd, _job->cache_item_metadata.type,
+   sizeof(cache_item_metadata_type));
+   if (ret == -1) {
+  unlink(filename_tmp);
+  goto done;
+   }
+
+   if (dc_job->cache_item_metadata.type == CACHE_ITEM_TYPE_GLSL) {
+  ret = write_all(fd, _job->cache_item_metadata.num_keys,
+  sizeof(uint32_t));
+  if (ret == -1) {
+ unlink(filename_tmp);
+ goto done;
+  }
+
+  ret = write_all(fd, dc_job->cache_item_metadata.keys[0],
+  dc_job->cache_item_metadata.num_keys *
+  sizeof(cache_key));
+  if (ret == -1) {
+ unlink(filename_tmp);
+ goto done;
+  }
+   }
+
/* Create CRC of the data. We will read this when restoring the cache and
 * use it to check for corruption.
 */
struct cache_entry_file_data cf_data;
cf_data.crc32 = util_hash_crc32(dc_job->data, dc_job->size);
cf_data.uncompressed_size = dc_job->size;
 
size_t cf_data_size = sizeof(cf_data);
ret = write_all(fd, _data, cf_data_size);
if (ret == -1) {
@@ -1020,29 +1081,55 @@ disk_cache_get(struct disk_cache *cache, const 
cache_key key, size_t *size)
free(file_header);
 #else
/* The cache keys are currently just used for distributing precompiled
 * shaders, they are not used by Mesa so just skip them for now.
 */
ret = lseek(fd, ck_size, SEEK_CUR);
if (ret == -1)
   goto fail;
 #endif
 
+   size_t cache_item_md_size = sizeof(cache_item_metadata_type);
+   cache_item_metadata_type md_type;
+   ret = read_all(fd, _type, cache_item_md_size);
+   if (ret == -1)
+  goto fail;
+
+   if (md_type == CACHE_ITEM_TYPE_GLSL) {
+  uint32_t num_keys;
+  cache_item_md_size += sizeof(uint32_t);
+  ret = 

Re: [Mesa-dev] [PATCH] configure: Trust LLVM >= 4.0 llvm-config --libs for shared libraries

[Grazvydas Ignotas]

On Mon, Aug 14, 2017 at 11:13 PM, Andy Furniss  wrote:
> Michel Dänzer wrote:
>>
>> On 11/08/17 01:45 AM, Emil Velikov wrote:
>>
>> Thanks, pushed.
>
>
> Don't know if this is expected or not, but llvm built like -
>
> cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release
> -DLLVM_TARGETS_TO_BUILD="host;AMDGPU" -DLLVM_ENABLE_ASSERTIONS=ON
> -DLLVM_APPEND_VC_REV=OFF -DLLVM_BUILD_LLVM_DYLIB=ON
>
> now fails to build mesa (I also tried without vulkan and it still fails
> raseonsi IIRC).
>
>  CXXLDlibvulkan_radeon.la
> /usr/lib/libLLVMSupport.a(Process.cpp.o): In function
> `llvm::sys::Process::FileDescriptorHasColors(int)':
> Process.cpp:(.text._ZN4llvm3sys7Process23FileDescriptorHasColorsEi+0x4d):
> undefined reference to `setupterm'
> Process.cpp:(.text._ZN4llvm3sys7Process23FileDescriptorHasColorsEi+0x78):
> undefined reference to `tigetnum'
> Process.cpp:(.text._ZN4llvm3sys7Process23FileDescriptorHasColorsEi+0x81):
> undefined reference to `set_curterm'
> Process.cpp:(.text._ZN4llvm3sys7Process23FileDescriptorHasColorsEi+0x89):
> undefined reference to `del_curterm'
> collect2: error: ld returned 1 exit status
>
> Haven't tried llvm with -DLLVM_APPEND_VC_REV=ON yet, mesa still builds OK
> with this commit reverted.

Same problem here, using LLVM-6.0 from a week ago, my cmake is just
-DCMAKE_INSTALL_PREFIX=/opt/xorg -DLLVM_TARGETS_TO_BUILD='AMDGPU;X86'
-DCMAKE_BUILD_TYPE=Release -DLLVM_BUILD_LLVM_DYLIB=TRUE

llvm-config --libs
seems to return tons of output like -lLLVMBitWriter -lLLVMAnalysis
-lLLVMProfileData -lLLVMObject ... which seems to result in static
linking that's supposedly not supported by mesa? The only .so I see is
libLLVM.so , all others are .a files.

Meanwhile
llvm-config --shared-mode
returns "static", which implies it wants be statically linked. There
is BUILD_SHARED_LIBS cmake option, but llvm documentation advices
against using it and suggests LLVM_BUILD_LLVM_DYLIB instead.
Confusing...

Also, llvm-config --version says "6.0.0git-f49c401", which means I had
to manually hack configure.ac every time to "6.0.0svn" to get mesa
building too :(

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

Re: [Mesa-dev] [PATCH v2 1/1] clover: Wait for requested operation if blocking flag is set

[Aaron Watry]

On Mon, Aug 14, 2017 at 1:53 PM, Francisco Jerez  wrote:
> Aaron Watry  writes:
>
>> On Sat, Aug 12, 2017 at 10:14 PM, Francisco Jerez  
>> wrote:
>>> Jan Vesely  writes:
>>>
 On Sat, 2017-08-05 at 12:34 -0700, Francisco Jerez wrote:
> Francisco Jerez  writes:
>
> > Jan Vesely  writes:
> >
> > > Hi,
> > >
> > > thanks for detailed explanation. I indeed missed the writeBuffer part
> > > in specs.
> > >
> > > On Wed, 2017-08-02 at 15:05 -0700, Francisco Jerez wrote:
> > > > These changes are somewhat redundant and potentially
> > > > performance-impacting, the reason is that in the OpenCL API,
> > > > clEnqueueWrite* commands are specified to block until the memory
> > > > provided by the application as origin can be reused safely (i.e. 
> > > > until
> > > > soft_copy_op()() runs), not necessarily until the transfer to 
> > > > graphics
> > > > memory has completed (which is what hard_event::wait() will wait 
> > > > for).
> > > > OTOH reads and maps as implemented by soft_copy_op and friends are
> > > > essentially blocking so the wait() call is redundant in most cases.
> > >
> > > That explains a noticeable slowdown running piglit with these changes.
> > > I'm not sure about the read part though. I expected it to be basically
> > > a noop, but it changes behaviour.
> >
> > I think this change would have slowed you down the most whenever the
> > mapping operation performed by soft_copy_op() is able to proceed
> > immediately, either because the buffer is idle (so the driver doesn't
> > stall on transfer_map()) *or* because the driver is trying to be smart
> > and creates a bounce buffer where data can be copied into immediately
> > without stalling, then inserts a pipelined GPU copy from the bounce
> > buffer into the real buffer.  With this patch you will stall on the GPU
> > copy regardless (and whatever other work was already on the command
> > stream which might be substantial), even though it wouldn't have been
> > necessary in any of these cases.
> >
> > > Adding clGetEventInfo(CL_EVENT_COMMAND_EXECUTION_STATUS) after a
> > > blocking read in one of the piglit tests surprisingly returns
> > > CL_QUEUED.
> > >
> >
> > Hmm, yeah, that seems kind of debatable behaviour, although it's
> > definitely legit for writes, not quite sure for reads...  I believe the
> > reason why that happens is because the CPU copy proceeds very quickly
> > (due to the reasons mentioned in the last paragraph), but the hard_event
> > is still associated with a pipe_fence synchronous with the GPU's command
> > stream, so it won't get signalled until the GPU catches up.

 Hi,
 sorry for the delay, last week was submission week...

>>>
>>> No worries.
>>>
 The part that I'm still missing is what kind of GPU work needs to be
 done after clEnqueueRead*(). I assume all necessary work is completed
 before I can access the data.
 Also CL_QUEUED status was surprising. since we performed at least some
 of the work (we got the data), I'd expect CL_RUNNING or CL_SUBMITTED at
 least.

>>>
>>> The lag is not due to GPU work that needs to be performed after the
>>> clEnqueueRead call, but due to GPU work that may precede it in the
>>> command stream: Because clover doesn't know when the last time was that
>>> the buffer was referenced by GPU work, the event is associated with a
>>> fence synchronous with the current batch (which obviously won't signal
>>> before any of the GPU work that actually referenced the buffer
>>> completes).  However the pipe driver has a more accurate idea of when
>>> the buffer was used last, so the transfer_map() operation is likely to
>>> complete more quickly than the CL event status changes to CL_COMPLETE.
>>> The reason you're seeing CL_QUEUED rather than CL_SUBMITTED is because
>>> the read operation didn't even need to flush the current batch, so
>>> there's no fence associated with the CL event object yet.
>>
>> Speaking of event status issues, I've been sitting on the attached
>> patch (and some others) until my current series dealing with language
>> versions is dealt with.
>>
>> Basically, our clSetEventCallback implementation is ignoring several
>> event statuses that *should* be triggering the callbacks, and is
>> instead generating errors which cause CTS failures.
>>
>> --Aaron
>>
>>>
> >
> > > The specs don't mention use of events with blocking read, but it does
> > > say that "When the read command has completed, the contents of the
> > > buffer that ptr points to can be used by the application." in the non-
> > > blocking section. I'd say that the expectation is for the event to be
> > > CL_COMPLETE after 

Re: [Mesa-dev] [PATCH 0/5] GL_OES_required_internalformat

[Eric Anholt]

Mark Janes  writes:

> Eric Anholt  writes:
>
>> Tapani Pälli  writes:
>>
>>> On 06/22/2017 02:08 AM, Eric Anholt wrote:
 Tapani Pälli  writes:
 
> On 06/14/2017 01:12 AM, Eric Anholt wrote:
>> Tapani Pälli  writes:
>>
>>> On 06/12/2017 09:52 AM, Tapani Pälli wrote:

 On 05/18/2017 09:39 PM, Eric Anholt wrote:
> Eric Anholt  writes:
>
>> This series came out of fixing dEQP failures on vc4's GLES2 context.
>> Mesa was allowing RGB565 textures, which is only valid with
>> GL_OES_required_internalformat.  Rather than disable RGB565, I 
>> decided
>> the extension was easy enough to support.
>>
>> I've sent one piglit test for renderbuffer sizing, and dEQP has tests
>> for whether enums get accepted for TexImage.
>>
>> There's a functional question in patch #2, see the comment there, and
>> there's a question of whether the extension should be dummy_true in
>> patch #5.
>>
>> branch: 
>> https://github.com/anholt/mesa/commits/required-internalformat
> I would still love review on this series.
>
 Earlier I took a brief look at series and run through our CI, there 
 were
 many failing tests but t seems I forgot to reply/report .. I'll run it
 again and let you know what's the result.

>>> '36 failures' (many likely duplicates of some same issue), these ones ..
>>>
>>> ES3-CTS.functional.fbo.completeness.renderable.texture.stencil.rgb10.bdwm64
>>> ES3-CTS.gtf.GL3Tests.packed_pixels.packed_pixels_pbo.bdwm64
>>> ES3-CTS.gtf.GL3Tests.packed_pixels.packed_pixels_pixelstore.hswm64
>>> ES3-CTS.functional.fbo.completeness.renderable.texture.stencil.rgb10.sklm64
>>> ES3-CTS.gtf.GL3Tests.packed_pixels.packed_pixels_pbo.sklm64
>>> ES3-CTS.functional.fbo.completeness.renderable.texture.depth.rgb10.bdwm64
>>> ES3-CTS.gtf.GL3Tests.packed_pixels.packed_pixels_pixelstore.bdwm64
>>> ES3-CTS.gtf.GL3Tests.packed_pixels.packed_pixels.hswm64
>>> ES3-CTS.gtf.GL3Tests.packed_pixels.packed_pixels_pixelstore.sklm64
>>> ES3-CTS.functional.fbo.completeness.renderable.texture.color0.rgb10.hswm64
>>> ES3-CTS.functional.fbo.completeness.renderable.texture.depth.rgb10.hswm64
>>> ES3-CTS.functional.fbo.completeness.renderable.texture.stencil.rgb10.hswm64
>>> ES3-CTS.gtf.GL3Tests.packed_pixels.packed_pixels_pbo.hswm64
>>> ES3-CTS.functional.fbo.completeness.renderable.texture.color0.rgb10.bdwm64
>>> ES3-CTS.gtf.GL3Tests.packed_pixels.packed_pixels.bdwm64
>>> ES3-CTS.functional.fbo.completeness.renderable.texture.depth.rgb10.sklm64
>>> ES3-CTS.functional.fbo.completeness.renderable.texture.color0.rgb10.sklm64
>>> ES3-CTS.gtf.GL3Tests.packed_pixels.packed_pixels.sklm64
>>> ES2-CTS.functional.fbo.completeness.renderable.texture.depth.rgb10.bdwm64
>>> ES2-CTS.functional.fbo.completeness.renderable.texture.depth.rgb10.sklm64
>>> ES2-CTS.functional.fbo.completeness.renderable.texture.stencil.rgb10.bdwm64
>>> ES2-CTS.functional.fbo.completeness.renderable.texture.depth.rgb10.hswm64
>>> ES2-CTS.functional.fbo.completeness.renderable.texture.stencil.rgb10.hswm64
>>> ES2-CTS.functional.fbo.completeness.renderable.texture.stencil.rgb10.sklm64
>>>
>>> piglit.spec.oes_texture_float.oes_texture_float half.g965m64
>>> piglit.spec.oes_texture_float.oes_texture_float.g965m64
>>> piglit.spec.oes_texture_float.oes_texture_float half linear.g965m64
>>> piglit.spec.oes_texture_float.oes_texture_float linear.g965m64
>>> piglit.spec.oes_texture_float.oes_texture_float half.g45m64
>>> piglit.spec.oes_texture_float.oes_texture_float half linear.g45m64
>>> piglit.spec.oes_texture_float.oes_texture_float linear.g45m64
>>> piglit.spec.oes_texture_float.oes_texture_float.g45m64
>>> piglit.spec.oes_texture_float.oes_texture_float.ilkm64
>>> piglit.spec.oes_texture_float.oes_texture_float half linear.ilkm64
>>> piglit.spec.oes_texture_float.oes_texture_float half.ilkm64
>>> piglit.spec.oes_texture_float.oes_texture_float linear.ilkm64
>>>
>>> Are you able to reproduce/run these tests on some machine?
>> I have a SKL desktop, so I reproduced the GLES2 rgb10 failure and fixed
>> it, and I think I've fixed the pre-snb failures in piglit.  New branch
>> up at https://github.com/anholt/mesa/commits/required-internalformat
>> which I'll piglit now.
>
>
> OK, seems the packed_pixels ones are still failing. I'll try to debug
> this a bit to see what's going on.
 
 Have you had a chance to look at this at all?  Or could you give me a
 command line for reproducing failure?  I've gone through my VK-GL-CTS
 tree and DEQP 

Re: [Mesa-dev] [PATCH] configure: Trust LLVM >= 4.0 llvm-config --libs for shared libraries

[Andy Furniss]

Michel Dänzer wrote:

On 11/08/17 01:45 AM, Emil Velikov wrote:

On 9 August 2017 at 02:00, Michel Dänzer  wrote:

On 09/08/17 03:24 AM, Emil Velikov wrote:


I think we'd want to keep the best of both - just not sure how to
exactly do that.
--libs/--libfiles was completely busted with LLVM 3.9 and is back to
normal with 4.0.

Could we use that somehow?


This patch relies on llvm-config --libs with LLVM >= 4.0. If you mean
something else, please be more specific.


That's the thing - in some versions --libs is busted while for others
--libs/--libfiles.


Do you have any specific information about --libs being broken with
recent versions of LLVM? I though that was fixed long ago.



That said, patch does exactly what it says on the
Reviewed-by: Emil Velikov 


Thanks, pushed.


Don't know if this is expected or not, but llvm built like -

cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release 
-DLLVM_TARGETS_TO_BUILD="host;AMDGPU" -DLLVM_ENABLE_ASSERTIONS=ON 
-DLLVM_APPEND_VC_REV=OFF -DLLVM_BUILD_LLVM_DYLIB=ON


now fails to build mesa (I also tried without vulkan and it still fails 
raseonsi IIRC).


 CXXLDlibvulkan_radeon.la
/usr/lib/libLLVMSupport.a(Process.cpp.o): In function 
`llvm::sys::Process::FileDescriptorHasColors(int)':
Process.cpp:(.text._ZN4llvm3sys7Process23FileDescriptorHasColorsEi+0x4d): 
undefined reference to `setupterm'
Process.cpp:(.text._ZN4llvm3sys7Process23FileDescriptorHasColorsEi+0x78): 
undefined reference to `tigetnum'
Process.cpp:(.text._ZN4llvm3sys7Process23FileDescriptorHasColorsEi+0x81): 
undefined reference to `set_curterm'
Process.cpp:(.text._ZN4llvm3sys7Process23FileDescriptorHasColorsEi+0x89): 
undefined reference to `del_curterm'

collect2: error: ld returned 1 exit status

Haven't tried llvm with -DLLVM_APPEND_VC_REV=ON yet, mesa still builds 
OK with this commit reverted.


My mesa config =

./autogen.sh --prefix=/usr --sysconfdir=/etc --enable-texture-float 
--enable-opencl --enable-omx --with-egl-platforms=x11,drm,wayland 
--with-gallium-drivers=radeonsi,swrast --with-vulkan-drivers=radeon 
--enable-gbm --enable-shared-glapi --enable-glx-tls --with-dri-drivers=


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

Re: [Mesa-dev] [PATCH v2 1/1] clover: Wait for requested operation if blocking flag is set

[Francisco Jerez]

Aaron Watry  writes:

> On Sat, Aug 12, 2017 at 10:14 PM, Francisco Jerez  
> wrote:
>> Jan Vesely  writes:
>>
>>> On Sat, 2017-08-05 at 12:34 -0700, Francisco Jerez wrote:
 Francisco Jerez  writes:

 > Jan Vesely  writes:
 >
 > > Hi,
 > >
 > > thanks for detailed explanation. I indeed missed the writeBuffer part
 > > in specs.
 > >
 > > On Wed, 2017-08-02 at 15:05 -0700, Francisco Jerez wrote:
 > > > These changes are somewhat redundant and potentially
 > > > performance-impacting, the reason is that in the OpenCL API,
 > > > clEnqueueWrite* commands are specified to block until the memory
 > > > provided by the application as origin can be reused safely (i.e. 
 > > > until
 > > > soft_copy_op()() runs), not necessarily until the transfer to 
 > > > graphics
 > > > memory has completed (which is what hard_event::wait() will wait 
 > > > for).
 > > > OTOH reads and maps as implemented by soft_copy_op and friends are
 > > > essentially blocking so the wait() call is redundant in most cases.
 > >
 > > That explains a noticeable slowdown running piglit with these changes.
 > > I'm not sure about the read part though. I expected it to be basically
 > > a noop, but it changes behaviour.
 >
 > I think this change would have slowed you down the most whenever the
 > mapping operation performed by soft_copy_op() is able to proceed
 > immediately, either because the buffer is idle (so the driver doesn't
 > stall on transfer_map()) *or* because the driver is trying to be smart
 > and creates a bounce buffer where data can be copied into immediately
 > without stalling, then inserts a pipelined GPU copy from the bounce
 > buffer into the real buffer.  With this patch you will stall on the GPU
 > copy regardless (and whatever other work was already on the command
 > stream which might be substantial), even though it wouldn't have been
 > necessary in any of these cases.
 >
 > > Adding clGetEventInfo(CL_EVENT_COMMAND_EXECUTION_STATUS) after a
 > > blocking read in one of the piglit tests surprisingly returns
 > > CL_QUEUED.
 > >
 >
 > Hmm, yeah, that seems kind of debatable behaviour, although it's
 > definitely legit for writes, not quite sure for reads...  I believe the
 > reason why that happens is because the CPU copy proceeds very quickly
 > (due to the reasons mentioned in the last paragraph), but the hard_event
 > is still associated with a pipe_fence synchronous with the GPU's command
 > stream, so it won't get signalled until the GPU catches up.
>>>
>>> Hi,
>>> sorry for the delay, last week was submission week...
>>>
>>
>> No worries.
>>
>>> The part that I'm still missing is what kind of GPU work needs to be
>>> done after clEnqueueRead*(). I assume all necessary work is completed
>>> before I can access the data.
>>> Also CL_QUEUED status was surprising. since we performed at least some
>>> of the work (we got the data), I'd expect CL_RUNNING or CL_SUBMITTED at
>>> least.
>>>
>>
>> The lag is not due to GPU work that needs to be performed after the
>> clEnqueueRead call, but due to GPU work that may precede it in the
>> command stream: Because clover doesn't know when the last time was that
>> the buffer was referenced by GPU work, the event is associated with a
>> fence synchronous with the current batch (which obviously won't signal
>> before any of the GPU work that actually referenced the buffer
>> completes).  However the pipe driver has a more accurate idea of when
>> the buffer was used last, so the transfer_map() operation is likely to
>> complete more quickly than the CL event status changes to CL_COMPLETE.
>> The reason you're seeing CL_QUEUED rather than CL_SUBMITTED is because
>> the read operation didn't even need to flush the current batch, so
>> there's no fence associated with the CL event object yet.
>
> Speaking of event status issues, I've been sitting on the attached
> patch (and some others) until my current series dealing with language
> versions is dealt with.
>
> Basically, our clSetEventCallback implementation is ignoring several
> event statuses that *should* be triggering the callbacks, and is
> instead generating errors which cause CTS failures.
>
> --Aaron
>
>>
 >
 > > The specs don't mention use of events with blocking read, but it does
 > > say that "When the read command has completed, the contents of the
 > > buffer that ptr points to can be used by the application." in the non-
 > > blocking section. I'd say that the expectation is for the event to be
 > > CL_COMPLETE after blocking read (at least beignet/pocl/intel-cpu-sdk
 > > follow this).
 > >
 > > >
 > > > The only reason why it might be useful to behave differently on 
 > > > 

Re: [Mesa-dev] [PATCH] i965/miptree: Set supports_fast_clear = false in make_shareable

[Jason Ekstrand]

I missed the stable CC when I pushed this one.  It needs to be in 17.2

On Thu, Aug 3, 2017 at 9:52 AM, Jason Ekstrand  wrote:

> The make_shareable function deletes the aux buffer and then whacks
> aux_usage to ISL_AUX_USAGE_NONE but not unsetting supports_fast_clear.
> Since we only look at supports_fast_clear to decide whether or not to do
> fast clears, this was causing assertion failures.
>
> Reported-by: Tapani Pälli 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101925
> ---
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> index 17ac563..6fca7e3 100644
> --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> @@ -2706,6 +2706,7 @@ intel_miptree_make_shareable(struct brw_context
> *brw,
> }
>
> mt->aux_usage = ISL_AUX_USAGE_NONE;
> +   mt->supports_fast_clear = false;
>  }
>
>
> --
> 2.5.0.400.gff86faf
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH V3] i965 : Optimize atom state flag checks

[Scott D Phillips]

Tapani Pälli  writes:

> Hello;
>
> On 07/25/2017 05:17 PM, Marathe, Yogesh wrote:
>> Hi Matt, Sorry for late reply, please see below.
>> 
>>> -Original Message-
>>> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On Behalf
>>> Of Matt Turner
>>> Sent: Saturday, July 22, 2017 12:12 AM
>>> To: Muthukumar, Aravindan 
>>> Cc: mesa-dev@lists.freedesktop.org; Marathe, Yogesh
>>> 
>>> Subject: Re: [Mesa-dev] [PATCH V3] i965 : Optimize atom state flag checks
>>>
>>> On 07/21, aravindan.muthuku...@intel.com wrote:
 From: Aravindan Muthukumar 

 This patch improves CPI Rate(Cycles per Instruction) and branch miss
 predict for i965. The function check_state() was showing CPI retired rate.

 Performance stats with android:
 - CPI retired lowered by 28% (lower is better)
 - Branch missprediction lowered by 13% (lower is better)
 - 3DMark improved by 2%

 The dissassembly doesn't show difference, although above results were
 observed with patch.
>>>
>> 
>> Yes this is true for V3 where we removed the function based on a review 
>> comment.
>> 
>>> If there's no difference in the assembly then whatever measurements you have
>>> taken must be noise.
>>>
>> 
>> No that's not guaranteed either. Lot of things still depend on how 
>> instructions are
>> aligned, sometimes even changing linking order gives different results where
>> disassemblies of individual functions remain same.
>>   
>>> I applied the patch and inspected brw_state_upload.o. There are assembly
>>> differences. I can produce the same assembly as this patch by just pulling 
>>> the if
>>> statement out of check_and_emit_atom() and into the caller. The replacement
>>> of check_state() with a macro is completely unnecessary.
>>>
>>>
>>> diff --git a/src/mesa/drivers/dri/i965/brw_state_upload.c
>>> b/src/mesa/drivers/dri/i965/brw_state_upload.c
>>> index acaa97ee7d..b163e1490d 100644
>>> --- a/src/mesa/drivers/dri/i965/brw_state_upload.c
>>> +++ b/src/mesa/drivers/dri/i965/brw_state_upload.c
>>> @@ -439,14 +439,12 @@ merge_ctx_state(struct brw_context *brw,  }
>>>
>>>   static inline void
>>> -check_and_emit_atom(struct brw_context *brw,
>>> -struct brw_state_flags *state,
>>> -const struct brw_tracked_state *atom)
>>> +emit_atom(struct brw_context *brw,
>>> +  struct brw_state_flags *state,
>>> +  const struct brw_tracked_state *atom)
>>>   {
>>> -   if (check_state(state, >dirty)) {
>>> -  atom->emit(brw);
>>> -  merge_ctx_state(brw, state);
>>> -   }
>>> +   atom->emit(brw);
>>> +   merge_ctx_state(brw, state);
>>>   }
>>>
>>>   static inline void
>>> @@ -541,7 +539,9 @@ brw_upload_pipeline_state(struct brw_context *brw,
>>>  const struct brw_tracked_state *atom = [i];
>>>  struct brw_state_flags generated;
>>>
>>> - check_and_emit_atom(brw, , atom);
>>> + if (check_state(, >dirty)) {
>>> +emit_atom(brw, , atom);
>>> + }
>>>
>>>  accumulate_state(, >dirty);
>>>
>>> @@ -558,7 +558,9 @@ brw_upload_pipeline_state(struct brw_context *brw,
>>> for (i = 0; i < num_atoms; i++) {
>>>  const struct brw_tracked_state *atom = [i];
>>>
>>> - check_and_emit_atom(brw, , atom);
>>> + if (check_state(, >dirty)) {
>>> +emit_atom(brw, , atom);
>>> + }
>>> }
>>>  }
>>>
>>>
>>> With that said, the assembly differences are not understandable to me.
>>> Why should extracting an if statement from a static inline function into 
>>> the caller
>>> of that function cause any difference whatsoever?
>> 
>> Agreed, it shouldn't in case of static inline.
>> 
>>>
>>> I'm viewing the assembly differences with:
>>>
>>> wdiff -n \
>>>  -w $'\033[30;41m' -x $'\033[0m' \
>>>  -y $'\033[30;42m' -z $'\033[0m' \
>>>  <(objdump -d brw_state_upload.o.before | sed -e 's/^.*\t//') \
>>>  <(objdump -d brw_state_upload.o.wtf| sed -e 's/^.*\t//') | less -R
>>>
>>> and the only real difference is the movement of some call and jmp 
>>> instructions.
>>>
>>> I cannot take the patch without some reasonable explanation for the change.
>> 
>> Ok I think this has been discussed already and we agree that there is no big 
>> visible difference
>> in disassembly which can be pointed out for improvement. Although, as you 
>> said this movement
>> of instructions can cause this. If with this patch instructions get cache 
>> aligned that too can show
>> improvement.  This is a busy function with bad CPI. Hence chosen for 
>> optimization. Branch miss
>> predict is another metric.  Do we want to consider all these or just 
>> disassembly?
>
> I don't have a reasonable explanation to give but I made some benchmark 
> runs today (3DMark "Ice Storm Unlimited" test ) and I'm getting 
> consistently 1-2% better results with the patch. I also tried 

[Mesa-dev] [Bug 101486] TAHITI XT hangs once "dota2 -vulkan" dashboard is loaded

[bugzilla-daemon]

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

Sylvain BERTRAND  changed:

   What|Removed |Added

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

--- Comment #3 from Sylvain BERTRAND  ---
Yope, it did the trick for me. Each time I come reporting bugs there, some
magic fixes it a little time right after my report without me knowing :)
Thanks for the tip!

-- 
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] i965/blorp: Correct type of src_format in call to intel_miptree_texture_aux_usage

[Jason Ekstrand]

Pushed.

On Mon, Aug 14, 2017 at 10:37 AM, Scott D Phillips <
scott.d.phill...@intel.com> wrote:

> Jason Ekstrand  writes:
>
> > On Fri, Aug 11, 2017 at 10:36 AM, Scott D Phillips <
> > scott.d.phill...@intel.com> wrote:
> >
> >> Jason Ekstrand  writes:
> >>
> >> > oof...  Have you run this through Jenkins?  It should be ok, but
> >> > it will be a functional change.  It's a good change, but it is a
> >> > change.
> >>
> >> I ran the patch through jenkins, where the only problem it
> >> reported was a gpu hang on skl gt2 in:
> >>
> >> ES2-CTS.functional.state_query.integers.stencil_back_
> >> fail_separate_both_getfloat
> >>
> >> Although the test succeeded and I didn't see a hang in several
> >> thousand runs on my own skl gt2. Maybe the hang was somebody
> >> else's fault?
> >>
> >
> > Yeah, I doubt this caused the hang.  Wouldn't be a bad idea to run it
> again
> > just to be sure.
>
> OK, re-ran and got a clean test result.
>
> >> > Also, this should probably get CCd to stable.
> >>
> >> I was under the impression that a Fixes tag somehow magically got
> >> it to the right stable branches. If that's not the case then it
> >> looks like it should be:
> >>
> >> Cc: "17.2" 
> >>
> >
> > Yup, that's right.
> >
> > Reviewed-by: Jason Ekstrand 
> >
> >
> >> > --Jason
> >> >
> >> > On Wed, Aug 9, 2017 at 3:52 PM, Scott D Phillips <
> >> scott.d.phill...@intel.com
> >> >> wrote:
> >> >
> >> >> intel_miptree_texture_aux_usage() takes an isl_format, but we are
> >> >> passing a mesa_format. clang warns:
> >> >>
> >> >>  brw_blorp.c:305:52: warning: implicit conversion from enumeration
> >> >> type 'mesa_format' to different enumeration type
> >> >> 'enum isl_format' [-Wenum-conversion]
> >> >>intel_miptree_texture_aux_usage(brw, src_mt, src_format);
> >> >>~~~  ^~
> >> >>
> >> >> Fixes: fc1639e46d ("i965/blorp: Use texture/render_aux_usage for
> blits")
> >> >> ---
> >> >>  src/mesa/drivers/dri/i965/brw_blorp.c | 3 ++-
> >> >>  1 file changed, 2 insertions(+), 1 deletion(-)
> >> >>
> >> >> diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c
> >> >> b/src/mesa/drivers/dri/i965/brw_blorp.c
> >> >> index 446f507619..d8e48064e3 100644
> >> >> --- a/src/mesa/drivers/dri/i965/brw_blorp.c
> >> >> +++ b/src/mesa/drivers/dri/i965/brw_blorp.c
> >> >> @@ -301,8 +301,9 @@ brw_blorp_blit_miptrees(struct brw_context *brw,
> >> >>src_format = dst_format = MESA_FORMAT_R_FLOAT32;
> >> >> }
> >> >>
> >> >> +   enum isl_format src_isl_format = brw_isl_format_for_mesa_
> >> >> format(src_format);
> >> >> enum isl_aux_usage src_aux_usage =
> >> >> -  intel_miptree_texture_aux_usage(brw, src_mt, src_format);
> >> >> +  intel_miptree_texture_aux_usage(brw, src_mt, src_isl_format);
> >> >> /* We do format workarounds for some depth formats so we can't
> >> reliably
> >> >>  * sample with HiZ.  One of these days, we should fix that.
> >> >>  */
> >> >> --
> >> >> 2.13.3
> >> >>
> >> >> ___
> >> >> mesa-dev mailing list
> >> >> mesa-dev@lists.freedesktop.org
> >> >> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >> >>
> >>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] i965/screen: Stop redefining DRM_FORMAT_MOD_(INVALID|LINEAR)

[Ben Widawsky]

On 17-08-14 10:13:23, Jason Ekstrand wrote:

---
src/mesa/drivers/dri/i965/intel_screen.c | 8 
1 file changed, 8 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index 452f0d1..a22d63e 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -43,14 +43,6 @@
#include "utils.h"
#include "util/xmlpool.h"

-#ifndef DRM_FORMAT_MOD_INVALID
-#define DRM_FORMAT_MOD_INVALID ((1ULL<<56) - 1)
-#endif
-
-#ifndef DRM_FORMAT_MOD_LINEAR
-#define DRM_FORMAT_MOD_LINEAR 0
-#endif
-
static const __DRIconfigOptionsExtension brw_config_options = {
   .base = { __DRI_CONFIG_OPTIONS, 1 },
   .xml =



Both are:
Reviewed-by: Ben Widawsky 

--
Ben Widawsky, Intel Open Source Technology Center
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/2] i965/screen: Stop redefining DRM_FORMAT_MOD_(INVALID|LINEAR)

[Jason Ekstrand]

---
 src/mesa/drivers/dri/i965/intel_screen.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index 452f0d1..a22d63e 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -43,14 +43,6 @@
 #include "utils.h"
 #include "util/xmlpool.h"
 
-#ifndef DRM_FORMAT_MOD_INVALID
-#define DRM_FORMAT_MOD_INVALID ((1ULL<<56) - 1)
-#endif
-
-#ifndef DRM_FORMAT_MOD_LINEAR
-#define DRM_FORMAT_MOD_LINEAR 0
-#endif
-
 static const __DRIconfigOptionsExtension brw_config_options = {
.base = { __DRI_CONFIG_OPTIONS, 1 },
.xml =
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 1/2] drm-uapi/forcc: Pull in new modifiers

[Jason Ekstrand]

---
 include/drm-uapi/drm_fourcc.h | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/include/drm-uapi/drm_fourcc.h b/include/drm-uapi/drm_fourcc.h
index 7586c46..3ad838d 100644
--- a/include/drm-uapi/drm_fourcc.h
+++ b/include/drm-uapi/drm_fourcc.h
@@ -185,6 +185,8 @@ extern "C" {
 #define DRM_FORMAT_MOD_VENDOR_BROADCOM 0x07
 /* add more to the end as needed */
 
+#define DRM_FORMAT_RESERVED  ((1ULL << 56) - 1)
+
 #define fourcc_mod_code(vendor, val) \
__u64)DRM_FORMAT_MOD_VENDOR_## vendor) << 56) | (val & 
0x00ffULL))
 
@@ -197,6 +199,15 @@ extern "C" {
  */
 
 /*
+ * Invalid Modifier
+ *
+ * This modifier can be used as a sentinel to terminate the format modifiers
+ * list, or to initialize a variable with an invalid modifier. It might also be
+ * used to report an error back to userspace for certain APIs.
+ */
+#define DRM_FORMAT_MOD_INVALID fourcc_mod_code(NONE, DRM_FORMAT_RESERVED)
+
+/*
  * Linear Layout
  *
  * Just plain linear layout. Note that this is different from no specifying any
@@ -253,6 +264,26 @@ extern "C" {
 #define I915_FORMAT_MOD_Yf_TILED fourcc_mod_code(INTEL, 3)
 
 /*
+ * Intel color control surface (CCS) for render compression
+ *
+ * The framebuffer format must be one of the 8:8:8:8 RGB formats.
+ * The main surface will be plane index 0 and must be Y/Yf-tiled,
+ * the CCS will be plane index 1.
+ *
+ * Each CCS tile matches a 1024x512 pixel area of the main surface.
+ * To match certain aspects of the 3D hardware the CCS is
+ * considered to be made up of normal 128Bx32 Y tiles, Thus
+ * the CCS pitch must be specified in multiples of 128 bytes.
+ *
+ * In reality the CCS tile appears to be a 64Bx64 Y tile, composed
+ * of QWORD (8 bytes) chunks instead of OWORD (16 bytes) chunks.
+ * But that fact is not relevant unless the memory is accessed
+ * directly.
+ */
+#define I915_FORMAT_MOD_Y_TILED_CCSfourcc_mod_code(INTEL, 4)
+#define I915_FORMAT_MOD_Yf_TILED_CCS   fourcc_mod_code(INTEL, 5)
+
+/*
  * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
  *
  * Macroblocks are laid in a Z-shape, and each pixel data is following the
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [Bug 102218] Nier:Automata (through wine) - Bloom too bright

[bugzilla-daemon]

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

Fabian Maurer  changed:

   What|Removed |Added

   See Also||https://bugs.winehq.org/sho
   ||w_bug.cgi?id=43406

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

[Mesa-dev] [Bug 102218] Nier:Automata (through wine) - Bloom too bright

[bugzilla-daemon]

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

Bug ID: 102218
   Summary: Nier:Automata (through wine) - Bloom too bright
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: dark.shad...@web.de
QA Contact: mesa-dev@lists.freedesktop.org

Created attachment 133500
  --> https://bugs.freedesktop.org/attachment.cgi?id=133500=edit
Scene from the beginning on linux

Tested this issue with running a game called "NieR:Automata" in
wine2.14-staging with CSMT enabled.
It renders fine overall, but the bloom is way too bright, see the attached
screenshots.
It seems to work fine with the proprietary NVIDIA driver though, as seen in the
wine appdb entry for the game.

Uploaded an OpenGL trace here:
http://www.mediafire.com/file/n3n1jn4cndizb5k/nier-opengl.7z (732MB compressed,
5.1GB unpacked)

Also see the linked wine bug for more info and an edited shader that fixed the
issue.


LIBGL_ALWAYS_SOFTWARE doesn't work at all.

System the bug was tested on:
- Arch Linux 64bit
- Linux 4.12.7, AMDGPU driver
- Mesa 17.3.0-devel (git-b420680ede)/ Mesa 17.1
- Radeon R9 285

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

Re: [Mesa-dev] [PATCH v2 2/4] st/omx_tizonia: Add --enable-omx-tizonia flag and build files

[Leo Liu]

On 08/14/2017 12:25 PM, Gurkirpal Singh wrote:



On Mon, Aug 14, 2017 at 8:55 PM, Leo Liu > wrote:




On 08/14/2017 11:19 AM, Gurkirpal Singh wrote:



On Mon, Aug 14, 2017 at 8:05 PM, Leo Liu > wrote:



On 08/14/2017 05:46 AM, Julien Isorce wrote:

Hi Leo,

>It would be better if you can extract the common code
between bellagio and tizonia to avoid the duplication.

This is something Gurkirpal and me discussed, like having
state_trackers/omx/common, state_trackers/omx/bellagio,
state_trackers/omx/tizonia. To anticipate that Gurkirpal
sent an email

https://www.mail-archive.com/mesa-dev@lists.freedesktop.org/msg153562.html


during the Community Bonding period in May (a few weeks from
the date (early May) students are officially accepted to the
date (end May) where student actually starts working)

The problem with the directory layout above is that it would
look like it will be built together in the same shared
library. This is not good because it is suppose to
export OMX_ComponentInit for each target. Of course this
would still be possible to have 2 shared libs but I believe
in state_trackers dir, all sub dir are for one target. Also
we were afraid that there would be other limitations so we
decided to go for a separate directory.
And since there were no objections in Gurkirpal's mail above
we went this way.

Now if I look into state_trackers/omx_tizonia, in fact the
common code with state_trackers/omx_bellagio does not have
anything to do with omx. For example "slice_header". Maybe
it can be moved to gallium/auxiliary/vl/ like it is done
already for vl_rbsp_init. Same for omx_get_screen.

So I suggest this 'factorization' to be not a blocker for
merging state_trackers/omx_tizonia into usptream. But later
on we can move gradually bits from
state_trackers/omx_bellagio to gallium/auxiliary. And then
make state_trackers/omx_tizonia use it as well.
This way you will only bother about maintaining
state_trackers/omx_bellagio the time being. This also allows
to not slowly get its work lost.

Of course we would have done differently if we knew advance.
But as today Gurkirpal won't have enough time to do this
factorization/move as the project ends in 1 week. Having all
of this merged in upstream is not mandatory to succeed the
project but Gurkirpal will need some rest after these 3
months of hard work. And who knows what happens after,
whether he will still be around after sometimes or not. And
this is entirely up to him.

So again I suggest this factorization/move not to be a
blocker for the reasons above. What do you think?


When the whole project will be completed, as least same
status as bellagio? Is there anyone keep working on this
project after this step 1?

Hi, I plan on continuing working on this after the GSoC project
ends.


Is the GSoC project done with your current patches?

Apart from these patches, at least two more will be needed for the 
project. One for adding H.264 enc and other for adding EGLImage 
support to H.264 dec.
Since I keep revising the commits quite frequently I'll give the link 
to the branch https://github.com/gpalsingh/mesa/commits/gsoc
Good to see them, then why did you send them to review as well? not 
working well or other reason?
And why don't you include mpeg2 and hevc to your project, and then after 
performance test, it could be replacing bellagio completely.


Regards,
Leo




Cheers


Regards,
Leo




The left stuff compared to bellagio are codecs of mpeg2 and
hevc, and encoding that is more important, since the most
usage for omx currently is to use transcoding from one codec
to another.

Other is the transcoding performance, at least meet the
performance of bellagio's.

If the above could be addressed at early time,  we could
remove Bellagio completely, then there is no need to do any
refactor now.

The original plan was this but making gst-omx  OMX IL 1.2
compatible has been a bit time consuming.



BTW what's the plan for new feature like EGL Images?

We've been able to make it work but with wrong colours in output.
I've written more about it and the performance comparison in my
blog post here
https://singhcodes.wordpress.com/2017/08/04/gsoc-2017-third-phase-starts/

But recently the EGLImage hook stopped 

Re: [Mesa-dev] [PATCH] swr/rast: [rasterizer core] fix invalid casting for calls to Interlocked* functions

[Cherniak, Bruce]

Reviewed-by: Bruce Cherniak 

> On Aug 9, 2017, at 5:22 PM, Tim Rowley  wrote:
> 
> CID: 1416243, 1416244, 1416255
> CC: mesa-sta...@lists.freedesktop.org
> ---
> src/gallium/drivers/swr/rasterizer/core/api.cpp | 2 +-
> src/gallium/drivers/swr/rasterizer/core/context.h   | 8 
> src/gallium/drivers/swr/rasterizer/core/threads.cpp | 4 ++--
> 3 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/src/gallium/drivers/swr/rasterizer/core/api.cpp 
> b/src/gallium/drivers/swr/rasterizer/core/api.cpp
> index 8dc9ac2..ccb6dfb 100644
> --- a/src/gallium/drivers/swr/rasterizer/core/api.cpp
> +++ b/src/gallium/drivers/swr/rasterizer/core/api.cpp
> @@ -189,7 +189,7 @@ void QueueWork(SWR_CONTEXT *pContext)
> 
> if (IsDraw)
> {
> -InterlockedIncrement((volatile long*)>drawsOutstandingFE);
> +InterlockedIncrement(>drawsOutstandingFE);
> }
> 
> _ReadWriteBarrier();
> diff --git a/src/gallium/drivers/swr/rasterizer/core/context.h 
> b/src/gallium/drivers/swr/rasterizer/core/context.h
> index 131b3cb..bcd5801 100644
> --- a/src/gallium/drivers/swr/rasterizer/core/context.h
> +++ b/src/gallium/drivers/swr/rasterizer/core/context.h
> @@ -409,12 +409,12 @@ struct DRAW_CONTEXT
> booldependent;  // Backend work is dependent on all 
> previous BE
> boolisCompute;  // Is this DC a compute context?
> boolcleanupState;   // True if this is the last draw using an 
> entry in the state ring.
> -volatile bool   doneFE; // Is FE work done for this draw?
> 
> FE_WORK FeWork;
> 
> +volatile OSALIGNLINE(bool)   doneFE; // Is FE work done for 
> this draw?
> volatile OSALIGNLINE(uint32_t)   FeLock;
> -volatile int32_tthreadsDone;
> +volatile OSALIGNLINE(uint32_t)   threadsDone;
> 
> SYNC_DESC   retireCallback; // Call this func when this DC is retired.
> };
> @@ -503,9 +503,9 @@ struct SWR_CONTEXT
> // Scratch space for workers.
> uint8_t** ppScratch;
> 
> -volatile int32_t  drawsOutstandingFE;
> +volatile OSALIGNLINE(uint32_t)  drawsOutstandingFE;
> 
> -CachingAllocator cachingArenaAllocator;
> +OSALIGNLINE(CachingAllocator) cachingArenaAllocator;
> uint32_t frameCount;
> 
> uint32_t lastFrameChecked;
> diff --git a/src/gallium/drivers/swr/rasterizer/core/threads.cpp 
> b/src/gallium/drivers/swr/rasterizer/core/threads.cpp
> index 70bde02..b704d23 100644
> --- a/src/gallium/drivers/swr/rasterizer/core/threads.cpp
> +++ b/src/gallium/drivers/swr/rasterizer/core/threads.cpp
> @@ -393,7 +393,7 @@ INLINE void ExecuteCallbacks(SWR_CONTEXT* pContext, 
> uint32_t workerId, DRAW_CONT
> // inlined-only version
> INLINE int32_t CompleteDrawContextInl(SWR_CONTEXT* pContext, uint32_t 
> workerId, DRAW_CONTEXT* pDC)
> {
> -int32_t result = InterlockedDecrement((volatile long*)>threadsDone);
> +int32_t result = 
> static_cast(InterlockedDecrement(>threadsDone));
> SWR_ASSERT(result >= 0);
> 
> AR_FLUSH(pDC->drawId);
> @@ -639,7 +639,7 @@ INLINE void CompleteDrawFE(SWR_CONTEXT* pContext, 
> uint32_t workerId, DRAW_CONTEX
> _mm_mfence();
> pDC->doneFE = true;
> 
> -InterlockedDecrement((volatile long*)>drawsOutstandingFE);
> +InterlockedDecrement(>drawsOutstandingFE);
> }
> 
> void WorkOnFifoFE(SWR_CONTEXT *pContext, uint32_t workerId, uint32_t 
> )
> -- 
> 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 v2 2/4] st/omx_tizonia: Add --enable-omx-tizonia flag and build files

[Gurkirpal Singh]

On Mon, Aug 14, 2017 at 8:55 PM, Leo Liu  wrote:

>
>
> On 08/14/2017 11:19 AM, Gurkirpal Singh wrote:
>
>
>
> On Mon, Aug 14, 2017 at 8:05 PM, Leo Liu  wrote:
>
>>
>>
>> On 08/14/2017 05:46 AM, Julien Isorce wrote:
>>
>> Hi Leo,
>>
>> >It would be better if you can extract the common code between bellagio
>> and tizonia to avoid the duplication.
>>
>> This is something Gurkirpal and me discussed, like having
>> state_trackers/omx/common, state_trackers/omx/bellagio,
>> state_trackers/omx/tizonia. To anticipate that Gurkirpal sent an email
>> https://www.mail-archive.com/mesa-dev@lists.freedeskto
>> p.org/msg153562.html during the Community Bonding period in May (a few
>> weeks from the date (early May) students are officially accepted to the
>> date (end May) where student actually starts working)
>>
>> The problem with the directory layout above is that it would look like it
>> will be built together in the same shared library. This is not good because
>> it is suppose to export OMX_ComponentInit for each target. Of course this
>> would still be possible to have 2 shared libs but I believe in
>> state_trackers dir, all sub dir are for one target. Also we were afraid
>> that there would be other limitations so we decided to go for a separate
>> directory.
>> And since there were no objections in Gurkirpal's mail above we went this
>> way.
>>
>> Now if I look into state_trackers/omx_tizonia, in fact the common code
>> with state_trackers/omx_bellagio does not have anything to do with omx. For
>> example "slice_header". Maybe it can be moved to gallium/auxiliary/vl/ like
>> it is done already for vl_rbsp_init. Same for omx_get_screen.
>>
>> So I suggest this 'factorization' to be not a blocker for merging
>> state_trackers/omx_tizonia into usptream. But later on we can move
>> gradually bits from state_trackers/omx_bellagio to gallium/auxiliary. And
>> then make state_trackers/omx_tizonia use it as well.
>> This way you will only bother about maintaining
>> state_trackers/omx_bellagio the time being. This also allows to not slowly
>> get its work lost.
>>
>> Of course we would have done differently if we knew advance. But as today
>> Gurkirpal won't have enough time to do this factorization/move as the
>> project ends in 1 week. Having all of this merged in upstream is not
>> mandatory to succeed the project but Gurkirpal will need some rest after
>> these 3 months of hard work. And who knows what happens after, whether he
>> will still be around after sometimes or not. And this is entirely up to him.
>>
>> So again I suggest this factorization/move not to be a blocker for the
>> reasons above. What do you think?
>>
>>
>> When the whole project will be completed, as least same status as
>> bellagio? Is there anyone keep working on this project after this step 1?
>>
> Hi, I plan on continuing working on this after the GSoC project ends.
>
>
> Is the GSoC project done with your current patches?
>
> Apart from these patches, at least two more will be needed for the
project. One for adding H.264 enc and other for adding EGLImage support to
H.264 dec.
Since I keep revising the commits quite frequently I'll give the link to
the branch https://github.com/gpalsingh/mesa/commits/gsoc

Cheers

>
> Regards,
> Leo
>
>
>
>> The left stuff compared to bellagio are codecs of mpeg2 and hevc, and
>> encoding that is more important, since the most usage for omx currently is
>> to use transcoding from one codec to another.
>>
>> Other is the transcoding performance,  at least meet the performance of
>> bellagio's.
>>
>> If the above could be addressed at early time,  we could remove Bellagio
>> completely, then there is no need to do any refactor now.
>>
> The original plan was this but making gst-omx  OMX IL 1.2 compatible has
> been a bit time consuming.
>
>>
>>
>> BTW what's the plan for new feature like EGL Images?
>>
> We've been able to make it work but with wrong colours in output. I've
> written more about it and the performance comparison in my blog post here
> https://singhcodes.wordpress.com/2017/08/04/gsoc-2017-third-phase-starts/
> But recently the EGLImage hook stopped working and I've opened the issue
> https://github.com/gpalsingh/mesa/issues/15 to keep track of it.
> This happened after we fixed another issue which made changes to gst-omx
> which might be the cause https://github.com/gpalsingh/mesa/issues/2#
> issuecomment-321839195
> I'm still looking into this.
>
> Cheers
>
>>
>> Regards,
>> Leo
>>
>>
>>
>> Thx
>> Julien
>>
>> On 13 August 2017 at 16:52, Gurkirpal Singh 
>> wrote:
>>
>>>
>>>
>>> On Sun, Aug 13, 2017 at 8:47 AM, Leo Liu  wrote:
>>>
 Where is the patch 1?
>>>
>>> Sorry for the patches got messed up somehow while sending, I could only
>>> see two patches on mail-archive but three on patchwork.
>>> Tried two times and same result.
>>> About the first one I got a mail saying that it was too large has been
>>> put 

[Mesa-dev] [Bug 101486] TAHITI XT hangs once "dota2 -vulkan" dashboard is loaded

[bugzilla-daemon]

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

--- Comment #2 from Gregor Münch  ---
Hi,
Ive got also a Tahiti (Radeon HD 7970), I had exactly the same issue with Dota2
and Vulkan like mentioned in this bug report. But things are working for me
after:
https://cgit.freedesktop.org/mesa/mesa/commit/?id=82ba384c10d598bee4786ef5f79e92a0e7b53892
The only difference is, Im using latest linux-amd-staging-4.11 maybe you could
try this?

-- 
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] isl: Validate row pitch of stencil surfaces.

[Pohjolainen, Topi]

On Thu, Aug 10, 2017 at 07:01:00AM -0700, Jason Ekstrand wrote:
> 
> 
> On August 10, 2017 2:42:29 AM Kenneth Graunke  wrote:
> 
> > On Wednesday, August 9, 2017 1:20:53 PM PDT Jason Ekstrand wrote:
> > > On Wed, Aug 9, 2017 at 1:09 PM, Kenneth Graunke 
> > > wrote:
> > > 
> > > > Also, silence an obnoxious finishme that started occurring for all
> > > > GL applications which use stencil after the i965 ISL conversion.
> > > > ---
> > > >  src/intel/isl/isl.c | 6 --
> > > >  1 file changed, 4 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/src/intel/isl/isl.c b/src/intel/isl/isl.c
> > > > index 6b4203d79d2..c35116214c8 100644
> > > > --- a/src/intel/isl/isl.c
> > > > +++ b/src/intel/isl/isl.c
> > > > @@ -1367,8 +1367,10 @@ isl_calc_row_pitch(const struct isl_device *dev,
> > > > !pitch_in_range(row_pitch, _3DSTATE_HIER_DEPTH_BUFFER_
> > > > SurfacePitch_bits(dev->info)))
> > > >return false;
> > > >
> > > > -   if (surf_info->usage & ISL_SURF_USAGE_STENCIL_BIT)
> > > > -  isl_finishme("validate row pitch of stencil surfaces");
> > > > +   if (dev->use_separate_stencil &&
> > > > +   (surf_info->usage & ISL_SURF_USAGE_STENCIL_BIT) &&
> > > > +   !pitch_in_range(row_pitch, _3DSTATE_STENCIL_BUFFER_
> > > > SurfacePitch_bits(dev->info)))
> > > >
> > > 
> > > Topi sent the same patch.  This doesn't work on gen4.
> > 
> > Did you see that I have dev->use_separate_stencil in the condition?
> > 
> > That essentially restricts this check to Gen6+, so Gen4-5 won't do
> > any checking at all.  Which is exactly how much checking it's doing
> > today. :)
> > 
> > Perhaps you'd instead prefer:
> > 
> >uint32_t stencil_pitch_bits =
> >   dev->use_separate_stencil ?
> >   _3DSTATE_STENCIL_BUFFER_SurfacePitch_bits(dev->info) :
> >   _3DSTATE_DEPTH_BUFFER_SurfacePitch_bits(dev->info);
> > 
> >if ((surf_info->usage & ISL_SURF_USAGE_STENCIL_BIT) &&
> >!pitch_in_range(row_pitch, stencil_pitch_bits))
> >   return false;
> > 
> > so that we use the 3DSTATE_DEPTH_BUFFER pitch limits on Gen4 or whenever
> > we're doing combined depth/stencil, and 3DSTATE_STENCIL_BUFFER's limits
> > when doing separate stencil.
> 
> Works for me

Thanks Ken, and sorry for leaving it behind.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] [rfc] ac/surface: always increase dcc size alignment.

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Mon, Aug 14, 2017 at 7:01 AM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> So with tile swizzle, and dcc enabled, the vrdashboard GL app
> generates a bunch of VM faults, this fixes it, however
> it now sometimes generates garbage, but I'm just sending this
> out to have some place to start.
>
> (it could be a tile swizzle import/export issue still).
>
> Signed-off-by: Dave Airlie 
> ---
>  src/amd/common/ac_surface.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
> index 823a65d..1203c2f 100644
> --- a/src/amd/common/ac_surface.c
> +++ b/src/amd/common/ac_surface.c
> @@ -733,7 +733,7 @@ static int gfx6_compute_surface(ADDR_HANDLE addrlib,
>  * This is what addrlib does, but calling addrlib would be a lot more
>  * complicated.
>  */
> -   if (surf->dcc_size && config->info.levels > 1) {
> +   if (surf->dcc_size) {
> /* The smallest miplevels that are never compressed by DCC
>  * still read the DCC buffer via TC if the base level uses 
> DCC,
>  * and for some reason the DCC buffer needs to be larger if
> --
> 2.9.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 v2 2/4] st/omx_tizonia: Add --enable-omx-tizonia flag and build files

[Julien Isorce]

Hi Leo,

>It would be better if you can extract the common code between bellagio and
tizonia to avoid the duplication.

This is something Gurkirpal and me discussed, like having
state_trackers/omx/common, state_trackers/omx/bellagio,
state_trackers/omx/tizonia. To anticipate that Gurkirpal sent an email
https://www.mail-archive.com/mesa-dev@lists.freedesktop.org/msg153562.html
during the Community Bonding period in May (a few weeks from the date
(early May) students are officially accepted to the date (end May) where
student actually starts working)

The problem with the directory layout above is that it would look like it
will be built together in the same shared library. This is not good because
it is suppose to export OMX_ComponentInit for each target. Of course this
would still be possible to have 2 shared libs but I believe in
state_trackers dir, all sub dir are for one target. Also we were afraid
that there would be other limitations so we decided to go for a separate
directory.
And since there were no objections in Gurkirpal's mail above we went this
way.

Now if I look into state_trackers/omx_tizonia, in fact the common code with
state_trackers/omx_bellagio does not have anything to do with omx. For
example "slice_header". Maybe it can be moved to gallium/auxiliary/vl/ like
it is done already for vl_rbsp_init. Same for omx_get_screen.

So I suggest this 'factorization' to be not a blocker for merging
state_trackers/omx_tizonia into usptream. But later on we can move
gradually bits from state_trackers/omx_bellagio to gallium/auxiliary. And
then make state_trackers/omx_tizonia use it as well.
This way you will only bother about maintaining state_trackers/omx_bellagio
the time being. This also allows to not slowly get its work lost.

Of course we would have done differently if we knew advance. But as today
Gurkirpal won't have enough time to do this factorization/move as the
project ends in 1 week. Having all of this merged in upstream is not
mandatory to succeed the project but Gurkirpal will need some rest after
these 3 months of hard work. And who knows what happens after, whether he
will still be around after sometimes or not. And this is entirely up to him.

So again I suggest this factorization/move not to be a blocker for the
reasons above. What do you think?

Thx
Julien

On 13 August 2017 at 16:52, Gurkirpal Singh  wrote:

>
>
> On Sun, Aug 13, 2017 at 8:47 AM, Leo Liu  wrote:
>
>> Where is the patch 1?
>
> Sorry for the patches got messed up somehow while sending, I could only
> see two patches on mail-archive but three on patchwork.
> Tried two times and same result.
> About the first one I got a mail saying that it was too large has been put
> aside for mod approval.
> The changes I made were to just rename the st/omx directory to
> st/omx_bellagio (the reason it became large)
> and renaming bits in the configure.ac and Makefiles.
>
>>
>>
>>
>> On 08/12/2017 12:07 PM, Gurkirpal Singh wrote:
>>
>>> Coexist with --enable-omx so they can be built independently
>>> Detect tizonia package config file
>>> Generate libomxtiz_mesa.so and install it to libtizcore.pc::pluginsdir
>>> Only compile empty source (target.c) for now.
>>>
>>> v2: Show error message when --enable-omx is used (Christian)
>>>  Use single PKG_CHECK_MODULES for omx_tizonia checks (Emil)
>>>  Use spaces instead of tabs
>>>  Add checks around omx-tizonia
>>>
>>> GSoC Project link: https://summerofcode.withgoogl
>>> e.com/projects/#4737166321123328
>>>
>>> Signed-off-by: Gurkirpal Singh 
>>> Reviewed-and-Tested-by: Julien Isorce 
>>> ---
>>>   configure.ac| 40 ++-
>>>   src/gallium/Makefile.am |  4 ++
>>>   src/gallium/targets/omx-tizonia/Makefile.am | 77
>>> +
>>>   src/gallium/targets/omx-tizonia/omx.sym | 11 +
>>>   src/gallium/targets/omx-tizonia/target.c|  2 +
>>>   5 files changed, 132 insertions(+), 2 deletions(-)
>>>   create mode 100644 src/gallium/targets/omx-tizonia/Makefile.am
>>>   create mode 100644 src/gallium/targets/omx-tizonia/omx.sym
>>>   create mode 100644 src/gallium/targets/omx-tizonia/target.c
>>>
>>> diff --git a/configure.ac b/configure.ac
>>> index 38af96a..5669695 100644
>>> --- a/configure.ac
>>> +++ b/configure.ac
>>> @@ -85,6 +85,7 @@ dnl Versions for external dependencies
>>>   DRI2PROTO_REQUIRED=2.8
>>>   GLPROTO_REQUIRED=1.4.14
>>>   LIBOMXIL_BELLAGIO_REQUIRED=0.0
>>> +LIBOMXIL_TIZONIA_REQUIRED=0.9.0
>>>   LIBVA_REQUIRED=0.38.0
>>>   VDPAU_REQUIRED=1.1
>>>   WAYLAND_REQUIRED=1.11
>>> @@ -1216,14 +1217,19 @@ AC_ARG_ENABLE([vdpau],
>>>  [enable_vdpau=auto])
>>>   AC_ARG_ENABLE([omx],
>>>  [AS_HELP_STRING([--enable-omx],
>>> - [DEPRECATED: Use --enable-omx-bellagio instead
>>> @<:@default=auto@:>@])],
>>> -   [AC_MSG_ERROR([--enable-omx is deprecated. Use --enable-omx-bellagio
>>> 

Re: [Mesa-dev] [PATCH V3] i965 : Optimize atom state flag checks

[Tapani Pälli]

Hello;

On 07/25/2017 05:17 PM, Marathe, Yogesh wrote:

Hi Matt, Sorry for late reply, please see below.


-Original Message-
From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On Behalf
Of Matt Turner
Sent: Saturday, July 22, 2017 12:12 AM
To: Muthukumar, Aravindan 
Cc: mesa-dev@lists.freedesktop.org; Marathe, Yogesh

Subject: Re: [Mesa-dev] [PATCH V3] i965 : Optimize atom state flag checks

On 07/21, aravindan.muthuku...@intel.com wrote:

From: Aravindan Muthukumar 

This patch improves CPI Rate(Cycles per Instruction) and branch miss
predict for i965. The function check_state() was showing CPI retired rate.

Performance stats with android:
- CPI retired lowered by 28% (lower is better)
- Branch missprediction lowered by 13% (lower is better)
- 3DMark improved by 2%

The dissassembly doesn't show difference, although above results were
observed with patch.




Yes this is true for V3 where we removed the function based on a review comment.


If there's no difference in the assembly then whatever measurements you have
taken must be noise.



No that's not guaranteed either. Lot of things still depend on how instructions 
are
aligned, sometimes even changing linking order gives different results where
disassemblies of individual functions remain same.
  

I applied the patch and inspected brw_state_upload.o. There are assembly
differences. I can produce the same assembly as this patch by just pulling the 
if
statement out of check_and_emit_atom() and into the caller. The replacement
of check_state() with a macro is completely unnecessary.


diff --git a/src/mesa/drivers/dri/i965/brw_state_upload.c
b/src/mesa/drivers/dri/i965/brw_state_upload.c
index acaa97ee7d..b163e1490d 100644
--- a/src/mesa/drivers/dri/i965/brw_state_upload.c
+++ b/src/mesa/drivers/dri/i965/brw_state_upload.c
@@ -439,14 +439,12 @@ merge_ctx_state(struct brw_context *brw,  }

  static inline void
-check_and_emit_atom(struct brw_context *brw,
-struct brw_state_flags *state,
-const struct brw_tracked_state *atom)
+emit_atom(struct brw_context *brw,
+  struct brw_state_flags *state,
+  const struct brw_tracked_state *atom)
  {
-   if (check_state(state, >dirty)) {
-  atom->emit(brw);
-  merge_ctx_state(brw, state);
-   }
+   atom->emit(brw);
+   merge_ctx_state(brw, state);
  }

  static inline void
@@ -541,7 +539,9 @@ brw_upload_pipeline_state(struct brw_context *brw,
 const struct brw_tracked_state *atom = [i];
 struct brw_state_flags generated;

- check_and_emit_atom(brw, , atom);
+ if (check_state(, >dirty)) {
+emit_atom(brw, , atom);
+ }

 accumulate_state(, >dirty);

@@ -558,7 +558,9 @@ brw_upload_pipeline_state(struct brw_context *brw,
for (i = 0; i < num_atoms; i++) {
 const struct brw_tracked_state *atom = [i];

- check_and_emit_atom(brw, , atom);
+ if (check_state(, >dirty)) {
+emit_atom(brw, , atom);
+ }
}
 }


With that said, the assembly differences are not understandable to me.
Why should extracting an if statement from a static inline function into the 
caller
of that function cause any difference whatsoever?


Agreed, it shouldn't in case of static inline.



I'm viewing the assembly differences with:

wdiff -n \
 -w $'\033[30;41m' -x $'\033[0m' \
 -y $'\033[30;42m' -z $'\033[0m' \
 <(objdump -d brw_state_upload.o.before | sed -e 's/^.*\t//') \
 <(objdump -d brw_state_upload.o.wtf| sed -e 's/^.*\t//') | less -R

and the only real difference is the movement of some call and jmp instructions.

I cannot take the patch without some reasonable explanation for the change.


Ok I think this has been discussed already and we agree that there is no big 
visible difference
in disassembly which can be pointed out for improvement. Although, as you said 
this movement
of instructions can cause this. If with this patch instructions get cache 
aligned that too can show
improvement.  This is a busy function with bad CPI. Hence chosen for 
optimization. Branch miss
predict is another metric.  Do we want to consider all these or just 
disassembly?


I don't have a reasonable explanation to give but I made some benchmark 
runs today (3DMark "Ice Storm Unlimited" test ) and I'm getting 
consistently 1-2% better results with the patch. I also tried the 
mentioned modification "pulling the if statement out of 
check_and_emit_atom() and into the caller" and it has same performance 
benefits. What I can tell from assembly dump is that 
brw_upload_render_state function becomes slightly shorter, there's 
movement with call and jmp and dump with the patch has less mov and nopl 
calls in total.




Let me make one more attempt, we clearly see icache misses for 
brw_upload_pipeline_state also
reduced with patch against without patch. Do 

Re: [Mesa-dev] [PATCH] configure: Trust LLVM >= 4.0 llvm-config --libs for shared libraries

[Michel Dänzer]

On 11/08/17 02:13 AM, Jan Vesely wrote:
> On Thu, 2017-08-10 at 17:45 +0100, Emil Velikov wrote:
>>
>> Topic for another thread:
>> There's been a handful of issues reported with BUILD_SHARED_LIBS=ON.
>> Should we consider that unsupported setup and error out?

I don't really see the point / gain in that.


> please no.
> BUILD_SHARED_LIBS=ON is a must for development setup
> debug build of clang + llvm takes 1.4GB, each. Having a ~2.8GB library,
> is a really bad idea for testing,

Not sure what testing you're referring to exactly, but IME application
startup takes on the order of hundreds of ms longer when linking against
the individual shared libraries than when linking against the single
one. It's one reason why distros building with BUILD_SHARED_LIBS=ON is
just silly.


> not to mention linking time that goes well into minutes for even a
> minor change in LLVM.

It can certainly take a long time, but I don't remember it taking
minutes. Are you counting the time for linking other libraries / tools
against libLLVM-*.0*.so as well? You can avoid that by explicitly
building only the library, e.g.:

 ninja [...] lib/libLLVM-6.0svn.so

Also, using the gold or lld linker might help.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer



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

Re: [Mesa-dev] [PATCH] configure: Trust LLVM >= 4.0 llvm-config --libs for shared libraries

[Michel Dänzer]

On 11/08/17 01:45 AM, Emil Velikov wrote:
> On 9 August 2017 at 02:00, Michel Dänzer  wrote:
>> On 09/08/17 03:24 AM, Emil Velikov wrote:
>>>
>>> I think we'd want to keep the best of both - just not sure how to
>>> exactly do that.
>>> --libs/--libfiles was completely busted with LLVM 3.9 and is back to
>>> normal with 4.0.
>>>
>>> Could we use that somehow?
>>
>> This patch relies on llvm-config --libs with LLVM >= 4.0. If you mean
>> something else, please be more specific.
>>
> That's the thing - in some versions --libs is busted while for others
> --libs/--libfiles.

Do you have any specific information about --libs being broken with
recent versions of LLVM? I though that was fixed long ago.


> That said, patch does exactly what it says on the
> Reviewed-by: Emil Velikov 

Thanks, pushed.


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

Re: [Mesa-dev] [PATCH v2 1/4] st/omx_bellagio: Rename state tracker and option

[Christian König]

Am 12.08.2017 um 18:07 schrieb Gurkirpal Singh:

Changes --enable-omx option to --enable-omx-bellagio

Signed-off-by: Gurkirpal Singh 
Reviewed-and-Tested-by: Julien Isorce 


Acked-by: Christian König 

Any objections that I push this one to master preliminary?

Regards,
Christian.


---
  configure.ac   |   49 +-
  src/gallium/Makefile.am|4 +-
  src/gallium/state_trackers/omx/Makefile.am |   35 -
  src/gallium/state_trackers/omx/Makefile.sources|   10 -
  src/gallium/state_trackers/omx/entrypoint.c|  152 ---
  src/gallium/state_trackers/omx/entrypoint.h|   48 -
  src/gallium/state_trackers/omx/vid_dec.c   |  665 --
  src/gallium/state_trackers/omx/vid_dec.h   |  148 ---
  src/gallium/state_trackers/omx/vid_dec_h264.c  | 1032 
  src/gallium/state_trackers/omx/vid_dec_h265.c  | 1013 
  src/gallium/state_trackers/omx/vid_dec_mpeg12.c|  383 --
  src/gallium/state_trackers/omx/vid_enc.c   | 1278 
  src/gallium/state_trackers/omx/vid_enc.h   |   96 --
  .../state_trackers/omx_bellagio/Makefile.am|   35 +
  .../state_trackers/omx_bellagio/Makefile.sources   |   10 +
  .../state_trackers/omx_bellagio/entrypoint.c   |  152 +++
  .../state_trackers/omx_bellagio/entrypoint.h   |   48 +
  src/gallium/state_trackers/omx_bellagio/vid_dec.c  |  665 ++
  src/gallium/state_trackers/omx_bellagio/vid_dec.h  |  148 +++
  .../state_trackers/omx_bellagio/vid_dec_h264.c | 1032 
  .../state_trackers/omx_bellagio/vid_dec_h265.c | 1013 
  .../state_trackers/omx_bellagio/vid_dec_mpeg12.c   |  383 ++
  src/gallium/state_trackers/omx_bellagio/vid_enc.c  | 1278 
  src/gallium/state_trackers/omx_bellagio/vid_enc.h  |   96 ++
  src/gallium/targets/omx-bellagio/Makefile.am   |   75 ++
  src/gallium/targets/omx-bellagio/omx.sym   |   11 +
  src/gallium/targets/omx-bellagio/target.c  |2 +
  src/gallium/targets/omx/Makefile.am|   75 --
  src/gallium/targets/omx/omx.sym|   11 -
  src/gallium/targets/omx/target.c   |2 -
  30 files changed, 4977 insertions(+), 4972 deletions(-)
  delete mode 100644 src/gallium/state_trackers/omx/Makefile.am
  delete mode 100644 src/gallium/state_trackers/omx/Makefile.sources
  delete mode 100644 src/gallium/state_trackers/omx/entrypoint.c
  delete mode 100644 src/gallium/state_trackers/omx/entrypoint.h
  delete mode 100644 src/gallium/state_trackers/omx/vid_dec.c
  delete mode 100644 src/gallium/state_trackers/omx/vid_dec.h
  delete mode 100644 src/gallium/state_trackers/omx/vid_dec_h264.c
  delete mode 100644 src/gallium/state_trackers/omx/vid_dec_h265.c
  delete mode 100644 src/gallium/state_trackers/omx/vid_dec_mpeg12.c
  delete mode 100644 src/gallium/state_trackers/omx/vid_enc.c
  delete mode 100644 src/gallium/state_trackers/omx/vid_enc.h
  create mode 100644 src/gallium/state_trackers/omx_bellagio/Makefile.am
  create mode 100644 src/gallium/state_trackers/omx_bellagio/Makefile.sources
  create mode 100644 src/gallium/state_trackers/omx_bellagio/entrypoint.c
  create mode 100644 src/gallium/state_trackers/omx_bellagio/entrypoint.h
  create mode 100644 src/gallium/state_trackers/omx_bellagio/vid_dec.c
  create mode 100644 src/gallium/state_trackers/omx_bellagio/vid_dec.h
  create mode 100644 src/gallium/state_trackers/omx_bellagio/vid_dec_h264.c
  create mode 100644 src/gallium/state_trackers/omx_bellagio/vid_dec_h265.c
  create mode 100644 src/gallium/state_trackers/omx_bellagio/vid_dec_mpeg12.c
  create mode 100644 src/gallium/state_trackers/omx_bellagio/vid_enc.c
  create mode 100644 src/gallium/state_trackers/omx_bellagio/vid_enc.h
  create mode 100644 src/gallium/targets/omx-bellagio/Makefile.am
  create mode 100644 src/gallium/targets/omx-bellagio/omx.sym
  create mode 100644 src/gallium/targets/omx-bellagio/target.c
  delete mode 100644 src/gallium/targets/omx/Makefile.am
  delete mode 100644 src/gallium/targets/omx/omx.sym
  delete mode 100644 src/gallium/targets/omx/target.c


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