GUI acceleration support

PabloPL commented 6 years ago

We can use:

g2d (there are two drivers for it, one in media directory but old. New is in drm directory, but it don't have support for our soc and also would require changes in libdrm)
powervr sgx540

PabloPL commented 5 years ago

I have a script that may integrate and work properly with the build, but I'm not sure. The issue with adding both lines is that the other one then keeps spewing errors saying that it can't find the terminal.

Not tested but in drivers/tty/serial/samsung.c there is name and dev_name.

in vendor it's set to "s3c2410_serial"
in mainline it's set to ttySAC

Maybe just rename in vendor kernel to mainline one + symlinks for compatibility with some old userspace code.

xc-racer99 commented 5 years ago

Not tested but in drivers/tty/serial/samsung.c there is name and dev_name.
* in vendor it's set to "s3c2410_serial"

* in mainline it's set to ttySAC

Yep, that's correct. The RIL blob hard-codes s3c2410_serial in it according to https://github.com/xc-racer99/android_kernel_samsung_aries/commit/b916682e7e498eba3434305f55bf28d77026746f#diff-d12fefdddd5c85f22c29eade7aeba2e3

However, now that I'm thinking about it again, it would make sense to rename it in the vendor kernel as my fork of libsamsung-ipc has been patched to support both names for mainline compatibility.

PabloPL commented 5 years ago

Another solution would be to run script which will detect which serial is present and then run getty on it http://lists.busybox.net/pipermail/busybox/2009-May/069243.html

PabloPL commented 5 years ago

@xc-racer99

s3c2410_serial2::/sbin/getty -L s3c2410_serial2 115200 vt100 Should be s3c2410_serial2::respawn:/sbin/getty -L s3c2410_serial2 115200 vt100

touchscreen is not working but pmOS boots and now i have console working! Will update my PR on gitlab

Edit 1: PR updated

PabloPL commented 5 years ago

@xc-racer99 FYI i've created new powervr2 branch here with all patches taken from YOur branch. If it'll be also working on my device, i'm going to remove my old powervr branches (since it looks like i've did break something and here are far less changes).

xc-racer99 commented 5 years ago

Alright, some progress has been made. I've found out that we need libhybris 4.4, not 7.1 (Edit: this also means a 4.4 system directory). The issue with 7.1 is that our blobs are so old that they have text relocations and other nasty stuff in them not officially supported by the 7.1 linker. That's the cause of the segfaults when running things like test_egl.

Next issue is that the older, source built pvrsrvinit init does need libhybris, but it doesn't seem to work properly. So, it can be simply re-implemented using the hybris_dl* symbols from libhybris-common, eg

#include <dlfcn.h>
#include <stdio.h>
#include <hybris/common/dlfcn.h>

int main()
{
    int (*SrvInit)(int x);
    void *handle = hybris_dlopen("/vendor/lib/libsrv_init.so", RTLD_LAZY);
    if (!handle) {
        fprintf(stderr, "failed to open libsrv_init.so\n");
        return -1;
    }

    fprintf(stdout, "opened libsrv_init.so\n");

    SrvInit = hybris_dlsym(handle, "SrvInit");
    if (!SrvInit) {
        fprintf(stderr, "failed to find SrvInit symbol\n");
        return -1;
    }

    fprintf(stdout, "found SrvInit symbol\n");

    SrvInit(1);

    hybris_dlclose(handle);

    return 0;
}

and compiled with gcc -o pvrsrvinit pvrsrvinit.c -lhybris-common

Once that is run, the the test_egl, test_glesv2 both work on vendor kernel on pmOS, but test_hwcomposer doesn't work (something is setting up the FIMC properly, so I'm implementing a hwcomposer that doesn't use the FIMC considering it's api is different to that of mainline's and was only used for hw video decoding anyways...).

On mainline kernel, there are still some issues with the powervr-2 branch, I've gotten to

