<YuGiOhJCJ>
do you know why glx.pc is not provided when I build mesa-23.0.3? it's a problem because when I build mesa-demo-9.0.0, glx is not found and so glxgears is not built
tursulin has joined #dri-devel
<pq>
YuGiOhJCJ, looks like it's provided by glvnd, like all GL related APIs.
<YuGiOhJCJ>
oops and I deleted libglvnd because I don't use it
<YuGiOhJCJ>
well, it means I need to keep libglvnd on my system
<pq>
emersion, zamundaaa[m], I guess we just need to start depending on the permanent connector ordering, wait for the kernel to break that, wait for users to complain, and then report a kernel regression. :-P
<emersion>
but afaik it's already somewhat broken in some situations?
<pq>
does it matter? all we need is something that used to work, and then doesn't.
<emersion>
"it worked once" is not what a regression means
<pq>
"it worked reliably for this user repeatedly, until they upgraded the kernel"
<emersion>
if a deferred probe makes it work 90% of the time, it's not a regression when it fails 10%
<pq>
that's not the failure case I'm thinking
<emersion>
ah, you're thinking driver changes order of its logic?
<pq>
I'm thinking no deferred probe involved, but driver code changes changed the order.
<emersion>
shuffles create_connector() calls?
<emersion>
right
<cwabbott>
anholt: there's one more fix required for ESO on turnip but it's still in review
<emersion>
yeah, that'd qualify
<pq>
emersion, but yeah, I agree, I'd prefer something that was intended as a persistent id.
<MrCooper>
YuGiOhJCJ: either that, or build Mesa with -Dglvnd=false
the_sea_peoples has quit [Remote host closed the connection]
JohnnyonFlame has quit [Read error: Connection reset by peer]
the_sea_peoples has joined #dri-devel
<YuGiOhJCJ>
MrCooper, if I build mesa with -Dglvnd=false, it won't help me because I want "glxgears" from "mesa-demos", so "glx.pc" is necessary and "libglvnd" has to be installed for that
<sima>
MrCooper, a surprise, but a welcome one
<sima>
emersion, pq I think gregkh is pretty stern on "driver load order resulting in different enumeration is not a regression" policy
<emersion>
sima, this isn't about driver load order
<sima>
ah I guess I misunderstood scrollback then
<pq>
sima, this is about connector registering order inside a driver.
<emersion>
sima, this is about eDP-1 being created before HDMI-1 in the driver
<sima>
how can that break userspace?
<sima>
you hardcode the connector_id instead of the name?
<sima>
s/hardcode/store in config/
<emersion>
if the driver decides to change its logic to create HDMI-1 before eDP-1, then it will break userspace using index as stable ID
<emersion>
connector_id is a KMS object ID no?
<emersion>
and connector_type_id is global, not per-driver
<emersion>
nor per-device
<pq>
sima, if we use the connector *index* in the connector array of get-reources as a stable identifier of a connector on a specific hardware device, then changing connector registering order would change that index and break our connector naming that is used in end user config files.
<emersion>
(note: we're aware this doesn't fly for DP-MST)
<sima>
yeah if userspace does that and a driver breaks I'll go grab the really good stuff and get wasted :-)
<pq>
sima, well, this is the only thing userspace could do atm.
<sima>
maybe celebrate the inglorious genius of making connector_type_id global too
<pq>
everything else is even worse
<sima>
pq, remap connector_type_id to be per-device?
<pq>
even if connector_type_id was per-device, it would still break if connector registering order changed, right?
<sima>
I think with all drivers it's safe to assume that that is stable
<MrCooper>
YuGiOhJCJ: AFAICT Mesa demos don't directly require glx.pc, so it should work if you re-generate its build system files against a non-glvnd Mesa build
<sima>
but e.g. the load order of edp vs hdmi might change, because those can be bridge drivers
<emersion>
we're talking about using the index, not the connector_type_id
<sima>
and with bridge drivers using component.c the driver load order impacts how they're called and registered
<sima>
emersion, yeah but I think the index is too risky
<emersion>
hm
<emersion>
so connector_type_id would be more reliable except for the fact it's global?
<sima>
remapping to counting 1st/2nd/3rd per connector type per device I think is something the kernel can sign up for as a full uapi promise
mripard has joined #dri-devel
<pq>
per-device connector_type_id is better than array index which is better than current(?) connector_type_id
<sima>
yeah the current global connector_type_id is bonghits
<sima>
but instead of computing the index across all connectors, you could compute it across all connnectors of the same type
<pq>
true
<sima>
and I think that the kernel could sign up for as "yes it's stable uapi" and we document it as such
<sima>
kinda like we can (do?) sign up that crtc/plane are stable, since they're sometimes not equal
<pq>
maybe the kernel should provide a userspace library for stable naming of connectors :-P
<pq>
or like, libdrm
<sima>
but across types there's lots of drivers where it's stitched together from components and bridges and that's load order fun
<sima>
pq, yeah we can also do a little stable-id helper in libdrm that implements the promise I guess
<MrCooper>
YuGiOhJCJ: nvm, was looking at old demos snapshot
<sima>
emersion, pq probably should still check with drivers using lots of component/bridge to make sure they're confident we can make this promise, but my gut feel at least it it's a lot more doable than connector_id or connector index
<MrCooper>
YuGiOhJCJ: oh, but the toplevel meson.build has code to handle this
<emersion>
ideally we'd just have a connector prop but…
<sima>
oh could do that too
<pq>
sima, what about the full solution? a new KMS connector prop containing a hardware-dictated path?
<sima>
emersion, pq might be even better since for hotplugged connectors we could use then something entirely different like the path prop
<emersion>
yea
<sima>
and we could have the entire thing handled in drm core code I think
<emersion>
and this time not with a KMS object ID embedded in it…
<sima>
since we know which ones are hotplugged and which not
<pq>
that was already 4 years ago, damn
<sima>
pq, well lift it to drm code
<sima>
just autofill the path prop for !MST connectors in drm_dev_register or so
<sima>
and complain if any driver ever fails to set path prop for hotplugged connectors
<pq>
PATH prop is already broken, is it a good idea to use the same name?
<sima>
how is path prop broken?
<pq>
embeds a KMS connector id number
<sima>
oh lol
<emersion>
connector object ID
<sima>
yeah then it's something new we need
<sima>
the base connector id really shouldn't be in there
<pq>
one could say that userspace needs to drop that part and replace it with root connector's PATH, but that's... ugh.
<sima>
well it should be the base connector but with the per-device&type idx
<emersion>
yea
<sima>
pq, yeah it's useable, but it's not great without parsing and fixing things up
<pq>
it should be the base connector's TRUE_PATH, literally
<sima>
which you can do already in the way we just discussed, but I'm on board with the kernel doing the work to encode it per whatever uapi promise we come up with
<sima>
I do wonder whether we could change the sysfs name to this true path
<sima>
or too many scripts for that
<sima>
but I expect that since most systems have only one gpu we should be able to get away with that
<sima>
would be at least nice if we could put a more reasonable path name into sysfs, it's kinda meant to reflect the physical topology ...
<pq>
could the kernel do better with TRUE_PATH than just per-device per-connector-type counter? Like some actual hardware path resembling thing, e.g. go through bridges A-B-C then second connector on that.
<pq>
not that we'd need to tell userspace about bridges per se, but just as opaque tokens in the TRUE_PATH
sarahwalker has joined #dri-devel
the_sea_peoples has quit [Ping timeout: 480 seconds]
ced117 has joined #dri-devel
<sima>
pq, I guess if we ever get the fun of different hdmi connectors going through different bridges we could use that topology internally to stabilize the numbers
<sima>
but feels like a bridge too far otherwise
<pq>
ok :-)
<sima>
I'm also not sure what userspace can do with that knowledge, unlike mst you're not going to resolder the chip-internal routing (or the pcb, but usually these are all on-chip)
<pq>
no, userspace would not *parse* that information.
<emersion>
i think the main upside would be that drivers would be less likely to break it
<sima>
yeah then I'd say it's better to not expose it, and only use internal once we need to
<sima>
because if we do, someone will get creative and parse it and create some fun with that perhaps
<emersion>
you could always sha1 the whole thing or something
<emersion>
but yea
<sima>
emersion, well we could iterate connectors by iterating encoders
<sima>
and then walking the bridge chain
<sima>
well don't even have to walk the bridge chain
<sima>
just check for which connector is there
<sima>
so that's pretty quick to implement I think, if we need it
mripard has quit [Quit: mripard]
<sima>
not sure we should do that from the start though, it'd be a bit brittle since there's a few funny corner cases
mripard has joined #dri-devel
<sima>
(like multiple connector on the same encoder and things like that)
<sima>
and I'm not even sure it'd be good enough as-is, we might also need to make sure that encoders are then stable enough with their ordering
<sima>
so just pushed the problem around a bit
<sima>
and sha1 wont help since for encoder there's nothing more stable than their idx
sarahwalker has quit [Ping timeout: 480 seconds]
<sima>
tldr; leaning towards "we solve this when it goes boom"
<pq>
yeah, which is why I was wondering if the identity string could be manuaactured from actual hardware arrangement.
<pq>
instead of counters
<sima>
we could sort by acpi/dt names maybe
<sima>
but that's a pile of typing
<sima>
and I'm not sure those are stable enough either
<emersion>
the failure case i'm worried about is when the kernel devs change the order of some function calls
<emersion>
and then don't realize it's a breaking uAPI change
<sima>
I think someone accidentally changing from fifo to lifo or the other way round with list walking to register/handle stuff is more likely
<sima>
the function call stuff is generally just calling into various connector/encoder types
<sima>
which is why I think per-type should cover all these
<sima>
but for the componentized drivers there's a lot of lists: struct device, component.c, bridge lists, the drm_device lists and probably more
<sima>
they all need to stay ordered the same or boom
digetx has joined #dri-devel
yyds has quit [Remote host closed the connection]
yyds has joined #dri-devel
Net147 has quit [Quit: Quit]
kts has joined #dri-devel
Net147 has joined #dri-devel
rasterman has joined #dri-devel
i509vcb has quit [Quit: Connection closed for inactivity]
<tomeu>
DavidHeidelberg: is it possible that docs/ci/kernel.rst is a bit out of date?
<tomeu>
I see it still refers KERNEL_URL and wonder if the rest matches the current state of things
<swick[m]>
so, everyone agrees we need a TRUE_PATH prop but who's going to actually write it?
<emersion>
thanks for signing up!
<swick[m]>
didn't vsyrjala wrote some patches before? :P
bmodem has quit [Ping timeout: 480 seconds]
Net147 has quit [Quit: Quit]
Net147 has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
kts has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
yyds has quit [Remote host closed the connection]
Company has joined #dri-devel
fab has quit [Quit: fab]
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
kts has joined #dri-devel
fab has joined #dri-devel
mclasen has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
glennk has joined #dri-devel
koki23[m] has joined #dri-devel
rgallaispou has quit [Read error: Connection reset by peer]
agd5f_ has quit []
rgallaispou has joined #dri-devel
agd5f has joined #dri-devel
bmodem has joined #dri-devel
xroumegue has quit [Ping timeout: 480 seconds]
djbw_ has quit [Read error: Connection reset by peer]
xroumegue has joined #dri-devel
jdavies has joined #dri-devel
jdavies is now known as Guest4571
kts has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
Guest4571 has quit [Ping timeout: 480 seconds]
sarahwalker has quit [Remote host closed the connection]
i509vcb has joined #dri-devel
kzd has joined #dri-devel
a-865 has quit [Ping timeout: 480 seconds]
aknautiy has quit [Read error: Connection reset by peer]
shankaru has quit [Read error: Connection reset by peer]
yuq825 has quit []
tursulin has quit [Remote host closed the connection]
aknautiy has joined #dri-devel
a-865 has joined #dri-devel
shankaru has joined #dri-devel
tursulin has joined #dri-devel
Duke`` has joined #dri-devel
mdroper has joined #dri-devel
Duke`` has quit []
sukrutb has joined #dri-devel
mbrost has joined #dri-devel
Duke`` has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
mclasen has quit [Remote host closed the connection]
mclasen has joined #dri-devel
<DemiMarie>
sima: In Qubes OS we want to be able to know which physical port a given device was plugged into. This is mostly the case for USB devices right now but knowing it for displays would also be very useful.
<sima>
I think for usb devices the plan is to sprinkle sysfs symlinks around so that you can figure that out
<DemiMarie>
The purpose of this is so that on certified hardware, we can display an image that shows where the device is plugged into the chassis. This is the only information about a device that a malicious device cannot spoof.
<sima>
but I haven't followed these plans closely, it's a bit a janky area
<DemiMarie>
sima: could the same information be provided for HDMI and DisplayPort devices?
<emersion>
something landed, but dmitry has objections
<sima>
DemiMarie, I have honestly no idea how/where we could even get that information from for most drivers/systems ...
<sima>
so I guess just hope everything becomes usb-c/dp/tb :-/
<DemiMarie>
sima: does the kernel have that information somewhere?
fluix has quit [Ping timeout: 480 seconds]
<DemiMarie>
Obviously the image generation is in userspace, I just need a number.
sarnex has quit [Read error: Connection reset by peer]
<DemiMarie>
Or is that hidden by some awful layer of firmware somewhere?
bcheng has quit [Ping timeout: 480 seconds]
bcheng has joined #dri-devel
sarnex has joined #dri-devel
<sima>
DemiMarie, I don't even know whether it exists
<sima>
so definitely a use-case I see, but this is going to be some work to make it happen
<gfxstrand>
Ugh... I'm gonna need to do a big SPIR-V refactor... :cry:
glennk has joined #dri-devel
<gfxstrand>
dschuermann: Does AMD hardware have caching/access flags for memory ops on the instruction?
kts has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
<gfxstrand>
dschuermann: NVIDIA does and now I kinda want to put a nir_memory_semantics on load/store/atomic_global
<gfxstrand>
And then type a pass to add barriers as per what spirv_to_nir.c does today.
<gfxstrand>
cmarcelo: ^^
anujp has quit [Remote host closed the connection]
<dj-death>
gfxstrand: sounds possible on DG2+
fluix has joined #dri-devel
<dj-death>
gfxstrand: but there are limitations with atomic_global
sarnex has quit [Read error: Connection reset by peer]
<cmarcelo>
gfxstrand: we expected someday we would use the semantics in loads and stores, why are you expecting a huge change though?
sarnex has joined #dri-devel
djbw has joined #dri-devel
eukara has quit []
eukara has joined #dri-devel
<cwabbott>
gfxstrand: yes it does
<cwabbott>
that was a regression when radv switch to the memory model intrinsics that never got fixed iirc
simon-perretta-img has quit [Read error: Connection reset by peer]
simon-perretta-img has joined #dri-devel
Danct12 has quit [Quit: A-lined: This user has been AViVA-lined!]
gouchi has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
Danct12 has joined #dri-devel
Danct12 has quit []
Danct12 has joined #dri-devel
flom84 has joined #dri-devel
jdavies has joined #dri-devel
jdavies is now known as Guest4592
flom84 has quit [Remote host closed the connection]
Guest4592 has quit []
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
Danct12 has quit [Read error: Connection reset by peer]
Daanct12 has joined #dri-devel
evadot_ has quit []
kts has quit [Quit: Konversation terminated!]
vliaskov has quit [Remote host closed the connection]
flom84 has joined #dri-devel
eukara has quit []
eukara has joined #dri-devel
<alyssa>
gfxstrand: I believe AGX has cache flags on load/store/atomic but I haven't r/e'd any details yet
digetx has quit [Ping timeout: 480 seconds]
<gfxstrand>
cmarcelo: On older Intel, it's mostly just a barrier. On NVIDIA, there is potentially actual cache flushing involved. We could do that on a per-cache-line basis or we could do it across the device. Less is better.
<gfxstrand>
And it's easy enough to write a pass which replicates the current behavior of spirv_to_nir.c which drivers can drop if they want.
digetx has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
evadot has joined #dri-devel
oneforall2 has joined #dri-devel
junaid has joined #dri-devel
junaid has quit [Remote host closed the connection]
glennk has quit [Ping timeout: 480 seconds]
flom84 has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
anholt_ has joined #dri-devel
anholt has quit [Ping timeout: 480 seconds]
<agd5f>
DemiMarie, IIRC, there is the ACPI _PLD stuff, but I don't think I've actually seen that implemented properly anywhere. Also, it's tied to the platform so it wouldn't work for add in boards.
<Lynne>
have I mentioned how much I hate vulkan queries?
<zmike>
no
crabbedhaloablut has quit []
sadlerap has joined #dri-devel
sima has quit [Ping timeout: 480 seconds]
dviola has quit [Ping timeout: 480 seconds]
oneforall2 has quit [Remote host closed the connection]
<Lynne>
you'd think that it just dumping everything in one big buffer is going to be a winning strategy, after all, it's what descriptor buffer does, which is beautiful
<Sachiel>
I guess you haven't worked with XFB
novaisc has joined #dri-devel
tonyk has joined #dri-devel
digetx has joined #dri-devel
tonyk has quit [Remote host closed the connection]
novaisc has quit [Remote host closed the connection]
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
novaisc has joined #dri-devel
tales-aparecida has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
tonyk has joined #dri-devel
novaisc9 has joined #dri-devel
tonyk4 has joined #dri-devel
tales-aparecida2 has joined #dri-devel
tales-aparecida has quit [Ping timeout: 480 seconds]
tonyk has quit [Ping timeout: 480 seconds]
novaisc has quit [Ping timeout: 480 seconds]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
diego has joined #dri-devel
oneforall2 has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
mvlad has quit [Remote host closed the connection]