ChanServ changed the topic of #etnaviv to: #etnaviv - the home of the reverse-engineered Vivante GPU driver - Logs https://oftc.irclog.whitequark.org/etnaviv
JohnnyonFlame has quit [Read error: Connection reset by peer]
lynxeye has joined #etnaviv
agx_ has quit []
agx has joined #etnaviv
ad__ has joined #etnaviv
<ad__> hi all, i was trying to use drm in kernel 5.4 imx, from menuconfig dependecies, seems the direction is to use etnaviv (with drm) and not gpu-viv way. Is this assumption correct ?
<ad__> if yocto side applies gpu-viv stuff. drm seems to get disabled
<lynxeye> ad__: gpu-viv is not a drm driver and wil lonly work with the proprietary userspace. If you want upstream open-source drivers, don't use gpu-viv.
<ad__> lynxeye, gpu-viv is buildable with drm support, and was used that way in some 4.9 kernel
<ad__> but i ask since etnaviv way seems easier for 5.4
<austriancoder> ad__: that was long time ago.. etnaviv is in mesa now and there is no gpu-viv support (and never will be)
<ad__> austriancoder, well, i am forced to work now on such _imx-x-x-x powered kernels that still includes drivers/mxc/gpu-viv creating quite some caos on menuconfig options
<ad__> this is why i came for help here :) to find a proper way to use drm in kernel 5.4 for imx6
<ad__> in such _imx kernel 5.4 you have the magic double ipu_v3 option ...
<austriancoder> ad__: sad that mainline kernel does not work for your use-case
<ad__> selecting etnaviv on such kernel should work. I just need to get a final "ok" from customer, since i am working on a migration from 4.9
<austriancoder> ad__: it could work.. yes..
<cphealy> ad__: if you are working on migration from 4.9 kernel to a different kernel, I would suggest upstream LTS kernel which has very good NXP i.MX6 support. Upstream LTS kernel for i.MX6 has full graphics and video support.
<ad__> cphealy, thanks
pcercuei has joined #etnaviv
ecrn has joined #etnaviv
<ecrn> hi, sorry for repasting my question which I already posted on the freenode channel, but it looks like the current channel is the right one
<ecrn> is there a support for GC320 2D blit/composition acceleration using the open source vivante driver stack?
<ecrn> I'm using imx6 SoC, which has both 3D gpu (GC880) and a simple 2D GPU (GC320)
<ecrn> In the closed-source driver there was something like "g2d" API
<ecrn> on the etnaviv wiki there is a mention of "gcx" which is supposed to be open implementation of that
<ecrn> but it seems that it is stale, and I'm wondering if there is a more adequate way now
<austriancoder> ecm: there is an armada x11 video driver
<ecrn> ok, I've looked at that, but I'm using kms/drm + mesa, without X11
<austriancoder> ecm: this is the only user
<ecrn> thanks, I will try to figure out if I can base on it / integrate it somehow
<ecrn> the thing I'm hoping to do is: blend/overlay two framebuffers (textures) rendered with opengl, where the bottom one is refreshed at 60fps
<ecrn> I have no idea if using GC320 will be better than directly blending with opengl
lynxeye has quit [Quit: Leaving.]
<cphealy> ecrn: does the i.MX6 you have have the IPU with 2 HW planes? If so, you can use this with Weston to do blend/overlay of two framebuffers.
<ecrn> yes, it does, and that solution is the perfect one, except that there is only one IPU unit, and there is one overlay plane per IPU while I need the blending setup on two outputs
<cphealy> There are two IPUs and each IPU supports two planes. Does this not satisfy the need?
<cphealy> Which i.MX6 is this?
<ecrn> in the i.MX6DL there is one, in DQ is two
<ecrn> I have i.MX6DL
<ecrn> I've read that there is an overlay plane on DI0 by default, which can be switched to DI1 by patching the kernel driver, but not both, since the hardware supports only one such plane
<cphealy> ecrn: are you using an upstream kernel that has the DRM/KMS driver for the display controller?
<cphealy> If so, you can use modetest from libdrm to see what the display controller plane capabilities exposed are.
karolherbst has quit [Quit: Konversation terminated!]
<ecrn> cphealy: I have no modetest compiled for the device, if needed I can build it, but I've once upon modified a drm/kms example just to test the overlays
<ecrn> and this is the output
<ecrn> drmSetClientCap(fd, DRM_CLIENT_CAP_UNIVERSAL_PLANES, 1); and then drmModeGetPlane(fd, plane_res->planes[i])
karolherbst has joined #etnaviv
<ecrn> looks like plane 31 is primary for crtc 0, plane 35 is overlay for crtc 0, and plane 38 is primary for crtc 1
<ecrn> with no plane for crtc 1 overlay
ecrn has quit [Remote host closed the connection]
cphealy_ has joined #etnaviv
cphealy has quit [Remote host closed the connection]
cphealy_ has quit []
JohnnyonFlame has joined #etnaviv
JohnnyonFlame has quit [Remote host closed the connection]
pcercuei has quit [Quit: dodo]
JohnnyonFlame has joined #etnaviv