Leopold has quit [Read error: Connection reset by peer]
Leopold has joined #dri-devel
ice99 has quit []
ice9 has joined #dri-devel
Leopold has quit [Remote host closed the connection]
Leopold__ has joined #dri-devel
Leopold__ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
Hi-Angel has joined #dri-devel
<Hi-Angel>
Do I do something wrong, or Vulkan env. variables for choosing default device doesn't work? Using a `MESA_VK_DEVICE_SELECT=8086:5916 MESA_VK_DEVICE_SELECT_FORCE_DEFAULT_DEVICE=1 gamescope -- glxgears` results in it using AMD GPU (even though the env. variables supposed to hide it completely), although running a `gamescope --prefer-vk-device=8086:5916 -- glxgears` launches it on Intel GPU
junaid has quit [Remote host closed the connection]
ice99 has joined #dri-devel
ice9 has quit [Ping timeout: 480 seconds]
<X512>
Hi-Angel: Why use Vulkan settings for GLX OpenGL program?
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<Hi-Angel>
X512, the gamescope in my comment is a vulkan program, not OpenGL. Even so, I use `gamescope` as just an example. I actually want to make Skype stop using my discrete card (nonsense, why would they do that 🤷♂️), which apparently does that through means of Vulkan.
<emersion>
Hi-Angel: have you tried VK_ICD_FILENAMES?
Leopold_ has quit [Ping timeout: 480 seconds]
Leopold has joined #dri-devel
<Hi-Angel>
emersion, yay, thank worked! So: `VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/intel_icd.x86_64.json gamescope -- glxgears` launches on Intel card, thanks!
<emersion>
np
<emersion>
i think MESA_VK_DEVICE_SELECT only works if the mesa device select layer is enabled
<emersion>
which it isn't by default in general
gouchi has quit [Remote host closed the connection]
<Hi-Angel>
As a side note, skypeforlinux still uses the discrete card even with the variable 🤷♂️ Not sure how else could it do that, from my googling there's no way to choose device with OpenGL or EGL, so Vulkan was the only way… Weird.
<emersion>
there are ways to select the device with EGL
<emersion>
e.g. by using EGL_EXT_platform_device
<emersion>
there are also other APIs with other conventions
<emersion>
VA-API for instance…
<Hi-Angel>
Huh. Actually, even when running `VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/intel_icd.x86_64.json gamescope -- glxgears`, the AMD GPU wakes up as can be seen by `[drm] PCIE GART of 256M enabled (table at 0x000000F400000000)` entry in the log. Even though the `gamescope` definitely does *not* use the AMD GPU, because it shows visual artifacts on glxgears (a known bug in combination with Intel GPU) :/
<Hi-Angel>
emersion, thanks for mentioning `EXT_platform_device`! I'll leave a comment on two StackOverflow questions about choosing a GPU through means of OpenGL as currently nobody mentioned that
<emersion>
another way would be GBM then using the GBM platform
<emersion>
in both of these cases, i don't think there is an env var to override
LordKalma has quit [Quit: Server has probably crashed]
LordKalma has joined #dri-devel
LordKalma has quit [Remote host closed the connection]
LordKalma has joined #dri-devel
LordKalma has quit []
<FireBurn>
I usually use DRI_PRIME so select which gpu, and there's a MR to make selecting using the pci address work too
Leopold has quit [Remote host closed the connection]
kts has quit [Quit: Leaving]
Leopold has joined #dri-devel
<emersion>
DRI_PRIME works with regular EGL apps only, not in the other cases mentioned above
iive has joined #dri-devel
<FireBurn>
VA-API lets me use DRI_PRIME
<Hi-Angel>
emersion, the MR FireBurn mentioned makes DRI_PRIME work with Vulkan as well
<Hi-Angel>
If I'm not misreading it of course
<emersion>
that surprises me, i don't see any mention of DRI_PRIME in libva
<FireBurn>
It already works with Vulkan, it just improves it
<FireBurn>
I've been using DRI_PRIME since it's support was added many moons ago
<FireBurn>
emersion: You can test it with DRI_PRIME=0 vainfo and DRI_PRIME=1 vainfo, if the second card uses a different driver you might also have to specify it using LIBVA_DRIVER_NAME=
<FireBurn>
So if you're on an Intel/AMD setup DRI_PRIME=1 LIBVA_DRIVER_NAME=radeonsi vainfo should be enough
<emersion>
ah, then DRI_PRIME=1 doesn't actually do anything
<Hi-Angel>
FireBurn, does it already work with Vulkan? Can't seem to confirm: when I run a `DRI_PRIME=8086:5916 gamescope -- glxgears`, it makes use of AMD GPU instead of the Intel one that has VID:PID 8086:5916
<FireBurn>
On an AMD/AMD setup LIBVA_DRIVER_NAME shouldn't be necessary
<emersion>
LIBVA_DRIVER_NAME does all of the work
<FireBurn>
Try DRI_PRIME=0 or 1
<Hi-Angel>
DRI_PRIME=0 has same effect; however according to docs https://docs.mesa3d.org/envvars.html#envvar-DRI_PRIME the `0` actually does nothing. The `1` implies "run on AMD GPU" which is the default on my system (for some reason, Idk why)
<FireBurn>
Do you have the vulkan layer enabled?
<Hi-Angel>
(I meant, default for Vulkan apps, not OpenGL 🤷♂️)
<FireBurn>
This: -Dvulkan-layers=device-select enabled in Mesa
<Hi-Angel>
Oh, wow!
kzd has joined #dri-devel
<Hi-Angel>
FireBurn, I instealled mesa-vulkan-layers, and now it does work!
<Hi-Angel>
Cool
<FireBurn>
Great news
<Hi-Angel>
Yeah, that's quite a nuance that for that to work vulkan layers are needed. Probably worth adding that to the docs for DRI_PRIME
<Hi-Angel>
Btw, installing vulkan layers actually improved the default behavior on my system, because now `gamescope` defaults to the integrated card as it's supposed to (but DRI_PRIME does work, I tested PID:VID with the AMD GPU as well)
kts has joined #dri-devel
sarnex_ has quit []
sarnex has joined #dri-devel
warpme_____ has quit []
sarnex has quit [Read error: No route to host]
sarnex has joined #dri-devel
sarnex has quit [Read error: Connection reset by peer]
cef has quit [Ping timeout: 480 seconds]
ice99 has quit [Read error: Connection reset by peer]
sarnex has joined #dri-devel
sarnex_ has joined #dri-devel
sarnex has quit [Read error: Connection reset by peer]
FireBurn has quit [Quit: Konversation terminated!]
<DemiMarie>
What are the advantages of userspace direct-to-FW submission? Seems like it massively increases FW-side attack surface. I guess it makes sense on Windows, where the GPU FW and kernel driver are made by the same company and likely of similar quality, but on Linux the GPU driver gets a lot of review while the FW gets none.
lemonzest has quit [Quit: WeeChat 3.6]
junaid has joined #dri-devel
glennk has quit [Remote host closed the connection]
glennk has joined #dri-devel
Hi-Angel has quit [Ping timeout: 480 seconds]
<jekstrand>
DemiMarie: In theory, it should be faster and more power-efficient since the kernel doesn't have to burn as much main CPU time on juggling GPU work.
<DemiMarie>
jekstrand: in practice?
<jekstrand>
DemiMarie: In practice, it's still not incredibly well-proven.
<jekstrand>
What is pretty well-proven, though, is tha non-firmware-based HW interfaces suck.
<jekstrand>
But can we get 99% of the efficiency with the kernel still in the loop? Maybe.
<jekstrand>
As far as security goes, it shouldn't be that much more of an attack surface than your GPU as a whole.
<jekstrand>
Depends on the HW and FW design, of course.
<javierm>
jekstrand, DemiMarie: I always thought that was more about protecting the GPU companies IP while allowing to have open source kernel and GL/vulkan drivers
<bnieuwenhuizen>
jekstrand: benefit is that we finally have an impetus to get the fairly slow BO LRU handling out of the hot path. Submission performance has been pretty brutal
<DemiMarie>
jekstrand: why do you state that the attack surface should not be much more?
digetx has joined #dri-devel
Leopold__ has quit [Ping timeout: 480 seconds]
bluetail has joined #dri-devel
<bluetail>
Hello. I am on archlinux. I installed mesa-git, but when I want to update I get ":: installing llvm-libs (15.0.7-1) breaks dependency 'llvm-libs=14.0.6' required by mesa-git"
<psykose>
this sounds like an issue for whoever maintains the aur package you are installing
RSpliet has quit [Quit: Bye bye man, bye bye]
RSpliet has joined #dri-devel
<bluetail>
in this case, I can just try the immediate git package right?
gbelgurr has quit [Ping timeout: 480 seconds]
<bluetail>
wait, there are comments on how to use it from the AUR page... I have to read up on it
RSpliet has quit []
pcercuei has quit [Read error: Connection reset by peer]
RSpliet has joined #dri-devel
pcercuei has joined #dri-devel
Leopold_ has joined #dri-devel
RSpliet has quit []
RSpliet has joined #dri-devel
Haaninjo has joined #dri-devel
ice99 has joined #dri-devel
ice9 has quit [Read error: Connection reset by peer]
RSpliet has quit [Quit: Bye bye man, bye bye]
RSpliet has joined #dri-devel
* sravn
just spammed dri-devel with a 86 patch series of trivial header changes. Let's see if the bots hate the patches
Leopold_ has quit [Remote host closed the connection]
Leopold has joined #dri-devel
dviola has quit [Ping timeout: 480 seconds]
gbelgurr has joined #dri-devel
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
genpaku has quit [Remote host closed the connection]
genpaku has joined #dri-devel
<eric_engestrom>
bluetail: you need to update both llvm and mesa-git in the same transaction
<bluetail>
eric_engestrom my PKGBUILD was out of date. I removed mesa-git with pacman -Rdd mesa-git and then reinstalled from git
<eric_engestrom>
or that, uninstall+reinstall works too, but for mesa I wouldn't recommend that as you might end up without a GUI which a lot of users are not going to know how to fix ^^
RSpliet has quit [Quit: Bye bye man, bye bye]
RSpliet has joined #dri-devel
Leopold has quit [Remote host closed the connection]
dviola has joined #dri-devel
RSpliet has quit []
RSpliet has joined #dri-devel
Leopold has joined #dri-devel
danvet has joined #dri-devel
agd5f_ has joined #dri-devel
RSpliet has quit [Quit: Bye bye man, bye bye]
RSpliet has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
jluthra has quit [Remote host closed the connection]
jluthra has joined #dri-devel
RSpliet has quit [Quit: Bye bye man, bye bye]
RSpliet has joined #dri-devel
gouchi has quit [Remote host closed the connection]
RSpliet has quit []
RSpliet has joined #dri-devel
Leopold_ has joined #dri-devel
junaid has quit [Ping timeout: 480 seconds]
Leopold has quit []
Haaninjo has quit [Quit: Ex-Chat]
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
RSpliet has quit [Quit: Bye bye man, bye bye]
RSpliet has joined #dri-devel
ice99 has quit [Ping timeout: 480 seconds]
djbw has joined #dri-devel
agd5f has joined #dri-devel
RSpliet has quit [Quit: Bye bye man, bye bye]
RSpliet has joined #dri-devel
bgs has quit [Remote host closed the connection]
agd5f_ has quit [Ping timeout: 480 seconds]
Venemo has quit [Remote host closed the connection]
Venemo has joined #dri-devel
RSpliet has quit [Quit: Bye bye man, bye bye]
RSpliet has joined #dri-devel
HerrSpliet has joined #dri-devel
RSpliet has quit [Ping timeout: 480 seconds]
<jekstrand>
bnieuwenhuizen: Yeah, I'm not convinced Intel's GuC is really any faster, either.
<jekstrand>
bnieuwenhuizen: It may be faster doing it kernel-side on Windows where there's more abstractions to punch through to handle an interrupt. On Linux, I'm unconvinced that it should be any faster.
<jekstrand>
But the execlist submission ports are a pretty bad HW design so not having to mess about with those is pretty nice.
<jekstrand>
I'm personally inclined to think that FW submission isn't what really matters. One core on your desktop CPU is going to be way faster than whatever that firmware is running on.
srslypascal has joined #dri-devel
RSpliet has joined #dri-devel
HerrSpliet has quit [Ping timeout: 480 seconds]
Leopold__ has joined #dri-devel
Leopold_ has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
pret7 has joined #dri-devel
cef has quit [Remote host closed the connection]
<bnieuwenhuizen>
jekstrand: I dunno, on AMD the direct-to-fw path seems to be pretty much the same as the kernel-to-fw path, so to me it looks like we save kernel costs while not really adding any FW cost
fab has quit [Quit: fab]
cef has joined #dri-devel
JohnnyonFlame has joined #dri-devel
JohnnyonF has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<jekstrand>
bnieuwenhuizen: Yup. The question is how much cost is being saved. IDK that it's much once we get kernel submit to be non-stupid.
<bnieuwenhuizen>
jekstrand: once we add in some virtualization?
<bnieuwenhuizen>
I hear those VM calls are expensive
<jekstrand>
bnieuwenhuizen: Yeah, for virtualization it's a pretty clear win
<jekstrand>
Though I think we can get kernel submit a lot better there with work
<bnieuwenhuizen>
granted I dunno how we end up doing sync primitives
<jekstrand>
UMF
<bnieuwenhuizen>
yeah, somehow UMF seems a lot farther away than direct-to-fw submissions
<bnieuwenhuizen>
though if it were me we'd just do the timeout thing and allow making sync files out of them
<jekstrand>
I'm hoping UMF is in the 2-4 years timeframe.
danvet has quit [Ping timeout: 480 seconds]
<bnieuwenhuizen>
yeah, some of the stuff I've been seeing from the amdgpu team have me hoping/dreaming for direct-to-fw this year :)
<bnieuwenhuizen>
which leaves the question what happens for sync in the interim
<LaserEyess>
https://gitlab.freedesktop.org/drm/amd/-/issues/476 consensus from AMD in this issue is that adding a patch to default to RGB would not be acceptable and they want to do things "properly" by adding a DRM parameter, exposing it to userspace via libdrm, and then having compositors handle the details of setting it
<LaserEyess>
however, there doesn't seem to be any information if people are working on this or not
<LaserEyess>
is there an active mailing list thread about this issue and/or a patch that implements some sort of solution to this?
<LaserEyess>
valve seems to have used the patch in that thread (or something similar) to make this work on the steam deck, so presumably someone has done some work to figure this out "properly", but I can't really find it
<jekstrand>
bnieuwenhuizen: With out UMF, they're going to be dissapointed. :)
<bnieuwenhuizen>
note that in amdgpu we kinda have UMF already
<bnieuwenhuizen>
or really (context, queue, submission seq id) pairs that get signalled to memory if we want to
<airlied>
I saw some userspace submit patches from amd for gfx recently? but didn't dig in
<airlied>
bnieuwenhuizen: do they just unmap the doorbell page when the VM invalidates?
<bnieuwenhuizen>
yeah looked like
<bnieuwenhuizen>
not sure I understand how that works exactly
<airlied>
would be fun if you have the two 51% vram users
<airlied>
I wonder how you'd guarantee any forward progress there
<airlied>
like by the time you get to submit a command stream from userspace the other process could have unmapped your page, and around it goes
<bnieuwenhuizen>
note the kernel can still spill to gtt and then enable the VM again