ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
cwegener2 has joined #dri-devel
cwegener1 has quit [Ping timeout: 480 seconds]
co1umbarius has joined #dri-devel
cwegener2 has quit []
columbarius has quit [Ping timeout: 480 seconds]
guru_ has joined #dri-devel
kzd has quit [Quit: kzd]
guru_ has quit []
jewins has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
<redeeman>
hello, what assumptions does userspace make about /dev/dri/renderD* devices? if there are no permissions to renderD128, will is renderD129 supposed to be attempted? a quick test shows that "vulkaninfo" does indeed do that, but mesa prints an error with permission denied. glxinfo does not print an error, but continues to work. I ask because I run a multiseat setup, and i notice both have 0666 permissions, and im thinking that I would
<redeeman>
quite prefer one seat not to touch the others graphics card for any reason at all
penguin42 has quit [Remote host closed the connection]
idr has quit [Ping timeout: 480 seconds]
frankbinns has quit [Remote host closed the connection]
frankbinns has joined #dri-devel
pallavim__ has joined #dri-devel
pallavim_ has quit [Ping timeout: 480 seconds]
benjamin1 has joined #dri-devel
JohnnyonF has quit [Ping timeout: 480 seconds]
benjamin1 has quit [Ping timeout: 480 seconds]
idr has joined #dri-devel
<dcbaker>
karolherbst: 1.2.0-rc1 will branch soon, and those rust fixes will be in. The -I stuff didn’t land, so we may need to do something different there in the short term
aravind has quit [Ping timeout: 480 seconds]
idr has quit [Ping timeout: 480 seconds]
kzd has joined #dri-devel
dsrt^ has joined #dri-devel
cwegener has joined #dri-devel
kzd has quit [Quit: kzd]
derRichard has quit [Remote host closed the connection]
iokill has quit [Remote host closed the connection]
iokill has joined #dri-devel
derRichard has joined #dri-devel
Duke`` has joined #dri-devel
cwegener1 has joined #dri-devel
cwegener has quit [Ping timeout: 480 seconds]
ngcortes has quit [Read error: Connection reset by peer]
eukara has joined #dri-devel
aravind has joined #dri-devel
Company has quit [Quit: Leaving]
Duke`` has quit [Ping timeout: 480 seconds]
tzimmermann has joined #dri-devel
bmodem has joined #dri-devel
itoral has joined #dri-devel
thellstrom has joined #dri-devel
rasterman has joined #dri-devel
thellstrom1 has joined #dri-devel
lina has joined #dri-devel
thellstrom has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
frieder has joined #dri-devel
idr has joined #dri-devel
Ahuj has joined #dri-devel
Ahuj has quit [Read error: Connection reset by peer]
Mary has joined #dri-devel
bmodem has joined #dri-devel
bmodem has quit [Read error: Connection reset by peer]
bmodem has joined #dri-devel
idr has quit [Ping timeout: 480 seconds]
frieder has quit [Remote host closed the connection]
frieder has joined #dri-devel
sghuge has quit [Remote host closed the connection]
<olv>
yeah, I should be able to get to tomorrow or the day afer
<olv>
sorry for the delay
<karolherbst>
dcbaker: okay. the flag stuff is easy to workaround though, or rather the current workaround doesn't look too ugly, so that's fine
<karolherbst>
ohh wait.. on debian it's broken.. nvm
swalker__ has joined #dri-devel
apinheiro has joined #dri-devel
swalker_ has joined #dri-devel
swalker_ is now known as Guest4429
sgruszka has joined #dri-devel
swalker__ has quit [Ping timeout: 480 seconds]
frankbinns has quit [Remote host closed the connection]
frankbinns has joined #dri-devel
Haaninjo has joined #dri-devel
vliaskov has joined #dri-devel
<pq>
redeeman, I think that depends on how each application picks the GPU it wants to work with. Window system may give hints that apps might follow, but if something tell the app to really this particular "wrong" GPU, then naturally it won't work.
<pq>
redeeman, so it depends on what API the app is using in the first place, and does it give the API implementation an opportunity to pick an arbitrary GPU.
<pq>
redeeman, if there is exactly one GPU for a seat, I guess you could try setting DRI_PRIME to a devpath in the environment.
lina has quit [Read error: Connection reset by peer]
lina has joined #dri-devel
Haaninjo has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
Haaninjo has quit [Remote host closed the connection]
<kchibisov>
Is mesa not supporting EGL_KHR_display_reference?
phasta has joined #dri-devel
FireBurn has joined #dri-devel
Leopold has joined #dri-devel
Leopold_ has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
bmodem has quit [Excess Flood]
bmodem has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
bmodem has quit [Excess Flood]
bmodem has joined #dri-devel
cmichael has joined #dri-devel
Ahuj has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.6]
lemonzest has joined #dri-devel
<redeeman>
pq: there is one gpu for each seat, would you also agree that it is probably most correct to not let seats cross contaminate? my attention was drawn to this when amdgpu_top was able to access both gpu's, but even more to my horror, chrome seems to allocate vram on both gpu's
<pq>
redeeman, yes, I agree. If you want separation, you should be able to have separation.
<pq>
especially when you already have completely separate GPUs to begin with
<redeeman>
i'll give it a go and just change the permissions out to match the seat permissions that are already enforced on the card devices and see, I just wanted to know if there was some assumptions from userspace that was known to break in 100 ways
<pq>
nothing that I know of, but I also don't know how things handle not having access to a render node
<pq>
render nodes are supposed to be safe in that they already isolate user contexts from each other
<pq>
but of course, isolating contexts does not stop someone from hogging all VRAM or GPU time
<pq>
hence dedicating a GPU per user makes sense to me
<pq>
well, per seat
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
bmodem has quit [Excess Flood]
JohnnyonFlame has joined #dri-devel
bmodem has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
bmodem has quit [Remote host closed the connection]
bmodem has joined #dri-devel
FireBurn has quit [Quit: Konversation terminated!]
thellstrom1 has quit [Ping timeout: 480 seconds]
vicky has joined #dri-devel
camus has quit [Remote host closed the connection]
alyssa has joined #dri-devel
<alyssa>
zmike: do interpolation qualifiers (flat/noperspective) need to match between the VS/FS when GPL/ESO are used?
<alyssa>
as far as I can tell:
<alyssa>
- OpenGL always gives enough information to match them without variants. ARB_separate_shader_objects requires the qualifiers to match. And linked shaders, you can just specialize at link time without variants.
<alyssa>
- Vulkan monolithic pipelines, same as the GL linked shader case
<alyssa>
- Vulkan 1.3 explicitly does not require the qualifiers to match (15.1.3 "Interface matching")
<alyssa>
- Vulkan EXT_shader_object spec says nothing about interpolation qualifiers. So seemingly this allows them to NOT match. This may or may not have been intended.
<alyssa>
- Vulkan GPL has a feature bit for this purpose: graphicsPipelineLibraryIndependentInterpolationDecoration
<alyssa>
Although...
<alyssa>
GPL proposal 5.6 comments
<alyssa>
"Some implementations require the interpolation decorations in the last geometry shader stage if pipeline libraries are used, and this is advertised by the graphicsPipelineLibraryIndependentInterpolationDecoration property. It is expected that these implementations are serving markets where OpenGL ES is dominant, where this requirement was never dropped for separate shader objects, unlike OpenGL"
<alyssa>
So apparently the GL requirement dropped at some point...
Guest4429 has quit [Remote host closed the connection]
fab has quit [Read error: Connection reset by peer]
<alyssa>
Bottom line is that we'll need to handle it for DXVK. Oh well.
<alyssa>
It's not the end fo the world. Annoying that this information is so spread out across Khronos specs.
<pq>
someone is still using skynet.ie address for airlied on mailing lists and I get tons of failed to deliver from gmail when replying.
djbw has quit [Read error: Connection reset by peer]
<pq>
"Gmail will retry for 140 more hours. You'll be notified " again and again
<lordheavy>
Hi everybody, i'm just here to get some help; rusticl doesn't work here - clinfo doesn't detect any device and i don't know how i can't fix this problem. I use llvm/libclc/mesa from git under archlinux
itoral has quit [Remote host closed the connection]
<karolherbst>
still trying to wrap my head around all that DRM stuff, but inside drm_crtc_helper_funcs::mode_valid, can I know what connector the mode is requested on? It's really a pita that I can reject userspace modes inside drm_connector_helper_funcs::mode_valid.. and I kinda need something which comes closest to that.
<karolherbst>
or is it "good enough" for atomic and non atmic uapi users to do that validation inside drm_connector_helper_funcs::atomic_check?
phasta_ has joined #dri-devel
phasta has quit [Read error: Connection reset by peer]
<pq>
Is https://docs.mesa3d.org/gallium/distro.html the page that is supposed to tell me what are "iris" or "crocus" or "i915" when used to refer to "gallium drivers"? Or maybe the "Drivers" section on the navigation bar on the left?
f11f12 has joined #dri-devel
<pq>
https://docs.mesa3d.org/amber.html is almost telling me what I wanted to know, but I also am specifically not wanting amber, so I wouldn't have known to look there.
phasta_ has quit [Ping timeout: 480 seconds]
<FLHerne>
pq: iris and crocus definitely belong in that Gallium list
<FLHerne>
probably in the 'Drivers' section too although that seems a fairly random assortment
<FLHerne>
I note 'Drivers' lacks an index, and some pages explain what they are whereas some assume you know and go straight into details
<pq>
What is "Gallium Off-screen rendering" and why does it default to "NO" in the Meson summary?
thellstrom1 has quit [Ping timeout: 480 seconds]
<MrCooper>
pq: I believe that's the Gallium version of OSMesa, a special API for offscreen software rendering
<pq>
oh, osmesa, ok
<MrCooper>
lordheavy: RUSTICL_ENABLE=radeonsi is required, it can't find spirv(64)-mesa3d-.spv
Venemo has quit [Remote host closed the connection]
glehmann has quit [Remote host closed the connection]
thellstrom has joined #dri-devel
jewins has joined #dri-devel
simon-perretta-img has quit [Read error: Connection reset by peer]
rasterman has quit [Quit: Gettin' stinky!]
thellstrom has quit [Ping timeout: 480 seconds]
glehmann has joined #dri-devel
Venemo has joined #dri-devel
kzd has joined #dri-devel
f11f12 has quit [Quit: Leaving]
frankbinns has quit [Remote host closed the connection]
pallavim has joined #dri-devel
fab has quit [Quit: fab]
<Lynne>
I haven't been able to get rusticl to run either, despire running fine on iris
<karolherbst>
is there actually a reason why we don't validate userspace modes? Seems like even if atomic_check fails, X is silly enough to set the mode regardless and stays on it?
<karolherbst>
or rather... do we have a 100% reliable way to fail a requested modeset from non atomic userspace so it uses a different mode or something?
<pq>
karolherbst, what do you mean set the mode regardless? Isn't atomic_check called as part of atomic_commit so it fail the whole commit?
<karolherbst>
yeah, but X doesn't seem to care
<pq>
The mode doesn't get set, Xorg cannot force its way through that. It can just sit there broken, but it cannot force the mode if the driver fails it.
<karolherbst>
okay, let me rephrase: X sits there broken
<pq>
ah
<karolherbst>
and gives me a black screen
alyssa has left #dri-devel [#dri-devel]
<karolherbst>
but actually.. I just want to reject broken userspace modes
<karolherbst>
like.. entirely
<karolherbst>
I also don't know why we don't run mode_valid on userspace modes on connectors...
<pq>
if you already make the drmModeSetCrtc() ioctl fail, you've done it already. If X doesn't handle that failing, it's X's fault.
<karolherbst>
I don't actually know what userspace does and what ioctl fails.. maybe I should check that...
<pq>
Xorg only uses legacy non-atomic UAPI, which the kernel translates to internal atomic API.
<karolherbst>
right
<pq>
So if you fail the internal atomic commit, you're done.
<daniels>
*atomic check
<karolherbst>
yeah.. but that leaves users with broken systems, because Xorg adds broken modes
<karolherbst>
people don't want xorg to not do that, so that leaves me with dealing with that mess
<karolherbst>
but we also don't reject broken modes, so... kinda sounds like our fault
<pq>
daniels, isn't atomic check is called from inside atomic commit? I presume one cannot commit without also going through check.
<daniels>
so there's not really an 'add mode' step; drmModeSetCrtc takes a completely random DRM mode struct which userspace can fill with anything it wants, even if it hasn't passed it to the kernel first
<karolherbst>
okay.. fair
<daniels>
pq: DRM_IOCTL_MODE_ATOMIC will call atomic_check() followed by (if you haven't passed TEST_ONLY) atomic_commit(); DRM_IOCTL_MODE_SETCRTC will call both
<pq>
daniels, exactly.
<karolherbst>
okay soo, here is the deal.. X doesn't fall back when starting with a broken mode
<pq>
what would it even fall back to?
<karolherbst>
a mode it didn't add?
<karolherbst>
I mean.. if xorg tries to set to a state with its own mode and it fails, it's kinda its own fault for trying so, no?
<pq>
Xorg uses exactly the mode that the config or X11 clients tell it to.
<karolherbst>
I've been there already
<karolherbst>
it does try something on its own
<karolherbst>
gnome doesn't add those modes
<karolherbst>
and apparently xorg shouldn't as well? what is it now
<karolherbst>
I've seeing custom modes that _I_ didn't configure
<MrCooper>
karolherbst: just stop caring about Xorg :)
<karolherbst>
yeah.. I mean.. fine by me, but then users still have to be able to migrate or something
<karolherbst>
but yeah, can also just close all bugs with xorg as "invalid"
<MrCooper>
the vast majority of them are able to migrate
<jannau>
karolherbst: gnome is adding modes (under speficic conditions)
<karolherbst>
it's not about being able to
<karolherbst>
it's about forcing them to
<karolherbst>
jannau: yeah.. but in this case it's X
<karolherbst>
because I see those modes without gnome running
<MrCooper>
think of it as encouragement
<karolherbst>
uhhh.. I wish _I_ could move to wayland for testing, but apparently today we can't even select the main GPU in a multi GPU setup
<karolherbst>
which I really need
<pq>
DRI_PRIME?
<karolherbst>
not for rendering
<karolherbst>
for compositing
<pq>
yes, for compositing
<karolherbst>
if that works... but anyway, I kinda wished X just wouldn't do this...
<pq>
set that for the compositor, does it not work? Though I guess it defaults to the same GPU that drives the outputs in most compositors.
<pq>
On Wayland compositors the choice of a GPU and display DRM devices is up to each compositor, and not Wayland, so it can vary.
<karolherbst>
right
<karolherbst>
but anyway
<karolherbst>
I really just need a way to deal with that mess without breaking users machines
<lordheavy>
MrCooper Lynne: Either with RUSTICL_ENABLE=radeonsi - it doesn't work - except "Libclc failed to load. Please make sure it is installed and provides spirv-mesa3d-.spv and/or spirv64-mesa3d-.spv" message - but libclc is installed with both spirv-mesa3d-.spv and spirv64-mesa3d-.spv
<karolherbst>
maybe it doesn't really find the correct path? where are those files installed?
<lordheavy>
Rusticl isn't very verbose about the problem. Is there any way to have more verbosity ?
sgruszka has quit [Remote host closed the connection]
<karolherbst>
lordheavy: the path kinda has to match libexecdir, but you can probably also check with strace where it tries to search for it
<lordheavy>
karolherbst: clc is installed in /usr/lib/clc
<karolherbst>
does the path of libclcs pkgconfig file point to the same location?
<karolherbst>
but anyway.. strace should also tell you where it tries to load it from.. gimme s ec
<lordheavy>
karolherbst: good catch! path is libexecdir=/usr//usr/lib/clc
<karolherbst>
uhhh
<karolherbst>
what a weird path :)
<lordheavy>
lol yes i know now how to fix that :)
<karolherbst>
I don't know if meson picks up a change in the pkgconfig file itself, but probably
alyssa has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
<zmike>
alyssa: good talk
* alyssa
gives zmike a thumbs-up
<alyssa>
zmike: possibly Zink should refuse to GPL if the vulkan driver doesn't advertise graphicsPipelineLibraryIndependentInterpolationDecoration though
<alyssa>
purely theoretical issue since {nvidia, all current mesa drivers} advertise that
* alyssa
doesn't really care
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
fab has joined #dri-devel
bmodem has quit [Excess Flood]
jewins has joined #dri-devel
bmodem has joined #dri-devel
junaid has joined #dri-devel
junaid has quit []
bmodem has quit [Remote host closed the connection]
bmodem has joined #dri-devel
junaid has joined #dri-devel
<lordheavy>
karolherbst MrCooper: fixed, thanks - now it works
<karolherbst>
also... would _anybody_ scream if we pipe modes through connects mode_valid callback?
<karolherbst>
I really need a way to reject modes through mode_valid based on the connector used... e.g. for rejecting modes used on HDMI displays based on the clock
<karolherbst>
and the other places don't cut it
lordheavy has quit [Remote host closed the connection]
<karolherbst>
encoder doesn't, because at this point I only know it's TMDS and that _might_ be duallink
<karolherbst>
and doing it on the crtc is kinda... "weird", or maybe it's the proper place?
<_jannau__>
karolherbst: I think nouveau might miss drm_mode_config_funcs::mode_valid
alyssa has left #dri-devel [#dri-devel]
<karolherbst>
yeah, it does
<karolherbst>
and I already implemented that.. kinda
<karolherbst>
or wait...
<karolherbst>
is that another one?
<_jannau__>
that gets the connector as argument and I think it will be called from setcrtc
<karolherbst>
ehh no, that's not useful
<karolherbst>
it only gives me the dev and the mode
<karolherbst>
but the mode might be fine on other connectors
<karolherbst>
like... 240MHz rate might be fine on duallink DVI, but not on HDMI
<karolherbst>
I really really _really_ have to know what connector it's used on
<karolherbst>
drm_connector_helper_funcs::mode_valid would be the _perfect_ place for it, but it's not called on userspace provided modes
<_jannau__>
oh, sorry. I missed that we currently just map that onto the connector in apple drm since there is just one connector
<karolherbst>
yeah... kinda figured that :D
<karolherbst>
I currently reject the mode in the encoder callback
<karolherbst>
but that only works because the mode I see is really crazy
<karolherbst>
so on some GPUs we can only do 165MHz HDMI (or lower), doubled with DVI duallink, but the mode in question (356MHz) is over that in either case
<karolherbst>
but a 200MHz HDMI mode would be accepted there :/
<karolherbst>
because the encoder is "TMDS" which can be either
lordheavy has joined #dri-devel
junaid has quit [Remote host closed the connection]
aravind has joined #dri-devel
<_jannau__>
drm_atomic_helper_check_modeset docs suggests that the mode is checked in drm_connector_helper_funcs.atomic_check
<karolherbst>
yeah, but not userspace ones
<karolherbst>
so.. what it's used on is to filter modes the kernel tells userspace exist
<karolherbst>
but it's not used on modes userspace then tries to set
<karolherbst>
I suspect just checking when doing atomic_check is the only _currently_ working way of doing this then
Duke`` has joined #dri-devel
Ahuj has quit [Ping timeout: 480 seconds]
jewins has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
kts has joined #dri-devel
pallavim_ has joined #dri-devel
pallavim has quit [Read error: Connection reset by peer]
lordheavy has quit [Remote host closed the connection]
junaid has joined #dri-devel
lordheavy has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
benjamin1 has joined #dri-devel
lordheavy has quit [Remote host closed the connection]
aravind has quit [Ping timeout: 480 seconds]
jewins has joined #dri-devel
rsalvaterra has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
idr has joined #dri-devel
rasterman has joined #dri-devel
djbw has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
vsyrjala_ is now known as vsyrjala
rsalvaterra has joined #dri-devel
Danct12 has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
junaid has quit [Remote host closed the connection]
junaid has joined #dri-devel
dsrt^ has quit [Remote host closed the connection]
<karolherbst>
okay.. I think I'm done implementing the mode check