ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
fxkamd1 has quit []
sarnex_ has quit []
sarnex has joined #dri-devel
ybogdano3 has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
maxzor has quit [Ping timeout: 480 seconds]
<Lynne>
driver dev life must be a fun life
<Lynne>
it's fun when things work
<Lynne>
and when they don't, it's a 5 minute wait to reboot while staring at vendor firmware for way too long
<airlied>
you get used to two machines and reading email in the breaks
nchery has quit [Quit: Leaving]
nchery has joined #dri-devel
<Lynne>
yup, it was the lack of a slice buffer pool
<Lynne>
638fps
<Lynne>
vs 858fps on nvdec
<Lynne>
radv too good for silly pooling, +5fps
Haaninjo has quit [Quit: Ex-Chat]
<Lynne>
on a 120mbps 4k intra-only h264
<airlied>
Lynne: nice, yeah radv probably not as delicate as nvidia there
<Lynne>
not even any meaningful difference on a bog standard low bitrate hevc movie either
<Lynne>
and yet radv is still considered beta-quality
yuq825 has joined #dri-devel
<Lynne>
I do wish av1 and vp9 decoding were standardized
<airlied>
Lynne: we should write an av1 ext in public :-P
<Lynne>
hey, why wait, I know someone who can write drivers and someone who can write an implementation and some silly system headers
<Lynne>
that aside, av1 has a much simpler header structure and ref frame structure
<Lynne>
because OBUs (AV1ese for NALs) were more of an afterthought by those who couldn't imagine life without MPEGisms
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
<Lynne>
airlied: 4%!!!
<Lynne>
faster than nvdec
<airlied>
Lynne: yay!
<airlied>
what did you fix?
ybogdano is now known as Guest2417
<Lynne>
it made zero difference on RADV, but I guess at least one party's happy
ybogdano has joined #dri-devel
<Lynne>
well, I have code to emulate multiple queue indices, and Zlatinski's suggestion was to have multiple command buffers and fences
<Lynne>
so I just put 32 virtual queue indices in there and that made it fast
Guest2417 has quit [Ping timeout: 480 seconds]
ybogdano has quit [Read error: Connection reset by peer]
ybogdano has joined #dri-devel
heat_ has quit [Read error: No route to host]
heat has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
q4a1 has joined #dri-devel
<airlied>
Lynne: tried to move the bit stream buffer to GTT, didn't seem to help
<airlied>
vaapi put it there
<airlied>
actually it might have been ending up there anyways
<Lynne>
wouldn't really make a difference with resizable bar
q4a has quit [Ping timeout: 480 seconds]
maxzor has joined #dri-devel
<airlied>
Lynne: did you push the cmd fix?
FireBurn has joined #dri-devel
<Lynne>
I think I did, force pushed again anyway
<airlied>
seems to help a bit on radv here
<airlied>
Lynne: also sometimes vaapi randomly goes extra fast
<airlied>
got a run 880 fps, then usually 500 fps
<airlied>
Lynne: though the cmd fix seems to end up creating more memory allocations for buffers now
<Lynne>
should be fine, they're pooled and not very large
<FireBurn>
I'd be quite happy to a more MESA extensions they can then base EXT on
<Lynne>
airlied: maybe you should test on intra-only, since there are less bottlenecks there
<Lynne>
for both x264 and x265 you can use -g 1 -keyint_min 1 to generate intra-only files
maxzor has quit [Ping timeout: 480 seconds]
<airlied>
Lynne: frequent allocations of any size are bad for vulkan
<airlied>
it's really designed around the mode where you call vkAllocateMemory once for a pool
<airlied>
and then suballocate buffers from that
illwieckz_ has quit [Remote host closed the connection]
<Lynne>
well, the only possible vulkan allocations left are in the session itself
illwieckz has joined #dri-devel
<Lynne>
and when I tested doing it once, it didn't result in any gain
<Lynne>
plus, radv's pooling is pretty good
<Lynne>
vaapi also sends the parameters at the start of each frame
heat has quit [Ping timeout: 480 seconds]
<airlied>
Lynne: I'm seeing allocations all the time now in the decode
<airlied>
ff_vk_get_decode_buffer
YuGiOhJCJ has joined #dri-devel
<airlied>
granted it probably is what is slowing it down here
<Lynne>
hmm
<Lynne>
yeah, I see what you mean
<Lynne>
buffers have to get resized often because they're all different sizes
lemonzest has joined #dri-devel
<Lynne>
just aligned slice buffers to the nearest power of two
<Lynne>
that eliminates pretty much all excessive allocation
<Lynne>
and helps with fragmentation management somewhat
<Lynne>
ought to have 2 pools, one for keyframes and one for I-frames, but that's ricing territorry for now, I think
aravind has joined #dri-devel
Daanct12 has joined #dri-devel
<airlied>
Lynne: I thik the other things vaapi is winning on is having a thread doing the queue submits
<airlied>
not sure how possible that would be within ffmpeg design
<airlied>
but you'd have the recording and submit happening on different threads
* airlied
is staring at flamegraphs and can't spot anything really lese
<Lynne>
well, vaapi is a slice-based API
<Lynne>
I don't really see a way of beating it with frame-based threading
Daanct12 has quit [Ping timeout: 480 seconds]
<Lynne>
plus, it's slightly unfair, as the vaapi hwaccel never calls any sync functions
<airlied>
Lynne: well the driver does a threaded submit to hw
<airlied>
Lynne: whereas vulkan leaves that up to the app side
<airlied>
but apart from that I think it's fairly even
<Lynne>
the driver has something to thread with vaapi
<Lynne>
with vulkan, you get a single packet at the end
<Lynne>
we thread as much as it's possible within a GOP, the decoder itself doesn't wait for frames to be decoded so we do as much in parallel as possible, maybe it's all that could be done
<Lynne>
and of course, vaapi cheats by not having sync
<airlied>
Lynne: the stuff the driver threads is just the queue submission
<airlied>
so it would be exactly the same work that is synced on a mutex in ffmpeg
<airlied>
instead of blocking the submit on a mutex you'd pass it off to a thread
<airlied>
submits don't block for long but it's not a great thing to do under a mutex
<Lynne>
it takes ~2 microsecond to wait on the fence
<airlied>
that's not the problem it's solving
<Lynne>
that's literally the time it takes to do the function calls
<airlied>
queuesubmit with deps will do syncobj waits with the queue submit mutex hels
<airlied>
which will block all threads
<Lynne>
queue submission takes ~80 microseconds
<airlied>
yes so you have threads all blocking on that lock for that time
<Lynne>
if they submit, yes
<Lynne>
but (1000*1000)/(80*32) is still 400fps or so
<Lynne>
and that's if you had 32 threads waiting on it
Daanct12 has joined #dri-devel
<Lynne>
come to think of it, all the files I've been testing with only have a single slice
<Lynne>
so vaapi can't benefit from that
<airlied>
yeah that lock contention is pretty low, usually get it within 1ms
<Lynne>
could, err, the driver expose multiple queue indices?
<Lynne>
even if they're virtual
<Lynne>
nvidia does this for their graphics queue
<Lynne>
that way it could still do the same threaded submission
bmodem has joined #dri-devel
<airlied>
nope vulkan don't lie like that :-P
<airlied>
Lynne: actually is that queue submit properly locked?
<airlied>
ah the % sign
<airlied>
I do see a couple of queue submit outlies, likes 500msg
<airlied>
msg
<airlied>
mostly in the 100ms range here
cheako has quit [Quit: Connection closed for inactivity]
<Lynne>
well, nvidia lies
<Lynne>
and if I had to implement threaded submit myself, it would have to be global enough for all decode instances
<Lynne>
and that means extra API, tons of extra code
<Lynne>
it won't be a lie either, it's just not going to tell the truth, they're two very different things :)
<airlied>
nvidia actually has hw submission ctx for the queues
<airlied>
amd doesn't
<Lynne>
it doesn't have 16 of them, even on their older generations
<airlied>
yeah I expect it to be a useful feature for all vulkan queues, but I understand it would be a big lift
<airlied>
I'd hack up a prototype to see it would help, but really I'm within 10% of vaapi which is good enough for nwo
<airlied>
Lynne: it doesn't have 16 engines, it does have hw ctx going to one engine
<Lynne>
plus, AMD's decode units are mostly separate, you wouldn't want someone decoding mjpeg to block someone decoding h264 on the same context
<Lynne>
yeah, it's good enough for now
<airlied>
yeah ideally you'd have the submit thread per queue
<Lynne>
well, that's it for me tonight, guess I'll continue with encoding tomorrow
<airlied>
Lynne: cool, I'm just kicking anv around, but it still won't comply
junaid has joined #dri-devel
junaid_ has joined #dri-devel
junaid_ has quit []
junaid has quit []
junaid has joined #dri-devel
Duke`` has joined #dri-devel
Daanct12 has quit [Read error: Connection reset by peer]
ella-0 has joined #dri-devel
fab has joined #dri-devel
bgs has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
junaid has quit [Read error: Connection reset by peer]
dcz_ has joined #dri-devel
kts has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
fab has quit [Quit: fab]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
danvet has joined #dri-devel
ahajda_ has joined #dri-devel
rasterman has joined #dri-devel
fab has joined #dri-devel
tzimmermann has joined #dri-devel
<MrCooper>
DemiMarie: you're preaching to the choir :) not saying it's a good thing, just that it's current reality
tursulin has joined #dri-devel
JohnnyonFlame has joined #dri-devel
vliaskov has joined #dri-devel
mvlad has joined #dri-devel
djbw_ has quit [Read error: Connection reset by peer]
LordKalma has quit [Quit: Server has probably crashed]
LordKalma has joined #dri-devel
LordKalma has quit []
LordKalma has joined #dri-devel
f11f12 has joined #dri-devel
Leopold_ has joined #dri-devel
frieder has joined #dri-devel
LordKalma is now known as Guest2453
LordKalma has joined #dri-devel
LordKalma has quit []
LordKalma has joined #dri-devel
Guest2453 has quit [Ping timeout: 480 seconds]
frieder has quit [Remote host closed the connection]
LordKalma has quit [Quit: Server has probably crashed]
swalker__ has joined #dri-devel
LordKalma has joined #dri-devel
rgallaispou has joined #dri-devel
junaid has joined #dri-devel
Guest2454 has quit [Ping timeout: 480 seconds]
junaid has quit []
junaid has joined #dri-devel
narmstrong_ has quit []
narmstrong has joined #dri-devel
junaid has quit [Ping timeout: 480 seconds]
urja has quit [Ping timeout: 480 seconds]
urja has joined #dri-devel
krh_ is now known as krh
aravind has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
genpaku has quit [Remote host closed the connection]
genpaku has joined #dri-devel
urja has quit [Ping timeout: 480 seconds]
LordKalma has quit [Quit: Server has probably crashed]
LordKalma has joined #dri-devel
junaid has joined #dri-devel
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
pcercuei has joined #dri-devel
urja has joined #dri-devel
maxzor has joined #dri-devel
devilhorns has joined #dri-devel
maxzor has quit [Remote host closed the connection]
maxzor has joined #dri-devel
sgruszka has joined #dri-devel
pendingchaos has quit [Ping timeout: 480 seconds]
pendingchaos has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
junaid has quit [Ping timeout: 480 seconds]
junaid has joined #dri-devel
srslypascal is now known as Guest2463
srslypascal has joined #dri-devel
Guest2463 has quit [Ping timeout: 480 seconds]
junaid_ has joined #dri-devel
junaid_ has quit []
devilhorns has quit [Remote host closed the connection]
devilhorns has joined #dri-devel
devilhorns has quit []
junaid_ has joined #dri-devel
Lucretia has quit [Read error: Connection reset by peer]
Lucretia has joined #dri-devel
junaid_ has quit []
aravind has joined #dri-devel
devilhorns has joined #dri-devel
sgruszka has quit [Ping timeout: 480 seconds]
maxzor has quit [Remote host closed the connection]
maxzor has joined #dri-devel
maxzor has quit [Remote host closed the connection]
maxzor has joined #dri-devel
Namarrgon has quit [Quit: WeeChat 3.7.1]
Namarrgon has joined #dri-devel
<hays_>
apologies if this is the wrong place for this question -- is there a way to force switch between panfrost and the closed mali blob for the purposes of running a test
Akari has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
rgallaispou has left #dri-devel [#dri-devel]
<daniels>
hays_: not very easily, since Panfrost requires panfrost.ko and the DDK requires mali_kbase.ko, and the two both want to claim the same device
Leopold_ has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
kts has quit [Quit: Leaving]
Leopold_ has joined #dri-devel
sgruszka_ has joined #dri-devel
<DemiMarie>
MrCooper: what are you replying to?
<MrCooper>
<DemiMarie> MrCooper: if https://shadertoy.com (or any other website, for that matter) can lock a user’s machine and killing the browser does not fix the problem, this is a security vulnerability in the GPU driver.
<DemiMarie>
MrCooper: thanks
<DemiMarie>
Has anyone considered using syzkaller on GPU drivers?
<MrCooper>
pretty sure it's being done already, not that system calls are the main factor for GPU hangs
<DemiMarie>
What is? Lack of proper GPU preemption?
<MrCooper>
GPU HW & drivers being complex beasts
junaid_ has joined #dri-devel
<eric_engestrom>
mlankhorst, Ristovski: re- "free space is wasted space", have a look at nilfs :)
<eric_engestrom>
(tl;dr: it uses all the free space to keep as many old versions of files as it can)
<eric_engestrom>
"continuous snapshot"
<ishitatsuyuki>
that sounds like an awful idea when SLC cache also utilizes free space :/
<Ristovski>
lol
<ishitatsuyuki>
ok nvm, I missed the joke
junaid_ has quit []
cheako has joined #dri-devel
yuq825 has quit []
The_ASV has joined #dri-devel
junaid has quit [Read error: Connection reset by peer]
fxkamd has joined #dri-devel
devilhorns has quit []
Akari has quit [Quit: segmentation fault (core dumped)]
kts has joined #dri-devel
sgruszka_ has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
MrCooper_ has joined #dri-devel
MrCooper has quit [Ping timeout: 480 seconds]
The_ASV has quit [Remote host closed the connection]
The_ASV has joined #dri-devel
The_ASV has quit [Read error: Connection reset by peer]
<kisak>
fwiw, the initial issue reported in https://gitlab.freedesktop.org/mesa/mesa/-/issues/7848 should be resolved with Debian Sid and my mesa 22.3.1 build if someone feels like evaluating if they want to keep it open for the fast spining vkcube with lavapipe or failure to init hasvk with their xanmod modified kernel.
The_ASV has joined #dri-devel
maxzor has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
djbw_ has joined #dri-devel
f11f12 has quit [Quit: Leaving]
maxzor has joined #dri-devel
The_ASV has quit [Read error: Connection reset by peer]
The_ASV has quit [Read error: Connection reset by peer]
The_ASV has joined #dri-devel
<DemiMarie>
MrCooper: do you know any i915 experts? i915 has a nasty cache coherence bug that can easily be reproduced by changing Linux’s PAT.
swalker__ has quit []
ybogdano has joined #dri-devel
MrCooper_ is now known as MrCooper
<MrCooper>
DemiMarie: #intel-gfx might be better for that, though there should be a few i915 devs here as well
<MrCooper>
kusma: BTW, amoeba runs great on a 240 Hz monitor, locked 240 fps :)
tzimmermann has quit [Quit: Leaving]
rasterman has quit [Quit: Gettin' stinky!]
<kusma>
Great!
junaid has joined #dri-devel
krushia has joined #dri-devel
Akari has joined #dri-devel
junaid has quit [Quit: leaving]
bwidawsk_ has quit []
bwidawsk has joined #dri-devel
hays_ is now known as hays
Namarrgon has quit [Ping timeout: 480 seconds]
Namarrgon has joined #dri-devel
vv221 has joined #dri-devel
The_ASV has quit [Read error: Connection reset by peer]
The_ASV has joined #dri-devel
probablymoony has joined #dri-devel
moony has quit [Read error: Connection reset by peer]
The_ASV has quit [Read error: Connection reset by peer]
vliaskov has quit []
jfalempe has quit [Quit: Leaving]
<robclark>
DemiMarie, MrCooper: i915 and msm (and img rogue, presumably the downstream driver used in some chromebooks) and core drm ioctls are described for syzkaller.. looks like amd is missing, which is unfortunate because otherwise it would get coverage in CrOS labs
<DemiMarie>
robclark: are those ioctls ever fuzzed on machines that actually have the hardware?
Haaninjo has joined #dri-devel
<robclark>
yes, that is the whole point of running syzkaller on hw in CrOS labs ;-)
The_ASV has joined #dri-devel
RSpliet has quit [Ping timeout: 480 seconds]
RSpliet has joined #dri-devel
The_ASV has quit [Read error: Connection reset by peer]
The_ASV has joined #dri-devel
junaid has joined #dri-devel
junaid_ has joined #dri-devel
junaid has quit [Read error: Connection reset by peer]
junaid has joined #dri-devel
junaid_ has quit [Read error: Connection reset by peer]
The_ASV has quit [Read error: Connection reset by peer]
junaid has quit [Read error: No route to host]
junaid has joined #dri-devel
The_ASV has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: WeeChat 3.6]
ybogdano has quit [Ping timeout: 480 seconds]
<airlied>
Lynne: got vaapi on crocus on haswell working in my steps towards getting anv going :-P
rsjw has joined #dri-devel
* airlied
has to decide whether to port to hasvk first in order to get anv going
ahajda_ has quit []
ds` has quit [Quit: ...]
ds` has joined #dri-devel
junaid has quit [Ping timeout: 480 seconds]
krushia has quit [Read error: Connection reset by peer]
junaid has joined #dri-devel
The_ASV has quit [Remote host closed the connection]
<airlied>
Lynne: got anv to decode a h264
<Lynne>
nice!
<Lynne>
with P/B frames?
<airlied>
yup
<airlied>
at least jellyfish seems fine
<airlied>
Lynne: what is pic->reference and DELAYED_PIC_REF?
<airlied>
I ask because we are setting is_reference from it, but not sure it's working