ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<Lynne> airlied: you got it!
<Lynne> identical results as vaapi
<Lynne> what was the issue?
<airlied> Lynne: alignment on the scaling matrix buffers
<airlied> the feedback, scaling matrix and hw cmd get suballocated from an "upload" buffer
<airlied> but it had no alignment constraints so sometimes the scaling matrix was getting bad values
<airlied> before I dumped the contents, I dumped the addresses and noticed it might be a problem
shashanks_ has joined #dri-devel
<Lynne> oof, the matrix is 4x4 and the hardware wanted 3x3?
<airlied> nah the matrix was 4x4 but we might have missed the first few entries due to misalignment
Lucretia has quit [Read error: Connection reset by peer]
<airlied> so we'd want to give the he 0x20 0x20 0x20 0x20 etc, but it would be getting 0x0 0x0 0x20 0x20 0x20
<Lynne> ah, I see
* airlied goes to see if I can roll back any of the other "fixes" now
<airlied> Lynne: can you recheck with branch I just pushed, I removed a patch that I'm not sure is useful
Lucretia has joined #dri-devel
shashanks has quit [Ping timeout: 480 seconds]
<Lynne> yup, it's still good
<airlied> great, I really don't want to parse the slice headers in the driver
pcercuei has quit [Quit: dodo]
<Lynne> which patch did you remove?
<airlied> Lynne: I have this blame it for all woes different from vaapi
<airlied> num_ref_idx_l0_active_minus1 and num_ref_idx_l1_active_minus1
<airlied> the vaapi decoder takes those values from the vaapi slice information
<airlied> but vulkan doesn't do slice info, so I use the defaults from the pps
<airlied> everytime I see misrendering I blame that, and have a slice header parser patch to pull out the values from the buffer the client submits
<airlied> maybe sometime it will matter :-P
<Lynne> ah, hmm
<Lynne> right, so if num_ref_idx_active_override_flag is set, num_ref_idx_l0_active_minus1 (P) and num_ref_idx_l1_active_minus1 (B) become essentially limiters for the references
<Lynne> where the decoder is meant to ignore any ref idx above it when decoding a slice
<Lynne> seems like it mostly happens in the most hated H264 swearword, PAF and MBAFF
<airlied> yeah so I full expect this to be future problems, but I don't want to pull the code in until I know better
<Lynne> doesn't the hardware decoder take care of parsing each slice and its header?
<Lynne> or does it expect you to do it?
<airlied> Lynne: it does
<airlied> Lynne: it's just this one case in the vaapi code is a mystery to me
<airlied> like the radeonsi driver ignores the vaapi slice header for everything else
<airlied> so it might be a bug workaround
ybogdano has quit [Ping timeout: 480 seconds]
<Lynne> yeah, that sounds like it could be a workaround
<Lynne> now, allow me to cool your enthusiasm by demonstrating how broken mbaff is
<airlied> I win because I've no idea what mbaff even is!
<airlied> except more reading
<airlied> but yeah keep throwing broken videos at me by all means
<Lynne> impossible, it's working too!
* airlied should try the simpsons trailer
<Lynne> it's that cursed h264 mode where interlaced video gets encoded more efficiently at the cost of implementers' sanity
<airlied> simpsons even seems fine
<emersion> sounds like a good trade-off to me
<Lynne> well, I can hack up h265 support quickly now
<Lynne> but I'd like to find out why nvidia's implementation doesn't work
<airlied> yeah do that first
<airlied> I'd like to get uvd going at the same level
<Lynne> I get nothing resempling an image for keyframes, and green everywhere else
<Lynne> *resembling
<airlied> I could try and get intel going I suppose
<Lynne> right, you had some code for that already, didn't you?
<airlied> yeah I forgot where I left it, but I had it kinda going previously
<airlied> -ETOOMANYLAPTOPS
<Lynne> I can test on intel too if code magically appears
<Lynne> as for nvidia, I'm betting they had no clue about pps/sps values
yuq825 has joined #dri-devel
rmckeever has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
<Lynne> err, either it hasn't been updated, or vk_video_samples doesn't actually support any P/B frames at all (list at the bottom)
<Lynne> which I'm guessing translates to nvidia's driver not supporting them too
<airlied> that would mildly embarrassing
<airlied> I'm thought it played jellyfish in the past
<Lynne> well, the source code doesn't set anything related to references in the StdVideoH264SequenceParameterSet structs and similar
<Lynne> in fact it hardly sets much values at all
<airlied> maybe the hw really doesnt care
heat_ has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
<airlied> Lynne: okay uvd cards back to tonga seem okay for h264 as well
Akari has quit [Quit: segmentation fault (core dumped)]
<Lynne> nice, I tried throwing constrained baseline, intra only at nvidia and it's all green
<Lynne> it's not the slice headers either, removing the three startcode bytes doesn't fix it
phire_ has joined #dri-devel
phire is now known as Guest501
phire_ is now known as phire
Guest501 has quit [Ping timeout: 480 seconds]
<airlied> Lynne: intel decodes the I frame, and there is some corrupt decoding after that, but the images make sense
* airlied tries to page back in how intel video decode works :-P
agd5f has quit [Ping timeout: 480 seconds]
<Lynne> nice, I'm trying to figure out how to build one of the worst pieces of code I've seen
<Lynne> hundreds of megabytes of submodules, and I'm on a DNS tunnel with a bandwidth of 40kb/sec
yoslin has quit [Ping timeout: 480 seconds]
rsalvaterra has quit [Quit: No Ping reply in 180 seconds.]
rsalvaterra has joined #dri-devel
mackerelian9 has quit []
rsalvaterra_ has joined #dri-devel
rsalvaterra is now known as Guest509
rsalvaterra_ is now known as rsalvaterra
yuq825 has quit [Ping timeout: 480 seconds]
Jeremy_Rand_Talos_ has joined #dri-devel
Guest510 has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
yoslin has joined #dri-devel
<airlied> Lynne: radv passes all the basic CTS tests now, the hw decoder dies on the test that does two streams interleaved, but all the i/p/b decode tests pass
<Lynne> nice
<Lynne> two streams interleaved?
<Lynne> I think I'll get h265 up first, this is taking forever
rsalvaterra_ has joined #dri-devel
rsalvaterra is now known as Guest516
rsalvaterra_ is now known as rsalvaterra
Guest517 has quit [Ping timeout: 480 seconds]
mhenning has quit [Quit: mhenning]
rmckeever has quit [Quit: Leaving]
rsalvaterra_ has joined #dri-devel
rsalvaterra is now known as Guest518
rsalvaterra_ is now known as rsalvaterra
Guest519 has quit [Ping timeout: 480 seconds]
<airlied> Lynne: it records two video decodes into command buffer sequences
<airlied> Lynne: then submits one job to the queue with the command buffers from each interleaved
Duke`` has joined #dri-devel
genpaku has quit [Remote host closed the connection]
<airlied> Lynne: I suspect h265 will explode appropriately
larunbe has quit [Ping timeout: 480 seconds]
genpaku has joined #dri-devel
bgs has joined #dri-devel
OftenTimeConsuming has quit [Remote host closed the connection]
nchery_ has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
heat_ has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
yuq825 has joined #dri-devel
bgs has quit [Remote host closed the connection]
ahajda_ has joined #dri-devel
psykose has joined #dri-devel
<ayaka_> there are still some V4L2 output device, are they just for display device that didn't support kms and mode setting
<ayaka_> likes the analog TV or SDI?
fab has quit [Quit: fab]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
JohnnyonFlame has joined #dri-devel
kts has joined #dri-devel
JohnnyonF has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
nchery_ is now known as nchery
danvet has joined #dri-devel
rasterman has joined #dri-devel
vliaskov has joined #dri-devel
fab has joined #dri-devel
frieder has quit [Quit: Leaving]
frieder has joined #dri-devel
fab has quit [Quit: fab]
MajorBiscuit has joined #dri-devel
Company has quit [Quit: Leaving]
jkrzyszt has joined #dri-devel
tzimmermann has joined #dri-devel
tursulin has joined #dri-devel
rgallaispou has joined #dri-devel
frieder has quit [Quit: Leaving]
frieder has joined #dri-devel
kxkamil has quit []
lynxeye has joined #dri-devel
kxkamil has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
Akari has joined #dri-devel
<danvet> jekstrand, ^^ maybe standing in for nv efforts too?
<danvet> bnieuwenhuizen, mareko ^^ for amd?
Terman has quit [Ping timeout: 480 seconds]
<danvet> just want a few more acks before I land this ...
<danvet> pinchartl, ^^ for libcamera/v4l2 area?
dcz_ has joined #dri-devel
<danvet> mareko, usually I'd ping agd5f for kernel stuff, but he's not around rn :-)
pcercuei has joined #dri-devel
pendingchaos_ has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
<airlied> danvet: ack from me
apinheiro has joined #dri-devel
djbw has quit [Read error: Connection reset by peer]
<pinchartl> danvet: should we require documentation then ?
<pinchartl> a 4CC without any known user and without documentation sounds like it will be painful
pendingchaos has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
<danvet> pinchartl, whatever the stakeholders feel like necessary
<danvet> afbc got some quite good docs
<danvet> others are more "hey we r/ed this, seems to work"
<pinchartl> you've probably seen the V4L2 4CCs documentation. it would be nice to have the same level of details in DRM
<danvet> pinchartl, another thing I've thought of is whether the kernel format validation code with it's table should be useable as a userspace library too
<danvet> uh that would need someone with quite some time on their hands, but yeah would be nice
<danvet> airlied, https://lore.kernel.org/dri-devel/20221201131825.701fb3f5@canb.auug.org.au/ <- need to include that one in the main PR
<pinchartl> I don't think we should duplicate that documentation though, it should really be shared between V4L2 and DRM. we could list both 4CCs in all those tables
<pinchartl> without that level of detail my experience in V4L2 is that drivers often picked the wrong 4C
<pinchartl> 4CC
<danvet> yeah that might be an option for those with overlap
<pinchartl> so you had identical V4L2 4CCs used by different drivers to refer to different formats, or the other way around
<danvet> my take is that we ideally need igt tests for this
<danvet> and ask people to check
<pinchartl> even when there's no overlap, we can leave the V4L2 or DRM 4CC column empty
<danvet> if it looks funny, then they'll fix things
<danvet> but that's kinda all orthogonal to the doc patch?
jkrzyszt has quit [Remote host closed the connection]
<pinchartl> having an authoritative test pattern generator that supports all formats would be great
<pinchartl> yes, it's orthogonal to the doc, I think both are useful
<pinchartl> tomba: wanna expand the kms++ test pattern generator to all DRM formats ? :-)
<pinchartl> it should be a standalone library, usable by other projects than igt
<emersion> <danvet> pinchartl, another thing I've thought of is whether the kernel format validation code with it's table should be useable as a userspace library too
<pinchartl> I'm sure there are dozens of implementations
<emersion> big +1
<pinchartl> what do you mean exactly by format validation code ?
<emersion> poor man's lib
<danvet> pinchartl, all the stuff that validates addfb2 metadata
<danvet> for some value of "all"
<emersion> pinchartl: that one is too basic
<danvet> emersion, trickiest part is probably to pull the driver specific validation out of them
<danvet> I think the afbc approach is probably best
<danvet> then just wrap that up in a libdrmfourcc.so
<emersion> pinchartl: it just assumes the DRM format naming is always the same, and only supports very simple stuff https://github.com/afrantzis/pixel-format-guide/blob/master/pfg/drm.py
<pinchartl> danvet: I only see framebuffer_check() in drm_framebuffer.c. there's not much there
<emersion> danvet: the reason i wanted to just ship a .json file is to allow other languages to use it too
<emersion> but one doesn't preclude the other i suppose
<emersion> pinchartl: i've seen it linked before. it seems too high-level?
<tomba> pinchartl: who's going to pay for the year of work it will take to add the test pat gen for all DRM formats? =)
<pinchartl> emersion: it could be served as the canonical description of 4CCs, we could have a database of 4CC -> KDF descriptors
<pinchartl> then applications could do whatever they want with that
<pinchartl> it should be possible to generate 4CC documentation in text form from the descriptors
<pinchartl> tomba: let's see who answers this call :-)
<emersion> it sounds complicated, but it's a standard, so probably a good idea than inventing our own thing
kts has quit [Quit: Leaving]
<tomeu> anholt: btw, I'm adding a job for testing vivante with rusticl
<tomeu> just in case you were planning to do the same for freedreno
<emersion> pinchartl: do you know if KDF defs are available for other stuff, e.g. Vulkan or GL?
rasterman has quit [Quit: Gettin' stinky!]
rasterman has joined #dri-devel
<pinchartl> emersion: I don't know, I haven't investigated. as far as I understand, it's a standardized way to precisely describe formats in a machine-readable way, and it's meant to cover the needs of all Khronos APIs
<emersion> seems like this exists at least for vk https://github.com/KhronosGroup/dfdutils/blob/master/vk2dfd.inl
<danvet> pinchartl, the format tables is the thing mostly
<danvet> pinchartl, tomba the real fun is in tiling modifiers
<pinchartl> :-)
<pinchartl> yes, tiling modifiers must be fun I'm sure. I'm happy to mostly ignore them on the camera side
<emersion> eh, C++… i thought it was deprecated by Rust these days
<pinchartl> I'll happily get into rust when it will be mature enough ;-)
<pinchartl> (one loves a good flamewar, right ?)
<javierm> emersion: even though I love rust, I'm very happy that libcamera is in C++, it makes my life as a package maintainer in fedora much easier :)
<javierm> packaging rust projects is challenging
<daniels> DavidHeidelberg[m]: heh, I was in bed too I’m afraid
MajorBiscuit has joined #dri-devel
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
<DavidHeidelberg[m]> daniels: btw. who to kick about https://gitlab.freedesktop.org/mesa/mesa/-/issues/7781 ?
jkrzyszt has joined #dri-devel
<daniels> DavidHeidelberg[m]: there’s no good answer there - zmike’s gone for the rest of the year, ajax is saying he doesn’t have time for it, and the revert fixes a bad bug apparently - unless kusma can debug and resolve it, I think we’re just down to either adding a lot of flake entries, or seeing if we can make it more stable by disabling tc for zink
aravind has joined #dri-devel
<kusma> This seems to be in Kopper land, so maybe ajax has a clue?
<mareko> danvet: Acked
<danvet> mareko, you'll reply or should I forward?
<kusma> David Heidelberg: But yeah, like daniels said, adding a bunch of flakes is probably the short-term "solution" here
<kusma> Sounds like this is Kopper/GLX stuff, and I'm pretty useless in those areas...
<daniels> kusma: he said in the reverting MR that he wouldn’t have time to look into the issue the revert fixed any time soon
<kusma> Oh, right.
<kusma> Yeah, then... 🤷
<mareko> danvet: I'm not on dri-devel
<danvet> ok I'll fwd
<emersion> pinchartl: the issue with KDF is that it's not very human-writable
<emersion> you can't just dump the data file in the git repo
kts has joined #dri-devel
<emersion> also i've heard that doing codegen in the kernel is… an experience
mvlad has joined #dri-devel
<HdkR> Wait, you can JIT in the kernel?
<HdkR> That sounds nutty
<HdkR> I love it
<FLHerne> I thought that meant compile-time codegen?
<FLHerne> there is some JIT in the kernel like the BPF interpreter
jkrzyszt has quit [Remote host closed the connection]
<HdkR> ah, my mistake, carry on :P
<HdkR> JIT-boy away
<emersion> lol yeah, i meant at compile-time, to generate C tables from KDF
<kusma> HdkR: Something about a shiny hammer and everything looking like a nail? :P
<kusma> (TBH, I also interpreted that as JIT)
<HdkR> I hear if you JIT your code specializations then your code can be faster. Everyone wants more speed right? Just embed libllvm in the kernel.
<kusma> What could possibly go wring?
<kusma> wrong
<kusma> Somehow proving my own point by derping!
MajorBiscuit has quit [Ping timeout: 480 seconds]
<DavidHeidelberg[m]> I will do another round of unassigning Marge, so zink fix get in before running the MRs (where is chance it would fail at least once)
RSpliet has quit [Quit: Bye bye man, bye bye]
RSpliet has joined #dri-devel
yoslin has quit [Ping timeout: 480 seconds]
<tomeu> anybody knows what is the deal with ASAN builds with LLVM?
<tomeu> [896/2425] Generating src/freedreno/afuc/afuc_test.fw with a custom command
<tomeu> FAILED: src/freedreno/afuc/afuc_test.fw
<tomeu> ==7904==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.
<tomeu> this is from https://gitlab.freedesktop.org/tomeu/mesa/-/jobs/32770692 , I'm adding rusticl to debian-arm64
jkrzyszt has joined #dri-devel
devilhorns has joined #dri-devel
MajorBiscuit has joined #dri-devel
Akari has quit [Quit: segmentation fault (core dumped)]
Leopold has joined #dri-devel
Leopold has quit []
frytaped is now known as Guest533
frytaped has joined #dri-devel
yoslin has joined #dri-devel
frytaped has quit [Remote host closed the connection]
frytaped has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
frytaped has quit [Quit: WeeChat 3.6]
frytaped has joined #dri-devel
pendingchaos_ is now known as pendingchaos
aravind has joined #dri-devel
frytaped has quit [Quit: WeeChat 3.6]
minecrell has quit [Remote host closed the connection]
minecrell has joined #dri-devel
<kusma> pendingchaos: Seems either nir_lower_global_vars_to_local changes the mode of the variable that's being sampled from input to a shader temp?!
<kusma> -either
<kusma> No, function temp
<danvet> ogabbay, can you ping sfr to get your accel branches added to linux-next? looks like they only showed up with the drm.git merge
<ogabbay> danvet: yes, I'll do it
OftenTimeConsuming has joined #dri-devel
<kusma> pendingchaos: Seems like nir_remove_dead_variables thought the var was dead first... But it's not...
aravind has quit [Ping timeout: 480 seconds]
frieder has quit [Quit: Leaving]
frieder has joined #dri-devel
frieder has quit [Remote host closed the connection]
frieder has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
frytaped has joined #dri-devel
<danvet> ogabbay, thx
OftenTimeConsuming is now known as Guest539
OftenTimeConsuming has joined #dri-devel
Guest539 has quit [Remote host closed the connection]
MajorBiscuit has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
frytaped has quit [Quit: WeeChat 3.6]
Akari has joined #dri-devel
Leopold has joined #dri-devel
apinheiro has quit [Ping timeout: 480 seconds]
Company has joined #dri-devel
yuq825 has left #dri-devel [#dri-devel]
fab_ has joined #dri-devel
fab_ is now known as Guest545
Guest545 has quit []
fab has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
Leopold has quit [Remote host closed the connection]
Leopold has joined #dri-devel
fab has quit [Quit: fab]
Leopold has quit [Remote host closed the connection]
Leopold has joined #dri-devel
Leopold has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
<cheako> [27265.771986] [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* amdgpu_vm_validate_pt_bos() failed.
<cheako> [27265.772019] [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Not enough memory for command submission!
<cheako> [27265.772076] [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Not enough memory for command submission!
<cheako> [27265.773814] [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* amdgpu_vm_validate_pt_bos() failed.
<cheako> I got tones of thoes.
alarumbe has joined #dri-devel
Net147_ has joined #dri-devel
Net147 has quit [Read error: Connection reset by peer]
jkrzyszt has joined #dri-devel
<kisak> this rust dependency rabbit hole is quickly becoming annoying on anything older than ubuntu 22.04
frytaped has joined #dri-devel
kts has joined #dri-devel
kts has quit [Quit: Leaving]
kts has joined #dri-devel
<MrCooper> kisak: even with rustup?
<karolherbst> it's a rabbit hole if one right out refuse to use cargo
<karolherbst> (like packager do)
<karolherbst> *packagers
shashanks_ has quit [Remote host closed the connection]
<alatiera> must replicate the C setup from 1979
* Ristovski shudders
Duke`` has joined #dri-devel
frytaped has quit [Quit: WeeChat 3.6]
kode54 has quit [Quit: Ping timeout (120 seconds)]
kode54 has joined #dri-devel
Leopold__ has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
Leopold__ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
djbw has joined #dri-devel
<cwabbott> does anyone know what ROQ stands for on radeon? Read-Only Queue? ReOrder Queue?
kts has quit [Ping timeout: 480 seconds]
<anholt> I wasn't able to dig anything up
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
<DavidHeidelberg[m]> eric_engestrom: btw. poking RPi to make prebuild kernels with zram would make probably lot of sense for their devices, if you get in touch with people who make them
<DavidHeidelberg[m]> only issue was that Kconfig had until now set EXPERIMENTAL flag from 2013, so that probably discouraged some folks to enable it
<eric_engestrom> "until now" = how recent?
<eric_engestrom> raspbian is still on 5.15
<eric_engestrom> but yeah, we talked about it internally a couple weeks ago (or whenever you linked me to that mr), but I'll pass on the suggestion
<eric_engestrom> ("internally" I mean igalia, I don't think any of us talked to someone at rpi about it)
<DavidHeidelberg[m]> eric_engestrom: nice. btw with the experimental flag I overlooked, that was ZSWAP and it got commited 2022-09-11
<DavidHeidelberg[m]> (btw. if anyone using swap on rpi zswap is also good idea)
fab has joined #dri-devel
<eric_engestrom> so zram didn't have the experimental flag?
<eric_engestrom> didn't know about zswap, but I guess usually disk isn't scarce so no need to compress
<kisak> MrCooper: Rustup isn't valid when dealing with submitting a build to a build farm for general use.
<kisak> I'm more inclined to disable rusticl on Focal and older and re-evaluate later.
<DavidHeidelberg[m]> Zswap does hybdrid thing. What can be compressed goes like zram and stays, what cannot be compressed goes to ssd
devilhorns has quit []
tursulin has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
krushia has joined #dri-devel
junaid has joined #dri-devel
krushia has quit [Ping timeout: 480 seconds]
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
mhenning has joined #dri-devel
vliaskov has quit [Remote host closed the connection]
Akari has quit [Quit: segmentation fault (core dumped)]
lynxeye has quit [Quit: Leaving.]
ybogdano has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
alyssa has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
<alyssa> NIR folk: could I get an ack on the first patch !19996?
<alyssa> Adding some vendored intrinsics for AGX (used later in the series)
<alyssa> The dicey bit is that it adds a (non-vendored) intrinsic index, IDK how people feel about that
<alyssa> though we do have a pile of AMD intrinsic indexes already so there's plenty of prior art
<alyssa> thanks :)
<alyssa> (I would have vendored the index but it seems like it might be useful for core intrinsics too.)
srslypascal is now known as Guest562
srslypascal has joined #dri-devel
<robclark> cwabbott: I think read-only-queue? although I don't remember what prompted me to believe this however many years back
Guest562 has quit [Ping timeout: 480 seconds]
<jenatali> Hm, is there a NIR util for flattening nested arrays?
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
<DavidHeidelberg[m]> any AMD people around? Re-enabling spec@arb_texture_buffer_object@texture-buffer-size-clamp for raven and stoney. Previously OOMing tests, but it'll gets enabled with ZRAM. R-b please on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19535
<DavidHeidelberg[m]> mareko: maybe? ^
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
<alyssa> jenatali: not that I know of, what did you have in mind?
ybogdano has joined #dri-devel
<jenatali> Not sure, I just found a bug where we called without_array() instead of get_array_element() in 2 places
<jenatali> And I was mainly just surprised that I still was seeing nested arrays coming to the compiler backend
<jenatali> (For CL)
<alyssa> yeah that's the more surprising part for me....
<alyssa> how does that happen?
<jenatali> Specifically, a nested array with a constant initializer. So that's fun
<alyssa> I'm still confused why that's not getting lowered waaay before it hits your backend
<jenatali> Probably because I'm missing running a lowering pass. I.e. the one I was asking about ;)
<alyssa> ahaha right okay
<alyssa> I guess I assumed lower_vars_to_ssa did that?
<alyssa> nir_split_vars, nir_split_var_copies, etc
<jenatali> Yeah... I'll dig a bit deeper I guess
<alyssa> lower_variable_initializers maybe
<alyssa> idk
<jenatali> We're probably skipping something because we actually want the initializers to stick around for this particular type of var
<alyssa> which type
<jenatali> DXIL has a path for an "immediate constant buffer," i.e. data embedded in the shader, and in NIR we represent that as a shader_temp var with a constant initializer
<alyssa> why?
<alyssa> nir->constant_data is made for that no?
<jenatali> To avoid having to read it out and send it to the runtime through a side channel and re-upload that
<alyssa> with nir_opt_large_constants for munching through that
<jenatali> I seem to recall this predating some of that
<alyssa> well, time to go postdating then :-D
<jenatali> Yeah, I probably should
<jenatali> But that sounds like a bigger change than just fixing this nested array handling for now
<alyssa> unrelated
<alyssa> i again wish that zink/d3d12 called lower_io so we can write lowering passes that assume lowered i/o
<alyssa> but als
<alyssa> alas
<jenatali> Yeah d3d12 does call lower_io in the backend these days
<alyssa> well zink then
<alyssa> for context I want to do as much lowering and optimization at CSO create time as possible
<alyssa> to make shader variants as cheap as possible
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
<alyssa> which means passes that depend on the shader key need to run as late as possible, i.e. after lowering I/O certainly
<alyssa> but between panfrost and asahi, I have quite a collection of key-dependent NIR passes that assume early I/O
<alyssa> handling both early and late in the same lowering pass is possible but a PITA
<alyssa> I'm tempted to straight up fork off lower_texcoord_replace into _early and _late versions
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.6]
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
nchery_ has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
<jekstrand> danvet: seems reasonable
sravn has quit [Quit: WeeChat 3.5]
Haaninjo has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
nchery_ is now known as nchery
haasn has quit [Quit: ZNC 1.7.5+deb4 - https://znc.in]
haasn has joined #dri-devel
junaid has quit [Ping timeout: 480 seconds]
junaid has joined #dri-devel
<DemiMarie> A database of fourcc codes would be AWESOME. Could that be used to generate validation code for use in libwayland, wlroots, and libweston?
<DemiMarie> Not to mention Smithay
heat has quit [Quit: Leaving]
sravn has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
oneforall2 has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
gouchi has joined #dri-devel
fab has quit [Quit: fab]
junaid has quit [Ping timeout: 480 seconds]
RSpliet has quit [Quit: Bye bye man, bye bye]
RSpliet has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
dcz_ has quit [Ping timeout: 480 seconds]
apinheiro has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
<dj-death> DavidHeidelberg[m]: kind of curious why you're unassigning-reassigning marge
<DavidHeidelberg[m]> dj-death: another zink-lvp flake, it's less frequent, but chance it'll hit some current MR is high, so this un-assigning will prioritize my MR with CI fix 😉
<dj-death> ah I see
danvet has joined #dri-devel
heat has joined #dri-devel
mvlad has quit [Remote host closed the connection]
danvet has quit [Ping timeout: 480 seconds]
fxkamd has joined #dri-devel
<DemiMarie> Does Mesa do LTS releases?
<alyssa> DemiMarie: I thin kso
<DemiMarie> alyssa: In Qubes OS we are having severe graphics glitches on Alder Lake hardware with Mesa 20.2.3. Upgrading Mesa is very hard due to the huge number of dependencies.
<airlied> no mesa doesn't do LTS
<alyssa> maybe I don't understand what LTS is
<alyssa> DemiMarie: what dependencies?
* airlied assumes LLVM :-P
<DemiMarie> LTS = Long-Term Support
<alyssa> airlied: ah well
<airlied> it's all fun and games until you update llvm
<DemiMarie> alyssa: probably LLVM
<FLHerne> aside from the amber branch (fork of 21.3 supporting old hardware that was dropped from current mesa), no
<alyssa> airlied: Over here we're doing LLVM-free, expat-free builds :-p
<alyssa> that leaves, what, zlib? Pff
<DemiMarie> can Mesa be statically linked to all of its dependencies?
<FLHerne> and that won't help you with Alder Lake
<alyssa> what does qubes need 3D acceleration for anyway
<DemiMarie> the problem is that we get graphics glitches galore
ahajda_ has quit [Ping timeout: 480 seconds]
<DemiMarie> to the point that some hardware is unusable
<DemiMarie> one option is to turn off Glamor in X11 but that might make the already mediocre performance worse
apinheiro has quit [Quit: Leaving]
<DemiMarie> alyssa: Mesa is mostly used by Xorg and the compositing window manager
<DemiMarie> at least that is what I assume
<airlied> all answers that arent rebase are likely wrong
<alyssa> DemiMarie: I thought Qubes was i3?
<alyssa> what's the compositor for?
<DemiMarie> alyssa: currently XFCE (so XFWM4) is the default
<alyssa> I guess avoiding tearing
<DemiMarie> airlied: rebase *what*?
<alyssa> airlied: idk i'm digging my "just don't ship any gl whatsoever" solution ;-p
<DemiMarie> is statically linking all dependencies (so that we don’t have to mess with system libs) an option?
<Sachiel> no
ybogdano has joined #dri-devel
<DemiMarie> Sachiel: why?
<alyssa> llvm
gouchi has quit [Quit: Quitte]
<DemiMarie> alyssa: lots of stuff has a hard requirement on OpenGL and I would not be surprised if much of it has no software fallback
<DemiMarie> does statically linking LLVM not work? Could the LLVM library be renamed?
<alyssa> the minute you allow llvm into your life you are entering a world of pain
<Sachiel> renaming the library doesn't help when you have something else using it and getting screwed up with symbol names
<DemiMarie> Sachiel: `objcopy`?
<DemiMarie> or is dlopen() involved?
<alyssa> wrote this a bunch of years ago at the FSF, idk how much it still applies
<DemiMarie> Qubes has enough UX problems already 😛
<airlied> DemiMarie: mesa
<DemiMarie> airlied: i meant statically link Mesa to *its* dependencies
<DemiMarie> so that one can have a standalone Mesa shared library that does not depend on any system libs
<DemiMarie> that would allow replacing the system Mesa in an old version of Fedora
<DemiMarie> alyssa: consider that some Qubes OS users are journalists, activists, and other non-technical people
<DemiMarie> “use i3” isn’t going to fly with those people
<airlied> DemiMarie: yeah static linking mesa won't end well usually
<DemiMarie> airlied: for what reason?
<DemiMarie> the problem is that we need to support new hardware on an old distro
<DemiMarie> airlied: it feels like the Linux graphics world is not friendly to fixed-release distros
Akari has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
<FLHerne> I don't see how it can be really
<FLHerne> the amount of code to bring up a new hardware generation isn't something you could sanely 'backport' to an LTS even if there was one
<FLHerne> you'd have to backport everything and it would just be the corresponding feature release again
<DemiMarie> FLHerne: what about having Mesa be entirely standalone, with no system dependencies except perhaps zlib?
<DemiMarie> Have Mesa bundle LLVM and link it statically.
<DemiMarie> Do most Linux graphics devs use Arch, Alpine Edge, or other rolling-release distros?
<FLHerne> you'd have to rename all the symbols, otherwise you try to run KDevelop and it blows up as Sachiel mentions
<FLHerne> (insert other LLVM-using apps as relevant)
<FLHerne> maybe objtool can do that for you, skim-reading the manpage...
warpme____ has quit []
Leopold_ has joined #dri-devel
<kisak> fwiw, I just reached the end of my local testing for my PPA build of mesa 22.3.0. The short notes are d3d12/dozen broke on Ubuntu 18.04. spirv-llvm-translator-15 wasn't viable, so ANV raytracing and rusticl are disabled, and getting bindgen 0.58+ backported before 22.04 is ... gross, so rusticl on 20.04 and older isn't going to happen.
<kisak> I should ask if these failed test cases in llvm-spirv are show stoppers for intel-clc or rusticl https://dpaste.com/78MPNNHF2
off^ has joined #dri-devel
<kisak> ^speaking of llvm-related pain right there
<DemiMarie> FLHerne: if someone is trying to run KDevelop in a Qubes dom0 they are doing something wrong, and we could rename the package so that trying to install it manually will fail with a dependency error
<DemiMarie> (LLVM package, that is)
<DemiMarie> also why would that be an issue if LLVM is linked statically? It shouldn’t export any symbols then.
<ajax> just build without llvm
<ajax> you get slow swrast, but whatever, and you lose some old pre-si radeons, but whatever
<ajax> and you lose semi-performant GL_SELECT, but. again, whatever.
<ajax> but also: llvm shouldn't be a problem? iirc they're using symbol versions now so having parallel llvms in one process shouldn't be an issue
<ajax> if your problem is you can't _build_ newer llvm for some reason, well, sorry, but not really a mesa problem, that.
<DemiMarie> what deps does llvm have? just a recent c++ compiler?
<DemiMarie> and cmake?
<ajax> afaik yeah
<psykose> libffi/zlib (optional?)
<psykose> so yeah pretty much
<ajax> not a lot
<ajax> llvm itself is the big dep
<ajax> so: don't use it
<ajax> i honestly wish we had an alternative jit backend, the full weight of llvm is silly here
<DemiMarie> and the compiler to build it
<ajax> but the things you lose by not building with llvm support are, honestly, not that bad.
<psykose> even 15 is gcc>=7.1
<psykose> that does not seem very new