Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
yuq825 has joined #dri-devel
camus has joined #dri-devel
camus has quit []
camus has joined #dri-devel
Danct12 has joined #dri-devel
lemonzest has joined #dri-devel
windleaves has joined #dri-devel
wind has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
aravind has joined #dri-devel
chip_x has joined #dri-devel
paulk has quit [Ping timeout: 480 seconds]
chipxxx has quit [Ping timeout: 480 seconds]
Danct12 has quit [Read error: Connection reset by peer]
Danct12 has joined #dri-devel
wooosaiii has quit [Remote host closed the connection]
wooosaiii has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
Zopolis4 has joined #dri-devel
motogangsters has quit [Quit: Leaving]
aravind has joined #dri-devel
aravind has quit [Read error: Connection reset by peer]
kzd has quit [Quit: kzd]
aravind has joined #dri-devel
mbrost has joined #dri-devel
<mareko>
actually gl_spirv seems to do it correctly
mbrost has quit [Ping timeout: 480 seconds]
karolherbst has quit [Read error: Connection reset by peer]
karolherbst has joined #dri-devel
mbrost has joined #dri-devel
mbrost has quit [Read error: Connection reset by peer]
agd5f has joined #dri-devel
agd5f_ has quit [Ping timeout: 480 seconds]
sarnex has quit [Remote host closed the connection]
sarnex has joined #dri-devel
Company has quit [Quit: Leaving]
agd5f_ has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
<mareko>
interesting fact: the current varying linker doesn't fully remove VS inputs (the vertex buffers and elements are still set even if unused), but my new varying linker does remove them properly
<mareko>
and I wondered why a display list had no vertex attribs... well they were eliminated by the linker
tzimmermann has joined #dri-devel
itoral has joined #dri-devel
hansg has joined #dri-devel
hansg has quit []
bgs has joined #dri-devel
wind has joined #dri-devel
windleaves has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
sghuge has joined #dri-devel
danvet has joined #dri-devel
kts has joined #dri-devel
junaid has joined #dri-devel
jfalempe has joined #dri-devel
fab has quit [Quit: fab]
epoll has quit [Ping timeout: 480 seconds]
epoll has joined #dri-devel
junaid has quit [Remote host closed the connection]
fab has joined #dri-devel
jkrzyszt has joined #dri-devel
Danct12 has quit [Quit: WeeChat 3.8]
Danct12 has joined #dri-devel
frieder has joined #dri-devel
tursulin has joined #dri-devel
mvlad has joined #dri-devel
fab has quit [Read error: No route to host]
fab has joined #dri-devel
fab has quit [Read error: Connection reset by peer]
fab_ has joined #dri-devel
fab_ is now known as Guest7546
pcercuei has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
pochu has joined #dri-devel
vliaskov has joined #dri-devel
ella-0[m] has quit []
Haaninjo has joined #dri-devel
kunal_1072002[m] has quit []
Guest7546 has quit []
fab has joined #dri-devel
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit [Remote host closed the connection]
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit []
moben[m] has quit []
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit [Remote host closed the connection]
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit [Remote host closed the connection]
fab has joined #dri-devel
fab has quit [Remote host closed the connection]
Haaninjo has quit [Quit: Ex-Chat]
fab has joined #dri-devel
fab has quit [Remote host closed the connection]
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
pcercuei has quit [Ping timeout: 480 seconds]
fab has quit []
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit []
pcercuei has joined #dri-devel
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit [Remote host closed the connection]
Ahuj has joined #dri-devel
fab has joined #dri-devel
aravind has joined #dri-devel
rasterman has joined #dri-devel
<jani>
hey, I pushed v6.3-rc2 to drm-intel-fixes and got a conflict in cirrus when merging drm-misc-next
<jani>
tzimmermann: you were apparently involved in it, any chance you could resolve it?
frieder has quit [Read error: Connection reset by peer]
<tzimmermann>
jani, give me a minute. there was a merge conflict during my cirrus push. working on it
<jani>
tzimmermann: ah, okay, it wasn't me then. thanks!
MrCooper has quit [Remote host closed the connection]
tobiasjakobi has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
devilhorns has joined #dri-devel
<jani>
tzimmermann: thanks
windleaves has joined #dri-devel
wind has quit [Ping timeout: 480 seconds]
khfeng_ has quit [Ping timeout: 480 seconds]
<jani>
vsyrjala: did you fix it with a conflict resolution?
<vsyrjala>
i just pushed a fixup patch for it
frieder has joined #dri-devel
<vsyrjala>
there is no conflict
<jani>
right, understood
<mareko>
apparently nobody in the industry does VS->TCS varying opts in the linker, otherwise they would have noticed that GLCTS contains a test that has a dead uniform only kept alive by a dead output
JohnnyonFlame has joined #dri-devel
YuGiOhJCJ has quit [Remote host closed the connection]
<mareko>
and it fails if it's eliminated
YuGiOhJCJ has joined #dri-devel
<zmike>
unsurprising
<zmike>
will you file an issue for it?
<zmike>
or should I
vyivel has quit [Remote host closed the connection]
vyivel has joined #dri-devel
aravind has quit [Remote host closed the connection]
aravind has joined #dri-devel
ced117 has quit [Ping timeout: 480 seconds]
junaid has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
junaid has quit [Remote host closed the connection]
MajorBiscuit has joined #dri-devel
aravind has joined #dri-devel
khfeng_ has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
lynxeye has joined #dri-devel
wind has joined #dri-devel
windleaves has quit [Ping timeout: 480 seconds]
agd5f has joined #dri-devel
devilhorns has quit []
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
agd5f_ has quit [Ping timeout: 480 seconds]
agd5f_ has joined #dri-devel
dwlsalmeida3 has quit []
dwlsalmeida has joined #dri-devel
fxkamd has joined #dri-devel
Danct12 has quit [Ping timeout: 480 seconds]
agd5f has quit [Ping timeout: 480 seconds]
<dwlsalmeida>
Lynne hey, if you have the time, I wonder what you think about the provisional vp9 vulkan video api? airlied apparently got it to work on radv after some work of his own on top
zehortigoza has joined #dri-devel
itoral has quit [Remote host closed the connection]
lemonzest has quit [Quit: WeeChat 3.6]
lemonzest has joined #dri-devel
kzd has joined #dri-devel
smiles has joined #dri-devel
smilessh has quit [Ping timeout: 480 seconds]
LuckyKnight has joined #dri-devel
Zopolis4 has quit []
dtmrzgl has quit []
<LuckyKnight>
Any one else have compilation error with Mesa V23.0.0?
<LuckyKnight>
17:28:10 ../src/egl/drivers/dri2/platform_x11.c:1213:4: error: implicit declaration of function ‘loader_dri3_update_screen_resources’ [-Werror=implicit-function-declaration]
<LuckyKnight>
17:28:10 ../src/egl/drivers/dri2/platform_x11.c: In function ‘dri2_x11_get_msc_rate’:
<MrCooper>
looks like loader_dri3_helper.h isn't getting included for some reason
<psykose>
it only gets included with dri3 enabled afaict
<psykose>
i guess it's some niche case where those options don't enable dri3 (which is weird) but are building the dri2 code
macromorgan has quit [Remote host closed the connection]
<psykose>
(the file itself only includes it with dri3 but won't compile without it?)
macromorgan has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
Leopold has joined #dri-devel
kts has joined #dri-devel
ddavenport has quit [Remote host closed the connection]
pcercuei has quit [Ping timeout: 480 seconds]
mohamexiety has joined #dri-devel
fab has quit [Quit: fab]
fab has joined #dri-devel
Company has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
<eric_engestrom>
I encourage everyone who has jobs in the CI to take a look at how long they take and reduce the coverage (or increase `parallel:` and the number of runners for those who can) in order to keep it fast enough to not be too much of a burden :)
<daniels>
eric_engestrom: fwiw we've mostly been trying to keep ours at 15, assuming that the build will complete in several minutes
<daniels>
we've done a bunch of stuff to cut test load, and I'm waiting until things stabilise before I start throwing out some of the slower tests as that changes the caselist so needs a stress test
jljusten has quit [Quit: WeeChat 3.7.1]
<daniels>
the biggest issue atm is that some of the Chromebooks have quite unreliable UART, so we need to retry far too often for my liking - we're waiting for a LAVA fix to land for that hopefully very soon which will cut the worst-case times in half
stuarts has joined #dri-devel
<eric_engestrom>
I didn't look at the docs recently but iirc the target was 10 minutes
<eric_engestrom>
if it was bumped to 15, perhaps we should bring it back to 10?
<jenatali>
I've been doing my best to keep to the spirit of that goal. If anybody notices the Windows jobs starting to be on the longer side of the job length spectrum please let me know and we can reduce coverage or something
frieder has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
<Wallbraker>
Speaking of CI, has one of the windows runner fallen off? Tags: docker/windows/2022 are not showing up.
<Wallbraker>
Ops wrong channel, reposting in #_oftc_#freedesktop:matrix.org.
agd5f_ has quit []
agd5f has joined #dri-devel
frieder has joined #dri-devel
srslypascal is now known as Guest7579
srslypascal has joined #dri-devel
soreau has quit [Ping timeout: 480 seconds]
Guest7579 has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
dviola has quit [Ping timeout: 480 seconds]
robmur01 has joined #dri-devel
<bbrezillon>
gfxstrand, danvet, robclark: I was discussing page table pre-allocation with robmur01, to guarantee that no attempt to allocate page tables in the run_job() path would deadlock with the shrinker, and robmur01 asked if we could allocate with GFP_NOWAIT, and simply return an ERR_PTR(-ENOMEM) if the allocation fails. This should result in the job finished fence being signaled right
<robclark>
daniels, eric_engestrom: is there some metrics somewhere on how long various CI jobs take.. I thought there was some grafana thing but failing to find that now
<daniels>
robclark: look for the 'ci daily' label on issues - that shows which jobs routinely take the longest
<robclark>
bbrezillon: I was considering GFP_NOWAIT and just treating it as a gpu hang if it fails.. but that seems a be severe
<robclark>
daniels: thx
<daniels>
anything for stoney/volteer/sarien is going to get inflated since we regularly have to retry due to UART death
<gfxstrand>
bbrezillon: Yeah, it depends on just how bad of a corner you have to get wedged into for that to happen.
dviola has joined #dri-devel
<gfxstrand>
That is the worst-case fall-back but we need to be sure it won't happen in practice unless you're in a OOM situation so bad that it's only a matter of time before the system crashes.
<robmur01>
gfxstrand: said pagetables are always regular kernel pages allocated one at a time, so failure does imply system-wide memory pressure in general (which is why I'm inclined to think it's OK)
jljusten has joined #dri-devel
Duke`` has joined #dri-devel
<robclark>
the bad thing about VM_BIND going badly is you pretty much need to throw the whole context away and start over since it is an async error
<bbrezillon>
yeah, there's that
alyssa has joined #dri-devel
<robclark>
it's probably ok as a way to unblock things and more fwd.. but I kinda suspect it will be something to revisit
frieder has quit [Remote host closed the connection]
<gfxstrand>
airlied: ^^
<gfxstrand>
So, one thing I've considered is to have a concept of a VA reservation that happens as a separate ioctl which would provide opportunity for the kernel to allocate pages for page tables. The guarantee would then be that as long as your VM_BIND happens within a reserved range, it can't cause a context loss due to OOM.
Leopold has quit [Remote host closed the connection]
<robclark>
gfxstrand: that could always be done as sync part of the VM_BIND ioctl.. the problem really is just that robmur01 doesn't want to break the io-pagetable abstraction by letting the drm driver allocate it's pages ;-)
genpaku has quit [Read error: Connection reset by peer]
Leopold_ has joined #dri-devel
<gfxstrand>
robclark: Yeah, I've thought about that too.
bmodem has quit [Ping timeout: 480 seconds]
<gfxstrand>
robclark: Yeah, if io-pagetable is your abstraction, I can see that being... tricky.
<gfxstrand>
CPU and GPU make very different assumptions here
genpaku has joined #dri-devel
<robmur01>
It's not that I don't want to per se, just that it would be fiddly since it's really not designed that way - the point was to abstract the details that callers shouldn't have to care about, so guessing how many pages a given mapping might need is probably far from straightforward
<robclark>
it's all just code. it can be changed.. but seems fine to punt on that bit and just use GFP_NOWAIT to start
<robclark>
robmur01: hand-wavey idea I had was that it should be possible to calculate an upper bound, and drm driver just makes sure there are at least that many pages in it's pool of pre-allocated pages in the sync part of the ioctl
<robclark>
so doesn't need to be exact, just worst-case figure that io-pgtable hands back
Ahuj has quit [Ping timeout: 480 seconds]
<gfxstrand>
Yeah, figuring out how many an allocation would need is fiddly. You can figure out a worst-case pretty easily if you know the page table structure. However, once you take various forms of hugepages into account, getting an exact count is impossible until you go to map. You can also end up increasing the PT count on unmap if you haven't reserved a worst-case amount if you unmap part of a hugepage.
Leopold_ has quit [Remote host closed the connection]
<robclark>
right.. but at the cost of wasting some small # of pages I think it should be doable to just ensure there is always a worst-case amount available.. ie in the unmap path you can split at most two huge pages so just need that # of spare pages around
Leopold_ has joined #dri-devel
soreau has joined #dri-devel
<eric_engestrom>
DavidHeidelberg[m]: feature request for ci_run_n_monitor: ability to pass `--pipeline 123` instead of `--rev $sha`, for when it fails to find the pipeline (or picks the wrong one) :)
junaid has joined #dri-devel
<danvet>
bbrezillon, does this mean the job fails when userspace would have legitimately expected it to succeed?
soreau has quit [Read error: Connection reset by peer]
alyssa has joined #dri-devel
alyssa has left #dri-devel [#dri-devel]
<gfxstrand>
robclark: For a single unmap, yes. But you may have N unmaps queued which each split two hugepages.
<robclark>
yeah
<robclark>
the question is whether 2*N pages laying around is reasonable or not. I guess the upper limit would be worse in the map case
<robclark>
I haven't done the math yet.. but it _seems_ like there could be a reasonable upper bound
tzimmermann has quit [Quit: Leaving]
<robmur01>
yup, worst-case means preallocating somewhat more than 1/512 * N * M, where N is the maximum size of any mapping and M is the maximum number of mappings which may happen concurrently
<robclark>
that doesn't seem too bad.. and a lot more reasonable than trying to calc an exact figure
<robmur01>
given that it only matters in low-memory situations, holding on to that many pages which in practice we almost certainly don't need seems counterproductive :/
<robclark>
I guess you'll have a lot more pages of GEM buffers
<robclark>
but.. I think it would be ok to start with gfp flags to get something working as a first step
<robmur01>
not as if it's hard to reach OOM on typical things that run Panfrost, to test the real-world impact :)
idr has joined #dri-devel
mohamexiety has quit []
<robmur01>
TBH once I get the freelist stuff hooked up in io-pgtable there will likely already be a temporary freelist in map, so recycling pages off that isn't much of a stretch.
<robmur01>
From there it's not too unthinkable to potentially pass in a non-empty "freelist" from outside, but what I really wouldn't want to have to deal with is synchronisation if said list is scoped any wider than per-call (like the freelist is in normal operation)
<robclark>
pretty much any chromebook with <= 4G of ram (plus zram swap) is doing lots of reclaim by the time you open up a average # of tabs
greenjustin has joined #dri-devel
smiles has quit [Ping timeout: 480 seconds]
lynxeye has quit [Quit: Leaving.]
<cwabbott>
dschuermann_: here's another fun issue with divergence analysis - we have to use a vector register for loading ssbo's even when loading from a uniform offset, and it appears that at least on certain gens loads can "tear" if there's an earlier store without a fence in between, where some threads in the wave see the earlier value and some see the later value, even if all threads are loading from the same location
<cwabbott>
the result is that the output isn't actually uniform and bad things happen when we assume it is (in this case skipping reconvergence for a branch based on its value)
<cwabbott>
I hope that doesn't happen on amd
<cwabbott>
(spec@arb_shader_storage_buffer_object@execution@ssbo-atomiccompswap-int is the test affected, for reference)
<cwabbott>
I wonder if the test is wrong for not including a fence between the atomic op and the load
fab has quit [Quit: fab]
fab has joined #dri-devel
pcercuei has quit [Ping timeout: 480 seconds]
agneli has quit [Remote host closed the connection]
agneli has joined #dri-devel
<cwabbott>
hmm, seems like vulkan memory model is much more strict here than the GLSL spec is
<cwabbott>
vulkan just says "Applications must ensure that no data races occur during the execution of their application." whereas GLSL has more hand-wavey language about stuff not becoming available
tursulin has quit [Ping timeout: 480 seconds]
<cwabbott>
*about writes not becoming available
MajorBiscuit has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
soreau has joined #dri-devel
DPA has quit [Ping timeout: 480 seconds]
<lumag>
jani, excuse me, just wanted to check for any updates on dsc helper series validation? I can ping drm-misc maintainers to get 1-5 in, but I'd probably restrain myself from doing that if we can get more or if I'd need to update any of the patches.
mbrost has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
ybogdano is now known as Guest7588
ybogdano has joined #dri-devel
ybogdano has quit []
hansg has joined #dri-devel
hansg has quit []
agneli_ has joined #dri-devel
agneli has quit [Ping timeout: 480 seconds]
Guest7507 has quit []
Daanct12 has joined #dri-devel
Daanct12 is now known as Danct12
JohnnyonF has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
Kayden has quit [Quit: _> office]
ybogdano has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
mbrost_ has joined #dri-devel
mvlad has quit [Remote host closed the connection]
mbrost__ has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
mbrost__ has quit []
mbrost__ has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
mbrost_ has quit [Ping timeout: 480 seconds]
dviola has left #dri-devel [#dri-devel]
DPA has joined #dri-devel
dviola has joined #dri-devel
<jani>
lumag: would be great to get other folks to review the various tables. I don't have the time right now
<lumag>
jani, I see
<lumag>
abhinav__, would it be possible for somebody to help with tables review?
DPA- has joined #dri-devel
<lumag>
jani, any other possible reviewers from Intel? AMD uses different approach, so they can not help us here.
DPA has quit [Ping timeout: 480 seconds]
<zmike>
DavidHeidelberg[m]: is it intended that virgl-iris-traces runs on all jobs? I just got one on a zink-only pipeline
DPA- has quit [Ping timeout: 480 seconds]
pcercuei has quit [Ping timeout: 480 seconds]
<anholt>
zmike: it won't run, that's .test-manual-mr.
<zmike>
ah
<zmike>
tremendous
mbrost__ has quit []
mbrost has joined #dri-devel
<abhinav__>
lumag QC will help with the tables in drm/dsc parts