ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
shashanks_ has quit [Ping timeout: 480 seconds]
vyivel has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
kzd has quit [Quit: kzd]
nyorain[m] has joined #dri-devel
Anson[m] has joined #dri-devel
isinyaaa[m] has joined #dri-devel
bylaws has joined #dri-devel
Daanct12 has joined #dri-devel
aswar002_ has quit []
aswar002 has joined #dri-devel
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
gdevi has joined #dri-devel
antoniospg has quit [Quit: Connection closed for inactivity]
kunal_10185[m] has joined #dri-devel
robertmader[m] has joined #dri-devel
Daanct12 has quit [Quit: WeeChat 4.0.5]
Dark-Show has joined #dri-devel
Daanct12 has joined #dri-devel
moben[m] has joined #dri-devel
sigmoidfunc[m] has joined #dri-devel
Dark-Show has quit [Remote host closed the connection]
minecrell has quit [Quit: Ping timeout (120 seconds)]
minecrell has joined #dri-devel
<airlied> gfxstrand: could you glance at the nir patch in 25536?
<Company> excellent, using an UBO for push constants became magically fast when I stopped using MapBuffer() for the VBO and used BufferSubData() there, too
<Company> I clearly have no idea what I'm doing
<Company> but things went from 600 to 1600 fps, so I'm at least moving in the right direction
jernej_ has joined #dri-devel
minecrell has quit [Quit: Ping timeout (120 seconds)]
minecrell has joined #dri-devel
sigmoidfunc[m] has quit [Ping timeout: 480 seconds]
gdevi has quit [Ping timeout: 480 seconds]
bylaws has quit [Ping timeout: 480 seconds]
kunal_10185[m] has quit [Ping timeout: 480 seconds]
jernej has quit [Ping timeout: 480 seconds]
darkglow has quit [Ping timeout: 480 seconds]
moben[m] has quit [Ping timeout: 480 seconds]
DPA has quit [Remote host closed the connection]
darkglow has joined #dri-devel
viciouss[m] has joined #dri-devel
crabbedhaloablut has joined #dri-devel
kzd has joined #dri-devel
FloGrauper[m] has joined #dri-devel
shoffmeister[m] has joined #dri-devel
YaLTeR[m] has joined #dri-devel
aravind has joined #dri-devel
cuiltb^ has joined #dri-devel
pushqrdx[m] has joined #dri-devel
Zopolis4 has joined #dri-devel
dabrain34[m]1 has joined #dri-devel
msizanoen[m] has joined #dri-devel
aravind has quit [Remote host closed the connection]
aravind has joined #dri-devel
q4a has joined #dri-devel
doraskayo has joined #dri-devel
aravind has quit [Read error: Connection reset by peer]
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
nielsdg has joined #dri-devel
tleydxdy has joined #dri-devel
reactormonk[m] has joined #dri-devel
siddh has joined #dri-devel
Company has quit [Quit: Leaving]
aravind has joined #dri-devel
kzd has quit [Quit: kzd]
rasterman has joined #dri-devel
K0bin[m] has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
Hazematman has joined #dri-devel
dcbaker has joined #dri-devel
bmodem has joined #dri-devel
Duke`` has joined #dri-devel
kelbaz[m] has joined #dri-devel
Zopolis4 has quit [Quit: Connection closed for inactivity]
halfline[m] has joined #dri-devel
tzimmermann has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
sima has joined #dri-devel
ahajda has joined #dri-devel
Nefsen402 has quit [Remote host closed the connection]
bl4ckb0ne has quit [Remote host closed the connection]
emersion has quit [Remote host closed the connection]
Nefsen402 has joined #dri-devel
bl4ckb0ne has joined #dri-devel
emersion has joined #dri-devel
<lina> anholt: I think you want another lina maybe? ^^
rppt has joined #dri-devel
zzoon_OOO_till_03_Oct[m] has joined #dri-devel
<emersion> there can only be one!
kos_tom has joined #dri-devel
<Daanct12> *insert the spiderman pointing each other meme*
nick1343[m] has joined #dri-devel
mszyprow has joined #dri-devel
kode54 has joined #dri-devel
<kode54> sorry about my departure, I'll try to be a little more mature about things
<kode54> quick question about modifiers, since I want to resolve that
<kode54> are they vendor specific identifiers for buffer formats?
<kode54> like, and can you ask the driver or device what the format for a specific modifier is
kts has joined #dri-devel
<emersion> a modifier can be used with multiple formats
<emersion> IOW: for a fixed modifier, there is no single format
<emersion> the driver may support the modifier for multiple formats
<emersion> or do you not mean "pixel format FourCC", by "format"?
<kode54> I guess I might have meant that
<kode54> I wasn't sure how unique modifiers were for formats
<kode54> or how much of a description is associated with one
<kode54> I'll look at that
Sofi[m] has joined #dri-devel
fab has joined #dri-devel
fab is now known as Guest2232
rasterman has joined #dri-devel
i-garrison has quit []
i-garrison has joined #dri-devel
ficoPRO10 has joined #dri-devel
go4godvin has joined #dri-devel
go4godvin is now known as Guest2233
<kode54> Thanks, that clears everything up
junaid has joined #dri-devel
jenatali has joined #dri-devel
aravind has quit [Read error: Connection reset by peer]
Guest2232 has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
pochu has joined #dri-devel
aravind has joined #dri-devel
rgallaispou has joined #dri-devel
donaldrobson has joined #dri-devel
<kode54> again, thanks, it didn’t occur to me that modifiers literally meant that, the unique descriptor for how a given fourcc is laid out in memory
<kode54> Like, something could be linear, or a specific form of tiled or something else
<kode54> Neat that soreau is working on modifier support for old AMD gpus
<kode54> Assuming they support more than some basic layouts
<kode54> Though it might help if each fourcc they support is at least paired with the explicit layout the devices expect
<kode54> If they don’t support more than one layout for a given format
<kode54> Incidentally, I sold my Arc gpu and plan to acquire a 6750 XT
Eighth_Doctor has joined #dri-devel
ficoPRO10 has quit [Ping timeout: 480 seconds]
sarahwalker has joined #dri-devel
lynxeye has joined #dri-devel
Newbyte has joined #dri-devel
ficoPRO10 has joined #dri-devel
AlaaEmad[m] has joined #dri-devel
jkrzyszt has joined #dri-devel
jasuarez has joined #dri-devel
Haaninjo has joined #dri-devel
tursulin has joined #dri-devel
<pq> kode54, no worries. When I told you that, it wasn't just the last comment, but I had been reading you here for couple days and some of your gitlab comments too. Happy to see you now.
masush5[m] has joined #dri-devel
tomba has joined #dri-devel
vidal72[m] has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
ttayar[m] has joined #dri-devel
elongbug has joined #dri-devel
heftig has joined #dri-devel
doras has joined #dri-devel
dos1 has quit [Ping timeout: 480 seconds]
dos1 has joined #dri-devel
Sumera[m] has joined #dri-devel
zzxyb[m] has joined #dri-devel
Daanct12 has quit [Quit: WeeChat 4.0.5]
cyrozap has quit [Quit: ZNC 1.8.2+deb3.1 - https://znc.in]
Frogging101 has quit [Quit: Close the World, Open the nExt]
cyrozap has joined #dri-devel
Frogging101 has joined #dri-devel
Daanct12 has joined #dri-devel
sghuge has quit [Remote host closed the connection]
nir2042 has quit [Quit: Connection closed for inactivity]
sghuge has joined #dri-devel
cmichael has joined #dri-devel
Cyrinux9474 has quit []
hch12907 has joined #dri-devel
lemonzest has quit [Quit: WeeChat 4.0.5]
<karolherbst> ohh.. gcc and clang will have a __element_count__ attribute to bound check VLAs at runtime
<karolherbst> we might want to do something like we have on the kernel side for it now
<karolherbst> in case somebody is bored
treeq[m] has joined #dri-devel
lemonzest has joined #dri-devel
<mareko> gerddie6: why does this fail, and if it fails because of the flake, why? because the flake is listed in the flakes file https://gitlab.freedesktop.org/mesa/mesa/-/jobs/49890490
Daanct12 has quit [Quit: WeeChat 4.0.5]
Cyrinux9474 has joined #dri-devel
Daanct12 has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
aravind has quit [Remote host closed the connection]
junaid has quit [Quit: leaving]
<mareko> gerddie: ^^
Mershl[m] has joined #dri-devel
junaid has joined #dri-devel
<zzag> anholt: sometimes kwin crashes when destroying EGLImageKHR. libepoxy crashes with "No provider of eglDestroyImageKHR found. Requires one of:". Do you know what can potentially cause it?
<zzag> not really reproducible crash, but it's weird
<zzag> eglDestroyImageKHR should not require a current opengl context
enick_185 has joined #dri-devel
junaid has quit [Remote host closed the connection]
junaid has joined #dri-devel
Armote[m] has joined #dri-devel
junaid has quit [Remote host closed the connection]
junaid has joined #dri-devel
digetx has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
aravind has joined #dri-devel
cmichael has quit [Quit: Leaving]
digetx has joined #dri-devel
junaid has quit [Remote host closed the connection]
junaid has joined #dri-devel
fab has joined #dri-devel
Cyrinux94743 has joined #dri-devel
Cyrinux9474 has quit [Ping timeout: 480 seconds]
Cyrinux94743 has quit []
Daanct12 has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
fab has joined #dri-devel
Zopolis4 has joined #dri-devel
<pepp> digetx, robclark: I don't get why virtio_gpu_do_fence_wait exits early if dma_fence_match_context returns true
<pepp> does it assume that previous jobs will always complete before the next ones?
fab has quit [Ping timeout: 480 seconds]
Wallbraker has joined #dri-devel
<robclark> pepp: if they are on the same timeline/fence-context/ring_idx then they should complete in order
orowith2os[m] has joined #dri-devel
<pepp> robclark: hm ok. I have one ring_idx per hw queue type.. I guess I should have one ring_idx per hw queue
<digetx> that's correct, you need to have fence context per queue
kts has joined #dri-devel
<pepp> digetx: right, but unless I'm missing something I can't submit job to a specific queue
kts has quit [Ping timeout: 480 seconds]
<digetx> then you'll need a new job flag to skip ctx matching for such jobs
heat has joined #dri-devel
tintou has joined #dri-devel
gallo[m] has joined #dri-devel
DUOLabs[m] has joined #dri-devel
fkassabri[m] has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
ohadsharabi[m] has joined #dri-devel
mvlad has joined #dri-devel
JosExpsito[m] has joined #dri-devel
bmodem has quit [Quit: bmodem]
bmodem has joined #dri-devel
Company has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
<karolherbst> anybody here knows how to deal with permission issues on render nodes passed into systemd-nspawn containers?
Zopolis4 has quit [Quit: Connection closed for inactivity]
kzd has joined #dri-devel
<psykose> do you get an EPERM on /dev/dri/render* ?
<psykose> i assume you need `DeviceAllow=/dev/dri/renderXXX rwm` in some dropin config
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
<karolherbst> yeah.. that's what I was missing
rgallaispou has quit [Read error: Connection reset by peer]
<karolherbst> gfxstrand: I need to be able to spill constant spec operations to an initializer function... any ideas or should I just start hacking on it once I find time.... I already see it being quite painful, because spirv_to_nir is entirely not designed for that...
<karolherbst> pocl seems to be doing the same in case you have crossworkgroup variables referencing other crossworkgroup variables :')
rgallaispou has joined #dri-devel
<Lynne> dj-death: any ideas when descriptor buffer for anv may get merged?
ficoPRO10 has quit [Ping timeout: 480 seconds]
<dj-death> Lynne: when someone reviews it
heat has quit [Read error: No route to host]
heat has joined #dri-devel
<Lynne> you don't have the rule where if it's sitting long enough without a review it gets merged?
<dj-death> I thought that was just for piglit/crucible ;)
alanc has quit [Remote host closed the connection]
DPA has joined #dri-devel
egalli has joined #dri-devel
alanc has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
Thymo has joined #dri-devel
nekit[m] has joined #dri-devel
<dj-death> Lynne: I've just been made aware of a HW thing, so I need to fix the existing DG2 direct descriptors & update the MR, so there is that too
jernej_ is now known as jernej
Ella[m] has joined #dri-devel
shashanks__ is now known as shashanks
i509vcb has quit [Quit: Connection closed for inactivity]
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
cmeissl[m] has joined #dri-devel
<Lynne> it's pretty much the last major implementation not to have them yet, even on windows all vendors implemented it
<zmike> it's been implemented for a long time, but one does not simply merge code to anv
Vanfanel has joined #dri-devel
<dj-death> do people merge unreviewed stuff in radv?
<zmike> we have weekly slapfights to argue over who has to review things
<psykose> if you bring a fish to the slapfight you're guaranteed to win
rasterman has quit [Quit: Gettin' stinky!]
Duke`` has joined #dri-devel
idr has quit [Ping timeout: 480 seconds]
aura[m] has joined #dri-devel
DPA2 has joined #dri-devel
DPA has quit [Ping timeout: 480 seconds]
x512[m] has joined #dri-devel
Peuc has quit [Quit: Peuc]
tzimmermann has quit [Quit: Leaving]
Peuc has joined #dri-devel
junaid has quit [Ping timeout: 480 seconds]
ram15[m] has joined #dri-devel
crabbedhaloablut has quit []
crabbedhaloablut has joined #dri-devel
<eric_engestrom> zmike: yes, I keep forgetting to create the 23.3 milestone
<eric_engestrom> thanks for the reminder :)
kts has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
ficoPRO10 has joined #dri-devel
<eric_engestrom> reminder for everyone: mesa 23.3 branchpoint is happening on Oct 25, the Wednesday _after_ XDC
<eric_engestrom> see https://docs.mesa3d.org/release-calendar for all the dates
<eric_engestrom> if you have any issue that need to be fixed before 23.3.0 final can be released, please add them to the milestone above :)
sarahwalker has quit [Remote host closed the connection]
Quinten[m] has joined #dri-devel
junaid has joined #dri-devel
<anholt> lina: yeah, whoops, meant linyaa about updated prm repo.
lynxeye has quit [Quit: Leaving.]
donaldrobson has quit [Ping timeout: 480 seconds]
<mareko> zmike: are you really arguing about that?
<zmike> what?
<zmike> oh
<zmike> no
<zmike> it's very structured discussion about areas of expertise
<zmike> sometimes we let bnieuwenhuizen do live code readings
<mareko> ooohh
ficoPRO10 has quit [Ping timeout: 480 seconds]
<bnieuwenhuizen> Just trying to make sure stuff doesn't fall through the cracks
znullptr[m] has joined #dri-devel
exp80[m] has joined #dri-devel
<mareko> sounds fun
kts has quit [Quit: Leaving]
<mareko> robclark: a306 has 9 new flakes: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/49910197
<anholt> mareko: those are all in known flakes.
<anholt> the job failure is in the post-processing stage, because //gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24738
<anholt> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25527 is up, but that MR should probably be reverted until then.
antoniospg has joined #dri-devel
i-garrison has quit []
i-garrison has joined #dri-devel
<mareko> so that's why all flake files are ignored
i-garrison has quit []
i-garrison has joined #dri-devel
idr has joined #dri-devel
Kayden has quit [Quit: -> JF]
jkrzyszt has quit [Ping timeout: 480 seconds]
<linyaa> anholt: what about an updated prm repo?
<linyaa> i didn't know people were still using it. but if anyone is, then i'll resume keeping it up-to-date.
<linyaa> do you think it makes sense to move it to gitlab? any opinion?
<linyaa> maybe there are ip issues with hosting it on gitlab. i'm unsure.
<linyaa> anholt: i'm updating them right now...
kusma has joined #dri-devel
ficoPRO10 has joined #dri-devel
zamundaaa[m] has joined #dri-devel
pekkari has joined #dri-devel
<anholt> linyaa: thanks! it's been nice to have.
<Company> is there a way to create a dmabuf from userspace? I want to test that my EGL code does the right thing and for that I need to feed it dmabufs from somewhere
<anholt> Company: for some of our testing, we export a dmabuf from GL in another context. but dmabuf testing overall is hard and not done well.
<Company> hrm
<Company> my next question would have been about YUV
<Company> and I don't think exporting YUV works without first getting a YUV buffeer, and with GL that requires importing a dmabuf...
<anholt> welcome to the "not done well" part!
<Company> more stuff to do!
<anholt> piglit generates some bespoke untiled yuv dmabufs using gbm. which frequently fail because they're 2x2 and aligned wrong for import requirements because it can't know those.
<anholt> stride-aligned
<Company> yeah
<Company> do 4x4 instead or 8x8!
<zmike> check weston tests ?
<Company> I had hoped there was some way with simpledrm or whatever to create cpu-backed dmabufs
<anholt> let's be real, I've thought about just cranking it up to like 256 wide with the same pixel data so that we could dodge this.
i509vcb has joined #dri-devel
<airlied> Company: udmabuf?
<anholt> Company: oh, that would be lovely. vgem/vkms are the thing that *should* be doable for this. except dmabuf import doesn't know about managing cache coherency, so you get mismatches between how vgem is mapping buffers (cpu cached woo why not) vs how your gpu wants to access them (data should have been write combined).
<anholt> so things only really work out when you're generating them from a real device on the system that's doing the same caching plan.
<Company> airlied: is that part of the kernel?
KunalAgarwal[m][m] has joined #dri-devel
<airlied> yeah but all i have is that word
* Company trying to figure out if it's worth trying to make CI work with it, or if it's just good enough for custom testing
<Company> google says https://github.com/ikwzm/udmabuf
<airlied> it may or may not be useful for you
<Company> well, /dev/udmabuf exists here
<Company> so it's definitely worth looking at
<airlied> the github thing is another thing
pekkari has quit [Quit: Konversation terminated!]
Cyrinux94743 has joined #dri-devel
digetx has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
ced117_ has joined #dri-devel
ced117 has quit [Ping timeout: 480 seconds]
<airlied> seems like it it
digetx has joined #dri-devel
tak2hu[m] has joined #dri-devel
Cyrinux94743 has quit []
Cyrinux94743 has joined #dri-devel
knr has joined #dri-devel
Haaninjo has joined #dri-devel
Omax has quit [Remote host closed the connection]
Omax has joined #dri-devel
<linyaa> anholt: tgl is up now at https://kiwitree.net/~lina/intel-gfx-docs/prm/
<linyaa> rkl should be another 5min
<robclark> I suppose we could get around to finishing https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23214 to allow gbm to allocate/export yuv surfaces
<anholt> the git appears to be down?
<linyaa> anholt: git clone is broken right now. i took it down for maintenance.
<linyaa> lemme push it somewhere else for now so you can clone, brb
dhirschfeld2[m] has joined #dri-devel
<linyaa> wait a few minutes for the initial push. it's fat.
<linyaa> s/push/push to complete/
<anholt> thanks!
<linyaa> do you want DG1 too today? RKL i'm doing now.
<linyaa> basically, i'm going to punt on the discrete cards until tomorrow, unless you need them now.
jdavies has joined #dri-devel
jdavies is now known as Guest2301
sima has quit [Ping timeout: 480 seconds]
Guest2301 has quit [Ping timeout: 480 seconds]
aradhya7[m] has joined #dri-devel
mvlad has quit [Remote host closed the connection]
<anholt> linyaa: something mtl-ish was what I was looking at that made me go try to git pull
<linyaa> mtl is xe-ish, according to intel_device_info.c, but i don't understand how much xe-ish
<linyaa> because dg is also xe-ish, i'll push those after lunch. leaving for 30min lunch now.
crabbedhaloablut has quit []
sarnex has quit [Read error: Connection reset by peer]
sarnex has joined #dri-devel
gildekel has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
ngcortes has joined #dri-devel
junaid has quit [Ping timeout: 480 seconds]
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
antoniospg has quit [Quit: Connection closed for inactivity]
junaid has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
Cyrinux94743 is now known as cyrinux
<airlied> gfxstrand: the copy prop pass also hits the cast deref in 25536
Kayden has joined #dri-devel
sravn has quit []
sravn has joined #dri-devel
benjaminl has quit [Remote host closed the connection]
benjaminl has joined #dri-devel
uihuih has joined #dri-devel
uihuih has quit []
crabbedhaloablut has joined #dri-devel
crabbedhaloablut has quit []
junaid has quit [Remote host closed the connection]
Duke`` has quit [Ping timeout: 480 seconds]
mattrope_ has quit [Remote host closed the connection]
kallisti5[m] has joined #dri-devel
MotiH[m] has joined #dri-devel
mszyprow has joined #dri-devel
Tooniis[m] has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
dantob has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
ofirbitt[m] has joined #dri-devel
neatversion has quit [Remote host closed the connection]
heat has quit [Remote host closed the connection]
ahajda has quit [Ping timeout: 480 seconds]
samueldr has joined #dri-devel
gnustomp[m] has joined #dri-devel
alyssa has joined #dri-devel
<alyssa> llvm moment
<karolherbst> ....
pcercuei has quit [Quit: dodo]
<karolherbst> I mean... `iand` is probably the cheaper operation here, so it kinda makes sense
<alyssa> karolherbst: my kernel got nir:
<alyssa> ine(umax(iand(b2i(x), 1), iand(b2i(y), 1)), 0)
<alyssa> truly inventive.
<alyssa> with that patch it becomes
<karolherbst> keep in mind that we generally compile with -O0
<alyssa> ior(x, y)
<karolherbst> but yeah..
<karolherbst> it's all madness :D
ficoPRO10 has quit [Ping timeout: 480 seconds]
<alyssa> big pile of .cl's coming soon
<karolherbst> oof
<alyssa> to a mesa repo near you
<karolherbst> btw.. we still have to fix memcpy :')
<alyssa> yes..
<karolherbst> though... we aren't so silly and copy megabytes of data
<linyaa> anholt: now, all the public prms are up. no mtl docs yet, but there are discrete alchemist/acm/arctic-sound docs, and both are 12.5. though i don't know how similar the ISA and arch are between mtl vs acm.
<anholt> thanks!
<linyaa> alyssa: now that it's oh-so-easy to write shaders, will you volunteer for writing hw-generic vulkan video encode shaders? ;-)
<karolherbst> yooo
<karolherbst> that would be a fun project, I just don't know how viable it is to do emulated video encoding/decoding via the vulkan APIs
<karolherbst> but should be fine.. I guess
<mattst88> the intel vaapi media driver has tons of encode shaders shipped as blobs -- presumably they're essentially compute shaders?
<karolherbst> not necassarily
<karolherbst> but probably?
<karolherbst> in any case... it would kinda be cool if we could have a sw video encoder/decoding lib inside mesa
<karolherbst> for various codecs
<linkmauve> karolherbst, depend on ffmpeg maybe instead?
<Lynne> take the dirtiest most convoluted ISA and overall architecture you can think of, and you still wouldn't be halfway to what implementing h264 from scratch would involve
<karolherbst> linkmauve: no
<karolherbst> also
<karolherbst> ffmpeg doesn't have that
<karolherbst> or at least, not what we'd need
<karolherbst> they don't even have cuda based encoders/decodes, alone CL based ones. For anything accelerated they use prop APIs
<karolherbst> it's super sad
<karolherbst> but ffmpeg won't help us here
<airlied> and gpus suck at decoding videos
<karolherbst> can't be worse than vp9 on the CPU
<Lynne> yeah, you wouldn't really gain much from this type of a decoder (what we call hybrid)
<airlied> karolherbst: can't it? :-P
<karolherbst> ehh.. wait.. I meant the vp9 encoder
<Lynne> most of the overhead of any well written decoder implementation is with token parsing for entropy decoding, which GPUs cannot do in parallel
<karolherbst> yeah.. I'm less worried about decoders, I'm more worried about encoding
<karolherbst> atm, e.g. gnome only supports vp9 for screen casting, which you can guess, is a horrible idea
<airlied> hopefully it grows av1
<karolherbst> it doesn't fix the problem of users not having GPUs supporting av1
benjaminl has quit [Read error: Connection reset by peer]
benjaminl has joined #dri-devel
<karolherbst> maybe in 15 years we can rely on it
<karolherbst> we still deal with h.264 videos today
<karolherbst> and recording
<karolherbst> because that's what people actually use
<linkmauve> karolherbst, AV1 is encodable in real time on not-that-performant CPUs nowadays.
<karolherbst> does it use <5% of the cPU?
<karolherbst> if not, it's useless
<linkmauve> Of course not.
<karolherbst> yeah, so it's useless for users
<karolherbst> for screencasting purposes
<linkmauve> Users do screencast using CPU encoders all the time.
<karolherbst> yeah.. and on gnome it's super broken
<karolherbst> h.264 would be fine, but it also doesn't push your CPU to its limits
<karolherbst> sorry, but relying on CPUs encoding for av1 won't cut it
<Lynne> encoding is easier, you can definitely implement a meh encoder on the GPU
<karolherbst> yeah.. as long as your CPU isn't at load that everything becomes laggy or the encoder can't keep up, that would be fine
<karolherbst> the issue is, you can totally encode vp9 on the CPU, but you get like 5 fps in avarage
<karolherbst> maybe av1 is simpler on the cpu?
<karolherbst> but the overall problem remains: high load on the CPU
<karolherbst> and power efficiency tanks
<Lynne> av1 is definitely not simpler than vp9
<karolherbst> yeah.... the only useable CPU encoder I've experience is h.264
<linkmauve> AV1 encoders are much more efficient than libvpx though.
<karolherbst> eveyrthing else is too heavy
nicofee[m] has joined #dri-devel
<karolherbst> yeah.. but libvpx is beyond terrible in terms of speed
<linkmauve> I can do 90 fps at 1080p using SvtAv1EncApp on my i5-8350U laptop, not even tweaking the toggles too much.
<linkmauve> Just asking for one pass, since that’s what screencasting does.
<linkmauve> 106 fps now.
minecrell has quit [Quit: Ping timeout (120 seconds)]
<karolherbst> I'm getting 9fps on my i7-10850H
<karolherbst> for 1080p content
<Lynne> if you turn on realtime mode you should get 100+
<Lynne> ffmpeg -i <input> -c:v libvpx-vp9 -quality realtime -speed 16 -b:v 2M -f null - gets me over 600fps here
<karolherbst> okay.. then it's just not very efficient but potentially usable
tutitutututu has quit []
minecrell has joined #dri-devel
orowith2os[m] has quit [Ping timeout: 480 seconds]
pushqrdx[m] has quit [Ping timeout: 480 seconds]
fkassabri[m] has quit [Ping timeout: 480 seconds]
<karolherbst> Lynne: interesting.... maybe it's the wrongly used in the end, but I'm getting like 100 fps here with proper content
<karolherbst> and 1080p is still kinda low, some laptops come with 2560 or something
<karolherbst> and then it becomes tight again
<karolherbst> and what if you are also in a video call and have to decode as well
<karolherbst> but anyway... the way gnome uses vp9 for encoding was terrible the last time I've tried
<karolherbst> maybe that was also on aarch64....
<linkmauve> ffmpeg still limits libaom’s cpu-used setting to 0..8? :/
<linkmauve> That really should get fixed someday.
<karolherbst> yeah...
<karolherbst> but uhh... it's still a terrible user experience, if you are actually wanting to do something while recording :D
<karolherbst> and screencasting comes with extra overhead
<linkmauve> karolherbst, on ARM you still don’t have a proper VP9 encoding uAPI in the kernel.
<karolherbst> anyway.. I kinda want to see it working on "all" laptops with great user experience before I'm convinced here
<linkmauve> So acceleration would be moot anyway, even if the hardware did support it.
<karolherbst> linkmauve: ? how does that matter for cpu encoding?
<linkmauve> karolherbst, ah, I thought you meant VP9 as it has hardware encoding, as opposed to AV1 which doesn’t yet on most ARM SoCs.
<karolherbst> ah yeah, fair, but the point was, if your CPU/GPU doesn't have the fixed function hardware, you could also probably use the GPU and get better power efficiency than encoding/decoding on the CPU
<karolherbst> ahhh no
<karolherbst> hardware is fine
<karolherbst> the problem is just, that not everybody has it
<karolherbst> and you need to find a solution in case you don't have hardware encoding
<karolherbst> and decoding
<karolherbst> burning through your battery ain't fun if you could get it cheaper
<Kayden> linyaa: yeah, alchemist docs are up at https://www.x.org/docs/intel/ACM/ - MTL is really similar. some differences with MOCS/PAT/modifiers/etc, but using those docs should be mostly right for either platform
<linkmauve> karolherbst, I doubt your GPU will do it cheaper than your CPU.
<karolherbst> why not?
<karolherbst> I'm not necssarily talking about faster
<karolherbst> only with less power
<linkmauve> That’s also what I’m talking about.
<linkmauve> But I don’t have numbers right now.
<karolherbst> yeah.. probably also because of lack of generic GPU impl
<linkmauve> Maybe check what Lynne mentioned, “hybrid encoders”.
<karolherbst> not sure if that means a e.g. CL based impl
<karolherbst> sometimes encoding/decoding is shader assisted on top of fixed function hardware
simon-perretta-img_ has joined #dri-devel
Kayden has quit [Quit: -> home]
<karolherbst> anyway.. could be a fun project
<bcheng> if I'm not mistaken x264 has some cl accelerated routines in it but I think they didn't get great results out of it
<karolherbst> there are proprietary products using CL for accelerated h.264/h.265 to cover all features on all hardware
<karolherbst> and they are faster than doing it on the CPU in general
<karolherbst> just in the open source world we don't have anything usefull
<karolherbst> I think there are also CUDA based ones, but that's kinda pointless to have
neniagh has quit [Ping timeout: 480 seconds]
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
simon-perretta-img has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
simon-perretta-img has joined #dri-devel
simon-perretta-img_ has quit [Ping timeout: 480 seconds]
<lumag> airlied, mripard, mlankhorst, could you please review and ack https://patchwork.freedesktop.org/patch/556295/?series=123412&rev=1 for merging through msm-next?
idr has quit [Ping timeout: 480 seconds]
shashanks_ has joined #dri-devel
shashanks has quit [Ping timeout: 480 seconds]
elongbug has quit [Read error: Connection reset by peer]