date:20170320

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

2017-03-20 Thread bugzilla-daemon

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

--- Comment #27 from Timothy Arceri  ---
https://patchwork.freedesktop.org/series/21582/(In reply to John from comment
#26)
> Timothy, do you have any patch you'd like me to test?
> 
> Thanks!
> John

This should do it:

https://patchwork.freedesktop.org/series/21582/

-- 
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] [PATCH 3/3] util/disk_cache: write cache entry keys to file header

2017-03-20 Thread Timothy Arceri

This can be used to deal with key hash collisions from different
versions (should we find that to actually happen) and to find
which mesa version produced the cache entry.
---

 I considered creating the cache key blob at cache creation time but since
 we would want a blob with the null terminator dropped for the hash and one
 that includes the terminator for reading the strings from the header, I
 decided just to create it on the fly to keep the code easier to follow.  

 src/util/disk_cache.c | 91 +++
 1 file changed, 85 insertions(+), 6 deletions(-)

diff --git a/src/util/disk_cache.c b/src/util/disk_cache.c
index 599e58f..f2d67c9 100644
--- a/src/util/disk_cache.c
+++ b/src/util/disk_cache.c
@@ -737,33 +737,60 @@ create_put_job(struct disk_cache *cache, const cache_key 
key,
 }
 
 static void
 destroy_put_job(void *job, int thread_index)
 {
if (job) {
   free(job);
}
 }
 
