ChanServ changed the topic of #lima to: Development channel for open source lima driver for ARM Mali4** GPUs - Kernel driver has landed in mainline, userspace driver is part of mesa - Logs at https://oftc.irclog.whitequark.org/lima/
camus has joined #lima
camus1 has quit [Ping timeout: 480 seconds]
drod has quit [Remote host closed the connection]
camus1 has joined #lima
camus has quit [Ping timeout: 480 seconds]
camus has joined #lima
camus1 has quit [Ping timeout: 480 seconds]
camus1 has joined #lima
camus has quit [Read error: Connection reset by peer]
camus1 has quit [Remote host closed the connection]
camus has joined #lima
drod has joined #lima
camus has quit []
camus has joined #lima
freemangordon has joined #lima
<Wizzup>
enunes: anarsoul: I figured out one of the problems that made things render poorly, With that now fixed, I have traces that renders fine on amdgpu, llvmpipe, nvidia binary drivers, but don't seem ok on the pinephone with lima (with X/glamor) for me
<Wizzup>
I can't get dump-images to actually work on my pinephone for some reason, but I can make a video with camera if that helps
<enunes>
Wizzup: looking at hildon-desktop-doublebuf-fallback.trace it seems that the application does not glClear after eglSwapBuffers, but does not seem to use any extension like partial_update or buffer_age, do you know if that is on purpose?
<enunes>
if it is hoping to reuse the frame, I think doing that is unreliable if not undefined
<Wizzup>
I think EGL_BUFFER_PRESERVED was set in that trace (if not, I will have to re-check, but iirc the result was the same) - that sets the buffer age does it not?
<enunes>
I cant find it searching by EGL_BUFFER_PRESERVED
<Wizzup>
Yeah it should be an eglSurfaceAttrib
<Wizzup>
I'll make a new trace, but I am pretty confident the outcome will be the same since I had that change locally earlier today and it didn't help
<enunes>
I would doublecheck if apitrace actually implements replaying EGL_BUFFER_PRESERVED
<Wizzup>
ok
<Wizzup>
what I meant is that with eglSurfaceAttrib in my code on the pinephone the problem seemed to persist
<enunes>
ok, so playing the trace on my intel system without EGL_BUFFER_PRESERVED does result in glitches, which seem to make sense since I get alternating blocks of black with selection as its not reusing the buffers properly
<enunes>
I think EGL_BUFFER_PRESERVED is not too common so if the application relies on that, it seems fishy
<Wizzup>
freemangordon might be in a better position to comment
<Wizzup>
The application is using clutter, for what it is worth
<Wizzup>
looks like eglSurfaceAttrib setting the EGL_SWAP_BEHAVIOUR to EGL_BUFFER_PRESERVED returns EGL_FALSE
<freemangordon>
BTW I have intel around, I will replay on it as well to see what the result will be
<enunes>
I mean its not used by many applications so it is probably less tested and this is some place where there might be some bug. also if apitrace doesnt even handle it properly, it might be making your debug more difficult
<freemangordon>
enunes: I see. Well, default behaviour is implementation specific, but it seems most if not all choose EGL_BUFFER_PRESERVED, at least by judging of replay on AMD/NV/llvmpipe and on-device behaviour on PVR
<freemangordon>
maybe it makes sense to read what lima thinks about the default value
<freemangordon>
enunes: still, there seems to be some issue in lima driver
<enunes>
yes there are probably still issues in the driver :)
<freemangordon>
:)
<freemangordon>
so, clutter seems to prefer partial updates and it relies on buffers being preserved
<freemangordon>
I guess we can tell it to do full scene update, but that would affect the performance on devices with slower GPUS (like d4 and friends and esp n900 with its dated sgx530)
<enunes>
I think EGL_SWAP_BEHAVIOUR is a different thing than partial updates, if you do partial updates you should query the buffer at the beginning of the frame iirc
<freemangordon>
not really, there is a note in buffer_age extension about EGL_SWAP_BEHAVIOUR
<freemangordon>
if I read the docs correctly that is
<freemangordon>
EGL_BUFFER_PRESERVED gives 2 frames age, and this is supported, like incremental damage for the last 2 frames
<freemangordon>
that's why I said "partial updates"
<freemangordon>
by "last frames" I mean current and previous frame
<enunes>
right but those are different things, what I understand is you do either buffer_age/partial_update (better) or BUFFER_PRESERVED, the blurb in the docs is more to say that it wont break in case you happen to try to use both
<enunes>
in the trace I got there was none of them
<freemangordon>
sure those are different what i was trying to say is that if buffer_age is not used, but BUFFER_PRESERVED, you are guaranteed to always have n-1 age :)
<freemangordon>
sure, but we set BUFFER_PRESERVED to no use
<freemangordon>
ofc we can provide traces with that call included
<freemangordon>
but we though it doesn;t make sense to do it, as it changes nothing on device
<freemangordon>
*thought
<enunes>
it can be that its not the main issue, but I think it should be fixed before proceeding with further analysis
<enunes>
otherwise we are basically debugging an invalid application
<enunes>
with the current state it seems that just setting BUFFER_PRESERVED is the straightforward thing to do and even if its not the best practice, I agree that should work
<freemangordon>
enunes: I think we shall first check what is the default value reported
<enunes>
if we suspect BUFFER_PRESERVED is broken with lima maybe it can be validated with a simple triangle app or something
<freemangordon>
kids are shouting at me that I am on the PC, ttyl :)
<enunes>
well the default shouldnt matter if you rely on it being BUFFER_PRESERVED
<anarsoul>
freemangordon: it's handled by winsys, not lima
<anarsoul>
lima as backend driver doesn't really care if you want to preserve buffers or not. If frontend doesn't call clear explicitly, it will reload the buffer into tile buffer
<anarsoul>
btw that's why using preserved buffers is expensive on tiling GPUs, if you don't do clear, you have to essentially draw a textured quad to restore contents of old buffer
<anarsoul>
well, bad wording, it's not you that have to draw it, lima does it for you
<freemangordon>
:nod:
<freemangordon>
I understand it might not be the best performance wise in some ocasions
<anarsoul>
freemangordon: actually in most cases it's a bad idea, especially if you don't use scissors
<freemangordon>
we use
<anarsoul>
OK, good
<freemangordon>
and damage tracking
<freemangordon>
well, 'we' is clutter
<freemangordon>
but it either uses viewport(not used) or scissors to limit the updated area
<freemangordon>
the point is that on all the GPUs we tested (we did not on intel), the trace renders correctly
<freemangordon>
I will test on intel later on
<anarsoul>
freemangordon: other GPUs may not require explicit tile reload
<freemangordon>
well, we use the same code on sgx 530 and sgx 540
<freemangordon>
both are tiling GPUs
<anarsoul>
freemangordon: sorry, no idea how these work :)
<freemangordon>
tiling
<anarsoul>
freemangordon: it doesn't mean that they need to reload tile buffer explicitly
<anarsoul>
there may be an implicit reload if driver doesn't send clear command
<anarsoul>
or something like that
<freemangordon>
won;t argue, I have no idea how those work too
<anarsoul>
try with panfrost if you have any devices with newer Mali, it does explicit reload for sure :)
<freemangordon>
anarsoul: well, the point is to have lete working with lima on pinephone
<freemangordon>
*leste
jernej_ is now known as jernej
<anarsoul>
well, get us an apitrace that doesn't work on lima and works on intel (IIRC enunes' laptop uses Intel GPU, mine is also Intel)
<freemangordon>
ok
<anarsoul>
and someone will look into it eventually
<freemangordon>
I have intel, will see what we can do :)
camus has quit [Ping timeout: 480 seconds]
<anarsoul>
freemangordon: tbh I haven't heard about issues like that with lima yet, so there must be something special about your compositor
<anarsoul>
gnome-shell (X11 and wayland), plasma (X11 and wayland), xcompmgr (X11), sway (wayland), weston (wayland) - all work just fine on lima
<anarsoul>
if you know what it is, that may help to pinpoint the issue :)
<freemangordon>
yeah, I think we'll be able to identify what's going on
<freemangordon>
anarsoul: is "GL_RENDERER: Mesa DRI Intel(R) UHD Graphics 620 (KBL GT2)" good enough?