<imirkin>
you also need some super-fresh wayland-protocols. or just revert a bunch of changes and move on your merry way.
<karolherbst>
alyssa: or just reset your tree to "a25d4dd27615^"
<alyssa>
I have never had to patch Mesa just to compile the thing
<alyssa>
Why is this different?
<karolherbst>
alyssa: because sometimes we require updated deps
<imirkin>
alyssa: feel free to read my complaints and the responses explaining why this is different
<alyssa>
Why is this MR so special that it justifies breaking the very normal use case of build Mesa with distro packages?
<imirkin>
(it's not.)
Bennett has quit [Read error: Connection reset by peer]
<karolherbst>
imirkin: ehh.. so we just added a tiny wrapper to libdrm?
<imirkin>
apparently if you're building mesa, you're also signing up for building untold quantities of other packages from source, and then remembering to switch back to the distro versions later.
<alyssa>
just read the responses
<alyssa>
I... still don't see how this is different?
<imirkin>
it's not. that was my point
<imirkin>
(i only complained after it landed, of course, since that's when i noticed it broke things)
<karolherbst>
honestly.. distros should just update their packages...
<alyssa>
I had no idea anything broke until I just tried to rebase
<imirkin>
yep.
<karolherbst>
it's not the first time this happens
<imirkin>
normally for mesa-wide things, we wait a lot longer.
<karolherbst>
ehh..
<karolherbst>
I ran into this issue probably a dozen times already
<karolherbst>
I just rebase on the commit before adding the updated dep
<karolherbst>
and move on
<imirkin>
i never have to the extent that there was no distro package.
<imirkin>
except maybe one time, and iirc that change was reverted.
<imirkin>
but this was ages ago, and my memory is hazy
<alyssa>
and suppose I build libdrm from source, and also every user who complains their panfrost build broke...?
<imirkin>
alyssa: the (imo bogus) argument is that if you can build mesa, you can build every package on your system
<alyssa>
there is a reason I do not use Gentoo even though in principle I could..
<karolherbst>
waiting for distros is not the solution though
<imirkin>
i use gentoo and it was annoying for me too :)
<alyssa>
karolherbst: isn't it..?
<karolherbst>
honestly... I side with Eric here, if you build _anything_ from source and the latest dev tree, then you might also have to use deps from source trees as well
<imirkin>
karolherbst: pretty reasonable for the commonly-used-by-developers distros to pick it up.
<imirkin>
i'm not suggesting waiting until it shows up in debian-stable...
<karolherbst>
if you are an developer you can also handle git and just rebase on an older commit
<karolherbst>
and skip the 4 days of work
<imirkin>
karolherbst: so you want everyone to have to waste time on this?
<imirkin>
how about just waiting a bit before pushing your changes
<karolherbst>
packaging sucks, the packaging situation sucks, everything related sucks, why should developer even suffer from that when distributions are just painfully slow
<airlied>
wierdly this has happened 4-5 times in the past few years
<karolherbst>
yeah
<karolherbst>
I hit this so often
<airlied>
not sure why everyone noticed it all of a sudden
<imirkin>
airlied: probably depends on your base distro how often you notice?
<imirkin>
this was one time that hit almost everyone
<karolherbst>
airlied just pushes an updated libdrm :D
<airlied>
imirkin: I'm usually the first to notice
<alyssa>
^ and also caught me (and presumably almost everyone?) off guard
<airlied>
which is why I know it's happened 4-5 times in the past few years
<karolherbst>
alyssa: the point is.. this happens so often...
<imirkin>
yeah ... i mean you guys are pretty good at operating rpm and have access to your distro's package distribution mechanisms
<imirkin>
this isn't the case for most people on either front
<karolherbst>
normally it's kind of restricted to drivers
<karolherbst>
just check how often radeonsi bumps the libdrm req
<alyssa>
the MR in question is just labelled as egl/wayland, neither of which is related to what I work on so not an MR I would read
<alyssa>
I am not radeonsi
<imirkin>
i think radeonsi does do this fairly often
<imirkin>
but i don't build it
<alyssa>
^^
<karolherbst>
yeah, then nobody notices
<karolherbst>
it or doesn't complain or something
<karolherbst>
I don't know
<imirkin>
perhaps the 4-5 times you're referring to were for radeonsi?
<airlied>
does not building the wayland platform help?
<karolherbst>
airlied: nope, this is a global req in mesa
<karolherbst>
for everything
<karolherbst>
I think it is reasonable to wait a few days to be nice here
<karolherbst>
but you can't just wait for distros to update
<karolherbst>
because some are just huge slowpokes
<alyssa>
There are good reasons to be slow.
<imirkin>
airlied: it just bumps the global drm ver
<karolherbst>
alyssa: not really
<imirkin>
karolherbst: you _can_ just wait
<karolherbst>
just means more work for upstream
<imirkin>
if your change requires this
<imirkin>
then you need to plan around it
<karolherbst>
it's not a tagged version of mesa...
<imirkin>
so what
<imirkin>
you can't be having everything in limbo.
<karolherbst>
I kind of expect from devs that keeping a local prefix with all kinds of random shit isn't the most complicated thing to do honestly. Sure using the distro provided package is easier, but sometimes you have to deal with this kind of stuff
<alyssa>
Why is libdrm separate from Mesa anyway?
<karolherbst>
be it mesa or some other library
<karolherbst>
alyssa: good question
<imirkin>
alyssa: it's used by things other than mesa.
<karolherbst>
I think DDX are using it?
<karolherbst>
mainly
<FLHerne>
Why aren't DDXs mesa? :p
<alyssa>
imirkin: that doesn't prevent libdrm from living in-tree
<karolherbst>
probably modesetting as well?
<imirkin>
yes. i'd also bet that intel-vaapi-driver uses libdrm_intel. not 100% sure.
<alyssa>
FLHerne: Also that ;-p
<karolherbst>
imirkin: ahh.. probably
<imirkin>
alyssa: a bunch of drivers have gotten rid of their libdrm deps, yea
<daniels>
libdrm is a single package which requires no arguments apart from common ones (prefix, cross-file if you use that), has no upstream dependency, and builds in literally seconds. it’s not like you’re being made to rebuild glibc and LibreOffice every week …
<karolherbst>
I think go and rust just went with the package manager being part of the tooling thing just so they don't have those stupid discussions around outdated deps and stuff :D
<imirkin>
right. so that's the "just stop whining" argument. but looks like i'm not the _only_ person running into this, wasting time on it
<daniels>
everything which wants to discover DRM devices and use ioctls or KMS uses libdrm. so having your compositor depend on Mesa even when it only uses pixman seems a bit perverse
<daniels>
imirkin: the glib answer is that these conversations have taken literally hundreds of times longer than building libdrm
<alyssa>
daniels: right, that's fair enough
* alyssa
build libdrm in between daniels' messages, proving his point
<alyssa>
built
<imirkin>
daniels: this is definitely a departure from the way we've done it in the past. radeonsi, sure, they update stuff same-day all the time. but the core stuff has always been done with some care.
<karolherbst>
managing your local prefix is probably the more annoying step if you are not already running mesa from your custom prefix (and knowing what env vars to set for meson/ninja to pick it up etc..)
<alyssa>
built
<daniels>
imirkin: the longer answer is that version ifdefs in the tree are not the done thing, so it wasn’t obvious that compiling one package would be a showstopper issue for people who compile packages all the time :\
<imirkin>
daniels: i could say the same that i should just push a revert and then we can avoid the discussion. goes both ways.
<karolherbst>
imirkin: so "how long" should we wait in the future?
<alyssa>
oh and wayland-protocols too apparently, uh
<imirkin>
daniels: ok. so just wait.
<daniels>
I guess we could revert and wait until after Christmas, but then it’s probably going to slip a release
<karolherbst>
imirkin: waiting on distributions to do something isn't the solution though
<daniels>
imirkin: core stuff hasn’t been done with care and making sure everyone has it. it just hasn’t been done often.
<imirkin>
daniels: i've been involved with the mesa project for 8 years now. i remember one instance of a time when i ran into this.
<karolherbst>
I agree that we should wait _a_little_ but I wouldn't wait more than a week or two
co1umbarius has joined #dri-devel
<alyssa>
a week is not a long time at distro scale
<karolherbst>
alyssa: they could automate this stuff...
<imirkin>
[one previous instance, that is]
<karolherbst>
let's face it.. they just bump the version, push it and are done
<daniels>
imirkin: yes, but that’s not because core device-handling code changes every week and it gets handled so seamlessly that you don’t see it unlike this cowboy nonsense. it’s because it doesn’t happen
<karolherbst>
they don't do more
<imirkin>
daniels: yeah, this stuff changes rarely. so some care has to be taken when it does.
<karolherbst>
at least not for libs like libdrm
<imirkin>
anyways, esp since someone in this group has or knows who has access to push updates to the various "rawhide" repos
columbarius has quit [Ping timeout: 480 seconds]
<imirkin>
it should be pretty easy to just coordinate that
<imirkin>
(or at least, achievable, if not easy)
<karolherbst>
anyway.. we can agree on "two weeks" or something and just CI on waiting :P
<airlied>
it's been 2.5 years since we last bumped it at all
<daniels>
imirkin: I understand that you’re frustrated about a compiler error and this is a continued outpouring of that. I don’t understand how your demand that you avoid a 30sec compilation of a deeply related and intertwined library is a proportionate response.
<airlied>
for the core req, and even then it was just timing that allowed to be unnoticed
<karolherbst>
yeah.. I think I hit the intel bump most often actually...
<idr>
daniels: It's not just libdrm.
<imirkin>
daniels: the outcome i'm going for is reverting these changes + waiting an appropriate amount of time for the dep to propagate in "the system"
ngcortes has quit [Remote host closed the connection]
<idr>
wayland-protocols also needs to be updated.
* alyssa
is no longer going for an outcome now that she's spent the 30sec and vented about it and is back to writing code
<daniels>
(rawhide is not usable day-to-day btw - it needs to flow to updates after some time in the updates-testing purgatory first)
<karolherbst>
alyssa: good for you! :D
<karolherbst>
coding is more fun than bikeshedding anyway
<daniels>
imirkin: so, a solution?
<karolherbst>
at least for some
<daniels>
idr: ?
<imirkin>
daniels: i assumed you could pick some packages from rawhide. i don't actually use redhat/fedora... so don't know what the appropriate solution is there.
<imirkin>
i thought you could have multiple repos "installed" so to speak, in yum or whatever. but i'm weak on the details.
mbrost has joined #dri-devel
<daniels>
idr: oh, w-p. that’s a bunch of XML files so goes way quicker than libdrm. last time we added ifdefs we were told not to, so we don’t.
<daniels>
imirkin: rawhide frequently involves new and exciting toolchain upgrades compared to release branches
<imirkin>
daniels: the solution is to either make it work with older versions (what _appears_ to be a very small amount of ifdeffery, but i didn't dig super-deep), or to wait until developers have easy access to the packages in question, based on a sampling of distros / methods of installing stuff.
<daniels>
it literally takes 30 seconds
<daniels>
that’s pretty easy
<alyssa>
sending a mesa-dev mail a few days before merging with the command to paste in to clone+build+install the relevant packages would've been nice and it's not /strictly/ too late for that!
<imirkin>
if those packages aren't available in the distros, how do you expect the next release of mesa to be installed
<alyssa>
(well, it's too late for before merging, but)
<airlied>
yeah no need for rawhide, it's all in updates-testing, and likely updates in a few days
<idr>
It's more than that because first you have to waste a bunch of time figuring out WTF the problem is.
<karolherbst>
imirkin: until then distros will notice the broken build and update deps
<daniels>
alyssa: yeah, that’s a good point - almost forgot the list existed
<alyssa>
idr: ^^ yeah. it's not the 30s, it's the "first I came on IRC wondering why Mesa won't build"
<alyssa>
daniels: It's nice and low traffic now that we've all forgotten :'D
<imirkin>
airlied: yeah, when i said "rawhide", that could have been the wrong thing. i'll try to remember "updates" and "updates-testing" in the future.
<karolherbst>
idr: meson complained about outdated libdrm?
<daniels>
idr: uh, is the meson error message about the dep version being insufficient not enough?
<karolherbst>
ohhh wait
<karolherbst>
not if you don't force a reconfigure....
<karolherbst>
mhhhhh
<idr>
I find the attitude of "I don't care about wasting other developer's time" to be, frankly, quite offensive.
<karolherbst>
mhhhhh
<karolherbst>
okay
<karolherbst>
I think this is a meson bug in the end
<karolherbst>
(not telling that a dep is too old)
* alyssa
is going to close IRC because she has actual work to get done
<karolherbst>
meson/ninja _should_ pick that stuff up
<alyssa>
🚲
<daniels>
idr: I don’t think 30 seconds is a waste in all honesty. but I am trying to understand how the output was not sufficient
<karolherbst>
although this happens with cmake all the time
<karolherbst>
or autotools
<imirkin>
karolherbst: i dunno, i saw the error about libdrm pretty clearly.
<idr>
...especially when what's being asked is "wait a trivial amount of time until new releases hit the distros."
<karolherbst>
imirkin: yeah.. but what if your build tree doens't need reconfiguring
<karolherbst>
although...
<karolherbst>
you updated the tree...
<daniels>
karolherbst: ? touching meson.build makes you reconfigure
<karolherbst>
ehhh...
<imirkin>
karolherbst: if you rebased it, meson.build will have updated, which i think yeah, reconfigures
<karolherbst>
daniels: yeah... I..... was thiking about crazy scenarios not happening
<imirkin>
i totally didn't know about the wayland-protocols thing until i read the change
<karolherbst>
okay, but then I don't understand the "wtf happened" argument
<imirkin>
but my solution was "just revert" so it didn't end up mattering
<imirkin>
daniels: you have to install things in such a way that meson will pick up the new version
<imirkin>
not everyone has that dexterity
<imirkin>
to either know how to convince meson to do something like that
<daniels>
yeah, in such a way that your prefix is contained within PKG_CONFIG_PATH
<imirkin>
or how to install it into the right palce without stomping all over
<idr>
And then uninstall when the distro dose catch up.
<idr>
*does
<daniels>
as pkg-config is how we discover ~all of your deps
<imirkin>
... all over your distro thing, that is.
<karolherbst>
idr: remove your prefix?
<karolherbst>
imirkin: just use a prefix?
<daniels>
karolherbst: that’s actually surprisingly non-ergonomic if you don’t know about —clearcache
<karolherbst>
I am not installing mesa system wide
<imirkin>
karolherbst: meson won't pick stuff up there
<karolherbst>
I am not crazy
<karolherbst>
imirkin: it does
<imirkin>
you have to tell it somehow
<imirkin>
iirc it drops env vars too
<karolherbst>
I have a shell script doing this stuff
<imirkin>
at random intervals
<karolherbst>
I don't invoke ninja/meson directly
<imirkin>
or perhaps that's been fixed along the way
<daniels>
imirkin: $PKG_CONFIG_PATH, same as autoconf
ybogdano has quit [Ping timeout: 480 seconds]
<daniels>
it listens to the environment you give it at the time you execute it
<imirkin>
daniels: i'm of the autoconf generation that liked the --with-foo-dir args :)
<daniels>
(same as autoconf)
<karolherbst>
(I even use it for cross compiling inside containers and shit)
<daniels>
imirkin: that never worked for a lot of our dependencies, including wayland-protocols
<Ristovski>
fwiw, there are also insane people like me who run their whole graphics stack on gentoos -9999 packages (git) :^)
<karolherbst>
(hence the env vars)
<imirkin>
daniels: i know
<imirkin>
daniels: mesa's autoconf usage was largely pkg-config-dependent
<imirkin>
i would have been annoyed by this irrespective of autoconf or meson though ... for pretty much that same reason
<imirkin>
if autoconf were set up in a way that didn't require pkg-config, then everything would have been golden, but that was never the case, as you pointed out
<imirkin>
(but many packages using autoconf _did_ work that way. it was nice.)
<karolherbst>
dcbaker: maybe we should make meson to look for deps inside the prefix in a magic way or soemthing?
<daniels>
making pkg-config not be a thing requires going back to 2004 and convincing a lot of people that the problems which caused pkg-config to exist are not real and everything is fine the way it is
<imirkin>
nah, i don't think that's a good solution. if it's using pkg-config, it should be consistent.
<imirkin>
daniels: not suggesting that in the slightest
<daniels>
it is consistent … it looks exactly where you tell it to
<karolherbst>
imirkin: meson could just set PKG_CONFIG_PATH if it's not set is what I meant
<imirkin>
daniels: also it's not muturally-exclusive -- you could have a system which allows easy per-package overrides while still using pkg-config for most things
<imirkin>
karolherbst: there was a time when meson would drop PKG_CONFIG_PATH. is that still the case?
<imirkin>
(like on a reconfigure or whatever)
<daniels>
imirkin: .pc files are like 6 lines usually
<karolherbst>
imirkin: there is -Dpkg_config_path now
<imirkin>
karolherbst: so i'll take that as a yes then? i.e. it does drop PKG_CONFIG_PATH env var, and you have to know about the other thing if you want it to work well?
<karolherbst>
I have no idea, I just use -Dpkg_config_path and never had a problem since then
<imirkin>
daniels: the problem isn't the .pc file's existence.
<daniels>
imirkin: it never ‘drops’ it. when configure runs, it takes it from the environment. so if your environment changes, so does the result. this is _exactly_ what autoconf did.
<imirkin>
daniels: iirc you could do like "./configure PKG_CONFIG_PATH=foo" which would then save it
<karolherbst>
daniels: how was configure invoked during the build?
<imirkin>
vs "PKG_CONFIG_PATH=foo ./configure" which would, yes, drop it
<karolherbst>
imirkin: ahh...
<daniels>
yes, and here it’s spelled meson configure -Dpkg_config_path=foo …
<imirkin>
yep
<daniels>
which persists it
<karolherbst>
I'd just derive it from -Dprefix....
<daniels>
in the same way that autoconf did
<karolherbst>
honestly
<imirkin>
so probably all this stuff isn't that hard, but most people just don't know it.
<imirkin>
or at least _i_ don't know it
<imirkin>
and i sort of assume i'm at least average at this stuff. perhaps vanity?
<karolherbst>
I liked that cmake had this automagic behaviour or at least I think it did
<imirkin>
karolherbst: where no matter what you did, it never worked? magic! :)
<karolherbst>
imirkin: maybe we should add a template build.sh file which has all the magic bits set and compiles to ~/local-mesa/
<karolherbst>
imirkin: could be :D
<Ristovski>
imirkin: btw can I ask about your custom profile setup on gentoo? I assume you somehow override the install dir to something like /opt/blah which then allows you to LD_LIBRARY_PATH or something when running stuff with the new mesa? Or did you go to the length of having `eselect mesa` :P just curious
<imirkin>
Ristovski: i use the crosstool thing
<Ristovski>
oh, I see
<imirkin>
Ristovski: oh, you mean for regular thing?
<imirkin>
i just set the prefix to like ~/install
<imirkin>
or whatever
<imirkin>
and then do ninja install, and then LD_LIBRARY_PATH=~/install/lib64
<imirkin>
[that doesn't literally work, iirc it wants a full path there]
<imirkin>
for my cross-compile envs i use gentoo's crosstool to create a separate gentoo ebuild-made environment
<imirkin>
i.e. using armv7a-hardfloat-linux-gnueabi-emerge instead of emerge
<karolherbst>
I honestly think that we might want to add one or two pages of documentation for this stuff
<imirkin>
which builds/installs into a "chroot" of sorts, which is then the nfsroot for some poor little device
<karolherbst>
the vulkan/cl loader sutff is already annoying, and then your local mesa sometimes picking up the system drivers for whatever dumb reasons or so
<karolherbst>
daniels: I meant using your built mesa, but yeah, this as well
mbrost has quit [Read error: Connection reset by peer]
<Ristovski>
imirkin: btw, in case you don't know about it: you can use `quickpkg mesa` for example, which generates a binary package than you can later easily install with `emerge -av -K mesa` (-K being short for --usepkgonly, which selects only binary packages). I use it when upgrading "critical" stuff so I can quickly revert to the old version and save myself a compile.
<karolherbst>
daniels: also.. it needs updating
<karolherbst>
-Dpkg_config_path is the cool new thing now
<imirkin>
Ristovski: what is "quickpkg"?
<karolherbst>
imirkin: it creates a binary package from the already built files
<imirkin>
Ristovski: i know about the binary packages ... used them once, decided it was a huge mistake
<imirkin>
i guess for the downgrade case it's fine
<Ristovski>
yeah, the only real use I can think of
<imirkin>
i just keep the source pakcages around. i guess i could still get into trouble though
<imirkin>
well, theo ther use-case is if you have a bunch of identical machines
<karolherbst>
Ristovski: or if you have like 100 machines you want to redeploy stuff to :D
<imirkin>
but at that point, the thing you want is "not gentoo" :)
<daniels>
idr: I need to put my phone down and go to sleep but I do actually want to hear about the confusion part, because I haven’t seen a failure mode which doesn’t result in you being told that a dep is outdated and exactly which version is required - if that’s happening it’s obviously something to be fixed
<Ristovski>
btw, lets say I have a bunch of free time to 'waste', is there a list of resources/docs or is docs.mesa3d.org and the source code all I get (hopefully not :( )
* Ristovski
eagerly waits for the magical tldr_mesa_internals.md
<ishitatsuyuki>
what happens when a buffer is read after being evicted? does it get moved to VRAM or are the requests served from system RAM?
bnieuwenhuizen has quit [Quit: Bye]
bnieuwenhuizen has joined #dri-devel
boistordu_ex has joined #dri-devel
boistordu has quit [Ping timeout: 480 seconds]
Company has quit [Ping timeout: 480 seconds]
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
thellstrom1 has joined #dri-devel
thellstrom has quit [Read error: Connection reset by peer]
mbrost has quit [Remote host closed the connection]
mattrope has quit [Remote host closed the connection]
jhli has joined #dri-devel
jhli has quit []
jhli has joined #dri-devel
lemonzest has joined #dri-devel
mclasen has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
thellstrom has joined #dri-devel
thellstrom1 has quit [Ping timeout: 480 seconds]
fxkamd has joined #dri-devel
tjaalton has joined #dri-devel
jhli has left #dri-devel [#dri-devel]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
jhli has joined #dri-devel
jhli_ has joined #dri-devel
jhli_ has quit []
jewins has quit [Remote host closed the connection]
jewins has joined #dri-devel
jhli_ has joined #dri-devel
jhli_ has quit []
danvet has joined #dri-devel
tzimmermann has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
mszyprow_ has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
itoral has joined #dri-devel
sdutt has quit [Remote host closed the connection]
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
mlankhorst has joined #dri-devel
Danct12 has quit [Quit: Quitting]
tjaalton has quit []
tjaalton has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
cphealy_ has joined #dri-devel
<Lynne>
I think I need a second opinion on how vkGetImageSubresourceLayout is meant to work from someone who works on anv
cphealy has quit [Ping timeout: 480 seconds]
<Lynne>
basically, Intel have sent a patch to introduce an offset to the base vulkan frame structure in ffmpeg, which indicates where the vkimage data starts in a scenario where you have per-plane vkimages bound to a single vkdevicememory
<Lynne>
but I don't think this is necessary, as with vkGetImageSubresourceLayout you should be able to get that offset for a DRM tiled image (we only care about the offset for DRM tiled images)
<Lynne>
the specs say that for DRM tiled images, the offset that vkGetImageSubresourceLayout returns is described as driver-specific
<Lynne>
however, on anv, it currently returns an offset that's based off of the base vkimage, rather than the memory backing it, so in practice, it always returns 0 for all vkimages, regardless of their vkdevicememory offset when binding
<Lynne>
so my question is, should anv return the bound offset for DRM tiled images, since the spec permits that, or is what it's currently outputting correct (it makes sense for mipmapped DRM-tiled images, but that's incredibly rare to say the least)
<emersion>
hm, is there a way to get the offset of the VkImage in the VkMemory?
Danct12 has joined #dri-devel
<Lynne>
nope, it's either this, or you do it externally
<emersion>
if not, there would be no way to get the real DMA-BUF planes offset?
<Lynne>
correct, that's exactly what Intel are interested in, exporting vulkan frames to drm frames
<emersion>
cc chadv jekstrand
<emersion>
i think anv is wrong here
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #dri-devel
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #dri-devel
egbert has joined #dri-devel
jkrzyszt has joined #dri-devel
egbert is now known as Guest7210
egbert has joined #dri-devel
jhli has quit [Remote host closed the connection]
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
egbert has quit [Quit: leaving]
egbert has joined #dri-devel
egbert has quit []
tursulin has joined #dri-devel
JohnnyonFlame has joined #dri-devel
Guest7210 has quit []
egbert has joined #dri-devel
rgallaispou has joined #dri-devel
egbert has quit []
<pq>
imirkin, alyssa, *before* that MR, I could not build Mesa on Debian Bullseye without manually building a new libdrm, so.
<MrCooper>
ishitatsuyuki: if you mean read by the GPU, it depends whether the buffer was allocated for only the VRAM domain or VRAM+GTT
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
<ishitatsuyuki>
MrCooper: so a DEVICE_LOCAL buffer would get sent back to the VRAM?
<MrCooper>
probably
<ishitatsuyuki>
I see
<MrCooper>
though amdgpu has some throttling for moving buffers back to VRAM, so it may stay in GTT for some time at least
pnowack has joined #dri-devel
pcercuei has joined #dri-devel
egbert has joined #dri-devel
vivijim has joined #dri-devel
gawin has joined #dri-devel
pjakobsson has joined #dri-devel
rasterman has joined #dri-devel
<bnieuwenhuizen>
emersion: what is wrong about it?
<emersion>
bnieuwenhuizen: sorry, i think i'm missing context
<bnieuwenhuizen>
The vulkan image offset
<emersion>
bnieuwenhuizen: anv returns the offset relative to the start of the VkImage instead of the start of the VkMemory it seems
<emersion>
when you do vkGetImageSubresourceLayout
<bnieuwenhuizen>
That is what I would expect intuitively
<emersion>
so you can't use that offset to export a Vulkan VkImage, and then import it into another API
<emersion>
the DMA-BUF FD will refer to the VkMemory
<bnieuwenhuizen>
App has to remember where it bound the image
<emersion>
hmm
<emersion>
can it do that even when it used Vulkan to allocate?
<bnieuwenhuizen>
if you use vulkan to allocate the app binds the image to the memory with an offset, no? Just remember that offset as the base for the subresource offsets
<emersion>
hm i guess so
<emersion>
Lynne: since you always manually call vkBindImageMemory, you should always have acces to the VkImage offset?
<emersion>
bnieuwenhuizen: yea that makes sense, i forgot about this
<Lynne>
the keyword here is DRM tiling
<emersion>
hm, what do you mean?
<Lynne>
of course we have access to the offset we used ourselves
<Lynne>
but the idea here is to keep the public api small, and not expose everything
<emersion>
with DRM, offset and stride are well-defined, even for tiled
<Lynne>
nope
<emersion>
*with DRM* ;)
<emersion>
the kernel has a doc comment explaining it
<bnieuwenhuizen>
note that the offset from the subresourcelayout is defined as "offset is the byte offset from the start of the image or the plane where the image subresource begins." and for DRM specifically "If the image is non-disjoint, then the offset is relative to the base address of the image. "
<Lynne>
I'm talking about the vulkan function to retrive the drm offset, not the kernel's idea, or anything to do with drm
<Lynne>
bnieuwenhuizen: it also mentions that the fields are driver-speicifc
<Lynne>
*specific
<bnieuwenhuizen>
Lynne: "If the image is non-linear, then rowPitch, arrayPitch, and depthPitch have an implementation-dependent meaning.", not offset?
<emersion>
i don't really understand
<Lynne>
"then the returned layout has an implementation-dependent meaning"
<emersion>
but anv returning offset=0 for all planes seems wrong
<emersion>
assuming it's not a disjoint image
<bnieuwenhuizen>
but in vulkan drm offset relative to bo should be image bind offset + plane subresource offset
<Lynne>
right there in the documentation for vkGetImageSubresourceLayout
<Lynne>
should be, but the function always returns 0 for the offset
<Lynne>
haasn has also ran into this, I believe
<bnieuwenhuizen>
yeah if it is not disjoint the 2nd/3rd plane should have a non-zero offset I think, it should be to the base of the image
<emersion>
yea
<Lynne>
yup, none of the images are disjoint
<emersion>
maybe wait for the intel devs i pinged above to chime in then
<Lynne>
it also happens on AMD, I think
<bnieuwenhuizen>
on AMD we absolutely don't return zero for 2nd/3rd plane
<Lynne>
guess it's only intel, which is sadly the only vendor that requires all planes to be part of a single allocation
<bnieuwenhuizen>
we require that for AMD vulkan as well
<Lynne>
due to a very limited plane pointer offset of <some bits>
<Lynne>
in the context of video, e.g. NV12, no, AMD's quite happy to have both planes in separate memory
<bnieuwenhuizen>
for vaapi maybe but for vulkan not
<Lynne>
yup, this is for VAAPI
Company has joined #dri-devel
<airlied>
intel vaapi doesnt have a byte offset at all
<airlied>
its in units of pitch of the luma surface
<Lynne>
yes, that's why it generally wants all images in e.g. nv12 to be allocated in a single region, it's got a limited range and alignment requirements
<Lynne>
but for the sake of exporting to drm, it could represent that in bytes and put it in the subresource layout field
JoseExposito has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
JoseExposito has quit [Quit: JoseExposito]
JoseExposito has joined #dri-devel
flacks has quit [Quit: Quitter]
flacks has joined #dri-devel
JoseExposito has quit [Quit: JoseExposito]
JoseExposito has joined #dri-devel
JoseExposito has quit [Quit: JoseExposito]
mclasen has joined #dri-devel
JoseExposito has joined #dri-devel
camus1 has joined #dri-devel
JoseExposito has quit [Quit: JoseExposito]
camus has quit [Ping timeout: 480 seconds]
JoseExposito has joined #dri-devel
<daniels>
airlied: you need a byte offset for MC CCS
itoral has quit [Remote host closed the connection]
<haasn>
how does mesa in practice verify that the contents of ~/.cache/mesa_shader_cache/ contain legal values? would it be possible to trigger UB in mesa by constructing malicious shader cache entries?
<haasn>
context: I'm faced with a similar problem, wanting to cache the results of translating GLSL to SPIR-V (or HLSL), and not wanting malicious users to trigger UB by placing corrupt/illegal SPIR-V into my shader cache dir
<imirkin>
haasn: completely possible, yea
<haasn>
I see
<haasn>
awkward
<haasn>
but I guess that means you should always cache somewhere in $HOME and not e.g. /tmp
<imirkin>
or maybe not UB
<imirkin>
but at least bogus shaders
<imirkin>
i do think the contents are slightly validated when read in
<haasn>
hm
<imirkin>
without some signing mechanism, hard to validate the shaders...
<haasn>
I just blindly pass the spir-v object I load into vkCreateShaderModule
<haasn>
according to vulkan spec that is trivially undefined behavior if the spir-v module is not legal
<haasn>
yeah I suppose this is an intractable problem
<haasn>
and in practice it amounts to making sure users understand that the shader cache contents have to be trusted
<imirkin>
i can't remember if there's a crc on it, to validate against garden-variety corruption
<daniels>
I was going to ask if it uses a JWT, but yeah, it just leaks it straight into the log ffs
<robclark>
oh, heh, that's maybe not good
<daniels>
maybe ... !
macromorgan is now known as Guest7228
macromorgan has joined #dri-devel
Guest7228 has quit [Read error: Connection reset by peer]
Haaninjo has joined #dri-devel
<jekstrand>
Lynne: vkGetImageSubresourceLayout() should return things relative to the start of the image because it can be called before the image is bound to memory.
<jekstrand>
Lynne: If the spec is unclear there, we should clerify it
soreau has quit [Read error: Connection reset by peer]
soreau has joined #dri-devel
<Lynne>
no, the spec's clear, this is an implementation problem, IMO
<jekstrand>
What are you seeing as the problem, then?
<Lynne>
that for a DRM-tiled image, anv always returns 0 for the image offset rather than the memory offset for where it was bound to
cphealy has joined #dri-devel
<zackr>
emersion: could we remove stdbool from xf86drmMode.h in libdrm? it was added in e641e2a632d779f638ac2ba983b9fceb20b3fac4 and i don't see any hard requirement for it. this seems to happen every few years (including stdbool.h in drm headers) and the issue is that x has a bunch of headers that use bool as a variable name, e.g. xf86Opt.h which means that anything that through some dependency includes the drm headers before an xorg header stops compiling
<jekstrand>
Lynne: The spec very specifically says "
<jekstrand>
offset is the byte offset from the start of the image or the plane where the image subresource begins.
<jekstrand>
"
<jekstrand>
Note "from the start of the image"
<jekstrand>
If it's got 1 plane, you should expect the offset from the start of the image to always be 0
<Lynne>
the spec also very specifically says that for drm-tiled images, the layout is implementation-defined
<Lynne>
radv returns non-zero offset according to bnieuwenhuizen
<Lynne>
and I'd also expect it to return a non-zero offset if the memory bound to the image was bound with a non-zero offset
<jekstrand>
It's ok if they return a non-zero offset but it should still be relative to the start of the image or memory plane (for disjoint)
<jekstrand>
No, the offset relative to the start of the memory object is the bound offset + the offset returned from vkGetImageSubresourceLayout()
* jekstrand
reads RADV code
<Lynne>
by the way, nothing here is about planar vulkan images, or disjoint vulkan images, just regular images
<Lynne>
this is what the problem with vkGetImageSubresourceLayout is according to intel
<emersion>
so, i don't think there's a better way than fixing xserver
<Lynne>
and I kind of think intel ought to communicate better internally about how this should work
<jekstrand>
Lynne: Ideally, yes. :)
<jekstrand>
tl;dr, Wenbin is wrong on this one. I'm not sure where he got that from.
Duke`` has joined #dri-devel
<bnieuwenhuizen>
jekstrand: my non-zero for RADV was for plane 2/3/4 in a non-disjoint image, which is still relative to the start of the image.
<bnieuwenhuizen>
maybe I added confusion when thinking multiplanar when talking vaapi
<jekstrand>
Lynne: I'm sending Wenbin an e-mail. I'd send it to the FFMpeg list but I'm not subscribed there.
<emersion>
you can send to lists without being subscribed
<jekstrand>
emersion: Yeah, but doing a reply without the e-mail in your inbox is a pain
<jekstrand>
Hopefully, one quick internal e-mail will sort out the confusion.
<jekstrand>
If not, I'll get on the list.
<zackr>
emersion: ah, missed that bool. yes, fixing xorg should definitely be on the list, but it's likely going to take longer for the new xorg headers to get into distros than libdrm . fwiw, the single bool in xf86drmMode.h is a little off. everything in the interface returns an int/errno or a pointer, even drmIsKMS returns an int, so it's a little weird that the only thing returning a bool is drmModeFormatModifierBlobIterNext . anyway, i understand if
<zackr>
the ship has sailed on that interface
<zackr>
i can take a look at sed'ing the xorg headers for s/bool/bVal/ or such
jewins has joined #dri-devel
<emersion>
zackr: returning a bool better indicates the intent (true for success and false for failure)
<Lynne>
jekstrand: thanks!
<Lynne>
message id is "<BY5PR11MB3879AEF7FDB79DE53BD32831F8679@BY5PR11MB3879.namprd11.prod.outlook.com>" if you'd like to respond to the ML
<Lynne>
you don't need to be subscribed
<Lynne>
but no one else apart from me and Wenbin care, so don't worry about it
tzimmermann has quit [Quit: Leaving]
<emersion>
i do care :<
<emersion>
but yeah nbd as long as it gets fixed
<pcercuei>
You can use _Bool :)
<emersion>
;_;
mbrost has joined #dri-devel
Duke`` has quit []
Duke`` has joined #dri-devel
gpuman has quit [Remote host closed the connection]
camus1 has quit [Remote host closed the connection]
rgallaispou has quit [Read error: Connection reset by peer]
gouchi has joined #dri-devel
camus1 has joined #dri-devel
jhli has joined #dri-devel
vivijim has quit [Quit: Lost terminal]
vivijim has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
<macromorgan>
question... I'm trying to mainline support for a panel for a Raspberry pi, but it looks like I need to come up with a new media bus format to do so? Any thoughts on what it should be called?
<macromorgan>
it's a panel that adheres to DPI_FORMAT_16BIT_565_RGB_2 instead of DPI_FORMAT_16BIT_565_RGB_3 which is mapped to MEDIA_BUS_FMT_RGB565_1X16
<macromorgan>
in summary I need to edit the vc4_dpi.c file with the new media bus format to support the new panel, then I need to add support for the panel in panel-simple.c. I just don't know what to call the new format.
fxkamd has quit [Remote host closed the connection]
fxkamd has joined #dri-devel
<macromorgan>
don't blame you alyssa
<macromorgan>
still, this is relatively straight-forward I hope
<macromorgan>
I mean, I guess I could also simply add a devicetree parameter to set the pixel mode and not fuss with media formats?
<daniels>
emersion: thanks for picking those up!
ybogdano has joined #dri-devel
<macromorgan>
anholt, do you have thoughts one way or another for the vc4_dpi driver? (add an optional devicetree parameter to override the DPI_FORMAT, or add a new media bus format and include it in the switch for the vc4_dpi driver?)
anarsoul has quit [Read error: Connection reset by peer]
illwieckz has quit [Remote host closed the connection]
anarsoul has joined #dri-devel
anarsoul has quit [Read error: Connection reset by peer]
anarsoul has joined #dri-devel
<anholt>
macromorgan: the bus format of the connector is used to set the DPI_FORMAT reg. You should be able to just set it appropriately in your panel driver.
LexSfX has quit []
<macromorgan>
right, but there is nothing currently that corresponds to DPI_FORMAT_16BIT_565_RGB_2
<macromorgan>
which is what I need to set the DPI_FORMAT reg to
<macromorgan>
should I either 1) allow specifying the DPI_FORMAT via an optional devicetree parameter or 2) create a new MEDIA_BUS_FMT_RGB565_1X16_SOMETHINGNEW to set in the panel driver and update the vc4_dpi driver to match that value to DPI_FORMAT 2?
<anholt>
new media bus format
<macromorgan>
okay, thanks. Any thoughts on what it should be named?
<anholt>
I haven't worked in display stuff for a couple of years, it would take me a while to get back up to speed on it.
<macromorgan>
that's fine... is there someone better to ask?
<anholt>
I don't know of much activity in that area (dpi isn't used a ton any more), so I would just go look at what the difference is in the layout of the pixel bits on the lines.
<macromorgan>
okay... looks like some padding before each color, I'll figure something out then
Bennett has joined #dri-devel
mlankhorst has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
mdnavare has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
anarsoul has quit []
anarsoul has joined #dri-devel
Surkow|laptop has quit [Remote host closed the connection]
Surkow|laptop has joined #dri-devel
anarsoul has quit [Remote host closed the connection]
<zackr>
emersion: yea, i get why it's returning bool, i'm just saying it's inconsistent with the rest of the api. in particular because it's returning false for both no further formats/modifiers and error which almost begs for an int (and again i apologize for not noticing this months earlier)
anarsoul has joined #dri-devel
mszyprow_ has quit [Ping timeout: 480 seconds]
camus1 has joined #dri-devel
anarsoul has quit [Read error: Connection reset by peer]
anarsoul has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
LexSfX has joined #dri-devel
Namarrgon has joined #dri-devel
gouchi has quit [Remote host closed the connection]
<jekstrand>
anholt: That's an old attempt at shrinking NIR algebraic so there's some prior art there.
<jekstrand>
anholt: Never landed, of course. :-( And I wouldn't try directly rebasing it either. But maybe there's some useful ideas?
<anholt>
yeah, I recalled that there was something around for that, but you landed the really important bit (ba0f203ae82673ad050355e94386c849de7eaa92) already.
ella-0 has quit [Ping timeout: 480 seconds]
<jekstrand>
anholt: Yeah, that was the biggest bit.
<anholt>
looking at it, I don't think you actually have anything important left in that branch?
<anholt>
bitfields for struct sizes, I guess
<anholt>
I was figuring I'd look at some bitfields once we get rid of the relocations
<jekstrand>
I was also getting rid of relocations
<jekstrand>
"Add support for "compact" expressions"
<jekstrand>
Not going to clame mine's any better than yours.
<jekstrand>
I've not looked at this problem space in a while and mine predates all the automata stuff
ngcortes has joined #dri-devel
<jekstrand>
Anyway, feel free to take anything you think is useful or chuck it all.
<alyssa>
jekstrand: If this doesnt work out we can try LLVM's approach to managing code size?
<jekstrand>
alyssa: don't bother?
<alyssa>
that's the one!
<alyssa>
:-p
<anholt>
jekstrand: ok, I see it now. I think my changes end up being simpler, other than the, you know, "doesn't work" part.
<jekstrand>
anholt: hehe. If you think you can do it simpler, that's fine by me
<anholt>
+70, -61 so far.
mlankhorst has joined #dri-devel
sadlerap1 has quit []
<alyssa>
jekstrand: the trouble with optimizing NIR is then my backend has to be optimized too to keep up my ratios :-p
sadlerap has joined #dri-devel
<alyssa>
OOI is NIR getting bloated over time or have there just always been bigger fires that optimizing NIR size wasn't priority until now?
yogesh_mohan has joined #dri-devel
<jekstrand>
NIR is like a tree. Every once in a while, it gets too big and starts rubbing up against the house or power lines or something and we need to trim it back a bit.
<alyssa>
Hehe
<alyssa>
I suppose shipping vulkan drivers with their own copies of NIR was the big bloat moment?
<alyssa>
i would add Java to my dislikes list, far ahead of even C++
<anholt>
tried to add a new member to the Value, but there was already something with that name and because you don't have to declare your stuff I didn't notice.
thellstrom has quit [Remote host closed the connection]
<alyssa>
um
thellstrom has joined #dri-devel
Daanct12 has joined #dri-devel
Danct12 has quit [Ping timeout: 480 seconds]
jkrzyszt has quit [Ping timeout: 480 seconds]
thellstrom has quit [Quit: thellstrom]
i-garrison has quit []
nchery is now known as Guest7246
nchery has joined #dri-devel
Bennett has quit [Remote host closed the connection]
i-garrison has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
Guest7246 has quit [Ping timeout: 480 seconds]
gawin has quit [Ping timeout: 480 seconds]
<anholt>
ajax: is there a good way of visualizing or summarizing relocations in my .o/.a/.so/whatever file?
<anholt>
I suspect I've finished cleaning them out of algebraic
vivijim has quit [Ping timeout: 480 seconds]
mszyprow_ has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
gpuman_ has quit [Remote host closed the connection]
gpuman has joined #dri-devel
mszyprow_ has quit [Ping timeout: 480 seconds]
<jekstrand>
Kayden (and others): If I want a sysval that's uvec2(gl_FragCoord.xy), what should I call it?
<jekstrand>
Current straw-man is to call it frag_pos
<jekstrand>
frag_coord_uvec2 is also an option if a bit verbose
<jekstrand>
BLORP really wants this and, with some changes I'm looking at around MSAA, adding it is looking like it'd help our back-end.
<jekstrand>
As a possible alternate, how would people feel about a version of sample_pos that doesn't force sample shading and returns (0.5,0.5) if sample shading isn't enabled?
<airlied>
how often you going to type it in, frag_coord_uvec2 sounds fine to me
<anholt>
+1 to having a nir frag_coord_uvec2 (:shrug: about naming it)
<jekstrand>
Plan would be to have nir_lower_system_values auto-convert to uvec2(gl_FragCoord.xy) if you don't claim support.
<jekstrand>
Related question: Should we have FRAG_Z and FRAG_W as separate system values and a lowering pass to re-construct gl_FragCoord from the bunch?
<jekstrand>
At least on Intel, that's what we really want.
<jekstrand>
One thing that's been bothering me for years is that we tell the HW to provide .z and .w regardless of whether or not they're used. No idea if it's actually costing us something but of the 10k instances of gl_FragCoord, a LOT of them only use xy
<jekstrand>
This gets especially annoying with variable-rate shading
<jekstrand>
The back-end's pretty good with dead-code and we do re-use unused payload regs but still...
<anholt>
yeah, for freedreno we use nir_ssa_def_components_read to mask off unnecessary fragcoord component generation by the HW.
<jekstrand>
Would freedreno also like w and z separate then?
<jekstrand>
And would it like the float->int and +sample_pos in NIR?