[   83.720170] S3C_InstallVsyncISR: Couldn't obtain IRQ -75
[   83.721876] PVR_K:(Error): DoMapToUser: Error - vm_insert_mixed failed (256) [577, drivers/gpu/drm/powervr/mmap.c]

-75 is -EOVERFLOW so I'll need to trace this backwards and see what's happening...

Edit: Oh, duh. Would help if I specified the IRQ in the dts...

Edit 2: Ok, IRQ issue fixed by specifying the FIMD vsync irq as the second IRQ, but still have PVR_K:(Error): DoMapToUser: Error - vm_insert_mixed failed (256) [577, drivers/gpu/drm/powervr/mmap.c]

Edit 3: Looks like the 256 part is from vmf_insert_mixed_failed returning VM_FAULT_NOPAGE - so we have some issue with our mempool area if I'm understanding things correctly

PabloPL commented 5 years ago

FYI https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/commits/n900/v5.1-patch

xc-racer99 commented 5 years ago

While not related to G2D nor PowerVR, the FIMC can be used for GUI acceleration. I've added support for it in https://github.com/PabloPL/linux/tree/for-upstream/drm-fimc and tested with the patches from https://github.com/tobiasjakobi/libdrm/tree/ippv2 rebased on v2.4.97 which I've uploaded to https://github.com/xc-racer99/libdrm

@PabloPL I think these can probably go upstream, including the FIMC DTS fix.

xc-racer99 commented 4 years ago

I have the hybris test_glesv2 working and rendering to the screen on PostmarketOS!!!

Branch created at https://github.com/xc-racer99/linux/tree/all-devices-pvr-3

I think the previous issue had been that we weren't using the correct memory location for the framebuffer and were hitting some random reserved area which was hanging.

I'll work on instructions/updating my pmOS repos for more info.

xc-racer99 commented 4 years ago

Ugh, it appears that pmOS master branch isn't compiling at the moment due to some Alpine toolchain updates.

I've pushed a branch to https://gitlab.com/xc-racer99/pmaports/tree/combined-sgs that should theoretically work for both i9000 and SGH-T959P. I can't build it so I can't test it :)

We do need to properly figure out how to handle the multiple modems bit...

xc-racer99 commented 4 years ago

