Hi,
I own an odroid XU3 wich runs currently with the newest mali driver (r6p0) on ubuntu 15.01 without X.
I spend the last days in trying to pass the drm buffer using gbm into the mali gpu, until now with no success.
Problem is, that I'm not able to set up a renderable surface, I tried several extensions (MESA_GBM for example) but they all fail.
Can you pls. provide me with the information if its possible or not?
If it should be possible - are there any resources / samples where to look or the key?
Thanks!
Markus
I walked now through the code of Chrome's ozone gbm platform and learned that they choose another way wich seems also not to work:
eglCreateImageKHR in with EGL_LINUX_DMA_BUF_EXT.
In my testcase I use following attributes:
};
before I call
gl.image = eglCreateImageKHR(gl.display,
EGL_NO_CONTEXT,
EGL_LINUX_DMA_BUF_EXT,
0,
attrs);
But unfortunately it is answerd with EGL_BAD_PARAMETER.
dma_fd and pith have valid values.
My question is: Is this way correct with the r6p0 fbdev driver?
Maybe only something missing?
* If <target> is EGL_LINUX_DMA_BUF_EXT and <buffer> is not NULL, the error EGL_BAD_PARAMETER is generated. * If <target> is EGL_LINUX_DMA_BUF_EXT, and the list of attributes is incomplete, EGL_BAD_PARAMETER is generated.
* If <target> is EGL_LINUX_DMA_BUF_EXT and <buffer> is not NULL, the error EGL_BAD_PARAMETER is generated.
* If <target> is EGL_LINUX_DMA_BUF_EXT, and the list of attributes is incomplete, EGL_BAD_PARAMETER is generated.
These are the possible reasons for EGL_BAD_PARAMETER.
Please make sure to change your buffer accordingly to rule out the first:
<buffer> must be NULL, cast into the type EGLClientBuffer.
As for the second, it looks like you have covered the requirements here based off of the spec. Please validate that the values are correct however:
* EGL_WIDTH & EGL_HEIGHT: The logical dimensions of the buffer in pixels* EGL_LINUX_DRM_FOURCC_EXT: The pixel format of the buffer, as specified by drm_fourcc.h and used as the pixel_format parameter of the drm_mode_fb_cmd2 ioctl.* EGL_DMA_BUF_PLANE0_FD_EXT: The dma_buf file descriptor of plane 0 of the image.* EGL_DMA_BUF_PLANE0_OFFSET_EXT: The offset from the start of the dma_buf of the first sample in plane 0, in bytes.* EGL_DMA_BUF_PLANE0_PITCH_EXT: The number of bytes between the start of subsequent rows of samples in plane 0. May have special meaning for non-linear formats.
* EGL_WIDTH & EGL_HEIGHT: The logical dimensions of the buffer in pixels
* EGL_LINUX_DRM_FOURCC_EXT: The pixel format of the buffer, as specified by drm_fourcc.h and used as the pixel_format parameter of the drm_mode_fb_cmd2 ioctl.
* EGL_DMA_BUF_PLANE0_FD_EXT: The dma_buf file descriptor of plane 0 of the image.
* EGL_DMA_BUF_PLANE0_OFFSET_EXT: The offset from the start of the dma_buf of the first sample in plane 0, in bytes.
* EGL_DMA_BUF_PLANE0_PITCH_EXT: The number of bytes between the start of subsequent rows of samples in plane 0. May have special meaning for non-linear formats.
We will try have a look on our end for any problems with this and report back if we find anything.
Similarly if you discover the solution, feel free to post it so others can benefit from this.
Kind Regards,
Michael McGeagh
Thanks for the quick response, Michael!
First let me say that I'm glad that the answer is not: "Not supported"
I came over this issue while building / testing the chromium content_shell application with the ozone gbm platform.
I already verified all the parameters passed to the function and they seem to be correct.
Chromium members told me, that the fbdev driver provided from malidevelopers might not work, I have to use the chrome-os driver (wich should have the same binary blob inside, doesn't it??)
I have a small test program, but it uses minigbm (from the chromium project) to handle the drm buffers.
I'll try to remove the minigbm dependencies this evening and send you a link to this simple program.
Thanks,
[Edit: I made a simple testcase wich uses only drm / egl now.
The example (https://github.com/mapfau/tests/blob/master/drm_image/drm_image.c) is without any cleanup code and written all in main for better readability.
On my odroid xu3 I have compiled it with: gcc -I/usr/include/libdrm/ -I/usr/include/exynos/ -O0 -g drm_image.c -ldrm -lmali -o drm_image
The example includes the steps: DRM setup / GEM buffer / DMA_Buffer retrieval and EGL initialization until the point where dhe eglImageKHR is created.
Thanks for looking over it!
Apologies if I'm not helping the actual problem, but some friendly advice -- rather than simply hammering the API with attributes it might not support and getting strange results, you could literally check to see if they're supported -- using eglQueryString(EGL_NO_DISPLAY, EGL_EXTENSIONS) or eglQueryString(display, EGL_EXTENSIONS) -- and looking at that returned string for the appropriate extension strings that would describe the features you want.
If the EGL or OpenGLES libraries don't support the extensions you want, you get really unhelpful errors from EGL (EGL_BAD_PARAMETER is one of them, but it never gives a hint as to which parameter if you pass an array!). It is always better to check to see if they exist before using them and wondering why nothing works.
Thanks for the advice, mwsealey.
As far as I understand the output, it should be supported:
EGL_NO_DISPLAY:
Using display 0x2d140 with EGL version 1.4
EGL Version "1.4 Midgard-"r6p0-02rel0""
EGL Vendor "ARM"
EGL Extensions " EGL_EXT_client_extensions EGL_EXT_platform_base EGL_KHR_client_get_all_proc_addresses"
EGL_DISPLAY retrieved form NATIVE_DISPLAY:
EGL Extensions " EGL_KHR_partial_update EGL_KHR_config_attribs EGL_KHR_image EGL_KHR_image_base EGL_KHR_fence_sync EGL_KHR_wait_sync EGL_KHR_gl_colorspace EGL_KHR_get_all_proc_addresses EGL_IMG_context_priority EGL_ARM_pixmap_multisample_discard EGL_KHR_gl_texture_2D_image EGL_KHR_gl_renderbuffer_image EGL_KHR_create_context EGL_KHR_surfaceless_context EGL_KHR_gl_texture_cubemap_image EGL_EXT_create_context_robustness EGL_KHR_cl_event2"
I'm not the EGL professional, my goal is currently simply get some applications running in an x-less environment.
So I'm looking forward for your professional statement about it.
Hi peak3d,
It doesnt look like the extension is supported based on your output.
To use eglCreateImageKHR API call, you need the extension EGL_KHR_image_base, which you have.
To use EGL_LINUX_DMA_BUF_EXT as the target in that API call, you need the extension EGL_EXT_image_dma_buf_import which I do not see in your list of supported extensions.
Values accepted for <target> are listed in Table aaa, below(fn1).(fn1) No values are defined by this extension. All functionality to create EGLImages from other types of resources, such as native pixmaps, GL textures, and VGImages, is layered in other extensions.
I hope that explains better why it is currently failing.
oh, i hoped so much that this answer wouldn't arrive during this discussion :-(
To stay constructive: Is this (beside drm / gbm) anything hardkernel can activate / implement in the compile step of the driver?
Or is this (from what I have learned) hidden inside the binary blob and we are dependend on your further work?
best regards,
B.t.w: I think we can close this issue
After discussing with the driver team, this extension is currently not available for non-X11 windowing systems. It has only been tested and available if you are using X11.
So in theory if you switch over to using X instead of fbdev, your code may work. I cannot say for certain at this point however so please let us know the results.
Thanks, Michael,
I tried this already but didn't get it working because of missing experience with DRM Master cloning.
I'll let you know if there is any progress!
Really appreciate the quick responses from your side!