[Mesa-dev] [PATCH] anv: Stall before fast-clear operations

During initial CCS bring-up, I discovered that you have to do a full CS stall prior to doing a CCS resolve as well as afterwards. It appears that the same is needed for fast-clears as well. This fixes rendering corruptions on The Talos Principal on Sky Lake GT4. The issue hasn't been

[Mesa-dev] [Bug 100073] Shader Disk Cache 32/64 bit detection has a flaw. Missed existence of x32 ABI

https://bugs.freedesktop.org/show_bug.cgi?id=100073 --- Comment #25 from oia...@gmail.com --- (In reply to Emil Velikov from comment #24) > On 10 March 2017 at 18:51, Steven Newbury wrote: > > On Fri, 2017-03-10 at 13:27 +, bugzilla-dae...@freedesktop.org > > wrote: >

[Mesa-dev] [Bug 99591] Segmentation fault when running vulkaninfo with RADV Radeon Vulkan driver

https://bugs.freedesktop.org/show_bug.cgi?id=99591 --- Comment #7 from Jure Repinc --- (In reply to Mike Lothian from comment #6) > Out of interest was LLVM compiled with LTO? I was seeing segfaults with > vulkaninfo and I found recompiling llvm without LTO fixed things for

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

https://bugs.freedesktop.org/show_bug.cgi?id=100091 --- Comment #21 from John --- (In reply to Emil Velikov from comment #20) > I would really appreciate if one can spend 2 minutes and test the patch in > question. Pretty please ? > > Do move/prune your cache and let me

Re: [Mesa-dev] [PATCH 12/24] radeonsi: set readnone on reads from read-only memory

On Fri, Mar 10, 2017 at 11:03 PM, Constantine Kharlamov wrote: > > On 26.02.2017 02:58, Marek Olšák wrote: >> From: Marek Olšák >> >> --- >> src/amd/common/ac_llvm_build.c | 11 +-- >> src/amd/common/ac_llvm_build.h | 3 ++-

[Mesa-dev] [libdrm PATCH] intel: Make unsynchronized GTT mappings work on systems with snooping.

On systems without LLC, drm_intel_gem_bo_map_unsynchronized() has had the surprising behavior of doing a synchronized GTT mapping. This is obviously not what the user of the API wanted. Eric left a comment indicating a valid concern: if the CPU and GPU caches are incoherent, we don't keep track

[Mesa-dev] [Bug 99591] Segmentation fault when running vulkaninfo with RADV Radeon Vulkan driver

https://bugs.freedesktop.org/show_bug.cgi?id=99591 Mike Lothian changed: What|Removed |Added CC||m...@fireburn.co.uk

[Mesa-dev] [Bug 99987] Mesa 13+ breaks Xvnc (and similar X servers)

https://bugs.freedesktop.org/show_bug.cgi?id=99987 Dennis Schridde changed: What|Removed |Added CC||devuran...@gmx.net

[Mesa-dev] [Bug 99591] Segmentation fault when running vulkaninfo with RADV Radeon Vulkan driver

https://bugs.freedesktop.org/show_bug.cgi?id=99591 --- Comment #5 from Jure Repinc --- I'm not sure if this helps but here is some steping by instructions in GDB: Temporary breakpoint 6, main () at main.cpp:82 82 HelloTriangleApplication app; (gdb) c Continuing.

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

https://bugs.freedesktop.org/show_bug.cgi?id=100091 --- Comment #20 from Emil Velikov --- (In reply to John from comment #18) > (In reply to Emil Velikov from comment #16) > > Some ideas: > > - a non-timestamp better solution might be applicable/in the works > >

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

https://bugs.freedesktop.org/show_bug.cgi?id=100091 --- Comment #19 from Emil Velikov --- (In reply to Michel Dänzer from comment #17) > Emil, I don't think there's any mystery anymore given comment 13 — the > different cache timestamps are due to *_dri.so and

Re: [Mesa-dev] Moving i965 driver to genxml commands and structures

Hi! So I've decided to use the version I had typed out after revising your current patches. My version has more functions included and I saw some minor mistakes in the committed files. Of course, there is no guarantee that it is totally error-free, but I did do a couple passes with the

[Mesa-dev] [Bug 100093] configure: error: Package requirements (zlib >= 1.2.8) were not met:

https://bugs.freedesktop.org/show_bug.cgi?id=100093 Vinson Lee changed: What|Removed |Added Resolution|--- |WONTFIX

Re: [Mesa-dev] [PATCH] intel: Correct the BDW surface state size

On Thu, Mar 09, 2017 at 08:18:25PM -0800, Kenneth Graunke wrote: > On Thursday, March 9, 2017 3:35:15 PM PST Nanley Chery wrote: > > The PRMs state that this packet is 16 DWORDS long. Ensure that the last > > three DWORDS are zeroed as required by the hardware when allocating a > > null surface

