ChanServ changed the topic of #etnaviv to: #etnaviv - the home of the reverse-engineered Vivante GPU driver - Logs https://oftc.irclog.whitequark.org/etnaviv
pcercuei has quit [Quit: dodo]
otavio__ has joined #etnaviv
otavio_ has quit [Ping timeout: 480 seconds]
mvlad has joined #etnaviv
frieder has joined #etnaviv
frieder has quit [Ping timeout: 480 seconds]
lynxeye has joined #etnaviv
frieder has joined #etnaviv
pcercuei has joined #etnaviv
frieder has quit [Ping timeout: 480 seconds]
frieder has joined #etnaviv
JohnnyonFlame has quit [Ping timeout: 480 seconds]
frieder has quit [Ping timeout: 480 seconds]
frieder has joined #etnaviv
pcercuei has quit [Read error: Connection reset by peer]
pcercuei has joined #etnaviv
<cmeissl[m]> tomeu: yes, or at least kind of. afaict after digging though the code in mesa it looks like the client would have to use the display node with kmsro to receive a scanout able dma buffer in the compositor. otherwise private memory would be allocated. But the wayland egl platform disables use of dmabuf feedback when I send card1 because it is not a render node. Sending the render node from etnaviv enables the use of dmabuf feedback, but
<cmeissl[m]> kms->ro will be NULL.
<cmeissl[m]> I opened https://gitlab.freedesktop.org/mesa/mesa/-/issues/8384 and asked in dri-devel, where I received some feedback about the problem. The last response from daniels suggests that it would be better to announce the render node as the main device and make the wayland platform code properly react on the scanout tranche target device.
<cmeissl[m]> tomeu: In the mean time I just patched the platform to allow card1 to be used as the main device. This allows my compositor to use the client buffer for scan-out on both, the overlay and the primary plane. So at least I now know it technically should work.
JohnnyonFlame has joined #etnaviv
<cmeissl[m]> But I saw something else today that I need to take a closer look. I am trying to use the 2D Core for composition and implemented some minimal example using the tests and examples from etnaviv to send commands to the gpu. At some point after running the example a few times it fails to allocate memory. I need to confirm, but it looks like allocating a gbm bo with SCANOUT and afterwards mapping it somehow leaks it. The map is unmapped and the
<cmeissl[m]> bo is also cleaned up, but there is still a dmabuf active after exit. The dmabuf is attached to etnaviv.
<cmeissl[m]> maybe, it seems that calling gbm_bo_map creates it internally
<cmeissl[m]> is it possible it references itself and therefore it doesn't get cleaned up when calling gbm_bo_destroy?
otavio__ has quit [Remote host closed the connection]
otavio_ has joined #etnaviv
frieder has quit [Quit: Leaving]
sknebel_ has quit []
sknebel has joined #etnaviv
JohnnyonFlame has quit [Ping timeout: 480 seconds]
lynxeye has quit [Quit: Leaving.]
mvlad has quit [Remote host closed the connection]
JohnnyonFlame has joined #etnaviv