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

2020-03-30 Thread Adam Jackson
On Sun, 2020-03-29 at 09:45 -0700, Kristian Høgsberg wrote:

> As for loading, doesn't glvnd solve that?

It could. It does not. Right now there's not a (good) way for the DDX
driver to communicate a preferred implementation name to the GLX
client. xserver's glx just knows it needs an implementation named mesa,
and nvidia's glx, nvidia. Not a hard thing to wire up, and in fact you
can give multiple names and the client side will try them in sequence
so fallback stands a chance of working.

Now, if we're doing that, we should maybe consider using glvnd's
libGLdispatch directly, as I think right now we have an ugly double-
indirection between glHamSandwichEXT and _mesa_HamSandwichEXT if you're
building for glvnd. The only thing in the world besides Mesa that cares
about glapi and what a DRI driver interface is is xserver, and that's a
detail I'd like to eliminate and the new EGL-backed GLX in Xwayland
gets really close to eliminating it. But if nobody else gets excited
that much about fixing GLX, I completely understand.

- ajax

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


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

2020-03-30 Thread Kristian Høgsberg
On Mon, Mar 30, 2020, 7:59 AM Adam Jackson  wrote:

> On Sun, 2020-03-29 at 09:45 -0700, Kristian Høgsberg wrote:
>
> > As for loading, doesn't glvnd solve that?
>
> It could. It does not. Right now there's not a (good) way for the DDX
> driver to communicate a preferred implementation name to the GLX
> client. xserver's glx just knows it needs an implementation named mesa,
> and nvidia's glx, nvidia. Not a hard thing to wire up, and in fact you
> can give multiple names and the client side will try them in sequence
> so fallback stands a chance of working.
>
> Now, if we're doing that, we should maybe consider using glvnd's
> libGLdispatch directly, as I think right now we have an ugly double-
> indirection between glHamSandwichEXT and _mesa_HamSandwichEXT if you're
> building for glvnd. The only thing in the world besides Mesa that cares
> about glapi and what a DRI driver interface is is xserver, and that's a
> detail I'd like to eliminate and the new EGL-backed GLX in Xwayland
> gets really close to eliminating it. But if nobody else gets excited
> that much about fixing GLX, I completely understand.
>

Yeah it would make sense to disable the double dispatch and it would be
tempting to get rid of dri driver loading entirely then...

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


[Mesa-dev] [PATCH kmscube] meson.build: Do not set c_std

2020-03-30 Thread Fabio Estevam
When building kmscube in Buildroot for ARM the following
errors are seen:

../common.c: In function 'get_time_ns':
../common.c:376:18: error: storage size of 'tv' isn't known
  struct timespec tv;
  ^~
../common.c:377:2: warning: implicit declaration of function 'clock_gettime'; 
did you mean 'localtime'? [-Wimplicit-function-declaration]
  clock_gettime(CLOCK_MONOTONIC, &tv);
  ^
  localtime
../common.c:377:16: error: 'CLOCK_MONOTONIC' undeclared (first use in this 
function)
  clock_gettime(CLOCK_MONOTONIC, &tv);

Fix it by using the default for each compiler on every platform instead.

Inspired by this gst-plugins-good commit:

https://cgit.freedesktop.org/gstreamer/gst-plugins-good/commit/?id=19f6559582c73123a3ec1fcf5a6b8651fbc2e83f

Signed-off-by: Fabio Estevam 
---
 meson.build | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/meson.build b/meson.build
index b8131db..0f52dfe 100644
--- a/meson.build
+++ b/meson.build
@@ -26,13 +26,9 @@ project(
   version : '0.0.1',
   license : 'MIT',
   meson_version : '>= 0.47',
-  default_options : ['c_std=c99', 'warning_level=2']
+  default_options : ['warning_level=2']
 )
 
