ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
Jeremy_Rand_Talos_ has quit [Ping timeout: 480 seconds]
<jenatali> Ugh does the Vulkan CTS really override stdout redirection?
<alyssa> jenatali: just be grateful it's not the CL CTS
<jenatali> Yeah... different problems
<jenatali> I just want to be able to debug a NIR shader, but writing to stdout overflows my terminal buffer size
<jenatali> So I want to dump that to a file... but apparently I can't do that
<alyssa> ooof
<alyssa> at least it's not the CL CTS
<HdkR> change to stderr instead? :D
<alyssa> "oh yes we are just going to test every single possible input how many could there be?"
<jenatali> alyssa: Yeah the CL CTS isn't too bad when you use wimpy mode though
<alyssa> even with wimpy it's pretty bad ;p
<jenatali> Weird, looks like my debugger was messing with it, nevermind
ybogdano has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
cengiz_io has quit [Quit: Connection closed for inactivity]
yuq825 has joined #dri-devel
ahajda_ has quit []
mattrope has quit [Remote host closed the connection]
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
ngcortes has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
jkrzyszt has joined #dri-devel
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
mattrope has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
ppascher has quit [Ping timeout: 480 seconds]
jkrzyszt has quit [Ping timeout: 480 seconds]
Akari has quit [Quit: segmentation fault (core dumped)]
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
persise[m] has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
persise[m] has quit [autokilled: This host has violated network policy. Mail support@oftc.net if you feel this is in error. (2022-12-15 02:50:02)]
Company has quit [Quit: Leaving]
<Lynne> highly informative post by nvidia engineer on DPB reference indices
pjakobsson has joined #dri-devel
pjakobsson_ has quit [Ping timeout: 480 seconds]
camus1 has quit [Remote host closed the connection]
camus has joined #dri-devel
kailanqq[m] has joined #dri-devel
kailanqq[m] has quit [autokilled: This host has violated network policy. Mail support@oftc.net if you feel this is in error. (2022-12-15 03:42:50)]
heat has quit [Ping timeout: 480 seconds]
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
<airlied> agd5f: yeah not sure how patching vulkan cmd bufs will go, I suppose I get to find out when I hit encode
<airlied> Lynne: oh I also was to fix separate dpb for h265 on navi21+
<airlied> uggh fixing it break h264, need to figure out the reference pics there
<airlied> Lynne: be interesting to see if that helps the speed any, fixes are pushed
<Lynne> neat, give me a sec
<Lynne> sadly no, speed is the same as before
<Lynne> at least it works, no corruption or crashes
bmodem has joined #dri-devel
<Lynne> ...just as I wrote that, I tried h264, and got a crash bad enough to have to reboot
<Lynne> yup, it's consistent, reverting the last commit fixes it
<airlied> Lynne: dang what video? I had just tested some 264
<airlied> okay fantastic four trailer killed it for me
<Lynne> some 4k high bitrate I had
<Lynne> aww, good thing you didn't try fan4stic, you may have needed a new card after it
<airlied> Lynne: is this legal?
<airlied> (gdb) print *frame_info->pSetupReferenceSlot
<airlied> $6 = {sType = VK_STRUCTURE_TYPE_VIDEO_REFERENCE_SLOT_INFO_KHR, pNext = 0x7fffd804a850, slotIndex = 0, pPictureResource = 0x7fffd8049bf0}
<airlied> (gdb) print *frame_info->pReferenceSlots
<airlied> $7 = {sType = VK_STRUCTURE_TYPE_VIDEO_REFERENCE_SLOT_INFO_KHR, pNext = 0x7fffd804abc8, slotIndex = 0, pPictureResource = 0x7fffd8049c40}
<airlied> for h264
<Lynne> the slotIndex?
<airlied> yeah
<airlied> seems wrong to have them both be 0
<airlied> though maybe it's fine
<Lynne> I have a not sure mark on it in my code, because vaapi uses "pic->long_ref ? pic->pic_id : pic->frame_num;" for it
<Lynne> it didn't change anything last time I tried it
pjakobsson_ has joined #dri-devel
<Lynne> output looks identical before and after, just tried it
<airlied> yeah just trying to see why this separate stuff is getting angry and noticed it
<airlied> still hangs when I fix it :-P
pjakobsson has quit [Ping timeout: 480 seconds]
* airlied backs out the change for now
<Lynne> I'll make the slotIndex change, just seems more correct as that's what other code uses
<airlied> Lynne: I think we still have some bugs around h264 dpb indexing
<airlied> Lynne: is there somewhere that tracks the DPB in h264?
<airlied> I think we should do the same thing for h264 as for 265 using DPB
<Lynne> I'm not sure, haven't seen anything like that in other hwaccels
<Lynne> I don't remember any dbp bugs in h264
<Lynne> but I do believe that's it for me tonight
<airlied> yeah I'm just seeing this when I try to control the dpb placements manually
<airlied> or sparsely rather
<airlied> the slotindex just don't make sense
<airlied> I'll dig around and what I can figure out now
<airlied> Lynne: yeah I think that is correct
<airlied> Lynne:other APIs have never had explicit DPB mgmt
<airlied> Lynne: pushed the corresponding radv fixes to my branch
kts has joined #dri-devel
lemonzest has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
bgs has joined #dri-devel
Duke`` has joined #dri-devel
itoral has joined #dri-devel
<airlied> Lynne: https://paste.centos.org/view/e2cfd025 rebased version
aravind has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
fab has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
yuq825 has quit []
danvet has joined #dri-devel
bgs has quit [Remote host closed the connection]
yuq825 has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
bgs has joined #dri-devel
dv_ has quit [Quit: WeeChat 3.0]
dcz_ has joined #dri-devel
bgs has quit [Remote host closed the connection]
dv_ has joined #dri-devel
dv_ has quit []
dv_ has joined #dri-devel
fab has quit [Quit: fab]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
frieder has joined #dri-devel
maxzor has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
<mripard> airlied: danvet : There's nothing in drm-misc-next-fixes, so there won't be a PR
tobiasjakobi has joined #dri-devel
mvlad has joined #dri-devel
tobiasjakobi has quit []
<airlied> mripard: cool!
off^ has quit [Remote host closed the connection]
ppascher has joined #dri-devel
fab has joined #dri-devel
jkrzyszt has joined #dri-devel
lanodan has quit [Ping timeout: 480 seconds]
camus has quit [Remote host closed the connection]
* airlied has paged back in enough of intel avc decode to realise I've no idea how it works
camus has joined #dri-devel
tursulin has joined #dri-devel
lanodan has joined #dri-devel
tzimmermann has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
<ccr> via eldritch dark magic?
sarahwalker has joined #dri-devel
Akari has joined #dri-devel
swalker_ has joined #dri-devel
swalker_ is now known as Guest2216
lynxeye has joined #dri-devel
vliaskov has joined #dri-devel
sarahwalker has quit [Ping timeout: 480 seconds]
nchery has quit [Remote host closed the connection]
nchery has joined #dri-devel
ahajda_ has joined #dri-devel
yuq825 has quit []
jagan_ has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
yuq825 has joined #dri-devel
frieder has quit [Quit: Leaving]
frieder has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Read error: No route to host]
jkrzyszt has quit [Remote host closed the connection]
tursulin has quit [Quit: Konversation terminated!]
tursulin has joined #dri-devel
MajorBiscuit has joined #dri-devel
itoral has quit []
fab has quit [Quit: fab]
fab has joined #dri-devel
jkrzyszt has joined #dri-devel
Akari has quit [Quit: segmentation fault (core dumped)]
kts has quit [Read error: Connection reset by peer]
kts has joined #dri-devel
yuq825 has quit []
pjakobsson has joined #dri-devel
pjakobsson_ has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
warpme_____ has joined #dri-devel
pcercuei has joined #dri-devel
MajorBiscuit has quit [Quit: WeeChat 3.6]
MajorBiscuit has joined #dri-devel
devarsht[m] has joined #dri-devel
aradhya7[m] has joined #dri-devel
LordKalma has quit [Quit: Server has probably crashed]
LordKalma has joined #dri-devel
lanodan has quit [Quit: WeeChat 3.6]
JohnnyonFlame has joined #dri-devel
Haaninjo has joined #dri-devel
srslypascal is now known as Guest2231
srslypascal has joined #dri-devel
lanodan has joined #dri-devel
Guest2231 has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
srslypascal has quit [Ping timeout: 480 seconds]
xantoz has quit [Remote host closed the connection]
zzag_ has quit []
Company has joined #dri-devel
zzag has joined #dri-devel
xantoz has joined #dri-devel
srslypascal has joined #dri-devel
kts has joined #dri-devel
djbw has quit [Read error: Connection reset by peer]
f11f12 has joined #dri-devel
maxzor has joined #dri-devel
egbert has quit [Remote host closed the connection]
yuq825 has joined #dri-devel
lynxeye has quit [Ping timeout: 480 seconds]
<graphitemaster> Looking forward to bringing down Linux distributions one stray long running compute shader at a time loaded directly in your browser without you even aware of it, activated all on the same day, served from a CDN silently, stealthy, the day every Linux freezes. https://twitter.com/Tojiro/status/1603087438150217728
<graphitemaster> Sorry, I'm writing a horror novel, let me know if you like my premise.
<ishitatsuyuki> wasn't that basically the same with webgl anyway
agd5f has quit [Remote host closed the connection]
cengiz_io has joined #dri-devel
lynxeye has joined #dri-devel
<zamundaaa[m]> graphitemaster: Wouldn't a shader that runs long enough to freeze other GPU tasks just trigger a GPU reset?
<FLHerne> reliability of GPU resets for most Linux kernel drivers is quite poor
bgs has joined #dri-devel
devilhorns has joined #dri-devel
maxzor has quit [Remote host closed the connection]
maxzor has joined #dri-devel
alarumbe has joined #dri-devel
maxzor has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
navi has joined #dri-devel
agd5f has joined #dri-devel
yuq825 has left #dri-devel [#dri-devel]
<ishitatsuyuki> it's just amdgpu that is bad lol
<ishitatsuyuki> friendly reminder that GL CTS has a test that contains infinite loop to test resets
tzimmermann has quit [Quit: Leaving]
tzimmermann has joined #dri-devel
kts has joined #dri-devel
jagan_ has quit [Remote host closed the connection]
mbrost has joined #dri-devel
camus1 has quit [Remote host closed the connection]
camus has joined #dri-devel
heat has joined #dri-devel
<FLHerne> It's not just amdgpu; nouveau is pretty hopeless and intel used to be unreliable but it's less bad now
OftenTimeConsuming has quit [Quit: OftenTimeConsuming]
<DemiMarie> Does Intel support preemption?
OftenTimeConsuming has joined #dri-devel
<MrCooper> yes
<MrCooper> mutter 44 will take full advantage of this (as Wayland compositor), it can run at full frame rate even while there are GPU-limited clients at much lower frame rate
fxkamd has joined #dri-devel
Leopold_ has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Read error: Connection reset by peer]
<zamundaaa[m]> ishitatsuyuki: amdgpu gpu resets work mostly fine here
<zamundaaa[m]> the bigger problem is userspace...
MajorBiscuit has quit [Read error: Connection reset by peer]
jkrzyszt has quit [Remote host closed the connection]
jkrzyszt has joined #dri-devel
The_ASV has joined #dri-devel
The_ASV has quit [Remote host closed the connection]
The_ASV has joined #dri-devel
The_ASV has quit []
kts has quit [Quit: Leaving]
The_ASV has joined #dri-devel
fab has quit [Quit: fab]
The_ASV has quit [Read error: Connection reset by peer]
The_ASV has joined #dri-devel
Testing has joined #dri-devel
Testing has quit []
The_ASV has quit [Remote host closed the connection]
jkrzyszt has quit [Remote host closed the connection]
The_ASV has joined #dri-devel
Akari has joined #dri-devel
f11f12 has quit [Quit: Leaving]
<ishitatsuyuki> that too
<Ristovski> I patiently await the day some new webgpu exploit with a witty name comes out and causes all drivers to implement mitigations that butcher performance
<ishitatsuyuki> I don't know why do you need to shit on the API so hard
<ishitatsuyuki> it's fine and it has some legitimate use cases
<Ristovski> it was mainly a joke :P I am actually pretty excited for webgpu myself
jkrzyszt has joined #dri-devel
<ishitatsuyuki> ah ok ;)
<Ristovski> Hopefully then Firefox will improve the efficiency of their GFX stack on Linux, chrome still beats it (esp. on older hardware)
<Ristovski> the webgl perf difference between firefox and chrome on my old Haswell is day and night
<ishitatsuyuki> did that change with dmabuf stuff or the disparity is still there
<Ristovski> dmabuf helped a bit (especially in vaapi video decode for example), but in general the difference is still there
<ishitatsuyuki> ok
<MrCooper> Ristovski: out of curiosity, what site(s) do you use for webgl perf testing?
kts has joined #dri-devel
<Ristovski> MrCooper: iirc even something like https://webglsamples.org/aquarium/aquarium.html (obviously selecting a higher num of fish makes the effect more apparent). Firefox also has higher CPU usage when playing a VAAPI decoded video for example
<Ristovski> given that machine is now my "spare", I could maybe try gathering some perf data hmmm
JohnnyonFlame has joined #dri-devel
<Ristovski> speaking of, can one hook up a spare machine as extra CI for mesa? I apparently have very cursed HW :)
lynxeye1 has joined #dri-devel
fab has joined #dri-devel
<MrCooper> Ristovski: indeed, Firefox runs at ~40 fps with 5000 fish, chromium with 15000
lynxeye has quit [Ping timeout: 480 seconds]
djbw has joined #dri-devel
<Ristovski> checks out
junaid has joined #dri-devel
Duke`` has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
jkrzyszt has joined #dri-devel
* pinchartl is scared to open the aquarium
<pinchartl> opening the shadertoys website (in Firefox or Chrome) locks up my i915 GPU after a few seconds
<MrCooper> not really the same thing :)
<pinchartl> and the deadlock detection and recovery doesn't work, I have to hard reboot
frieder has quit [Remote host closed the connection]
<MrCooper> shadertoys is nasty by design, "normal" webgl sites are generally safe
alyssa has quit [Quit: leaving]
<Ristovski> opening shadertoy is always fun, I can "hear" the shaders thanks to shitty filtering on my (old) mobo
kts has quit [Quit: Leaving]
<pinchartl> MrCooper: if it's that easy to lock up i915 from any untrusted website, there's a problem though
<Ristovski> (yes, vblank_mode=0 glxgears does make it _scream_)
<Ristovski> pinchartl: Hmm, might be worth filing a bug report then
mvlad has quit [Ping timeout: 480 seconds]
LordKalma has quit [Quit: Server has probably crashed]
<MrCooper> pinchartl: welcome to the wonderful world of GPUs
LordKalma has joined #dri-devel
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
vliaskov has quit [Remote host closed the connection]
navi has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
LordKalma has quit [Quit: Server has probably crashed]
LordKalma has joined #dri-devel
<pinchartl> MrCooper: I used to dream of working on GPUs when I was a student, I'm now relieved I didn't succeed :-)
<MrCooper> FWIW, I'm on the second page of shadertoy.com Browse, no hang yet with an AMD GPU
jkrzyszt has quit [Remote host closed the connection]
<MrCooper> some amazing stuff on there
<javierm> I'm curious but also have a i915 so I'm afraid to have a hard lock up as pinchartl mentioned :)
devilhorns has quit []
Guest2216 has quit [Remote host closed the connection]
<Ristovski> I have a Haswell running i915 as well, and it works fine for me
mvlad has joined #dri-devel
jkrzyszt has joined #dri-devel
fxkamd has quit []
fxkamd has joined #dri-devel
pcercuei has quit [Ping timeout: 480 seconds]
tursulin has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
rgallaispou has quit [Ping timeout: 480 seconds]
jhli_ has quit [Remote host closed the connection]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
The_ASV has quit [Read error: Connection reset by peer]
pcercuei has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
Akari has quit [Quit: segmentation fault (core dumped)]
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
maxzor has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
junaid has quit [Remote host closed the connection]
The_ASV has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
<Lynne> airlied: thanks, merged
<Lynne> also fixed the last todo in h264, scaling_list_present_mask
<Lynne> mesa doesn't use it, and doesn't fix nvidia, but it's now complete
The_ASV has quit [Read error: Connection reset by peer]
bnieuwenhuizen has quit [Quit: Bye]
bnieuwenhuizen has joined #dri-devel
<Lynne> also tried host mapping the slices buffer to avoid uploading, but didn't make a difference to speed
LordKalma has quit [Quit: Server has probably crashed]
LordKalma has joined #dri-devel
<Lynne> (also, should've linked to my blog post in your so folks know how to run the code, but w/e, too late for that now)
LordKalma has quit []
LordKalma has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.6]
<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.
ahajda_ has quit []
<airlied> Lynne: my current blogpost is kinda a placeholder
<airlied> the other blogpost needed a place to point to
<airlied> ill rewrite it next week
The_ASV has joined #dri-devel
<Lynne> yeah, I can get away with publishing bad blogs because spreading the news or not won't change the fact no one reads them
<airlied> Lynne: except people unhappy about the benchmark figures :-P
<airlied> Lynne: why do you create sps/pps lists for every frame? do they really change that often?
<airlied> the idea behind the vulkan api is that you should just create those as they come out of the stream, not on every frame
<psykose> i was going to say the other day you should be careful with the numbers since they're going to instantly become a phoronix headline :p
<airlied> yeah I'd back off on them a bit until we actualy spend time on perf, so far getting things correct has been more important
<mlankhorst> My disk space is now 99% utilized!
<airlied> but also I suspect nvidia beta drivers might come with requests to not benchmark things :-P
<Ristovski> mlankhorst: Remember, free space is wasted space!
<graphitemaster> re: the webgpu stuff, I think pushing it will help Linux along in getting resources put towards solving the whole userspace graphics preemption thing
tzimmermann has quit [Quit: Leaving]
<Lynne> of course my voice falls on deaf ears
<Lynne> I have complete respect in someone's opinion, who gave up on testing my code within 2 minutes and didn't bother investigate or attempt again
<Lynne> as for why I create SPS/PPS/headers on every frame - *state*
<Lynne> managing state in a decoder is the hardest part
<Lynne> you want to give every single frame the maximum chance of being decoded
<airlied> I don't see why that should matter though, you are reading a stream, every sps/pps will be processed in order won't it?
<Lynne> packets get lost, get corrupted, rotational velocidensity takes its toll on 10 year old mp3
<airlied> if there's a missing sps/pps then it'll screw up whether you handed it to the decoder sw once or every frame
<Lynne> the decoder internally does magic to compensate
<Lynne> we don't want another layer of magic on top
<Lynne> besides, it's really not that much data, most of it is a memcpy
<Lynne> couple of kilobytes, and the allocation is pooled just in case we get crafted input
<Lynne> I looked at whether it's a bottleneck but it's too insignificant to detect
The_ASV has quit []
<Lynne> by the decoder, I meant the ffmpeg parser really, there's a good reason why we call hwaccels hwaccels rather than decoders
<airlied> Lynne: like if sps/pps was done optimally I could optimise it a lot more in the driver
<airlied> I've just been lazy so far
<Lynne> (when cuda had its own decoder, complete with a parser, we had a separate h264_cuda decoder, and it was bad enough that no one really considered using it)
<Lynne> done optimally where?
lynxeye1 has quit []
<DemiMarie> Lynne: I really wish openH264 had HW accel support ☹️
<Lynne> the last original h264 patent should expire next year, I think?
<airlied> Lynne: by the decoder
<Lynne> well, how would you suggest that's done? like I said, it's not much overhead for us to set it?
<airlied> it's still memory allocation overhead for the backend
<Lynne> can't you pool it like we do?
<airlied> it creates vulkan objects
<airlied> those are usually just malloced
<airlied> the idea behind the API is you get the sps/pps sets you need and batch create them if you can
<airlied> then have the decode video call just reference the entries in the set
<Lynne> is that what the session template field is for when creating it?
<Lynne> other than that, you'd have to compare pointers the user gives you, which is ghetto
<Ristovski> Is there some other interface one can use instead of /sys/kernel/debug/ttm/page_pool_shrink?
* airlied isn't 100% sure how the templating bit is expected to work
<airlied> I think it's just a start from this point with a new set of parms
<airlied> but that idea is you should create a sized set, and update them as new ones come in
<airlied> not generate one every frame
<Lynne> how would the driver know they haven't been updated?
<airlied> the driver shouldn't have to care, the decoder would tell it when it gets updated ones
<airlied> like if seq_parameter_set_id is needed a frame, make sure you've given it to the driver before that
<airlied> but if the video just uses seq_parameter_set_id == 0 then just give it once
<airlied> Lynne: I wonder how much overheads there are just in driver init
<Lynne> in mesa, I didn't see much at all in perf, it was mostly in the kernel
<Lynne> still how would the decoder tell the driver the sets have been updated?
<Lynne> the reset flag?
<Lynne> OH, videoSessionParameters?
<Lynne> so video session == SPS/PPS/VPS data?
<airlied> videosessionparameters yes
macromorgan_ has joined #dri-devel
<Lynne> I thought it was decoding context, not a compiled list of headers
macromorgan is now known as Guest2265
Guest2265 has quit [Read error: Connection reset by peer]
macromorgan_ is now known as macromorgan
flibit has joined #dri-devel
<airlied> Lynne: in theory the driver can prebake part of the hw packets from those, at the moment I don't yet
<airlied> which means submitting individual decode video cmds should be faster
<Lynne> I can do it, I guess, though it'll be a per-frame memcmp of ~400kib on average
flibitijibibo has quit [Ping timeout: 480 seconds]
<Lynne> because due to frame threading, non-consecutive frames can be submitted out of order for decoders
<airlied> Lynne: do you not have the sps id from the stream? or is this part of the decoder working around broken things?
<Lynne> I'm not sure if it's trustworthy
<airlied> what do you do if a frame references an sps you haven't seen?
<Lynne> it's handled by the decoder
<airlied> though I don't reckon that is going to save a massive amount of clock time, it's just one place I know there is some
dcz_ has quit [Ping timeout: 480 seconds]
alyssa has joined #dri-devel
<alyssa> robclark: Any reason not to use BLIT for TEXTURE_TRANSFER_MODES on freedreno?
<airlied> Lynne: what's the equiv cmd line to time vaapi btw?
<alyssa> The gallium docs say to use BLIT for dGPUs and default for swrasts and doesn't give any guidance for iGPUs, and the drivers in tree all do different things
<airlied> just remove the init_hw_device and change others to vaapi?
<alyssa> otoh ccce9409470 ("v3d: Disable PIPE_CAP_BLIT_BASED_TEXTURE_TRANSFER.")
<alyssa> i guess it's going to depend entirely on whether you can be smart about the cache
JohnnyonFlame has joined #dri-devel
<Lynne> airlied: yup, "./ffmpeg_g -init_hw_device "vaapi=vk:/dev/dri/renderD128" -hwaccel vaapi -hwaccel_output_format vaapi -i TEST -an -sn -"
<Lynne> you can omit the init_hw_device (the vk is just a label)
<Lynne> -an -sn prevent decoding of audio and subtitles
<Lynne> err, there should be an -f null - at the end there to use the null muxer which just frees packets
<robclark> alyssa: we'll end up doing a blit internally to tiled and/or ubwc in many cases (depends on format/target/etc).. so using BLIT probably ends up doing two blits. or at the very least something not better than the current setup
ahajda_ has joined #dri-devel
<alyssa> robclark: hum, okay... it's not clear to me that should be the case though (though it may be)
<alyssa> without blit-based transfer, mesa will do BGRA->RGBA conversion on the CPU which isn't great
<alyssa> (versus a straight memcpy)
* airlied will see if I can hunt perf issue once I get kids sorted
<alyssa> AFAICT:
<alyssa> blit-based: 1 GPU blit + 1 memcpy from STAGING (i.e. write-back)
<robclark> I guess that at least hasn't shown up in the things I've profiled
<alyssa> transfer-based: 1 GPU blit (internal blit for ubwc -> linear) + 1 BGRA->RGBA conversion on the CPU
<robclark> but game startup isn't a thing I've looked at a whole lot
<alyssa> this is from profiling screenshots on wayland
<alyssa> which can spend a whole lot of time in glReadPixels if you're unlucky
<robclark> oh, for the readback?
<alyssa> ye
<alyssa> I guess both paths are doing 2 blits effectively
<alyssa> but at least you get the format conversion for free along one of them
<alyssa> the case where blit-based loses is if the framebuffer is linear in memory
<alyssa> blit-based is 1 blit to format convert on the GPU and 1 memcpy after
<alyssa> transfer-based is converting into the dest buffer in 1 pass
<alyssa> (on the CPU)
<alyssa> but if the framebuffer is write-combine, that might actually be slower.
<robclark> I think w/ blit based you'd get two blits, but from a quick look that could probably be solved if mesa/st used PIPE_BIND_LINEAR for the staging buffer.. but either way we are using cached coherent for the staging buffer which probably makes the format conversion less painful
<alyssa> right, I see
<alyssa> for a ubwc framebuffer, I see why 1 blit + 1 format conversion on the CPU as you get from transfer-based would win, yeah
<alyssa> or at least be no worse than the 1 blit + 1 memcpy on the CPU you'd get from blit-based + the BIND_LINEAR fix
<alyssa> (although maybe usage==STAGING should imply LINEAR, because STAGING is defined by gallium to be optimized for CPU access)
bgs has quit [Remote host closed the connection]
Duke`` has quit [Ping timeout: 480 seconds]
alyssa has left #dri-devel [#dri-devel]
mvlad has quit [Remote host closed the connection]
camus1 has joined #dri-devel
<Lynne> I gave calling vkCreateVideoSessionParametersKHR only if sps/pps/vps updated a go, but it didn't improve performance on nvidia
<Lynne> so I guess they haven't done that optimization either
ybogdano3 has joined #dri-devel
quantum5_ has joined #dri-devel
fxkamd1 has joined #dri-devel
tchar_ has joined #dri-devel
narmstrong_ has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
hfink_ has joined #dri-devel
cengiz_io_ has joined #dri-devel
SanchayanMaity_ has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
flto_ has joined #dri-devel
sarnex_ has joined #dri-devel
zf_ has joined #dri-devel
cengiz_io has quit [Ping timeout: 480 seconds]
SanchayanMaity has quit [Ping timeout: 480 seconds]
sarnex has quit [Read error: Connection reset by peer]
Mangix has quit [Read error: Connection reset by peer]
Mangix has joined #dri-devel
cengiz_io_ is now known as cengiz_io
quantum5 has quit [Ping timeout: 480 seconds]
hfink has quit [Ping timeout: 480 seconds]
dviola has quit [Remote host closed the connection]
agd5f has quit [Read error: Connection reset by peer]
mslusarz has quit [Remote host closed the connection]
mslusarz has joined #dri-devel
dviola has joined #dri-devel
djbw_ has joined #dri-devel
djbw has quit [Read error: Connection reset by peer]
fxkamd has quit [resistance.oftc.net larich.oftc.net]
mbrost has quit [resistance.oftc.net larich.oftc.net]
warpme_____ has quit [resistance.oftc.net larich.oftc.net]
alanc has quit [resistance.oftc.net larich.oftc.net]
tchar has quit [resistance.oftc.net larich.oftc.net]
zehortigoza has quit [resistance.oftc.net larich.oftc.net]
zf has quit [resistance.oftc.net larich.oftc.net]
flto has quit [resistance.oftc.net larich.oftc.net]
narmstrong has quit [resistance.oftc.net larich.oftc.net]
sumits has quit [resistance.oftc.net larich.oftc.net]
soreau has quit [resistance.oftc.net larich.oftc.net]
ybogdano has quit [resistance.oftc.net larich.oftc.net]
Mangix has quit [resistance.oftc.net larich.oftc.net]
agd5f has joined #dri-devel
Mangix has joined #dri-devel
mbrost has joined #dri-devel
fxkamd has joined #dri-devel
alanc has joined #dri-devel
zehortigoza has joined #dri-devel
warpme_____ has joined #dri-devel
flto has joined #dri-devel
zf has joined #dri-devel
sumits has joined #dri-devel
soreau has joined #dri-devel
sumits has quit [Ping timeout: 482 seconds]
zf has quit [Ping timeout: 482 seconds]
agd5f has quit [Remote host closed the connection]
fxkamd has quit [Ping timeout: 482 seconds]
mbrost has quit [Ping timeout: 482 seconds]
flto has quit [Ping timeout: 482 seconds]
agd5f has joined #dri-devel
flto_ has quit []
flto has joined #dri-devel
sumits has joined #dri-devel
pcercuei has quit [Quit: dodo]
<airlied> Lynne: yeah I'm going to guess it something sync related, so we are blocked rather than burning CPU
flibit has quit []
flibitijibibo has joined #dri-devel
<airlied> Lynne: how hard would it be to pool the slice data buffer memory?
<airlied> Lynne: so you'd do a larger allocate memory and do smaller updates to it?
<airlied> you also shouldn't destroy the slice buffer until semaphores have signalled
<airlied> ah you don't just reading the code now :)
ahajda_ has quit []
Mangix has quit []
Mangix has joined #dri-devel
JohnnyonFlame has quit [Read error: Connection reset by peer]
<Lynne> yeah, I forgot to write that, updated it
<Lynne> as for locking, hmm, I remember the kernel doesn't have a native representation of timeline semaphores
<Lynne> and converts them to regular binary semaphores internally
<Lynne> it has to wait for #semaphoes == #refs+2
<Lynne> the ref semaphores are pretty much guaranteed to be signalled by the time they have to be waited on
<Lynne> as there's only a single decode queue index
<Lynne> but we still have to wait on them
<Lynne> maybe explicit (read: actual) synchronization has its price?
<airlied> yeah I don't see any stalls around waiting there
fab has quit [Quit: fab]
<airlied> Lynne: ff_vk_free_buf does a full device idle
<airlied> that doesn't seem optimal
<airlied> not sure removing it helps, but it definitely not good idea
<Lynne> good point, done
heat_ has joined #dri-devel
<DavidHeidelberg[m]> added possibility to drop --rev for the ci_run_n_monitor.py into MR fixing unicode parsing: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20271 .
<DavidHeidelberg[m]> Any review welcome.
<Lynne> buffer uploading, then, maybe? it has to be done right before decoding, maybe there's a stall there
<airlied> Lynne: the allocate/free memory paths are definitely going to be slow
<airlied> vulkan really expects those to be managed and pool in the app
heat has quit [Ping timeout: 480 seconds]
<Lynne> fair enough, menial, but I can quickly write something up