ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<gawin>
btw nine-tests, noice ^^
<DavidHeidelberg[m]>
nah. it's just construct for compiling them in piglit. it needs lot of work
<DavidHeidelberg[m]>
and I'll probably don't have chance to spend time on it until next year, so if you're advanced piglit player, feel free to improve them :) I'll happily share authorship :D
<DavidHeidelberg[m]>
anyway on Panfrost, simpler stuff already working, arm64 support is ~ ok; we have zink for running Nine on random vulkan drivers, so in 2022-23 it seems there is future for the Gallium Nine
<DavidHeidelberg[m]>
performance wise, zink+nine seems to be nicer on low-end HW than dxvk :)
<gawin>
imho overall it shouldn't matter which design is used (polished and maintained solution X is gonna be better than unmaintained Y) but at least to my limited experience: vulkan doesn't hide hardware enough from apps. so if hardware is a bit exotic (behaves differently) or have unmaintained vulkan driver the nine may work better
<gawin>
now I see that I forgot about adding rb, maybe it's reason why marge is angry
T_UNIX has joined #dri-devel
<DavidHeidelberg[m]>
gawin: nah, it's windows runner has mental issues :)
Haaninjo has quit [Quit: Ex-Chat]
RSpliet has joined #dri-devel
srslypascal has quit [Ping timeout: 480 seconds]
HerrSpliet has quit [Ping timeout: 480 seconds]
<Lynne>
airlied: looking at dxva2_h264.c, it looks like long mode is more explicit
cphealy_ has quit []
bluepenquin has joined #dri-devel
fxkamd has quit []
bluepenquin is now known as Guest18
gawin has quit [Ping timeout: 480 seconds]
anholt has joined #dri-devel
sigmoidfunc[m] has joined #dri-devel
kunal_10185[m] has joined #dri-devel
srslypascal has joined #dri-devel
gawin has joined #dri-devel
FloGrauper[m] has joined #dri-devel
jenatali has joined #dri-devel
pmoreau has joined #dri-devel
pmoreau is now known as Guest23
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
masush5[m] has joined #dri-devel
knr has joined #dri-devel
Akari has quit [Quit: segmentation fault (core dumped)]
<Lynne>
I'd like to compare vaapi's speed on intel, but vaapi's such a hot mess there, I can't get it to run anymore
<Lynne>
who's idea was it to create 2 implementations that support mostly overlapping systems, one of which can purely only do decoding and is considered newer and therefore better, and one which can do encoding, decoding and post, but it's older, and therefore worse?
Daanct12 has joined #dri-devel
<Mangix>
Lynne: that sounds horrible
<Lynne>
intel-media-va and the venerable infallable i965
<Lynne>
intel seem to love doing the same work multiple times when it comes to video
<Lynne>
first, it was libva, then libyami, then their own qsv, then mfx, then onevpl, and I probably missed on
<Lynne>
all of these do video encode/decode, and all but one only work on for intel hw, despite attempt at making it the new standard
<Lynne>
a few of them were/are just libva wrappers
srslypascal is now known as Guest50
srslypascal has joined #dri-devel
orbea has quit [Quit: You defeated orbea! 2383232 XP gained!]
orbea has joined #dri-devel
Guest50 has quit [Ping timeout: 480 seconds]
srslypascal has quit [Ping timeout: 480 seconds]
srslypascal has joined #dri-devel
Daanct12 has quit [Read error: No route to host]
Daanct12 has joined #dri-devel
Daanct12 has quit [Remote host closed the connection]
camus1 has quit [Read error: Connection reset by peer]
Daanct12 has joined #dri-devel
camus has joined #dri-devel
Daaanct12 has joined #dri-devel
Daanct12 has quit [Read error: Connection reset by peer]
agd5f has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
lemonzest has joined #dri-devel
frytaped is now known as Guest52
Guest27 is now known as frytaped
Leopold_ has quit [Remote host closed the connection]
fab has joined #dri-devel
dcz_ has joined #dri-devel
alanc has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
alanc has joined #dri-devel
Duke`` has joined #dri-devel
<vjaquez>
hi Lynne and airlied :)
<airlied>
vjaquez: hey!
<airlied>
Lynne: i got the legacy vaapi working
<airlied>
i also have a vaapi mesa impl for crocus
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
Daaanct12 has quit [Remote host closed the connection]
kode54 has quit [Quit: Ping timeout (120 seconds)]
junaid has joined #dri-devel
kode54 has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
junaid has quit [Remote host closed the connection]
heat_ has quit [Ping timeout: 480 seconds]
SanchayanMaity_ has quit []
SanchayanMaity has joined #dri-devel
The_ASV has joined #dri-devel
rasterman has joined #dri-devel
<MrCooper>
kusma: btw, aurora ran great as well, though it didn't handle the 32:9 aspect ratio as well as amoeba
<kusma>
Yeah, I need to fix the aspect ratio stuff. It needs 1080p internally, but I should be able to pillar box it properly...
kts has quit [Quit: Leaving]
kts has joined #dri-devel
<MrCooper>
yep, that's what amoeba does
kts_ has joined #dri-devel
warpme_____ has quit []
kts has quit [Ping timeout: 480 seconds]
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
camus has quit [Remote host closed the connection]
danvet has joined #dri-devel
The_ASV has quit [Read error: Connection reset by peer]
The_ASV has joined #dri-devel
camus 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
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
OftenTimeConsuming has quit [Remote host closed the connection]
Company has joined #dri-devel
OftenTimeConsuming has joined #dri-devel
The_ASV has quit [Read error: Connection reset by peer]
kts has quit [Quit: Leaving]
The_ASV has joined #dri-devel
* ccr
sprays some particles and spinning polygons at kusma
The_ASV has quit [Read error: Connection reset by peer]
pcercuei has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
The_ASV has joined #dri-devel
Leopold_ has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
Leopold has joined #dri-devel
FireBurn has quit [Quit: Konversation terminated!]
FireBurn has joined #dri-devel
The_ASV has quit [Read error: Connection reset by peer]
The_ASV has joined #dri-devel
heat has joined #dri-devel
The_ASV has quit [Read error: Connection reset by peer]
The_ASV has joined #dri-devel
The_ASV has quit []
The_ASV has joined #dri-devel
The_ASV has quit [Read error: Connection reset by peer]
Leopold has quit [Remote host closed the connection]
pendingchaos has joined #dri-devel
Leopold has joined #dri-devel
kts has joined #dri-devel
kts has quit [Quit: Leaving]
Akari has joined #dri-devel
kts has joined #dri-devel
<Ristovski>
Lynne: dont forget intel retrospectively implemented vp8/9 decoding on BDW/HSW+ with (closed source :(( sadly) media kernels via "intel-hybrid-driver"
srslypascal is now known as Guest13
srslypascal has joined #dri-devel
<Ristovski>
Makes you wonder just how capable the hw is :) (theoretical hevc decoding via kernels possible?)
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #dri-devel
Guest13 has quit [Ping timeout: 480 seconds]
MrCooper_ has joined #dri-devel
<linkmauve>
Ristovski, isn’t that a CPU + 3D hybrid instead of media?
<Lynne>
hmm, vp8/9 uses different transforms to h264, but otherwise it's similar
<Lynne>
and different/simpler EC
MrCooper has quit [Ping timeout: 480 seconds]
<Lynne>
the MC part is IIRC identical, so probably they reused that part
<Lynne>
still, having codec-specific DSP exposed as regular functions would be very powerful and would allow you to build a great hybrid encoder
<Lynne>
*regular instructions
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
<Lynne>
reminds me how navi21+ has a 4x4 SAD instruction with no real way to use it from glsl other than to hope the compiler emits it
<Ristovski>
Oh bah, that repo even has shaders in non-source form
<Ristovski>
oh nvm, the sources are included along with them
<Lynne>
speaking of hybrid stuff, I'm planning to have someone write an mjpeg/dirac encoder in glsl for gsoc
camus has quit [Remote host closed the connection]
danilo has joined #dri-devel
<glehmann>
Lynne: d3d11 has a msad instruction, is that what you mean?
FireBurn has quit [Quit: Konversation terminated!]
FireBurn has joined #dri-devel
dakr has quit [Ping timeout: 480 seconds]
dakr has joined #dri-devel
camus has joined #dri-devel
camus has quit [Remote host closed the connection]
Akari has quit [Quit: segmentation fault (core dumped)]
danilo has quit [Read error: Connection reset by peer]
camus has joined #dri-devel
<Lynne>
kind of, but no, the one from the nav21 datasheet was much better
<glehmann>
anyway, if you have a hardware feature that you want to use you could open a feature request in the Vulkan-Docs github repo
<Lynne>
I could expose it as a spir-v extension
<Lynne>
but with no direct correspondance between glsl and spir-v, it would be up to glslang to use it
<Lynne>
I love assembly and would rather explicitly write out spir-v, but with no mnemonics or e.g. gas support, I'd also have to write that
<glehmann>
there is a SPIR-V intrinsic extension for GLSL
Leopold has quit [Remote host closed the connection]
Leopold has joined #dri-devel
srslypascal is now known as Guest20
srslypascal has joined #dri-devel
flto has quit [Remote host closed the connection]
OftenTimeConsuming has quit [Remote host closed the connection]
Guest20 has quit [Ping timeout: 480 seconds]
OftenTimeConsuming has joined #dri-devel
flto has joined #dri-devel
warpme_____ has quit []
bmodem has joined #dri-devel
Akari has joined #dri-devel
Guest18 is now known as bluepenquin
kts has joined #dri-devel
danilo has joined #dri-devel
dakr has quit [Ping timeout: 480 seconds]
The_ASV has joined #dri-devel
Akari has quit [Quit: segmentation fault (core dumped)]
The_ASV has quit [Read error: Connection reset by peer]
The_ASV has joined #dri-devel
The_ASV has quit [Read error: Connection reset by peer]
The_ASV has joined #dri-devel
rpigott_ is now known as rpigott
The_ASV has quit [Read error: Connection reset by peer]
The_ASV has joined #dri-devel
heat_ has joined #dri-devel
heat has quit [Read error: No route to host]
bmodem has quit [Ping timeout: 480 seconds]
gouchi has quit [Remote host closed the connection]
gouchi has joined #dri-devel
The_ASV has quit [Read error: Connection reset by peer]
The_ASV has joined #dri-devel
The_ASV has quit [Read error: Connection reset by peer]
kts has quit [Quit: Leaving]
HerrSpliet has joined #dri-devel
RSpliet has quit [Ping timeout: 480 seconds]
iive has joined #dri-devel
<Lynne>
I do wish vulkan video gets adopted by SoC vendors
<HdkR>
Me too
<Lynne>
we make fun of large desktop vendors' implementations for being weird and quirky, but nothing beats SoCs in quirkiness
heat_ has quit [Read error: No route to host]
<Lynne>
nvidia jetson is by far the winner
heat_ has joined #dri-devel
<Lynne>
it uses the standard v4l API, but then for some reason it mixes in nvdec functions that are unlike those on desktops
warpme_____ has joined #dri-devel
<Lynne>
they sent a patch to ffmpeg 2 years ago and we had to tell them "v4l2 fully or nvdec fully, you control the API, you decide, but not both"
<airlied>
yeah I've no idea how SoC will deal with Vulkan
<airlied>
a lot of their IP isn't really queued
<Lynne>
unfortunately, the v4l2 API seems to be winning with SoCs, complete with its zoo of stateful/stateless variants, with various degree of bitstream parsing competence
<Lynne>
btw, airlied did you fix the crash with the sample I linked?
<Lynne>
I'd test, but my intel testing rig is an optimus laptop which has randomly decided to break intel
<HdkR>
Everyone supporting Vulkan Video would probably resolve my open question about video decode on x86 games running on ARM hardware :D
<airlied>
not yet will take a look
Haaninjo has joined #dri-devel
<daniels>
Lynne: SoC vendors won’t support it over stateless V4L2 unless there’s a compelling reason to eat all the pain of doing so
RSpliet has joined #dri-devel
<daniels>
only supporting H.264 isn’t particularly compelling atm
<airlied>
I think the stateful vs stateless is kinda hard to deal with, not sure vulkan can really deal with stateless
<airlied>
daniels: you think it needs AV1?
<Mis012[m]>
what's wrong with v4l2
<Lynne>
vulkan is very stateless in comparison to other APIs, only state to be found is with hevc's tmvp and av1's ref picking code
HerrSpliet has quit [Ping timeout: 480 seconds]
HerrSpliet has joined #dri-devel
<Lynne>
it could be made fully stateless by exposing them, I guess, it's a little bit of extra parsing work
RSpliet- has joined #dri-devel
<Lynne>
as for what's wrong with v4l2, it's a decoder, not a hwaccel, it's very quirky, standardization has dragged on for years now, and it's got different codepaths
<Mis012[m]>
standardization of Linux mainline code doesn't even need vendor cooperation
RSpliet has quit [Ping timeout: 480 seconds]
<Mis012[m]>
the sad part is the firmware that's helpfully signed
<Mis012[m]>
if the vendors are the only ones who care about it enough to write code to support it... then you get vendor quality code I guess :P
<Mis012[m]>
could also have stricter reviews, but meh
HerrSpliet has quit [Ping timeout: 480 seconds]
<Mis012[m]>
arguably vulkan isn't really hwaccel either, the main part is running your shader code on a coprocessor core cluster (GPU) and most SoC vendors don't really let you do that :P
<Mis012[m]>
(with whatever cores are doing the decoding, i.e venus arm9)
maxzor has joined #dri-devel
RSpliet has joined #dri-devel
RSpliet- has quit [Ping timeout: 480 seconds]
maxzor has quit []
<Lynne>
speaking of, there are some folks doing a free raspberry pi firmware
HerrSpliet has joined #dri-devel
<Lynne>
complete with freeing the vc1/h264 decoders, those required license keys
RSpliet has quit [Ping timeout: 480 seconds]
<daniels>
airlied: yep
<daniels>
Lynne: v4l2 stateless uAPI cycles aren’t exactly the quickest for new codecs, but otoh here we are in 2022 with Vulkan Video not having HEVC or AV1
<daniels>
I don’t like HEVC one bit for obvious reasons, but sadly it isn’t optional
<daniels>
(or does it have HEVC now?)
<airlied>
it has hevc
<daniels>
oh they added it, nice :) so it just needs AV1
maxzor has joined #dri-devel
<airlied>
vulkan video is definitely a product of it's investment :-P
<daniels>
the old chicken and egg
<airlied>
we should just do MESA_decode_av1
<Lynne>
I've never complained about vulkan being so incredibly verbose and low-level, but I've never really liked it either
<Lynne>
...until now
<airlied>
and not drag it through the stds body :-P
<Lynne>
freedom to implement your own rate control system for encoding is huge
<Lynne>
vaapi's rate control on intel has always been laughable, and amd's is just there for show
<Lynne>
but there's so much to improve with just proper rate control
<bcheng>
how does vulkan video allow rc? does it expose a qp map buffer of some sort?
<Lynne>
it forces you to pick your own frame types
<Lynne>
and lets you either figure out the quantizers by default or let it do its own rate control
<Lynne>
you also get to set the frame refs yourself
<bcheng>
when you say figure out the quantizers, do you get like CU level specification or just frame-level?
<Lynne>
frame level only, I don't remember seeing a knob for AQ, sadly
<bcheng>
would you really call that your own RC though, you're still beholden to the firmware behaviour to achieve the target bitrate at the frame level
<bcheng>
I'm surprised vaapi doesn't let you pick frame types though
<Lynne>
nope, you can turn off the RC system entirely
<Lynne>
and force quantizers per-frame
<Lynne>
with I believe chroma quantizers too
<Lynne>
no room for firmware intervention or built-in "boosting" to blow your budget
<Lynne>
and if you don't like a frame, you can run it again with a different quantizer or run it through your own denoiser first
<Lynne>
(well, not being able to use multiplane images as storage is a problem, but it's just fixable with some annoying code)
* airlied
wonders would it be easier to just figure out intel short mode than do manual ref pic list manipulation
Akari has joined #dri-devel
<Lynne>
giving up on long/short mode?
<Lynne>
you should check out oneVPL or libva, it's bad code but may contain some hints
rasterman has quit [Quit: Gettin' stinky!]
<airlied>
Lynne: all long mode so far
<Lynne>
that's the more explicit mode, right?
<airlied>
yeah, but it requires you to have parsed the slice headers
<airlied>
which vulkan doesn't require you to have done
<airlied>
it's annoying since ffmpeg already has decent slice header parsers :-P
<airlied>
which is what vaapi would use
<Lynne>
ah, oof, is that why I saw some generic parsing code in your anv patchset?
<airlied>
I have docs for short so I can probably make sense of it, just a lot of gpu hangs to iterate through
<airlied>
Lynne: yes that's why
<Lynne>
I don't think the parsing code is that bad, but the reference code does look nasty
<Lynne>
why do they have 2 modes? historical reasons? I'm guessing the long mode would've come first
<airlied>
Lynne: it comes from DXVA API I guess
<airlied>
and they just implemented what microsoft came up with
<Lynne>
where did you get docs for the short mode?
<Lynne>
airlied: hmm, I found some docs for iris xe
<Lynne>
they list short/long modes for h264, but only mention long mode for hevc
<alyssa>
75% reduction in mpv cpu usage with that fix
<Lynne>
maybe it's not worth looking into short mode if you can't really reuse anything for hevc
<alyssa>
which convinces me that the pathological CPU usage isn't mpv's fault, but all of { asahi, panfrost, lima, vc4, v3d }
<alyssa>
(freedreno I think is ok)
<alyssa>
I'd say "let's just fix all the drivers then"
<alyssa>
..but fixing it depends on UAPI which most of those drivers didn't have the foresight to introduce
<airlied>
Lynne: yeah I may have to write a hevc header parser
<alyssa>
and given that people update userspace more than their kernel, idk if it makes sense to leave mpv -ESLOW on any kernel older than 6.4 or whatever
<alyssa>
furthermore I don't know if all of those MMUs *can* disable write combining
<alyssa>
/ enable CPU caching
gouchi has quit [Remote host closed the connection]
<airlied>
ah the media driver has some short form stuff
<Lynne>
got the init code done for vulkan encoding, now it's setting endless number of headers
camus has quit [Ping timeout: 480 seconds]
<Lynne>
with great flexibility comes great complexity, so most implementations will probably suck
<Lynne>
I, however, am a researcher, with much experience writing encoders and rate control systems
<Lynne>
muhwahaha
Duke`` has quit [Ping timeout: 480 seconds]
RSpliet has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
HerrSpliet has quit [Ping timeout: 480 seconds]
Akari has quit [Quit: segmentation fault (core dumped)]
camus has joined #dri-devel
cdoltb^ has joined #dri-devel
heat_ has quit [Read error: No route to host]
heat has joined #dri-devel
JohnnyonF has joined #dri-devel
Johnny has joined #dri-devel
Johnny_ has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
JohnnyonF has quit [Ping timeout: 480 seconds]
Johnny has quit [Ping timeout: 480 seconds]
Johnny_ has quit []
<DavidHeidelberg[m]>
should be EGL linked to the libgallium? It fixed the LTO build issue for me
<DavidHeidelberg[m]>
FireBurn: do you build with lto?
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
<jenatali>
David Heidelberg: I'm pretty sure it should be linked with gallium
<jenatali>
At least after mareko's latest round of removing unnecessary indirections
<DavidHeidelberg[m]>
jenatali: then LTO discovered an issue :D (thus I have one more argument for enabling the LTO CI build)
<DavidHeidelberg[m]>
also I'm running mine pipeline with LTO enabled and except killing gcc on arm crossbuild (I haven't seen GCC failure long time ago), it seems to be a visibly faster
<jenatali>
Yeah, Marek had to add new exports to the Windows equivalent so I'm pretty sure it was needed