Re: [Mesa-dev] [PATCH 12/24] radeonsi: set readnone on reads from read-only memory

On 26.02.2017 02:58, Marek Olšák wrote: > From: Marek Olšák > > --- > src/amd/common/ac_llvm_build.c | 11 +-- > src/amd/common/ac_llvm_build.h | 3 ++- > src/gallium/drivers/radeonsi/si_shader.c | 20 ++-- > 3 files changed, 21

[Mesa-dev] [Bug 100151] Front buffer drawing mode shows black window with gallium software rasterizers

https://bugs.freedesktop.org/show_bug.cgi?id=100151 --- Comment #4 from Pradeep Yadav --- Not able to clone mesa repository using git clone git://anongit.freedesktop.org/git/mesa/mesa . anongit.freedesktop.org is not responding. $ git clone

[Mesa-dev] [Bug 100151] Front buffer drawing mode shows black window with gallium software rasterizers

https://bugs.freedesktop.org/show_bug.cgi?id=100151 --- Comment #3 from Józef Kucia --- (In reply to Pradeep Yadav from comment #2) > Applied the patch attached with bug 99116 in Mesa 13.0.5 source code but can > still reproduce the problem. FWIW, your OpenGL program

[Mesa-dev] [Bug 100151] Front buffer drawing mode shows black window with gallium software rasterizers

https://bugs.freedesktop.org/show_bug.cgi?id=100151 --- Comment #2 from Pradeep Yadav --- Applied the patch attached with bug 99116 in Mesa 13.0.5 source code but can still reproduce the problem. -- You are receiving this mail because: You are the QA Contact for the

Re: [Mesa-dev] [PATCH 1/2] configure.ac: require pthread-stubs only where available

On 02/03/2017 19:02, Emil Velikov wrote: From: Emil Velikov The project is a thing only for BSD platforms. Or in other words - for any other platforms building/installing pthread-stubs results only in a pthread-stub.pc file. And even where it provides a DSO,

Re: [Mesa-dev] [PATCH 2/3] gbm: Introduce modifiers into surface/bo creation

On Thu, Mar 9, 2017 at 6:52 PM, Jason Ekstrand wrote: > On Thu, Mar 9, 2017 at 5:48 PM, Ben Widawsky wrote: > >> The idea behind modifiers like this is that the user of GBM will have >> some mechanism to query what properties the hardware supports for

Re: [Mesa-dev] [PATCH v2 1/2] intel: genxml: add script to generate gzipped genxml

Quoting Lionel Landwerlin (2017-03-10 10:00:12) > v2 (from Dylan): >Add main function >Add missing Copyright >Use print_function > > Signed-off-by: Lionel Landwerlin > --- > src/intel/Makefile.genxml.am| 1 + >

Re: [Mesa-dev] [Bug 100073] Shader Disk Cache 32/64 bit detection has a flaw. Missed existence of x32 ABI

On 10 March 2017 at 18:51, Steven Newbury wrote: > On Fri, 2017-03-10 at 13:27 +, bugzilla-dae...@freedesktop.org > wrote: >> Comment # 23 on bug 100073 from Grazvydas Ignotas >> (In reply to oiaohm from comment #21) >> > This is why I am so upset. As soon as this

[Mesa-dev] [Bug 100073] Shader Disk Cache 32/64 bit detection has a flaw. Missed existence of x32 ABI

https://bugs.freedesktop.org/show_bug.cgi?id=100073 --- Comment #24 from Emil Velikov --- On 10 March 2017 at 18:51, Steven Newbury wrote: > On Fri, 2017-03-10 at 13:27 +, bugzilla-dae...@freedesktop.org > wrote: >> Comment # 23 on bug 100073

[Mesa-dev] [Bug 100151] Front buffer drawing mode shows black window with gallium software rasterizers

https://bugs.freedesktop.org/show_bug.cgi?id=100151 Józef Kucia changed: What|Removed |Added CC|

[Mesa-dev] [Bug 100151] Front buffer drawing mode shows black window with gallium software rasterizers

https://bugs.freedesktop.org/show_bug.cgi?id=100151 --- Comment #1 from Józef Kucia --- (In reply to Pradeep Yadav from comment #0) > When front buffer drawing mode is enabled using glDrawBuffer(GL_FRONT); the > window becomes black after glFlush() call. This is likely a

[Mesa-dev] [Bug 100151] Front buffer drawing mode shows black window with gallium software rasterizers

https://bugs.freedesktop.org/show_bug.cgi?id=100151 Pradeep Yadav changed: What|Removed |Added Summary|Front buffer drawing mode |Front buffer

[Mesa-dev] [Bug 100151] Front buffer drawing mode shows black window