Hmm, some bad news about the drivers. For wlroots, you need the extension eglGetPlatformDisplayEXT (see https://github.com/swaywm/sway/issues/2766#issuecomment-427594025) but we don't support it so we get errors such as those in https://gist.github.com/xc-racer99/8c00bb80d6eaf8b9a7a34854e8497b5b

We might be able to fake it by falling back to eglGetDisplay (eg like XBMC says they've been doing in https://github.com/xbmc/xbmc/pull/13746#discussion_r179914174 or the example given in https://github.com/Cloudef/wlc/pull/233 could be useful), but I'm not sure yet...

mirh commented 4 years ago

Sway was born around desktop graphics, so it's just natural that it's not accounting for stuff outside mesa. But even the bloody SGX, is not a fixed function gpu.. And it supports GLES 2.0. It's more similar to https://github.com/swaywm/wlroots/issues/1812 and https://github.com/swaywm/wlroots/pull/1047 if any. You just need to find the right workarounds imo.

xc-racer99 commented 4 years ago

Sway was born around desktop graphics, so it's just natural that it's not accounting for stuff outside mesa. But even the bloody SGX, is not a fixed function gpu.. And it supports GLES 2.0. It's more similar to swaywm/wlroots#1812 and swaywm/wlroots#1047 if any. You just need to find the right workarounds imo.

Yep, but Android's EGL shim only supports EGL 1.4, while wlroots (which the phoc compositor uses) supposedly requires 1.5 due to using eglGetPlatformDisplayEXT and eglCreatePlatformWindowSurfaceEXT (see https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_platform_base.txt for more info on them). I seem to have gotten around this by a patch (https://gist.githubusercontent.com/xc-racer99/8c00bb80d6eaf8b9a7a34854e8497b5b/raw/99d76e3006676d47394d5abedbebcc358a4ed4b8/libhybris.diff) to the libhybris source code as these two are similar to eglGetDisplay and eglCreateWindowSurface. Now I'm getting no valid configs :) (see https://gist.githubusercontent.com/xc-racer99/8c00bb80d6eaf8b9a7a34854e8497b5b/raw/99d76e3006676d47394d5abedbebcc358a4ed4b8/.xsession-errors-2)

Of course, if we had the hwcomposer working it might be different as we could use that backend for things such as Plasma Mobile; however, it doesn't appear to work properly with the mainline kernel as it relies upon a bunch of interfaces that are specific to the vendor kernel.

mirh commented 4 years ago

Uh, well, cool if you got 1.4 to be shimmed to 1.5 (not sure about other major differences.. and it's not like their compositor would blow up if they were to support one lower version). This is also of relevance perhaps https://github.com/swaywm/wlroots/issues/1679

Anyway, the question is.. Why are you getting mesa errors if you aren't using it? :smile:

p.s. I thought they had got hwcomposer to work? https://github.com/libhybris/libhybris/issues/368

xc-racer99 commented 4 years ago

p.s. I thought they had got hwcomposer to work? libhybris/libhybris#368

Yeah, but our hwcomposer relies on some FIMC stuff whose interface has entirely changed in the mainline kernel. I don't have a good way of testing a mainline version, plus it shouldn't be necessary (I hope!).

xc-racer99 commented 4 years ago

Ugh, looks like wlroots depends on GBM (https://drewdevault.com/2019/02/10/Wayland-misconceptions-debunked.html - see the "Wayland isn’t suitable for embedded devices!" section) which we obviously don't have... Guess that means a new backend for wlroots will have to be written.

Anyway, the question is.. Why are you getting mesa errors if you aren't using it? smile

I think these errors are coming from libdrm - the pmOS version of libdrm is built without exynos support IIRC.

mirh commented 4 years ago

Something like this? https://github.com/NotKit/wlroots/tree/hwcomposer ( ͡° ͜ʖ ͡°) (for as much as some criticality)

I think these errors are coming from libdrm - the pmOS version of libdrm is built without exynos support IIRC.

I mean, yes, but why would your graphics driver be mesa at all? There's nothing for pvr there.

xc-racer99 commented 4 years ago

Something like this? https://github.com/NotKit/wlroots/tree/hwcomposer ( ͡° ͜ʖ ͡°)

Oh, cool, didn't realize this was a thing. Some things in there I can look at. Unfortunately, it involves the hwcomposer which doesn't work :) (I have tried, but there's something in it that doesn't work properly).

I mean, yes, but why would your graphics driver be mesa at all? There's nothing for pvr there.

Well, it depends :) PVR itself isn't using mesa, but if we're using DRM then we probably actually need to display via the exynos DRM, while rendering with powervr (if I understand things correctly). The errors showing up are because wlroots is trying to use the exynos DRM device (which doesn't work properly with the lihbyris-based graphics). However, these errors are "normal" in that they show up even when using a mesa software renderer (eg softpipe, llvmpipe, etc)

xc-racer99 commented 4 years ago

Ok, I'm trying an fbdev backend to wlroots but have discovered a few bugs with the proprietary GLESv2 implementation:

calling eglMakeCurrent() with a valid context but EGL_NO_SURFACE for the src/dest results in an EGL_BAD_MATCH error
calling gl*() function before running eglMakeCurrent (with a valid context and surface) results in returning null. This is an issue because we can't parse the extensions available until after we've created a surface... So the wlroots source code is getting extremely messing trying to create the surface first.

Maybe I'll run into even more bugs :)

mirh commented 4 years ago

Perhaps you need EGL_NO_CONTEXT? Android checks stuff this way.

xc-racer99 commented 4 years ago

Perhaps you need EGL_NO_CONTEXT?

Interesting, didn't realize that this was actually spec-compliant.

Anyways, I did try with EGL_NO_CONTEXT, but while that call does succeed, none of the gl*() functions work until eglMakeCurrent is called with a valid context and surface. This means no checking of extensions and no rendering/shader compiling until that has been done.

mirh commented 4 years ago

https://community.arm.com/developer/tools-software/graphics/f/discussions/7138/getting-egl_bad_display-while-firing-eglquerystring-from-application This looks very helpful.

xc-racer99 commented 4 years ago

Well, I'm giving up on wlroots - it appears to use GL_EXT_unpack_subimage based on the code at https://github.com/swaywm/wlroots/blob/6d3f3b930077d3c1b39106481fe21ee25b9a6a0e/render/gles2/texture.c#L71 which is where my fork stops working as expected - and that extension doesn't appear in our list of supported extensions.

mirh commented 4 years ago

I mean.. There is a TODO there for a reason I guess. Not sure how much of a priority it could be, given https://github.com/swaywm/wlroots/pull/23#issue-127403055, but still. As a matter of fact, weston has a fallback.

xc-racer99 commented 4 years ago

Well, I got tired of fighting with the SGX540, so I moved to the G2D again.

I've added G2D v3.0 support to the DRM driver at https://github.com/xc-racer99/linux/tree/s5pv210-g2d and to libdrm at https://github.com/xc-racer99/libdrm/tree/s5pv210-g2d - note that all the tests appear to work properly.

There appears to be a couple of X11 drivers using the G2D driver - notably https://github.com/tobiasjakobi/xf86-video-armsoc/commits/g2d (although this uses a heavily patched libdrm and kernel driver) and https://github.com/OtherCrashOverride/xf86-video-armsoc with some more info on it at https://forum.odroid.com/viewtopic.php?f=146&t=26248

I haven't tested either of the above and don't know how well they work.

mirh commented 4 years ago

Mhh cool. @paulkocialkowski did your 2D helper effort ever go anywhere by any chance? 🤔

xc-racer99 commented 4 years ago

I've added G2D v3.0 support to the DRM driver at https://github.com/xc-racer99/linux/tree/s5pv210-g2d and to libdrm at https://github.com/xc-racer99/libdrm/tree/s5pv210-g2d - note that all the tests appear to work properly.

There appears to be a couple of X11 drivers using the G2D driver - notably https://github.com/tobiasjakobi/xf86-video-armsoc/commits/g2d (although this uses a heavily patched libdrm and kernel driver) and https://github.com/OtherCrashOverride/xf86-video-armsoc with some more info on it at https://forum.odroid.com/viewtopic.php?f=146&t=26248

Hmm, I've tested the G2D. Discovered it needs more work, as the userptr method is in fact quite broken and will never work on s5pv210 (it depends on the IOMMU which we don't have). A call to is_drm_iommu_supported needs to be added and fail whenever there is a userptr passed.

xc-racer99 commented 4 years ago

Ok, I've added patches for xf86-video-armsoc for support for the G2D at https://gist.github.com/xc-racer99/b048eec95bdf3115cb0c3e2c266563f2 - but I highly recommend not using it. It appears that armsoc has a high overhead and it's much slower than just using raw fbdev. When enabling the g2d backend it seems to be slightly better (but still worse than raw fbdev), but maybe that's just wishful thinking.

kwizart commented 4 years ago

Is it possible to use the modesetting driver instead ? or is this driver not relevant ? (or eventually fork the default modesetting driver to add optimized code path).

xc-racer99 commented 4 years ago

Is it possible to use the modesetting driver instead ? or is this driver not relevant ? (or eventually fork the default modesetting driver to add optimized code path).

Well, thanks for bringing this up :) I'll have to try it, but it looks like it should work (I hadn't tested it as I thought it required OpenGL and thus wouldn't work, but that's just for the Glamor 2D acceleration part). That does mean it will be entirely non-accelerated, but it might be better than the fbdev driver.

