dinfuehr has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
<tursulin>
airlied, danvet: ping on f25affc9-a819-415e-0250-eba99ac813aa@linux.intel.com please wrt getting an ack to merge a drm_mm patch via drm-intel-gt-next?
<danvet>
tursulin, ack
<tursulin>
ty!
<danvet>
hm the 2nd patch looks a bit like conceptual nonsense, but maybe I'm not awake yet
dinfuehr has joined #dri-devel
<danvet>
like shouldn't the check be whether we already have a normal view mapped (or whichever view it is)
<danvet>
and just use that, instead of trying to force mappable and eating a stall, and then trying to paper over that with clever heuristics that work in one case but not in another (like hey per-crtc buffers or triple buffering)
<danvet>
doesn't really pass the smell test
<tursulin>
with a disclaimer that it is early here too, and it's been a few weeks since I thought about - but conceptually it is supposed to simply be replacing the current heuristic of "is the object larger than half of the aperture" with "do we have at least two object size holes free in the aperture"
<danvet>
yeah the current heuristic doesn't pass the smell test either, but at least it's dead simple :-)
dinfuehr has quit []
<tursulin>
okay, holding off the merge assuming you want to comment to the thread
<danvet>
what I think should work here is 1) check whether we have the right view already 2) try nonblocking mappable 3) fall back to unmappable pin
<danvet>
ok will drop a question
<danvet>
ofc if we need mappable due to fencing on gen3.5 then that's different, but that's the absolute exception of the exception
dinfuehr has joined #dri-devel
maxzor has joined #dri-devel
dinfuehr has quit []
dinfuehr has joined #dri-devel
shankaru has quit [Quit: Leaving.]
pcercuei has joined #dri-devel
shankaru has joined #dri-devel
pochu has joined #dri-devel
simon-perretta-img has quit [Read error: No route to host]
simon-perretta-img has joined #dri-devel
ahajda has joined #dri-devel
simon-perretta-img_ has joined #dri-devel
Daanct12 has quit [Quit: Quit]
simon-perretta-img has quit [Ping timeout: 480 seconds]
Terman has joined #dri-devel
simon-perretta-img_ has quit []
simon-perretta-img has joined #dri-devel
rasterman has joined #dri-devel
adjtm has quit [Quit: Leaving]
adjtm has joined #dri-devel
kts has quit [Read error: Connection reset by peer]
rkanwal has joined #dri-devel
dinfuehr has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
Lucretia has quit []
dinfuehr has joined #dri-devel
kts has joined #dri-devel
dinfuehr has quit []
itoral has quit [Read error: Connection reset by peer]
<dcbaker>
thanks for your help on these, btw, I appreciate it
<zmike>
sure, maybe one day I'll get the process right on my end
shankaru has quit [Quit: Leaving.]
mclasen has quit []
mclasen has joined #dri-devel
Guest1859 has quit [Ping timeout: 480 seconds]
camus has quit []
jkrzyszt has quit [Ping timeout: 480 seconds]
<dcbaker>
zmike: that was it, zink is green :)
<jekstrand>
zmike: Is not autogenerating vkCmdBeginRendering causing asan fails on lavapipe?
<zmike>
jekstrand: yes, it leaks
<zmike>
dcbaker: great!
<jekstrand>
zmike: Ok...
<jekstrand>
zmike: In that case, I'll just drop those fails
<zmike>
yes
cheako has joined #dri-devel
<jekstrand>
\o/
* jekstrand
fixed things!
ybogdano has joined #dri-devel
<karolherbst>
current state: failing to compile to nir because if libclc missing
mbrost has quit [Ping timeout: 480 seconds]
DottorLeo has joined #dri-devel
<DottorLeo>
hi!
<DottorLeo>
@Plagman, where i should report a bug with proton that affect many games together?
Danct12 has quit [Quit: Quitting]
frankbinns has quit [Remote host closed the connection]
<DottorLeo>
It's a strange thing, i'm using Proton Experimental, nothing else, if i start a game fullscreen with the maximum resolution for my laptop 1360x768 , i see the image stretching in and out very quickly but if i try with a resolution slightly smaller (1280x720), no problem! It affect many games like Dead Space, Bayonetta, Mortal Kombat 9 (strangely Untitled Goose game has not this problem). I've also upgraded to mesa 21.3.7
<DottorLeo>
(intel HD620, Kaby Lake Processor) but i don't think it's this the problem, native linux games with native resolution has no such problem. I'm also on Wayland. If you can tell me where i should report this i'd like to help with logs and anything can help :)
Danct12 has joined #dri-devel
mbrost has joined #dri-devel
<kisak>
DottorLeo: same as all other feedback for Proton -> Proton's issue tracker
<kisak>
how long ago were you testing this?
<DottorLeo>
kisak, right now ^^"
Danct12 has quit [Quit: Quitting]
<DottorLeo>
i mean i'm using the latest now but started 2 days ago
<DottorLeo>
let me try doom 2016
macc24 has joined #dri-devel
dinfuehr has joined #dri-devel
dinfuehr has quit []
dinfuehr has joined #dri-devel
dinfuehr has quit []
Danct12 has joined #dri-devel
<kisak>
yeah, open a new compatibility report oriented around the specific issue, mention the affected games, and when the behavior changed.
gouchi has quit [Remote host closed the connection]
gouchi has joined #dri-devel
<DottorLeo>
kisak, let me try older proton just to be sure :)
<ajax>
i'm getting tempted to rewrite drisw's winsys anyway
<anholt>
but, like, how are we getting expose events?
<anholt>
or, rather, 2 expose events
ngcortes has joined #dri-devel
<ajax>
not sure. i feel like i've been down this road before... the bit about 'when no valid contents are available' from page 13 of proto.pdf i think is relevant
<ajax>
you map the the window, it paints the background because yes you have bs but you haven't put anything in it yet, you get an expose to let you know you need to paint for real
<anholt>
yeah, and that's great because our event loop relies on getting the expose in order to run the test. but how are we getting a second expose?
<anholt>
that really sounds like we didn't get composited
<ajax>
that, might be a bug? it would make sense if the exposure code _always_ thought bs windows needed exposures just like notuseful windows, and didn't understand that bs means "valid contents are available"
<ajax>
in which case, we map, something else maps and occludes us, we unmap, more exposes
<ajax>
they unmap rather
<anholt>
hmm. even two loops running the test in parallel under xvfb without bs don't reproduce it as quickly as ci seems to.
tzimmermann has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
macromorgan is now known as Guest1903
Guest1903 has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
i-garrison has quit []
<zmike>
jekstrand: \o/
ybogdano has quit [Ping timeout: 480 seconds]
i-garrison has joined #dri-devel
pnowack has quit [Quit: pnowack]
<zmike>
anholt: is it possible to specify not-flakes? like if a named test fails for any reason then it fails the whole job?
<anholt>
there is not.
<zmike>
hm
<anholt>
(why?)
<zmike>
there's one test in the zink job which flakes in the course of trying to fix lavapipe async stuff, so if I'm working on that and spamming ci jobs then I'd like it to fail
<zmike>
or if some other change causes it to flake for the same reason
ybogdano has joined #dri-devel
<anholt>
do you mean that you're trying to squash a flake, so you need to know if it still happens?
<anholt>
tomeu said he had some tools for rerunning jobs a ton of times and watching their stability, and I want something like that too.
<zmike>
no, I mean it does not flake currently and if I cause it to flake then I want to make sure I (or whoever is causing it to reoccur) am immediately informed
<zmike>
a tool like that would be nice too, yes
<zmike>
but this is more like if a change I'm not expecting causes a flake regression I want to know
<anholt>
it sounds like you want this as a temporary hack. Just grep for the <test name>,Flake in the results.csv I'd say.
<ajax>
the odds that the test that notices a flake will happen on the MR that introduces it are not 100%
<zmike>
I guess that's true
mvlad has quit [Remote host closed the connection]
mclasen has quit []
mclasen has joined #dri-devel
Danct12 has quit [Ping timeout: 480 seconds]
lynxeye has quit []
rkanwal has quit [Ping timeout: 480 seconds]
pnowack has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
cheako has quit [Quit: Connection closed for inactivity]
Danct12 has joined #dri-devel
JohnnyonFlame has joined #dri-devel
mclasen has quit []
mclasen has joined #dri-devel
mclasen has quit []
mclasen has joined #dri-devel
ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]
ngcortes has quit [Remote host closed the connection]
FLHerne has quit [Quit: There's a real world out here!]
FLHerne has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
ngcortes has joined #dri-devel
mclasen has quit []
mclasen has joined #dri-devel
mattst88 has quit [Ping timeout: 480 seconds]
sdutt has quit [Ping timeout: 480 seconds]
mclasen has quit []
mclasen has joined #dri-devel
mclasen has quit []
mclasen has joined #dri-devel
mclasen has quit []
mclasen has joined #dri-devel
rkanwal has joined #dri-devel
iive has joined #dri-devel
ngcortes has quit [Remote host closed the connection]
Duke`` has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: WeeChat 3.4]
linearcannon has joined #dri-devel
ngcortes has joined #dri-devel
rkanwal has quit [Quit: rkanwal]
mlankhorst has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
thellstrom has quit [Read error: Connection reset by peer]
<Lyude>
btw hwentlan____ - turns out there's a chance my roommate (who also happens to be my coworker lol) may have access to an older AMD GPU that both uses radeon and can do MST, so hopefully I should know more about whether radeon's MST support is still functional at all or not
gouchi has quit [Remote host closed the connection]
thellstrom has joined #dri-devel
<Lyude>
(I hope it isn't, because if so that means i'm just about done with removing non-atomic MST stuff :)
rasterman has quit [Quit: Gettin' stinky!]
Haaninjo has quit [Quit: Ex-Chat]
mattst88 has joined #dri-devel
hansg has joined #dri-devel
hansg has quit []
sdutt has joined #dri-devel
pnowack has quit [Quit: pnowack]
jewins1 has joined #dri-devel
<karolherbst>
jekstrand: you'll hate me for what I just did :D
<karolherbst>
so uhm... I need to iterate over nir_variables and.. uhm... I want to do that in rust :p