-if get_option('c_std') != 'c99'
-  error('c_std must be c99')
-endif
-
 sources = files(
   'common.c',
   'cube-shadertoy.c',
-- 
2.17.1

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


Re: [Mesa-dev] [PATCH kmscube] meson.build: Do not set c_std

2020-03-30 Thread Fabio Estevam
Hi Rob,

On Mon, Mar 30, 2020 at 6:29 PM Fabio Estevam  wrote:
>
> When building kmscube in Buildroot for ARM the following
> errors are seen:
>
> ../common.c: In function 'get_time_ns':
> ../common.c:376:18: error: storage size of 'tv' isn't known
>   struct timespec tv;
>   ^~
> ../common.c:377:2: warning: implicit declaration of function 'clock_gettime'; 
> did you mean 'localtime'? [-Wimplicit-function-declaration]
>   clock_gettime(CLOCK_MONOTONIC, &tv);
>   ^
>   localtime
> ../common.c:377:16: error: 'CLOCK_MONOTONIC' undeclared (first use in this 
> function)
>   clock_gettime(CLOCK_MONOTONIC, &tv);
>
> Fix it by using the default for each compiler on every platform instead.
>
> Inspired by this gst-plugins-good commit:
>
> https://cgit.freedesktop.org/gstreamer/gst-plugins-good/commit/?id=19f6559582c73123a3ec1fcf5a6b8651fbc2e83f
>
> Signed-off-by: Fabio Estevam 
> ---
>  meson.build | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/meson.build b/meson.build
> index b8131db..0f52dfe 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -26,13 +26,9 @@ project(
>version : '0.0.1',
>license : 'MIT',
>meson_version : '>= 0.47',
> -  default_options : ['c_std=c99', 'warning_level=2']
> +  default_options : ['warning_level=2']

c99 was set in commit 6cbd03ab9406 ("Makefile.am: Add -std=c99 to
CFLAGS") to fix build failure on mips64el:

cube-tex.c:230:2: note: use option -std=c99 or -std=gnu99 to compile your code

If we change c_std=gnu99 then we could make both mips64el and ARM happy.

Will send a v2 with c_std=gnu99.

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


[Mesa-dev] [PATCH kmscube v2] meson.build: Change c_std to gnu99

2020-03-30 Thread Fabio Estevam
Since commit 301a556b8ece ("add fps reporting") the  header
is included, which causes build failures with c99 extension on ARM32:

../common.c: In function 'get_time_ns':
../common.c:376:18: error: storage size of 'tv' isn't known
  struct timespec tv;
  ^~
../common.c:377:16: error: 'CLOCK_MONOTONIC' undeclared (first use in this 
function)
  clock_gettime(CLOCK_MONOTONIC, &tv);

Change c_std to gnu99 to fix the build error as explained at:
https://gcc-help.gcc.gnu.narkive.com/8xCaKI6r/problem-with-struct-timespec-and-c99-standard
 
c99 has been used since commit 6cbd03ab9406 ("Makefile.am: Add -std=c99 to
CFLAGS") to fix the following mips64el build failure:

"cube-tex.c:230:2: note: use option -std=c99 or -std=gnu99 to compile your code"

Use c_std=gnu99 to make both mips64el and ARM32 happy.

Signed-off-by: Fabio Estevam 
---
Changes since v1:
- Change c_std to gnu99

 meson.build | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meson.build b/meson.build
index b8131db..4fca2f2 100644
--- a/meson.build
+++ b/meson.build
@@ -26,11 +26,11 @@ project(
   version : '0.0.1',
   license : 'MIT',
   meson_version : '>= 0.47',
-  default_options : ['c_std=c99', 'warning_level=2']
+  default_options : ['c_std=gnu99', 'warning_level=2']
 )
 
-if get_option('c_std') != 'c99'
-  error('c_std must be c99')
+if get_option('c_std') != 'gnu99'
+  error('c_std must be gnu99')
 endif
 
 sources = files(
-- 
2.17.1

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


[Mesa-dev] [AppVeyor] mesa-webhook master #15095 failed

2020-03-30 Thread AppVeyor



Build mesa-webhook 15095 failed


Commit 50e3b2e390 by Icecream95 on 3/24/2020 4:33 AM:

panfrost: Correctly identify format 0x4c\n\nReviewed-by: Alyssa Rosenzweig \nTested-by: Marge Bot \nPart-of: 


Configure your notification preferences

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


[Mesa-dev] [AppVeyor] mesa-webhook master #15096 completed

2020-03-30 Thread AppVeyor


Build mesa-webhook 15096 completed



Commit 02ad147c5c by Alyssa Rosenzweig on 3/31/2020 12:54 AM:

pan/bi: Fix handling of constants with COMBINE\n\nWe should never see COMBINE constants explicitly since they'll become\nmoves anyway, so we can simplify that. On the other hand, we do need the\ntype information for the lowering to work properly.\n\nSigned-off-by: Alyssa Rosenzweig \nTested-by: Marge Bot \nPart-of: 


Configure your notification preferences

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