Re: [Mesa-dev] [ANNOUNCE] mesa 17.0.0
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
Re: [Mesa-dev] [ANNOUNCE] mesa 17.0.0
On Mon, Feb 13, 2017 at 11:09 AM, Fabio Estevam wrote: > 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. 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
[Mesa-dev] [PATCH] etnaviv: etnaviv_fence: Simplify the return code logic
The return code can be simplified by using the logical not operator. Signed-off-by: Fabio Estevam --- 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
[Mesa-dev] [PATCH] freedreno: freedreno_fence: Simplify the return code logic
The return code can be simplified by using the logical not operator. Signed-off-by: Fabio Estevam --- 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
Re: [Mesa-dev] [PATCH] etnaviv: etnaviv_fence: Simplify the return code logic
On Sat, Apr 22, 2017 at 12:44 PM, Christian Gmeiner wrote: > 2017-04-18 0:36 GMT+02:00 Fabio Estevam : >> The return code can be simplified by using the logical not operator. >> >> Signed-off-by: Fabio Estevam > > Reviewed-by: Christian Gmeiner > > 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] drm-atomic: Include header file
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 --- 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
[Mesa-dev] [PATCH] loader: Move non-error message to debug level
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 --- 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(&device); -- 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
Hi Gary, On Mon, Mar 13, 2017 at 6:42 AM, Gary Bisson 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 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 1/2] drm.h: Include libdrm headers
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 Signed-off-by: Fabio Estevam --- 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
[Mesa-dev] [PATCH 2/2] cube-tex: Include
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 > --- 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
Re: [Mesa-dev] [PATCH 1/2] drm.h: Include libdrm headers
Hi Ilia, On Mon, Mar 13, 2017 at 11:03 AM, Ilia Mirkin 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
Re: [Mesa-dev] [PATCH 1/2] drm.h: Include libdrm headers
On Mon, Mar 13, 2017 at 11:07 AM, Ilia Mirkin wrote: > On Mon, Mar 13, 2017 at 10:04 AM, Fabio Estevam wrote: >> Hi Ilia, >> >> On Mon, Mar 13, 2017 at 11:03 AM, Ilia Mirkin 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
[Mesa-dev] [PATCH kmscube v2 1/2] drm.h: Include libdrm headers
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 Signed-off-by: Fabio Estevam --- 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
[Mesa-dev] [PATCH kmscube v2 2/2] cube-tex: Include
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 > --- 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 v3 1/2] drm.h: Include
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 Signed-off-by: Fabio Estevam --- 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 v3 2/2] cube-tex: Include
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 --- 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
Re: [Mesa-dev] [PATCH kmscube v3 2/2] cube-tex: Include
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] mx6q: Cannot run Cinematic demo correctly
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] mx6q: Cannot run Cinematic demo correctly
Hi Otavio, On Tue, Mar 14, 2017 at 1:58 PM, Otavio Salvador wrote: > On Tue, Mar 14, 2017 at 12:31 PM, Fabio Estevam 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 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: Signed-off-by: Wladimir J. van der Laan Acked-by: Christian Gmeiner 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
Re: [Mesa-dev] mx6q: Cannot run Cinematic demo correctly
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] [PATCH kmscube 7/7] drm-legacy.c: suppress 'unused parameter warnings
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
[Mesa-dev] [PATCH kmscube] cube-tex: Handle SMOOTH switch case
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 --- 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
[Mesa-dev] [PATCH kmscube] kmscube: Remove unneeded brackets
There is no need to use brackets for single line if statements, so simply remove them. Signed-off-by: Fabio Estevam --- 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
Re: [Mesa-dev] [PATCH kmscube] kmscube: Remove unneeded brackets
Hi Emil, On Sun, Mar 19, 2017 at 7:57 AM, Emil Velikov wrote: > On 18 March 2017 at 21:47, Fabio Estevam wrote: >> There is no need to use brackets for single line if statements, >> so simply remove them. >> >> Signed-off-by: Fabio Estevam > 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] cube-tex: Do not initialize counter inside 'for' loop
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 --- 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, &stride, &map_data); - for (uint32_t i = 0; i < texh; i++) { + for (i = 0; i < texh; i++) { memcpy(&map[stride * i], &src[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, &stride, &map_data); - for (uint32_t i = 0; i < texh; i++) { + for (i = 0; i < texh; i++) { memcpy(&map[stride * i], &src[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, &stride, &map_data); - for (uint32_t i = 0; i < texh/2; i++) { + for (i = 0; i < texh/2; i++) { memcpy(&map[stride * i], &src[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 v2 kmscube] cube-tex: Do not declare counter inside 'for' loop
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 --- 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, &stride, &map_data); - for (uint32_t i = 0; i < texh; i++) { + for (i = 0; i < texh; i++) { memcpy(&map[stride * i], &src[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, &stride, &map_data); - for (uint32_t i = 0; i < texh; i++) { + for (i = 0; i < texh; i++) { memcpy(&map[stride * i], &src[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, &stride, &map_data); - for (uint32_t i = 0; i < texh/2; i++) { + for (i = 0; i < texh/2; i++) { memcpy(&map[stride * i], &src[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] drm-legacy: Include
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(&fds); ^ drm-legacy.c:56:2: warning: implicit declaration of function 'FD_SET' [-Wimplicit-function-declaration] FD_SET(0, &fds); ^ drm-legacy.c:94:4: warning: implicit declaration of function 'select' [-Wimplicit-function-declaration] ret = select(drm.fd + 1, &fds, NULL, NULL, NULL); ^ drm-legacy.c:101:4: warning: implicit declaration of function 'FD_ISSET' [-Wimplicit-function-declaration] } else if (FD_ISSET(0, &fds)) { ^ Signed-off-by: Fabio Estevam --- 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
Re: [Mesa-dev] [PATCH v2 kmscube] cube-tex: Do not declare counter inside 'for' loop
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] Makefile.am: Add -std=c99 to CFLAGS
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 --- 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 kmscube 3/3] meson build support (v2)
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
Re: [Mesa-dev] [PATCH kmscube 3/3] meson build support (v2)
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 0/6] Shooting some piglits
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
[Mesa-dev] glmark2 segfault on imx6
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] glmark2 segfault on imx6
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
Re: [Mesa-dev] glmark2 segfault on imx6
Hi Lucas, On Tue, Jun 13, 2017 at 7:20 PM, Fabio Estevam 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+0xc/0xa4 [ 288.333620] LR is
Re: [Mesa-dev] glmark2 segfault on imx6
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
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
[Mesa-dev] glmark2 terrain errors on imx6q
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 terrain errors on imx6q
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
Re: [Mesa-dev] [PATCH 2/2] etnaviv: blt: s/TRUE/true && s/FALSE/false
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
[Mesa-dev] [PATCH kmscube] meson.build: Do not set c_std
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
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
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] [PATCH kmscube] texturator: Only define png variable when libpng is present
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] texturator: Use !! for boolean assignment
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
Re: [Mesa-dev] [PATCH kmscube] meson.build: Do not set c_std
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
Re: [Mesa-dev] [PATCH kmscube] meson.build: Do not set c_std
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
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] texturator: Use !! for boolean assignment
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
[Mesa-dev] Etnaviv: eglCreateWindowSurface fails with glmark2
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] Etnaviv: eglCreateWindowSurface fails with glmark2
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
Re: [Mesa-dev] Etnaviv: eglCreateWindowSurface fails with glmark2
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
[PATCH kmscube] cube-gears: Change header file to
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