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
<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?
<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
<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