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]
karolherbst is now known as karolherbst_
karolherbst_ is now known as karolherbst
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #etnaviv
mvlad has joined #etnaviv
frieder has joined #etnaviv
lynxeye has joined #etnaviv
Peng_Fan___ has joined #etnaviv
pcercuei has joined #etnaviv
otavio has joined #etnaviv
otavio has quit [Remote host closed the connection]
mvlad has quit [Remote host closed the connection]
mvlad has joined #etnaviv
<heeen> I stumbled across some commits about scanout buffers for wayland
<heeen> does this mean this is supported all the way through the stack using weston? the comments seem to indicate that
<heeen> what do you need to support this on a qtwayland based stack
<lynxeye> heeen: If you are using a recent Mesa and weston, your Qt client application will automatically allocate a buffer suitable for direct scanout when weston thinks that the application could be put on a display plane.
<lynxeye> In fact Qt doesn't know anything about it. The EGL implementation in Mesa will reallocate the backbuffers when needed.
<mntirc> lynxeye: do you have any advice on how to further debug this kind of issue in the kernel, or how/where is should report it? the problem is not that the app itself is messed up, but it can also mess up the desktop session/other apps. i'm not sure if that's just how it is/WONTFIX, though. https://gitlab.freedesktop.org/mesa/mesa/-/issues/8180
<lynxeye> mntirc: The right place to report kernel driver issues is the etnaviv ML. However I'm fine looking at reports in gitlab, even if they aren't strictly Mesa related.
<mntirc> lynxeye: ah, ok. and do you think this merits further investigation or it's uninteresting?
<heeen> I'm asking from the perspective of someone writing a qtwayland qml compositor with Qt or non qt apps
<lynxeye> mntirc: If you are able to hang the machine with this, then it's certainly interesting. While broken apps may shoot themselves in the foot or even hang the GPU at worst, they should never be able to kill the whole machine.
<heeen> surely the compositor at some point will have to ask some lower layer for a scanout capable buffer that is hardware blitted at a certain location?
<lynxeye> heeen: In that case you may need to look at the state of the dmabuf feedback compositor side implementation in qt.
<lynxeye> dmabuf feedback is how weston communicates the buffer allocation preferences to the client side EGL implementation.
<mntirc> lynxeye: ok, i agree!
<heeen> thanks. I'm looking for the right keywords to google for and grep in weston for
karolherbst has quit [Quit: Konversation terminated!]
karolherbst has joined #etnaviv
cphealy_ has quit []
cphealy has joined #etnaviv
<cphealy> heeen: you should probably look at this in the context of implementing dmabuf-feedback: https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/544
<heeen> whats a tranche in this context
frieder has quit [Remote host closed the connection]
lynxeye has quit [Quit: Leaving.]
pcercuei has quit [Read error: Connection reset by peer]
pcercuei has joined #etnaviv
JohnnyonFlame has joined #etnaviv
mvlad has quit [Remote host closed the connection]