<glehmann>
alyssa: rdna4 supports 64K images (but not as render targets)
bluetail has joined #dri-devel
<HdkR>
oooo, mega textures
<HdkR>
RAGE is coming back
kzd has quit [Ping timeout: 480 seconds]
gfxstrand is now known as Guest10819
gfxstrand has joined #dri-devel
fab has joined #dri-devel
Guest10819 has quit [Ping timeout: 480 seconds]
jsa1 has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
jkrzyszt has joined #dri-devel
tzimmermann has joined #dri-devel
coldfeet has joined #dri-devel
zzyiwei has quit [Remote host closed the connection]
tobiasjakobi has joined #dri-devel
coldfeet has quit [Quit: Lost terminal]
tobiasjakobi has quit []
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
frankbinns has quit [Ping timeout: 480 seconds]
ondracka has joined #dri-devel
woskova has quit []
woskova has joined #dri-devel
<pinchartl>
lumag: -ENOTIME for the next two weeks I'm afraid. I'll travel on Sunday and will be back on the 22nd
<lumag>
pinchartl, I see, thanks
bolson has quit [Ping timeout: 480 seconds]
<tzimmermann>
sima, do you have comments on the fbdev-backlight series?
<sima>
tzimmermann, looked reasonable
<sima>
or do you want some r-b?
<tzimmermann>
sima, maybe give it ack at least. IDK if helge is active. i haven't seen him recently
<sima>
tzimmermann, for core stuff we still have full maintainership in drm-misc
<sima>
I carved that out when helge took over
<sima>
backlight itself is more fun, since nominally that's still in the separate tree and the backlight maintainer occasionally gets annoyed when we just merge stuff
<sima>
tzimmermann, and I'd treat helge like any other drm stakeholder, if he's not around just merge after a reasonable time to drm-misc
<tzimmermann>
i expect this to go through lee jones' tree (unless i hear differently)
<tzimmermann>
sima, and if you have a bit, maybe could you look at the dumb-buffer series i posted. it slightly concerns UAPI. please let me know if you have comments. (there's also been some controversy, which apparently has been resolved)
<tzimmermann>
sima, i mostly want you to be aware that this is happening
<sima>
oh dear how did mesa get to bpp of 64
<sima>
that's defo abuse of dumb buffers I think but oh welp
frankbinns has joined #dri-devel
<tzimmermann>
exactly :)
<tzimmermann>
people doing funny things with this
<sima>
tzimmermann, so one thing we can't do is warn on userspace input
<sima>
defo not warn and allow it, but warn and fail also not cool
<tzimmermann>
maybe drm_warn_once() ?
<sima>
still a bit ugh
mvlad has joined #dri-devel
vliaskov_ has joined #dri-devel
dt9 has joined #dri-devel
<sima>
tzimmermann, dropped a reply with some thoughts
<tzimmermann>
i can surely drop it. but that warning only comes on bpp == 3,5,6,7 and other crazy stuff. that switch already filters out the "known crazy stuff" (10, 12)
<tzimmermann>
ok, thanks
<sima>
yeah I do see the case for warn_once since it helps to debug regressions
<sima>
so not opposed in this very specific case here
<sima>
especially if we also lock down ->depth validation, which I'd do while we're digging through this mess
<sima>
tzimmermann, also thanks for doing this, I looked into this years ago and gave up because too much a mess
<tzimmermann>
sima, thats for the mail. tomi has been very vocal about not rejecting any bpp values. but warn_once seems good to me. about depth values: for all legitimate bpp values, we handle them in the _color_mode() lookup function. it doesn't handle the awkward cases, so things should be fine
<sima>
tzimmermann, I'm more thinking whether we should be strict and reject any funny depth values
<sima>
so anything that's not depth == 0 || depth == bpp
<sima>
and wrt tomba 's ask, I think what we could do is just document that you should use the bpp=64 trick from mesa as escape hatch
<tzimmermann>
that will break depth==15 and depth==24, which have bpp==16 and bpp==32
<sima>
or encourage people to do a dumb_create2 with fourcc and modifiers
<sima>
tzimmermann, yeah but those should be filtered out as real formats and handled with the fourcc path?
<sima>
I'm only talking about the hacky fallback handling for the non-fourcc case
warpme has joined #dri-devel
<tzimmermann>
but what do you mean by 'depth' then?
<tzimmermann>
there's only bpp, which we take as a raw value
<sima>
hm
<sima>
I'm mixing stuff up
<tzimmermann>
ok, no worries
<sima>
tzimmermann, yeah mixed it up with legacy addfb, which also has depth
<sima>
and there we fully validate
<sima>
somehow I thought dumb_create thas this too
<sima>
so yeah pls ignore my comments about depth, apologies for the noise
<lumag>
sima, stupid question, did we ever propose to Lee to move backlight to drm-misc? Or do you think that it might counterproductive?
<tzimmermann>
BTW, everyone seems supportive of a dumb_create2 with fourcc. maybe we should attempt to do this or put it on the TODO list
<tzimmermann>
lumag, i wouldn't want even more stuff in drm-misc TBH
<sima>
might be lack of need with stuff like rounding ...
<sima>
lumag, we did, he doesn't want to
<lumag>
ack :-)
<sima>
tzimmermann, I think it's annoying that backlight is the one thing kms drivers generally need that isn't in drm
<sima>
for pci drivers we just merge backlight stuff into drivers directly, which imo makes much more sense from a coordination pov
<tzimmermann>
is there so much churn?
<sima>
there isn't, which is why I don't care, just find it silly
<tzimmermann>
ok, lol
<sima>
it's a bit like helge maintaining fbdev
<sima>
if it makes people happy, go for it, as long as it's not blocking us
<austriancoder>
valentine: is there a reason you removed marge from !33759?
<sima>
tzimmermann, if we ever get around to properly integrating backlight into kms consistently and ditch that fbdev special case, then there might be some churn
<sima>
but 95% probably within drm and fbdev/core, so not a concern for lee
<valentine>
austriancoder: Yes, writing a comment right now, TLDR is that the recent LAVA changes broke other farms
<sima>
I think your rework really is the only part of backlight architecture dusting that impact's lee's stuff directly
<austriancoder>
valentine: ah okay
<tzimmermann>
sima, it's not really high on my todo list, but i'll keep it in mind
<pjakobsson>
pushing drm-tip is taking way looooong
<tzimmermann>
btw, we really mess up kconfig dependencies wrt backlight. DRM drivers often select it, when they should depend on it
<sima>
tzimmermann, I was hoping that hans de geode would dig in, it's really messy with uapi impact
<sima>
tzimmermann, jani has really dug into this and despaired :-/
<sima>
this = backlight kconfig
<tzimmermann>
ouch
mehdi-djait3397165695212282475 has quit []
mehdi-djait3397165695212282475 has joined #dri-devel
<sima>
iirc at least, so chat with jani before you get going
<tzimmermann>
i gave it a quick lock (and then quickly looked elsewhere)
<jani>
that's a good strategy
<jani>
:p
<sima>
yeah that's a bit the kconfig expeirence :-/
<tzimmermann>
i see i'm in good company :D
<jani>
if kconfig was a separate upstream open source project, there might be incentive, but the whole thing is so fringe
<sima>
imo people adding tiny kconfig symbols for very small things also doesn't help
benjaminl has quit [Read error: Connection reset by peer]
<sima>
which is why I'm trying to curb that as much as possible in drm, gpu drivers tend to be huge already anyway
benjaminl has joined #dri-devel
<sima>
still hoping that lto could sort some of this out instead for really tiny setups with everything built-in
<jani>
yeah, I'm not sure I buy the whole "people might want to disable this and enable that"
<tzimmermann>
sima, i try to avoid these tiny symbols, but sometimes it's the only way without messing uo someone's .config file
<jani>
anyway, re backlight. IMO the correct thing to do is to depend on BACKLIGHT, or depend on BACKLIGHT || BACKLIGHT=n
<sima>
tzimmermann, yeah, there's unfortunately a huge pressure to add more and make the situation worse
<jani>
which one to use, uh, depends on the case
<jani>
IMO selecting it is always broken
<tzimmermann>
jani, this. backlight is user-selectable. so we shouldn't autoselect it
<jani>
way back when I tried to switch all of them to depends, I got negative feedback because it's an inconvenience. select is so "simple"
<lumag>
tzimmermann, it was logical to be autoselected, when we had seprate fbdev, LCD and backlight drivers. Might it make sense to make it non-user-selectable now?
<lumag>
Ugh. ... 'it was logical to have BACKLIGHT to be user-selectable...'
<jani>
you see, if say i915 depends on backlight, and backlight is disabled, you won't even see i915 in menuconfig. and that's what's so hard about this. the whole kconfig UX is so bad
* lumag
thinks that the best kconfig UI is ed and 'make oldconfig'.
<jani>
you'd want to see something like, "so you want to enable i915, please enable these too: <list of config items>" and maybe recursively
<jani>
lumag: *sigh* that's what I do. well s/ed/emacs/
<jani>
'make oldconfig', then go see what the end result in .config was
<lumag>
jani, but for which symbols do we need to show such help string?
<jani>
I mean for *anything* that depends on something that's not enabled
<lumag>
Would you like to see tons of ARM options on x86?
<lumag>
Most likely you mean 'depends on something user-selectable'
<jani>
A depends on B. you won't see A in menuconfig unless B is enabled.
<jani>
maybe you don't need to *see* it, but you should be able to search for it, and then recursively enable stuff to be able to enable A
<lumag>
So, still 'depends on user-selectable'. You can't enable ARM64 or ARCH_QCOM on x86
<jani>
but this whole discussion is moot, because I find it highly unlike that anyone would be crazy enough to dig into kconfig guts to actually do this
<lumag>
:D
<lumag>
Sounds like GSoC project.
<jani>
and I've actually been crazy enough to *look*, and ran away
<jani>
I think that would just lead to *another* UI. we already have plenty :p
<jani>
all of them depend on an arcane C library
<jani>
like, I think you should be able to get warnings for selecting symbols that a) have dependencies, or b) have user prompts
<jani>
that's what the kconfig documentation tells you to avoid. I can't remember the number of times I've copy-pasted that documentation snippet in reply to kconfig changes
<jani>
we have a system that does not automatically discourage bad habits
<jani>
actually somewhat encourages bad habits, because select is more convenient at first
<jani>
/rant
fantom has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
<jani>
tzimmermann: anyway, if you switch all select backlight to depends on backlight, I'm on board
<tzimmermann>
jani, ok. i'll do so if i find some time
<jani>
\o/
<sima>
yeah happy to weight in with some acks too if that helps push this
<jani>
I think hans sorted out some of the ACPI parts, should look if we could reduce the selects there too
<sima>
yeah acpi selects are nasty, because they're multiple levels
<sima>
maybe we should have a kconfig sanitizer in checkpatch
<sima>
and complain if someone adds a new select BACKLIGHT (once the cleanup has landed)
<sima>
otherwise these pop back up forever
<jani>
another tool I refuse to touch because it's a) kernel niche, and b) written in perl :p
jsa1 has quit [Ping timeout: 480 seconds]
<jani>
say what you may about sphinx and restructuredtext, but the custom xml docbook pipeline we had in kernel was ridiculously bad
<jani>
as a whole we seem to be amazingly incapable of reusing existing tools and always err on the side of reinventing the wheels
<jani>
sure, there are some valid reasons, like reducing external build dependencies
rasterman has joined #dri-devel
<sima>
I think most is because of 3 decades of inertia :-/
<jani>
sure, but the attitude remains
kts has joined #dri-devel
colinmarc has joined #dri-devel
<colinmarc>
weird question. if I have two identical GPUs and a game running in a VM, is it technically possible to pause the VM, move everything it owns to the second GPU, and unpause it? without the game being implemented in a special way?
<colinmarc>
slash is there a name for this?
apinheiro has joined #dri-devel
<javierm>
jani: I don't think there's any other FOSS project I'm involved where *new* tools are written in perl
heat has joined #dri-devel
<K900>
colinmarc: Theoretically maybe, practically no driver provides you the tools to do this
<javierm>
jani, lumag: the least bad kconfig UX I know is when you search a symbol in menuconfig (with `/`), that actually shows you the depds that a symbol has and IIRC even the dep graph
<K900>
Actually Nvidia has some sort of live migration for GPUs I think
<K900>
But it's only for Quadro class stuff
fab has quit [Quit: fab]
fab has joined #dri-devel
<colinmarc>
could a really sophisticated vulkan layer do it?
fab is now known as Guest10834
<austriancoder>
valentine: as you are working lot with CI, I have a question: where can I see the stats of the daily ci run for my manual boardfarm jobs?
<K900>
colinmarc: You'd have to serialize all the GPU state somewhere
<colinmarc>
<HdkR> "Look up criu-amdgpu" <- thank you, this looks interesting :)
phasta has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
Calandracas_ has joined #dri-devel
dolphin has joined #dri-devel
<tomba>
Anyone know if raspberry pi 5 supports compute shaders with opengl?
Calandracas has quit [Ping timeout: 480 seconds]
<Hazematman>
tomba: according to mesa matrix https://mesamatrix.net/ yes `GL_ARB_compute_shader` is supported on v3d (the opengl driver for the pi5 gpu)
<tomba>
Hazematman: thanks, I need to debug this more. I didn't see the compute shader extension advertised from mesa, and a simple compute shader example just gave kernel errors.
vliaskov_ has quit [Ping timeout: 480 seconds]
<tomba>
Hazematman: also thanks for pointing to mesamatrix, looks very useful =)
<Hazematman>
yeah if you just want to quickly check hardware support, its nice :)
rgallaispou1 has quit [Read error: Connection reset by peer]
qpla has joined #dri-devel
phasta has quit [Ping timeout: 480 seconds]
guludo has joined #dri-devel
phasta has joined #dri-devel
<dj-death>
someone knows if there is a equivalent of the screenshot layer for opengl ?
soreau has quit [Ping timeout: 480 seconds]
FireBurn has joined #dri-devel
bbhtt has quit [Ping timeout: 480 seconds]
warpme has quit []
fab has joined #dri-devel
pcercuei has joined #dri-devel
Guest10834 has quit [Ping timeout: 480 seconds]
fab has quit [Ping timeout: 480 seconds]
<tzimmermann>
PSA: With -rc6 around the corner drm-misc-next-fixes is now open. Features still go into drm-misc-next. Fixes for stable still go into drm-misc-fixes. Fixes for v6.15 go into drm-misc-next-fixes. Patches in -fixes branches should be small and have a Fixes tag.
coldfeet has joined #dri-devel
<sima>
jfalempe, I'm a bit confused by your reply, I was talking about why we need vmap, you replied with that we have support for tiling?
<sima>
that's a bit separate issues I think, or maybe I'm just confused
<sima>
since if we need to set up a vmap for every framebuffer just for panic, that's a bit awkward
<sima>
jfalempe, wrt compression, one trick is to clear the compression metadata to "everything uncompressed", that works I think with all intel compressed scanout formats still
<sima>
it's not an option with some of the lossy compressed formats like afbc has
tango_ has quit [Ping timeout: 480 seconds]
tango_ has joined #dri-devel
<alyssa>
sima: afbc is lossless, afrc is the lossy one
<alyssa>
that trick should work with afbc
<sima>
oh I guess I just smashed them all into one arm-compression-thingy :-P
<sima>
but yeah for lossless ones with explicit compression control bits it tends to be the simplest trick for panic logging
davispuh has joined #dri-devel
<sima>
or at least the least risky, since you don't need to mess with hw state and might hang the memory controller on some invalid watermark config
<zmike>
it looks okay to me but I think you probably want dcbaker / daniels to signoff for something more meaningful
<K900>
I just want to make sure it doesn't blow up dril
<K900>
It seems to not have, so far at least
<K900>
But I didn't test it on really weird configs
<K900>
(because I don't have any)
<zmike>
I don't have any either
<zmike>
hence why the initial dril rollout had so many issues
soreau has joined #dri-devel
<K900>
We (NixOS) had people exhume xf86-video-intel's rotting corpse
<K900>
And then get mad because it doesn't work with dril
<K900>
And I didn't nack it in time so now we have xf86-video-intel in the repos again
<zmike>
sounds great
<jfalempe>
sima: you mentionned non-linear buffer, so tiling is a kind of non-linear buffer. (but the whole framebuffer is still contiguous in virtual memory).
forthebesteffort has joined #dri-devel
nerdopolis has quit [Ping timeout: 480 seconds]
<jfalempe>
sima: regarding vmap, it's the only way to write the pixels, so either we do it in the panic handler, but if that is not possible, we can make sure the primary framebuffer is always vmapped before we send it for display.
<alyssa>
gfxstrand: think it's a CTS bug, the opaque buffer thing
<alyssa>
not sure how nvk passes tho
mehdi-djait3397165695212282475 has quit []
<alyssa>
I'm like 98% sure this is a CTS bug. I'm just still confused how nvk would pass the test.
<alyssa>
Oh. Because CTS version
<alyssa>
046343f46 ("Stop querying device address from unbound buffers")
<alyssa>
the fix is in main but not tagged into any vulkan CTS release yet
<alyssa>
clown.gif
<alyssa>
well, that solves that.
<forthebesteffort>
I enhanced the method a bit, 256-57-57-57=59 128-59=69 256+72=328-69-57-57=145 cause intermediate result 69 did not divide by two, we subtract 1. similarly 256-60-60-60=76-16=60 128-60=68 now 68 divides by two we need to add 2, so 326-68-60-60=138+2=140 so with third member 256+68=232 so 256-62-62-62=70-8=62 128-62=66 cause 66 divides by two we add 2 again. so 324-66-62-62=134+2=136
<forthebesteffort>
, so the bottom line is when we remove 256 you get 72 70 or 68 but when we do the thing before to any of them we get twice of that, so obviously after removing single result of all from such selection other elements become 0, selection elements get filtered to the single value searched. to get rid of the conditional only for odd format even indexes should be used or smth. Needs a bit
<forthebesteffort>
more testing but i assume that is the final so called slimmest and hence much preferred method. so values of the members were mentioned 72 70 and 68 for high indexes 115 120 124 where as we calculate in half the indexes as it was demonstrated on this statement of the problem.
warpme has joined #dri-devel
davispuh has quit [Ping timeout: 480 seconds]
<mareko>
zmike: the surface idea seems reasonable
<forthebesteffort>
so 26 comes from 256-115-115 so does 16 come from 256-120-120 so does 8 come from 256-124-124
<zmike>
cool
<forthebesteffort>
now you would hear a lot of me, such as interferring with politics defending my favorites, throwing big parties and even visiting XDC and alike, but ever since i became slightly injured, i have had to make selections , cause the efficiency in my life is lower, so i sacrificed my time to programming to start progressing towards rehabilitation plan later.
<dcbaker>
K900: re Benjamin’s concerns about changing the option type. Is the long term plan for this to be like longline where we’re going to have to support both a gbm loader and a non loader version, or more like OpenCL where the standalone support will be removed?
<dcbaker>
Sorry, not logged into gitlab on my phone
kzd has joined #dri-devel
<K900>
My long term goal is to just move the libgbm loader out of Mesa
<K900>
And have it be just another dependency like, say, vulkan-loader is now
forthebesteffort has quit [Remote host closed the connection]
KAL9000 has quit [Ping timeout: 480 seconds]
<dcbaker>
I think then having two options might be easier to deal with (rather than changing the type) one that turns on gbm support, and one that toggles standalone vs loaders
<dcbaker>
Have you started on a standalone loader for gbm yet?
Company has joined #dri-devel
<K900>
I think the existing one is fine, mostly
<K900>
It can just be moved out to a separate repo
<K900>
But yeah it basically ends up being two options internally anyway
kts has joined #dri-devel
<K900>
We can expose that as API, but it gets a little weird because not every combination of those options actually makes sense
<K900>
Like gbm=disabled external_gbm=enabled
<K900>
What should that do?
<psykose>
if they don't make sense just throw an error
mbrost has joined #dri-devel
bolson has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
epoch101 has joined #dri-devel
<alyssa>
anyone see KHR-GL46.es_31_compatibility.shader_storage_buffer_object.basic-binding fail?
<alyssa>
new since CTS uprev for me
<alyssa>
passes on its own fail, fails reliably if run after KHR-GL46.limits.max_varying_vectors
heat has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
<zmike>
alyssa: pls cc me and assign to kamil
<alyssa>
done
<alyssa>
as a bit of good news, uprevving vulkan cts lets me drop one of my "HACK: DO NOT UPSTREAM" patches so that's nice
<alyssa>
and drop a bunch of backports
<alyssa>
so my cts branch is now 5 patches away from upstream, and all 5 are for GLCTS issues :melt:
<dcbaker>
K900: I would have gbm-loader=bool along with the existing use gbm option
<alyssa>
(ok 3/5 are reverts of something that blows up and IDK if it's my bug or not. But I'd think someone else would hit it too if it wasn't my bug.)
<K900>
dcbaker: Do you mean, like, separate options for gbm-loader and gbm-backend?
<K900>
That still ends up in a weird state where we can't build gbm-backend=true gbm-loader=false with no ambient libgbm
<K900>
Which I guess is maybe fine?
<K900>
I just want to be clear here that I hate all the options
<K900>
I think the one I have right now is the one I hate the leasat
<K900>
But I do not _like_ any of them
<dcbaker>
Like a “gbm=feature” (no change) and gbm-backed=loader|standalone (new option), with the long term plan to deprecate the latter. And if you select a configuration that doesn’t work you get an error
<dcbaker>
I don’t like any of them either, but trying to come up with a good way to keep bisects working
<K900>
Hmm
<dcbaker>
You can paint the second option however you like your bikesheds, string options, bool, whatever
<K900>
Yeah I was not thinking about bisects
<K900>
I was more thinking about making illegal states unrepresentable
<dcbaker>
Changing option types and bisects sucks, but this suggestion still doesn’t create an illegal state situation, if you turn gbm off the loader va standalone question is moot
<K900>
I guess
<K900>
If you think about it that way
Duke`` has joined #dri-devel
<K900>
Hmm
<K900>
Need to think
<K900>
Currently pretty out of think juice
<dcbaker>
I’ve been meaning to do some work there in meson, but I only have so much meson time and there’s so much to do… :/
mbrost_ has joined #dri-devel
<alyssa>
dcbaker: relatable
mbrost has quit [Ping timeout: 480 seconds]
epoch101 has quit []
mbrost has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
<K900>
Same but nixos tbh
FireBurn has quit [Ping timeout: 480 seconds]
davispuh has joined #dri-devel
mbrost_ has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
epoch101 has joined #dri-devel
gouchi has joined #dri-devel
frankbinns has quit [Ping timeout: 480 seconds]
epoch101 has quit [Ping timeout: 480 seconds]
frankbinns has joined #dri-devel
<K900>
dcbaker I have something but gitlab is shitting itself
* alyssa
can only keep track of so many sets of code naemes
<alyssa>
but yeah, bumping to 1.3 seems reasonable I think
<K900>
That's uh
<K900>
I think that's unstable from January 2024
<danylo>
I guess it's time for a bump =)
<K900>
Yeah
<K900>
Definitely
<dcbaker>
K900: it’ll be a few hours before I can give it a good look.
<K900>
No rush
<dcbaker>
Anyone building rust stuff needs a relatively recent version of meson too. That’s going to be 1.7.1 or 1.8 soon because of bindgen changes :/
<alyssa>
dcbaker: tbf, a lot depends on mesa_clc than rust rn
<alyssa>
notably, iris
<zmike>
uhhh
<zmike>
this is a really dumb question
<zmike>
but is it actually legal to create a pipe_surface from a buffer???
<zmike>
oh it's a fucking clover thing
<zmike>
fuck this
<alyssa>
zmike: also rusticl no?
<alyssa>
or is that a different fucking thing
<zmike>
I can't imagine it's a rusticl thing because zink definitely does not do that
bbhtt has joined #dri-devel
gouchi has quit [Remote host closed the connection]
<anholt>
I think we could poll core developers and decide to retire clover even if we're not at parity for that hw.
<alyssa>
anholt: acked-by
<redisorporgand>
but that was kind of the start of it, but this latest method is also sophisticated, as the intrinsics for sequences to filter out a focal subset values are slightly moer work. So but the elaboration of the second half goes so, those procedures go into as reference values as told, now since 256+73 is out of reference by 5 it's that 329-324=5 right, hence 8+66-62=12, hence 12-5=7 where
<redisorporgand>
other elements cancel out, so what would we do with 7? As we got 66 as reference, so obviously 66+7 is single 73 , that needs more testing but appears to be the third working fs method.
mripard has quit [Quit: WeeChat 4.5.1]
jsa1 has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
NiGaR has quit [Ping timeout: 480 seconds]
NiGaR has joined #dri-devel
phasta has quit [Quit: Leaving]
jfalempe has quit [Quit: jfalempe]
jfalempe has joined #dri-devel
nitikesh_ has quit []
gouchi has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
riteo has quit [Ping timeout: 480 seconds]
warpme has joined #dri-devel
riteo has joined #dri-devel
epoch101 has joined #dri-devel
epoch101 has quit []
redisorporgand has quit [Remote host closed the connection]
nameandfigure has joined #dri-devel
nameandfigure has quit [Remote host closed the connection]
nameandfigure has joined #dri-devel
nameandfigure has quit [Remote host closed the connection]
<zmike>
TIL gallium-i915 is not built with -Dgallium-drivers=all
guludo has quit [Quit: WeeChat 4.5.2]
guludo has joined #dri-devel
freebonusrun has joined #dri-devel
fomys_ has joined #dri-devel
freebonusrun has quit [Remote host closed the connection]
nothingisrealnow has joined #dri-devel
gouchi has quit [Quit: Quitte]
unerlige has left #dri-devel [#dri-devel]
unerlige has joined #dri-devel
unerlige has left #dri-devel [#dri-devel]
unerlige has joined #dri-devel
coldfeet has quit [Quit: Lost terminal]
epoch101 has joined #dri-devel
<alyssa>
zmike: it doesn't build on arm :(
<alyssa>
and well i (runs arm) added it for the convenience of our release manager (also runs arm)
unerlige has quit []
<zmike>
🤔
<zmike>
but that's not what "all" means
<HdkR>
Maybe all needs an additional pass afterwards to remove drivers from the list if they're known broken :D
<zmike>
or maybe it should just be fixed to build ?
<HdkR>
"Oops, you're on AArch64, I'm just gonna remove i915"
<zmike>
how hard could it be
<HdkR>
:thonk:
unerlige has joined #dri-devel
<HdkR>
zmike: You're right
<HdkR>
If I remove the meson check, it just builds
<HdkR>
Four line change deleting the check
<HdkR>
`Build-test everything except for i915, which depends on libdrm-intel which is not available on non-Intel distros.`
<HdkR>
Probably the comment that matters more
<HdkR>
But really if libdrm-intel isn't shipping on other architectures, that's a new problem and distros should fix their packages.
<HdkR>
crocus and iris don't depend on libdrm-intel?
<jannau>
I have libdrm_intel.so.1.124.0 on aarch64 f41
<HdkR>
Looks like it's just a debian/ubuntu problem from what I can see
<HdkR>
Actually, Debian bookworm problem. Trixie and Sid has intel as well
<anarsoul>
alyssa: why it doesn't build on arm though?
<HdkR>
bookworm-backports has it even actually
<HdkR>
anarsoul: That's what I just found. It does build once the architecture check is removed from the meson file :)
<anarsoul>
I mean I can build lima on x86 (and I do so, I use it with drm-shim for debugging compiler issues), so I don't see why e.g. alyssa couldn't use i915 with drm-shim on her arm machine :)
<eric_engestrom>
anarsoul: I think it's just that the gitlab api is so slow right now that marge's internal queries time out; I would just re-assign to marge and let it try again
<anarsoul>
let me try
<eric_engestrom>
oh, I see that it didn't unassign itself, so it's still assigned, but marge it not doing anything with it
<eric_engestrom>
I have the ability to restart marge (but that's the only thing I can do, I can't look at its logs); doing that now
<anarsoul>
I unassigned and assigned it back
<eric_engestrom>
done
<eric_engestrom>
ak
<eric_engestrom>
*ack
<K900>
dcbaker going to sleep now but I built all my systems with the latest iteration of the patch and it seems good
jeeeun841351908155 has quit []
jeeeun841351908155 has joined #dri-devel
<sima>
jfalempe, yeah the requirement to have the primary buffer vmap is the thing I'm not super sure about, since it also means display buffers must be visible to the cpu to begin with
<sima>
which isn't always the case
nerdopolis has joined #dri-devel
<sima>
so maybe we need another indirection for a write_byte function, which then looks at the right address to write to, even if the buffer isn't contiguously mapped
<sima>
or if all you have are peek/poke registers to get at invisible vram