Re: [Mesa-dev] what happened to libgallium.so ?

[Enrico Weigelt, metux IT consult]

On 03.08.2016 18:09, Marek Olšák wrote:
> It has always been statically linked as far as I remember.
> libgallium.so is a Ubuntu speciality that we don't support.

on win32 (using scons), it doesn't seem to be the case:

https://github.com/metux/mesa/blob/a44ed2123ea6c84df9d00cdc12162112f20ed57e/src/glx/SConscript#L44

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

Re: [Mesa-dev] __func__ vs. __FUNCTION__

[Enrico Weigelt, metux IT consult]

On 03.08.2016 12:20, Eric Engestrom wrote:

> BTW, c99_compat.h has a #define for __func__ where needed, so this
> change (removing use of __FUNCTION__) is a good one indeed :)

Did a few experiments w/ gcc vs msvc. The common denominator is
both define __FUNCTION__, so I moved there and dropped the defines
in c99_compat.h.


See: https://github.com/metux/mesa/commits/WIP_cleanup


--mtx

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

Re: [Mesa-dev] OpenCL for radeon Hawaii?

[Aaron Watry]

It looks like CLBlast makes the same mistake that the CLU library did until
recently (fixed in 435957d667bc22cdb2f0bdc32).

It assumes that if your system has OpenCL 2.0 headers installed that the
OpenCL platforms present on the system also support CL 2.0.

In the case of Mesa, it doesn't support clCreateCommandQueueWithProperties
which was introduced in CL 2.0, and so CLBlast (or the ocl icd) segfaults
when it tries to call that function.

The relevant code CLBlast (CLBlast/src/clpp11.hpp around line 388) is:
#ifdef CL_VERSION_2_0
  cl_queue_properties properties[] = {CL_QUEUE_PROPERTIES,
CL_QUEUE_PROFILING_ENABLE, 0};
  *queue_ = clCreateCommandQueueWithProperties(context(), device(),
properties, );
#else
  *queue_ = clCreateCommandQueue(context(), device(),
CL_QUEUE_PROFILING_ENABLE, );
#endif


The fix that I sent to CLU changed its code to call clGetPlatformInfo to
fetch CL_PLATFORM_VERSION, and then checked the returned string for "OpenCL
1." in order to check if clCreateCommandQueueWithProperties was safe to
invoke.

You still need some if-deffery to get it to compile against CL 1.x headers,
but at least it doesn't crash then and remains compatible.

Given that CLBlast claims to support CL 1.x, this should probably get filed
as a bug with them. When I modified the code in CLBlast to call
clCreateCommandQueue(), it stopped crashing and the clblast_test_xdot test
started passing.

Note: I found this using valgrind, which is always a great tool for
diagnosing crashing crashing C/C++ programs that you have the source (or
debug symbols) for.

--Aaron



On Wed, Aug 3, 2016 at 2:45 PM, Sam Halliday  wrote:

> Hello everybody,
>
> I recently got a Radeon R9 290x (aka Hawaii). I run ArchLinux, which has
> mesa 12.0.1.
>
> I am keen to try out mesa's partial OpenCL implementation. Ideally to
> use a BLAS implementation such as https://github.com/CNugteren/CLBlast
> but I'd also be happy to just write something basic like dense
> matrix/matrix multiplication in OpenCL.
>
>
> However, when I tried to run the "luxmark" OpenCL benchmark (the only
> way I could think to test if my card is supported), I got this error
>
> [PathOCLBaseRenderThread::0] Compiling kernels
> [PathOCLBaseRenderThread::0] PathOCL kernel compilation error ERROR
> clBuildProgram[CL_INVALID_BUILD_OPTIONS]:
> RUNTIME ERROR: PathOCLBase kernel compilation error
>
> which, I'm guessing, means that my GPU isn't supported for OpenCL by
> mesa yet. Is that correct? (I don't know how to get any more output or
> logs than this).
>
>
> Could somebody please help by letting me know if there is a ticket I
> could subscribe to track progress of support for my card (a simple
> search of the bug database didn't bring up anything obvious). This
> message is to the -dev list, so I am suppose I am saying that I am
> prepared to get my hands dirty... but I am primarily a Scala developer
> and haven't done any C in years so the extent of my help is limited.
>
> If somebody who knows what they are doing would be willing to implement
> some of the functionality needed, I'd be prepared to buy this GPU for
> them to use for their hacking - it's the least I could do (but it is an
> absolute monster, I didn't even know GPUs could be this big! I needed to
> get a bigger case for it).
>
>
> Somewhat tangentially, if OpenCL support is really not a possibility
> anytime soon, could somebody please point me in the direction of a way
> to use this card programmatically for something like matrix/matrix
> multiplication? (I'm prepared to go really low level if there is
> sufficient documentation).
>
>
> I'm not at all interested in using proprietary drivers for OpenCL.
>
>
> --
> Best regards,
> Sam
> ___
> 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] egl/x11: avoid using freed memory if dri2 init fails

[Nicolas Boichat]

Thanks! See also related series here, which fixes the other platforms:
https://lists.freedesktop.org/archives/mesa-dev/2016-August/125147.html

On Sun, Jul 31, 2016 at 9:44 PM, Jan Ziak <0xe2.0x9a.0...@gmail.com> wrote:
> Found with valgrind:
>
> ==4841== Invalid read of size 4
> ==4841==at 0x56BDC80: dri2_initialize (egl_dri2.c:783)
> ==4841==by 0x56BAFE5: _eglMatchAndInitialize (egldriver.c:261)
> ==4841==by 0x56BB15E: _eglMatchDriver (egldriver.c:295)
> ==4841==by 0x56B58C9: eglInitialize (eglapi.c:480)
> ==4841==by 0x4F537DC: _glfwInitEGL (in /usr/lib64/libglfw.so.3.2)
> ==4841==by 0x4F4BEFB: _glfwPlatformInit (in /usr/lib64/libglfw.so.3.2)
> ==4841==by 0x4F46F40: glfwInit (in /usr/lib64/libglfw.so.3.2)
> ==4841==by 0x402E59: main
> ==4841==  Address 0x6a05824 is 148 bytes inside a block of size 480 free'd
> ==4841==at 0x4C2B680: free (in 
> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==4841==by 0x56C2AAE: dri2_initialize_x11_swrast (platform_x11.c:1233)
> ==4841==by 0x56C2AAE: dri2_initialize_x11 (platform_x11.c:1493)
> ==4841==by 0x56BDCEB: dri2_initialize (egl_dri2.c:805)
> ==4841==by 0x56BAFAF: _eglMatchAndInitialize (egldriver.c:261)
> ==4841==by 0x56BB0C9: _eglMatchDriver (egldriver.c:292)
> ==4841==by 0x56B58C9: eglInitialize (eglapi.c:480)
> ==4841==by 0x4F537DC: _glfwInitEGL (in /usr/lib64/libglfw.so.3.2)
> ==4841==by 0x4F4BEFB: _glfwPlatformInit (in /usr/lib64/libglfw.so.3.2)
> ==4841==by 0x4F46F40: glfwInit (in /usr/lib64/libglfw.so.3.2)
> ==4841==by 0x402E59: main
> ==4841==  Block was alloc'd at
> ==4841==at 0x4C2A868: calloc (in 
> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==4841==by 0x56C2A47: dri2_initialize_x11_swrast (platform_x11.c:1171)
> ==4841==by 0x56C2A47: dri2_initialize_x11 (platform_x11.c:1493)
> ==4841==by 0x56BDCEB: dri2_initialize (egl_dri2.c:805)
> ==4841==by 0x56BAFAF: _eglMatchAndInitialize (egldriver.c:261)
> ==4841==by 0x56BB0C9: _eglMatchDriver (egldriver.c:292)
> ==4841==by 0x56B58C9: eglInitialize (eglapi.c:480)
> ==4841==by 0x4F537DC: _glfwInitEGL (in /usr/lib64/libglfw.so.3.2)
> ==4841==by 0x4F4BEFB: _glfwPlatformInit (in /usr/lib64/libglfw.so.3.2)
> ==4841==by 0x4F46F40: glfwInit (in /usr/lib64/libglfw.so.3.2)
> ==4841==by 0x402E59: main
>
> Signed-off-by: Jan Ziak (http://atom-symbol.net) <0xe2.0x9a.0...@gmail.com>

Fixes: 9ee683f877 (egl/dri2: Add reference count for dri2_egl_display)
Cc: "12.0" 
Reviewed-by: Nicolas Boichat 

> ---
>  src/egl/drivers/dri2/platform_x11.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/src/egl/drivers/dri2/platform_x11.c 
> b/src/egl/drivers/dri2/platform_x11.c
> index c0a4005..686552c 100644
> --- a/src/egl/drivers/dri2/platform_x11.c
> +++ b/src/egl/drivers/dri2/platform_x11.c
> @@ -1231,6 +1231,7 @@ dri2_initialize_x11_swrast(_EGLDriver *drv, _EGLDisplay 
> *disp)
>xcb_disconnect(dri2_dpy->conn);
>   cleanup_dpy:
> free(dri2_dpy);
> +   disp->DriverData = NULL;
>
> return EGL_FALSE;
>  }
> @@ -1370,6 +1371,7 @@ dri2_initialize_x11_dri3(_EGLDriver *drv, _EGLDisplay 
> *disp)
>xcb_disconnect(dri2_dpy->conn);
>   cleanup_dpy:
> free(dri2_dpy);
> +   disp->DriverData = NULL;
>
> return EGL_FALSE;
>  }
> @@ -1467,6 +1469,7 @@ dri2_initialize_x11_dri2(_EGLDriver *drv, _EGLDisplay 
> *disp)
>xcb_disconnect(dri2_dpy->conn);
>   cleanup_dpy:
> free(dri2_dpy);
> +   disp->DriverData = NULL;
>
> return EGL_FALSE;
>  }
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/4] egl/surfaceless: Set disp->DriverData to NULL on error

[Nicolas Boichat]

Avoid use-after-free on error.

Fixes: 9ee683f877 (egl/dri2: Add reference count for dri2_egl_display)
Cc: "12.0" 
Signed-off-by: Nicolas Boichat 
---
 src/egl/drivers/dri2/platform_surfaceless.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/egl/drivers/dri2/platform_surfaceless.c 
b/src/egl/drivers/dri2/platform_surfaceless.c
index 8ce6162..e0d383b 100644
--- a/src/egl/drivers/dri2/platform_surfaceless.c
+++ b/src/egl/drivers/dri2/platform_surfaceless.c
@@ -362,6 +362,7 @@ cleanup_driver:
close(dri2_dpy->fd);
 cleanup_display:
free(dri2_dpy);
+   disp->DriverData = NULL;
 
return _eglError(EGL_NOT_INITIALIZED, err);
 }
-- 
2.8.0.rc3.226.g39d4020

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

[Mesa-dev] [PATCH 3/4] egl/drm: Set disp->DriverData to NULL on error

[Nicolas Boichat]

Avoid use-after-free on error.

Fixes: 9ee683f877 (egl/dri2: Add reference count for dri2_egl_display)
Cc: "12.0" 
Signed-off-by: Nicolas Boichat 
---
 src/egl/drivers/dri2/platform_drm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/egl/drivers/dri2/platform_drm.c 
b/src/egl/drivers/dri2/platform_drm.c
index 9373496..1ce282f 100644
--- a/src/egl/drivers/dri2/platform_drm.c
+++ b/src/egl/drivers/dri2/platform_drm.c
@@ -726,5 +726,6 @@ cleanup:
   close(fd);
 
free(dri2_dpy);
+   disp->DriverData = NULL;
return EGL_FALSE;
 }
-- 
2.8.0.rc3.226.g39d4020

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

[Mesa-dev] [PATCH 1/4] egl/wayland: Set disp->DriverData to NULL on error

[Nicolas Boichat]

Avoid use-after-free, fix spec@egl_khr_fence_sync@conformance.

Fixes: 9ee683f877 (egl/dri2: Add reference count for dri2_egl_display)
Cc: "12.0" 
Reported-by: Michel Dänzer 
Signed-off-by: Nicolas Boichat 
---
 src/egl/drivers/dri2/platform_wayland.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/egl/drivers/dri2/platform_wayland.c 
b/src/egl/drivers/dri2/platform_wayland.c
index e714e44..cbdcd76 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -1236,6 +1236,7 @@ dri2_initialize_wayland_drm(_EGLDriver *drv, _EGLDisplay 
*disp)
wl_event_queue_destroy(dri2_dpy->wl_queue);
  cleanup_dpy:
free(dri2_dpy);
+   disp->DriverData = NULL;
 
return EGL_FALSE;
 }
@@ -1881,6 +1882,7 @@ dri2_initialize_wayland_swrast(_EGLDriver *drv, 
_EGLDisplay *disp)
wl_event_queue_destroy(dri2_dpy->wl_queue);
  cleanup_dpy:
free(dri2_dpy);
+   disp->DriverData = NULL;
 
return EGL_FALSE;
 }
-- 
2.8.0.rc3.226.g39d4020

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

[Mesa-dev] [PATCH 4/4] egl/android: Set dpy->DriverData to NULL on error

[Nicolas Boichat]

Avoid use-after-free on error.

Fixes: 9ee683f877 (egl/dri2: Add reference count for dri2_egl_display)
Cc: "12.0" 
Signed-off-by: Nicolas Boichat 
---
 src/egl/drivers/dri2/platform_android.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/egl/drivers/dri2/platform_android.c 
b/src/egl/drivers/dri2/platform_android.c
index e3d5f0b..ffa7bba 100644
--- a/src/egl/drivers/dri2/platform_android.c
+++ b/src/egl/drivers/dri2/platform_android.c
@@ -889,6 +889,7 @@ cleanup_device:
close(dri2_dpy->fd);
 cleanup_display:
free(dri2_dpy);
+   dpy->DriverData = NULL;
 
return _eglError(EGL_NOT_INITIALIZED, err);
 }
-- 
2.8.0.rc3.226.g39d4020

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

