austriancoder changed the topic of #etnaviv to: #etnaviv - the home of the reverse-engineered Vivante GPU driver - Logs https://freenode.irclog.whitequark.org/etnaviv
Chewi has quit [Quit: ZNC 1.7.5 - https://znc.in]
Chewi has joined #etnaviv
pcercuei has quit [Quit: dodo]
jicksaw has quit [Quit: ZNC is kill]
jicksaw has joined #etnaviv
lilstevie has quit [Ping timeout: 256 seconds]
lilstevie has joined #etnaviv
mupuf has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
diverger has quit [Ping timeout: 260 seconds]
diverger has joined #etnaviv
_whitelogger has joined #etnaviv
diego_r has joined #etnaviv
lynxeye has joined #etnaviv
karolherbst has quit [Quit: duh 🐧]
karolherbst has joined #etnaviv
T_UNIX has joined #etnaviv
pcercuei has joined #etnaviv
<karolherbst> I've heard you have the same issue as we have with tegra that userspace not using modifiers is quite busted, is that correct? In any case, I opened a feature request against mutter to enable their kms modifier support on some devcices where it is actual required and things won't work without it: https://gitlab.gnome.org/GNOME/mutter/-/issues/1408
<karolherbst> I was wondering if that's the actual case with etnaviv as well or not?
<mntmn> karolherbst: OOC, what kind of visible problems does that cause?
<karolherbst> mntmn: the screen is completly black when starting mutter :)
<mntmn> ah lol!
<karolherbst> yeah..
<karolherbst> the issue is we can't render into a linear depth buffer
<mntmn> i've seen that only when using Xorg
<karolherbst> sooo... things just break if we get one
<mntmn> like, xorg+modesetting+etnaviv
<karolherbst> mntmn: yeah.. it's an issue with 1.20
<karolherbst> it should work on 1.21
<karolherbst> I know that weston just works as it uses modifier
<karolherbst> but mutter does not
<mntmn> yes, all wayland compositors work for me on etnaviv, incl. mutter when started in wayland mode
<karolherbst> ohh, interesting
<karolherbst> maybe etnaviv does something inside mesa so the issue is not visible.. mhh
<karolherbst> are you doing some magic detiling stuff or something?
<karolherbst> I know that I have to enable kms-modifiers in mutter first
<mntmn> mutter --wayland --display-server works for me
<mntmn> i think etnaviv does automatic detiling for scanout, but i'm not an expert in that area
<karolherbst> mhhhh
<karolherbst> yeah.. we were wondering to add this stuff to the tegra driver as well
<karolherbst> but using kms modifiers would give better perf anyway
<austriancoder> karolherbst: If needed we do an extra blit to detile
berton has joined #etnaviv
<karolherbst> austriancoder: ohh, I see.
<karolherbst> austriancoder: when are you doing it? We have an MR for tegra do support this but maybe there are some pitfalls we are not aware of
<karolherbst> so essentially we do it at flush_resource
\\server\share has joined #etnaviv
<lynxeye> karolherbst: you really want some age counters on the resources. flush_resource might be called multiple times without actual rendering happening to the resource
<lynxeye> so you want to optimize this into only doing the blit when there were changes to your internal shadow
berton has quit [Quit: Leaving]
<karolherbst> yeah.. I think that sounds like a reasonable thing
<karolherbst> but I was more interested on the high level overview on how the resource are created and when you do the detiling... I mean, I know that the MR seems to work well enough, just wondering if you do it differently or not
<mntmn> gnome 3.36 (wayland) works perfectly now on etnaviv/gc7000l btw. needs those 2 little fixes to glamor for xwayland apps, otherwise stable and surprisingly fast
<karolherbst> mntmn: what two fixes?
<mntmn> karolherbst: i had to remove one glClear from glamor to fix texture/fbo corruption of xwayland windows. and put in one glFinish to fix sync issues that make everything flicker
<karolherbst> mhh, let's see if I hit the same thing
<lynxeye> karolherbst: In general etnaviv was in the nice place that we did never support winsys buffers in tiled layout without modifiers. So if we get to import a buffer or create one without a specified modifier we just assume linear and then have internal shadows for actual rednering
<lynxeye> Not sure how well this translates to tegra
<karolherbst> well.. the issue with tegra is that tegra is essentially kmsro, and it uses nouveau for the actual operations
<mntmn> the glFinish() is a workaround that causes some buffer flushes to hard sync. because apps that draw directly via legacy X apis don't have a sync mechanism with etnaviv
<karolherbst> right..
<mntmn> removing the glClear() is a workaround for unknown corruption bug in etnaviv/gc7000l
<karolherbst> I think I remember sawing a similiar issue,not sure if it was X or xwayland though
<mntmn> i also found that Xwayland works much better when used in rooted mode. it is tricker when wayland also acts as the window manager
<austriancoder> karolherbst we are using the renderonly library for scanout buffers (renderonly_create_kms_dumb_buffer_for_resource(..) ) - see etna_resource_alloc(..) and the flush should happen in etna_flush_resource(..)
* austriancoder is currently in a meeting
HQ has joined #etnaviv
T_UNIX has quit [Quit: Connection closed for inactivity]
\\server\share has quit [Ping timeout: 265 seconds]
\\server\share has joined #etnaviv
<karolherbst> mntmn: mhh.. can I launch mutter from ssh?
HQ has quit [Ping timeout: 240 seconds]
HQ has joined #etnaviv
\\server\share has quit [Ping timeout: 240 seconds]
<mntmn> karolherbst: not sure, maybe with openvt?
<daniels> mntmn: yeah, rooted mode means that you get a real surface with eglSwapBuffers; rootless mode means that the user buffers get directly passed through for GL clients, but for software-rendered clients, you just periodically blit into a shared surface, which is ... a bit of a disaster tbh
<daniels> but it's the same when running X11 with any other composition manager, not specific to Xwayland
<mntmn> daniels: btw, remember our little experiment with glFinish? do you think it's realistic to get a patch specific to etnaviv into xorg/glamor?
<mntmn> i guess the glClear thing has to be fixed on etnaviv side somehow, but for the sync issue i don't know any other solutions
<daniels> mntmn: I do remember it well (found the branch the other day in fact), but I don't really know how it is we'd detect that we need to be using it
\\server\share has joined #etnaviv
HQ has quit [Ping timeout: 260 seconds]
\\server\share has quit [Client Quit]
Chewi has quit [Ping timeout: 264 seconds]
Chewi has joined #etnaviv
<marex> lynxeye: did you make any progress on the GPC/PGC ? I'll slowly get back to it todayish
<marex> I also got no reply from NXP, of course
JohnnyonFlame has joined #etnaviv
cphealy__ has joined #etnaviv
lynxeye has quit [Quit: Leaving.]
JohnnyonF has joined #etnaviv
JohnnyonFlame has quit [Ping timeout: 246 seconds]
sravn_ has quit [Quit: WeeChat 2.8]
diego_r has quit [Ping timeout: 246 seconds]
diego_r has joined #etnaviv
diego_r has quit [Remote host closed the connection]
philn has quit [*.net *.split]
philn has joined #etnaviv
diego_r has joined #etnaviv
diego_r has quit [Ping timeout: 240 seconds]
diego_r has joined #etnaviv