+static size_t
+cache_keys_size(struct disk_cache *cache)
+{
+   /* The 2 is for the terminating null bytes of the strings */
+   return cache->timestamp_size + cache->gpu_name_size +
+  sizeof(cache->ptr_size) + 2;
+}
+
+static uint8_t *
+generate_cache_keys_blob(struct disk_cache *cache, size_t ck_size)
+{
+   uint8_t *key_blob = malloc(ck_size);
+   if (!key_blob)
+  return NULL;
+
+   size_t ts_size = cache->timestamp_size + 1;
+   memcpy(key_blob, cache->timestamp, ts_size);
+
+   size_t gn_size = cache->gpu_name_size + 1;
+   memcpy(key_blob + ts_size, cache->gpu_name, gn_size);
+
+   memcpy(key_blob + ts_size + gn_size, >ptr_size, sizeof(uint8_t));
+
+   return key_blob;
+}
+
 struct cache_entry_file_data {
uint32_t crc32;
uint32_t uncompressed_size;
 };
 
 static void
 cache_put(void *job, int thread_index)
 {
assert(job);
 
int fd = -1, fd_final = -1, err, ret;
unsigned i = 0;
char *filename = NULL, *filename_tmp = NULL;
+   uint8_t *key_blob = NULL;
struct disk_cache_put_job *dc_job = (struct disk_cache_put_job *) job;
 
filename = get_cache_file(dc_job->cache, dc_job->key);
if (filename == NULL)
   goto done;
 
/* If the cache is too large, evict something else first. */
while (*dc_job->cache->size + dc_job->size > dc_job->cache->max_size &&
   i < 8) {
   evict_lru_item(dc_job->cache);
@@ -808,23 +835,41 @@ cache_put(void *job, int thread_index)
 */
fd_final = open(filename, O_RDONLY | O_CLOEXEC);
if (fd_final != -1) {
   unlink(filename_tmp);
   goto done;
}
 
/* OK, we're now on the hook to write out a file that we know is
 * not in the cache, and is also not being written out to the cache
 * by some other process.
-*
-* Create CRC of the data and store at the start of the file. We will
-* read this when restoring the cache and use it to check for corruption.
+*/
+
+   /* Write the key_blob, this can be used find information about the
+* mesa version that produced the entry or deal with hash collisions,
+* should that ever become a real problem.
+*/
+   size_t ck_size = cache_keys_size(dc_job->cache);
+   key_blob = generate_cache_keys_blob(dc_job->cache, ck_size);
+   if (!key_blob) {
+  unlink(filename_tmp);
+  goto done;
+   }
+
+   ret = write_all(fd, key_blob, ck_size);
+   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) {
   unlink(filename_tmp);
   goto done;
@@ -839,35 +884,37 @@ cache_put(void *job, int thread_index)
if (file_size == 0) {
   unlink(filename_tmp);
   goto done;
}
ret = rename(filename_tmp, filename);
if (ret == -1) {
   unlink(filename_tmp);
   goto done;
}
 
-   file_size += cf_data_size;
+   file_size += cf_data_size + ck_size;
p_atomic_add(dc_job->cache->size, file_size);
 
  done:
if (fd_final != -1)
   close(fd_final);
/* This close finally releases the flock, (now that the final file
 * has been renamed into place and the size has been added).
 */
if (fd != -1)
   close(fd);
if (filename_tmp)
   free(filename_tmp);
if (filename)
   free(filename);
+   if (key_blob)
+  free(key_blob);
 }
 
 void
 disk_cache_put(struct disk_cache *cache, const cache_key key,
const void *data, size_t size)
 {
struct disk_cache_put_job *dc_job =
   create_put_job(cache, key, data, size);
 
if (dc_job) {
@@ -936,32 +983,64 @@ disk_cache_get(struct disk_cache *cache, const cache_key 
key, size_t *size)
if (fd == -1)
   goto fail;
 
if (fstat(fd, ) == -1)
   goto fail;

[Mesa-dev] [PATCH 1/3] util/disk_cache: hash timestamps into the cache keys

2017-03-20 Thread Timothy Arceri

From: Grazvydas Ignotas 

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

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

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

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100091
Signed-off-by: Grazvydas Ignotas 
---
 src/compiler/glsl/tests/cache_test.c | 10 +++---
 src/util/disk_cache.c| 70 ++--
 2 files changed, 24 insertions(+), 56 deletions(-)

diff --git a/src/compiler/glsl/tests/cache_test.c 
b/src/compiler/glsl/tests/cache_test.c
index b1b3c33..b604943 100644
--- a/src/compiler/glsl/tests/cache_test.c
+++ b/src/compiler/glsl/tests/cache_test.c
@@ -121,21 +121,21 @@ remove_entry(const char *path,
 static int
 rmrf_local(const char *path)
 {
if (path == NULL || *path == '\0' || *path != '.')
   return -1;
 
return nftw(path, remove_entry, 64, FTW_DEPTH | FTW_PHYS | FTW_MOUNT);
 }
 
 static void
-check_timestamp_and_gpu_id_directories_created(char *cache_dir)
+check_directories_created(char *cache_dir)
 {
bool sub_dirs_created = false;
 
char buf[PATH_MAX];
if (getcwd(buf, PATH_MAX)) {
   char *full_path = NULL;
   if (asprintf(_path, "%s%s", buf, ++cache_dir) != -1 ) {
  struct stat sb;
  if (stat(full_path, ) != -1 && S_ISDIR(sb.st_mode))
 sub_dirs_created = true;
@@ -177,48 +177,48 @@ 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");
expect_null(cache, "disk_cache_create with XDG_CACHE_HOME set with"
"a non-existing parent directory");
 
/* Create string with expected directory hierarchy */
char expected_dir_h[255];
sprintf(expected_dir_h, "%s%s%s", CACHE_TEST_TMP "/xdg-cache-home/mesa/",
-   get_arch_bitness_str(), "/make_check/test");
+   get_arch_bitness_str(), "/test");
 
mkdir(CACHE_TEST_TMP, 0755);
cache = disk_cache_create("test", "make_check");
expect_non_null(cache, "disk_cache_create with XDG_CACHE_HOME set");
 
-   check_timestamp_and_gpu_id_directories_created(expected_dir_h);
+   check_directories_created(expected_dir_h);
 
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");
expect_null(cache, "disk_cache_create with MESA_GLSL_CACHE_DIR set with"
"a non-existing parent directory");
 
sprintf(expected_dir_h, "%s%s%s", CACHE_TEST_TMP
"/mesa-glsl-cache-dir/mesa/", get_arch_bitness_str(),
-   "/make_check/test");
+   "/test");
 
mkdir(CACHE_TEST_TMP, 0755);
cache = disk_cache_create("test", "make_check");
expect_non_null(cache, "disk_cache_create with MESA_GLSL_CACHE_DIR set");
 
-   check_timestamp_and_gpu_id_directories_created(expected_dir_h);
+   check_directories_created(expected_dir_h);
 
disk_cache_destroy(cache);
 }
 
 static bool
 does_cache_contain(struct disk_cache *cache, 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 dd3cadb..eb17206 100644
--- a/src/util/disk_cache.c
+++ b/src/util/disk_cache.c
@@ -71,20 +71,24 @@ struct disk_cache {
size_t index_mmap_size;
 
/* Pointer to total size of all objects in cache (within index_mmap) */
uint64_t *size;
 
/* Pointer to stored keys, (within index_mmap). */
uint8_t *stored_keys;
 
/* Maximum size of all cached objects (in bytes). */
uint64_t max_size;
+
+   /* Driver cache keys. */
+   char *timestamp;
+   size_t timestamp_size;
 };
 
 struct disk_cache_put_job {
struct util_queue_fence fence;
 
struct disk_cache *cache;
 
cache_key key;
 
/* Copy of cache data to be compressed and written. */
@@ -147,80 +151,36 @@ concatenate_and_mkdir(void *ctx, const char *path, const 
char *name)
   return NULL;
 
new_path = ralloc_asprintf(ctx, "%s/%s", path, name);
 
if (mkdir_if_needed(new_path) == 0)
   return new_path;
else
   return NULL;
 }
 
-static int
-remove_dir(const char *fpath, const struct stat *sb,
-   int typeflag, struct FTW *ftwbuf)
-{
-   if

[Mesa-dev] [PATCH 2/3] util/disk_cache: hash pointer size and gpu name into cache keys

2017-03-20 Thread Timothy Arceri

From: Grazvydas Ignotas 

This allows to get rid of the arch and gpu name directories.

v2: (Timothy Arceri) don't use an opaque data type to store
pointer size and gpu name.

Signed-off-by: Grazvydas Ignotas 
---
 src/compiler/glsl/tests/cache_test.c | 13 ++-
 src/util/disk_cache.c| 44 +++-
 src/util/disk_cache.h| 17 --
 3 files changed, 20 insertions(+), 54 deletions(-)

diff --git a/src/compiler/glsl/tests/cache_test.c 
b/src/compiler/glsl/tests/cache_test.c
index b604943..2302f44 100644
--- a/src/compiler/glsl/tests/cache_test.c
+++ b/src/compiler/glsl/tests/cache_test.c
@@ -174,51 +174,42 @@ test_disk_cache_create(void)
expect_non_null(cache, "disk_cache_create with no environment variables");
 
disk_cache_destroy(cache);
 
/* Test with XDG_CACHE_HOME set */
setenv("XDG_CACHE_HOME", CACHE_TEST_TMP "/xdg-cache-home", 1);
cache = disk_cache_create("test", "make_check");
expect_null(cache, "disk_cache_create with XDG_CACHE_HOME set with"
"a non-existing parent directory");
 
-   /* Create string with expected directory hierarchy */
-   char expected_dir_h[255];
-   sprintf(expected_dir_h, "%s%s%s", CACHE_TEST_TMP "/xdg-cache-home/mesa/",
-   get_arch_bitness_str(), "/test");
-
mkdir(CACHE_TEST_TMP, 0755);
cache = disk_cache_create("test", "make_check");
expect_non_null(cache, "disk_cache_create with XDG_CACHE_HOME set");
 
-   check_directories_created(expected_dir_h);
+   check_directories_created(CACHE_TEST_TMP "/xdg-cache-home/mesa");
 
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");
expect_null(cache, "disk_cache_create with MESA_GLSL_CACHE_DIR set with"
"a non-existing parent directory");
 
-   sprintf(expected_dir_h, "%s%s%s", CACHE_TEST_TMP
-   "/mesa-glsl-cache-dir/mesa/", get_arch_bitness_str(),
-   "/test");
-
mkdir(CACHE_TEST_TMP, 0755);
cache = disk_cache_create("test", "make_check");
expect_non_null(cache, "disk_cache_create with MESA_GLSL_CACHE_DIR set");
 
-   check_directories_created(expected_dir_h);
+   check_directories_created(CACHE_TEST_TMP "/mesa-glsl-cache-dir/mesa");
 
disk_cache_destroy(cache);
 }
 
 static bool
 does_cache_contain(struct disk_cache *cache, 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 eb17206..599e58f 100644
--- a/src/util/disk_cache.c
+++ b/src/util/disk_cache.c
@@ -75,20 +75,23 @@ struct disk_cache {
 
/* Pointer to stored keys, (within index_mmap). */
uint8_t *stored_keys;
 
/* Maximum size of all cached objects (in bytes). */
uint64_t max_size;
 
/* Driver cache keys. */
char *timestamp;
size_t timestamp_size;
+   char *gpu_name;
+   size_t gpu_name_size;
+   uint8_t ptr_size;
 };
 
 struct disk_cache_put_job {
struct util_queue_fence fence;
 
struct disk_cache *cache;
 
cache_key key;
 
/* Copy of cache data to be compressed and written. */
@@ -151,43 +154,20 @@ concatenate_and_mkdir(void *ctx, const char *path, const 
char *name)
   return NULL;
 
new_path = ralloc_asprintf(ctx, "%s/%s", path, name);
 
if (mkdir_if_needed(new_path) == 0)
   return new_path;
else
   return NULL;
 }
 
-static char *
-create_mesa_cache_dir(void *mem_ctx, const char *path, const char *gpu_name)
-{
-   char *new_path = concatenate_and_mkdir(mem_ctx, path, "mesa");
-   if (new_path == NULL)
-  return NULL;
-
-   /* Create a parent architecture directory so that we don't remove cache
-* files for other architectures. In theory we could share the cache
-* between architectures but we have no way of knowing if they were created
-* by a compatible Mesa version.
-*/
-   new_path = concatenate_and_mkdir(mem_ctx, new_path, get_arch_bitness_str());
-   if (new_path == NULL)
-  return NULL;
-
-   new_path = concatenate_and_mkdir(mem_ctx, new_path, gpu_name);
-   if (new_path == NULL)
-  return NULL;
-
-   return new_path;
-}
-
 struct disk_cache *
 disk_cache_create(const char *gpu_name, const char *timestamp)
 {
void *local;
struct disk_cache *cache = NULL;
char *path, *max_size_str;
uint64_t max_size;
int fd = -1;
struct stat sb;
struct statvfs vfs = { 0 };
@@ -210,33 +190,33 @@ disk_cache_create(const char *gpu_name, const char 
*timestamp)
 *
 *   $MESA_GLSL_CACHE_DIR
 *   $XDG_CACHE_HOME/mesa
 *   /.cache/mesa
 */
path = getenv("MESA_GLSL_CACHE_DIR");
if (path) {
   if (mkdir_if_needed(path) == -1)
  goto fail;
 
-  path =

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

2017-03-20 Thread Jonathan Gray

On Mon, Mar 20, 2017 at 11:30:25AM -0700, Matt Turner wrote:
> On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov  
> wrote:
> > Seems like we ended up all over the place, so let me try afresh.
> >
> > Above all:
> >  - Saying "I don't care" about your users is arrogant - let us _not_
> > do that, please ?
> 
> Let's be honest, the OpenBSD is subjecting itself to some pretty
> arbitrary restrictions caused including Mesa in its core: 10+ year old
> GCC, non-GNU Make, and now no Meson. I don't believe either FreeBSD or
> NetBSD keep Mesa as part of the core operating system, and as such
> don't suffer from these problems.
> 
> For better or worse, they have made their choices and they get to live
> with them. We are not beholden to them.

This isn't a situation like OpenSSH where people explicitly go out of
their way to provide support for and test multiple systems and add
support for horrible things like PAM.  It is more along the lines of
considering integrating patches sent by others to make code build.

> 
> > Even Linux distribution maintainers have responded that "upstream does
> > not care us", which is indicative that we should be more careful what
> > we say.
> 
> Citation needed.
> 
> > For the rest - we're dealing with two orthogonal issues here:
> >
> > * Multiple build systems
> > I believe we'll all agree that I might be the person who's been in all
> > the build systems the most.
> > Yes I _would_ _love_ to drop it all but we simply _cannot_ do that yet:
> 
> No one is advocating dropping all of the existing build systems yet.
> 
> This patch is an RFC for a smaller project to start the discussion about Mesa.
> 
> >  - [currently] there is no viable solution for Android
> 
> Acknowledged. Dylan is going to see if this is something that can be
> solved in upstream Meson.
> 
> >  - dropping the Autotools will lead to OpenBSD and NetBSD having to
> > write one from scratch, IIRC Solaris/FreeBSD and others are in similar
> > boat.
> 
> Solaris is a closed source operating system whose developers do not
> contribute to the project. We do not need to base our decisions on
> them.

So Mesa will remove support for libglvnd then?  I don't see a lot of
open source non-Mesa alternatives for libGL.

Oh and the mingw, windows and macos support can go as well, great!
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

2017-03-20 Thread Jonathan Gray

On Tue, Mar 21, 2017 at 08:28:22AM +1100, Timothy Arceri wrote:
> 
> 
> On 21/03/17 06:39, Emil Velikov wrote:
> > On 20 March 2017 at 18:30, Matt Turner  wrote:
> > > On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov  
> > > wrote:
> > > > Seems like we ended up all over the place, so let me try afresh.
> > > > 
> > > > Above all:
> > > >  - Saying "I don't care" about your users is arrogant - let us _not_
> > > > do that, please ?
> > > 
> > > Let's be honest, the OpenBSD is subjecting itself to some pretty
> > > arbitrary restrictions caused including Mesa in its core: 10+ year old
> > > GCC,
> > IIRC Brian was using old MinGW GCC, which was one of the blockers - it
> > wasn't OpenBSD to blame here ;-)
> 
> Sorry Emil I probably wasn't clear in our discussion. I sent out patches to
> switch to GCC 4.8 last Sept (I believe this was needed by RHEL6) [1].
> 
> Brain jumped in and said "I'm still using the MinGW gcc 4.6 compiler. I'd
> rather not go through the upgrade hassle if I don't have to."
> 
> Followed by Jose "We're internally building and shipping Mesa compiled with
> GCC 4.4 (more specifically 4.4.3).
> 
> It's fine if you require GCC 4.8 on automake, but please leave support
> for GCC 4.4.x in SCons."
> 
> By this point I got bored and moved on. But OpenBSDs GCC is a fork with
> various features backported, from what I understand Mesa would not build on
> a real GCC 4.2 release and we should not be using it as a min version. IMO
> if OpenBSD want to maintain a GCC fork they can handle a patch to downgrade
> the min GCC version.
> 
> I believe Jonathan would like us to stick with 4.2 as min but is prepared to
> deal with it if we move on.

I would like to see Mesa test features it uses in configure rather than
arbitary versions that are what a certain linux distribution ships with.
The zlib change for instance didn't reference any specific problems with
older versions or interfaces required from newer versions.

We have one platform using clang/lld now (arm64) and are likely to move
others in future where possible.  libtool has to be patched and the Mesa
configure script regenerated to make this work or Mesa won't build due
to libtool.m4 looking for specific strings in ld -v produced by bfd
binutils or gold...

And yes if you change the configure script to check for a newer version
I'll revert it locally like I did with the zlib one.

As I get the impression no one cares about patches for older GCC I've
not being sending them to the list, ie

commit d3d340d6026e516cc405a2eb1d925a7a7a467480
Author: Jonathan Gray 
Date:   Thu Mar 16 00:30:07 2017 +1100

i965: don't use designated array initialisation

Don't use a form of designated array initialisation that breaks gcc 4.2.1.

compiler/brw_vec4_gs_visitor.cpp:589: error: expected primary-expression 
before '[' token
compiler/brw_vec4_gs_visitor.cpp:590: error: expected primary-expression 
before '[' token
compiler/brw_vec4_gs_visitor.cpp:591: error: expected primary-expression 
before '[' token
compiler/brw_vec4_gs_visitor.cpp:592: error: expected primary-expression 
before '[' token
compiler/brw_vec4_gs_visitor.cpp:593: error: expected primary-expression 
before '[' token
compiler/brw_vec4_gs_visitor.cpp:594: error: expected primary-expression 
before '[' token
compiler/brw_vec4_gs_visitor.cpp:595: error: expected primary-expression 
before '[' token
compiler/brw_vec4_gs_visitor.cpp:596: error: expected primary-expression 
before '[' token
compiler/brw_vec4_gs_visitor.cpp:597: error: expected primary-expression 
before '[' token
compiler/brw_vec4_gs_visitor.cpp:598: error: expected primary-expression 
before '[' token
compiler/brw_vec4_gs_visitor.cpp:599: error: expected primary-expression 
before '[' token
compiler/brw_vec4_gs_visitor.cpp:600: error: expected primary-expression 
before '[' token
compiler/brw_vec4_gs_visitor.cpp:601: error: expected primary-expression 
before '[' token
compiler/brw_vec4_gs_visitor.cpp:602: error: expected primary-expression 
before '[' token

Signed-off-by: Jonathan Gray 

diff --git a/src/intel/compiler/brw_vec4_gs_visitor.cpp 
b/src/intel/compiler/brw_vec4_gs_visitor.cpp
index 4a8b5be30e..e7a502306e 100644
--- a/src/intel/compiler/brw_vec4_gs_visitor.cpp
+++ b/src/intel/compiler/brw_vec4_gs_visitor.cpp
@@ -585,23 +585,6 @@ vec4_gs_visitor::gs_end_primitive()
emit(OR(dst_reg(this->control_data_bits), this->control_data_bits, mask));
 }
 
-static const GLuint gl_prim_to_hw_prim[GL_TRIANGLE_STRIP_ADJACENCY+1] = {
-   [GL_POINTS] =_3DPRIM_POINTLIST,
-   [GL_LINES] = _3DPRIM_LINELIST,
-   [GL_LINE_LOOP] = _3DPRIM_LINELOOP,
-   [GL_LINE_STRIP] = _3DPRIM_LINESTRIP,
-   [GL_TRIANGLES] = _3DPRIM_TRILIST,
-   [GL_TRIANGLE_STRIP] = _3DPRIM_TRISTRIP,
-   [GL_TRIANGLE_FAN] = _3DPRIM_TRIFAN,
-   [GL_QUADS] = _3DPRIM_QUADLIST,
-   [GL_QUAD_STRIP] = _3DPRIM_QUADSTRIP,
-

Re: [Mesa-dev] [PATCH] i965: Shut up major()/minor() warnings.

2017-03-20 Thread Jonathan Gray

On Mon, Mar 20, 2017 at 04:05:04PM -0700, Kenneth Graunke wrote:
> Recent glibc generates this warning:
> 
> brw_performance_query.c:1648:13: warning: In the GNU C Library, "minor" is 
> defined
>  by . For historical compatibility, it is
>  currently defined by  as well, but we plan to
>  remove this soon. To use "minor", include 
>  directly. If you did not intend to use a system-defined macro
>  "minor", you should undefine it after including .
> 
> min = minor(sb.st_rdev);
> 
> So, include sys/sysmacros.h to shut up the warning.

This header is only present on glibc so it should be gated by an ifdef
or it will break all other systems.

minor()/major() are documented as needing sys/types.h and there is no
sys/sysmacro.h on OpenBSD for instance.

> ---
>  src/mesa/drivers/dri/i965/brw_performance_query.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_performance_query.c 
> b/src/mesa/drivers/dri/i965/brw_performance_query.c
> index 2e04e091d29..17e0d6f0cdf 100644
> --- a/src/mesa/drivers/dri/i965/brw_performance_query.c
> +++ b/src/mesa/drivers/dri/i965/brw_performance_query.c
> @@ -42,6 +42,7 @@
>  #include 
>  #include 
>  
> +#include 
>  #include 
>  #include 
>  #include 
> -- 
> 2.12.0
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 5/6] [v2] i965: Handle X-tiled modifier

2017-03-20 Thread Ben Widawsky

This doesn't really "do" anything because the default tiling for the
winsys buffer is X tiled. We do however want the X tiled modifier to
work correctly from the API perspective, which would imply that if you
set this modifier, and later do a get_modifier, you get back at least X
tiled.

Cc: Kristian Høgsberg 
Signed-off-by: Ben Widawsky 
Acked-by: Daniel Stone 
---
 src/mesa/drivers/dri/i965/intel_screen.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index e4f858ed33..9d458c707a 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -519,12 +519,14 @@ intel_destroy_image(__DRIimage *image)
 enum modifier_priority {
MODIFIER_PRIORITY_INVALID = 0,
MODIFIER_PRIORITY_LINEAR,
+   MODIFIER_PRIORITY_X,
MODIFIER_PRIORITY_Y,
 };
 
 const uint64_t priority_to_modifier[] = {
[MODIFIER_PRIORITY_INVALID] = DRM_FORMAT_MOD_INVALID,
[MODIFIER_PRIORITY_LINEAR] = DRM_FORMAT_MOD_LINEAR,
+   [MODIFIER_PRIORITY_X] = I915_FORMAT_MOD_X_TILED,
[MODIFIER_PRIORITY_Y] = I915_FORMAT_MOD_Y_TILED,
 };
 
@@ -540,6 +542,9 @@ select_best_modifier(struct gen_device_info *devinfo,
   case I915_FORMAT_MOD_Y_TILED:
  prio = MAX2(prio, MODIFIER_PRIORITY_Y);
  break;
+  case I915_FORMAT_MOD_X_TILED:
+ prio = MAX2(prio, MODIFIER_PRIORITY_X);
+ break;
   case DRM_FORMAT_MOD_LINEAR:
  prio = MAX2(prio, MODIFIER_PRIORITY_LINEAR);
  break;
@@ -577,6 +582,9 @@ intel_create_image_common(__DRIscreen *dri_screen,
 
uint64_t modifier = select_best_modifier(>devinfo, modifiers, 
count);
switch (modifier) {
+   case I915_FORMAT_MOD_X_TILED:
+  assert(tiling == I915_TILING_X);
+  break;
case DRM_FORMAT_MOD_LINEAR:
   tiling = I915_TILING_NONE;
   break;
@@ -641,6 +649,7 @@ intel_create_image_with_modifiers(__DRIscreen *dri_screen,
for (int i = 0; i < count; i++) {
   switch (modifiers[i]) {
   case I915_FORMAT_MOD_Y_TILED:
+  case I915_FORMAT_MOD_X_TILED:
   case DRM_FORMAT_MOD_LINEAR:
  local_mods[local_count++] = modifiers[i];
  break;
-- 
2.12.0

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

[Mesa-dev] [PATCH 4/6] [v2] i965: Handle Y-tiled modifier

2017-03-20 Thread Ben Widawsky

This patch begins introducing how we'll actually handle the potentially
many modifiers coming in from the API, how we'll store them, and the
structure in the code to support it.

Prior to this patch, the Y-tiled modifier would be entirely ignored. It
shouldn't actually be used until this point because we've not bumped the
DRIimage extension version (which is a requirement to use modifiers).

Measuring later in the series with kmscbe:
Linear:
Read bandwidth: 1048.44 MiB/s
Write bandwidth: 1483.17 MiB/s

Y-tiled:
Read bandwidth: 471.13 MiB/s
Write bandwidth: 589.10 MiB/s

Similar functionality was introduced and then reverted here:

commit 6a0d036483caf87d43ebe2edd1905873446c9589
Author: Ben Widawsky 
Date:   Thu Apr 21 20:14:58 2016 -0700

i965: Always use Y-tiled buffers on SKL+

v2: Use last set bit instead of first set bit in modifiers to address
bug found by Daniel Stone.

v3: Use the new priority modifier selection thing. This nullifies the
bug fixed by v2 also.

Signed-off-by: Ben Widawsky 
Reviewed-by: Eric Engestrom 
Acked-by: Daniel Stone 
---
 src/gbm/backends/dri/gbm_dri.c   | 18 
 src/mesa/drivers/dri/i965/intel_screen.c | 36 
 2 files changed, 50 insertions(+), 4 deletions(-)

diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
index a7ac149365..a78ea89fca 100644
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/dri/gbm_dri.c
@@ -1143,6 +1143,15 @@ gbm_dri_bo_create(struct gbm_device *gbm,
  goto failed;
   }
 
+  if (modifiers) {
+ for (int i = 0; i < count; i++)
+if (modifiers[i] == DRM_FORMAT_MOD_INVALID) {
+   fprintf(stderr, "Invalid modifier passed in 
DRM_FORMAT_MOD_INVALID");
+   errno = EINVAL;
+   goto failed;
+}
+  }
+
   bo->image =
  dri->image->createImageWithModifiers(dri->screen,
   width, height,
@@ -1240,6 +1249,15 @@ gbm_dri_surface_create(struct gbm_device *gbm,
   return NULL;
}
 
+   if (modifiers) {
+  for (int i = 0; i < count; i++)
+ if (modifiers[i] == DRM_FORMAT_MOD_INVALID) {
+fprintf(stderr, "Invalid modifier passed in 
DRM_FORMAT_MOD_INVALID");
+errno = EINVAL;
+return NULL;
+ }
+   }
+
surf = calloc(1, sizeof *surf);
if (surf == NULL) {
   errno = ENOMEM;
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index 14e60ef1a1..e4f858ed33 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -23,6 +23,7 @@
  * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -518,11 +519,13 @@ intel_destroy_image(__DRIimage *image)
 enum modifier_priority {
MODIFIER_PRIORITY_INVALID = 0,
MODIFIER_PRIORITY_LINEAR,
+   MODIFIER_PRIORITY_Y,
 };
 
 const uint64_t priority_to_modifier[] = {
[MODIFIER_PRIORITY_INVALID] = DRM_FORMAT_MOD_INVALID,
[MODIFIER_PRIORITY_LINEAR] = DRM_FORMAT_MOD_LINEAR,
+   [MODIFIER_PRIORITY_Y] = I915_FORMAT_MOD_Y_TILED,
 };
 
 static uint64_t
@@ -530,11 +533,13 @@ select_best_modifier(struct gen_device_info *devinfo,
  const uint64_t *modifiers,
  const unsigned count)
 {
-
enum modifier_priority prio = MODIFIER_PRIORITY_INVALID;
 
for (int i = 0; i < count; i++) {
   switch (modifiers[i]) {
+  case I915_FORMAT_MOD_Y_TILED:
+ prio = MAX2(prio, MODIFIER_PRIORITY_Y);
+ break;
   case DRM_FORMAT_MOD_LINEAR:
  prio = MAX2(prio, MODIFIER_PRIORITY_LINEAR);
  break;
@@ -575,6 +580,9 @@ intel_create_image_common(__DRIscreen *dri_screen,
case DRM_FORMAT_MOD_LINEAR:
   tiling = I915_TILING_NONE;
   break;
+   case I915_FORMAT_MOD_Y_TILED:
+  tiling = I915_TILING_Y;
+  break;
case DRM_FORMAT_MOD_INVALID:
default:
  break;
@@ -626,8 +634,26 @@ intel_create_image_with_modifiers(__DRIscreen *dri_screen,
   const unsigned count,
   void *loaderPrivate)
 {
-   return intel_create_image_common(dri_screen, width, height, format, 0, NULL,
-0, loaderPrivate);
+   uint64_t local_mods[count];
+   int local_count = 0;
+
+   /* This compacts the actual modifiers to the ones we know how to handle */
+   for (int i = 0; i < count; i++) {
+  switch (modifiers[i]) {
+  case I915_FORMAT_MOD_Y_TILED:
+  case DRM_FORMAT_MOD_LINEAR:
+ local_mods[local_count++] = modifiers[i];
+ break;
+  case DRM_FORMAT_MOD_INVALID:
+ unreachable("Invalid modifiers specified\n");
+  default:
+ /* Modifiers from other vendors would land here. */
+ break;

[Mesa-dev] [PATCH 3/6] [v2] i965: Handle the linear fb modifier

2017-03-20 Thread Ben Widawsky

At image creation create a path for dealing with the linear modifier.
This works exactly like the old usage flags where __DRI_IMAGE_USE_LINEAR
was specified.

During development of this patch series, it was decided that a lack of
modifier was an insufficient way to express the required modifiers. As a
result, 0 was repurposed to mean a modifier for a LINEAR layout.

NOTE: This patch was added for v3 of the patch series.

v2: Rework the algorithm for modifier selection to go from a bitmask
based selection to this priority value.

Requested-by: Jason Ekstrand 
Signed-off-by: Ben Widawsky 
---
 src/mesa/drivers/dri/i965/intel_screen.c | 50 +++-
 1 file changed, 42 insertions(+), 8 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index 2455649032..14e60ef1a1 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -45,6 +45,10 @@
 #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 =
@@ -511,13 +515,36 @@ intel_destroy_image(__DRIimage *image)
free(image);
 }
 
+enum modifier_priority {
+   MODIFIER_PRIORITY_INVALID = 0,
+   MODIFIER_PRIORITY_LINEAR,
+};
+
+const uint64_t priority_to_modifier[] = {
+   [MODIFIER_PRIORITY_INVALID] = DRM_FORMAT_MOD_INVALID,
+   [MODIFIER_PRIORITY_LINEAR] = DRM_FORMAT_MOD_LINEAR,
+};
+
 static uint64_t
 select_best_modifier(struct gen_device_info *devinfo,
  const uint64_t *modifiers,
  const unsigned count)
 {
-   /* Modifiers are not supported by this DRI driver */
-   return DRM_FORMAT_MOD_INVALID;
+
+   enum modifier_priority prio = MODIFIER_PRIORITY_INVALID;
+
+   for (int i = 0; i < count; i++) {
+  switch (modifiers[i]) {
+  case DRM_FORMAT_MOD_LINEAR:
+ prio = MAX2(prio, MODIFIER_PRIORITY_LINEAR);
+ break;
+  case DRM_FORMAT_MOD_INVALID:
+  default:
+ unreachable("Invalid modifiers specified\n");
+  }
+   }
+
+   return priority_to_modifier[prio];
 }
 
 static __DRIimage *
@@ -530,7 +557,10 @@ intel_create_image_common(__DRIscreen *dri_screen,
 {
__DRIimage *image;
struct intel_screen *screen = dri_screen->driverPrivate;
-   uint32_t tiling;
+   /* Historically, X-tiled was the default, and so lack of modifier means
+* X-tiled.
+*/
+   uint32_t tiling = I915_TILING_X;
int cpp;
unsigned long pitch;
 
@@ -541,12 +571,15 @@ intel_create_image_common(__DRIscreen *dri_screen,
assert(!(use && count));
 
uint64_t modifier = select_best_modifier(>devinfo, modifiers, 
count);
-   assert(modifier == DRM_FORMAT_MOD_INVALID);
+   switch (modifier) {
+   case DRM_FORMAT_MOD_LINEAR:
+  tiling = I915_TILING_NONE;
+  break;
+   case DRM_FORMAT_MOD_INVALID:
+   default:
+ break;
+   }
 
-   /* Historically, X-tiled was the default, and so lack of modifier means
-* X-tiled.
-*/
-   tiling = I915_TILING_X;
if (use & __DRI_IMAGE_USE_CURSOR) {
   if (width != 64 || height != 64)
 return NULL;
@@ -571,6 +604,7 @@ intel_create_image_common(__DRIscreen *dri_screen,
image->width = width;
image->height = height;
image->pitch = pitch;
+   image->modifier = modifier;
 
return image;
 }
-- 
2.12.0

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

[Mesa-dev] [PATCH 2/6] [v2] i965: Enable modifier queries

2017-03-20 Thread Ben Widawsky

New to the patch series after reordering things for landing smaller
chunks.

This will essentially enable modifiers from clients that were just
enabled in previous patches. A client could use the modifiers by
setting all of them at create, but had no way to actually query them
after creating the surface (ie. stupid clients could be broken before
this patch, but in more ways than this).

Obviously, there are no modifiers being actually stored yet - so this
patch shouldn't do anything other than allow the API to get back 0 (or
the LINEAR modifier).

Signed-off-by: Ben Widawsky 
---
 src/mesa/drivers/dri/i965/intel_image.h  | 1 +
 src/mesa/drivers/dri/i965/intel_screen.c | 6 ++
 2 files changed, 7 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/intel_image.h 
b/src/mesa/drivers/dri/i965/intel_image.h
index fd63919b2d..a362c76689 100644
--- a/src/mesa/drivers/dri/i965/intel_image.h
+++ b/src/mesa/drivers/dri/i965/intel_image.h
@@ -71,6 +71,7 @@ struct __DRIimageRec {
GLenum internal_format;
uint32_t dri_format;
GLuint format;
+   uint64_t modifier; /**< fb modifier (fourcc) */
uint32_t offset;
 
/*
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index 1525b4c560..2455649032 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -632,6 +632,12 @@ intel_query_image(__DRIimage *image, int attrib, int 
*value)
case __DRI_IMAGE_ATTRIB_OFFSET:
   *value = image->offset;
   return true;
+   case __DRI_IMAGE_ATTRIB_MODIFIER_LOWER:
+  *value = (image->modifier & 0x);
+  return true;
+   case __DRI_IMAGE_ATTRIB_MODIFIER_UPPER:
+  *value = ((image->modifier >> 32) & 0x);
+  return true;
 
   default:
   return false;
-- 
2.12.0

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

[Mesa-dev] [PATCH 2/6] [v2] i965: Enable modifier queries

2017-03-20 Thread Ben Widawsky

New to the patch series after reordering things for landing smaller
chunks.

This will essentially enable modifiers from clients that were just
enabled in previous patches. A client could use the modifiers by
setting all of them at create, but had no way to actually query them
after creating the surface (ie. stupid clients could be broken before
this patch, but in more ways than this).

Obviously, there are no modifiers being actually stored yet - so this
patch shouldn't do anything other than allow the API to get back 0 (or
the LINEAR modifier).

Signed-off-by: Ben Widawsky 
---
 src/mesa/drivers/dri/i965/intel_image.h  | 1 +
 src/mesa/drivers/dri/i965/intel_screen.c | 6 ++
 2 files changed, 7 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/intel_image.h 
b/src/mesa/drivers/dri/i965/intel_image.h
index fd63919b2d..a362c76689 100644
--- a/src/mesa/drivers/dri/i965/intel_image.h
+++ b/src/mesa/drivers/dri/i965/intel_image.h
@@ -71,6 +71,7 @@ struct __DRIimageRec {
GLenum internal_format;
uint32_t dri_format;
GLuint format;
+   uint64_t modifier; /**< fb modifier (fourcc) */
uint32_t offset;
 
/*
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index 1525b4c560..2455649032 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -632,6 +632,12 @@ intel_query_image(__DRIimage *image, int attrib, int 
*value)
case __DRI_IMAGE_ATTRIB_OFFSET:
   *value = image->offset;
   return true;
+   case __DRI_IMAGE_ATTRIB_MODIFIER_LOWER:
+  *value = (image->modifier & 0x);
+  return true;
+   case __DRI_IMAGE_ATTRIB_MODIFIER_UPPER:
+  *value = ((image->modifier >> 32) & 0x);
+  return true;
 
   default:
   return false;
-- 
2.12.0

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

Re: [Mesa-dev] [PATCH v2] configure.ac: Use POSIX word boundary regex.

2017-03-20 Thread Michel Dänzer

On 20/03/17 12:19 AM, Eric Engestrom wrote:
> On Sunday, 2017-03-19 13:44:30 +, Jan Beich wrote:
>> Vinson Lee  writes:
>>
>>> --e 's/[[[:space:]]]+-DNDEBUG\>//g' \
>>> --e 's/[[[:space:]]]+-D_GNU_SOURCE\>//g' \
>>> --e 's/[[[:space:]]]+-pedantic\>//g' \
>>> +-e 's/[[[:space:]]]+-DNDEBUG[[[:space:]]]//g' \
>>> +-e 's/[[[:space:]]]+-D_GNU_SOURCE[[[:space:]]]//g' \
>>> +-e 's/[[[:space:]]]+-pedantic[[[:space:]]]//g' \
>>
>> If you always expect whitespace on both sides but trim it the RE
>> may not match with more than one occurence in sequence e.g.,
>>
>>  $ echo ' -D_GNU_SOURCE -DNDEBUG ' |
>>sed -E -e 's/[[:space:]]+-DNDEBUG[[:space:]]//g' \
>>   -e 's/[[:space:]]+-D_GNU_SOURCE[[:space:]]//g'
>>-D_GNU_SOURCE
>>
>> vs. (restore some whitespace)
>>
>>   $ echo ' -D_GNU_SOURCE -DNDEBUG ' |
>> sed -E -e 's/[[:space:]]+-DNDEBUG[[:space:]]/ /g' \
>>-e 's/[[:space:]]+-D_GNU_SOURCE[[:space:]]/ /g'
>>
> 
> Oh yes, very good point there!
> My r-b now stands with this fix applied :)
> 
> This will lead to a bunch of unnecessary whitespace in the middle, but
> I'm not sure I'd recommend addressing this:
> A simple 's/[[[:space:]]]+/ /g' at the end should trivially fix this,
> [...]

Another option would be to match the trailing whitespace as a
subexpression and add that back on the right hand side.


-- 
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] configure.ac: Use POSIX word boundary regex.

2017-03-20 Thread Michel Dänzer


In addition to other comments, the Git shortlog no longer matches the
patch itself.


-- 
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] i965: Select pipeline and emit state base address in Gen8+ HiZ ops.

2017-03-20 Thread Nanley Chery

On Mon, Mar 20, 2017 at 08:01:25PM -0700, Nanley Chery wrote:
> On Thu, Mar 16, 2017 at 05:34:13PM -0700, Kenneth Graunke wrote:
> > On Wednesday, March 8, 2017 10:27:20 AM PDT Nanley Chery wrote:
> > > On Wed, Mar 08, 2017 at 10:07:12AM -0800, Nanley Chery wrote:
> > > > On Wed, Mar 08, 2017 at 02:17:59AM -0800, Kenneth Graunke wrote:
> > > > > On Thursday, March 2, 2017 4:36:08 PM PST Nanley Chery wrote:
> > > > > > On Mon, Feb 06, 2017 at 03:55:49PM -0800, Kenneth Graunke wrote:
> > > > > > > If a HiZ op is the first thing in the batch, we should make sure
> > > > > > > to select the render pipeline and emit state base address before
> > > > > > > proceeding.
> > > > > > > 
> > > > > > > I believe 3DSTATE_WM_HZ_OP creates 3DPRIMITIVEs internally, and
> > > > > > > dispatching those on the GPGPU pipeline seems a bit sketchy.  I'm
> > > > > > 
> > > > > > Yes, it does seem like we currently allow HZ_OPs within a GPGPU
> > > > > > pipeline. This patch should fix that problem.
> > > > > > 
> > > > > > > not actually sure that STATE_BASE_ADDRESS is necessary, as the
> > > > > > > depth related commands use graphics addresses, not ones relative
> > > > > > > to the base address...but we're likely to set it as part of the
> > > > > > > next operation anyway, so we should just do it right away.
> > > > > > > 
> 
> Why should we do it right away if it will happen later on? I don't see
> why this part of the patch is necessary.
> 
> > > > > > 
> > > > > > I agree, re-emitting STATE_BASE_ADDRESS doesn't seem necessary. I 
> > > > > > think
> > > > > > we should drop this part of the patch and add it back in later if 
> > > > > > we get
> > > > > > some data that it's necessary. Leaving it there may be distracting 
> > > > > > to
> > > > > > some readers and the BDW PRM warns that it's an expensive command:
> > > > > > 
> > > > > > Execution of this command causes a full pipeline flush, thus its
> > > > > > use should be minimized for higher performance.
> > > > > 
> > > > > I think it should be basically free, actually.  We track a boolean,
> > > > > brw->batch.state_base_address_emitted, to avoid emitting it multiple
> > > > > times per batch.
> > > > > 
> > > > > Let's say the first thing in a fresh batch is a HiZ op, followed by
> > > > > normal drawing.  Previously, we'd do:
> > > > > 
> > > > > 1. HiZ op commands
> > > > > 2. STATE_BASE_ADDRESS (triggered by normal rendering upload)
> > > > > 3. rest of normal drawing commands
> > > > > 
> > > > > Now we'd do:
> > > > > 
> > > > > 1. STATE_BASE_ADDRESS (triggered by HiZ op)
> > > > > 2. HiZ op commands
> > > > > 3. normal drawing commands (second SBA is skipped)
> > > > > 
> > > > > In other words...we're just moving it a bit earlier.  I suppose there
> > > > > could be a batch containing only HiZ ops, at which point we'd pay for
> > > > > a single STATE_BASE_ADDRESS...but that seems really unlikely.
> > > > > 
> > > > 
> > > > Sorry for not stating it up front, but the special case you've mentioned
> > > > is exactly what I'd like not to hurt unnecessarily.
> > > > 
> > 
> > Why?  We really think there are going to be batches with only
> > 3DSTATE_WM_HZ_OP and no normal rendering or BLORP?  It sounds
> > really hypothetical to me.
> > 
> 
> I've commented on the performance implications of that snippet because
> it is the only functional change I can see from emitting SBA. That
> unfortunately seems to have distracted us from the more important
> question found above. Sorry about that.
> 
> > > Correct me if I'm wrong, but after thinking about it some more, it seems
> > > that performance wouldn't suffer by emitting the SBA since the pipeline
> > > was already flushed at the end of the preceding batch. It may also
> > > improve since the pipelined HiZ op will likely be followed by other
> > > pipelined commands. I'm not totally confident in my understanding on
> > > pipeline flushes by the way. Is this why you'd like to emit the SBA here?
> > > I think it's fine to leave it if we expound on the rationale.
> > 
> > Performance is not a motivation for this patch.  Having the GPU do
> > work without a pipeline selected or state base addresses in place seems
> > potentially dangerous.  I was hoping it would help with GPU hangs.  I'm
> > not certain that it does, and it might be safe to skip this, but it
> > seems like a lot of mental gymnastics to prove that it's safe for very
> > little upside.
> > 
> 
> I was only referring to the portion of the patch that emits SBA.
> 

Sorry, I definitely did not read this thoroughly enough. Please ignore
my earlier reply.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965: Select pipeline and emit state base address in Gen8+ HiZ ops.

2017-03-20 Thread Nanley Chery

On Thu, Mar 16, 2017 at 05:34:13PM -0700, Kenneth Graunke wrote:
> On Wednesday, March 8, 2017 10:27:20 AM PDT Nanley Chery wrote:
> > On Wed, Mar 08, 2017 at 10:07:12AM -0800, Nanley Chery wrote:
> > > On Wed, Mar 08, 2017 at 02:17:59AM -0800, Kenneth Graunke wrote:
> > > > On Thursday, March 2, 2017 4:36:08 PM PST Nanley Chery wrote:
> > > > > On Mon, Feb 06, 2017 at 03:55:49PM -0800, Kenneth Graunke wrote:
> > > > > > If a HiZ op is the first thing in the batch, we should make sure
> > > > > > to select the render pipeline and emit state base address before
> > > > > > proceeding.
> > > > > > 
> > > > > > I believe 3DSTATE_WM_HZ_OP creates 3DPRIMITIVEs internally, and
> > > > > > dispatching those on the GPGPU pipeline seems a bit sketchy.  I'm
> > > > > 
> > > > > Yes, it does seem like we currently allow HZ_OPs within a GPGPU
> > > > > pipeline. This patch should fix that problem.
> > > > > 
> > > > > > not actually sure that STATE_BASE_ADDRESS is necessary, as the
> > > > > > depth related commands use graphics addresses, not ones relative
> > > > > > to the base address...but we're likely to set it as part of the
> > > > > > next operation anyway, so we should just do it right away.
> > > > > > 

Why should we do it right away if it will happen later on? I don't see
why this part of the patch is necessary.

> > > > > 
> > > > > I agree, re-emitting STATE_BASE_ADDRESS doesn't seem necessary. I 
> > > > > think
> > > > > we should drop this part of the patch and add it back in later if we 
> > > > > get
> > > > > some data that it's necessary. Leaving it there may be distracting to
> > > > > some readers and the BDW PRM warns that it's an expensive command:
> > > > > 
> > > > >   Execution of this command causes a full pipeline flush, thus its
> > > > >   use should be minimized for higher performance.
> > > > 
> > > > I think it should be basically free, actually.  We track a boolean,
> > > > brw->batch.state_base_address_emitted, to avoid emitting it multiple
> > > > times per batch.
> > > > 
> > > > Let's say the first thing in a fresh batch is a HiZ op, followed by
> > > > normal drawing.  Previously, we'd do:
> > > > 
> > > > 1. HiZ op commands
> > > > 2. STATE_BASE_ADDRESS (triggered by normal rendering upload)
> > > > 3. rest of normal drawing commands
> > > > 
> > > > Now we'd do:
> > > > 
> > > > 1. STATE_BASE_ADDRESS (triggered by HiZ op)
> > > > 2. HiZ op commands
> > > > 3. normal drawing commands (second SBA is skipped)
> > > > 
> > > > In other words...we're just moving it a bit earlier.  I suppose there
> > > > could be a batch containing only HiZ ops, at which point we'd pay for
> > > > a single STATE_BASE_ADDRESS...but that seems really unlikely.
> > > > 
> > > 
> > > Sorry for not stating it up front, but the special case you've mentioned
> > > is exactly what I'd like not to hurt unnecessarily.
> > > 
> 
> Why?  We really think there are going to be batches with only
> 3DSTATE_WM_HZ_OP and no normal rendering or BLORP?  It sounds
> really hypothetical to me.
> 

I've commented on the performance implications of that snippet because
it is the only functional change I can see from emitting SBA. That
unfortunately seems to have distracted us from the more important
question found above. Sorry about that.

> > Correct me if I'm wrong, but after thinking about it some more, it seems
> > that performance wouldn't suffer by emitting the SBA since the pipeline
> > was already flushed at the end of the preceding batch. It may also
> > improve since the pipelined HiZ op will likely be followed by other
> > pipelined commands. I'm not totally confident in my understanding on
> > pipeline flushes by the way. Is this why you'd like to emit the SBA here?
> > I think it's fine to leave it if we expound on the rationale.
> 
> Performance is not a motivation for this patch.  Having the GPU do
> work without a pipeline selected or state base addresses in place seems
> potentially dangerous.  I was hoping it would help with GPU hangs.  I'm
> not certain that it does, and it might be safe to skip this, but it
> seems like a lot of mental gymnastics to prove that it's safe for very
> little upside.
> 

I was only referring to the portion of the patch that emits SBA.

> I think you're right, though - doing the non-pipelined commands at the
> top may actually be better than kicking off work, stalling, and kicking
> off more work.  *shrug*
> 
> > -Nanley
> > 
> > > > > > Cc: "17.0" 
> > > > > > Signed-off-by: Kenneth Graunke 
> > > > > > ---
> > > > > >  src/mesa/drivers/dri/i965/gen8_depth_state.c | 3 +++
> > > > > >  1 file changed, 3 insertions(+)
> > > > > > 
> > > > > > diff --git a/src/mesa/drivers/dri/i965/gen8_depth_state.c 
> > > > > > b/src/mesa/drivers/dri/i965/gen8_depth_state.c
> > > > > > index a7e61354fd5..620b32df8bb 100644
> > > > > > --- a/src/mesa/drivers/dri/i965/gen8_depth_state.c
> > > > > > +++

[Mesa-dev] [AppVeyor] mesa master #3808 completed

2017-03-20 Thread AppVeyor



Build mesa 3808 completed



Commit 020b3f0c46 by Timothy Arceri on 3/21/2017 12:49 AM:

util/disk_cache: fix build on platforms where shader cache is disabled


Configure your notification preferences

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

Re: [Mesa-dev] 10bit HEVC decoding for RadeonSI v2

2017-03-20 Thread Peter Frühberger

Hi Christian,

we use it the following way:
Dependend on the surface NV12 vs. P010 we use:
https://github.com/FernetMenta/kodi-agile/blob/master/xbmc/cores/VideoPlayer/DVDCodecs/Video/VAAPI.cpp#L1416


R8 and GR88

or alternatively:
https://github.com/FernetMenta/kodi-agile/blob/master/xbmc/cores/VideoPlayer/DVDCodecs/Video/VAAPI.cpp#L1493

R16 and GR32

There is also a possibility to use BGRA, but this involves internal copy of
the yuv surfaces in vaapi and is therefore not suited well (more memory and
more load).

For both images Y and UV we use: eglCreateImageKHR extension follow
by glEGLImageTargetTexture2DOES.

See:
https://github.com/FernetMenta/kodi-agile/blob/master/xbmc/cores/VideoPlayer/DVDCodecs/Video/VAAPI.cpp#L1262

On the VAAPI side:
VA_SURFACE_ATTRIB_MEM_TYPE_DRM_PRIME with either VA_RT_FORMAT_YUV420
or VA_FOURCC_P010 are used.

I think that method is quite generalizable and nothing is intel specific.

What do you think?

Best regards
Peter



2017-03-19 14:49 GMT+01:00 Christian König :

> Hi Peter,
>
> Adding Michel and Marek for the Mesa interop side and Harry for the
> display side.
>
> How do you want us to display the decoded surfaces?
>
> Well to make a long story short: I don't have the slightest idea. Ideally
> we would of the same handling as Intel so that you guys don't have anything
> vendor dependent in your code.
>
> The first step would be to get the VA-API DRM extension to work with EGL.
> So that Kodi is able to export the YUV surfaces and import parts of them as
> separate R8/R16 or R8G8/R16G16 surfaces, right?
>
> What EGL/GL extension do you guys use to import the surfaces? Marek is
> that stuff fully supported, e.g. do we also handle the offsets correctly?
> I've added the backend code for this while doing VDPAU interop, but the
> EGL/GL frontend code needs to handle it gracefully as well.
>
> The second step is then to teach our DC how to handle RGB surfaces with
> 10bit. I doubt the old code has support for that and we probably don't want
> to add it. So Harry can you comment on how far along we got with that in DC?
>
> Regards,
> Christian.
>
>
> Am 19.03.2017 um 13:26 schrieb Peter Frühberger:
>
> Hi Christian,
>
> thank you for your message. We are still wondering about the render part.
> How do you want us to display the decoded surfaces? Looking at mpv it seems
> it will only work via vaPutSurface and is therefore tight to X11. That
> means it's dependend on the visuals 8 bit only.
>
> We are working on a drm-only kodi and now ask ourselves: Is there a
> possibility to interop with a drm extension and eglCreateImage on AMD hw,
> too? With the intel only R32, R8 linux buf methods we are also running
> succesfully on MIR now, wayland would work the very same.
>
> Best regards
> Peter
>
>
>
> 2017-03-10 17:25 GMT+01:00 rainer.hochec...@onlinehome.de <
> rainer.hochec...@onlinehome.de>:
>
>> Hi Christian,
>>
>> I already removed the check for Intel in my dev branch. On startup
>> Kodi does a functional test if vaapi works. If the test passes, it is
>> availalbe
>> regarless of the underlying type of hardware/driver.
>>
>> Regards,
>> Rainer
>>
>> *Gesendet:* Mittwoch, 08. März 2017 um 13:29 Uhr
>> *Von:* "Christian König" 
>> *An:* mesa-dev@lists.freedesktop.org
>> *Cc:* rainer.hochec...@onlinehome.de, peter.fruehber...@gmail.com
>> *Betreff:* 10bit HEVC decoding for RadeonSI v2
>> Hi guys,
>>
>> I finally found time testing this and hammering out (hopefully) all the
>> remaining bugs. Playing a 10bit HEVC file through VAAPI with mpv/ffmpeg
>> git
>> master from about two days ago now works flawlessly and has only about
>> 15% CPU
>> load on one core on a Kaveri system.
>>
>> The VDPAU path should work as well, but NVidias implementation of this is
>> still
>> completely broken and so nobody enables it and we don't have a way to
>> test it.
>>
>> Rainer/Peter maybe you guys want to take a look and enable it in Kodi.
>>
>> The next logical step is to get our display code paths to be 10bit ready.
>>
>> Please review and comment,
>> Christian.
>>
>>
>
>
>
> --
>Key-ID: 0x1A995A9B
>keyserver: pgp.mit.edu
> ==
> Fingerprint: 4606 DA19 EC2E 9A0B 0157  C81B DA07 CF63 1A99 5A9B
>
>
>


-- 
   Key-ID: 0x1A995A9B
   keyserver: pgp.mit.edu
==
Fingerprint: 4606 DA19 EC2E 9A0B 0157  C81B DA07 CF63 1A99 5A9B
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] 10bit HEVC decoding for RadeonSI v2

2017-03-20 Thread Peter Frühberger

Hi Christian,

thank you for your message. We are still wondering about the render part.
How do you want us to display the decoded surfaces? Looking at mpv it seems
it will only work via vaPutSurface and is therefore tight to X11. That
means it's dependend on the visuals 8 bit only.

We are working on a drm-only kodi and now ask ourselves: Is there a
possibility to interop with a drm extension and eglCreateImage on AMD hw,
too? With the intel only R32, R8 linux buf methods we are also running
succesfully on MIR now, wayland would work the very same.

Best regards
Peter



2017-03-10 17:25 GMT+01:00 rainer.hochec...@onlinehome.de <
rainer.hochec...@onlinehome.de>:

> Hi Christian,
>
> I already removed the check for Intel in my dev branch. On startup
> Kodi does a functional test if vaapi works. If the test passes, it is
> availalbe
> regarless of the underlying type of hardware/driver.
>
> Regards,
> Rainer
>
> *Gesendet:* Mittwoch, 08. März 2017 um 13:29 Uhr
> *Von:* "Christian König" 
> *An:* mesa-dev@lists.freedesktop.org
> *Cc:* rainer.hochec...@onlinehome.de, peter.fruehber...@gmail.com
> *Betreff:* 10bit HEVC decoding for RadeonSI v2
> Hi guys,
>
> I finally found time testing this and hammering out (hopefully) all the
> remaining bugs. Playing a 10bit HEVC file through VAAPI with mpv/ffmpeg git
> master from about two days ago now works flawlessly and has only about 15%
> CPU
> load on one core on a Kaveri system.
>
> The VDPAU path should work as well, but NVidias implementation of this is
> still
> completely broken and so nobody enables it and we don't have a way to test
> it.
>
> Rainer/Peter maybe you guys want to take a look and enable it in Kodi.
>
> The next logical step is to get our display code paths to be 10bit ready.
>
> Please review and comment,
> Christian.
>
>



-- 
   Key-ID: 0x1A995A9B
   keyserver: pgp.mit.edu
==
Fingerprint: 4606 DA19 EC2E 9A0B 0157  C81B DA07 CF63 1A99 5A9B
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa glthread: allow asynchronous pixel transfer operation when a buffer is bound

2017-03-20 Thread Markus Wick


Am 2017-03-20 14:21, schrieb Nicolai Hähnle:

On 17.03.2017 18:59, gregory hainaut wrote:
If the application is badly/strangely coded, glthread will make it 
worst.

The solution ought to be either fix the app or don't use glthread.


It would be nice if glthread could handle this properly, but I don't
currently see how.


The dispatcher thread needs a map of all valid buffer objects. So we 
need to update such a map on all glGenBuffers/glDeleteBuffers calls. So 
the overhead will be the map lookup on all affected glBindBuffer calls.


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

[Mesa-dev] [PATCH] glxglvnddispatch: Add missing dispatch for GetDriverConfig

2017-03-20 Thread Hans de Goede

Together with some fixes to xdriinfo this fixes xdriinfo not working
with glvnd.

Since apps (xdriinfo) expect GetDriverConfig to work without going to
need through the dance to setup a glxcontext (which is a reasonable
expectation IMHO), the dispatch for this ends up significantly different
then any other dispatch function.

This patch gets the job done, but I'm not really happy with how this
patch turned out, suggestions for a better fix are welcome.

Cc: Kyle Brenneman 
Signed-off-by: Hans de Goede 
---
 src/glx/g_glxglvnddispatchfuncs.c   | 18 ++
 src/glx/g_glxglvnddispatchindices.h |  1 +
 2 files changed, 19 insertions(+)

diff --git a/src/glx/g_glxglvnddispatchfuncs.c 
b/src/glx/g_glxglvnddispatchfuncs.c
index b5e3398..040cdf8 100644
--- a/src/glx/g_glxglvnddispatchfuncs.c
+++ b/src/glx/g_glxglvnddispatchfuncs.c
@@ -4,6 +4,7 @@
  */
 #include 
 
+#include "glxclient.h"
 #include "glxglvnd.h"
 #include "glxglvnddispatchfuncs.h"
 #include "g_glxglvnddispatchindices.h"
@@ -50,6 +51,7 @@ const char * const __glXDispatchTableStrings[DI_LAST_INDEX] = 
{
 __ATTRIB(GetCurrentDisplayEXT),
 // glXGetCurrentDrawable implemented by libglvnd
 // glXGetCurrentReadDrawable implemented by libglvnd
+__ATTRIB(GetDriverConfig),
 // glXGetFBConfigAttrib implemented by libglvnd
 __ATTRIB(GetFBConfigAttribSGIX),
 __ATTRIB(GetFBConfigFromVisualSGIX),
@@ -334,6 +336,21 @@ static Display *dispatch_GetCurrentDisplayEXT(void)
 
 
 
+static const char *dispatch_GetDriverConfig(const char *driverName)
+{
+/*
+ * The options are constant for a given driverName, so we do not need
+ * a context (and apps expect to be able to call this without one).
+ */
+#if defined(GLX_DIRECT_RENDERING) && !defined(GLX_USE_APPLEGL)
+return glXGetDriverConfig(driverName);
+#else
+return NULL;
+#endif
+}
+
+
+
 static int dispatch_GetFBConfigAttribSGIX(Display *dpy, GLXFBConfigSGIX config,
   int attribute, int *value_return)
 {
@@ -939,6 +956,7 @@ const void * const __glXDispatchFunctions[DI_LAST_INDEX + 
1] = {
 __ATTRIB(DestroyGLXPbufferSGIX),
 __ATTRIB(GetContextIDEXT),
 __ATTRIB(GetCurrentDisplayEXT),
+__ATTRIB(GetDriverConfig),
 __ATTRIB(GetFBConfigAttribSGIX),
 __ATTRIB(GetFBConfigFromVisualSGIX),
 __ATTRIB(GetMscRateOML),
diff --git a/src/glx/g_glxglvnddispatchindices.h 
b/src/glx/g_glxglvnddispatchindices.h
index 05a2c8c..3ba50a7 100644
--- a/src/glx/g_glxglvnddispatchindices.h
+++ b/src/glx/g_glxglvnddispatchindices.h
@@ -39,6 +39,7 @@ typedef enum __GLXdispatchIndex {
 DI_GetCurrentDisplayEXT,
 // GetCurrentDrawable implemented by libglvnd
 // GetCurrentReadDrawable implemented by libglvnd
+DI_GetDriverConfig,
 // GetFBConfigAttrib implemented by libglvnd
 DI_GetFBConfigAttribSGIX,
 DI_GetFBConfigFromVisualSGIX,
-- 
2.9.3

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

Re: [Mesa-dev] 10bit HEVC decoding for RadeonSI v2

2017-03-20 Thread rainer.hochec...@onlinehome.de

> for example how does synchronization happen between the two APIs?

right, vaapi seems not as matured as vdpau in this regard. But Kodi's multithreading design does cope with this. We call

vaSyncSurface before feeding vpp and before maping va buffers to GL.

I suggest to keep it simple from a driver perspective and require applications to use vaSyncSurface

Gesendet: Sonntag, 19. März 2017 um 15:28 Uhr
Von: "Christian König"
An: "Peter Frühberger"
Cc: "rainer.hochec...@onlinehome.de" , mesa-dev@lists.freedesktop.org, lru...@libreelec.tv, "Michel Dänzer" , "Marek Olšák" , "Wentland, Harry"
Betreff: Re: 10bit HEVC decoding for RadeonSI v2

What do you think?

In general that it might work, but basic problem is the API design once more.

While with VDPAU the steps where applications asks OpenGL to interop with VDPAU and the two APIs can do all the handshaking internally.

With VA-API we have Application exporting buffers from VA-API and then importing the same buffer as two surfaces into OpenGL.

That leaves a whole bunch of open questions, for example how does synchronization happen between the two APIs? E.g. the application (Kodi) probably doesn't wants to wait for the decoding result before it uses the the surface with OpenGL. We don't have a way to sync between the two APIs here except for the handle.

The next problem is how do we communicate the layout of data in the buffer? E.g. we have the format and the offset, but that assumes that you don't have any nasty kind of tilling modes applied here.

I think we can make that work for now (we aren't using tilling modes with UVD much anyway), but this is going to bite us again sooner or later. Going to put the whole thing on my todo list once more.

Regards,
Christian.

Am 19.03.2017 um 15:06 schrieb Peter Frühberger:

Hi Christian,

we use it the following way:

Dependend on the surface NV12 vs. P010 we use:

https://github.com/FernetMenta/kodi-agile/blob/master/xbmc/cores/VideoPlayer/DVDCodecs/Video/VAAPI.cpp#L1416

R8 and GR88

or alternatively:

https://github.com/FernetMenta/kodi-agile/blob/master/xbmc/cores/VideoPlayer/DVDCodecs/Video/VAAPI.cpp#L1493

R16 and GR32

There is also a possibility to use BGRA, but this involves internal copy of the yuv surfaces in vaapi and is therefore not suited well (more memory and more load).

For both images Y and UV we use: eglCreateImageKHR extension follow by glEGLImageTargetTexture2DOES.

See: https://github.com/FernetMenta/kodi-agile/blob/master/xbmc/cores/VideoPlayer/DVDCodecs/Video/VAAPI.cpp#L1262

On the VAAPI side:
VA_SURFACE_ATTRIB_MEM_TYPE_DRM_PRIME with either VA_RT_FORMAT_YUV420 or VA_FOURCC_P010 are used.

I think that method is quite generalizable and nothing is intel specific.

What do you think?

Best regards

Peter

2017-03-19 14:49 GMT+01:00 Christian König :

Hi Peter,

Adding Michel and Marek for the Mesa interop side and Harry for the display side.
How do you want us to display the decoded surfaces?
Well to make a long story short: I don't have the slightest idea. Ideally we would of the same handling as Intel so that you guys don't have anything vendor dependent in your code.

The first step would be to get the VA-API DRM extension to work with EGL. So that Kodi is able to export the YUV surfaces and import parts of them as separate R8/R16 or R8G8/R16G16 surfaces, right?

What EGL/GL extension do you guys use to import the surfaces? Marek is that stuff fully supported, e.g. do we also handle the offsets correctly? I've added the backend code for this while doing VDPAU interop, but the EGL/GL frontend code needs to handle it gracefully as well.

The second step is then to teach our DC how to handle RGB surfaces with 10bit. I doubt the old code has support for that and we probably don't want to add it. So Harry can you comment on how far along we got with that in DC?

Regards,
Christian.

Am 19.03.2017 um 13:26 schrieb Peter Frühberger:

Hi Christian,

thank you for your message. We are still wondering about the render part. How do you want us to display the decoded surfaces? Looking at mpv it seems it will only work via vaPutSurface and is therefore tight to X11. That means it's dependend on the visuals 8 bit only.

We are working on a drm-only kodi and now ask ourselves: Is there a possibility to interop with a drm extension and eglCreateImage on AMD hw, too? With the intel only R32, R8 linux buf methods we are also running succesfully on MIR now, wayland would work the very same.

Best regards

Peter

2017-03-10 17:25 GMT+01:00 rainer.hochec...@onlinehome.de :

Hi Christian,

I already removed the check for Intel in my dev branch. On startup

Kodi does a functional test if vaapi works. If the

[Mesa-dev] [AppVeyor] mesa master #3807 failed

2017-03-20 Thread AppVeyor




Build mesa 3807 failed


Commit af73acca2b by Grazvydas Ignotas on 3/15/2017 11:09 PM:

tests/cache_test: use the blob key's actual first byte\n\nThere is no need to hardcode it, we can just use blob_key[0].\nThis is needed because the next patches are going to change how cache\nkeys are computed.\n\nSigned-off-by: Grazvydas Ignotas \nReviewed-by: Timothy Arceri 


Configure your notification preferences

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

Re: [Mesa-dev] [PATCH 6/5] i965: Turn on support for image modifiers

2017-03-20 Thread Jason Ekstrand

On Mon, Mar 20, 2017 at 4:30 PM, Ben Widawsky  wrote:

> On 17-03-20 16:21:53, Jason Ekstrand wrote:
>
>> On Mon, Mar 20, 2017 at 4:15 PM, Ben Widawsky  wrote:
>>
>> On 17-03-20 12:03:24, Jason Ekstrand wrote:
>>>
>>> My only question here is whether or not we want to add a "supported
 modifiers" query to DRIimage before we bump the version number.  It's
 probably not super-important because we can always bump the version
 number
 again.  Meh.


 Remind me what the reasoning is for support modifiers? I thought we
>>> agreed
>>> to
>>> just use GET_PLANE2? Supported modifiers is difficult because mesa has no
>>> idea
>>> of per plane constraints.
>>>
>>
>>
>> They're for completely different cases.  If you want to scan out, use
>> GET_PLANE2, end of story.  If, however, you're not trying to scan out and
>> your window is always going to get composited (think not full-screen) then
>> you may have a much larger set of modifiers available to you and that set
>> of modifiers is not determined by GET_PLANE2 but by the GL or whatever is
>> being used for compositing.
>>
>>
>>
> Oh, yeah. Is there a consumer today of this? If we don't really have one
> readily
> available, I'd say don't worry about it until we need it.


It'll be consumed by the EGL extension that's being cooked up.  If you want
to put it off, that's fine with me.


>
>
>>> On Sat, Mar 18, 2017 at 1:00 PM, Ben Widawsky  wrote:
>>>

 All the plumbing is in place so the extension just needs to be

> advertised.
>
> Signed-off-by: Ben Widawsky 
> ---
>  src/mesa/drivers/dri/i965/intel_screen.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
> b/src/mesa/drivers/dri/i965/intel_screen.c
> index ca725d9202..1ff18b30e4 100644
> --- a/src/mesa/drivers/dri/i965/intel_screen.c
> +++ b/src/mesa/drivers/dri/i965/intel_screen.c
> @@ -948,7 +948,7 @@ intel_from_planar(__DRIimage *parent, int plane,
> void
> *loaderPrivate)
>  }
>
>  static const __DRIimageExtension intelImageExtension = {
> -.base = { __DRI_IMAGE, 13 },
> +.base = { __DRI_IMAGE, 14 },
>
>  .createImageFromName=
> intel_create_image_from_name,
>  .createImageFromRenderbuffer= intel_create_image_from_
> renderbuffer,
> --
> 2.12.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
> --
>>> Ben Widawsky, Intel Open Source Technology Center
>>>
>>>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 6/5] i965: Turn on support for image modifiers

2017-03-20 Thread Ben Widawsky


On 17-03-20 16:21:53, Jason Ekstrand wrote:

On Mon, Mar 20, 2017 at 4:15 PM, Ben Widawsky  wrote:


On 17-03-20 12:03:24, Jason Ekstrand wrote:


My only question here is whether or not we want to add a "supported
modifiers" query to DRIimage before we bump the version number.  It's
probably not super-important because we can always bump the version number
again.  Meh.



Remind me what the reasoning is for support modifiers? I thought we agreed
to
just use GET_PLANE2? Supported modifiers is difficult because mesa has no
idea
of per plane constraints.



They're for completely different cases.  If you want to scan out, use
GET_PLANE2, end of story.  If, however, you're not trying to scan out and
your window is always going to get composited (think not full-screen) then
you may have a much larger set of modifiers available to you and that set
of modifiers is not determined by GET_PLANE2 but by the GL or whatever is
being used for compositing.




Oh, yeah. Is there a consumer today of this? If we don't really have one readily
available, I'd say don't worry about it until we need it.



On Sat, Mar 18, 2017 at 1:00 PM, Ben Widawsky  wrote:


All the plumbing is in place so the extension just needs to be

advertised.

Signed-off-by: Ben Widawsky 
---
 src/mesa/drivers/dri/i965/intel_screen.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
b/src/mesa/drivers/dri/i965/intel_screen.c
index ca725d9202..1ff18b30e4 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -948,7 +948,7 @@ intel_from_planar(__DRIimage *parent, int plane, void
*loaderPrivate)
 }

 static const __DRIimageExtension intelImageExtension = {
-.base = { __DRI_IMAGE, 13 },
+.base = { __DRI_IMAGE, 14 },

 .createImageFromName= intel_create_image_from_name,
 .createImageFromRenderbuffer= intel_create_image_from_
renderbuffer,
--
2.12.0

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



--
Ben Widawsky, Intel Open Source Technology Center


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

Re: [Mesa-dev] [PATCH 6/5] i965: Turn on support for image modifiers

2017-03-20 Thread Jason Ekstrand

On Mon, Mar 20, 2017 at 4:15 PM, Ben Widawsky  wrote:

> On 17-03-20 12:03:24, Jason Ekstrand wrote:
>
>> My only question here is whether or not we want to add a "supported
>> modifiers" query to DRIimage before we bump the version number.  It's
>> probably not super-important because we can always bump the version number
>> again.  Meh.
>>
>>
> Remind me what the reasoning is for support modifiers? I thought we agreed
> to
> just use GET_PLANE2? Supported modifiers is difficult because mesa has no
> idea
> of per plane constraints.


They're for completely different cases.  If you want to scan out, use
GET_PLANE2, end of story.  If, however, you're not trying to scan out and
your window is always going to get composited (think not full-screen) then
you may have a much larger set of modifiers available to you and that set
of modifiers is not determined by GET_PLANE2 but by the GL or whatever is
being used for compositing.


>
> On Sat, Mar 18, 2017 at 1:00 PM, Ben Widawsky  wrote:
>>
>> All the plumbing is in place so the extension just needs to be
>>> advertised.
>>>
>>> Signed-off-by: Ben Widawsky 
>>> ---
>>>  src/mesa/drivers/dri/i965/intel_screen.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
>>> b/src/mesa/drivers/dri/i965/intel_screen.c
>>> index ca725d9202..1ff18b30e4 100644
>>> --- a/src/mesa/drivers/dri/i965/intel_screen.c
>>> +++ b/src/mesa/drivers/dri/i965/intel_screen.c
>>> @@ -948,7 +948,7 @@ intel_from_planar(__DRIimage *parent, int plane, void
>>> *loaderPrivate)
>>>  }
>>>
>>>  static const __DRIimageExtension intelImageExtension = {
>>> -.base = { __DRI_IMAGE, 13 },
>>> +.base = { __DRI_IMAGE, 14 },
>>>
>>>  .createImageFromName= intel_create_image_from_name,
>>>  .createImageFromRenderbuffer= intel_create_image_from_
>>> renderbuffer,
>>> --
>>> 2.12.0
>>>
>>> ___
>>> mesa-dev mailing list
>>> mesa-dev@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>>
>>>
> --
> Ben Widawsky, Intel Open Source Technology Center
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 6/5] i965: Turn on support for image modifiers

2017-03-20 Thread Ben Widawsky


On 17-03-20 12:03:24, Jason Ekstrand wrote:

My only question here is whether or not we want to add a "supported
modifiers" query to DRIimage before we bump the version number.  It's
probably not super-important because we can always bump the version number
again.  Meh.



Remind me what the reasoning is for support modifiers? I thought we agreed to
just use GET_PLANE2? Supported modifiers is difficult because mesa has no idea
of per plane constraints.


On Sat, Mar 18, 2017 at 1:00 PM, Ben Widawsky  wrote:


All the plumbing is in place so the extension just needs to be
advertised.

Signed-off-by: Ben Widawsky 
---
 src/mesa/drivers/dri/i965/intel_screen.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
b/src/mesa/drivers/dri/i965/intel_screen.c
index ca725d9202..1ff18b30e4 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -948,7 +948,7 @@ intel_from_planar(__DRIimage *parent, int plane, void
*loaderPrivate)
 }

 static const __DRIimageExtension intelImageExtension = {
-.base = { __DRI_IMAGE, 13 },
+.base = { __DRI_IMAGE, 14 },

 .createImageFromName= intel_create_image_from_name,
 .createImageFromRenderbuffer= intel_create_image_from_
renderbuffer,
--
2.12.0

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



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

Re: [Mesa-dev] [PATCH] i965: Shut up major()/minor() warnings.

2017-03-20 Thread Matt Turner

Yep, lots of patches like this in Gentoo.

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

[Mesa-dev] [PATCH] i965: Shut up major()/minor() warnings.

2017-03-20 Thread Kenneth Graunke

Recent glibc generates this warning:

brw_performance_query.c:1648:13: warning: In the GNU C Library, "minor" is 
defined
 by . For historical compatibility, it is
 currently defined by  as well, but we plan to
 remove this soon. To use "minor", include 
 directly. If you did not intend to use a system-defined macro
 "minor", you should undefine it after including .

min = minor(sb.st_rdev);

So, include sys/sysmacros.h to shut up the warning.
---
 src/mesa/drivers/dri/i965/brw_performance_query.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/mesa/drivers/dri/i965/brw_performance_query.c 
b/src/mesa/drivers/dri/i965/brw_performance_query.c
index 2e04e091d29..17e0d6f0cdf 100644
--- a/src/mesa/drivers/dri/i965/brw_performance_query.c
+++ b/src/mesa/drivers/dri/i965/brw_performance_query.c
@@ -42,6 +42,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 #include 
-- 
2.12.0

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

1 2 3 4 >

1 - 100 of 337 matches

Mail list logo