[PATCH kmscube] cube-gears: Change header file to

[Fabio Estevam]

Since commit 96d63eb59e34 (" kmscube: Add gears mode") , kmscube fails
to build on platforms without .

Fix it by changing the header file to .

Reported-by: Martin Jansa 
Suggested-by: Martin Jansa 
Signed-off-by: Fabio Estevam 
---
 cube-gears.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cube-gears.c b/cube-gears.c
index d5b7a5f9cbef..cb538ecc4aee 100644
--- a/cube-gears.c
+++ b/cube-gears.c
@@ -31,7 +31,7 @@
 #include 
 #include 
 
-#include 
+#include 
 
 #include "common.h"
 #include "esUtil.h"
-- 
2.34.1

Re: [Mesa-dev] Etnaviv: eglCreateWindowSurface fails with glmark2

[Fabio Estevam]

Hi Lucas,

On Mon, Sep 21, 2020 at 9:59 AM Lucas Stach  wrote:

> Try starting glmark with --visual-config red=8 as a workaround to get a
> scanout capable visual.

You are right: passing --visual-config red=8 works with the old
version of glmark2.

The latest glmark2 version works without passing any extra parameter.

I believe this has been fixed by this glmark2 commit:
https://github.com/glmark2/glmark2/commit/c50755b5a19370fef5b865c9a4a9eeb0bbe56a8f

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

Re: [Mesa-dev] Etnaviv: eglCreateWindowSurface fails with glmark2

[Fabio Estevam]

Hi Lucas,

On Mon, Sep 21, 2020 at 9:59 AM Lucas Stach  wrote:

> Since a while Mesa offers 10bit EGL configs, which have the highest
> priority and thus get selected if the application doesn't care about
> bit depth. imx-drm is unable to scanout those formats.
>
> Try starting glmark with --visual-config red=8 as a workaround to get a
> scanout capable visual.

Thanks for the suggestion.

I bumped the glmark2 version to the latest one in master and now it
runs fine without any extra parameters.

Thanks,

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

[Mesa-dev] Etnaviv: eglCreateWindowSurface fails with glmark2

[Fabio Estevam]

Hi,

I am trying to run glmark2 and I am getting the following error on an
imx6qp-sabresd with kernel 5.8.4:

# glmark2-es2-drm -d
Debug: Using Udev to detect the right DRM node to use
Debug: Looking for the main GPU DRM node...
Debug: Not found!
Debug: Looking for a concrete GPU DRM node...
Debug: Success!
Debug: Trying to use the DRM node /dev/dri/card0
Debug: Success!
Debug: Using eglGetPlatformDisplayEXT()
Debug: Got 6 suitable EGLConfigs:
Debug:
Debug: cfg buf  rgb  colorbuffer dp st config native support surface sample
Debug:  id  sz  lum  r  g  b  a  th cl caveat render  visidtype  buf ns
Debug: 
Debug: 0x2  32  rgb 10 10 10  2  16  0   None   true0x30334241
0x4   0  0
Debug: 0xa  32  rgb  8  8  8  8  16  0   None   true0x34325241
0x4   0  0
Debug: 0x3  32  rgb 10 10 10  2  24  0   None   true0x30334241
0x4   0  0
Debug: 0xb  32  rgb  8  8  8  8  24  0   None   true0x34325241
0x4   0  0
Debug: 0x4  32  rgb 10 10 10  2  24  8   None   true0x30334241
0x4   0  0
Debug: 0xc  32  rgb  8  8  8  8  24  8   None   true0x34325241
0x4   0  0
Debug:
Debug: Best EGLConfig ID: 0x3
Error: eglCreateWindowSurface failed with error: 0x3009
Error: eglCreateWindowSurface failed with error: 0x3009
Error: CanvasGeneric: Invalid EGL state
Error: main: Could not initialize canvas

kmscube runs without issues.

glmark2-es2-drm used to work fine with older kernel/Mesa versions.

Does anyone have any ideas?

Thanks,

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

Re: [Mesa-dev] [PATCH kmscube] texturator: Use !! for boolean assignment

[Fabio Estevam]

Hi Jason and Ian,

On Tue, Mar 31, 2020 at 5:39 PM Jason Ekstrand  wrote:

> My feelings aren't usually all that strong on this point though I
> generally prefer !=.  That said, this is a float.  I very strongly
> prefer != 0.0f.

Thanks for the feedback. I did as suggested:
https://gitlab.freedesktop.org/festevam/kmscube/-/commit/4660a7dca6512b6e658759d00cff7d4ad2a2059d

and sent Rob a merge request.

Thanks
___
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

[Fabio Estevam]

On Tue, Mar 31, 2020 at 10:25 PM Fabio Estevam  wrote:
>
> Hi Rob,
>
> On Tue, Mar 31, 2020 at 7:40 PM Rob Clark  wrote:
>
> > thx.. I don't suppose I could talk you in to sending a gitlab merge request?
>
> Please find it at
> https://gitlab.freedesktop.org/mesa/kmscube/-/merge_requests/22

Sorry, this is the correct one:
https://gitlab.freedesktop.org/mesa/kmscube/-/merge_requests/23
___
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

[Fabio Estevam]

Hi Rob,

On Tue, Mar 31, 2020 at 7:40 PM Rob Clark  wrote:

> thx.. I don't suppose I could talk you in to sending a gitlab merge request?

Please find it at
https://gitlab.freedesktop.org/mesa/kmscube/-/merge_requests/22

Let me know if this is the correct process.

Thanks
___
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

[Fabio Estevam]

Hi Rob,

On Tue, Mar 31, 2020 at 7:40 PM Rob Clark  wrote:

> thx.. I don't suppose I could talk you in to sending a gitlab merge request?

I never did it, but let me try to learn it how to do it.

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

[Mesa-dev] [PATCH kmscube] texturator: Use !! for boolean assignment

[Fabio Estevam]

The 'complemented' variable is a pointer to boolean. Use the !! operator
to fix the following build warning:

../texturator.c:603:45: warning: '*' in boolean context, suggest '&&' instead 
[-Wint-in-bool-context]
  *complemented = (((float)rgba[2]) / 255.0) / 0.25;

Signed-off-by: Fabio Estevam 
---
 texturator.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/texturator.c b/texturator.c
