APic has quit [Read error: Connection reset by peer]
Daaanct12 is now known as Danct12
APic has joined #dri-devel
APic has quit [Read error: Connection reset by peer]
APic has joined #dri-devel
APic has quit [Read error: Connection reset by peer]
<danvet>
bbrezillon, sry am a bit behind on mails
<danvet>
robclark, ^^ I guess more reasons for your igts to exercise failure paths :-)
APic has joined #dri-devel
APic has quit [Read error: Connection reset by peer]
APic has joined #dri-devel
APic has quit [Read error: Connection reset by peer]
APic has joined #dri-devel
APic has quit [Read error: Connection reset by peer]
thellstrom1 has quit []
rasterman has joined #dri-devel
thellstrom has joined #dri-devel
APic has joined #dri-devel
APic has quit [Read error: Connection reset by peer]
APic has joined #dri-devel
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #dri-devel
Danct12 has quit [Read error: Connection reset by peer]
Danct12 has joined #dri-devel
tarceri has quit [Read error: Connection reset by peer]
tarceri has joined #dri-devel
<danvet>
bbrezillon, ok now that I woke up: r-b: me, apologies for the mess
<danvet>
bbrezillon, uh strike that, why do we need the _rcu version?
<danvet>
drm_sched_fence_release_scheduled has the drm_sched_fence pointer already too
Daanct12 has joined #dri-devel
tarceri has quit [Read error: No route to host]
tarceri has joined #dri-devel
adjtm has quit [Remote host closed the connection]
adjtm has joined #dri-devel
Danct12 has quit [Ping timeout: 480 seconds]
Daaanct12 has joined #dri-devel
<bbrezillon>
danvet: the _rcu variant is so we can pass it to call_rcu()
<danvet>
bbrezillon, oh right, missed that
<danvet>
r-b: me
<bbrezillon>
ok, I'll queue it to drm-misc-next, thanks
Daanct12 has quit [Ping timeout: 480 seconds]
tursulin has joined #dri-devel
sdutt has quit [Ping timeout: 480 seconds]
f11f12 has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
mlankhorst has joined #dri-devel
mlankhorst_ has quit [Remote host closed the connection]
jkrzyszt has joined #dri-devel
adjtm is now known as Guest6573
adjtm has joined #dri-devel
X-Scale` has quit []
oneforall2 has quit [Quit: Leaving]
Lucretia has joined #dri-devel
Guest6573 has quit [Ping timeout: 480 seconds]
<danvet>
bbrezillon, thx for taking care of this fumble
<bbrezillon>
danvet: np
bcarvalho has joined #dri-devel
pcercuei has joined #dri-devel
APic has quit []
<danvet>
mlankhorst, könig pushed a fix to drm-misc-fixes instead of drm-misc-next-fixes
<danvet>
pls make sure it's not lost
<danvet>
I guess in general consult dim status to catch these
<danvet>
mripard, ^^ fyi
pendingchaos_ is now known as pendingchaos
sylware has joined #dri-devel
f11f12 has quit [Quit: Leaving]
iokill has quit [Ping timeout: 480 seconds]
oneforall2 has joined #dri-devel
iokill has joined #dri-devel
f11f12 has joined #dri-devel
sylware has quit [Quit: sylware]
gpoo has joined #dri-devel
thellstrom has quit [Remote host closed the connection]
thellstrom has joined #dri-devel
itoral has quit [Remote host closed the connection]
Hi-Angel has quit [Remote host closed the connection]
Hi-Angel has joined #dri-devel
vivijim has joined #dri-devel
vivijim has quit [Remote host closed the connection]
vivijim has joined #dri-devel
sdutt has joined #dri-devel
sdutt has quit []
sdutt has joined #dri-devel
Company has joined #dri-devel
camus has quit []
mattrope has joined #dri-devel
iive has joined #dri-devel
marex has joined #dri-devel
jewins has joined #dri-devel
Ahuj has quit [Ping timeout: 480 seconds]
<MrCooper>
emersion: re "amdgpu: atomic API and cursor/overlay planes", does the atomic API now allow fully asynchronous cursor movement?
Daanct12 has joined #dri-devel
Daaanct12 has quit [Read error: Connection reset by peer]
Daaanct12 has joined #dri-devel
<emersion>
MrCooper: not yet
Danct12 has joined #dri-devel
heat has joined #dri-devel
Daanct12 has quit [Ping timeout: 480 seconds]
<MrCooper>
then I'm afraid more user space will want to use the legacy cursor ioctl even with atomic otherwise
<MrCooper>
e.g. Xorg would be unusable with the atomic API for the cursor then
Duke`` has joined #dri-devel
Daaanct12 has quit [Ping timeout: 480 seconds]
<ajax>
how much of that is Xorg failing to coalesce cursor updates to something like a frame boundary?
sneil has quit [Quit: Leaving]
camus has joined #dri-devel
f11f12 has quit [Quit: Leaving]
<ajax>
if the problem is we have to queue a flip immediately on cursor motion, and therefore we're always 16ms behind, then... doctor it hurts?
<robclark>
there are other userspaces that combine atomic ioctl + legacy cursor.. like CrOS :-(
<emersion>
robclark: xorg doesn't use atomic though
<robclark>
drm/msm does shenanigans to defer cursor update until close to vblank in hopes of merging it with a pageflip
nchery has joined #dri-devel
<ajax>
robclark: also an entirely reasonable approach
<ajax>
maybe i don't understand how brutally complicated enqueueing a flip is but i would really hope you could defer finalizing cursor position to, i dunno, vblank start.
<emersion>
MrCooper: i never understood the urge for async cursor upates tbh… does it even make sense if the compositor sets up the KMS state right before vblank?
<robclark>
I think part of the issue is legacy pageflip+cursor gets turned into atomic on kernel side..
<MrCooper>
ajax: possible of course, though that would be more or less the opposite of "silken mouse" :)
jessica_24 has joined #dri-devel
<MrCooper>
emersion: the Xorg modesetting driver has some (currently hardcoded disabled, but some people are discussing allowing it to be enabled again) atomic support, but not for the cursor
<emersion>
yeah, it's broken
<MrCooper>
the general appeal of async cursor updates is that the cursor stays fully responsive even if the display manager misses a refresh cycle
<emersion>
that doesn't seem like a good starting point…
<ajax>
MrCooper: if i can get an ioctl for GetCurrentScanline we can race the beam ;)
<MrCooper>
the current atomic API won't move the cursor before next vertical blank though?
<ajax>
right. ngh
<robclark>
at least in the arm SoC side of things, I think it is uncommon to have a truly async cursor.. everything I've worked on, it doesn't update until vblank (with some older gens not using double buffered registers so you had to be very careful to only write them during vblank)
<MrCooper>
the cursor not actually moving outside of vblank isn't a big deal; the cursor completely missing a refresh cycle can feel pretty jarring for the user though, so at least pseudo-async updates which are latched during vblank would be nice
<MrCooper>
in other words, don't force the cursor to miss a cycle as well if a page flip does
<MrCooper>
which is more or less what the legacy cursor ioctl provides ATM (assuming the KMS driver supports async cursor updates)
<swick>
MrCooper: isn't that just amending commits and not async commits?
<MrCooper>
does amending commits allow a cursor update to take effect while the corresponding page flip gets delayed?
<swick>
mhh, good point
gouchi has joined #dri-devel
<bnieuwenhuizen>
well, if it can wait until vblank, when does it even happen? (which vblank). Since AFAIU for the compositors that have problems with delayed commits this is mostly because they don't wait for implicit sync to finish with the buffer.
<bnieuwenhuizen>
for HW without the ability to amend commits this sounds like doing the compositors work, and for HW which does support it I'd like full support so that it can be used for triple buffering :)
<swick>
compositors can miss deadlines even if they waited for all client buffers to be ready
<swick>
you would have to wait for all compositor buffers to become ready and then commit but that increases the chance of missing the deadline
<bnieuwenhuizen>
on HW that doesn't support amending commits internally the driver would try to do the exact same thing, no?
<swick>
I guess, yeah
rsalvaterra_ has joined #dri-devel
<swick>
the KMS mailbox model is just bad :/
achrisan has joined #dri-devel
rsalvaterra has quit [Ping timeout: 480 seconds]
frieder has quit [Remote host closed the connection]
<MrCooper>
the driver should be less likely to miss the deadline than the compositor, though I agree even the latter may be good enough if it only submits idle buffers to KMS
mlankhorst has joined #dri-devel
idr has joined #dri-devel
APic has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
Duke`` has quit []
Duke`` has joined #dri-devel
alatiera has joined #dri-devel
jhli has joined #dri-devel
f11f12 has joined #dri-devel
ngcortes has joined #dri-devel
hch12907 has joined #dri-devel
hch12907_ has quit [Ping timeout: 480 seconds]
pendingchaos has quit [Ping timeout: 480 seconds]
pendingchaos_ has joined #dri-devel
nirmoy has joined #dri-devel
pendingchaos_ is now known as pendingchaos
camus has quit []
sneil has joined #dri-devel
melissawen has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
siqueira has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
melissawen has joined #dri-devel
siqueira has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.2]
bcarvalho has quit [Remote host closed the connection]
bcarvalho has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
bcarvalho_ has joined #dri-devel
bcarvalho has quit [Read error: Connection reset by peer]
hch12907_ has joined #dri-devel
bcarvalho_ has quit [Remote host closed the connection]
hch12907 has quit [Ping timeout: 480 seconds]
melissawen has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
siqueira has quit []
melissawen has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
siqueira has joined #dri-devel
mbrost has joined #dri-devel
mlankhorst has quit [Ping timeout: 480 seconds]
Mershl[m] has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
just_passing_by has joined #dri-devel
ngcortes has joined #dri-devel
siqueira has quit []
melissawen has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
melissawen has joined #dri-devel
siqueira has joined #dri-devel
gouchi has quit [Remote host closed the connection]
danvet has quit [Ping timeout: 480 seconds]
JoshuaAshton_ has joined #dri-devel
pepp has quit [Remote host closed the connection]
pepp has joined #dri-devel
<zmike>
how is glVertexAttribDivisor supposed to be handled with negative divisors?
<daniels>
zmike: ^ you know you're in trouble when myself & Ilia are agreeing
<imirkin_>
it's a cold day in hell...
<zmike>
ah I didn't trace it back far enough; it's negative in gallium because for some reason it's an int there
<daniels>
imirkin_: even a broken calendar is right once a ... well I can't quite be bothered googling it since I'll get stuck in a rathole, but some amount of time
<alyssa>
zmike: Not sure how instance divisors work in Vulkan, but in at least one of my drivers UINT_MAX is special cased.
tlwoerner has quit [Quit: Leaving]
<zmike>
🤔
<HdkR>
:thonk:
<alyssa>
(AGX compiler, we special cased it to just ID == max ? 1 : 0.)
<alyssa>
For Panfrost ... ummmm .... Mali instancing is stupidly complicated because of all the optimizations and I'm not being paid to think through what happens with UINT_MAX 😋
dviola has joined #dri-devel
<alyssa>
I think it just gets forced to "always pick attribute 0" which I guess is technically wrong if you manage to draw 4 billion points on a poor little mali.
<zmike>
I'm just gonna clamp it for now since that's at least better than exploding
<mareko>
hm, prime on the vulkan side needs quite some work to be viable
<bnieuwenhuizen>
what do you mean? isn't it working now?
<mareko>
it's probably working, but the FPS is lower than non-prime while it can be almost the same as non-prime
<bnieuwenhuizen>
what is the main problem you think?
<bnieuwenhuizen>
I know that doing the copy on the transfer queue could potentially be nice, but no idea about whether that is significant
<mareko>
there are two: 1) the linear buffer should be allocated by the display GPU driver, not the render GPU driver, to enable P2P DMA and thus skip a linear->scanout blit on the display GPU
adjtm has quit [Remote host closed the connection]
adjtm has joined #dri-devel
<bnieuwenhuizen>
I thought the linear buffer was in host memory was generally enough for APUs? (yes I know we also need it to be USWC, but at least for AMD+AMD that should work I think)
<mareko>
2) use the transfer queue, which has the advantage that it's parallel with gfx and doesn't steal any CU resources from gfx for the next frame
<mareko>
the next frame rendering and the copy can execute in parallel because there are no dependencies
iive has quit []
<bnieuwenhuizen>
btw big question I have with the transfer queue is that it can't (at least pre-RDNA2, not sure what is up with RDNA2) read DCC compressed images, so to what extent would it be beneficial to do a low-wave-count optimized compute based copy instead?
<mareko>
bnieuwenhuizen: sdma is faster if it can run in parallel because a low-wave-count compute still consumes CU resources; SDMA can also do compression the same way shaders do it (minus hw bugs)
<airlied>
it might be possible to expose the transfer queue internally in the driver just for prime blits
<airlied>
exposing it to the API is a disaster
tursulin has quit [Read error: Connection reset by peer]
<mareko>
agreed
<bnieuwenhuizen>
well, the "minus bugs" part tends to be half of the story with SDMA it seems :P
<bnieuwenhuizen>
but yeah that seems reasonable
<mareko>
we might add SDMA back just for prime blits
<airlied>
bnieuwenhuizen: it also doesn't handle sparse at all, so at least amdvlk switches to compute in those cases
<airlied>
like as long as prime blits are tiled->linear sdma should be fine
<airlied>
it just chokes bad when tiled->tiled
<bnieuwenhuizen>
huh, I thought Nicolai said sparse worked from GFX9+
<airlied>
bnieuwenhuizen: I haven't checked amdvlk in a while, but last I looked it used a compute for transfer if sparse was enabled
* airlied
wonders where my last transfers branch went
<mareko>
what is wrong with tiled->tiled? prime blits are full surface blits, so coord alignment restrictions don't matter
* bnieuwenhuizen
has memories of airlied implementing a copy per line to work around some SDMA issues
<mareko>
modifiers can give us tiled->tiled for prime
<bnieuwenhuizen>
my vague recollection was that it craps out at certain strides/widths
<airlied>
yeah there is some narrow eye of the needle you can thread to use it
<bnieuwenhuizen>
I'd be half for doing that via compute if we have a compute fallback anyway
<airlied>
"// That said... what does "except HW rotation" mean? Until we know what it means just ignore it to be safe."
<airlied>
my favourite comment :-P
<mareko>
T2T blits whole 256B tiles and doesn't care about the layout within tiles, so the code is correct
<bnieuwenhuizen>
for prime that is annoying
<bnieuwenhuizen>
because on RDNA2 (+?) the_R tiling is likely different between the source and destination GPU, and anything besides _R excludes DCC
<mareko>
yes
<mareko>
luckily, we can hardcode linear in Mesa for prime regardless of modifiers
<airlied>
bnieuwenhuizen: looks like gfx9 can do it transfers for sparse alright
<mareko>
let's ignore that T2T exists
<bnieuwenhuizen>
for tiled->tiled with the same swizzle mode the other params are probably also equal and we could just do a buffer copy and be done with it