anarsoul has quit [Remote host closed the connection]
anarsoul has joined #lima
anarsoul has quit [Ping timeout: 272 seconds]
anarsoul has joined #lima
anarsoul|c has joined #lima
buzzmarshall has joined #lima
dddddd has quit [Ping timeout: 258 seconds]
buzzmarshall has quit [Remote host closed the connection]
drod has joined #lima
drod has quit [Remote host closed the connection]
warpme_ has joined #lima
Elpaulo has joined #lima
anarsoul|c has quit [Quit: Connection closed for inactivity]
yann has joined #lima
dddddd has joined #lima
buzzmarshall has joined #lima
anarsoul|c has joined #lima
buzzmarshall has quit [Ping timeout: 260 seconds]
warpme_ has quit [Quit: Connection closed for inactivity]
<anarsoul>
enunes: could you check whether your changes prioritize load_coords for ld_tex?
<anarsoul>
I'm running your lima-ppir-sched-readylist branch and I see some graphics artefacts that are likely caused by coords evicted to a register
<anarsoul>
it's important to use varying result directly in ldtex in order to utilize high-precision path
<anarsoul>
otherwise sampling textures larger than 1024x1024 results in artefacts
<enunes>
anarsoul: well I wrote exactly that in the commit message, yes it should prioritize coords since it outputs to pipeline and a normal load var doesn't
<enunes>
without that branch, what you're describing can happen, it happens even with kmscube -M rgba
<enunes>
that branch should fix it
<enunes>
I didn't notice any case where it still has artifacts, if there is some can you point to some application that gets artifacts?
<anarsoul>
chromium
<anarsoul>
but I'm not sure how to debug it since it actually does rendering in separate gpu process
<enunes>
can you double check if it is really using the branch? because that would make total sense to me if it is just master
<anarsoul>
last commit is "lima/ppir: use a ready list in node_to_instr"
<enunes>
ok I can give chromium a try
<anarsoul>
make sure you're using screen that's wider than 1024 pixels
<enunes>
nothing too weird on full hd on xorg with xfce, some flickers but I think it's not related
<enunes>
let me try with master and with before the last tex optimization
<enunes>
on master I already see some artifacts on the xfce4 bar
<enunes>
what I did while working on that branch was to write a small "validator" that checked whether a shader ended up with a broken coords not followed by tex in the same instruction
<enunes>
and my conclusion was that some regressions were introduced in 632a921bd0d and all of them were fixed again in that branch
warpme_ has joined #lima
<anarsoul>
what about chromium?
<enunes>
I didnt notice anything weird on chromium on xorg, full hd, tried a few websites and get.webgl.org, resized and moved the window around
<anarsoul>
wanna screenshot?
<enunes>
so you can reproduce it easily?
<anarsoul>
yep
<enunes>
screenshot probably doesnt help much, I guess shaders would or more details on the environment
<enunes>
and is it a regression really on that commit from mastre?
<anarsoul>
I'll check later whether it's a regression
<enunes>
I see, well a few minutes ago built from the 20.1 branch which doesnt have any of the new ppir commits, and I also get some of those low res text rendering
<anarsoul>
which is essentially your change rebased on master
<enunes>
yeah, I think those text misrenderings are not affected by this commit or any of the ppir commits in the last month
<anarsoul>
I tried setting MESA_SHADER_CAPTURE_PATH but unfortunately it does nothing with chromium :(
<anarsoul>
well, maybe they broke chromium even further with lima...
cwabbott has quit [Ping timeout: 252 seconds]
<enunes>
thats why I tested 20.1, that particular situation is not affected at all
<enunes>
the current bug on master without that commit is much worse, if a shader is affected (without the commit in that branch) textures just become random garbage
<enunes>
so with that commit, it should be back to normality, which is what you are seeing
<enunes>
not much we can do if there is math on tex coordinates
<enunes>
one thing that might be possible is to implement texture2dproj (if that is used) with the divide by z embedded in the ld_coords that utgard supports, so we don't fall back to the nir lowering in that case
cwabbott has joined #lima
<enunes>
but thats not very trivial since the separation of coords and perspective seems to happen very early, I guess even before nir, I couldn't find where to add a handler to try and disable that
<enunes>
anyway, bottom line without much digressing, please check if it is a regression in your setup, if it is the same as I am seeing, it is not that branch and not a recent regression