https://bugs.freedesktop.org/show_bug.cgi?id=100151 Bug ID: 100151 Summary: Front buffer drawing mode shows black window Product: Mesa Version: 13.0 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW

Re: [Mesa-dev] [PATCH v3 0/6] Use drmDevice2 API, take ... final

On 10 March 2017 at 14:25, Mike Lothian wrote: > Works great - tested remotely passing DISPLAY=:0 now only when I pass > DRI_PRIME=1 does the card fire up > Perfect. I'll translate this to "Tested-by..." and, barring any objections, I'll push the series mid next week. -Emil

Re: [Mesa-dev] [Bug 100073] Shader Disk Cache 32/64 bit detection has a flaw. Missed existence of x32 ABI

On Fri, 2017-03-10 at 13:27 +, bugzilla-dae...@freedesktop.org wrote: > Comment # 23 on bug 100073 from Grazvydas Ignotas > (In reply to oiaohm from comment #21) > > This is why I am so upset.   As soon as this comes though I have > possible > > trouble with miss matched mesa versions crossing

Re: [Mesa-dev] [PATCH 1/2] configure.ac: require pthread-stubs only where available

On 2 March 2017 at 19:02, Emil Velikov wrote: > From: Emil Velikov > > The project is a thing only for BSD platforms. Or in other words - for > any other platforms building/installing pthread-stubs results only in a > pthread-stub.pc file. >

Re: [Mesa-dev] [Mesa-stable] [PATCH] intel: Correct the BDW surface state size

On Thu, Mar 9, 2017 at 3:35 PM, Nanley Chery wrote: > The PRMs state that this packet is 16 DWORDS long. Ensure that the last > three DWORDS are zeroed as required by the hardware when allocating a > null surface state. > > Cc: >

Re: [Mesa-dev] [PATCH v2 2/2] aubinator/genxml: use gzipped files to store embedded genxml

On 10 March 2017 at 18:00, Lionel Landwerlin wrote: > $(GENXML_GENERATED_FILES): Makefile.am We don't need this one any more - there's no code in the Makefile that would influence (should trigger) the file to be regenerated. -Emil

Re: [Mesa-dev] [PATCH 1/2] intel: genxml: add script to generate gzipped genxml

On 10 March 2017 at 18:01, Emil Velikov wrote: > Hi Lionel, > > I thinking about this just the other day - we have zlib dependency, > yet we store some ~1MiB of XML in the binary. > Not to mention that some distros ship xxd as part of vim ... but that > a distro problem

Re: [Mesa-dev] [PATCH 1/2] intel: genxml: add script to generate gzipped genxml

Hi Lionel, I thinking about this just the other day - we have zlib dependency, yet we store some ~1MiB of XML in the binary. Not to mention that some distros ship xxd as part of vim ... but that a distro problem ;-) On 10 March 2017 at 16:26, Lionel Landwerlin

[Mesa-dev] [PATCH v2 2/2] aubinator/genxml: use gzipped files to store embedded genxml

This reduces the size of the aubinator binary from ~1.4Mb to ~700Kb. We can now also drop the checks on xxd in configure. v2: Fix incorrect makefile dependency (Lionel) Signed-off-by: Lionel Landwerlin --- configure.ac | 1 -

[Mesa-dev] [PATCH v2 1/2] intel: genxml: add script to generate gzipped genxml

v2 (from Dylan): Add main function Add missing Copyright Use print_function Signed-off-by: Lionel Landwerlin --- src/intel/Makefile.genxml.am| 1 + src/intel/genxml/gen_zipped_file.py | 29 + 2 files changed, 30

Re: [Mesa-dev] [PATCH 1/2] intel: genxml: add script to generate gzipped genxml

Quoting Lionel Landwerlin (2017-03-10 08:26:15) > Signed-off-by: Lionel Landwerlin > --- > src/intel/Makefile.genxml.am| 1 + > src/intel/genxml/gen_zipped_file.py | 25 + > 2 files changed, 26 insertions(+) > create mode 100755

[Mesa-dev] [PATCH 2/3] radeon_drm_cs_flush: check null return from radeon_cs_create_fence

Follow-up of patch: "radeon_cs_create_fence: check null return from radeon_winsys_bo_create" radeon_drm_cs_flush radeon_cs_create_fence radeon_winsys_bo_create Signed-off-by: Julien Isorce --- src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 24 +---

[Mesa-dev] [PATCH 0/3] Fixes 1 crash in gallium/hud and 1 crash in gallium/radeon

I encountered these crashes with the radeonsi driver when the VRAM was full. Even if the app should be careful to not upload too much texture for example, it is better not to crash in mesa. Also I found other places in mesa when these checks are done so let's do the same here. I am quite

[Mesa-dev] [PATCH 1/3] radeon_cs_create_fence: check null return from radeon_winsys_bo_create

Fixes the following segmentation fault: radeon_drm_cs_add_buffer (bo=0x0) at radeon_drm_cs.c -> if (!bo->handle) (gdb) bt 0 radeon_drm_cs_add_buffer (bo=0x0) at radeon_drm_cs.c 1 0x7fffe73575de in radeon_cs_create_fence radeon_drm_cs.c 2 0x7fffe7358c48 in radeon_drm_cs_flush

[Mesa-dev] [PATCH 3/3] hud_context: check NULL return from u_upload_alloc

Fixes the following segmentation fault: signal SIGSEGV: invalid address (fault address: 0x0) frame #0: 0x7fffe718e117 radeonsi_dri.so hud_draw_background_quad hud_context.c:170 167 168 assert(hud->bg.num_vertices + 4 <= hud->bg.max_num_vertices); 169 -> 170 vertices[num++]

[Mesa-dev] [PATCH 2/3] radeon_drm_cs_flush: check null return from radeon_cs_create_fence

Follow-up of patch: "radeon_cs_create_fence: check null return from radeon_winsys_bo_create" radeon_drm_cs_flush radeon_cs_create_fence radeon_winsys_bo_create Signed-off-by: Julien Isorce --- src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 22 +++---

[Mesa-dev] [Bug 100120] Mesa fails to build with gcc address sanitizer (-fsanitize=address -lasan)

https://bugs.freedesktop.org/show_bug.cgi?id=100120 --- Comment #9 from Jeff Smith --- A few more things I found... Either with or without a fixed libtool, libdl detection is still affected when -fsanitize=address is set. A more precise way to handle this than adding -ldl

[Mesa-dev] [PATCH 2/2] aubinator/genxml: use gzipped files to store embedded genxml

This reduces the size of the aubinator binary from ~1.4Mb to ~700Kb. With can now drop the checks on xxd in configure. Signed-off-by: Lionel Landwerlin --- configure.ac | 1 - src/intel/Makefile.genxml.am | 10 ++- src/intel/tools/Makefile.am

[Mesa-dev] [PATCH 0/2] Aubinator: use gzipped genxml files

Hi, Now that zlib has been added as a dependency to Mesa, we can start using gzip to store embedded copies of genxml into aubinator. It reduces the size of the aubinator binary by roughly half. Cheers, Lionel Landwerlin (2): intel: genxml: add script to generate gzipped genxml

[Mesa-dev] [PATCH 1/2] intel: genxml: add script to generate gzipped genxml

Signed-off-by: Lionel Landwerlin --- src/intel/Makefile.genxml.am| 1 + src/intel/genxml/gen_zipped_file.py | 25 + 2 files changed, 26 insertions(+) create mode 100755 src/intel/genxml/gen_zipped_file.py diff --git

[Mesa-dev] [PATCH 1/3] util/disk_cache: use LRU eviction rather than random eviction (v3)

Still using fast random selection of two-character subdirectory in which to check cache files rather than scanning entire cache. v2: Factor out double strlen call v3: C99 declaration of variables where used --- Also have a patch to pass the predicate functions sb and len instead which saves

Re: [Mesa-dev] [PATCH] drm-atomic: Include header file

On 4 March 2017 at 15:01, Fabio Estevam wrote: > Include header file to fix the following build warning: > > CC kmscube-drm.o > drm-atomic.c: In function 'init_drm_atomic': > drm-atomic.c:346:14: warning: implicit declaration of function 'calloc' >

Re: [Mesa-dev] [PATCH v3 0/6] Use drmDevice2 API, take ... final

Works great - tested remotely passing DISPLAY=:0 now only when I pass DRI_PRIME=1 does the card fire up Thanks Mike On Fri, 10 Mar 2017 at 13:56 Emil Velikov wrote: > On 10 March 2017 at 13:35, Mike Lothian wrote: > > Does this mean my dGPU will

Re: [Mesa-dev] [PATCH v3 0/6] Use drmDevice2 API, take ... final

On 10 March 2017 at 13:35, Mike Lothian wrote: > Does this mean my dGPU will stop being woken up when I play videos or open > Chromium? > Yes, precisely. Do give it a test and let me know how it behaves on your end. -Emil ___

Re: [Mesa-dev] [PATCH] util/disk_cache: fix zlib linking with LTO build

On Fri, 2017-03-10 at 12:11 +, Emil Velikov wrote: > On 9 March 2017 at 14:39, Steven Newbury > wrote: > > Introduction of zlib compression for the shader cache means > > zlib needs to be explicitly linked to libOSMesa and libstandalone > > otherwise build fails when

Re: [Mesa-dev] [PATCH v3 0/6] Use drmDevice2 API, take ... final