index a450dfe..d31b601 100644
--- a/texturator.c
+++ b/texturator.c
@@ -602,7 +602,7 @@ static void extract_pix(uint8_t *rgba, int *slice, int 
*level, bool *complemente
 {
*slice = (((float)rgba[0]) / 255.0) * 8.0;
*level = (((float)rgba[1]) / 255.0) * 16.0;
-   *complemented = (((float)rgba[2]) / 255.0) / 0.25;
+   *complemented = !!(((float)rgba[2]) / 255.0) / 0.25;
 }
 
 static bool probe_pix(int x, int y, int w, int h, int s, int m)
-- 
2.17.1

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

[Mesa-dev] [PATCH kmscube] texturator: Only define png variable when libpng is present

[Fabio Estevam]

When libpng is not present the following build warning is seen:

../texturator.c:98:13: warning: 'png' defined but not used [-Wunused-variable]
 static bool png;

Fix it by only defining the png variable when HAVE_LIBPNG is defined.

Signed-off-by: Fabio Estevam 
---
 texturator.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/texturator.c b/texturator.c
index 2675244..a450dfe 100644
--- a/texturator.c
+++ b/texturator.c
@@ -95,7 +95,9 @@ static int error_frames;
 static int zoom = 1;
 static bool full;
 static bool stop;
+#ifdef HAVE_LIBPNG
 static bool png;
+#endif
 static GLenum target;
 static struct size {
unsigned x, y, z;
-- 
2.17.1

___
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

[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, );

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

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

[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, );
>   ^
>   localtime
> ../common.c:377:16: error: 'CLOCK_MONOTONIC' undeclared (first use in this 
> function)
>   clock_gettime(CLOCK_MONOTONIC, );
>
> 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] meson.build: Do not set c_std

[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, );
  ^
  localtime
../common.c:377:16: error: 'CLOCK_MONOTONIC' undeclared (first use in this 
function)
  clock_gettime(CLOCK_MONOTONIC, );

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 2/2] etnaviv: blt: s/TRUE/true && s/FALSE/false

[Fabio Estevam]

Hi Christian,

On Fri, May 24, 2019 at 7:52 AM Christian Gmeiner
 wrote:
>
> Signed-off-by: Christian Gmeiner 

Maybe you could remove the '&& s/FALSE/false' from the Subject since
you are only replacing the TRUE occurrences in this patch.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] glmark2 terrain errors on imx6q

[Fabio Estevam]

Hi Lucas,

On Fri, Aug 25, 2017 at 4:57 AM, Lucas Stach  wrote:

> There is no fix for this. The terrain shaders are simply too big to be
> executed on GC2000. (You remember that 512 instruction limit mentioned
> in the reference manual? That's it.)
>
> This demo runs fine on GC3000.

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

[Mesa-dev] glmark2 terrain errors on imx6q

[Fabio Estevam]

Hi,

Getting the following errors when running glmark2 terrain test on imx6q:

# glmark2-es2-drm -b terrain
** Failed to set swap interval. Results may be bounded above by refresh rate.
===
glmark2 2014.03
===
OpenGL Information
GL_VENDOR: etnaviv
GL_RENDERER:   Gallium 0.4 on Vivante GC2000 rev 5108
GL_VERSION:OpenGL ES 2.0 Mesa 17.1.7
===
** Failed to set swap interval. Results may be bounded above by refresh rate.
[terrain] :error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
 FPS: 3 FrameTime: 333.333 ms
===
  glmark2 Score: 3
===

Does anyone know of a possible fix for this test?

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

Re: [Mesa-dev] glmark2 segfault on imx6

[Fabio Estevam]

Hi Eric,

On Thu, Jun 22, 2017 at 8:08 PM, Eric Anholt  wrote:

> I asked afrantzis today, and hopefully I'll get added as a co-maintainer
> so we can get maintenance patches like this in.  Also, apparently
> something has been broken with his mail filters, so PRs weren't being
> seen at all.

Excellent, thanks for the update!
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] glmark2 segfault on imx6

[Fabio Estevam]

Hi Lucas,

On Tue, Jun 13, 2017 at 7:10 PM, Lucas Stach  wrote:
> Hi Fabio,
>
> the attached patch should fix the issue. I should really try to get
> this upstream, as some people complained about this already...

It seems that Eric has already sent a fix for this segfault issue in
this pull request:
https://github.com/glmark2/glmark2/pull/32

There is also this pull request from Gary back in February that adds
imx drm support:
https://github.com/glmark2/glmark2/pull/29

,which was not applied.

Looks like that glmark2 project is not getting fixes/updates on a regular basis.

Would it help to move glmark2 into cgit.freedesktop.org so that more
people could contribute, review patches, etc?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] glmark2 segfault on imx6

[Fabio Estevam]

Hi Lucas,

On Tue, Jun 13, 2017 at 7:20 PM, Fabio Estevam <feste...@gmail.com> wrote:

> Excellent! This fixes the segfault. Thanks a lot!

Got a different segfault now. Please see below.

Thanks

[ideas] speed=duration:[  218.073898] etnaviv-gpu 13.gpu: hangcheck detected
 gpu lockup!
[  218.080195] etnaviv-gpu 13.gpu:  completed fence: 11124
[  218.086139] etnaviv-gpu 13.gpu:  active fence: 11125
[  218.092094] etnaviv-gpu 13.gpu: hangcheck recover!
[  221.033887] etnaviv-gpu 13.gpu: hangcheck detected gpu lockup!
[  221.040105] etnaviv-gpu 13.gpu:  completed fence: 11125
[  221.046049] etnaviv-gpu 13.gpu:  active fence: 11126
[  221.051780] etnaviv-gpu 13.gpu: hangcheck recover!
[  224.073891] etnaviv-gpu 13.gpu: hangcheck detected gpu lockup!
[  224.080111] etnaviv-gpu 13.gpu:  completed fence: 11128
[  224.086055] etnaviv-gpu 13.gpu:  active fence: 11130
[  224.091780] etnaviv-gpu 13.gpu: hangcheck recover!
[  226.073890] etnaviv-gpu 13.gpu: hangcheck detected gpu lockup!
[  226.080106] etnaviv-gpu 13.gpu:  completed fence: 11130
[  226.086052] etnaviv-gpu 13.gpu:  active fence: 11132
[  226.091772] etnaviv-gpu 13.gpu: hangcheck recover!
 FPS: 0 FrameTime: inf ms
** Failed to set swap interval. Results may be bounded above by refresh rate.
[jellyfish] : FPS: 60 FrameTime: 16.667 ms
** Failed to set swap interval. Results may be bounded above by refresh rate.
[terrain] :error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
 FPS: 3 FrameTime: 333.333 ms