Looking at it, I'm not sure entirely how the glamor bit is integrated, but it might be possible to replace that with a g2d backend.

xc-racer99 commented 4 years ago

Alright, I've managed to load the DDK 1.17 libraries from the OMAP4 (eg, run pvrsrvctl --no-module --start), but there is no rendering. Probably the libraries are looking for something omap specific, although I believe they use dumb buffers which we also support.

Branch at https://github.com/xc-racer99/linux/tree/v5.5.1-all-devices-openpvr strace trying to run the OGLES2Water at https://gist.github.com/xc-racer99/854aac152cfdc1849cc553e730d22407 Note that the DDK 1.17 drivers from https://git.ti.com/cgit/graphics/omap5-sgx-ddk-um-linux/log/?h=ti-img-sgx/zeus/1.17.4948957 require GLIBC 2.29 which requires Debian bullseye.

@tmlind I notice you've worked on the Droid4 which also has an SGX 540-120. Have you gotten the DDK 1.17 libraries working there? When running anything (eg kmscube, the PVR demos), I get ../src/egl/main/eglconfig.h:160: _eglSetConfigKey: Assertionoffset >= 0' failed.` but I highly suspect this is due to the fact that I'm running them on a different platform :) I know that the DDK 1.8 and 1.9 Android libraries were mostly compatible (only issue had to do with gralloc and buffer allocations for the camera).

mirh commented 4 years ago

Quick google search for that error: https://bugs.freedesktop.org/show_bug.cgi?id=38622 https://gitlab.freedesktop.org/mesa/mesa/issues/1856

xc-racer99 commented 4 years ago

Quick google search for that error: https://bugs.freedesktop.org/show_bug.cgi?id=38622 https://gitlab.freedesktop.org/mesa/mesa/issues/1856

Ah, looks like the second one is the issue - the error comes from loading kms_swrast_dri.so (from the distro mesa) after the pvr_dri.so is loaded (and presumably fails to initialize).

Means it's probably a red herring, unfortunately :( I suppose I can enable all of the pvr kernel debugging and see what the IOCTLs are returning.

xc-racer99 commented 4 years ago

jon@jon-hp-6570b:~$ sudo kmscube 
[sudo] password for jon: 
Using display 0x69d9b0 with EGL version 1.5
===================================
EGL information:
  version: "1.5"
  vendor: "Mesa Project"
  client extensions: "EGL_EXT_client_extensions EGL_EXT_device_base EGL_EXT_device_enumeration EGL_EXT_device_query EGL_EXT_platform_base EGL_KHR_client_get_all_proc_addresses EGL_KHR_debug EGL_EXT_platform_wayland EGL_MESA_platform_gbm EGL_MESA_platform_surfaceless"
  display extensions: "EGL_EXT_buffer_age EGL_EXT_create_context_robustness EGL_EXT_image_dma_buf_import EGL_IMG_cl_image EGL_KHR_config_attribs EGL_KHR_create_context EGL_KHR_fence_sync EGL_KHR_get_all_proc_addresses EGL_KHR_gl_renderbuffer_image EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap EGL_KHR_no_config_context EGL_KHR_reusable_sync EGL_KHR_surfaceless_context EGL_EXT_pixel_format_float EGL_KHR_wait_sync EGL_MESA_configless_context EGL_MESA_drm_image EGL_WL_bind_wayland_display "
===================================
OpenGL ES 2.x information:
  version: "OpenGL ES 2.0 build 1.17@4948957"
  shading language version: "OpenGL ES GLSL ES 1.00 build 1.17@4948957"
  vendor: "Imagination Technologies"
  renderer: "PowerVR SGX 540"
  extensions: "GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth24 GL_OES_depth_texture GL_OES_egl_sync GL_OES_element_index_uint GL_OES_EGL_image GL_OES_EGL_image_external GL_OES_fbo_render_mipmap GL_OES_fragment_precision_high GL_OES_get_program_binary GL_OES_mapbuffer GL_OES_packed_depth_stencil GL_OES_required_internalformat GL_OES_rgb8_rgba8 GL_OES_standard_derivatives GL_OES_surfaceless_context GL_OES_texture_float GL_OES_texture_half_float GL_OES_vertex_array_object GL_OES_vertex_half_float GL_EXT_blend_minmax GL_EXT_discard_framebuffer GL_EXT_multi_draw_arrays GL_EXT_multisampled_render_to_texture GL_EXT_shader_texture_lod GL_EXT_texture_format_BGRA8888 GL_EXT_texture_rg GL_IMG_multisampled_render_to_texture GL_IMG_program_binary GL_IMG_read_format GL_IMG_shader_binary GL_IMG_texture_compression_pvrtc GL_IMG_texture_format_BGRA8888 GL_IMG_texture_npot GL_IMG_uniform_buffer_object GL_KHR_debug GL_EXT_texture_storage"
===================================
Using modifier ffffffffffffff
Using modifier ffffffffffffff

And presto! You have a rotating multi-colored cube that's accelerated.

To replicate my results, create a booting debian bullseye install. Install the attached .deb file which will download the SGX userspace libraries and install them. Then you need to patch them with the command printf "exynos\x00" > exynos && dd if=exynos of=/lib/libsrv_um.so.1.17.4948957 obs=1 seek=110644 conv=notrunc && dd if=exynos of=/lib/libdbm.so.1.17.4948957 obs=1 seek=5960 conv=notrunc && rm exynos (basically replacing the string omapdrm with the string exynos, as we're using exynos DRM).

Then you need to run pvrsrvctl --no-module --start, then you can run kmscube (installed from the debian repos).

The kernel is from https://github.com/xc-racer99/linux/tree/v5.5.1-all-devices-openpvr, in addition to the PVR module, it needs a small patch to the exynos drm driver to allow DRM_FORMAT_RESERVED (0xffffffffffffff) as an fb modifier (see https://github.com/xc-racer99/linux/commit/b7a73201a821c216dac8846b0898cc305999fb45).

Edit: Forget to attach the deb, here it is in a zip file: pvrsgx-1.17_0.20200227150751_exynos.deb.zip

It is based on the one for letux from @goldelico but with support for s5pv210 added to the postinst script as well as changed depends so no actual mesa packages are installed.

Update: If cloning revision 551665bf9c321bc3e7721416e6ebbc9f65c18155 of https://git.ti.com/cgit/graphics/omap5-sgx-ddk-um-linux, use the command printf "exynos\x00" > exynos && dd if=exynos of=/lib/libsrv_um.so.1.17.4948957 obs=1 seek=110644 conv=notrunc && dd if=exynos of=/lib/libdbm.so.1.17.4948957 obs=1 seek=5960 conv=notrunc && rm exynos

kwizart commented 3 years ago

FYI, I've managed to install the pvr driver on fedora (31) implementing the pvrsgx debian package manually.

weston logs: https://paste.centos.org/view/92b78309 kernel logs: https://paste.centos.org/view/a2194ca1

but

[kwizart@galaxys ~]$ kmstest 
trying to open device 'i915'...failed
trying to open device 'amdgpu'...failed
trying to open device 'radeon'...failed
trying to open device 'nouveau'...failed
trying to open device 'vmwgfx'...failed
trying to open device 'omapdrm'...failed
trying to open device 'exynos'...done
main: All ok!
[kwizart@galaxys ~]$ kmscube 
Using display 0x7508b0 with EGL version 1.5
===================================
EGL information:
  version: "1.5"
  vendor: "Mesa Project"
  client extensions: "EGL_EXT_client_extensions EGL_EXT_device_base EGL_EXT_device_enumeration EGL_EXT_device_query EGL_EXT_platform_base EGL_KHR_client_get_all_proc_addresses EGL_KHR_debug EGL_EXT_platform_wayland EGL_MESA_platform_gbm EGL_MESA_platform_surfaceless"
  display extensions: "EGL_EXT_buffer_age EGL_EXT_create_context_robustness EGL_EXT_image_dma_buf_import EGL_IMG_cl_image EGL_KHR_config_attribs EGL_KHR_create_context EGL_KHR_fence_sync EGL_KHR_get_all_proc_addresses EGL_KHR_gl_renderbuffer_image EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap EGL_KHR_no_config_context EGL_KHR_reusable_sync EGL_KHR_surfaceless_context EGL_EXT_pixel_format_float EGL_KHR_wait_sync EGL_MESA_configless_context EGL_MESA_drm_image EGL_WL_bind_wayland_display "
===================================
OpenGL ES 2.x information:
  version: "OpenGL ES 2.0 build 1.17@4948957"
  shading language version: "OpenGL ES GLSL ES 1.00 build 1.17@4948957"
  vendor: "Imagination Technologies"
  renderer: "PowerVR SGX 540"
  extensions: "GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth24 GL_OES_depth_texture GL_OES_egl_sync GL_OES_element_index_uint GL_OES_EGL_image GL_OES_EGL_image_external GL_OES_fbo_render_mipmap GL_OES_fragment_precision_high GL_OES_get_program_binary GL_OES_mapbuffer GL_OES_packed_depth_stencil GL_OES_required_internalformat GL_OES_rgb8_rgba8 GL_OES_standard_derivatives GL_OES_surfaceless_context GL_OES_texture_float GL_OES_texture_half_float GL_OES_vertex_array_object GL_OES_vertex_half_float GL_EXT_blend_minmax GL_EXT_discard_framebuffer GL_EXT_multi_draw_arrays GL_EXT_multisampled_render_to_texture GL_EXT_shader_texture_lod GL_EXT_texture_format_BGRA8888 GL_EXT_texture_rg GL_IMG_multisampled_render_to_texture GL_IMG_program_binary GL_IMG_read_format GL_IMG_shader_binary GL_IMG_texture_compression_pvrtc GL_IMG_texture_format_BGRA8888 GL_IMG_texture_npot GL_IMG_uniform_buffer_object GL_KHR_debug GL_EXT_texture_storage"
===================================
Using modifier ffffffffffffff
failed to set mode: Permission denied

strace kmscube shows: ...

write(1, "Using modifier ffffffffffffff\n", 30Using modifier ffffffffffffff
) = 30
ioctl(3, DRM_IOCTL_MODE_ADDFB2, 0xbe9ed1b0) = 0
ioctl(3, DRM_IOCTL_MODE_SETCRTC, 0xbe9ed280) = -1 EACCES (Permission denied)
write(1, "failed to set mode: Permission d"..., 38failed to set mode: Permission denied
) = 38
exit_group(-13)

I've switch perms for /dev/dri/card* as a+rw, but it changes nothings. any idea where to search ? This is on a 5.9.2 kernel with your patches rebased on. (specially there is the framebuffer patch for exynos reserved format modifier).

kwizart commented 3 years ago

FYI, I've also run the previous command with sudo, but actually seems like I forgot that kmscube didn't need a wayland compositor. Now running remotely from a console...

I've tried several time to run the command and got various SGX errors, but once a cube appeared and about 2 frames was rendered (hardly accelerated).

xc-racer99 commented 3 years ago

You're required to have DRM master permissions to be able to set the mode. So if you have something else running with DRM master permissions, you won't be able to run a bunch of stuff. Remotely from a console with no GUI session running is the way to go.

Finally, you need to make sure that you've initialized pvr. To do this, run pvrsrvctl --no-module --start and then you can finally run kmscube. Are you sure that you don't have two copies of the opengl es libraries - one of which is being used and one without?

To install the libraries, you can go directly from the ti gi, clone https://git.ti.com/cgit/graphics/omap5-sgx-ddk-um-linux and checkout 551665bf9c321bc3e7721416e6ebbc9f65c18155 before and installing it by running make TARGET_PRODUCT=ti443x and then patching it by running the command printf "exynos\x00" > exynos && dd if=exynos of=/lib/libsrv_um.so.1.17.4948957 obs=1 seek=110644 conv=notrunc && dd if=exynos of=/lib/libdbm.so.1.17.4948957 obs=1 seek=5960 conv=notrunc && rm exynos

kwizart commented 3 years ago

I think I have all theses steps done for the driver integration, what I suspicious about is more about:

Any missing kernel CONFIG option to validate that the sgx driver can communicate with exynos. config-i9000.txt
Have libgbm (and others) that are patched and provided pre-built from the omap git and rebase the patch on top of the newer versions that might be provided by Fedora...

kwizart commented 3 years ago

Seem I've made some progress, I've switched off CONFIG_VIDEO_SAMSUNG_S5P_G2D so I can set CONFIG_DRM_EXYNOS_G2D=y (as they are conflicting), I've also verified that my "pvr.service " (replacement for pvr.rc) return no error (I have to enable it during boot as later activation fails for any reason).

Also the pvr kernel module isn't loaded before exynos_drm as it might have the /dev/dri/card0 number changed.

I've also reverted to use "upstream" libdrm over your fork (with ippv2 patches)...But I don't think this has changed anything. Maybe I should still pick the s5pv210-g2d patches ?

Now with sudo kmscube I have a black screen replacing my console output. but no frame on screen appearing... When closing I have my console back.

xc-racer99 commented 3 years ago

Odd. All of the changes to ippv2/g2d/other exynos bits aren't necessary but also shouldn't harm. The only change required for things to work right is https://github.com/xc-racer99/linux/commit/b7a73201a821c216dac8846b0898cc305999fb45

No changes to userspace libdrm are required, upstream and/or my fork should both work. Your defconfig looks good, use the prebuilt libgbm from the ti git, don't try building it from source, I think TI/IMG has changed their patches from the last open-source version they had.

Does /dev/dri/card1 exist? Is the PVR module loaded (check with lsmod)? If you manually run pvrsrvctl, does anything appear in dmesg. Can you post the output of your dmesg | grep -i pvr

kwizart commented 3 years ago

I've forwarded the issue to https://github.com/PabloPL/linux/issues/43 to track.

As this bug is concerned, I wonder if it's possible to run the pvr driver under weston or even phosh ? (weston leads to a black screen with me, but maybe it's because of my previous issue).

I've also used the modesetting under Xorg, but I had to disable glamor as this relies on libGL support. This was un-accelerated (by sgx at least) of course.

Tried to use gl4es, but no success (and I doubt the pvr driver will work under Xorg context)...

xc-racer99 commented 3 years ago

As this bug is concerned, I wonder if it's possible to run the pvr driver under weston or even phosh ? (weston leads to a black screen with me, but maybe it's because of my previous issue).

There seems to be a bug with using the DRM backend with weston. If you force the FBDEV backend, then everything works and you have 3d acceleration for clients.

For phosh, we're missing an extension (GL_EXT_unpack_subimage) but this can be worked around. I think there's something wrong as I only ever get a black screen. Maybe the renderer v6 in wlroots would fix this. I have gotten the wlroots demos working. I seem to have discard my patches for wlroots though :(

I've also used the modesetting under Xorg, but I had to disable glamor as this relies on libGL support. This was un-accelerated (by sgx at least) of course.

Interesting, it should with opengl es (eg there's https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/401). Haven't looked into glamor that much, but maybe just needs to be built without the libgl backend.

Tried to use gl4es, but no success (and I doubt the pvr driver will work under Xorg context)...

gl4es is missing some extensions to be able to run a full desktop environment, sadly

kwizart commented 3 years ago

There seems to be a bug with using the DRM backend with weston. If you force the FBDEV backend, then everything works and you have 3d acceleration for clients.

Looks like I've managed to have a display using the fbdev backend for weston. But then the device hard-lockup when attempting to use anything related to pvrsgx under wayland. (using WAYLAND_DISPLAY=wayland0). That's with either eglinfo, kmscube or glmark2-es2-drm). I haven't had experienced such system wide freeze previously when running from a console...

mirh commented 2 years ago

I don't really remember how and why I got here, nor where we were left Anyhow, you may be interested to know that fbdev drivers are now hip again https://github.com/frno7/linux/issues/30#issuecomment-1024503541

PabloPL / linux

GUI acceleration support #18