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