** Failed to set swap interval. Results may be bounded above by refresh rate.
[shadow] : FPS: 47 FrameTime: 21.277 ms
** Failed to set swap interval. Results may be bounded above by refresh rate.
[refract] : FPS: 9 FrameTime: 111.111 ms
** Failed to set swap interval. Results may be bounded above by refresh rate.
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 63 FrameTime: 15.873 ms
[  288.290466] Unable to handle kernel paging request at virtual address 0fe6139
4
[  288.297752] pgd = ee554000
[  288.300473] [0fe61394] *pgd=
[  288.304112] Internal error: Oops: 5 [#1] SMP ARM
[  288.308743] Modules linked in:
[  288.311813] CPU: 1 PID: 217 Comm: glmark2-es2-drm Not tainted 4.11.4 #1
[  288.318433] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[  288.324966] task: ee86b100 task.stack: ee546000
[  288.329511] PC is at page_mapping

Re: [Mesa-dev] glmark2 segfault on imx6

[Fabio Estevam]

Hi Lucas,

On Tue, Jun 13, 2017 at 7:10 PM, Lucas Stach  wrote:
> Hi Fabio,
>
> the attached patch should fix the issue. I should really try to get
> this upstream, as some people complained about this already...

Excellent! This fixes the segfault. Thanks a lot!
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] glmark2 segfault on imx6

[Fabio Estevam]

Hi,

I am running kernel 4.11.4 with Etnaviv 17.1.2 on a imx6qsabresd board
and when I try to run glmark I am getting a segmentation fault:

# glmark2-es2-drm
** Failed to set swap interval. Results may be bounded above by refresh rate.
===
glmark2 2014.03
===
OpenGL Information
GL_VENDOR: etnaviv
GL_RENDERER:   Gallium 0.4 on Vivante GC2000 rev 5108
GL_VERSION:OpenGL ES 2.0 Mesa 17.1.2
===
** Failed to set swap interval. Results may be bounded above by refresh rate.
[build] use-vbo=false:Segmentation fault
#

strace log can be found here:
https://paste.ubuntu.com/24851027/

This used to work before. Does anyone have any suggestions?

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

Re: [Mesa-dev] [PATCH 0/6] Shooting some piglits

[Fabio Estevam]

Hi Lucas,

On Sun, Jun 4, 2017 at 4:06 PM, Lucas Stach  wrote:
> Hi all,
>
> I decided to take a look at our current piglit status and the following are
> some stright foward fixes for some of the issues.
>
> The first 3 patches fix some resource copy issues, that may send the blitter
> into an infinite loop in a release build, or just fall over in a debug build.
>
> The next 2 patches fix some fallout from the RB swapped rendertarget work, so
> they are fixing real regressions from mesa 17.0.
>
> The last patch gets the LOD bias test to pass.

Out of curiosity: what is the piglit pass rate for etnaviv now?

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

Re: [Mesa-dev] [PATCH] etnaviv: etnaviv_fence: Simplify the return code logic

[Fabio Estevam]

On Sat, Apr 22, 2017 at 12:44 PM, Christian Gmeiner
<christian.gmei...@gmail.com> wrote:
> 2017-04-18 0:36 GMT+02:00 Fabio Estevam <feste...@gmail.com>:
>> The return code can be simplified by using the logical not operator.
>>
>> Signed-off-by: Fabio Estevam <feste...@gmail.com>
>
> Reviewed-by: Christian Gmeiner <christian.gmei...@gmail.com>
>
> Btw. the same change could be made to freedreno.

Thanks, just sent the change to freedreno.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] freedreno: freedreno_fence: Simplify the return code logic

[Fabio Estevam]

The return code can be simplified by using the logical not operator.

Signed-off-by: Fabio Estevam <feste...@gmail.com>
---
 src/gallium/drivers/freedreno/freedreno_fence.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/freedreno/freedreno_fence.c 
b/src/gallium/drivers/freedreno/freedreno_fence.c
index f20c6ac..a4cdc3e 100644
--- a/src/gallium/drivers/freedreno/freedreno_fence.c
+++ b/src/gallium/drivers/freedreno/freedreno_fence.c
@@ -64,10 +64,8 @@ boolean fd_fence_finish(struct pipe_screen *pscreen,
struct pipe_fence_handle *fence,
uint64_t timeout)
 {
-   if (fence->fence_fd != -1) {
-   int ret = sync_wait(fence->fence_fd, timeout / 100);
-   return ret == 0;
-   }
+   if (fence->fence_fd != -1)
+   return !sync_wait(fence->fence_fd, timeout / 100);
 
if (fd_pipe_wait_timeout(fence->screen->pipe, fence->timestamp, 
timeout))
return false;
-- 
2.7.4

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

[Mesa-dev] [PATCH] etnaviv: etnaviv_fence: Simplify the return code logic

[Fabio Estevam]

The return code can be simplified by using the logical not operator.

Signed-off-by: Fabio Estevam <feste...@gmail.com>
---
 src/gallium/drivers/etnaviv/etnaviv_fence.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_fence.c 
b/src/gallium/drivers/etnaviv/etnaviv_fence.c
index 65402aa..d82708e 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_fence.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_fence.c
@@ -65,10 +65,8 @@ static boolean
 etna_screen_fence_finish(struct pipe_screen *pscreen, struct pipe_context *ctx,
  struct pipe_fence_handle *fence, uint64_t timeout)
 {
-   if (fence->fence_fd != -1) {
-  int ret = sync_wait(fence->fence_fd, timeout / 100);
-  return ret == 0;
-   }
+   if (fence->fence_fd != -1)
+   return !sync_wait(fence->fence_fd, timeout / 100);
 
if (etna_pipe_wait_ns(fence->screen->pipe, fence->timestamp, timeout))
   return false;
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH kmscube 3/3] meson build support (v2)

[Fabio Estevam]

On Mon, Mar 27, 2017 at 11:42 AM, Rob Clark  wrote:

> I'm undecided about whether or not to keep the autotools build.  I
> know there is some OE recipe floating around to build kmscube (since
> it really is the killer-app of the embedded world :-P), but otherwise
> probably aren't many/any distro's packaging it

Buildroot is using kmscube too :-)
https://git.buildroot.net/buildroot/tree/package/kmscube
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH kmscube 3/3] meson build support (v2)

[Fabio Estevam]

Hi Rob,