[Mesa-dev] [PATCH 0/4] egl/*: Set disp->DriverData to NULL on error

[Nicolas Boichat]

egl/x11 fixup has already be sent here:
https://patchwork.freedesktop.org/patch/101934/

Compile-tested only (on android only).

I was first thinking of modifying most functions in egl_dri2.c to take in
dri2_egl_display *dri2_dpy instead of _EGLDisplay *disp as parameter, so
we do not need to set disp->DriverData early in the dri_initialize_* functions.

But there are some functions that do need disp as well:
 - dri2_add_config, to call _eglInitConfig (disp->DriverData does not need to be
   set), and to check if extensions are supported.
 - dri2_setup_screen (similar reasons)

Ideas to untangle this are welcome. In the mean time, this patch series should
fix crashes and a piglit test.

Nicolas Boichat (4):
  egl/wayland: Set disp->DriverData to NULL on error
  egl/surfaceless: Set disp->DriverData to NULL on error
  egl/drm: Set disp->DriverData to NULL on error
  egl/android: Set dpy->DriverData to NULL on error

 src/egl/drivers/dri2/platform_android.c | 1 +
 src/egl/drivers/dri2/platform_drm.c | 1 +
 src/egl/drivers/dri2/platform_surfaceless.c | 1 +
 src/egl/drivers/dri2/platform_wayland.c | 2 ++
 4 files changed, 5 insertions(+)

-- 
2.8.0.rc3.226.g39d4020

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

Re: [Mesa-dev] [PATCH] egl/dri2: dri2_initialize: Do not reference-count TestOnly display

[Nicolas Boichat]

On Thu, Aug 4, 2016 at 9:38 AM, Michel Dänzer  wrote:
> On 04.08.2016 09:53, Nicolas Boichat wrote:
>> On Thu, Aug 4, 2016 at 12:22 AM, Martin Peres
>>  wrote:
>>> On 03/08/16 16:54, Nicolas Boichat wrote:

 In the case where dri2_initialize is called with a TestOnly display,
 the display is not actually initialized, so dri2_egl_display always
 fails, and we cannot do any reference counting.

 Fixes piglit spec@egl_khr_create_context@verify gl flavor (reproducible
 with LIBGL_ALWAYS_SOFTWARE=1) and spec@egl_khr_fence_sync@conformance.

 Fixes: 9ee683f877 (egl/dri2: Add reference count for dri2_egl_display)
 Cc: "12.0" 
 Reported-by: Michel Dänzer 
 Signed-off-by: Nicolas Boichat 
 ---

 Compile-tested only, please give it a spin, thanks!
>>>
>>> Still crashes, same backtrace before and after the patch:
>>
>> Actually, I was thinking about this bug:
>> https://bugs.freedesktop.org/show_bug.cgi?id=97136, which should be
>> spec@egl_khr_create_context@verify gl flavor? Did you try that test?
>
> Your patch fixes this test for me.
>
> Tested-by: Michel Dänzer 
>
> Please remove the reference to the egl_khr_fence_sync test from the
> commit log.

Thanks.

Emil: Can you fixup the commit message before applying?

>> Not easy for me to reproduce, but... Looking that the test source code:
>> https://cgit.freedesktop.org/piglit/tree/tests/egl/spec/egl_khr_fence_sync/egl_khr_fence_sync.c
>>
>> Do you know why we end up in the error path in init_display?
>>
>> My guess is that
>> eglInitialize->dri2_initialize->dri2_initialize_wayland fails after
>> setting disp->DriverData, so the display refcount is == 0, but the
>> display is not null, leading to the crash in egl_terminate.
>>
>> I just spotted this patch for x11:
>> https://patchwork.freedesktop.org/patch/101934/
>>
>> platform_wayland needs to be modified in a similar way.
>
> Indeed, that fixes the egl_khr_fence_sync test for me FWIW.

I'll send a series to fix that very soon, on all platforms.

>> For the record, Emil spotted this issue when I submitted the offending
>> patch, and I haven't followed up ,-(
>
> For future patches, please make sure there are no piglit regressions, at
> least for the tests which run with swrast via LIBGL_ALWAYS_SOFTWARE=1.

Is there some simple instructions to do that? Or maybe some continuous
integration farm somewhere we can submit the patch to? (I see
appveyor.yml, but that's for Windows?)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] egl/dri2: dri2_initialize: Do not reference-count TestOnly display

[Michel Dänzer]

On 04.08.2016 09:53, Nicolas Boichat wrote:
> On Thu, Aug 4, 2016 at 12:22 AM, Martin Peres
>  wrote:
>> On 03/08/16 16:54, Nicolas Boichat wrote:
>>>
>>> In the case where dri2_initialize is called with a TestOnly display,
>>> the display is not actually initialized, so dri2_egl_display always
>>> fails, and we cannot do any reference counting.
>>>
>>> Fixes piglit spec@egl_khr_create_context@verify gl flavor (reproducible
>>> with LIBGL_ALWAYS_SOFTWARE=1) and spec@egl_khr_fence_sync@conformance.
>>>
>>> Fixes: 9ee683f877 (egl/dri2: Add reference count for dri2_egl_display)
>>> Cc: "12.0" 
>>> Reported-by: Michel Dänzer 
>>> Signed-off-by: Nicolas Boichat 
>>> ---
>>>
>>> Compile-tested only, please give it a spin, thanks!
>>
>> Still crashes, same backtrace before and after the patch:
> 
> Actually, I was thinking about this bug:
> https://bugs.freedesktop.org/show_bug.cgi?id=97136, which should be
> spec@egl_khr_create_context@verify gl flavor? Did you try that test?

Your patch fixes this test for me.

Tested-by: Michel Dänzer 

Please remove the reference to the egl_khr_fence_sync test from the
commit log.


> Not easy for me to reproduce, but... Looking that the test source code:
> https://cgit.freedesktop.org/piglit/tree/tests/egl/spec/egl_khr_fence_sync/egl_khr_fence_sync.c
> 
> Do you know why we end up in the error path in init_display?
> 
> My guess is that
> eglInitialize->dri2_initialize->dri2_initialize_wayland fails after
> setting disp->DriverData, so the display refcount is == 0, but the
> display is not null, leading to the crash in egl_terminate.
> 
> I just spotted this patch for x11:
> https://patchwork.freedesktop.org/patch/101934/
> 
> platform_wayland needs to be modified in a similar way.

Indeed, that fixes the egl_khr_fence_sync test for me FWIW.


> For the record, Emil spotted this issue when I submitted the offending
> patch, and I haven't followed up ,-(

For future patches, please make sure there are no piglit regressions, at
least for the tests which run with swrast via LIBGL_ALWAYS_SOFTWARE=1.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] egl/dri2: dri2_initialize: Do not reference-count TestOnly display

[Nicolas Boichat]

On Thu, Aug 4, 2016 at 12:22 AM, Martin Peres
 wrote:
>
>
> On 03/08/16 16:54, Nicolas Boichat wrote:
>>
>> In the case where dri2_initialize is called with a TestOnly display,
>> the display is not actually initialized, so dri2_egl_display always
>> fails, and we cannot do any reference counting.
>>
>> Fixes piglit spec@egl_khr_create_context@verify gl flavor (reproducible
>> with LIBGL_ALWAYS_SOFTWARE=1) and spec@egl_khr_fence_sync@conformance.
>>
>> Fixes: 9ee683f877 (egl/dri2: Add reference count for dri2_egl_display)
>> Cc: "12.0" 
>> Reported-by: Michel Dänzer 
>> Signed-off-by: Nicolas Boichat 
>> ---
>>
>> Compile-tested only, please give it a spin, thanks!
>
> Still crashes, same backtrace before and after the patch:

Actually, I was thinking about this bug:
https://bugs.freedesktop.org/show_bug.cgi?id=97136, which should be
spec@egl_khr_create_context@verify gl flavor? Did you try that test?

I probably should not have mentionned
spec@egl_khr_fence_sync@conformance in the commit message...

>
> Program received signal SIGSEGV, Segmentation fault.
> 0x73b90de9 in wl_proxy_destroy () from
> /usr/lib/libwayland-client.so.0
> (gdb) bt
> #0  0x73b90de9 in wl_proxy_destroy () from
> /usr/lib/libwayland-client.so.0
> #1  0x7679bc4e in wl_registry_destroy (wl_registry=)
> at /usr/include/wayland-client-protocol.h:1047
> #2  dri2_display_release (disp=disp@entry=0x7913f0) at
> drivers/dri2/egl_dri2.c:896
> #3  0x7679c031 in dri2_terminate (drv=,
> disp=0x7913f0) at drivers/dri2/egl_dri2.c:932
> #4  0x76790f7d in eglTerminate (dpy=0x7913f0) at main/eglapi.c:532
> #5  0x004016f5 in init_display (platform=12760,
> out_dpy=0x7fffe3a0) at
> /home/mupuf/programmation/piglit/tests/egl/spec/egl_khr_fence_sync/egl_khr_fence_sync.c:136
> #6  0x0040285f in init_other_display (out_other_dpy=0x7fffe3d8,
> orig_dpy=0x617c50) at
> /home/mupuf/programmation/piglit/tests/egl/spec/egl_khr_fence_sync/egl_khr_fence_sync.c:956
> #7  0x00402917 in test_eglCreateSyncKHR_wrong_display_same_thread
> (test_data=0x0) at
> /home/mupuf/programmation/piglit/tests/egl/spec/egl_khr_fence_sync/egl_khr_fence_sync.c:1006
> #8  0x775e10aa in piglit_run_selected_subtests
> (all_subtests=0x404380 , selected_subtests=0x0,
> num_selected_subtests=0, previous_result=PIGLIT_SKIP) at
> /home/mupuf/programmation/piglit/tests/util/piglit-util.c:756
> #9  0x0040319d in main (argc=1, argv=0x7fffe578) at
> /home/mupuf/programmation/piglit/tests/egl/spec/egl_khr_fence_sync/egl_khr_fence_sync.c:1435
>
> If you cannot reproduce, this is something I could be persuaded to look
> into.

Not easy for me to reproduce, but... Looking that the test source code:
https://cgit.freedesktop.org/piglit/tree/tests/egl/spec/egl_khr_fence_sync/egl_khr_fence_sync.c

Do you know why we end up in the error path in init_display?

My guess is that
eglInitialize->dri2_initialize->dri2_initialize_wayland fails after
setting disp->DriverData, so the display refcount is == 0, but the
display is not null, leading to the crash in egl_terminate.

I just spotted this patch for x11:
https://patchwork.freedesktop.org/patch/101934/

platform_wayland needs to be modified in a similar way. Or, better, we
need to refactor dri2_initialize_* functions to avoid touching
_EGLDisplay.

For the record, Emil spotted this issue when I submitted the offending
patch, and I haven't followed up ,-(

Best,

>
>
>>
>>  src/egl/drivers/dri2/egl_dri2.c | 29 +
>>  1 file changed, 9 insertions(+), 20 deletions(-)
>>
>> diff --git a/src/egl/drivers/dri2/egl_dri2.c
>> b/src/egl/drivers/dri2/egl_dri2.c
>> index a5cab68..8cdca6a 100644
>> --- a/src/egl/drivers/dri2/egl_dri2.c
>> +++ b/src/egl/drivers/dri2/egl_dri2.c
>> @@ -788,45 +788,34 @@ dri2_initialize(_EGLDriver *drv, _EGLDisplay *disp)
>> if (disp->Options.UseFallback)
>>return EGL_FALSE;
>>
>> +   /* Nothing to initialize for a test only display */
>> +   if (disp->Options.TestOnly)
>> +  return EGL_TRUE;
>> +
>> switch (disp->Platform) {
>>  #ifdef HAVE_SURFACELESS_PLATFORM
>> case _EGL_PLATFORM_SURFACELESS:
>> -  if (disp->Options.TestOnly)
>> - ret = EGL_TRUE;
>> -  else
>> - ret = dri2_initialize_surfaceless(drv, disp);
>> +  ret = dri2_initialize_surfaceless(drv, disp);
>>break;
>>  #endif
>>  #ifdef HAVE_X11_PLATFORM
>> case _EGL_PLATFORM_X11:
>> -  if (disp->Options.TestOnly)
>> - ret = EGL_TRUE;
>> -  else
>> - ret = dri2_initialize_x11(drv, disp);
>> +  ret = dri2_initialize_x11(drv, disp);
>>break;
>>  #endif
>>  #ifdef HAVE_DRM_PLATFORM
>> case _EGL_PLATFORM_DRM:
>> -  if (disp->Options.TestOnly)
>> - ret = EGL_TRUE;
>> -  else
>> - ret = dri2_initialize_drm(drv, disp);
>> +  ret = 

Re: [Mesa-dev] c99 vs v90

[Enrico Weigelt, metux IT consult]

On 03.08.2016 23:28, Jose Fonseca wrote:

Hi,

> There are minor inconsistencies.  For example, it doesn't support
> __func__,  but doing
> 
>   #define __func__ __FUNCTION__
> 
> suffices to make __func__ work compatible.

Wait a second ... IIRC, __FUNCTION__ was a non-standard gcc'ism - now
msvc support that, but lacks the standardized __func__ ? Seriously ?

> Also MSVC C++ doesn't support many C99 that are not part of C++.  Where
> as GNU C++ munches all.

grmpf!

by the way: what's the exact reason for using msvc instead of gcc on
win32 ?

>> hmm, I dont have any msvc here (actually, no windows at all), but I
>> could prepare patches, which other people could test.
> 
> You could make a fork on github and then register with AppVeyor.

yeah, already got it running.

can I also deploy it to some VM there and log in via VNC ?



--mtx

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

Re: [Mesa-dev] [PATCH 1/5] glsl/types: disallow implicit conversions before GLSL 1.20

[Timothy Arceri]

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

Re: [Mesa-dev] [PATCH 5/5] glsl: fix indentation, comments and line lengths in ast_function.cpp

[Timothy Arceri]

Acked-by: Timothy Arceri 

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

Re: [Mesa-dev] [PATCH 4/5] glsl: apply_implicit_conversion is static again

[Timothy Arceri]

Reviewed-by: Timothy Arceri 

On Wed, 2016-08-03 at 23:51 +0300, Andres Gomez wrote:
> Signed-off-by: Andres Gomez 
> ---
>  src/compiler/glsl/ast_function.cpp | 4 
>  src/compiler/glsl/ast_to_hir.cpp   | 2 +-
>  2 files changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/src/compiler/glsl/ast_function.cpp
> b/src/compiler/glsl/ast_function.cpp
> index ccd070f..52cbf1f 100644
> --- a/src/compiler/glsl/ast_function.cpp
> +++ b/src/compiler/glsl/ast_function.cpp
> @@ -31,10 +31,6 @@
>  static ir_rvalue *
>  convert_component(ir_rvalue *src, const glsl_type *desired_type);
>  
> -bool
> -apply_implicit_conversion(const glsl_type *to, ir_rvalue * ,
> -  struct _mesa_glsl_parse_state *state);
> -
>  static unsigned
>  process_parameters(exec_list *instructions, exec_list
> *actual_parameters,
>      exec_list *parameters,
> diff --git a/src/compiler/glsl/ast_to_hir.cpp
> b/src/compiler/glsl/ast_to_hir.cpp
> index 0b54979..69e545c 100644
> --- a/src/compiler/glsl/ast_to_hir.cpp
> +++ b/src/compiler/glsl/ast_to_hir.cpp
> @@ -280,7 +280,7 @@ get_implicit_conversion_operation(const glsl_type
> *to, const glsl_type *from,
>   * If a conversion is possible (or unnecessary), \c true is
> returned.
>   * Otherwise \c false is returned.
>   */
> -bool
> +static bool
>  apply_implicit_conversion(const glsl_type *to, ir_rvalue * ,
>    struct _mesa_glsl_parse_state *state)
>  {
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/5] glsl: struct constructors/initializers only allow implicit conversions

[Timothy Arceri]

On Wed, 2016-08-03 at 23:51 +0300, Andres Gomez wrote:
> When an argument for a structure constructor or initializer doesn't
> match the expected type, only Section 4.1.10 “Implicit Conversions”
> are allowed to try to match that expected type.
> 
> From page 32 (page 38 of the PDF) of the GLSL 1.20 spec:
> 
>   " The arguments to the constructor will be used to set the
> structure's
> fields, in order, using one argument per field. Each argument
> must
> be the same type as the field it sets, or be a type that can be
> converted to the field's type according to Section 4.1.10
> “Implicit
> Conversions.”"
> 
> From page 35 (page 41 of the PDF) of the GLSL 4.20 spec:
> 
>   " In all cases, the innermost initializer (i.e., not a list of
> initializers enclosed in curly braces) applied to an object must
> have the same type as the object being initialized or be a type
> that
> can be converted to the object's type according to section 4.1.10
> "Implicit Conversions". In the latter case, an implicit
> conversion
> will be done on the initializer before the assignment is done."
> 
> Fixes GL44-CTS.shading_language_420pack.initializer_list_negative
> 
> Signed-off-by: Andres Gomez 
> ---
>  src/compiler/glsl/ast_function.cpp | 36
> +++-
>  1 file changed, 31 insertions(+), 5 deletions(-)
> 
> diff --git a/src/compiler/glsl/ast_function.cpp
> b/src/compiler/glsl/ast_function.cpp
> index 567ad6e..ccd070f 100644
> --- a/src/compiler/glsl/ast_function.cpp
> +++ b/src/compiler/glsl/ast_function.cpp
> @@ -1718,6 +1718,23 @@ process_record_constructor(exec_list
> *instructions,
> struct _mesa_glsl_parse_state *state)
>  {
> void *ctx = state;
> +   /* From page 32 (page 38 of the PDF) of the GLSL 1.20 spec:
> +*
> +*"The arguments to the constructor will be used to set the
> structure's
> +* fields, in order, using one argument per field. Each
> argument must
> +* be the same type as the field it sets, or be a type that
> can be
> +* converted to the field's type according to Section 4.1.10
> “Implicit
> +* Conversions.”"
> +*
> +* From page 35 (page 41 of the PDF) of the GLSL 4.20 spec:
> +*
> +*"In all cases, the innermost initializer (i.e., not a list
> of
> +* initializers enclosed in curly braces) applied to an
> object must
> +* have the same type as the object being initialized or be a
> type that
> +* can be converted to the object's type according to section
> 4.1.10
> +* "Implicit Conversions". In the latter case, an implicit
> conversion
> +* will be done on the initializer before the assignment is
> done."
> +*/
> exec_list actual_parameters;
>  
> process_parameters(instructions, _parameters,
> @@ -1734,17 +1751,26 @@ process_record_constructor(exec_list
> *instructions,
>   return ir_rvalue::error_value(ctx);
>    }
>  
> -  if (apply_implicit_conversion(constructor_type-
> >fields.structure[i].type,
> - ir, state)) {
> +  const glsl_struct_field *struct_field =
> + _type->fields.structure[i];
> +
> +  /* Apply implicit conversions (not the scalar constructor
> rules!). See
> +   * the spec quote above.
> +   */
> +  if ((struct_field->type->base_type != ir->type->base_type)
> +  && (implicitly_convert_component(ir, struct_field->type-
> >base_type,
> +   ir, state))) {
>   node->replace_with(ir);
> -  } else {
> +  }

If you flow my suggestions in patch 2 you should be able to make this
function more like the other two i.e change this too:

  all_parameters_are_constant &= implicitly_convert_component(...)
Remove the constant_record_constructor function and replace the last
couple of lines with:

   if (all_parameters_are_constant) {
      return return new(ctx) ir_constant(constructor_type,            
_parameters);
   } else {
      return emit_inline_record_constructor(constructor_type,
instructions,
                                     _parameters, state);
   }



> +
> +  if (ir->type != struct_field->type) {
>   _mesa_glsl_error(loc, state,
>    "parameter type mismatch in constructor
> for `%s.%s' "
>    "(%s vs %s)",
>    constructor_type->name,
> -  constructor_type-
> >fields.structure[i].name,
> +  struct_field->name,
>    ir->type->name,
> -  constructor_type-
> >fields.structure[i].type->name);
> +  struct_field->type->name);
>   return ir_rvalue::error_value(ctx);
>    }
>  


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org

Re: [Mesa-dev] [PATCH 4/6] util/rgb9e5: Get rid of the float754 union

[Roland Scheidegger]

Am 03.08.2016 um 20:09 schrieb Jason Ekstrand:
> There are a number of reasons for this refactor.  First, format_rgb9e5.h is
> not something that a user would expect to define such a generic union.
> Second, defining it requires checking for endianness which is ugly.  Third,
> 90% of what we were doing with the union was float <-> uint32_t bitcasts
> and the remaining 10% can be done with a sinmple left-shift by 23.
simple

For the series:
Reviewed-by: Roland Scheidegger 



> 
> Signed-off-by: Jason Ekstrand 
> ---
>  src/util/format_rgb9e5.h | 69 
> +++-
>  1 file changed, 27 insertions(+), 42 deletions(-)
> 
> diff --git a/src/util/format_rgb9e5.h b/src/util/format_rgb9e5.h
> index 644b9d8..2559e1e 100644
> --- a/src/util/format_rgb9e5.h
> +++ b/src/util/format_rgb9e5.h
> @@ -28,6 +28,7 @@
>  #define RGB9E5_H
>  
>  #include 
> +#include 
>  
>  #include "c99_math.h"
>  
> @@ -41,59 +42,43 @@
>  #define MAX_RGB9E5_MANTISSA  (RGB9E5_MANTISSA_VALUES-1)
>  #define MAX_RGB9E5   
> (((float)MAX_RGB9E5_MANTISSA)/RGB9E5_MANTISSA_VALUES * (1<  
> -typedef union {
> -   unsigned int raw;
> -   float value;
> -   struct {
> -#if defined(MESA_BIG_ENDIAN) || defined(PIPE_ARCH_BIG_ENDIAN)
> -  unsigned int negative:1;
> -  unsigned int biasedexponent:8;
> -  unsigned int mantissa:23;
> -#else
> -  unsigned int mantissa:23;
> -  unsigned int biasedexponent:8;
> -  unsigned int negative:1;
> -#endif
> -   } field;
> -} float754;
> -
>  static inline int rgb9e5_ClampRange(float x)
>  {
> -   float754 f;
> -   float754 max;
> -   f.value = x;
> -   max.value = MAX_RGB9E5;
> +   union { float f; uint32_t u; } f, max;
> +   f.f = x;
> +   max.f = MAX_RGB9E5;
>  
> -   if (f.raw > 0x7f80)
> +   if (f.u > 0x7f80)
>/* catches neg, NaNs */
>return 0;
> -   else if (f.raw >= max.raw)
> -  return max.raw;
> +   else if (f.u >= max.u)
> +  return max.u;
> else
> -  return f.raw;
> +  return f.u;
>  }
>  
>  static inline unsigned int float3_to_rgb9e5(const float rgb[3])
>  {
> int rm, gm, bm, exp_shared;
> -   float754 revdenom = {0};
> -   float754 rc, bc, gc, maxrgb;
> +   uint32_t revdenom_biasedexp;
> +   union { float f; uint32_t u; } rc, bc, gc, maxrgb, revdenom;
>  
> -   rc.raw = rgb9e5_ClampRange(rgb[0]);
> -   gc.raw = rgb9e5_ClampRange(rgb[1]);
> -   bc.raw = rgb9e5_ClampRange(rgb[2]);
> -   maxrgb.raw = MAX3(rc.raw, gc.raw, bc.raw);
> +   rc.u = rgb9e5_ClampRange(rgb[0]);
> +   gc.u = rgb9e5_ClampRange(rgb[1]);
> +   bc.u = rgb9e5_ClampRange(rgb[2]);
> +   maxrgb.u = MAX3(rc.u, gc.u, bc.u);
>  
> /*
>  * Compared to what the spec suggests, instead of conditionally adjusting
>  * the exponent after the fact do it here by doing the equivalent of +0.5 
> -
>  * the int add will spill over into the exponent in this case.
>  */
> -   maxrgb.raw += maxrgb.raw & (1 << (23-9));
> -   exp_shared = MAX2((maxrgb.raw >> 23), -RGB9E5_EXP_BIAS - 1 + 127) +
> +   maxrgb.u += maxrgb.u & (1 << (23-9));
> +   exp_shared = MAX2((maxrgb.u >> 23), -RGB9E5_EXP_BIAS - 1 + 127) +
>  1 + RGB9E5_EXP_BIAS - 127;
> -   revdenom.field.biasedexponent = 127 - (exp_shared - RGB9E5_EXP_BIAS -
> -  RGB9E5_MANTISSA_BITS) + 1;
> +   revdenom_biasedexp = 127 - (exp_shared - RGB9E5_EXP_BIAS -
> +   RGB9E5_MANTISSA_BITS) + 1;
> +   revdenom.u = revdenom_biasedexp << 23;
> assert(exp_shared <= RGB9E5_MAX_VALID_BIASED_EXP);
>  
> /*
> @@ -102,9 +87,9 @@ static inline unsigned int float3_to_rgb9e5(const float 
> rgb[3])
>  * We avoid the doubles ((int) rc * revdenom + 0.5) by doing the rounding
>  * ourselves (revdenom was adjusted by +1, above).
>  */
> -   rm = (int) (rc.value * revdenom.value);
> -   gm = (int) (gc.value * revdenom.value);
> -   bm = (int) (bc.value * revdenom.value);
> +   rm = (int) (rc.f * revdenom.f);
> +   gm = (int) (gc.f * revdenom.f);
> +   bm = (int) (bc.f * revdenom.f);
> rm = (rm & 1) + (rm >> 1);
> gm = (gm & 1) + (gm >> 1);
> bm = (bm & 1) + (bm >> 1);
> @@ -122,14 +107,14 @@ static inline unsigned int float3_to_rgb9e5(const float 
> rgb[3])
>  static inline void rgb9e5_to_float3(unsigned rgb, float retval[3])
>  {
> int exponent;
> -   float754 scale = {0};
> +   union { float f; uint32_t u; } scale;
>  
> exponent = (rgb >> 27) - RGB9E5_EXP_BIAS - RGB9E5_MANTISSA_BITS;
> -   scale.field.biasedexponent = exponent + 127;
> +   scale.u = (exponent + 127) << 23;
>  
> -   retval[0] = ( rgb& 0x1ff) * scale.value;
> -   retval[1] = ((rgb >> 9)  & 0x1ff) * scale.value;
> -   retval[2] = ((rgb >> 18) & 0x1ff) * scale.value;
> +   retval[0] = ( rgb& 0x1ff) * scale.f;
> +   retval[1] = ((rgb >> 9)  & 0x1ff) * scale.f;
> +   retval[2] = ((rgb >> 18) & 0x1ff) * scale.f;
>  }
>  
>  

Re: [Mesa-dev] [PATCH 1/2] vl: add a lanczos interpolation filter v3

[Andy Furniss]

Nayan Deshmukh wrote:

Hi Christian

On Wed, Aug 3, 2016 at 6:16 PM, Christian König
 wrote:


Sorry for the delay I've been on vacation for a week.

Good to hear back from you !!




Where you able to fix the problem Andy reported? I was able to
rather easily reproduce that.

I have tested it on my system and my friend's system and it seems
to be

working fine. It would be great if Andy can confirm the same.


I am still seeing some artifacts though not the same as last patches and
un-scaled on first look appears OK but it isn't.

Does the scaling happen before CSC? I ask as on  unscaled which doesn't
show any line/block type artifacts, there are sometimes what look like
gamma shifts. There is also a slight shift in image position vs default
or bicubic.

Just to really confuse me I also managed to get mpv to produce a
different result from mplayer on one particular test, they usually look
the same. I did already correct for their differing behaviors WRT using
601 and 709 CSC.

Pendulum again just fullscreen this time as you can't really see
anything wrong windowed.

https://drive.google.com/file/d/0BxP5-S1t9VEEcW02VkVYWDdZd1E/view?usp=sharing
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/5] glsl: Refactor implicit conversion into its own helper

[Timothy Arceri]

On Wed, 2016-08-03 at 23:51 +0300, Andres Gomez wrote:
> Signed-off-by: Andres Gomez 
> ---
>  src/compiler/glsl/ast_function.cpp | 79 +++-
> --
>  1 file changed, 47 insertions(+), 32 deletions(-)
> 
> diff --git a/src/compiler/glsl/ast_function.cpp
> b/src/compiler/glsl/ast_function.cpp
> index 9dcec50..567ad6e 100644
> --- a/src/compiler/glsl/ast_function.cpp
> +++ b/src/compiler/glsl/ast_function.cpp
> @@ -836,6 +836,47 @@ convert_component(ir_rvalue *src, const
> glsl_type *desired_type)
> return (constant != NULL) ? (ir_rvalue *) constant : (ir_rvalue
> *) result;
>  }
>  
> +
> +/**
> + * Perform automatic type conversion of constructor parameters
> + *
> + * This implements the rules in the "Implicit Conversions" rules,
> not the
> + * "Conversion and Scalar Constructors".
> + *
> + * \param from   Operand that is being converted
> + * \param to Base type the operand will be converted to
> + * \param dstDestination in which to store the new operand
> + * \param state  GLSL compiler state
> + *
> + * \return
> + * If a conversion is possible (or unnecessary), \c true is
> returned.
> + * Otherwise \c false is returned.
> + */
> +static bool
> +implicitly_convert_component(ir_rvalue * from,
> + const glsl_base_type to,
> + ir_rvalue * ,
> + struct _mesa_glsl_parse_state *state)
> +{
      If you also add the IR replacement to this helper you can add
this here too.

      if (from->type->base_type != constructor_type->base_type) {

> +   const glsl_type *desired_type =
> +  glsl_type::get_instance(to,
> +  from->type->vector_elements,
> +  from->type->matrix_columns);
> +
> +   if (!from->type->can_implicitly_convert_to(desired_type, state))
> +  return false;
> +
> +   /* Even though convert_component() implements the constructor
> +* conversion rules (not the implicit conversion rules), its safe
> +* to use it here because we already checked that the implicit
> +* conversion is legal.
> +*/
> +   dst = convert_component(from, desired_type);

     }

I think you should be able to take this helper further and add the
constant evaluation logic and IR replacement here also. 

      /* Attempt to convert the parameter to a constant valued
expression.
   * After doing so, track whether or not all the parameters to the
   * constructor are trivially constant valued expressions.
   */
  ir_rvalue *const constant = dst->constant_expression_value();

  if (constant != NULL)
         dst = constant;

  from->replace_with(dst);

      return constant != NULL;
> +}
> +
> +
>  /**
>   * Dereference a specific component from a scalar, vector, or matrix
>   */
> @@ -922,20 +963,9 @@ process_vec_mat_constructor(exec_list
> *instructions,
>  
>    /* Apply implicit conversions (not the scalar constructor
> rules!). See
> * the spec quote above. */
> -  if (constructor_type->base_type != result->type->base_type) {
> - const glsl_type *desired_type =
> -glsl_type::get_instance(constructor_type->base_type,
> -ir->type->vector_elements,;
> -ir->type->matrix_columns);
> - if (result->type->can_implicitly_convert_to(desired_type,
> state)) {
> -/* Even though convert_component() implements the
> constructor
> - * conversion rules (not the implicit conversion rules),
> its safe
> - * to use it here because we already checked that the
> implicit
> - * conversion is legal.
> - */
> -result = convert_component(ir, desired_type);
> - }
> -  }
> +  if (constructor_type->base_type != result->type->base_type)
> + implicitly_convert_component(ir, constructor_type-
> >base_type, result,
> +  state);

If there is more than one textual line after and if we always add
braces.

If you follow my suggestions above you can remove the if and just have:

all_parameters_are_constant &= implicitly_convert_component(...)

And you can remove the constant processing code:

      ir_rvalue *const constant = result->constant_expression_value();

  if (constant != NULL)
 result = constant;
  else
 all_parameters_are_constant = false;

  ir->replace_with(result);

>  
>    if (constructor_type->is_matrix()) {
>   if (result->type != constructor_type->column_type()) {
> @@ -1059,26 +1089,11 @@ process_array_constructor(exec_list
> *instructions,
> foreach_in_list_safe(ir_rvalue, ir, _parameters) {
>    ir_rvalue *result = ir;
>  
> -  const glsl_base_type element_base_type =
> - constructor_type->fields.array->base_type;
> -
>    /* Apply implicit conversions (not the scalar constructor
> rules!). 

[Mesa-dev] [PATCH 1/5] glsl/types: disallow implicit conversions before GLSL 1.20

[Andres Gomez]

Implicit conversions were added in the GLSL 1.20 spec version.

v2 (Timothy): Join the checks for GLSL 1.10 and ESSL.

Signed-off-by: Andres Gomez 
---
 src/compiler/glsl_types.cpp | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/compiler/glsl_types.cpp b/src/compiler/glsl_types.cpp
index 8a06695..641644d 100644
--- a/src/compiler/glsl_types.cpp
+++ b/src/compiler/glsl_types.cpp
@@ -1384,11 +1384,11 @@ glsl_type::can_implicitly_convert_to(const glsl_type 
*desired,
if (this == desired)
   return true;
 
-   /* ESSL does not allow implicit conversions. If there is no state, we're
-* doing intra-stage function linking where these checks have already been
-* done.
+   /* GLSL 1.10 and ESSL do not allow implicit conversions. If there is no
+* state, we're doing intra-stage function linking where these checks have
+* already been done.
 */
-   if (state && state->es_shader)
+   if (state && (state->es_shader || !state->is_version(120, 0)))
   return false;
 
/* There is no conversion among matrix types. */
-- 
2.8.1

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

Re: [Mesa-dev] [PATCH 1/5] glsl/types: disallow implicit conversions before GLSL 1.20

[Andres Gomez]

On Thu, 2016-08-04 at 08:53 +1000, Timothy Arceri wrote:
> On Wed, 2016-08-03 at 23:51 +0300, Andres Gomez wrote:
> > Implicit conversions were added in the GLSL 1.20 spec version.
> > 
> > Signed-off-by: Andres Gomez 
> > ---
> >  src/compiler/glsl_types.cpp | 4 
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/src/compiler/glsl_types.cpp
> > b/src/compiler/glsl_types.cpp
> > index 8a06695..24aec25 100644
> > --- a/src/compiler/glsl_types.cpp
> > +++ b/src/compiler/glsl_types.cpp
> > @@ -1384,6 +1384,10 @@ glsl_type::can_implicitly_convert_to(const
> > glsl_type *desired,
> > if (this == desired)
> >    return true;
> >  
> > +   /* Prior to GLSL 1.20, there are no implicit conversions */
> > +   if (state && !state->is_version(120, 0))
> > +  return false;
> > +
> 
> I thought you were going to update this one?
> 
> https://lists.freedesktop.org/archives/mesa-dev/2016-August/124873.html

Argh!

Sorry about that ☹

-- 

Br,

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

Re: [Mesa-dev] [PATCH 1/5] glsl/types: disallow implicit conversions before GLSL 1.20

[Timothy Arceri]

On Wed, 2016-08-03 at 23:51 +0300, Andres Gomez wrote:
> Implicit conversions were added in the GLSL 1.20 spec version.
> 
> Signed-off-by: Andres Gomez 
> ---
>  src/compiler/glsl_types.cpp | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/src/compiler/glsl_types.cpp
> b/src/compiler/glsl_types.cpp
> index 8a06695..24aec25 100644
> --- a/src/compiler/glsl_types.cpp
> +++ b/src/compiler/glsl_types.cpp
> @@ -1384,6 +1384,10 @@ glsl_type::can_implicitly_convert_to(const
> glsl_type *desired,
> if (this == desired)
>    return true;
>  
> +   /* Prior to GLSL 1.20, there are no implicit conversions */
> +   if (state && !state->is_version(120, 0))
> +  return false;
> +

I thought you were going to update this one?

https://lists.freedesktop.org/archives/mesa-dev/2016-August/124873.html

> /* ESSL does not allow implicit conversions. If there is no
> state, we're
>  * doing intra-stage function linking where these checks have
> already been
>  * done.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 39/95] i965/vec4: dump the instruction execution size

[Francisco Jerez]

Reviewed-by: Francisco Jerez 

Iago Toral Quiroga  writes:

> ---
>  src/mesa/drivers/dri/i965/brw_vec4.cpp | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp 
> b/src/mesa/drivers/dri/i965/brw_vec4.cpp
> index c55d594..8316691 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
> @@ -1410,7 +1410,8 @@ vec4_visitor::dump_instruction(backend_instruction 
> *be_inst, FILE *file)
>pred_ctrl_align16[inst->predicate]);
> }
>  
> -   fprintf(file, "%s", brw_instruction_name(devinfo, inst->opcode));
> +   fprintf(file, "%s(%d)", brw_instruction_name(devinfo, inst->opcode),
> +   inst->exec_size);
> if (inst->saturate)
>fprintf(file, ".sat");
> if (inst->conditional_mod) {
> -- 
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

Re: [Mesa-dev] [PATCH 2/2 v2] mesa: Dynamically allocate the matrix stack.

[Brian Paul]

Reviewed-by: Brian Paul 


On 08/03/2016 03:22 PM, Eric Anholt wrote:

By allocating and initializing the matrices at context creation, the OS
can't even overcommit the pages.  This saves about 63k (out of 946k) of
maximum memory size according to massif on simulated vc4
glsl-algebraic-add-add-1.  It also means we could potentially relax the
maximum stack sizes, but that should be a separate commit.

v2: Drop redundant Top update, explain why the stack is small at init
 time.
---
  src/mesa/main/matrix.c | 28 
  src/mesa/main/mtypes.h |  1 +
  2 files changed, 25 insertions(+), 4 deletions(-)

diff --git a/src/mesa/main/matrix.c b/src/mesa/main/matrix.c
index 293d50c33595..b30b983f14fd 100644
--- a/src/mesa/main/matrix.c
+++ b/src/mesa/main/matrix.c
@@ -243,6 +243,24 @@ _mesa_PushMatrix( void )
}
return;
 }
+   if (stack->Depth + 1 >= stack->StackSize) {
+  unsigned new_stack_size = stack->StackSize * 2;
+  unsigned i;
+  GLmatrix *new_stack = realloc(stack->Stack,
+sizeof(*new_stack) * new_stack_size);
+
+  if (!new_stack) {
+ _mesa_error(ctx, GL_OUT_OF_MEMORY, "glPushMatrix()");
+ return;
+  }
+
+  for (i = stack->StackSize; i < new_stack_size; i++)
+ _math_matrix_ctr(_stack[i]);
+
+  stack->Stack = new_stack;
+  stack->StackSize = new_stack_size;
+   }
+
 _math_matrix_copy( >Stack[stack->Depth + 1],
>Stack[stack->Depth] );
 stack->Depth++;
@@ -645,9 +663,10 @@ init_matrix_stack( struct gl_matrix_stack *stack,
 stack->Depth = 0;
 stack->MaxDepth = maxDepth;
 stack->DirtyFlag = dirtyFlag;
-   /* The stack */
-   stack->Stack = calloc(maxDepth, sizeof(GLmatrix));
-   for (i = 0; i < maxDepth; i++) {
+   /* The stack will be dynamically resized at glPushMatrix() time */
+   stack->Stack = calloc(1, sizeof(GLmatrix));
+   stack->StackSize = 1;
+   for (i = 0; i < stack->StackSize; i++) {
_math_matrix_ctr(>Stack[i]);
 }
 stack->Top = stack->Stack;
@@ -665,11 +684,12 @@ static void
  free_matrix_stack( struct gl_matrix_stack *stack )
  {
 GLuint i;
-   for (i = 0; i < stack->MaxDepth; i++) {
+   for (i = 0; i < stack->StackSize; i++) {
_math_matrix_dtr(>Stack[i]);
 }
 free(stack->Stack);
 stack->Stack = stack->Top = NULL;
+   stack->StackSize = 0;
  }

  /*@}*/
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 2647f8fab841..5b02fadf3cd8 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -3990,6 +3990,7 @@ struct gl_matrix_stack
  {
 GLmatrix *Top;  /**< points into Stack */
 GLmatrix *Stack;/**< array [MaxDepth] of GLmatrix */
+   unsigned StackSize; /**< Number of elements in Stack */
 GLuint Depth;   /**< 0 <= Depth < MaxDepth */
 GLuint MaxDepth;/**< size of Stack[] array */
 GLuint DirtyFlag;   /**< _NEW_MODELVIEW or _NEW_PROJECTION, for example */



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

Re: [Mesa-dev] [PATCH 40/95] i965/vec4: add a SIMD lowering pass

[Francisco Jerez]

Iago Toral Quiroga  writes:

> Generally, instructions in Align16 mode only ever write to a single
> register and don't need anny form of SIMD splitting, that's why we
> have never had a SIMD splitting pass in the vec4 backend. However,
> double-precision instructions typically write 2 registers and in
> some cases they run into certain hardware bugs and limitations
> that we need to work around by splitting the instructions so we only
> write to 1 register at a time.
>
> This patch implements a basic SIMD splitting pass for this purpose.
> Notice that it does not attempt to be as flexible and generic as the
> FS version, because as I explain above, the cases where this needs
> to act are more limited, so we take advantage of that to simplify
> the implementation.
>
> Because we only use double-precision instructions in Align16 mode
> in gen7 (gen8+ is fully scalar and gens < 7 do not implement fp64)
> the pass is restricted to act on gen7 hardware only.
>
> For now the pass only handles the gen7 restriction where any
> instruction that writes 2 registers also needs to read 2 registers.
> This affects double-precision instructions reading uniforms, for
> example. Later patches will extend the lowering pass adding a few
> more cases.
> ---
>  src/mesa/drivers/dri/i965/brw_ir_vec4.h |   1 +
>  src/mesa/drivers/dri/i965/brw_vec4.cpp  | 100 
> +++-
>  src/mesa/drivers/dri/i965/brw_vec4.h|   2 +
>  3 files changed, 102 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_ir_vec4.h 
> b/src/mesa/drivers/dri/i965/brw_ir_vec4.h
> index 721772e..f66c093 100644
> --- a/src/mesa/drivers/dri/i965/brw_ir_vec4.h
> +++ b/src/mesa/drivers/dri/i965/brw_ir_vec4.h
> @@ -167,6 +167,7 @@ public:
> unsigned sol_vertex; /**< gen6: used for setting dst index in SVB header 
> */
>  
> uint8_t exec_size;
> +   uint8_t group;
>  
> bool is_send_from_grf();
> unsigned regs_read(unsigned arg) const;
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp 
> b/src/mesa/drivers/dri/i965/brw_vec4.cpp
> index 8316691..829b7d3 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
> @@ -1947,6 +1947,101 @@ vec4_visitor::convert_to_hw_regs()
> }
>  }
>  
> +/**
> + * Get the closest native SIMD width supported by the hardware for 
> instruction
> + * \p inst.  The instruction will be left untouched by
> + * vec4_visitor::lower_simd_width() if the returned value matches the
> + * instruction's original execution size.
> + */
> +static unsigned
> +get_lowered_simd_width(const struct brw_device_info *devinfo,
> +   const vec4_instruction *inst)
> +{
> +   /* For now we only need to split some cases of double-precision 
> instructions
> +* that write 2 registers. We only need to care about this in gen7 because
> +* that is the only hardware that implements fp64 in Align16.
> +*/
> +   if (devinfo->gen != 7 || inst->regs_written < 2)
> +  return inst->exec_size;
> +
This check is logically part of the Gen7 workaround below, and is going
to prevent adding more workarounds to the function that affect non-Gen7
platforms or instructions with regs_written less than two.  Maybe wrap
the workaround below around an if-conditional with the converse
condition instead of this?

> +   unsigned lowered_width = MIN2(8, inst->exec_size);

The 8 above should be a 16, Align16 instructions can potentially be
wider than 8.

> +
> +   /* HSW PRM, 3D Media GPGPU Engine, Region Alignment Rules for Direct
> +* Register Addressing:
> +*
> +*"When destination spans two registers, the source MUST span two
> +* registers."
> +*/
> +   for (unsigned i = 0; i < 3; i++) {
> +  if (inst->src[i].file == BAD_FILE)
> + continue;
> +  if (inst->regs_read(i) < 2)
> + lowered_width = MIN2(lowered_width, 4);
> +   }
> +

This is going to need a number of additional workarounds for IVB, but I
guess they can be added later on...

> +   return lowered_width;
> +}
> +
> +bool
> +vec4_visitor::lower_simd_width()
> +{
> +   bool progress = false;
> +
> +   foreach_block_and_inst_safe(block, vec4_instruction, inst, cfg) {
> +  const unsigned lowered_width = get_lowered_simd_width(devinfo, inst);
> +  assert(lowered_width <= inst->exec_size);
> +  if (lowered_width == inst->exec_size)
> + continue;
> +
> +  /* For now we only support splitting 8-wide instructions into 4-wide */
> +  assert(inst->exec_size == 8 && lowered_width == 4);
> +
Seems artificial, there is no reason for the logic below to care whether
the original and lowered execution size are exactly equal to these, and
SIMD16 vec4 instructions are useful.

> +  /* We always split so that each lowered instruction writes exactly to
> +   * one register.
> +   */
> +  assert(inst->regs_written == inst->exec_size / lowered_width);
> +

AFAICT the only reason why you 

Re: [Mesa-dev] c99 vs v90

[Jose Fonseca]

On 03/08/16 09:43, Enrico Weigelt, metux IT consult wrote:

On 03.08.2016 09:47, Timothy Arceri wrote:


The current requirement for Mesa is MSVC 2013 so any compat workarounds
for functionality supported by that version can be dropped.

A bunch of stuff has been dropped already but feel free to find any
remaining code.


Right.  We no longer need to be constrained by C90.  MSVC 2013 has 
fairly decent C99 support.


There are minor inconsistencies.  For example, it doesn't support 
__func__,  but doing


  #define __func__ __FUNCTION__

suffices to make __func__ work compatible.


Also MSVC C++ doesn't support many C99 that are not part of C++.  Where 
as GNU C++ munches all.




hmm, I dont have any msvc here (actually, no windows at all), but I
could prepare patches, which other people could test.


You could make a fork on github and then register with AppVeyor.

See the comments on the top of mesa/appveyor.yml

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

[Mesa-dev] [PATCH 2/2 v2] mesa: Dynamically allocate the matrix stack.

[Eric Anholt]

By allocating and initializing the matrices at context creation, the OS
can't even overcommit the pages.  This saves about 63k (out of 946k) of
maximum memory size according to massif on simulated vc4
glsl-algebraic-add-add-1.  It also means we could potentially relax the
maximum stack sizes, but that should be a separate commit.

v2: Drop redundant Top update, explain why the stack is small at init
time.
---
 src/mesa/main/matrix.c | 28 
 src/mesa/main/mtypes.h |  1 +
 2 files changed, 25 insertions(+), 4 deletions(-)

diff --git a/src/mesa/main/matrix.c b/src/mesa/main/matrix.c
index 293d50c33595..b30b983f14fd 100644
--- a/src/mesa/main/matrix.c
+++ b/src/mesa/main/matrix.c
@@ -243,6 +243,24 @@ _mesa_PushMatrix( void )
   }
   return;
}
+   if (stack->Depth + 1 >= stack->StackSize) {
+  unsigned new_stack_size = stack->StackSize * 2;
+  unsigned i;
+  GLmatrix *new_stack = realloc(stack->Stack,
+sizeof(*new_stack) * new_stack_size);
+
+  if (!new_stack) {
+ _mesa_error(ctx, GL_OUT_OF_MEMORY, "glPushMatrix()");
+ return;
+  }
+
+  for (i = stack->StackSize; i < new_stack_size; i++)
+ _math_matrix_ctr(_stack[i]);
+
+  stack->Stack = new_stack;
+  stack->StackSize = new_stack_size;
+   }
+
_math_matrix_copy( >Stack[stack->Depth + 1],
   >Stack[stack->Depth] );
stack->Depth++;
@@ -645,9 +663,10 @@ init_matrix_stack( struct gl_matrix_stack *stack,
stack->Depth = 0;
stack->MaxDepth = maxDepth;
stack->DirtyFlag = dirtyFlag;
-   /* The stack */
-   stack->Stack = calloc(maxDepth, sizeof(GLmatrix));
-   for (i = 0; i < maxDepth; i++) {
+   /* The stack will be dynamically resized at glPushMatrix() time */
+   stack->Stack = calloc(1, sizeof(GLmatrix));
+   stack->StackSize = 1;
+   for (i = 0; i < stack->StackSize; i++) {
   _math_matrix_ctr(>Stack[i]);
}
stack->Top = stack->Stack;
@@ -665,11 +684,12 @@ static void
 free_matrix_stack( struct gl_matrix_stack *stack )
 {
GLuint i;
-   for (i = 0; i < stack->MaxDepth; i++) {
+   for (i = 0; i < stack->StackSize; i++) {
   _math_matrix_dtr(>Stack[i]);
}
free(stack->Stack);
stack->Stack = stack->Top = NULL;
+   stack->StackSize = 0;
 }
 
 /*@}*/
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 2647f8fab841..5b02fadf3cd8 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -3990,6 +3990,7 @@ struct gl_matrix_stack
 {
GLmatrix *Top;  /**< points into Stack */
GLmatrix *Stack;/**< array [MaxDepth] of GLmatrix */
+   unsigned StackSize; /**< Number of elements in Stack */
GLuint Depth;   /**< 0 <= Depth < MaxDepth */
GLuint MaxDepth;/**< size of Stack[] array */
GLuint DirtyFlag;   /**< _NEW_MODELVIEW or _NEW_PROJECTION, for example */
-- 
2.8.1

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

[Mesa-dev] [PATCH 3/3] radeonsi: move spi_ps_input_addr override outside of the loop

[Nicolai Hähnle]

From: Nicolai Hähnle 

---
 src/gallium/drivers/radeonsi/si_shader.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
b/src/gallium/drivers/radeonsi/si_shader.c
index 455f604..64c367e 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -5990,10 +5990,10 @@ void si_shader_binary_read_config(struct 
radeon_shader_binary *binary,
}
break;
}
-
-   if (!conf->spi_ps_input_addr)
-   conf->spi_ps_input_addr = conf->spi_ps_input_ena;
}
+
+   if (!conf->spi_ps_input_addr)
+   conf->spi_ps_input_addr = conf->spi_ps_input_ena;
 }
 
 void si_shader_apply_scratch_relocs(struct si_context *sctx,
-- 
2.7.4

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

[Mesa-dev] [PATCH 1/3] radeonsi: do not pass the return type to buffer_load_const

[Nicolai Hähnle]

From: Nicolai Hähnle 

Overriding it is not allowed anyway, and actually lead to a crash when polygon
stippling was used with monolithic shaders.
---
 src/gallium/drivers/radeonsi/si_shader.c | 36 
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
b/src/gallium/drivers/radeonsi/si_shader.c
index 62a1486..0aae097 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -1593,12 +1593,14 @@ static LLVMValueRef get_thread_id(struct 
si_shader_context *ctx)
 /**
  * Load a dword from a constant buffer.
  */
-static LLVMValueRef buffer_load_const(LLVMBuilderRef builder, LLVMValueRef 
resource,
- LLVMValueRef offset, LLVMTypeRef 
return_type)
+static LLVMValueRef buffer_load_const(struct si_shader_context *ctx,
+ LLVMValueRef resource,
+ LLVMValueRef offset)
 {
+   LLVMBuilderRef builder = ctx->radeon_bld.gallivm.builder;
LLVMValueRef args[2] = {resource, offset};
 
-   return lp_build_intrinsic(builder, "llvm.SI.load.const", return_type, 
args, 2,
+   return lp_build_intrinsic(builder, "llvm.SI.load.const", ctx->f32, 
args, 2,
   LLVMReadNoneAttribute);
 }
 
@@ -1618,8 +1620,8 @@ static LLVMValueRef load_sample_position(struct 
radeon_llvm_context *radeon_bld,
LLVMValueRef offset1 = LLVMBuildAdd(builder, offset0, 
lp_build_const_int32(gallivm, 4), "");
 
LLVMValueRef pos[4] = {
-   buffer_load_const(builder, resource, offset0, ctx->f32),
-   buffer_load_const(builder, resource, offset1, ctx->f32),
+   buffer_load_const(ctx, resource, offset0),
+   buffer_load_const(ctx, resource, offset1),
lp_build_const_float(gallivm, 0),
lp_build_const_float(gallivm, 0)
};
@@ -1772,9 +1774,8 @@ static void declare_system_value(
offset = decl->Semantic.Name == 
TGSI_SEMANTIC_DEFAULT_TESSINNER_SI ? 4 : 0;
 
for (i = 0; i < 4; i++)
-   val[i] = buffer_load_const(gallivm->builder, buf,
-  
lp_build_const_int32(gallivm, (offset + i) * 4),
-  ctx->f32);
+   val[i] = buffer_load_const(ctx, buf,
+  
lp_build_const_int32(gallivm, (offset + i) * 4));
value = lp_build_gather_values(gallivm, val, 4);
break;
}
@@ -1908,8 +1909,7 @@ static LLVMValueRef fetch_constant(
addr = lp_build_add(_base->uint_bld, addr,
lp_build_const_int32(base->gallivm, idx * 4));
 
-   result = buffer_load_const(base->gallivm->builder, bufp,
-  addr, ctx->f32);
+   result = buffer_load_const(ctx, bufp, addr);
 
if (!tgsi_type_is_64bit(type))
result = bitcast(bld_base, type, result);
@@ -1921,8 +1921,8 @@ static LLVMValueRef fetch_constant(
addr2 = lp_build_add(_base->uint_bld, addr2,
 lp_build_const_int32(base->gallivm, idx * 
4));
 
-   result2 = buffer_load_const(base->gallivm->builder, 
ctx->const_buffers[buf],
-  addr2, ctx->f32);
+   result2 = buffer_load_const(ctx, ctx->const_buffers[buf],
+   addr2);
 
result = radeon_llvm_emit_fetch_64bit(bld_base, type,
  result, result2);
@@ -2219,8 +2219,8 @@ static void si_llvm_emit_clipvertex(struct 
lp_build_tgsi_context *bld_base,
args[1] = lp_build_const_int32(base->gallivm,
   ((reg_index * 4 
+ chan) * 4 +
const_chan) * 
4);
-   base_elt = 
buffer_load_const(base->gallivm->builder, const_resource,
- args[1], ctx->f32);
+   base_elt = buffer_load_const(ctx, 
const_resource,
+args[1]);
args[5 + chan] =
lp_build_add(base, args[5 + chan],
 lp_build_mul(base, 
base_elt,
@@ -5725,10 +5725,9 @@ static void preload_constants(struct si_shader_context 
*ctx)
/* Load the constants, we rely on the code sinking to do the 
rest */
for (i = 0; i < num_const * 4; ++i) {
ctx->constants[buf][i] =
-   

[Mesa-dev] [PATCH 2/3] radeonsi: drop unnecessary u_pstipple.h include

[Nicolai Hähnle]

From: Nicolai Hähnle 

---
 src/gallium/drivers/radeonsi/si_shader.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
b/src/gallium/drivers/radeonsi/si_shader.c
index 0aae097..455f604 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -39,7 +39,6 @@
 #include "radeon/radeon_elf_util.h"
 #include "radeon/radeon_llvm_emit.h"
 #include "util/u_memory.h"
-#include "util/u_pstipple.h"
 #include "util/u_string.h"
 #include "tgsi/tgsi_parse.h"
 #include "tgsi/tgsi_build.h"
-- 
2.7.4

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

[Mesa-dev] [PATCH 3/5] glsl: struct constructors/initializers only allow implicit conversions

[Andres Gomez]

When an argument for a structure constructor or initializer doesn't
match the expected type, only Section 4.1.10 “Implicit Conversions”
are allowed to try to match that expected type.

From page 32 (page 38 of the PDF) of the GLSL 1.20 spec:

  " The arguments to the constructor will be used to set the structure's
fields, in order, using one argument per field. Each argument must
be the same type as the field it sets, or be a type that can be
converted to the field's type according to Section 4.1.10 “Implicit
Conversions.”"

From page 35 (page 41 of the PDF) of the GLSL 4.20 spec:

  " In all cases, the innermost initializer (i.e., not a list of
initializers enclosed in curly braces) applied to an object must
have the same type as the object being initialized or be a type that
can be converted to the object's type according to section 4.1.10
"Implicit Conversions". In the latter case, an implicit conversion
will be done on the initializer before the assignment is done."

Fixes GL44-CTS.shading_language_420pack.initializer_list_negative

Signed-off-by: Andres Gomez 
---
 src/compiler/glsl/ast_function.cpp | 36 +++-
 1 file changed, 31 insertions(+), 5 deletions(-)

diff --git a/src/compiler/glsl/ast_function.cpp 
b/src/compiler/glsl/ast_function.cpp
index 567ad6e..ccd070f 100644
--- a/src/compiler/glsl/ast_function.cpp
+++ b/src/compiler/glsl/ast_function.cpp
@@ -1718,6 +1718,23 @@ process_record_constructor(exec_list *instructions,
struct _mesa_glsl_parse_state *state)
 {
void *ctx = state;
+   /* From page 32 (page 38 of the PDF) of the GLSL 1.20 spec:
+*
+*"The arguments to the constructor will be used to set the structure's
+* fields, in order, using one argument per field. Each argument must
+* be the same type as the field it sets, or be a type that can be
+* converted to the field's type according to Section 4.1.10 “Implicit
+* Conversions.”"
+*
+* From page 35 (page 41 of the PDF) of the GLSL 4.20 spec:
+*
+*"In all cases, the innermost initializer (i.e., not a list of
+* initializers enclosed in curly braces) applied to an object must
+* have the same type as the object being initialized or be a type that
+* can be converted to the object's type according to section 4.1.10
+* "Implicit Conversions". In the latter case, an implicit conversion
+* will be done on the initializer before the assignment is done."
+*/
exec_list actual_parameters;
 
process_parameters(instructions, _parameters,
@@ -1734,17 +1751,26 @@ process_record_constructor(exec_list *instructions,
  return ir_rvalue::error_value(ctx);
   }
 
-  if (apply_implicit_conversion(constructor_type->fields.structure[i].type,
- ir, state)) {
+  const glsl_struct_field *struct_field =
+ _type->fields.structure[i];
+
+  /* Apply implicit conversions (not the scalar constructor rules!). See
+   * the spec quote above.
+   */
+  if ((struct_field->type->base_type != ir->type->base_type)
+  && (implicitly_convert_component(ir, struct_field->type->base_type,
+   ir, state))) {
  node->replace_with(ir);
-  } else {
+  }
+
+  if (ir->type != struct_field->type) {
  _mesa_glsl_error(loc, state,
   "parameter type mismatch in constructor for `%s.%s' "
   "(%s vs %s)",
   constructor_type->name,
-  constructor_type->fields.structure[i].name,
+  struct_field->name,
   ir->type->name,
-  constructor_type->fields.structure[i].type->name);
+  struct_field->type->name);
  return ir_rvalue::error_value(ctx);
   }
 
-- 
2.8.1

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

[Mesa-dev] [PATCH v2 0/5] struct constructors/initializers only allow implicit conversions

[Andres Gomez]

When an argument for a structure constructor or initializer doesn't
match the expected type, only Section 4.1.10 “Implicit Conversions”
are allowed to try to match that expected type.

Fixes GL44-CTS.shading_language_420pack.initializer_list_negative

Andres Gomez (5):
  glsl/types: disallow implicit conversions before GLSL 1.20
  glsl: Refactor implicit conversion into its own helper
  glsl: struct constructors/initializers only allow implicit conversions
  glsl: apply_implicit_conversion is static again
  glsl: fix indentation, comments and line lengths in ast_function.cpp

 src/compiler/glsl/ast_function.cpp | 999 -
 src/compiler/glsl/ast_to_hir.cpp   |   2 +-
 src/compiler/glsl_types.cpp|   4 +
 3 files changed, 543 insertions(+), 462 deletions(-)

-- 
2.8.1

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

[Mesa-dev] [PATCH 5/5] glsl: fix indentation, comments and line lengths in ast_function.cpp

[Andres Gomez]

Signed-off-by: Andres Gomez 
---
 src/compiler/glsl/ast_function.cpp | 880 +++--
 1 file changed, 460 insertions(+), 420 deletions(-)

diff --git a/src/compiler/glsl/ast_function.cpp 
b/src/compiler/glsl/ast_function.cpp
index 52cbf1f..817673a 100644
--- a/src/compiler/glsl/ast_function.cpp
+++ b/src/compiler/glsl/ast_function.cpp
@@ -33,8 +33,8 @@ convert_component(ir_rvalue *src, const glsl_type 
*desired_type);
 
 static unsigned
 process_parameters(exec_list *instructions, exec_list *actual_parameters,
-  exec_list *parameters,
-  struct _mesa_glsl_parse_state *state)
+   exec_list *parameters,
+   struct _mesa_glsl_parse_state *state)
 {
unsigned count = 0;
 
@@ -49,7 +49,7 @@ process_parameters(exec_list *instructions, exec_list 
*actual_parameters,
 
   ir_constant *const constant = result->constant_expression_value();
   if (constant != NULL)
-result = constant;
+ result = constant;
 
   actual_parameters->push_tail(result);
   count++;
@@ -74,7 +74,7 @@ process_parameters(exec_list *instructions, exec_list 
*actual_parameters,
  */
 char *
 prototype_string(const glsl_type *return_type, const char *name,
-exec_list *parameters)
+ exec_list *parameters)
 {
char *str = NULL;
 
@@ -146,7 +146,7 @@ verify_image_parameter(YYLTYPE *loc, _mesa_glsl_parse_state 
*state,
 
 static bool
 verify_first_atomic_parameter(YYLTYPE *loc, _mesa_glsl_parse_state *state,
-   ir_variable *var)
+  ir_variable *var)
 {
if (!var ||
(!var->is_in_shader_storage_block() &&
@@ -178,9 +178,9 @@ is_atomic_function(const char *func_name)
  */
 static bool
 verify_parameter_modes(_mesa_glsl_parse_state *state,
-  ir_function_signature *sig,
-  exec_list _ir_parameters,
-  exec_list _ast_parameters)
+   ir_function_signature *sig,
+   exec_list _ir_parameters,
+   exec_list _ast_parameters)
 {
exec_node *actual_ir_node  = actual_ir_parameters.get_head_raw();
exec_node *actual_ast_node = actual_ast_parameters.get_head_raw();
@@ -192,7 +192,7 @@ verify_parameter_modes(_mesa_glsl_parse_state *state,
 
   const ir_rvalue *const actual = (ir_rvalue *) actual_ir_node;
   const ast_expression *const actual_ast =
-exec_node_data(ast_expression, actual_ast_node, link);
+ exec_node_data(ast_expression, actual_ast_node, link);
 
   /* FIXME: 'loc' is incorrect (as of 2011-01-21). It is always
* FIXME: 0:0(0).
@@ -201,18 +201,18 @@ verify_parameter_modes(_mesa_glsl_parse_state *state,
 
   /* Verify that 'const_in' parameters are ir_constants. */
   if (formal->data.mode == ir_var_const_in &&
- actual->ir_type != ir_type_constant) {
-_mesa_glsl_error(, state,
- "parameter `in %s' must be a constant expression",
- formal->name);
-return false;
+  actual->ir_type != ir_type_constant) {
+ _mesa_glsl_error(, state,
+  "parameter `in %s' must be a constant expression",
+  formal->name);
+ return false;
   }
 
   /* Verify that shader_in parameters are shader inputs */
   if (formal->data.must_be_shader_input) {
  const ir_rvalue *val = actual;
 
- // GLSL 4.40 allows swizzles, while earlier GLSL versions do not.
+ /* GLSL 4.40 allows swizzles, while earlier GLSL versions do not. */
  if (val->ir_type == ir_type_swizzle) {
 if (!state->is_version(440, 0)) {
_mesa_glsl_error(, state,
@@ -239,29 +239,30 @@ verify_parameter_modes(_mesa_glsl_parse_state *state,
   /* Verify that 'out' and 'inout' actual parameters are lvalues. */
   if (formal->data.mode == ir_var_function_out
   || formal->data.mode == ir_var_function_inout) {
-const char *mode = NULL;
-switch (formal->data.mode) {
-case ir_var_function_out:   mode = "out";   break;
-case ir_var_function_inout: mode = "inout"; break;
-default:assert(false);  break;
-}
-
-/* This AST-based check catches errors like f(i++).  The IR-based
- * is_lvalue() is insufficient because the actual parameter at the
- * IR-level is just a temporary value, which is an l-value.
- */
-if (actual_ast->non_lvalue_description != NULL) {
-   _mesa_glsl_error(, state,
-"function parameter '%s %s' references a %s",
-mode, formal->name,
-actual_ast->non_lvalue_description);
-   return false;
-}
-
-ir_variable *var = actual->variable_referenced();
+  

[Mesa-dev] [PATCH 2/5] glsl: Refactor implicit conversion into its own helper

[Andres Gomez]

Signed-off-by: Andres Gomez 
---
 src/compiler/glsl/ast_function.cpp | 79 +++---
 1 file changed, 47 insertions(+), 32 deletions(-)

diff --git a/src/compiler/glsl/ast_function.cpp 
b/src/compiler/glsl/ast_function.cpp
index 9dcec50..567ad6e 100644
--- a/src/compiler/glsl/ast_function.cpp
+++ b/src/compiler/glsl/ast_function.cpp
@@ -836,6 +836,47 @@ convert_component(ir_rvalue *src, const glsl_type 
*desired_type)
return (constant != NULL) ? (ir_rvalue *) constant : (ir_rvalue *) result;
 }
 
+
+/**
+ * Perform automatic type conversion of constructor parameters
+ *
+ * This implements the rules in the "Implicit Conversions" rules, not the
+ * "Conversion and Scalar Constructors".
+ *
+ * \param from   Operand that is being converted
+ * \param to Base type the operand will be converted to
+ * \param dstDestination in which to store the new operand
+ * \param state  GLSL compiler state
+ *
+ * \return
+ * If a conversion is possible (or unnecessary), \c true is returned.
+ * Otherwise \c false is returned.
+ */
+static bool
+implicitly_convert_component(ir_rvalue * from,
+ const glsl_base_type to,
+ ir_rvalue * ,
+ struct _mesa_glsl_parse_state *state)
+{
+   const glsl_type *desired_type =
+  glsl_type::get_instance(to,
+  from->type->vector_elements,
+  from->type->matrix_columns);
+
+   if (!from->type->can_implicitly_convert_to(desired_type, state))
+  return false;
+
+   /* Even though convert_component() implements the constructor
+* conversion rules (not the implicit conversion rules), its safe
+* to use it here because we already checked that the implicit
+* conversion is legal.
+*/
+   dst = convert_component(from, desired_type);
+
+   return true;
+}
+
+
 /**
  * Dereference a specific component from a scalar, vector, or matrix
  */
@@ -922,20 +963,9 @@ process_vec_mat_constructor(exec_list *instructions,
 
   /* Apply implicit conversions (not the scalar constructor rules!). See
* the spec quote above. */
-  if (constructor_type->base_type != result->type->base_type) {
- const glsl_type *desired_type =
-glsl_type::get_instance(constructor_type->base_type,
-ir->type->vector_elements,
-ir->type->matrix_columns);
- if (result->type->can_implicitly_convert_to(desired_type, state)) {
-/* Even though convert_component() implements the constructor
- * conversion rules (not the implicit conversion rules), its safe
- * to use it here because we already checked that the implicit
- * conversion is legal.
- */
-result = convert_component(ir, desired_type);
- }
-  }
+  if (constructor_type->base_type != result->type->base_type)
+ implicitly_convert_component(ir, constructor_type->base_type, result,
+  state);
 
   if (constructor_type->is_matrix()) {
  if (result->type != constructor_type->column_type()) {
@@ -1059,26 +1089,11 @@ process_array_constructor(exec_list *instructions,
foreach_in_list_safe(ir_rvalue, ir, _parameters) {
   ir_rvalue *result = ir;
 
-  const glsl_base_type element_base_type =
- constructor_type->fields.array->base_type;
-
   /* Apply implicit conversions (not the scalar constructor rules!). See
* the spec quote above. */
-  if (element_base_type != result->type->base_type) {
- const glsl_type *desired_type =
-glsl_type::get_instance(element_base_type,
-ir->type->vector_elements,
-ir->type->matrix_columns);
-
-if (result->type->can_implicitly_convert_to(desired_type, state)) {
-   /* Even though convert_component() implements the constructor
-* conversion rules (not the implicit conversion rules), its safe
-* to use it here because we already checked that the implicit
-* conversion is legal.
-*/
-   result = convert_component(ir, desired_type);
-}
-  }
+  if (element_type->base_type != result->type->base_type)
+ implicitly_convert_component(ir, element_type->base_type, result,
+  state);
 
   if (constructor_type->fields.array->is_unsized_array()) {
  /* As the inner parameters of the constructor are created without
-- 
2.8.1

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

[Mesa-dev] [PATCH 1/5] glsl/types: disallow implicit conversions before GLSL 1.20

[Andres Gomez]

Implicit conversions were added in the GLSL 1.20 spec version.

Signed-off-by: Andres Gomez 
---
 src/compiler/glsl_types.cpp | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/compiler/glsl_types.cpp b/src/compiler/glsl_types.cpp
index 8a06695..24aec25 100644
--- a/src/compiler/glsl_types.cpp
+++ b/src/compiler/glsl_types.cpp
@@ -1384,6 +1384,10 @@ glsl_type::can_implicitly_convert_to(const glsl_type 
*desired,
if (this == desired)
   return true;
 
+   /* Prior to GLSL 1.20, there are no implicit conversions */
+   if (state && !state->is_version(120, 0))
+  return false;
+
/* ESSL does not allow implicit conversions. If there is no state, we're
 * doing intra-stage function linking where these checks have already been
 * done.
-- 
2.8.1

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

[Mesa-dev] [PATCH 4/5] glsl: apply_implicit_conversion is static again

[Andres Gomez]

Signed-off-by: Andres Gomez 
---
 src/compiler/glsl/ast_function.cpp | 4 
 src/compiler/glsl/ast_to_hir.cpp   | 2 +-
 2 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/src/compiler/glsl/ast_function.cpp 
b/src/compiler/glsl/ast_function.cpp
index ccd070f..52cbf1f 100644
--- a/src/compiler/glsl/ast_function.cpp
+++ b/src/compiler/glsl/ast_function.cpp
@@ -31,10 +31,6 @@
 static ir_rvalue *
 convert_component(ir_rvalue *src, const glsl_type *desired_type);
 
-bool
-apply_implicit_conversion(const glsl_type *to, ir_rvalue * ,
-  struct _mesa_glsl_parse_state *state);
-
 static unsigned
 process_parameters(exec_list *instructions, exec_list *actual_parameters,
   exec_list *parameters,
diff --git a/src/compiler/glsl/ast_to_hir.cpp b/src/compiler/glsl/ast_to_hir.cpp
index 0b54979..69e545c 100644
--- a/src/compiler/glsl/ast_to_hir.cpp
+++ b/src/compiler/glsl/ast_to_hir.cpp
@@ -280,7 +280,7 @@ get_implicit_conversion_operation(const glsl_type *to, 
const glsl_type *from,
  * If a conversion is possible (or unnecessary), \c true is returned.
  * Otherwise \c false is returned.
  */
-bool
+static bool
 apply_implicit_conversion(const glsl_type *to, ir_rvalue * ,
   struct _mesa_glsl_parse_state *state)
 {
-- 
2.8.1

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

Re: [Mesa-dev] [PATCH 2/2] glsl: struct constructors/initializers only allow implicit conversions

[Andres Gomez]

On Mon, 2016-08-01 at 12:05 +0300, Andres Gomez wrote:
> On Mon, 2016-08-01 at 10:01 +1000, Timothy Arceri wrote:
> > On Sun, 2016-07-31 at 18:43 +0300, Andres Gomez wrote:
> 
> [snip]
> 
> > diff --git a/src/compiler/glsl/ast_function.cpp
> > > b/src/compiler/glsl/ast_function.cpp
> > > index 9dcec50..9b09cb6 100644
> > > --- a/src/compiler/glsl/ast_function.cpp
> > > +++ b/src/compiler/glsl/ast_function.cpp

[snip]

> > > @@ -1719,18 +1732,35 @@ process_record_constructor(exec_list
> > > *instructions,
> > >   return ir_rvalue::error_value(ctx);
> > >    }
> > >  
> > > -  if (apply_implicit_conversion(constructor_type-
> > > > fields.structure[i].type,
> > > - ir, state)) {
> > > - node->replace_with(ir);
> > > -  } else {
> > > - _mesa_glsl_error(loc, state,
> > > -  "parameter type mismatch in constructor
> > > for `%s.%s' "
> > > -  "(%s vs %s)",
> > > -  constructor_type->name,
> > > -  constructor_type-
> > > > fields.structure[i].name,
> > > -  ir->type->name,
> > > -  constructor_type-
> > > > fields.structure[i].type->name);
> > > +  const glsl_base_type element_base_type =
> > > + constructor_type->fields.structure[i].type->base_type;
> > > +
> > > +  /* Apply implicit conversions (not the scalar constructor
> > > rules!). See
> > > +   * the spec quote above. */
> > 
> > */ should be on the next line
> 
> Right! I will update.
> 
> > > +  if (element_base_type != result->type->base_type) {
> > > + const glsl_type *desired_type =
> > > +glsl_type::get_instance(element_base_type,
> > > +result->type->vector_elements,
> > > +result->type->matrix_columns);
> > > +
> > > +  if (result->type->can_implicitly_convert_to(desired_type,
> > > state)) {
> > > + /* Even though convert_component() implements the
> > > constructor
> > > +  * conversion rules (not the implicit conversion rules),
> > > its safe
> > > +  * to use it here because we already checked that the
> > > implicit
> > > +  * conversion is legal.
> > > +  */
> > > + result = convert_component(result, desired_type);
> > > +  }
> > 
> > You are adding a bunch of tabs above please remove them. It would be
> > nice if you could add a forth patch to the series that removes the
> > remain tabs in this file since there are not many remaining.
> 
> Ouch! The curse of copy and paste ☹
> 
> I will update and add that 4th patch.
> 
> Now that you comment that, maybe you can give a review to?
> https://patchwork.freedesktop.org/patch/97838/
> 
> > > +  }
> > > +
> > > +  if (result->type != constructor_type-
> > > > fields.structure[i].type) {
> > > +  _mesa_glsl_error(loc, state, "type error in array
> > > constructor: "
> > > +   "expected: %s, found %s",
> > > +   constructor_type-
> > > > fields.structure[i].type->name,
> > > +   result->type->name);
> > >   return ir_rvalue::error_value(ctx);
> > > +  } else {
> > > + node->replace_with(result);
> > >    }
> > 
> > This if-else should be inside the previous if.
> > 
> >  The node->replace_with(result); should be after
> >  result = convert_component(result, desired_type);
> > 
> > Otherwise you are replacing the node with itself.
> > 
> > The error message can be added as an else to if (result->type-
> > > can_implicitly_convert_to())
> 
> Argh! Yeah, that's a shame.
> 
> I will update.

Forgot to comment about placing the error message also nested as an
else to the conversion.

That's not OK. Since we are not attempting the convert for any type,
but only the ones with a different base_type, we still have to check
whether the type is the expected or not and, then, run the error code.

-- 

Br,

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

Re: [Mesa-dev] OpenCL for radeon Hawaii?

[Jan Vesely]

Hi,

you can use clinfo utility to check whether OpenCL has been setup
correctly. It won't be able to run luxmark, but simpler stuff should
work.

Jan

On Wed, 2016-08-03 at 20:45 +0100, Sam Halliday wrote:
> Hello everybody,
> 
> I recently got a Radeon R9 290x (aka Hawaii). I run ArchLinux, which
> has
> mesa 12.0.1.
> 
> I am keen to try out mesa's partial OpenCL implementation. Ideally to
> use a BLAS implementation such as https://github.com/CNugteren/CLBlas
> t
> but I'd also be happy to just write something basic like dense
> matrix/matrix multiplication in OpenCL.
> 
> 
> However, when I tried to run the "luxmark" OpenCL benchmark (the only
> way I could think to test if my card is supported), I got this error
> 
> [PathOCLBaseRenderThread::0] Compiling kernels 
> [PathOCLBaseRenderThread::0] PathOCL kernel compilation error ERROR
> clBuildProgram[CL_INVALID_BUILD_OPTIONS]: 
> RUNTIME ERROR: PathOCLBase kernel compilation error
> 
> which, I'm guessing, means that my GPU isn't supported for OpenCL by
> mesa yet. Is that correct? (I don't know how to get any more output
> or
> logs than this).
> 
> 
> Could somebody please help by letting me know if there is a ticket I
> could subscribe to track progress of support for my card (a simple
> search of the bug database didn't bring up anything obvious). This
> message is to the -dev list, so I am suppose I am saying that I am
> prepared to get my hands dirty... but I am primarily a Scala
> developer
> and haven't done any C in years so the extent of my help is limited.
> 
> If somebody who knows what they are doing would be willing to
> implement
> some of the functionality needed, I'd be prepared to buy this GPU for
> them to use for their hacking - it's the least I could do (but it is
> an
> absolute monster, I didn't even know GPUs could be this big! I needed
> to
> get a bigger case for it).
> 
> 
> Somewhat tangentially, if OpenCL support is really not a possibility
> anytime soon, could somebody please point me in the direction of a
> way
> to use this card programmatically for something like matrix/matrix
> multiplication? (I'm prepared to go really low level if there is
> sufficient documentation).
> 
> 
> I'm not at all interested in using proprietary drivers for OpenCL.
> 
> 
-- 
Jan Vesely 

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

Re: [Mesa-dev] [PATCH 36/95] i965/vec4: add a helper function to create double immediates

[Francisco Jerez]

Iago Toral Quiroga  writes:

> Gen7 hardware does not support double immediates so these need
> to be moved in 32-bit chunks to a regular vgrf instead. Instead
> of doing this every time we need to create a DF immediate,
> create a helper function that does the right thing depending
> on the hardware generation.
>
> Signed-off-by: Samuel Iglesias Gonsálvez 
> ---
>  src/mesa/drivers/dri/i965/brw_vec4.h   |  2 ++
>  src/mesa/drivers/dri/i965/brw_vec4_nir.cpp | 40 
> ++
>  2 files changed, 42 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h 
> b/src/mesa/drivers/dri/i965/brw_vec4.h
> index 4650ae0..cf7cdab 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4.h
> +++ b/src/mesa/drivers/dri/i965/brw_vec4.h
> @@ -320,6 +320,8 @@ public:
> void emit_single_to_double(dst_reg dst, src_reg src, bool saturate,
>brw_reg_type single_type);
>  
> +   src_reg setup_imm_df(double v);
> +
> virtual void emit_nir_code();
> virtual void nir_setup_uniforms();
> virtual void nir_setup_system_value_intrinsic(nir_intrinsic_instr *instr);
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp 
> b/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
> index d7c6bf4..8a45fde 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
> @@ -1063,6 +1063,46 @@ vec4_visitor::emit_single_to_double(dst_reg dst, 
> src_reg src, bool saturate,
> inst->saturate = saturate;
>  }
>  
> +src_reg
> +vec4_visitor::setup_imm_df(double v)
> +{
> +   assert(devinfo->gen >= 7);
> +
> +   if (devinfo->gen >= 8)
> +  return brw_imm_df(v);
> +
> +   /* gen7 does not support DF immediates */
> +   union {
> +  double d;
> +  struct {
> + uint32_t i1;
> + uint32_t i2;
> +  };
> +   } di;
> +
> +   di.d = v;
> +
> +   /* Write the low 32-bit of the constant to the X:UD channel and the
> +* high 32-bit to the Y:UD channel to build the constant in a VGRF.
> +* We have to do this twice (offset 0 and offset 1), since a DF VGRF takes
> +* two SIMD8 registers in SIMD4x2 execution. Finally, return a swizzle
> +*  so any access to the VGRF only reads the constant data in these
> +* channels.
> +*/
> +   dst_reg tmp = dst_reg(VGRF, alloc.allocate(2));
> +   tmp.type = BRW_REGISTER_TYPE_UD;
> +   for (int n = 0; n < 2; n++) {
> +  tmp.writemask = WRITEMASK_X;

If you used the writemask helper instead the tmp register could be
declared const.

> +  emit(MOV(offset(tmp, n), brw_imm_ud(di.i1)))->force_writemask_all = 
> true;
> +  tmp.writemask = WRITEMASK_Y;
> +  emit(MOV(offset(tmp, n), brw_imm_ud(di.i2)))->force_writemask_all = 
> true;

Because you're adding support for arbitrary exec sizes to the VEC4
back-end, wouldn't it make sense to use SIMD16 instructions here instead
of the loop?  (At least on HSW, on IVB it would end up being lowered
into four uncompressed instructions anyway)

> +   }
> +
> +   src_reg tmp_as_src = src_reg(retype(tmp, BRW_REGISTER_TYPE_DF));
> +   tmp_as_src.swizzle = BRW_SWIZZLE_;
> +   return tmp_as_src;

You could use the swizzle() helper instead of the last three lines:

| return swizzle(retype(tmp, BRW_REGISTER_TYPE_DF), BRW_SWIZZLE_XXX));

> +}
> +
>  void
>  vec4_visitor::nir_emit_alu(nir_alu_instr *instr)
>  {
> -- 
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

[Mesa-dev] [PATCH 1/2] anv/clear: Make cmd_clear_image take an actual VkClearValue

[Jason Ekstrand]

Cc: "12.0" 
---
 src/intel/vulkan/anv_meta_clear.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/intel/vulkan/anv_meta_clear.c 
b/src/intel/vulkan/anv_meta_clear.c
index e399498..fa07ec1 100644
--- a/src/intel/vulkan/anv_meta_clear.c
+++ b/src/intel/vulkan/anv_meta_clear.c
@@ -754,7 +754,7 @@ static void
 anv_cmd_clear_image(struct anv_cmd_buffer *cmd_buffer,
 struct anv_image *image,
 VkImageLayout image_layout,
-const VkClearValue *clear_value,
+VkClearValue clear_value,
 uint32_t range_count,
 const VkImageSubresourceRange *ranges)
 {
@@ -864,7 +864,7 @@ anv_cmd_clear_image(struct anv_cmd_buffer *cmd_buffer,
 VkClearAttachment clear_att = {
.aspectMask = range->aspectMask,
.colorAttachment = 0,
-   .clearValue = *clear_value,
+   .clearValue = clear_value,
 };
 
 VkClearRect clear_rect = {
@@ -903,7 +903,7 @@ void anv_CmdClearColorImage(
meta_clear_begin(_state, cmd_buffer);
 
anv_cmd_clear_image(cmd_buffer, image, imageLayout,
-   (const VkClearValue *) pColor,
+   (VkClearValue) { .color = *pColor },
rangeCount, pRanges);
 
meta_clear_end(_state, cmd_buffer);
@@ -924,7 +924,7 @@ void anv_CmdClearDepthStencilImage(
meta_clear_begin(_state, cmd_buffer);
 
anv_cmd_clear_image(cmd_buffer, image, imageLayout,
-   (const VkClearValue *) pDepthStencil,
+   (VkClearValue) { .depthStencil = *pDepthStencil },
rangeCount, pRanges);
 
meta_clear_end(_state, cmd_buffer);
@@ -1005,7 +1005,7 @@ do_buffer_fill(struct anv_cmd_buffer *cmd_buffer,
 
anv_cmd_clear_image(cmd_buffer, anv_image_from_handle(dest_image),
VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL,
-   _value, 1, );
+   clear_value, 1, );
 }
 
 void anv_CmdFillBuffer(
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 2/2] anv/clear: Clear E5B9G9R9 images as R32_UINT

[Jason Ekstrand]

We can't actually clear these images normally because we can't render to
them.  Instead, we have to manually unpack the rgb9e5 color value on the
CPU and clear it as R32_UINT.  We still have a bit of work to do to clear
non-power-of-two images, but this should get all of the power-of-two clears
working on at least Haswell.

Cc: "12.0" 
---
 src/intel/vulkan/anv_meta_clear.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/src/intel/vulkan/anv_meta_clear.c 
b/src/intel/vulkan/anv_meta_clear.c
index fa07ec1..d8b5ce0 100644
--- a/src/intel/vulkan/anv_meta_clear.c
+++ b/src/intel/vulkan/anv_meta_clear.c
@@ -25,6 +25,8 @@
 #include "anv_private.h"
 #include "nir/nir_builder.h"
 
+#include "gallium/auxiliary/util/u_format_rgb9e5.h"
+
 /** Vertex attributes for color clears.  */
 struct color_clear_vattrs {
struct anv_vue_header vue_header;
@@ -760,6 +762,16 @@ anv_cmd_clear_image(struct anv_cmd_buffer *cmd_buffer,
 {
VkDevice device_h = anv_device_to_handle(cmd_buffer->device);
 
+   VkFormat vk_format = image->vk_format;
+   if (vk_format == VK_FORMAT_E5B9G9R9_UFLOAT_PACK32) {
+  /* We can't actually render to this format so we have to work around it
+   * by manualy unpacking and using R32_UINT.
+   */
+  clear_value.color.uint32[0] =
+ float3_to_rgb9e5(clear_value.color.float32);
+  vk_format = VK_FORMAT_R32_UINT;
+   }
+
for (uint32_t r = 0; r < range_count; r++) {
   const VkImageSubresourceRange *range = [r];
   for (uint32_t l = 0; l < anv_get_levelCount(image, range); ++l) {
@@ -773,7 +785,7 @@ anv_cmd_clear_image(struct anv_cmd_buffer *cmd_buffer,
   .sType = VK_STRUCTURE_TYPE_IMAGE_VIEW_CREATE_INFO,
   .image = anv_image_to_handle(image),
   .viewType = anv_meta_get_view_type(image),
-  .format = image->vk_format,
+  .format = vk_format,
   .subresourceRange = {
  .aspectMask = range->aspectMask,
  .baseMipLevel = range->baseMipLevel + l,
@@ -800,7 +812,7 @@ anv_cmd_clear_image(struct anv_cmd_buffer *cmd_buffer,
);
 
 VkAttachmentDescription att_desc = {
-   .format = iview.vk_format,
+   .format = vk_format,
.loadOp = VK_ATTACHMENT_LOAD_OP_LOAD,
.storeOp = VK_ATTACHMENT_STORE_OP_STORE,
.stencilLoadOp = VK_ATTACHMENT_LOAD_OP_LOAD,
-- 
2.5.0.400.gff86faf

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

Re: [Mesa-dev] OpenCL for radeon Hawaii?

[Ilia Mirkin]

Without commenting on the opencl question(which should be supported, but
perhaps not a late enough spec version that your programs require), you
should be able to get all the necessary functionality by writing opengl
compute programs, supported in both desktop core and es profiles.

On Aug 3, 2016 14:45, "Sam Halliday"  wrote:

> Hello everybody,
>
> I recently got a Radeon R9 290x (aka Hawaii). I run ArchLinux, which has
> mesa 12.0.1.
>
> I am keen to try out mesa's partial OpenCL implementation. Ideally to
> use a BLAS implementation such as https://github.com/CNugteren/CLBlast
> but I'd also be happy to just write something basic like dense
> matrix/matrix multiplication in OpenCL.
>
>
> However, when I tried to run the "luxmark" OpenCL benchmark (the only
> way I could think to test if my card is supported), I got this error
>
> [PathOCLBaseRenderThread::0] Compiling kernels
> [PathOCLBaseRenderThread::0] PathOCL kernel compilation error ERROR
> clBuildProgram[CL_INVALID_BUILD_OPTIONS]:
> RUNTIME ERROR: PathOCLBase kernel compilation error
>
> which, I'm guessing, means that my GPU isn't supported for OpenCL by
> mesa yet. Is that correct? (I don't know how to get any more output or
> logs than this).
>
>
> Could somebody please help by letting me know if there is a ticket I
> could subscribe to track progress of support for my card (a simple
> search of the bug database didn't bring up anything obvious). This
> message is to the -dev list, so I am suppose I am saying that I am
> prepared to get my hands dirty... but I am primarily a Scala developer
> and haven't done any C in years so the extent of my help is limited.
>
> If somebody who knows what they are doing would be willing to implement
> some of the functionality needed, I'd be prepared to buy this GPU for
> them to use for their hacking - it's the least I could do (but it is an
> absolute monster, I didn't even know GPUs could be this big! I needed to
> get a bigger case for it).
>
>
> Somewhat tangentially, if OpenCL support is really not a possibility
> anytime soon, could somebody please point me in the direction of a way
> to use this card programmatically for something like matrix/matrix
> multiplication? (I'm prepared to go really low level if there is
> sufficient documentation).
>
>
> I'm not at all interested in using proprietary drivers for OpenCL.
>
>
> --
> Best regards,
> Sam
> ___
> 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] OpenCL for radeon Hawaii?

[Sam Halliday]

Hello everybody,

I recently got a Radeon R9 290x (aka Hawaii). I run ArchLinux, which has
mesa 12.0.1.

I am keen to try out mesa's partial OpenCL implementation. Ideally to
use a BLAS implementation such as https://github.com/CNugteren/CLBlast
but I'd also be happy to just write something basic like dense
matrix/matrix multiplication in OpenCL.


However, when I tried to run the "luxmark" OpenCL benchmark (the only
way I could think to test if my card is supported), I got this error

[PathOCLBaseRenderThread::0] Compiling kernels 
[PathOCLBaseRenderThread::0] PathOCL kernel compilation error ERROR 
clBuildProgram[CL_INVALID_BUILD_OPTIONS]: 
RUNTIME ERROR: PathOCLBase kernel compilation error

which, I'm guessing, means that my GPU isn't supported for OpenCL by
mesa yet. Is that correct? (I don't know how to get any more output or
logs than this).


Could somebody please help by letting me know if there is a ticket I
could subscribe to track progress of support for my card (a simple
search of the bug database didn't bring up anything obvious). This
message is to the -dev list, so I am suppose I am saying that I am
prepared to get my hands dirty... but I am primarily a Scala developer
and haven't done any C in years so the extent of my help is limited.

If somebody who knows what they are doing would be willing to implement
some of the functionality needed, I'd be prepared to buy this GPU for
them to use for their hacking - it's the least I could do (but it is an
absolute monster, I didn't even know GPUs could be this big! I needed to
get a bigger case for it).


Somewhat tangentially, if OpenCL support is really not a possibility
anytime soon, could somebody please point me in the direction of a way
to use this card programmatically for something like matrix/matrix
multiplication? (I'm prepared to go really low level if there is
sufficient documentation).


I'm not at all interested in using proprietary drivers for OpenCL.


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

Re: [Mesa-dev] dead code

[Rob Clark]

On Wed, Aug 3, 2016 at 2:48 PM, Rob Clark  wrote:
> On Wed, Aug 3, 2016 at 2:18 PM, Enrico Weigelt, metux IT consult
>  wrote:
>> On 03.08.2016 13:25, Rob Clark wrote:
>>
>>> Probably it would be on a case-by-case basis.  There are at least a
>>> few places with some useful debug code, ie. not the kind that you'd
>>> normally enable, but stuff you'd want if you were making changes in
>>> those areas..
>>
>> In those cases, shouldn't we instead introduce proper #define's ?
>
> At least in the cases I am thinking of, I'm not sure I really see the
> value in that..  it isn't really stuff I'd ask a user to turn on.  (If
> it came to that, I'd just ask the user to send me an apitrace so that
> I could debug, and possibly change some #if 0 to #if 1, and/or add
> other debug code in the process.)
>
> There is a DEBUG define that is enabled for --enable-debug builds, but
> most of the #if 0 debug code I've seen is stuff that is either too
> much overhead, or too much printf spam for debug builds.
>
> Anyways, I'm not saying there aren't some #if 0's that could be
> removed.. some look relatively trivial and easy enough to recreate.
> And/or useless.  I'm just saying we shouldn't blindly remove them all.
>
> And I wouldn't be surprised if there were some '#ifdef SOMETHING's
> that are actually worth removing.

just fyi, as far as clean-up tasks, fixing coverity[1] issues is a
good thing.. it does require requesting access, since I guess by
default the issues are not visible without being granted access (which
in more security sensitive projects, at least, makes sense)

[1] https://scan.coverity.com/projects/mesa
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 5/7] radeonsi: add has_draw_indirect_multi flag

[Nicolai Hähnle]

On 03.08.2016 19:43, Marek Olšák wrote:

Is this for the latest version of the MULTI packets and not the first
one without indirect_count?


According to the firmware person, it's for the latest version of those 
packets.


Nicolai




Marek

On Tue, Aug 2, 2016 at 9:41 PM, Nicolai Hähnle  wrote:

From: Nicolai Hähnle 

Prefer to use DRAW_(INDEX)_INDIRECT_MULTI when available in the firmware.

Versions for SI and CI already added as provided by the firmware team, but
keep in mind that they won't currently be used since the radeon kernel module
has no interface to query the firmware version.
---
 src/gallium/drivers/radeonsi/si_pipe.c   | 12 
 src/gallium/drivers/radeonsi/si_pipe.h   |  1 +
 src/gallium/drivers/radeonsi/si_state_draw.c |  2 +-
 3 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_pipe.c 
b/src/gallium/drivers/radeonsi/si_pipe.c
index 9304e5c..d2965050 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -754,6 +754,18 @@ struct pipe_screen *radeonsi_screen_create(struct 
radeon_winsys *ws)
sscreen->b.chip_class >= VI &&
sscreen->b.info.max_se >= 2;

+   sscreen->has_draw_indirect_multi =
+   (sscreen->b.family >= CHIP_POLARIS10) ||
+   (sscreen->b.chip_class == VI &&
+sscreen->b.info.pfp_fw_version >= 121 &&
+sscreen->b.info.me_fw_version >= 87) ||
+   (sscreen->b.chip_class == CIK &&
+sscreen->b.info.pfp_fw_version >= 211 &&
+sscreen->b.info.me_fw_version >= 173) ||
+   (sscreen->b.chip_class == SI &&
+sscreen->b.info.pfp_fw_version >= 121 &&
+sscreen->b.info.me_fw_version >= 87);
+
sscreen->b.has_cp_dma = true;
sscreen->b.has_streamout = true;
pipe_mutex_init(sscreen->shader_parts_mutex);
diff --git a/src/gallium/drivers/radeonsi/si_pipe.h 
b/src/gallium/drivers/radeonsi/si_pipe.h
index 326b819..bb570bb 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.h
+++ b/src/gallium/drivers/radeonsi/si_pipe.h
@@ -85,6 +85,7 @@ struct si_screen {
unsignedgs_table_depth;
unsignedtess_offchip_block_dw_size;
boolhas_distributed_tess;
+   boolhas_draw_indirect_multi;

/* Whether shaders are monolithic (1-part) or separate (3-part). */
booluse_monolithic_shaders;
diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c 
b/src/gallium/drivers/radeonsi/si_state_draw.c
index 54fe2bb..a918f85 100644
--- a/src/gallium/drivers/radeonsi/si_state_draw.c
+++ b/src/gallium/drivers/radeonsi/si_state_draw.c
@@ -634,7 +634,7 @@ static void si_emit_draw_packets(struct si_context *sctx,
radeon_emit(cs, index_max_size);
}

-   if (sctx->b.family < CHIP_POLARIS10) {
+   if (!sctx->screen->has_draw_indirect_multi) {
radeon_emit(cs, PKT3(info->indexed ? 
PKT3_DRAW_INDEX_INDIRECT
   : PKT3_DRAW_INDIRECT,
 3, render_cond_bit));
--
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] [PATCH v2 2/2] anv/blit2d: Add support for RGB destinations

[Jason Ekstrand]

This fixes 104 of the new image_clearing and copy_and_blit Vulkan CTS
tests.

Signed-off-by: Jason Ekstrand 
Cc: "12.0" 
---
 src/intel/vulkan/anv_meta_blit2d.c | 216 -
 1 file changed, 214 insertions(+), 2 deletions(-)

diff --git a/src/intel/vulkan/anv_meta_blit2d.c 
b/src/intel/vulkan/anv_meta_blit2d.c
index 30bc6ed..8ed7694 100644
--- a/src/intel/vulkan/anv_meta_blit2d.c
+++ b/src/intel/vulkan/anv_meta_blit2d.c
@@ -92,6 +92,21 @@ vk_format_for_size(int bs)
}
 }
 
+/* This function returns the format corresponding to a single component of the
+ * RGB format for the given size returned by vk_format_for_size().
+ */
+static VkFormat
+vk_single_component_format_for_rgb_size(int bs)
+{
+   switch (bs) {
+   case 3: return VK_FORMAT_R8_UNORM;
+   case 6: return VK_FORMAT_R16_UNORM;
+   case 12: return VK_FORMAT_R32_UINT;
+   default:
+  unreachable("Invalid format block size");
+   }
+}
+
 static void
 create_iview(struct anv_cmd_buffer *cmd_buffer,
  struct anv_meta_blit2d_surf *surf,
@@ -663,6 +678,141 @@ anv_meta_blit2d_w_tiled_dst(struct anv_cmd_buffer 
*cmd_buffer,
}
 }
 
+static void
+anv_meta_blit2d_rgb_dst(struct anv_cmd_buffer *cmd_buffer,
+struct anv_meta_blit2d_surf *src,
+enum blit2d_src_type src_type,
+struct anv_meta_blit2d_surf *dst,
+unsigned num_rects,
+struct anv_meta_blit2d_rect *rects)
+{
+   struct anv_device *device = cmd_buffer->device;
+
+   for (unsigned r = 0; r < num_rects; ++r) {
+  struct blit2d_src_temps src_temps;
+  blit2d_bind_src(cmd_buffer, src, src_type, [r], _temps);
+
+  assert(dst->bs % 3 == 0);
+  assert(dst->tiling == ISL_TILING_LINEAR);
+
+  uint32_t offset;
+  isl_tiling_get_intratile_offset_el(_buffer->device->isl_dev,
+ dst->tiling, 1, dst->pitch,
+ rects[r].dst_x, rects[r].dst_y,
+ ,
+ [r].dst_x, [r].dst_y);
+
+  /* A red surface three times as wide as the actual RGB destination */
+  struct anv_meta_blit2d_surf dst_R = {
+ .bo = dst->bo,
+ .tiling = dst->tiling,
+ .base_offset = dst->base_offset,
+ .bs = dst->bs / 3,
+ .pitch = dst->pitch,
+  };
+
+  struct blit2d_dst_temps dst_temps;
+  blit2d_bind_dst(cmd_buffer, _R, offset,
+  (rects[r].dst_x + rects[r].width) * 3,
+  rects[r].dst_y + rects[r].height,
+  vk_single_component_format_for_rgb_size(dst->bs),
+  _temps);
+
+  struct blit_vb_data {
+ float pos[2];
+ float tex_coord[3];
+  } *vb_data;
+
+  unsigned vb_size = sizeof(struct anv_vue_header) + 3 * sizeof(*vb_data);
+
+  struct anv_state vb_state =
+ anv_cmd_buffer_alloc_dynamic_state(cmd_buffer, vb_size, 16);
+  memset(vb_state.map, 0, sizeof(struct anv_vue_header));
+  vb_data = vb_state.map + sizeof(struct anv_vue_header);
+
+  vb_data[0] = (struct blit_vb_data) {
+ .pos = {
+(rects[r].dst_x + rects[r].width) * 3,
+rects[r].dst_y + rects[r].height,
+ },
+ .tex_coord = {
+rects[r].src_x + rects[r].width,
+rects[r].src_y + rects[r].height,
+src->pitch,
+ },
+  };
+
+  vb_data[1] = (struct blit_vb_data) {
+ .pos = {
+rects[r].dst_x * 3,
+rects[r].dst_y + rects[r].height,
+ },
+ .tex_coord = {
+rects[r].src_x,
+rects[r].src_y + rects[r].height,
+src->pitch,
+ },
+  };
+
+  vb_data[2] = (struct blit_vb_data) {
+ .pos = {
+rects[r].dst_x * 3,
+rects[r].dst_y,
+ },
+ .tex_coord = {
+rects[r].src_x,
+rects[r].src_y,
+src->pitch,
+ },
+  };
+
+  if (!device->info.has_llc)
+ anv_state_clflush(vb_state);
+
+  struct anv_buffer vertex_buffer = {
+ .device = device,
+ .size = vb_size,
+ .bo = >dynamic_state_block_pool.bo,
+ .offset = vb_state.offset,
+  };
+
+  anv_CmdBindVertexBuffers(anv_cmd_buffer_to_handle(cmd_buffer), 0, 2,
+ (VkBuffer[]) {
+anv_buffer_to_handle(_buffer),
+anv_buffer_to_handle(_buffer)
+ },
+ (VkDeviceSize[]) {
+0,
+sizeof(struct anv_vue_header),
+ });
+
+  ANV_CALL(CmdBeginRenderPass)(anv_cmd_buffer_to_handle(cmd_buffer),
+ &(VkRenderPassBeginInfo) {
+.sType = VK_STRUCTURE_TYPE_RENDER_PASS_BEGIN_INFO,
+.renderPass = device->meta_state.blit2d.render_pass,
+.framebuffer = 

Re: [Mesa-dev] dead code

[Rob Clark]

On Wed, Aug 3, 2016 at 2:18 PM, Enrico Weigelt, metux IT consult
 wrote:
> On 03.08.2016 13:25, Rob Clark wrote:
>
>> Probably it would be on a case-by-case basis.  There are at least a
>> few places with some useful debug code, ie. not the kind that you'd
>> normally enable, but stuff you'd want if you were making changes in
>> those areas..
>
> In those cases, shouldn't we instead introduce proper #define's ?

At least in the cases I am thinking of, I'm not sure I really see the
value in that..  it isn't really stuff I'd ask a user to turn on.  (If
it came to that, I'd just ask the user to send me an apitrace so that
I could debug, and possibly change some #if 0 to #if 1, and/or add
other debug code in the process.)

There is a DEBUG define that is enabled for --enable-debug builds, but
most of the #if 0 debug code I've seen is stuff that is either too
much overhead, or too much printf spam for debug builds.

Anyways, I'm not saying there aren't some #if 0's that could be
removed.. some look relatively trivial and easy enough to recreate.
And/or useless.  I'm just saying we shouldn't blindly remove them all.

And I wouldn't be surprised if there were some '#ifdef SOMETHING's
that are actually worth removing.

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

Re: [Mesa-dev] [PATCH 1/2] vl: add a lanczos interpolation filter v3

[Nayan Deshmukh]

Hi Christian

On Wed, Aug 3, 2016 at 6:16 PM, Christian König 
wrote:

> Sorry for the delay I've been on vacation for a week.
>
> Good to hear back from you !!


> Where you able to fix the problem Andy reported? I was able to rather
> easily reproduce that.
>
> I have tested it on my system and my friend's system and it seems to be
working fine. It would be great
if Andy can confirm the same.

Leave out level 8&9 is clearly a good idea and I'm rather eager to commit
> this set now if it doesn't show any more obvious problems.
>
> Me too :)

Regards,
Nayan.


> Regards,
> Christian.
>
>
> Am 01.08.2016 um 12:56 schrieb Nayan Deshmukh:
>
>> v2: avoid dividing by zero when calculating lanczos
>>
>> Signed-off-by: Nayan Deshmukh 
>> ---
>>   src/gallium/auxiliary/Makefile.sources   |   2 +
>>   src/gallium/auxiliary/vl/vl_lanczos_filter.c | 445
>> +++
>>   src/gallium/auxiliary/vl/vl_lanczos_filter.h |  63 
>>   3 files changed, 510 insertions(+)
>>   create mode 100644 src/gallium/auxiliary/vl/vl_lanczos_filter.c
>>   create mode 100644 src/gallium/auxiliary/vl/vl_lanczos_filter.h
>>
>> diff --git a/src/gallium/auxiliary/Makefile.sources
>> b/src/gallium/auxiliary/Makefile.sources
>> index e0311bf..4eb0f65 100644
>> --- a/src/gallium/auxiliary/Makefile.sources
>> +++ b/src/gallium/auxiliary/Makefile.sources
>> @@ -330,6 +330,8 @@ VL_SOURCES := \
>> vl/vl_deint_filter.h \
>> vl/vl_idct.c \
>> vl/vl_idct.h \
>> +   vl/vl_lanczos_filter.c \
>> +   vl/vl_lanczos_filter.h \
>> vl/vl_matrix_filter.c \
>> vl/vl_matrix_filter.h \
>> vl/vl_mc.c \
>> diff --git a/src/gallium/auxiliary/vl/vl_lanczos_filter.c
>> b/src/gallium/auxiliary/vl/vl_lanczos_filter.c
>> new file mode 100644
>> index 000..0601b90
>> --- /dev/null
>> +++ b/src/gallium/auxiliary/vl/vl_lanczos_filter.c
>> @@ -0,0 +1,445 @@
>>
>> +/**
>> + *
>> + * Copyright 2016 Nayan Deshmukh.
>> + * All Rights Reserved.
>> + *
>> + * Permission is hereby granted, free of charge, to any person obtaining
>> a
>> + * copy of this software and associated documentation files (the
>> + * "Software"), to deal in the Software without restriction, including
>> + * without limitation the rights to use, copy, modify, merge, publish,
>> + * distribute, sub license, and/or sell copies of the Software, and to
>> + * permit persons to whom the Software is furnished to do so, subject to
>> + * the following conditions:
>> + *
>> + * The above copyright notice and this permission notice (including the
>> + * next paragraph) shall be included in all copies or substantial
>> portions
>> + * of the Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> EXPRESS
>> + * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
>> + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>> NON-INFRINGEMENT.
>> + * IN NO EVENT SHALL VMWARE AND/OR ITS SUPPLIERS BE LIABLE FOR
>> + * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF
>> CONTRACT,
>> + * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
>> + * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
>> + *
>> +
>> **/
>> +
>> +#include 
>> +
>> +#include "pipe/p_context.h"
>> +
>> +#include "tgsi/tgsi_ureg.h"
>> +
>> +#include "util/u_draw.h"
>> +#include "util/u_memory.h"
>> +#include "util/u_math.h"
>> +#include "util/u_rect.h"
>> +
>> +#include "vl_types.h"
>> +#include "vl_vertex_buffers.h"
>> +#include "vl_lanczos_filter.h"
>> +
>> +enum VS_OUTPUT
>> +{
>> +   VS_O_VPOS = 0,
>> +   VS_O_VTEX = 0
>> +};
>> +
>> +static void *
>> +create_vert_shader(struct vl_lanczos_filter *filter)
>> +{
>> +   struct ureg_program *shader;
>> +   struct ureg_src i_vpos;
>> +   struct ureg_dst o_vpos, o_vtex;
>> +
>> +   shader = ureg_create(PIPE_SHADER_VERTEX);
>> +   if (!shader)
>> +  return NULL;
>> +
>> +   i_vpos = ureg_DECL_vs_input(shader, 0);
>> +   o_vpos = ureg_DECL_output(shader, TGSI_SEMANTIC_POSITION, VS_O_VPOS);
>> +   o_vtex = ureg_DECL_output(shader, TGSI_SEMANTIC_GENERIC, VS_O_VTEX);
>> +
>> +   ureg_MOV(shader, o_vpos, i_vpos);
>> +   ureg_MOV(shader, o_vtex, i_vpos);
>> +
>> +   ureg_END(shader);
>> +
>> +   return ureg_create_shader_and_destroy(shader, filter->pipe);
>> +}
>> +
>> +static void
>> +create_frag_shader_lanczos(struct ureg_program *shader, struct ureg_src
>> a,
>> +   struct ureg_src x, struct ureg_dst o_fragment)
>> +{
>> +   struct ureg_dst temp[8];
>> +   unsigned i;
>> +
>> +   for(i = 0; i < 8; ++i)
>> +   temp[i] = ureg_DECL_temporary(shader);
>> +
>> +   /*
>> +* temp[0] = (x == 0) ? 1.0f : x
>> +* temp[7] = (sin(pi * x) * sin ((pi * x)/a)) / x^2
>> +* o_fragment = (x == 0) ? 1.0f : temp[7]
>> +*/
>> +   

Re: [Mesa-dev] dead code

[Enrico Weigelt, metux IT consult]

On 03.08.2016 13:25, Rob Clark wrote:

> Probably it would be on a case-by-case basis.  There are at least a
> few places with some useful debug code, ie. not the kind that you'd
> normally enable, but stuff you'd want if you were making changes in
> those areas..

In those cases, shouldn't we instead introduce proper #define's ?


--mtx

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

Re: [Mesa-dev] [PATCH 4/7] radeonsi: transpose indirect/index draw dispatch

[Marek Olšák]

Patches 1-4:

Reviewed-by: Marek Olšák 

Marek

On Tue, Aug 2, 2016 at 9:41 PM, Nicolai Hähnle  wrote:
> From: Nicolai Hähnle 
>
> This allows better code sharing for indirect draw calls.
> ---
>  src/gallium/drivers/radeonsi/si_state_draw.c | 76 
> 
>  1 file changed, 31 insertions(+), 45 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c 
> b/src/gallium/drivers/radeonsi/si_state_draw.c
> index 6b8ab9f..54fe2bb 100644
> --- a/src/gallium/drivers/radeonsi/si_state_draw.c
> +++ b/src/gallium/drivers/radeonsi/si_state_draw.c
> @@ -619,36 +619,45 @@ static void si_emit_draw_packets(struct si_context 
> *sctx,
>   RADEON_USAGE_READ, 
> RADEON_PRIO_DRAW_INDIRECT);
> }
>
> -   if (info->indexed) {
> -   if (info->indirect) {
> -   assert(info->indirect_offset % 4 == 0);
> +   if (info->indirect) {
> +   unsigned di_src_sel = info->indexed ? V_0287F0_DI_SRC_SEL_DMA
> +   : 
> V_0287F0_DI_SRC_SEL_AUTO_INDEX;
> +
> +   assert(info->indirect_offset % 4 == 0);
>
> +   if (info->indexed) {
> radeon_emit(cs, PKT3(PKT3_INDEX_BASE, 1, 0));
> radeon_emit(cs, index_va);
> radeon_emit(cs, index_va >> 32);
>
> radeon_emit(cs, PKT3(PKT3_INDEX_BUFFER_SIZE, 0, 0));
> radeon_emit(cs, index_max_size);
> +   }
>
> -   if (sctx->b.family < CHIP_POLARIS10) {
> -   radeon_emit(cs, 
> PKT3(PKT3_DRAW_INDEX_INDIRECT, 3, render_cond_bit));
> -   radeon_emit(cs, info->indirect_offset);
> -   radeon_emit(cs, (sh_base_reg + 
> SI_SGPR_BASE_VERTEX * 4 - SI_SH_REG_OFFSET) >> 2);
> -   radeon_emit(cs, (sh_base_reg + 
> SI_SGPR_START_INSTANCE * 4 - SI_SH_REG_OFFSET) >> 2);
> -   radeon_emit(cs, V_0287F0_DI_SRC_SEL_DMA);
> -   } else {
> -   radeon_emit(cs, 
> PKT3(PKT3_DRAW_INDEX_INDIRECT_MULTI, 8, render_cond_bit));
> -   radeon_emit(cs, info->indirect_offset);
> -   radeon_emit(cs, (sh_base_reg + 
> SI_SGPR_BASE_VERTEX * 4 - SI_SH_REG_OFFSET) >> 2);
> -   radeon_emit(cs, (sh_base_reg + 
> SI_SGPR_START_INSTANCE * 4 - SI_SH_REG_OFFSET) >> 2);
> -   radeon_emit(cs, 0); /* draw_index */
> -   radeon_emit(cs, 1); /* count */
> -   radeon_emit(cs, 0); /* count_addr -- disabled 
> */
> -   radeon_emit(cs, 0);
> -   radeon_emit(cs, 16); /* stride */
> -   radeon_emit(cs, V_0287F0_DI_SRC_SEL_DMA);
> -   }
> +   if (sctx->b.family < CHIP_POLARIS10) {
> +   radeon_emit(cs, PKT3(info->indexed ? 
> PKT3_DRAW_INDEX_INDIRECT
> +  : 
> PKT3_DRAW_INDIRECT,
> +3, render_cond_bit));
> +   radeon_emit(cs, info->indirect_offset);
> +   radeon_emit(cs, (sh_base_reg + SI_SGPR_BASE_VERTEX * 
> 4 - SI_SH_REG_OFFSET) >> 2);
> +   radeon_emit(cs, (sh_base_reg + SI_SGPR_START_INSTANCE 
> * 4 - SI_SH_REG_OFFSET) >> 2);
> +   radeon_emit(cs, di_src_sel);
> } else {
> +   radeon_emit(cs, PKT3(info->indexed ? 
> PKT3_DRAW_INDEX_INDIRECT_MULTI :
> +
> PKT3_DRAW_INDIRECT_MULTI,
> +8, render_cond_bit));
> +   radeon_emit(cs, info->indirect_offset);
> +   radeon_emit(cs, (sh_base_reg + SI_SGPR_BASE_VERTEX * 
> 4 - SI_SH_REG_OFFSET) >> 2);
> +   radeon_emit(cs, (sh_base_reg + SI_SGPR_START_INSTANCE 
> * 4 - SI_SH_REG_OFFSET) >> 2);
> +   radeon_emit(cs, 0); /* draw_index */
> +   radeon_emit(cs, 1); /* count */
> +   radeon_emit(cs, 0); /* count_addr -- disabled */
> +   radeon_emit(cs, 0);
> +   radeon_emit(cs, 16); /* stride */
> +   radeon_emit(cs, di_src_sel);
> +   }
> +   } else {
> +   if (info->indexed) {
> index_va += info->start * ib->index_size;
>
> radeon_emit(cs, PKT3(PKT3_DRAW_INDEX_2, 4, 
> render_cond_bit));
> @@ -657,34 +666,11 @@ static void si_emit_draw_packets(struct si_context 

[Mesa-dev] [PATCH 5/6] util/format: Use explicitly sized types

[Jason Ekstrand]

Both the rgb9e5 and r11g11b10 formats are defined based on how they are
packed into a 32-bit integer.  It makes sense that the functions that
manipulate them take an explicitly sized type.

Signed-off-by: Jason Ekstrand 
---
 src/util/format_r11g11b10f.h | 10 ++
 src/util/format_rgb9e5.h |  4 ++--
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/src/util/format_r11g11b10f.h b/src/util/format_r11g11b10f.h
index 218822b..5fe2e51 100644
--- a/src/util/format_r11g11b10f.h
+++ b/src/util/format_r11g11b10f.h
@@ -27,6 +27,8 @@
  * below.
  */
 
+#include 
+
 #define UF11(e, m)   ((e << 6) | (m))
 #define UF11_EXPONENT_BIAS   15
 #define UF11_EXPONENT_BITS   0x1F
@@ -45,7 +47,7 @@
 
 #define F32_INFINITY 0x7f80
 
-static inline unsigned f32_to_uf11(float val)
+static inline uint32_t f32_to_uf11(float val)
 {
union {
   float f;
@@ -131,7 +133,7 @@ static inline float uf11_to_f32(uint16_t val)
return f32.f;
 }
 
-static inline unsigned f32_to_uf10(float val)
+static inline uint32_t f32_to_uf10(float val)
 {
union {
   float f;
@@ -217,14 +219,14 @@ static inline float uf10_to_f32(uint16_t val)
return f32.f;
 }
 
-static inline unsigned float3_to_r11g11b10f(const float rgb[3])
+static inline uint32_t float3_to_r11g11b10f(const float rgb[3])
 {
return ( f32_to_uf11(rgb[0]) & 0x7ff) |
   ((f32_to_uf11(rgb[1]) & 0x7ff) << 11) |
   ((f32_to_uf10(rgb[2]) & 0x3ff) << 22);
 }
 
-static inline void r11g11b10f_to_float3(unsigned rgb, float retval[3])
+static inline void r11g11b10f_to_float3(uint32_t rgb, float retval[3])
 {
retval[0] = uf11_to_f32( rgb& 0x7ff);
retval[1] = uf11_to_f32((rgb >> 11) & 0x7ff);
diff --git a/src/util/format_rgb9e5.h b/src/util/format_rgb9e5.h
index 2559e1e..70ad04f 100644
--- a/src/util/format_rgb9e5.h
+++ b/src/util/format_rgb9e5.h
@@ -57,7 +57,7 @@ static inline int rgb9e5_ClampRange(float x)
   return f.u;
 }
 
-static inline unsigned int float3_to_rgb9e5(const float rgb[3])
+static inline uint32_t float3_to_rgb9e5(const float rgb[3])
 {
int rm, gm, bm, exp_shared;
uint32_t revdenom_biasedexp;
@@ -104,7 +104,7 @@ static inline unsigned int float3_to_rgb9e5(const float 
rgb[3])
return (exp_shared << 27) | (bm << 18) | (gm << 9) | rm;
 }
 
-static inline void rgb9e5_to_float3(unsigned rgb, float retval[3])
+static inline void rgb9e5_to_float3(uint32_t rgb, float retval[3])
 {
int exponent;
union { float f; uint32_t u; } scale;
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 4/6] util/rgb9e5: Get rid of the float754 union

[Jason Ekstrand]

There are a number of reasons for this refactor.  First, format_rgb9e5.h is
not something that a user would expect to define such a generic union.
Second, defining it requires checking for endianness which is ugly.  Third,
90% of what we were doing with the union was float <-> uint32_t bitcasts
and the remaining 10% can be done with a sinmple left-shift by 23.

Signed-off-by: Jason Ekstrand 
---
 src/util/format_rgb9e5.h | 69 +++-
 1 file changed, 27 insertions(+), 42 deletions(-)

diff --git a/src/util/format_rgb9e5.h b/src/util/format_rgb9e5.h
index 644b9d8..2559e1e 100644
--- a/src/util/format_rgb9e5.h
+++ b/src/util/format_rgb9e5.h
@@ -28,6 +28,7 @@
 #define RGB9E5_H
 
 #include 
+#include 
 
 #include "c99_math.h"
 
@@ -41,59 +42,43 @@
 #define MAX_RGB9E5_MANTISSA  (RGB9E5_MANTISSA_VALUES-1)
 #define MAX_RGB9E5   
(((float)MAX_RGB9E5_MANTISSA)/RGB9E5_MANTISSA_VALUES * (1< 0x7f80)
+   if (f.u > 0x7f80)
   /* catches neg, NaNs */
   return 0;
-   else if (f.raw >= max.raw)
-  return max.raw;
+   else if (f.u >= max.u)
+  return max.u;
else
-  return f.raw;
+  return f.u;
 }
 
 static inline unsigned int float3_to_rgb9e5(const float rgb[3])
 {
int rm, gm, bm, exp_shared;
-   float754 revdenom = {0};
-   float754 rc, bc, gc, maxrgb;
+   uint32_t revdenom_biasedexp;
+   union { float f; uint32_t u; } rc, bc, gc, maxrgb, revdenom;
 
-   rc.raw = rgb9e5_ClampRange(rgb[0]);
-   gc.raw = rgb9e5_ClampRange(rgb[1]);
-   bc.raw = rgb9e5_ClampRange(rgb[2]);
-   maxrgb.raw = MAX3(rc.raw, gc.raw, bc.raw);
+   rc.u = rgb9e5_ClampRange(rgb[0]);
+   gc.u = rgb9e5_ClampRange(rgb[1]);
+   bc.u = rgb9e5_ClampRange(rgb[2]);
+   maxrgb.u = MAX3(rc.u, gc.u, bc.u);
 
/*
 * Compared to what the spec suggests, instead of conditionally adjusting
 * the exponent after the fact do it here by doing the equivalent of +0.5 -
 * the int add will spill over into the exponent in this case.
 */
-   maxrgb.raw += maxrgb.raw & (1 << (23-9));
-   exp_shared = MAX2((maxrgb.raw >> 23), -RGB9E5_EXP_BIAS - 1 + 127) +
+   maxrgb.u += maxrgb.u & (1 << (23-9));
+   exp_shared = MAX2((maxrgb.u >> 23), -RGB9E5_EXP_BIAS - 1 + 127) +
 1 + RGB9E5_EXP_BIAS - 127;
-   revdenom.field.biasedexponent = 127 - (exp_shared - RGB9E5_EXP_BIAS -
-  RGB9E5_MANTISSA_BITS) + 1;
+   revdenom_biasedexp = 127 - (exp_shared - RGB9E5_EXP_BIAS -
+   RGB9E5_MANTISSA_BITS) + 1;
+   revdenom.u = revdenom_biasedexp << 23;
assert(exp_shared <= RGB9E5_MAX_VALID_BIASED_EXP);
 
/*
@@ -102,9 +87,9 @@ static inline unsigned int float3_to_rgb9e5(const float 
rgb[3])
 * We avoid the doubles ((int) rc * revdenom + 0.5) by doing the rounding
 * ourselves (revdenom was adjusted by +1, above).
 */
-   rm = (int) (rc.value * revdenom.value);
-   gm = (int) (gc.value * revdenom.value);
-   bm = (int) (bc.value * revdenom.value);
+   rm = (int) (rc.f * revdenom.f);
+   gm = (int) (gc.f * revdenom.f);
+   bm = (int) (bc.f * revdenom.f);
rm = (rm & 1) + (rm >> 1);
gm = (gm & 1) + (gm >> 1);
bm = (bm & 1) + (bm >> 1);
@@ -122,14 +107,14 @@ static inline unsigned int float3_to_rgb9e5(const float 
rgb[3])
 static inline void rgb9e5_to_float3(unsigned rgb, float retval[3])
 {
int exponent;
-   float754 scale = {0};
+   union { float f; uint32_t u; } scale;
 
exponent = (rgb >> 27) - RGB9E5_EXP_BIAS - RGB9E5_MANTISSA_BITS;
-   scale.field.biasedexponent = exponent + 127;
+   scale.u = (exponent + 127) << 23;
 
-   retval[0] = ( rgb& 0x1ff) * scale.value;
-   retval[1] = ((rgb >> 9)  & 0x1ff) * scale.value;
-   retval[2] = ((rgb >> 18) & 0x1ff) * scale.value;
+   retval[0] = ( rgb& 0x1ff) * scale.f;
+   retval[1] = ((rgb >> 9)  & 0x1ff) * scale.f;
+   retval[2] = ((rgb >> 18) & 0x1ff) * scale.f;
 }
 
 #endif
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 0/6] util: Clean up rgb9e5 and r11g11b10f

[Jason Ekstrand]

This little series pulls the helpers for rgb9e5 and r11g11b10f into
src/util and cleans them up a bit.  We've been using them from both gallium
and mesa main for quite some time now but, since they were header-only,
they got left in gallium.

Jason Ekstrand (6):
  util: Move format_rgb9e5.h to src/util
  util: Move format_r11g11b10f.h to src/util
  util/format_rgb9e5: Get rid of the rgb9e5 union
  util/rgb9e5: Get rid of the float754 union
  util/format: Use explicitly sized types
  util/r11g11b10f: Whitespace cleanups

 src/gallium/auxiliary/Makefile.sources|   2 -
 src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c |   2 +-
 src/gallium/auxiliary/util/u_format_other.c   |   4 +-
 src/gallium/auxiliary/util/u_format_r11g11b10f.h  | 232 --
 src/gallium/auxiliary/util/u_format_rgb9e5.h  | 161 ---
 src/mesa/main/format_pack.py  |   4 +-
 src/mesa/main/format_unpack.py|   4 +-
 src/mesa/main/mipmap.c|   4 +-
 src/mesa/main/texstore.c  |   4 +-
 src/mesa/swrast/s_texfetch.c  |   4 +-
 src/mesa/vbo/vbo_attrib_tmp.h |   2 +-
 src/util/Makefile.sources |   2 +
 src/util/format_r11g11b10f.h  | 227 +
 src/util/format_rgb9e5.h  | 120 +++
 14 files changed, 363 insertions(+), 409 deletions(-)
 delete mode 100644 src/gallium/auxiliary/util/u_format_r11g11b10f.h
 delete mode 100644 src/gallium/auxiliary/util/u_format_rgb9e5.h
 create mode 100644 src/util/format_r11g11b10f.h
 create mode 100644 src/util/format_rgb9e5.h

-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 2/6] util: Move format_r11g11b10f.h to src/util

[Jason Ekstrand]

It's used from both mesa main and gallium.

Signed-off-by: Jason Ekstrand 
---
 src/gallium/auxiliary/Makefile.sources   |   1 -
 src/gallium/auxiliary/util/u_format_other.c  |   2 +-
 src/gallium/auxiliary/util/u_format_r11g11b10f.h | 232 ---
 src/mesa/main/format_pack.py |   2 +-
 src/mesa/main/format_unpack.py   |   2 +-
 src/mesa/main/mipmap.c   |   2 +-
 src/mesa/main/texstore.c |   2 +-
 src/mesa/swrast/s_texfetch.c |   2 +-
 src/mesa/vbo/vbo_attrib_tmp.h|   2 +-
 src/util/Makefile.sources|   1 +
 src/util/format_r11g11b10f.h | 232 +++
 11 files changed, 240 insertions(+), 240 deletions(-)
 delete mode 100644 src/gallium/auxiliary/util/u_format_r11g11b10f.h
 create mode 100644 src/util/format_r11g11b10f.h

diff --git a/src/gallium/auxiliary/Makefile.sources 
b/src/gallium/auxiliary/Makefile.sources
index 230f52b..586f057 100644
--- a/src/gallium/auxiliary/Makefile.sources
+++ b/src/gallium/auxiliary/Makefile.sources
@@ -228,7 +228,6 @@ C_SOURCES := \
util/u_format_latc.h \
util/u_format_other.c \
util/u_format_other.h \
-   util/u_format_r11g11b10f.h \
util/u_format_rgtc.c \
util/u_format_rgtc.h \
util/u_format_s3tc.c \
diff --git a/src/gallium/auxiliary/util/u_format_other.c 
b/src/gallium/auxiliary/util/u_format_other.c
index 8197835..c53bf55 100644
--- a/src/gallium/auxiliary/util/u_format_other.c
+++ b/src/gallium/auxiliary/util/u_format_other.c
@@ -29,7 +29,7 @@
 #include "u_math.h"
 #include "u_format_other.h"
 #include "util/format_rgb9e5.h"
-#include "u_format_r11g11b10f.h"
+#include "util/format_r11g11b10f.h"
 
 
 void
diff --git a/src/gallium/auxiliary/util/u_format_r11g11b10f.h 
b/src/gallium/auxiliary/util/u_format_r11g11b10f.h
deleted file mode 100644
index 218822b..000
--- a/src/gallium/auxiliary/util/u_format_r11g11b10f.h
+++ /dev/null
@@ -1,232 +0,0 @@
-/*
- * Copyright (C) 2011 Marek Olšák 
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sublicense,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice (including the next
- * paragraph) shall be included in all copies or substantial portions of the
- * Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
- * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
- * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
- * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
- * DEALINGS IN THE SOFTWARE.
- */
-
-/* Based on code from The OpenGL Programming Guide / 7th Edition, Appendix J.
- * Available here: http://www.opengl-redbook.com/appendices/
- * The algorithm in the book contains a bug though, which is fixed in the code
- * below.
- */
-
-#define UF11(e, m)   ((e << 6) | (m))
-#define UF11_EXPONENT_BIAS   15
-#define UF11_EXPONENT_BITS   0x1F
-#define UF11_EXPONENT_SHIFT  6
-#define UF11_MANTISSA_BITS   0x3F
-#define UF11_MANTISSA_SHIFT  (23 - UF11_EXPONENT_SHIFT)
-#define UF11_MAX_EXPONENT(UF11_EXPONENT_BITS << UF11_EXPONENT_SHIFT)
-
-#define UF10(e, m)   ((e << 5) | (m))
-#define UF10_EXPONENT_BIAS   15
-#define UF10_EXPONENT_BITS   0x1F
-#define UF10_EXPONENT_SHIFT  5
-#define UF10_MANTISSA_BITS   0x1F
-#define UF10_MANTISSA_SHIFT  (23 - UF10_EXPONENT_SHIFT)
-#define UF10_MAX_EXPONENT(UF10_EXPONENT_BITS << UF10_EXPONENT_SHIFT)
-
-#define F32_INFINITY 0x7f80
-
-static inline unsigned f32_to_uf11(float val)
-{
-   union {
-  float f;
-  uint32_t ui;
-   } f32 = {val};
-
-   uint16_t uf11 = 0;
-
-   /* Decode little-endian 32-bit floating-point value */
-   int sign = (f32.ui >> 16) & 0x8000;
-   /* Map exponent to the range [-127,128] */
-   int exponent = ((f32.ui >> 23) & 0xff) - 127;
-   int mantissa = f32.ui & 0x007f;
-
-   if (exponent == 128) { /* Infinity or NaN */
-  /* From the GL_EXT_packed_float spec:
-   *
-   * "Additionally: negative infinity is converted to zero; positive
-   *  infinity is converted to positive infinity; and both positive and
-   *  negative NaN are converted to positive NaN."
-   */
-  uf11 = UF11_MAX_EXPONENT;
-  if (mantissa) {
- uf11 |= 

[Mesa-dev] [PATCH 6/6] util/r11g11b10f: Whitespace cleanups

[Jason Ekstrand]

Signed-off-by: Jason Ekstrand 
---
 src/util/format_r11g11b10f.h | 21 +++--
 1 file changed, 7 insertions(+), 14 deletions(-)

diff --git a/src/util/format_r11g11b10f.h b/src/util/format_r11g11b10f.h
index 5fe2e51..c9e967c 100644
--- a/src/util/format_r11g11b10f.h
+++ b/src/util/format_r11g11b10f.h
@@ -86,8 +86,7 @@ static inline uint32_t f32_to_uf11(float val)
*  converted to 65024."
*/
   uf11 = UF11(30, 63);
-   }
-   else if (exponent > -15) { /* Representable value */
+   } else if (exponent > -15) { /* Representable value */
   exponent += UF11_EXPONENT_BIAS;
   mantissa >>= UF11_MANTISSA_SHIFT;
   uf11 = exponent << UF11_EXPONENT_SHIFT | mantissa;
@@ -113,17 +112,14 @@ static inline float uf11_to_f32(uint16_t val)
  const float scale = 1.0 / (1 << 20);
  f32.f = scale * mantissa;
   }
-   }
-   else if (exponent == 31) {
+   } else if (exponent == 31) {
   f32.ui = F32_INFINITY | mantissa;
-   }
-   else {
+   } else {
   float scale, decimal;
   exponent -= 15;
   if (exponent < 0) {
  scale = 1.0f / (1 << -exponent);
-  }
-  else {
+  } else {
  scale = (float) (1 << exponent);
   }
   decimal = 1.0f + (float) mantissa / 64;
@@ -172,8 +168,7 @@ static inline uint32_t f32_to_uf10(float val)
*  converted to 64512."
*/
   uf10 = UF10(30, 31);
-   }
-   else if (exponent > -15) { /* Representable value */
+   } else if (exponent > -15) { /* Representable value */
   exponent += UF10_EXPONENT_BIAS;
   mantissa >>= UF10_MANTISSA_SHIFT;
   uf10 = exponent << UF10_EXPONENT_SHIFT | mantissa;
@@ -199,11 +194,9 @@ static inline float uf10_to_f32(uint16_t val)
  const float scale = 1.0 / (1 << 20);
  f32.f = scale * mantissa;
   }
-   }
-   else if (exponent == 31) {
+   } else if (exponent == 31) {
   f32.ui = F32_INFINITY | mantissa;
-   }
-   else {
+   } else {
   float scale, decimal;
   exponent -= 15;
   if (exponent < 0) {
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 3/6] util/format_rgb9e5: Get rid of the rgb9e5 union

[Jason Ekstrand]

The rgb9e5 format is a packed format defined in terms of slicing up a
single 32-bit value.  The bitfields are far more confusing than simple
shifts and require that we check the endianness.

Signed-off-by: Jason Ekstrand 
---
 src/util/format_rgb9e5.h | 38 ++
 1 file changed, 6 insertions(+), 32 deletions(-)

diff --git a/src/util/format_rgb9e5.h b/src/util/format_rgb9e5.h
index 21feba7..644b9d8 100644
--- a/src/util/format_rgb9e5.h
+++ b/src/util/format_rgb9e5.h
@@ -57,24 +57,6 @@ typedef union {
} field;
 } float754;
 
-typedef union {
-   unsigned int raw;
-   struct {
-#if defined(MESA_BIG_ENDIAN) || defined(PIPE_ARCH_BIG_ENDIAN)
-  unsigned int biasedexponent:RGB9E5_EXPONENT_BITS;
-  unsigned int b:RGB9E5_MANTISSA_BITS;
-  unsigned int g:RGB9E5_MANTISSA_BITS;
-  unsigned int r:RGB9E5_MANTISSA_BITS;
-#else
-  unsigned int r:RGB9E5_MANTISSA_BITS;
-  unsigned int g:RGB9E5_MANTISSA_BITS;
-  unsigned int b:RGB9E5_MANTISSA_BITS;
-  unsigned int biasedexponent:RGB9E5_EXPONENT_BITS;
-#endif
-   } field;
-} rgb9e5;
-
-
 static inline int rgb9e5_ClampRange(float x)
 {
float754 f;
@@ -91,9 +73,8 @@ static inline int rgb9e5_ClampRange(float x)
   return f.raw;
 }
 
-static inline unsigned float3_to_rgb9e5(const float rgb[3])
+static inline unsigned int float3_to_rgb9e5(const float rgb[3])
 {
-   rgb9e5 retval;
int rm, gm, bm, exp_shared;
float754 revdenom = {0};
float754 rc, bc, gc, maxrgb;
@@ -135,27 +116,20 @@ static inline unsigned float3_to_rgb9e5(const float 
rgb[3])
assert(gm >= 0);
assert(bm >= 0);
 
-   retval.field.r = rm;
-   retval.field.g = gm;
-   retval.field.b = bm;
-   retval.field.biasedexponent = exp_shared;
-
-   return retval.raw;
+   return (exp_shared << 27) | (bm << 18) | (gm << 9) | rm;
 }
 
 static inline void rgb9e5_to_float3(unsigned rgb, float retval[3])
 {
-   rgb9e5 v;
int exponent;
float754 scale = {0};
 
-   v.raw = rgb;
-   exponent = v.field.biasedexponent - RGB9E5_EXP_BIAS - RGB9E5_MANTISSA_BITS;
+   exponent = (rgb >> 27) - RGB9E5_EXP_BIAS - RGB9E5_MANTISSA_BITS;
scale.field.biasedexponent = exponent + 127;
 
-   retval[0] = v.field.r * scale.value;
-   retval[1] = v.field.g * scale.value;
-   retval[2] = v.field.b * scale.value;
+   retval[0] = ( rgb& 0x1ff) * scale.value;
+   retval[1] = ((rgb >> 9)  & 0x1ff) * scale.value;
+   retval[2] = ((rgb >> 18) & 0x1ff) * scale.value;
 }
 
 #endif
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 1/6] util: Move format_rgb9e5.h to src/util

[Jason Ekstrand]

It's used from both mesa main and gallium.

Signed-off-by: Jason Ekstrand 
---
 src/gallium/auxiliary/Makefile.sources|   1 -
 src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c |   2 +-
 src/gallium/auxiliary/util/u_format_other.c   |   2 +-
 src/gallium/auxiliary/util/u_format_rgb9e5.h  | 161 --
 src/mesa/main/format_pack.py  |   2 +-
 src/mesa/main/format_unpack.py|   2 +-
 src/mesa/main/mipmap.c|   2 +-
 src/mesa/main/texstore.c  |   2 +-
 src/mesa/swrast/s_texfetch.c  |   2 +-
 src/util/Makefile.sources |   1 +
 src/util/format_rgb9e5.h  | 161 ++
 11 files changed, 169 insertions(+), 169 deletions(-)
 delete mode 100644 src/gallium/auxiliary/util/u_format_rgb9e5.h
 create mode 100644 src/util/format_rgb9e5.h

diff --git a/src/gallium/auxiliary/Makefile.sources 
b/src/gallium/auxiliary/Makefile.sources
index 26f7eee..230f52b 100644
--- a/src/gallium/auxiliary/Makefile.sources
+++ b/src/gallium/auxiliary/Makefile.sources
@@ -229,7 +229,6 @@ C_SOURCES := \
util/u_format_other.c \
util/u_format_other.h \
util/u_format_r11g11b10f.h \
-   util/u_format_rgb9e5.h \
util/u_format_rgtc.c \
util/u_format_rgtc.h \
util/u_format_s3tc.c \
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c 
b/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c
index 3a8327d..1b48fc2 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c
@@ -42,7 +42,7 @@
 #include "util/u_math.h"
 #include "util/u_format.h"
 #include "util/u_cpu_detect.h"
-#include "util/u_format_rgb9e5.h"
+#include "util/format_rgb9e5.h"
 #include "lp_bld_debug.h"
 #include "lp_bld_type.h"
 #include "lp_bld_const.h"
diff --git a/src/gallium/auxiliary/util/u_format_other.c 
b/src/gallium/auxiliary/util/u_format_other.c
index 20752d4..8197835 100644
--- a/src/gallium/auxiliary/util/u_format_other.c
+++ b/src/gallium/auxiliary/util/u_format_other.c
@@ -28,7 +28,7 @@
 
 #include "u_math.h"
 #include "u_format_other.h"
-#include "u_format_rgb9e5.h"
+#include "util/format_rgb9e5.h"
 #include "u_format_r11g11b10f.h"
 
 
diff --git a/src/gallium/auxiliary/util/u_format_rgb9e5.h 
b/src/gallium/auxiliary/util/u_format_rgb9e5.h
deleted file mode 100644
index 21feba7..000
--- a/src/gallium/auxiliary/util/u_format_rgb9e5.h
+++ /dev/null
@@ -1,161 +0,0 @@
-/*
- * Copyright (C) 2011 Marek Olšák 
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sublicense,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice (including the next
- * paragraph) shall be included in all copies or substantial portions of the
- * Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
- * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
- * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
- * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
- * DEALINGS IN THE SOFTWARE.
- */
-
-/* Copied from EXT_texture_shared_exponent and edited, getting rid of
- * expensive float math bits too. */
-
-#ifndef RGB9E5_H
-#define RGB9E5_H
-
-#include 
-
-#include "c99_math.h"
-
-#define RGB9E5_EXPONENT_BITS  5
-#define RGB9E5_MANTISSA_BITS  9
-#define RGB9E5_EXP_BIAS   15
-#define RGB9E5_MAX_VALID_BIASED_EXP   31
-
-#define MAX_RGB9E5_EXP   (RGB9E5_MAX_VALID_BIASED_EXP - 
RGB9E5_EXP_BIAS)
-#define RGB9E5_MANTISSA_VALUES   (1<

Re: [Mesa-dev] [PATCH 6/7] radeonsi: program multi draw and indirect draw count parameters

[Marek Olšák]

On Tue, Aug 2, 2016 at 10:18 PM, Nicolai Hähnle  wrote:
> Bas pointed out some things that mean this patch (and the next) probably
> need to be reworked. The tests were probably not thorough enough.

I think that all indirect parameters are read by PFP. Our cache flush
sequence already takes that into account and emits PFP_SYNC_ME.

Also note that the driver only handles coherency between TC L2 and
CB/DB caches. For anything else (e.g. special CP packets), you need to
check r600_resource::TC_L2_dirty, which will tell you whether you need
to flush TC before you can use the buffer with a block not using TC.
See all usages of TC_L2_dirty.

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

Re: [Mesa-dev] [PATCH] loader: fix memory leak in loader_dri3_open

[Eric Anholt]

Jan Ziak <0xe2.0x9a.0...@gmail.com> writes:

> Found via "valgrind --leak-check=full glxgears".

Pushed.  Thanks!


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

Re: [Mesa-dev] [PATCH] gbm: Correct bo_import documentation (trivial)

[Eric Anholt]

Ben Widawsky  writes:

> Missed here:
> commit a43d286ef7ff65087b1f051d071b829ca7b02073
> Author: Kristian Høgsberg 
> Date:   Fri Mar 28 10:17:11 2014 -0700
>
> gbm: Add import from fd
>
> Cc: Kristian Høgsberg 
> Signed-off-by: Ben Widawsky 

Pushed.  Thanks!


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

[Mesa-dev] [Bug 93089] mesa fails to check for gcc atomic primitives before using them

[bugzilla-daemon]

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

Lauri Kasanen  changed:

   What|Removed |Added

 OS|OpenBSD |All
   Hardware|Other   |All

--- Comment #9 from Lauri Kasanen  ---
We're hitting this on TinyCore, and I see Alpine hit it a while back too [1].

We build with -march=i486, and some of the atomics require a 586. Things build,
but some drivers fail to load:

libGL: dlopen /usr/local/lib/dri/i915_dri.so failed
(/usr/local/lib/dri/i915_dri.so: undefined symbol:
__sync_val_compare_and_swap_8)
libGL error: unable to load driver: i915_dri.so
libGL error: driver pointer missing

They should fail to build at the very least. Changing the hw and os to all.

[1] https://bugs.alpinelinux.org/issues/4254

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

Re: [Mesa-dev] what happened to libgallium.so ?

[Jose Fonseca]

libgallium.so was an awful idea.

Just a few days ago we had an internal bug report because libgallium.so 
symbols were clashing with the application symbols.


This is because all that libgallium.so export all gallium symbols, even 
though they have no unique prefix -- it uses common symbols like util_* 
or os_* which can easily be used by the app internally...


Awful idea.

Jose

On 03/08/16 17:09, Marek Olšák wrote:

It has always been statically linked as far as I remember.
libgallium.so is a Ubuntu speciality that we don't support.

Marek


On Wed, Aug 3, 2016 at 10:45 AM, Enrico Weigelt, metux IT consult
 wrote:

Hi folks,


I'm currently backporting latest mesa to Ubuntu Trusty, starting
with their original deb files. One problem I stumbled across is that
libgallium.so isn't built/installed anymore - it seems that it's now
statically linked into all the drivers.

What happened to that so ? Why now statically linked ?


--thx
___
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 5/7] radeonsi: add has_draw_indirect_multi flag

[Marek Olšák]

Is this for the latest version of the MULTI packets and not the first
one without indirect_count?

Marek

On Tue, Aug 2, 2016 at 9:41 PM, Nicolai Hähnle  wrote:
> From: Nicolai Hähnle 
>
> Prefer to use DRAW_(INDEX)_INDIRECT_MULTI when available in the firmware.
>
> Versions for SI and CI already added as provided by the firmware team, but
> keep in mind that they won't currently be used since the radeon kernel module
> has no interface to query the firmware version.
> ---
>  src/gallium/drivers/radeonsi/si_pipe.c   | 12 
>  src/gallium/drivers/radeonsi/si_pipe.h   |  1 +
>  src/gallium/drivers/radeonsi/si_state_draw.c |  2 +-
>  3 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_pipe.c 
> b/src/gallium/drivers/radeonsi/si_pipe.c
> index 9304e5c..d2965050 100644
> --- a/src/gallium/drivers/radeonsi/si_pipe.c
> +++ b/src/gallium/drivers/radeonsi/si_pipe.c
> @@ -754,6 +754,18 @@ struct pipe_screen *radeonsi_screen_create(struct 
> radeon_winsys *ws)
> sscreen->b.chip_class >= VI &&
> sscreen->b.info.max_se >= 2;
>
> +   sscreen->has_draw_indirect_multi =
> +   (sscreen->b.family >= CHIP_POLARIS10) ||
> +   (sscreen->b.chip_class == VI &&
> +sscreen->b.info.pfp_fw_version >= 121 &&
> +sscreen->b.info.me_fw_version >= 87) ||
> +   (sscreen->b.chip_class == CIK &&
> +sscreen->b.info.pfp_fw_version >= 211 &&
> +sscreen->b.info.me_fw_version >= 173) ||
> +   (sscreen->b.chip_class == SI &&
> +sscreen->b.info.pfp_fw_version >= 121 &&
> +sscreen->b.info.me_fw_version >= 87);
> +
> sscreen->b.has_cp_dma = true;
> sscreen->b.has_streamout = true;
> pipe_mutex_init(sscreen->shader_parts_mutex);
> diff --git a/src/gallium/drivers/radeonsi/si_pipe.h 
> b/src/gallium/drivers/radeonsi/si_pipe.h
> index 326b819..bb570bb 100644
> --- a/src/gallium/drivers/radeonsi/si_pipe.h
> +++ b/src/gallium/drivers/radeonsi/si_pipe.h
> @@ -85,6 +85,7 @@ struct si_screen {
> unsignedgs_table_depth;
> unsignedtess_offchip_block_dw_size;
> boolhas_distributed_tess;
> +   boolhas_draw_indirect_multi;
>
> /* Whether shaders are monolithic (1-part) or separate (3-part). */
> booluse_monolithic_shaders;
> diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c 
> b/src/gallium/drivers/radeonsi/si_state_draw.c
> index 54fe2bb..a918f85 100644
> --- a/src/gallium/drivers/radeonsi/si_state_draw.c
> +++ b/src/gallium/drivers/radeonsi/si_state_draw.c
> @@ -634,7 +634,7 @@ static void si_emit_draw_packets(struct si_context *sctx,
> radeon_emit(cs, index_max_size);
> }
>
> -   if (sctx->b.family < CHIP_POLARIS10) {
> +   if (!sctx->screen->has_draw_indirect_multi) {
> radeon_emit(cs, PKT3(info->indexed ? 
> PKT3_DRAW_INDEX_INDIRECT
>: 
> PKT3_DRAW_INDIRECT,
>  3, render_cond_bit));
> --
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] mesa: Dynamically allocate the matrix stack.

[Brian Paul]

Just two minor things below.

On 08/03/2016 11:27 AM, Eric Anholt wrote:

By allocating and initializing the matrices at context creation, the OS
can't even overcommit the pages.  This saves about 63k (out of 946k) of
maximum memory size according to massif on simulated vc4
glsl-algebraic-add-add-1.  It also means we could potentially relax the
maximum stack sizes, but that should be a separate commit.
---
  src/mesa/main/matrix.c | 27 ---
  src/mesa/main/mtypes.h |  1 +
  2 files changed, 25 insertions(+), 3 deletions(-)

diff --git a/src/mesa/main/matrix.c b/src/mesa/main/matrix.c
index 293d50c33595..a7cca799bcca 100644
--- a/src/mesa/main/matrix.c
+++ b/src/mesa/main/matrix.c
@@ -243,6 +243,25 @@ _mesa_PushMatrix( void )
}
return;
 }
+   if (stack->Depth + 1 >= stack->StackSize) {
+  unsigned new_stack_size = stack->StackSize * 2;
+  unsigned i;
+  GLmatrix *new_stack = realloc(stack->Stack,
+sizeof(*new_stack) * new_stack_size);
+
+  if (!new_stack) {
+ _mesa_error(ctx, GL_OUT_OF_MEMORY, "glPushMatrix()");
+ return;
+  }
+
+  for (i = stack->StackSize; i < new_stack_size; i++)
+ _math_matrix_ctr(_stack[i]);
+
+  stack->Top = new_stack + (stack->Top - stack->Stack);


It looks like stack->Top is assigned later in the function so I don't 
think this assignment is needed.



+  stack->Stack = new_stack;
+  stack->StackSize = new_stack_size;
+   }
+
 _math_matrix_copy( >Stack[stack->Depth + 1],
>Stack[stack->Depth] );
 stack->Depth++;
@@ -646,8 +665,9 @@ init_matrix_stack( struct gl_matrix_stack *stack,
 stack->MaxDepth = maxDepth;
 stack->DirtyFlag = dirtyFlag;
 /* The stack */
-   stack->Stack = calloc(maxDepth, sizeof(GLmatrix));
-   for (i = 0; i < maxDepth; i++) {


Maybe put a comment here saying that the allocation for the stack will 
grow as needed in _mesa_PushMatrix().




+   stack->Stack = calloc(1, sizeof(GLmatrix));
+   stack->StackSize = 1;
+   for (i = 0; i < stack->StackSize; i++) {
_math_matrix_ctr(>Stack[i]);
 }
 stack->Top = stack->Stack;
@@ -665,11 +685,12 @@ static void
  free_matrix_stack( struct gl_matrix_stack *stack )
  {
 GLuint i;
-   for (i = 0; i < stack->MaxDepth; i++) {
+   for (i = 0; i < stack->StackSize; i++) {
_math_matrix_dtr(>Stack[i]);
 }
 free(stack->Stack);
 stack->Stack = stack->Top = NULL;
+   stack->StackSize = 0;
  }

  /*@}*/
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 2647f8fab841..5b02fadf3cd8 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -3990,6 +3990,7 @@ struct gl_matrix_stack
  {
 GLmatrix *Top;  /**< points into Stack */
 GLmatrix *Stack;/**< array [MaxDepth] of GLmatrix */
+   unsigned StackSize; /**< Number of elements in Stack */
 GLuint Depth;   /**< 0 <= Depth < MaxDepth */
 GLuint MaxDepth;/**< size of Stack[] array */
 GLuint DirtyFlag;   /**< _NEW_MODELVIEW or _NEW_PROJECTION, for example */



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

Re: [Mesa-dev] [PATCH 1/2] state_tracker: Initialize the draw context only when needed.

[Brian Paul]

Reviewed-by: Brian Paul 

On 08/03/2016 11:27 AM, Eric Anholt wrote:

It's only used for rarely-used deprecated GL features
(feedback/rasterpos), so we can skip the memory allocation and
initialization for it most of the time.

Saves about 659k (out of 1605k) of maximum memory size according to massif
on simulated vc4 glsl-algebraic-add-add-1
---
  src/mesa/state_tracker/st_cb_feedback.c   |  5 -
  src/mesa/state_tracker/st_cb_rasterpos.c  |  5 -
  src/mesa/state_tracker/st_draw.c  | 31 +++
  src/mesa/state_tracker/st_draw.h  |  2 ++
  src/mesa/state_tracker/st_draw_feedback.c |  5 +++--
  5 files changed, 36 insertions(+), 12 deletions(-)

diff --git a/src/mesa/state_tracker/st_cb_feedback.c 
b/src/mesa/state_tracker/st_cb_feedback.c
index 735e268be870..a18f4f76bcf2 100644
--- a/src/mesa/state_tracker/st_cb_feedback.c
+++ b/src/mesa/state_tracker/st_cb_feedback.c
@@ -274,7 +274,10 @@ static void
  st_RenderMode(struct gl_context *ctx, GLenum newMode )
  {
 struct st_context *st = st_context(ctx);
-   struct draw_context *draw = st->draw;
+   struct draw_context *draw = st_get_draw_context(st);
+
+   if (!st->draw)
+  return;

 if (newMode == GL_RENDER) {
/* restore normal VBO draw function */
diff --git a/src/mesa/state_tracker/st_cb_rasterpos.c 
b/src/mesa/state_tracker/st_cb_rasterpos.c
index 29c148471801..5dda0e2c8b7b 100644
--- a/src/mesa/state_tracker/st_cb_rasterpos.c
+++ b/src/mesa/state_tracker/st_cb_rasterpos.c
@@ -219,10 +219,13 @@ static void
  st_RasterPos(struct gl_context *ctx, const GLfloat v[4])
  {
 struct st_context *st = st_context(ctx);
-   struct draw_context *draw = st->draw;
+   struct draw_context *draw = st_get_draw_context(st);
 struct rastpos_stage *rs;
 const struct gl_client_array **saved_arrays = ctx->Array._DrawArrays;

+   if (!st->draw)
+  return;
+
 if (ctx->VertexProgram._Current == NULL ||
 ctx->VertexProgram._Current == ctx->VertexProgram._TnlProgram) {
/* No vertex shader/program is enabled, used the simple/fast fixed-
diff --git a/src/mesa/state_tracker/st_draw.c b/src/mesa/state_tracker/st_draw.c
index b248dafc9a20..f4af23da97f3 100644
--- a/src/mesa/state_tracker/st_draw.c
+++ b/src/mesa/state_tracker/st_draw.c
@@ -346,8 +346,29 @@ st_init_draw(struct st_context *st)

 vbo_set_draw_func(ctx, st_draw_vbo);
 vbo_set_indirect_draw_func(ctx, st_indirect_draw_vbo);
+}
+
+
+void
+st_destroy_draw(struct st_context *st)
+{
+   draw_destroy(st->draw);
+}

-   st->draw = draw_create(st->pipe); /* for selection/feedback */
+/**
+ * Getter for the draw_context, so that initialization of it can happen only
+ * when needed (the TGSI exec machines take up quite a bit of memory).
+ */
+struct draw_context *
+st_get_draw_context(struct st_context *st)
+{
+   if (!st->draw) {
+  st->draw = draw_create(st->pipe);
+  if (!st->draw) {
+ _mesa_error(st->ctx, GL_OUT_OF_MEMORY, "feedback fallback 
allocation");
+ return NULL;
+  }
+   }

 /* Disable draw options that might convert points/lines to tris, etc.
  * as that would foul-up feedback/selection mode.
@@ -356,16 +377,10 @@ st_init_draw(struct st_context *st)
 draw_wide_point_threshold(st->draw, 1000.0f);
 draw_enable_line_stipple(st->draw, FALSE);
 draw_enable_point_sprites(st->draw, FALSE);
-}
-

-void
-st_destroy_draw(struct st_context *st)
-{
-   draw_destroy(st->draw);
+   return st->draw;
  }

-
  /**
   * Draw a quad with given position, texcoords and color.
   */
diff --git a/src/mesa/state_tracker/st_draw.h b/src/mesa/state_tracker/st_draw.h
index d85c3b7facdd..fc863819c7e0 100644
--- a/src/mesa/state_tracker/st_draw.h
+++ b/src/mesa/state_tracker/st_draw.h
@@ -47,6 +47,8 @@ void st_init_draw( struct st_context *st );

  void st_destroy_draw( struct st_context *st );

+struct draw_context *st_get_draw_context(struct st_context *st);
+
  extern void
  st_draw_vbo(struct gl_context *ctx,
  const struct _mesa_prim *prims,
diff --git a/src/mesa/state_tracker/st_draw_feedback.c 
b/src/mesa/state_tracker/st_draw_feedback.c
index e76694d4b2b0..6cc7dd77701d 100644
--- a/src/mesa/state_tracker/st_draw_feedback.c
+++ b/src/mesa/state_tracker/st_draw_feedback.c
@@ -123,7 +123,7 @@ st_feedback_draw_vbo(struct gl_context *ctx,
  {
 struct st_context *st = st_context(ctx);
 struct pipe_context *pipe = st->pipe;
-   struct draw_context *draw = st->draw;
+   struct draw_context *draw = st_get_draw_context(st);
 const struct st_vertex_program *vp;
 const struct pipe_shader_state *vs;
 struct pipe_vertex_buffer vbuffers[PIPE_MAX_SHADER_INPUTS];
@@ -136,7 +136,8 @@ st_feedback_draw_vbo(struct gl_context *ctx,
 const GLubyte *low_addr = NULL;
 const void *mapped_indices = NULL;

-   assert(draw);
+   if (!draw)
+  return;

 st_flush_bitmap_cache(st);
 st_invalidate_readpix_cache(st);

[Mesa-dev] [PATCH 2/2] mesa: Dynamically allocate the matrix stack.

[Eric Anholt]

By allocating and initializing the matrices at context creation, the OS
can't even overcommit the pages.  This saves about 63k (out of 946k) of
maximum memory size according to massif on simulated vc4
glsl-algebraic-add-add-1.  It also means we could potentially relax the
maximum stack sizes, but that should be a separate commit.
---
 src/mesa/main/matrix.c | 27 ---
 src/mesa/main/mtypes.h |  1 +
 2 files changed, 25 insertions(+), 3 deletions(-)

diff --git a/src/mesa/main/matrix.c b/src/mesa/main/matrix.c
index 293d50c33595..a7cca799bcca 100644
--- a/src/mesa/main/matrix.c
+++ b/src/mesa/main/matrix.c
@@ -243,6 +243,25 @@ _mesa_PushMatrix( void )
   }
   return;
}
+   if (stack->Depth + 1 >= stack->StackSize) {
+  unsigned new_stack_size = stack->StackSize * 2;
+  unsigned i;
+  GLmatrix *new_stack = realloc(stack->Stack,
+sizeof(*new_stack) * new_stack_size);
+
+  if (!new_stack) {
+ _mesa_error(ctx, GL_OUT_OF_MEMORY, "glPushMatrix()");
+ return;
+  }
+
+  for (i = stack->StackSize; i < new_stack_size; i++)
+ _math_matrix_ctr(_stack[i]);
+
+  stack->Top = new_stack + (stack->Top - stack->Stack);
+  stack->Stack = new_stack;
+  stack->StackSize = new_stack_size;
+   }
+
_math_matrix_copy( >Stack[stack->Depth + 1],
   >Stack[stack->Depth] );
stack->Depth++;
@@ -646,8 +665,9 @@ init_matrix_stack( struct gl_matrix_stack *stack,
stack->MaxDepth = maxDepth;
stack->DirtyFlag = dirtyFlag;
/* The stack */
-   stack->Stack = calloc(maxDepth, sizeof(GLmatrix));
-   for (i = 0; i < maxDepth; i++) {
+   stack->Stack = calloc(1, sizeof(GLmatrix));
+   stack->StackSize = 1;
+   for (i = 0; i < stack->StackSize; i++) {
   _math_matrix_ctr(>Stack[i]);
}
stack->Top = stack->Stack;
@@ -665,11 +685,12 @@ static void
 free_matrix_stack( struct gl_matrix_stack *stack )
 {
GLuint i;
-   for (i = 0; i < stack->MaxDepth; i++) {
+   for (i = 0; i < stack->StackSize; i++) {
   _math_matrix_dtr(>Stack[i]);
}
free(stack->Stack);
stack->Stack = stack->Top = NULL;
+   stack->StackSize = 0;
 }
 
 /*@}*/
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 2647f8fab841..5b02fadf3cd8 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -3990,6 +3990,7 @@ struct gl_matrix_stack
 {
GLmatrix *Top;  /**< points into Stack */
GLmatrix *Stack;/**< array [MaxDepth] of GLmatrix */
+   unsigned StackSize; /**< Number of elements in Stack */
GLuint Depth;   /**< 0 <= Depth < MaxDepth */
GLuint MaxDepth;/**< size of Stack[] array */
GLuint DirtyFlag;   /**< _NEW_MODELVIEW or _NEW_PROJECTION, for example */
-- 
2.8.1

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

[Mesa-dev] [PATCH 1/2] state_tracker: Initialize the draw context only when needed.

[Eric Anholt]

It's only used for rarely-used deprecated GL features
(feedback/rasterpos), so we can skip the memory allocation and
initialization for it most of the time.

Saves about 659k (out of 1605k) of maximum memory size according to massif
on simulated vc4 glsl-algebraic-add-add-1
---
 src/mesa/state_tracker/st_cb_feedback.c   |  5 -
 src/mesa/state_tracker/st_cb_rasterpos.c  |  5 -
 src/mesa/state_tracker/st_draw.c  | 31 +++
 src/mesa/state_tracker/st_draw.h  |  2 ++
 src/mesa/state_tracker/st_draw_feedback.c |  5 +++--
 5 files changed, 36 insertions(+), 12 deletions(-)

diff --git a/src/mesa/state_tracker/st_cb_feedback.c 
b/src/mesa/state_tracker/st_cb_feedback.c
index 735e268be870..a18f4f76bcf2 100644
--- a/src/mesa/state_tracker/st_cb_feedback.c
+++ b/src/mesa/state_tracker/st_cb_feedback.c
@@ -274,7 +274,10 @@ static void
 st_RenderMode(struct gl_context *ctx, GLenum newMode )
 {
struct st_context *st = st_context(ctx);
-   struct draw_context *draw = st->draw;
+   struct draw_context *draw = st_get_draw_context(st);
+
+   if (!st->draw)
+  return;
 
if (newMode == GL_RENDER) {
   /* restore normal VBO draw function */
diff --git a/src/mesa/state_tracker/st_cb_rasterpos.c 
b/src/mesa/state_tracker/st_cb_rasterpos.c
index 29c148471801..5dda0e2c8b7b 100644
--- a/src/mesa/state_tracker/st_cb_rasterpos.c
+++ b/src/mesa/state_tracker/st_cb_rasterpos.c
@@ -219,10 +219,13 @@ static void
 st_RasterPos(struct gl_context *ctx, const GLfloat v[4])
 {
struct st_context *st = st_context(ctx);
-   struct draw_context *draw = st->draw;
+   struct draw_context *draw = st_get_draw_context(st);
struct rastpos_stage *rs;
const struct gl_client_array **saved_arrays = ctx->Array._DrawArrays;
 
+   if (!st->draw)
+  return;
+
if (ctx->VertexProgram._Current == NULL ||
ctx->VertexProgram._Current == ctx->VertexProgram._TnlProgram) {
   /* No vertex shader/program is enabled, used the simple/fast fixed-
diff --git a/src/mesa/state_tracker/st_draw.c b/src/mesa/state_tracker/st_draw.c
index b248dafc9a20..f4af23da97f3 100644
--- a/src/mesa/state_tracker/st_draw.c
+++ b/src/mesa/state_tracker/st_draw.c
@@ -346,8 +346,29 @@ st_init_draw(struct st_context *st)
 
vbo_set_draw_func(ctx, st_draw_vbo);
vbo_set_indirect_draw_func(ctx, st_indirect_draw_vbo);
+}
+
+
+void
+st_destroy_draw(struct st_context *st)
+{
+   draw_destroy(st->draw);
+}
 
-   st->draw = draw_create(st->pipe); /* for selection/feedback */
+/**
+ * Getter for the draw_context, so that initialization of it can happen only
+ * when needed (the TGSI exec machines take up quite a bit of memory).
+ */
+struct draw_context *
+st_get_draw_context(struct st_context *st)
+{
+   if (!st->draw) {
+  st->draw = draw_create(st->pipe);
+  if (!st->draw) {
+ _mesa_error(st->ctx, GL_OUT_OF_MEMORY, "feedback fallback 
allocation");
+ return NULL;
+  }
+   }
 
/* Disable draw options that might convert points/lines to tris, etc.
 * as that would foul-up feedback/selection mode.
@@ -356,16 +377,10 @@ st_init_draw(struct st_context *st)
draw_wide_point_threshold(st->draw, 1000.0f);
draw_enable_line_stipple(st->draw, FALSE);
draw_enable_point_sprites(st->draw, FALSE);
-}
-
 
-void
-st_destroy_draw(struct st_context *st)
-{
-   draw_destroy(st->draw);
+   return st->draw;
 }
 
-
 /**
  * Draw a quad with given position, texcoords and color.
  */
diff --git a/src/mesa/state_tracker/st_draw.h b/src/mesa/state_tracker/st_draw.h
index d85c3b7facdd..fc863819c7e0 100644
--- a/src/mesa/state_tracker/st_draw.h
+++ b/src/mesa/state_tracker/st_draw.h
@@ -47,6 +47,8 @@ void st_init_draw( struct st_context *st );
 
 void st_destroy_draw( struct st_context *st );
 
+struct draw_context *st_get_draw_context(struct st_context *st);
+
 extern void
 st_draw_vbo(struct gl_context *ctx,
 const struct _mesa_prim *prims,
diff --git a/src/mesa/state_tracker/st_draw_feedback.c 
b/src/mesa/state_tracker/st_draw_feedback.c
index e76694d4b2b0..6cc7dd77701d 100644
--- a/src/mesa/state_tracker/st_draw_feedback.c
+++ b/src/mesa/state_tracker/st_draw_feedback.c
@@ -123,7 +123,7 @@ st_feedback_draw_vbo(struct gl_context *ctx,
 {
struct st_context *st = st_context(ctx);
struct pipe_context *pipe = st->pipe;
-   struct draw_context *draw = st->draw;
+   struct draw_context *draw = st_get_draw_context(st);
const struct st_vertex_program *vp;
const struct pipe_shader_state *vs;
struct pipe_vertex_buffer vbuffers[PIPE_MAX_SHADER_INPUTS];
@@ -136,7 +136,8 @@ st_feedback_draw_vbo(struct gl_context *ctx,
const GLubyte *low_addr = NULL;
const void *mapped_indices = NULL;
 
-   assert(draw);
+   if (!draw)
+  return;
 
st_flush_bitmap_cache(st);
st_invalidate_readpix_cache(st);
-- 
2.8.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org

Re: [Mesa-dev] [PATCH] egl/dri2: dri2_initialize: Do not reference-count TestOnly display

[Martin Peres]

On 03/08/16 16:54, Nicolas Boichat wrote:

In the case where dri2_initialize is called with a TestOnly display,
the display is not actually initialized, so dri2_egl_display always
fails, and we cannot do any reference counting.

Fixes piglit spec@egl_khr_create_context@verify gl flavor (reproducible
with LIBGL_ALWAYS_SOFTWARE=1) and spec@egl_khr_fence_sync@conformance.

Fixes: 9ee683f877 (egl/dri2: Add reference count for dri2_egl_display)
Cc: "12.0" 
Reported-by: Michel Dänzer 
Signed-off-by: Nicolas Boichat 
---

Compile-tested only, please give it a spin, thanks!


Still crashes, same backtrace before and after the patch:

Program received signal SIGSEGV, Segmentation fault.
0x73b90de9 in wl_proxy_destroy () from 
/usr/lib/libwayland-client.so.0

(gdb) bt
#0  0x73b90de9 in wl_proxy_destroy () from 
/usr/lib/libwayland-client.so.0
#1  0x7679bc4e in wl_registry_destroy (wl_registry=out>) at /usr/include/wayland-client-protocol.h:1047
#2  dri2_display_release (disp=disp@entry=0x7913f0) at 
drivers/dri2/egl_dri2.c:896
#3  0x7679c031 in dri2_terminate (drv=, 
disp=0x7913f0) at drivers/dri2/egl_dri2.c:932

#4  0x76790f7d in eglTerminate (dpy=0x7913f0) at main/eglapi.c:532
#5  0x004016f5 in init_display (platform=12760, 
out_dpy=0x7fffe3a0) at 
/home/mupuf/programmation/piglit/tests/egl/spec/egl_khr_fence_sync/egl_khr_fence_sync.c:136
#6  0x0040285f in init_other_display 
(out_other_dpy=0x7fffe3d8, orig_dpy=0x617c50) at 
/home/mupuf/programmation/piglit/tests/egl/spec/egl_khr_fence_sync/egl_khr_fence_sync.c:956
#7  0x00402917 in 
test_eglCreateSyncKHR_wrong_display_same_thread (test_data=0x0) at 
/home/mupuf/programmation/piglit/tests/egl/spec/egl_khr_fence_sync/egl_khr_fence_sync.c:1006
#8  0x775e10aa in piglit_run_selected_subtests 
(all_subtests=0x404380 , selected_subtests=0x0, 
num_selected_subtests=0, previous_result=PIGLIT_SKIP) at 
/home/mupuf/programmation/piglit/tests/util/piglit-util.c:756
#9  0x0040319d in main (argc=1, argv=0x7fffe578) at 
/home/mupuf/programmation/piglit/tests/egl/spec/egl_khr_fence_sync/egl_khr_fence_sync.c:1435


If you cannot reproduce, this is something I could be persuaded to look 
into.




 src/egl/drivers/dri2/egl_dri2.c | 29 +
 1 file changed, 9 insertions(+), 20 deletions(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index a5cab68..8cdca6a 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -788,45 +788,34 @@ dri2_initialize(_EGLDriver *drv, _EGLDisplay *disp)
if (disp->Options.UseFallback)
   return EGL_FALSE;

+   /* Nothing to initialize for a test only display */
+   if (disp->Options.TestOnly)
+  return EGL_TRUE;
+
switch (disp->Platform) {
 #ifdef HAVE_SURFACELESS_PLATFORM
case _EGL_PLATFORM_SURFACELESS:
-  if (disp->Options.TestOnly)
- ret = EGL_TRUE;
-  else
- ret = dri2_initialize_surfaceless(drv, disp);
+  ret = dri2_initialize_surfaceless(drv, disp);
   break;
 #endif
 #ifdef HAVE_X11_PLATFORM
case _EGL_PLATFORM_X11:
-  if (disp->Options.TestOnly)
- ret = EGL_TRUE;
-  else
- ret = dri2_initialize_x11(drv, disp);
+  ret = dri2_initialize_x11(drv, disp);
   break;
 #endif
 #ifdef HAVE_DRM_PLATFORM
case _EGL_PLATFORM_DRM:
-  if (disp->Options.TestOnly)
- ret = EGL_TRUE;
-  else
- ret = dri2_initialize_drm(drv, disp);
+  ret = dri2_initialize_drm(drv, disp);
   break;
 #endif
 #ifdef HAVE_WAYLAND_PLATFORM
case _EGL_PLATFORM_WAYLAND:
-  if (disp->Options.TestOnly)
- ret = EGL_TRUE;
-  else
- ret = dri2_initialize_wayland(drv, disp);
+  ret = dri2_initialize_wayland(drv, disp);
   break;
 #endif
 #ifdef HAVE_ANDROID_PLATFORM
case _EGL_PLATFORM_ANDROID:
-  if (disp->Options.TestOnly)
- ret = EGL_TRUE;
-  else
- ret = dri2_initialize_android(drv, disp);
+  ret = dri2_initialize_android(drv, disp);
   break;
 #endif
default:


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

Re: [Mesa-dev] what happened to libgallium.so ?

[Marek Olšák]

It has always been statically linked as far as I remember.
libgallium.so is a Ubuntu speciality that we don't support.

Marek


On Wed, Aug 3, 2016 at 10:45 AM, Enrico Weigelt, metux IT consult
 wrote:
> Hi folks,
>
>
> I'm currently backporting latest mesa to Ubuntu Trusty, starting
> with their original deb files. One problem I stumbled across is that
> libgallium.so isn't built/installed anymore - it seems that it's now
> statically linked into all the drivers.
>
> What happened to that so ? Why now statically linked ?
>
>
> --thx
> ___
> 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] __func__ vs. __FUNCTION__

[Daniel Vetter]

On Wed, Aug 03, 2016 at 11:41:58AM +0200, Enrico Weigelt, metux IT consult 
wrote:
> Hi folks,
> 
> 
> I've seen we're using __func__ as well as __FUNCTION__.
> Should we consolidate that ?

Quick comment, but for small questions like these asking on IRC
(#dri-devel on freenode) tends to be much faster, since you can follow up
right away.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] non-shared glapi still needed ?

[Chad Versace]

On 08/02/2016 06:40 PM, Enrico Weigelt, metux IT consult wrote:

Hi folks,


is there still a real need for having non-shared glapi ?
Otherwise, should we remove it ?


+1
I have the same question.

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

Re: [Mesa-dev] [PATCH v2] i965: use mt->offset in intel_miptree_map_movntdqa().

[Chad Versace]

On 08/02/2016 08:09 PM, Kenneth Graunke wrote:

On Tuesday, August 2, 2016 5:03:32 PM PDT Haixia Shi wrote:

We need to include mt->offset in the calculation of src pointer because its
value may be non-zero, for example in a cubemap texture.

Signed-off-by: Haixia Shi 
Cc: Jason Ekstrand 
Cc: kenneth.w.grau...@intel.com
Cc: Chad Versace 

Change-Id: I461ad5b204626d5a1c45611fc6b63735dcf29f63
---
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 3 +++
 1 file changed, 3 insertions(+)




Reviewed-by: Kenneth Graunke 


And pushed.

hshi, for future reference, small bugfix patches like this are
good candidates for Mesa's stable branches. When sending a patch
to mesa-dev, adding this footer
Cc: mesa-sta...@lists.freedestkop.org
will automatically make it a candidate for the stable branch.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] vl: add a lanczos interpolation filter v3

[Christian König]

Sorry for the delay I've been on vacation for a week.

Where you able to fix the problem Andy reported? I was able to rather 
easily reproduce that.


Leave out level 8&9 is clearly a good idea and I'm rather eager to 
commit this set now if it doesn't show any more obvious problems.


Regards,
Christian.

Am 01.08.2016 um 12:56 schrieb Nayan Deshmukh:

v2: avoid dividing by zero when calculating lanczos

Signed-off-by: Nayan Deshmukh 
---
  src/gallium/auxiliary/Makefile.sources   |   2 +
  src/gallium/auxiliary/vl/vl_lanczos_filter.c | 445 +++
  src/gallium/auxiliary/vl/vl_lanczos_filter.h |  63 
  3 files changed, 510 insertions(+)
  create mode 100644 src/gallium/auxiliary/vl/vl_lanczos_filter.c
  create mode 100644 src/gallium/auxiliary/vl/vl_lanczos_filter.h

diff --git a/src/gallium/auxiliary/Makefile.sources 
b/src/gallium/auxiliary/Makefile.sources
index e0311bf..4eb0f65 100644
--- a/src/gallium/auxiliary/Makefile.sources
+++ b/src/gallium/auxiliary/Makefile.sources
@@ -330,6 +330,8 @@ VL_SOURCES := \
vl/vl_deint_filter.h \
vl/vl_idct.c \
vl/vl_idct.h \
+   vl/vl_lanczos_filter.c \
+   vl/vl_lanczos_filter.h \
vl/vl_matrix_filter.c \
vl/vl_matrix_filter.h \
vl/vl_mc.c \
diff --git a/src/gallium/auxiliary/vl/vl_lanczos_filter.c 
b/src/gallium/auxiliary/vl/vl_lanczos_filter.c
new file mode 100644
index 000..0601b90
--- /dev/null
+++ b/src/gallium/auxiliary/vl/vl_lanczos_filter.c
@@ -0,0 +1,445 @@
+/**
+ *
+ * Copyright 2016 Nayan Deshmukh.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
+ * IN NO EVENT SHALL VMWARE AND/OR ITS SUPPLIERS BE LIABLE FOR
+ * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
+ * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
+ * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ **/
+
+#include 
+
+#include "pipe/p_context.h"
+
+#include "tgsi/tgsi_ureg.h"
+
+#include "util/u_draw.h"
+#include "util/u_memory.h"
+#include "util/u_math.h"
+#include "util/u_rect.h"
+
+#include "vl_types.h"
+#include "vl_vertex_buffers.h"
+#include "vl_lanczos_filter.h"
+
+enum VS_OUTPUT
+{
+   VS_O_VPOS = 0,
+   VS_O_VTEX = 0
+};
+
+static void *
+create_vert_shader(struct vl_lanczos_filter *filter)
+{
+   struct ureg_program *shader;
+   struct ureg_src i_vpos;
+   struct ureg_dst o_vpos, o_vtex;
+
+   shader = ureg_create(PIPE_SHADER_VERTEX);
+   if (!shader)
+  return NULL;
+
+   i_vpos = ureg_DECL_vs_input(shader, 0);
+   o_vpos = ureg_DECL_output(shader, TGSI_SEMANTIC_POSITION, VS_O_VPOS);
+   o_vtex = ureg_DECL_output(shader, TGSI_SEMANTIC_GENERIC, VS_O_VTEX);
+
+   ureg_MOV(shader, o_vpos, i_vpos);
+   ureg_MOV(shader, o_vtex, i_vpos);
+
+   ureg_END(shader);
+
+   return ureg_create_shader_and_destroy(shader, filter->pipe);
+}
+
+static void
+create_frag_shader_lanczos(struct ureg_program *shader, struct ureg_src a,
+   struct ureg_src x, struct ureg_dst o_fragment)
+{
+   struct ureg_dst temp[8];
+   unsigned i;
+
+   for(i = 0; i < 8; ++i)
+   temp[i] = ureg_DECL_temporary(shader);
+
+   /*
+* temp[0] = (x == 0) ? 1.0f : x
+* temp[7] = (sin(pi * x) * sin ((pi * x)/a)) / x^2
+* o_fragment = (x == 0) ? 1.0f : temp[7]
+*/
+   ureg_MOV(shader, temp[0], x);
+   ureg_SEQ(shader, temp[1], x, ureg_imm1f(shader, 0.0f));
+
+   ureg_LRP(shader, temp[0], ureg_src(temp[1]),
+ureg_imm1f(shader, 1.0f), ureg_src(temp[0]));
+
+   ureg_MUL(shader, temp[2], x,
+ureg_imm1f(shader, 3.141592));
+   ureg_DIV(shader, temp[3], ureg_src(temp[2]), a);
+
+   ureg_SIN(shader, temp[4], ureg_src(temp[2]));
+   ureg_SIN(shader, temp[5], ureg_src(temp[3]));
+
+   ureg_MUL(shader, temp[6], ureg_src(temp[4]),
+ureg_src(temp[5]));
+   ureg_MUL(shader, temp[7], ureg_imm1f(shader,
+0.101321), a);
+   ureg_MUL(shader, temp[7], ureg_src(temp[7]),
+ureg_src(temp[6]));
+   

Re: [Mesa-dev] [PATCH] anv: GetDeviceImageFormatProperties: fix transfer destination formats

[Jason Ekstrand]

On Aug 3, 2016 5:53 AM, "Lionel Landwerlin" 
wrote:
>
> We let the user believe we support some transfer destination formats
> which we don't. This can lead to crashes when actually trying to use
> those formats for example on
> dEQP-VK.api.copy_and_blit.image_to_image.* tests.
>
> Allow formats we can render to as meta implements transfers using
> attachments.

Sadly, it's not quite that simple... Nanley and I had a long chat about
this in the office last week.  I'll try and summarize here.  Let's take one
particular format as an example: R9G9B9E5.  This format is required to be
supported for sampling with VK_TILING_OPTIMAL but has no requirements on
rendering.  We can sample from it but cannot render to it.  Since it's
required to be supported in a tilled configuration, the only way the user
can get data into it is through vkCopy* commands. This means it has to be
supported as a transfer destination.  This means we have to support
vkClearColorImage on it as well.

This implies two things: First, the correct criterion for supporting
transfer operations is render, depth-stencil, *or* sampling.  Second, we
really need to come up with a better clearing sorry than just "bind as a
render target and draw".  While this works for most formats, there are a
few where we have to bind as a different format and manually convert the
data.

Make sense?

--Jason

> Signed-off-by: Lionel Landwerlin 
> Cc: Jason Ekstrand 
> ---
>  src/intel/vulkan/anv_formats.c | 11 +++
>  1 file changed, 3 insertions(+), 8 deletions(-)
>
> diff --git a/src/intel/vulkan/anv_formats.c
b/src/intel/vulkan/anv_formats.c
> index b26e48a..1a3b19d 100644
> --- a/src/intel/vulkan/anv_formats.c
> +++ b/src/intel/vulkan/anv_formats.c
> @@ -514,18 +514,13 @@ VkResult anv_GetPhysicalDeviceImageFormatProperties(
>}
> }
>
> -#if 0
> if (usage & VK_IMAGE_USAGE_TRANSFER_DST_BIT) {
> -  if (anv_format_for_vk_format(format)->has_stencil) {
> - /* Not yet implemented because copying to a W-tiled surface is
crazy
> -  * hard.
> -  */
> - anv_finishme("support VK_IMAGE_USAGE_TRANSFER_DST_BIT for "
> -  "stencil format");
> +  /* Meta implements transfers by rendering to the attachment image.
*/
> +  if (!(format_feature_flags &
(VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BIT |
> +
VK_FORMAT_FEATURE_DEPTH_STENCIL_ATTACHMENT_BIT))) {
>   goto unsupported;
>}
> }
> -#endif
>
> if (usage & VK_IMAGE_USAGE_SAMPLED_BIT) {
>if (!(format_feature_flags & VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT))
{
> --
> 2.8.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] egl/dri2: dri2_initialize: Do not reference-count TestOnly display

[Nicolas Boichat]

In the case where dri2_initialize is called with a TestOnly display,
the display is not actually initialized, so dri2_egl_display always
fails, and we cannot do any reference counting.

Fixes piglit spec@egl_khr_create_context@verify gl flavor (reproducible
with LIBGL_ALWAYS_SOFTWARE=1) and spec@egl_khr_fence_sync@conformance.

Fixes: 9ee683f877 (egl/dri2: Add reference count for dri2_egl_display)
Cc: "12.0" 
Reported-by: Michel Dänzer 
Signed-off-by: Nicolas Boichat 
---

Compile-tested only, please give it a spin, thanks!

 src/egl/drivers/dri2/egl_dri2.c | 29 +
 1 file changed, 9 insertions(+), 20 deletions(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index a5cab68..8cdca6a 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -788,45 +788,34 @@ dri2_initialize(_EGLDriver *drv, _EGLDisplay *disp)
if (disp->Options.UseFallback)
   return EGL_FALSE;
 
+   /* Nothing to initialize for a test only display */
+   if (disp->Options.TestOnly)
+  return EGL_TRUE;
+
switch (disp->Platform) {
 #ifdef HAVE_SURFACELESS_PLATFORM
case _EGL_PLATFORM_SURFACELESS:
-  if (disp->Options.TestOnly)
- ret = EGL_TRUE;
-  else
- ret = dri2_initialize_surfaceless(drv, disp);
+  ret = dri2_initialize_surfaceless(drv, disp);
   break;
 #endif
 #ifdef HAVE_X11_PLATFORM
case _EGL_PLATFORM_X11:
-  if (disp->Options.TestOnly)
- ret = EGL_TRUE;
-  else
- ret = dri2_initialize_x11(drv, disp);
+  ret = dri2_initialize_x11(drv, disp);
   break;
 #endif
 #ifdef HAVE_DRM_PLATFORM
case _EGL_PLATFORM_DRM:
-  if (disp->Options.TestOnly)
- ret = EGL_TRUE;
-  else
- ret = dri2_initialize_drm(drv, disp);
+  ret = dri2_initialize_drm(drv, disp);
   break;
 #endif
 #ifdef HAVE_WAYLAND_PLATFORM
case _EGL_PLATFORM_WAYLAND:
-  if (disp->Options.TestOnly)
- ret = EGL_TRUE;
-  else
- ret = dri2_initialize_wayland(drv, disp);
+  ret = dri2_initialize_wayland(drv, disp);
   break;
 #endif
 #ifdef HAVE_ANDROID_PLATFORM
case _EGL_PLATFORM_ANDROID:
-  if (disp->Options.TestOnly)
- ret = EGL_TRUE;
-  else
- ret = dri2_initialize_android(drv, disp);
+  ret = dri2_initialize_android(drv, disp);
   break;
 #endif
default:
-- 
2.8.0.rc3.226.g39d4020

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

Re: [Mesa-dev] [PATCH v2 3/7] egl/android: Fix support for pbuffers (v2)

[Tomasz Figa]

On Wed, Aug 3, 2016 at 9:38 PM, Rob Herring  wrote:
> On Tue, Aug 2, 2016 at 9:27 PM, Tomasz Figa  wrote:
>> Hi Rob,
>>
>> On Wed, Aug 3, 2016 at 2:32 AM, Rob Herring  wrote:
>>> On Tue, Aug 2, 2016 at 6:07 AM, Tomasz Figa  wrote:
 From: Nicolas Boichat 

 Existing image loader code supports creating images only for window
 surfaces. Moreover droid_create_surface() passes wrong surface type to
 dri2_get_dri_config(), resulting in incorrect configs being returned for
 pbuffers. This patch fixes these issues.

 In addition, the config generation code is fixed to include single
 buffered contexts required for pbuffers and make sure that generated
 configs support only surfaces which can handle their supported buffering
 modes.

 v2: Return error only in case of real error condition and ignore requests
 of unavailable buffers.
 Improve coding style.
>>>
>>> This still breaks Android for me. Just adding the hunks below is
>>> enough to break things. It results in get_buffers() being called with
>>> type == EGL_WINDOW_BIT and buffer_mask == __DRI_IMAGE_BUFFER_FRONT. I
>>> don't see any requests for the front buffer without this change. I've
>>> looked through the tree, but don't really see what would cause
>>> buffer_mask to change.
>>
>> Thanks for testing again and sorry to hear that it still doesn't work 
>> correctly.
>>
>> It looks like somehow a single buffered config ends up being used for
>> a window surface with your driver.
>>
>> Could you give me some instructions how to set up some environment for
>> testing to reproduce the issue?
>
> https://github.com/robherring/generic_device/wiki/KConfig-based-Multi-platform-Android-Device-(and-Mesa-graphics)

Thanks. Will try in next days.

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

Re: [Mesa-dev] [PATCH v2 3/7] egl/android: Fix support for pbuffers (v2)

[Rob Herring]

On Tue, Aug 2, 2016 at 9:27 PM, Tomasz Figa  wrote:
> Hi Rob,
>
> On Wed, Aug 3, 2016 at 2:32 AM, Rob Herring  wrote:
>> On Tue, Aug 2, 2016 at 6:07 AM, Tomasz Figa  wrote:
>>> From: Nicolas Boichat 
>>>
>>> Existing image loader code supports creating images only for window
>>> surfaces. Moreover droid_create_surface() passes wrong surface type to
>>> dri2_get_dri_config(), resulting in incorrect configs being returned for
>>> pbuffers. This patch fixes these issues.
>>>
>>> In addition, the config generation code is fixed to include single
>>> buffered contexts required for pbuffers and make sure that generated
>>> configs support only surfaces which can handle their supported buffering
>>> modes.
>>>
>>> v2: Return error only in case of real error condition and ignore requests
>>> of unavailable buffers.
>>> Improve coding style.
>>
>> This still breaks Android for me. Just adding the hunks below is
>> enough to break things. It results in get_buffers() being called with
>> type == EGL_WINDOW_BIT and buffer_mask == __DRI_IMAGE_BUFFER_FRONT. I
>> don't see any requests for the front buffer without this change. I've
>> looked through the tree, but don't really see what would cause
>> buffer_mask to change.
>
> Thanks for testing again and sorry to hear that it still doesn't work 
> correctly.
>
> It looks like somehow a single buffered config ends up being used for
> a window surface with your driver.
>
> Could you give me some instructions how to set up some environment for
> testing to reproduce the issue?

https://github.com/robherring/generic_device/wiki/KConfig-based-Multi-platform-Android-Device-(and-Mesa-graphics)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 12/12] gallium/radeon/winsyses: decrease max_alloc_size to 1/3 of largest heap

[Marek Olšák]

Hi Christian,

That deqp failure was due to my deqp setup that always used 16Kx16K
framebuffers.

I'm dropping this patch because it's obviously silly. It at least raised
awareness of this issue.

Marek

On Aug 2, 2016 7:30 PM, "Christian König"  wrote:

> Am 02.08.2016 um 14:57 schrieb Alex Deucher:
>
>> On Tue, Aug 2, 2016 at 4:55 AM, Marek Olšák  wrote:
>>
>>> On Tue, Aug 2, 2016 at 3:13 AM, Michel Dänzer 
>>> wrote:
>>>
 On 01.08.2016 16:35, Michel Dänzer wrote:

> On 30.07.2016 06:42, Marek Olšák wrote:
>
>> From: Marek Olšák 
>>
>> This is controversial, but I don't see a better way out of this.
>>
>> Tonga has 2 GB of VRAM and 2 GB of GTT. amdgpu is not capable of
>> submitting
>> an IB referencing 1 GB of VRAM and 1 GB of GTT. The CS ioctl never
>> succeeds
>> even though it's far below the limits.
>>
>> Without this, "dEQP-GLES2.functional.color_clear.single_rgb" fails to
>> submit an IB. With this, dEQP throws a framebuffer-incomplete
>> exception
>> and kills the process.
>>
>> IMO, failing the CS ioctl is worse for stability than failing big
>> allocations.
>>
> I can agree with that, but this change can't reliably prevent CS ioctl
> failures:
>
> I believe the problem is mostly due to BOs which are pinned for
> scanout.
> Since up to 6 CRTCs can scan out different buffers at any time, in the
> worst case it may not be possible to place any BOs whose size is >=
> ~1/7
> of the VRAM size.
>
> At the end of the day, this needs to be solved in the kernel one way or
> another.
>
 Or if you do want to avoid the problem in userspace for now, maybe use 1
 / (number of CRTCs + 1) instead of hardcoding 1/3?

>>> I don't know.
>>>
>>> I could avoid the problem by splitting buffers into 128MB blocks
>>> mapped into GPUVM consecutively, but that would prevent easy DMABUF
>>> sharing and CPU mappings would not be consecutive.
>>>
>> I think it could be fixed to a certain extent by handling migrations
>> to/from vram iteratively rather than trying to move the whole buffer
>> at once.  E.g., we may have enough room in vram, but not enough
>> contiguous gtt aperture or system pages to map the whole buffer to do
>> the transfer in one shot.
>>
>
> Additional to that paging VRAM should help a lot with that as well.
>
> Anyway I have both VRAM paging and splitting moves on my TODO list.
>
> Good to know that I can use "dEQP-GLES2.functional.color_clear.single_rgb"
> as a test case.
>
> Regards,
> Christian.
>
>
>> Alex
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH mesa] glx/dri3: remove never-used field

[⚛]

Your patch created rev4 at https://patchwork.freedesktop.org/series/10429/

I just created rev5 which no longer includes field hasPresent.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] dead code

[Rob Clark]

On Wed, Aug 3, 2016 at 5:00 AM, Enrico Weigelt, metux IT consult
 wrote:
> Hi folks,
>
>
> I've seen quite a lot of #if 0's - looks like dead code.
> Should we remove that ?
>

Probably it would be on a case-by-case basis.  There are at least a
few places with some useful debug code, ie. not the kind that you'd
normally enable, but stuff you'd want if you were making changes in
those areas..

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

[Mesa-dev] [PATCH] dri: use 'bool' instead of 'int' for boolean variables

[Jan Ziak]

Signed-off-by: Jan Ziak (http://atom-symbol.net) <0xe2.0x9a.0...@gmail.com>
---
 src/egl/drivers/dri2/egl_dri2.h   | 19 ++-
 src/egl/drivers/dri2/platform_drm.c   |  6 +++---
 src/egl/drivers/dri2/platform_wayland.c   | 20 ++--
 src/egl/drivers/dri2/platform_x11.c   |  4 ++--
 src/gallium/auxiliary/vl/vl_winsys_dri3.c |  3 ++-
 src/glx/dri3_priv.h   |  5 +++--
 src/loader/loader.c   | 19 ++-
 src/loader/loader.h   |  4 +++-
 8 files changed, 43 insertions(+), 37 deletions(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
index 4577875..f4e6be8 100644
--- a/src/egl/drivers/dri2/egl_dri2.h
+++ b/src/egl/drivers/dri2/egl_dri2.h
@@ -28,6 +28,7 @@
 #ifndef EGL_DRI2_INCLUDED
 #define EGL_DRI2_INCLUDED
 
+#include 
 #include 
 
 #ifdef HAVE_X11_PLATFORM
@@ -160,7 +161,7 @@ struct dri2_egl_display
int   dri2_major;
int   dri2_minor;
__DRIscreen  *dri_screen;
-   int   own_dri_screen;
+   bool  own_dri_screen;
const __DRIconfig   **driver_configs;
void *driver;
const __DRIcoreExtension   *core;
@@ -181,8 +182,8 @@ struct dri2_egl_display
 * dri2_make_current (tracks if there are active contexts/surfaces). */
int   ref_count;
 
-   int   own_device;
-   int   invalidate_available;
+   bool  own_device;
+   bool  invalidate_available;
int   min_swap_interval;
int   max_swap_interval;
int   default_swap_interval;
@@ -201,7 +202,7 @@ struct dri2_egl_display
 #ifdef HAVE_X11_PLATFORM
xcb_connection_t *conn;
int  screen;
-   int  swap_available;
+   bool swap_available;
 #ifdef HAVE_DRI3
struct loader_dri3_extensions loader_dri3_ext;
 #endif
@@ -214,13 +215,13 @@ struct dri2_egl_display
struct wl_drm*wl_drm;
struct wl_shm*wl_shm;
struct wl_event_queue*wl_queue;
-   int  authenticated;
+   bool  authenticated;
int  formats;
uint32_t  capabilities;
 #endif
 
-   int  is_render_node;
-   int  is_different_gpu;
+   bool  is_render_node;
+   bool  is_different_gpu;
 };
 
 struct dri2_egl_context
@@ -244,7 +245,7 @@ struct dri2_egl_surface
__DRIdrawable   *dri_drawable;
__DRIbuffer  buffers[5];
int  buffer_count;
-   int  have_fake_front;
+   bool have_fake_front;
 
 #ifdef HAVE_X11_PLATFORM
xcb_drawable_t   drawable;
@@ -282,7 +283,7 @@ struct dri2_egl_surface
 #ifdef HAVE_DRM_PLATFORM
   struct gbm_bo   *bo;
 #endif
-  int locked;
+  boollocked;
   int age;
} color_buffers[4], *back, *current;
 #endif
diff --git a/src/egl/drivers/dri2/platform_drm.c 
b/src/egl/drivers/dri2/platform_drm.c
index 9373496..06c06ab 100644
--- a/src/egl/drivers/dri2/platform_drm.c
+++ b/src/egl/drivers/dri2/platform_drm.c
@@ -56,7 +56,7 @@ lock_front_buffer(struct gbm_surface *_surf)
bo = dri2_surf->current->bo;
 
if (device->dri2) {
-  dri2_surf->current->locked = 1;
+  dri2_surf->current->locked = true;
   dri2_surf->current = NULL;
}
 
@@ -72,7 +72,7 @@ release_buffer(struct gbm_surface *_surf, struct gbm_bo *bo)
 
for (i = 0; i < ARRAY_SIZE(dri2_surf->color_buffers); i++) {
   if (dri2_surf->color_buffers[i].bo == bo) {
-dri2_surf->color_buffers[i].locked = 0;
+dri2_surf->color_buffers[i].locked = false;
   }
}
 }
@@ -621,7 +621,7 @@ dri2_initialize_drm(_EGLDriver *drv, _EGLDisplay *disp)
  fd = loader_open_device(buf);
   if (fd < 0)
  fd = loader_open_device("/dev/dri/card0");
-  dri2_dpy->own_device = 1;
+  dri2_dpy->own_device = true;
   gbm = gbm_create_device(fd);
   if (gbm == NULL)
  goto cleanup;
diff --git a/src/egl/drivers/dri2/platform_wayland.c 
b/src/egl/drivers/dri2/platform_wayland.c
index e714e44..675ca2b 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -101,7 +101,7 @@ wl_buffer_release(void *data, struct wl_buffer *buffer)
   return;
}
 
-   dri2_surf->color_buffers[i].locked = 0;
+   dri2_surf->color_buffers[i].locked = false;
 }
 
 static const struct wl_buffer_listener wl_buffer_listener = {
@@ -288,7 +288,7 @@ dri2_wl_release_buffers(struct dri2_egl_surface *dri2_surf)
   dri2_surf->color_buffers[i].dri_image = NULL;
   dri2_surf->color_buffers[i].linear_copy = 

[Mesa-dev] [PATCH] anv: GetDeviceImageFormatProperties: fix transfer destination formats

[Lionel Landwerlin]

We let the user believe we support some transfer destination formats
which we don't. This can lead to crashes when actually trying to use
those formats for example on
dEQP-VK.api.copy_and_blit.image_to_image.* tests.

Allow formats we can render to as meta implements transfers using
attachments.

Signed-off-by: Lionel Landwerlin 
Cc: Jason Ekstrand 
---
 src/intel/vulkan/anv_formats.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/src/intel/vulkan/anv_formats.c b/src/intel/vulkan/anv_formats.c
index b26e48a..1a3b19d 100644
--- a/src/intel/vulkan/anv_formats.c
+++ b/src/intel/vulkan/anv_formats.c
@@ -514,18 +514,13 @@ VkResult anv_GetPhysicalDeviceImageFormatProperties(
   }
}
 
-#if 0
if (usage & VK_IMAGE_USAGE_TRANSFER_DST_BIT) {
-  if (anv_format_for_vk_format(format)->has_stencil) {
- /* Not yet implemented because copying to a W-tiled surface is crazy
-  * hard.
-  */
- anv_finishme("support VK_IMAGE_USAGE_TRANSFER_DST_BIT for "
-  "stencil format");
+  /* Meta implements transfers by rendering to the attachment image. */
+  if (!(format_feature_flags & (VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BIT |
+
VK_FORMAT_FEATURE_DEPTH_STENCIL_ATTACHMENT_BIT))) {
  goto unsupported;
   }
}
-#endif
 
if (usage & VK_IMAGE_USAGE_SAMPLED_BIT) {
   if (!(format_feature_flags & VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT)) {
-- 
2.8.1

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

Re: [Mesa-dev] __func__ vs. __FUNCTION__

[Eric Engestrom]

On Wed, Aug 03, 2016 at 11:41:58AM +0200, Enrico Weigelt, metux IT consult 
wrote:
> Hi folks,
> 
> 
> I've seen we're using __func__ as well as __FUNCTION__.
> Should we consolidate that ?
> 
> 
> --mtx

Hi,

To reply this and your other questions, I think you should just send
those patches and see what people think of it, especially for patches
as easy as running:
sed s/__FUNCTION__/__func__/g -i $(grep -rl __FUNCTION__)

BTW, c99_compat.h has a #define for __func__ where needed, so this
change (removing use of __FUNCTION__) is a good one indeed :)

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

[Mesa-dev] __func__ vs. __FUNCTION__

[Enrico Weigelt, metux IT consult]

Hi folks,


I've seen we're using __func__ as well as __FUNCTION__.
Should we consolidate that ?


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

Re: [Mesa-dev] [PATCH 0/3] RadeonSI GLSL "lit" tests

[Nicolai Hähnle]

On 03.08.2016 01:28, Marek Olšák wrote:

On Tue, Aug 2, 2016 at 9:23 PM, Nicolai Hähnle  wrote:



On 02.08.2016 21:06, Marek Olšák wrote:


On Tue, Aug 2, 2016 at 3:40 PM, Nicolai Hähnle  wrote:


On 31.07.2016 22:29, Marek Olšák wrote:



Inspired by LLVM, I created a small test suite that looks like "lit"
tests, except that the input is GLSL and it verifies asm.

The motivation was to verify that we generate optimal code when starting
from GLSL.

[PATCH 1/3] radeonsi: add environment variable SI_FORCE_FAMILY
[PATCH 2/3] radeonsi: add a standalone compiler amdgcn_glslc
[PATCH 3/3] radeonsi: add GLSL lit tests




Good idea. Two comments:

Please use .glsl or some such instead of .ll as a file extension. Those
files are not LLVM IR.

There's a `make check` in Mesa, which I readily admit to not using
enough.
There are r300_compiler_tests that are hooked up to it. Perhaps it's
worth
wiring that up?



Some of the tests currently fail and will continue to fail for quite
some time. I don't think people would appreciate it if "make check"
always failed.



llvm-lit has an "expected failures" mode which could be used. It works by
adding a line

; XFAIL: *

to the test.


"expected failures" doesn't say whether the failures are good or bad.
I've always understood "expected failures" as "failing is the correct
behavior here".


I think those cases are better expressed with `not` and the like.


Also, I guess people would be very unhappy that their make check
failures can only be fixed by building LLVM from source, or worse
(better?), by writing patches for LLVM. ;)


That's a fair point. I don't feel that strongly about the `make check` 
integration anyway. My R-b also applies if you only change those file 
extensions.


Cheers,
Nicolai



Marek


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

[Mesa-dev] dead code

[Enrico Weigelt, metux IT consult]

Hi folks,


I've seen quite a lot of #if 0's - looks like dead code.
Should we remove that ?


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

[Mesa-dev] what happened to libgallium.so ?

[Enrico Weigelt, metux IT consult]

Hi folks,


I'm currently backporting latest mesa to Ubuntu Trusty, starting
with their original deb files. One problem I stumbled across is that
libgallium.so isn't built/installed anymore - it seems that it's now
statically linked into all the drivers.

What happened to that so ? Why now statically linked ?


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

Re: [Mesa-dev] c99 vs v90

[Enrico Weigelt, metux IT consult]

On 03.08.2016 09:47, Timothy Arceri wrote:

> The current requirement for Mesa is MSVC 2013 so any compat workarounds
> for functionality supported by that version can be dropped.
> 
> A bunch of stuff has been dropped already but feel free to find any
> remaining code. 

hmm, I dont have any msvc here (actually, no windows at all), but I
could prepare patches, which other people could test.


--mtx

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

Re: [Mesa-dev] [PATCH] dri2: Insert a synchronisation point for glXWaitX

[Chris Wilson]

On Mon, Aug 17, 2015 at 03:17:30PM -0700, Eric Anholt wrote:
> Chris Wilson  writes:
> 
> > "X rendering calls made prior to glXWaitX are guaranteed to be
> > executed before GL rendering calls made after glXWaitX."
> >
> > The goal is to implement that without adding a round-trip to the
> > Xserver. Adding one using XSync() is easy, but we can piggy-back
> > another, the DRI2GetBuffers request made to update the render buffers
> > before the next rendering (thus satisfying the condition of flushing all
> > X operations before the next GL rendering). To this end we can just flag
> > the DRI2 buffers as invalid, and the driver will refresh them in due
> > course. If the DRI2 buffers are, or will be, invalid due to damage from
> > X or through a SwapBuffers call, we will not have to add another
> > roundtrip as the single DRI2GetBuffers will refresh over multiple
> > invalidates.
> >
> > This should fix the historic issue that glXWaitX() has been unreliable,
> > but has recently found itself a new trigger will the removal of
> > unnecessary glViewport calls:
> 
> I think XSync makes more sense.  It's cheaper, and it does exactly what
> you're supposed to do at this point -- make sure that all your X
> requests have been processed, so that any GL batchbuffer flushes happen
> after that.

Considering the issue that Michel raise, XSync is not cheaper than a
known flush point.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Mesa (master): egl/dri2: Add reference count for dri2_egl_display

[Tomasz Figa]

Hi,

On Tue, Aug 2, 2016 at 7:21 PM, Martin Peres
 wrote:
> On 29/07/16 09:20, Michel Dänzer wrote:
>>
>> On 28.07.2016 22:11, Emil Velikov wrote:
>>>
>>> Module: Mesa
>>> Branch: master
>>> Commit: 9ee683f877b283020c6f24776236f1145cb7a4ea
>>> URL:
>>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=9ee683f877b283020c6f24776236f1145cb7a4ea
>>>
>>> Author: Nicolas Boichat 
>>> Date:   Fri Jul 22 11:27:41 2016 +0800
>>>
>>> egl/dri2: Add reference count for dri2_egl_display
>>
>>
>> While this change fixed the piglit test "spec@egl 1.4@eglterminate then
>> unbind context" for me with radeonsi, unfortunately it broke
>> "spec@egl_khr_create_context@verify gl flavor" (reproducible with
>> LIBGL_ALWAYS_SOFTWARE=1) and spec@egl_khr_fence_sync@conformance in turn.
>>
>>
>
> Came here to report the same thing, are you planning on looking into this
> Nicolas?

Took a quick look at this and it seems like we might have found the
culprit. Stay tuned for a patch. Thanks for reporting.

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

Re: [Mesa-dev] [PATCH] main/shaderimage: image unit invalid if texture is incomplete, independently of the level

[Alejandro Piñeiro]

On 27/07/16 13:47, Alejandro Piñeiro wrote:
> On 26/07/16 22:16, Francisco Jerez wrote:
 -- However that spec change would have the side effect of making
 the CTS test you're trying to fix non-compliant...
>>> This would not be the first case of a CTS test that is not correct due
>>> the complexities/ambiguities of the OpenGL spec. Or worse, CTS tests
>>> that are just
>>>
>> Heh, seems like some words were censored from your last paragraph. :P
> Totally unintentional and innocent, I promise ;) When writing the email
> I didn't find a suitable word when writing that paragraph, and then I
> forgot to got back. Let's go simple and just say "wrong".
>
>>> So what about this: I open a Khronos bug (public unless someone thinks
>>> that it would be better private), using your explanation as a base to
>>> the description (although tempted to just point this email), and we put
>>> the patch/bugfix on hold until we get an answer?
>>>
>> Sure, feel free to use my last post as starting point, and thanks for
>> filing the bug at Khronos. :)
> Thanks to you for the patience and the long and detailed explanation.
>
> You can find the bug here:
> https://www.khronos.org/bugzilla/show_bug.cgi?id=1654
>
> Is basically a edited form of your explanation (some sections are your
> explanation word by word).

FWIW, the list of CTS tests that would need to be tweaked is bigger. 8
CTS tests would need to be updated if the conclusion is that as soon as
the texture is incomplete the image unit is invalid. Full list on the
ping I just sent to the khronos bug:
https://www.khronos.org/bugzilla/show_bug.cgi?id=1654#c1

BR



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

Re: [Mesa-dev] c99 vs v90

[Timothy Arceri]

On Wed, 2016-08-03 at 08:27 +0200, Enrico Weigelt, metux IT consult
wrote:
> Hi folks,
> 
> 
> do we still need to support pre-c99 compilers or could we drop
> that compat stuff ?

The problem we have had is Microsoft Visual C doesn't fully support c99
although Microsoft has finally been adding support in recent versions
\o/ 

The current requirement for Mesa is MSVC 2013 so any compat workarounds
for functionality supported by that version can be dropped.

A bunch of stuff has been dropped already but feel free to find any
remaining code. 

> 
> 
> --mtx
> ___
> 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] c99 vs v90

[Enrico Weigelt, metux IT consult]

Hi folks,


do we still need to support pre-c99 compilers or could we drop
that compat stuff ?


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