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