On Sun, Mar 26, 2017 at 10:59 AM, Rob Clark  wrote:
> Figured I should figure out what this meson stuff is all about.  After a
> bit of hunting around to find examples to look at (and interruptions) it
> took maybe ~1hr to convert (for someone who never looked at meson
> before).  The build speed is definitely faster even after Emil's auto-
> tools improvements:
>
> meson:
> real0m1.310s
> user0m2.069s
> sys 0m0.459s
>
> autotools:
> real0m4.489s
> user0m3.754s
> sys 0m0.731s
>
> (with gst / video-cube enabled, fresh build in either case so it is
> including the time spent compiling .c files in both cases)
>
> Signed-off-by: Rob Clark 

I got the following build error when applying this patch:

  CC   kmscube-gst-decoder.o
gst-decoder.c: In function ‘buf_to_fd’:
gst-decoder.c:189:40: error: ‘GBM_FORMAT_R8’ undeclared (first use in
this function)
  bo = gbm_bo_create(gbm->dev, size, 1, GBM_FORMAT_R8, GBM_BO_USE_LINEAR);
^
gst-decoder.c:189:40: note: each undeclared identifier is reported
only once for each function it appears in
Makefile:613: recipe for target 'kmscube-gst-decoder.o' failed
make: *** [kmscube-gst-decoder.o] Error 1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH kmscube] Makefile.am: Add -std=c99 to CFLAGS

[Fabio Estevam]

Currently the following build errors are seen on mips64el:

cube-tex.c: In function 'get_fd_rgba':
cube-tex.c:230:2: error: 'for' loop initial declarations are only allowed in 
C99 mode
  for (uint32_t i = 0; i < texh; i++) {
  ^
cube-tex.c:230:2: note: use option -std=c99 or -std=gnu99 to compile your code
cube-tex.c: In function 'get_fd_y':
cube-tex.c:261:2: error: 'for' loop initial declarations are only allowed in 
C99 mode
  for (uint32_t i = 0; i < texh; i++) {
  ^
cube-tex.c: In function 'get_fd_uv':
cube-tex.c:292:2: error: 'for' loop initial declarations are only allowed in 
C99 mode
  for (uint32_t i = 0; i < texh/2; i++) {
  ^

Add the -std=c99 option in CFLAGS to fix this problem.

Signed-off-by: Fabio Estevam <fabio.este...@nxp.com>
---
 Makefile.am | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Makefile.am b/Makefile.am
index b0467f8..0c29b39 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -33,6 +33,7 @@ kmscube_LDADD = \
 kmscube_CFLAGS = \
-O0 -g \
-Wall -Wextra \
+   -std=c99  \
$(DRM_CFLAGS) \
$(GBM_CFLAGS) \
$(EGL_CFLAGS) \
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH v2 kmscube] cube-tex: Do not declare counter inside 'for' loop

[Fabio Estevam]

Hi Eric,

On Tue, Mar 21, 2017 at 9:01 AM, Eric Engestrom
 wrote:

> I think I'd prefer not going backwards. Does your compiler support C99?
> If so, I'd suggest using it explicitly by adding -std=c99 to the CFLAGS
> in Makefile.am.

Yes, that works too. Just sent a patch adding -std=c99.

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

[Mesa-dev] [PATCH kmscube] drm-legacy: Include

[Fabio Estevam]

Include  to fix the following build error seen on mips64el:

drm-legacy.c: In function 'legacy_run':
drm-legacy.c:45:2: error: unknown type name 'fd_set'
  fd_set fds;
  ^
drm-legacy.c:55:2: warning: implicit declaration of function 'FD_ZERO' 
[-Wimplicit-function-declaration]
  FD_ZERO();
  ^
drm-legacy.c:56:2: warning: implicit declaration of function 'FD_SET' 
[-Wimplicit-function-declaration]
  FD_SET(0, );
  ^
drm-legacy.c:94:4: warning: implicit declaration of function 'select' 
[-Wimplicit-function-declaration]
ret = select(drm.fd + 1, , NULL, NULL, NULL);
^
drm-legacy.c:101:4: warning: implicit declaration of function 'FD_ISSET' 
[-Wimplicit-function-declaration]
} else if (FD_ISSET(0, )) {
^

Signed-off-by: Fabio Estevam <feste...@gmail.com>
---
 drm-legacy.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drm-legacy.c b/drm-legacy.c
index 8e49075..8eac417 100644
--- a/drm-legacy.c
+++ b/drm-legacy.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "common.h"
 #include "drm-common.h"
-- 
2.7.4

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

[Mesa-dev] [PATCH v2 kmscube] cube-tex: Do not declare counter inside 'for' loop

[Fabio Estevam]

Do not declare counter inside 'for' loop to fix the following build errors
on mips64el:

cube-tex.c: In function 'get_fd_rgba':
cube-tex.c:230:2: error: 'for' loop initial declarations are only allowed in 
C99 mode
  for (uint32_t i = 0; i < texh; i++) {
  ^
cube-tex.c:230:2: note: use option -std=c99 or -std=gnu99 to compile your code
cube-tex.c: In function 'get_fd_y':
cube-tex.c:261:2: error: 'for' loop initial declarations are only allowed in 
C99 mode
  for (uint32_t i = 0; i < texh; i++) {
  ^
cube-tex.c: In function 'get_fd_uv':
cube-tex.c:292:2: error: 'for' loop initial declarations are only allowed in 
C99 mode
  for (uint32_t i = 0; i < texh/2; i++) {
  ^

Signed-off-by: Fabio Estevam <feste...@gmail.com>
---
Changes since v1:
- s/initialize/declare to match the build error

 cube-tex.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/cube-tex.c b/cube-tex.c
index 0caeaea..0eff2ae 100644
--- a/cube-tex.c
+++ b/cube-tex.c
@@ -217,7 +217,7 @@ static int get_fd_rgba(uint32_t *pstride)
 {
struct gbm_bo *bo;
void *map_data = NULL;
-   uint32_t stride;
+   uint32_t stride, i;
extern const uint32_t raw_512x512_rgba[];
uint8_t *map, *src = (uint8_t *)raw_512x512_rgba;
int fd;
@@ -227,7 +227,7 @@ static int get_fd_rgba(uint32_t *pstride)
 
map = gbm_bo_map(bo, 0, 0, texw, texh, GBM_BO_TRANSFER_WRITE, , 
_data);
 
-   for (uint32_t i = 0; i < texh; i++) {
+   for (i = 0; i < texh; i++) {
memcpy([stride * i], [texw * 4 * i], texw * 4);
}
 
@@ -247,7 +247,7 @@ static int get_fd_y(uint32_t *pstride)
 {
struct gbm_bo *bo;
void *map_data = NULL;
-   uint32_t stride;
+   uint32_t stride, i;
extern const uint32_t raw_512x512_nv12[];
uint8_t *map, *src = (uint8_t *)raw_512x512_nv12;
int fd;
@@ -258,7 +258,7 @@ static int get_fd_y(uint32_t *pstride)
 
map = gbm_bo_map(bo, 0, 0, texw/4, texh, GBM_BO_TRANSFER_WRITE, 
, _data);
 
-   for (uint32_t i = 0; i < texh; i++) {
+   for (i = 0; i < texh; i++) {
memcpy([stride * i], [texw * i], texw);
}
 
@@ -278,7 +278,7 @@ static int get_fd_uv(uint32_t *pstride)
 {
struct gbm_bo *bo;
void *map_data = NULL;
-   uint32_t stride;
+   uint32_t stride, i;
extern const uint32_t raw_512x512_nv12[];
uint8_t *map, *src = &((uint8_t *)raw_512x512_nv12)[texw * texh];
int fd;
@@ -289,7 +289,7 @@ static int get_fd_uv(uint32_t *pstride)
 
map = gbm_bo_map(bo, 0, 0, texw/2/2, texh/2, GBM_BO_TRANSFER_WRITE, 
, _data);
 
-   for (uint32_t i = 0; i < texh/2; i++) {
+   for (i = 0; i < texh/2; i++) {
memcpy([stride * i], [texw * i], texw);
}
 
-- 
2.7.4

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

[Mesa-dev] [PATCH kmscube] cube-tex: Do not initialize counter inside 'for' loop

[Fabio Estevam]

Do not initialize counter inside 'for' loop to fix the following build errors
on mips64el:

cube-tex.c: In function 'get_fd_rgba':
cube-tex.c:230:2: error: 'for' loop initial declarations are only allowed in 
C99 mode
  for (uint32_t i = 0; i < texh; i++) {
  ^
cube-tex.c:230:2: note: use option -std=c99 or -std=gnu99 to compile your code
cube-tex.c: In function 'get_fd_y':
cube-tex.c:261:2: error: 'for' loop initial declarations are only allowed in 
C99 mode
  for (uint32_t i = 0; i < texh; i++) {
  ^
cube-tex.c: In function 'get_fd_uv':
cube-tex.c:292:2: error: 'for' loop initial declarations are only allowed in 
C99 mode
  for (uint32_t i = 0; i < texh/2; i++) {
  ^

Signed-off-by: Fabio Estevam <feste...@gmail.com>
---
 cube-tex.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/cube-tex.c b/cube-tex.c
index 0caeaea..0eff2ae 100644
--- a/cube-tex.c
+++ b/cube-tex.c
@@ -217,7 +217,7 @@ static int get_fd_rgba(uint32_t *pstride)
 {
struct gbm_bo *bo;
void *map_data = NULL;
-   uint32_t stride;
+   uint32_t stride, i;
extern const uint32_t raw_512x512_rgba[];
uint8_t *map, *src = (uint8_t *)raw_512x512_rgba;
int fd;
@@ -227,7 +227,7 @@ static int get_fd_rgba(uint32_t *pstride)
 
map = gbm_bo_map(bo, 0, 0, texw, texh, GBM_BO_TRANSFER_WRITE, , 
_data);
 
-   for (uint32_t i = 0; i < texh; i++) {
+   for (i = 0; i < texh; i++) {
memcpy([stride * i], [texw * 4 * i], texw * 4);
}
 
@@ -247,7 +247,7 @@ static int get_fd_y(uint32_t *pstride)
 {
struct gbm_bo *bo;
void *map_data = NULL;
-   uint32_t stride;
+   uint32_t stride, i;
extern const uint32_t raw_512x512_nv12[];
uint8_t *map, *src = (uint8_t *)raw_512x512_nv12;
int fd;
@@ -258,7 +258,7 @@ static int get_fd_y(uint32_t *pstride)
 
map = gbm_bo_map(bo, 0, 0, texw/4, texh, GBM_BO_TRANSFER_WRITE, 
, _data);
 
-   for (uint32_t i = 0; i < texh; i++) {
+   for (i = 0; i < texh; i++) {
memcpy([stride * i], [texw * i], texw);
}
 
@@ -278,7 +278,7 @@ static int get_fd_uv(uint32_t *pstride)
 {
struct gbm_bo *bo;
void *map_data = NULL;
-   uint32_t stride;
+   uint32_t stride, i;
extern const uint32_t raw_512x512_nv12[];
uint8_t *map, *src = &((uint8_t *)raw_512x512_nv12)[texw * texh];
int fd;
@@ -289,7 +289,7 @@ static int get_fd_uv(uint32_t *pstride)
 
map = gbm_bo_map(bo, 0, 0, texw/2/2, texh/2, GBM_BO_TRANSFER_WRITE, 
, _data);
 
-   for (uint32_t i = 0; i < texh/2; i++) {
+   for (i = 0; i < texh/2; i++) {
memcpy([stride * i], [texw * i], texw);
}
 
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH kmscube] kmscube: Remove unneeded brackets

[Fabio Estevam]

Hi Emil,

On Sun, Mar 19, 2017 at 7:57 AM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> On 18 March 2017 at 21:47, Fabio Estevam <feste...@gmail.com> wrote:
>> There is no need to use brackets for single line if statements,
>> so simply remove them.
>>
>> Signed-off-by: Fabio Estevam <feste...@gmail.com>
> R-b and pushed to master.
>
> I'm wondering if piping the whole kmscube repo through something like
> [the kernel's] checkpatch would be OK ?
> Just an idea of course.

Looks like a good idea to me.

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

[Mesa-dev] [PATCH kmscube] kmscube: Remove unneeded brackets

[Fabio Estevam]

There is no need to use brackets for single line if statements,
so simply remove them.

Signed-off-by: Fabio Estevam <feste...@gmail.com>
---
 kmscube.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/kmscube.c b/kmscube.c
index 8057e66..fcfd902 100644
--- a/kmscube.c
+++ b/kmscube.c
@@ -113,11 +113,10 @@ int main(int argc, char *argv[])
return -1;
}
 
-   if (mode == SMOOTH) {
+   if (mode == SMOOTH)
egl = init_cube_smooth(gbm);
-   } else {
+   else
egl = init_cube_tex(gbm, mode);
-   }
 
if (!egl) {
printf("failed to initialize EGL\n");
-- 
2.7.4

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

[Mesa-dev] [PATCH kmscube] cube-tex: Handle SMOOTH switch case

[Fabio Estevam]

In kmscube.c there is the following logic:

if (mode == SMOOTH) {
egl = init_cube_smooth(gbm);
} else {
egl = init_cube_tex(gbm, mode);
}

,which makes init_cube_tex() to be never called on the SMOOTH case.

Handle the SMOOTH switch case inside init_tex() to fix the following
build warning:

cube-tex.c: In function 'init_tex':
cube-tex.c:438:2: warning: enumeration value 'SMOOTH' not handled in switch 
[-Wswitch]
  switch (mode) {
  ^

Signed-off-by: Fabio Estevam <feste...@gmail.com>
---
 cube-tex.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/cube-tex.c b/cube-tex.c
index a543e83..8aab06c 100644
--- a/cube-tex.c
+++ b/cube-tex.c
@@ -442,6 +442,9 @@ static int init_tex(enum mode mode)
return init_tex_nv12_2img();
case NV12_1IMG:
return init_tex_nv12_1img();
+   /* should never reach here */
+   case SMOOTH:
+   return -1;
}
return -1;
 }
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH kmscube 7/7] drm-legacy.c: suppress 'unused parameter warnings

[Fabio Estevam]

Hi Eric,

On Tue, Mar 14, 2017 at 10:33 AM, Eric Engestrom
 wrote:
> Signed-off-by: Eric Engestrom 
> ---
>  drm-legacy.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drm-legacy.c b/drm-legacy.c
> index 2392a3d..8e49075 100644
> --- a/drm-legacy.c
> +++ b/drm-legacy.c
> @@ -33,6 +33,9 @@ static struct drm drm;
>  static void page_flip_handler(int fd, unsigned int frame,
>   unsigned int sec, unsigned int usec, void *data)
>  {
> +   /* suppress 'unused parameter' warnings */
> +   (void)fd, (void)frame, (void)sec, (void)usec;
> +
> int *waiting_for_flip = data;
> *waiting_for_flip = 0;
>  }

Thanks for your series.

Now there is a single warning left:

cube-tex.c: In function ‘init_tex’:
cube-tex.c:438:2: warning: enumeration value ‘SMOOTH’ not handled in
switch [-Wswitch]
  switch (mode) {
  ^

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

Re: [Mesa-dev] mx6q: Cannot run Cinematic demo correctly

[Fabio Estevam]

Hi Wladimir,

On Tue, Mar 14, 2017 at 2:47 PM, Wladimir J. van der Laan
 wrote:

> Yea, variants would be the way to render to RGBA succesfully
> on vivantes.
>
> Until then it's best to revert those two patches.
>
> Reverting only the one (latest) patch can give red/blue swapped issues when
> doing render-to-texture, it was applied in the first place to fix those issues
> caused by the first patch, but it didn't really make things better.

Thanks for your feedback.

Otavio,

Care to submit the revert for the two patches?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] mx6q: Cannot run Cinematic demo correctly

[Fabio Estevam]

Hi Otavio,

On Tue, Mar 14, 2017 at 1:58 PM, Otavio Salvador
<otavio.salva...@ossystems.com.br> wrote:
> On Tue, Mar 14, 2017 at 12:31 PM, Fabio Estevam <feste...@gmail.com> wrote:
> ...
>> The cover of the movies are just black rectangles instead of showing
>> the actual movie pictures.
> ...
>
> I am attaching the two patches I am applying on mesa locally and which
> has fixed our current issues.

Thanks for the patches!

By only reverting:

commit 6c89a728d9e5d072cb504453e73077564c6523d3
Author: Wladimir J. van der Laan <laa...@gmail.com>
Date:   Wed Dec 7 12:59:54 2016 +

etnaviv: Cannot render to rb-swapped formats

Exposing rb swapped (or other swizzled) formats for rendering would
involve swizzing in the pixel shader. This is not the case at the
moment, so reject requests for creating such surfaces.

(GPUs that need an extra resolve step anyway due to multiple pixel
pipes, such as gc2000, might also do this swap in the resolve operation.
But this would be tricky to keep track of)

CC: <mesa-sta...@lists.freedesktop.org>
Signed-off-by: Wladimir J. van der Laan <laa...@gmail.com>
Acked-by: Christian Gmeiner <christian.gmei...@gmail.com>

I can confirm that the Cinematic demo can run successfully. I do not
see the black boxes, nor font issues anymore.

Also the previous error messages are gone:
QOpenGLFramebufferObject: Unsupported framebuffer format.
QOpenGLFramebufferObject: Framebuffer incomplete, missing attachment.
QOpenGLFramebufferObject: Unsupported framebuffer format.
QOpenGLFramebufferObject: Framebuffer incomplete, missing attachment.
QOpenGLFramebufferObject: Unsupported framebuffer format.
QOpenGLFramebufferObject: Framebuffer incomplete, missing attachment.
QOpenGLFramebufferObject: Unsupported framebuffer format.
QOpenGLFramebufferObject: Framebuffer incomplete, missing attachment.

as to your other patch: I do not see commit
89bb5c79e29613ad9a4e43d670654e98a220fc60 in mesa tree.

Wladimir/Christian,

What would be the proper fix for this problem?

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

[Mesa-dev] mx6q: Cannot run Cinematic demo correctly

[Fabio Estevam]

Hi,

On a imx6q-sabresd board running kernel 4.9.14, mesa 17.0.1 and QT5.8:

# export QT_QPA_EGLFS_KMS_CONFIG=/media/sabresd.json

where sabresd.json contains:

{
  "device": "/dev/dri/card1",
  "hwcursor": false,
  "pbuffers": true,
  "outputs": [
{
  "name": "HDMI-1",
  "mode": "off"
},
{
  "name": "LVDS-1",
  "mode": "1024x768"
}
  ]
}

# /usr/share/Qt5/CinematicExperience/Qt5_CinematicExperience
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
QOpenGLFramebufferObject: Unsupported framebuffer format.
QOpenGLFramebufferObject: Framebuffer incomplete, missing attachment.
QOpenGLFramebufferObject: Unsupported framebuffer format.
QOpenGLFramebufferObject: Framebuffer incomplete, missing attachment.
QOpenGLFramebufferObject: Unsupported framebuffer format.
QOpenGLFramebufferObject: Framebuffer incomplete, missing attachment.
QOpenGLFramebufferObject: Unsupported framebuffer format.
QOpenGLFramebufferObject: Framebuffer incomplete, missing attachment.

The cover of the movies are just black rectangles instead of showing
the actual movie pictures.

As Gary Bisson noticed, if we go to bottom left setting icon and
select 'Show movies cover lighting', then all boxes show the correct
pictures, but fonts in the descriptions are still wrong.

Here is a video clip showing the the board in action:
https://www.dropbox.com/s/uuqcr3opjwlfjj5/QT5_8_on_mx6q.mp4?dl=0

Any ideas as to how to fix these problems?

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

Re: [Mesa-dev] [PATCH kmscube v3 2/2] cube-tex: Include

[Fabio Estevam]

Hi Emil,

On Mon, Mar 13, 2017 at 1:12 PM, Emil Velikov  wrote:

> Since all these were getting a bit of a drag I've addressed most of
> the major issues.
> Can you please pull latest master and send any applicable fixes on top of it.

With the latest master all the kmscube errors are gone! Thanks!
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH kmscube v3 2/2] cube-tex: Include

[Fabio Estevam]

The following error is observed on sparc64:

cube-tex.c: In function 'init_tex_nv12_2img':
cube-tex.c:350:29: error: 'DRM_FORMAT_R8' undeclared (first use in this 
function)
   EGL_LINUX_DRM_FOURCC_EXT, DRM_FORMAT_R8,
 ^
cube-tex.c:350:29: note: each undeclared identifier is reported only once for 
each function it appears in
cube-tex.c:359:29: error: 'DRM_FORMAT_GR88' undeclared (first use in this 
function)
   EGL_LINUX_DRM_FOURCC_EXT, DRM_FORMAT_GR88,

Include  to fix it.

Signed-off-by: Fabio Estevam <feste...@gmail.com>
---
 cube-tex.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/cube-tex.c b/cube-tex.c
index 1e7741d..61d6c78 100644
--- a/cube-tex.c
+++ b/cube-tex.c
@@ -22,6 +22,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
2.7.4

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

[Mesa-dev] [PATCH kmscube v3 1/2] drm.h: Include

[Fabio Estevam]

Include  header to avoid the following kmscube
build errors on sparc64:

http://autobuild.buildroot.net/results/d7e/d7e82c67e0b04b0aea990bfb19dd6e4fd914bebe/build-end.log

This also fixes the build error reported by Gary Bisson on ARM
when using Linaro 2017.02 ARM gnueabihf toolchain.

Reported-by: Gary Bisson <gary.bis...@boundarydevices.com>
Signed-off-by: Fabio Estevam <feste...@gmail.com>
---
Changes since v2:
- Only include 

 drm.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drm.h b/drm.h
index c41683b..5225c6c 100644
--- a/drm.h
+++ b/drm.h
@@ -24,6 +24,7 @@
 #ifndef _DRM_H
 #define _DRM_H
 
+#include 
 #include 
 #include 
 
-- 
2.7.4

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

[Mesa-dev] [PATCH kmscube v2 2/2] cube-tex: Include

[Fabio Estevam]

The following error is observed on sparc64:

cube-tex.c: In function 'init_tex_nv12_2img':
cube-tex.c:350:29: error: 'DRM_FORMAT_R8' undeclared (first use in this 
function)
   EGL_LINUX_DRM_FOURCC_EXT, DRM_FORMAT_R8,
 ^
cube-tex.c:350:29: note: each undeclared identifier is reported only once for 
each function it appears in
cube-tex.c:359:29: error: 'DRM_FORMAT_GR88' undeclared (first use in this 
function)
   EGL_LINUX_DRM_FOURCC_EXT, DRM_FORMAT_GR88,

Include  to fix it.

Signed-off-by: Fabio Estevam <feste...@gmail.com>>
---
Changes since v1:
- Indicate kmscube in the Subject (Ilia)

 cube-tex.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/cube-tex.c b/cube-tex.c
index 1e7741d..1fc388b 100644
--- a/cube-tex.c
+++ b/cube-tex.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "common.h"
 #include "esUtil.h"
-- 
2.7.4

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

[Mesa-dev] [PATCH kmscube v2 1/2] drm.h: Include libdrm headers

[Fabio Estevam]

Include  and  headers to avoid
the following build errors on sparc64:

http://autobuild.buildroot.net/results/d7e/d7e82c67e0b04b0aea990bfb19dd6e4fd914bebe/build-end.log

This also fixes the build error reported by Gary Bisson on ARM
when using Linaro 2017.02 ARM gnueabihf toolchain and
also on x86 with Ubuntu 16.04.

Reported-by: Gary Bisson <gary.bis...@boundarydevices.com>
Signed-off-by: Fabio Estevam <feste...@gmail.com>
---
Changes since v1:
- Indicate kmscube in the Subject (Ilia)

 drm.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drm.h b/drm.h
index c41683b..6ac7a82 100644
--- a/drm.h
+++ b/drm.h
@@ -24,6 +24,8 @@
 #ifndef _DRM_H
 #define _DRM_H
 
+#include 
+#include 
 #include 
 #include 
 
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH 1/2] drm.h: Include libdrm headers

[Fabio Estevam]

On Mon, Mar 13, 2017 at 11:07 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote:
> On Mon, Mar 13, 2017 at 10:04 AM, Fabio Estevam <feste...@gmail.com> wrote:
>> Hi Ilia,
>>
>> On Mon, Mar 13, 2017 at 11:03 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote:
>>> Which repository do these patches apply to? Also the proper way of
>>> including drm headers is
>>
>> These patches apply against kmscube repository:
>> https://cgit.freedesktop.org/mesa/kmscube
>
> Ah, it'd probably be good to use a subject like
>
> [PATCH kmscube 1/2] drm.h: bla bla bla

Yes, will do it for future patches. Thanks
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] drm.h: Include libdrm headers

[Fabio Estevam]

Hi Ilia,

On Mon, Mar 13, 2017 at 11:03 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote:
> Which repository do these patches apply to? Also the proper way of
> including drm headers is

These patches apply against kmscube repository:
https://cgit.freedesktop.org/mesa/kmscube

Regards,

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

[Mesa-dev] [PATCH 2/2] cube-tex: Include

[Fabio Estevam]

The following error is observed on sparc64:

cube-tex.c: In function ‘init_tex_nv12_2img’:
cube-tex.c:350:29: error: ‘DRM_FORMAT_R8’ undeclared (first use in this 
function)
   EGL_LINUX_DRM_FOURCC_EXT, DRM_FORMAT_R8,
 ^
cube-tex.c:350:29: note: each undeclared identifier is reported only once for 
each function it appears in
cube-tex.c:359:29: error: ‘DRM_FORMAT_GR88’ undeclared (first use in this 
function)
   EGL_LINUX_DRM_FOURCC_EXT, DRM_FORMAT_GR88,

Include  to fix it.

Signed-off-by: Fabio Estevam <feste...@gmail.com>>
---
 cube-tex.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/cube-tex.c b/cube-tex.c
index 1e7741d..1fc388b 100644
--- a/cube-tex.c
+++ b/cube-tex.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "common.h"
 #include "esUtil.h"
-- 
2.7.4

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

[Mesa-dev] [PATCH 1/2] drm.h: Include libdrm headers

[Fabio Estevam]

Include  and  headers to avoid
the following build errors on sparc64:

http://autobuild.buildroot.net/results/d7e/d7e82c67e0b04b0aea990bfb19dd6e4fd914bebe/build-end.log

This also fixes the build error reported by Gary Bisson on ARM
when using Linaro 2017.02 ARM gnueabihf toolchain and
also on x86 with Ubuntu 16.04.

Reported-by: Gary Bisson <gary.bis...@boundarydevices.com>
Signed-off-by: Fabio Estevam <feste...@gmail.com>
---
 drm.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drm.h b/drm.h
index c41683b..6ac7a82 100644
--- a/drm.h
+++ b/drm.h
@@ -24,6 +24,8 @@
 #ifndef _DRM_H
 #define _DRM_H
 
+#include 
+#include 
 #include 
 #include 
 
-- 
2.7.4

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

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

[Fabio Estevam]

Hi Gary,

On Mon, Mar 13, 2017 at 6:42 AM, Gary Bisson
<gary.bis...@boundarydevices.com> wrote:
> Include  header file to fix the following build
> error:
> drm-atomic.c: In function ‘get_plane_id’:
> drm-atomic.c:290:44: error: ‘DRM_MODE_OBJECT_PLANE’ undeclared (first
> use in this function)
>  drmModeObjectGetProperties(drm.fd, id, DRM_MODE_OBJECT_PLANE);
>
> This error only happens when using a toolchain with kernel headers
> < 4.7 since the DRM_MODE_OBJECT_* have been moved to uapi headers
> in 4.7 [1].
>
> This error was therefore seen with Linaro 2017.02 ARM gnueabihf
> toolchain [2].
>
> It has been tested that this patch doesn't affect users using a
> toolchain with headers >= 4.7.
>
> [1] 
> http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=8812f38141
> [2] 
> https://releases.linaro.org/components/toolchain/binaries/latest-6/arm-linux-gnueabihf/gcc-linaro-6.3.1-2017.02-x86_64_arm-linux-gnueabihf.tar.xz
>
> Signed-off-by: Gary Bisson <gary.bis...@boundarydevices.com>

I just took a look on this build issue and I think we could fix it like this:

--- a/drm.h
+++ b/drm.h
@@ -24,6 +24,8 @@
 #ifndef _DRM_H
 #define _DRM_H

+#include 
+#include 
 #include 
 #include 

This should fix your issue as well as the one I see on my x86 host PC
and also this one on sparc64:
http://autobuild.buildroot.net/results/d7e/d7e82c67e0b04b0aea990bfb19dd6e4fd914bebe/build-end.log

Could you please give it a try?

Regards,

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

[Mesa-dev] [PATCH] loader: Move non-error message to debug level

[Fabio Estevam]

Currently when running mesa on imx6 the following loader warnings
are seen:

# kmscube -D /dev/dri/card1
MESA-LOADER: device is not located on the PCI bus
MESA-LOADER: device is not located on the PCI bus
MESA-LOADER: device is not located on the PCI bus
Using display 0x1920948 with EGL version 1.4

As this is not an error message, change it to debug level in
order to have a cleaner log output.

Signed-off-by: Fabio Estevam <feste...@gmail.com>
---
 src/loader/loader.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/loader/loader.c b/src/loader/loader.c
index 3b28a0e..9b4752d 100644
--- a/src/loader/loader.c
+++ b/src/loader/loader.c
@@ -282,7 +282,7 @@ drm_get_pci_id_for_fd(int fd, int *vendor_id, int *chip_id)
  ret = 1;
   }
   else {
- log_(_LOADER_WARNING, "MESA-LOADER: device is not located on the PCI 
bus\n");
+ log_(_LOADER_DEBUG, "MESA-LOADER: device is not located on the PCI 
bus\n");
  ret = 0;
   }
   drmFreeDevice();
-- 
2.7.4

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

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

[Fabio Estevam]

Include  header file to fix the following build warning:

  CC   kmscube-drm.o
drm-atomic.c: In function 'init_drm_atomic':
drm-atomic.c:346:14: warning: implicit declaration of function 'calloc' 
[-Wimplicit-function-declaration]
  drm.plane = calloc(1, sizeof(*drm.plane));
  ^
drm-atomic.c:346:14: warning: incompatible implicit declaration of built-in 
function 'calloc'
drm-atomic.c:346:14: note: include '' or provide a declaration of 
'calloc'

Signed-off-by: Fabio Estevam <feste...@gmail.com>
---
Hi Rob,

This one is against your recent kmscube tree at:
https://cgit.freedesktop.org/mesa/kmscube/

 drm-atomic.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drm-atomic.c b/drm-atomic.c
index b4755e1..0b38c32 100644
--- a/drm-atomic.c
+++ b/drm-atomic.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
-- 
2.7.4

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

Re: [Mesa-dev] [ANNOUNCE] mesa 17.0.0

[Fabio Estevam]

On Mon, Feb 13, 2017 at 11:09 AM, Fabio Estevam <feste...@gmail.com> wrote:
> Hi Emil,
>
> On Mon, Feb 13, 2017 at 10:10 AM, Emil Velikov <emil.l.veli...@gmail.com> 
> wrote:
>> Hi all,
>>
>> Mesa 17.0.0 is now available.
>
> ftp://ftp.freedesktop.org/pub/mesa misses the 17.0.0 directory.

17.0.0 directory is available now at ftp://ftp.freedesktop.org/pub/mesa/17.0.0/

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

Re: [Mesa-dev] [ANNOUNCE] mesa 17.0.0

[Fabio Estevam]

Hi Emil,

On Mon, Feb 13, 2017 at 10:10 AM, Emil Velikov  wrote:
> Hi all,
>
> Mesa 17.0.0 is now available.

ftp://ftp.freedesktop.org/pub/mesa misses the 17.0.0 directory.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev