Re: Intel clc dependency

[Tapani Pälli]

On 11.4.2024 1.15, Brian Paul wrote:

On 4/10/24 13:53, Timo Aaltonen wrote:

Brian Paul kirjoitti 6.4.2024 klo 1.05:
I'm trying to build the Intel Vulkan driver.  First time in a few 
months.  I'm having build problems related to clc.  I'm on Ubuntu 22.04



[...]
[1347/3181] Generating src/intel/vulkan/...om command (wrapped by 
meson to set env)
FAILED: 
src/intel/vulkan/grl/gfx125_bvh_build_BFS_BFS_pass1_indexed_batchable.h
env MESA_SHADER_CACHE_DISABLE=true MESA_SPIRV_LOG_LEVEL=error 
/home/brianp/build3/mesa/build/src/intel/compiler/intel_clc -p dg2 
--prefix gfx125_bvh_build_BFS_BFS_pass1_indexed_batchable -e 
BFS_pass1_indexed_batchable --in 
../src/intel/vulkan/grl/gpu/bvh_build_BFS.cl --in 
/home/brianp/build3/mesa/src/intel/vulkan/grl/gpu/libs/lsc_intrinsics_fallback.cl 
-o 
src/intel/vulkan/grl/gfx125_bvh_build_BFS_BFS_pass1_indexed_batchable.h 
-- -cl-std=cl2.0 -D__OPENCL_VERSION__=200 -DMAX_HW_SIMD_WIDTH=16 
-DMAX_WORKGROUP_SIZE=16 
-I/home/brianp/build3/mesa/src/intel/vulkan/grl/gpu 
-I/home/brianp/build3/mesa/src/intel/vulkan/grl/include

ERROR: libclc shader missing. Consider installing the libclc package
Aborted (core dumped)

I've installed every clc-related package I could find.  I've tried 
several options for the 'intel-clc' option without luck.


BTW, the description of intel-clc in meson_options.txt looks suspect:

option(
   'intel-clc',
   type : 'combo',
   deprecated: {'true': 'enabled', 'false': 'disabled'},
   value : 'disabled',
   choices : [
 'enabled', 'disabled', 'system',
   ],
   description : 'Build the intel-clc compiler (enables Vulkan Intel 
' +

 'Ray Tracing on supported hardware).'
)

The default is 'disabled' but that's deprecated?  Choices include 
'enabled' but that's deprecated too?


Any tips for building the ToT Intel Vulkan driver?

-Brian



You need to have libclc-NN-dev installed matching with the llvm 
version, which on stock 22.04 would be libclc-13-dev.


I'm using llvm 15 and have libclc-15-dev installed.  I get the "ERROR: 
libclc shader missing. Consider installing the libclc package" issue I 
quoted above.




You'll need to install libclc-15 too. I think libclc-15-dev package is 
missing dependency to libclc-15 .. did not verify this but I've been 
able to install libclc-15-dev without the library package getting installed.



I have llvm 15 installed because I also want to build the radv Vulkan 
driver.


-Brian

Re: [ANNOUNCE] mesa 22.3.0-rc1

[Tapani Pälli]

On 2.11.2022 23.25, Eric Engestrom wrote:

Hello everyone,

I'm happy to announce the start of a new release cycle with the first
release candidate, 22.3.0-rc1.

New features (in no particular order):
- GL_ARB_shader_clock on llvmpipe
- VK_KHR_shader_clock on lavapipe
- Mesa-DB, the new single file cache type
- VK_EXT_attachment_feedback_loop_layout on RADV, lavapipe
- VK_KHR_global_priority on RADV
- GL_KHR_blend_equation_advanced_coherent on zink
- VK_EXT_load_store_op_none on RADV
- VK_EXT_mutable_descriptor_type on RADV
- VK_EXT_shader_atomic_float on lvp
- VK_EXT_shader_atomic_float2 on lvp
- GL_NV_shader_atomic_float on llvmpipe
- VK_EXT_image_robustness on v3dv
- VK_EXT_extended_dynamic_state3 on lavapipe
- VK_EXT_extended_dynamic_state3 on RADV


+ VK_EXT_extended_dynamic_state3 on anv


- VK_EXT_pipeline_robustness on v3dv
- Mali T620 on panfrost
- Shader disk cache on Panfrost
- support for R8G8B8, B8G8R8, R16G16B16 and 64-bit vertex buffer formats
   on RADV
- initial GFX11/RDNA3 support on RADV
- various ray tracing optimizations on RADV
- extendedDynamicState2PatchControlPoints on RADV
   (VK_EXT_extended_dynamic_state2 feature)
- Radeon Raytracing Analyzer integration (using RADV_RRA_* environment
   variables)

A couple of notes for packagers:
- When building the Intel Vulkan driver with ray-tracing (using
   `-D intel-clc=enabled`, disabled by default), libclc is required
   (both as build and runtime dependency).
- Rusticl, the OpenCL implementation (`-D gallium-rusticl=true`,
   disabled by default), introduces a bunch of new dependencies.
   Make sure you read docs/rusticl.rst (https://docs.mesa3d.org/rusticl)
   if you're considering enabling it.

For now, no driver is enabled by default in Rusticl. See here for how
to enable them:
https://docs.mesa3d.org/envvars#rusticl-environment-variables

If you find any issues, please report them here:
https://gitlab.freedesktop.org/mesa/mesa/-/issues/new

The next release candidate is expected in one week, on November 9th.

Cheers,
   Eric

---

git tag: mesa-22.3.0-rc1

https://mesa.freedesktop.org/archive/mesa-22.3.0-rc1.tar.xz
SHA256: 2f2e0fca149bd8dcc333ebeda14fc14ebd8a10c3560cf2958b5ebdaa455d0566  
mesa-22.3.0-rc1.tar.xz
SHA512: 
5222759260f0288c28fab9ba419a7699aa85033ccf30fb5070ae558e342158ef0981974196fd10c738fa187b774807d4a2de03b98360efef5c03040484abd52c
  mesa-22.3.0-rc1.tar.xz
PGP:  https://mesa.freedesktop.org/archive/mesa-22.3.0-rc1.tar.xz.sig

Re: [Mesa-dev] bad performance issue in GPU & CPU data sharing

[Tapani Pälli]

Hi;

On 5/31/21 12:33 PM, Zong, Wei wrote:

Hello,

I'm using GLES shader to run algorithms on image frames, I got very bad 
performance issue in GPU & CPU data sharing, especially retrieve data 
from GPU to CPU.


Basically, I use 
*/glGenBuffers/*/*/glBindBuffer/*/*/glBufferData(target, size, data, 
usage) /*to create GPU buffer object and initialize GPU data store with 
CPU data pointer. After GLES shader finished the processing, I use 
/*glMapBufferRange*///to retrieve processed image data back to CPU, and 
for some reason I have to do an extra data copy from the gl map pointer 
to another CPU buffer, this is super slow.


Here’s the code snippet 
https://github.com/intel/libxcam/blob/master/modules/gles/gl_buffer.cpp#L94 



https://github.com/intel/libxcam/blob/master/modules/gles/gl_buffer.cpp#L127 



I wonder If there has other efficient way to sharing data between CPU & 
GPU GLES shader?


Thanks,

Zong Wei



Could you break down the use-case here a bit, why do you need CPU access 
to the image? If I understand correctly, is it so that camera pipeline 
renders to a dmabuf and then this is imported to GLES for processing and 
then you map it to CPU for ... something?


Thanks;

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

Re: [Mesa-dev] Fwd: [Mesa-users] Surfaceless mesa 20.3.X?

[Tapani Pälli]

Hi;

On 27.1.2021 15.01, Brian Paul wrote:
Forwarding to mesa-dev where you may get more help.  There was talk of 
changing software rendering but I'm not sure what's changed.  What 
version of Mesa are you using?


-Brian


 Forwarded Message 
Subject: [Mesa-users] Surfaceless mesa 20.3.X?
Date: Wed, 27 Jan 2021 09:59:03 +0100
From: Sophonet 
To: mesa-us...@lists.freedesktop.org

Hi list,

I would like to compile mesa for a surfaceless system (server, software 
rendering, no GPU). This was possible earlier with the „surfaceless“ 
platform.


The recent versions do not allow surfaceless as a platform option 
anymore. The build info which is listed for building osmesa 
(https://docs.mesa3d.org/osmesa.html) does not list a platform, and in 
that case, wayland is required, which is not available on our server.


Surfaceless option was removed because it is now compiled always (see 
commit a38e21d6683 "egl: always compile surfaceless"). It is compiled 
always and is supported.



I could build osMesa with the x11 platform, but rendering does not work 
if there is no (remote) X connection (DISPLAY missing etc.).


What is the recommended approach now?

Thanks,

sophonet



___
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] [EXT] Re: GLES 3.2 support for android

[Tapani Pälli]

Hi;

Sorry for very late answer, I've managed to miss this mail.

On 6/18/20 2:06 PM, Vinay Kumar Madaralli Panchakshari wrote:

Hi Tapani,

  Thanks for the info.





Hi;

On 6/17/20 11:51 AM, Vinay Kumar Madaralli Panchakshari wrote:

Dear mesa-dev team,

Is there a support for GLES 3.2 ?


What kind of hardware and Android version/release are you using?

[VINAY] : Android-9 (Pie) a9_r42 revision.

Mesa version- 20.1.0
Underlying host GPU - case 1: AMD RX500 and Vega series  
(with mesa UMD driver)
 case 2 : Nvidia T4
 


The latest we are using on android points to 3.1 version.



While in practice there may be 3.2 support from the drivers, Android itself 
might be configured (this is a build time configuration) to advertise support 
for OpenGL ES 3.1 + Android extension pack (AEP).

[VINAY] : May be this is true.

   If so, Is it supported/feasible to reconfigure it for 
3.2 provided the above details.



You can try to configure this by setting ro.opengles.version:
ro.opengles.version=196610

This setting is in the 'build.prop' file which may be generated during 
the build depending on what kind of android sources you are building. 
Sometimes this is set in device.mk with following:


PRODUCT_PROPERTY_OVERRIDES  += ro.opengles.version=196610

For individual applications you can also try to toggle this during 
runtime (I don't know if that really works though):


setprop ro.opengles.version=196610


Hopefully this helps!





---

I SurfaceFlinger: version   : OpenGL ES 3.1 Mesa 20.1.0-devel
(git-87924646db)



Regards,
Vinay


-Original Message-
From: Tapani Pälli 
Sent: Thursday, June 18, 2020 3:19 PM
To: Vinay Kumar Madaralli Panchakshari ; 
mesa-dev@lists.freedesktop.org
Subject: [EXT] Re: [Mesa-dev] GLES 3.2 support for android

External Email

--
Hi;

On 6/17/20 11:51 AM, Vinay Kumar Madaralli Panchakshari wrote:

Dear mesa-dev team,

Is there a support for GLES 3.2 ?


What kind of hardware and Android version/release are you using?

[VINAY] : Android-9 (Pie) a9_r42 revision.

Mesa version- 20.1.0
Underlying host GPU - case 1: AMD RX500 and Vega series  
(with mesa UMD driver)
 case 2 : Nvidia T4
 


The latest we are using on android points to 3.1 version.



While in practice there may be 3.2 support from the drivers, Android itself 
might be configured (this is a build time configuration) to advertise support 
for OpenGL ES 3.1 + Android extension pack (AEP).

[VINAY] : May be this is true.

   If so, Is it supported/feasible to reconfigure it for 
3.2 provided the above details.

  


---

I SurfaceFlinger: version   : OpenGL ES 3.1 Mesa 20.1.0-devel
(git-87924646db)

Regards,

Vinay


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop
.org_mailman_listinfo_mesa-2Ddev=DwID-g=nKjWec2b6R0mOyPaz7xtfQ=x
NS9hkQzE1o5-sUnrBfutTuL4GSG4ihW6TZHNz8_1jc=ToyGLz8mx52-k-1uipWdHiXMs
vpv786Jqs_EeAiwaUA=2PoZa5gfUNqfMZ-HJs8aoB5CK8DFd5uMuDmaDSBFLCU=



// Tapani


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

Re: [Mesa-dev] GLES 3.2 support for android

[Tapani Pälli]

Hi;

On 6/17/20 11:51 AM, Vinay Kumar Madaralli Panchakshari wrote:

Dear mesa-dev team,

Is there a support for GLES 3.2 ?


What kind of hardware and Android version/release are you using?


The latest we are using on android points to 3.1 version.



While in practice there may be 3.2 support from the drivers, Android 
itself might be configured (this is a build time configuration) to 
advertise support for OpenGL ES 3.1 + Android extension pack (AEP).




---

I SurfaceFlinger: version   : OpenGL ES 3.1 Mesa 20.1.0-devel 
(git-87924646db)


Regards,

Vinay


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



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

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Tapani Pälli]

Hi;

On 12/4/19 2:39 AM, Marek Olšák wrote:

Hi,

Here are 2 proposals to simplify and better optimize the GL->Gallium 
translation.


1) Move classic drivers to a fork of Mesa, and remove them from master. 
Classic drivers won't share any code with master. glvnd will load them, 
but glvnd is not ready for this yet.


2) Keep classic drivers. Fork src/mesa for Gallium. I think only 
mesa/main, mesa/vbo, mesa/program, and drivers/dri/common need to be 
forked and mesa/state_tracker moved. src/gallium/state-trackers/gl/ can 
be the target location.


Option 2 is more acceptable to people who want to keep classic drivers 
in the tree and it can be done right now.


Opinions?



I'm still quite newbie with gallium side of things and I'd like to know 
more about the possible simplifications and optimizations that could be 
done if this happened. Is this more about 'cleaning up the tree' or are 
there also some performance opportunities we are missing right now with 
current state?


Thanks;

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

Re: [Mesa-dev] How to merge Mesa changes which require corresponding piglit changes

[Tapani Pälli]

On 12/2/19 5:25 PM, Michel Dänzer wrote:

On 2019-12-02 3:15 p.m., Tapani Pälli wrote:

On 11/15/19 8:41 PM, Mark Janes wrote:

Michel Dänzer  writes:


On 2019-11-15 4:02 p.m., Mark Janes wrote:

Michel Dänzer  writes:


Now that the GitLab CI pipeline tests a snapshot of piglit with
llvmpipe
(https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2468), the
question has come up how to deal with inter-dependent Mesa/piglit
changes (where merging only one or the other causes some piglit
regressions).


First of all, let it be clear that just merging the Mesa changes as-is
and breaking the GitLab CI pipeline is not acceptable.


  From the Mesa POV, the easiest solution is:

1. Merge the piglit changes
2. In the Mesa MR (merge request), add a commit which updates
piglit[0]
3. If the CI pipeline is green, the MR can be merged


In case one wants to avoid alarms from external CI systems, another
possibility is:


For the Intel CI, no alarm is generated if the piglit test is pushed
first.  Normal development process includes writing a piglit test to
illustrate the bug that is being fixed.


Cool, but what if the piglit changes affect the results of existing
tests? That was the situation yesterday which prompted this thread.


We attribute the status change to piglit in the CI config, within a few
hours.  The test shows up as a failure in CI until it is triaged.


I think we have a problem with current gitlab CI process.

Right now if someone needs to update piglit commit used by CI, he also
ends up fixing and editing the .gitlab-ci/piglit/quick_gl.txt (and
glslparser+quick_shader.txt) as CI reports numerous failures because of
completely unrelated stuff as meanwhile people added other tests,
removed tests and modified them.


This is at least somewhat intentional, as the results of any newly added
tests should be carefully checked for plausibility.



I think we should turn such warnings on only when we have more
sophisticated algorithm to detect actual regression (not just 'state
change', like additional test or removed test).


It's unclear what exactly you're proposing. In order to catch
regressions (e.g. pass -> warn, pass -> fail, pass -> skip, pass ->
crash), we need a list of all tests on at least one side of each
transition. We're currently keeping the list of all
warning/failing/skipped/crashing tests, but not passing tests (to keep
the lists as small as possible).

One possibility might be to remove the summary at the end of the lists.
That would allow new passing tests to be silently added, but it would
mean we could no longer catch pass -> notrun regressions.



Yeah, the last point is what I had in mind but it is tricky .. I guess I 
don't really have a good concrete proposal currently but I was hoping 
maybe someone comes up with one :)


I guess my issues boil down to difference vs Intel CI that there we 
track Piglit master so the overall state is 'more fresh'. With current 
gitlab CI the issues come late as many commits may have happened. So the 
person dealing with the issue (updating tag) does not have the context 
of those changes or maybe even expertise about the changes (and what was 
expected result), it should've have been caught already earlier.


It could be also that I'm trying to update too big chunk at once, should 
go commit by commit and see what happens to the results.


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

Re: [Mesa-dev] How to merge Mesa changes which require corresponding piglit changes

[Tapani Pälli]

Hi;

On 11/15/19 8:41 PM, Mark Janes wrote:

Michel Dänzer  writes:


On 2019-11-15 4:02 p.m., Mark Janes wrote:

Michel Dänzer  writes:


Now that the GitLab CI pipeline tests a snapshot of piglit with llvmpipe
(https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2468), the
question has come up how to deal with inter-dependent Mesa/piglit
changes (where merging only one or the other causes some piglit
regressions).


First of all, let it be clear that just merging the Mesa changes as-is
and breaking the GitLab CI pipeline is not acceptable.


 From the Mesa POV, the easiest solution is:

1. Merge the piglit changes
2. In the Mesa MR (merge request), add a commit which updates piglit[0]
3. If the CI pipeline is green, the MR can be merged


In case one wants to avoid alarms from external CI systems, another
possibility is:


For the Intel CI, no alarm is generated if the piglit test is pushed
first.  Normal development process includes writing a piglit test to
illustrate the bug that is being fixed.


Cool, but what if the piglit changes affect the results of existing
tests? That was the situation yesterday which prompted this thread.


We attribute the status change to piglit in the CI config, within a few
hours.  The test shows up as a failure in CI until it is triaged.


I think we have a problem with current gitlab CI process.

Right now if someone needs to update piglit commit used by CI, he also 
ends up fixing and editing the .gitlab-ci/piglit/quick_gl.txt (and 
glslparser+quick_shader.txt) as CI reports numerous failures because of 
completely unrelated stuff as meanwhile people added other tests, 
removed tests and modified them. I think we should turn such warnings on 
only when we have more sophisticated algorithm to detect actual 
regression (not just 'state change', like additional test or removed test).



1. In the Mesa MR, add a commit which disables the piglit tests broken
by the Mesa changes.
2. If the CI pipeline is green, the MR can be merged
3. Merge the piglit changes
4. Create another Mesa MR which updates piglit[0] and re-enables the
tests disabled in step 1

I hope that covers it, don't hesitate to ask questions if something's
still unclear.


It might help developers if CI generated the patch to make their pipeline
pass.


It does for the test result list, if that's what you mean.

However, that patch shouldn't be applied mechanically, but only after
confirming that all changes in test results are expected. Ideally,
whenever there are any new tests, the corresponding CI jobs should be
run several times to make sure the new results are stable, otherwise any
flaky tests should be excluded.


--
Earthling Michel Dänzer   |   https://redhat.com
Libre software enthusiast | Mesa and X developer

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




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

Re: [Mesa-dev] [PATCH] egl: Mention if swrast is being forced

[Tapani Pälli]

Makes sense;

Reviewed-By: Tapani Pälli 

On 10/31/19 9:35 AM, Chris Wilson wrote:

The system can be disabling HW acceleration unbeknowst to the user,
leading to a long debug session trying to work out which component is
failing. A quick mention that it is the environment override would be
very useful.
---
  src/egl/main/egldriver.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/src/egl/main/egldriver.c b/src/egl/main/egldriver.c
index 0d8919aa0e1..132b12ab4cb 100644
--- a/src/egl/main/egldriver.c
+++ b/src/egl/main/egldriver.c
@@ -92,6 +92,8 @@ _eglMatchDriver(_EGLDisplay *disp)
 /* set options */
 disp->Options.ForceSoftware =
env_var_as_boolean("LIBGL_ALWAYS_SOFTWARE", false);
+   if (disp->Options.ForceSoftware)
+  _eglLog(_EGL_DEBUG, "Found 'LIBGL_ALWAYS_SOFTWARE' set, forcing swrast");
  
 best_drv = _eglMatchAndInitialize(disp);

 if (!best_drv && !disp->Options.ForceSoftware) {


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

Re: [Mesa-dev] [PATCH] egl/android: Enable HAL_PIXEL_FORMAT_RGBA_FP16 format

[Tapani Pälli]

Reviewed-by: Tapani Pälli 

On 8/29/19 12:18 AM, Nataraj Deshpande wrote:

The patch adds support for 64 bit HAL_PIXEL_FORMAT_RGBA_FP16
for android platform.

Fixes android.graphics.cts.BitmapColorSpaceTest#test16bitHardware
which failed in egl due to "Unsupported native buffer format 0x16"
on chromebooks.

Change-Id: I44f886fce27fe5f738d2dc229eed8b59088cf6d6
Signed-off-by: Nataraj Deshpande 
---
  src/egl/drivers/dri2/platform_android.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/src/egl/drivers/dri2/platform_android.c 
b/src/egl/drivers/dri2/platform_android.c
index 601b29e..97e7947 100644
--- a/src/egl/drivers/dri2/platform_android.c
+++ b/src/egl/drivers/dri2/platform_android.c
@@ -109,6 +109,9 @@ get_format_bpp(int native)
 int bpp;
  
 switch (native) {

+   case HAL_PIXEL_FORMAT_RGBA_FP16:
+  bpp = 8;
+  break;
 case HAL_PIXEL_FORMAT_RGBA_:
 case HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED:
/*
@@ -143,6 +146,7 @@ static int get_fourcc(int native)
 * TODO: Remove this once https://issuetracker.google.com/32077885 is 
fixed.
 */
 case HAL_PIXEL_FORMAT_RGBX_: return __DRI_IMAGE_FOURCC_XBGR;
+   case HAL_PIXEL_FORMAT_RGBA_FP16: return __DRI_IMAGE_FOURCC_ABGR16161616F;
 default:
_eglLog(_EGL_WARNING, "unsupported native buffer format 0x%x", native);
 }
@@ -161,6 +165,7 @@ static int get_format(int format)
 * TODO: Revert this once https://issuetracker.google.com/32077885 is 
fixed.
 */
 case HAL_PIXEL_FORMAT_RGBX_: return __DRI_IMAGE_FORMAT_XBGR;
+   case HAL_PIXEL_FORMAT_RGBA_FP16: return __DRI_IMAGE_FORMAT_ABGR16161616F;
 default:
_eglLog(_EGL_WARNING, "unsupported native buffer format 0x%x", format);
 }


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

Re: [Mesa-dev] [PATCH] android: mesa: revert "Enable asm unconditionally"

[Tapani Pälli]

On 8/15/19 12:52 PM, Mauro Rossi wrote:

Hi Tapani,

On Thu, Aug 15, 2019 at 7:29 AM Tapani Pälli <mailto:tapani.pa...@intel.com>> wrote:



On 8/13/19 9:55 PM, Mauro Rossi wrote:
 > Hi,
 >
 > On Tue, Aug 13, 2019 at 3:51 PM Tapani Pälli
mailto:tapani.pa...@intel.com>
 > <mailto:tapani.pa...@intel.com <mailto:tapani.pa...@intel.com>>>
wrote:
 >
 >
 >     On 8/13/19 3:32 PM, Mauro Rossi wrote:
 >      > Hi,
 >      >
 >      > On Tue, Aug 13, 2019 at 2:03 PM Tapani Pälli
 >     mailto:tapani.pa...@intel.com>
<mailto:tapani.pa...@intel.com <mailto:tapani.pa...@intel.com>>
 >      > <mailto:tapani.pa...@intel.com
<mailto:tapani.pa...@intel.com> <mailto:tapani.pa...@intel.com
<mailto:tapani.pa...@intel.com>>>>
 >     wrote:
 >      >
 >      >     Hi;
 >      >
 >      >     On 8/13/19 2:43 PM, Mauro Rossi wrote:
 >      >      > Hi Tapani,
 >      >      >
 >      >      > On Sat, Jul 27, 2019 at 2:56 PM Mauro Rossi
 >      >     mailto:issor.or...@gmail.com>
<mailto:issor.or...@gmail.com <mailto:issor.or...@gmail.com>>
 >     <mailto:issor.or...@gmail.com <mailto:issor.or...@gmail.com>
<mailto:issor.or...@gmail.com <mailto:issor.or...@gmail.com>>>
 >      >      > <mailto:issor.or...@gmail.com
<mailto:issor.or...@gmail.com>
 >     <mailto:issor.or...@gmail.com <mailto:issor.or...@gmail.com>>
<mailto:issor.or...@gmail.com <mailto:issor.or...@gmail.com>
 >     <mailto:issor.or...@gmail.com
<mailto:issor.or...@gmail.com>>>>> wrote:
 >      >      >
 >      >      >     On Sat, Jul 27, 2019 at 2:56 PM Mauro Rossi
 >      >     mailto:issor.or...@gmail.com>
<mailto:issor.or...@gmail.com <mailto:issor.or...@gmail.com>>
 >     <mailto:issor.or...@gmail.com <mailto:issor.or...@gmail.com>
<mailto:issor.or...@gmail.com <mailto:issor.or...@gmail.com>>>
 >      >      >     <mailto:issor.or...@gmail.com
<mailto:issor.or...@gmail.com>
 >     <mailto:issor.or...@gmail.com <mailto:issor.or...@gmail.com>>
 >      >     <mailto:issor.or...@gmail.com
<mailto:issor.or...@gmail.com>
 >     <mailto:issor.or...@gmail.com
<mailto:issor.or...@gmail.com>>>>> wrote:
 >      >      >      >
 >      >      >      > On Thu, Jul 18, 2019 at 1:07 PM Chih-Wei Huang
 >      >      >     mailto:cwhu...@android-x86.org>
 >     <mailto:cwhu...@android-x86.org
<mailto:cwhu...@android-x86.org>> <mailto:cwhu...@android-x86.org
<mailto:cwhu...@android-x86.org>
 >     <mailto:cwhu...@android-x86.org
<mailto:cwhu...@android-x86.org>>>
 >      >     <mailto:cwhu...@android-x86.org
<mailto:cwhu...@android-x86.org>
 >     <mailto:cwhu...@android-x86.org
<mailto:cwhu...@android-x86.org>> <mailto:cwhu...@android-x86.org
<mailto:cwhu...@android-x86.org>
 >     <mailto:cwhu...@android-x86.org
<mailto:cwhu...@android-x86.org>>>>>
 >      >     wrote:
 >      >      >      > >
 >      >      >      > > Mauro Rossi mailto:issor.or...@gmail.com>
 >     <mailto:issor.or...@gmail.com <mailto:issor.or...@gmail.com>>
 >      >     <mailto:issor.or...@gmail.com
<mailto:issor.or...@gmail.com> <mailto:issor.or...@gmail.com
<mailto:issor.or...@gmail.com>>>
 >      >      >     <mailto:issor.or...@gmail.com
<mailto:issor.or...@gmail.com>
 >     <mailto:issor.or...@gmail.com <mailto:issor.or...@gmail.com>>
 >      >     <mailto:issor.or...@gmail.com
<mailto:issor.or...@gmail.com>
 >     <mailto:issor.or...@gmail.com
<mailto:issor.or...@gmail.com>>>>> 於 2019年7月14日 週日 下午5:17寫道：
 >      >      >      > > >
 >      >      >      > > > This patch partially reverts 20294dc ("mesa:
 >     Enable asm
 >      >      >     unconditionally, ...")
 >      >      >      > > >
 >      >      >      > > > Android makefile build logic needs to
disable
 >     assembler
 >      >      >     optimization
 >      >      >      > > > in 32bit builds to avoid text
relocations for
 >      >     libglapi

Re: [Mesa-dev] [PATCH] egl/android: remove HAL_PIXEL_FORMAT_BGRA_8888 support

[Tapani Pälli]

On 8/14/19 7:43 AM, Lepton Wu wrote:

Any concern for this CL? I think it's pretty safe to merge this since
any way android egl wrapper
doesn't like HAL_PIXEL_FORMAT_BGRA_ and won't return it for native
window format
and then won't set it as native window format.

https://android.googlesource.com/platform/frameworks/native/+/refs/heads/master/opengl/libs/EGL/eglApi.cpp#608


No concerns, this is fine.

Reviewed-by: Tapani Pälli 



On Wed, Jul 31, 2019 at 3:50 PM Lepton Wu  wrote:


From: Emil Velikov 

As said in the EGL_KHR_platform_android extensions

 For each EGLConfig that belongs to the Android platform, the
 EGL_NATIVE_VISUAL_ID attribute is an Android window format, such as
 WINDOW_FORMAT_RGBA_.

Although it should be applicable overall.

Even though we use HAL_PIXEL_FORMAT here, those are numerically
identical to the  WINDOW_FORMAT_ and AHARDWAREBUFFER_FORMAT_ ones.

Barring the said format of course. That one is only listed in HAL.

Keep in mind that even if we try to use the said format, you'll get
caught by droid_create_surface(). The function compares the format of
the underlying window, against the NATIVE_VISUAL_ID of the config.

Unfortunatelly it only prints a warning, rather than error out, likely
leading to visual corruption.

While SDL will even call ANativeWindow_setBuffersGeometry() with the
wrong format, and conviniently ignore the [expected] failure.

Signed-off-by: Emil Velikov 
Acked-by: Tomasz Figa 
(tfiga: Remove only respective EGL config, leave EGL image as is.)
Signed-off-by: Tomasz Figa 
Signed-off-by: Lepton Wu 
---
  src/egl/drivers/dri2/platform_android.c | 1 -
  1 file changed, 1 deletion(-)

diff --git a/src/egl/drivers/dri2/platform_android.c 
b/src/egl/drivers/dri2/platform_android.c
index d37f6b8e447..6c54fc4f1fe 100644
--- a/src/egl/drivers/dri2/platform_android.c
+++ b/src/egl/drivers/dri2/platform_android.c
@@ -1193,7 +1193,6 @@ droid_add_configs_for_visuals(_EGLDriver *drv, 
_EGLDisplay *disp)
{ HAL_PIXEL_FORMAT_RGBA_, { 0x00ff, 0xff00, 0x00ff, 
0xff00 } },
{ HAL_PIXEL_FORMAT_RGBX_, { 0x00ff, 0xff00, 0x00ff, 
0x } },
{ HAL_PIXEL_FORMAT_RGB_565,   { 0xf800, 0x07e0, 0x001f, 
0x } },
-  { HAL_PIXEL_FORMAT_BGRA_, { 0x00ff, 0xff00, 0x00ff, 
0xff00 } },
 };

 unsigned int format_count[ARRAY_SIZE(visuals)] = { 0 };
--
2.22.0.770.g0f2c4a37fd-goog


___
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] android: mesa: revert "Enable asm unconditionally"

[Tapani Pälli]

On 8/13/19 9:55 PM, Mauro Rossi wrote:

Hi,

On Tue, Aug 13, 2019 at 3:51 PM Tapani Pälli <mailto:tapani.pa...@intel.com>> wrote:



On 8/13/19 3:32 PM, Mauro Rossi wrote:
 > Hi,
 >
 > On Tue, Aug 13, 2019 at 2:03 PM Tapani Pälli
mailto:tapani.pa...@intel.com>
 > <mailto:tapani.pa...@intel.com <mailto:tapani.pa...@intel.com>>>
wrote:
 >
 >     Hi;
 >
 >     On 8/13/19 2:43 PM, Mauro Rossi wrote:
 >      > Hi Tapani,
 >      >
 >      > On Sat, Jul 27, 2019 at 2:56 PM Mauro Rossi
 >     mailto:issor.or...@gmail.com>
<mailto:issor.or...@gmail.com <mailto:issor.or...@gmail.com>>
 >      > <mailto:issor.or...@gmail.com
<mailto:issor.or...@gmail.com> <mailto:issor.or...@gmail.com
<mailto:issor.or...@gmail.com>>>> wrote:
 >      >
 >      >     On Sat, Jul 27, 2019 at 2:56 PM Mauro Rossi
 >     mailto:issor.or...@gmail.com>
<mailto:issor.or...@gmail.com <mailto:issor.or...@gmail.com>>
 >      >     <mailto:issor.or...@gmail.com
<mailto:issor.or...@gmail.com>
 >     <mailto:issor.or...@gmail.com
<mailto:issor.or...@gmail.com>>>> wrote:
 >      >      >
 >      >      > On Thu, Jul 18, 2019 at 1:07 PM Chih-Wei Huang
 >      >     mailto:cwhu...@android-x86.org> <mailto:cwhu...@android-x86.org
<mailto:cwhu...@android-x86.org>>
 >     <mailto:cwhu...@android-x86.org
<mailto:cwhu...@android-x86.org> <mailto:cwhu...@android-x86.org
<mailto:cwhu...@android-x86.org>>>>
 >     wrote:
 >      >      > >
 >      >      > > Mauro Rossi mailto:issor.or...@gmail.com>
 >     <mailto:issor.or...@gmail.com <mailto:issor.or...@gmail.com>>
 >      >     <mailto:issor.or...@gmail.com
<mailto:issor.or...@gmail.com>
 >     <mailto:issor.or...@gmail.com
<mailto:issor.or...@gmail.com>>>> 於 2019年7月14日 週日 下午5:17寫道：
 >      >      > > >
 >      >      > > > This patch partially reverts 20294dc ("mesa:
Enable asm
 >      >     unconditionally, ...")
 >      >      > > >
 >      >      > > > Android makefile build logic needs to disable
assembler
 >      >     optimization
 >      >      > > > in 32bit builds to avoid text relocations for
 >     libglapi.so shared
 >      >      > > >
 >      >      > > > Fixes the following build error with Android
x86 32bit
 >     target:
 >      >      > > >
 >      >      > > > [  0% 4/477] target SharedLib: libglapi
 >      >
 > 
  (out/target/product/x86/obj/SHARED_LIBRARIES/libglapi_intermediates/LINKED/libglapi.so)

 >      >      > > > FAILED:
 >      >
 > 
  out/target/product/x86/obj/SHARED_LIBRARIES/libglapi_intermediates/LINKED/libglapi.so

 >      >      > > > ...
 >      >      > > >
 >      >
 > 
  prebuilts/gcc/linux-x86/x86/x86_64-linux-android-4.9/x86_64-linux-android/bin/ld:

 >      >     warning: shared library text segment is not shareable
 >      >      > > >
 >      >
 > 
  prebuilts/gcc/linux-x86/x86/x86_64-linux-android-4.9/x86_64-linux-android/bin/ld:

 >      >     error: treating warnings as errors
 >      >      > > > clang-6.0: error: linker command failed with
exit code
 >     1 (use
 >      >     -v to see invocation)
 >      >      > > >
 >      >      > > > Fixes: 20294dc ("mesa: Enable asm
unconditionally, now
 >     that
 >      >     gen_matypes is gone.")
 >      >      > > > Signed-off-by: Mauro Rossi
mailto:issor.or...@gmail.com>
 >     <mailto:issor.or...@gmail.com <mailto:issor.or...@gmail.com>>
 >      >     <mailto:issor.or...@gmail.com
<mailto:issor.or...@gmail.com> <mailto:issor.or...@gmail.com
<mailto:issor.or...@gmail.com>>>>
 >      >      > > > ---
 >      >      > > > Android.common.mk <http://Android.common.mk>
<http://Android.common.mk>
 >     <http://Android.common.mk>
 >      >       | 3 +++
 >      >      > > >  Android.mk                          | 7 +++
 >      >      > > >  src/mesa/Android.libmesa_dricore.mk
&

Re: [Mesa-dev] [PATCH] android: mesa: revert "Enable asm unconditionally"

[Tapani Pälli]

On 8/13/19 3:32 PM, Mauro Rossi wrote:

Hi,

On Tue, Aug 13, 2019 at 2:03 PM Tapani Pälli <mailto:tapani.pa...@intel.com>> wrote:


Hi;

On 8/13/19 2:43 PM, Mauro Rossi wrote:
 > Hi Tapani,
 >
 > On Sat, Jul 27, 2019 at 2:56 PM Mauro Rossi
mailto:issor.or...@gmail.com>
 > <mailto:issor.or...@gmail.com <mailto:issor.or...@gmail.com>>> wrote:
 >
 >     On Sat, Jul 27, 2019 at 2:56 PM Mauro Rossi
mailto:issor.or...@gmail.com>
 >     <mailto:issor.or...@gmail.com
<mailto:issor.or...@gmail.com>>> wrote:
 >      >
 >      > On Thu, Jul 18, 2019 at 1:07 PM Chih-Wei Huang
 >     mailto:cwhu...@android-x86.org>
<mailto:cwhu...@android-x86.org <mailto:cwhu...@android-x86.org>>>
wrote:
 >      > >
 >      > > Mauro Rossi mailto:issor.or...@gmail.com>
 >     <mailto:issor.or...@gmail.com
<mailto:issor.or...@gmail.com>>> 於 2019年7月14日 週日 下午5:17寫道：
 >      > > >
 >      > > > This patch partially reverts 20294dc ("mesa: Enable asm
 >     unconditionally, ...")
 >      > > >
 >      > > > Android makefile build logic needs to disable assembler
 >     optimization
 >      > > > in 32bit builds to avoid text relocations for
libglapi.so shared
 >      > > >
 >      > > > Fixes the following build error with Android x86 32bit
target:
 >      > > >
 >      > > > [  0% 4/477] target SharedLib: libglapi
 >   
  (out/target/product/x86/obj/SHARED_LIBRARIES/libglapi_intermediates/LINKED/libglapi.so)

 >      > > > FAILED:
 >   
  out/target/product/x86/obj/SHARED_LIBRARIES/libglapi_intermediates/LINKED/libglapi.so

 >      > > > ...
 >      > > >
 >   
  prebuilts/gcc/linux-x86/x86/x86_64-linux-android-4.9/x86_64-linux-android/bin/ld:

 >     warning: shared library text segment is not shareable
 >      > > >
 >   
  prebuilts/gcc/linux-x86/x86/x86_64-linux-android-4.9/x86_64-linux-android/bin/ld:

 >     error: treating warnings as errors
 >      > > > clang-6.0: error: linker command failed with exit code
1 (use
 >     -v to see invocation)
 >      > > >
 >      > > > Fixes: 20294dc ("mesa: Enable asm unconditionally, now
that
 >     gen_matypes is gone.")
 >      > > > Signed-off-by: Mauro Rossi mailto:issor.or...@gmail.com>
 >     <mailto:issor.or...@gmail.com <mailto:issor.or...@gmail.com>>>
 >      > > > ---
 >      > > > Android.common.mk <http://Android.common.mk>
<http://Android.common.mk>
 >       | 3 +++
 >      > > >  Android.mk                          | 7 +++
 >      > > >  src/mesa/Android.libmesa_dricore.mk
<http://Android.libmesa_dricore.mk>
 >     <http://Android.libmesa_dricore.mk> | 2 ++
 >      > > >  src/mesa/Android.libmesa_st_mesa.mk
<http://Android.libmesa_st_mesa.mk>
 >     <http://Android.libmesa_st_mesa.mk> | 2 ++
 >      > > >  4 files changed, 14 insertions(+)
 >      > > >
 >      > > > diff --git a/Android.common.mk
<http://Android.common.mk> <http://Android.common.mk>
 >     b/Android.common.mk <http://Android.common.mk>
<http://Android.common.mk>
 >      > > > index 8a1c734353..209654bb75 100644
 >      > > > --- a/Android.common.mk <http://Android.common.mk>
<http://Android.common.mk>
 >      > > > +++ b/Android.common.mk <http://Android.common.mk>
<http://Android.common.mk>
 >      > > > @@ -106,9 +106,12 @@ ifeq ($(shell test
 >     $(PLATFORM_SDK_VERSION) -ge 26 && echo true),true)
 >      > > >  LOCAL_CFLAGS += -DHAVE_SYS_SHM_H
 >      > > >  endif
 >      > > >
 >      > > > +ifeq ($(strip $(MESA_ENABLE_ASM)),true)
 >      > > >  ifeq ($(TARGET_ARCH),x86)
 >      > > >  LOCAL_CFLAGS += \
 >      > > >         -DUSE_X86_ASM
 >      > > > +
 >      > > > +endif
 >      > > >  endif
 >      > > >  ifeq ($(ARCH_ARM_HAVE_NEON),true)
 >      > > >  LOCAL_CFLAGS_arm += -DUSE_ARM_ASM
 >      > > > diff --git a/Android.mk b/Android.mk
 >      > > > index 57613eccfc..4a2a003ea3 100644
 >   

Re: [Mesa-dev] [PATCH] gbm: add gbm_{bo, surface}_create_with_modifiers2

[Tapani Pälli]

On 6/24/19 9:51 PM, Simon Ser wrote:

gbm_{bo,surface}_create_with_modifiers is missing the usage flags. Add a new
function which lets library users specify it.

Signed-off-by: Simon Ser 
---
  src/gbm/main/gbm.c | 38 ++
  src/gbm/main/gbm.h | 17 +
  2 files changed, 55 insertions(+)

diff --git a/src/gbm/main/gbm.c b/src/gbm/main/gbm.c
index 38480ca966c6..ca68a3292327 100644
--- a/src/gbm/main/gbm.c
+++ b/src/gbm/main/gbm.c
@@ -491,6 +491,27 @@ gbm_bo_create_with_modifiers(struct gbm_device *gbm,
 return gbm->bo_create(gbm, width, height, format, 0, modifiers, count);
  }

+GBM_EXPORT struct gbm_bo *
+gbm_bo_create_with_modifiers2(struct gbm_device *gbm,
+  uint32_t width, uint32_t height,
+  uint32_t format,
+  const uint64_t *modifiers,
+  const unsigned int count,
+  uint32_t usage)
+{
+   if (width == 0 || height == 0) {
+  errno = EINVAL;
+  return NULL;
+   }
+
+   if ((count && !modifiers) || (modifiers && !count)) {
+  errno = EINVAL;
+  return NULL;
+   }
+
+   return gbm->bo_create(gbm, width, height, format, usage, modifiers, count);
+}
+
  /**
   * Create a gbm buffer object from a foreign object
   *
@@ -616,6 +637,23 @@ gbm_surface_create_with_modifiers(struct gbm_device *gbm,
modifiers, count);
  }

+GBM_EXPORT struct gbm_surface *
+gbm_surface_create_with_modifiers2(struct gbm_device *gbm,
+   uint32_t width, uint32_t height,
+   uint32_t format,
+   const uint64_t *modifiers,
+   const unsigned int count,
+   uint32_t flags)
+{
+   if ((count && !modifiers) || (modifiers && !count)) {
+  errno = EINVAL;
+  return NULL;
+   }
+
+   return gbm->surface_create(gbm, width, height, format, flags,
+  modifiers, count);
+}
+
  /**
   * Destroys the given surface and frees all resources associated with
   * it.
diff --git a/src/gbm/main/gbm.h b/src/gbm/main/gbm.h
index 9b5288710a5b..0bb2e4443f97 100644
--- a/src/gbm/main/gbm.h
+++ b/src/gbm/main/gbm.h
@@ -263,6 +263,15 @@ gbm_bo_create_with_modifiers(struct gbm_device *gbm,
   uint32_t format,
   const uint64_t *modifiers,
   const unsigned int count);
+
+struct gbm_bo *
+gbm_bo_create_with_modifiers2(struct gbm_device *gbm,
+  uint32_t width, uint32_t height,
+  uint32_t format,
+  const uint64_t *modifiers,
+  const unsigned int count,
+  uint32_t flags);


Declaration here says 'flags' while definition says 'usage'.

I noticed that original patch (v1) for gbm_bo_create_with_modifiers did 
have usage at first but it was removed during the review. I'm having 
trouble digging what was the reason for this?




+
  #define GBM_BO_IMPORT_WL_BUFFER 0x5501
  #define GBM_BO_IMPORT_EGL_IMAGE 0x5502
  #define GBM_BO_IMPORT_FD0x5503
@@ -390,6 +399,14 @@ gbm_surface_create_with_modifiers(struct gbm_device *gbm,
const uint64_t *modifiers,
const unsigned int count);

+struct gbm_surface *
+gbm_surface_create_with_modifiers2(struct gbm_device *gbm,
+   uint32_t width, uint32_t height,
+   uint32_t format,
+   const uint64_t *modifiers,
+   const unsigned int count,
+   uint32_t flags);
+
  struct gbm_bo *
  gbm_surface_lock_front_buffer(struct gbm_surface *surface);

--
2.22.0


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


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

Re: [Mesa-dev] [PATCH] android: virgl: fix libmesa_virgil_common build and dependencies

[Tapani Pälli]

On 6/15/19 8:42 AM, Mauro Rossi wrote:

Hi,
there is a typo in the commit title, the library is 
libmesa_winsys_virgl_common

I will correct it in the final commit


Reviewed-by: Tapani Pälli 


Mauro

On Sat, Jun 15, 2019 at 7:39 AM Mauro Rossi <mailto:issor.or...@gmail.com>> wrote:


Fixes the following building errors and resolves Bug 110922
Fixes gallium_dri target missing symbols at linking.

external/mesa/src/gallium/winsys/virgl/drm/Android.mk:
error: libmesa_winsys_virgl (STATIC_LIBRARIES android-x86_64)
missing libmesa_winsys_virgl_common (STATIC_LIBRARIES android-x86_64)
...
external/mesa/src/gallium/winsys/virgl/vtest/Android.mk:
error: libmesa_winsys_virgl_vtest (STATIC_LIBRARIES android-x86_64)
missing libmesa_winsys_virgl_common (STATIC_LIBRARIES android-x86_64)
...
build/core/main.mk:728 <http://main.mk:728>: error: exiting from
previous errors.

In file included from
external/mesa/src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c:34:
external/mesa/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.h:35:10:
fatal error: 'virgl_resource_cache.h' file not found
          ^~~~
1 error generated.

In file included from
external/mesa/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.c:32:
external/mesa/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.h:35:10:
fatal error: 'virgl_resource_cache.h' file not found
#include "virgl_resource_cache.h"
          ^~~~
1 error generated.

Fixes: b18f09a ("virgl: Introduce virgl_resource_cache")
Signed-off-by: Mauro Rossi mailto:issor.or...@gmail.com>>
---
  src/gallium/Android.mk                    | 2 +-
  src/gallium/drivers/virgl/Android.mk      | 2 +-
  src/gallium/winsys/virgl/drm/Android.mk   | 2 ++
  src/gallium/winsys/virgl/vtest/Android.mk | 2 ++
  4 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/gallium/Android.mk b/src/gallium/Android.mk
index 3a3f042c7a..37e923c225 100644
--- a/src/gallium/Android.mk
+++ b/src/gallium/Android.mk
@@ -43,7 +43,7 @@ SUBDIRS += winsys/radeon/drm drivers/r300
  SUBDIRS += winsys/radeon/drm drivers/r600
  SUBDIRS += winsys/radeon/drm winsys/amdgpu/drm drivers/radeonsi
  SUBDIRS += winsys/vc4/drm drivers/vc4
-SUBDIRS += winsys/virgl/drm winsys/virgl/vtest drivers/virgl
+SUBDIRS += winsys/virgl/common winsys/virgl/drm winsys/virgl/vtest
drivers/virgl
  SUBDIRS += winsys/svga/drm drivers/svga
  SUBDIRS += winsys/etnaviv/drm drivers/etnaviv drivers/renderonly
  SUBDIRS += state_trackers/dri
diff --git a/src/gallium/drivers/virgl/Android.mk
b/src/gallium/drivers/virgl/Android.mk
index 0067dfa702..a6fe53fbe9 100644
--- a/src/gallium/drivers/virgl/Android.mk
+++ b/src/gallium/drivers/virgl/Android.mk
@@ -35,5 +35,5 @@ include $(BUILD_STATIC_LIBRARY)

  ifneq ($(HAVE_GALLIUM_VIRGL),)
  GALLIUM_TARGET_DRIVERS += virtio_gpu
-$(eval GALLIUM_LIBS += $(LOCAL_MODULE) libmesa_winsys_virgl
libmesa_winsys_virgl_vtest)
+$(eval GALLIUM_LIBS += $(LOCAL_MODULE) libmesa_winsys_virgl_common
libmesa_winsys_virgl libmesa_winsys_virgl_vtest)
  endif
diff --git a/src/gallium/winsys/virgl/drm/Android.mk
b/src/gallium/winsys/virgl/drm/Android.mk
index 5e2500774e..398a7645bc 100644
--- a/src/gallium/winsys/virgl/drm/Android.mk
+++ b/src/gallium/winsys/virgl/drm/Android.mk
@@ -27,6 +27,8 @@ include $(CLEAR_VARS)

  LOCAL_SRC_FILES := $(C_SOURCES)

+LOCAL_C_INCLUDES := $(GALLIUM_TOP)/winsys/virgl/common
+
  LOCAL_MODULE := libmesa_winsys_virgl

  LOCAL_STATIC_LIBRARIES := libmesa_winsys_virgl_common
diff --git a/src/gallium/winsys/virgl/vtest/Android.mk
b/src/gallium/winsys/virgl/vtest/Android.mk
index 5b33f67711..6d35223c8e 100644
--- a/src/gallium/winsys/virgl/vtest/Android.mk
+++ b/src/gallium/winsys/virgl/vtest/Android.mk
@@ -27,6 +27,8 @@ include $(CLEAR_VARS)

  LOCAL_SRC_FILES := $(C_SOURCES)

+LOCAL_C_INCLUDES := $(GALLIUM_TOP)/winsys/virgl/common
+
  LOCAL_MODULE := libmesa_winsys_virgl_vtest

  LOCAL_STATIC_LIBRARIES := libmesa_winsys_virgl_common
-- 
2.20.1



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

Re: [Mesa-dev] [PATCH] android: radv: fix necessary dependecies

[Tapani Pälli]

This looks good;
Reviewed-by: Tapani Pälli 

Note that there is ongoing work to get rid of the whole libexpat 
dependency for Android. But until that happens, let's do this.



On 4/24/19 4:44 PM, Mauro Rossi wrote:

Fixes building errors due to missing libmesa_util generated files include
and libexpat dependencies:

In file included from external/mesa/src/amd/vulkan/radv_device.c:52:
external/mesa/src/util/xmlpool.h:115:10: fatal error: 'xmlpool/options.h' file 
not found
  ^~~
1 error generated.

FAILED: 
out/target/product/x86_64/obj_x86/SHARED_LIBRARIES/vulkan.radv_intermediates/LINKED/vulkan.radv.so
...
external/mesa/src/util/xmlconfig.c:670: error: undefined reference to 
'XML_ParserCreate'
...
clang.real: error: linker command failed with exit code 1 (use -v to see 
invocation)

Fixes: 3c2e826 ("radv: Add support for driconf.")
Signed-off-by: Mauro Rossi 
---
  src/amd/vulkan/Android.mk | 12 +++-
  1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/src/amd/vulkan/Android.mk b/src/amd/vulkan/Android.mk
index 9574bf54e5..ab39ba3b72 100644
--- a/src/amd/vulkan/Android.mk
+++ b/src/amd/vulkan/Android.mk
@@ -71,7 +71,8 @@ LOCAL_C_INCLUDES := \
$(call generated-sources-dir-for,STATIC_LIBRARIES,libmesa_amd_common,,) 
\
$(call generated-sources-dir-for,STATIC_LIBRARIES,libmesa_nir,,)/nir \
$(call 
generated-sources-dir-for,STATIC_LIBRARIES,libmesa_radv_common,,) \
-   $(call 
generated-sources-dir-for,STATIC_LIBRARIES,libmesa_vulkan_util,,)/util
+   $(call 
generated-sources-dir-for,STATIC_LIBRARIES,libmesa_vulkan_util,,)/util \
+   $(call generated-sources-dir-for,STATIC_LIBRARIES,libmesa_util,,)
  
  LOCAL_WHOLE_STATIC_LIBRARIES := \

libmesa_vulkan_util \
@@ -165,5 +166,14 @@ LOCAL_WHOLE_STATIC_LIBRARIES := \
  
  LOCAL_SHARED_LIBRARIES += $(RADV_SHARED_LIBRARIES) libz libsync liblog
  
+# If Android version >=8 MESA should static link libexpat else should dynamic link

+ifeq ($(shell test $(PLATFORM_SDK_VERSION) -ge 27; echo $$?), 0)
+LOCAL_STATIC_LIBRARIES := \
+   libexpat
+else
+LOCAL_SHARED_LIBRARIES += \
+   libexpat
+endif
+
  include $(MESA_COMMON_MK)
  include $(BUILD_SHARED_LIBRARY)


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

Re: [Mesa-dev] Zero-Copy Texture usage from OpenCL

[Tapani Pälli]

Hi;

On 5/30/19 12:03 PM, Rudrappa, Shiva Kumara wrote:

Hi,

Can someone please help to validate below MESA features.

“system shall allow 3D rendering to make use of OpenCL buffers in a 
zero-copy manner”


“system shall allow 3D rendering to make use of Media SDK buffers in a 
zero-copy manner.”




I'm not entirely sure what the actual feature description here is but 
these features go through the stack and need implementation in OpenCL 
and Media SDK stacks + graphics allocator (minigbm, gralloc) as well. So 
this is not just a 'MESA feature'. Perhaps some clarification of the 
features would make the whole thing easier to validate.


I'm guessing that by 'system shall allow 3D rendering to make use of 
Media SDK buffers' it is meant that Mesa driver can create a texture out 
of buffer that contains video frame that Media SDK has produced. Mesa 
side of this use-case can be validated as example using Piglit test 
'ext_image_dma_buf_import-sample_yuv' but it assumes that Media SDK is 
capable is producing similar buffers as what the test is using.


Thanks;

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

Re: [Mesa-dev] Zero-Copy Texture usage from OpenCL

[Tapani Pälli]

On 6/3/19 1:17 PM, Tapani Pälli wrote:

Hi;

On 5/30/19 12:03 PM, Rudrappa, Shiva Kumara wrote:

Hi,

Can someone please help to validate below MESA features.

“system shall allow 3D rendering to make use of OpenCL buffers in a 
zero-copy manner”


“system shall allow 3D rendering to make use of Media SDK buffers in a 
zero-copy manner.”




I'm not entirely sure what the actual feature description here is but 
these features go through the stack and need implementation in OpenCL 
and Media SDK stacks + graphics allocator (minigbm, gralloc) as well. So 
this is not just a 'MESA feature'. Perhaps some clarification of the 
features would make the whole thing easier to validate.


I'm guessing that by 'system shall allow 3D rendering to make use of 
Media SDK buffers' it is meant that Mesa driver can create a texture out 
of buffer that contains video frame that Media SDK has produced. Mesa 
side of this use-case can be validated as example using Piglit test 
'ext_image_dma_buf_import-sample_yuv' but it assumes that Media SDK is 
capable is producing similar buffers as what the test is using.


Oops, wanted to add that if you are validating things on Android, CTS 
contains tests that utilize Media + GL stack and validate the media 
use-case.



Thanks;

// Tapani
___
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] st/glsl: make sure to propagate initialisers to driver storage

[Tapani Pälli]

Verified to fix the test as initializers get propagated;

Reviewed-by: Tapani Pälli 

On 5/29/19 6:13 AM, Timothy Arceri wrote:

This essentially reverts 20234cfe3a20.

Fixes piglit test:
tests/spec/arb_get_program_binary/execution/uniform-after-restore.shader_test

Fixes: 20234cfe3a20 "st/mesa: don't propagate uniforms when restoring from 
cache"

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110784
---
  src/mesa/program/ir_to_mesa.cpp| 41 ++
  src/mesa/program/ir_to_mesa.h  |  3 +-
  src/mesa/state_tracker/st_glsl_to_nir.cpp  |  2 +-
  src/mesa/state_tracker/st_glsl_to_tgsi.cpp |  2 +-
  src/mesa/state_tracker/st_shader_cache.c   |  2 +-
  5 files changed, 23 insertions(+), 27 deletions(-)

diff --git a/src/mesa/program/ir_to_mesa.cpp b/src/mesa/program/ir_to_mesa.cpp
index f875c00238f..005b855230b 100644
--- a/src/mesa/program/ir_to_mesa.cpp
+++ b/src/mesa/program/ir_to_mesa.cpp
@@ -2506,8 +2506,7 @@ _mesa_generate_parameters_list_for_uniforms(struct 
gl_context *ctx,
  void
  _mesa_associate_uniform_storage(struct gl_context *ctx,
  struct gl_shader_program *shader_program,
-struct gl_program *prog,
-bool propagate_to_storage)
+struct gl_program *prog)
  {
 struct gl_program_parameter_list *params = prog->Parameters;
 gl_shader_stage shader_type = prog->info.stage;
@@ -2633,26 +2632,24 @@ _mesa_associate_uniform_storage(struct gl_context *ctx,
* data from the linker's backing store.  This will cause values from
* initializers in the source code to be copied over.
*/
- if (propagate_to_storage) {
-unsigned array_elements = MAX2(1, storage->array_elements);
-if (ctx->Const.PackedDriverUniformStorage && !prog->is_arb_asm &&
-(storage->is_bindless || !storage->type->contains_opaque())) {
-   const int dmul = storage->type->is_64bit() ? 2 : 1;
-   const unsigned components =
-  storage->type->vector_elements *
-  storage->type->matrix_columns;
-
-   for (unsigned s = 0; s < storage->num_driver_storage; s++) {
-  gl_constant_value *uni_storage = (gl_constant_value *)
- storage->driver_storage[s].data;
-  memcpy(uni_storage, storage->storage,
- sizeof(storage->storage[0]) * components *
- array_elements * dmul);
-   }
-} else {
-   _mesa_propagate_uniforms_to_driver_storage(storage, 0,
-  array_elements);
+ unsigned array_elements = MAX2(1, storage->array_elements);
+ if (ctx->Const.PackedDriverUniformStorage && !prog->is_arb_asm &&
+ (storage->is_bindless || !storage->type->contains_opaque())) {
+const int dmul = storage->type->is_64bit() ? 2 : 1;
+const unsigned components =
+   storage->type->vector_elements *
+   storage->type->matrix_columns;
+
+for (unsigned s = 0; s < storage->num_driver_storage; s++) {
+   gl_constant_value *uni_storage = (gl_constant_value *)
+  storage->driver_storage[s].data;
+   memcpy(uni_storage, storage->storage,
+  sizeof(storage->storage[0]) * components *
+  array_elements * dmul);
  }
+ } else {
+_mesa_propagate_uniforms_to_driver_storage(storage, 0,
+   array_elements);
   }
  
  	  last_location = location;

@@ -3011,7 +3008,7 @@ get_mesa_program(struct gl_context *ctx,
  * prog->ParameterValues to get reallocated (e.g., anything that adds a
  * program constant) has to happen before creating this linkage.
  */
-   _mesa_associate_uniform_storage(ctx, shader_program, prog, true);
+   _mesa_associate_uniform_storage(ctx, shader_program, prog);
 if (!shader_program->data->LinkStatus) {
goto fail_exit;
 }
diff --git a/src/mesa/program/ir_to_mesa.h b/src/mesa/program/ir_to_mesa.h
index f5665e6316e..33eb801bae8 100644
--- a/src/mesa/program/ir_to_mesa.h
+++ b/src/mesa/program/ir_to_mesa.h
@@ -50,8 +50,7 @@ _mesa_generate_parameters_list_for_uniforms(struct gl_context 
*ctx,
  void
  _mesa_associate_uniform_storage(struct gl_context *ctx,
  struct gl_shader_program *shader_program,
-struct gl_program *prog,
-bool propagate_to_storage);
+struct gl_program *prog);
  
  #ifdef __cplusplu

Re: [Mesa-dev] [RFC 0/2] Alternate default config mechanism

[Tapani Pälli]

On 5/23/19 8:22 PM, Sumit Semwal wrote:

Hi Eric,

On Thu, 23 May 2019 at 20:25, Eric Engestrom  wrote:


On Thursday, 2019-05-23 08:34:40 +0300, Tapani Pälli wrote:

Hi;

On 5/22/19 9:20 PM, Alistair Strachan wrote:

On Tue, May 21, 2019 at 10:10 PM Tapani Pälli  wrote:



On 5/21/19 4:53 PM, Sumit Semwal wrote:

Hello everyone,

First up, my apologies on not being able to respond earlier; secondly,
thanks very much for your review.

On Wed, 15 May 2019 at 19:27, Emil Velikov  wrote:


Hi all,

On Tue, 14 May 2019 at 08:18, Tapani Pälli  wrote:



On 5/13/19 6:52 PM, Haehnle, Nicolai wrote:

This approach seems entirely incompatible with si_debug_options.h, and
will be an absolute maintenance nightmare going forward for adding /
removing options, because you're introducing a second location where
options are defined.

Quite frankly, this seems like a terrible idea as-is.

If you really can't use XML for whatever reason, then please find some
way of deriving both the tables here and the XML from the same single
source of truth.


I was looking at this yesterday and came up with same conclusion. We
should have the options in one place. Currently libexpat is statically
linked with Android >=O, maybe for such restricted environments we could
just inline the xml as is at compile time and parse that later or
alternatively (maybe cleaner) parse and generate default option cache
already during compilation?


I realise that jumping the "me too" train does not help much, so here
are some alternative ideas.

How about we first distil the reasons why this is a problem and what
kind. Then explore independent solution for each one - as-is this
seems like a one-size-fits-all approach.

I totally agree that this seems like a rudimentary / ugly approach,
and we can definitely improve upon it once the reasons are discussed.


Some examples:
- XML file may be inaccessible - the in-driver defaults should work(tm)
Yes there are some app specific ones, yet neither(?) of these apps is
present on Android
- libexpat is not available, but libFOO is - investigate into a compat 
wrapper
- cannot use external libraries (libexpat or equivalent) - static link



AFAIU, in the Android space, it is a combination of some of the above:
a. current Android doesn't allow GL drivers to access config files
from the vendor partition: this is enforced via selinux policy.


For point a, vendors can (and should) define their own policy rules
regarding what file access and ioctl's are required. This is done by
setting BOARD_SEPOLICY_DIRS in BoardConfig.mk file. That directory then
contains all the necessary rules required for the particular driver to
work. As example:

BOARD_SEPOLICY_DIRS += device/samsung/tuna/sepolicy

If a vendor wanted to use xml based configuration for Mesa it should be
possible by setting a sepolicy rule so that particular library is able
to access such file. Looking at Android Celadon selinux files,
'file_contexts' is probably the place to do it.


The EGL/GLES driver stack is a special kind of HAL in Android
(same-process HAL) so we have to be very careful about expanding the
sepolicy rules to work around unnecessary file accesses. We also have
strict sepolicy "neverallows" for untrusted apps (the processes this
same-process HAL might be loaded into). I strongly disagree with your
suggestion here.

  From an Android PoV, the EGL/GLES drivers should minimize their
dependencies so as to not affect other NDK libraries loaded into the
app processes. They should also limit interactions with the rest of
the system, such as opening configuration files. It's clear that Mesa
can work just fine without reading a configuration file, and that the
use case of opening a configuration file should only be necessary for
development and bring-up.

The discussion so far on this thread seems to be optimizing for Mesa's
configuration file, rather than for security and file size. On an
embedded platform such as Android, in cases where Mesa might ship in a
production configuration, there should be no configuration file, and
we would want vendors to optimize for security and file size.

My opinion is that we need Sumit's changes, or something like them.
Pulling in libexpat just to build internal configuration state from a
built-in XML file seems quite over-engineered.

That said, I agree with other feedback on this thread that it should
be possible to derive the baked configuration from the same source of
truth (possibly an XML file) as another platform which might not have
a baked configuration.


b. Also, they had some concerns around how safe libexpat is vis-a-vis
dual-loading, and that's where the concern around static linking came
from.

Alistair, could you please correct me if I am wrong, and if there are
additional details on the need of this?



The concern is basically that libexpat might be "dual loaded" - by the
linker namespace for the sphal, and that of the app itself - and that
there m

Re: [Mesa-dev] [RFC 0/2] Alternate default config mechanism

[Tapani Pälli]

Hi;

On 5/22/19 9:20 PM, Alistair Strachan wrote:

On Tue, May 21, 2019 at 10:10 PM Tapani Pälli  wrote:



On 5/21/19 4:53 PM, Sumit Semwal wrote:

Hello everyone,

First up, my apologies on not being able to respond earlier; secondly,
thanks very much for your review.

On Wed, 15 May 2019 at 19:27, Emil Velikov  wrote:


Hi all,

On Tue, 14 May 2019 at 08:18, Tapani Pälli  wrote:



On 5/13/19 6:52 PM, Haehnle, Nicolai wrote:

This approach seems entirely incompatible with si_debug_options.h, and
will be an absolute maintenance nightmare going forward for adding /
removing options, because you're introducing a second location where
options are defined.

Quite frankly, this seems like a terrible idea as-is.

If you really can't use XML for whatever reason, then please find some
way of deriving both the tables here and the XML from the same single
source of truth.


I was looking at this yesterday and came up with same conclusion. We
should have the options in one place. Currently libexpat is statically
linked with Android >=O, maybe for such restricted environments we could
just inline the xml as is at compile time and parse that later or
alternatively (maybe cleaner) parse and generate default option cache
already during compilation?


I realise that jumping the "me too" train does not help much, so here
are some alternative ideas.

How about we first distil the reasons why this is a problem and what
kind. Then explore independent solution for each one - as-is this
seems like a one-size-fits-all approach.

I totally agree that this seems like a rudimentary / ugly approach,
and we can definitely improve upon it once the reasons are discussed.


Some examples:
   - XML file may be inaccessible - the in-driver defaults should work(tm)
Yes there are some app specific ones, yet neither(?) of these apps is
present on Android
   - libexpat is not available, but libFOO is - investigate into a compat 
wrapper
   - cannot use external libraries (libexpat or equivalent) - static link



AFAIU, in the Android space, it is a combination of some of the above:
a. current Android doesn't allow GL drivers to access config files
from the vendor partition: this is enforced via selinux policy.


For point a, vendors can (and should) define their own policy rules
regarding what file access and ioctl's are required. This is done by
setting BOARD_SEPOLICY_DIRS in BoardConfig.mk file. That directory then
contains all the necessary rules required for the particular driver to
work. As example:

BOARD_SEPOLICY_DIRS += device/samsung/tuna/sepolicy

If a vendor wanted to use xml based configuration for Mesa it should be
possible by setting a sepolicy rule so that particular library is able
to access such file. Looking at Android Celadon selinux files,
'file_contexts' is probably the place to do it.


The EGL/GLES driver stack is a special kind of HAL in Android
(same-process HAL) so we have to be very careful about expanding the
sepolicy rules to work around unnecessary file accesses. We also have
strict sepolicy "neverallows" for untrusted apps (the processes this
same-process HAL might be loaded into). I strongly disagree with your
suggestion here.

 From an Android PoV, the EGL/GLES drivers should minimize their
dependencies so as to not affect other NDK libraries loaded into the
app processes. They should also limit interactions with the rest of
the system, such as opening configuration files. It's clear that Mesa
can work just fine without reading a configuration file, and that the
use case of opening a configuration file should only be necessary for
development and bring-up.

The discussion so far on this thread seems to be optimizing for Mesa's
configuration file, rather than for security and file size. On an
embedded platform such as Android, in cases where Mesa might ship in a
production configuration, there should be no configuration file, and
we would want vendors to optimize for security and file size.

My opinion is that we need Sumit's changes, or something like them.
Pulling in libexpat just to build internal configuration state from a
built-in XML file seems quite over-engineered.

That said, I agree with other feedback on this thread that it should
be possible to derive the baked configuration from the same source of
truth (possibly an XML file) as another platform which might not have
a baked configuration.


b. Also, they had some concerns around how safe libexpat is vis-a-vis
dual-loading, and that's where the concern around static linking came
from.

Alistair, could you please correct me if I am wrong, and if there are
additional details on the need of this?



The concern is basically that libexpat might be "dual loaded" - by the
linker namespace for the sphal, and that of the app itself - and that
there might be global data (like pthread keys, etc.) that could
conflict. The versions of the library needn't be the same, either; the
app and the EGL/GLES stack might be using 

Re: [Mesa-dev] [RFC 0/2] Alternate default config mechanism

[Tapani Pälli]

On 5/21/19 4:53 PM, Sumit Semwal wrote:

Hello everyone,

First up, my apologies on not being able to respond earlier; secondly,
thanks very much for your review.

On Wed, 15 May 2019 at 19:27, Emil Velikov  wrote:


Hi all,

On Tue, 14 May 2019 at 08:18, Tapani Pälli  wrote:



On 5/13/19 6:52 PM, Haehnle, Nicolai wrote:

This approach seems entirely incompatible with si_debug_options.h, and
will be an absolute maintenance nightmare going forward for adding /
removing options, because you're introducing a second location where
options are defined.

Quite frankly, this seems like a terrible idea as-is.

If you really can't use XML for whatever reason, then please find some
way of deriving both the tables here and the XML from the same single
source of truth.


I was looking at this yesterday and came up with same conclusion. We
should have the options in one place. Currently libexpat is statically
linked with Android >=O, maybe for such restricted environments we could
just inline the xml as is at compile time and parse that later or
alternatively (maybe cleaner) parse and generate default option cache
already during compilation?


I realise that jumping the "me too" train does not help much, so here
are some alternative ideas.

How about we first distil the reasons why this is a problem and what
kind. Then explore independent solution for each one - as-is this
seems like a one-size-fits-all approach.

I totally agree that this seems like a rudimentary / ugly approach,
and we can definitely improve upon it once the reasons are discussed.


Some examples:
  - XML file may be inaccessible - the in-driver defaults should work(tm)
Yes there are some app specific ones, yet neither(?) of these apps is
present on Android
  - libexpat is not available, but libFOO is - investigate into a compat wrapper
  - cannot use external libraries (libexpat or equivalent) - static link



AFAIU, in the Android space, it is a combination of some of the above:
a. current Android doesn't allow GL drivers to access config files
from the vendor partition: this is enforced via selinux policy.


For point a, vendors can (and should) define their own policy rules 
regarding what file access and ioctl's are required. This is done by 
setting BOARD_SEPOLICY_DIRS in BoardConfig.mk file. That directory then 
contains all the necessary rules required for the particular driver to 
work. As example:


BOARD_SEPOLICY_DIRS += device/samsung/tuna/sepolicy

If a vendor wanted to use xml based configuration for Mesa it should be 
possible by setting a sepolicy rule so that particular library is able 
to access such file. Looking at Android Celadon selinux files, 
'file_contexts' is probably the place to do it.



b. Also, they had some concerns around how safe libexpat is vis-a-vis
dual-loading, and that's where the concern around static linking came
from.

Alistair, could you please correct me if I am wrong, and if there are
additional details on the need of this?



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

Re: [Mesa-dev] [PATCH] util: add missing include to build_id.h

[Tapani Pälli]

Reviewed-by: Tapani Pälli 

On 5/17/19 8:23 AM, Timothy Arceri wrote:

Required to use uint8_t
---
  src/util/build_id.h | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/src/util/build_id.h b/src/util/build_id.h
index 86d611d8db7..1872ca5c7e5 100644
--- a/src/util/build_id.h
+++ b/src/util/build_id.h
@@ -26,6 +26,8 @@
  
  #ifdef HAVE_DL_ITERATE_PHDR
  
+#include 

+
  struct build_id_note;
  
  const struct build_id_note *



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

Re: [Mesa-dev] [RFC 0/2] Alternate default config mechanism

[Tapani Pälli]

On 5/13/19 6:52 PM, Haehnle, Nicolai wrote:

This approach seems entirely incompatible with si_debug_options.h, and
will be an absolute maintenance nightmare going forward for adding /
removing options, because you're introducing a second location where
options are defined.

Quite frankly, this seems like a terrible idea as-is.

If you really can't use XML for whatever reason, then please find some
way of deriving both the tables here and the XML from the same single
source of truth.


I was looking at this yesterday and came up with same conclusion. We 
should have the options in one place. Currently libexpat is statically 
linked with Android >=O, maybe for such restricted environments we could 
just inline the xml as is at compile time and parse that later or 
alternatively (maybe cleaner) parse and generate default option cache 
already during compilation?




Cheers,
Nicolai

On 10.05.19 08:02, Sumit Semwal wrote:

Mesa uses libexpat for many configuration parsing needs; however some
userspaces like Android may not want to use libexpat for various reasons -
eg some might restrict reading of any config xml files from filesystems.

This patchset proposes a simple lookup mechanism for the default values
as per current core mesa, keeping the same mesa-internal API as existing
xmlconfig.c.

Note:
This RFC doesn't change mesa drivers that directly use libexpat API - vc4
and intel gen decoder. If these drivers need Android to be enabled for
them, I request help from the experts there.

For building and testing this on current AOSP/master, I have two hack patches
- one provides empty dummy declarations for the XML* API in use in
gen_decoder, while the other disables vc4 decoder functionality. These can be
found at [1].

These have been built and boot-tested to UI on dragonboard.

[1]: 
https://git.linaro.org/people/sumit.semwal/aosp/external/mesa3d.git/log/?h=expat_wip

Sumit Semwal (2):
mesa: utils: provide alternate default config mechanism
mesa: Android: enable altxmlconfig for O+

   src/gallium/targets/dri/Android.mk |   8 +-
   src/mesa/drivers/dri/Android.mk|  12 +-
   src/util/Android.mk|  12 +-
   src/util/Makefile.sources  |   2 +-
   src/util/altxmlconfig.c| 261 +
   5 files changed, 275 insertions(+), 20 deletions(-)
   create mode 100644 src/util/altxmlconfig.c



___
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] android: amd/common: fix missing include path

[Tapani Pälli]

Reviewed-by: Tapani Pälli 

On 5/5/19 7:54 PM, Mauro Rossi wrote:

Fixes the following building error in Android:

In file included from external/mesa/src/amd/common/ac_llvm_helper.cpp:34:
In file included from external/mesa/src/amd/common/ac_llvm_build.h:30:
In file included from external/mesa/src/compiler/nir/nir.h:40:
In file included from external/mesa/src/compiler/nir_types.h:36:
external/mesa/src/compiler/glsl_types.h:37:10: fatal error: 'main/config.h' 
file not found
  ^~~
1 error generated.

Fixes: bd4c661 ("ac,ac/nir: use a better sync scope for shared atomics")
Signed-off-by: Mauro Rossi 
---
  src/amd/Android.common.mk | 1 +
  1 file changed, 1 insertion(+)

diff --git a/src/amd/Android.common.mk b/src/amd/Android.common.mk
index 4ef7f176e9..29a294adcd 100644
--- a/src/amd/Android.common.mk
+++ b/src/amd/Android.common.mk
@@ -55,6 +55,7 @@ LOCAL_C_INCLUDES := \
$(call generated-sources-dir-for,STATIC_LIBRARIES,libmesa_nir,,)/nir \
$(MESA_TOP)/src/gallium/include \
$(MESA_TOP)/src/gallium/auxiliary \
+   $(MESA_TOP)/src/mesa \
$(intermediates)/common
  
  LOCAL_EXPORT_C_INCLUDE_DIRS := \



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

Re: [Mesa-dev] [PATCH v3 6/6] glsl/linker: check for xfb_offset aliasing

[Tapani Pälli]

->orig_name, xfb_offset * 4);
+return false;
+ }
+ used[word] |= BITSET_RANGE(start_range, end_range);
+  }
+
while (num_components > 0) {
   unsigned output_size = MIN2(num_components, 4 - location_frac);
   assert((info->NumOutputs == 0 && max_outputs == 0) ||
@@ -1247,28 +1315,6 @@ tfeedback_decl::store(struct gl_context *ctx, struct 
gl_shader_program *prog,
info->Buffers[buffer].Stride = xfb_offset;
 }
  
-   /* From GL_EXT_transform_feedback:

-*   A program will fail to link if:
-*
-* * the total number of components to capture is greater than
-*   the constant MAX_TRANSFORM_FEEDBACK_INTERLEAVED_COMPONENTS_EXT
-*   and the buffer mode is INTERLEAVED_ATTRIBS_EXT.
-*
-* From GL_ARB_enhanced_layouts:
-*
-*   "The resulting stride (implicit or explicit) must be less than or
-*   equal to the implementation-dependent constant
-*   gl_MaxTransformFeedbackInterleavedComponents."
-*/
-   if ((prog->TransformFeedback.BufferMode == GL_INTERLEAVED_ATTRIBS ||
-has_xfb_qualifiers) &&
-   info->Buffers[buffer].Stride >
-   ctx->Const.MaxTransformFeedbackInterleavedComponents) {
-  linker_error(prog, "The MAX_TRANSFORM_FEEDBACK_INTERLEAVED_COMPONENTS "
-   "limit has been exceeded.");
-  return false;
-   }
-
   store_varying:
 info->Varyings[info->NumVarying].Name = ralloc_strdup(prog,
   this->orig_name);
@@ -1389,7 +1435,8 @@ cmp_xfb_offset(const void * x_generic, const void * 
y_generic)
  static bool
  store_tfeedback_info(struct gl_context *ctx, struct gl_shader_program *prog,
   unsigned num_tfeedback_decls,
- tfeedback_decl *tfeedback_decls, bool has_xfb_qualifiers)
+ tfeedback_decl *tfeedback_decls, bool has_xfb_qualifiers,
+ const void *mem_ctx)
  {
 if (!prog->last_vert_prog)
return true;
@@ -1431,6 +1478,7 @@ store_tfeedback_info(struct gl_context *ctx, struct 
gl_shader_program *prog,
  
 unsigned num_buffers = 0;

 unsigned buffers = 0;
+   BITSET_WORD *used_components[MAX_FEEDBACK_BUFFERS];


You need to initialize it here, otherwise things end up bad:

BITSET_WORD *used_components[MAX_FEEDBACK_BUFFERS] = {};

With this change;
Reviewed-by: Tapani Pälli 



 if (!has_xfb_qualifiers && separate_attribs_mode) {
/* GL_SEPARATE_ATTRIBS */
@@ -1438,7 +1486,8 @@ store_tfeedback_info(struct gl_context *ctx, struct 
gl_shader_program *prog,
   if (!tfeedback_decls[i].store(ctx, prog,
 xfb_prog->sh.LinkedTransformFeedback,
 num_buffers, num_buffers, num_outputs,
-   NULL, has_xfb_qualifiers))
+   used_components, NULL,
+   has_xfb_qualifiers, mem_ctx))
  return false;
  
   buffers |= 1 << num_buffers;

@@ -1475,7 +1524,8 @@ store_tfeedback_info(struct gl_context *ctx, struct 
gl_shader_program *prog,
  if (!tfeedback_decls[i].store(ctx, prog,

xfb_prog->sh.LinkedTransformFeedback,
buffer, num_buffers, num_outputs,
-  explicit_stride, has_xfb_qualifiers))
+  used_components, explicit_stride,
+  has_xfb_qualifiers, mem_ctx))
 return false;
  num_buffers++;
  buffer_stream_id = -1;
@@ -1516,7 +1566,8 @@ store_tfeedback_info(struct gl_context *ctx, struct 
gl_shader_program *prog,
   if (!tfeedback_decls[i].store(ctx, prog,
 xfb_prog->sh.LinkedTransformFeedback,
 buffer, num_buffers, num_outputs,
-   explicit_stride, has_xfb_qualifiers))
+   used_components, explicit_stride,
+   has_xfb_qualifiers, mem_ctx))
  return false;
}
 }
@@ -3002,7 +3053,7 @@ link_varyings(struct gl_shader_program *prog, unsigned 
first, unsigned last,
 }
  
 if (!store_tfeedback_info(ctx, prog, num_tfeedback_decls, tfeedback_decls,

- has_xfb_qualifiers))
+ has_xfb_qualifiers, mem_ctx))
return false;
  
 return true;

diff --git a/src/compiler/glsl/link_varyings.h 
b/src/compiler/glsl/link_varyings.h
index d0f7ca355b8..b802250819e 100644
--- a/src/compiler/glsl/link_varyings.h
+++ b/src/compiler/glsl/link_varyings.h
@@ -34,7 +34,7 @@
  
  #include 

Re: [Mesa-dev] [PATCH] Revert "compiler/glsl: handle case where we have multiple users for types"

[Tapani Pälli]

On 4/18/19 8:50 AM, Timothy Arceri wrote:

On 18/4/19 3:08 pm, Tapani Pälli wrote:



On 4/18/19 8:05 AM, Timothy Arceri wrote:

This reverts commit 624789e3708c87ea2a4c8d2266266b489b421cba.

It caused 400+ piglit tests to crash on radeonsi, I haven't been able
to track down the reason yet.


Could you share the backtrace?


It's more complicated than that. There is some kind of race condition, 
we end up crashing in nir validation as it seems the types are released 
before validation finishes.


I do wonder how that can happen :/ I'm ok with revert;

Acked-by: Tapani Pälli 



e.g. for ./bin/getuniform-03 -auto -fbo

...
 vec1 32 ssa_404 = deref_array &(*ssa_403)[0] (uniform vec4) /* 
_TextureEnvColor[0] */
error: glsl_type_is_array(parent->type) || 
glsl_type_is_matrix(parent->type) (../src/compiler/nir/nir_validate.c:453)


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

Re: [Mesa-dev] [PATCH] Revert "compiler/glsl: handle case where we have multiple users for types"

[Tapani Pälli]

On 4/18/19 8:05 AM, Timothy Arceri wrote:

This reverts commit 624789e3708c87ea2a4c8d2266266b489b421cba.

It caused 400+ piglit tests to crash on radeonsi, I haven't been able
to track down the reason yet.


Could you share the backtrace?


---
  src/amd/vulkan/radv_device.c |  3 ---
  src/compiler/glsl/glsl_parser_extras.cpp | 20 ++-
  src/compiler/glsl/glsl_parser_extras.h   |  2 --
  src/compiler/glsl/standalone.cpp |  3 +--
  src/compiler/glsl_types.cpp  | 32 
  src/compiler/glsl_types.h| 10 +++-
  src/intel/vulkan/anv_device.c|  3 ---
  src/mesa/main/context.c  |  4 ---
  8 files changed, 11 insertions(+), 66 deletions(-)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 96c6543141e..13021a9f2da 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -48,7 +48,6 @@
  #include "util/build_id.h"
  #include "util/debug.h"
  #include "util/mesa-sha1.h"
-#include "compiler/glsl_types.h"
  
  static int

  radv_device_get_cache_uuid(enum radeon_family family, void *uuid)
@@ -583,7 +582,6 @@ VkResult radv_CreateInstance(
}
  
  	_mesa_locale_init();

-   glsl_type_singleton_init_or_ref();
  
  	VG(VALGRIND_CREATE_MEMPOOL(instance, 0, false));
  
@@ -609,7 +607,6 @@ void radv_DestroyInstance(
  
  	VG(VALGRIND_DESTROY_MEMPOOL(instance));
  
-	glsl_type_singleton_decref();

_mesa_locale_fini();
  
  	vk_debug_report_instance_destroy(>debug_report_callbacks);

diff --git a/src/compiler/glsl/glsl_parser_extras.cpp 
b/src/compiler/glsl/glsl_parser_extras.cpp
index b30c638cdc9..0ffad2d25a0 100644
--- a/src/compiler/glsl/glsl_parser_extras.cpp
+++ b/src/compiler/glsl/glsl_parser_extras.cpp
@@ -2324,24 +2324,6 @@ do_common_optimization(exec_list *ir, bool linked,
  
  extern "C" {
  
-/**

- * To be called at GL context ctor.
- */
-void
-_mesa_init_shader_compiler_types(void)
-{
-   glsl_type_singleton_init_or_ref();
-}
-
-/**
- * To be called at GL context dtor.
- */
-void
-_mesa_destroy_shader_compiler_types(void)
-{
-   glsl_type_singleton_decref();
-}
-
  /**
   * To be called at GL teardown time, this frees compiler datastructures.
   *
@@ -2353,6 +2335,8 @@ void
  _mesa_destroy_shader_compiler(void)
  {
 _mesa_destroy_shader_compiler_caches();
+
+   _mesa_glsl_release_types();
  }
  
  /**

diff --git a/src/compiler/glsl/glsl_parser_extras.h 
b/src/compiler/glsl/glsl_parser_extras.h
index f92d2160aac..8646ba6cadd 100644
--- a/src/compiler/glsl/glsl_parser_extras.h
+++ b/src/compiler/glsl/glsl_parser_extras.h
@@ -1010,8 +1010,6 @@ extern int glcpp_preprocess(void *ctx, const char 
**shader, char **info_log,
  struct _mesa_glsl_parse_state *state,
  struct gl_context *gl_ctx);
  
-extern void _mesa_init_shader_compiler_types(void);

-extern void _mesa_destroy_shader_compiler_types(void);
  extern void _mesa_destroy_shader_compiler(void);
  extern void _mesa_destroy_shader_compiler_caches(void);
  
diff --git a/src/compiler/glsl/standalone.cpp b/src/compiler/glsl/standalone.cpp

index 7b3d358ca96..942b9ee4986 100644
--- a/src/compiler/glsl/standalone.cpp
+++ b/src/compiler/glsl/standalone.cpp
@@ -132,7 +132,6 @@ static void
  initialize_context(struct gl_context *ctx, gl_api api)
  {
 initialize_context_to_defaults(ctx, api);
-   glsl_type_singleton_init_or_ref();
  
 /* The standalone compiler needs to claim support for almost

  * everything in order to compile the built-in functions.
@@ -618,6 +617,6 @@ standalone_compiler_cleanup(struct gl_shader_program 
*whole_program)
 delete whole_program->FragDataIndexBindings;
  
 ralloc_free(whole_program);

-   glsl_type_singleton_decref();
+   _mesa_glsl_release_types();
 _mesa_glsl_release_builtin_functions();
  }
diff --git a/src/compiler/glsl_types.cpp b/src/compiler/glsl_types.cpp
index 9938b3df450..66241b34281 100644
--- a/src/compiler/glsl_types.cpp
+++ b/src/compiler/glsl_types.cpp
@@ -37,12 +37,6 @@ hash_table *glsl_type::interface_types = NULL;
  hash_table *glsl_type::function_types = NULL;
  hash_table *glsl_type::subroutine_types = NULL;
  
-/* There might be multiple users for types (e.g. application using OpenGL

- * and Vulkan simultanously or app using multiple Vulkan instances). Counter
- * is used to make sure we don't release the types if a user is still present.
- */
-static uint32_t glsl_type_users = 0;
-
  glsl_type::glsl_type(GLenum gl_type,
   glsl_base_type base_type, unsigned vector_elements,
   unsigned matrix_columns, const char *name,
@@ -475,26 +469,12 @@ hash_free_type_function(struct hash_entry *entry)
  }
  
  void

-glsl_type_singleton_init_or_ref()
+_mesa_glsl_release_types(void)
  {
-   mtx_lock(_type::hash_mutex);
-   glsl_type_users++;
-   mtx_unlock(_type::hash_mutex);
-}
-
-void
-glsl_type_singleton_decref()
-{
-   

Re: [Mesa-dev] [PATCH] nir: initialise some variables in opt_if_loop_last_continue()

[Tapani Pälli]

Reviewed-by: Tapani Pälli 

On 4/11/19 2:38 AM, Timothy Arceri wrote:

Fixes a couple of Coverity warnings CID 1444626.

Fixes: e30804c6024f ("nir/radv: remove restrictions on 
opt_if_loop_last_continue()")
---
  src/compiler/nir/nir_opt_if.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/compiler/nir/nir_opt_if.c b/src/compiler/nir/nir_opt_if.c
index 713bdf0c38a..d0aaf9f7133 100644
--- a/src/compiler/nir/nir_opt_if.c
+++ b/src/compiler/nir/nir_opt_if.c
@@ -839,8 +839,8 @@ static bool
  opt_if_loop_last_continue(nir_loop *loop, bool aggressive_last_continue)
  {
 nir_if *nif;
-   bool then_ends_in_continue;
-   bool else_ends_in_continue;
+   bool then_ends_in_continue = false;
+   bool else_ends_in_continue = false;
  
 /* Scan the control flow of the loop from the last to the first node

  * looking for an if-statement we can optimise.


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

Re: [Mesa-dev] [PATCH] mesa: don't overwrite existing shader files with MESA_SHADER_CAPTURE_PATH

[Tapani Pälli]

On 4/11/19 3:32 AM, Marek Olšák wrote:

From: Marek Olšák 

---
  src/mesa/main/shaderapi.c | 20 +---
  1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
index 01342c04e8f..6b73e6c7e7a 100644
--- a/src/mesa/main/shaderapi.c
+++ b/src/mesa/main/shaderapi.c
@@ -1233,24 +1233,38 @@ link_program(struct gl_context *ctx, struct 
gl_shader_program *shProg,
   if (shProg->_LinkedShaders[stage])
  prog = shProg->_LinkedShaders[stage]->Program;
  
   _mesa_use_program(ctx, stage, shProg, prog, ctx->_Shader);

}
 }
  
 /* Capture .shader_test files. */

 const char *capture_path = _mesa_get_shader_capture_path();
 if (shProg->Name != 0 && shProg->Name != ~0 && capture_path != NULL) {
-  FILE *file;
-  char *filename = ralloc_asprintf(NULL, "%s/%u.shader_test",
+  /* Find an unused filename. */
+  char *filename = NULL;
+  for (unsigned i = 0;; i++) {
+ if (i) {
+filename = ralloc_asprintf(NULL, "%s/%u-%u.shader_test",
+   capture_path, shProg->Name, i);
+ } else {
+filename = ralloc_asprintf(NULL, "%s/%u.shader_test",
 capture_path, shProg->Name);


How about just having the counter always there, to simplify a bit and 
have consistent filename scheme? Just a suggestion.



-  file = fopen(filename, "w");
+ }
+ FILE *file = fopen(filename, "r");
+ if (!file)
+break;


I'm surprised we don't have some helper like 'util_path_exists' but this 
works, I guess then we should have 'util_path_isdir|isfile' and others 
as well.


With or without the suggestion;
Reviewed-by: Tapani Pälli 


+ fclose(file);
+ ralloc_free(filename);
+  }
+
+  FILE *file = fopen(filename, "w");
if (file) {
   fprintf(file, "[require]\nGLSL%s >= %u.%02u\n",
   shProg->IsES ? " ES" : "",
   shProg->data->Version / 100, shProg->data->Version % 100);
   if (shProg->SeparateShader)
  fprintf(file, "GL_ARB_separate_shader_objects\nSSO ENABLED\n");
   fprintf(file, "\n");
  
   for (unsigned i = 0; i < shProg->NumShaders; i++) {

  fprintf(file, "[%s shader]\n%s\n",


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

Re: [Mesa-dev] [PATCH v7 1/5] util: Get program name based on path when possible

[Tapani Pälli]

On 3/21/19 12:02 PM, Eric Engestrom wrote:

On Thursday, 2019-03-21 09:14:15 +0200, Tapani Pälli wrote:

Hello;

One *very late* comment below ..

On 10/23/18 6:38 PM, Nicholas Kazlauskas wrote:

Some programs start with the path and command line arguments in
argv[0] (program_invocation_name). Chromium is an example of
an application using mesa that does this.

This tries to query the real path for the symbolic link /proc/self/exe
to find the program name instead. It only uses the realpath if it
was a prefix of the invocation to avoid breaking wine programs.

Cc: Timothy Arceri 
Signed-off-by: Nicholas Kazlauskas 
Reviewed-by: Eric Engestrom 
---
   src/util/u_process.c | 23 ++-
   1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/src/util/u_process.c b/src/util/u_process.c
index 5e5927678d..a1667e7807 100644
--- a/src/util/u_process.c
+++ b/src/util/u_process.c
@@ -41,8 +41,29 @@ static const char *
   __getProgramName()
   {
  char * arg = strrchr(program_invocation_name, '/');
-   if (arg)
+   if (arg) {
+  /* If the / character was found this is likely a linux path or
+   * an invocation path for a 64-bit wine program.
+   *
+   * However, some programs pass command line arguments into argv[0].
+   * Strip these arguments out by using the realpath only if it was
+   * a prefix of the invocation name.
+   */
+  static char *path;
+
+  if (!path)
+ path = realpath("/proc/self/exe", NULL);


realpath allocates memory that we will leak, it's not much but just wanted
to mention, it might be not trivial to fix since I guess not all variants of
__getProgramName will allocate?


Yeah, I was aware of this, but it will only be called once and will live
for the lifetime of the app, so it doesn't hurt much, and when I looked
it seemed like a hard thing to fix, so I decided to just ignore it.

If this is a problem somewhere, you can raise a bug and/or add a FIXME
comment on the line, if only to document it.



Yeah, should not be a real problem. I just happened to notice as I was 
trying to reach 0 leaks.


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

Re: [Mesa-dev] [PATCH] mesa: Fix GL_NUM_DEVICE_UUIDS_EXT

[Tapani Pälli]

On 3/21/19 4:03 PM, Józef Kucia wrote:

On Thu, Mar 21, 2019 at 1:24 PM Tapani Pälli  wrote:

Yeah, checked that value matches of find_value_indexed;

Reviewed-by: Tapani Pälli 


I don't have commits rights. Please push the patch for me.


sure


Does this affect 'ext_semaphore-api-errors' Piglit test that calls this
in any way?


No. Before the patch numDevices is 0 and 1 is invalid index anyway.

glGetUnsignedBytei_vEXT(GL_DEVICE_UUID_EXT, numDevices + 1, data);



Right :/ I find it a bit bad that the return value is not checked at 
all, maybe should update that test, ideally it would have caught this one.


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

Re: [Mesa-dev] [PATCH] mesa: Fix GL_NUM_DEVICE_UUIDS_EXT

[Tapani Pälli]

On 3/21/19 1:47 PM, Józef Kucia wrote:

On Tue, Mar 12, 2019 at 4:11 PM Józef Kucia  wrote:

  src/mesa/main/get.c | 3 +++
  1 file changed, 3 insertions(+)


Ping.

The patch fixes glGetIntegerv(GL_NUM_DEVICE_UUIDS_EXT, ...).
GL_NUM_DEVICE_UUIDS_EXT is implemented in the same way in
find_value_indexed().


Yeah, checked that value matches of find_value_indexed;

Reviewed-by: Tapani Pälli 

Does this affect 'ext_semaphore-api-errors' Piglit test that calls this 
in any way?




___
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 v7 1/5] util: Get program name based on path when possible

[Tapani Pälli]

doh, it seems I used reply-list instead of reply-all, sending again with 
original author of the patch ..


On 3/21/19 9:14 AM, Tapani Pälli wrote:

Hello;

One *very late* comment below ..

On 10/23/18 6:38 PM, Nicholas Kazlauskas wrote:

Some programs start with the path and command line arguments in
argv[0] (program_invocation_name). Chromium is an example of
an application using mesa that does this.

This tries to query the real path for the symbolic link /proc/self/exe
to find the program name instead. It only uses the realpath if it
was a prefix of the invocation to avoid breaking wine programs.

Cc: Timothy Arceri 
Signed-off-by: Nicholas Kazlauskas 
Reviewed-by: Eric Engestrom 
---
  src/util/u_process.c | 23 ++-
  1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/src/util/u_process.c b/src/util/u_process.c
index 5e5927678d..a1667e7807 100644
--- a/src/util/u_process.c
+++ b/src/util/u_process.c
@@ -41,8 +41,29 @@ static const char *
  __getProgramName()
  {
 char * arg = strrchr(program_invocation_name, '/');
-   if (arg)
+   if (arg) {
+  /* If the / character was found this is likely a linux path or
+   * an invocation path for a 64-bit wine program.
+   *
+   * However, some programs pass command line arguments into 
argv[0].

+   * Strip these arguments out by using the realpath only if it was
+   * a prefix of the invocation name.
+   */
+  static char *path;
+
+  if (!path)
+ path = realpath("/proc/self/exe", NULL);


realpath allocates memory that we will leak, it's not much but just 
wanted to mention, it might be not trivial to fix since I guess not all 
variants of __getProgramName will allocate?



+
+  if (path && strncmp(path, program_invocation_name, 
strlen(path)) == 0) {

+ /* This shouldn't be null because path is a a prefix,
+  * but check it anyway since path is static. */
+ char * name = strrchr(path, '/');
+ if (name)
+    return name + 1;
+  }
+
    return arg+1;
+   }
 /* If there was no '/' at all we likely have a windows like path 
from

  * a wine application.


___
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 v7 1/5] util: Get program name based on path when possible

[Tapani Pälli]

Hello;

One *very late* comment below ..

On 10/23/18 6:38 PM, Nicholas Kazlauskas wrote:

Some programs start with the path and command line arguments in
argv[0] (program_invocation_name). Chromium is an example of
an application using mesa that does this.

This tries to query the real path for the symbolic link /proc/self/exe
to find the program name instead. It only uses the realpath if it
was a prefix of the invocation to avoid breaking wine programs.

Cc: Timothy Arceri 
Signed-off-by: Nicholas Kazlauskas 
Reviewed-by: Eric Engestrom 
---
  src/util/u_process.c | 23 ++-
  1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/src/util/u_process.c b/src/util/u_process.c
index 5e5927678d..a1667e7807 100644
--- a/src/util/u_process.c
+++ b/src/util/u_process.c
@@ -41,8 +41,29 @@ static const char *
  __getProgramName()
  {
 char * arg = strrchr(program_invocation_name, '/');
-   if (arg)
+   if (arg) {
+  /* If the / character was found this is likely a linux path or
+   * an invocation path for a 64-bit wine program.
+   *
+   * However, some programs pass command line arguments into argv[0].
+   * Strip these arguments out by using the realpath only if it was
+   * a prefix of the invocation name.
+   */
+  static char *path;
+
+  if (!path)
+ path = realpath("/proc/self/exe", NULL);


realpath allocates memory that we will leak, it's not much but just 
wanted to mention, it might be not trivial to fix since I guess not all 
variants of __getProgramName will allocate?



+
+  if (path && strncmp(path, program_invocation_name, strlen(path)) == 0) {
+ /* This shouldn't be null because path is a a prefix,
+  * but check it anyway since path is static. */
+ char * name = strrchr(path, '/');
+ if (name)
+return name + 1;
+  }
+
return arg+1;
+   }
  
 /* If there was no '/' at all we likely have a windows like path from

  * a wine application.


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

Re: [Mesa-dev] MESA_Build_ERROR

[Tapani Pälli]

On 3/14/19 1:26 PM, Milav wrote:

Hello Sir,

This Is Milav Soni From TEQ DILIGENT.

I cross compiled the xserver using jhbuild.

I follow the following link.

https://www.x.org/wiki/CrossCompilingXorg/

But when it comes in mesa configuration, it gives following error.

/*--error-*/

copying selected object files to avoid basename conflicts...
   CXXLD    glsl_compiler
make[4]: Leaving directory 
`/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src/compiler'
make[3]: Leaving directory 
`/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src/compiler'

Making all in intel
make[3]: Entering directory 
`/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src/intel'

make  all-am
make[4]: Entering directory 
`/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src/intel'

   CC isl/libisl_tiled_memcpy_sse41_la-isl_tiled_memcpy_sse41.lo
   CC   tools/tools_aubinator-aub_mem.o
/home/teqdiligent/sources/xorg/git/mesa/mesa/src/intel/tools/aub_mem.c: 
In function 'memfd_create':
/home/teqdiligent/sources/xorg/git/mesa/mesa/src/intel/tools/aub_mem.c:37:19: 
error: 'SYS_memfd_create' undeclared (first use in this function)
/home/teqdiligent/sources/xorg/git/mesa/mesa/src/intel/tools/aub_mem.c:37:19: 
note: each undeclared identifier is reported only once for each function 
it appears in

make[4]: *** [tools/tools_aubinator-aub_mem.o] Error 1
make[4]: *** Waiting for unfinished jobs
*arm-cortexa8-linux-gnueabihf-gcc: error: unrecognized command line 
option '-msse4.1'*


What comes to sse41 error, it looks like we properly check for support 
in configure.ac but ignore the result (SSE41_SUPPORTED) in 
Makefile.isl.am. This change should fix it:


https://gitlab.freedesktop.org/mesa/mesa/merge_requests/451

(meson build handles this correctly)

make[4]: *** 
[isl/libisl_tiled_memcpy_sse41_la-isl_tiled_memcpy_sse41.lo] Error 1
make[4]: Leaving directory 
`/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src/intel'

make[3]: *** [all] Error 2
make[3]: Leaving directory 
`/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src/intel'

make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory 
`/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src'

make[1]: *** [all] Error 2
make[1]: Leaving directory 
`/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src'

make: *** [all-recursive] Error 1
*** Error during phase build of mesa-mesa: ## Error running make 
-j 2  *** [37/38]


   [1] Rerun phase build
   [2] Ignore error and continue to install
   [3] Give up on module
   [4] Start shell
   [5] Reload configuration
   [6] Go to phase "wipe directory and start over"
   [7] Go to phase "configure"
   [8] Go to phase "clean"
   [9] Go to phase "distclean"
choice: ^X^CInterrupted
teqdiligent@ubuntu:~$

/*---*/

I use following configuration.

$/home/teqdiligent/sources/xorg/git/mesa/mesa/autogen.sh --prefix 
/home/teqdiligent/jhbuild/wega_build/usr/local --disable-Werror 
--enable-autotools --enable-xa --disable-static --disable-dri2 
--with-driver=dri --cache-file=~/sources/xorg/git/autoconf-cache 
--with-log-dir=/var/log --with-mesa-source=~/sources/xorg/git/mesa 
--enable-malloc0returnsnull --build=x86_64-unknown-linux-gnu 
--host=arm-cortexa8-linux-gnueabihf 
--target=arm-cortexa8-linux-gnueabihf 
AR="/home/teqdiligent/HMI_SCADA/Toolchain/arm-cortexa8-linux-gnueabihf/bin/arm-cortexa8-linux-gnueabihf-ar" 
RANLIB="/home/teqdiligent/HMI_SCADA/Toolchain/arm-cortexa8-linux-gnueabihf/bin/arm-cortexa8-linux-gnueabihf-ranlib" 
STRIP="/home/teqdiligent/HMI_SCADA/Toolchain/arm-cortexa8-linux-gnueabihf/bin/arm-cortexa8-linux-gnueabihf-strip" 
AS="/home/teqdiligent/HMI_SCADA/Toolchain/arm-cortexa8-linux-gnueabihf/bin/arm-cortexa8-linux-gnueabihf-as" 
OBJDUMP="/home/teqdiligent/HMI_SCADA/Toolchain/arm-cortexa8-linux-gnueabihf/bin/arm-cortexa8-linux-gnueabihf-objdump" 
NM="/home/teqdiligent/HMI_SCADA/Toolchain/arm-cortexa8-linux-gnueabihf/bin/arm-cortexa8-linux-gnueabihf-nm" 




please help me to sort out this problem.

Looking forward hearing from you.

Regards

Milav Soni



___
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] anv: destroy descriptor sets when pool gets reset

[Tapani Pälli]

Makes sense, sorry I missed this one;

Reviewed-by: Tapani Pälli 

On 3/11/19 7:33 PM, Juan A. Suarez Romero wrote:

As stated in Vulkan spec:
"Resetting a descriptor pool recycles all of the resources from all
 of the descriptor sets allocated from the descriptor pool back to
 the descriptor pool, and the descriptor sets are implicitly freed."

This fixes dEQP-VK.api.descriptor_pool.*

Fixes: 14f6275c92f1 ("anv/descriptor_set: add reference counting for descriptor set 
layouts")
CC: Tapani Pälli 
CC: Lionel Landwerlin 
CC: Jason Ekstrand 
---
  src/intel/vulkan/anv_descriptor_set.c | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/src/intel/vulkan/anv_descriptor_set.c 
b/src/intel/vulkan/anv_descriptor_set.c
index f293cf469ee..f34a44aefd7 100644
--- a/src/intel/vulkan/anv_descriptor_set.c
+++ b/src/intel/vulkan/anv_descriptor_set.c
@@ -636,6 +636,12 @@ VkResult anv_ResetDescriptorPool(
 }
  
 anv_state_stream_finish(>surface_state_stream);

+
+   list_for_each_entry_safe(struct anv_descriptor_set, set,
+>desc_sets, pool_link) {
+  anv_descriptor_set_destroy(device, pool, set);
+   }
+
 anv_state_stream_init(>surface_state_stream,
   >surface_state_pool, 4096);
 pool->surface_state_free_list = NULL;


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

Re: [Mesa-dev] [PATCH 1/2] android: anv: fix generated files depedencies

[Tapani Pälli]

On 3/5/19 11:09 AM, Chih-Wei Huang wrote:

Tapani Pälli  於 2019年3月5日 週二 下午4:48寫道：


On 3/5/19 9:26 AM, Chih-Wei Huang wrote:

Mauro Rossi  於 2019年3月4日 週一 上午3:58寫道：


Fix anv_extrypoints.{c,h} and anv_extensions.{c,h} missing dependencies
Rename the variable labels according to targets and python scripts
Align the building rules as per Automake for simplification

Fixes building errors during rebuils due to missing dependencies

Fixes: 9a508b7 ("android: anv/extensions: fix generated sources build")
Fixes: dd088d4bec7 ("anv/extensions: Generate a header file with extension 
tables")
Signed-off-by: Mauro Rossi 
Cc: "19.0" 
---
   src/intel/Android.vulkan.mk | 38 +++--
   1 file changed, 24 insertions(+), 14 deletions(-)

diff --git a/src/intel/Android.vulkan.mk b/src/intel/Android.vulkan.mk
index 04c9d5b3e4..2e99ac6294 100644
--- a/src/intel/Android.vulkan.mk
+++ b/src/intel/Android.vulkan.mk
@@ -23,9 +23,10 @@ LOCAL_PATH := $(call my-dir)
   include $(CLEAR_VARS)
   include $(LOCAL_PATH)/Makefile.sources

-VK_ENTRYPOINTS_SCRIPT := $(MESA_PYTHON2) 
$(LOCAL_PATH)/vulkan/anv_entrypoints_gen.py
-
-VK_EXTENSIONS_SCRIPT := $(MESA_PYTHON2) 
$(LOCAL_PATH)/vulkan/anv_extensions_gen.py
+ANV_ENTRYPOINTS_GEN_SCRIPT := $(LOCAL_PATH)/vulkan/anv_entrypoints_gen.py
+ANV_EXTENSIONS_GEN_SCRIPT := $(LOCAL_PATH)/vulkan/anv_extensions_gen.py
+ANV_EXTENSIONS_SCRIPT := $(LOCAL_PATH)/vulkan/anv_extensions.py
+VULKAN_API_XML := $(MESA_TOP)/src/vulkan/registry/vk.xml

   VULKAN_COMMON_INCLUDES := \
  $(MESA_TOP)/include \
@@ -64,10 +65,13 @@ $(intermediates)/vulkan/dummy.c:
  @echo "Gen Dummy: $(PRIVATE_MODULE) <= $(notdir $(@))"
  $(hide) touch $@

-$(intermediates)/vulkan/anv_entrypoints.h: $(intermediates)/vulkan/dummy.c
-   $(VK_ENTRYPOINTS_SCRIPT) \
+$(intermediates)/vulkan/anv_entrypoints.h: $(intermediates)/vulkan/dummy.c \


I know it was not introduced in this patch.
However, it makes no sense to let the header depend on a generated empty file.
This should be removed.


dummy.c is there to meet the Android build system's rules .. comment in
this file says:


I understand that.
I meant the header anv_entrypoints.h doesn't need to
depend on the generated dummy.c. That's clear.


Yeah is see, it is enough to have it in LOCAL_GENERATED_SOURCES and 
there is no need to depend on it to get it generated.



# libmesa_anv_entrypoints with header and dummy.c
#
# This static library is built to pull entrypoints header
# for multiple gen specific build targets below. The c file
# is generated separately for libmesa_vulkan_common to avoid
# duplicate symbols when linking the anv libraries.

we have same hack applied also in following files within Mesa tree:

src/mesa/Android.libmesa_git_sha1.mk
src/intel/Android.genxml.mk
src/broadcom/Android.genxml.mk



+  $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
+  $(ANV_EXTENSIONS_SCRIPT) \
+  $(VULKAN_API_XML)
+   $(MESA_PYTHON2) $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
  --outdir $(dir $@) \
-   --xml $(MESA_TOP)/src/vulkan/registry/vk.xml
+   --xml $(VULKAN_API_XML)

   LOCAL_EXPORT_C_INCLUDE_DIRS := \
   $(intermediates)
@@ -241,22 +245,28 @@ LOCAL_GENERATED_SOURCES += 
$(intermediates)/vulkan/anv_entrypoints.c
   LOCAL_GENERATED_SOURCES += $(intermediates)/vulkan/anv_extensions.c
   LOCAL_GENERATED_SOURCES += $(intermediates)/vulkan/anv_extensions.h

-$(intermediates)/vulkan/anv_entrypoints.c:
+$(intermediates)/vulkan/anv_entrypoints.c: $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
+  $(ANV_EXTENSIONS_SCRIPT) \
+  $(VULKAN_API_XML)
  @mkdir -p $(dir $@)
-   $(VK_ENTRYPOINTS_SCRIPT) \
+   $(MESA_PYTHON2) $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
  --xml $(MESA_TOP)/src/vulkan/registry/vk.xml \
  --outdir $(dir $@)

-$(intermediates)/vulkan/anv_extensions.c:
+$(intermediates)/vulkan/anv_extensions.c: $(ANV_EXTENSIONS_GEN_SCRIPT) \
+ $(ANV_EXTENSIONS_SCRIPT) \
+ $(VULKAN_API_XML)
  @mkdir -p $(dir $@)
-   $(VK_EXTENSIONS_SCRIPT) \
-   --xml $(MESA_TOP)/src/vulkan/registry/vk.xml \
+   $(MESA_PYTHON2) $(ANV_EXTENSIONS_GEN_SCRIPT) \
+   --xml $(VULKAN_API_XML) \
  --out-c $@

-$(intermediates)/vulkan/anv_extensions.h:
+$(intermediates)/vulkan/anv_extensions.h: $(ANV_EXTENSIONS_GEN_SCRIPT) \
+  $(ANV_EXTENSIONS_SCRIPT) \
+  $(VULKAN_API_XML)
  @mkdir -p $(dir $@)
-   $(VK_EXTENSIONS_SCRIPT) \
-   --xml $(MESA_TOP)/src/vulkan/registry/vk.xml \
+   $(MESA_PYTHON2) $(ANV_EXTENSIONS_GEN_SCRIP

Re: [Mesa-dev] [PATCH 1/2] android: anv: fix generated files depedencies

[Tapani Pälli]

On 3/5/19 9:26 AM, Chih-Wei Huang wrote:

Mauro Rossi  於 2019年3月4日 週一 上午3:58寫道：


Fix anv_extrypoints.{c,h} and anv_extensions.{c,h} missing dependencies
Rename the variable labels according to targets and python scripts
Align the building rules as per Automake for simplification

Fixes building errors during rebuils due to missing dependencies

Fixes: 9a508b7 ("android: anv/extensions: fix generated sources build")
Fixes: dd088d4bec7 ("anv/extensions: Generate a header file with extension 
tables")
Signed-off-by: Mauro Rossi 
Cc: "19.0" 
---
  src/intel/Android.vulkan.mk | 38 +++--
  1 file changed, 24 insertions(+), 14 deletions(-)

diff --git a/src/intel/Android.vulkan.mk b/src/intel/Android.vulkan.mk
index 04c9d5b3e4..2e99ac6294 100644
--- a/src/intel/Android.vulkan.mk
+++ b/src/intel/Android.vulkan.mk
@@ -23,9 +23,10 @@ LOCAL_PATH := $(call my-dir)
  include $(CLEAR_VARS)
  include $(LOCAL_PATH)/Makefile.sources

-VK_ENTRYPOINTS_SCRIPT := $(MESA_PYTHON2) 
$(LOCAL_PATH)/vulkan/anv_entrypoints_gen.py
-
-VK_EXTENSIONS_SCRIPT := $(MESA_PYTHON2) 
$(LOCAL_PATH)/vulkan/anv_extensions_gen.py
+ANV_ENTRYPOINTS_GEN_SCRIPT := $(LOCAL_PATH)/vulkan/anv_entrypoints_gen.py
+ANV_EXTENSIONS_GEN_SCRIPT := $(LOCAL_PATH)/vulkan/anv_extensions_gen.py
+ANV_EXTENSIONS_SCRIPT := $(LOCAL_PATH)/vulkan/anv_extensions.py
+VULKAN_API_XML := $(MESA_TOP)/src/vulkan/registry/vk.xml

  VULKAN_COMMON_INCLUDES := \
 $(MESA_TOP)/include \
@@ -64,10 +65,13 @@ $(intermediates)/vulkan/dummy.c:
 @echo "Gen Dummy: $(PRIVATE_MODULE) <= $(notdir $(@))"
 $(hide) touch $@

-$(intermediates)/vulkan/anv_entrypoints.h: $(intermediates)/vulkan/dummy.c
-   $(VK_ENTRYPOINTS_SCRIPT) \
+$(intermediates)/vulkan/anv_entrypoints.h: $(intermediates)/vulkan/dummy.c \


I know it was not introduced in this patch.
However, it makes no sense to let the header depend on a generated empty file.
This should be removed.


dummy.c is there to meet the Android build system's rules .. comment in 
this file says:


# libmesa_anv_entrypoints with header and dummy.c
#
# This static library is built to pull entrypoints header
# for multiple gen specific build targets below. The c file
# is generated separately for libmesa_vulkan_common to avoid
# duplicate symbols when linking the anv libraries.

we have same hack applied also in following files within Mesa tree:

src/mesa/Android.libmesa_git_sha1.mk
src/intel/Android.genxml.mk
src/broadcom/Android.genxml.mk



+  $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
+  $(ANV_EXTENSIONS_SCRIPT) \
+  $(VULKAN_API_XML)
+   $(MESA_PYTHON2) $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
 --outdir $(dir $@) \
-   --xml $(MESA_TOP)/src/vulkan/registry/vk.xml
+   --xml $(VULKAN_API_XML)

  LOCAL_EXPORT_C_INCLUDE_DIRS := \
  $(intermediates)
@@ -241,22 +245,28 @@ LOCAL_GENERATED_SOURCES += 
$(intermediates)/vulkan/anv_entrypoints.c
  LOCAL_GENERATED_SOURCES += $(intermediates)/vulkan/anv_extensions.c
  LOCAL_GENERATED_SOURCES += $(intermediates)/vulkan/anv_extensions.h

-$(intermediates)/vulkan/anv_entrypoints.c:
+$(intermediates)/vulkan/anv_entrypoints.c: $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
+  $(ANV_EXTENSIONS_SCRIPT) \
+  $(VULKAN_API_XML)
 @mkdir -p $(dir $@)
-   $(VK_ENTRYPOINTS_SCRIPT) \
+   $(MESA_PYTHON2) $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
 --xml $(MESA_TOP)/src/vulkan/registry/vk.xml \
 --outdir $(dir $@)

-$(intermediates)/vulkan/anv_extensions.c:
+$(intermediates)/vulkan/anv_extensions.c: $(ANV_EXTENSIONS_GEN_SCRIPT) \
+ $(ANV_EXTENSIONS_SCRIPT) \
+ $(VULKAN_API_XML)
 @mkdir -p $(dir $@)
-   $(VK_EXTENSIONS_SCRIPT) \
-   --xml $(MESA_TOP)/src/vulkan/registry/vk.xml \
+   $(MESA_PYTHON2) $(ANV_EXTENSIONS_GEN_SCRIPT) \
+   --xml $(VULKAN_API_XML) \
 --out-c $@

-$(intermediates)/vulkan/anv_extensions.h:
+$(intermediates)/vulkan/anv_extensions.h: $(ANV_EXTENSIONS_GEN_SCRIPT) \
+  $(ANV_EXTENSIONS_SCRIPT) \
+  $(VULKAN_API_XML)
 @mkdir -p $(dir $@)
-   $(VK_EXTENSIONS_SCRIPT) \
-   --xml $(MESA_TOP)/src/vulkan/registry/vk.xml \
+   $(MESA_PYTHON2) $(ANV_EXTENSIONS_GEN_SCRIPT) \
+   --xml $(VULKAN_API_XML) \
 --out-h $@

  LOCAL_SHARED_LIBRARIES := $(ANV_SHARED_LIBRARIES)
--




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

Re: [Mesa-dev] [PATCH] android: anv: fix generated files depedencies (v2)

[Tapani Pälli]

Reviewed-by: Tapani Pälli 

On 3/4/19 2:45 PM, Mauro Rossi wrote:

Fix anv_extrypoints.{c,h} and anv_extensions.{c,h} missing dependencies
Rename the variable labels according to targets and python scripts
Align the building rules as per Automake for simplification

Fixes building errors during rebuils due to missing dependencies

(v2) Fixed a missing $(VULKAN_API_XML) reference

Fixes: 9a508b7 ("android: anv/extensions: fix generated sources build")
Fixes: dd088d4bec7 ("anv/extensions: Generate a header file with extension 
tables")
Signed-off-by: Mauro Rossi 
Cc: "19.0" 
---
  src/intel/Android.vulkan.mk | 40 +++--
  1 file changed, 25 insertions(+), 15 deletions(-)

diff --git a/src/intel/Android.vulkan.mk b/src/intel/Android.vulkan.mk
index 04c9d5b3e4..9fdb8debf2 100644
--- a/src/intel/Android.vulkan.mk
+++ b/src/intel/Android.vulkan.mk
@@ -23,9 +23,10 @@ LOCAL_PATH := $(call my-dir)
  include $(CLEAR_VARS)
  include $(LOCAL_PATH)/Makefile.sources
  
-VK_ENTRYPOINTS_SCRIPT := $(MESA_PYTHON2) $(LOCAL_PATH)/vulkan/anv_entrypoints_gen.py

-
-VK_EXTENSIONS_SCRIPT := $(MESA_PYTHON2) 
$(LOCAL_PATH)/vulkan/anv_extensions_gen.py
+ANV_ENTRYPOINTS_GEN_SCRIPT := $(LOCAL_PATH)/vulkan/anv_entrypoints_gen.py
+ANV_EXTENSIONS_GEN_SCRIPT := $(LOCAL_PATH)/vulkan/anv_extensions_gen.py
+ANV_EXTENSIONS_SCRIPT := $(LOCAL_PATH)/vulkan/anv_extensions.py
+VULKAN_API_XML := $(MESA_TOP)/src/vulkan/registry/vk.xml
  
  VULKAN_COMMON_INCLUDES := \

$(MESA_TOP)/include \
@@ -64,10 +65,13 @@ $(intermediates)/vulkan/dummy.c:
@echo "Gen Dummy: $(PRIVATE_MODULE) <= $(notdir $(@))"
$(hide) touch $@
  
-$(intermediates)/vulkan/anv_entrypoints.h: $(intermediates)/vulkan/dummy.c

-   $(VK_ENTRYPOINTS_SCRIPT) \
+$(intermediates)/vulkan/anv_entrypoints.h: $(intermediates)/vulkan/dummy.c \
+  $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
+  $(ANV_EXTENSIONS_SCRIPT) \
+  $(VULKAN_API_XML)
+   $(MESA_PYTHON2) $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
--outdir $(dir $@) \
-   --xml $(MESA_TOP)/src/vulkan/registry/vk.xml
+   --xml $(VULKAN_API_XML)
  
  LOCAL_EXPORT_C_INCLUDE_DIRS := \

  $(intermediates)
@@ -241,22 +245,28 @@ LOCAL_GENERATED_SOURCES += 
$(intermediates)/vulkan/anv_entrypoints.c
  LOCAL_GENERATED_SOURCES += $(intermediates)/vulkan/anv_extensions.c
  LOCAL_GENERATED_SOURCES += $(intermediates)/vulkan/anv_extensions.h
  
-$(intermediates)/vulkan/anv_entrypoints.c:

+$(intermediates)/vulkan/anv_entrypoints.c: $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
+  $(ANV_EXTENSIONS_SCRIPT) \
+  $(VULKAN_API_XML)
@mkdir -p $(dir $@)
-   $(VK_ENTRYPOINTS_SCRIPT) \
-   --xml $(MESA_TOP)/src/vulkan/registry/vk.xml \
+   $(MESA_PYTHON2) $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
+   --xml $(VULKAN_API_XML) \
--outdir $(dir $@)
  
-$(intermediates)/vulkan/anv_extensions.c:

+$(intermediates)/vulkan/anv_extensions.c: $(ANV_EXTENSIONS_GEN_SCRIPT) \
+ $(ANV_EXTENSIONS_SCRIPT) \
+ $(VULKAN_API_XML)
@mkdir -p $(dir $@)
-   $(VK_EXTENSIONS_SCRIPT) \
-   --xml $(MESA_TOP)/src/vulkan/registry/vk.xml \
+   $(MESA_PYTHON2) $(ANV_EXTENSIONS_GEN_SCRIPT) \
+   --xml $(VULKAN_API_XML) \
--out-c $@
  
-$(intermediates)/vulkan/anv_extensions.h:

+$(intermediates)/vulkan/anv_extensions.h: $(ANV_EXTENSIONS_GEN_SCRIPT) \
+  $(ANV_EXTENSIONS_SCRIPT) \
+  $(VULKAN_API_XML)
@mkdir -p $(dir $@)
-   $(VK_EXTENSIONS_SCRIPT) \
-   --xml $(MESA_TOP)/src/vulkan/registry/vk.xml \
+   $(MESA_PYTHON2) $(ANV_EXTENSIONS_GEN_SCRIPT) \
+   --xml $(VULKAN_API_XML) \
--out-h $@
  
  LOCAL_SHARED_LIBRARIES := $(ANV_SHARED_LIBRARIES)



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

Re: [Mesa-dev] [PATCH 2/2] android: anv: fix libexpat shared dependency

[Tapani Pälli]

Never saw this error but change looks correct,

Reviewed-by: Tapani Pälli 

On 3/3/19 9:57 PM, Mauro Rossi wrote:

Fixes undefined reference building errors for XML_* functions

Signed-off-by: Mauro Rossi 
Cc: "19.0" 
---
  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 2e99ac6294..c9bce50c78 100644
--- a/src/intel/Android.vulkan.mk
+++ b/src/intel/Android.vulkan.mk
@@ -318,7 +318,7 @@ LOCAL_WHOLE_STATIC_LIBRARIES := \
libmesa_intel_compiler \
libmesa_anv_entrypoints
  
-LOCAL_SHARED_LIBRARIES := $(ANV_SHARED_LIBRARIES) libz libsync liblog

+LOCAL_SHARED_LIBRARIES := $(ANV_SHARED_LIBRARIES) libexpat libz libsync liblog
  
  include $(MESA_COMMON_MK)

  include $(BUILD_SHARED_LIBRARY)


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

Re: [Mesa-dev] [PATCH 1/2] android: anv: fix generated files depedencies

[Tapani Pälli]

On 3/3/19 9:57 PM, Mauro Rossi wrote:

Fix anv_extrypoints.{c,h} and anv_extensions.{c,h} missing dependencies
Rename the variable labels according to targets and python scripts
Align the building rules as per Automake for simplification

Fixes building errors during rebuils due to missing dependencies


rebuils -> rebuilds


Fixes: 9a508b7 ("android: anv/extensions: fix generated sources build")
Fixes: dd088d4bec7 ("anv/extensions: Generate a header file with extension 
tables")
Signed-off-by: Mauro Rossi 
Cc: "19.0" 
---
  src/intel/Android.vulkan.mk | 38 +++--
  1 file changed, 24 insertions(+), 14 deletions(-)

diff --git a/src/intel/Android.vulkan.mk b/src/intel/Android.vulkan.mk
index 04c9d5b3e4..2e99ac6294 100644
--- a/src/intel/Android.vulkan.mk
+++ b/src/intel/Android.vulkan.mk
@@ -23,9 +23,10 @@ LOCAL_PATH := $(call my-dir)
  include $(CLEAR_VARS)
  include $(LOCAL_PATH)/Makefile.sources
  
-VK_ENTRYPOINTS_SCRIPT := $(MESA_PYTHON2) $(LOCAL_PATH)/vulkan/anv_entrypoints_gen.py

-
-VK_EXTENSIONS_SCRIPT := $(MESA_PYTHON2) 
$(LOCAL_PATH)/vulkan/anv_extensions_gen.py
+ANV_ENTRYPOINTS_GEN_SCRIPT := $(LOCAL_PATH)/vulkan/anv_entrypoints_gen.py
+ANV_EXTENSIONS_GEN_SCRIPT := $(LOCAL_PATH)/vulkan/anv_extensions_gen.py
+ANV_EXTENSIONS_SCRIPT := $(LOCAL_PATH)/vulkan/anv_extensions.py
+VULKAN_API_XML := $(MESA_TOP)/src/vulkan/registry/vk.xml
  
  VULKAN_COMMON_INCLUDES := \

$(MESA_TOP)/include \
@@ -64,10 +65,13 @@ $(intermediates)/vulkan/dummy.c:
@echo "Gen Dummy: $(PRIVATE_MODULE) <= $(notdir $(@))"
$(hide) touch $@
  
-$(intermediates)/vulkan/anv_entrypoints.h: $(intermediates)/vulkan/dummy.c

-   $(VK_ENTRYPOINTS_SCRIPT) \
+$(intermediates)/vulkan/anv_entrypoints.h: $(intermediates)/vulkan/dummy.c \
+  $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
+  $(ANV_EXTENSIONS_SCRIPT) \
+  $(VULKAN_API_XML)
+   $(MESA_PYTHON2) $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
--outdir $(dir $@) \
-   --xml $(MESA_TOP)/src/vulkan/registry/vk.xml
+   --xml $(VULKAN_API_XML)
  
  LOCAL_EXPORT_C_INCLUDE_DIRS := \

  $(intermediates)
@@ -241,22 +245,28 @@ LOCAL_GENERATED_SOURCES += 
$(intermediates)/vulkan/anv_entrypoints.c
  LOCAL_GENERATED_SOURCES += $(intermediates)/vulkan/anv_extensions.c
  LOCAL_GENERATED_SOURCES += $(intermediates)/vulkan/anv_extensions.h
  
-$(intermediates)/vulkan/anv_entrypoints.c:

+$(intermediates)/vulkan/anv_entrypoints.c: $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
+  $(ANV_EXTENSIONS_SCRIPT) \
+  $(VULKAN_API_XML)
@mkdir -p $(dir $@)
-   $(VK_ENTRYPOINTS_SCRIPT) \
+   $(MESA_PYTHON2) $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
--xml $(MESA_TOP)/src/vulkan/registry/vk.xml \


This one should be $(VULKAN_API_XML) as well


--outdir $(dir $@)
  
-$(intermediates)/vulkan/anv_extensions.c:

+$(intermediates)/vulkan/anv_extensions.c: $(ANV_EXTENSIONS_GEN_SCRIPT) \
+ $(ANV_EXTENSIONS_SCRIPT) \
+ $(VULKAN_API_XML)
@mkdir -p $(dir $@)
-   $(VK_EXTENSIONS_SCRIPT) \
-   --xml $(MESA_TOP)/src/vulkan/registry/vk.xml \
+   $(MESA_PYTHON2) $(ANV_EXTENSIONS_GEN_SCRIPT) \
+   --xml $(VULKAN_API_XML) \
--out-c $@
  
-$(intermediates)/vulkan/anv_extensions.h:

+$(intermediates)/vulkan/anv_extensions.h: $(ANV_EXTENSIONS_GEN_SCRIPT) \
+  $(ANV_EXTENSIONS_SCRIPT) \
+  $(VULKAN_API_XML)
@mkdir -p $(dir $@)
-   $(VK_EXTENSIONS_SCRIPT) \
-   --xml $(MESA_TOP)/src/vulkan/registry/vk.xml \
+   $(MESA_PYTHON2) $(ANV_EXTENSIONS_GEN_SCRIPT) \
+   --xml $(VULKAN_API_XML) \
--out-h $@
  
  LOCAL_SHARED_LIBRARIES := $(ANV_SHARED_LIBRARIES)



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

Re: [Mesa-dev] [PATCH] android, autotools: st/mesa: fix location of float64_glsl.h

[Tapani Pälli]

Hi;

On 3/3/19 10:10 PM, Mauro Rossi wrote:

Necessary to avoid building error in Android,
due to 'compiler/glsl/float64_glsl.h' file not found

Fixes: cb4e3e3 ("st/mesa: add support for lowering fp64/int64 for nir drivers")
Signed-off-by: Mauro Rossi 
---
  src/mesa/Android.libmesa_st_mesa.mk   | 1 +
  src/mesa/Makefile.sources | 1 +
  src/mesa/state_tracker/st_glsl_to_nir.cpp | 2 +-
  3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/mesa/Android.libmesa_st_mesa.mk 
b/src/mesa/Android.libmesa_st_mesa.mk
index ddfd03059c..c5b16cad34 100644
--- a/src/mesa/Android.libmesa_st_mesa.mk
+++ b/src/mesa/Android.libmesa_st_mesa.mk
@@ -58,6 +58,7 @@ endif
  LOCAL_C_INCLUDES := \
$(MESA_TOP)/src/mapi \
$(MESA_TOP)/src/mesa/main \
+   $(call generated-sources-dir-for,STATIC_LIBRARIES,libmesa_glsl,,) \
$(MESA_TOP)/src/compiler/nir \
$(MESA_TOP)/src/gallium/auxiliary \
$(MESA_TOP)/src/gallium/include
diff --git a/src/mesa/Makefile.sources b/src/mesa/Makefile.sources
index 1e25f47e50..69f32c6adf 100644
--- a/src/mesa/Makefile.sources
+++ b/src/mesa/Makefile.sources
@@ -689,6 +689,7 @@ INCLUDE_DIRS = \
-I$(top_srcdir)/include \
-I$(top_builddir)/src \
-I$(top_srcdir)/src \
+   -I$(top_builddir)/src/compiler \
-I$(top_builddir)/src/compiler/glsl \
-I$(top_builddir)/src/compiler/nir \
-I$(top_builddir)/src/mesa \
diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp 
b/src/mesa/state_tracker/st_glsl_to_nir.cpp
index a1e3b6233c..ad77b746ab 100644
--- a/src/mesa/state_tracker/st_glsl_to_nir.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_nir.cpp
@@ -48,7 +48,7 @@
  #include "compiler/glsl/ir.h"
  #include "compiler/glsl/ir_optimization.h"
  #include "compiler/glsl/string_to_uint_map.h"
-#include "compiler/glsl/float64_glsl.h"
+#include "glsl/float64_glsl.h"


Looks familiar :)

https://github.com/tpalli/external-mesa/commit/ebd8581ad133206ec2b1b818e98dc4f8401af8de

Before going further though, I'd like to understand why do we have both 
'compiler/glsl/' and 'glsl/' going on. Should we rather put the 
'compiler' back in the header generation? I can't remember the full 
story behind commit c812c740e60 but that one changed this .. perhaps we 
should pull it back and have the 'compiler/', any objections to that?


Thanks;

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

Re: [Mesa-dev] [PATCH] mesa/prgram: Use nir_variable_create in prog_to_nir to avoid a memleak.

[Tapani Pälli]

Hi Matthias;

I pushed this change earlier (commit 1d5e5ec30a6) with you in 'Reported-by'.

Thanks;

// Tapani

On 2/25/19 1:16 PM, Matthias Lorenz wrote:

Use of nir_variable_create was suggested by Jason Ekstrand.

Fixes: 3d7611e9 "st/nir: use NIR for asm programs"
---
  src/mesa/program/prog_to_nir.c | 13 ++---
  1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/src/mesa/program/prog_to_nir.c b/src/mesa/program/prog_to_nir.c
index 1c9d0018d55..3f8abb121e7 100644
--- a/src/mesa/program/prog_to_nir.c
+++ b/src/mesa/program/prog_to_nir.c
@@ -1012,13 +1012,12 @@ prog_to_nir(const struct gl_program *prog,
 s = c->build.shader;

 if (prog->Parameters->NumParameters > 0) {
-  c->parameters = rzalloc(s, nir_variable);
-  c->parameters->type =
- glsl_array_type(glsl_vec4_type(), prog->Parameters->NumParameters, 0);
-  c->parameters->name = strdup(prog->Parameters->Parameters[0].Name);
-  c->parameters->data.read_only = true;
-  c->parameters->data.mode = nir_var_uniform;
-  exec_list_push_tail(>uniforms, >parameters->node);
+  c->parameters =
+ nir_variable_create(s, nir_var_uniform,
+ glsl_array_type(glsl_vec4_type(),
+ prog->Parameters->NumParameters,
+ 0),
+ prog->Parameters->Parameters[0].Name);
 }

 setup_registers_and_variables(c);
--
2.20.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] nir: use nir_variable_create instead of open-coding the logic

[Tapani Pälli]

Fixes: 3d7611e9 "st/nir: use NIR for asm programs"
Reported-by: Matthias Lorenz 
Signed-off-by: Tapani Pälli 
---
 src/mesa/program/prog_to_nir.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/src/mesa/program/prog_to_nir.c b/src/mesa/program/prog_to_nir.c
index 1c9d0018d55..aa4f2aaf72a 100644
--- a/src/mesa/program/prog_to_nir.c
+++ b/src/mesa/program/prog_to_nir.c
@@ -1012,13 +1012,11 @@ prog_to_nir(const struct gl_program *prog,
s = c->build.shader;
 
if (prog->Parameters->NumParameters > 0) {
-  c->parameters = rzalloc(s, nir_variable);
-  c->parameters->type =
+  const struct glsl_type *type =
  glsl_array_type(glsl_vec4_type(), prog->Parameters->NumParameters, 0);
-  c->parameters->name = strdup(prog->Parameters->Parameters[0].Name);
-  c->parameters->data.read_only = true;
-  c->parameters->data.mode = nir_var_uniform;
-  exec_list_push_tail(>uniforms, >parameters->node);
+  c->parameters =
+ nir_variable_create(s, nir_var_uniform, type,
+ prog->Parameters->Parameters[0].Name);
}
 
setup_registers_and_variables(c);
-- 
2.20.1

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

Re: [Mesa-dev] [PATCH 1/1] Avoid leaking parameter name in prog_to_nir.

[Tapani Pälli]

Yep, confirmed that this plugs the leak.

FWIW there seems to be also "Conditional jump or move depends on 
uninitialised value(s)" from valgrind but that is for something different.


Reviewed-by: Tapani Pälli 

On 2/21/19 11:09 AM, Matthias Lorenz wrote:

Fixes: 3d7611e9 "st/nir: use NIR for asm programs"
---
  src/mesa/program/prog_to_nir.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/mesa/program/prog_to_nir.c b/src/mesa/program/prog_to_nir.c
index 312b299361e..6e3fa9432a3 100644
--- a/src/mesa/program/prog_to_nir.c
+++ b/src/mesa/program/prog_to_nir.c
@@ -1024,7 +1024,8 @@ prog_to_nir(const struct gl_program *prog,
c->parameters = rzalloc(s, nir_variable);
c->parameters->type =
   glsl_array_type(glsl_vec4_type(), prog->Parameters->NumParameters, 
0);
-  c->parameters->name = strdup(prog->Parameters->Parameters[0].Name);
+  c->parameters->name =
+ ralloc_strdup(c->parameters, prog->Parameters->Parameters[0].Name);
c->parameters->data.read_only = true;
c->parameters->data.mode = nir_var_uniform;
exec_list_push_tail(>uniforms, >parameters->node);
--
2.20.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

Re: [Mesa-dev] [PATCH] android: intel/isl: remove redundant building rules

[Tapani Pälli]

OK now I understand, this hunk got added accidentially twice from 2 
separate commits!


Reviewed-by: Tapani Pälli 

On 2/22/19 7:50 AM, Tapani Pälli wrote:

Hi;

On 2/22/19 1:30 AM, Mauro Rossi wrote:

Fixes the following building error:

including ./external/mesa/Android.mk ...
build/core/base_rules.mk:183: *** external/mesa/src/intel:
MODULE.TARGET.STATIC_LIBRARIES.libmesa_isl_tiled_memcpy already 
defined by external/mesa/src/intel.
make: *** [build/core/ninja.mk:164: out/build-android_x86_64.ninja] 
Error 1


This is strange, craftyguy also reported same error .. I haven't seen 
this though.



ISL_TILED_MEMCPY_FILES is isl/isl_tiled_memcpy_normal.c
and that source file includes isl_tiled_memcpy.c source


Yes, that is intentional. We want to compile 2 versions of the library, 
'normal' one and 'sse41' one.



Fixes: 96bb328 ("iris: add Android build")
Signed-off-by: Mauro Rossi 
---
  src/intel/Android.isl.mk | 13 -
  1 file changed, 13 deletions(-)

diff --git a/src/intel/Android.isl.mk b/src/intel/Android.isl.mk
index 28944875e0..07a64b8ed1 100644
--- a/src/intel/Android.isl.mk
+++ b/src/intel/Android.isl.mk
@@ -198,19 +198,6 @@ LOCAL_WHOLE_STATIC_LIBRARIES := libmesa_genxml
  include $(MESA_COMMON_MK)
  include $(BUILD_STATIC_LIBRARY)
-
-# ---
-# Build libmesa_isl_tiled_memcpy
-# ---
-include $(CLEAR_VARS)
-
-LOCAL_MODULE := libmesa_isl_tiled_memcpy
-
-LOCAL_SRC_FILES := isl/isl_tiled_memcpy.c
-
-include $(MESA_COMMON_MK)
-include $(BUILD_STATIC_LIBRARY)
-
  # ---
  # Build libmesa_isl_tiled_memcpy
  # ---


     ^^^

Do you have libmesa_isl_tiled_memcpy 2 times there? This does not match 
what Mesa has ATM.


// Tapani
___
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] android: intel/isl: remove redundant building rules

[Tapani Pälli]

Hi;

On 2/22/19 1:30 AM, Mauro Rossi wrote:

Fixes the following building error:

including ./external/mesa/Android.mk ...
build/core/base_rules.mk:183: *** external/mesa/src/intel:
MODULE.TARGET.STATIC_LIBRARIES.libmesa_isl_tiled_memcpy already defined by 
external/mesa/src/intel.
make: *** [build/core/ninja.mk:164: out/build-android_x86_64.ninja] Error 1


This is strange, craftyguy also reported same error .. I haven't seen 
this though.



ISL_TILED_MEMCPY_FILES is isl/isl_tiled_memcpy_normal.c
and that source file includes isl_tiled_memcpy.c source


Yes, that is intentional. We want to compile 2 versions of the library, 
'normal' one and 'sse41' one.



Fixes: 96bb328 ("iris: add Android build")
Signed-off-by: Mauro Rossi 
---
  src/intel/Android.isl.mk | 13 -
  1 file changed, 13 deletions(-)

diff --git a/src/intel/Android.isl.mk b/src/intel/Android.isl.mk
index 28944875e0..07a64b8ed1 100644
--- a/src/intel/Android.isl.mk
+++ b/src/intel/Android.isl.mk
@@ -198,19 +198,6 @@ LOCAL_WHOLE_STATIC_LIBRARIES := libmesa_genxml
  include $(MESA_COMMON_MK)
  include $(BUILD_STATIC_LIBRARY)
  
-

-# ---
-# Build libmesa_isl_tiled_memcpy
-# ---
-include $(CLEAR_VARS)
-
-LOCAL_MODULE := libmesa_isl_tiled_memcpy
-
-LOCAL_SRC_FILES := isl/isl_tiled_memcpy.c
-
-include $(MESA_COMMON_MK)
-include $(BUILD_STATIC_LIBRARY)
-
  # ---
  # Build libmesa_isl_tiled_memcpy
  # ---


^^^

Do you have libmesa_isl_tiled_memcpy 2 times there? This does not match 
what Mesa has ATM.


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

Re: [Mesa-dev] [PATCH] glsl: Fix function return typechecking

[Tapani Pälli]

On 2/21/19 11:35 AM, Tapani Pälli wrote:

Hi;

On 2/11/19 6:46 PM, Oscar Blumberg wrote:

apply_implicit_conversion only converts and check base types but we
need actual type equality for function returns, otherwise you can
return a vec2 from a function declared as returning a float.


Do you have some test shader that hits this condition? It seems to me 
that currently we will error out correctly if one tries to return vec2 
from function declared as returning a float.


Ah forget that, I can see it can happen with ARB_shading_language_420pack!

Reviewed-by: Tapani Pälli 


---
  src/compiler/glsl/ast_to_hir.cpp | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

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

index 620153e6a34..6bf2910954f 100644
--- a/src/compiler/glsl/ast_to_hir.cpp
+++ b/src/compiler/glsl/ast_to_hir.cpp
@@ -6248,7 +6248,8 @@ ast_jump_statement::hir(exec_list *instructions,
  if (state->has_420pack()) {
 if 
(!apply_implicit_conversion(state->current_function->return_type,

-  ret, state)) {
+  ret, state)
+   || (ret->type != 
state->current_function->return_type)) {

    _mesa_glsl_error(& loc, state,
 "could not implicitly convert 
return value "

 "to %s, in function `%s'",


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

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

Re: [Mesa-dev] [PATCH] glsl: Fix function return typechecking

[Tapani Pälli]

Hi;

On 2/11/19 6:46 PM, Oscar Blumberg wrote:

apply_implicit_conversion only converts and check base types but we
need actual type equality for function returns, otherwise you can
return a vec2 from a function declared as returning a float.


Do you have some test shader that hits this condition? It seems to me 
that currently we will error out correctly if one tries to return vec2 
from function declared as returning a float.



---
  src/compiler/glsl/ast_to_hir.cpp | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/compiler/glsl/ast_to_hir.cpp b/src/compiler/glsl/ast_to_hir.cpp
index 620153e6a34..6bf2910954f 100644
--- a/src/compiler/glsl/ast_to_hir.cpp
+++ b/src/compiler/glsl/ast_to_hir.cpp
@@ -6248,7 +6248,8 @@ ast_jump_statement::hir(exec_list *instructions,
  
  if (state->has_420pack()) {

 if 
(!apply_implicit_conversion(state->current_function->return_type,
-  ret, state)) {
+  ret, state)
+   || (ret->type != state->current_function->return_type)) {
_mesa_glsl_error(& loc, state,
 "could not implicitly convert return value 
"
 "to %s, in function `%s'",


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

Re: [Mesa-dev] [PATCH] mesa: INVALID_VALUE for wrong type or format in Clear*Buffer*Data

[Tapani Pälli]

On 2/14/19 2:41 PM, Andres Gomez wrote:

On Thu, 2019-02-14 at 14:31 +0200, Tapani Pälli wrote:

LGTM

Reviewed-by: Tapani Pälli 


Thanks for the review, Tapani ☺



On 2/12/19 2:17 PM, Andres Gomez wrote:

Instead of generating a GL_INVALID_ENUM error when the type or format
is incorrect while using glClear{Named}Buffer{Sub}Data, generate
GL_INVALID_VALUE.

  From page 72 (page 94 of the PDF) of the OpenGL 4.6 spec:


Not sure what is the PDF referred there but in the PDF I have
(glspec46.core.pdf) these error values are specified on page 72.


Maybe I should stop writing the actual page in the PDF. I was following
the example of other references from previous commits and different
developers.

It is indeed page 72, as I also wrote.

What I mean is that, before the numbering starts in the document, there
are still another 22 pages so, basically, "page 1", in the PDF, is page
23.



Right yeah ... not sure if it brings real value but for consistency why 
not :)


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

Re: [Mesa-dev] [PATCH] mesa: INVALID_VALUE for wrong type or format in Clear*Buffer*Data

[Tapani Pälli]

LGTM

Reviewed-by: Tapani Pälli 

On 2/12/19 2:17 PM, Andres Gomez wrote:

Instead of generating a GL_INVALID_ENUM error when the type or format
is incorrect while using glClear{Named}Buffer{Sub}Data, generate
GL_INVALID_VALUE.

 From page 72 (page 94 of the PDF) of the OpenGL 4.6 spec:


Not sure what is the PDF referred there but in the PDF I have 
(glspec46.core.pdf) these error values are specified on page 72.



   " An INVALID_VALUE error is generated if type is not one of the
 types in table 8.2.

 An INVALID_VALUE error is generated if format is not one of the
 formats in table 8.3."

Fixes the following test:
KHR-GL45.direct_state_access.buffers_errors

Cc: Pi Tabred 
Cc: Brian Paul 
Signed-off-by: Andres Gomez 
---
  src/mesa/main/bufferobj.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index 534326858bb..25b47ddab66 100644
--- a/src/mesa/main/bufferobj.c
+++ b/src/mesa/main/bufferobj.c
@@ -346,7 +346,7 @@ buffer_object_subdata_range_good(struct gl_context *ctx,
  
  /**

   * Test the format and type parameters and set the GL error code for
- * \c glClearBufferData and \c glClearBufferSubData.
+ * \c glClear{Named}Buffer{Sub}Data.
   *
   * \param ctx GL context.
   * \param internalformat  Format to which the data is to be converted.
@@ -356,7 +356,7 @@ buffer_object_subdata_range_good(struct gl_context *ctx,
   * \return   If internalformat, format and type are legal the mesa_format
   *   corresponding to internalformat, otherwise MESA_FORMAT_NONE.
   *
- * \sa glClearBufferData and glClearBufferSubData
+ * \sa glClear{Named}Buffer{Sub}Data
   */
  static mesa_format
  validate_clear_buffer_format(struct gl_context *ctx,
@@ -386,14 +386,14 @@ validate_clear_buffer_format(struct gl_context *ctx,
 }
  
 if (!_mesa_is_color_format(format)) {

-  _mesa_error(ctx, GL_INVALID_ENUM,
+  _mesa_error(ctx, GL_INVALID_VALUE,
"%s(format is not a color format)", caller);
return MESA_FORMAT_NONE;
 }
  
 errorFormatType = _mesa_error_check_format_and_type(ctx, format, type);

 if (errorFormatType != GL_NO_ERROR) {
-  _mesa_error(ctx, GL_INVALID_ENUM,
+  _mesa_error(ctx, GL_INVALID_VALUE,
"%s(invalid format or type)", caller);
return MESA_FORMAT_NONE;
 }


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

Re: [Mesa-dev] [PATCH 1/3] mesa: add explicit enable for EXT_float_blend, and error condition

[Tapani Pälli]

Patches 1 and 3 are
Reviewed-by: Tapani Pälli 

On 2/13/19 5:40 AM, Ilia Mirkin wrote:

If EXT_float_blend is not supported, error out on blending of FP32
attachments in an ES2 context.

Signed-off-by: Ilia Mirkin 
---
  src/mesa/main/draw_validate.c| 19 +++
  src/mesa/main/extensions_table.h |  2 +-
  src/mesa/main/fbobject.c |  4 
  src/mesa/main/mtypes.h   |  2 ++
  4 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/src/mesa/main/draw_validate.c b/src/mesa/main/draw_validate.c
index b715a27f8b7..779cd1c12c7 100644
--- a/src/mesa/main/draw_validate.c
+++ b/src/mesa/main/draw_validate.c
@@ -304,6 +304,25 @@ check_valid_to_render(struct gl_context *ctx, const char 
*function)
   "%s(tess ctrl shader is missing)", function);
   return false;
}
+
+  /* From GL_EXT_color_buffer_float:
+   *
+   * "Blending applies only if the color buffer has a fixed-point or
+   * or floating-point format. If the color buffer has an integer
+   * format, proceed to the next operation.  Furthermore, an
+   * INVALID_OPERATION error is generated by DrawArrays and the other
+   * drawing commands defined in section 2.8.3 (10.5 in ES 3.1) if
+   * blending is enabled (see below) and any draw buffer has 32-bit
+   * floating-point format components."
+   *
+   * However GL_EXT_float_blend removes this text.
+   */
+  if (!ctx->Extensions.EXT_float_blend &&
+  (ctx->DrawBuffer->_FP32Buffers & ctx->Color.BlendEnabled)) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ "%s(32-bit float output + blending)", function);
+ return false;
+  }
break;
  
 case API_OPENGL_CORE:

diff --git a/src/mesa/main/extensions_table.h b/src/mesa/main/extensions_table.h
index 0d6bb452ffa..b0492fed698 100644
--- a/src/mesa/main/extensions_table.h
+++ b/src/mesa/main/extensions_table.h
@@ -226,7 +226,7 @@ EXT(EXT_draw_buffers_indexed, 
ARB_draw_buffers_blend
  EXT(EXT_draw_elements_base_vertex   , ARB_draw_elements_base_vertex   
   ,  x ,  x ,  x , ES2, 2014)
  EXT(EXT_draw_instanced  , ARB_draw_instanced  
   , GLL, GLC,  x ,  x , 2006)
  EXT(EXT_draw_range_elements , dummy_true  
   , GLL,  x ,  x ,  x , 1997)
-EXT(EXT_float_blend , dummy_true   
  ,  x ,  x ,  x ,  30, 2015)
+EXT(EXT_float_blend , EXT_float_blend  
  ,  x ,  x ,  x ,  30, 2015)
  EXT(EXT_fog_coord   , dummy_true  
   , GLL,  x ,  x ,  x , 1999)
  EXT(EXT_frag_depth  , dummy_true  
   ,  x ,  x ,  x , ES2, 2010)
  EXT(EXT_framebuffer_blit, dummy_true  
   , GLL, GLC,  x ,  x , 2005)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 87c33be7854..21e3496593c 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -1004,6 +1004,7 @@ _mesa_test_framebuffer_completeness(struct gl_context 
*ctx,
 fb->_HasAttachments = true;
 fb->_IntegerBuffers = 0;
 fb->_RGBBuffers = 0;
+   fb->_FP32Buffers = 0;
  
 /* Start at -2 to more easily loop over all attachment points.

  *  -2: depth buffer
@@ -1153,6 +1154,9 @@ _mesa_test_framebuffer_completeness(struct gl_context 
*ctx,
   if (f == GL_RGB)
  fb->_RGBBuffers |= (1 << i);
  
+ if (type == GL_FLOAT && _mesa_get_format_max_bits(attFormat) > 16)

+fb->_FP32Buffers |= (1 << i);
+
   fb->_AllColorBuffersFixedPoint =
  fb->_AllColorBuffersFixedPoint &&
  (type == GL_UNSIGNED_NORMALIZED || type == GL_SIGNED_NORMALIZED);
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index dda96cd2f19..ca00de7dc63 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -3506,6 +3506,7 @@ struct gl_framebuffer
  
 GLbitfield _IntegerBuffers;  /**< Which color buffers are integer valued */

 GLbitfield _RGBBuffers;  /**< Which color buffers have baseformat == RGB */
+   GLbitfield _FP32Buffers; /**< Which color buffers are FP32 */
  
 /* ARB_color_buffer_float */

 GLboolean _AllColorBuffersFixedPoint; /* no integer, no float */
@@ -4248,6 +4249,7 @@ struct gl_extensions
 GLboolean EXT_depth_bounds_test;
 GLboolean EXT_disjoint_timer_query;
 GLboolean EXT_draw_buffers2;
+   GLboolean EXT_float_blend;
 GLboolean EXT_framebuffer_multisample;
 GLboolean EXT_framebuffer_multisample_blit_scaled;
 GLboolean EXT_framebuffer_sRGB;


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

Re: [Mesa-dev] 10-bit fbconfigs break most video players using VAAPI+GLX

[Tapani Pälli]

On 2/8/19 11:39 AM, Michel Dänzer wrote:

On 2019-02-08 10:30 a.m., Tapani Pälli wrote:

On 2/6/19 7:40 PM, Michel Dänzer wrote:

On 2019-02-06 12:55 p.m., Tapani Pälli wrote:

On 2/6/19 1:16 PM, Michel Dänzer wrote:

On 2019-02-05 11:30 p.m., Marek Olšák wrote:

Hi,

Video players request fbconfigs with these attributes:
GLX_RED_SIZE = 8
GLX_GREEN_SIZE = 8
GLX_BLUE_SIZE = 8
GLX_ALPHA_SIZE = 0

Note that the values specify MINIMUM required component sizes, not
exact
sizes. 10-10-10-2 satisfies the requirement and therefore
glXChooseFBConfig
returns it first. Then video players choose the first config.

There are many video players that have this issue. I guess they
copied the
same code from each other.

If we expose 10-bit or 16-bit formats, a lot of software will be
broken.
Any ideas how to get out of this rabbit hole?

My suggestion is to change the behavior of glXChooseFBConfig to return
8-8-8 or 8-8-8-8 first if they satisfy the attributes and ignore the
spec.


Deliberately violating the spec and diverging from other GL(X)
implementations sounds like a bad idea to me.

We should help getting broken code fixed by identifying it and making
suggestions.


For code using glXChooseFBConfig, unless I'm missing something, a
water-tight way to get a config which exactly matches a specific format
is to specify all of GLX_RED/GREEN/BLUE/ALPHA_SIZE corresponding to
each
component's size, and GLX_BUFFER_SIZE corresponding to the sum of all
sizes. The former and the latter have opposing sort orders, so only a
single combination of R/G/B/A sizes should match all five of them.



This is the main reason why 1010102 is still disabled in i965, there are
still issues, even with ubuntu 18.10. It looks like gnome-shell version
in 18.10 is too old (does not have the 'fix' which was essentially to
disable 1010102),


gnome-shell is a different case though, and AFAIK it's only ever been
broken if Xorg runs at depth 30.



Xorg 1.20 seems to work ok with DefaultDepth 30 though.


With no 10/10/10/x FBConfigs? I don't get any depth 30 GLX visual in
that case either, so no compositing manager using OpenGL can work.
glxgears works, but only via automatic compositing I suspect.


Hmm I'm not sure I follow you here but I got gnome-shell compositor
running when setting DefaultDepth to 30 and it still had the bug where
picking the objects (like selecting a window) did not work, rendering
was looking OK though


Yeah, as I wrote that's a different issue from what this thread is about.


Sure, that can be discussed separately. I just wanted to note this as a 
working desktop with wide color support would be one nice goal to have 
and there has been requests to get this working. Apparently using 
modesetting driver and compton compositor is the safest path. I've CC'd 
Mario who has knowledge on working combinations.





and there were 1010102 visuals available in glxinfo.


So does i965 expose 1010102 configs when the X server runs at depth 30?
Or did you test with another driver?


I tested this with i965 and setting allow_rgb10_configs to true. Having 
said that, currently I cannot seem to be able to launch X with '--depth 
30' anymore, I don't know what did I change but will try to get it back 
again :/



I was thinking only exposing 1010102 configs (by default) when the X
server runs at depth 30 might be a solution, but I wonder if that might
affect some CTS/piglit tests or apps making use of those configs.


Yes, this seems like possible solution.

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

Re: [Mesa-dev] 10-bit fbconfigs break most video players using VAAPI+GLX

[Tapani Pälli]

On 2/6/19 7:40 PM, Michel Dänzer wrote:

On 2019-02-06 12:55 p.m., Tapani Pälli wrote:

On 2/6/19 1:16 PM, Michel Dänzer wrote:

On 2019-02-05 11:30 p.m., Marek Olšák wrote:

Hi,

Video players request fbconfigs with these attributes:
GLX_RED_SIZE = 8
GLX_GREEN_SIZE = 8
GLX_BLUE_SIZE = 8
GLX_ALPHA_SIZE = 0

Note that the values specify MINIMUM required component sizes, not exact
sizes. 10-10-10-2 satisfies the requirement and therefore
glXChooseFBConfig
returns it first. Then video players choose the first config.

There are many video players that have this issue. I guess they
copied the
same code from each other.

If we expose 10-bit or 16-bit formats, a lot of software will be broken.
Any ideas how to get out of this rabbit hole?

My suggestion is to change the behavior of glXChooseFBConfig to return
8-8-8 or 8-8-8-8 first if they satisfy the attributes and ignore the
spec.


Deliberately violating the spec and diverging from other GL(X)
implementations sounds like a bad idea to me.

We should help getting broken code fixed by identifying it and making
suggestions.


For code using glXChooseFBConfig, unless I'm missing something, a
water-tight way to get a config which exactly matches a specific format
is to specify all of GLX_RED/GREEN/BLUE/ALPHA_SIZE corresponding to each
component's size, and GLX_BUFFER_SIZE corresponding to the sum of all
sizes. The former and the latter have opposing sort orders, so only a
single combination of R/G/B/A sizes should match all five of them.



This is the main reason why 1010102 is still disabled in i965, there are
still issues, even with ubuntu 18.10. It looks like gnome-shell version
in 18.10 is too old (does not have the 'fix' which was essentially to
disable 1010102),


gnome-shell is a different case though, and AFAIK it's only ever been
broken if Xorg runs at depth 30.



Xorg 1.20 seems to work ok with DefaultDepth 30 though.


With no 10/10/10/x FBConfigs? I don't get any depth 30 GLX visual in
that case either, so no compositing manager using OpenGL can work.
glxgears works, but only via automatic compositing I suspect.


Hmm I'm not sure I follow you here but I got gnome-shell compositor 
running when setting DefaultDepth to 30 and it still had the bug where 
picking the objects (like selecting a window) did not work, rendering 
was looking OK though and there were 1010102 visuals available in 
glxinfo. I did not run any tests to actually utilize those visuals 
myself though.






I guess one way forward would be to expose 1010102 but start
listing all problematic apps with 'allow_rgb10_configs=false' to drirc.


Then they would probably never get fixed anyway.




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

Re: [Mesa-dev] 10-bit fbconfigs break most video players using VAAPI+GLX

[Tapani Pälli]

On 2/6/19 1:16 PM, Michel Dänzer wrote:

On 2019-02-05 11:30 p.m., Marek Olšák wrote:

Hi,

Video players request fbconfigs with these attributes:
GLX_RED_SIZE = 8
GLX_GREEN_SIZE = 8
GLX_BLUE_SIZE = 8
GLX_ALPHA_SIZE = 0

Note that the values specify MINIMUM required component sizes, not exact
sizes. 10-10-10-2 satisfies the requirement and therefore glXChooseFBConfig
returns it first. Then video players choose the first config.

There are many video players that have this issue. I guess they copied the
same code from each other.

If we expose 10-bit or 16-bit formats, a lot of software will be broken.
Any ideas how to get out of this rabbit hole?

My suggestion is to change the behavior of glXChooseFBConfig to return
8-8-8 or 8-8-8-8 first if they satisfy the attributes and ignore the spec.


Deliberately violating the spec and diverging from other GL(X)
implementations sounds like a bad idea to me.

We should help getting broken code fixed by identifying it and making
suggestions.


For code using glXChooseFBConfig, unless I'm missing something, a
water-tight way to get a config which exactly matches a specific format
is to specify all of GLX_RED/GREEN/BLUE/ALPHA_SIZE corresponding to each
component's size, and GLX_BUFFER_SIZE corresponding to the sum of all
sizes. The former and the latter have opposing sort orders, so only a
single combination of R/G/B/A sizes should match all five of them.



This is the main reason why 1010102 is still disabled in i965, there are 
still issues, even with ubuntu 18.10. It looks like gnome-shell version 
in 18.10 is too old (does not have the 'fix' which was essentially to 
disable 1010102), Xorg 1.20 seems to work ok with DefaultDepth 30 
though. I guess one way forward would be to expose 1010102 but start 
listing all problematic apps with 'allow_rgb10_configs=false' to drirc.


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

Re: [Mesa-dev] last call for autotools

[Tapani Pälli]

On 2/5/19 8:20 PM, Marek Olšák wrote:
PKG_CONFIG_PATH still seems to be forgotten by meson. Is there an 
alternative?


Maybe this can be worked out since at least for me it seems to complain 
that 'different PKG_CONFIG_PATH' was used when configuring last time:


WARNING: PKG_CONFIG_PATH has changed between invocations from "" to 
"/home/tpalli/mesa/lib64/pkgconfig/"


so it is stored .. somewhere.



Thanks,
Marek

On Sun, Dec 23, 2018 at 9:32 PM Ilia Mirkin > wrote:


On Wed, Dec 19, 2018 at 1:30 PM Dylan Baker mailto:dy...@pnwbakers.com>> wrote:
 >
 > Quoting Nicolai Hähnle (2018-12-18 09:37:43)
 > > On 17.12.18 23:46, Dylan Baker wrote:
 > > > Quoting Marek Olšák (2018-12-17 12:25:29)
 > > >> On Mon, Dec 17, 2018 at 1:18 PM Eric Anholt mailto:e...@anholt.net>> wrote:
 > > >>
 > > >>      Eero Tamminen mailto:eero.t.tammi...@intel.com>> writes:
 > > >>
 > > >>      > Hi,
 > > >>      >
 > > >>      > On 17.12.2018 8.08, Marek Olšák wrote:
 > > >>      > [...]
 > > >>      >> I think one of the serious usability issues is that
environment
 > > >>      >> variables such as CFLAGS, CXXFLAGS, LDFLAGS, and
PKG_CONFIG_PATH are not
 > > >>      >> saved by meson for future reconfigures.
 > > >>      >
 > > >>      > I don't know what Meson is supposed to do, but to me
that would be
 > > >>      > a bug in a build tool.
 > > >>      >
 > > >>      > Re-configure is supposed to adapt SW to the changes
in the build
 > > >>      > environment, and environment variables are part of
that (along with
 > > >>      > command line options and SW installed to to the
system).  Build
 > > >>      > configure tool deciding to "remember" some of those
things instead
 > > >>      > of checking the new situation, seems like a great
opportunity for
 > > >>      > confusion.
 > > >>
 > > >>      A user-triggered reconfigure, sure.  Recapture env vars
then.  But "git
 > > >>      pull; ninja -C build" losing track of the configuration
state is broken.
 > > >>      We don't have to specify all of your meson
-Doption=state configuration
 > > >>      on every build, why should you need to specify your
PKG_CONFIG_PATH
 > > >>      configure options on every build?
 > > >>
 > > >>
 > > >> Thanks, Eric.
 > > >>
 > > >> Yes, meson behaves such that users have to set all
environment variables for
 > > >> every "ninja" command that might reconfigure.
 > > >>
 > > >> I see 2 solutions:
 > > >> 1) meson needs to remember the relevant env vars
 > > >> 2) meson should FAIL to configure if any of the env vars are
set (if it wants
 > > >> to ignore them)
 > > >>
 > > >> Marek
 > > >
 > > > Meson does remember the *_FLAGS variables. Those are
translated on configure
 > > > into meson's internal ${lang}_args and ${lang}_link args. It
does look like
 > > > those aren't remembered when --wipe is called though, I filed
a bug for that:
 > > > https://github.com/mesonbuild/meson/issues/4650
 > >
 > > I ran into this same problem and noticed that Meson is already
able to
 > > *warn* about such changes.
 > >
 > > It should either ignore the changes, or better yet, fail.
 > >
 > > (Or even better: ignore environment variables entirely; IMO
sourcing the
 > > environment implicitly in a build system with an explicit
configure is
 > > just a broken design that was unfortunately inherited from
plain make
 > > without really considering the UI implications.)
 >
 > I agree with this, as do most of the upstream meson developers.
So do the
 > autotools developers, who recommend passing CFLAGS (and friends)
as arguments
 > instead of as env variables:
 >
 > ./configure CFLAGS='-march=native -03' LDFLAGS='-O3' --enable-foo
 >
 > meson supports this using:
 >
 > meson -Dc_args='-march-native' -Dc_link_args='-O3' -Dfoo=true
 >
 > Meson basically inherited this from autotools, and in hindsight
we shouldn't
 > have.
 >
 > I'm going to do 3 things I think:
 > - Update our documentation to strongly recommend -Dc_args and not
CLFAGS
 > - Push for meson to warn about using environment variables and
recommend command
 >   line options.
 > - Push for meson to remove CFLAGS and friends support:
 > https://github.com/mesonbuild/meson/issues/4664

FWIW when I was talking about env vars, I was very much referring to

./configure CFLAGS=..., not the CFLAGS=... ./configure variant --
that's fraught with peril.

An especially important one to be able to bake in is
PKG_CONFIG_PATH. Having support for just doing it rather than
knowing what the mapping to meson is would be rather preferable -- e.g.

meson 

Re: [Mesa-dev] [PATCH] glsl: use remap location when serialising uniform program resource data

[Tapani Pälli]

On 1/28/19 8:15 AM, Timothy Arceri wrote:

This allows us to avoid expensive string compares since we already have
a map to the pointers.

These compares were taking ~30 seconds for a single shader compile
in Godot due to it using 64,000+ uniforms.


wow .. and I thought Borderlands was using too many (IIRC had something 
like 12000)


Reviewed-by: Tapani Pälli 


Fixes: c4cff5f40254 ("glsl: add basic support for resource list to shader 
cache")

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109229
---
  src/compiler/glsl/serialize.cpp | 33 ++---
  1 file changed, 26 insertions(+), 7 deletions(-)

diff --git a/src/compiler/glsl/serialize.cpp b/src/compiler/glsl/serialize.cpp
index 26d8ec4b75b..fdd99ec59da 100644
--- a/src/compiler/glsl/serialize.cpp
+++ b/src/compiler/glsl/serialize.cpp
@@ -764,6 +764,12 @@ get_shader_var_and_pointer_sizes(size_t *s_var_size, 
size_t *s_var_ptrs,
sizeof(var->name);
  }
  
+enum uniform_type

+{
+   uniform_remapped,
+   uniform_not_remapped
+};
+
  static void
  write_program_resource_data(struct blob *metadata,
  struct gl_shader_program *prog,
@@ -816,12 +822,19 @@ write_program_resource_data(struct blob *metadata,
 case GL_TESS_CONTROL_SUBROUTINE_UNIFORM:
 case GL_TESS_EVALUATION_SUBROUTINE_UNIFORM:
 case GL_UNIFORM:
-  for (unsigned i = 0; i < prog->data->NumUniformStorage; i++) {
- if (strcmp(((gl_uniform_storage *)res->Data)->name,
-prog->data->UniformStorage[i].name) == 0) {
-blob_write_uint32(metadata, i);
-break;
+  if (((gl_uniform_storage *)res->Data)->builtin ||
+  res->Type != GL_UNIFORM) {
+ blob_write_uint32(metadata, uniform_not_remapped);
+ for (unsigned i = 0; i < prog->data->NumUniformStorage; i++) {
+if (strcmp(((gl_uniform_storage *)res->Data)->name,
+   prog->data->UniformStorage[i].name) == 0) {
+   blob_write_uint32(metadata, i);
+   break;
+}
   }
+  } else {
+ blob_write_uint32(metadata, uniform_remapped);
+ blob_write_uint32(metadata, ((gl_uniform_storage 
*)res->Data)->remap_location);
}
break;
 case GL_ATOMIC_COUNTER_BUFFER:
@@ -906,9 +919,15 @@ read_program_resource_data(struct blob_reader *metadata,
 case GL_COMPUTE_SUBROUTINE_UNIFORM:
 case GL_TESS_CONTROL_SUBROUTINE_UNIFORM:
 case GL_TESS_EVALUATION_SUBROUTINE_UNIFORM:
-   case GL_UNIFORM:
-  res->Data = >data->UniformStorage[blob_read_uint32(metadata)];
+   case GL_UNIFORM: {
+  enum uniform_type type = (enum uniform_type) blob_read_uint32(metadata);
+  if (type == uniform_not_remapped) {
+ res->Data = >data->UniformStorage[blob_read_uint32(metadata)];
+  } else {
+ res->Data = prog->UniformRemapTable[blob_read_uint32(metadata)];
+  }
break;
+   }
 case GL_ATOMIC_COUNTER_BUFFER:
res->Data = >data->AtomicBuffers[blob_read_uint32(metadata)];
break;


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

Re: [Mesa-dev] Thoughts on fp64 for GLES?

[Tapani Pälli]

On 1/25/19 8:25 AM, Stéphane Marchesin wrote:

On Thu, Jan 24, 2019 at 10:17 PM Tapani Pälli  wrote:


Hi;

On 1/25/19 4:57 AM, Stéphane Marchesin wrote:

Hi,

We'd like to expose fp64 functionality on Chrome OS where we only have
GLES. It seems like a simple approach is to enable this extension for
GLES:
https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_gpu_shader_fp64.txt

Anyone knows if what's the right thing to do? It seems to me that the
extension might just work on GLES without any changes, but I could be
missing something.


Sorry for not responding the the actual question but could you share the
usecase? Back when this was enabled for HW that supports it we did not
find applications (just some fractal shadertoy things), would be
interesting to know how it is being used.


Yes, it's for running virgl on top of GLES. To emulate fp64 in GL on
the guest side, we need fp64 on the host...



OK thanks. One thing that comes to mind (specific to GLSL ES) is that 
should double type have precision qualifier support? Maybe some specific 
rules what happens when expression has both floats and doubles with some 
precision qualifiers ... there might be a lot more things to this but 
this is what comes first to my mind.


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

Re: [Mesa-dev] Thoughts on fp64 for GLES?

[Tapani Pälli]

Hi;

On 1/25/19 4:57 AM, Stéphane Marchesin wrote:

Hi,

We'd like to expose fp64 functionality on Chrome OS where we only have
GLES. It seems like a simple approach is to enable this extension for
GLES:
https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_gpu_shader_fp64.txt

Anyone knows if what's the right thing to do? It seems to me that the
extension might just work on GLES without any changes, but I could be
missing something.


Sorry for not responding the the actual question but could you share the 
usecase? Back when this was enabled for HW that supports it we did not 
find applications (just some fractal shadertoy things), would be 
interesting to know how it is being used.


Thanks;

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

Re: [Mesa-dev] [PATCH] anv: Only parse pImmutableSamplers if the descriptor has samplers

[Tapani Pälli]

Reviewed-by: Tapani Pälli 

On 1/19/19 9:04 PM, Jason Ekstrand wrote:

---
  src/intel/vulkan/anv_descriptor_set.c | 43 +++
  1 file changed, 31 insertions(+), 12 deletions(-)

diff --git a/src/intel/vulkan/anv_descriptor_set.c 
b/src/intel/vulkan/anv_descriptor_set.c
index a308fbf8540..a4e466cf3dd 100644
--- a/src/intel/vulkan/anv_descriptor_set.c
+++ b/src/intel/vulkan/anv_descriptor_set.c
@@ -94,7 +94,22 @@ VkResult anv_CreateDescriptorSetLayout(
 uint32_t immutable_sampler_count = 0;
 for (uint32_t j = 0; j < pCreateInfo->bindingCount; j++) {
max_binding = MAX2(max_binding, pCreateInfo->pBindings[j].binding);
-  if (pCreateInfo->pBindings[j].pImmutableSamplers)
+
+  /* From the Vulkan 1.1.97 spec for VkDescriptorSetLayoutBinding:
+   *
+   *"If descriptorType specifies a VK_DESCRIPTOR_TYPE_SAMPLER or
+   *VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER type descriptor, then
+   *pImmutableSamplers can be used to initialize a set of immutable
+   *samplers. [...]  If descriptorType is not one of these descriptor
+   *types, then pImmutableSamplers is ignored.
+   *
+   * We need to be careful here and only parse pImmutableSamplers if we
+   * have one of the right descriptor types.
+   */
+  VkDescriptorType desc_type = pCreateInfo->pBindings[j].descriptorType;
+  if ((desc_type == VK_DESCRIPTOR_TYPE_SAMPLER ||
+   desc_type == VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER) &&
+  pCreateInfo->pBindings[j].pImmutableSamplers)
   immutable_sampler_count += pCreateInfo->pBindings[j].descriptorCount;
 }
  
@@ -153,6 +168,12 @@ VkResult anv_CreateDescriptorSetLayout(

if (binding == NULL)
   continue;
  
+  /* We temporarily stashed the pointer to the binding in the

+   * immutable_samplers pointer.  Now that we've pulled it back out
+   * again, we reset immutable_samplers to NULL.
+   */
+  set_layout->binding[b].immutable_samplers = NULL;
+
if (binding->descriptorCount == 0)
   continue;
  
@@ -170,6 +191,15 @@ VkResult anv_CreateDescriptorSetLayout(

  set_layout->binding[b].stage[s].sampler_index = sampler_count[s];
  sampler_count[s] += binding->descriptorCount;
   }
+
+ if (binding->pImmutableSamplers) {
+set_layout->binding[b].immutable_samplers = samplers;
+samplers += binding->descriptorCount;
+
+for (uint32_t i = 0; i < binding->descriptorCount; i++)
+   set_layout->binding[b].immutable_samplers[i] =
+  anv_sampler_from_handle(binding->pImmutableSamplers[i]);
+ }
   break;
default:
   break;
@@ -221,17 +251,6 @@ VkResult anv_CreateDescriptorSetLayout(
   break;
}
  
-  if (binding->pImmutableSamplers) {

- set_layout->binding[b].immutable_samplers = samplers;
- samplers += binding->descriptorCount;
-
- for (uint32_t i = 0; i < binding->descriptorCount; i++)
-set_layout->binding[b].immutable_samplers[i] =
-   anv_sampler_from_handle(binding->pImmutableSamplers[i]);
-  } else {
- set_layout->binding[b].immutable_samplers = NULL;
-  }
-
set_layout->shader_stages |= binding->stageFlags;
 }
  


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

Re: [Mesa-dev] [PATCH] relnotes: Add newly added Vulkan extensions

[Tapani Pälli]

Acked-by: Tapani Pälli 

On 1/19/19 9:11 PM, Jason Ekstrand wrote:

Both the Intel and RADV people have been really bad about adding things
to the release notes.  We should start actually paying attention.
---
  docs/relnotes/19.0.0.html | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/docs/relnotes/19.0.0.html b/docs/relnotes/19.0.0.html
index 10c883f398f..1b4edd7ce76 100644
--- a/docs/relnotes/19.0.0.html
+++ b/docs/relnotes/19.0.0.html
@@ -48,6 +48,13 @@ TBD.
  GL_OES_texture_view on drivers supporting texture views (ES 
extension).
  GL_NV_shader_atomic_float on nvc0 (Fermi/Kepler only).
  Shader-based software implementations of GL_ARB_gpu_shader_fp64, 
GL_ARB_gpu_shader_int64, GL_ARB_vertex_attrib_64bit, and GL_ARB_shader_ballot on 
i965.
+VK_ANDROID_external_memory_android_hardware_buffer on Intel
+Fixed and re-exposed VK_EXT_pci_bus_info on Intel and RADV
+VK_EXT_scalar_block_layout on Intel and RADV
+VK_KHR_depth_stencil_resolve on Intel
+VK_KHR_draw_indirect_count on Intel
+VK_EXT_conditional_rendering on Intel
+VK_EXT_memory_budget on RADV
  
  
  Bug fixes



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

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Tapani Pälli]

On 1/17/19 12:32 PM, apinheiro wrote:


On 17/1/19 9:39, Kenneth Graunke wrote:

On Wednesday, January 16, 2019 11:38:05 PM PST Erik Faye-Lund wrote:

On Fri, 2019-01-11 at 10:57 -0600, Jason Ekstrand wrote:

All,

The mesa project has now hit 100 merge requests (36 are still open).
I (and I'm sure others) would be curious to hear people's initial
thoughts on the process.  What's working well?  What's not working?
Is it total fail and should we go back to mailing lists?


So, overall I think it works pretty well. I have some things I think
maybe we could do better, some of which has already been pointed out:

1. New MRs should probably get their cover-letter automatically sent to
the mailing list for incrased visibility.

2. Perhaps we should ban sending MRs from the main mesa repo? With
gitlab, it's trivial to make your own fork, and you can delegate
permissions to other users for collaborators. I don't think there's any
reason to clutter up the main mesa repo with all kinds of branches. But
it seems some people send their MRs from the main-repo anyway. Perhaps
we should document that this isn't how to send MRs?

I agree, I would much rather see MRs sent from personal forks.
That's what I've been doing, and it works well.  If you see people
doing that, feel free to say something - I assume they just don't
realize they can do that.



As one of the people doing it wrongly (using a branch of the main repo, 
instead of a personal fork): yes please, let's document that, as I was 
unaware that was a problem.


What Im not sure if it is possible to update a existing MR in order to 
use a different repo/branch. If that is not possible, should I close my 
MR and reopen it with a fork?




I guess it's not a big deal (?) if we just take care of proper cleanup 
(can be done via checkbox while merging). For me this happened by 
accident (with recent ahw-fix branch), I just happen to have remote 
names 'gitlab' and 'gitlab-tpalli' so it got pushed to the wrong one.


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

Re: [Mesa-dev] [PATCH] nir/lower_tex: Fix the channel ordering during conversion of AYUV images

[Tapani Pälli]

On 1/15/19 9:45 AM, Tapani Pälli wrote:



On 1/15/19 4:34 AM, Lionel Landwerlin wrote:
When writing this I used this page to figure the bytes' ordering : 
https://docs.microsoft.com/en-us/windows/desktop/medfound/recommended-8-bit-yuv-formats-for-video-rendering#ayuv 


Of course endianess confuses everything :(

sunxi seems to support AYUV & VUYA : 
https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/include/video/sunxi_display2.h#L40 



Finally this patch (and its gstreamer comments) confuses me even more 
: https://patchwork.freedesktop.org/patch/255529/


I really don't know what's right or wrong here...


IMO order 1230 seems wrong to me. Vivek, was the order chosen just 
because vivid driver outputs that or is it based on anything else, like 
some specification or other information?


CC also Stan who is enabling the format for SNA




-
Lionel

On 15/01/2019 00:49, Vivek Kasireddy wrote:

From: "Kasireddy, Vivek" 

The channel ordering should be 1230 instead of 2103.

While displaying the packed YUV buffers generated by the Vivid (Virtual
Video) driver on Weston, it was observed that AYUV images were not
displayed correctly. Changing the ordering to 1230 makes AYUV buffers
display as expected.

CC: Lionel Landwerlin 
CC: Tapani Palli 
Signed-off-by: Vivek Kasireddy 
---
  src/compiler/nir/nir_lower_tex.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/compiler/nir/nir_lower_tex.c 
b/src/compiler/nir/nir_lower_tex.c

index a618b86b34c..7058c54f17c 100644
--- a/src/compiler/nir/nir_lower_tex.c
+++ b/src/compiler/nir/nir_lower_tex.c
@@ -434,10 +434,10 @@ lower_ayuv_external(nir_builder *b, 
nir_tex_instr *tex)

    nir_ssa_def *ayuv = sample_plane(b, tex, 0);
    convert_yuv_to_rgb(b, tex,
- nir_channel(b, ayuv, 2),
   nir_channel(b, ayuv, 1),
- nir_channel(b, ayuv, 0),
- nir_channel(b, ayuv, 3));
+ nir_channel(b, ayuv, 2),
+ nir_channel(b, ayuv, 3),
+ nir_channel(b, ayuv, 0));
  }
  /*




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

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

Re: [Mesa-dev] [PATCH] nir/lower_tex: Fix the channel ordering during conversion of AYUV images

[Tapani Pälli]

On 1/15/19 4:34 AM, Lionel Landwerlin wrote:
When writing this I used this page to figure the bytes' ordering : 
https://docs.microsoft.com/en-us/windows/desktop/medfound/recommended-8-bit-yuv-formats-for-video-rendering#ayuv 


Of course endianess confuses everything :(

sunxi seems to support AYUV & VUYA : 
https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/include/video/sunxi_display2.h#L40 



Finally this patch (and its gstreamer comments) confuses me even more : 
https://patchwork.freedesktop.org/patch/255529/


I really don't know what's right or wrong here...


IMO order 1230 seems wrong to me. Vivek, was the order chosen just 
because vivid driver outputs that or is it based on anything else, like 
some specification or other information?




-
Lionel

On 15/01/2019 00:49, Vivek Kasireddy wrote:

From: "Kasireddy, Vivek" 

The channel ordering should be 1230 instead of 2103.

While displaying the packed YUV buffers generated by the Vivid (Virtual
Video) driver on Weston, it was observed that AYUV images were not
displayed correctly. Changing the ordering to 1230 makes AYUV buffers
display as expected.

CC: Lionel Landwerlin 
CC: Tapani Palli 
Signed-off-by: Vivek Kasireddy 
---
  src/compiler/nir/nir_lower_tex.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/compiler/nir/nir_lower_tex.c 
b/src/compiler/nir/nir_lower_tex.c

index a618b86b34c..7058c54f17c 100644
--- a/src/compiler/nir/nir_lower_tex.c
+++ b/src/compiler/nir/nir_lower_tex.c
@@ -434,10 +434,10 @@ lower_ayuv_external(nir_builder *b, 
nir_tex_instr *tex)

    nir_ssa_def *ayuv = sample_plane(b, tex, 0);
    convert_yuv_to_rgb(b, tex,
- nir_channel(b, ayuv, 2),
   nir_channel(b, ayuv, 1),
- nir_channel(b, ayuv, 0),
- nir_channel(b, ayuv, 3));
+ nir_channel(b, ayuv, 2),
+ nir_channel(b, ayuv, 3),
+ nir_channel(b, ayuv, 0));
  }
  /*




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

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Tapani Pälli]

On 1/14/19 2:36 PM, Daniel Stone wrote:

Hi,

On Fri, 11 Jan 2019 at 17:05, Jason Ekstrand  wrote:

  5. There's no way with gitlab for Reviewed-by tags to get automatically 
applied as part of the merging process.  This makes merging a bit more manual 
than it needs to be but is really no worse than it was before.


I'm still on the side of not seeing the value in them. Most of the
time when I go to pursue someone who reviewed a commit, I'll go to see
what came up in review anyway. Maybe someone had the same comment
which was found to be not applicable or otherwise explained away.
Reviewed-by and Acked-by are also pretty lossy anyway, and freeform
text descriptors in a comment can much better capture the intent (e.g.
'I'm strongly OK with the driver changes and weakly OK with the core
changes as it's not really my area of expertise').

In other projects, we looked for ways to apply the tags and ended up
concluding that they didn't bring enough value to make it worthwhile.
I don't know if that holds for Mesa, but it would be better to start
with an actual problem statement - what value does R-b bring and how?
- then look at ways to solve that problem, rather than just very
directly finding a way to insert that literal text string into every
commit message.


IMO it brings some 'shared responsibility' for correctness of the patch 
and quickly accessible information on who were looking at the change. So 
ideally later when filing bug against commit/series there would be more 
people than just the committer that should take a look at the possible 
regressions. At least in my experience people filing bugs tend to often 
also CC the reviewer.



FWIW, if you go to
https://gitlab.freedesktop.org/mesa/mesa/commit/SHA1 then you get a
hyperlink from the web UI which points you to the MR. The API to do
this is pretty straightforward and amenable to piping through jq:
https://docs.gitlab.com/ce/api/commits.html#list-merge-requests-associated-with-a-commit


I guess if we would move issue tracking to gitlab then we could possibly 
automate the CC list generation based on commit?


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

Re: [Mesa-dev] [RFC 1/6] dri: Support 64 bit rgba masks

[Tapani Pälli]

On 1/11/19 5:01 PM, Emil Velikov wrote:

Hi Kevin,

Thanks for that massive undertaking in addressing this.

On 2019/01/04, Kevin Strasser wrote:

The dri core api was written with the assumption that all attribute values
would fit into 32 bits. This limitation means the config handlers can't
accept 64 bpp formats. Reserve 64 bits for rgba masks and add new
attributes that allow access to the upper 32 bits.

Signed-off-by: Kevin Strasser 
---
  include/GL/internal/dri_interface.h |  6 ++-
  src/egl/drivers/dri2/egl_dri2.c | 28 +---
  src/egl/drivers/dri2/egl_dri2.h |  6 +--
  src/egl/drivers/dri2/platform_android.c |  2 +-
  src/egl/drivers/dri2/platform_drm.c | 67 ++---
  src/egl/drivers/dri2/platform_surfaceless.c |  2 +-
  src/egl/drivers/dri2/platform_wayland.c |  2 +-
  src/egl/drivers/dri2/platform_x11.c |  6 +--
  src/gbm/backends/dri/gbm_driint.h   |  8 ++--
  src/glx/glxconfig.h |  2 +-
  src/mesa/drivers/dri/common/utils.c | 16 ++-
  src/mesa/main/mtypes.h  |  2 +-
  12 files changed, 108 insertions(+), 39 deletions(-)


Please split this up a bit. I'm thinking of:
  - dri_interface
  - mesa
  - egl
  - gbm
  - glx - seems sparse on updates, guessting you're followed in laster
patches?


diff --git a/include/GL/internal/dri_interface.h 
b/include/GL/internal/dri_interface.h
index 072f379..c5761c4 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -747,7 +747,11 @@ struct __DRIuseInvalidateExtensionRec {
  #define __DRI_ATTRIB_YINVERTED47
  #define __DRI_ATTRIB_FRAMEBUFFER_SRGB_CAPABLE 48
  #define __DRI_ATTRIB_MUTABLE_RENDER_BUFFER49 /* 
EGL_MUTABLE_RENDER_BUFFER_BIT_KHR */
-#define __DRI_ATTRIB_MAX   50
+#define __DRI_ATTRIB_RED_MASK_HI   50
+#define __DRI_ATTRIB_GREEN_MASK_HI 51
+#define __DRI_ATTRIB_BLUE_MASK_HI  52
+#define __DRI_ATTRIB_ALPHA_MASK_HI 53
+#define __DRI_ATTRIB_MAX   54


Worth adding some defines as below for clarity/consistency sake and
updating the existing code to use them?

#define __DRI_ATTRIB_RED_MASK_LO __DRI_ATTRIB_RED_MASK
...


  
  /* __DRI_ATTRIB_RENDER_TYPE */

  #define __DRI_ATTRIB_RGBA_BIT 0x01
diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 0be9235..d19950d 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -179,7 +179,7 @@ dri2_match_config(const _EGLConfig *conf, const _EGLConfig 
*criteria)
  struct dri2_egl_config *
  dri2_add_config(_EGLDisplay *disp, const __DRIconfig *dri_config, int id,
  EGLint surface_type, const EGLint *attr_list,
-const unsigned int *rgba_masks)
+const unsigned long long int *rgba_masks)

I'm slightly inclided towards uint64_t since it's a little more explicit
and clear. IIRC sizeof(long long) varies across platforms and/or
compilers so uint64_t will avoid all the potential fun ;-)


This was my thinking as well, we use uint64_t in other places. I've gone 
briefly through the series and overall these changes look good to me.




[snip]


+  const __DRIconfig *config = dri2_dpy->driver_configs[i];
+  unsigned long long int red, green, blue, alpha;
+  unsigned int mask_hi = 0, mask_lo;
+
+  dri2_dpy->core->getConfigAttrib(config, __DRI_ATTRIB_RED_MASK_HI,
+  _hi);
+  dri2_dpy->core->getConfigAttrib(config, __DRI_ATTRIB_RED_MASK,
+  _lo);
+  red = (unsigned long long int)mask_hi << 32 | mask_lo;
+
+  dri2_dpy->core->getConfigAttrib(config, __DRI_ATTRIB_GREEN_MASK_HI,
+  _hi);
+  dri2_dpy->core->getConfigAttrib(config, __DRI_ATTRIB_GREEN_MASK,
+  _lo);
+  green = (unsigned long long int)mask_hi << 32 | mask_lo;
+
+  dri2_dpy->core->getConfigAttrib(config, __DRI_ATTRIB_BLUE_MASK_HI,
+  _hi);
+  dri2_dpy->core->getConfigAttrib(config, __DRI_ATTRIB_BLUE_MASK,
+  _lo);
+  blue = (unsigned long long int)mask_hi << 32 | mask_lo;
+
+  dri2_dpy->core->getConfigAttrib(config, __DRI_ATTRIB_ALPHA_MASK_HI,
+  _hi);
+  dri2_dpy->core->getConfigAttrib(config, __DRI_ATTRIB_ALPHA_MASK,
+  _lo);
+  alpha = (unsigned long long int)mask_hi << 32 | mask_lo;
  

Would be great to fold this into a helper since we have it in three
places already.

Speaking of which did you forget to git add the platform_wayland.c hunk?

Note: getConfigAttrib returns 0 (GL_FALSE) on error (think new libEGL,
old i965_dri.so) so we want to handle that in some way.

[snip]


@@ -460,6 +464,14 

Re: [Mesa-dev] [PATCH] nir: fix copy-paste error in nir_lower_constant_initializers

[Tapani Pälli]

Wrote the same patch and it fixes issues for me;
Reviewed-by: Tapani Pälli 

On 1/10/19 1:23 PM, Rhys Perry wrote:

Fixes: 393b59e0772e7bf0426bdf61c740752c4e09dde1
 ('nir: Rework nir_lower_constant_initializers() to handle functions')
---
  src/compiler/nir/nir_lower_constant_initializers.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/compiler/nir/nir_lower_constant_initializers.c 
b/src/compiler/nir/nir_lower_constant_initializers.c
index cbee59b1f30..959d1eabfca 100644
--- a/src/compiler/nir/nir_lower_constant_initializers.c
+++ b/src/compiler/nir/nir_lower_constant_initializers.c
@@ -104,10 +104,10 @@ nir_lower_constant_initializers(nir_shader *shader, 
nir_variable_mode modes)
   impl_progress |= lower_const_initializer(, >outputs);
  
if ((modes & nir_var_private) && function->is_entrypoint)

- impl_progress |= lower_const_initializer(, >outputs);
+ impl_progress |= lower_const_initializer(, >globals);
  
if ((modes & nir_var_system_value) && function->is_entrypoint)

- impl_progress |= lower_const_initializer(, >outputs);
+ impl_progress |= lower_const_initializer(, 
>system_values);
  
if (modes & nir_var_function)

   impl_progress |= lower_const_initializer(, 
>impl->locals);


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

Re: [Mesa-dev] [RFC 0/6] Enable fp16 visuals and fbconfigs

[Tapani Pälli]

On 1/7/19 6:25 PM, Strasser, Kevin wrote:

On 1/7/19 8:44 AM, Tapani Pälli wrote:

On 1/4/19 11:56 PM, Kevin Strasser wrote:

While I have run this series against Piglit, I still need to sort out
test coverage for these formats. If anyone has pointers to existing
tests that would be really helpful.


dEQP (EGL module) has set of 'wide color' tests that also cover
1010102 and fp16.


Having said that, it's not really a 'complete test' but at least something to
start with.


Right, I'm familiar with that test, looks to just check if the config gets
exposed or not. I was hoping to find some tests that were more rigorously
testing 10 bit configs that I would be able to extend for fp16. So far I
haven't found much between piglit and dEQP, but I'm still looking.


It does also a clear test and has reference values for these formats. It 
does not render any other content though so just a basic 'contents are 
sane' test.



Does kernel already support fp16?


I have a series that enables fp16 for ICL+ [1], and Ville has patches that can
support platforms prior to that. I still need to rework my series with the
review feedback I got.. mostly concerned with getting userspace ready before
trying to land that.

Thanks,
Kevin

[1] https://patchwork.freedesktop.org/series/53213/


Nice! I guess we should also try to open up 1010102 again. There were 
couple of issues which might have been fixed. Both issues were happening 
with compositors, rendering bug on Unity (Ubuntu) and another was 
picking bug with Clutter based Gnome-Shell.


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

Re: [Mesa-dev] [PATCH] anv/android: handle storage images in vkGetSwapchainGrallocUsageANDROID

[Tapani Pälli]

On 1/7/19 1:28 PM, Bas Nieuwenhuizen wrote:

On Mon, Jan 7, 2019 at 11:54 AM Tapani Pälli  wrote:




On 1/7/19 11:56 AM, Bas Nieuwenhuizen wrote:

On Wed, Dec 5, 2018 at 1:05 PM Tapani Pälli  wrote:




On 12/5/18 2:00 PM, Bas Nieuwenhuizen wrote:

On Wed, Dec 5, 2018 at 12:51 PM Tapani Pälli  wrote:




On 12/5/18 1:44 PM, Bas Nieuwenhuizen wrote:

On Wed, Dec 5, 2018 at 12:37 PM Tapani Pälli  wrote:




On 12/5/18 1:22 PM, Bas Nieuwenhuizen wrote:

On Wed, Dec 5, 2018 at 12:15 PM Tapani Pälli  wrote:




On 12/5/18 1:01 PM, Bas Nieuwenhuizen wrote:

On Fri, Sep 7, 2018 at 12:54 AM Kevin Strasser  wrote:


Android P and earlier expect that the surface supports storage images, and
so many of the tests fail when the framework checks for that support. The
framework also includes various image format and usage combinations that are
invalid for the hardware.

Drop the STORAGE restriction from the HAL and whitelist a pair of
formats so that existing versions of Android can pass these tests.

Fixes:
 dEQP-VK.wsi.android.*

Signed-off-by: Kevin Strasser 
---
   src/intel/vulkan/anv_android.c | 23 ++-
   1 file changed, 14 insertions(+), 9 deletions(-)

diff --git a/src/intel/vulkan/anv_android.c b/src/intel/vulkan/anv_android.c
index 46c41d5..e2640b8 100644
--- a/src/intel/vulkan/anv_android.c
+++ b/src/intel/vulkan/anv_android.c
@@ -234,7 +234,7 @@ VkResult anv_GetSwapchainGrallocUsageANDROID(
  *grallocUsage = 0;
  intel_logd("%s: format=%d, usage=0x%x", __func__, format, imageUsage);

-   /* WARNING: Android Nougat's libvulkan.so hardcodes the VkImageUsageFlags
+   /* WARNING: Android's libvulkan.so hardcodes the VkImageUsageFlags
   * returned to applications via 
VkSurfaceCapabilitiesKHR::supportedUsageFlags.
   * The relevant code in libvulkan/swapchain.cpp contains this fun 
comment:
   *
@@ -247,7 +247,7 @@ VkResult anv_GetSwapchainGrallocUsageANDROID(
   * dEQP-VK.wsi.android.swapchain.*.image_usage to fail.
   */

-   const VkPhysicalDeviceImageFormatInfo2KHR image_format_info = {
+   VkPhysicalDeviceImageFormatInfo2KHR image_format_info = {


Why remove the const here?


 .sType = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_FORMAT_INFO_2_KHR,
 .format = format,
 .type = VK_IMAGE_TYPE_2D,
@@ -255,6 +255,17 @@ VkResult anv_GetSwapchainGrallocUsageANDROID(
 .usage = imageUsage,
  };

+   /* Android P and earlier doesn't check if the physical device supports a
+* given format and usage combination before calling this function. Omit the
+* storage requirement to make the tests pass.
+*/
+#if ANDROID_API_LEVEL <= 28
+   if (format == VK_FORMAT_R8G8B8A8_SRGB ||
+   format == VK_FORMAT_R5G6B5_UNORM_PACK16) {
+  image_format_info.usage &= ~VK_IMAGE_USAGE_STORAGE_BIT;
+   }
+#endif


I don't think you need this. Per the vulkan spec you can only use an
format + usage combination for a swapchain if it is supported per
ImageFormatProperties, using essentially the same check happening
above. I know CTs has been bad at this, but Vulkan CTS should have
been fixed for a bit now. (I don't think all the fixes are in Android
CTS 9.0_r4 yet, maybe the next release?)


AFAIK the problem here is not about CTS. It's the swapchain
implementation that always requires storage support.


Actually swapchain creation has the following valid usage rule:

"The implied image creation parameters of the swapchain must be
supported as reported by vkGetPhysicalDeviceImageFormatProperties"

So since those formats don't support the STORAGE usage bit, that test
fails and you are not allowed to create a swapchain with those formats
and storage, even if the surface capabiliities expose the STORAGE
usage bit in general.


Right ... this stuff was done because comment in the swapchain setting
the bits seems like maybe it's not thought through:

// TODO(jessehall): I think these are right, but haven't thought hard about
// it. Do we need to query the driver for support of any of these?


That was from before the spec was changed to add that rule.


OK if I understand correctly, so should we rather then try to fix those
tests to skip instead of fail?


They should be fixed with:
https://github.com/KhronosGroup/VK-GL-CTS/commit/49eab80e4a8b3af1790b9ac88b096aa9bffd193f#diff-8369d6640a2c6ad0c0fc1d85b113faeb
https://github.com/KhronosGroup/VK-GL-CTS/commit/858f5396a4f63223fcf31f717d23b4b552e10182#diff-8369d6640a2c6ad0c0fc1d85b113faeb


Thanks, will try with these!


Hi,

Did you have any luck with this? This patch (or mine) are still
pending review based on this?


Sorry I've forgotten this but will get to this now. Could you please
pinpoint which patch from you was referred here?


https://patchwork.freedesktop.org/patch/265974/

(Though it is missing a bit: see
https://chromium-review.googlesource.com/c/chromiumos/third_party/mesa/+/1366537
for what I

Re: [Mesa-dev] [RFC 0/6] Enable fp16 visuals and fbconfigs

[Tapani Pälli]

On 1/7/19 8:44 AM, Tapani Pälli wrote:

Hi;

On 1/4/19 11:56 PM, Kevin Strasser wrote:
This series enables fp16 fbconfigs and visuals by leveraging existing 
off-screen

rendering support.

These formats can be used in conjunction with 
EXT_surface_SMPTE2086_metadata

(not yet implemented by any drivers) to support EXT_gl_colorspace_scrgb /
EXT_gl_colorspace_scrgb_linear, used in places like Android wide color 
gamut.


While I have run this series against Piglit, I still need to sort out 
test
coverage for these formats. If anyone has pointers to existing tests 
that would

be really helpful.


dEQP (EGL module) has set of 'wide color' tests that also cover 1010102 
and fp16.


Having said that, it's not really a 'complete test' but at least 
something to start with. Does kernel already support fp16?




As an easy smoke test I have a modified version of kmscube:
   https://github.com/strassek/kmscube/commits/fp16

Kevin Strasser (6):
   dri: Support 64 bit rgba masks
   dri: Set bit for float configs
   drm-uapi: Add fp16 formats to drm_fourcc.h
   dri: Enable fp16 configs and visuals
   gallium/winsys/kms: Respect format bpp
   gbm: Add visuals and buffer handling for fp16 formats

  include/GL/internal/dri_interface.h    | 11 ++-
  include/drm-uapi/drm_fourcc.h  |  8 +++
  src/egl/drivers/dri2/egl_dri2.c    | 32 +++--
  src/egl/drivers/dri2/egl_dri2.h    |  6 +-
  src/egl/drivers/dri2/platform_android.c    |  2 +-
  src/egl/drivers/dri2/platform_drm.c    | 79 
++

  src/egl/drivers/dri2/platform_surfaceless.c    |  2 +-
  src/egl/drivers/dri2/platform_wayland.c    |  2 +-
  src/egl/drivers/dri2/platform_x11.c    |  6 +-
  .../auxiliary/pipe-loader/driinfo_gallium.h    |  1 +
  src/gallium/state_trackers/dri/dri2.c  | 22 ++
  src/gallium/state_trackers/dri/dri_drawable.c  |  3 +
  src/gallium/state_trackers/dri/dri_screen.c    | 26 ++-
  src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c  |  2 +-
  src/gbm/backends/dri/gbm_dri.c | 38 ++-
  src/gbm/backends/dri/gbm_driint.h  |  9 +--
  src/gbm/main/gbm.c |  3 +
  src/gbm/main/gbm.h |  9 +++
  src/glx/glxconfig.h    |  2 +-
  src/loader/loader_dri3_helper.c    |  5 ++
  src/mesa/drivers/dri/common/dri_util.c |  8 +++
  src/mesa/drivers/dri/common/utils.c    | 31 -
  src/mesa/drivers/dri/i965/intel_screen.c   | 39 ++-
  src/mesa/main/mtypes.h |  2 +-
  src/mesa/state_tracker/st_cb_fbo.c |  3 +
  src/util/xmlpool/t_options.h   |  5 ++
  26 files changed, 311 insertions(+), 45 deletions(-)


___
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] anv/android: handle storage images in vkGetSwapchainGrallocUsageANDROID

[Tapani Pälli]

On 1/7/19 11:56 AM, Bas Nieuwenhuizen wrote:

On Wed, Dec 5, 2018 at 1:05 PM Tapani Pälli  wrote:




On 12/5/18 2:00 PM, Bas Nieuwenhuizen wrote:

On Wed, Dec 5, 2018 at 12:51 PM Tapani Pälli  wrote:




On 12/5/18 1:44 PM, Bas Nieuwenhuizen wrote:

On Wed, Dec 5, 2018 at 12:37 PM Tapani Pälli  wrote:




On 12/5/18 1:22 PM, Bas Nieuwenhuizen wrote:

On Wed, Dec 5, 2018 at 12:15 PM Tapani Pälli  wrote:




On 12/5/18 1:01 PM, Bas Nieuwenhuizen wrote:

On Fri, Sep 7, 2018 at 12:54 AM Kevin Strasser  wrote:


Android P and earlier expect that the surface supports storage images, and
so many of the tests fail when the framework checks for that support. The
framework also includes various image format and usage combinations that are
invalid for the hardware.

Drop the STORAGE restriction from the HAL and whitelist a pair of
formats so that existing versions of Android can pass these tests.

Fixes:
dEQP-VK.wsi.android.*

Signed-off-by: Kevin Strasser 
---
  src/intel/vulkan/anv_android.c | 23 ++-
  1 file changed, 14 insertions(+), 9 deletions(-)

diff --git a/src/intel/vulkan/anv_android.c b/src/intel/vulkan/anv_android.c
index 46c41d5..e2640b8 100644
--- a/src/intel/vulkan/anv_android.c
+++ b/src/intel/vulkan/anv_android.c
@@ -234,7 +234,7 @@ VkResult anv_GetSwapchainGrallocUsageANDROID(
 *grallocUsage = 0;
 intel_logd("%s: format=%d, usage=0x%x", __func__, format, imageUsage);

-   /* WARNING: Android Nougat's libvulkan.so hardcodes the VkImageUsageFlags
+   /* WARNING: Android's libvulkan.so hardcodes the VkImageUsageFlags
  * returned to applications via 
VkSurfaceCapabilitiesKHR::supportedUsageFlags.
  * The relevant code in libvulkan/swapchain.cpp contains this fun 
comment:
  *
@@ -247,7 +247,7 @@ VkResult anv_GetSwapchainGrallocUsageANDROID(
  * dEQP-VK.wsi.android.swapchain.*.image_usage to fail.
  */

-   const VkPhysicalDeviceImageFormatInfo2KHR image_format_info = {
+   VkPhysicalDeviceImageFormatInfo2KHR image_format_info = {


Why remove the const here?


.sType = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_FORMAT_INFO_2_KHR,
.format = format,
.type = VK_IMAGE_TYPE_2D,
@@ -255,6 +255,17 @@ VkResult anv_GetSwapchainGrallocUsageANDROID(
.usage = imageUsage,
 };

+   /* Android P and earlier doesn't check if the physical device supports a
+* given format and usage combination before calling this function. Omit the
+* storage requirement to make the tests pass.
+*/
+#if ANDROID_API_LEVEL <= 28
+   if (format == VK_FORMAT_R8G8B8A8_SRGB ||
+   format == VK_FORMAT_R5G6B5_UNORM_PACK16) {
+  image_format_info.usage &= ~VK_IMAGE_USAGE_STORAGE_BIT;
+   }
+#endif


I don't think you need this. Per the vulkan spec you can only use an
format + usage combination for a swapchain if it is supported per
ImageFormatProperties, using essentially the same check happening
above. I know CTs has been bad at this, but Vulkan CTS should have
been fixed for a bit now. (I don't think all the fixes are in Android
CTS 9.0_r4 yet, maybe the next release?)


AFAIK the problem here is not about CTS. It's the swapchain
implementation that always requires storage support.


Actually swapchain creation has the following valid usage rule:

"The implied image creation parameters of the swapchain must be
supported as reported by vkGetPhysicalDeviceImageFormatProperties"

So since those formats don't support the STORAGE usage bit, that test
fails and you are not allowed to create a swapchain with those formats
and storage, even if the surface capabiliities expose the STORAGE
usage bit in general.


Right ... this stuff was done because comment in the swapchain setting
the bits seems like maybe it's not thought through:

// TODO(jessehall): I think these are right, but haven't thought hard about
// it. Do we need to query the driver for support of any of these?


That was from before the spec was changed to add that rule.


OK if I understand correctly, so should we rather then try to fix those
tests to skip instead of fail?


They should be fixed with:
https://github.com/KhronosGroup/VK-GL-CTS/commit/49eab80e4a8b3af1790b9ac88b096aa9bffd193f#diff-8369d6640a2c6ad0c0fc1d85b113faeb
https://github.com/KhronosGroup/VK-GL-CTS/commit/858f5396a4f63223fcf31f717d23b4b552e10182#diff-8369d6640a2c6ad0c0fc1d85b113faeb


Thanks, will try with these!


Hi,

Did you have any luck with this? This patch (or mine) are still
pending review based on this?


Sorry I've forgotten this but will get to this now. Could you please 
pinpoint which patch from you was referred here?




Thanks,
Bas











(Also silently removing the usage bit is bad, because the app could
try actually using images stores with the image ...)


True, it is not nice ..



+
 VkImageFormatProperties2KHR image_format_props = {
.sType = VK_STRUCTURE_TYPE_IM

Re: [Mesa-dev] Chromium - Application-level nouveau blacklist

[Tapani Pälli]

On 1/6/19 9:37 AM, Jason Ekstrand wrote:
On Sat, Jan 5, 2019 at 2:40 PM Ilia Mirkin > wrote:


It looks like as of Chromium 71, nouveau is completely blacklisted.


That's rather unfortunate. :-(  The intel mesa drivers were also 
blacklisted for quite some time a while back.  I'm not really sure what 
we did to get blacklisted or what we did to get unblacklisted.


We had lots of GPU hangs from WebGL tests. We fixed things until in some 
point things were passing and our web team sent a patch to Chromium to 
enable it back again. This is probably the best route to get Nouveau 
enabled as well.


Have to note that we do have currently some WebGL issues on i965 too .. 
should take a look at some point.




I don't really see a way back from this, since they don't cite any
easily reproducible issues, except that some people had some issues
with indeterminate hardware and indeterminate versions of mesa.

In the bug that triggered this
(https://bugs.chromium.org/p/chromium/issues/detail?id=876523), where
I might have slightly lost my cool, they (at the end) suggested that
we try to make nouveau a first-class citizen with chromium. However I
will never be able to present concrete evidence that inconcrete issues
are resolved. I did run the WebGL CTS suite, but that resulted in some
hangs from the the max-texture-size-equivalent test, and some
browser-level weirdness after some tests where later tests all fail
(due to what I have to assume is a browser bug). I don't think I
managed to properly track down the true reason why. I didn't want to
reach out to them with such results, as that's just further evidence
of nouveau not working perfectly.


If you want concrete bugs to fix, I highly recommend OpenGL[ES] 
conformance tests, dEQP, and the WebGL CTS (which is mostly a re-hash of 
the OpenGL ES 3.0 CTS).  Google cares quite a bit about driver 
conformance and are much more likely to consider nouveau to be 
high-quality if those test suites are in good shape.  Years of 
experience dealing with Google says that dEQP results speak much louder 
than philosophical arguments about who should decide whether or not 
Chromium should accept the distro GL.  Fortunately for you, the well 
funded driver teams (Intel and AMD) have already done a lot of the 
painful work of getting a lot of the bugs and "bugs" out of core mesa 
and galium.  What's left are likely real back-end driver bugs which may 
be affecting some user somewhere so they're worth fixing.


In the meanwhile, end users are losing accelerated WebGL which in
practice worked just fine (at least in my usage of it), and probably
some other functionality.

One idea is to flip GL_VENDOR to some random string if chromium is
running. I don't like this idea, but I also don't have any great
alternatives. We can also just take this, as yet-another nail in the
nouveau coffin.


You asked for opinions, so here you go. :-P  In my personal (and rather 
disinterested) opinion, I would recommend against such measures.  The 
last thing anyone needs is an arms race between nouveau and Chromium 
teams.  I think the better short-term thing to do would be to provide 
some documentation about WebGL and educate users about Chromium's 
--ignore-gpu-blacklist option.  This documentation could go on the mesa 
website or, likely more usefully, it could go in various distro wiki 
entries about nouveau and/or general nvidia issues.  In the long term, 
what's needed is improving nouveau quality and stability and re-building 
trust with the Chromium team.  I'm not trying to attack nouveau here but 
the fact is that trust has been lost due to an unfortunate history of 
mis-filed (against Chromium) bugs.  That trust doesn't get re-built by 
nuclear solutions.


--Jason

___
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] [RFC 0/6] Enable fp16 visuals and fbconfigs

[Tapani Pälli]

Hi;

On 1/4/19 11:56 PM, Kevin Strasser wrote:

This series enables fp16 fbconfigs and visuals by leveraging existing off-screen
rendering support.

These formats can be used in conjunction with EXT_surface_SMPTE2086_metadata
(not yet implemented by any drivers) to support EXT_gl_colorspace_scrgb /
EXT_gl_colorspace_scrgb_linear, used in places like Android wide color gamut.

While I have run this series against Piglit, I still need to sort out test
coverage for these formats. If anyone has pointers to existing tests that would
be really helpful.


dEQP (EGL module) has set of 'wide color' tests that also cover 1010102 
and fp16.



As an easy smoke test I have a modified version of kmscube:
   https://github.com/strassek/kmscube/commits/fp16

Kevin Strasser (6):
   dri: Support 64 bit rgba masks
   dri: Set bit for float configs
   drm-uapi: Add fp16 formats to drm_fourcc.h
   dri: Enable fp16 configs and visuals
   gallium/winsys/kms: Respect format bpp
   gbm: Add visuals and buffer handling for fp16 formats

  include/GL/internal/dri_interface.h| 11 ++-
  include/drm-uapi/drm_fourcc.h  |  8 +++
  src/egl/drivers/dri2/egl_dri2.c| 32 +++--
  src/egl/drivers/dri2/egl_dri2.h|  6 +-
  src/egl/drivers/dri2/platform_android.c|  2 +-
  src/egl/drivers/dri2/platform_drm.c| 79 ++
  src/egl/drivers/dri2/platform_surfaceless.c|  2 +-
  src/egl/drivers/dri2/platform_wayland.c|  2 +-
  src/egl/drivers/dri2/platform_x11.c|  6 +-
  .../auxiliary/pipe-loader/driinfo_gallium.h|  1 +
  src/gallium/state_trackers/dri/dri2.c  | 22 ++
  src/gallium/state_trackers/dri/dri_drawable.c  |  3 +
  src/gallium/state_trackers/dri/dri_screen.c| 26 ++-
  src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c  |  2 +-
  src/gbm/backends/dri/gbm_dri.c | 38 ++-
  src/gbm/backends/dri/gbm_driint.h  |  9 +--
  src/gbm/main/gbm.c |  3 +
  src/gbm/main/gbm.h |  9 +++
  src/glx/glxconfig.h|  2 +-
  src/loader/loader_dri3_helper.c|  5 ++
  src/mesa/drivers/dri/common/dri_util.c |  8 +++
  src/mesa/drivers/dri/common/utils.c| 31 -
  src/mesa/drivers/dri/i965/intel_screen.c   | 39 ++-
  src/mesa/main/mtypes.h |  2 +-
  src/mesa/state_tracker/st_cb_fbo.c |  3 +
  src/util/xmlpool/t_options.h   |  5 ++
  26 files changed, 311 insertions(+), 45 deletions(-)


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

Re: [Mesa-dev] [PATCH] glsl/linker: complete documentation for assign_attribute_or_color_locations

[Tapani Pälli]

Thanks Andres;
Reviewed-by: Tapani Pälli 

On 1/2/19 3:21 PM, Andres Gomez wrote:

Commit 27f1298b9d9 ("glsl/linker: validate attribute aliasing before 
optimizations")
forgot to complete the documentation.

Cc: Tapani Pälli 
Signed-off-by: Andres Gomez 
---
  src/compiler/glsl/linker.cpp | 22 +-
  1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/src/compiler/glsl/linker.cpp b/src/compiler/glsl/linker.cpp
index 17fe0a58448..08e9fb721f8 100644
--- a/src/compiler/glsl/linker.cpp
+++ b/src/compiler/glsl/linker.cpp
@@ -2693,18 +2693,22 @@ find_available_slots(unsigned used_mask, unsigned 
needed_count)
  #define SAFE_MASK_FROM_INDEX(i) (((i) >= 32) ? ~0 : ((1 << (i)) - 1))
  
  /**

- * Assign locations for either VS inputs or FS outputs
+ * Assign locations for either VS inputs or FS outputs.
   *
- * \param mem_ctx   Temporary ralloc context used for linking
- * \param prog  Shader program whose variables need locations assigned
- * \param constants Driver specific constant values for the program.
- * \param target_index  Selector for the program target to receive location
- *  assignmnets.  Must be either \c MESA_SHADER_VERTEX or
- *  \c MESA_SHADER_FRAGMENT.
+ * \param mem_ctxTemporary ralloc context used for linking.
+ * \param prog   Shader program whose variables need locations
+ *   assigned.
+ * \param constants  Driver specific constant values for the program.
+ * \param target_index   Selector for the program target to receive location
+ *   assignmnets.  Must be either \c MESA_SHADER_VERTEX or
+ *   \c MESA_SHADER_FRAGMENT.
+ * \param do_assignment  Whether we are actually marking the assignment or we
+ *   are just doing a dry-run checking.
   *
   * \return
- * If locations are successfully assigned, true is returned.  Otherwise an
- * error is emitted to the shader link log and false is returned.
+ * If locations are (or can be, in case of dry-running) successfully assigned,
+ * true is returned.  Otherwise an error is emitted to the shader link log and
+ * false is returned.
   */
  static bool
  assign_attribute_or_color_locations(void *mem_ctx,


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

Re: [Mesa-dev] Let's talk about -DDEBUG

[Tapani Pälli]

On 12/14/18 12:53 PM, Erik Faye-Lund wrote:

On Thu, 2018-12-13 at 10:46 -0800, Eric Anholt wrote:

Dylan Baker  writes:


[ Unknown signature status ]
In the autotools discussion I've come to realize that we also need
to talk about
the -DDEBUG guard. It seems that there are two different uses, and
thus two
different asks about it:

- Nine (and RadeonSI?) use -DDEBUG to hide generic debugging
- NIR and Intel (at least) use -DDEBUG to hide really expensive
checks that are
   useful, but necessarily tank performance.

The first group would like -DDEBUG in debugoptimized builds, the
second
obviously doesn't.

Is the right solution to move the first group being !NDEBUG, or
would it be
better to split DEBUG into two different defines such as
DEBUG_MESSAGES and
EXPENSIVE_VALIDATION (paint the bikeshed whatever color you like),
with the
first for both debug and debugoptimized and the second only in
debug builds?


I would like to see NIR validation in debugoptimized builds (which is
the build I use on a regular basis: "please catch all bugs you can at
runtime with asserts, but don't waste CPU time by compiling with
-O0");



I'm starting to think that we should add explicit options (with
reasonable defaults based on ) for things like nir validation. That way
it'd be easy for anyone to pimp their buildtype. Meddling directly with
CFLAGS feels kinda hacky for something as useful like this.

Something like this?


Looks nice and is easy to understand. IMO something like 
'ENABLE_ASSERTS' would be also much more easier/straightforward than 
using "-Db_ndebug=false", here I'm thinking about the bug reporters.




---8<---
diff --git a/meson.build b/meson.build
index aba033387d3..da994e6ea87 100644
--- a/meson.build
+++ b/meson.build
@@ -734,6 +734,16 @@ if get_option('buildtype') == 'debug'
pre_args += '-DDEBUG'
  endif
  
+# define NIR_VALIDATION if needed

+_nir_validation = get_option('nir-validation')
+if _nir_validation == 'auto'
+  if get_option('buildtype') == 'debug'
+pre_args += '-DNIR_VALIDATION'
+  endif
+elif _nir_validation == 'true'
+  pre_args += '-DNIR_VALIDATION'
+endif
+
  if get_option('shader-cache')
pre_args += '-DENABLE_SHADER_CACHE'
  elif with_amd_vk
diff --git a/meson_options.txt b/meson_options.txt
index c636b0a1099..9df20a6e080 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -318,3 +318,10 @@ option(
choices : ['auto', 'true', 'false'],
description : 'Enable VK_EXT_acquire_xlib_display.'
  )
+option(
+  'nir-validation',
+  type : 'combo',
+  value : 'auto',
+  choices : ['auto', 'true', 'false'],
+  description : 'Enable automatic validation of NIR. This has a non-
trivial performance penalty.'
+)
diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index e8be2e101cc..d5609565bea 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/nir/nir.h
@@ -2727,7 +2727,7 @@ nir_variable *nir_variable_clone(const
nir_variable *c, nir_shader *shader);
  
  nir_shader *nir_shader_serialize_deserialize(void *mem_ctx, nir_shader

*s);
  
-#ifndef NDEBUG

+#ifndef NIR_VALIDATION
  void nir_validate_shader(nir_shader *shader, const char *when);
  void nir_metadata_set_validation_flag(nir_shader *shader);
  void nir_metadata_check_validation_flag(nir_shader *shader);
@@ -2768,7 +2768,7 @@ static inline void
nir_metadata_check_validation_flag(nir_shader *shader) { (voi
  static inline bool should_clone_nir(void) { return false; }
  static inline bool should_serialize_deserialize_nir(void) { return
false; }
  static inline bool should_print_nir(void) { return false; }
-#endif /* NDEBUG */
+#endif /* NIR_VALIDATION */
  
  #define _PASS(pass, nir, do_pass) do {   \

 do_pass   \
---8<---

___
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 15/15] anv/android: turn on VK_ANDROID_external_memory_android_hardware_buffer

[Tapani Pälli]

On 12/11/18 4:33 PM, Lionel Landwerlin wrote:

On 27/11/2018 10:53, Tapani Pälli wrote:

Signed-off-by: Tapani Pälli 



Reviewed-by: Lionel Landwerlin 


Thanks a lot! I've applied all changes you proposed and sent new 
versions on the ones where r-b was not given. I also pushed a new branch 
with these changes here:


https://cgit.freedesktop.org/~tpalli/mesa/log/?h=ahw-rebase




---
  src/intel/vulkan/anv_extensions.py | 1 +
  1 file changed, 1 insertion(+)

diff --git a/src/intel/vulkan/anv_extensions.py 
b/src/intel/vulkan/anv_extensions.py

index 7c81228f705..ed9b2edef32 100644
--- a/src/intel/vulkan/anv_extensions.py
+++ b/src/intel/vulkan/anv_extensions.py
@@ -69,6 +69,7 @@ MAX_API_VERSION = None # Computed later
  # the those extension strings, then tests 
dEQP-VK.api.info.instance.extensions

  # and dEQP-VK.api.info.device fail due to the duplicated strings.
  EXTENSIONS = [
+    Extension('VK_ANDROID_external_memory_android_hardware_buffer', 
3, 'ANDROID'),
  Extension('VK_ANDROID_native_buffer', 5, 
'ANDROID'),
  Extension('VK_KHR_16bit_storage', 1, 
'device->info.gen >= 8'),
  Extension('VK_KHR_8bit_storage',  1, 
'device->info.gen >= 8'),




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

Re: [Mesa-dev] [PATCH 13/15] anv: support VkSamplerYcbcrConversionInfo in vkCreateImageView

[Tapani Pälli]

On 12/11/18 3:48 PM, Lionel Landwerlin wrote:

On 27/11/2018 10:53, Tapani Pälli wrote:

If a conversion struct was passed, then initialize view using
format from the conversion structure.

v2: use vk_format directly from the anv_format struct

Signed-off-by: Tapani Pälli



One suggestion :


Reviewed-by: Lionel Landwerlin 



---
  src/intel/vulkan/anv_image.c | 18 +-
  1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
index 79777efe456..2ac3eccbbe0 100644
--- a/src/intel/vulkan/anv_image.c
+++ b/src/intel/vulkan/anv_image.c
@@ -1391,6 +1391,16 @@ anv_CreateImageView(VkDevice _device,
 assert(range->layerCount > 0);
 assert(range->baseMipLevel < image->levels);
  
+   /* Check if a conversion info was passed. */

+   const struct anv_format *conv_format = NULL;
+   const struct VkSamplerYcbcrConversionInfo *conv_info =
+  vk_find_struct_const(pCreateInfo->pNext, SAMPLER_YCBCR_CONVERSION_INFO);
+
+   if (conv_info) {
+  ANV_FROM_HANDLE(anv_ycbcr_conversion, conversion, conv_info->conversion);
+  conv_format = conversion->format;
+   }
+
 const VkImageViewUsageCreateInfo *usage_info =
vk_find_struct_const(pCreateInfo, IMAGE_VIEW_USAGE_CREATE_INFO);
 VkImageUsageFlags view_usage = usage_info ? usage_info->usage : 
image->usage;
@@ -1435,6 +1445,12 @@ anv_CreateImageView(VkDevice _device,
 iview->n_planes = anv_image_aspect_get_planes(iview->aspect_mask);
 iview->vk_format = pCreateInfo->format;



Not sure if overly harsh, but I could add this :


/* "If|image|has anexternal format 
<#memory-external-android-hardware-buffer-external-formats>,|format|*must*be|VK_FORMAT_UNDEFINED|." 
*/


assert(!image->external_format || pCreateInfo->format == 
VK_FORMAT_UNDEFINED);


/* " If|image|has anexternal format 
<#memory-external-android-hardware-buffer-external-formats>, 
the|pNext|chain*must*contain an instance ofVkSamplerYcbcrConversionInfo 
<#VkSamplerYcbcrConversionInfo>with a|conversion|object created with the 
same external format as|image|." */


assert(!image->external_format || conv_info);



Yes makes sense, I've added these!

  
+   /* Format is undefined, this can happen when using external formats. Set

+* view format from the passed conversion info.
+*/
+   if (iview->vk_format == VK_FORMAT_UNDEFINED && conv_format)
+  iview->vk_format = conv_format->vk_format;
+
 iview->extent = (VkExtent3D) {
.width  = anv_minify(image->extent.width , range->baseMipLevel),
.height = anv_minify(image->extent.height, range->baseMipLevel),
@@ -1451,7 +1467,7 @@ anv_CreateImageView(VkDevice _device,
VkImageAspectFlags vplane_aspect =
   anv_plane_to_aspect(iview->aspect_mask, vplane);
struct anv_format_plane format =
- anv_get_format_plane(>info, pCreateInfo->format,
+ anv_get_format_plane(>info, iview->vk_format,
vplane_aspect, image->tiling);
  
iview->planes[vplane].image_plane = iplane;




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

[Mesa-dev] [PATCH v3] anv: support VkExternalFormatANDROID in vkCreateSamplerYcbcrConversion

[Tapani Pälli]

If external format is used, we store the external format identifier in
conversion to be used later when creating VkImageView.

v2: rebase to b43f955037c changes
v3: added assert, ignore components when creating external
format conversion (Lionel)

Signed-off-by: Tapani Pälli 
---
 src/intel/vulkan/anv_formats.c | 30 ++
 1 file changed, 26 insertions(+), 4 deletions(-)

diff --git a/src/intel/vulkan/anv_formats.c b/src/intel/vulkan/anv_formats.c
index 972a6f98620..26b7915662c 100644
--- a/src/intel/vulkan/anv_formats.c
+++ b/src/intel/vulkan/anv_formats.c
@@ -1170,6 +1170,17 @@ VkResult anv_CreateSamplerYcbcrConversion(
ANV_FROM_HANDLE(anv_device, device, _device);
struct anv_ycbcr_conversion *conversion;
 
+   /* Search for VkExternalFormatANDROID and resolve the format. */
+   struct anv_format *ext_format = NULL;
+   const struct VkExternalFormatANDROID *ext_info =
+  vk_find_struct_const(pCreateInfo->pNext, EXTERNAL_FORMAT_ANDROID);
+
+   uint64_t format = ext_info ? ext_info->externalFormat : 0;
+   if (format) {
+  assert(pCreateInfo->format == VK_FORMAT_UNDEFINED);
+  ext_format = (struct anv_format *) (uintptr_t) format;
+   }
+
assert(pCreateInfo->sType == 
VK_STRUCTURE_TYPE_SAMPLER_YCBCR_CONVERSION_CREATE_INFO);
 
conversion = vk_alloc2(>alloc, pAllocator, sizeof(*conversion), 8,
@@ -1182,14 +1193,25 @@ VkResult anv_CreateSamplerYcbcrConversion(
conversion->format = anv_get_format(pCreateInfo->format);
conversion->ycbcr_model = pCreateInfo->ycbcrModel;
conversion->ycbcr_range = pCreateInfo->ycbcrRange;
-   conversion->mapping[0] = pCreateInfo->components.r;
-   conversion->mapping[1] = pCreateInfo->components.g;
-   conversion->mapping[2] = pCreateInfo->components.b;
-   conversion->mapping[3] = pCreateInfo->components.a;
+
+   /* The Vulkan 1.1.95 spec says "When creating an external format conversion,
+* the value of components if ignored."
+*/
+   if (ext_format) {
+  conversion->mapping[0] = pCreateInfo->components.r;
+  conversion->mapping[1] = pCreateInfo->components.g;
+  conversion->mapping[2] = pCreateInfo->components.b;
+  conversion->mapping[3] = pCreateInfo->components.a;
+   }
+
conversion->chroma_offsets[0] = pCreateInfo->xChromaOffset;
conversion->chroma_offsets[1] = pCreateInfo->yChromaOffset;
conversion->chroma_filter = pCreateInfo->chromaFilter;
 
+   /* Setup external format. */
+   if (ext_format)
+  conversion->format = ext_format;
+
bool has_chroma_subsampled = false;
for (uint32_t p = 0; p < conversion->format->n_planes; p++) {
   if (conversion->format->planes[p].has_chroma &&
-- 
2.17.2

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

Re: [Mesa-dev] [PATCH 10/15] anv/android: support creating images from external format

[Tapani Pälli]

On 12/11/18 3:27 PM, Lionel Landwerlin wrote:

On 27/11/2018 10:53, Tapani Pälli wrote:
Since we don't know the exact format at creation time, some 
initialization

is done only when bound with memory in vkBindImageMemory.

v2: demand dedicated allocation in vkGetImageMemoryRequirements2 if
 image has external format

v3: refactor prepare_ahw_image, support vkBindImageMemory2,
 calculate stride correctly for rgb(x) surfaces, rename as
 'resolve_ahw_image'

v4: rebase to b43f955037c changes

Signed-off-by: Tapani Pälli 



Another couple of suggestions belower, otherwise :


Reviewed-by: Lionel Landwerlin 



---
  src/intel/vulkan/anv_android.c   |  36 ++
  src/intel/vulkan/anv_android.h   |   8 +++
  src/intel/vulkan/anv_android_stubs.c |  10 +++
  src/intel/vulkan/anv_device.c    |   2 +-
  src/intel/vulkan/anv_image.c | 103 ++-
  src/intel/vulkan/anv_private.h   |   4 ++
  6 files changed, 160 insertions(+), 3 deletions(-)

diff --git a/src/intel/vulkan/anv_android.c 
b/src/intel/vulkan/anv_android.c

index bdc720214c4..3bc2b63b1c9 100644
--- a/src/intel/vulkan/anv_android.c
+++ b/src/intel/vulkan/anv_android.c
@@ -356,6 +356,42 @@ anv_create_ahw_memory(VkDevice device_h,
 return VK_SUCCESS;
  }
+VkResult
+anv_image_from_external(
+   VkDevice device_h,
+   const VkImageCreateInfo *base_info,
+   const struct VkExternalMemoryImageCreateInfo *create_info,
+   const VkAllocationCallbacks *alloc,
+   VkImage *out_image_h)
+{
+   ANV_FROM_HANDLE(anv_device, device, device_h);
+
+   const struct VkExternalFormatANDROID *ext_info =
+  vk_find_struct_const(base_info->pNext, EXTERNAL_FORMAT_ANDROID);
+
+   if (ext_info && ext_info->externalFormat != 0) {
+  assert(base_info->format == VK_FORMAT_UNDEFINED);
+  assert(base_info->imageType == VK_IMAGE_TYPE_2D);
+  assert(base_info->usage == VK_IMAGE_USAGE_SAMPLED_BIT);
+  assert(base_info->tiling == VK_IMAGE_TILING_OPTIMAL);
+   }
+
+   struct anv_image_create_info anv_info = {
+  .vk_info = base_info,
+  .isl_extra_usage_flags = ISL_SURF_USAGE_DISABLE_AUX_BIT,
+  .external_format = true,
+   };
+
+   VkImage image_h;
+   VkResult result = anv_image_create(device_h, _info, alloc, 
_h);

+   if (result != VK_SUCCESS)
+  return result;
+
+   *out_image_h = image_h;
+
+   return VK_SUCCESS;
+}
+
  VkResult
  anv_image_from_gralloc(VkDevice device_h,
 const VkImageCreateInfo *base_info,
diff --git a/src/intel/vulkan/anv_android.h 
b/src/intel/vulkan/anv_android.h

index 01f0e856291..d5c073126e3 100644
--- a/src/intel/vulkan/anv_android.h
+++ b/src/intel/vulkan/anv_android.h
@@ -29,6 +29,8 @@
  #include 
  struct anv_device_memory;
+struct anv_device;
+struct anv_image;
  VkResult anv_image_from_gralloc(VkDevice device_h,
  const VkImageCreateInfo *base_info,
@@ -36,6 +38,12 @@ VkResult anv_image_from_gralloc(VkDevice device_h,
  const VkAllocationCallbacks *alloc,
  VkImage *pImage);
+VkResult anv_image_from_external(VkDevice device_h,
+ const VkImageCreateInfo *base_info,
+ const struct 
VkExternalMemoryImageCreateInfo *create_info,

+ const VkAllocationCallbacks *alloc,
+ VkImage *out_image_h);
+
  uint64_t anv_ahw_usage_from_vk_usage(const VkImageCreateFlags 
vk_create,

   const VkImageUsageFlags vk_usage);
diff --git a/src/intel/vulkan/anv_android_stubs.c 
b/src/intel/vulkan/anv_android_stubs.c

index ccc16500494..a34afc198a1 100644
--- a/src/intel/vulkan/anv_android_stubs.c
+++ b/src/intel/vulkan/anv_android_stubs.c
@@ -55,3 +55,13 @@ anv_create_ahw_memory(VkDevice device_h,
  {
 return VK_ERROR_EXTENSION_NOT_PRESENT;
  }
+
+VkResult
+anv_image_from_external(VkDevice device_h,
+    const VkImageCreateInfo *base_info,
+    const struct VkExternalMemoryImageCreateInfo 
*create_info,

+    const VkAllocationCallbacks *alloc,
+    VkImage *out_image_h)
+{
+   return VK_ERROR_EXTENSION_NOT_PRESENT;
+}
diff --git a/src/intel/vulkan/anv_device.c 
b/src/intel/vulkan/anv_device.c

index a1ee9315956..5777de96d80 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -2768,7 +2768,7 @@ void anv_GetImageMemoryRequirements2(
    switch (ext->sType) {
    case VK_STRUCTURE_TYPE_MEMORY_DEDICATED_REQUIREMENTS: {
   VkMemoryDedicatedRequirements *requirements = (void *)ext;
- if (image->needs_set_tiling) {
+ if (image->needs_set_tiling || image->external_format) {
  /* If we need to set the tiling for external consumers, 
we need a

   * dedicated allocation.



It's tem

[Mesa-dev] [PATCH v5] anv/android: add GetAndroidHardwareBufferPropertiesANDROID

[Tapani Pälli]

Use the anv_format address in formats table as implementation-defined
external format identifier for now. When adding YUV format support this
might need to change.

v2: code cleanup (Jason)
v3: set anv_format address as identifier
v4: setup suggestedYcbcrModel and suggested[X|Y]ChromaOffset
as expected for HAL_PIXEL_FORMAT_NV12_Y_TILED_INTEL
v5: set linear tiling for GPU_DATA_BUFFER usage, add comment
about multi-bo support to clarify current implementation (Lionel)

Signed-off-by: Tapani Pälli 
---
 src/intel/vulkan/anv_android.c | 119 +
 1 file changed, 119 insertions(+)

diff --git a/src/intel/vulkan/anv_android.c b/src/intel/vulkan/anv_android.c
index 916e76c93ff..ef8deec2ea7 100644
--- a/src/intel/vulkan/anv_android.c
+++ b/src/intel/vulkan/anv_android.c
@@ -29,6 +29,8 @@
 #include 
 
 #include "anv_private.h"
+#include "vk_format_info.h"
+#include "vk_util.h"
 
 static int anv_hal_open(const struct hw_module_t* mod, const char* id, struct 
hw_device_t** dev);
 static int anv_hal_close(struct hw_device_t *dev);
@@ -96,6 +98,123 @@ anv_hal_close(struct hw_device_t *dev)
return -1;
 }
 
+static VkResult
+get_ahw_buffer_format_properties(
+   VkDevice device_h,
+   const struct AHardwareBuffer *buffer,
+   VkAndroidHardwareBufferFormatPropertiesANDROID *pProperties)
+{
+   ANV_FROM_HANDLE(anv_device, device, device_h);
+
+   /* Get a description of buffer contents . */
+   AHardwareBuffer_Desc desc;
+   AHardwareBuffer_describe(buffer, );
+
+   /* Verify description. */
+   uint64_t gpu_usage =
+  AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE |
+  AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT |
+  AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER;
+
+   /* "Buffer must be a valid Android hardware buffer object with at least
+* one of the AHARDWAREBUFFER_USAGE_GPU_* usage flags."
+*/
+   if (!(desc.usage & (gpu_usage)))
+  return VK_ERROR_INVALID_EXTERNAL_HANDLE_KHR;
+
+   /* Fill properties fields based on description. */
+   VkAndroidHardwareBufferFormatPropertiesANDROID *p = pProperties;
+
+   p->format = vk_format_from_android(desc.format);
+
+   const struct anv_format *anv_format = anv_get_format(p->format);
+   p->externalFormat = (uint64_t) (uintptr_t) anv_format;
+
+   /* Default to OPTIMAL tiling but set to linear in case
+* of AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER usage.
+*/
+   VkImageTiling tiling = VK_IMAGE_TILING_OPTIMAL;
+
+   if (desc.usage & AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER)
+  tiling = VK_IMAGE_TILING_LINEAR;
+
+   p->formatFeatures =
+  anv_get_image_format_features(>info, p->format,
+anv_format, VK_IMAGE_TILING_OPTIMAL);
+
+   /* "Images can be created with an external format even if the Android 
hardware
+*  buffer has a format which has an equivalent Vulkan format to enable
+*  consistent handling of images from sources that might use either 
category
+*  of format. However, all images created with an external format are 
subject
+*  to the valid usage requirements associated with external formats, even 
if
+*  the Android hardware buffer’s format has a Vulkan equivalent."
+*
+* "The formatFeatures member *must* include
+*  VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT and at least one of
+*  VK_FORMAT_FEATURE_MIDPOINT_CHROMA_SAMPLES_BIT or
+*  VK_FORMAT_FEATURE_COSITED_CHROMA_SAMPLES_BIT"
+*/
+   p->formatFeatures |=
+  VK_FORMAT_FEATURE_MIDPOINT_CHROMA_SAMPLES_BIT;
+
+   /* "Implementations may not always be able to determine the color model,
+*  numerical range, or chroma offsets of the image contents, so the values
+*  in VkAndroidHardwareBufferFormatPropertiesANDROID are only suggestions.
+*  Applications should treat these values as sensible defaults to use in
+*  the absence of more reliable information obtained through some other
+*  means."
+*/
+   p->samplerYcbcrConversionComponents.r = VK_COMPONENT_SWIZZLE_IDENTITY;
+   p->samplerYcbcrConversionComponents.g = VK_COMPONENT_SWIZZLE_IDENTITY;
+   p->samplerYcbcrConversionComponents.b = VK_COMPONENT_SWIZZLE_IDENTITY;
+   p->samplerYcbcrConversionComponents.a = VK_COMPONENT_SWIZZLE_IDENTITY;
+
+   p->suggestedYcbcrModel = VK_SAMPLER_YCBCR_MODEL_CONVERSION_YCBCR_601;
+   p->suggestedYcbcrRange = VK_SAMPLER_YCBCR_RANGE_ITU_FULL;
+
+   p->suggestedXChromaOffset = VK_CHROMA_LOCATION_MIDPOINT;
+   p->suggestedYChromaOffset = VK_CHROMA_LOCATION_MIDPOINT;
+
+   return VK_SUCCESS;
+}
+
+VkResult
+anv_GetAndroidHardwareBufferPropertiesANDROID(
+   VkDevice device_h,
+   const struct AHardwareBuffer *buffer,
+   VkAndroidHardwareBufferPropertiesANDROID *pProperties)
+{
+   ANV_FROM_HANDLE(anv_device, dev, device_h);
+   struct anv_physical_device *pdevice = >instance->physicalDevice;
+
+   VkAndroidHardwareBufferFormatPropertiesANDROID

Re: [Mesa-dev] [PATCH] mesa: ES2 glReadPixels support for OES float extensions.

[Tapani Pälli]

On 12/12/18 7:10 AM, Nick Kreeger wrote:

The OES extensions for float/half-float allow glReadPixels to read
GL_RGBA values as GL_FLOAT for both floats and half-floats. This patch
ensures that ES2 context versions allows this if at least one of the
extensions is present.


Reading the extension spec, I don't see any changes to glReadPixels section:

https://www.khronos.org/registry/OpenGL/extensions/OES/OES_texture_float.txt

EXT_color_buffer_float (that requires ES 3.0) and OpenGL ES 3.2 add 
following text:


"For floating-point rendering surfaces, the combi-
nation format RGBA and type FLOAT is accepted."

That seems to be handled properly in read_pixels_es3_error_check.


---
  src/mesa/main/readpix.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/mesa/main/readpix.c b/src/mesa/main/readpix.c
index 556c860d39..59f14a6563 100644
--- a/src/mesa/main/readpix.c
+++ b/src/mesa/main/readpix.c
@@ -1084,7 +1084,8 @@ read_pixels(GLint x, GLint y, GLsizei width, GLsizei 
height, GLenum format,
   } else if (ctx->Version < 30) {
  err = _mesa_es_error_check_format_and_type(ctx, format, type, 2);
  if (err == GL_NO_ERROR) {
-   if (type == GL_FLOAT || type == GL_HALF_FLOAT_OES) {
+   if ((type == GL_FLOAT || type == GL_HALF_FLOAT_OES) &&
+   (!_mesa_has_OES_texture_float(ctx) && 
!_mesa_has_OES_texture_half_float(ctx))) {
err = GL_INVALID_OPERATION;
 }
  }


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

Re: [Mesa-dev] [PATCH 08/15] anv/android: support import/export of AHardwareBuffer objects

[Tapani Pälli]

On 12/11/18 3:05 PM, Lionel Landwerlin wrote:

On 27/11/2018 10:53, Tapani Pälli wrote:

v2: add support for non-image buffers (AHARDWAREBUFFER_FORMAT_BLOB)
v3: properly handle usage bits when creating from image
v4: refactor, code cleanup (Jason)
v5: rebase to b43f955037c changes,
 initialize bo flags as ANV_BO_EXTERNAL (Lionel)

Signed-off-by: Tapani Pälli 



Just a couple of suggestions below, otherwise :


Reviewed-by: Lionel Landwerlin 



---
  src/intel/vulkan/anv_android.c   | 123 +++
  src/intel/vulkan/anv_android.h   |  10 +++
  src/intel/vulkan/anv_android_stubs.c |  16 
  src/intel/vulkan/anv_device.c    |  45 +-
  src/intel/vulkan/anv_private.h   |   5 ++
  5 files changed, 197 insertions(+), 2 deletions(-)

diff --git a/src/intel/vulkan/anv_android.c 
b/src/intel/vulkan/anv_android.c

index f2dd16212c1..bdc720214c4 100644
--- a/src/intel/vulkan/anv_android.c
+++ b/src/intel/vulkan/anv_android.c
@@ -233,6 +233,129 @@ anv_ahw_usage_from_vk_usage(const 
VkImageCreateFlags vk_create,

 return ahw_usage;
  }
+VkResult
+anv_GetMemoryAndroidHardwareBufferANDROID(
+   VkDevice device_h,
+   const VkMemoryGetAndroidHardwareBufferInfoANDROID *pInfo,
+   struct AHardwareBuffer **pBuffer)
+{
+   ANV_FROM_HANDLE(anv_device_memory, mem, pInfo->memory);
+
+   /* Some quotes from Vulkan spec:
+    *
+    * "If the device memory was created by importing an Android hardware
+    * buffer, vkGetMemoryAndroidHardwareBufferANDROID must return 
that same

+    * Android hardware buffer object."
+    *
+    * 
"VK_EXTERNAL_MEMORY_HANDLE_TYPE_ANDROID_HARDWARE_BUFFER_BIT_ANDROID must
+    * have been included in 
VkExportMemoryAllocateInfoKHR::handleTypes when

+    * memory was created."
+    */
+   if (mem->ahw) {
+  *pBuffer = mem->ahw;
+  /* Increase refcount. */
+  AHardwareBuffer_acquire(mem->ahw);
+  return VK_SUCCESS;
+   }
+
+   return VK_ERROR_OUT_OF_HOST_MEMORY;
+}
+
+/*
+ * Called from anv_AllocateMemory when import AHardwareBuffer.
+ */
+VkResult
+anv_import_ahw_memory(VkDevice device_h,
+  struct anv_device_memory *mem,
+  const VkImportAndroidHardwareBufferInfoANDROID 
*info)

+{
+   ANV_FROM_HANDLE(anv_device, device, device_h);
+
+   /* Import from AHardwareBuffer to anv_device_memory. */
+   const native_handle_t *handle =
+  AHardwareBuffer_getNativeHandle(info->buffer);
+
+   int dma_buf = (handle && handle->numFds) ? handle->data[0] : -1;



Maybe assert(handle->numFds == 1) so we don't forget to update this when 
we add support for multiple BOs later.


Perhaps I should have added some comment or warning here ... I'm 
actually letting in buffers with multiple fds now because thing is that 
we do get 2 fds with 'HAL_PIXEL_FORMAT_NV12_Y_TILED_INTEL' as we have 2 
logical planes but really just one buffer (both point to the same). I 
was considering to add some special case/check for that but maybe just a 
comment for now?






+   if (dma_buf < 0)
+  return VK_ERROR_INVALID_EXTERNAL_HANDLE_KHR;
+
+   uint64_t bo_flags = ANV_BO_EXTERNAL;
+   if (device->instance->physicalDevice.supports_48bit_addresses)
+  bo_flags |= EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
+   if (device->instance->physicalDevice.use_softpin)
+  bo_flags |= EXEC_OBJECT_PINNED;
+
+   VkResult result = anv_bo_cache_import(device, >bo_cache,
+    dma_buf, bo_flags, >bo);
+   if (result != VK_SUCCESS)
+  return result;
+
+   /* "If the vkAllocateMemory command succeeds, the implementation must
+    * acquire a reference to the imported hardware buffer, which it must
+    * release when the device memory object is freed. If the command 
fails,

+    * the implementation must not retain a reference."
+    */
+   AHardwareBuffer_acquire(info->buffer);
+   mem->ahw = info->buffer;
+
+   return VK_SUCCESS;
+}
+
+VkResult
+anv_create_ahw_memory(VkDevice device_h,
+  struct anv_device_memory *mem,
+  const VkMemoryAllocateInfo *pAllocateInfo)
+{
+   ANV_FROM_HANDLE(anv_device, dev, device_h);
+
+   const VkMemoryDedicatedAllocateInfo *dedicated_info =
+  vk_find_struct_const(pAllocateInfo->pNext,
+   MEMORY_DEDICATED_ALLOCATE_INFO);
+
+   uint32_t w = 0;
+   uint32_t h = 1;
+   uint32_t layers = 1;
+   uint32_t format = 0;
+   uint64_t usage = 0;
+
+   /* If caller passed dedicated information. */
+   if (dedicated_info && dedicated_info->image) {
+  ANV_FROM_HANDLE(anv_image, image, dedicated_info->image);
+  w = image->extent.width;
+  h = image->extent.height;
+  layers = image->array_size;
+  format = android_format_from_vk(image->vk_format);
+  usage = anv_ahw_usage_from_vk_usage(image->create_flags, 
image->usage);

+   } else if (dedicated_info &&am

Re: [Mesa-dev] [PATCH v3] mesa: Fix GLES2 OES float texture framebuffer rendering.

[Tapani Pälli]

On 12/12/18 8:42 AM, Tapani Pälli wrote:



On 12/12/18 5:05 AM, Nick Kreeger wrote:

This change enables GLES2 to render float/half-float textures to a
framebuffer when the appropriate OES extensions are available.

This commit regressed OES GLES2 float texture rendering:
https://gitlab.freedesktop.org/mesa/mesa/commit/e333035c47a6a4cc88f0f9ca2bced500538bebae 



Which test/app got regressed? I'm curious because this commit also fixed 
a failing conformance test that explicitly tests that the fbo with float 
attachment should be marked incomplete.




I'm against this change because these same tests will start to fail if 
we allow this:


https://mesa-ci.01.org/tpalli/builds/652/group/63a9f0ea7bb98050796b649e85481845

I believe the rule is that you should be able to render to sized formats 
such as RGBA32F (with modern GLES) but not to unsized formats such as 
GL_FLOAT.




---
  src/mesa/main/fbobject.c | 20 +++-
  1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 23e4939619..cedfc3d81b 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -869,15 +869,17 @@ test_attachment_completeness(const struct 
gl_context *ctx, GLenum format,

  return;
   }
- /* OES_texture_float allows creation and use of floating point
-  * textures with GL_FLOAT, GL_HALF_FLOAT but it does not allow
-  * these textures to be used as a render target, this is 
done via
-  * GL_EXT_color_buffer(_half)_float with set of new sized 
types.

-  */
- if (_mesa_is_gles(ctx) && (texObj->_IsFloat || 
texObj->_IsHalfFloat)) {

-    att_incomplete("bad internal format");
-    att->Complete = GL_FALSE;
-    return;
+ if (_mesa_is_gles(ctx)) {
+   /**
+    * GL ES 2 will allow GL_FLOAT and GL_HALF_FLOAT to render 
as a
+    * target when the appropriate OES_* extensions are 
available.

+    */
+   if ((texObj->_IsHalfFloat && 
!_mesa_has_OES_texture_half_float(ctx)) ||
+   (texObj->_IsFloat && 
!_mesa_has_OES_texture_float(ctx))) {

+ att_incomplete("bad internal format");
+ att->Complete = GL_FALSE;
+ return;
+   }
   }
    }
    else if (format == GL_DEPTH) {


___
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 v3] mesa: Fix GLES2 OES float texture framebuffer rendering.

[Tapani Pälli]

On 12/12/18 5:05 AM, Nick Kreeger wrote:

This change enables GLES2 to render float/half-float textures to a
framebuffer when the appropriate OES extensions are available.

This commit regressed OES GLES2 float texture rendering:
https://gitlab.freedesktop.org/mesa/mesa/commit/e333035c47a6a4cc88f0f9ca2bced500538bebae


Which test/app got regressed? I'm curious because this commit also fixed 
a failing conformance test that explicitly tests that the fbo with float 
attachment should be marked incomplete.




---
  src/mesa/main/fbobject.c | 20 +++-
  1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 23e4939619..cedfc3d81b 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -869,15 +869,17 @@ test_attachment_completeness(const struct gl_context 
*ctx, GLenum format,
  return;
   }
  
- /* OES_texture_float allows creation and use of floating point

-  * textures with GL_FLOAT, GL_HALF_FLOAT but it does not allow
-  * these textures to be used as a render target, this is done via
-  * GL_EXT_color_buffer(_half)_float with set of new sized types.
-  */
- if (_mesa_is_gles(ctx) && (texObj->_IsFloat || texObj->_IsHalfFloat)) 
{
-att_incomplete("bad internal format");
-att->Complete = GL_FALSE;
-return;
+ if (_mesa_is_gles(ctx)) {
+   /**
+* GL ES 2 will allow GL_FLOAT and GL_HALF_FLOAT to render as a
+* target when the appropriate OES_* extensions are available.
+*/
+   if ((texObj->_IsHalfFloat && 
!_mesa_has_OES_texture_half_float(ctx)) ||
+   (texObj->_IsFloat && !_mesa_has_OES_texture_float(ctx))) {
+ att_incomplete("bad internal format");
+ att->Complete = GL_FALSE;
+ return;
+   }
   }
}
else if (format == GL_DEPTH) {


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

Re: [Mesa-dev] [PATCH 05/15] anv/android: add GetAndroidHardwareBufferPropertiesANDROID

[Tapani Pälli]

On 12/11/18 1:22 PM, Lionel Landwerlin wrote:

On 27/11/2018 10:53, Tapani Pälli wrote:

Use the anv_format address in formats table as implementation-defined
external format identifier for now. When adding YUV format support this
might need to change.

v2: code cleanup (Jason)
v3: set anv_format address as identifier
v4: setup suggestedYcbcrModel and suggested[X|Y]ChromaOffset
 as expected for HAL_PIXEL_FORMAT_NV12_Y_TILED_INTEL

Signed-off-by: Tapani Pälli 
---
  src/intel/vulkan/anv_android.c | 106 +
  1 file changed, 106 insertions(+)

diff --git a/src/intel/vulkan/anv_android.c 
b/src/intel/vulkan/anv_android.c

index 916e76c93ff..54b62b9d02f 100644
--- a/src/intel/vulkan/anv_android.c
+++ b/src/intel/vulkan/anv_android.c
@@ -29,6 +29,8 @@
  #include 
  #include "anv_private.h"
+#include "vk_format_info.h"
+#include "vk_util.h"
  static int anv_hal_open(const struct hw_module_t* mod, const char* 
id, struct hw_device_t** dev);

  static int anv_hal_close(struct hw_device_t *dev);
@@ -96,6 +98,110 @@ anv_hal_close(struct hw_device_t *dev)
 return -1;
  }
+static VkResult
+get_ahw_buffer_format_properties(
+   VkDevice device_h,
+   const struct AHardwareBuffer *buffer,
+   VkAndroidHardwareBufferFormatPropertiesANDROID *pProperties)
+{
+   ANV_FROM_HANDLE(anv_device, device, device_h);
+
+   /* Get a description of buffer contents . */
+   AHardwareBuffer_Desc desc;
+   AHardwareBuffer_describe(buffer, );
+
+   /* Verify description. */
+   uint64_t gpu_usage =
+  AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE |
+  AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT |
+  AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER;
+
+   /* "Buffer must be a valid Android hardware buffer object with at 
least

+    * one of the AHARDWAREBUFFER_USAGE_GPU_* usage flags."
+    */
+   if (!(desc.usage & (gpu_usage)))
+  return VK_ERROR_INVALID_EXTERNAL_HANDLE_KHR;
+
+   /* Fill properties fields based on description. */
+   VkAndroidHardwareBufferFormatPropertiesANDROID *p = pProperties;
+
+   p->format = vk_format_from_android(desc.format);
+
+   const struct anv_format *anv_format = anv_get_format(p->format);
+   p->externalFormat = (uint64_t) (uintptr_t) anv_format;
+
+   p->formatFeatures =
+  anv_get_image_format_features(>info, p->format,
+    anv_format, 
VK_IMAGE_TILING_OPTIMAL);



The Android documentation is not very clear about what the different 
usages mean for tiling.


But I would expect that DATA_BUFFER would mean linear. Am I wrong?


You are correct, will fix this.




+
+   /* "Images can be created with an external format even if the 
Android hardware
+    *  buffer has a format which has an equivalent Vulkan format to 
enable
+    *  consistent handling of images from sources that might use 
either category
+    *  of format. However, all images created with an external format 
are subject
+    *  to the valid usage requirements associated with external 
formats, even if

+    *  the Android hardware buffer’s format has a Vulkan equivalent."
+    *
+    * "The formatFeatures member *must* include
+    *  VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT and at least one of
+    *  VK_FORMAT_FEATURE_MIDPOINT_CHROMA_SAMPLES_BIT or
+    *  VK_FORMAT_FEATURE_COSITED_CHROMA_SAMPLES_BIT"
+    */
+   p->formatFeatures |=
+  VK_FORMAT_FEATURE_MIDPOINT_CHROMA_SAMPLES_BIT;
+
+   /* "Implementations may not always be able to determine the color 
model,
+    *  numerical range, or chroma offsets of the image contents, so 
the values
+    *  in VkAndroidHardwareBufferFormatPropertiesANDROID are only 
suggestions.
+    *  Applications should treat these values as sensible defaults to 
use in
+    *  the absence of more reliable information obtained through some 
other

+    *  means."
+    */
+   p->samplerYcbcrConversionComponents.r = 
VK_COMPONENT_SWIZZLE_IDENTITY;
+   p->samplerYcbcrConversionComponents.g = 
VK_COMPONENT_SWIZZLE_IDENTITY;
+   p->samplerYcbcrConversionComponents.b = 
VK_COMPONENT_SWIZZLE_IDENTITY;
+   p->samplerYcbcrConversionComponents.a = 
VK_COMPONENT_SWIZZLE_IDENTITY;

+
+   p->suggestedYcbcrModel = VK_SAMPLER_YCBCR_MODEL_CONVERSION_YCBCR_601;
+   p->suggestedYcbcrRange = VK_SAMPLER_YCBCR_RANGE_ITU_FULL;
+
+   p->suggestedXChromaOffset = VK_CHROMA_LOCATION_MIDPOINT;
+   p->suggestedYChromaOffset = VK_CHROMA_LOCATION_MIDPOINT;
+
+   return VK_SUCCESS;
+}
+
+VkResult
+anv_GetAndroidHardwareBufferPropertiesANDROID(
+   VkDevice device_h,
+   const struct AHardwareBuffer *buffer,
+   VkAndroidHardwareBufferPropertiesANDROID *pProperties)
+{
+   ANV_FROM_HANDLE(anv_device, dev, device_h);
+   struct anv_physical_device *pdevice = >instance->physicalDevice;
+
+   VkAndroidHardwareBufferFormatPropertiesANDROID *format_prop =
+  vk_find_struct(pProperties->pNext,
+ ANDROID_H

Re: [Mesa-dev] [PATCH 04/15] anv: add from/to helpers with android and vulkan formats

[Tapani Pälli]

On 12/11/18 12:56 PM, Lionel Landwerlin wrote:

On 27/11/2018 10:53, Tapani Pälli wrote:

v2: handle R8G8B8X8 as R8G8B8_UNORM (Jason)
v3: add HAL_PIXEL_FORMAT_NV12_Y_TILED_INTEL, we make it define
 for now to avoid direct dependency to minigbm headers

Signed-off-by: Tapani Pälli 
---
  src/intel/vulkan/vk_format_info.h | 50 +++
  1 file changed, 50 insertions(+)

diff --git a/src/intel/vulkan/vk_format_info.h 
b/src/intel/vulkan/vk_format_info.h

index a1cc6952c8f..555c67704bc 100644
--- a/src/intel/vulkan/vk_format_info.h
+++ b/src/intel/vulkan/vk_format_info.h
@@ -27,6 +27,56 @@
  #include 
  #include 
+#ifdef ANDROID
+#include 
+/* See i915_private_android_types.h in minigbm. */
+#define HAL_PIXEL_FORMAT_NV12_Y_TILED_INTEL 0x100
+
+static inline VkFormat
+vk_format_from_android(unsigned android_format)
+{
+   switch (android_format) {
+   case AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM:
+  return VK_FORMAT_R8G8B8A8_UNORM;
+   case AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM:
+   case AHARDWAREBUFFER_FORMAT_R8G8B8_UNORM:
+  return VK_FORMAT_R8G8B8_UNORM;



Hm... I think you could run into issue with a linear buffer 
AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM.


It seems anv will actually select R8G8B8 in that case and that probably 
won't match.


Thinking here was that these would be handled in similar way, both have 
alpha 1.0 channel. Right now these are not required though so I can also 
remove them from the list if this is preferred?





+   case AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM:
+  return VK_FORMAT_R5G6B5_UNORM_PACK16;
+   case AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT:
+  return VK_FORMAT_R16G16B16A16_SFLOAT;
+   case AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM:
+  return VK_FORMAT_A2B10G10R10_UNORM_PACK32;



Is the android naming inconsistent or are all the other formats backwards?


I took these from Vulkan spec 'AHardwareBuffer Format Equivalence' so 
seems to be what is wanted.





+   case HAL_PIXEL_FORMAT_NV12_Y_TILED_INTEL:
+  return VK_FORMAT_G8_B8R8_2PLANE_420_UNORM;
+   case AHARDWAREBUFFER_FORMAT_BLOB:
+   default:
+  return VK_FORMAT_UNDEFINED;
+   }
+}
+
+static inline unsigned
+android_format_from_vk(unsigned vk_format)
+{
+   switch (vk_format) {
+   case VK_FORMAT_R8G8B8A8_UNORM:
+  return AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM;
+   case VK_FORMAT_R8G8B8_UNORM:
+  return AHARDWAREBUFFER_FORMAT_R8G8B8_UNORM;
+   case VK_FORMAT_R5G6B5_UNORM_PACK16:
+  return AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM;
+   case VK_FORMAT_R16G16B16A16_SFLOAT:
+  return AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT;
+   case VK_FORMAT_A2B10G10R10_UNORM_PACK32:
+  return AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM;
+   case VK_FORMAT_G8_B8R8_2PLANE_420_UNORM:
+  return HAL_PIXEL_FORMAT_NV12_Y_TILED_INTEL;
+   default:
+  return AHARDWAREBUFFER_FORMAT_BLOB;
+   }
+}
+#endif
+
  static inline VkImageAspectFlags
  vk_format_aspects(VkFormat format)
  {




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

Re: [Mesa-dev] [PATCH 00/15] VK_ANDROID_external_memory_android_hardware_buffer

[Tapani Pälli]

ping!

On 11/27/18 12:53 PM, Tapani Pälli wrote:

Hi;

Series was rebased and fixes applied from review, also some changes
applied to support HAL_PIXEL_FORMAT_NV12_Y_TILED_INTEL. With these
changes android.graphics.cts.MediaVulkanGpuTest starts to pass, now
all tests utilizing AHardwareBuffer pass (CTS + SkQP) \o/

tree:
https://cgit.freedesktop.org/~tpalli/mesa/log/?h=ahw

android tree used in testing:
https://github.com/tpalli/external-mesa/tree/ahw-android

CI was happy:
https://mesa-ci.01.org/tpalli/builds/642/group/63a9f0ea7bb98050796b649e85481845

Tapani Pälli (15):
   anv: add create_flags as part of anv_image
   anv: refactor make_surface to use data from anv_image
   anv: make anv_get_image_format_features public
   anv: add from/to helpers with android and vulkan formats
   anv/android: add GetAndroidHardwareBufferPropertiesANDROID
   anv: add anv_ahw_usage_from_vk_usage helper function
   anv: refactor, remove else block in AllocateMemory
   anv/android: support import/export of AHardwareBuffer objects
   anv/android: add ahardwarebuffer external memory properties
   anv/android: support creating images from external format
   anv: support VkExternalFormatANDROID in vkCreateSamplerYcbcrConversion
   anv: add VkFormat field as part of anv_format
   anv: support VkSamplerYcbcrConversionInfo in vkCreateImageView
   anv: ignore VkSamplerYcbcrConversion on non-yuv formats
   anv/android: turn on
 VK_ANDROID_external_memory_android_hardware_buffer

  src/intel/vulkan/anv_android.c   | 296 +++
  src/intel/vulkan/anv_android.h   |  20 ++
  src/intel/vulkan/anv_android_stubs.c |  33 +++
  src/intel/vulkan/anv_device.c| 107 +++---
  src/intel/vulkan/anv_extensions.py   |   1 +
  src/intel/vulkan/anv_formats.c   |  80 +++-
  src/intel/vulkan/anv_image.c | 200 ++
  src/intel/vulkan/anv_private.h   |  21 ++
  src/intel/vulkan/genX_state.c|   7 +-
  src/intel/vulkan/vk_format_info.h|  50 +
  10 files changed, 731 insertions(+), 84 deletions(-)


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

Re: [Mesa-dev] [PATCH 03/11] mesa: add logging function for formatted string

[Tapani Pälli]

On 12/7/18 2:35 AM, Mark Janes wrote:

---
  src/mesa/main/errors.c | 27 +++
  src/mesa/main/errors.h |  8 
  2 files changed, 35 insertions(+)

diff --git a/src/mesa/main/errors.c b/src/mesa/main/errors.c
index fad8cb59cae..995b0510575 100644
--- a/src/mesa/main/errors.c
+++ b/src/mesa/main/errors.c
@@ -253,6 +253,33 @@ _mesa_gl_debugf(struct gl_context *ctx,
 va_end(args);
  }
  
+size_t

+_mesa_gl_debug(struct gl_context *ctx,
+   GLuint *id,
+   enum mesa_debug_source source,
+   enum mesa_debug_type type,
+   enum mesa_debug_severity severity,
+   const char *msg)
+{
+   _mesa_debug_get_id(id);
+
+   size_t len = strnlen(msg, MAX_DEBUG_MESSAGE_LENGTH);
+   if (len < MAX_DEBUG_MESSAGE_LENGTH) {
+  _mesa_log_msg(ctx, source, type, *id, severity, len, msg);
+  return len;
+   }
+
+   /* limit the message to fit within KHR_debug buffers */
+   char s[MAX_DEBUG_MESSAGE_LENGTH];
+   strncpy(s, msg, MAX_DEBUG_MESSAGE_LENGTH);
+   s[MAX_DEBUG_MESSAGE_LENGTH - 1] = '\0';
+   len = MAX_DEBUG_MESSAGE_LENGTH - 1;
+   _mesa_log_msg(ctx, source, type, *id, severity, len, s);


Maybe less code when using strndup here? Or maybe not, did not really 
check but just throwing ideas :)



+
+   /* report the number of characters that were logged */
+   return len;
+}
+
  
  /**

   * Record an OpenGL state error.  These usually occur when the user
diff --git a/src/mesa/main/errors.h b/src/mesa/main/errors.h
index 3e2d56e7741..17fe380f26a 100644
--- a/src/mesa/main/errors.h
+++ b/src/mesa/main/errors.h
@@ -90,6 +90,14 @@ _mesa_gl_debugf(struct gl_context *ctx,
  enum mesa_debug_severity severity,
  const char *fmtString, ...) PRINTFLIKE(6, 7);
  
+extern size_t

+_mesa_gl_debug(struct gl_context *ctx,
+   GLuint *id,
+   enum mesa_debug_source source,
+   enum mesa_debug_type type,
+   enum mesa_debug_severity severity,
+   const char *msg);
+
  #define _mesa_perf_debug(ctx, sev, ...) do {  \
 static GLuint msg_id = 0;  \
 if (unlikely(ctx->Const.ContextFlags & GL_CONTEXT_FLAG_DEBUG_BIT)) {   \


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

Re: [Mesa-dev] [PATCH] anv/android: handle storage images in vkGetSwapchainGrallocUsageANDROID

[Tapani Pälli]

On 12/5/18 2:00 PM, Bas Nieuwenhuizen wrote:

On Wed, Dec 5, 2018 at 12:51 PM Tapani Pälli  wrote:




On 12/5/18 1:44 PM, Bas Nieuwenhuizen wrote:

On Wed, Dec 5, 2018 at 12:37 PM Tapani Pälli  wrote:




On 12/5/18 1:22 PM, Bas Nieuwenhuizen wrote:

On Wed, Dec 5, 2018 at 12:15 PM Tapani Pälli  wrote:




On 12/5/18 1:01 PM, Bas Nieuwenhuizen wrote:

On Fri, Sep 7, 2018 at 12:54 AM Kevin Strasser  wrote:


Android P and earlier expect that the surface supports storage images, and
so many of the tests fail when the framework checks for that support. The
framework also includes various image format and usage combinations that are
invalid for the hardware.

Drop the STORAGE restriction from the HAL and whitelist a pair of
formats so that existing versions of Android can pass these tests.

Fixes:
   dEQP-VK.wsi.android.*

Signed-off-by: Kevin Strasser 
---
 src/intel/vulkan/anv_android.c | 23 ++-
 1 file changed, 14 insertions(+), 9 deletions(-)

diff --git a/src/intel/vulkan/anv_android.c b/src/intel/vulkan/anv_android.c
index 46c41d5..e2640b8 100644
--- a/src/intel/vulkan/anv_android.c
+++ b/src/intel/vulkan/anv_android.c
@@ -234,7 +234,7 @@ VkResult anv_GetSwapchainGrallocUsageANDROID(
*grallocUsage = 0;
intel_logd("%s: format=%d, usage=0x%x", __func__, format, imageUsage);

-   /* WARNING: Android Nougat's libvulkan.so hardcodes the VkImageUsageFlags
+   /* WARNING: Android's libvulkan.so hardcodes the VkImageUsageFlags
 * returned to applications via 
VkSurfaceCapabilitiesKHR::supportedUsageFlags.
 * The relevant code in libvulkan/swapchain.cpp contains this fun 
comment:
 *
@@ -247,7 +247,7 @@ VkResult anv_GetSwapchainGrallocUsageANDROID(
 * dEQP-VK.wsi.android.swapchain.*.image_usage to fail.
 */

-   const VkPhysicalDeviceImageFormatInfo2KHR image_format_info = {
+   VkPhysicalDeviceImageFormatInfo2KHR image_format_info = {


Why remove the const here?


   .sType = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_FORMAT_INFO_2_KHR,
   .format = format,
   .type = VK_IMAGE_TYPE_2D,
@@ -255,6 +255,17 @@ VkResult anv_GetSwapchainGrallocUsageANDROID(
   .usage = imageUsage,
};

+   /* Android P and earlier doesn't check if the physical device supports a
+* given format and usage combination before calling this function. Omit the
+* storage requirement to make the tests pass.
+*/
+#if ANDROID_API_LEVEL <= 28
+   if (format == VK_FORMAT_R8G8B8A8_SRGB ||
+   format == VK_FORMAT_R5G6B5_UNORM_PACK16) {
+  image_format_info.usage &= ~VK_IMAGE_USAGE_STORAGE_BIT;
+   }
+#endif


I don't think you need this. Per the vulkan spec you can only use an
format + usage combination for a swapchain if it is supported per
ImageFormatProperties, using essentially the same check happening
above. I know CTs has been bad at this, but Vulkan CTS should have
been fixed for a bit now. (I don't think all the fixes are in Android
CTS 9.0_r4 yet, maybe the next release?)


AFAIK the problem here is not about CTS. It's the swapchain
implementation that always requires storage support.


Actually swapchain creation has the following valid usage rule:

"The implied image creation parameters of the swapchain must be
supported as reported by vkGetPhysicalDeviceImageFormatProperties"

So since those formats don't support the STORAGE usage bit, that test
fails and you are not allowed to create a swapchain with those formats
and storage, even if the surface capabiliities expose the STORAGE
usage bit in general.


Right ... this stuff was done because comment in the swapchain setting
the bits seems like maybe it's not thought through:

// TODO(jessehall): I think these are right, but haven't thought hard about
// it. Do we need to query the driver for support of any of these?


That was from before the spec was changed to add that rule.


OK if I understand correctly, so should we rather then try to fix those
tests to skip instead of fail?


They should be fixed with:
https://github.com/KhronosGroup/VK-GL-CTS/commit/49eab80e4a8b3af1790b9ac88b096aa9bffd193f#diff-8369d6640a2c6ad0c0fc1d85b113faeb
https://github.com/KhronosGroup/VK-GL-CTS/commit/858f5396a4f63223fcf31f717d23b4b552e10182#diff-8369d6640a2c6ad0c0fc1d85b113faeb


Thanks, will try with these!










(Also silently removing the usage bit is bad, because the app could
try actually using images stores with the image ...)


True, it is not nice ..



+
VkImageFormatProperties2KHR image_format_props = {
   .sType = VK_STRUCTURE_TYPE_IMAGE_FORMAT_PROPERTIES_2_KHR,
};
@@ -268,19 +279,13 @@ VkResult anv_GetSwapchainGrallocUsageANDROID(
"inside %s", __func__);
}

-   /* Reject STORAGE here to avoid complexity elsewhere. */
-   if (imageUsage & VK_IMAGE_USAGE_STORAGE_BIT) {
-  return vk_errorf(device->ins

Re: [Mesa-dev] [PATCH] anv/android: handle storage images in vkGetSwapchainGrallocUsageANDROID

[Tapani Pälli]

On 12/5/18 1:44 PM, Bas Nieuwenhuizen wrote:

On Wed, Dec 5, 2018 at 12:37 PM Tapani Pälli  wrote:




On 12/5/18 1:22 PM, Bas Nieuwenhuizen wrote:

On Wed, Dec 5, 2018 at 12:15 PM Tapani Pälli  wrote:




On 12/5/18 1:01 PM, Bas Nieuwenhuizen wrote:

On Fri, Sep 7, 2018 at 12:54 AM Kevin Strasser  wrote:


Android P and earlier expect that the surface supports storage images, and
so many of the tests fail when the framework checks for that support. The
framework also includes various image format and usage combinations that are
invalid for the hardware.

Drop the STORAGE restriction from the HAL and whitelist a pair of
formats so that existing versions of Android can pass these tests.

Fixes:
  dEQP-VK.wsi.android.*

Signed-off-by: Kevin Strasser 
---
src/intel/vulkan/anv_android.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)

diff --git a/src/intel/vulkan/anv_android.c b/src/intel/vulkan/anv_android.c
index 46c41d5..e2640b8 100644
--- a/src/intel/vulkan/anv_android.c
+++ b/src/intel/vulkan/anv_android.c
@@ -234,7 +234,7 @@ VkResult anv_GetSwapchainGrallocUsageANDROID(
   *grallocUsage = 0;
   intel_logd("%s: format=%d, usage=0x%x", __func__, format, imageUsage);

-   /* WARNING: Android Nougat's libvulkan.so hardcodes the VkImageUsageFlags
+   /* WARNING: Android's libvulkan.so hardcodes the VkImageUsageFlags
* returned to applications via 
VkSurfaceCapabilitiesKHR::supportedUsageFlags.
* The relevant code in libvulkan/swapchain.cpp contains this fun 
comment:
*
@@ -247,7 +247,7 @@ VkResult anv_GetSwapchainGrallocUsageANDROID(
* dEQP-VK.wsi.android.swapchain.*.image_usage to fail.
*/

-   const VkPhysicalDeviceImageFormatInfo2KHR image_format_info = {
+   VkPhysicalDeviceImageFormatInfo2KHR image_format_info = {


Why remove the const here?


  .sType = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_FORMAT_INFO_2_KHR,
  .format = format,
  .type = VK_IMAGE_TYPE_2D,
@@ -255,6 +255,17 @@ VkResult anv_GetSwapchainGrallocUsageANDROID(
  .usage = imageUsage,
   };

+   /* Android P and earlier doesn't check if the physical device supports a
+* given format and usage combination before calling this function. Omit the
+* storage requirement to make the tests pass.
+*/
+#if ANDROID_API_LEVEL <= 28
+   if (format == VK_FORMAT_R8G8B8A8_SRGB ||
+   format == VK_FORMAT_R5G6B5_UNORM_PACK16) {
+  image_format_info.usage &= ~VK_IMAGE_USAGE_STORAGE_BIT;
+   }
+#endif


I don't think you need this. Per the vulkan spec you can only use an
format + usage combination for a swapchain if it is supported per
ImageFormatProperties, using essentially the same check happening
above. I know CTs has been bad at this, but Vulkan CTS should have
been fixed for a bit now. (I don't think all the fixes are in Android
CTS 9.0_r4 yet, maybe the next release?)


AFAIK the problem here is not about CTS. It's the swapchain
implementation that always requires storage support.


Actually swapchain creation has the following valid usage rule:

"The implied image creation parameters of the swapchain must be
supported as reported by vkGetPhysicalDeviceImageFormatProperties"

So since those formats don't support the STORAGE usage bit, that test
fails and you are not allowed to create a swapchain with those formats
and storage, even if the surface capabiliities expose the STORAGE
usage bit in general.


Right ... this stuff was done because comment in the swapchain setting
the bits seems like maybe it's not thought through:

// TODO(jessehall): I think these are right, but haven't thought hard about
// it. Do we need to query the driver for support of any of these?


That was from before the spec was changed to add that rule.


OK if I understand correctly, so should we rather then try to fix those 
tests to skip instead of fail?







(Also silently removing the usage bit is bad, because the app could
try actually using images stores with the image ...)


True, it is not nice ..



+
   VkImageFormatProperties2KHR image_format_props = {
  .sType = VK_STRUCTURE_TYPE_IMAGE_FORMAT_PROPERTIES_2_KHR,
   };
@@ -268,19 +279,13 @@ VkResult anv_GetSwapchainGrallocUsageANDROID(
   "inside %s", __func__);
   }

-   /* Reject STORAGE here to avoid complexity elsewhere. */
-   if (imageUsage & VK_IMAGE_USAGE_STORAGE_BIT) {
-  return vk_errorf(device->instance, device, VK_ERROR_FORMAT_NOT_SUPPORTED,
-   "VK_IMAGE_USAGE_STORAGE_BIT unsupported for gralloc "
-   "swapchain");
-   }
-
   if (unmask32(, VK_IMAGE_USAGE_TRANSFER_DST_BIT |
 VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT))
  *grallocUsage |= GRALLOC_USAGE_HW_RENDER;

   if (unmask32(, VK_IMAGE_USAGE_TRANSFER_SRC_BIT |
 VK_IMAGE_USAGE_SAMPLE

Re: [Mesa-dev] [PATCH] anv/android: handle storage images in vkGetSwapchainGrallocUsageANDROID

[Tapani Pälli]

On 12/5/18 1:22 PM, Bas Nieuwenhuizen wrote:

On Wed, Dec 5, 2018 at 12:15 PM Tapani Pälli  wrote:




On 12/5/18 1:01 PM, Bas Nieuwenhuizen wrote:

On Fri, Sep 7, 2018 at 12:54 AM Kevin Strasser  wrote:


Android P and earlier expect that the surface supports storage images, and
so many of the tests fail when the framework checks for that support. The
framework also includes various image format and usage combinations that are
invalid for the hardware.

Drop the STORAGE restriction from the HAL and whitelist a pair of
formats so that existing versions of Android can pass these tests.

Fixes:
 dEQP-VK.wsi.android.*

Signed-off-by: Kevin Strasser 
---
   src/intel/vulkan/anv_android.c | 23 ++-
   1 file changed, 14 insertions(+), 9 deletions(-)

diff --git a/src/intel/vulkan/anv_android.c b/src/intel/vulkan/anv_android.c
index 46c41d5..e2640b8 100644
--- a/src/intel/vulkan/anv_android.c
+++ b/src/intel/vulkan/anv_android.c
@@ -234,7 +234,7 @@ VkResult anv_GetSwapchainGrallocUsageANDROID(
  *grallocUsage = 0;
  intel_logd("%s: format=%d, usage=0x%x", __func__, format, imageUsage);

-   /* WARNING: Android Nougat's libvulkan.so hardcodes the VkImageUsageFlags
+   /* WARNING: Android's libvulkan.so hardcodes the VkImageUsageFlags
   * returned to applications via 
VkSurfaceCapabilitiesKHR::supportedUsageFlags.
   * The relevant code in libvulkan/swapchain.cpp contains this fun comment:
   *
@@ -247,7 +247,7 @@ VkResult anv_GetSwapchainGrallocUsageANDROID(
   * dEQP-VK.wsi.android.swapchain.*.image_usage to fail.
   */

-   const VkPhysicalDeviceImageFormatInfo2KHR image_format_info = {
+   VkPhysicalDeviceImageFormatInfo2KHR image_format_info = {


Why remove the const here?


 .sType = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_FORMAT_INFO_2_KHR,
 .format = format,
 .type = VK_IMAGE_TYPE_2D,
@@ -255,6 +255,17 @@ VkResult anv_GetSwapchainGrallocUsageANDROID(
 .usage = imageUsage,
  };

+   /* Android P and earlier doesn't check if the physical device supports a
+* given format and usage combination before calling this function. Omit the
+* storage requirement to make the tests pass.
+*/
+#if ANDROID_API_LEVEL <= 28
+   if (format == VK_FORMAT_R8G8B8A8_SRGB ||
+   format == VK_FORMAT_R5G6B5_UNORM_PACK16) {
+  image_format_info.usage &= ~VK_IMAGE_USAGE_STORAGE_BIT;
+   }
+#endif


I don't think you need this. Per the vulkan spec you can only use an
format + usage combination for a swapchain if it is supported per
ImageFormatProperties, using essentially the same check happening
above. I know CTs has been bad at this, but Vulkan CTS should have
been fixed for a bit now. (I don't think all the fixes are in Android
CTS 9.0_r4 yet, maybe the next release?)


AFAIK the problem here is not about CTS. It's the swapchain
implementation that always requires storage support.


Actually swapchain creation has the following valid usage rule:

"The implied image creation parameters of the swapchain must be
supported as reported by vkGetPhysicalDeviceImageFormatProperties"

So since those formats don't support the STORAGE usage bit, that test
fails and you are not allowed to create a swapchain with those formats
and storage, even if the surface capabiliities expose the STORAGE
usage bit in general.


Right ... this stuff was done because comment in the swapchain setting 
the bits seems like maybe it's not thought through:


// TODO(jessehall): I think these are right, but haven't thought hard about
// it. Do we need to query the driver for support of any of these?




(Also silently removing the usage bit is bad, because the app could
try actually using images stores with the image ...)


True, it is not nice ..



+
  VkImageFormatProperties2KHR image_format_props = {
 .sType = VK_STRUCTURE_TYPE_IMAGE_FORMAT_PROPERTIES_2_KHR,
  };
@@ -268,19 +279,13 @@ VkResult anv_GetSwapchainGrallocUsageANDROID(
  "inside %s", __func__);
  }

-   /* Reject STORAGE here to avoid complexity elsewhere. */
-   if (imageUsage & VK_IMAGE_USAGE_STORAGE_BIT) {
-  return vk_errorf(device->instance, device, VK_ERROR_FORMAT_NOT_SUPPORTED,
-   "VK_IMAGE_USAGE_STORAGE_BIT unsupported for gralloc "
-   "swapchain");
-   }
-
  if (unmask32(, VK_IMAGE_USAGE_TRANSFER_DST_BIT |
VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT))
 *grallocUsage |= GRALLOC_USAGE_HW_RENDER;

  if (unmask32(, VK_IMAGE_USAGE_TRANSFER_SRC_BIT |
VK_IMAGE_USAGE_SAMPLED_BIT |
+ VK_IMAGE_USAGE_STORAGE_BIT |
VK_IMAGE_USAGE_INPUT_ATTACHMENT_BIT))
 *grallocUsage |= GRALLOC_USAGE_HW_TEXTURE;

--
2.7.4

___
mesa-dev mailing list
mesa-dev@lists.freedes

Re: [Mesa-dev] [PATCH] anv/android: handle storage images in vkGetSwapchainGrallocUsageANDROID

[Tapani Pälli]

On 12/5/18 1:01 PM, Bas Nieuwenhuizen wrote:

On Fri, Sep 7, 2018 at 12:54 AM Kevin Strasser  wrote:


Android P and earlier expect that the surface supports storage images, and
so many of the tests fail when the framework checks for that support. The
framework also includes various image format and usage combinations that are
invalid for the hardware.

Drop the STORAGE restriction from the HAL and whitelist a pair of
formats so that existing versions of Android can pass these tests.

Fixes:
dEQP-VK.wsi.android.*

Signed-off-by: Kevin Strasser 
---
  src/intel/vulkan/anv_android.c | 23 ++-
  1 file changed, 14 insertions(+), 9 deletions(-)

diff --git a/src/intel/vulkan/anv_android.c b/src/intel/vulkan/anv_android.c
index 46c41d5..e2640b8 100644
--- a/src/intel/vulkan/anv_android.c
+++ b/src/intel/vulkan/anv_android.c
@@ -234,7 +234,7 @@ VkResult anv_GetSwapchainGrallocUsageANDROID(
 *grallocUsage = 0;
 intel_logd("%s: format=%d, usage=0x%x", __func__, format, imageUsage);

-   /* WARNING: Android Nougat's libvulkan.so hardcodes the VkImageUsageFlags
+   /* WARNING: Android's libvulkan.so hardcodes the VkImageUsageFlags
  * returned to applications via 
VkSurfaceCapabilitiesKHR::supportedUsageFlags.
  * The relevant code in libvulkan/swapchain.cpp contains this fun comment:
  *
@@ -247,7 +247,7 @@ VkResult anv_GetSwapchainGrallocUsageANDROID(
  * dEQP-VK.wsi.android.swapchain.*.image_usage to fail.
  */

-   const VkPhysicalDeviceImageFormatInfo2KHR image_format_info = {
+   VkPhysicalDeviceImageFormatInfo2KHR image_format_info = {


Why remove the const here?


.sType = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_FORMAT_INFO_2_KHR,
.format = format,
.type = VK_IMAGE_TYPE_2D,
@@ -255,6 +255,17 @@ VkResult anv_GetSwapchainGrallocUsageANDROID(
.usage = imageUsage,
 };

+   /* Android P and earlier doesn't check if the physical device supports a
+* given format and usage combination before calling this function. Omit the
+* storage requirement to make the tests pass.
+*/
+#if ANDROID_API_LEVEL <= 28
+   if (format == VK_FORMAT_R8G8B8A8_SRGB ||
+   format == VK_FORMAT_R5G6B5_UNORM_PACK16) {
+  image_format_info.usage &= ~VK_IMAGE_USAGE_STORAGE_BIT;
+   }
+#endif


I don't think you need this. Per the vulkan spec you can only use an
format + usage combination for a swapchain if it is supported per
ImageFormatProperties, using essentially the same check happening
above. I know CTs has been bad at this, but Vulkan CTS should have
been fixed for a bit now. (I don't think all the fixes are in Android
CTS 9.0_r4 yet, maybe the next release?)


AFAIK the problem here is not about CTS. It's the swapchain 
implementation that always requires storage support.



(Also silently removing the usage bit is bad, because the app could
try actually using images stores with the image ...)


True, it is not nice ..



+
 VkImageFormatProperties2KHR image_format_props = {
.sType = VK_STRUCTURE_TYPE_IMAGE_FORMAT_PROPERTIES_2_KHR,
 };
@@ -268,19 +279,13 @@ VkResult anv_GetSwapchainGrallocUsageANDROID(
 "inside %s", __func__);
 }

-   /* Reject STORAGE here to avoid complexity elsewhere. */
-   if (imageUsage & VK_IMAGE_USAGE_STORAGE_BIT) {
-  return vk_errorf(device->instance, device, VK_ERROR_FORMAT_NOT_SUPPORTED,
-   "VK_IMAGE_USAGE_STORAGE_BIT unsupported for gralloc "
-   "swapchain");
-   }
-
 if (unmask32(, VK_IMAGE_USAGE_TRANSFER_DST_BIT |
   VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT))
*grallocUsage |= GRALLOC_USAGE_HW_RENDER;

 if (unmask32(, VK_IMAGE_USAGE_TRANSFER_SRC_BIT |
   VK_IMAGE_USAGE_SAMPLED_BIT |
+ VK_IMAGE_USAGE_STORAGE_BIT |
   VK_IMAGE_USAGE_INPUT_ATTACHMENT_BIT))
*grallocUsage |= GRALLOC_USAGE_HW_TEXTURE;

--
2.7.4

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

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


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

Re: [Mesa-dev] [PATCH] anv/android: Do not reject storage images.

[Tapani Pälli]

On 12/5/18 12:34 PM, Bas Nieuwenhuizen wrote:

We do the ImageFormatProperties check already, and rejecting an usage
flag when both ImageFormatProperties and the WSI (which is Android)
support it is not allowed.

Intel does support storage for some of the support WSI formats, such
as R8G8B8A8_UNORM, and looking at the ISL_SURF_USAGE_DISABLE_AUX_BIT,
the imported images do not have any form of compression that would
prevent this fix.


Bas FYI, we have this one used internally:

https://patchwork.freedesktop.org/patch/247681/



Fixes: 053d4c328fa "anv: Implement VK_ANDROID_native_buffer (v9)"
CC: Jason Ekstrand 
---
  src/intel/vulkan/anv_android.c | 7 ---
  1 file changed, 7 deletions(-)

diff --git a/src/intel/vulkan/anv_android.c b/src/intel/vulkan/anv_android.c
index a3bab8087b4..92c3787b49b 100644
--- a/src/intel/vulkan/anv_android.c
+++ b/src/intel/vulkan/anv_android.c
@@ -268,13 +268,6 @@ VkResult anv_GetSwapchainGrallocUsageANDROID(
 "inside %s", __func__);
 }
  
-   /* Reject STORAGE here to avoid complexity elsewhere. */

-   if (imageUsage & VK_IMAGE_USAGE_STORAGE_BIT) {
-  return vk_errorf(device->instance, device, VK_ERROR_FORMAT_NOT_SUPPORTED,
-   "VK_IMAGE_USAGE_STORAGE_BIT unsupported for gralloc "
-   "swapchain");
-   }
-
 if (unmask32(, VK_IMAGE_USAGE_TRANSFER_DST_BIT |
   VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT))
*grallocUsage |= GRALLOC_USAGE_HW_RENDER;


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

Re: [Mesa-dev] [PATCH 2/2] i965: Set the FBO error state INCOMPLETE_ATTACHMENT only for SRGB_R8

[Tapani Pälli]

On 11/22/18 8:00 PM, Gert Wollny wrote:

Originally the driver reported GL_FRAMEBUFFER_UNSUPPORTED in all cases,
adding more specific error messages was not correct and broke many tests.
Mostly revert this and only report GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT
for MESA_FORMAT_R_SRGB8.

Fixes: ebcde3454552adc6d3fea8af2207aafaba857796
   i965: be more specific about FBO completeness errors


Like with patch 1, fix 'Fixes', with that
Reviewed-by: Tapani Pälli 



Signed-off-by: Gert Wollny 
---
  src/mesa/drivers/dri/i965/intel_fbo.c | 13 ++---
  1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_fbo.c 
b/src/mesa/drivers/dri/i965/intel_fbo.c
index 7e40d61a47..5bcd846a1b 100644
--- a/src/mesa/drivers/dri/i965/intel_fbo.c
+++ b/src/mesa/drivers/dri/i965/intel_fbo.c
@@ -719,7 +719,7 @@ intel_validate_framebuffer(struct gl_context *ctx, struct 
gl_framebuffer *fb)
"FBO incomplete: separate stencil unsupported\n");
 }
 if (stencil_mt->format != MESA_FORMAT_S_UINT8) {
-   fbo_incomplete(fb, GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT,
+   fbo_incomplete(fb, GL_FRAMEBUFFER_UNSUPPORTED,
"FBO incomplete: separate stencil is %s "
"instead of S8\n",
_mesa_get_format_name(stencil_mt->format));
@@ -750,7 +750,7 @@ intel_validate_framebuffer(struct gl_context *ctx, struct 
gl_framebuffer *fb)
 */
rb = fb->Attachment[i].Renderbuffer;
if (rb == NULL) {
-fbo_incomplete(fb, GL_FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT,
+fbo_incomplete(fb, GL_FRAMEBUFFER_UNSUPPORTED,
 "FBO incomplete: attachment without "
 "renderbuffer\n");
 continue;
@@ -771,8 +771,15 @@ intel_validate_framebuffer(struct gl_context *ctx, struct 
gl_framebuffer *fb)
 continue;
}
  
+ if (rb->Format == MESA_FORMAT_R_SRGB8) {

+fbo_incomplete(fb, GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT,
+   "FBO incomplete: Format not color renderable: %s\n",
+   _mesa_get_format_name(rb->Format));
+continue;
+ }
+
if (!brw_render_target_supported(brw, rb)) {
-fbo_incomplete(fb, GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT,
+fbo_incomplete(fb, GL_FRAMEBUFFER_UNSUPPORTED,
 "FBO incomplete: Unsupported HW "
 "texture/renderbuffer format attached: %s\n",
 _mesa_get_format_name(intel_rb_format(irb)));


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

Re: [Mesa-dev] [PATCH 1/2] i965: Explicitely handle swizzles for MESA_FORMAT_R_SRGB8

[Tapani Pälli]

On 11/22/18 8:00 PM, Gert Wollny wrote:

The format is emulated by using ISL_FORMAT_L8_SRGB, therefore we need to
force swizzles for the GBA channels. However, doing this only based on the
data type GL_RED breaks other formats, therefore, test specifically for the
format.

Fixes: 5363869d4971780401b21bb75083ef2518c12be
   965: Force zero swizzles for unused components in GL_RED and GL_RG


As Emil said, 'Fixes' line needs to be fixed before committing. 
Otherwise this LGTM;


Reviewed-by: Tapani Pälli 


Signed-off-by: Gert Wollny 
---
  src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 10 +++---
  1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c 
b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
index 018bae98e8..4daa0e2add 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
@@ -420,11 +420,15 @@ brw_get_texture_swizzle(const struct gl_context *ctx,
}
break;
 case GL_RED:
-  swizzles[1] = SWIZZLE_ZERO;
+  if (img->TexFormat == MESA_FORMAT_R_SRGB8) {
+ swizzles[0] = SWIZZLE_X;
+ swizzles[1] = SWIZZLE_ZERO;
+ swizzles[2] = SWIZZLE_ZERO;
+ swizzles[3] = SWIZZLE_ONE;
+ break;
+  }
/* fallthrough */
 case GL_RG:
-  swizzles[2] = SWIZZLE_ZERO;
-  /* fallthrough */
 case GL_RGB:
if (_mesa_get_format_bits(img->TexFormat, GL_ALPHA_BITS) > 0 ||
img->TexFormat == MESA_FORMAT_RGB_DXT1 ||


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

[Mesa-dev] [PATCH 10/15] anv/android: support creating images from external format

[Tapani Pälli]

Since we don't know the exact format at creation time, some initialization
is done only when bound with memory in vkBindImageMemory.

v2: demand dedicated allocation in vkGetImageMemoryRequirements2 if
image has external format

v3: refactor prepare_ahw_image, support vkBindImageMemory2,
calculate stride correctly for rgb(x) surfaces, rename as
'resolve_ahw_image'

v4: rebase to b43f955037c changes

Signed-off-by: Tapani Pälli 
---
 src/intel/vulkan/anv_android.c   |  36 ++
 src/intel/vulkan/anv_android.h   |   8 +++
 src/intel/vulkan/anv_android_stubs.c |  10 +++
 src/intel/vulkan/anv_device.c|   2 +-
 src/intel/vulkan/anv_image.c | 103 ++-
 src/intel/vulkan/anv_private.h   |   4 ++
 6 files changed, 160 insertions(+), 3 deletions(-)

diff --git a/src/intel/vulkan/anv_android.c b/src/intel/vulkan/anv_android.c
index bdc720214c4..3bc2b63b1c9 100644
--- a/src/intel/vulkan/anv_android.c
+++ b/src/intel/vulkan/anv_android.c
@@ -356,6 +356,42 @@ anv_create_ahw_memory(VkDevice device_h,
return VK_SUCCESS;
 }
 
+VkResult
+anv_image_from_external(
+   VkDevice device_h,
+   const VkImageCreateInfo *base_info,
+   const struct VkExternalMemoryImageCreateInfo *create_info,
+   const VkAllocationCallbacks *alloc,
+   VkImage *out_image_h)
+{
+   ANV_FROM_HANDLE(anv_device, device, device_h);
+
+   const struct VkExternalFormatANDROID *ext_info =
+  vk_find_struct_const(base_info->pNext, EXTERNAL_FORMAT_ANDROID);
+
+   if (ext_info && ext_info->externalFormat != 0) {
+  assert(base_info->format == VK_FORMAT_UNDEFINED);
+  assert(base_info->imageType == VK_IMAGE_TYPE_2D);
+  assert(base_info->usage == VK_IMAGE_USAGE_SAMPLED_BIT);
+  assert(base_info->tiling == VK_IMAGE_TILING_OPTIMAL);
+   }
+
+   struct anv_image_create_info anv_info = {
+  .vk_info = base_info,
+  .isl_extra_usage_flags = ISL_SURF_USAGE_DISABLE_AUX_BIT,
+  .external_format = true,
+   };
+
+   VkImage image_h;
+   VkResult result = anv_image_create(device_h, _info, alloc, _h);
+   if (result != VK_SUCCESS)
+  return result;
+
+   *out_image_h = image_h;
+
+   return VK_SUCCESS;
+}
+
 VkResult
 anv_image_from_gralloc(VkDevice device_h,
const VkImageCreateInfo *base_info,
diff --git a/src/intel/vulkan/anv_android.h b/src/intel/vulkan/anv_android.h
index 01f0e856291..d5c073126e3 100644
--- a/src/intel/vulkan/anv_android.h
+++ b/src/intel/vulkan/anv_android.h
@@ -29,6 +29,8 @@
 #include 
 
 struct anv_device_memory;
+struct anv_device;
+struct anv_image;
 
 VkResult anv_image_from_gralloc(VkDevice device_h,
 const VkImageCreateInfo *base_info,
@@ -36,6 +38,12 @@ VkResult anv_image_from_gralloc(VkDevice device_h,
 const VkAllocationCallbacks *alloc,
 VkImage *pImage);
 
+VkResult anv_image_from_external(VkDevice device_h,
+ const VkImageCreateInfo *base_info,
+ const struct VkExternalMemoryImageCreateInfo 
*create_info,
+ const VkAllocationCallbacks *alloc,
+ VkImage *out_image_h);
+
 uint64_t anv_ahw_usage_from_vk_usage(const VkImageCreateFlags vk_create,
  const VkImageUsageFlags vk_usage);
 
diff --git a/src/intel/vulkan/anv_android_stubs.c 
b/src/intel/vulkan/anv_android_stubs.c
index ccc16500494..a34afc198a1 100644
--- a/src/intel/vulkan/anv_android_stubs.c
+++ b/src/intel/vulkan/anv_android_stubs.c
@@ -55,3 +55,13 @@ anv_create_ahw_memory(VkDevice device_h,
 {
return VK_ERROR_EXTENSION_NOT_PRESENT;
 }
+
+VkResult
+anv_image_from_external(VkDevice device_h,
+const VkImageCreateInfo *base_info,
+const struct VkExternalMemoryImageCreateInfo 
*create_info,
+const VkAllocationCallbacks *alloc,
+VkImage *out_image_h)
+{
+   return VK_ERROR_EXTENSION_NOT_PRESENT;
+}
diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index a1ee9315956..5777de96d80 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -2768,7 +2768,7 @@ void anv_GetImageMemoryRequirements2(
   switch (ext->sType) {
   case VK_STRUCTURE_TYPE_MEMORY_DEDICATED_REQUIREMENTS: {
  VkMemoryDedicatedRequirements *requirements = (void *)ext;
- if (image->needs_set_tiling) {
+ if (image->needs_set_tiling || image->external_format) {
 /* If we need to set the tiling for external consumers, we need a
  * dedicated allocation.
  *
diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
index 59e9d007831..79777efe456 100644
--- a/src/intel/vulkan/anv_image.c
+++ b/src/intel/vulkan/anv_image.c
@@ -594,6 +594,15 @@ anv_image_create(VkDev

[Mesa-dev] [PATCH 07/15] anv: refactor, remove else block in AllocateMemory

[Tapani Pälli]

This makes it cleaner to introduce more cases where we import memory
from different types of external memory buffers.

Signed-off-by: Tapani Pälli 
---
 src/intel/vulkan/anv_device.c | 64 +++
 1 file changed, 34 insertions(+), 30 deletions(-)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 6b5ba25c6bc..0cbbaeca3b3 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -2340,42 +2340,46 @@ VkResult anv_AllocateMemory(
* If the import fails, we leave the file descriptor open.
*/
   close(fd_info->fd);
-   } else {
-  const VkExportMemoryAllocateInfoKHR *fd_info =
- vk_find_struct_const(pAllocateInfo->pNext, 
EXPORT_MEMORY_ALLOCATE_INFO_KHR);
-  if (fd_info && fd_info->handleTypes)
- bo_flags |= ANV_BO_EXTERNAL;
-
-  result = anv_bo_cache_alloc(device, >bo_cache,
-  pAllocateInfo->allocationSize, bo_flags,
-  >bo);
-  if (result != VK_SUCCESS)
- goto fail;
+  goto success;
+   }
 
-  const VkMemoryDedicatedAllocateInfoKHR *dedicated_info =
- vk_find_struct_const(pAllocateInfo->pNext, 
MEMORY_DEDICATED_ALLOCATE_INFO_KHR);
-  if (dedicated_info && dedicated_info->image != VK_NULL_HANDLE) {
- ANV_FROM_HANDLE(anv_image, image, dedicated_info->image);
+   /* Regular allocate (not importing memory). */
 
- /* Some legacy (non-modifiers) consumers need the tiling to be set on
-  * the BO.  In this case, we have a dedicated allocation.
-  */
- if (image->needs_set_tiling) {
-const uint32_t i915_tiling =
-   isl_tiling_to_i915_tiling(image->planes[0].surface.isl.tiling);
-int ret = anv_gem_set_tiling(device, mem->bo->gem_handle,
- 
image->planes[0].surface.isl.row_pitch_B,
- i915_tiling);
-if (ret) {
-   anv_bo_cache_release(device, >bo_cache, mem->bo);
-   return vk_errorf(device->instance, NULL,
-VK_ERROR_OUT_OF_DEVICE_MEMORY,
-"failed to set BO tiling: %m");
-}
+   const VkExportMemoryAllocateInfoKHR *export_info =
+  vk_find_struct_const(pAllocateInfo->pNext, 
EXPORT_MEMORY_ALLOCATE_INFO_KHR);
+   if (export_info && export_info->handleTypes)
+  bo_flags |= ANV_BO_EXTERNAL;
+
+   result = anv_bo_cache_alloc(device, >bo_cache,
+   pAllocateInfo->allocationSize, bo_flags,
+   >bo);
+   if (result != VK_SUCCESS)
+  goto fail;
+
+   const VkMemoryDedicatedAllocateInfoKHR *dedicated_info =
+  vk_find_struct_const(pAllocateInfo->pNext, 
MEMORY_DEDICATED_ALLOCATE_INFO_KHR);
+   if (dedicated_info && dedicated_info->image != VK_NULL_HANDLE) {
+  ANV_FROM_HANDLE(anv_image, image, dedicated_info->image);
+
+  /* Some legacy (non-modifiers) consumers need the tiling to be set on
+   * the BO.  In this case, we have a dedicated allocation.
+   */
+  if (image->needs_set_tiling) {
+ const uint32_t i915_tiling =
+isl_tiling_to_i915_tiling(image->planes[0].surface.isl.tiling);
+ int ret = anv_gem_set_tiling(device, mem->bo->gem_handle,
+  image->planes[0].surface.isl.row_pitch_B,
+  i915_tiling);
+ if (ret) {
+anv_bo_cache_release(device, >bo_cache, mem->bo);
+return vk_errorf(device->instance, NULL,
+ VK_ERROR_OUT_OF_DEVICE_MEMORY,
+ "failed to set BO tiling: %m");
  }
   }
}
 
+ success:
*pMem = anv_device_memory_to_handle(mem);
 
return VK_SUCCESS;
-- 
2.17.2

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