Re: [Mesa-dev] [PATCH 14/14] anv: Implement VK_ANDROID_native_buffer (v8)

[Jason Ekstrand]

I will review these eventually


On September 27, 2017 8:14:25 PM Chad Versace  wrote:


This implementation is correct (afaict), but takes two shortcuts
regarding the import/export of Android sync fds.

  Shortcut 1. When Android calls vkAcquireImageANDROID to import a sync
  fd into a VkSemaphore or VkFence, the driver instead simply blocks on
  the sync fd, then puts the VkSemaphore or VkFence into the signalled
  state. Thanks to implicit sync, this produces correct behavior (with
  extra latency overhead, perhaps) despite its ugliness.

  Shortcut 2. When Android calls vkQueueSignalReleaseImageANDROID to export
  a collection of wait semaphores as a sync fd, the driver instead
  submits the semaphores to the queue, then returns sync fd -1, which
  informs the caller that no additional synchronization is needed.
  Again, thanks to implicit sync, this produces correct behavior (with
  extra batch submission overhead) despite its ugliness.

I chose to take the shortcuts instead of properly importing/exporting
the sync fds for two reasons:

  Reason 1. I've already tested this patch with dEQP and with demos
  apps. It works. I wanted to get the tested patches into the tree now,
  and polish the implementation afterwards.

  Reason 2. I want to run this on a 3.18 kernel (gasp!). In 3.18, i915
  supports neither Android's sync_fence, nor upstream's sync_file, nor
  drm_syncobj. Again, I tested these patches on Android with a 3.18
  kernel and they work.

I plan to quickly follow-up with patches that remove the shortcuts and
properly import/export the sync fds.

Non-Testing
===
I did not test at all using the Android.mk buildsystem. I probably
broke it. Please test and review that.

Testing
===
I tested with 64-bit ARC++ on a Skylake Chromebook and a 3.18 kernel.
The following pass (as of patchset v7):

  a little spinning cube demo APK
  dEQP-VK.info.*
  dEQP-VK.api.smoke.*
  dEQP-VK.api.info.instance.*
  dEQP-VK.api.info.device.*
  dEQP-VK.api.wsi.android.*
except dEQP-VK.api.wsi.android.swapchain.*.image_usage, because
dEQP wants to create swapchains with VK_IMAGE_USAGE_STORAGE_BIT.

v2:
  - Reject VkNativeBufferANDROID if the dma-buf's size is too small for
the VkImage.
  - Stop abusing VkNativeBufferANDROID by passing it to vkAllocateMemory
during vkCreateImage. Instead, directly import its dma-buf during
vkCreateImage with anv_bo_cache_import(). [for jekstrand]
  - Rebase onto Tapani's VK_EXT_debug_report changes.
  - Drop `CPPFLAGS += $(top_srcdir)/include/android`. The dir does not
exist.

v3:
  - Delete duplicate #include "anv_private.h". [per Tapani]
  - Try to fix the Android-IA build in Android.vulkan.mk by following
Tapani's example.

v4:
  - Unset EXEC_OBJECT_ASYNC and set EXEC_OBJECT_WRITE on the imported
gralloc buffer, just as we do for all other winsys buffers in
anv_wsi.c. [found by Tapani]

v5:
  - Really fix the Android-IA build by ensuring that Android.vulkan.mk
uses Mesa' vulkan.h and not Android's.  Insert -I$(MESA_TOP)/include
before -Iframeworks/native/vulkan/include. [for Tapani]
  - In vkAcquireImageANDROID, submit signal operations to the
VkSemaphore and VkFence. [for zhou]

v6:
  - Drop copy-paste duplication in vkGetSwapchainGrallocUsageANDROID().
[found by zhou]
  - Improve comments in vkGetSwapchainGrallocUsageANDROID().

v7:
  - Fix vkGetSwapchainGrallocUsageANDROID() to inspect its
VkImageUsageFlags parameter. [for tfiga]
  - This fix regresses dEQP-VK.api.wsi.android.swapchain.*.image_usage
because dEQP wants to create swapchains with
VK_IMAGE_USAGE_STORAGE_BIT.

v8:
  - Drop unneeded goto in vkAcquireImageANDROID. [for tfiga]

Reviewed-by: Tapani Pälli  (v5)
Cc: Jason Ekstrand 
Cc: zhoucm1 
Cc: Tomasz Figa 
---
 src/intel/Android.vulkan.mk |   7 +-
 src/intel/Makefile.sources  |   3 +
 src/intel/Makefile.vulkan.am|   2 +
 src/intel/vulkan/anv_android.c  | 300 
 src/intel/vulkan/anv_device.c   |  12 +-
 src/intel/vulkan/anv_entrypoints_gen.py |  10 +-
 src/intel/vulkan/anv_extensions.py  |   1 +
 src/intel/vulkan/anv_image.c| 147 ++--
 src/intel/vulkan/anv_private.h  |   1 +
 9 files changed, 469 insertions(+), 14 deletions(-)
 create mode 100644 src/intel/vulkan/anv_android.c

diff --git a/src/intel/Android.vulkan.mk b/src/intel/Android.vulkan.mk
index e20b32b87c5..b2d7d4e46c5 100644
--- a/src/intel/Android.vulkan.mk
+++ b/src/intel/Android.vulkan.mk
@@ -28,6 +28,7 @@ VK_ENTRYPOINTS_SCRIPT := $(MESA_PYTHON2) 
$(LOCAL_PATH)/vulkan/anv_entrypoints_ge

 VK_EXTENSIONS_SCRIPT := $(MESA_PYTHON2) $(LOCAL_PATH)/vulkan/anv_extensions.py

 VULKAN_COMMON_INCLUDES := \
+   $(MESA_TOP)/include \
$(MESA_TOP)/src/mapi \
$(MESA_TOP)/src/gallium/auxiliary \

Re: [Mesa-dev] XDC 2017 feedback

[Ian Romanick]

On 09/27/2017 10:07 PM, Rob Clark wrote:
> On Wed, Sep 27, 2017 at 10:49 PM, Ian Romanick  wrote:
>> On 09/27/2017 04:55 PM, Rob Clark wrote:
>>> On Wed, Sep 27, 2017 at 7:25 PM, Ian Romanick  wrote:
 On 09/26/2017 09:57 AM, Daniel Vetter wrote:
> Hi all,
>
> First again big thanks to Stéphane and Jennifer for organizing a great 
> XDC.
>
> Like last year we'd like to hear feedback on how this year's XDC went,
> both the good (and what you'd like to see more of) and the not so
> good. Talk selection, organization, location, scheduling of talks,
> anything really.

 Not scheduling it to conflict with another industry event would be a
 good start.  This is the first XDC that I've missed in nearly a decade.
 I know I'm not the only person that missed one or the other due to
 scheduling fail.
>>>
>>> Sadly by the time we were aware of the dates for the khronos f2f it
>>> was not possible to change the dates for XDC :-(
>>>
>>> The XDC dates were set in Feb, and afaict the khronos dates were
>>> announced in July (?), so take this up with khronos ;-)
>>
>> Ok... so we're going to go there.
>>
>> Frankly, that's a giant steaming load of bull.  Blocks of hotel rooms,
>> multiple conference rooms for 500+ people, and catering for the Khronos
>> meeting was booked in late 2016.  We're already working on contracts for
>> the September 2018 meeting.  Contracts of this scale are really hard to
>> change.  There are 5x to 10x as many people at a Khronos face-to-face as
>> at XDC.  Events of that scale have a massively deep pipeline.
>>
>> Google was just unwilling to find a different dates for space *at their
>> own campus*.  That's really, really weak.  This is especially
>> infuriating because there are numerous Googlers who attend the Khronos
>> meetings.  Did the organizers poll any of them?  The XDC organizers
>> clearly did not even exercise due diligence to detect a possible
>> conflict.  If the organizers had cared to be aware of dates of
>> conflicting events, they would have known.
> 
> I have no doubt there is a long lead time on organizing large conf's..
> I wasn't calling that into question.  The July date was based on a
> quick search of my khr emails.  I couldn't find any earlier reference
> to dates, but I could have missed something.
> 
> If you had known of the khr dates, and brought it up in Feb (or really
> somewhat earlier, given that XDC is roughly same time each year +/-
> few weeks), that *might* have been early enough to move things.  But
> IIRC there wasn't much flexibility in booking such a large room from
> the google side either.  Plus also trying to fit around LPC/etc..
> Khronos isn't the only other conference to avoid.  Once the XDC date
> is announced and people have begun booking travel, we can't really
> move things.  Sorry, it sucks, I wasn't happy about it either, but it
> is what it is.  As far as other conferences that XDC attendees are
> likely to go to, and given the turn-out (by far largest XDC in NA), I
> think the dates worked out reasonably well overall.

The point of my original post wasn't to start a big to-do.  My point was
just that future organizers should be more careful.

Once school starts in September, other conferences stop.  I had always
assumed that was part of the reason XDC was scheduled the way that it
was scheduled.  There are basically two events from mid-September to
early October to avoid: LPC / kernel summit and Khronos meetings.  At
least as far back as 2008, XDC had always been able to avoid both.
Hopefully that long run will be repeated and improved.

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

Re: [Mesa-dev] XDC 2017 feedback

[Daniel Vetter]

On Thu, Sep 28, 2017 at 7:36 AM, Matt Turner  wrote:
> On Wed, Sep 27, 2017 at 10:07 PM, Rob Clark  wrote:
>> If you had known of the khr dates, and brought it up in Feb (or really
>> somewhat earlier, given that XDC is roughly same time each year +/-
>> few weeks), that *might* have been early enough to move things.
>
> That's unfair. It's part of the X.Org board's responsibilities to plan
> conferences and that means being aware of potential conflicts. In
> February, six of the eight members of the X.Org board worked for
> companies with Khronos access (that's not including Keith who I
> suspect has access as well).
>
> I replied to the 2017-03-02 minutes and noted the conflict, but as you
> say that was too late. Unfortunately that was the first time a date
> was publicly announced, so I'm not really sure what could have been
> done from outside the X.Org board.

I don't remember all the details anymore, but we have plumbers right
before, and Linaro connect right afterwards, both conferences that
also have considerable overlap with XDC (we have a lot more than x86
folks since 2-3 years now). Bunch of people decided not to do XDC this
year even, because too much travelling in one row. Plus Google's limit
in scheduling a room, plus Khr f2f. We'll try to do better next year,
but sometimes perfect scheduling is just not an option.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] meson: remove duplicate libisl dependency in anv

[Tapani Pälli]

Reviewed-by: Tapani Pälli 

On 09/28/2017 02:26 AM, Dylan Baker wrote:

Signed-off-by: Dylan Baker 
CC: Kristian Høgsberg 
---
  src/intel/vulkan/meson.build | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/vulkan/meson.build b/src/intel/vulkan/meson.build