Does this mean my dGPU will stop being woken up when I play videos or open Chromium? On Fri, 10 Mar 2017 at 12:32 Emil Velikov wrote: > Hi all, > > Here is hopefully the final round of using drmDevice2. > > As a brief reminder - probing devices via drmDevice or

[Mesa-dev] [Bug 100073] Shader Disk Cache 32/64 bit detection has a flaw. Missed existence of x32 ABI

https://bugs.freedesktop.org/show_bug.cgi?id=100073 --- Comment #23 from Grazvydas Ignotas --- (In reply to oiaohm from comment #21) > This is why I am so upset. As soon as this comes though I have possible > trouble with miss matched mesa versions crossing with each other

Re: [Mesa-dev] [PATCH 4/8] util/disk_cache: make disk_cache_put() compatible with u_queue

On Fri, Mar 10, 2017 at 4:28 AM, Timothy Arceri wrote: > --- > src/compiler/glsl/shader_cache.cpp | 5 - > src/compiler/glsl/tests/cache_test.c| 29 > - > src/gallium/drivers/radeonsi/si_state_shaders.c | 9 ++-- >

[Mesa-dev] [PATCH v2 21/24] anv/blorp: make anv_cmd_buffer_alloc_blorp_binding_table() return a VkResult

Instead of asserting inside the function, and then use use that information to return early from its callers upon failure. --- src/intel/vulkan/anv_blorp.c | 35 --- src/intel/vulkan/anv_private.h | 5 +++-- src/intel/vulkan/genX_blorp_exec.c | 8

[Mesa-dev] [PATCH v2 14/24] anv/cmd_buffer: handle allocation errors during vkCmdBeginRenderPass()

Fixes: dEQP-VK.api.out_of_host_memory.cmd_begin_render_pass --- src/intel/vulkan/genX_cmd_buffer.c | 14 +++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/src/intel/vulkan/genX_cmd_buffer.c b/src/intel/vulkan/genX_cmd_buffer.c index efb271e..539e9ea 100644 ---

[Mesa-dev] [PATCH v2 17/24] anv/cmd_buffer: skip vkCmdDraw*() on broken command buffers

--- src/intel/vulkan/genX_cmd_buffer.c | 12 1 file changed, 12 insertions(+) diff --git a/src/intel/vulkan/genX_cmd_buffer.c b/src/intel/vulkan/genX_cmd_buffer.c index 539e9ea..112239c 100644 --- a/src/intel/vulkan/genX_cmd_buffer.c +++ b/src/intel/vulkan/genX_cmd_buffer.c @@

[Mesa-dev] [PATCH v2 23/24] anv: handle errors in emit_binding_table() and emit_samplers()

These can fail to allocate device memory, however, the driver can recover from this error by allocating a new binding table block and trying again. v2: - Instead of tracking the errors in these functions and making callers reset the batch's status before attempting to allocate a new block

[Mesa-dev] [PATCH v2 11/24] anv/cmd_buffer: report tracked errors in vkEndCommandBuffer()

--- src/intel/vulkan/genX_cmd_buffer.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/intel/vulkan/genX_cmd_buffer.c b/src/intel/vulkan/genX_cmd_buffer.c index 61066b8..9ae9de1 100644 --- a/src/intel/vulkan/genX_cmd_buffer.c +++ b/src/intel/vulkan/genX_cmd_buffer.c @@ -618,6 +618,9

[Mesa-dev] [PATCH v2 19/24] anv/cmd_buffer: skip vkCmdExecuteCommands() on broken command buffers

v2: Assert on secondary commands, applications should've called vkEndCommandBuffer() and received an error for them before. --- src/intel/vulkan/genX_cmd_buffer.c | 4 1 file changed, 4 insertions(+) diff --git a/src/intel/vulkan/genX_cmd_buffer.c b/src/intel/vulkan/genX_cmd_buffer.c

[Mesa-dev] [PATCH v2 15/24] anv/cmd_buffer: handle out of memory during vkCmdPushConstants

Fixes: dEQP-VK.api.out_of_host_memory.cmd_push_constants --- src/intel/vulkan/anv_cmd_buffer.c | 14 +++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/src/intel/vulkan/anv_cmd_buffer.c b/src/intel/vulkan/anv_cmd_buffer.c index 003a28c..3c9efac 100644 ---

[Mesa-dev] [PATCH v2 20/24] anv/device: assert that commands submitted to a queue are not bogus

Any errors that may have happened during the command buffer recording are reported by vkEndCommandBuffer() and it is the application's reponsibility to not submit broken commands to a queue. --- src/intel/vulkan/anv_device.c | 1 + 1 file changed, 1 insertion(+) diff --git

[Mesa-dev] [PATCH v2 09/24] anv: avoid crashes when failing to allocate batches

Most of the time we use macros that handle this situation transparently, but there are some cases were we need to handle this explicitly. This patch makes sure we don't crash, notice that error handling takes place in the function that actually failed the allocation, anv_batch_emit_dwords(),

[Mesa-dev] [PATCH v2 04/24] anv/cmd_buffer: report errors in vkBeginCommandBuffer()

--- src/intel/vulkan/genX_cmd_buffer.c | 15 +-- 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/src/intel/vulkan/genX_cmd_buffer.c b/src/intel/vulkan/genX_cmd_buffer.c index 9fdc08b..f74109e 100644 --- a/src/intel/vulkan/genX_cmd_buffer.c +++

[Mesa-dev] [PATCH v2 03/24] anv/blorp: return early if we failed to create the shader binary

--- src/intel/vulkan/anv_blorp.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c index d79c5e0..c871f03 100644 --- a/src/intel/vulkan/anv_blorp.c +++ b/src/intel/vulkan/anv_blorp.c @@ -72,6 +72,9 @@ upload_blorp_shader(struct

[Mesa-dev] [PATCH v2 16/24] anv: handle memory allocation errors during queue submissions

--- src/intel/vulkan/anv_batch_chain.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/src/intel/vulkan/anv_batch_chain.c b/src/intel/vulkan/anv_batch_chain.c index 2add5bd..0dc781c 100644 --- a/src/intel/vulkan/anv_batch_chain.c +++

[Mesa-dev] [PATCH v2 12/24] anv/cmd_buffer: skip vkCmdNextSubpass() for broken command buffers

--- src/intel/vulkan/genX_cmd_buffer.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/intel/vulkan/genX_cmd_buffer.c b/src/intel/vulkan/genX_cmd_buffer.c index 9ae9de1..557893b 100644 --- a/src/intel/vulkan/genX_cmd_buffer.c +++ b/src/intel/vulkan/genX_cmd_buffer.c @@ -2489,6 +2489,9

[Mesa-dev] [PATCH v2 22/24] anv: handle errors while allocating new binding table blocks

Also, we had a couple of instances in flush_descriptor_sets() were we were returning a VkResult directly upon error, but the return value of this function is not a VkResult but a uint32_t dirty mask, so simply return 0 in these cases which reduces the amount of work the driver will do after the

[Mesa-dev] [PATCH v2 24/24] anv: improve error reporting when creating pipelines

Specifically, report 'out of memory' errors that might have happened while emitting the pipeline's batch. --- src/intel/vulkan/anv_pipeline.c | 1 + src/intel/vulkan/genX_pipeline.c | 5 +++-- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/src/intel/vulkan/anv_pipeline.c

[Mesa-dev] [PATCH v2 10/24] anv: handle failures when growing reloc lists

Growing the reloc list happens through calling anv_reloc_list_add() or anv_reloc_list_append(). Make sure that we call these through helpers that check the result and set the batch error status if needed. v2: - Handling the crashes is not good enough, we need to keep track of the error, for

[Mesa-dev] [PATCH v2 13/24] anv/cmd_buffer: skip vkCmdEndRenderPass() for broken command buffers

--- src/intel/vulkan/genX_cmd_buffer.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/intel/vulkan/genX_cmd_buffer.c b/src/intel/vulkan/genX_cmd_buffer.c index 557893b..efb271e 100644 --- a/src/intel/vulkan/genX_cmd_buffer.c +++ b/src/intel/vulkan/genX_cmd_buffer.c @@ -2508,6 +2508,9

[Mesa-dev] [PATCH v2 06/24] anv: add anv_batch_set_error() and anv_batch_has_error() helpers

The anv_batch_set_error() helper will track the first error that happened while recording a command buffer. The helper returns the currently tracked error to help the job of internal functions that may generate errors that need to be tracked and return a VkResult to the caller. We will use the

[Mesa-dev] [PATCH v2 18/24] anv/cmd_buffer: skip vkCmdDispatch() on broken command buffers

--- src/intel/vulkan/genX_cmd_buffer.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/intel/vulkan/genX_cmd_buffer.c b/src/intel/vulkan/genX_cmd_buffer.c index 112239c..b3f1009 100644 --- a/src/intel/vulkan/genX_cmd_buffer.c +++ b/src/intel/vulkan/genX_cmd_buffer.c @@ -1933,6 +1933,9

[Mesa-dev] [PATCH v2 02/24] anv: do not try to ref/unref NULL shaders

This situation can happen if we failed to allocate memory for the shader. v2: - We shouldn't see NULL shaders in anv_shader_bin_ref so we should not check for that (Jason). Make sure that callers don't attempt to call this function with a NULL shader and assert that this never happens

[Mesa-dev] [PATCH v2 07/24] anv: handle allocation failure in anv_batch_emit_batch()

Fixes: dEQP-VK.api.out_of_host_memory.cmd_execute_commands --- src/intel/vulkan/anv_batch_chain.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/src/intel/vulkan/anv_batch_chain.c b/src/intel/vulkan/anv_batch_chain.c index 3f6039e..1236001 100644 ---

[Mesa-dev] [PATCH v2 05/24] anv/cmd_buffer: add a status field to anv_batch

The vkCmd*() functions do not report errors, instead, any errors should be reported by the time we call vkEndCommandBuffer(). This means that we need to make the driver robust against incosistent and/or imcomplete command buffer states through the command recording process, particularly, avoid

[Mesa-dev] [PATCH v2 00/24] anv: Handle out of memory situations better

I think this series addresses all the issues raised for v1, except making similar changes to anv_cmd_buffer_alloc_dynamic_state and anv_cmd_buffer_alloc_blorp_binding_table which Jason suggested we should probably do as well, and that I'd like to cover separately from this. The main change from v1

[Mesa-dev] [PATCH v2 08/24] anv: handle allocation failure in anv_batch_emit_dwords()

--- src/intel/vulkan/anv_batch_chain.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/src/intel/vulkan/anv_batch_chain.c b/src/intel/vulkan/anv_batch_chain.c index 1236001..3774172 100644 --- a/src/intel/vulkan/anv_batch_chain.c +++

[Mesa-dev] [PATCH v2 01/24] anv: remove unnecessary function prototype.

The function is defined right after the prototype declaration. Also, the protoype for it is included in anv_genX.h which is included via anv_private.h. --- src/intel/vulkan/genX_blorp_exec.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/src/intel/vulkan/genX_blorp_exec.c

[Mesa-dev] [PATCH v3 0/6] Use drmDevice2 API, take ... final

Hi all, Here is hopefully the final round of using drmDevice2. As a brief reminder - probing devices via drmDevice or directly opening the device node wakes up the device, even if we're not planning to use it. The wakeup in itself, can be very slow in some cases. Note: you _will_ need to

[Mesa-dev] [PATCH v3 3/6] winsys/amdgpu: use drmGetDevice2 API

From: Emil Velikov Analogous to previous commit Signed-off-by: Emil Velikov Reviewed-by: Michel Dänzer Reviewed-by: Marek Olšák Reviewed-by: Eric Engestrom ---

[Mesa-dev] [PATCH v3 6/6] anv: do not open random render node(s)

From: Emil Velikov drmGetDevices2() provides us with enough flexibility to build heuristics upon. Opening a random node on the other hand will wake up the device, regardless if it's the one we're interested or not. v2: Rebase, explicitly require/check for libdrm v3:

[Mesa-dev] [PATCH v3 5/6] radv: do not open random render node(s)

From: Emil Velikov drmGetDevices2() provides us with enough flexibility to build heuristics upon. Opening a random node on the other hand will wake up the device, regardless if it's the one we're interested or not. v2: Rebase. v3: Return VK_ERROR_INCOMPATIBLE_DRIVER

[Mesa-dev] [PATCH v3 4/6] radv/winsys: use drmGetDevice2 API

From: Emil Velikov Analogous to previous commit Cc: Dave Airlie Signed-off-by: Emil Velikov Reviewed-by: Michel Dänzer Reviewed-by: Bas Nieuwenhuizen Reviewed-by:

[Mesa-dev] [PATCH v3 2/6] loader: use drmGetDevice[s]2 API

From: Emil Velikov By this allows us to fetch the device list/info w/o the revision field. At the moment retrieving the latter wakes up the device. Note: kernel patch to resolve that should be in 4.10. Signed-off-by: Emil Velikov

[Mesa-dev] [PATCH v3 1/6] autoconf/scons: bump libdrm to 2.4.75

From: Emil Velikov We'll be using the drmGetDevice[s]2 API in src/loader with next patch. v2: Rebase. Signed-off-by: Emil Velikov Reviewed-by: Michel Dänzer (v1) Reviewed-by: Eric Engestrom

Re: [Mesa-dev] [PATCH] util/disk_cache: fix zlib linking with LTO build

On 9 March 2017 at 14:39, Steven Newbury wrote: > Introduction of zlib compression for the shader cache means > zlib needs to be explicitly linked to libOSMesa and libstandalone > otherwise build fails when LTO is used. > --- How exactly are you doing the LTO build ? The

Re: [Mesa-dev] [PATCH] util/disk_cache: fix zlib linking with LTO build

Acked-by: Marek Olšák Marek On Thu, Mar 9, 2017 at 3:39 PM, Steven Newbury wrote: > Introduction of zlib compression for the shader cache means > zlib needs to be explicitly linked to libOSMesa and libstandalone > otherwise build fails when LTO is

Re: [Mesa-dev] RFC Thread queue for shader cache compression/writes (real)

I'm seeing patches I've already reviewed in the previous extended series (e.g. 1/8) and later ones show up multiple times (e.g. there are two patches for 5/8), so I don't know what to review. Can you send the whole thing again. Thanks. Marek On Fri, Mar 10, 2017 at 3:28 AM, Timothy Arceri

Re: [Mesa-dev] [PATCH 2/2] glsl: don't recompile a shader on fallback unless needed

For the series: Acked-by: Marek Olšák Does this fix the crash when GLSL gets a cache hit and st/mesa gets a cache miss? Marek On Thu, Mar 9, 2017 at 1:42 PM, Timothy Arceri wrote: > On 09/03/17 22:58, Timothy Arceri wrote: >> >> Because we

Re: [Mesa-dev] [PATCH 3/3] gbm: Export a get modifiers

Hi Ben, Just a minor nitpick below. On 10 March 2017 at 01:49, Ben Widawsky wrote: > This patch originally had i965 specific code and was named: > commit 61cd3c52b868cf8cb90b06e53a382a921eb42754 > Author: Ben Widawsky > Date: Thu Oct 20 18:21:24 2016

Re: [Mesa-dev] [PATCH 2/3] gbm: Introduce modifiers into surface/bo creation

On 10 March 2017 at 01:48, Ben Widawsky wrote: > The idea behind modifiers like this is that the user of GBM will have > some mechanism to query what properties the hardware supports for its BO > or surface. This information is directly passed in (and stored) so that > the DRI

Re: [Mesa-dev] [PATCH 7/4] gallium/util: replace pipe_thread_setname() with u_thread_setname()

For 5-7: Reviewed-by: Marek Olšák Marek On Thu, Mar 9, 2017 at 12:09 AM, Timothy Arceri wrote: > They do the same thing we are just moving the function to be > accessible to all of Mesa. > --- > src/gallium/auxiliary/os/os_thread.h | 12

Re: [Mesa-dev] [PATCH 4/4] gallium/util: move u_queue.{c, h} to src/util

On Fri, Mar 10, 2017 at 12:00 PM, Mike Lothian wrote: > Does that include patches 5, 6 & 7? I replied on the other patches separately. Marek > > On Fri, 10 Mar 2017 at 10:57 Marek Olšák wrote: >> >> For the series: >> >> Reviewed-by: Marek Olšák

Re: [Mesa-dev] [Mesa-stable] [PATCH] st/mesa: set result writemask based on ir type

Reviewed-by: Marek Olšák Marek On Sat, Mar 4, 2017 at 7:52 PM, Ilia Mirkin wrote: > This prevents textureQueryLevels, which maps as LODQ, from ending up > with a xyzw writemask, which is illegal. > > Bugzilla:

Re: [Mesa-dev] [PATCH 4/4] gallium/util: move u_queue.{c, h} to src/util

Does that include patches 5, 6 & 7? On Fri, 10 Mar 2017 at 10:57 Marek Olšák wrote: > For the series: > > Reviewed-by: Marek Olšák > > Marek > > On Wed, Mar 8, 2017 at 5:36 AM, Timothy Arceri > wrote: > > This will allow us to use

Re: [Mesa-dev] [PATCH 4/4] gallium/util: move u_queue.{c, h} to src/util

For the series: Reviewed-by: Marek Olšák Marek On Wed, Mar 8, 2017 at 5:36 AM, Timothy Arceri wrote: > This will allow us to use it outside of gallium for things like > compressing shader cache entries. > --- >

Re: [Mesa-dev] [PATCH 4/4] gallium/util: move u_string.h to src/util/u_string.h

For the series: Reviewed-by: Marek Olšák Marek On Wed, Mar 8, 2017 at 4:36 AM, Timothy Arceri wrote: > This will help use move u_queue.c here eventually and also provide > string function wrappers for anyone wishing to port disk_cache.c > to

Re: [Mesa-dev] [PATCH 13/25] mesa: Connect the generated GL command marshalling code to the build.

BTW I don't think that supporting GL compat contexts is worth it. Marek On Tue, Mar 7, 2017 at 7:21 AM, Timothy Arceri wrote: > From: Eric Anholt > > v2: Rebase on the Begin/End changes, and just disable this feature on > non-GL-core. > v3: (Timothy

Re: [Mesa-dev] [PATCH 1/3] util/disk_cache: use LRU eviction rather than random eviction (v2)

On Fri, Mar 10, 2017 at 6:23 AM, Timothy Arceri wrote: > On 07/03/17 12:25, Alan Swanson wrote: >> >> Still using random selection of two-character subdirectory in which >> to check cache files rather than scanning entire cache. >> >> v2: Factor out double strlen call >>

  1   2   >