ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
fab has quit [Quit: fab]
maxzor has joined #dri-devel
<DavidHeidelberg[m]> by picking randomly selected samples of jobs, most of them is visible (30s - 1m30s) faster with lto. While CI isn't extra stable in terms of performance, it does look good. So far no test failed yet (thou cannot test ARMv7 for now)
maxzor has quit [Remote host closed the connection]
maxzor has joined #dri-devel
<DavidHeidelberg[m]> output binaries: aarch64: 47.7 -> 47.2M; amd64: 177M -> 150M;
<jenatali> This is making me wonder if we use LTCG for our release binaries...
<HdkR> Isn't the answer, yes always use LTO in release unless you have bugs? :P
<kisak> ah, link-time code generation ... I definitely didn't read that as long term care group and get confused for a couple minutes.
<kisak> I've not really been paying attention to LTO and have been following upstream Debian packaging. Are these LTO bugs getting reported upstream for the linker devs to ponder?
<kisak> Or is the mesa side entirely responsible for investigating them?
<DavidHeidelberg[m]> kisak: LTO is these days in good shape, I think Firefox use it and other big projects
<jenatali> Yeah Windows has used it for a while
<DavidHeidelberg[m]> kisak: for example the failed arm crossbuild is probably compiler error (I reported it, but I'll have to also test more recent GCC... hopefully debian-snapshots will help); but usually LTO issues are the software issues these days
<jenatali> I just don't think meson enables it by default so we're probably not using it for Mesa. I should fix that
<kisak> for completing the build, yes, I agree it's healthy, but https://gitlab.freedesktop.org/mesa/mesa/-/issues/6911 and similar likes to keep coming back to haunt us and bisecting leads to random unrelated commits.
<DavidHeidelberg[m]> jenatali: yeah, neither does it enable LTO for Linux. I understand that because it often discovers hidden issues (as now the missing libgallium link).
<DavidHeidelberg[m]> kisak: if we get piglit tests which can reproduce that, it would be amazing :) but I guess no luck with lto related stuff. Anyway I think there is still too much flakiness in Mesa anyway. Maybe LTO can highlight the issues.
iive has quit [Quit: They came for me...]
<psykose> a lot of lto bugs are not the fault of the compiler(the linker doesn't do lto) but rather just issues lto makes more likely
<psykose> there's a few things that are impossible without lto that it could cause (symbol naming related things?) but for the most part it exacerbates things like strict-aliasing and ODR violations
<psykose> sometimes the lto itself is broken of course, but in my experience it is almost always code error
<psykose> it's definitely very hard to debug though
alyssa has quit [Quit: leaving]
<DavidHeidelberg[m]> I would sign that ^ :)
* DavidHeidelberg[m] sending brain $ systemctl suspend. Good night.
<psykose> sleep well
danilo has quit []
dakr has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
maxzor has quit [Remote host closed the connection]
maxzor has joined #dri-devel
shoragan has quit [Quit: quit]
srslypascal has quit [Remote host closed the connection]
shoragan has joined #dri-devel
maxzor has quit [Remote host closed the connection]
maxzor has joined #dri-devel
shoragan has quit [Read error: Connection reset by peer]
srslypascal has joined #dri-devel
shoragan has joined #dri-devel
<Lynne> airlied: well, I think I found out why my code doesn't work on nvdec
<Lynne> *nvidia
<Lynne> ...annexb
<Lynne> I can't find out how they put data into the bitstream buffer
<Lynne> they don't actually specify what the slice data should contain
columbarius has joined #dri-devel
<Lynne> but if they think it should contain annex-b, well, number one, they're wrong, number two, they're very wrong, number three, they need to take responsibility for their failure, shave their heads and become monks
co1umbarius has quit [Ping timeout: 480 seconds]
Akari has joined #dri-devel
<Lynne> oh, no, they have a closed source parsing library which I can't even inspect
<airlied> Lynne: yes they do
<Lynne> I don't know how to bring this up to them
<Lynne> last thing I want is for them to tell us to provide annex-b to decoders
<Lynne> we have the moral majority, 2 drivers which expect just startcode vs their 1 which doesn't
<airlied> if you pass a srcBufferOffset of 3 to them does it work?
* airlied isn't sure what intel is expected in short mode
<Lynne> no, it doesn't work, but I know it's a hard failure in the driver because speed slows down to 2 frames per second
<Lynne> dxva does not require annex-b in ffmpeg, in fact *no* hwaccel requires annex-b, most only require startcodes
<Lynne> I wouldn't even begin to know how to convert slices into annex-b form
<Lynne> so, uh, they need to be told they're wrong, and because they wrote the spec, and they can do whatever they like, there has to be an element of strategy to this
<Lynne> I guess we could point them to nvdec, which doesn't require annex-b, just startcodes
<Lynne> still, this is meant to be *reference* code
<Lynne> aside from the code being the most horrible sphagetti mess I've ever seen, to use a black box parsing library is as good of a technical reference as patents
cengiz_io has quit [Quit: Connection closed for inactivity]
kode54 has quit [Quit: Ping timeout (120 seconds)]
kode54 has joined #dri-devel
maxzor has quit [Ping timeout: 480 seconds]
kode54 has quit [Quit: Ping timeout (120 seconds)]
<airlied> Lynne: I've gotten their player to work with my driver ages ago, but it was a long time ago
<airlied> Lynne: but the spec should state this sort of thing, instead of them baking it into their driver
kode54 has joined #dri-devel
Company has quit [Quit: Leaving]
<Lynne> yeah, plus, the slices do seem vaild
<Lynne> because otherwise I know if I get failure in the bitstream because the speed drops
<Lynne> could really be what I suspect - just some oversight, like getting a CABAC flag wrong
<Lynne> it really does look like bitstream desync due to wrong parameters
<Lynne> I did check the registry xml spec for any gotchas in the comments, but found none
<airlied> Lynne: is it with lots of streams?
<airlied> but tbh I'm happy to just hand nvidia stuff and let them debug it, closed src drivers get to pay for their choices
<Lynne> with a lot of streams? no, all of them, no h264 stream decodes correctly
<Lynne> yeah, I'll leave the fun of debugging themselves
<Lynne> they had at least 3 weeks since I got h264 working to test it but never did
<Lynne> still, wow, a black box h264 parser, I was wondering why I couldn't see anything grepping through their code
<Lynne> just wow, the tsg should've gotten someone to write something based on the spec
<Lynne> I mean, they did, but what was I going to do? leave it up for someone else to mess it up
YuGiOhJCJ has joined #dri-devel
quantum5_ has quit []
quantum5 has joined #dri-devel
<vjaquez> Hi, Stephane and I are trying to replace the nvidia closed source parser (they also are using it for the CTS) with something with gstreamer: https://github.com/Igalia/GstVkVideoParser
nchery has quit [Ping timeout: 480 seconds]
<vjaquez> and yes, it only provides annex.b frames
kode54 has quit [Quit: Ping timeout (120 seconds)]
kode54 has joined #dri-devel
<Lynne> have to say, not the way I would've improved the code
<Lynne> I would've researched the digital equivalent of napalm and set it aflame
nchery has joined #dri-devel
mwalle has quit [Quit: WeeChat 3.0]
JohnnyonFlame has joined #dri-devel
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
OftenTimeConsuming is now known as Guest71
OftenTimeConsuming has joined #dri-devel
Guest71 has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
kts has quit [Quit: Leaving]
cdoltb^ has quit [Remote host closed the connection]
<DemiMarie> I wish Linux required SoC firmware to be built along with the driver that uses it, instead of forbidding that.
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
kode54 has quit [Quit: Ping timeout (120 seconds)]
kode54 has joined #dri-devel
fab has joined #dri-devel
<Lynne> the fact that image creation for encoding (and decoding) requires a valid video profile is mental
<Lynne> why/how would a decoder care if an encoder is chained?
<Lynne> is it to support some horrid alien media chip which has different memory for different codecs?
<Lynne> I see no way out of this but to cheat and say my image has valid usage flags and paperwork and hope the encoder doesn't care (and why would it?)
<Lynne> I remember when it didn't used to be like this a year ago, I think, but they changed the spec
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
dcz_ has joined #dri-devel
kode54 has quit [Quit: Ping timeout (120 seconds)]
kts has joined #dri-devel
rasterman has joined #dri-devel
danvet has joined #dri-devel
maxzor has joined #dri-devel
Leopold has quit [Remote host closed the connection]
Leopold has joined #dri-devel
maxzor has quit [Remote host closed the connection]
maxzor has joined #dri-devel
junaid has joined #dri-devel
srslypascal has quit [Quit: Leaving]
Company has joined #dri-devel
srslypascal has joined #dri-devel
pcercuei has joined #dri-devel
JohnnyonF has joined #dri-devel
kode54 has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
Leopold has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
gouchi has joined #dri-devel
Leopold has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
junaid has quit [Ping timeout: 480 seconds]
hfink_ has quit []
hfink has joined #dri-devel
Akari has quit [Quit: segmentation fault (core dumped)]
junaid has joined #dri-devel
zaratustra has quit [Quit: zaratustra]
zaratustra has joined #dri-devel
maxzor has quit [Ping timeout: 480 seconds]
Lucretia has quit []
Lucretia has joined #dri-devel
Leopold has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
kts has quit [Quit: Leaving]
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
gouchi has quit [Remote host closed the connection]
MrCooper_ is now known as MrCooper
<MrCooper> DavidHeidelberg[m]: we can enable LTO build testing in CI, but not for building binaries used in test jobs as long as it results in seemingly random failures
<DavidHeidelberg[m]> MrCooper: sure, agree with you :)
enunes has quit [Remote host closed the connection]
enunes has joined #dri-devel
kts has joined #dri-devel
cengiz_io has joined #dri-devel
zehortigoza has quit [Remote host closed the connection]
<ishitatsuyuki> for a middle ground, ThinLTO might provide similar results while being more parallelizable and not harm too much on build time
<ishitatsuyuki> it's clang only though, not sure if that's a dealbreaker
Leopold_ has quit []
Leopold_ has joined #dri-devel
<MrCooper> it might also hit the same random issues though
junaid has quit [Read error: No route to host]
junaid_ has joined #dri-devel
<FireBurn> DavidHeidelberg: Yeah I build with clang-15, lto, O3
<FireBurn> That is thinLTO
junaid_ has quit []
<ishitatsuyuki> "-Wl,-O1 -Wl,--as-needed"
<ishitatsuyuki> I don't suggest adding random link flags. These stuff gets you no performance and tons of headaches when behavior diverges from upstream
<ishitatsuyuki> (the LTO one is OK, but you only really need that. Also -flto=thin is the correct one)
jani has quit []
<ishitatsuyuki> wait, you don't pass -flto to ld. some linkers may refuse to load IR objects if not passed -flto
jani has joined #dri-devel
jani has quit []
jani has joined #dri-devel
<hays> in the spirit of making a christmas present better, does anyone have any tips on what might be causing this error on an unsupported hostile fork of panfrost when trying to load anything wayland (sway, gl2mark, etc.) Assertion '!(type== DRM_PLANE_TYPE_PRIMARY && crtc->primary)'
<emersion> can you share a drm_info log?
<hays> emersion: https://termbin.com/nvv3
<hays> i ran that from an ssh console not sure it makes a difference
<hays> this might just be a driver bug, but i had wayland working on almost the exact same build, just debian testing instead of debian stable... so older versions of many things
<hays> libdrm is off git though, and wayland-protocol is also built from source
<emersion> hays: sounds like a very old wlroots bug which got fixed ages ago
<emersion> used to trip on primary planes compatible with multiple CRTCs
<pinchartl> emersion: yes it's a weird concept. if only we could redesign all this :-)
<hays> emersion: ok ill try to build wlroots from source
<emersion> do you know which wlroots version you have?
<hays> i don't
kts has quit [Quit: Leaving]
<hays> 0.11.0-3
kts has joined #dri-devel
<hays> this gives me something to work on... updating wlroots requires updating wayland
<emersion> you should be able to use subprojects
alyssa has joined #dri-devel
<alyssa> robclark: re blit-based glReadPixels, I think mesa/st is ok here
JohnnyonF has quit [Ping timeout: 480 seconds]
<alyssa> At least iris treats usage=STAGING as "use linear"
kts has quit [Quit: Leaving]
<hays> emersion: no dice.. wlroots 0.16 wayland 1.21.0
<hays> thanks for the insight though--appreciate it
kts has joined #dri-devel
<emersion> hays: same error?
<hays> yeah
<emersion> that's pretty weird, this should protect against the assert:
<hays> i mean... its fine i think. was trying to make things a little cleaner than boot->autologin-tty->startxfce4->autorun emulationstation
<hays> emersion: im installing to /usr/local im maybe assuming the system can see all of it there and gives it priority
<emersion> installing it won't make the compositor use the new wlroots version
<emersion> you need to recompile the compositor as well
<hays> are you talking about sway
<kisak> apparently my IRC connect doesn't meet the requirements for #asahi, and I'm not interested in draging and of the drama related to that in here ... seems like side channels are blocked for me so I'll drop this here: alyssa / lina, I noticed that oibaf's PPA has the asahi gallium driver turned on. Two questions related to that: 1) Are you to happy with the overall health of the driver to support users on
<kisak> point releases of mesa and 2) do you currently have interest in user feedback from outside of the asahi linux distro? Objectively asking if I should try to turn it on in the kisak-mesa PPA.
<emersion> hays: yea
<emersion> hays: the easiest way to build new sway+wlroots+deps is https://github.com/swaywm/sway/wiki/Development-Setup#compiling-as-a-subproject
junaid has joined #dri-devel
<alyssa> kisak: no to both questions, because the required kernel support is downstream
<alyssa> and as a consequence there's no linux uapi in mesa/mesa
<alyssa> which means the driver in mesa/mesa is useless on its own
<alyssa> (it does have dodgy macOS 12.3 support but I've been threatening to remove that code for months)
<alyssa> so there's no point packaging mesa/mesa
<alyssa> for asahi
<alyssa> but also no harm -- it just won't probe and users will get llvmpipe instead
<alyssa> the powervr vulkan driver is in the same boat IIRC
<alyssa> and panfrost was like this for a while too
<kisak> okay, thanks
gouchi has joined #dri-devel
<alyssa> :+1:
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
The_Company has joined #dri-devel
ArcticAtelier has joined #dri-devel
camus has quit [Remote host closed the connection]
Company has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
junaid has quit [Ping timeout: 480 seconds]
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
cphealy has joined #dri-devel
JohnnyonFlame has joined #dri-devel
tobiasjakobi has joined #dri-devel
heat has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
<hays> emersion: thank you for that.. i willuse that nexst time :) haha
jani has quit []
jani has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
jani has quit []
<hays> emersion: sadly i got it working, but then another really dumb issue prevents me from going forward
jani has joined #dri-devel
<hays> i may push harder on it, but i am afraid a bit to break what i have that is basically working--if a little dumb
kts has quit [Quit: Leaving]
Leopold has joined #dri-devel
krushia has joined #dri-devel
Akari has joined #dri-devel
maxzor has joined #dri-devel
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
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
Haaninjo has joined #dri-devel
<Lynne> airlied: figured out short mode on intel?
<Lynne> close to getting packets on the encoding side here
lemonzest has quit [Quit: WeeChat 3.6]
<DemiMarie> hays: have you considered seeing if the Debian maintainers can include a newer wlroots in backports? wlroots seems like something that Debian should *only* be including in sid/backports, not in stable
alyssa has left #dri-devel [#dri-devel]
<airlied> Lynne: nah pulled out more hair, didn't stop it locking up yet, might switch to encoding when I get going again
JohnnyonFlame has quit [Ping timeout: 480 seconds]
Rayyan_ has left #dri-devel [#dri-devel]
<Lynne> I think you should, encoding API's really not as bad as decoding if you just want I-frames
<Lynne> and for P-frames, the users manage the frame indices themselves
<Lynne> plus, wouldn't it be a great shame if someone got P-frame encoding working ahead of vk_video_samples and nvidia?
<airlied> Lynne: you have a navi2x?
<airlied> just have to decide which rev of the vaapi driver to start porting from
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
<Lynne> yup, navi21
danvet has quit [Ping timeout: 480 seconds]
Akari has quit [Quit: segmentation fault (core dumped)]
<airlied> Lynne: so MESA_decode_av1 after encode? :-P
<Mis012[m]> Lynne: would you at least agree that standardized v4l2 would be saner than X-to-vaapi translation mechanisms :P
<Mis012[m]> actually it's userspace ABI isn't it, how come there's so little oversight over stuff that is not allowed to change at a later date
<Lynne> airlied: absolutely, 100%
<Lynne> I also may get my hands on some niagara falls intel card as soon as next week, which has av1 encoding I'm rather keen to get working
<Lynne> so maybe even a MESA_encode_av1
<Lynne> Mis012[m]: for SoCs or in general?
<Mis012[m]> Lynne: everything is an SoC these days
<Mis012[m]> including GPU dies fwiw
<Lynne> I meant the level of curse
<Mis012[m]> well, imho treating x86 special is usually not for the better
<Lynne> it's not special, just less cursed due to decades of compatibility, for better or worse
<Mis012[m]> the SoC in this laptop has spent die space on glue that pretends AMBA IPs are pcie
<Mis012[m]> that's cursed AF
<Lynne> regardless, I prefer hwaccels rather than decoders, they're more flexible, easier to fix, easier to implement, lower overhead, easier to schedule, and offer you sub-frame latency if you really need it
<Mis012[m]> and you literally can't access those IPs directly, you have to go through the two PCIE phys merged into one
<Mis012[m]> Lynne: isn't the point of decoders that they are lower power?
<Lynne> reading a few dozen golomb coded ints won't break the bank
<airlied> Lynne: yeah i have some prerelease dg2 cards that i assumr have av1 encode
<Mis012[m]> it won't break a bank in an architecture that doesn't really target the same level of power usage as phone SoCs
<linkmauve> Lynne, where do you place the limit between decoder and hwaccel?
<linkmauve> Is it stateless vs. stateful?
<Mis012[m]> well, hwaccel probably shouldn't include sw /hides
<Mis012[m]> as in some MCU core
<Lynne> linkmauve: giving it slices vs giving it NAL units
<hays> DemiMarie: i did not consider that--but yeah i think they would target backports for newer versions.. there seems to be some version constraints to manage
<hays> power outage here
<linkmauve> Ok.
Duke`` has quit [Ping timeout: 480 seconds]
apinheiro has joined #dri-devel
heat has quit [Read error: No route to host]
heat has joined #dri-devel
genpaku has quit [Remote host closed the connection]
genpaku has joined #dri-devel
gouchi has quit [Remote host closed the connection]
heat_ has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
codingkoopa90 is now known as codingkoopa
heat_ has quit [Remote host closed the connection]
heat_ has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
fab has quit [Quit: fab]
apinheiro has quit [Quit: Leaving]
rasterman has quit [Quit: Gettin' stinky!]
dcz_ has quit [Ping timeout: 480 seconds]
q66_ has joined #dri-devel
q66 has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: dodo]
<Lynne> I thought I'd have to write out all AUs manually one by one
<Lynne> I'm glad we have the CBS infra
zehortigoza has joined #dri-devel