index 9f0ee558e8a..a0be95c747c 100644
--- a/src/intel/vulkan/meson.build
+++ b/src/intel/vulkan/meson.build
@@ -144,7 +144,7 @@ libvulkan_intel = shared_library(
include_directories : [inc_common, inc_intel, inc_compiler, inc_drm_uapi,
   inc_vulkan_util, inc_vulkan_wsi],
link_whole : [libanv_common, libanv_gen_libs],
-  link_with : [libintel_compiler, libintel_common, libisl, libisl, libblorp,
+  link_with : [libintel_compiler, libintel_common, libisl, libblorp,
 libvulkan_util, libvulkan_wsi, libnir, libmesa_util],
dependencies : [dep_libdrm, dep_thread, dep_dl, dep_m, anv_deps, 
dep_valgrind],
c_args : [c_vis_args, no_override_init_args, '-msse2', anv_flags],


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

Re: [Mesa-dev] XDC 2017 feedback

[Matt Turner]

On Wed, Sep 27, 2017 at 10:07 PM, Rob Clark  wrote:
> If you had known of the khr dates, and brought it up in Feb (or really
> somewhat earlier, given that XDC is roughly same time each year +/-
> few weeks), that *might* have been early enough to move things.

That's unfair. It's part of the X.Org board's responsibilities to plan
conferences and that means being aware of potential conflicts. In
February, six of the eight members of the X.Org board worked for
companies with Khronos access (that's not including Keith who I
suspect has access as well).

I replied to the 2017-03-02 minutes and noted the conflict, but as you
say that was too late. Unfortunately that was the first time a date
was publicly announced, so I'm not really sure what could have been
done from outside the X.Org board.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] XDC 2017 feedback

[Rob Clark]

On Wed, Sep 27, 2017 at 10:49 PM, Ian Romanick  wrote:
> On 09/27/2017 04:55 PM, Rob Clark wrote:
>> On Wed, Sep 27, 2017 at 7:25 PM, Ian Romanick  wrote:
>>> On 09/26/2017 09:57 AM, Daniel Vetter wrote:
 Hi all,

 First again big thanks to Stéphane and Jennifer for organizing a great XDC.

 Like last year we'd like to hear feedback on how this year's XDC went,
 both the good (and what you'd like to see more of) and the not so
 good. Talk selection, organization, location, scheduling of talks,
 anything really.
>>>
>>> Not scheduling it to conflict with another industry event would be a
>>> good start.  This is the first XDC that I've missed in nearly a decade.
>>> I know I'm not the only person that missed one or the other due to
>>> scheduling fail.
>>
>> Sadly by the time we were aware of the dates for the khronos f2f it
>> was not possible to change the dates for XDC :-(
>>
>> The XDC dates were set in Feb, and afaict the khronos dates were
>> announced in July (?), so take this up with khronos ;-)
>
> Ok... so we're going to go there.
>
> Frankly, that's a giant steaming load of bull.  Blocks of hotel rooms,
> multiple conference rooms for 500+ people, and catering for the Khronos
> meeting was booked in late 2016.  We're already working on contracts for
> the September 2018 meeting.  Contracts of this scale are really hard to
> change.  There are 5x to 10x as many people at a Khronos face-to-face as
> at XDC.  Events of that scale have a massively deep pipeline.
>
> Google was just unwilling to find a different dates for space *at their
> own campus*.  That's really, really weak.  This is especially
> infuriating because there are numerous Googlers who attend the Khronos
> meetings.  Did the organizers poll any of them?  The XDC organizers
> clearly did not even exercise due diligence to detect a possible
> conflict.  If the organizers had cared to be aware of dates of
> conflicting events, they would have known.

I have no doubt there is a long lead time on organizing large conf's..
I wasn't calling that into question.  The July date was based on a
quick search of my khr emails.  I couldn't find any earlier reference
to dates, but I could have missed something.

If you had known of the khr dates, and brought it up in Feb (or really
somewhat earlier, given that XDC is roughly same time each year +/-
few weeks), that *might* have been early enough to move things.  But
IIRC there wasn't much flexibility in booking such a large room from
the google side either.  Plus also trying to fit around LPC/etc..
Khronos isn't the only other conference to avoid.  Once the XDC date
is announced and people have begun booking travel, we can't really
move things.  Sorry, it sucks, I wasn't happy about it either, but it
is what it is.  As far as other conferences that XDC attendees are
likely to go to, and given the turn-out (by far largest XDC in NA), I
think the dates worked out reasonably well overall.

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

Re: [Mesa-dev] [PATCH] mesa: fix texture updates for ATI_fragment_shader

[Kenneth Graunke]

On Wednesday, September 27, 2017 8:39:27 AM PDT Marek Olšák wrote:
> From: Marek Olšák 
> 
> ---
>  src/mesa/main/texstate.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/src/mesa/main/texstate.c b/src/mesa/main/texstate.c
> index 269e291..edd2253 100644
> --- a/src/mesa/main/texstate.c
> +++ b/src/mesa/main/texstate.c
> @@ -833,23 +833,25 @@ update_ff_texture_state(struct gl_context *ctx,
>  void
>  _mesa_update_texture_state(struct gl_context *ctx)
>  {
> struct gl_program *prog[MESA_SHADER_STAGES];
> int i;
> int old_max_unit = ctx->Texture._MaxEnabledTexImageUnit;
> BITSET_DECLARE(enabled_texture_units, MAX_COMBINED_TEXTURE_IMAGE_UNITS);
>  
> memcpy(prog, ctx->_Shader->CurrentProgram, sizeof(prog));
>  
> -   if (prog[MESA_SHADER_FRAGMENT] == NULL &&
> -   _mesa_arb_fragment_program_enabled(ctx)) {
> -  prog[MESA_SHADER_FRAGMENT] = ctx->FragmentProgram.Current;
> +   if (prog[MESA_SHADER_FRAGMENT] == NULL) {
> +  if (_mesa_arb_fragment_program_enabled(ctx))
> + prog[MESA_SHADER_FRAGMENT] = ctx->FragmentProgram.Current;
> +  else if (_mesa_ati_fragment_shader_enabled(ctx))
> + prog[MESA_SHADER_FRAGMENT] = 
> ctx->ATIFragmentShader.Current->Program;
> }
>  
> /* TODO: only set this if there are actual changes */
> ctx->NewState |= _NEW_TEXTURE_OBJECT | _NEW_TEXTURE_STATE;
>  
> ctx->Texture._GenFlags = 0x0;
> ctx->Texture._TexMatEnabled = 0x0;
> ctx->Texture._TexGenEnabled = 0x0;
> ctx->Texture._MaxEnabledTexImageUnit = -1;
> ctx->Texture._EnabledCoordUnits = 0x0;
> 

Reviewed-by: Kenneth Graunke 


signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 14/14] anv: Implement VK_ANDROID_native_buffer (v8)

[Chad Versace]

This implementation is correct (afaict), but takes two shortcuts
regarding the import/export of Android sync fds.

  Shortcut 1. When Android calls vkAcquireImageANDROID to import a sync
  fd into a VkSemaphore or VkFence, the driver instead simply blocks on
  the sync fd, then puts the VkSemaphore or VkFence into the signalled
  state. Thanks to implicit sync, this produces correct behavior (with
  extra latency overhead, perhaps) despite its ugliness.

  Shortcut 2. When Android calls vkQueueSignalReleaseImageANDROID to export
  a collection of wait semaphores as a sync fd, the driver instead
  submits the semaphores to the queue, then returns sync fd -1, which
  informs the caller that no additional synchronization is needed.
  Again, thanks to implicit sync, this produces correct behavior (with
  extra batch submission overhead) despite its ugliness.

I chose to take the shortcuts instead of properly importing/exporting
the sync fds for two reasons:

  Reason 1. I've already tested this patch with dEQP and with demos
  apps. It works. I wanted to get the tested patches into the tree now,
  and polish the implementation afterwards.

  Reason 2. I want to run this on a 3.18 kernel (gasp!). In 3.18, i915
  supports neither Android's sync_fence, nor upstream's sync_file, nor
  drm_syncobj. Again, I tested these patches on Android with a 3.18
  kernel and they work.

I plan to quickly follow-up with patches that remove the shortcuts and
properly import/export the sync fds.

Non-Testing
===
I did not test at all using the Android.mk buildsystem. I probably
broke it. Please test and review that.

Testing
===
I tested with 64-bit ARC++ on a Skylake Chromebook and a 3.18 kernel.
The following pass (as of patchset v7):

  a little spinning cube demo APK
  dEQP-VK.info.*
  dEQP-VK.api.smoke.*
  dEQP-VK.api.info.instance.*
  dEQP-VK.api.info.device.*
  dEQP-VK.api.wsi.android.*
except dEQP-VK.api.wsi.android.swapchain.*.image_usage, because
dEQP wants to create swapchains with VK_IMAGE_USAGE_STORAGE_BIT.

v2:
  - Reject VkNativeBufferANDROID if the dma-buf's size is too small for
the VkImage.
  - Stop abusing VkNativeBufferANDROID by passing it to vkAllocateMemory
during vkCreateImage. Instead, directly import its dma-buf during
vkCreateImage with anv_bo_cache_import(). [for jekstrand]
  - Rebase onto Tapani's VK_EXT_debug_report changes.
  - Drop `CPPFLAGS += $(top_srcdir)/include/android`. The dir does not
exist.

v3:
  - Delete duplicate #include "anv_private.h". [per Tapani]
  - Try to fix the Android-IA build in Android.vulkan.mk by following
Tapani's example.

v4:
  - Unset EXEC_OBJECT_ASYNC and set EXEC_OBJECT_WRITE on the imported
gralloc buffer, just as we do for all other winsys buffers in
anv_wsi.c. [found by Tapani]

v5:
  - Really fix the Android-IA build by ensuring that Android.vulkan.mk
uses Mesa' vulkan.h and not Android's.  Insert -I$(MESA_TOP)/include
before -Iframeworks/native/vulkan/include. [for Tapani]
  - In vkAcquireImageANDROID, submit signal operations to the
VkSemaphore and VkFence. [for zhou]

v6:
  - Drop copy-paste duplication in vkGetSwapchainGrallocUsageANDROID().
[found by zhou]
  - Improve comments in vkGetSwapchainGrallocUsageANDROID().

v7:
  - Fix vkGetSwapchainGrallocUsageANDROID() to inspect its
VkImageUsageFlags parameter. [for tfiga]
  - This fix regresses dEQP-VK.api.wsi.android.swapchain.*.image_usage
because dEQP wants to create swapchains with
VK_IMAGE_USAGE_STORAGE_BIT.

v8:
  - Drop unneeded goto in vkAcquireImageANDROID. [for tfiga]

Reviewed-by: Tapani Pälli  (v5)
Cc: Jason Ekstrand 
Cc: zhoucm1 
Cc: Tomasz Figa 
---
 src/intel/Android.vulkan.mk |   7 +-
 src/intel/Makefile.sources  |   3 +
 src/intel/Makefile.vulkan.am|   2 +
 src/intel/vulkan/anv_android.c  | 300 
 src/intel/vulkan/anv_device.c   |  12 +-
 src/intel/vulkan/anv_entrypoints_gen.py |  10 +-
 src/intel/vulkan/anv_extensions.py  |   1 +
 src/intel/vulkan/anv_image.c| 147 ++--
 src/intel/vulkan/anv_private.h  |   1 +
 9 files changed, 469 insertions(+), 14 deletions(-)
 create mode 100644 src/intel/vulkan/anv_android.c

diff --git a/src/intel/Android.vulkan.mk b/src/intel/Android.vulkan.mk
index e20b32b87c5..b2d7d4e46c5 100644
--- a/src/intel/Android.vulkan.mk
+++ b/src/intel/Android.vulkan.mk
@@ -28,6 +28,7 @@ VK_ENTRYPOINTS_SCRIPT := $(MESA_PYTHON2) 
$(LOCAL_PATH)/vulkan/anv_entrypoints_ge
 VK_EXTENSIONS_SCRIPT := $(MESA_PYTHON2) $(LOCAL_PATH)/vulkan/anv_extensions.py
 
 VULKAN_COMMON_INCLUDES := \
+   $(MESA_TOP)/include \
$(MESA_TOP)/src/mapi \
$(MESA_TOP)/src/gallium/auxiliary \
$(MESA_TOP)/src/gallium/include \
@@ -36,7 +37,8 @@ VULKAN_COMMON_INCLUDES := \

Re: [Mesa-dev] [PATCH] mesa: fix texture updates for ATI_fragment_shader

[Ian Romanick]

On 09/27/2017 05:06 PM, Marek Olšák wrote:
> It fixes a crash with an apitrace that I have. Other than that, no
> tests. Yes, it should be tagged for stable.

Ok.  Adding a test would be cool, but I won't bust your chops. :)

Reviewed-by: Ian Romanick 

> Marek
> 
> On Thu, Sep 28, 2017 at 1:34 AM, Ian Romanick  wrote:
>> This looks right... at least it makes ATI_fragment_shader behave like
>> ARB_fragment_program.  I don't suppose there are any tests that exercise
>> this problem?  Should this be tagged for stable?
>>
>> On 09/27/2017 08:39 AM, Marek Olšák wrote:
>>> From: Marek Olšák 
>>>
>>> ---
>>>  src/mesa/main/texstate.c | 8 +---
>>>  1 file changed, 5 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/src/mesa/main/texstate.c b/src/mesa/main/texstate.c
>>> index 269e291..edd2253 100644
>>> --- a/src/mesa/main/texstate.c
>>> +++ b/src/mesa/main/texstate.c
>>> @@ -833,23 +833,25 @@ update_ff_texture_state(struct gl_context *ctx,
>>>  void
>>>  _mesa_update_texture_state(struct gl_context *ctx)
>>>  {
>>> struct gl_program *prog[MESA_SHADER_STAGES];
>>> int i;
>>> int old_max_unit = ctx->Texture._MaxEnabledTexImageUnit;
>>> BITSET_DECLARE(enabled_texture_units, MAX_COMBINED_TEXTURE_IMAGE_UNITS);
>>>
>>> memcpy(prog, ctx->_Shader->CurrentProgram, sizeof(prog));
>>>
>>> -   if (prog[MESA_SHADER_FRAGMENT] == NULL &&
>>> -   _mesa_arb_fragment_program_enabled(ctx)) {
>>> -  prog[MESA_SHADER_FRAGMENT] = ctx->FragmentProgram.Current;
>>> +   if (prog[MESA_SHADER_FRAGMENT] == NULL) {
>>> +  if (_mesa_arb_fragment_program_enabled(ctx))
>>> + prog[MESA_SHADER_FRAGMENT] = ctx->FragmentProgram.Current;
>>> +  else if (_mesa_ati_fragment_shader_enabled(ctx))
>>> + prog[MESA_SHADER_FRAGMENT] = 
>>> ctx->ATIFragmentShader.Current->Program;
>>> }
>>>
>>> /* TODO: only set this if there are actual changes */
>>> ctx->NewState |= _NEW_TEXTURE_OBJECT | _NEW_TEXTURE_STATE;
>>>
>>> ctx->Texture._GenFlags = 0x0;
>>> ctx->Texture._TexMatEnabled = 0x0;
>>> ctx->Texture._TexGenEnabled = 0x0;
>>> ctx->Texture._MaxEnabledTexImageUnit = -1;
>>> ctx->Texture._EnabledCoordUnits = 0x0;
>>>
>>
> 

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

Re: [Mesa-dev] XDC 2017 feedback

[Ian Romanick]

On 09/27/2017 04:55 PM, Rob Clark wrote:
> On Wed, Sep 27, 2017 at 7:25 PM, Ian Romanick  wrote:
>> On 09/26/2017 09:57 AM, Daniel Vetter wrote:
>>> Hi all,
>>>
>>> First again big thanks to Stéphane and Jennifer for organizing a great XDC.
>>>
>>> Like last year we'd like to hear feedback on how this year's XDC went,
>>> both the good (and what you'd like to see more of) and the not so
>>> good. Talk selection, organization, location, scheduling of talks,
>>> anything really.
>>
>> Not scheduling it to conflict with another industry event would be a
>> good start.  This is the first XDC that I've missed in nearly a decade.
>> I know I'm not the only person that missed one or the other due to
>> scheduling fail.
> 
> Sadly by the time we were aware of the dates for the khronos f2f it
> was not possible to change the dates for XDC :-(
> 
> The XDC dates were set in Feb, and afaict the khronos dates were
> announced in July (?), so take this up with khronos ;-)

Ok... so we're going to go there.

Frankly, that's a giant steaming load of bull.  Blocks of hotel rooms,
multiple conference rooms for 500+ people, and catering for the Khronos
meeting was booked in late 2016.  We're already working on contracts for
the September 2018 meeting.  Contracts of this scale are really hard to
change.  There are 5x to 10x as many people at a Khronos face-to-face as
at XDC.  Events of that scale have a massively deep pipeline.

Google was just unwilling to find a different dates for space *at their
own campus*.  That's really, really weak.  This is especially
infuriating because there are numerous Googlers who attend the Khronos
meetings.  Did the organizers poll any of them?  The XDC organizers
clearly did not even exercise due diligence to detect a possible
conflict.  If the organizers had cared to be aware of dates of
conflicting events, they would have known.

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

[Mesa-dev] [PATCH] anv: Implement VK_ANDROID_native_buffer (v7)

[Chad Versace]

This implementation is correct (afaict), but takes two shortcuts
regarding the import/export of Android sync fds.

  Shortcut 1. When Android calls vkAcquireImageANDROID to import a sync
  fd into a VkSemaphore or VkFence, the driver instead simply blocks on
  the sync fd, then puts the VkSemaphore or VkFence into the signalled
  state. Thanks to implicit sync, this produces correct behavior (with
  extra latency overhead, perhaps) despite its ugliness.

  Shortcut 2. When Android calls vkQueueSignalReleaseImageANDROID to export
  a collection of wait semaphores as a sync fd, the driver instead
  submits the semaphores to the queue, then returns sync fd -1, which
  informs the caller that no additional synchronization is needed.
  Again, thanks to implicit sync, this produces correct behavior (with
  extra batch submission overhead) despite its ugliness.

I chose to take the shortcuts instead of properly importing/exporting
the sync fds for two reasons:

  Reason 1. I've already tested this patch with dEQP and with demos
  apps. It works. I wanted to get the tested patches into the tree now,
  and polish the implementation afterwards.

  Reason 2. I want to run this on a 3.18 kernel (gasp!). In 3.18, i915
  supports neither Android's sync_fence, nor upstream's sync_file, nor
  drm_syncobj. Again, I tested these patches on Android with a 3.18
  kernel and they work.

I plan to quickly follow-up with patches that remove the shortcuts and
properly import/export the sync fds.

Non-Testing
===
I did not test at all using the Android.mk buildsystem. I probably
broke it. Please test and review that.

Testing
===
I tested with 64-bit ARC++ on a Skylake Chromebook and a 3.18 kernel.
The following pass (as of patchset v7):

  a little spinning cube demo APK
  dEQP-VK.info.*
  dEQP-VK.api.smoke.*
  dEQP-VK.api.info.instance.*
  dEQP-VK.api.info.device.*
  dEQP-VK.api.wsi.android.*
except dEQP-VK.api.wsi.android.swapchain.*.image_usage, because
dEQP wants to create swapchains with VK_IMAGE_USAGE_STORAGE_BIT.

v2:
  - Reject VkNativeBufferANDROID if the dma-buf's size is too small for
the VkImage.
  - Stop abusing VkNativeBufferANDROID by passing it to vkAllocateMemory
during vkCreateImage. Instead, directly import its dma-buf during
vkCreateImage with anv_bo_cache_import(). [for jekstrand]
  - Rebase onto Tapani's VK_EXT_debug_report changes.
  - Drop `CPPFLAGS += $(top_srcdir)/include/android`. The dir does not
exist.

v3:
  - Delete duplicate #include "anv_private.h". [per Tapani]
  - Try to fix the Android-IA build in Android.vulkan.mk by following
Tapani's example.

v4:
  - Unset EXEC_OBJECT_ASYNC and set EXEC_OBJECT_WRITE on the imported
gralloc buffer, just as we do for all other winsys buffers in
anv_wsi.c. [found by Tapani]

v5:
  - Really fix the Android-IA build by ensuring that Android.vulkan.mk
uses Mesa' vulkan.h and not Android's.  Insert -I$(MESA_TOP)/include
before -Iframeworks/native/vulkan/include. [for Tapani]
  - In vkAcquireImageANDROID, submit signal operations to the
VkSemaphore and VkFence. [for zhou]

v6:
  - Drop copy-paste duplication in vkGetSwapchainGrallocUsageANDROID().
[found by zhou]
  - Improve comments in vkGetSwapchainGrallocUsageANDROID().

v7:
  - Fix vkGetSwapchainGrallocUsageANDROID() to inspect its
VkImageUsageFlags parameter. [for tfiga]
  - This fix regresses dEQP-VK.api.wsi.android.swapchain.*.image_usage
because dEQP wants to create swapchains with
VK_IMAGE_USAGE_STORAGE_BIT.

Reviewed-by: Tapani Pälli  (v5)
Cc: Jason Ekstrand 
Cc: zhoucm1 
Cc: Tomasz Figa 
Cc: Bas Nieuwenhuizen 
---
 src/intel/Android.vulkan.mk |   7 +-
 src/intel/Makefile.sources  |   3 +
 src/intel/Makefile.vulkan.am|   2 +
 src/intel/vulkan/anv_android.c  | 301 
 src/intel/vulkan/anv_device.c   |  12 +-
 src/intel/vulkan/anv_entrypoints_gen.py |  10 +-
 src/intel/vulkan/anv_extensions.py  |   1 +
 src/intel/vulkan/anv_image.c| 147 ++--
 src/intel/vulkan/anv_private.h  |   1 +
 9 files changed, 470 insertions(+), 14 deletions(-)
 create mode 100644 src/intel/vulkan/anv_android.c

diff --git a/src/intel/Android.vulkan.mk b/src/intel/Android.vulkan.mk
index e20b32b87c..b2d7d4e46c 100644
--- a/src/intel/Android.vulkan.mk
+++ b/src/intel/Android.vulkan.mk
@@ -28,6 +28,7 @@ VK_ENTRYPOINTS_SCRIPT := $(MESA_PYTHON2) 
$(LOCAL_PATH)/vulkan/anv_entrypoints_ge
 VK_EXTENSIONS_SCRIPT := $(MESA_PYTHON2) $(LOCAL_PATH)/vulkan/anv_extensions.py
 
 VULKAN_COMMON_INCLUDES := \
+   $(MESA_TOP)/include \
$(MESA_TOP)/src/mapi \
$(MESA_TOP)/src/gallium/auxiliary \
$(MESA_TOP)/src/gallium/include \
@@ -36,7 +37,8 @@ VULKAN_COMMON_INCLUDES := \
$(MESA_TOP)/src/vulkan/util \

[Mesa-dev] [PATCH] gallium: add new LOD opcode

[sroland]

From: Roland Scheidegger 

The operation performed is all the same as LODQ, but with the usual
differences between dx10 and GL texture opcodes, that is separate resource
and sampler indices (plus result swizzling, and setting z/w channels
to zero).
---
 src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c | 14 
 src/gallium/auxiliary/tgsi/tgsi_exec.c  | 48 ++---
 src/gallium/auxiliary/tgsi/tgsi_info_opcodes.h  |  1 +
 src/gallium/docs/source/tgsi.rst| 12 +++
 src/gallium/include/pipe/p_shader_tokens.h  |  4 ++-
 5 files changed, 74 insertions(+), 5 deletions(-)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c 
b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
index 3e47372..fe0068b 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
@@ -3285,6 +3285,18 @@ sviewinfo_emit(
emit_size_query(bld, emit_data->inst, emit_data->output, TRUE);
 }
 
+static void
+lod_emit(
+   const struct lp_build_tgsi_action * action,
+   struct lp_build_tgsi_context * bld_base,
+   struct lp_build_emit_data * emit_data)
+{
+   struct lp_build_tgsi_soa_context * bld = lp_soa_context(bld_base);
+
+   emit_sample(bld, emit_data->inst, LP_BLD_TEX_MODIFIER_NONE,
+   FALSE, LP_SAMPLER_OP_LODQ, emit_data->output);
+}
+
 static LLVMValueRef
 mask_vec(struct lp_build_tgsi_context *bld_base)
 {
@@ -3899,6 +3911,8 @@ lp_build_tgsi_soa(struct gallivm_state *gallivm,
bld.bld_base.op_actions[TGSI_OPCODE_SAMPLE_L].emit = sample_l_emit;
bld.bld_base.op_actions[TGSI_OPCODE_GATHER4].emit = gather4_emit;
bld.bld_base.op_actions[TGSI_OPCODE_SVIEWINFO].emit = sviewinfo_emit;
+   bld.bld_base.op_actions[TGSI_OPCODE_LOD].emit = lod_emit;
+
 
if (gs_iface) {
   /* There's no specific value for this because it should always
diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.c 
b/src/gallium/auxiliary/tgsi/tgsi_exec.c
index 1264df0..4257a60 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_exec.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_exec.c
@@ -2340,15 +2340,22 @@ static void
 exec_lodq(struct tgsi_exec_machine *mach,
   const struct tgsi_full_instruction *inst)
 {
-   uint unit;
+   uint resource_unit, sampler_unit;
int dim;
int i;
union tgsi_exec_channel coords[4];
const union tgsi_exec_channel *args[ARRAY_SIZE(coords)];
union tgsi_exec_channel r[2];
 
-   unit = fetch_sampler_unit(mach, inst, 1);
-   dim = tgsi_util_get_texture_coord_dim(inst->Texture.Texture);
+   resource_unit = fetch_sampler_unit(mach, inst, 1);
+   if (inst->Instruction.Opcode == TGSI_OPCODE_LOD) {
+  uint target = mach->SamplerViews[resource_unit].Resource;
+  dim = tgsi_util_get_texture_coord_dim(target);
+  sampler_unit = fetch_sampler_unit(mach, inst, 2);
+   } else {
+  dim = tgsi_util_get_texture_coord_dim(inst->Texture.Texture);
+  sampler_unit = resource_unit;
+   }
assert(dim <= ARRAY_SIZE(coords));
/* fetch coordinates */
for (i = 0; i < dim; i++) {
@@ -2358,7 +2365,7 @@ exec_lodq(struct tgsi_exec_machine *mach,
for (i = dim; i < ARRAY_SIZE(coords); i++) {
   args[i] = 
}
-   mach->Sampler->query_lod(mach->Sampler, unit, unit,
+   mach->Sampler->query_lod(mach->Sampler, resource_unit, sampler_unit,
 args[0]->f,
 args[1]->f,
 args[2]->f,
@@ -2375,6 +2382,35 @@ exec_lodq(struct tgsi_exec_machine *mach,
   store_dest(mach, [1], >Dst[0], inst, TGSI_CHAN_Y,
  TGSI_EXEC_DATA_FLOAT);
}
+   if (inst->Instruction.Opcode == TGSI_OPCODE_LOD) {
+  unsigned char swizzles[4];
+  unsigned chan;
+  swizzles[0] = inst->Src[1].Register.SwizzleX;
+  swizzles[1] = inst->Src[1].Register.SwizzleY;
+  swizzles[2] = inst->Src[1].Register.SwizzleZ;
+  swizzles[3] = inst->Src[1].Register.SwizzleW;
+
+  for (chan = 0; chan < TGSI_NUM_CHANNELS; chan++) {
+ if (inst->Dst[0].Register.WriteMask & (1 << chan)) {
+if (swizzles[chan] >= 2) {
+   store_dest(mach, ,
+  >Dst[0], inst, chan, TGSI_EXEC_DATA_FLOAT);
+} else {
+   store_dest(mach, [swizzles[chan]],
+  >Dst[0], inst, chan, TGSI_EXEC_DATA_FLOAT);
+}
+ }
+  }
+   } else {
+  if (inst->Dst[0].Register.WriteMask & TGSI_WRITEMASK_X) {
+ store_dest(mach, [0], >Dst[0], inst, TGSI_CHAN_X,
+TGSI_EXEC_DATA_FLOAT);
+  }
+  if (inst->Dst[0].Register.WriteMask & TGSI_WRITEMASK_Y) {
+ store_dest(mach, [1], >Dst[0], inst, TGSI_CHAN_Y,
+TGSI_EXEC_DATA_FLOAT);
+  }
+   }
 }
 
 static void
@@ -5705,6 +5741,10 @@ exec_instruction(
   assert(0);
   break;
 
+   case TGSI_OPCODE_LOD:
+  exec_lodq(mach, inst);
+  break;
+
case TGSI_OPCODE_UARL:
   

Re: [Mesa-dev] [PATCH] anv: Remove base_vertex/instance from push_constants

[Lionel Landwerlin]

Reviewed-by: Lionel Landwerlin 

On 28/09/17 01:02, Jason Ekstrand wrote:

This is just legacy cruft.  We don't push these values; we pass them in
as vertex attributes.
---
  src/intel/vulkan/anv_private.h | 7 ---
  1 file changed, 7 deletions(-)

diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index 3ba623a..b58c803 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -1560,13 +1560,6 @@ struct anv_push_constants {
 /* Push constant data provided by the client through vkPushConstants */
 uint8_t client_data[MAX_PUSH_CONSTANTS_SIZE];
  
-   /* Our hardware only provides zero-based vertex and instance id so, in

-* order to satisfy the vulkan requirements, we may have to push one or
-* both of these into the shader.
-*/
-   uint32_t base_vertex;
-   uint32_t base_instance;
-
 /* Image data for image_load_store on pre-SKL */
 struct brw_image_param images[MAX_IMAGES];
  };



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

[Mesa-dev] [PATCH 10/14] anv: Move close(fd) from anv_bo_cache_import to its callers

[Chad Versace]

This will allow us to implement VK_ANDROID_native_buffer without dup'ing
the fd. We must close the fd in VK_KHR_external_memory_fd, but we should
not in VK_ANDROID_native_buffer.
---
 src/intel/vulkan/anv_allocator.c | 12 
 src/intel/vulkan/anv_device.c| 11 +++
 src/intel/vulkan/anv_intel.c |  2 ++
 3 files changed, 13 insertions(+), 12 deletions(-)

diff --git a/src/intel/vulkan/anv_allocator.c b/src/intel/vulkan/anv_allocator.c
index be750adeb52..2cf1130bf29 100644
--- a/src/intel/vulkan/anv_allocator.c
+++ b/src/intel/vulkan/anv_allocator.c
@@ -1324,18 +1324,6 @@ anv_bo_cache_import(struct anv_device *device,
}
 
pthread_mutex_unlock(>mutex);
-
-   /* From the Vulkan spec:
-*
-*"Importing memory from a file descriptor transfers ownership of
-*the file descriptor from the application to the Vulkan
-*implementation. The application must not perform any operations on
-*the file descriptor after a successful import."
-*
-* If the import fails, we leave the file descriptor open.
-*/
-   close(fd);
-
*bo_out = >bo;
 
return VK_SUCCESS;
diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index f04be4fce22..5c20f80024b 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -1539,6 +1539,17 @@ VkResult anv_AllocateMemory(
>bo);
   if (result != VK_SUCCESS)
  goto fail;
+
+  /* From the Vulkan spec:
+   *
+   *"Importing memory from a file descriptor transfers ownership of
+   *the file descriptor from the application to the Vulkan
+   *implementation. The application must not perform any operations on
+   *the file descriptor after a successful import."
+   *
+   * If the import fails, we leave the file descriptor open.
+   */
+  close(fd_info->fd);
} else {
   result = anv_bo_cache_alloc(device, >bo_cache,
   pAllocateInfo->allocationSize,
diff --git a/src/intel/vulkan/anv_intel.c b/src/intel/vulkan/anv_intel.c
index 991a93542d2..be6568468e1 100644
--- a/src/intel/vulkan/anv_intel.c
+++ b/src/intel/vulkan/anv_intel.c
@@ -79,6 +79,8 @@ VkResult anv_CreateDmaBufImageINTEL(
   }},
   pAllocator, _h);
 
+   close(pCreateInfo->fd);
+
image = anv_image_from_handle(image_h);
image->bo = mem->bo;
image->offset = 0;
-- 
2.13.5

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

[Mesa-dev] [PATCH 14/14] anv: Install as Vulkan HAL module in Android.mk build

[Chad Versace]

From: Tapani Pälli 

Now that anvil fully implements the Vulkan HAL interface, we can install
it as the vendor HAL module at /vendor/lib/hw/vulkan.${board}.so. To do
so:

  - Rename LOCAL_MODULE to vulkan.$(TARGET_BOARD_PLATFORM).
  - Use LOCAL_PROPRIETARY_MODULE to install under vendor path.

Tested by running different Sascha Williams demos on Android-IA.

Signed-off-by: Tapani Pälli 
[chadv: Extract this hunk from Tapani's patch, and embed it as
 stand-alone patch in my arc-vulkan series].
Signed-off-by: Chad Versace 
---
 src/intel/Android.vulkan.mk | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/intel/Android.vulkan.mk b/src/intel/Android.vulkan.mk
index b2d7d4e46c5..1ada848cfbe 100644
--- a/src/intel/Android.vulkan.mk
+++ b/src/intel/Android.vulkan.mk
@@ -248,8 +248,10 @@ include $(BUILD_STATIC_LIBRARY)
 
 include $(CLEAR_VARS)
 
-LOCAL_MODULE := libvulkan_intel
+LOCAL_MODULE := vulkan.$(TARGET_BOARD_PLATFORM)
 LOCAL_MODULE_CLASS := SHARED_LIBRARIES
+LOCAL_PROPRIETARY_MODULE := true
+LOCAL_MODULE_RELATIVE_PATH := hw
 
 LOCAL_CFLAGS := -DLOG_TAG=\"INTEL-MESA\"
 
-- 
2.13.5

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

[Mesa-dev] [PATCH 13/14] anv: Implement VK_ANDROID_native_buffer (v6)

[Chad Versace]

This implementation is correct (afaict), but takes two shortcuts
regarding the import/export of Android sync fds.

  Shortcut 1. When Android calls vkAcquireImageANDROID to import a sync
  fd into a VkSemaphore or VkFence, the driver instead simply blocks on
  the sync fd, then puts the VkSemaphore or VkFence into the signalled
  state. Thanks to implicit sync, this produces correct behavior (with
  extra latency overhead, perhaps) despite its ugliness.

  Shortcut 2. When Android calls vkQueueSignalReleaseImageANDROID to export
  a collection of wait semaphores as a sync fd, the driver instead
  submits the semaphores to the queue, then returns sync fd -1, which
  informs the caller that no additional synchronization is needed.
  Again, thanks to implicit sync, this produces correct behavior (with
  extra batch submission overhead) despite its ugliness.

I chose to take the shortcuts instead of properly importing/exporting
the sync fds for two reasons:

  Reason 1. I've already tested this patch with dEQP and with demos
  apps. It works. I wanted to get the tested patches into the tree now,
  and polish the implementation afterwards.

  Reason 2. I want to run this on a 3.18 kernel (gasp!). In 3.18, i915
  supports neither Android's sync_fence, nor upstream's sync_file, nor
  drm_syncobj. Again, I tested these patches on Android with a 3.18
  kernel and they work.

I plan to quickly follow-up with patches that remove the shortcuts and
properly import/export the sync fds.

Non-Testing
===
I did not test at all using the Android.mk buildsystem. I probably
broke it. Please test and review that.

Testing
===
I tested with 64-bit ARC++ on a Skylake Chromebook and a 3.18 kernel.
The following pass (as of patch v6):

  a little spinning cube demo APK
  dEQP-VK.info.*
  dEQP-VK.api.smoke.*
  dEQP-VK.api.info.instance.*
  dEQP-VK.api.info.device.*
  dEQP-VK.api.wsi.android.*

v2:
  - Reject VkNativeBufferANDROID if the dma-buf's size is too small for
the VkImage.
  - Stop abusing VkNativeBufferANDROID by passing it to vkAllocateMemory
during vkCreateImage. Instead, directly import its dma-buf during
vkCreateImage with anv_bo_cache_import(). [for jekstrand]
  - Rebase onto Tapani's VK_EXT_debug_report changes.
  - Drop `CPPFLAGS += $(top_srcdir)/include/android`. The dir does not
exist.

v3:
  - Delete duplicate #include "anv_private.h". [per Tapani]
  - Try to fix the Android-IA build in Android.vulkan.mk by following
Tapani's example.

v4:
  - Unset EXEC_OBJECT_ASYNC and set EXEC_OBJECT_WRITE on the imported
gralloc buffer, just as we do for all other winsys buffers in
anv_wsi.c. [found by Tapani]

v5:
  - Really fix the Android-IA build by ensuring that Android.vulkan.mk
uses Mesa' vulkan.h and not Android's.  Insert -I$(MESA_TOP)/include
before -Iframeworks/native/vulkan/include. [for Tapani]
  - In vkAcquireImageANDROID, submit signal operations to the
VkSemaphore and VkFence. [for zhou]

v6:
  - Drop copy-paste duplication in vkGetSwapchainGrallocUsageANDROID().
[found by zhou]
  - Improve comments in vkGetSwapchainGrallocUsageANDROID().

Reviewed-by: Tapani Pälli  (v5)
Cc: Jason Ekstrand 
Cc: zhoucm1 
---
 src/intel/Android.vulkan.mk |   7 +-
 src/intel/Makefile.sources  |   3 +
 src/intel/Makefile.vulkan.am|   2 +
 src/intel/vulkan/anv_android.c  | 244 
 src/intel/vulkan/anv_device.c   |  12 +-
 src/intel/vulkan/anv_entrypoints_gen.py |  10 +-
 src/intel/vulkan/anv_extensions.py  |   1 +
 src/intel/vulkan/anv_image.c| 147 +--
 src/intel/vulkan/anv_private.h  |   1 +
 9 files changed, 413 insertions(+), 14 deletions(-)
 create mode 100644 src/intel/vulkan/anv_android.c

diff --git a/src/intel/Android.vulkan.mk b/src/intel/Android.vulkan.mk
index e20b32b87c5..b2d7d4e46c5 100644
--- a/src/intel/Android.vulkan.mk
+++ b/src/intel/Android.vulkan.mk
@@ -28,6 +28,7 @@ VK_ENTRYPOINTS_SCRIPT := $(MESA_PYTHON2) 
$(LOCAL_PATH)/vulkan/anv_entrypoints_ge
 VK_EXTENSIONS_SCRIPT := $(MESA_PYTHON2) $(LOCAL_PATH)/vulkan/anv_extensions.py
 
 VULKAN_COMMON_INCLUDES := \
+   $(MESA_TOP)/include \
$(MESA_TOP)/src/mapi \
$(MESA_TOP)/src/gallium/auxiliary \
$(MESA_TOP)/src/gallium/include \
@@ -36,7 +37,8 @@ VULKAN_COMMON_INCLUDES := \
$(MESA_TOP)/src/vulkan/util \
$(MESA_TOP)/src/intel \
$(MESA_TOP)/include/drm-uapi \
-   $(MESA_TOP)/src/intel/vulkan
+   $(MESA_TOP)/src/intel/vulkan \
+   frameworks/native/vulkan/include
 
 # libmesa_anv_entrypoints with header and dummy.c
 #
@@ -254,7 +256,8 @@ LOCAL_CFLAGS := -DLOG_TAG=\"INTEL-MESA\"
 LOCAL_LDFLAGS += -Wl,--build-id=sha1
 
 LOCAL_SRC_FILES := \
-   $(VULKAN_GEM_FILES)
+   $(VULKAN_GEM_FILES) \
+   $(VULKAN_ANDROID_FILES)
 
 LOCAL_C_INCLUDES := \

[Mesa-dev] [PATCH 11/14] anv: Add sizeless anv_bo_cache_import()

[Chad Versace]

The patch renames anv_bo_cache_import() to
anv_bo_cache_import_with_size(); and adds a new variant,
anv_bo_cache_import(), that lacks the 'size' parameter. Same as
pre-patch, anv_bo_cache_import_with_size() continues to validate the
imported size.

The patch is essentially a refactor patch.  It should change no existing
behavior.

This split makes it easier to implement VK_ANDROID_native_buffer. When
the user imports a gralloc hande into a VkImage using
VK_ANDROID_native_buffer, the user provides no size. The driver must
infer the size from the internals of the gralloc buffer.
---
 src/intel/vulkan/anv_allocator.c | 118 +--
 src/intel/vulkan/anv_device.c|   7 ++-
 src/intel/vulkan/anv_intel.c |   4 +-
 src/intel/vulkan/anv_private.h   |   3 +
 src/intel/vulkan/anv_queue.c |   5 +-
 5 files changed, 88 insertions(+), 49 deletions(-)

diff --git a/src/intel/vulkan/anv_allocator.c b/src/intel/vulkan/anv_allocator.c
index 2cf1130bf29..756f49f3103 100644
--- a/src/intel/vulkan/anv_allocator.c
+++ b/src/intel/vulkan/anv_allocator.c
@@ -1269,63 +1269,97 @@ anv_bo_cache_alloc(struct anv_device *device,
return VK_SUCCESS;
 }
 
+static VkResult
+anv_bo_cache_import_locked(struct anv_device *device,
+   struct anv_bo_cache *cache,
+   int fd, struct anv_bo **bo_out)
+{
+   uint32_t gem_handle = anv_gem_fd_to_handle(device, fd);
+   if (!gem_handle)
+  return vk_error(VK_ERROR_INVALID_EXTERNAL_HANDLE_KHR);
+
+   struct anv_cached_bo *bo = anv_bo_cache_lookup_locked(cache, gem_handle);
+   if (bo) {
+  __sync_fetch_and_add(>refcount, 1);
+  return VK_SUCCESS;
+   }
+
+   off_t size = lseek(fd, 0, SEEK_END);
+   if (size == (off_t)-1) {
+  anv_gem_close(device, gem_handle);
+  return vk_error(VK_ERROR_INVALID_EXTERNAL_HANDLE_KHR);
+   }
+
+   bo = vk_alloc(>alloc, sizeof(struct anv_cached_bo), 8,
+ VK_SYSTEM_ALLOCATION_SCOPE_OBJECT);
+   if (!bo) {
+  anv_gem_close(device, gem_handle);
+  return vk_error(VK_ERROR_OUT_OF_HOST_MEMORY);
+   }
+
+   bo->refcount = 1;
+   anv_bo_init(>bo, gem_handle, size);
+   _mesa_hash_table_insert(cache->bo_map, (void *)(uintptr_t)gem_handle, bo);
+   *bo_out = >bo;
+   return VK_SUCCESS;
+}
+
 VkResult
 anv_bo_cache_import(struct anv_device *device,
 struct anv_bo_cache *cache,
-int fd, uint64_t size, struct anv_bo **bo_out)
+int fd, struct anv_bo **bo_out)
 {
+   VkResult result;
+
pthread_mutex_lock(>mutex);
+   result = anv_bo_cache_import_locked(device, cache, fd, bo_out);
+   pthread_mutex_unlock(>mutex);
+
+   return result;
+}
+
+VkResult
+anv_bo_cache_import_with_size(struct anv_device *device,
+  struct anv_bo_cache *cache,
+  int fd, uint64_t size,
+  struct anv_bo **bo_out)
+{
+   struct anv_bo *bo = NULL;
+   VkResult result;
 
/* The kernel is going to give us whole pages anyway */
size = align_u64(size, 4096);
 
-   uint32_t gem_handle = anv_gem_fd_to_handle(device, fd);
-   if (!gem_handle) {
+   pthread_mutex_lock(>mutex);
+
+   result = anv_bo_cache_import_locked(device, cache, fd, );
+   if (result != VK_SUCCESS) {
   pthread_mutex_unlock(>mutex);
-  return vk_error(VK_ERROR_INVALID_EXTERNAL_HANDLE_KHR);
+  return result;
}
 
-   struct anv_cached_bo *bo = anv_bo_cache_lookup_locked(cache, gem_handle);
-   if (bo) {
-  if (bo->bo.size != size) {
- pthread_mutex_unlock(>mutex);
- return vk_error(VK_ERROR_INVALID_EXTERNAL_HANDLE_KHR);
-  }
-  __sync_fetch_and_add(>refcount, 1);
-   } else {
-  /* For security purposes, we reject BO imports where the size does not
-   * match exactly.  This prevents a malicious client from passing a
-   * buffer to a trusted client, lying about the size, and telling the
-   * trusted client to try and texture from an image that goes
-   * out-of-bounds.  This sort of thing could lead to GPU hangs or worse
-   * in the trusted client.  The trusted client can protect itself against
-   * this sort of attack but only if it can trust the buffer size.
-   */
-  off_t import_size = lseek(fd, 0, SEEK_END);
-  if (import_size == (off_t)-1 || import_size != size) {
- anv_gem_close(device, gem_handle);
- pthread_mutex_unlock(>mutex);
- return vk_error(VK_ERROR_INVALID_EXTERNAL_HANDLE_KHR);
-  }
-
-  bo = vk_alloc(>alloc, sizeof(struct anv_cached_bo), 8,
-VK_SYSTEM_ALLOCATION_SCOPE_OBJECT);
-  if (!bo) {
- anv_gem_close(device, gem_handle);
- pthread_mutex_unlock(>mutex);
- return vk_error(VK_ERROR_OUT_OF_HOST_MEMORY);
-  }
-
-  bo->refcount = 1;
-
-  anv_bo_init(>bo, gem_handle, size);
-
-  _mesa_hash_table_insert(cache->bo_map, (void *)(uintptr_t)gem_handle, 
bo);
+   /* For 

[Mesa-dev] [PATCH 09/14] anv: Add field anv_image::bo_is_owned

[Chad Versace]

If this flag is set, then the image and it's bo have the same
lifetime. vkDestroyImage will release the bo.

We need this for VK_ANDROID_native_buffer, because that extension
creates the VkImage and imports its memory in the same call,
vkCreateImage.
---
 src/intel/vulkan/anv_image.c   | 9 -
 src/intel/vulkan/anv_private.h | 1 +
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
index f2553970b31..36ba0ca15ce 100644
--- a/src/intel/vulkan/anv_image.c
+++ b/src/intel/vulkan/anv_image.c
@@ -527,8 +527,12 @@ anv_image_create(VkDevice _device,
return VK_SUCCESS;
 
 fail:
-   if (image)
+   if (image) {
+  if (image->bo_is_owned && image->bo)
+ anv_bo_cache_release(device, >bo_cache, image->bo);
+
   vk_free2(>alloc, alloc, image);
+   }
 
return r;
 }
@@ -557,6 +561,9 @@ anv_DestroyImage(VkDevice _device, VkImage _image,
if (!image)
   return;
 
+   if (image->bo_is_owned && image->bo)
+  anv_bo_cache_release(device, >bo_cache, image->bo);
+
vk_free2(>alloc, pAllocator, image);
 }
 
diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index 0b215c4f738..cd1295d078b 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -2241,6 +2241,7 @@ struct anv_image {
/* Set when bound */
struct anv_bo *bo;
VkDeviceSize offset;
+   bool bo_is_owned; /**< When destroying the image, also free its bo. */
 
/**
 * Image subsurfaces
-- 
2.13.5

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

[Mesa-dev] [PATCH 07/14] anv/image: Refactor how tiling is chosen (v2)

[Chad Versace]

The code that restricts the VkImage's tiling flags, extract it into
a new function named choose_isl_tiling_flags().  This reduces the diff
in upcoming patches for VK_ANDROID_native_buffer.

v2:
  - Rebase onto 'needs_shadow' changes on master.
  - Assert that choose_isl_tiling_flags() chooses at least one tiling.
---
 src/intel/vulkan/anv_image.c | 41 -
 1 file changed, 28 insertions(+), 13 deletions(-)

diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
index 6f6bd59e89d..795badd27fd 100644
--- a/src/intel/vulkan/anv_image.c
+++ b/src/intel/vulkan/anv_image.c
@@ -107,6 +107,28 @@ get_surface(struct anv_image *image, VkImageAspectFlags 
aspect)
}
 }
 
+static VkResult
+choose_isl_tiling_flags(const struct anv_image_create_info *anv_info,
+bool needs_shadow,
+isl_tiling_flags_t *restrict flags)
+{
+   *flags = ISL_TILING_ANY_MASK;
+
+   if (anv_info->isl_tiling_flags)
+  *flags &= anv_info->isl_tiling_flags;
+
+   if (needs_shadow)
+  *flags &= ISL_TILING_LINEAR_BIT;
+
+   if (anv_info->vk_info->tiling == VK_IMAGE_TILING_LINEAR)
+  *flags = ISL_TILING_LINEAR_BIT;
+
+   /* Only invalid Vulkan usage can filter out all tiling formats. */
+   assert(*flags != 0);
+
+   return VK_SUCCESS;
+}
+
 static void
 add_surface(struct anv_image *image, struct anv_surface *surf)
 {
@@ -239,6 +261,7 @@ make_surface(const struct anv_device *dev,
  VkImageAspectFlags aspect)
 {
const VkImageCreateInfo *base_info = anv_info->vk_info;
+   VkResult result;
bool ok UNUSED;
 
static const enum isl_surf_dim vk_to_isl_surf_dim[] = {
@@ -247,18 +270,6 @@ make_surface(const struct anv_device *dev,
   [VK_IMAGE_TYPE_3D] = ISL_SURF_DIM_3D,
};
 
-   /* Translate the Vulkan tiling to an equivalent ISL tiling, then filter the
-* result with an optionally provided ISL tiling argument.
-*/
-   isl_tiling_flags_t tiling_flags =
-  (base_info->tiling == VK_IMAGE_TILING_LINEAR) ?
-  ISL_TILING_LINEAR_BIT : ISL_TILING_ANY_MASK;
-
-   if (anv_info->isl_tiling_flags)
-  tiling_flags &= anv_info->isl_tiling_flags;
-
-   assert(tiling_flags);
-
struct anv_surface *anv_surf = get_surface(image, aspect);
 
image->extent = anv_sanitize_image_extent(base_info->imageType,
@@ -279,10 +290,14 @@ make_surface(const struct anv_device *dev,
(base_info->flags & 
VK_IMAGE_CREATE_BLOCK_TEXEL_VIEW_COMPATIBLE_BIT_KHR) &&
base_info->tiling == VK_IMAGE_TILING_OPTIMAL) {
   assert(isl_format_is_compressed(format));
-  tiling_flags = ISL_TILING_LINEAR_BIT;
   needs_shadow = true;
}
 
+   isl_tiling_flags_t tiling_flags;
+   result = choose_isl_tiling_flags(anv_info, needs_shadow, _flags);
+   if (result != VK_SUCCESS)
+  return result;
+
ok = isl_surf_init(>isl_dev, _surf->isl,
   .dim = vk_to_isl_surf_dim[base_info->imageType],
   .format = format,
-- 
2.13.5

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

[Mesa-dev] [PATCH 12/14] anv: Add func anv_gem_get_tiling()

[Chad Versace]

Will use in VK_ANDROID_native_buffer.
---
 src/intel/vulkan/anv_gem.c | 16 
 src/intel/vulkan/anv_private.h |  1 +
 2 files changed, 17 insertions(+)

diff --git a/src/intel/vulkan/anv_gem.c b/src/intel/vulkan/anv_gem.c
index 3994c6b66c2..34c09891086 100644
--- a/src/intel/vulkan/anv_gem.c
+++ b/src/intel/vulkan/anv_gem.c
@@ -192,6 +192,22 @@ anv_gem_execbuffer(struct anv_device *device,
   return anv_ioctl(device->fd, DRM_IOCTL_I915_GEM_EXECBUFFER2, execbuf);
 }
 
+/** Return -1 on error. */
+int
+anv_gem_get_tiling(struct anv_device *device, uint32_t gem_handle)
+{
+   struct drm_i915_gem_get_tiling get_tiling = {
+  .handle = gem_handle,
+   };
+
+   if (anv_ioctl(device->fd, DRM_IOCTL_I915_GEM_GET_TILING, _tiling)) {
+  assert(!"Failed to get BO tiling");
+  return -1;
+   }
+
+   return get_tiling.tiling_mode;
+}
+
 int
 anv_gem_set_tiling(struct anv_device *device,
uint32_t gem_handle, uint32_t stride, uint32_t tiling)
diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index 8e310d7e1a6..b5a0aee6057 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -930,6 +930,7 @@ int anv_gem_destroy_context(struct anv_device *device, int 
context);
 int anv_gem_get_context_param(int fd, int context, uint32_t param,
   uint64_t *value);
 int anv_gem_get_param(int fd, uint32_t param);
+int anv_gem_get_tiling(struct anv_device *device, uint32_t gem_handle);
 bool anv_gem_get_bit6_swizzle(int fd, uint32_t tiling);
 int anv_gem_get_aperture(int fd, uint64_t *size);
 bool anv_gem_supports_48b_addresses(int fd);
-- 
2.13.5

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

[Mesa-dev] [PATCH 06/14] anv/image: Better var names for image-create-info structs

[Chad Versace]

Upcoming patches teach vkCreateImage to understand
VkNativeBufferANDROID. And much later patches will do the same for
whatever VkImageCreateInfo-chained struct imports dma-bufs. And then
again for the struct that will be introduced by the inevitable extension
VK_ANDROID_external_memory_whatever. So let's reduce ambiguity now by
choosing better variable names in make_surface() and
anv_image_create_info().

Rename:
  struct anv_image_create_info *create_info -> anv_info
  VkImageCreateInfo *pCreateInfo-> base_info
  VkImageCreateInfo *vk_info-> base_info
---
 src/intel/vulkan/anv_image.c | 98 ++--
 1 file changed, 49 insertions(+), 49 deletions(-)

diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
index 7561b9b52b4..6f6bd59e89d 100644
--- a/src/intel/vulkan/anv_image.c
+++ b/src/intel/vulkan/anv_image.c
@@ -120,20 +120,20 @@ add_surface(struct anv_image *image, struct anv_surface 
*surf)
 
 static bool
 all_formats_ccs_e_compatible(const struct gen_device_info *devinfo,
- const struct VkImageCreateInfo *vk_info)
+ const struct VkImageCreateInfo *base_info)
 {
enum isl_format format =
-  anv_get_isl_format(devinfo, vk_info->format,
- VK_IMAGE_ASPECT_COLOR_BIT, vk_info->tiling);
+  anv_get_isl_format(devinfo, base_info->format,
+ VK_IMAGE_ASPECT_COLOR_BIT, base_info->tiling);
 
if (!isl_format_supports_ccs_e(devinfo, format))
   return false;
 
-   if (!(vk_info->flags & VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT))
+   if (!(base_info->flags & VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT))
   return true;
 
const VkImageFormatListCreateInfoKHR *fmt_list =
-  vk_find_struct_const(vk_info->pNext, IMAGE_FORMAT_LIST_CREATE_INFO_KHR);
+  vk_find_struct_const(base_info->pNext, 
IMAGE_FORMAT_LIST_CREATE_INFO_KHR);
 
if (!fmt_list || fmt_list->viewFormatCount == 0)
   return false;
@@ -141,7 +141,7 @@ all_formats_ccs_e_compatible(const struct gen_device_info 
*devinfo,
for (uint32_t i = 0; i < fmt_list->viewFormatCount; i++) {
   enum isl_format view_format =
  anv_get_isl_format(devinfo, fmt_list->pViewFormats[i],
-VK_IMAGE_ASPECT_COLOR_BIT, vk_info->tiling);
+VK_IMAGE_ASPECT_COLOR_BIT, base_info->tiling);
 
   if (!isl_formats_are_ccs_e_compatible(devinfo, format, view_format))
  return false;
@@ -238,7 +238,7 @@ make_surface(const struct anv_device *dev,
  const struct anv_image_create_info *anv_info,
  VkImageAspectFlags aspect)
 {
-   const VkImageCreateInfo *vk_info = anv_info->vk_info;
+   const VkImageCreateInfo *base_info = anv_info->vk_info;
bool ok UNUSED;
 
static const enum isl_surf_dim vk_to_isl_surf_dim[] = {
@@ -251,7 +251,7 @@ make_surface(const struct anv_device *dev,
 * result with an optionally provided ISL tiling argument.
 */
isl_tiling_flags_t tiling_flags =
-  (vk_info->tiling == VK_IMAGE_TILING_LINEAR) ?
+  (base_info->tiling == VK_IMAGE_TILING_LINEAR) ?
   ISL_TILING_LINEAR_BIT : ISL_TILING_ANY_MASK;
 
if (anv_info->isl_tiling_flags)
@@ -261,11 +261,11 @@ make_surface(const struct anv_device *dev,
 
struct anv_surface *anv_surf = get_surface(image, aspect);
 
-   image->extent = anv_sanitize_image_extent(vk_info->imageType,
- vk_info->extent);
+   image->extent = anv_sanitize_image_extent(base_info->imageType,
+ base_info->extent);
 
-   enum isl_format format = anv_get_isl_format(>info, vk_info->format,
-   aspect, vk_info->tiling);
+   enum isl_format format = anv_get_isl_format(>info, base_info->format,
+   aspect, base_info->tiling);
assert(format != ISL_FORMAT_UNSUPPORTED);
 
/* If an image is created as BLOCK_TEXEL_VIEW_COMPATIBLE, then we need to
@@ -276,25 +276,25 @@ make_surface(const struct anv_device *dev,
 */
bool needs_shadow = false;
if (dev->info.gen <= 8 &&
-   (vk_info->flags & VK_IMAGE_CREATE_BLOCK_TEXEL_VIEW_COMPATIBLE_BIT_KHR) 
&&
-   vk_info->tiling == VK_IMAGE_TILING_OPTIMAL) {
+   (base_info->flags & 
VK_IMAGE_CREATE_BLOCK_TEXEL_VIEW_COMPATIBLE_BIT_KHR) &&
+   base_info->tiling == VK_IMAGE_TILING_OPTIMAL) {
   assert(isl_format_is_compressed(format));
   tiling_flags = ISL_TILING_LINEAR_BIT;
   needs_shadow = true;
}
 
ok = isl_surf_init(>isl_dev, _surf->isl,
-  .dim = vk_to_isl_surf_dim[vk_info->imageType],
+  .dim = vk_to_isl_surf_dim[base_info->imageType],
   .format = format,
   .width = image->extent.width,
   .height = image->extent.height,
   .depth = image->extent.depth,
-  .levels = vk_info->mipLevels,
-  .array_len = vk_info->arrayLayers,

[Mesa-dev] [PATCH 04/14] intel: Add simple logging façade for Android

[Chad Versace]

I'm bringing up Vulkan in the Android container of Chrome OS (ARC++).

On Android, stdio goes to /dev/null. On Android, remote gdb is even more
painful than the usual remote gdb. On Android, nothing works like you
expect and debugging is hell. I need logging.

This patch introduces a small, simple logging API that can easily wrap
Android's API. On non-Android platforms, this logger does nothing fancy.
It follows the time-honored Unix tradition of spewing everything to
stderr with minimal fuss.

My goal here is not perfection. My goal is to make a minimal, clean API,
that people hate merely a little instead of a lot, and that's good
enough to let me bring up Android Vulkan.  And it needs to be fast,
which means it must be small. No one wants to their game to miss frames
while aiming a flaming bow into the jaws of an angry robot t-rex, and
thus become t-rex breakfast, because some fool had too much fun desiging
a bloated, ideal logging API.

If people like it, perhaps we should quickly promote it to src/util.

The API looks like this:

#define INTEL_LOG_TAG "intel-vulkan"
#define DEBUG

intel_logd("try hard thing with foo=%d", foo);

n = try_foo(...);
if (n < 0) {
intel_loge("%s:%d: foo failed bigtime", __FILE__, __LINE__);
return VK_ERROR_DEVICE_LOST;
}

And produces this on non-Android:

intel-vulkan: debug: try hard thing with foo=93
intel-vulkan: error: anv_device.c:182: foo failed bigtime
---
 src/intel/Makefile.sources   |  4 +-
 src/intel/common/intel_log.c | 87 
 src/intel/common/intel_log.h | 82 +
 3 files changed, 172 insertions(+), 1 deletion(-)
 create mode 100644 src/intel/common/intel_log.c
 create mode 100644 src/intel/common/intel_log.h

diff --git a/src/intel/Makefile.sources b/src/intel/Makefile.sources
index bca7a132b26..64a2dfe10e7 100644
--- a/src/intel/Makefile.sources
+++ b/src/intel/Makefile.sources
@@ -18,7 +18,9 @@ COMMON_FILES = \
common/gen_l3_config.c \
common/gen_l3_config.h \
common/gen_urb_config.c \
-   common/gen_sample_positions.h
+   common/gen_sample_positions.h \
+   common/intel_log.c \
+   common/intel_log.h
 
 COMPILER_FILES = \
compiler/brw_cfg.cpp \
diff --git a/src/intel/common/intel_log.c b/src/intel/common/intel_log.c
new file mode 100644
index 000..cebdd6dd6d8
--- /dev/null
+++ b/src/intel/common/intel_log.c
@@ -0,0 +1,87 @@
+/*
+ * Copyright © 2017 Google, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include 
+
+#ifdef ANDROID
+#include 
+#else
+#include 
+#endif
+
+#include "intel_log.h"
+
+#ifdef ANDROID
+static inline android_LogPriority
+level_to_android(enum intel_log_level l)
+{
+   switch (l) {
+   case INTEL_LOG_ERROR: return ANDROID_LOG_ERROR;
+   case INTEL_LOG_WARN: return ANDROID_LOG_WARN;
+   case INTEL_LOG_INFO: return ANDROID_LOG_INFO;
+   case INTEL_LOG_DEBUG: return ANDROID_LOG_DEBUG;
+   }
+
+   unreachable("bad intel_log_level");
+}
+#endif
+
+#ifndef ANDROID
+static inline const char *
+level_to_str(enum intel_log_level l)
+{
+   switch (l) {
+   case INTEL_LOG_ERROR: return "error";
+   case INTEL_LOG_WARN: return "warning";
+   case INTEL_LOG_INFO: return "info";
+   case INTEL_LOG_DEBUG: return "debug";
+   }
+
+   unreachable("bad intel_log_level");
+}
+#endif
+
+void
+intel_log(enum intel_log_level level, const char *tag, const char *format, ...)
+{
+   va_list va;
+
+   va_start(va, format);
+   intel_log_v(level, tag, format, va);
+   va_end(va);
+}
+
+void
+intel_log_v(enum intel_log_level level, const char *tag, const char *format,
+va_list va)
+{
+#ifdef ANDROID
+   __android_log_vprint(level_to_android(level), tag, format, va);
+#else
+   flockfile(stderr);
+   fprintf(stderr, "%s: %s: ", tag, level_to_str(level));
+   vfprintf(stderr, format, va);
+   

[Mesa-dev] [PATCH 03/14] intel: Move definition of LOG_TAG from header into Makefiles

[Chad Versace]

This patch prevents compilation failures in upcoming Android Vulkan
patches, failures due to redefinition of LOG_TAG in Android system
headers.

This patch does not change the value of LOG_TAG. It remains
"INTEL-MESA". (I don't like it, though. The all-caps smells like
FORTRAN).

Only one Intel header defined LOG_TAG: gen_debug.h. I believe I defined
it correctly in all the necessary Automake and Android.mk files, but one
can never truly know when touching build systems.

This patch is ugly and too big. If someone knows a better way, please
speak up.
---
 src/intel/Android.blorp.mk|  2 ++
 src/intel/Android.common.mk   |  2 ++
 src/intel/Android.vulkan.mk   | 21 -
 src/intel/Makefile.am |  3 ++-
 src/intel/common/gen_debug.h  |  1 -
 src/mesa/drivers/dri/i965/Android.mk  | 23 +--
 src/mesa/drivers/dri/i965/Makefile.am |  1 +
 7 files changed, 36 insertions(+), 17 deletions(-)

diff --git a/src/intel/Android.blorp.mk b/src/intel/Android.blorp.mk
index e1aa908706e..0fc7e1ed090 100644
--- a/src/intel/Android.blorp.mk
+++ b/src/intel/Android.blorp.mk
@@ -31,6 +31,8 @@ LOCAL_MODULE_CLASS := STATIC_LIBRARIES
 
 LOCAL_SRC_FILES := $(BLORP_FILES)
 
+LOCAL_CFLAGS := -DLOG_TAG=\"INTEL-MESA\"
+
 LOCAL_C_INCLUDES := \
$(call generated-sources-dir-for,STATIC_LIBRARIES,libmesa_nir,,)/nir \
$(MESA_TOP)/src/gallium/auxiliary \
diff --git a/src/intel/Android.common.mk b/src/intel/Android.common.mk
index 12cea6e5472..931800a596f 100644
--- a/src/intel/Android.common.mk
+++ b/src/intel/Android.common.mk
@@ -31,6 +31,8 @@ LOCAL_MODULE_CLASS := STATIC_LIBRARIES
 
 LOCAL_SRC_FILES := $(COMMON_FILES)
 
+LOCAL_CFLAGS := -DLOG_TAG=\"INTEL-MESA\"
+
 LOCAL_C_INCLUDES := \
external/zlib \
$(MESA_TOP)/src/gallium/include \
diff --git a/src/intel/Android.vulkan.mk b/src/intel/Android.vulkan.mk
index ee98e30c355..e20b32b87c5 100644
--- a/src/intel/Android.vulkan.mk
+++ b/src/intel/Android.vulkan.mk
@@ -51,6 +51,8 @@ LOCAL_MODULE_CLASS := STATIC_LIBRARIES
 
 intermediates := $(call local-generated-sources-dir)
 
+LOCAL_CFLAGS := -DLOG_TAG=\"INTEL-MESA\"
+
 LOCAL_C_INCLUDES := \
$(VULKAN_COMMON_INCLUDES)
 
@@ -91,7 +93,8 @@ LOCAL_MODULE := libmesa_anv_gen7
 LOCAL_MODULE_CLASS := STATIC_LIBRARIES
 
 LOCAL_SRC_FILES := $(VULKAN_GEN7_FILES)
-LOCAL_CFLAGS := -DGEN_VERSIONx10=70
+
+LOCAL_CFLAGS := -DLOG_TAG=\"INTEL-MESA\" -DGEN_VERSIONx10=70
 
 LOCAL_C_INCLUDES := $(ANV_INCLUDES)
 
@@ -111,7 +114,8 @@ LOCAL_MODULE := libmesa_anv_gen75
 LOCAL_MODULE_CLASS := STATIC_LIBRARIES
 
 LOCAL_SRC_FILES := $(VULKAN_GEN75_FILES)
-LOCAL_CFLAGS := -DGEN_VERSIONx10=75
+
+LOCAL_CFLAGS := -DLOG_TAG=\"INTEL-MESA\" -DGEN_VERSIONx10=75
 
 LOCAL_C_INCLUDES := $(ANV_INCLUDES)
 
@@ -131,7 +135,8 @@ LOCAL_MODULE := libmesa_anv_gen8
 LOCAL_MODULE_CLASS := STATIC_LIBRARIES
 
 LOCAL_SRC_FILES := $(VULKAN_GEN8_FILES)
-LOCAL_CFLAGS := -DGEN_VERSIONx10=80
+
+LOCAL_CFLAGS := -DLOG_TAG=\"INTEL-MESA\" -DGEN_VERSIONx10=80
 
 LOCAL_C_INCLUDES := $(ANV_INCLUDES)
 
@@ -151,7 +156,8 @@ LOCAL_MODULE := libmesa_anv_gen9
 LOCAL_MODULE_CLASS := STATIC_LIBRARIES
 
 LOCAL_SRC_FILES := $(VULKAN_GEN9_FILES)
-LOCAL_CFLAGS := -DGEN_VERSIONx10=90
+
+LOCAL_CFLAGS := -DLOG_TAG=\"INTEL-MESA\" -DGEN_VERSIONx10=90
 
 LOCAL_C_INCLUDES := $(ANV_INCLUDES)
 
@@ -171,7 +177,8 @@ LOCAL_MODULE := libmesa_anv_gen10
 LOCAL_MODULE_CLASS := STATIC_LIBRARIES
 
 LOCAL_SRC_FILES := $(VULKAN_GEN10_FILES)
-LOCAL_CFLAGS := -DGEN_VERSIONx10=100
+
+LOCAL_CFLAGS := -DLOG_TAG=\"INTEL-MESA\" -DGEN_VERSIONx10=100
 
 LOCAL_C_INCLUDES := $(ANV_INCLUDES)
 
@@ -194,6 +201,8 @@ intermediates := $(call local-generated-sources-dir)
 
 LOCAL_SRC_FILES := $(VULKAN_FILES)
 
+LOCAL_CFLAGS := -DLOG_TAG=\"INTEL-MESA\"
+
 LOCAL_C_INCLUDES := \
$(ANV_INCLUDES) \
$(MESA_TOP)/src/compiler
@@ -240,6 +249,8 @@ include $(CLEAR_VARS)
 LOCAL_MODULE := libvulkan_intel
 LOCAL_MODULE_CLASS := SHARED_LIBRARIES
 
+LOCAL_CFLAGS := -DLOG_TAG=\"INTEL-MESA\"
+
 LOCAL_LDFLAGS += -Wl,--build-id=sha1
 
 LOCAL_SRC_FILES := \
diff --git a/src/intel/Makefile.am b/src/intel/Makefile.am
index a34e3014497..2872ffc1e89 100644
--- a/src/intel/Makefile.am
+++ b/src/intel/Makefile.am
@@ -40,7 +40,8 @@ AM_CPPFLAGS = \
-I$(top_srcdir)/src/gallium/include \
$(VALGRIND_CFLAGS) \
$(LIBDRM_CFLAGS) \
-   $(DEFINES)
+   $(DEFINES) \
+   -DLOG_TAG=\"INTEL-MESA\"
 
 AM_CFLAGS = \
$(VISIBILITY_CFLAGS) \
diff --git a/src/intel/common/gen_debug.h b/src/intel/common/gen_debug.h
index e418e3fb166..053c41c0fb2 100644
--- a/src/intel/common/gen_debug.h
+++ b/src/intel/common/gen_debug.h
@@ -85,7 +85,6 @@ extern uint64_t INTEL_DEBUG;
 #define DEBUG_REEMIT  (1ull << 41)
 
 #ifdef HAVE_ANDROID_PLATFORM
-#define LOG_TAG "INTEL-MESA"
 #include 
 #ifndef ALOGW
 #define ALOGW LOGW
diff --git a/src/mesa/drivers/dri/i965/Android.mk 
b/src/mesa/drivers/dri/i965/Android.mk
index 

[Mesa-dev] [PATCH 01/14] anv/android: Link to Android libraries in the autotools build

[Chad Versace]

A first step to supporting Vulkan on ARC++. Mesa on ARC++ uses
Autotools, not Android.mk.

Doing this now, even before VK_ANDROID_native_buffer is implemented,
allows us to incrementally add Android support to the Autotools build.
---
 src/intel/Makefile.vulkan.am | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/intel/Makefile.vulkan.am b/src/intel/Makefile.vulkan.am
index 271b0a5079b..0f488fc9f63 100644
--- a/src/intel/Makefile.vulkan.am
+++ b/src/intel/Makefile.vulkan.am
@@ -146,6 +146,11 @@ VULKAN_LIB_DEPS = \
$(DLOPEN_LIBS) \
-lm
 
+if HAVE_PLATFORM_ANDROID
+VULKAN_CFLAGS += $(ANDROID_CFLAGS)
+VULKAN_LIB_DEPS += $(ANDROID_LIBS)
+endif
+
 if HAVE_PLATFORM_X11
 VULKAN_CPPFLAGS += \
$(XCB_DRI3_CFLAGS) \
-- 
2.13.5

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

[Mesa-dev] [PATCH 00/14] anv: Implement VK_ANDROID_native_buffer (v3)

[Chad Versace]

This series adds Android support to Anvil. And Android requires
VK_ANDROID_native_buffer.


I tested the series on 64-bit ARC++ on a Skylake Chromebook with a 3.18
kernel. (ARC++ is the Android container in Chrome OS). (Yes, I said 3.18.
That's not a typo).


Here's my test results:

  - A little, spinning cube demo APK works, proving that the window
system integration is, if not fully correct, at least good enough.

  - On Linux (non-Android), this patch series causes no regressions in
VK-GL-CTS (master@dfcb8e87) under Wayland.

  - On Android, in patchset v1, dEQP from
android-cts-7.1_r8-linux_x86-x86 had 1 failure. I'm still waiting
for the results for patchset v2.

 Passed: 66889/81423 (82.2%)
 Failed: 1/81423 (0.0%)
 Not supported:  14529/81423 (17.8%)
 Warnings:   4/81423 (0.0%)

 The sole failure was
 
dEQP-VK.pipeline.image_view.view_type.cube_array.format.r16g16_sint.component_swizzle.one_r_g_zero

This patch series lives at:
git://git.kiwitree.net/~chadv/mesa refs/tags/chadv/review/anv-android-v03
cgit 
http://git.kiwitree.net/cgit/~chadv/mesa/tag/?h=chadv/review/arc-android-v03

I tested tag anv-android-v03 on Wayland. To test on ARC++, I had to add
additional fixes. The branch I tested on ARC++ lives at:
git://git.kiwitree.net/~chadv/mesa refs/tags/chadv/review/arc-vulkan-v03
cgit 
http://git.kiwitree.net/cgit/~chadv/mesa/tag/?h=chadv/review/arc-vulkan-v03


Note that Mesa's ARC++ build uses Autotools, not Android.mk. This series
probably broke the Android.mk files. Someone, please review and test
that.


Each patch but the last is just prep. You should read the last patch
first to better understand the goal, then afterwards review the series
linearly from the beginning.


v2:
  - A few patches have already landed on master.
  - Drop the ugly flag params from anv_bo_cache_import(), for jekstrand.
  - Reject VkNativeBufferANDROID if the dma-buf's size is too small for
the VkImage.
  - Stop abusing VkNativeBufferANDROID by passing it to vkAllocateMemory
during vkCreateImage. Instead, directly import its dma-buf during
vkCreateImage with anv_bo_cache_import(). [for jekstrand]
  - Rebase onto Tapani's VK_EXT_debug_report changes.


v3:
  - Omit v2 patches already upstreamed.
  - Many fixes to "anv: Implement VK_ANDROID_native_buffer".
  - Don't break the Android.mk buildsystem used by Android-IA.
  - Rebase onto the anv_image.c:needs_shadow changes in master.


Chad Versace (12):
  anv/android: Link to Android libraries in the autotools build
  intel: Move definition of LOG_TAG from header into Makefiles
  intel: Add simple logging façade for Android
  anv: Better support for Android logging (v2)
  anv/image: Better var names for image-create-info structs
  anv/image: Refactor how tiling is chosen (v2)
  anv/image: Refactor creation of aux surfaces (v2)
  anv: Add field anv_image::bo_is_owned
  anv: Move close(fd) from anv_bo_cache_import to its callers
  anv: Add sizeless anv_bo_cache_import()
  anv: Add func anv_gem_get_tiling()
  anv: Implement VK_ANDROID_native_buffer (v6)

Tapani Pälli (2):
  anv/android: Link to libsync, liblog in Android.mk
  anv: Install as Vulkan HAL module in Android.mk build

 src/intel/Android.blorp.mk  |   2 +
 src/intel/Android.common.mk |   2 +
 src/intel/Android.vulkan.mk |  34 ++-
 src/intel/Makefile.am   |   3 +-
 src/intel/Makefile.sources  |   7 +-
 src/intel/Makefile.vulkan.am|   7 +
 src/intel/common/gen_debug.h|   1 -
 src/intel/common/intel_log.c|  87 ++
 src/intel/common/intel_log.h|  82 ++
 src/intel/vulkan/anv_allocator.c| 126 +
 src/intel/vulkan/anv_android.c  | 244 
 src/intel/vulkan/anv_device.c   |  41 ++-
 src/intel/vulkan/anv_entrypoints_gen.py |  10 +-
 src/intel/vulkan/anv_extensions.py  |   1 +
 src/intel/vulkan/anv_gem.c  |  16 ++
 src/intel/vulkan/anv_image.c| 475 ++--
 src/intel/vulkan/anv_intel.c|   6 +-
 src/intel/vulkan/anv_private.h  |  18 +-
 src/intel/vulkan/anv_queue.c|   5 +-
 src/intel/vulkan/anv_util.c |  21 +-
 src/intel/vulkan/genX_cmd_buffer.c  |   4 +-
 src/mesa/drivers/dri/i965/Android.mk|  23 +-
 src/mesa/drivers/dri/i965/Makefile.am   |   1 +
 23 files changed, 960 insertions(+), 256 deletions(-)
 create mode 100644 src/intel/common/intel_log.c
 create mode 100644 src/intel/common/intel_log.h
 create mode 100644 src/intel/vulkan/anv_android.c

-- 
2.13.5

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

[Mesa-dev] [PATCH 02/14] anv/android: Link to libsync, liblog in Android.mk

[Chad Versace]

From: Tapani Pälli 

chadv: I made this patch by extracting the hunk from Tapani's patch in
https://lists.freedesktop.org/archives/mesa-dev/2017-September/169602.html.

Signed-off-by: Chad Versace 
---
 src/intel/Android.vulkan.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/Android.vulkan.mk b/src/intel/Android.vulkan.mk
index a15d9169425..ee98e30c355 100644
--- a/src/intel/Android.vulkan.mk
+++ b/src/intel/Android.vulkan.mk
@@ -268,7 +268,7 @@ LOCAL_WHOLE_STATIC_LIBRARIES := \
libmesa_intel_compiler \
libmesa_anv_entrypoints
 
-LOCAL_SHARED_LIBRARIES := libdrm libz
+LOCAL_SHARED_LIBRARIES := libdrm libz libsync liblog
 
 include $(MESA_COMMON_MK)
 include $(BUILD_SHARED_LIBRARY)
-- 
2.13.5

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

[Mesa-dev] [PATCH 08/14] anv/image: Refactor creation of aux surfaces (v2)

[Chad Versace]

Creation of hiz, ccs, and mcs surfaces was encoded in a large, deep 'if'
tree at the tail of make_surface(). This patch extracts that 'if' tree
into one function per aux type:

try_make_hiz_surface()
try_make_ccs_surface()
try_make_mcs_surface()

For clarity, also rename make_surface() to make_main_surface().

No behavioral change is intended.

v2: Rebase onto Tapani's VK_EXT_debug_report changes.
---
 src/intel/vulkan/anv_image.c | 220 ++-
 1 file changed, 133 insertions(+), 87 deletions(-)

diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
index 795badd27fd..f2553970b31 100644
--- a/src/intel/vulkan/anv_image.c
+++ b/src/intel/vulkan/anv_image.c
@@ -34,6 +34,10 @@
 
 #include "vk_format_info.h"
 
+static void
+add_fast_clear_state_buffer(struct anv_image *image,
+const struct anv_device *device);
+
 /**
  * Exactly one bit must be set in \a aspect.
  */
@@ -139,7 +143,6 @@ add_surface(struct anv_image *image, struct anv_surface 
*surf)
image->alignment = MAX2(image->alignment, surf->isl.alignment);
 }
 
-
 static bool
 all_formats_ccs_e_compatible(const struct gen_device_info *devinfo,
  const struct VkImageCreateInfo *base_info)
@@ -172,6 +175,124 @@ all_formats_ccs_e_compatible(const struct gen_device_info 
*devinfo,
return true;
 }
 
+static void
+try_make_hiz_surface(const struct anv_device *dev,
+ const VkImageCreateInfo *base_info,
+ struct anv_image *image)
+{
+   bool ok UNUSED;
+
+   assert(image->aux_surface.isl.size == 0);
+
+   /* We don't advertise that depth buffers could be used as storage
+* images.
+*/
+   assert(!(image->usage & VK_IMAGE_USAGE_STORAGE_BIT));
+
+   /* Allow the user to control HiZ enabling through environment variables.
+* Disable by default on gen7 because resolves are not currently
+* implemented pre-BDW.
+*/
+   if (!(image->usage & VK_IMAGE_USAGE_DEPTH_STENCIL_ATTACHMENT_BIT)) {
+  /* It will never be used as an attachment, HiZ is pointless. */
+   } else if (dev->info.gen == 7) {
+  anv_perf_warn(dev->instance, image, "Implement gen7 HiZ");
+   } else if (base_info->mipLevels > 1) {
+  anv_perf_warn(dev->instance, image, "Enable multi-LOD HiZ");
+   } else if (base_info->arrayLayers > 1) {
+  anv_perf_warn(dev->instance, image, "Implement multi-arrayLayer HiZ 
clears and resolves");
+   } else if (dev->info.gen == 8 && base_info->samples > 1) {
+  anv_perf_warn(dev->instance, image, "Enable gen8 multisampled HiZ");
+   } else if (!unlikely(INTEL_DEBUG & DEBUG_NO_HIZ)) {
+  ok = isl_surf_get_hiz_surf(>isl_dev, >depth_surface.isl,
+ >aux_surface.isl);
+  assert(ok);
+  add_surface(image, >aux_surface);
+  image->aux_usage = ISL_AUX_USAGE_HIZ;
+   }
+}
+
+static void
+try_make_ccs_surface(const struct anv_device *dev,
+ const VkImageCreateInfo *base_info,
+ struct anv_image *image)
+{
+   assert(image->aux_surface.isl.size == 0);
+
+   if (unlikely(INTEL_DEBUG & DEBUG_NO_RBC))
+  return;
+
+   if (!isl_surf_get_ccs_surf(>isl_dev, >color_surface.isl,
+  >aux_surface.isl, 0))
+  return;
+
+   /* Disable CCS when it is not useful (i.e., when you can't render
+* to the image with CCS enabled).
+*/
+   if (!isl_format_supports_rendering(>info,
+  image->color_surface.isl.format)) {
+  /* While it may be technically possible to enable CCS for this
+   * image, we currently don't have things hooked up to get it
+   * working.
+   */
+  anv_perf_warn(dev->instance, image,
+"This image format doesn't support rendering. "
+"Not allocating an CCS buffer.");
+  image->aux_surface.isl.size = 0;
+  return;
+   }
+
+   add_surface(image, >aux_surface);
+   add_fast_clear_state_buffer(image, dev);
+
+   /* For images created without MUTABLE_FORMAT_BIT set, we know that
+* they will always be used with the original format.  In
+* particular, they will always be used with a format that
+* supports color compression.  If it's never used as a storage
+* image, then it will only be used through the sampler or the as
+* a render target.  This means that it's safe to just leave
+* compression on at all times for these formats.
+*/
+   if (!(base_info->usage & VK_IMAGE_USAGE_STORAGE_BIT) &&
+   all_formats_ccs_e_compatible(>info, base_info)) {
+  image->aux_usage = ISL_AUX_USAGE_CCS_E;
+   }
+}
+
+static void
+try_make_mcs_surface(const struct anv_device *dev,
+ const VkImageCreateInfo *base_info,
+ struct anv_image *image)
+{
+   assert(image->aux_surface.isl.size == 0);
+   assert(!(base_info->usage & VK_IMAGE_USAGE_STORAGE_BIT));
+
+   if 

[Mesa-dev] [PATCH 05/14] anv: Better support for Android logging (v2)

[Chad Versace]

In src/intel/vulkan/*, redirect all instances of printf, vk_error,
anv_loge, anv_debug, anv_finishme, anv_perf_warn, anv_assert, and their
many variants to the new intel_log functions. I believe I caught them
all.

The other subdirs of src/intel are left for a future exercise.

v2:
  - Rebase onto Tapani's VK_EXT_debug_report changes.
  - Drop unused #include .
---
 src/intel/vulkan/anv_device.c  | 11 +--
 src/intel/vulkan/anv_private.h | 12 +---
 src/intel/vulkan/anv_util.c| 21 +++--
 src/intel/vulkan/genX_cmd_buffer.c |  4 ++--
 4 files changed, 15 insertions(+), 33 deletions(-)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index d576bb55315..f04be4fce22 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -50,7 +50,7 @@ compiler_perf_log(void *data, const char *fmt, ...)
va_start(args, fmt);
 
if (unlikely(INTEL_DEBUG & DEBUG_PERF))
-  vfprintf(stderr, fmt, args);
+  intel_logd_v(fmt, args);
 
va_end(args);
 }
@@ -294,11 +294,11 @@ anv_physical_device_init(struct anv_physical_device 
*device,
}
 
if (device->info.is_haswell) {
-  fprintf(stderr, "WARNING: Haswell Vulkan support is incomplete\n");
+  intel_logw("Haswell Vulkan support is incomplete");
} else if (device->info.gen == 7 && !device->info.is_baytrail) {
-  fprintf(stderr, "WARNING: Ivy Bridge Vulkan support is incomplete\n");
+  intel_logw("Ivy Bridge Vulkan support is incomplete");
} else if (device->info.gen == 7 && device->info.is_baytrail) {
-  fprintf(stderr, "WARNING: Bay Trail Vulkan support is incomplete\n");
+  intel_logw("Bay Trail Vulkan support is incomplete");
} else if (device->info.gen >= 8 && device->info.gen <= 9) {
   /* Broadwell, Cherryview, Skylake, Broxton, Kabylake is as fully
* supported as anything */
@@ -365,8 +365,7 @@ anv_physical_device_init(struct anv_physical_device *device,
* many platforms, but otherwise, things will just work.
*/
   if (device->subslice_total < 1 || device->eu_total < 1) {
- fprintf(stderr, "WARNING: Kernel 4.1 required to properly"
- " query GPU properties.\n");
+ intel_logw("Kernel 4.1 required to properly query GPU properties");
   }
} else if (device->info.gen == 7) {
   device->subslice_total = 1 << (device->info.gt - 1);
diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index 3ba623a37fd..0b215c4f738 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -74,6 +74,7 @@ struct gen_l3_config;
 #include "isl/isl.h"
 
 #include "common/gen_debug.h"
+#include "common/intel_log.h"
 #include "wsi_common.h"
 
 /* Allowing different clear colors requires us to perform a depth resolve at
@@ -314,11 +315,9 @@ VkResult __vk_errorf(struct anv_instance *instance, const 
void *object,
 #define vk_errorf(instance, obj, error, format, ...)\
 __vk_errorf(instance, obj, REPORT_OBJECT_TYPE(obj), error,\
 __FILE__, __LINE__, format, ## __VA_ARGS__);
-#define anv_debug(format, ...) fprintf(stderr, "debug: " format, ##__VA_ARGS__)
 #else
 #define vk_error(error) error
 #define vk_errorf(instance, obj, error, format, ...) error
-#define anv_debug(format, ...)
 #endif
 
 /**
@@ -337,10 +336,8 @@ VkResult __vk_errorf(struct anv_instance *instance, const 
void *object,
  *defined by extensions supported by that component.
  */
 #define anv_debug_ignored_stype(sType) \
-   anv_debug("%s: ignored VkStructureType %u\n", __func__, (sType))
+   intel_logd("%s: ignored VkStructureType %u\n", __func__, (sType))
 
-void __anv_finishme(const char *file, int line, const char *format, ...)
-   anv_printflike(3, 4);
 void __anv_perf_warn(struct anv_instance *instance, const void *object,
  VkDebugReportObjectTypeEXT type, const char *file,
  int line, const char *format, ...)
@@ -364,7 +361,8 @@ void anv_debug_report(struct anv_instance *instance,
do { \
   static bool reported = false; \
   if (!reported) { \
- __anv_finishme(__FILE__, __LINE__, format, ##__VA_ARGS__); \
+ intel_logw("%s:%d: FINISHME: " format, __FILE__, __LINE__, \
+##__VA_ARGS__); \
  reported = true; \
   } \
} while (0)
@@ -386,7 +384,7 @@ void anv_debug_report(struct anv_instance *instance,
 #ifdef DEBUG
 #define anv_assert(x) ({ \
if (unlikely(!(x))) \
-  fprintf(stderr, "%s:%d ASSERT: %s\n", __FILE__, __LINE__, #x); \
+  intel_loge("%s:%d ASSERT: %s", __FILE__, __LINE__, #x); \
 })
 #else
 #define anv_assert(x)
diff --git a/src/intel/vulkan/anv_util.c b/src/intel/vulkan/anv_util.c
index ec61f7355ef..59f893492b7 100644
--- a/src/intel/vulkan/anv_util.c
+++ b/src/intel/vulkan/anv_util.c
@@ -47,22 +47,7 @@ anv_loge(const char *format, ...)
 void
 anv_loge_v(const char *format, va_list va)
 {
-   

Re: [Mesa-dev] [PATCH] mesa: fix texture updates for ATI_fragment_shader

[Marek Olšák]

It fixes a crash with an apitrace that I have. Other than that, no
tests. Yes, it should be tagged for stable.

Marek

On Thu, Sep 28, 2017 at 1:34 AM, Ian Romanick  wrote:
> This looks right... at least it makes ATI_fragment_shader behave like
> ARB_fragment_program.  I don't suppose there are any tests that exercise
> this problem?  Should this be tagged for stable?
>
> On 09/27/2017 08:39 AM, Marek Olšák wrote:
>> From: Marek Olšák 
>>
>> ---
>>  src/mesa/main/texstate.c | 8 +---
>>  1 file changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/mesa/main/texstate.c b/src/mesa/main/texstate.c
>> index 269e291..edd2253 100644
>> --- a/src/mesa/main/texstate.c
>> +++ b/src/mesa/main/texstate.c
>> @@ -833,23 +833,25 @@ update_ff_texture_state(struct gl_context *ctx,
>>  void
>>  _mesa_update_texture_state(struct gl_context *ctx)
>>  {
>> struct gl_program *prog[MESA_SHADER_STAGES];
>> int i;
>> int old_max_unit = ctx->Texture._MaxEnabledTexImageUnit;
>> BITSET_DECLARE(enabled_texture_units, MAX_COMBINED_TEXTURE_IMAGE_UNITS);
>>
>> memcpy(prog, ctx->_Shader->CurrentProgram, sizeof(prog));
>>
>> -   if (prog[MESA_SHADER_FRAGMENT] == NULL &&
>> -   _mesa_arb_fragment_program_enabled(ctx)) {
>> -  prog[MESA_SHADER_FRAGMENT] = ctx->FragmentProgram.Current;
>> +   if (prog[MESA_SHADER_FRAGMENT] == NULL) {
>> +  if (_mesa_arb_fragment_program_enabled(ctx))
>> + prog[MESA_SHADER_FRAGMENT] = ctx->FragmentProgram.Current;
>> +  else if (_mesa_ati_fragment_shader_enabled(ctx))
>> + prog[MESA_SHADER_FRAGMENT] = 
>> ctx->ATIFragmentShader.Current->Program;
>> }
>>
>> /* TODO: only set this if there are actual changes */
>> ctx->NewState |= _NEW_TEXTURE_OBJECT | _NEW_TEXTURE_STATE;
>>
>> ctx->Texture._GenFlags = 0x0;
>> ctx->Texture._TexMatEnabled = 0x0;
>> ctx->Texture._TexGenEnabled = 0x0;
>> ctx->Texture._MaxEnabledTexImageUnit = -1;
>> ctx->Texture._EnabledCoordUnits = 0x0;
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] anv: Remove base_vertex/instance from push_constants

[Jason Ekstrand]

This is just legacy cruft.  We don't push these values; we pass them in
as vertex attributes.
---
 src/intel/vulkan/anv_private.h | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index 3ba623a..b58c803 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -1560,13 +1560,6 @@ struct anv_push_constants {
/* Push constant data provided by the client through vkPushConstants */
uint8_t client_data[MAX_PUSH_CONSTANTS_SIZE];
 
-   /* Our hardware only provides zero-based vertex and instance id so, in
-* order to satisfy the vulkan requirements, we may have to push one or
-* both of these into the shader.
-*/
-   uint32_t base_vertex;
-   uint32_t base_instance;
-
/* Image data for image_load_store on pre-SKL */
struct brw_image_param images[MAX_IMAGES];
 };
-- 
2.5.0.400.gff86faf

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

Re: [Mesa-dev] XDC 2017 feedback

[Rob Clark]

On Wed, Sep 27, 2017 at 7:25 PM, Ian Romanick  wrote:
> On 09/26/2017 09:57 AM, Daniel Vetter wrote:
>> Hi all,
>>
>> First again big thanks to Stéphane and Jennifer for organizing a great XDC.
>>
>> Like last year we'd like to hear feedback on how this year's XDC went,
>> both the good (and what you'd like to see more of) and the not so
>> good. Talk selection, organization, location, scheduling of talks,
>> anything really.
>
> Not scheduling it to conflict with another industry event would be a
> good start.  This is the first XDC that I've missed in nearly a decade.
> I know I'm not the only person that missed one or the other due to
> scheduling fail.
>

Sadly by the time we were aware of the dates for the khronos f2f it
was not possible to change the dates for XDC :-(

The XDC dates were set in Feb, and afaict the khronos dates were
announced in July (?), so take this up with khronos ;-)

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

Re: [Mesa-dev] XDC 2017 feedback

[Ryan Houdek]

It was a great time! Next year I should pay more attention that this was
happening so I don't sign up at the last moment causing me to miss a day,
and having a fever on the last day.
Looking forward to next year's!

On Wed, Sep 27, 2017 at 4:25 PM, Ian Romanick  wrote:

> On 09/26/2017 09:57 AM, Daniel Vetter wrote:
> > Hi all,
> >
> > First again big thanks to Stéphane and Jennifer for organizing a great
> XDC.
> >
> > Like last year we'd like to hear feedback on how this year's XDC went,
> > both the good (and what you'd like to see more of) and the not so
> > good. Talk selection, organization, location, scheduling of talks,
> > anything really.
>
> Not scheduling it to conflict with another industry event would be a
> good start.  This is the first XDC that I've missed in nearly a decade.
> I know I'm not the only person that missed one or the other due to
> scheduling fail.
>
> > Here's a few things we took into account from Helsinki and tried to
> apply:
> > - More breaks for more hallway track.
> > - Try to schedule the hot topics on the first day (did we pick the
> > right ones) for better hallway track.
> > - More lightning talk time to give all the late/rejected submissions
> > some place to give a quick showcase.
> >
> > Things that didn't work out perfectly this year and that we'll try to
> > get better at next year:
> > - Lots of people missed the submission deadline and their talks were
> > rejected only because of that. We'll do better PR by sending out a
> > pile of reminders.
> > - Comparitively few people asked for travel assistance. No idea
> > whether this was a year with more budget around, or whether this isn't
> > all that well know and we need to make more PR in maybe the call for
> > papers about it.
> >
> > But that's just the stuff we've gathered already, we'd like to hear
> > more feedback. Just reply to this mail or send a mail to
> > bo...@foundation.x.org if you don't want the entire world to read it.
> > And if you want to send at pseudonymous feedback, drop a pastebin onto
> > the #xf-bod channel on the OFTC irc server.
> >
> > Thanks, Daniel
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: fix texture updates for ATI_fragment_shader

[Ian Romanick]

This looks right... at least it makes ATI_fragment_shader behave like
ARB_fragment_program.  I don't suppose there are any tests that exercise
this problem?  Should this be tagged for stable?

On 09/27/2017 08:39 AM, Marek Olšák wrote:
> From: Marek Olšák 
> 
> ---
>  src/mesa/main/texstate.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/src/mesa/main/texstate.c b/src/mesa/main/texstate.c
> index 269e291..edd2253 100644
> --- a/src/mesa/main/texstate.c
> +++ b/src/mesa/main/texstate.c
> @@ -833,23 +833,25 @@ update_ff_texture_state(struct gl_context *ctx,
>  void
>  _mesa_update_texture_state(struct gl_context *ctx)
>  {
> struct gl_program *prog[MESA_SHADER_STAGES];
> int i;
> int old_max_unit = ctx->Texture._MaxEnabledTexImageUnit;
> BITSET_DECLARE(enabled_texture_units, MAX_COMBINED_TEXTURE_IMAGE_UNITS);
>  
> memcpy(prog, ctx->_Shader->CurrentProgram, sizeof(prog));
>  
> -   if (prog[MESA_SHADER_FRAGMENT] == NULL &&
> -   _mesa_arb_fragment_program_enabled(ctx)) {
> -  prog[MESA_SHADER_FRAGMENT] = ctx->FragmentProgram.Current;
> +   if (prog[MESA_SHADER_FRAGMENT] == NULL) {
> +  if (_mesa_arb_fragment_program_enabled(ctx))
> + prog[MESA_SHADER_FRAGMENT] = ctx->FragmentProgram.Current;
> +  else if (_mesa_ati_fragment_shader_enabled(ctx))
> + prog[MESA_SHADER_FRAGMENT] = 
> ctx->ATIFragmentShader.Current->Program;
> }
>  
> /* TODO: only set this if there are actual changes */
> ctx->NewState |= _NEW_TEXTURE_OBJECT | _NEW_TEXTURE_STATE;
>  
> ctx->Texture._GenFlags = 0x0;
> ctx->Texture._TexMatEnabled = 0x0;
> ctx->Texture._TexGenEnabled = 0x0;
> ctx->Texture._MaxEnabledTexImageUnit = -1;
> ctx->Texture._EnabledCoordUnits = 0x0;
> 

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

Re: [Mesa-dev] [PATCH] vc4: Mark BOs as purgeable when they enter the BO cache

[Eric Anholt]

Boris Brezillon  writes:

> On Wed, 27 Sep 2017 12:41:52 -0700
> Eric Anholt  wrote:
>
>> Boris Brezillon  writes:
>> 
>> > On Wed, 27 Sep 2017 10:15:23 -0700
>> > Eric Anholt  wrote:
>> >  
>> >> Boris Brezillon  writes:
>> >>   
>> >> > On Wed, 27 Sep 2017 15:24:16 +0100
>> >> > Chris Wilson  wrote:
>> >> >
>> >> >> Quoting Boris Brezillon (2017-09-27 15:06:53)
>> >> >> > On Wed, 27 Sep 2017 14:50:10 +0100
>> >> >> > Chris Wilson  wrote:
>> >> >> >   
>> >> >> > > Quoting Boris Brezillon (2017-09-27 14:45:17)  
>> >> >> > > >  static struct vc4_bo *
>> >> >> > > >  vc4_bo_from_cache(struct vc4_screen *screen, uint32_t size, 
>> >> >> > > > const char *name)
>> >> >> > > >  {
>> >> >> > > > @@ -111,6 +121,11 @@ vc4_bo_from_cache(struct vc4_screen 
>> >> >> > > > *screen, uint32_t size, const char *name)
>> >> >> > > >  return NULL;
>> >> >> > > >  }
>> >> >> > > >  
>> >> >> > > > +if (vc4_bo_purgeable(bo, false)) {
>> >> >> > > > +mtx_unlock(>lock);
>> >> >> > > > +return NULL;
>> >> >> > > 
>> >> >> > > So this would just mean that the bo was purged in the meantime. 
>> >> >> > > Why not
>> >> >> > > just try to use the next one in the cache or allocate afresh?  
>> >> >> > 
>> >> >> > No, this means the BO was purged and the kernel failed to allocate 
>> >> >> > the
>> >> >> > memory back. We don't care about the retained status here, because we
>> >> >> > don't need to restore BO's content, that's why we're not checking
>> >> >> > arg.retained in vc4_bo_purgeable(). Allocating a fresh BO is likely 
>> >> >> > to
>> >> >> > fail with the same ENOMEM error because both path use the CMA mem.   
>> >> >> >
>> >> >> 
>> >> >> Hmm, you don't treat purging as permanent. But you do track the lose of
>> >> >> contents, so retained is false?
>> >> >
>> >> > vc4_bo_purgeable() is not reporting the retained status, it just
>> >> > reports whether the BO can be used or not. I can change
>> >> > vc4_bo_purgeable() semantic to return 1 if the BO content was retained,
>> >> > 0 if it was purged and -1 if you the ioctl returned an error (ENOMEM)
>> >> > if you prefer, but in the end, all I'll check here is
>> >> > 'vc4_bo_purgeable() >= 0' because I don't don't care about the retained
>> >> > status in this specific use case, all I care about is whether the BO can
>> >> > be re-used or not (IOW, is there a valid CMA region attached to the BO).
>> >> >
>> >> >> 
>> >> >> I took a harder line, and said that userspace should recreate the 
>> >> >> object
>> >> >> from scratch after it was purged. I thought that would be easier
>> >> >> overall. But maybe not.:)
>> >> >
>> >> > Well, maybe I'm wrong in how I implemented this
>> >> > DRM_IOCTL_VC4_GEM_MADVISE ioctl, but right now, when the BO has been
>> >> > purged and someone marks it back as unpurgeable I'm trying to
>> >> > re-allocate BO's buffer in the ioctl path, and if the CMA allocation
>> >> > fails I return -ENOMEM. I could move the allocation in the fault
>> >> > handler, but this would result in pretty much the same behavior except
>> >> > it would require an extra page-fault to realize the memory is not
>> >> > available or force us to check the retained status and decide to
>> >> > release the BO object from the BO cache.
>> >> 
>> >> Hmm.  The downside I see to this plan is if we eventually decide to have
>> >> the purge operation not clear all the BOs, then we would probably rather
>> >> have userspace freeing objects that had been purged until it finds one
>> >> in the cache that hadn't been purged, rather than forcing reallocation
>> >> of this BO now (and possibly then purging something from elsewhere in
>> >> the cache).  
>> >
>> > Okay, that's a good reason to move dma_alloc_wc() in the page-fault
>> > path. I need to change a bit the implementation to check cma_gem->vaddr
>> > value instead of checking bo->madv != __VC4_MADV_PURGED, otherwise we
>> > might pass a non-allocated BO to the GPU/Display-Engine.  
>> 
>> Huh, allocation in the page-fault path?  We would need the storage to be
>> definitely be available at the point that we've set it back to WILLNEED.
>> Otherwise I'll "allocate" the BO from the cache, go to fill it through
>> my mapping, and sigbus when CMA says we're out of memory.
>
> Yep, I find that weird too, but that's unfortunately the only way we can
> achieve what you want to do.
>
> The only solution to know the ->retained status is by asking the the DRM
> driver to put the BO in WILLNEED or DONTNEED state. If you send ->madv
> = DONTNEED, and the kernel returns ->retained = true, this ->retained
> state may not be valid anymore when you get back to the application,
> because someone else 

[Mesa-dev] [PATCH] meson: remove duplicate libisl dependency in anv

[Dylan Baker]

Signed-off-by: Dylan Baker 
CC: Kristian Høgsberg 
---
 src/intel/vulkan/meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/vulkan/meson.build b/src/intel/vulkan/meson.build
index 9f0ee558e8a..a0be95c747c 100644
--- a/src/intel/vulkan/meson.build
+++ b/src/intel/vulkan/meson.build
@@ -144,7 +144,7 @@ libvulkan_intel = shared_library(
   include_directories : [inc_common, inc_intel, inc_compiler, inc_drm_uapi,
  inc_vulkan_util, inc_vulkan_wsi],
   link_whole : [libanv_common, libanv_gen_libs],
-  link_with : [libintel_compiler, libintel_common, libisl, libisl, libblorp,
+  link_with : [libintel_compiler, libintel_common, libisl, libblorp,
libvulkan_util, libvulkan_wsi, libnir, libmesa_util],
   dependencies : [dep_libdrm, dep_thread, dep_dl, dep_m, anv_deps, 
dep_valgrind],
   c_args : [c_vis_args, no_override_init_args, '-msse2', anv_flags],
-- 
2.14.1

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

Re: [Mesa-dev] XDC 2017 feedback

[Ian Romanick]

On 09/26/2017 09:57 AM, Daniel Vetter wrote:
> Hi all,
> 
> First again big thanks to Stéphane and Jennifer for organizing a great XDC.
> 
> Like last year we'd like to hear feedback on how this year's XDC went,
> both the good (and what you'd like to see more of) and the not so
> good. Talk selection, organization, location, scheduling of talks,
> anything really.

Not scheduling it to conflict with another industry event would be a
good start.  This is the first XDC that I've missed in nearly a decade.
I know I'm not the only person that missed one or the other due to
scheduling fail.

> Here's a few things we took into account from Helsinki and tried to apply:
> - More breaks for more hallway track.
> - Try to schedule the hot topics on the first day (did we pick the
> right ones) for better hallway track.
> - More lightning talk time to give all the late/rejected submissions
> some place to give a quick showcase.
> 
> Things that didn't work out perfectly this year and that we'll try to
> get better at next year:
> - Lots of people missed the submission deadline and their talks were
> rejected only because of that. We'll do better PR by sending out a
> pile of reminders.
> - Comparitively few people asked for travel assistance. No idea
> whether this was a year with more budget around, or whether this isn't
> all that well know and we need to make more PR in maybe the call for
> papers about it.
> 
> But that's just the stuff we've gathered already, we'd like to hear
> more feedback. Just reply to this mail or send a mail to
> bo...@foundation.x.org if you don't want the entire world to read it.
> And if you want to send at pseudonymous feedback, drop a pastebin onto
> the #xf-bod channel on the OFTC irc server.
> 
> Thanks, Daniel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radv: set image view type when decompressing depth surfaces

[Bas Nieuwenhuizen]

Reviewed-by: Bas Nieuwenhuizen 

On Wed, Sep 27, 2017 at 2:09 PM, Samuel Pitoiset
 wrote:
> This was missing.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_meta_decompress.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/src/amd/vulkan/radv_meta_decompress.c 
> b/src/amd/vulkan/radv_meta_decompress.c
> index 4ff4e41ea7..fedcfad3ae 100644
> --- a/src/amd/vulkan/radv_meta_decompress.c
> +++ b/src/amd/vulkan/radv_meta_decompress.c
> @@ -311,6 +311,7 @@ radv_decompress_depth_image_inplace(struct 
> radv_cmd_buffer *cmd_buffer,
>  &(VkImageViewCreateInfo) {
>  .sType = 
> VK_STRUCTURE_TYPE_IMAGE_VIEW_CREATE_INFO,
>  .image = 
> radv_image_to_handle(image),
> +.viewType = 
> radv_meta_get_view_type(image),
>  .format = image->vk_format,
>  .subresourceRange = {
>  .aspectMask = 
> VK_IMAGE_ASPECT_DEPTH_BIT,
> --
> 2.14.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] radv: set image view type when decompressing depth surfaces

[Samuel Pitoiset]

This was missing.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_meta_decompress.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/amd/vulkan/radv_meta_decompress.c 
b/src/amd/vulkan/radv_meta_decompress.c
index 4ff4e41ea7..fedcfad3ae 100644
--- a/src/amd/vulkan/radv_meta_decompress.c
+++ b/src/amd/vulkan/radv_meta_decompress.c
@@ -311,6 +311,7 @@ radv_decompress_depth_image_inplace(struct radv_cmd_buffer 
*cmd_buffer,
 &(VkImageViewCreateInfo) {
 .sType = 
VK_STRUCTURE_TYPE_IMAGE_VIEW_CREATE_INFO,
 .image = 
radv_image_to_handle(image),
+.viewType = 
radv_meta_get_view_type(image),
 .format = image->vk_format,
 .subresourceRange = {
 .aspectMask = 
VK_IMAGE_ASPECT_DEPTH_BIT,
-- 
2.14.1

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

Re: [Mesa-dev] [PATCH] util: fix in-class initialization of static member

[Vinson Lee]

On Wed, Sep 27, 2017 at 12:36 PM, Thomas Helland
 wrote:
> string_buffer_test.cpp:43: error: ISO C++ forbids initialization of
> member ‘str1’
> string_buffer_test.cpp:43: error: making ‘str1’ static
> string_buffer_test.cpp:43: error: invalid in-class initialization of
> static data member of non-integral type ‘const char*’
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103002
> ---
>  src/util/tests/string_buffer/string_buffer_test.cpp | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/src/util/tests/string_buffer/string_buffer_test.cpp 
> b/src/util/tests/string_buffer/string_buffer_test.cpp
> index c3d43cb67b..545f607fad 100644
> --- a/src/util/tests/string_buffer/string_buffer_test.cpp
> +++ b/src/util/tests/string_buffer/string_buffer_test.cpp
> @@ -40,9 +40,9 @@ class string_buffer : public ::testing::Test {
>  public:
>
> struct _mesa_string_buffer *buf;
> -   const char *str1 = "test1";
> -   const char *str2 = "test2";
> -   const char *str3 = "test1test2";
> +   const char *str1;
> +   const char *str2;
> +   const char *str3;
> char str4[80];
> char str5[40];
>
> @@ -53,6 +53,9 @@ public:
>  void
>  string_buffer::SetUp()
>  {
> +   str1 = "test1";
> +   str2 = "test2";
> +   str3 = "test1test2";
> buf = _mesa_string_buffer_create(NULL, INITIAL_BUF_SIZE);
>  }
>
> --
> 2.14.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Tested that this patch fixes g++ 4.4 build error.

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

Re: [Mesa-dev] [PATCH 2/2] wayland-drm: constify the callbacks struct, take 2

[Derek Foreman]

On 2017-09-27 01:49 PM, Emil Velikov wrote:

From: Emil Velikov 

Now that wayland-drm (correctly) keeps a local copy of the callbacks,
this should not longer cause explosions.

After all the symbol is a local, constant data.

Cc: Daniel Stone 
Cc: Derek Foreman 
Signed-off-by: Emil Velikov 
---
Derek, can you please check the series on your end.

I've ran this through wayland (xwayland and drm) + mpv and the simple
weston demos (simple-egl, simple-damage, flowers, smoke, editor)


of the weston demos, I think only simple-egl is actually an egl user, 
but thanks for being thorough. :)


The series looks good to me, and functions well in my testing too.

Tested-by: Derek Foreman 


---
  src/egl/drivers/dri2/egl_dri2.c   | 14 +-
  src/egl/wayland/wayland-drm/wayland-drm.c |  2 +-
  src/egl/wayland/wayland-drm/wayland-drm.h |  2 +-
  3 files changed, 7 insertions(+), 11 deletions(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index adcaae0bab7..a0e8b0be5b0 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -2730,17 +2730,16 @@ dri2_wl_release_buffer(void *user_data, struct 
wl_drm_buffer *buffer)
 dri2_dpy->image->destroyImage(buffer->driver_buffer);
  }
  
-static struct wayland_drm_callbacks wl_drm_callbacks = {

-.authenticate = NULL,
-.reference_buffer = dri2_wl_reference_buffer,
-.release_buffer = dri2_wl_release_buffer
-};
-
  static EGLBoolean
  dri2_bind_wayland_display_wl(_EGLDriver *drv, _EGLDisplay *disp,
   struct wl_display *wl_dpy)
  {
 struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
+   const struct wayland_drm_callbacks wl_drm_callbacks = {
+  .authenticate = (int(*)(void *, uint32_t)) dri2_dpy->vtbl->authenticate,
+  .reference_buffer = dri2_wl_reference_buffer,
+  .release_buffer = dri2_wl_release_buffer
+   };
 int flags = 0;
 uint64_t cap;
  
@@ -2749,9 +2748,6 @@ dri2_bind_wayland_display_wl(_EGLDriver *drv, _EGLDisplay *disp,

 if (dri2_dpy->wl_server_drm)
 return EGL_FALSE;
  
-   wl_drm_callbacks.authenticate =

-  (int(*)(void *, uint32_t)) dri2_dpy->vtbl->authenticate;
-
 if (drmGetCap(dri2_dpy->fd, DRM_CAP_PRIME, ) == 0 &&
 cap == (DRM_PRIME_CAP_IMPORT | DRM_PRIME_CAP_EXPORT) &&
 dri2_dpy->image->base.version >= 7 &&
diff --git a/src/egl/wayland/wayland-drm/wayland-drm.c 
b/src/egl/wayland/wayland-drm/wayland-drm.c
index 0f0a2317c7e..73dfba9600e 100644
--- a/src/egl/wayland/wayland-drm/wayland-drm.c
+++ b/src/egl/wayland/wayland-drm/wayland-drm.c
@@ -259,7 +259,7 @@ wayland_drm_buffer_get(struct wl_drm *drm, struct 
wl_resource *resource)
  
  struct wl_drm *

  wayland_drm_init(struct wl_display *display, char *device_name,
- struct wayland_drm_callbacks *callbacks, void *user_data,
+ const struct wayland_drm_callbacks *callbacks, void 
*user_data,
   uint32_t flags)
  {
struct wl_drm *drm;
diff --git a/src/egl/wayland/wayland-drm/wayland-drm.h 
b/src/egl/wayland/wayland-drm/wayland-drm.h
index 77e8d273042..111383ff1d6 100644
--- a/src/egl/wayland/wayland-drm/wayland-drm.h
+++ b/src/egl/wayland/wayland-drm/wayland-drm.h
@@ -34,7 +34,7 @@ wayland_drm_buffer_get(struct wl_drm *drm, struct wl_resource 
*resource);
  
  struct wl_drm *

  wayland_drm_init(struct wl_display *display, char *device_name,
-struct wayland_drm_callbacks *callbacks, void *user_data,
+const struct wayland_drm_callbacks *callbacks, void *user_data,
   uint32_t flags);
  
  void




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

Re: [Mesa-dev] [PATCH] vc4: Mark BOs as purgeable when they enter the BO cache

[Boris Brezillon]

On Wed, 27 Sep 2017 22:03:15 +0200
Boris Brezillon  wrote:

> On Wed, 27 Sep 2017 12:41:52 -0700
> Eric Anholt  wrote:
> 
> > Boris Brezillon  writes:
> >   
> > > On Wed, 27 Sep 2017 10:15:23 -0700
> > > Eric Anholt  wrote:
> > >
> > >> Boris Brezillon  writes:
> > >> 
> > >> > On Wed, 27 Sep 2017 15:24:16 +0100
> > >> > Chris Wilson  wrote:
> > >> >  
> > >> >> Quoting Boris Brezillon (2017-09-27 15:06:53)  
> > >> >> > On Wed, 27 Sep 2017 14:50:10 +0100
> > >> >> > Chris Wilson  wrote:
> > >> >> > 
> > >> >> > > Quoting Boris Brezillon (2017-09-27 14:45:17)
> > >> >> > > >  static struct vc4_bo *
> > >> >> > > >  vc4_bo_from_cache(struct vc4_screen *screen, uint32_t size, 
> > >> >> > > > const char *name)
> > >> >> > > >  {
> > >> >> > > > @@ -111,6 +121,11 @@ vc4_bo_from_cache(struct vc4_screen 
> > >> >> > > > *screen, uint32_t size, const char *name)
> > >> >> > > >  return NULL;
> > >> >> > > >  }
> > >> >> > > >  
> > >> >> > > > +if (vc4_bo_purgeable(bo, false)) {
> > >> >> > > > +mtx_unlock(>lock);
> > >> >> > > > +return NULL;  
> > >> >> > > 
> > >> >> > > So this would just mean that the bo was purged in the meantime. 
> > >> >> > > Why not
> > >> >> > > just try to use the next one in the cache or allocate afresh? 
> > >> >> > >
> > >> >> > 
> > >> >> > No, this means the BO was purged and the kernel failed to allocate 
> > >> >> > the
> > >> >> > memory back. We don't care about the retained status here, because 
> > >> >> > we
> > >> >> > don't need to restore BO's content, that's why we're not checking
> > >> >> > arg.retained in vc4_bo_purgeable(). Allocating a fresh BO is likely 
> > >> >> > to
> > >> >> > fail with the same ENOMEM error because both path use the CMA mem.  
> > >> >> >   
> > >> >> 
> > >> >> Hmm, you don't treat purging as permanent. But you do track the lose 
> > >> >> of
> > >> >> contents, so retained is false?  
> > >> >
> > >> > vc4_bo_purgeable() is not reporting the retained status, it just
> > >> > reports whether the BO can be used or not. I can change
> > >> > vc4_bo_purgeable() semantic to return 1 if the BO content was retained,
> > >> > 0 if it was purged and -1 if you the ioctl returned an error (ENOMEM)
> > >> > if you prefer, but in the end, all I'll check here is
> > >> > 'vc4_bo_purgeable() >= 0' because I don't don't care about the retained
> > >> > status in this specific use case, all I care about is whether the BO 
> > >> > can
> > >> > be re-used or not (IOW, is there a valid CMA region attached to the 
> > >> > BO).
> > >> >  
> > >> >> 
> > >> >> I took a harder line, and said that userspace should recreate the 
> > >> >> object
> > >> >> from scratch after it was purged. I thought that would be easier
> > >> >> overall. But maybe not.:)  
> > >> >
> > >> > Well, maybe I'm wrong in how I implemented this
> > >> > DRM_IOCTL_VC4_GEM_MADVISE ioctl, but right now, when the BO has been
> > >> > purged and someone marks it back as unpurgeable I'm trying to
> > >> > re-allocate BO's buffer in the ioctl path, and if the CMA allocation
> > >> > fails I return -ENOMEM. I could move the allocation in the fault
> > >> > handler, but this would result in pretty much the same behavior except
> > >> > it would require an extra page-fault to realize the memory is not
> > >> > available or force us to check the retained status and decide to
> > >> > release the BO object from the BO cache.  
> > >> 
> > >> Hmm.  The downside I see to this plan is if we eventually decide to have
> > >> the purge operation not clear all the BOs, then we would probably rather
> > >> have userspace freeing objects that had been purged until it finds one
> > >> in the cache that hadn't been purged, rather than forcing reallocation
> > >> of this BO now (and possibly then purging something from elsewhere in
> > >> the cache).
> > >
> > > Okay, that's a good reason to move dma_alloc_wc() in the page-fault
> > > path. I need to change a bit the implementation to check cma_gem->vaddr
> > > value instead of checking bo->madv != __VC4_MADV_PURGED, otherwise we
> > > might pass a non-allocated BO to the GPU/Display-Engine.
> > 
> > Huh, allocation in the page-fault path?  We would need the storage to be
> > definitely be available at the point that we've set it back to WILLNEED.
> > Otherwise I'll "allocate" the BO from the cache, go to fill it through
> > my mapping, and sigbus when CMA says we're out of memory.  
> 
> Yep, I find that weird too, but that's unfortunately the only way we can
> achieve what you want to do.
> 
> The only solution to know the ->retained status is by asking the the DRM
> driver to put the BO 

Re: [Mesa-dev] [PATCH] vc4: Mark BOs as purgeable when they enter the BO cache

[Boris Brezillon]

On Wed, 27 Sep 2017 12:41:52 -0700
Eric Anholt  wrote:

> Boris Brezillon  writes:
> 
> > On Wed, 27 Sep 2017 10:15:23 -0700
> > Eric Anholt  wrote:
> >  
> >> Boris Brezillon  writes:
> >>   
> >> > On Wed, 27 Sep 2017 15:24:16 +0100
> >> > Chris Wilson  wrote:
> >> >
> >> >> Quoting Boris Brezillon (2017-09-27 15:06:53)
> >> >> > On Wed, 27 Sep 2017 14:50:10 +0100
> >> >> > Chris Wilson  wrote:
> >> >> >   
> >> >> > > Quoting Boris Brezillon (2017-09-27 14:45:17)  
> >> >> > > >  static struct vc4_bo *
> >> >> > > >  vc4_bo_from_cache(struct vc4_screen *screen, uint32_t size, 
> >> >> > > > const char *name)
> >> >> > > >  {
> >> >> > > > @@ -111,6 +121,11 @@ vc4_bo_from_cache(struct vc4_screen *screen, 
> >> >> > > > uint32_t size, const char *name)
> >> >> > > >  return NULL;
> >> >> > > >  }
> >> >> > > >  
> >> >> > > > +if (vc4_bo_purgeable(bo, false)) {
> >> >> > > > +mtx_unlock(>lock);
> >> >> > > > +return NULL;
> >> >> > > 
> >> >> > > So this would just mean that the bo was purged in the meantime. Why 
> >> >> > > not
> >> >> > > just try to use the next one in the cache or allocate afresh?  
> >> >> > 
> >> >> > No, this means the BO was purged and the kernel failed to allocate the
> >> >> > memory back. We don't care about the retained status here, because we
> >> >> > don't need to restore BO's content, that's why we're not checking
> >> >> > arg.retained in vc4_bo_purgeable(). Allocating a fresh BO is likely to
> >> >> > fail with the same ENOMEM error because both path use the CMA mem.
> >> >> >   
> >> >> 
> >> >> Hmm, you don't treat purging as permanent. But you do track the lose of
> >> >> contents, so retained is false?
> >> >
> >> > vc4_bo_purgeable() is not reporting the retained status, it just
> >> > reports whether the BO can be used or not. I can change
> >> > vc4_bo_purgeable() semantic to return 1 if the BO content was retained,
> >> > 0 if it was purged and -1 if you the ioctl returned an error (ENOMEM)
> >> > if you prefer, but in the end, all I'll check here is
> >> > 'vc4_bo_purgeable() >= 0' because I don't don't care about the retained
> >> > status in this specific use case, all I care about is whether the BO can
> >> > be re-used or not (IOW, is there a valid CMA region attached to the BO).
> >> >
> >> >> 
> >> >> I took a harder line, and said that userspace should recreate the object
> >> >> from scratch after it was purged. I thought that would be easier
> >> >> overall. But maybe not.:)
> >> >
> >> > Well, maybe I'm wrong in how I implemented this
> >> > DRM_IOCTL_VC4_GEM_MADVISE ioctl, but right now, when the BO has been
> >> > purged and someone marks it back as unpurgeable I'm trying to
> >> > re-allocate BO's buffer in the ioctl path, and if the CMA allocation
> >> > fails I return -ENOMEM. I could move the allocation in the fault
> >> > handler, but this would result in pretty much the same behavior except
> >> > it would require an extra page-fault to realize the memory is not
> >> > available or force us to check the retained status and decide to
> >> > release the BO object from the BO cache.
> >> 
> >> Hmm.  The downside I see to this plan is if we eventually decide to have
> >> the purge operation not clear all the BOs, then we would probably rather
> >> have userspace freeing objects that had been purged until it finds one
> >> in the cache that hadn't been purged, rather than forcing reallocation
> >> of this BO now (and possibly then purging something from elsewhere in
> >> the cache).  
> >
> > Okay, that's a good reason to move dma_alloc_wc() in the page-fault
> > path. I need to change a bit the implementation to check cma_gem->vaddr
> > value instead of checking bo->madv != __VC4_MADV_PURGED, otherwise we
> > might pass a non-allocated BO to the GPU/Display-Engine.  
> 
> Huh, allocation in the page-fault path?  We would need the storage to be
> definitely be available at the point that we've set it back to WILLNEED.
> Otherwise I'll "allocate" the BO from the cache, go to fill it through
> my mapping, and sigbus when CMA says we're out of memory.

Yep, I find that weird too, but that's unfortunately the only way we can
achieve what you want to do.

The only solution to know the ->retained status is by asking the the DRM
driver to put the BO in WILLNEED or DONTNEED state. If you send ->madv
= DONTNEED, and the kernel returns ->retained = true, this ->retained
state may not be valid anymore when you get back to the application,
because someone else may have triggered a purge. If you send ->madv =
WILLNEED then the ->retained state is guaranteed to be valid until you
explicitly switch back to DONTNEED, but that also means the driver has
already 

Re: [Mesa-dev] [PATCH] st/dri: don't expose modifiers in EGL if the driver doesn't implement them

[Andy Furniss]

Marek Olšák wrote:


Sorry too late, I pushed it.

I don't know if stable is affected.


It regresses things starting on radeonsi using weston eg.

mpv -

[vo/opengl/wayland] error occurred on the display fd: closing file 
descriptor


kodi -

terminate called after throwing an instance of 'std::system_error'
  what():  wl_display_dispatch_pending: Protocol error

weston-simple-egl -

[destroyed object]: error 7: importing the supplied dmabufs failed
Error sending request: Broken pipe
has EGL_EXT_buffer_age and EGL_EXT_swap_buffers_with_damage
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] vc4: Mark BOs as purgeable when they enter the BO cache

[Eric Anholt]

Boris Brezillon  writes:

> On Wed, 27 Sep 2017 10:15:23 -0700
> Eric Anholt  wrote:
>
>> Boris Brezillon  writes:
>> 
>> > On Wed, 27 Sep 2017 15:24:16 +0100
>> > Chris Wilson  wrote:
>> >  
>> >> Quoting Boris Brezillon (2017-09-27 15:06:53)  
>> >> > On Wed, 27 Sep 2017 14:50:10 +0100
>> >> > Chris Wilson  wrote:
>> >> > 
>> >> > > Quoting Boris Brezillon (2017-09-27 14:45:17)
>> >> > > >  static struct vc4_bo *
>> >> > > >  vc4_bo_from_cache(struct vc4_screen *screen, uint32_t size, const 
>> >> > > > char *name)
>> >> > > >  {
>> >> > > > @@ -111,6 +121,11 @@ vc4_bo_from_cache(struct vc4_screen *screen, 
>> >> > > > uint32_t size, const char *name)
>> >> > > >  return NULL;
>> >> > > >  }
>> >> > > >  
>> >> > > > +if (vc4_bo_purgeable(bo, false)) {
>> >> > > > +mtx_unlock(>lock);
>> >> > > > +return NULL;  
>> >> > > 
>> >> > > So this would just mean that the bo was purged in the meantime. Why 
>> >> > > not
>> >> > > just try to use the next one in the cache or allocate afresh?
>> >> > 
>> >> > No, this means the BO was purged and the kernel failed to allocate the
>> >> > memory back. We don't care about the retained status here, because we
>> >> > don't need to restore BO's content, that's why we're not checking
>> >> > arg.retained in vc4_bo_purgeable(). Allocating a fresh BO is likely to
>> >> > fail with the same ENOMEM error because both path use the CMA mem.
>> >> 
>> >> Hmm, you don't treat purging as permanent. But you do track the lose of
>> >> contents, so retained is false?  
>> >
>> > vc4_bo_purgeable() is not reporting the retained status, it just
>> > reports whether the BO can be used or not. I can change
>> > vc4_bo_purgeable() semantic to return 1 if the BO content was retained,
>> > 0 if it was purged and -1 if you the ioctl returned an error (ENOMEM)
>> > if you prefer, but in the end, all I'll check here is
>> > 'vc4_bo_purgeable() >= 0' because I don't don't care about the retained
>> > status in this specific use case, all I care about is whether the BO can
>> > be re-used or not (IOW, is there a valid CMA region attached to the BO).
>> >  
>> >> 
>> >> I took a harder line, and said that userspace should recreate the object
>> >> from scratch after it was purged. I thought that would be easier
>> >> overall. But maybe not.:)  
>> >
>> > Well, maybe I'm wrong in how I implemented this
>> > DRM_IOCTL_VC4_GEM_MADVISE ioctl, but right now, when the BO has been
>> > purged and someone marks it back as unpurgeable I'm trying to
>> > re-allocate BO's buffer in the ioctl path, and if the CMA allocation
>> > fails I return -ENOMEM. I could move the allocation in the fault
>> > handler, but this would result in pretty much the same behavior except
>> > it would require an extra page-fault to realize the memory is not
>> > available or force us to check the retained status and decide to
>> > release the BO object from the BO cache.  
>> 
>> Hmm.  The downside I see to this plan is if we eventually decide to have
>> the purge operation not clear all the BOs, then we would probably rather
>> have userspace freeing objects that had been purged until it finds one
>> in the cache that hadn't been purged, rather than forcing reallocation
>> of this BO now (and possibly then purging something from elsewhere in
>> the cache).
>
> Okay, that's a good reason to move dma_alloc_wc() in the page-fault
> path. I need to change a bit the implementation to check cma_gem->vaddr
> value instead of checking bo->madv != __VC4_MADV_PURGED, otherwise we
> might pass a non-allocated BO to the GPU/Display-Engine.

Huh, allocation in the page-fault path?  We would need the storage to be
definitely be available at the point that we've set it back to WILLNEED.
Otherwise I'll "allocate" the BO from the cache, go to fill it through
my mapping, and sigbus when CMA says we're out of memory.



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

[Mesa-dev] [PATCH] util: fix in-class initialization of static member

[Thomas Helland]

string_buffer_test.cpp:43: error: ISO C++ forbids initialization of
member ‘str1’
string_buffer_test.cpp:43: error: making ‘str1’ static
string_buffer_test.cpp:43: error: invalid in-class initialization of
static data member of non-integral type ‘const char*’

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103002
---
 src/util/tests/string_buffer/string_buffer_test.cpp | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/src/util/tests/string_buffer/string_buffer_test.cpp 
b/src/util/tests/string_buffer/string_buffer_test.cpp
index c3d43cb67b..545f607fad 100644
--- a/src/util/tests/string_buffer/string_buffer_test.cpp
+++ b/src/util/tests/string_buffer/string_buffer_test.cpp
@@ -40,9 +40,9 @@ class string_buffer : public ::testing::Test {
 public:
 
struct _mesa_string_buffer *buf;
-   const char *str1 = "test1";
-   const char *str2 = "test2";
-   const char *str3 = "test1test2";
+   const char *str1;
+   const char *str2;
+   const char *str3;
char str4[80];
char str5[40];
 
@@ -53,6 +53,9 @@ public:
 void
 string_buffer::SetUp()
 {
+   str1 = "test1";
+   str2 = "test2";
+   str3 = "test1test2";
buf = _mesa_string_buffer_create(NULL, INITIAL_BUF_SIZE);
 }
 
-- 
2.14.1

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

Re: [Mesa-dev] [Mesa-stable] [PATCH] st/dri: don't expose modifiers in EGL if the driver doesn't implement them

[Juan A. Suarez Romero]

On Wed, 2017-09-27 at 18:09 +0100, Emil Velikov wrote:
> On 27 September 2017 at 17:28, Marek Olšák  wrote:
> > On Wed, Sep 27, 2017 at 6:22 PM, Emil Velikov  
> > wrote:
> > > On 27 September 2017 at 16:00, Daniel Stone  wrote:
> > > > Hi Marek,
> > > > 
> > > > On 27 September 2017 at 15:55, Marek Olšák  wrote:
> > > > > if (dmabuf_ret && dmabuf_ret->val.val_bool) {
> > > > >uint64_t cap;
> > > > > 
> > > > >if (drmGetCap(sPriv->fd, DRM_CAP_PRIME, ) == 0 &&
> > > > >(cap & DRM_PRIME_CAP_IMPORT)) {
> > > > >   dri2ImageExtension.createImageFromFds = dri2_from_fds;
> > > > >   dri2ImageExtension.createImageFromDmaBufs = 
> > > > > dri2_from_dma_bufs;
> > > > >   dri2ImageExtension.createImageFromDmaBufs2 = 
> > > > > dri2_from_dma_bufs2;
> > > > >   dri2ImageExtension.queryDmaBufFormats = 
> > > > > dri2_query_dma_buf_formats;
> > > > > - dri2ImageExtension.queryDmaBufModifiers =
> > > > > -dri2_query_dma_buf_modifiers;
> > > > > + if (pscreen->query_dmabuf_modifiers) {
> > > > > +dri2ImageExtension.queryDmaBufModifiers =
> > > > > +   dri2_query_dma_buf_modifiers;
> > > > > + }
> > > > 
> > > > This should also not expose queryDmaBufFormats, since that is also
> > > > part of EGL_EXT_image_dma_buf_import_modifiers, which is pretty
> > > > useless without modifiers.
> > > > 
> > > 
> > > True, it's useless. Suggestion makes the code a bit confusing though.
> > > After all EGL already checks that all the entry points are present
> > > before advertising the extension.
> > > 
> > > Either way, I think we want this in stable, right?
> > 
> > Sorry too late, I pushed it.
> > 
> 
> No need to apologise.
> 
> > I don't know if stable is affected.
> > 
> 
> You're right - code was introduced around commit
> f84bb6a9d91521de6da4c3d1ddd8de456761efaa.
> The latter of which landed in Mesa 17.2.0-devel
> 

Not sure if I'm understanding correctly. Do you mean we don't need this
patch in stable?

J.A.

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

Re: [Mesa-dev] [PATCH] i965/fs: force pull model for 64-bit GS inputs

[Kenneth Graunke]

On Wednesday, September 27, 2017 5:21:49 AM PDT Iago Toral Quiroga wrote:
> Triggering the push model when 64-bit inputs are involved is not easy due to
> the constrains on the maximum number of registers that we allow for this mode,
> however, for GS with 'points' primitive type and just a couple of double
> varyings we can trigger this and it just doesn't work because the
> implementation is not 64-bit aware at all. For now, let's make sure that we
> don't attempt this model whith 64-bit inputs and we always fall back to pull
> model for them.
> 
> Also, don't enable the VUE handles in the thread payload on the fly when we
> find an input for which we need the pull model, this is not safe: if we need
> to resort to the pull model we need to account for that when we setup the
> thread payload so we compute the first non-payload register properly. If we
> didn't do that correctly and we enable it on-the-fly here then we will end up
> VUE handles on the first non-payload register which will probably lead to
> GPU hangs. Instead, assert that we have identified that we needed the VUE
> handles during the payload setup.
> ---
>  src/intel/compiler/brw_fs.cpp | 12 +++-
>  src/intel/compiler/brw_fs_nir.cpp |  4 +++-
>  2 files changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
> index eb9b4c3890..69b993bb55 100644
> --- a/src/intel/compiler/brw_fs.cpp
> +++ b/src/intel/compiler/brw_fs.cpp
> @@ -5605,6 +5605,15 @@ fs_visitor::setup_gs_payload()
> /* Use a maximum of 24 registers for push-model inputs. */
> const unsigned max_push_components = 24;
>  
> +   /* We don't support the push model for 64-bit inputs */
> +   bool has_64bit_inputs = false;
> +   nir_foreach_variable(var, >inputs) {
> +  if (glsl_get_bit_size(var->type->without_array()) == 64) {
> + has_64bit_inputs = true;
> + break;
> +  }
> +   }
> +
> /* If pushing our inputs would take too many registers, reduce the URB 
> read
>  * length (which is in HWords, or 8 registers), and resort to pulling.
>  *
> @@ -5612,7 +5621,8 @@ fs_visitor::setup_gs_payload()
>  * have to multiply by VerticesIn to obtain the total storage requirement.
>  */
> if (8 * vue_prog_data->urb_read_length * nir->info.gs.vertices_in >
> -   max_push_components || gs_prog_data->invocations > 1) {
> +   max_push_components || gs_prog_data->invocations > 1 ||
> +   has_64bit_inputs) {
>gs_prog_data->base.include_vue_handles = true;
>  
>/* R3..RN: ICP Handles for each incoming vertex (when using pull 
> model) */
> diff --git a/src/intel/compiler/brw_fs_nir.cpp 
> b/src/intel/compiler/brw_fs_nir.cpp
> index d760946e62..aa57bb9d78 100644
> --- a/src/intel/compiler/brw_fs_nir.cpp
> +++ b/src/intel/compiler/brw_fs_nir.cpp
> @@ -1915,7 +1915,9 @@ fs_visitor::emit_gs_input_load(const fs_reg ,
> const unsigned push_reg_count = gs_prog_data->base.urb_read_length * 8;
>  
> /* TODO: figure out push input layout for invocations == 1 */
> +   /* TODO: make this work with 64-bit inputs */
> if (gs_prog_data->invocations == 1 &&
> +   type_sz(dst.type) <= 4 &&
> offset_const != NULL && vertex_const != NULL &&
> 4 * (base_offset + offset_const->u32[0]) < push_reg_count) {
>int imm_offset = (base_offset + offset_const->u32[0]) * 4 +
> @@ -1928,7 +1930,7 @@ fs_visitor::emit_gs_input_load(const fs_reg ,
> }
>  
> /* Resort to the pull model.  Ensure the VUE handles are provided. */
> -   gs_prog_data->base.include_vue_handles = true;
> +   assert(gs_prog_data->base.include_vue_handles);

I believe a variable-indexed input would hit this path and assert fail.

The push support here is pretty sketchy.  Push inputs take up a *ton*
of register space, so even basic piglit tests seem to hit the limit
and resort to pulling at least some of them.

It might make sense to simply always include the VUE handles - that's
certainly easiest, and less buggy.

It might also make sense to stop bothering with the push model entirely.
I know it was very useful for TES inputs, but I don't recall whether I
bothered to take any performance data about push inputs for the GS. :(

> unsigned first_icp_handle = gs_prog_data->include_primitive_id ? 3 : 2;
> fs_reg icp_handle = bld.vgrf(BRW_REGISTER_TYPE_UD, 1);
> 



signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] amd/addrlib: Rename the GB_ADDR_CONFIGs to GB_ADDR_CONFIG_{SI, GFX9}

[Nicholas Miell]

On 09/27/2017 11:53 AM, Nicolai Hähnle wrote:
> On 27.09.2017 20:42, Nicholas Miell wrote:
>> Giving the same name to two different types violates the C++ One 
>> Definition
>> Rule and gcc will complain about it in LTO builds.
> 
> Oh my. What does the gcc warning look like? (I assume it's just a warning.)
> 

[5/5] Linking target src/amd/vulkan/libvulkan_radeon.so.
../src/amd/addrlib/inc/chip/gfx9/gfx9_gb_reg.h:39:7: warning: type ‘union 
GB_ADDR_CONFIG’ violates the C++ One Definition Rule [-Wodr]
 union GB_ADDR_CONFIG {
   ^
../src/amd/addrlib/inc/chip/r800/si_gb_reg.h:92:3: note: a different type is 
defined in another translation unit
 } GB_ADDR_CONFIG;
   ^
../src/amd/addrlib/inc/chip/gfx9/gfx9_gb_reg.h:74:7: note: the first difference 
of corresponding definitions is field ‘bitfields’
 } bitfields, bits;
   ^
../src/amd/addrlib/inc/chip/r800/si_gb_reg.h:90:25: note: a field with 
different name is defined in another translation unit
  unsigned int val : 32;

> Since these are auto-generated headers which are very much standardized 
> inside AMD, I'm hesitant to apply this particular patch. Certainly there 
> can't be a bug here in reality, since those are just dumb unions.
> 
> I think internally we'd rather want a namespace-based solution. Any 
> ideas? I need to reflect on this a bit...
> 
> Thanks,
> Nicolai
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] amd/addrlib: Rename the GB_ADDR_CONFIGs to GB_ADDR_CONFIG_{SI, GFX9}

[Nicolai Hähnle]

On 27.09.2017 20:42, Nicholas Miell wrote:

Giving the same name to two different types violates the C++ One Definition
Rule and gcc will complain about it in LTO builds.


Oh my. What does the gcc warning look like? (I assume it's just a warning.)

Since these are auto-generated headers which are very much standardized 
inside AMD, I'm hesitant to apply this particular patch. Certainly there 
can't be a bug here in reality, since those are just dumb unions.


I think internally we'd rather want a namespace-based solution. Any 
ideas? I need to reflect on this a bit...


Thanks,
Nicolai




Signed-off-by: Nicholas Miell 
---
  src/amd/addrlib/gfx9/gfx9addrlib.cpp| 2 +-
  src/amd/addrlib/inc/chip/gfx9/gfx9_gb_reg.h | 2 +-
  src/amd/addrlib/inc/chip/r800/si_gb_reg.h   | 2 +-
  src/amd/addrlib/r800/siaddrlib.cpp  | 4 ++--
  4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/amd/addrlib/gfx9/gfx9addrlib.cpp 
b/src/amd/addrlib/gfx9/gfx9addrlib.cpp
index edb4c6e636a..6837e0a3d9b 100644
--- a/src/amd/addrlib/gfx9/gfx9addrlib.cpp
+++ b/src/amd/addrlib/gfx9/gfx9addrlib.cpp
@@ -992,7 +992,7 @@ BOOL_32 Gfx9Lib::HwlInitGlobalParams(
  
  if (m_settings.isArcticIsland)

  {
-GB_ADDR_CONFIG gbAddrConfig;
+GB_ADDR_CONFIG_GFX9 gbAddrConfig;
  
  gbAddrConfig.u32All = pCreateIn->regValue.gbAddrConfig;
  
diff --git a/src/amd/addrlib/inc/chip/gfx9/gfx9_gb_reg.h b/src/amd/addrlib/inc/chip/gfx9/gfx9_gb_reg.h

index 823710cc189..d387dba2271 100644
--- a/src/amd/addrlib/inc/chip/gfx9/gfx9_gb_reg.h
+++ b/src/amd/addrlib/inc/chip/gfx9/gfx9_gb_reg.h
@@ -36,7 +36,7 @@
  #error "BIGENDIAN_CPU or LITTLEENDIAN_CPU must be defined"
  #endif
  
-union GB_ADDR_CONFIG {

+union GB_ADDR_CONFIG_GFX9 {
  struct {
  #ifdefined(LITTLEENDIAN_CPU)
  unsigned int   NUM_PIPES : 3;
diff --git a/src/amd/addrlib/inc/chip/r800/si_gb_reg.h 
b/src/amd/addrlib/inc/chip/r800/si_gb_reg.h
index cf67f602bdf..99a2879048b 100644
--- a/src/amd/addrlib/inc/chip/r800/si_gb_reg.h
+++ b/src/amd/addrlib/inc/chip/r800/si_gb_reg.h
@@ -89,7 +89,7 @@
  typedef union {
   unsigned int val : 32;
   GB_ADDR_CONFIG_T f;
-} GB_ADDR_CONFIG;
+} GB_ADDR_CONFIG_SI;
  
  #if   defined(LITTLEENDIAN_CPU)
  
diff --git a/src/amd/addrlib/r800/siaddrlib.cpp b/src/amd/addrlib/r800/siaddrlib.cpp

index 9ee1335b3ae..af794c2dbea 100644
--- a/src/amd/addrlib/r800/siaddrlib.cpp
+++ b/src/amd/addrlib/r800/siaddrlib.cpp
@@ -2239,7 +2239,7 @@ VOID SiLib::HwlSetupTileInfo(
  *   SiLib::DecodeGbRegs
  *
  *   @brief
-*   Decodes GB_ADDR_CONFIG and noOfBanks/noOfRanks
+*   Decodes GB_ADDR_CONFIG_SI and noOfBanks/noOfRanks
  *
  *   @return
  *   TRUE if all settings are valid
@@ -2249,7 +2249,7 @@ VOID SiLib::HwlSetupTileInfo(
  BOOL_32 SiLib::DecodeGbRegs(
  const ADDR_REGISTER_VALUE* pRegValue) ///< [in] create input
  {
-GB_ADDR_CONFIG  reg;
+GB_ADDR_CONFIG_SI  reg;
  BOOL_32 valid = TRUE;
  
  reg.val = pRegValue->gbAddrConfig;





--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/2] wayland-drm: constify the callbacks struct, take 2

[Emil Velikov]

From: Emil Velikov 

Now that wayland-drm (correctly) keeps a local copy of the callbacks,
this should not longer cause explosions.

After all the symbol is a local, constant data.

Cc: Daniel Stone 
Cc: Derek Foreman 
Signed-off-by: Emil Velikov 
---
Derek, can you please check the series on your end.

I've ran this through wayland (xwayland and drm) + mpv and the simple
weston demos (simple-egl, simple-damage, flowers, smoke, editor)
---
 src/egl/drivers/dri2/egl_dri2.c   | 14 +-
 src/egl/wayland/wayland-drm/wayland-drm.c |  2 +-
 src/egl/wayland/wayland-drm/wayland-drm.h |  2 +-
 3 files changed, 7 insertions(+), 11 deletions(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index adcaae0bab7..a0e8b0be5b0 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -2730,17 +2730,16 @@ dri2_wl_release_buffer(void *user_data, struct 
wl_drm_buffer *buffer)
dri2_dpy->image->destroyImage(buffer->driver_buffer);
 }
 
-static struct wayland_drm_callbacks wl_drm_callbacks = {
-.authenticate = NULL,
-.reference_buffer = dri2_wl_reference_buffer,
-.release_buffer = dri2_wl_release_buffer
-};
-
 static EGLBoolean
 dri2_bind_wayland_display_wl(_EGLDriver *drv, _EGLDisplay *disp,
  struct wl_display *wl_dpy)
 {
struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
+   const struct wayland_drm_callbacks wl_drm_callbacks = {
+  .authenticate = (int(*)(void *, uint32_t)) dri2_dpy->vtbl->authenticate,
+  .reference_buffer = dri2_wl_reference_buffer,
+  .release_buffer = dri2_wl_release_buffer
+   };
int flags = 0;
uint64_t cap;
 
@@ -2749,9 +2748,6 @@ dri2_bind_wayland_display_wl(_EGLDriver *drv, _EGLDisplay 
*disp,
if (dri2_dpy->wl_server_drm)
return EGL_FALSE;
 
-   wl_drm_callbacks.authenticate =
-  (int(*)(void *, uint32_t)) dri2_dpy->vtbl->authenticate;
-
if (drmGetCap(dri2_dpy->fd, DRM_CAP_PRIME, ) == 0 &&
cap == (DRM_PRIME_CAP_IMPORT | DRM_PRIME_CAP_EXPORT) &&
dri2_dpy->image->base.version >= 7 &&
diff --git a/src/egl/wayland/wayland-drm/wayland-drm.c 
b/src/egl/wayland/wayland-drm/wayland-drm.c
index 0f0a2317c7e..73dfba9600e 100644
--- a/src/egl/wayland/wayland-drm/wayland-drm.c
+++ b/src/egl/wayland/wayland-drm/wayland-drm.c
@@ -259,7 +259,7 @@ wayland_drm_buffer_get(struct wl_drm *drm, struct 
wl_resource *resource)
 
 struct wl_drm *
 wayland_drm_init(struct wl_display *display, char *device_name,
- struct wayland_drm_callbacks *callbacks, void *user_data,
+ const struct wayland_drm_callbacks *callbacks, void 
*user_data,
  uint32_t flags)
 {
struct wl_drm *drm;
diff --git a/src/egl/wayland/wayland-drm/wayland-drm.h 
b/src/egl/wayland/wayland-drm/wayland-drm.h
index 77e8d273042..111383ff1d6 100644
--- a/src/egl/wayland/wayland-drm/wayland-drm.h
+++ b/src/egl/wayland/wayland-drm/wayland-drm.h
@@ -34,7 +34,7 @@ wayland_drm_buffer_get(struct wl_drm *drm, struct wl_resource 
*resource);
 
 struct wl_drm *
 wayland_drm_init(struct wl_display *display, char *device_name,
-struct wayland_drm_callbacks *callbacks, void *user_data,
+const struct wayland_drm_callbacks *callbacks, void *user_data,
  uint32_t flags);
 
 void
-- 
2.14.1

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

[Mesa-dev] [PATCH 1/2] wayland-drm: use a copy of the wayland_drm_callbacks struct

[Emil Velikov]

From: Emil Velikov 

The callbacks may be called even when they are no longer valid.
Say, the user is dlclose(ing) libEGL while the buffers are being
destroyed.

Cc: Daniel Stone 
Cc: Derek Foreman 
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Emil Velikov 
---
 src/egl/wayland/wayland-drm/wayland-drm.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/egl/wayland/wayland-drm/wayland-drm.c 
b/src/egl/wayland/wayland-drm/wayland-drm.c
index 2e256aea6d5..0f0a2317c7e 100644
--- a/src/egl/wayland/wayland-drm/wayland-drm.c
+++ b/src/egl/wayland/wayland-drm/wayland-drm.c
@@ -47,7 +47,7 @@ struct wl_drm {
char *device_name;
 uint32_t flags;
 
-   struct wayland_drm_callbacks *callbacks;
+   struct wayland_drm_callbacks callbacks;
 
 struct wl_buffer_interface buffer_interface;
 };
@@ -58,7 +58,7 @@ destroy_buffer(struct wl_resource *resource)
struct wl_drm_buffer *buffer = wl_resource_get_user_data(resource);
struct wl_drm *drm = buffer->drm;
 
-   drm->callbacks->release_buffer(drm->user_data, buffer);
+   drm->callbacks.release_buffer(drm->user_data, buffer);
free(buffer);
 }
 
@@ -97,7 +97,7 @@ create_buffer(struct wl_client *client, struct wl_resource 
*resource,
buffer->offset[2] = offset2;
buffer->stride[2] = stride2;
 
-drm->callbacks->reference_buffer(drm->user_data, name, fd, buffer);
+drm->callbacks.reference_buffer(drm->user_data, name, fd, buffer);
if (buffer->driver_buffer == NULL) {
wl_resource_post_error(resource,
   WL_DRM_ERROR_INVALID_NAME,
@@ -189,7 +189,7 @@ drm_authenticate(struct wl_client *client,
 {
struct wl_drm *drm = wl_resource_get_user_data(resource);
 
-   if (drm->callbacks->authenticate(drm->user_data, id) < 0)
+   if (drm->callbacks.authenticate(drm->user_data, id) < 0)
wl_resource_post_error(resource,
   WL_DRM_ERROR_AUTHENTICATE_FAIL,
   "authenicate failed");
@@ -270,7 +270,7 @@ wayland_drm_init(struct wl_display *display, char 
*device_name,
 
drm->display = display;
drm->device_name = strdup(device_name);
-   drm->callbacks = callbacks;
+   drm->callbacks = *callbacks;
drm->user_data = user_data;
 drm->flags = flags;
 
-- 
2.14.1

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

Re: [Mesa-dev] [PATCH v2] egl/dri: link directly to libglapi.so

[Rob Herring]

On Wed, Sep 27, 2017 at 11:36 AM, Emil Velikov  wrote:
> From: Emil Velikov 
>
> Shared glapi (libglapi.so) has been a requirement for years, in order
> to build EGL.
>
> Remove the no longer necessary dlopen/dlsym dance and link to the
> library directly.
>
> This allows us to remove a handful of platform specific workarounds, due
> to the different name of the library.
>
> v2:
>  - Android: export the include dir (RobH)
>  - Drop unused local variable (Eric)
>
> Cc: Jonathan Gray 
> Cc: Jon Turney 
> Cc: Julien Isorce 
> Cc: Rob Herring 
> Cc: Tomasz Figa 
> Signed-off-by: Emil Velikov 
> Reviewed-by: Eric Engestrom  (v1)
> Tested-by: Tomasz Figa  (v1)
> ---
> Rob, I'd appreciate a quick check that this doesn't break on your end.

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

[Mesa-dev] [Bug 102980] weston crashes with egl use since wayland-drm: constify the callbacks struct

[bugzilla-daemon]

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

Andy Furniss  changed:

   What|Removed |Added

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

--- Comment #1 from Andy Furniss  ---
commit has been reverted.

-- 
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] amd/addrlib: Rename the GB_ADDR_CONFIGs to GB_ADDR_CONFIG_{SI, GFX9}

[Nicholas Miell]

Giving the same name to two different types violates the C++ One Definition
Rule and gcc will complain about it in LTO builds.

Signed-off-by: Nicholas Miell 
---
 src/amd/addrlib/gfx9/gfx9addrlib.cpp| 2 +-
 src/amd/addrlib/inc/chip/gfx9/gfx9_gb_reg.h | 2 +-
 src/amd/addrlib/inc/chip/r800/si_gb_reg.h   | 2 +-
 src/amd/addrlib/r800/siaddrlib.cpp  | 4 ++--
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/amd/addrlib/gfx9/gfx9addrlib.cpp 
b/src/amd/addrlib/gfx9/gfx9addrlib.cpp
index edb4c6e636a..6837e0a3d9b 100644
--- a/src/amd/addrlib/gfx9/gfx9addrlib.cpp
+++ b/src/amd/addrlib/gfx9/gfx9addrlib.cpp
@@ -992,7 +992,7 @@ BOOL_32 Gfx9Lib::HwlInitGlobalParams(
 
 if (m_settings.isArcticIsland)
 {
-GB_ADDR_CONFIG gbAddrConfig;
+GB_ADDR_CONFIG_GFX9 gbAddrConfig;
 
 gbAddrConfig.u32All = pCreateIn->regValue.gbAddrConfig;
 
diff --git a/src/amd/addrlib/inc/chip/gfx9/gfx9_gb_reg.h 
b/src/amd/addrlib/inc/chip/gfx9/gfx9_gb_reg.h
index 823710cc189..d387dba2271 100644
--- a/src/amd/addrlib/inc/chip/gfx9/gfx9_gb_reg.h
+++ b/src/amd/addrlib/inc/chip/gfx9/gfx9_gb_reg.h
@@ -36,7 +36,7 @@
 #error "BIGENDIAN_CPU or LITTLEENDIAN_CPU must be defined"
 #endif
 
-union GB_ADDR_CONFIG {
+union GB_ADDR_CONFIG_GFX9 {
 struct {
 #ifdefined(LITTLEENDIAN_CPU)
 unsigned int   NUM_PIPES : 3;
diff --git a/src/amd/addrlib/inc/chip/r800/si_gb_reg.h 
b/src/amd/addrlib/inc/chip/r800/si_gb_reg.h
index cf67f602bdf..99a2879048b 100644
--- a/src/amd/addrlib/inc/chip/r800/si_gb_reg.h
+++ b/src/amd/addrlib/inc/chip/r800/si_gb_reg.h
@@ -89,7 +89,7 @@
 typedef union {
  unsigned int val : 32;
  GB_ADDR_CONFIG_T f;
-} GB_ADDR_CONFIG;
+} GB_ADDR_CONFIG_SI;
 
 #if   defined(LITTLEENDIAN_CPU)
 
diff --git a/src/amd/addrlib/r800/siaddrlib.cpp 
b/src/amd/addrlib/r800/siaddrlib.cpp
index 9ee1335b3ae..af794c2dbea 100644
--- a/src/amd/addrlib/r800/siaddrlib.cpp
+++ b/src/amd/addrlib/r800/siaddrlib.cpp
@@ -2239,7 +2239,7 @@ VOID SiLib::HwlSetupTileInfo(
 *   SiLib::DecodeGbRegs
 *
 *   @brief
-*   Decodes GB_ADDR_CONFIG and noOfBanks/noOfRanks
+*   Decodes GB_ADDR_CONFIG_SI and noOfBanks/noOfRanks
 *
 *   @return
 *   TRUE if all settings are valid
@@ -2249,7 +2249,7 @@ VOID SiLib::HwlSetupTileInfo(
 BOOL_32 SiLib::DecodeGbRegs(
 const ADDR_REGISTER_VALUE* pRegValue) ///< [in] create input
 {
-GB_ADDR_CONFIG  reg;
+GB_ADDR_CONFIG_SI  reg;
 BOOL_32 valid = TRUE;
 
 reg.val = pRegValue->gbAddrConfig;
-- 
2.13.5

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

Re: [Mesa-dev] feature levels in clover (was: Re: [PATCH 2/2] clover: Query and export int64 atomics)

[Francisco Jerez]

Jan Vesely  writes:

> On Tue, 2017-09-26 at 14:51 -0700, Francisco Jerez wrote:
>> Jan Vesely  writes:
>> 
>> > On Wed, 2017-09-20 at 19:10 -0500, Aaron Watry wrote:
>> > > [SNIP]
>> > > 
>> > > Not trying to rain on your parade, but I've been thinking that we
>> > > might need to be able to query the installed libclc version or
>> > > possibly consider querying the libclc library for information about
>> > > which extensions are implemented (possibly even for the specific
>> > > device/target and the llvm version it was built against).
>> > > 
>> > > I've been slowly working on a printf implementation, and I'll need to
>> > > expose that based on some dynamic state of the system as well.
>> > > 
>> > > For something that's adding new extension support in libclc, we might
>> > > at least want to bump the libclc version number and ask Tom what he
>> > > did in the past related to branching off a libclc release, and then
>> > > make sure we've got a way to link against libclc (if we're not
>> > > already) and get its version number.
>> > 
>> > I disagree.
>> > Extensions need to be exposed by both clover (for host code) and clang
>> > (for clc code), synchronizing those is tricky enough. adding two more
>> > variables (libclc version, libclc clang build version) will make things
>> > intractable.
>> > 
>> > It's a lot easier (and I'd say common) for applications to check for
>> > extensions in CLC code (ifdef/ifndef) and handle all failures in
>> > generic 'build failed' error path. That makes clang the authoritative
>> > source of supported extensions for each target.
>> > Ideally, clover would get the list of supported extensions from clang
>> > (based on device target) and expose those.
>> > clang has exposed almost all extensions since at least 3.9.
>> > Implementing and exposing them (including int64 atomics) is thus a
>> > bugfix, not a feature update.
>> > 
>> > I don't want to have libclc release until the library is complete (we
>> > still miss ~12 builtins + variants). Distros now ship development
>> > snapshot and providing a released version would make more
>> > backward^Wconservative distros (ehm, debian) stuck on that version.
>> > This way we have only one version; HEAD.
>> > 
>> > I have posted patches that bring back llvm-3.9 support to libclc, thus
>> > everyone can use the latest libclcHEAD.
>> > 
>> > I agree that we need to differentiate libclc variants that follow
>> > different version of standard. Not just because of missing features,
>> > but because not all builtins should be exposed in all versions.
>> > for example: atomic_* should not be available in clc1.0.
>> > or the program can do something like this:
>> > #ifndef extension
>> > ...custom implementation of extensions function
>> > #else
>> > #pragma extension: enable
>> > #endif
>> > 
>> > I'd thus propose to add lang version suffix to libclc.
>> > *.bc.cl100 -- follows OCL-1.0 (builtins added later are not available)
>> > *.bc.cl110 -- follows OCL-1.1 (deprecated OCL-1.0 builtins/macros are
>> > not available, buitlins from 1.2 are not available)
>> > ...
>> > Current libclc would thus provide only .cl100 and .cl110 with missing
>> > builtins/bugs.
>> > 
>> > 
>> > It'd be possible for clover to check presence of such libraries and
>> > restrict CLC (and CL) feature level accordingly.
>> > 
>> 
>> Wouldn't it be easier for Clover to check which libclc version it's
>> linking against and expose a subset of language versions and extensions
>> accordingly?  That should only take a tiny bit of build system support
>> and wouldn't lock us to a single libclc release per API version (which
>> would make things tricky if extensions get back-ported by Khronos to
>> older API versions after the fact, or if people have reasons to delay
>> the implementation of a subset of extensions after a release).
>
> I don't think libclc version makes sense.
>
> atm, there are still core clc 1.0 builtins missing so we really should
> not expose even cl1.0
>
> when it comes to extensions, libclc has to implement all builtins for
> extensions exposed by clang, whether clover exposes the same extension
> or not, otherwise legal programs fail to build.

I'd argue instead that we shouldn't be letting Clang expose an extension
that is missing support code from libclc.

> I would not expect an application to check clGetDeviceInfo for
> extensions and then pass custom defines to kernel build (that's what
> ifdef cl_khr_* is for).

Why not?  It certainly seems useful to me for the host to have an
accurate view of what extensions are supported by the language.
Sometimes working around for a missing extension implies different host
behavior (e.g. if 64bit atomics are not supported there may be a 32bit
fall-back path that requires splitting up work into smaller pieces to
avoid 32bit overflow), or providing completely different kernels.

> Moreover, libclc is the easiest one to upgrade because nothing else in
> 

Re: [Mesa-dev] [PATCH] vc4: Mark BOs as purgeable when they enter the BO cache

[Boris Brezillon]

On Wed, 27 Sep 2017 10:15:23 -0700
Eric Anholt  wrote:

> Boris Brezillon  writes:
> 
> > On Wed, 27 Sep 2017 15:24:16 +0100
> > Chris Wilson  wrote:
> >  
> >> Quoting Boris Brezillon (2017-09-27 15:06:53)  
> >> > On Wed, 27 Sep 2017 14:50:10 +0100
> >> > Chris Wilson  wrote:
> >> > 
> >> > > Quoting Boris Brezillon (2017-09-27 14:45:17)
> >> > > >  static struct vc4_bo *
> >> > > >  vc4_bo_from_cache(struct vc4_screen *screen, uint32_t size, const 
> >> > > > char *name)
> >> > > >  {
> >> > > > @@ -111,6 +121,11 @@ vc4_bo_from_cache(struct vc4_screen *screen, 
> >> > > > uint32_t size, const char *name)
> >> > > >  return NULL;
> >> > > >  }
> >> > > >  
> >> > > > +if (vc4_bo_purgeable(bo, false)) {
> >> > > > +mtx_unlock(>lock);
> >> > > > +return NULL;  
> >> > > 
> >> > > So this would just mean that the bo was purged in the meantime. Why not
> >> > > just try to use the next one in the cache or allocate afresh?
> >> > 
> >> > No, this means the BO was purged and the kernel failed to allocate the
> >> > memory back. We don't care about the retained status here, because we
> >> > don't need to restore BO's content, that's why we're not checking
> >> > arg.retained in vc4_bo_purgeable(). Allocating a fresh BO is likely to
> >> > fail with the same ENOMEM error because both path use the CMA mem.
> >> 
> >> Hmm, you don't treat purging as permanent. But you do track the lose of
> >> contents, so retained is false?  
> >
> > vc4_bo_purgeable() is not reporting the retained status, it just
> > reports whether the BO can be used or not. I can change
> > vc4_bo_purgeable() semantic to return 1 if the BO content was retained,
> > 0 if it was purged and -1 if you the ioctl returned an error (ENOMEM)
> > if you prefer, but in the end, all I'll check here is
> > 'vc4_bo_purgeable() >= 0' because I don't don't care about the retained
> > status in this specific use case, all I care about is whether the BO can
> > be re-used or not (IOW, is there a valid CMA region attached to the BO).
> >  
> >> 
> >> I took a harder line, and said that userspace should recreate the object
> >> from scratch after it was purged. I thought that would be easier
> >> overall. But maybe not.:)  
> >
> > Well, maybe I'm wrong in how I implemented this
> > DRM_IOCTL_VC4_GEM_MADVISE ioctl, but right now, when the BO has been
> > purged and someone marks it back as unpurgeable I'm trying to
> > re-allocate BO's buffer in the ioctl path, and if the CMA allocation
> > fails I return -ENOMEM. I could move the allocation in the fault
> > handler, but this would result in pretty much the same behavior except
> > it would require an extra page-fault to realize the memory is not
> > available or force us to check the retained status and decide to
> > release the BO object from the BO cache.  
> 
> Hmm.  The downside I see to this plan is if we eventually decide to have
> the purge operation not clear all the BOs, then we would probably rather
> have userspace freeing objects that had been purged until it finds one
> in the cache that hadn't been purged, rather than forcing reallocation
> of this BO now (and possibly then purging something from elsewhere in
> the cache).

Okay, that's a good reason to move dma_alloc_wc() in the page-fault
path. I need to change a bit the implementation to check cma_gem->vaddr
value instead of checking bo->madv != __VC4_MADV_PURGED, otherwise we
might pass a non-allocated BO to the GPU/Display-Engine.

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

Re: [Mesa-dev] [PATCH 00/13] i965: Align1 ternary instruction support for CNL

[Matt Turner]

On Fri, Aug 25, 2017 at 6:25 PM, Matt Turner  wrote:
> Cannonlake (Gen10) adds align1 access mode to ternary instructions. In align1
> mode, instructions can use more (and mixed) datatypes and a single 16-bit
> immediate value. This series adds the infrastructure to emit and disassemble
> such instructions. Patch 12 switches ternary instructions to align1 mode, but
> does not begin using any of the new features. I'm not sure if that's worth
> committing on its own.
>
> i965: Move brw_reg_type_is_floating_point to brw_reg_type.h
> i965: Add functions for brw_reg_type <-> hw 3src type
> i965: Print subreg in units of type-size on ternary instructions
> i965: Rename brw_inst 3src functions in preparation for align1
> i965: Rename brw_inst's functions that access the 3src register type
> i965: Add functions to abstract access to 3src register types
> i965: Add align1 ternary instruction field encodings
> i965: Add align1 ternary instruction support to conversion functions
> i965: Add align1 ternary instruction-word support
> i965: Add align1 ternary instruction disassembler support
> i965: Add align1 ternary instruction emission support
> i965/fs: Use align1 mode on ternary instructions on Gen10+
> i965/fs: Don't apply POW/FDIV workaround on Gen10+

Ping for review. These patches have now been on the list for a full
month without eliciting a single comment.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] initial meson port

[Rob Herring]

On Wed, Sep 27, 2017 at 12:38 PM, Eric Anholt  wrote:
> Dylan Baker  writes:
>
>> [ Unknown signature status ]
>> I've gone ahead and pushed the Vulkan drivers meson builds.
>>
>> For those interested in helping finish the conversion, I have a branch
>> "wip/meson-4" on my github (github.com/dcbaker/mesa) that has i965 and most 
>> of
>> the core classic mesa stack building. I'm working on GLX, then EGL to start
>> testing this stack. Getting gallium building is my next step after that 
>> (it'll
>> be RadeonSI because I have hardware).
>>
>> I'm also working on getting features into upstream meson to make meson more
>> comfortable for mesa. Currently there are patches landed or pending for the 
>> two
>> workarounds in the meson build we have currently (choosing the right linker 
>> and
>> indexing into CustomTargets). I'm also still thinking about how we can share
>> source files with the other 3 build systems already in mesa (autotools and
>> android being the most important, since hopefully our meson will be able to
>> support windows in the future, I don't know what will happen when android 
>> moves
>> to blueprint/soong). If there is anything else please let me know.
>
> Talking with ChromeOS folks at XDC, it sounded like having Android.mk be
> a small wrapper around another build system is a totally acceptable and
> not unusual thing to do.  Rob, does that seem possible/OK to you?  It
> seems like that should seriously reduce the android maintenance burden.

I haven't come across any examples doing that, but it seems fine to me
if that can work. I'd guess we just need to create a prebuilt target
and somehow trigger it to run meson. It could be problematic if
anything in mesa is a dependency on another project as there's some
expectations about where things are built. But I don't think mesa is a
dependency for anything.

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

[Mesa-dev] [PATCH v2] broadcom: Fix out-of-tree build include path

[Daniel Stone]

Cc: Eric Anholt 
Fixes: 5b102160ae ("broadcom/genxml: Introduce a V3D packet/struct decoder.")
---
 src/broadcom/Makefile.cle.am| 4 +++-
 src/gallium/drivers/vc4/Makefile.am | 2 ++
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/broadcom/Makefile.cle.am b/src/broadcom/Makefile.cle.am
index 368826796d..1c262d0396 100644
--- a/src/broadcom/Makefile.cle.am
+++ b/src/broadcom/Makefile.cle.am
@@ -1,4 +1,6 @@
 noinst_LTLIBRARIES += cle/libbroadcom_cle.la
 
-cle_libbroadcom_cle_la_CFLAGS = $(AM_CFLAGS)
+cle_libbroadcom_cle_la_CFLAGS = \
+   -I$(top_builddir)/src/broadcom/cle  \
+   $(AM_CFLAGS)
 cle_libbroadcom_cle_la_SOURCES = $(BROADCOM_DECODER_FILES)
diff --git a/src/gallium/drivers/vc4/Makefile.am 
b/src/gallium/drivers/vc4/Makefile.am
index 4c2b7486c5..6db5fef037 100644
--- a/src/gallium/drivers/vc4/Makefile.am
+++ b/src/gallium/drivers/vc4/Makefile.am
@@ -29,6 +29,8 @@ endif
 AM_CFLAGS = \
-I$(top_builddir)/src/compiler/nir \
-I$(top_srcdir)/include/drm-uapi \
+   -I$(top_builddir)/src \
+   -I$(top_srcdir)/src/broadcom/cle \
$(LIBDRM_CFLAGS) \
$(GALLIUM_DRIVER_CFLAGS) \
$(SIM_CFLAGS) \
-- 
2.14.1

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

Re: [Mesa-dev] initial meson port

[Eric Anholt]

Dylan Baker  writes:

> [ Unknown signature status ]
> I've gone ahead and pushed the Vulkan drivers meson builds.
>
> For those interested in helping finish the conversion, I have a branch
> "wip/meson-4" on my github (github.com/dcbaker/mesa) that has i965 and most of
> the core classic mesa stack building. I'm working on GLX, then EGL to start
> testing this stack. Getting gallium building is my next step after that (it'll
> be RadeonSI because I have hardware).
>
> I'm also working on getting features into upstream meson to make meson more
> comfortable for mesa. Currently there are patches landed or pending for the 
> two
> workarounds in the meson build we have currently (choosing the right linker 
> and
> indexing into CustomTargets). I'm also still thinking about how we can share
> source files with the other 3 build systems already in mesa (autotools and
> android being the most important, since hopefully our meson will be able to
> support windows in the future, I don't know what will happen when android 
> moves
> to blueprint/soong). If there is anything else please let me know.

Talking with ChromeOS folks at XDC, it sounded like having Android.mk be
a small wrapper around another build system is a totally acceptable and
not unusual thing to do.  Rob, does that seem possible/OK to you?  It
seems like that should seriously reduce the android maintenance burden.


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

Re: [Mesa-dev] [PATCH 2/2] gallium/util: use new util_vasprintf() function

[Brian Paul]

On 09/27/2017 11:18 AM, Nicolai Hähnle wrote:

Didn't you send this already? It looks familiar, even in the v2.


Yeah, but I neglected to cc my coworkers.



Anyway, both patches:

Reviewed-by: Nicolai Hähnle 


Thanks!
-Brian




On 27.09.2017 16:01, Brian Paul wrote:

---
  src/gallium/auxiliary/util/u_log.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/util/u_log.c
b/src/gallium/auxiliary/util/u_log.c
index 359b3e1..dacbe05 100644
--- a/src/gallium/auxiliary/util/u_log.c
+++ b/src/gallium/auxiliary/util/u_log.c
@@ -24,6 +24,7 @@
  #include "u_log.h"
  #include "u_memory.h"
+#include "util/u_string.h"
  struct page_entry {
 const struct u_log_chunk_type *type;
@@ -129,7 +130,7 @@ u_log_printf(struct u_log_context *ctx, const char
*fmt, ...)
 char *str = NULL;
 va_start(va, fmt);
-   int ret = vasprintf(, fmt, va);
+   int ret = util_vasprintf(, fmt, va);
 va_end(va);
 if (ret >= 0) {






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

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

[AppVeyor]

Build mesa 5633 completed



Commit a8fd58eae5 by Eric Anholt on 5/12/2017 11:05 PM:

vc4: Add labels to BOs for debug builds or with VC4_DEBUG=surf set.\n\nThis has proven to be incredibly useful for debugging CMA allocation\nfailures and driving memory management improvements.  However, we don't\nwant to burden entry and exit from the BO cache with the labeling ioctl's\noverhead on release builds.


Configure your notification preferences

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

Re: [Mesa-dev] XDC 2017 feedback

[Miguel Angel Vico]

Hi,

In general, I think the organization was great. I agree having
everything happen in a single room was a good point. Here's some of my
personal feedback:

 * I didn't like the tables layout at all. I found it to be extremely
   uncomfortable to have to look sideways in order to see the screens
   and presenter.

 * There were a very few power strips, and not well distributed along
   the tables.


Also, this is what I've been able to gather from some of my colleagues
here at NVIDIA::

 * Some people watching the conference remotely complained about the
   stream quality, and the recordings wouldn't include the presenter.

   In one of the hallway conversations, Martin mentioned in XDC2016
   they had a team of camera experts doing the job, and will try to
   improve that part in future XDC's.

 * The microphone/audio situation wasn't great either.  I don't know
   how practical it is with something the size of XDC, but at Khronos
   meetings, they usually set up microphones for the audience too, with
   tap-on/tap-off switches, and a ratio of 1:2 or 1:3 for
   microphones:people.  That makes Q a lot easier.  Alternatively,
   having a question queue rather than running mics around the room can
   speed things up, but makes cross-talk harder.

 * The table/chair layout was really cumbersome. Beyond just the
   orientation, some people had a lot of trouble getting in/out to use
   the restroom, grab snacks, etc.


On a positive note:

 * More time for hallway conversations was in general a good thing.
   Some of us got a ton of useful feedback talking to others.

 * The food was great, and having food on-site gave us even more time
   for hallway-tracking.

 * Surprisingly, parking was not an issue.

 * Signage was good, and the security guards were polite/helpful. It
   was easy to find the room and get our badges.

 * The wifi worked great in general, which is a rarity at conferences.
   It was pretty spotty at XDC 2016.


Thank you.

On Tue, 26 Sep 2017 11:49:10 -0700
Manasi Navare wrote:

> Hi,
> 
> XDC was a really great conference and loved the fact that it was
> in just one room which kept all the hallway conversations in that room 
> resulting
> into more networking.
> But I agree with Andres that for the videos, it would be great to split the
> huge youtube video stream per presentation and have seperate links for each
> talk somewhere on the XDC page.
> 
> Regards
> Manasi
> 
> 
> 
> On Tue, Sep 26, 2017 at 01:25:15PM -0400, Andres Rodriguez wrote:
> > Hi,
> > 
> > A small piece of feedback from those of us watching remotely. It would be
> > nice to have a simple to access index for the long livestream videos.
> > 
> > I think the XDC 2017 wiki page would be a good place for this information. A
> > brief example:
> > 
> > Presentation Title | Presenter Name | Link with timestamp
> > ---||-
> > ...| ...| youtu.be/video-id?t=XhYmZs
> > 
> > Or alternatively, a list of hyperlinks with the presentation title as text
> > that point to the correct timestamp in the video would also be sufficient.
> > 
> > Really enjoyed the talks, and would like them to be slightly easier to
> > access and share with others.
> > 
> > Regards,
> > Andres
> > 
> > 
> > On 2017-09-26 12:57 PM, Daniel Vetter wrote:  
> > >Hi all,
> > >
> > >First again big thanks to Stéphane and Jennifer for organizing a great XDC.
> > >
> > >Like last year we'd like to hear feedback on how this year's XDC went,
> > >both the good (and what you'd like to see more of) and the not so
> > >good. Talk selection, organization, location, scheduling of talks,
> > >anything really.
> > >
> > >Here's a few things we took into account from Helsinki and tried to apply:
> > >- More breaks for more hallway track.
> > >- Try to schedule the hot topics on the first day (did we pick the
> > >right ones) for better hallway track.
> > >- More lightning talk time to give all the late/rejected submissions
> > >some place to give a quick showcase.
> > >
> > >Things that didn't work out perfectly this year and that we'll try to
> > >get better at next year:
> > >- Lots of people missed the submission deadline and their talks were
> > >rejected only because of that. We'll do better PR by sending out a
> > >pile of reminders.
> > >- Comparitively few people asked for travel assistance. No idea
> > >whether this was a year with more budget around, or whether this isn't
> > >all that well know and we need to make more PR in maybe the call for
> > >papers about it.
> > >
> > >But that's just the stuff we've gathered already, we'd like to hear
> > >more feedback. Just reply to this mail or send a mail to
> > >bo...@foundation.x.org if you don't want the entire world to read it.
> > >And if you want to send at pseudonymous feedback, drop a pastebin onto
> > >the #xf-bod channel on the OFTC irc server.
> > >
> > >Thanks, Daniel
> > >  
> > 

[Mesa-dev] [PATCH] broadcom: Fix out-of-tree build include path

[Daniel Stone]

Cc: Eric Anholt 
Fixes: 5b102160ae ("broadcom/genxml: Introduce a V3D packet/struct decoder.")
---
 src/broadcom/Makefile.cle.am | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/broadcom/Makefile.cle.am b/src/broadcom/Makefile.cle.am
index 368826796d..1c262d0396 100644
--- a/src/broadcom/Makefile.cle.am
+++ b/src/broadcom/Makefile.cle.am
@@ -1,4 +1,6 @@
 noinst_LTLIBRARIES += cle/libbroadcom_cle.la
 
-cle_libbroadcom_cle_la_CFLAGS = $(AM_CFLAGS)
+cle_libbroadcom_cle_la_CFLAGS = \
+   -I$(top_builddir)/src/broadcom/cle  \
+   $(AM_CFLAGS)
 cle_libbroadcom_cle_la_SOURCES = $(BROADCOM_DECODER_FILES)
-- 
2.14.1

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

Re: [Mesa-dev] [PATCH 2/2] gallium/util: use new util_vasprintf() function

[Nicolai Hähnle]

Didn't you send this already? It looks familiar, even in the v2.

Anyway, both patches:

Reviewed-by: Nicolai Hähnle 


On 27.09.2017 16:01, Brian Paul wrote:

---
  src/gallium/auxiliary/util/u_log.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/util/u_log.c 
b/src/gallium/auxiliary/util/u_log.c
index 359b3e1..dacbe05 100644
--- a/src/gallium/auxiliary/util/u_log.c
+++ b/src/gallium/auxiliary/util/u_log.c
@@ -24,6 +24,7 @@
  #include "u_log.h"
  
  #include "u_memory.h"

+#include "util/u_string.h"
  
  struct page_entry {

 const struct u_log_chunk_type *type;
@@ -129,7 +130,7 @@ u_log_printf(struct u_log_context *ctx, const char *fmt, 
...)
 char *str = NULL;
  
 va_start(va, fmt);

-   int ret = vasprintf(, fmt, va);
+   int ret = util_vasprintf(, fmt, va);
 va_end(va);
  
 if (ret >= 0) {





--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] vc4: Mark BOs as purgeable when they enter the BO cache

[Eric Anholt]

Boris Brezillon  writes:

> On Wed, 27 Sep 2017 15:24:16 +0100
> Chris Wilson  wrote:
>
>> Quoting Boris Brezillon (2017-09-27 15:06:53)
>> > On Wed, 27 Sep 2017 14:50:10 +0100
>> > Chris Wilson  wrote:
>> >   
>> > > Quoting Boris Brezillon (2017-09-27 14:45:17)  
>> > > >  static struct vc4_bo *
>> > > >  vc4_bo_from_cache(struct vc4_screen *screen, uint32_t size, const 
>> > > > char *name)
>> > > >  {
>> > > > @@ -111,6 +121,11 @@ vc4_bo_from_cache(struct vc4_screen *screen, 
>> > > > uint32_t size, const char *name)
>> > > >  return NULL;
>> > > >  }
>> > > >  
>> > > > +if (vc4_bo_purgeable(bo, false)) {
>> > > > +mtx_unlock(>lock);
>> > > > +return NULL;
>> > > 
>> > > So this would just mean that the bo was purged in the meantime. Why not
>> > > just try to use the next one in the cache or allocate afresh?  
>> > 
>> > No, this means the BO was purged and the kernel failed to allocate the
>> > memory back. We don't care about the retained status here, because we
>> > don't need to restore BO's content, that's why we're not checking
>> > arg.retained in vc4_bo_purgeable(). Allocating a fresh BO is likely to
>> > fail with the same ENOMEM error because both path use the CMA mem.  
>> 
>> Hmm, you don't treat purging as permanent. But you do track the lose of
>> contents, so retained is false?
>
> vc4_bo_purgeable() is not reporting the retained status, it just
> reports whether the BO can be used or not. I can change
> vc4_bo_purgeable() semantic to return 1 if the BO content was retained,
> 0 if it was purged and -1 if you the ioctl returned an error (ENOMEM)
> if you prefer, but in the end, all I'll check here is
> 'vc4_bo_purgeable() >= 0' because I don't don't care about the retained
> status in this specific use case, all I care about is whether the BO can
> be re-used or not (IOW, is there a valid CMA region attached to the BO).
>
>> 
>> I took a harder line, and said that userspace should recreate the object
>> from scratch after it was purged. I thought that would be easier
>> overall. But maybe not.:)
>
> Well, maybe I'm wrong in how I implemented this
> DRM_IOCTL_VC4_GEM_MADVISE ioctl, but right now, when the BO has been
> purged and someone marks it back as unpurgeable I'm trying to
> re-allocate BO's buffer in the ioctl path, and if the CMA allocation
> fails I return -ENOMEM. I could move the allocation in the fault
> handler, but this would result in pretty much the same behavior except
> it would require an extra page-fault to realize the memory is not
> available or force us to check the retained status and decide to
> release the BO object from the BO cache.

Hmm.  The downside I see to this plan is if we eventually decide to have
the purge operation not clear all the BOs, then we would probably rather
have userspace freeing objects that had been purged until it finds one
in the cache that hadn't been purged, rather than forcing reallocation
of this BO now (and possibly then purging something from elsewhere in
the cache).


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

Re: [Mesa-dev] [PATCH] st/dri: don't expose modifiers in EGL if the driver doesn't implement them

[Emil Velikov]

On 27 September 2017 at 17:28, Marek Olšák  wrote:
> On Wed, Sep 27, 2017 at 6:22 PM, Emil Velikov  
> wrote:
>> On 27 September 2017 at 16:00, Daniel Stone  wrote:
>>> Hi Marek,
>>>
>>> On 27 September 2017 at 15:55, Marek Olšák  wrote:
 if (dmabuf_ret && dmabuf_ret->val.val_bool) {
uint64_t cap;

if (drmGetCap(sPriv->fd, DRM_CAP_PRIME, ) == 0 &&
(cap & DRM_PRIME_CAP_IMPORT)) {
   dri2ImageExtension.createImageFromFds = dri2_from_fds;
   dri2ImageExtension.createImageFromDmaBufs = dri2_from_dma_bufs;
   dri2ImageExtension.createImageFromDmaBufs2 = dri2_from_dma_bufs2;
   dri2ImageExtension.queryDmaBufFormats = 
 dri2_query_dma_buf_formats;
 - dri2ImageExtension.queryDmaBufModifiers =
 -dri2_query_dma_buf_modifiers;
 + if (pscreen->query_dmabuf_modifiers) {
 +dri2ImageExtension.queryDmaBufModifiers =
 +   dri2_query_dma_buf_modifiers;
 + }
>>>
>>> This should also not expose queryDmaBufFormats, since that is also
>>> part of EGL_EXT_image_dma_buf_import_modifiers, which is pretty
>>> useless without modifiers.
>>>
>> True, it's useless. Suggestion makes the code a bit confusing though.
>> After all EGL already checks that all the entry points are present
>> before advertising the extension.
>>
>> Either way, I think we want this in stable, right?
>
> Sorry too late, I pushed it.
>
No need to apologise.

> I don't know if stable is affected.
>
You're right - code was introduced around commit
f84bb6a9d91521de6da4c3d1ddd8de456761efaa.
The latter of which landed in Mesa 17.2.0-devel

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

Re: [Mesa-dev] feature levels in clover (was: Re: [PATCH 2/2] clover: Query and export int64 atomics)

[Jan Vesely]

On Tue, 2017-09-26 at 14:51 -0700, Francisco Jerez wrote:
> Jan Vesely  writes:
> 
> > On Wed, 2017-09-20 at 19:10 -0500, Aaron Watry wrote:
> > > [SNIP]
> > > 
> > > Not trying to rain on your parade, but I've been thinking that we
> > > might need to be able to query the installed libclc version or
> > > possibly consider querying the libclc library for information about
> > > which extensions are implemented (possibly even for the specific
> > > device/target and the llvm version it was built against).
> > > 
> > > I've been slowly working on a printf implementation, and I'll need to
> > > expose that based on some dynamic state of the system as well.
> > > 
> > > For something that's adding new extension support in libclc, we might
> > > at least want to bump the libclc version number and ask Tom what he
> > > did in the past related to branching off a libclc release, and then
> > > make sure we've got a way to link against libclc (if we're not
> > > already) and get its version number.
> > 
> > I disagree.
> > Extensions need to be exposed by both clover (for host code) and clang
> > (for clc code), synchronizing those is tricky enough. adding two more
> > variables (libclc version, libclc clang build version) will make things
> > intractable.
> > 
> > It's a lot easier (and I'd say common) for applications to check for
> > extensions in CLC code (ifdef/ifndef) and handle all failures in
> > generic 'build failed' error path. That makes clang the authoritative
> > source of supported extensions for each target.
> > Ideally, clover would get the list of supported extensions from clang
> > (based on device target) and expose those.
> > clang has exposed almost all extensions since at least 3.9.
> > Implementing and exposing them (including int64 atomics) is thus a
> > bugfix, not a feature update.
> > 
> > I don't want to have libclc release until the library is complete (we
> > still miss ~12 builtins + variants). Distros now ship development
> > snapshot and providing a released version would make more
> > backward^Wconservative distros (ehm, debian) stuck on that version.
> > This way we have only one version; HEAD.
> > 
> > I have posted patches that bring back llvm-3.9 support to libclc, thus
> > everyone can use the latest libclcHEAD.
> > 
> > I agree that we need to differentiate libclc variants that follow
> > different version of standard. Not just because of missing features,
> > but because not all builtins should be exposed in all versions.
> > for example: atomic_* should not be available in clc1.0.
> > or the program can do something like this:
> > #ifndef extension
> > ...custom implementation of extensions function
> > #else
> > #pragma extension: enable
> > #endif
> > 
> > I'd thus propose to add lang version suffix to libclc.
> > *.bc.cl100 -- follows OCL-1.0 (builtins added later are not available)
> > *.bc.cl110 -- follows OCL-1.1 (deprecated OCL-1.0 builtins/macros are
> > not available, buitlins from 1.2 are not available)
> > ...
> > Current libclc would thus provide only .cl100 and .cl110 with missing
> > builtins/bugs.
> > 
> > 
> > It'd be possible for clover to check presence of such libraries and
> > restrict CLC (and CL) feature level accordingly.
> > 
> 
> Wouldn't it be easier for Clover to check which libclc version it's
> linking against and expose a subset of language versions and extensions
> accordingly?  That should only take a tiny bit of build system support
> and wouldn't lock us to a single libclc release per API version (which
> would make things tricky if extensions get back-ported by Khronos to
> older API versions after the fact, or if people have reasons to delay
> the implementation of a subset of extensions after a release).

I don't think libclc version makes sense.

atm, there are still core clc 1.0 builtins missing so we really should
not expose even cl1.0

when it comes to extensions, libclc has to implement all builtins for
extensions exposed by clang, whether clover exposes the same extension
or not, otherwise legal programs fail to build.
I would not expect an application to check clGetDeviceInfo for
extensions and then pass custom defines to kernel build (that's what
ifdef cl_khr_* is for).
Moreover, libclc is the easiest one to upgrade because nothing else in
the system depends on it (as opposed to llvm and mesa).

The idea behind liblc per language variants is that the user should be
able to use function names that were later taken for builtins (like
shuffle).
we might be able to get away with a single library variant if users
don't use overloadable attribute.

> 
> Either way, patch looks good to me:
> 
> Reviewed-by: Francisco Jerez 

thanks, pushed.
Jan

> 
> > Jan
> > 
> > [SNIP]
> > -- 
> > Jan Vesely 
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > 

Re: [Mesa-dev] initial meson port

[Dylan Baker]

I've gone ahead and pushed the Vulkan drivers meson builds.

For those interested in helping finish the conversion, I have a branch
"wip/meson-4" on my github (github.com/dcbaker/mesa) that has i965 and most of
the core classic mesa stack building. I'm working on GLX, then EGL to start
testing this stack. Getting gallium building is my next step after that (it'll
be RadeonSI because I have hardware).

I'm also working on getting features into upstream meson to make meson more
comfortable for mesa. Currently there are patches landed or pending for the two
workarounds in the meson build we have currently (choosing the right linker and
indexing into CustomTargets). I'm also still thinking about how we can share
source files with the other 3 build systems already in mesa (autotools and
android being the most important, since hopefully our meson will be able to
support windows in the future, I don't know what will happen when android moves
to blueprint/soong). If there is anything else please let me know.

Dylan

Quoting Dylan Baker (2017-09-20 13:27:37)
> Hi everyone,
> 
> A long time ago I made some rumbling about porting mesa to meson (isn't that
> confusing). In the mean time I've been bogged down with other projects,
> including adding features to meson itself, and trying to write and rebase 
> meson
> patches for all of mesa. Unfortunately mesa is a large fast moving project and
> trying to writing meson for the entire thing has proven to simply be
> intractable, I could spend nearly half my day rebasing to current master, and
> that's both demoralizing and error prone.
> 
> So I took Jason's advice and started with what mattered to him ;) Vulkan. This
> was a chunk big enough to be a decent example, but small and contained enough 
> to
> not require lots of rebasing. Intel's "anv" and the AMD "radv" driver share a
> large number of dependencies between each other, and demonstrate writing a 
> meson
> build system.
> 
> You may notice a lot of TODO/FIXME comments here. Some of them are related to
> upstream meson bugs (there are two currently, one that I have a pull request 
> for
> that is probably ready for merge, and one that I'm working on currently), or
> things that need to be implemented for the meson build system to be complete.
> There are a few things that will need to be resolved before implementing mesa
> and gallium drivers (around dependencies that are hard dependencies for 
> Vulkan,
> but soft dependencies for mesa/gallium).
> 
> The meson build system is much faster for building these two drivers than the
> autotools build system, but there are a couple of caveats worth mentioning
> before I give you the numbers. 1: meson doesn't check for as many features,
> flags, or dependencies; 2: meson doesn't build glx, egl, or the glsl compiler,
> just enough of the glsl_compiler to get anv and radv building. The 1st will 
> just
> naturally happen, the second could be fixed.
> 
> Methodology : I ran each build system in as close of a configuration as I 
> could
> (out of tree, same number of jobs) using zsh's time. These were run on a 2 
> core
> 4 thread Intel skylake. Note that ninja by default runs with logical cores + 2
> jobs.
> 
> Commands
> autotools : 'mkdir autotools ; cd autotools ; ../autogen.sh \
> --without-dri-drivers --without-gallium-drivers \
> --with-platforms=x11,wayland --with-vulkan-drivers=intel,radeon \
> && make -j6'
> meson : meson build -Dvulkan-drivers=intel,amd -Dplatforms=x11,wayland && 
> ninja -C build
> 
> Results
> autotools : sh -c   535.34s user 30.33s system 310% cpu 3:02.05 total
> meson : sh -c   136.58s user 11.98s system 372% cpu 39.895 total
> 
> I'm hopeful that we can start landing the meson build system incrementally, so
> that the rebasing pain can be eased. I'm working on getting i965 and radeonSI
> as my next targets (I have access to hardware to test those), and I'll 
> continue
> to add additional drivers from there.
> 
> Dylan
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

[Mesa-dev] [PATCH] anv: fix push descriptors with set > 0

[Lionel Landwerlin]

When writing to set > 0, we were just wrongly writing to set 0. This
commit fixes this by allocating each set from the dynamic state stream
as we write to them.

Cc: "17.2 17.1" 
Fixes: 9f60ed98e501 ("anv: add VK_KHR_push_descriptor support")
Reported-by: Daniel Ribeiro Maciel 
Signed-off-by: Lionel Landwerlin 
---
 src/intel/vulkan/anv_cmd_buffer.c | 35 +--
 src/intel/vulkan/anv_private.h|  2 +-
 2 files changed, 30 insertions(+), 7 deletions(-)

diff --git a/src/intel/vulkan/anv_cmd_buffer.c 
b/src/intel/vulkan/anv_cmd_buffer.c
index 3b59af8f6f4..3a80a4994b1 100644
--- a/src/intel/vulkan/anv_cmd_buffer.c
+++ b/src/intel/vulkan/anv_cmd_buffer.c
@@ -216,8 +216,8 @@ static VkResult anv_create_cmd_buffer(
anv_state_stream_init(_buffer->dynamic_state_stream,
  >dynamic_state_pool, 16384);
 
-   memset(_buffer->state.push_descriptor, 0,
-  sizeof(cmd_buffer->state.push_descriptor));
+   memset(cmd_buffer->state.push_descriptors, 0,
+  sizeof(cmd_buffer->state.push_descriptors));
 
if (pool) {
   list_addtail(_buffer->pool_link, >cmd_buffers);
@@ -834,6 +834,24 @@ anv_cmd_buffer_get_depth_stencil_view(const struct 
anv_cmd_buffer *cmd_buffer)
return iview;
 }
 
+static struct anv_push_descriptor_set *
+anv_cmd_buffer_ensure_push_descriptor_set(struct anv_cmd_buffer *cmd_buffer,
+  uint32_t set)
+{
+   assert(set < MAX_SETS);
+   if (!cmd_buffer->state.push_descriptors[set]) {
+  struct anv_state state =
+ anv_cmd_buffer_alloc_dynamic_state(cmd_buffer,
+
sizeof(*cmd_buffer->state.push_descriptors[set]), 8);
+  cmd_buffer->state.push_descriptors[set] = state.map;
+
+  memset(cmd_buffer->state.push_descriptors[set], 0,
+ sizeof(*cmd_buffer->state.push_descriptors[set]));
+   }
+
+   return cmd_buffer->state.push_descriptors[set];
+}
+
 void anv_CmdPushDescriptorSetKHR(
 VkCommandBuffer commandBuffer,
 VkPipelineBindPoint pipelineBindPoint,
@@ -851,12 +869,14 @@ void anv_CmdPushDescriptorSetKHR(
 
const struct anv_descriptor_set_layout *set_layout =
   layout->set[_set].layout;
-   struct anv_descriptor_set *set = _buffer->state.push_descriptor.set;
+   struct anv_push_descriptor_set *push_set =
+  anv_cmd_buffer_ensure_push_descriptor_set(cmd_buffer, _set);
+   struct anv_descriptor_set *set = _set->set;
 
set->layout = set_layout;
set->size = anv_descriptor_set_layout_size(set_layout);
set->buffer_count = set_layout->buffer_count;
-   set->buffer_views = cmd_buffer->state.push_descriptor.buffer_views;
+   set->buffer_views = push_set->buffer_views;
 
/* Go through the user supplied descriptors. */
for (uint32_t i = 0; i < descriptorWriteCount; i++) {
@@ -937,12 +957,15 @@ void anv_CmdPushDescriptorSetWithTemplateKHR(
 
const struct anv_descriptor_set_layout *set_layout =
   layout->set[_set].layout;
-   struct anv_descriptor_set *set = _buffer->state.push_descriptor.set;
+
+   struct anv_push_descriptor_set *push_set =
+  anv_cmd_buffer_ensure_push_descriptor_set(cmd_buffer, _set);
+   struct anv_descriptor_set *set = _set->set;
 
set->layout = set_layout;
set->size = anv_descriptor_set_layout_size(set_layout);
set->buffer_count = set_layout->buffer_count;
-   set->buffer_views = cmd_buffer->state.push_descriptor.buffer_views;
+   set->buffer_views = push_set->buffer_views;
 
anv_descriptor_set_write_template(set,
  cmd_buffer->device,
diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index 3ba623a37fd..11ff33c8912 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -1686,7 +1686,7 @@ struct anv_cmd_state {
struct anv_dynamic_state dynamic;
bool need_query_wa;
 
-   struct anv_push_descriptor_set   push_descriptor;
+   struct anv_push_descriptor_set * push_descriptors[MAX_SETS];
 
/**
 * Whether or not the gen8 PMA fix is enabled.  We ensure that, at the top
-- 
2.14.2

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

Re: [Mesa-dev] [PATCH 4/3] glsl: tidy up IR after loop unrolling

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Fri, Sep 22, 2017 at 1:49 AM, Timothy Arceri  wrote:
> c7affbf6875622a enabled GLSLOptimizeConservatively on some
> drivers. The idea was to speed up compile times by running
> the GLSL IR passes only once each time do_common_optimization()
> is called. However loop unrolling can create a big mess and
> with large loops can actually case compile times to increase
> significantly due to a bunch of redundant if statements being
> propagated to other IRs.
>
> Here we make sure to clean things up before moving on.
>
> There was no measureable difference in shader-db compile times,
> but it makes compile times of some piglit tests go from a couple
> of seconds to basically instant.
>
> The shader-db results seemed positive also:
>
> Totals:
> SGPRS: 2829456 -> 2828376 (-0.04 %)
> VGPRS: 1720793 -> 1721457 (0.04 %)
> Spilled SGPRs: 7707 -> 7707 (0.00 %)
> Spilled VGPRs: 33 -> 33 (0.00 %)
> Private memory VGPRs: 3140 -> 2060 (-34.39 %)
> Scratch size: 3308 -> 2180 (-34.10 %) dwords per thread
> Code Size: 79441464 -> 79214616 (-0.29 %) bytes
> LDS: 436 -> 436 (0.00 %) blocks
> Max Waves: 558670 -> 558571 (-0.02 %)
> Wait states: 0 -> 0 (0.00 %)
> ---
>  src/compiler/glsl/glsl_parser_extras.cpp | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/src/compiler/glsl/glsl_parser_extras.cpp 
> b/src/compiler/glsl/glsl_parser_extras.cpp
> index 9cbc2355f9..764c05ad80 100644
> --- a/src/compiler/glsl/glsl_parser_extras.cpp
> +++ b/src/compiler/glsl/glsl_parser_extras.cpp
> @@ -2209,21 +2209,27 @@ do_common_optimization(exec_list *ir, bool linked,
> OPT(lower_vector_insert, ir, false);
> OPT(do_swizzle_swizzle, ir);
> OPT(do_noop_swizzle, ir);
>
> OPT(optimize_split_arrays, ir, linked);
> OPT(optimize_redundant_jumps, ir);
>
> if (options->MaxUnrollIterations) {
>loop_state *ls = analyze_loop_variables(ir);
>if (ls->loop_found) {
> - OPT(unroll_loops, ir, ls, options);
> + bool loop_progress = unroll_loops(ir, ls, options);
> + while (loop_progress) {
> +loop_progress = false;
> +loop_progress |= do_constant_propagation(ir);
> +loop_progress |= do_if_simplification(ir);
> + }
> + progress |= loop_progress;
>}
>delete ls;
> }
>
>  #undef OPT
>
> return progress;
>  }
>
>  extern "C" {
> --
> 2.13.5
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [AppVeyor] mesa wip/meson-4 #5632 failed

[AppVeyor]

Build mesa 5632 failed


Commit e48445a757 by Dylan Baker on 9/22/2017 7:55 PM:

meson: build the loader


Configure your notification preferences

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

[Mesa-dev] [PATCH v2] egl/dri: link directly to libglapi.so

[Emil Velikov]

From: Emil Velikov 

Shared glapi (libglapi.so) has been a requirement for years, in order
to build EGL.

Remove the no longer necessary dlopen/dlsym dance and link to the
library directly.

This allows us to remove a handful of platform specific workarounds, due
to the different name of the library.

v2:
 - Android: export the include dir (RobH)
 - Drop unused local variable (Eric)

Cc: Jonathan Gray 
Cc: Jon Turney 
Cc: Julien Isorce 
Cc: Rob Herring 
Cc: Tomasz Figa 
Signed-off-by: Emil Velikov 
Reviewed-by: Eric Engestrom  (v1)
Tested-by: Tomasz Figa  (v1)
---
Rob, I'd appreciate a quick check that this doesn't break on your end.
---
 src/egl/Android.mk  |  1 +
 src/egl/Makefile.am |  2 ++
 src/egl/drivers/dri2/egl_dri2.c | 42 -
 src/egl/drivers/dri2/egl_dri2.h |  2 --
 src/mapi/Android.mk |  3 +++
 5 files changed, 10 insertions(+), 40 deletions(-)

diff --git a/src/egl/Android.mk b/src/egl/Android.mk
index d7a6e88918f..2de842ca417 100644
--- a/src/egl/Android.mk
+++ b/src/egl/Android.mk
@@ -53,6 +53,7 @@ LOCAL_STATIC_LIBRARIES := \
 
 LOCAL_SHARED_LIBRARIES := \
libdl \
+   libglapi \
libhardware \
liblog \
libcutils \
diff --git a/src/egl/Makefile.am b/src/egl/Makefile.am
index f140f5d6412..eeb745f973a 100644
--- a/src/egl/Makefile.am
+++ b/src/egl/Makefile.am
@@ -27,6 +27,7 @@ BUILT_SOURCES =
 
 AM_CFLAGS = \
-I$(top_srcdir)/include \
+   -I$(top_srcdir)/src/mapi \
-I$(top_srcdir)/src/egl/main \
-I$(top_srcdir)/src/gbm/main \
-I$(top_srcdir)/src \
@@ -45,6 +46,7 @@ libEGL_common_la_SOURCES = \
$(LIBEGL_C_FILES)
 
 libEGL_common_la_LIBADD = \
+   $(top_builddir)/src/mapi/shared-glapi/libglapi.la \
$(top_builddir)/src/util/libmesautil.la \
$(EGL_LIB_DEPS)
 
diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index adcaae0bab7..c2b16d11732 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -62,6 +62,7 @@
 #include "loader/loader.h"
 #include "util/u_atomic.h"
 #include "util/u_vector.h"
+#include "mapi/glapi/glapi.h"
 
 /* The kernel header drm_fourcc.h defines the DRM formats below.  We duplicate
  * some of the definitions here so that building Mesa won't bleeding-edge
@@ -1564,9 +1565,7 @@ dri2_surface_get_dri_drawable(_EGLSurface *surf)
 static _EGLProc
 dri2_get_proc_address(_EGLDriver *drv, const char *procname)
 {
-   struct dri2_egl_driver *dri2_drv = dri2_egl_driver(drv);
-
-   return dri2_drv->get_proc_address(procname);
+   return _glapi_get_proc_address(procname);
 }
 
 static _EGLSurface*
@@ -3169,7 +3168,6 @@ dri2_unload(_EGLDriver *drv)
 {
struct dri2_egl_driver *dri2_drv = dri2_egl_driver(drv);
 
-   dlclose(dri2_drv->handle);
free(dri2_drv);
 }
 
@@ -3177,49 +3175,17 @@ static EGLBoolean
 dri2_load(_EGLDriver *drv)
 {
struct dri2_egl_driver *dri2_drv = dri2_egl_driver(drv);
-#ifdef HAVE_ANDROID_PLATFORM
-   const char *libname = "libglapi.so";
-#elif defined(__APPLE__)
-   const char *libname = "libglapi.0.dylib";
-#elif defined(__CYGWIN__)
-   const char *libname = "cygglapi-0.dll";
-#else
-   const char *libname = "libglapi.so.0";
-#endif
-   void *handle;
-
-   /* RTLD_GLOBAL to make sure glapi symbols are visible to DRI drivers */
-   handle = dlopen(libname, RTLD_LAZY | RTLD_GLOBAL);
-   if (!handle) {
-  _eglLog(_EGL_WARNING, "DRI2: failed to open glapi provider");
-  goto no_handle;
-   }
-
-   dri2_drv->get_proc_address = (_EGLProc (*)(const char *))
- dlsym(handle, "_glapi_get_proc_address");
-
-   /* if glapi is not available, loading DRI drivers will fail */
-   if (!dri2_drv->get_proc_address) {
-  _eglLog(_EGL_WARNING, "DRI2: failed to find _glapi_get_proc_address");
-  goto no_symbol;
-   }
 
dri2_drv->glFlush = (void (*)(void))
-  dri2_drv->get_proc_address("glFlush");
+  _glapi_get_proc_address("glFlush");
 
/* if glFlush is not available things are horribly broken */
if (!dri2_drv->glFlush) {
   _eglLog(_EGL_WARNING, "DRI2: failed to find glFlush entry point");
-  goto no_symbol;
+  return EGL_FALSE;
}
 
-   dri2_drv->handle = handle;
return EGL_TRUE;
-
-no_symbol:
-   dlclose(handle);
-no_handle:
-   return EGL_FALSE;
 }
 
 /**
diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
index 10a41518172..c70a84bb917 100644
--- a/src/egl/drivers/dri2/egl_dri2.h
+++ b/src/egl/drivers/dri2/egl_dri2.h
@@ -83,8 +83,6 @@ struct dri2_egl_driver
 {
_EGLDriver base;
 
-   void *handle;
-   _EGLProc (*get_proc_address)(const char *procname);
void (*glFlush)(void);
 };
 
diff --git a/src/mapi/Android.mk b/src/mapi/Android.mk
index 

Re: [Mesa-dev] [PATCH] st/dri: don't expose modifiers in EGL if the driver doesn't implement them

[Marek Olšák]

On Wed, Sep 27, 2017 at 6:22 PM, Emil Velikov  wrote:
> On 27 September 2017 at 16:00, Daniel Stone  wrote:
>> Hi Marek,
>>
>> On 27 September 2017 at 15:55, Marek Olšák  wrote:
>>> if (dmabuf_ret && dmabuf_ret->val.val_bool) {
>>>uint64_t cap;
>>>
>>>if (drmGetCap(sPriv->fd, DRM_CAP_PRIME, ) == 0 &&
>>>(cap & DRM_PRIME_CAP_IMPORT)) {
>>>   dri2ImageExtension.createImageFromFds = dri2_from_fds;
>>>   dri2ImageExtension.createImageFromDmaBufs = dri2_from_dma_bufs;
>>>   dri2ImageExtension.createImageFromDmaBufs2 = dri2_from_dma_bufs2;
>>>   dri2ImageExtension.queryDmaBufFormats = 
>>> dri2_query_dma_buf_formats;
>>> - dri2ImageExtension.queryDmaBufModifiers =
>>> -dri2_query_dma_buf_modifiers;
>>> + if (pscreen->query_dmabuf_modifiers) {
>>> +dri2ImageExtension.queryDmaBufModifiers =
>>> +   dri2_query_dma_buf_modifiers;
>>> + }
>>
>> This should also not expose queryDmaBufFormats, since that is also
>> part of EGL_EXT_image_dma_buf_import_modifiers, which is pretty
>> useless without modifiers.
>>
> True, it's useless. Suggestion makes the code a bit confusing though.
> After all EGL already checks that all the entry points are present
> before advertising the extension.
>
> Either way, I think we want this in stable, right?

Sorry too late, I pushed it.

I don't know if stable is affected.

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

Re: [Mesa-dev] [PATCH] st/dri: don't expose modifiers in EGL if the driver doesn't implement them

[Emil Velikov]

On 27 September 2017 at 16:00, Daniel Stone  wrote:
> Hi Marek,
>
> On 27 September 2017 at 15:55, Marek Olšák  wrote:
>> if (dmabuf_ret && dmabuf_ret->val.val_bool) {
>>uint64_t cap;
>>
>>if (drmGetCap(sPriv->fd, DRM_CAP_PRIME, ) == 0 &&
>>(cap & DRM_PRIME_CAP_IMPORT)) {
>>   dri2ImageExtension.createImageFromFds = dri2_from_fds;
>>   dri2ImageExtension.createImageFromDmaBufs = dri2_from_dma_bufs;
>>   dri2ImageExtension.createImageFromDmaBufs2 = dri2_from_dma_bufs2;
>>   dri2ImageExtension.queryDmaBufFormats = dri2_query_dma_buf_formats;
>> - dri2ImageExtension.queryDmaBufModifiers =
>> -dri2_query_dma_buf_modifiers;
>> + if (pscreen->query_dmabuf_modifiers) {
>> +dri2ImageExtension.queryDmaBufModifiers =
>> +   dri2_query_dma_buf_modifiers;
>> + }
>
> This should also not expose queryDmaBufFormats, since that is also
> part of EGL_EXT_image_dma_buf_import_modifiers, which is pretty
> useless without modifiers.
>
True, it's useless. Suggestion makes the code a bit confusing though.
After all EGL already checks that all the entry points are present
before advertising the extension.

Either way, I think we want this in stable, right?
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965: Record the presence of the kernel scheduler

[Joonas Lahtinen]

On Wed, 2017-09-27 at 16:18 +0100, Chris Wilson wrote:
> Mention to the debug log if the kernel scheduler is enabled; and in
> particular if it has preemption enabled.
> 
> Signed-off-by: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: Ben Widawsky 

This should debugging much more pleasant.

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v4 2/4] util/ralloc: Don't define assert with magic member without DEBUG

[Dylan Baker]

Quoting Eric Engestrom (2017-09-27 04:10:37)
> On Tuesday, 2017-09-26 23:38:11 +, Dylan Baker wrote:
> > It is possible to have DEBUG disabled but asserts on (NDEBUG(, which
> 
> parentheses typo
> 
> other than that:
> Reviewed-by: Eric Engestrom 
> 
> and I think you should've pushed these first two patches instead of
> carrying them in your unrelated meson series :)
> 
> speaking of, I'm happy to write the egl/meson.build; I'll get on that
> when the initial support lands.

I do have most of the classic dri stack building in a branch on top of this
work, I'm working on getting GLX, EGL, etc building at the moment. I'll send
that out as a "WIP" series after this lands so that others can look at it and we
don't all end up duplicating effort.

Dylan

> 
> > cannot build because these asserts work on members that are only present
> > when DEBUG is on.
> > 
> > Reviewed-by: Kenneth Graunke 
> > Signed-off-by: Dylan Baker 
> > ---
> >  src/util/ralloc.c | 8 
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/src/util/ralloc.c b/src/util/ralloc.c
> > index 566f08ad94e..9cce9e02f68 100644
> > --- a/src/util/ralloc.c
> > +++ b/src/util/ralloc.c
> > @@ -630,7 +630,9 @@ linear_alloc_child(void *parent, unsigned size)
> > linear_size_chunk *ptr;
> > unsigned full_size;
> >  
> > +#ifdef DEBUG
> > assert(first->magic == LMAGIC);
> > +#endif
> > assert(!latest->next);
> >  
> > size = ALIGN_POT(size, SUBALLOC_ALIGNMENT);
> > @@ -702,7 +704,9 @@ linear_free_parent(void *ptr)
> >return;
> >  
> > node = LINEAR_PARENT_TO_HEADER(ptr);
> > +#ifdef DEBUG
> > assert(node->magic == LMAGIC);
> > +#endif
> >  
> > while (node) {
> >void *ptr = node;
> > @@ -721,7 +725,9 @@ ralloc_steal_linear_parent(void *new_ralloc_ctx, void 
> > *ptr)
> >return;
> >  
> > node = LINEAR_PARENT_TO_HEADER(ptr);
> > +#ifdef DEBUG
> > assert(node->magic == LMAGIC);
> > +#endif
> >  
> > while (node) {
> >ralloc_steal(new_ralloc_ctx, node);
> > @@ -734,7 +740,9 @@ void *
> >  ralloc_parent_of_linear_parent(void *ptr)
> >  {
> > linear_header *node = LINEAR_PARENT_TO_HEADER(ptr);
> > +#ifdef DEBUG
> > assert(node->magic == LMAGIC);
> > +#endif
> > return node->ralloc_parent;
> >  }
> >  
> > -- 
> > 2.14.1
> > 


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

[Mesa-dev] [PATCH] mesa: fix texture updates for ATI_fragment_shader

[Marek Olšák]

From: Marek Olšák 

---
 src/mesa/main/texstate.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/src/mesa/main/texstate.c b/src/mesa/main/texstate.c
index 269e291..edd2253 100644
--- a/src/mesa/main/texstate.c
+++ b/src/mesa/main/texstate.c
@@ -833,23 +833,25 @@ update_ff_texture_state(struct gl_context *ctx,
 void
 _mesa_update_texture_state(struct gl_context *ctx)
 {
struct gl_program *prog[MESA_SHADER_STAGES];
int i;
int old_max_unit = ctx->Texture._MaxEnabledTexImageUnit;
BITSET_DECLARE(enabled_texture_units, MAX_COMBINED_TEXTURE_IMAGE_UNITS);
 
memcpy(prog, ctx->_Shader->CurrentProgram, sizeof(prog));
 
-   if (prog[MESA_SHADER_FRAGMENT] == NULL &&
-   _mesa_arb_fragment_program_enabled(ctx)) {
-  prog[MESA_SHADER_FRAGMENT] = ctx->FragmentProgram.Current;
+   if (prog[MESA_SHADER_FRAGMENT] == NULL) {
+  if (_mesa_arb_fragment_program_enabled(ctx))
+ prog[MESA_SHADER_FRAGMENT] = ctx->FragmentProgram.Current;
+  else if (_mesa_ati_fragment_shader_enabled(ctx))
+ prog[MESA_SHADER_FRAGMENT] = ctx->ATIFragmentShader.Current->Program;
}
 
/* TODO: only set this if there are actual changes */
ctx->NewState |= _NEW_TEXTURE_OBJECT | _NEW_TEXTURE_STATE;
 
ctx->Texture._GenFlags = 0x0;
ctx->Texture._TexMatEnabled = 0x0;
ctx->Texture._TexGenEnabled = 0x0;
ctx->Texture._MaxEnabledTexImageUnit = -1;
ctx->Texture._EnabledCoordUnits = 0x0;
-- 
2.7.4

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

Re: [Mesa-dev] [Mesa-stable] [PATCH 4/8] egl: rework input validation order in _eglCreateWindowSurfaceCommon

[Juan A. Suarez Romero]

On Wed, 2017-09-27 at 16:15 +0100, Emil Velikov wrote:
> On 26 September 2017 at 18:08, Juan A. Suarez Romero
>  wrote:
> > On Wed, 2017-09-06 at 15:07 +0100, Emil Velikov wrote:
> > > On 5 August 2017 at 00:25, Emil Velikov  wrote:
> > > > From: Emil Velikov 
> > > > 
> > > > As mentioned in previous commit the negative tests in dEQP expect the
> > > > arguments to be evaluated in particular order.
> > > > 
> > > > Namely - first the dpy, then the config, followed by the surface/window.
> > > > 
> > > > Move the check further down or executing the test below will produce
> > > > the following error.
> > > > 
> > > >dEQP-EGL.functional.negative_api.create_pbuffer_surface
> > > > 
> > > > 
> > > >
> > > >   eglCreateWindowSurface(0x9bfff0f150, 0x, 
> > > > 0x, { EGL_NONE });
> > > >   // 0x returned
> > > >   // ERROR expected: EGL_BAD_CONFIG, Got: 
> > > > EGL_BAD_NATIVE_WINDOW
> > > >
> > > > 
> > > 
> > > FTR dEQP has been "fixed" (by removing the test all together) to not
> > > generate the above error. At the same the Pixman equivalent is still
> > > buggy, hence the v2 of commit
> > > df8efd5b74d45e2bfb977a92dcd3db86abd6b143.
> > > 
> > 
> > Emil, does it mean this patch is superseded? I'm interesting in knowing
> > the situation as this was tagged to be included in stable release.
> > 
> 
> I'd like to keep this open and eventually merge it.
> The dEQP patches need 'a bit' of polishing.
> 

Sure. I'll skip it for next release. Thanks

J.A.

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

Re: [Mesa-dev] [Mesa-stable] [PATCH 2/2] egl/drm: set the VISUAL_TYPE alongside the VISUAL_ID

[Juan A. Suarez Romero]

On Wed, 2017-09-27 at 16:13 +0100, Emil Velikov wrote:
> Hi Juan,
> 
> On 26 September 2017 at 18:00, Juan A. Suarez Romero
>  wrote:
> > On Tue, 2017-08-22 at 09:20 +0100, Daniel Stone wrote:
> > > Hi,
> > > 
> > > On 21 August 2017 at 18:30, Emil Velikov  wrote:
> > > > On 21 August 2017 at 15:44, Daniel Stone  wrote:
> > > > > My take on it is that the visual types are defined by the platform,
> > > > > and 0 is a perfectly sensible visual type for a platform which does
> > > > > not actually have any.
> > > > > 
> > > > 
> > > > Having the exact same visual type for all visual IDs does strikes me
> > > > as a bit odd.
> > > > That said, the spec does not explicitly forbids it so I guess it should 
> > > > be fine?
> > > 
> > > It should be, yeah. It would be quite odd to use anything other than
> > > TrueColor for X11, so in effect that only has one value for the type
> > > either. Maybe just imagine '#define GBM_VISUAL_TYPE_FOURCC 0'
> > > existing, with no others to ever be defined, and then it might make
> > > more sense?
> > > 
> > 
> > Hello, people.
> > 
> > What's the status of this patch? It was tagged as candidate for stable,
> > and hence I'd like to know if requires changes or a R-b.
> > 
> 
> Considering the feedback, I think we can throw the series in the bin.
> At least in the current shape... Can revisit if we get some reports
> that need them ;-)
> 
> 

Roger that! I'll discard then. Thanks

J.A.

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

Re: [Mesa-dev] [PATCH 3/4] vulkan/wsi/wayland: Copy wl_proxy objects from oldSwapchain if available

[Jason Ekstrand]

On Wed, Sep 27, 2017 at 1:53 AM, Daniel Stone  wrote:

> Hi,
>
> On 26 September 2017 at 23:55, Jason Ekstrand 
> wrote:
> >  static void
> > -wsi_wl_display_destroy(struct wsi_wl_display *display)
> > +wsi_wl_display_ref(struct wsi_wl_display *display)
> > +{
> > +   display->refcount++;
> > +}
>
> Better:
> static struct wsi_wl_display *
> wsi_wl_display_ref(struct wsi_wl_display *display)
> {
>display->refcount++;
>return display;
> }
>
> Makes it much more difficult to get it wrong. :)
>

Yeah.  I thought about doing that the first time around but decided against
it for no good reason.  You've pushed me over the edge back into sanity. :)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/4] vulkan/wsi/wayland: Return better error messages

[Jason Ekstrand]

On Wed, Sep 27, 2017 at 1:55 AM, Daniel Stone  wrote:

> Good stuff; thanks for cleaning that up. Modulo my comments on 2 and
> 3, the series is:
> Reviewed-by: Daniel Stone 
>

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

Re: [Mesa-dev] [PATCH 3/3] radeonsi: fix border color translation for integer textures

[Dieter Nützel]

For the series:

Tested-by: Dieter Nützel 

Dieter

Am 26.09.2017 16:46, schrieb Nicolai Hähnle:

From: Nicolai Hähnle 

This fixes the extremely unlikely case that an application uses
0x8000 or 0x3f80 as border color for an integer texture and
helps in the also, but perhaps slightly less, unlikely case that 1 is
used as a border color.
---
 src/gallium/drivers/radeonsi/si_descriptors.c | 37 


 src/gallium/drivers/radeonsi/si_pipe.h|  2 ++
 src/gallium/drivers/radeonsi/si_state.c   | 50 
+++

 3 files changed, 60 insertions(+), 29 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c
b/src/gallium/drivers/radeonsi/si_descriptors.c
index 27239c25389..db77b1cb982 100644
--- a/src/gallium/drivers/radeonsi/si_descriptors.c
+++ b/src/gallium/drivers/radeonsi/si_descriptors.c
@@ -372,20 +372,34 @@ void si_set_mutable_tex_desc_fields(struct
si_screen *sscreen,
unsigned pitch = base_level_info->nblk_x * block_width;
unsigned index = si_tile_mode_index(tex, base_level, 
is_stencil);

state[3] &= C_008F1C_TILING_INDEX;
state[3] |= S_008F1C_TILING_INDEX(index);
state[4] &= C_008F20_PITCH_GFX6;
state[4] |= S_008F20_PITCH_GFX6(pitch - 1);
}
 }

+static void si_set_sampler_state_desc(struct si_sampler_state *sstate,
+ struct si_sampler_view *sview,
+ struct r600_texture *tex,
+ uint32_t *desc)
+{
+   if (sview && sview->is_integer)
+   memcpy(desc, sstate->integer_val, 4*4);
+   else if (tex && tex->upgraded_depth &&
+(!sview || !sview->is_stencil_sampler))
+   memcpy(desc, sstate->upgraded_depth_val, 4*4);
+   else
+   memcpy(desc, sstate->val, 4*4);
+}
+
 static void si_set_sampler_view_desc(struct si_context *sctx,
 struct si_sampler_view *sview,
 struct si_sampler_state *sstate,
 uint32_t *desc)
 {
struct pipe_sampler_view *view = >base;
struct r600_texture *rtex = (struct r600_texture *)view->texture;
bool is_buffer = rtex->resource.b.b.target == PIPE_BUFFER;

if (unlikely(!is_buffer && sview->dcc_incompatible)) {
@@ -415,27 +429,24 @@ static void si_set_sampler_view_desc(struct
si_context *sctx,
   is_separate_stencil,
   desc);
}

if (!is_buffer && rtex->fmask.size) {
memcpy(desc + 8, sview->fmask_state, 8*4);
} else {
/* Disable FMASK and bind sampler state in [12:15]. */
memcpy(desc + 8, null_texture_descriptor, 4*4);

-   if (sstate) {
-   if (!is_buffer && rtex->upgraded_depth &&
-   !sview->is_stencil_sampler)
-   memcpy(desc + 12, sstate->upgraded_depth_val, 
4*4);
-   else
-   memcpy(desc + 12, sstate->val, 4*4);
-   }
+   if (sstate)
+   si_set_sampler_state_desc(sstate, sview,
+ is_buffer ? NULL : rtex,
+ desc + 12);
}
 }

 static void si_set_sampler_view(struct si_context *sctx,
unsigned shader,
unsigned slot, struct pipe_sampler_view *view,
bool disallow_early_out)
 {
struct si_sampler_views *views = >samplers[shader].views;
struct si_sampler_view *rview = (struct si_sampler_view*)view;
@@ -463,22 +474,22 @@ static void si_set_sampler_view(struct si_context 
*sctx,

si_sampler_view_add_buffer(sctx, view->texture,
   RADEON_USAGE_READ,
   rview->is_stencil_sampler, true);
} else {
pipe_sampler_view_reference(>views[slot], NULL);
memcpy(desc, null_texture_descriptor, 8*4);
/* Only clear the lower dwords of FMASK. */
memcpy(desc + 8, null_texture_descriptor, 4*4);
/* Re-set the sampler state if we are transitioning from FMASK. 
*/
if (views->sampler_states[slot])
-   memcpy(desc + 12,
-  views->sampler_states[slot]->val, 4*4);
+   si_set_sampler_state_desc(views->sampler_states[slot], 
NULL, NULL,
+ desc + 12);

views->enabled_mask &= ~(1u << slot);
}

 	sctx->descriptors_dirty |= 1u << 

Re: [Mesa-dev] [Mesa-stable] [PATCH 5/5] radeonsi/gfx9: fix geometry shaders without output vertices

[Dieter Nützel]

For the series:

Tested-by: Dieter Nützel 

Dieter

Am 26.09.2017 16:43, schrieb Nicolai Hähnle:

From: Nicolai Hähnle 

Not that those are super common or useful, but hey! Fun corner cases
of the API...

Fixes dEQP-GLES31.functional.geometry_shading.emit.*

Cc: mesa-sta...@lists.freedesktop.org
---
 src/gallium/drivers/radeonsi/si_state_shaders.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c
b/src/gallium/drivers/radeonsi/si_state_shaders.c
index 53a60ba11ed..985ee130e6d 100644
--- a/src/gallium/drivers/radeonsi/si_state_shaders.c
+++ b/src/gallium/drivers/radeonsi/si_state_shaders.c
@@ -637,23 +637,25 @@ static void gfx9_get_gs_info(struct
si_shader_selector *es,
assert(gs_num_invocations <= 32); /* GL maximum */

if (uses_adjacency || gs_num_invocations > 1)
max_gs_prims = 127 / gs_num_invocations;
else
max_gs_prims = 255;

/* MAX_PRIMS_PER_SUBGROUP = gs_prims * max_vert_out * gs_invocations.
 * Make sure we don't go over the maximum value.
 */
-   max_gs_prims = MIN2(max_gs_prims,
-   max_out_prims /
-   (gs->gs_max_out_vertices * gs_num_invocations));
+   if (gs->gs_max_out_vertices > 0) {
+   max_gs_prims = MIN2(max_gs_prims,
+   max_out_prims /
+   (gs->gs_max_out_vertices * 
gs_num_invocations));
+   }
assert(max_gs_prims > 0);

/* If the primitive has adjacency, halve the number of vertices
 * that will be reused in multiple primitives.
 */
 	min_es_verts = gs->gs_input_verts_per_prim / (uses_adjacency ? 2 : 
1);


gs_prims = MIN2(ideal_gs_prims, max_gs_prims);
worst_case_es_verts = MIN2(min_es_verts * gs_prims, max_es_verts);

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

Re: [Mesa-dev] [PATCH] glsl: do not set the 'smooth' qualifier by default on ES shaders

[Dieter Nützel]

Tested-by: Dieter Nützel 

Dieter

Am 26.09.2017 17:11, schrieb Nicolai Hähnle:

From: Nicolai Hähnle 

It leads to surprising states with integer inputs and outputs on
vertex processing stages (e.g. geometry stages). Instead, rely on the
driver to choose smooth interpolation by default.

We still allow varyings to match when one stage declares it as smooth
and the other declares it without interpolation qualifiers.
--
This should cover all the relevant I/O checks, tested with dEQP.
---
 src/compiler/glsl/ast_to_hir.cpp| 11 ---
 src/compiler/glsl/link_varyings.cpp | 17 -
 src/mesa/main/shader_query.cpp  |  8 +++-
 3 files changed, 23 insertions(+), 13 deletions(-)

diff --git a/src/compiler/glsl/ast_to_hir.cpp 
b/src/compiler/glsl/ast_to_hir.cpp

index c46454956d7..1999e68158c 100644
--- a/src/compiler/glsl/ast_to_hir.cpp
+++ b/src/compiler/glsl/ast_to_hir.cpp
@@ -3119,31 +3119,20 @@ interpret_interpolation_qualifier(const struct
ast_type_qualifier *qual,
   struct _mesa_glsl_parse_state 
*state,

   YYLTYPE *loc)
 {
glsl_interp_mode interpolation;
if (qual->flags.q.flat)
   interpolation = INTERP_MODE_FLAT;
else if (qual->flags.q.noperspective)
   interpolation = INTERP_MODE_NOPERSPECTIVE;
else if (qual->flags.q.smooth)
   interpolation = INTERP_MODE_SMOOTH;
-   else if (state->es_shader &&
-((mode == ir_var_shader_in &&
-  state->stage != MESA_SHADER_VERTEX) ||
- (mode == ir_var_shader_out &&
-  state->stage != MESA_SHADER_FRAGMENT)))
-  /* Section 4.3.9 (Interpolation) of the GLSL ES 3.00 spec says:
-   *
-   *"When no interpolation qualifier is present, smooth 
interpolation

-   *is used."
-   */
-  interpolation = INTERP_MODE_SMOOTH;
else
   interpolation = INTERP_MODE_NONE;

validate_interpolation_qualifier(state, loc,
 interpolation,
 qual, var_type, mode);

return interpolation;
 }

diff --git a/src/compiler/glsl/link_varyings.cpp
b/src/compiler/glsl/link_varyings.cpp
index 528506fd0eb..7c90de393ad 100644
--- a/src/compiler/glsl/link_varyings.cpp
+++ b/src/compiler/glsl/link_varyings.cpp
@@ -318,22 +318,37 @@ cross_validate_types_and_qualifiers(struct
gl_shader_program *prog,
}

/* GLSL >= 4.40 removes text requiring interpolation qualifiers
 * to match cross stage, they must only match within the same 
stage.

 *
 * From page 84 (page 90 of the PDF) of the GLSL 4.40 spec:
 *
 * "It is a link-time error if, within the same stage, the 
interpolation

 * qualifiers of variables of the same name do not match.
 *
+* Section 4.3.9 (Interpolation) of the GLSL ES 3.00 spec says:
+*
+*"When no interpolation qualifier is present, smooth 
interpolation

+*is used."
+*
+* So we match variables where one is smooth and the other has no 
explicit

+* qualifier.
 */
-   if (input->data.interpolation != output->data.interpolation &&
+   unsigned input_interpolation = input->data.interpolation;
+   unsigned output_interpolation = output->data.interpolation;
+   if (prog->IsES) {
+  if (input_interpolation == INTERP_MODE_NONE)
+ input_interpolation = INTERP_MODE_SMOOTH;
+  if (output_interpolation == INTERP_MODE_NONE)
+ output_interpolation = INTERP_MODE_SMOOTH;
+   }
+   if (input_interpolation != output_interpolation &&
prog->data->Version < 440) {
   linker_error(prog,
"%s shader output `%s' specifies %s "
"interpolation qualifier, "
"but %s shader input specifies %s "
"interpolation qualifier\n",
_mesa_shader_stage_to_string(producer_stage),
output->name,
interpolation_string(output->data.interpolation),
_mesa_shader_stage_to_string(consumer_stage),
diff --git a/src/mesa/main/shader_query.cpp 
b/src/mesa/main/shader_query.cpp

index 64e68b4a26d..6712bb45fb2 100644
--- a/src/mesa/main/shader_query.cpp
+++ b/src/mesa/main/shader_query.cpp
@@ -1627,21 +1627,27 @@ validate_io(struct gl_program *producer,
struct gl_program *consumer)
*Precision  |   mediump   |  Yes
*   |highp|
*---+-+--
*Variance   |  invariant  |   No
*---+-+--
*Memory | all |  N/A
*
* Note that location mismatches are detected by the loops above 
that
* find the producer variable that goes with the consumer 
variable.

*/
-  if (producer_var->interpolation != consumer_var->interpolation) 
{

+  unsigned producer_interpolation 

Re: [Mesa-dev] [PATCH 2/4] vulkan/wsi/wayland: Stop caching Wayland displays

[Jason Ekstrand]

On Wed, Sep 27, 2017 at 1:52 AM, Daniel Stone  wrote:

> Hi,
>
> On 26 September 2017 at 23:55, Jason Ekstrand 
> wrote:
> > @@ -833,24 +816,19 @@ wsi_wl_surface_create_swapchain(VkIcdSurfaceBase
> *icd_surface,
> > chain->vk_format = pCreateInfo->imageFormat;
> > chain->drm_format = wl_drm_format_for_vk_format(chain->vk_format,
> alpha);
> >
> > -   chain->display = wsi_wl_get_display(wsi_device, surface->display);
> > +   chain->display = wsi_wl_display_create(wsi, surface->display, false);
>
> Please leave this still getting the formats. In the modifier-support
> patches, we need the display to have stored the set of acceptable
> per-format modifiers, so we'd need to flip the false to true here.
>

Sure, I can do that.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] i965: Record the presence of the kernel scheduler

[Chris Wilson]

Mention to the debug log if the kernel scheduler is enabled; and in
particular if it has preemption enabled.

Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Ben Widawsky 
---
 src/mesa/drivers/dri/i965/intel_screen.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index 42acdb3303..3b2697499f 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -2530,6 +2530,17 @@ __DRIconfig **intelInitScreen2(__DRIscreen *dri_screen)
 
intel_screen_init_surface_formats(screen);
 
+   if (INTEL_DEBUG & DEBUG_SUBMIT) {
+  unsigned int caps = intel_get_integer(screen, I915_PARAM_HAS_SCHEDULER);
+  if (caps) {
+ fprintf(stderr, "Kernel scheduler detected: %08x\n", caps);
+ if (caps & 0x2)
+fprintf(stderr, "  - Priority sorting enabled\n");
+ if (caps & 0x4)
+fprintf(stderr, "  - Preemption enabled\n");
+  }
+   }
+
return (const __DRIconfig**) intel_screen_make_configs(dri_screen);
 }
 
-- 
2.14.1

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

Re: [Mesa-dev] [PATCH 4/8] egl: rework input validation order in _eglCreateWindowSurfaceCommon

[Emil Velikov]

On 26 September 2017 at 18:08, Juan A. Suarez Romero
 wrote:
> On Wed, 2017-09-06 at 15:07 +0100, Emil Velikov wrote:
>> On 5 August 2017 at 00:25, Emil Velikov  wrote:
>> > From: Emil Velikov 
>> >
>> > As mentioned in previous commit the negative tests in dEQP expect the
>> > arguments to be evaluated in particular order.
>> >
>> > Namely - first the dpy, then the config, followed by the surface/window.
>> >
>> > Move the check further down or executing the test below will produce
>> > the following error.
>> >
>> >dEQP-EGL.functional.negative_api.create_pbuffer_surface
>> >
>> >
>> >
>> >   eglCreateWindowSurface(0x9bfff0f150, 0x, 
>> > 0x, { EGL_NONE });
>> >   // 0x returned
>> >   // ERROR expected: EGL_BAD_CONFIG, Got: 
>> > EGL_BAD_NATIVE_WINDOW
>> >
>> >
>>
>> FTR dEQP has been "fixed" (by removing the test all together) to not
>> generate the above error. At the same the Pixman equivalent is still
>> buggy, hence the v2 of commit
>> df8efd5b74d45e2bfb977a92dcd3db86abd6b143.
>>
>
> Emil, does it mean this patch is superseded? I'm interesting in knowing
> the situation as this was tagged to be included in stable release.
>
I'd like to keep this open and eventually merge it.
The dEQP patches need 'a bit' of polishing.

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

Re: [Mesa-dev] [Mesa-stable] [PATCH 2/2] egl/drm: set the VISUAL_TYPE alongside the VISUAL_ID

[Emil Velikov]

Hi Juan,

On 26 September 2017 at 18:00, Juan A. Suarez Romero
 wrote:
> On Tue, 2017-08-22 at 09:20 +0100, Daniel Stone wrote:
>> Hi,
>>
>> On 21 August 2017 at 18:30, Emil Velikov  wrote:
>> > On 21 August 2017 at 15:44, Daniel Stone  wrote:
>> > > My take on it is that the visual types are defined by the platform,
>> > > and 0 is a perfectly sensible visual type for a platform which does
>> > > not actually have any.
>> > >
>> >
>> > Having the exact same visual type for all visual IDs does strikes me
>> > as a bit odd.
>> > That said, the spec does not explicitly forbids it so I guess it should be 
>> > fine?
>>
>> It should be, yeah. It would be quite odd to use anything other than
>> TrueColor for X11, so in effect that only has one value for the type
>> either. Maybe just imagine '#define GBM_VISUAL_TYPE_FOURCC 0'
>> existing, with no others to ever be defined, and then it might make
>> more sense?
>>
>
> Hello, people.
>
> What's the status of this patch? It was tagged as candidate for stable,
> and hence I'd like to know if requires changes or a R-b.
>
Considering the feedback, I think we can throw the series in the bin.
At least in the current shape... Can revisit if we get some reports
that need them ;-)

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

[Mesa-dev] [PATCH 2/2] gallium/util: use new util_vasprintf() function

[Brian Paul]

---
 src/gallium/auxiliary/util/u_log.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/util/u_log.c 
b/src/gallium/auxiliary/util/u_log.c
index 359b3e1..dacbe05 100644
--- a/src/gallium/auxiliary/util/u_log.c
+++ b/src/gallium/auxiliary/util/u_log.c
@@ -24,6 +24,7 @@
 #include "u_log.h"
 
 #include "u_memory.h"
+#include "util/u_string.h"
 
 struct page_entry {
const struct u_log_chunk_type *type;
@@ -129,7 +130,7 @@ u_log_printf(struct u_log_context *ctx, const char *fmt, 
...)
char *str = NULL;
 
va_start(va, fmt);
-   int ret = vasprintf(, fmt, va);
+   int ret = util_vasprintf(, fmt, va);
va_end(va);
 
if (ret >= 0) {
-- 
1.9.1

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

Re: [Mesa-dev] [PATCH] st/dri: don't expose modifiers in EGL if the driver doesn't implement them

[Daniel Stone]

Hi Marek,

On 27 September 2017 at 15:55, Marek Olšák  wrote:
> if (dmabuf_ret && dmabuf_ret->val.val_bool) {
>uint64_t cap;
>
>if (drmGetCap(sPriv->fd, DRM_CAP_PRIME, ) == 0 &&
>(cap & DRM_PRIME_CAP_IMPORT)) {
>   dri2ImageExtension.createImageFromFds = dri2_from_fds;
>   dri2ImageExtension.createImageFromDmaBufs = dri2_from_dma_bufs;
>   dri2ImageExtension.createImageFromDmaBufs2 = dri2_from_dma_bufs2;
>   dri2ImageExtension.queryDmaBufFormats = dri2_query_dma_buf_formats;
> - dri2ImageExtension.queryDmaBufModifiers =
> -dri2_query_dma_buf_modifiers;
> + if (pscreen->query_dmabuf_modifiers) {
> +dri2ImageExtension.queryDmaBufModifiers =
> +   dri2_query_dma_buf_modifiers;
> + }

This should also not expose queryDmaBufFormats, since that is also
part of EGL_EXT_image_dma_buf_import_modifiers, which is pretty
useless without modifiers.

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

[Mesa-dev] [PATCH 1/2] util: add util_vasprintf() for Windows (v2)

[Brian Paul]

We don't have vasprintf() on Windows so we need to implement it ourselves.

v2: compute actual length of output string, per Nicolai Hähnle.
---
 src/util/u_string.h | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/src/util/u_string.h b/src/util/u_string.h
index e88e13f..48f1125 100644
--- a/src/util/u_string.h
+++ b/src/util/u_string.h
@@ -110,6 +110,27 @@ util_sprintf(char *str, const char *format, ...)
va_end(ap);
 }
 
+static inline int
+util_vasprintf(char **ret, const char *format, va_list ap)
+{
+   va_list ap_copy;
+
+   /* Compute length of output string first */
+   va_copy(ap_copy, ap);
+   int r = util_vsnprintf(NULL, 0, format, ap);
+   va_end(ap_copy);
+
+   if (r < 0)
+  return -1;
+
+   *ret = (char *) malloc(r + 1);
+   if (!ret)
+  return -1;
+
+   /* Print to buffer */
+   return util_vsnprintf(*ret, r + 1, format, ap);
+}
+
 static inline char *
 util_strchr(const char *s, char c)
 {
@@ -186,6 +207,7 @@ util_strstr(const char *haystack, const char *needle)
 #define util_vsnprintf vsnprintf
 #define util_snprintf snprintf
 #define util_vsprintf vsprintf
+#define util_vasprintf vasprintf
 #define util_sprintf sprintf
 #define util_strchr strchr
 #define util_strcmp strcmp
-- 
1.9.1

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

[Mesa-dev] [PATCH] st/dri: don't expose modifiers in EGL if the driver doesn't implement them

[Marek Olšák]

From: Marek Olšák 

This unbreaks waffle/gbm (piglit/gbm) which fails initialization.
---
 src/gallium/state_trackers/dri/dri2.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/gallium/state_trackers/dri/dri2.c 
b/src/gallium/state_trackers/dri/dri2.c
index 1e8bb48..c499822 100644
--- a/src/gallium/state_trackers/dri/dri2.c
+++ b/src/gallium/state_trackers/dri/dri2.c
@@ -1990,22 +1990,24 @@ dri2_init_screen(__DRIscreen * sPriv)
 
if (dmabuf_ret && dmabuf_ret->val.val_bool) {
   uint64_t cap;
 
   if (drmGetCap(sPriv->fd, DRM_CAP_PRIME, ) == 0 &&
   (cap & DRM_PRIME_CAP_IMPORT)) {
  dri2ImageExtension.createImageFromFds = dri2_from_fds;
  dri2ImageExtension.createImageFromDmaBufs = dri2_from_dma_bufs;
  dri2ImageExtension.createImageFromDmaBufs2 = dri2_from_dma_bufs2;
  dri2ImageExtension.queryDmaBufFormats = dri2_query_dma_buf_formats;
- dri2ImageExtension.queryDmaBufModifiers =
-dri2_query_dma_buf_modifiers;
+ if (pscreen->query_dmabuf_modifiers) {
+dri2ImageExtension.queryDmaBufModifiers =
+   dri2_query_dma_buf_modifiers;
+ }
   }
}
 
if (pscreen->get_param(pscreen, PIPE_CAP_DEVICE_RESET_STATUS_QUERY)) {
   sPriv->extensions = dri_robust_screen_extensions;
   screen->has_reset_status_query = true;
}
else
   sPriv->extensions = dri_screen_extensions;
 
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH] vc4: Mark BOs as purgeable when they enter the BO cache

[Boris Brezillon]

On Wed, 27 Sep 2017 15:24:16 +0100
Chris Wilson  wrote:

> Quoting Boris Brezillon (2017-09-27 15:06:53)
> > On Wed, 27 Sep 2017 14:50:10 +0100
> > Chris Wilson  wrote:
> >   
> > > Quoting Boris Brezillon (2017-09-27 14:45:17)  
> > > >  static struct vc4_bo *
> > > >  vc4_bo_from_cache(struct vc4_screen *screen, uint32_t size, const char 
> > > > *name)
> > > >  {
> > > > @@ -111,6 +121,11 @@ vc4_bo_from_cache(struct vc4_screen *screen, 
> > > > uint32_t size, const char *name)
> > > >  return NULL;
> > > >  }
> > > >  
> > > > +if (vc4_bo_purgeable(bo, false)) {
> > > > +mtx_unlock(>lock);
> > > > +return NULL;
> > > 
> > > So this would just mean that the bo was purged in the meantime. Why not
> > > just try to use the next one in the cache or allocate afresh?  
> > 
> > No, this means the BO was purged and the kernel failed to allocate the
> > memory back. We don't care about the retained status here, because we
> > don't need to restore BO's content, that's why we're not checking
> > arg.retained in vc4_bo_purgeable(). Allocating a fresh BO is likely to
> > fail with the same ENOMEM error because both path use the CMA mem.  
> 
> Hmm, you don't treat purging as permanent. But you do track the lose of
> contents, so retained is false?

vc4_bo_purgeable() is not reporting the retained status, it just
reports whether the BO can be used or not. I can change
vc4_bo_purgeable() semantic to return 1 if the BO content was retained,
0 if it was purged and -1 if you the ioctl returned an error (ENOMEM)
if you prefer, but in the end, all I'll check here is
'vc4_bo_purgeable() >= 0' because I don't don't care about the retained
status in this specific use case, all I care about is whether the BO can
be re-used or not (IOW, is there a valid CMA region attached to the BO).

> 
> I took a harder line, and said that userspace should recreate the object
> from scratch after it was purged. I thought that would be easier
> overall. But maybe not.:)

Well, maybe I'm wrong in how I implemented this
DRM_IOCTL_VC4_GEM_MADVISE ioctl, but right now, when the BO has been
purged and someone marks it back as unpurgeable I'm trying to
re-allocate BO's buffer in the ioctl path, and if the CMA allocation
fails I return -ENOMEM. I could move the allocation in the fault
handler, but this would result in pretty much the same behavior except
it would require an extra page-fault to realize the memory is not
available or force us to check the retained status and decide to
release the BO object from the BO cache.

Note that I tried to stay as close as possible to the existing
CMA-based-BO logic where everything is allocated at creation time and
not based on an on-demand allocation, hence the decision to allocate
the CMA region in the ioctl path and not in the page-fault handler.

Regards,

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

Re: [Mesa-dev] [PATCH 06/22] i965: Enable BatchbufferLogger in i965 driver

[Rogovin, Kevin]

>My worry is that batch->bo is not constant for the construction of a single 
>execbuf2.
> If intel_batchbuffer.c runs out of room inside the batch->bo, it will 
> allocate a new one and continue building it.

That will be ok, but if the (fd, GEM BO handle) changes, there is a serious 
issue.

> I'm just mentioning that may not be the same handle as some of the earlier 
> state calls.

This is a serious issue; sighs. The Logger will not miss any GPU state (since 
that is handled at ioctl interception time), but it will get the GL/GLES call 
ID's royally hosed because the api call markers will be on the log associated 
to that (old) (fd, GEM handle) pair.

Futz.

The solution is to add another function to the driver interface that the driver 
calls when it "migrates" stuff from one BO to another (i.e. when it grows a 
batchbuffer to fit in that last draw call).

Good catch on that, I had utterly forgotten that the batchbuffer split lets 
i965 "grow" the batchbuffer to fit in that one last call. All the stuff I have 
run on it so far have not hit that, but there will be loads where it gets hit.

I will fix this ASAP.

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

Re: [Mesa-dev] [PATCH 06/22] i965: Enable BatchbufferLogger in i965 driver

[Chris Wilson]

Quoting Rogovin, Kevin (2017-09-27 15:22:00)
> Hi,
> 
> > Hmm, this needs updating for the batch/state split; 
> 
> This was rebased (and working) against Mesa of Monday, Sept 25, 2017, which I 
> thought already had the batchbuffer split. I had thought the split was 
> already in master... but why would it need to know that the state is on a 
> separate BO? The logger reads into the batchbuffer, in particular, 
> STATE_BASE_ADDRESS, and uses that data to fetch the data structure placed 
> into the direct state jazz (which used to be at the end of the batchbuffer), 
> i.e. the logger chases GPU address to get GEM BO's and offsets into them. It 
> does this by tracking the creation (and destruction) all GEM BO's by 
> intercepting drmIoctl. The Logger chases everything so it can write out all 
> sorts of things, including shader disassembly (shaders are placed on a 
> different GEM BO as well).

No problem, I guessed it was assuming the old behaviour and knew that
everything (more or less) referred to the batch->bo.

> 
> > and of particular note that the batch->bo  is no longer constant. It 
> > shouldn't 
> > matter overall as the contents/offsets are preserved.
> > I would need to go back and see why you need to know the handle before the 
> > submit, 
> > but the obvious solution to me would be to record the submission.
> 
> The system if perfectly fine (and happy) if the value behind batch->bo 
> changes on every execbuffer2. The logger works as follows:
> Application calls pre_call() before issuing a GL API call. That function then 
> has the Logger ask the driver "what is the active batch buffer on this 
> thread?" whose answer is by calling intel_active_batchbuffer (). The active 
> batch buffer is identified by the pair (fd, GEM BO handle). The driver_data 
> pointer is not used by the Logger to track, rather it is for the driver to 
> use to point to whatever data structure it has for tracking batchbuffer (in 
> i965's case the address of brw->batch) so that can tell where it is in a 
> given batchbuffer. Now that the logger has the ID of the batchbuffer, i.e. 
> the pair (fd, GEM BO handle), it then knows to what batchbuffer the GL API 
> call is to be associated and it appends the call information to the log for 
> that batchbuffer. What is also important, is that the system will also work 
> if there are multiple threads in the calling application each with their own 
> context current. 

My worry is that batch->bo is not constant for the construction of a
single execbuf2. If intel_batchbuffer.c runs out of room inside the
batch->bo, it will allocate a new one and continue building it.

> When drmIoctl happens, the logger then trivially extracts the (fd, GEM BO 
> handle) pair of the batchbuffer to be executed and from there knows what log 
> to emit.

I'm just mentioning that may not be the same handle as some of the
earlier state calls.
-Chris
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH mesa 1/6] egl_dri2: move glFlush out of struct dri2_egl_driver

[Emil Velikov]

On 26 September 2017 at 23:47, Eric Engestrom  wrote:
> There's no reason to store this there, it doesn't depend on the driver.
>
> Signed-off-by: Eric Engestrom 
> ---
>  src/egl/drivers/dri2/egl_dri2.c | 44 
> ++---
>  src/egl/drivers/dri2/egl_dri2.h |  2 --
>  2 files changed, 19 insertions(+), 27 deletions(-)
>
> diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
> index f27e72505b..1f68bcdcbb 100644
> --- a/src/egl/drivers/dri2/egl_dri2.c
> +++ b/src/egl/drivers/dri2/egl_dri2.c
> @@ -101,6 +101,23 @@ dri_set_background_context(void *loaderPrivate)
> _eglBindContextToThread(ctx, t);
>  }
>
> +static void
> +dri2_gl_flush()
> +{
> +   static void (*glFlush)(void);
> +
> +   if (!glFlush)
> +  glFlush = _glapi_get_proc_address("glFlush");
> +
> +   /* if glFlush is not available things are horribly broken */
> +   if (!glFlush) {
> +  _eglLog(_EGL_WARNING, "DRI2: failed to find glFlush entry point");
> +  return;
> +   }
> +
> +   glFlush();
I'm slightly worries about a couple of things:

 A) before on !glFlush we'll fallback to "other" driver, now we'll just be stuck
Should be a non issue since the case should be unreachable in practise

 B) calling dri2_gl_flush from multiple threads
Currently that's implicitly handles by various locking further up the stack.
If we're to rework/drop that things will pair-shape here.

Can you please apply some magic for B?

The rest of the series is
Reviewed-by: Emil Velikov 

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

Re: [Mesa-dev] [PATCH] egl/wayland: Make wayland_drm_init declaration match the implementation

[Daniel Stone]

Hi,

On 27 September 2017 at 14:56, Emil Velikov  wrote:
> On 26 September 2017 at 21:51, Daniel Stone  wrote:
>> The wayland-drm callback struct is referenced, rather than duplicated,
>> inside wayland-drm. Constifying this struct involved moving it on to the
>> stack; as a result, starting any EGL client on Wayland called into
>> random stack memory, and killed the compositor.
>
> Thanks Dan and pardon for the mess.
>
> I think we'd want to change wl_drm to have a copy of the callbacks.
> As-is one could get a crash racing dlclose of libEGL (or friends)
> while any of the callbacks are still used.

Sure, and it's also broken with doing BindWaylandDisplay multiple
times, I'd imagine. I'd happily review & test a patch which copies the
struct, as that seems like the right thing to do, but a revert was
quickest/easiest for now.

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

Re: [Mesa-dev] [PATCH] vc4: Mark BOs as purgeable when they enter the BO cache

[Chris Wilson]

Quoting Boris Brezillon (2017-09-27 15:06:53)
> On Wed, 27 Sep 2017 14:50:10 +0100
> Chris Wilson  wrote:
> 
> > Quoting Boris Brezillon (2017-09-27 14:45:17)
> > >  static struct vc4_bo *
> > >  vc4_bo_from_cache(struct vc4_screen *screen, uint32_t size, const char 
> > > *name)
> > >  {
> > > @@ -111,6 +121,11 @@ vc4_bo_from_cache(struct vc4_screen *screen, 
> > > uint32_t size, const char *name)
> > >  return NULL;
> > >  }
> > >  
> > > +if (vc4_bo_purgeable(bo, false)) {
> > > +mtx_unlock(>lock);
> > > +return NULL;  
> > 
> > So this would just mean that the bo was purged in the meantime. Why not
> > just try to use the next one in the cache or allocate afresh?
> 
> No, this means the BO was purged and the kernel failed to allocate the
> memory back. We don't care about the retained status here, because we
> don't need to restore BO's content, that's why we're not checking
> arg.retained in vc4_bo_purgeable(). Allocating a fresh BO is likely to
> fail with the same ENOMEM error because both path use the CMA mem.

Hmm, you don't treat purging as permanent. But you do track the lose of
contents, so retained is false?

I took a harder line, and said that userspace should recreate the object
from scratch after it was purged. I thought that would be easier
overall. But maybe not.:)
-Chris
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] egl/dri2: Implement swapInterval fallback in a conformant way (v2)

[Tomasz Figa]

On Wed, Sep 27, 2017 at 11:06 PM, Emil Velikov  wrote:
> On 25 September 2017 at 08:25, Tomasz Figa  wrote:
>
>> Gentle ping. :)
>>
>
> I forgot that you don't have commit access. Can you please apply for one?

Yep, I have it on my list, sorry for being slow. Thanks for useful
links. (Need to dig out my PGP key.)

Best regards,
Tomasz

>
> Thanks
> Emil
>
> [1] https://www.freedesktop.org/wiki/AccountRequests/
> [2] https://bugs.freedesktop.org/show_bug.cgi?id=99601
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev