<airlied>
dcbaker: also I tried using some of the cmake path env vars to pick up the cmake files from one of my llvm installs, and I didn't make that work
gildekel has quit [Quit: Connection closed for inactivity]
karolherbst_ has joined #dri-devel
karolherbst has quit [Ping timeout: 480 seconds]
crabbedhaloablut has joined #dri-devel
Daanct12 has quit [Quit: WeeChat 4.0.4]
Daanct12 has joined #dri-devel
youmukon1 has joined #dri-devel
youmukonpaku1337 has quit [Read error: Connection reset by peer]
yyds_ has quit [Quit: Lost terminal]
yyds has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
yyds has quit [Quit: Lost terminal]
yyds has joined #dri-devel
ayaka_ has quit [Remote host closed the connection]
yyds has quit []
ayaka_ has joined #dri-devel
yyds has joined #dri-devel
yyds has quit []
yyds has joined #dri-devel
<mareko>
"This patch is trying to acheive feature parity between config-tool searching of LLVM and CMake-based one, which is arch-agnostic." - so that's why cmake is trying link a 64-bit mesa with 32-bit llvm, it's "arch-agnostic"
<mareko>
they can't fail more than that
sukrutb has quit [Ping timeout: 480 seconds]
youmukonpaku1337 has joined #dri-devel
youmukon1 has quit [Read error: Connection reset by peer]
yyds has quit [Quit: Lost terminal]
yyds has joined #dri-devel
youmukonpaku1337 has quit [Remote host closed the connection]
youmukonpaku1337 has joined #dri-devel
aravind has joined #dri-devel
epony has quit [Remote host closed the connection]
epony has joined #dri-devel
youmukonpaku1337 has quit [Remote host closed the connection]
youmukonpaku1337 has joined #dri-devel
ayaka_ has quit [Ping timeout: 480 seconds]
kzd has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
Duke`` has joined #dri-devel
youmukonpaku1337 has quit [Remote host closed the connection]
youmukonpaku1337 has joined #dri-devel
sukrutb has joined #dri-devel
antoniospg has quit [Quit: Connection closed for inactivity]
serjosna has joined #dri-devel
bmodem has joined #dri-devel
tzimmermann has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
ayaka_ has joined #dri-devel
i-garrison has quit []
i-garrison has joined #dri-devel
youmukonpaku1337 has quit [Remote host closed the connection]
youmukonpaku1337 has joined #dri-devel
sima has joined #dri-devel
itoral has joined #dri-devel
bmodem has quit [Quit: bmodem]
bmodem has joined #dri-devel
yyds has quit [Quit: Lost terminal]
yyds has joined #dri-devel
yyds has quit []
yyds has joined #dri-devel
ayaka_ has quit [Remote host closed the connection]
ayaka_ has joined #dri-devel
yyds has quit []
youmukonpaku1337 has quit [Ping timeout: 480 seconds]
yyds has joined #dri-devel
yyds has quit []
yyds has joined #dri-devel
yyds has quit [Remote host closed the connection]
fab has quit [Quit: fab]
yyds has joined #dri-devel
yyds has quit [Remote host closed the connection]
yyds has joined #dri-devel
Company has joined #dri-devel
yyds has quit [Remote host closed the connection]
yyds has joined #dri-devel
rasterman has joined #dri-devel
yyds has quit [Quit: Lost terminal]
yyds has joined #dri-devel
yyds has quit []
yyds has joined #dri-devel
yyds has quit []
yyds has joined #dri-devel
ayaka_ has quit [Ping timeout: 480 seconds]
yyds has quit []
yyds has joined #dri-devel
ayaka_ has joined #dri-devel
fab has joined #dri-devel
yyds has quit [Quit: Lost terminal]
mszyprow has joined #dri-devel
yyds has joined #dri-devel
yyds has quit []
yyds has joined #dri-devel
yyds has quit []
yyds has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
yyds has quit [Quit: Lost terminal]
yyds has joined #dri-devel
jkrzyszt has joined #dri-devel
tristan has joined #dri-devel
tristan is now known as Guest1314
thellstrom has joined #dri-devel
<serjosna>
what we found out is just amazing, like whoa, i really made it through all riddles finally! It turns out that gpio from cpu and dma writes are different in terms of dma parameter loading, internal dma can corrupt the condition, cause it thought it already decremented the count, but it's adjusted back on. But as the descriptor moves ahead contiguously it hits the condition where full addition is made without transferring any bytes. so they have
<serjosna>
super computers yeah, what i was really expecting when they sell that technology onto people doorstep. I am also shocking dummy at times.
Ahuj has joined #dri-devel
pekkari has joined #dri-devel
apinheiro has joined #dri-devel
vliaskov has joined #dri-devel
<serjosna>
currently i am just looking at the best way to expose subtract as minor addition of functionality to cornell pic32 , other stuff i know it leads to success entire success, there is maybe some other method than changing the addressing mode to decremental.
pcercuei has joined #dri-devel
frankbinns has quit [Remote host closed the connection]
An0num0us has joined #dri-devel
dviola has quit [Quit: WeeChat 4.0.4]
anujp has quit [Ping timeout: 480 seconds]
<serjosna>
provided that likely dma hardware reinits internal registers flushes/invalidates, there is maybe such way, depending on where in the pipeline it is, mark nbytes as bigger than source size and byte mask all the results out, than it must do some early skipping on the chip, currently searching for such pointers from the web
lynxeye has joined #dri-devel
anujp has joined #dri-devel
swalker_ has joined #dri-devel
swalker_ is now known as Guest1319
swalker__ has joined #dri-devel
frankbinns has joined #dri-devel
serjosna was kicked from #dri-devel by ChanServ [You are not permitted on this channel]
Guest1319 has quit [Ping timeout: 480 seconds]
pekkari has quit [Quit: Konversation terminated!]
djbw has quit [Read error: Connection reset by peer]
jkrzyszt has quit [Remote host closed the connection]
mvlad has joined #dri-devel
thellstrom1 has joined #dri-devel
Guest1314 has quit [Ping timeout: 480 seconds]
thellstrom has quit [Ping timeout: 480 seconds]
<pq>
MrCooper, my question about hiding pipelines was explicitly about the all-blob design. We already have a solution more or less for the new KMS object type design. The all-blob proposal said nothing about it.
donaldrobson has joined #dri-devel
<pq>
swick[m], my issue about the adding props question is adding a new prop to an existing and otherwise understood colorop. IMO, userspace cannot use a colorop (must be bypassed or not present) if userspace does not understand all props it has.
<pq>
emersion, I don't think new props on an otherwise known colorop can be ignored, who knows what state they are in, or what it did before the prop was added. Do you have a solution to that? I *really* do not want to fall into the "same as other KMS props" horrors.
<pq>
emersion, actually, "the same as other KMS props" solution is the same: do no use a pipeline at all, if it has any detail you don't understand.
<pq>
it all seems to converge on the same rules even when we are not "solving" the "trash in unknown properties" problem.
ayaka_ has quit [Remote host closed the connection]
ayaka_ has joined #dri-devel
apinheiro has quit [Ping timeout: 480 seconds]
<pq>
all this means that adding a new prop into an old colorop would stop userspace from using that colorop, meaning it's practically equivalent to a whole new colorop if it had users relying on it.
ayaka_ has quit [Remote host closed the connection]
ayaka_ has joined #dri-devel
sgruszka has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
tristan has joined #dri-devel
dviola has joined #dri-devel
tristan is now known as Guest1323
thellstrom1 has quit [Ping timeout: 480 seconds]
<dottedmag>
Is there any syscall that returns sync_file unrelated to any dma-buf buffer? Or are all sync_files available to userspace always originate from a buffer and obtained using DMA_BUF_IOCTL_EXPORT_SYNC?
hansg has joined #dri-devel
aravind has joined #dri-devel
<sima>
dottedmag, atomic display ioctl and many execbuf/comman submission ioctl can return a sync_file too
<dottedmag>
sima: thanks
<sima>
dottedmag, you can also use sync_file to get fences in/out of drm_syncobj
<dottedmag>
sima: aha, this is the next piece of puzzle I was going to untangle, thanks
Company has quit [Ping timeout: 480 seconds]
youmukonpaku1337 has joined #dri-devel
Company has joined #dri-devel
cmichael has joined #dri-devel
<swick[m]>
pq: I think in general you're right. Read-only props are one exception. Otherwise, we would need that reset mechanism.
<pq>
swick[m], read-only props are not obviously harmless. Someone might try to use a read-only prop to squash two different ops into a single colorop type.
<pq>
That should be stopped at kernel patch review, but...
<swick[m]>
yeah, was gonna say, that's true, but we should not allow stuff like this in the first place
<pq>
what if a read-only prop is added for hardware that does the original operation, but with reduced precision? which might not satisfy old userspace
<swick[m]>
so we could make a guarantee that read-only props must not introduce incompatibility
<swick[m]>
I would say: not allowed, needs a new op type
<pq>
I wonder, what kind of detail userspace would be interested to know, but also cannot cause incompatibility?
<swick[m]>
but yes, you're right, it's not generally true that any read-only prop is harmless
frieder has joined #dri-devel
<pq>
...maybe something like a LUT that allows more sizes than usual
<swick[m]>
we really have to write all of that down and think about it hard
youmukon1 has joined #dri-devel
<pq>
or flags increased precision
<swick[m]>
well, if precision was unspecified and then gets specified with a r/o thing
<swick[m]>
anything that exposes more information that was previously unspecified basically
<pq>
for userspace that wants to be more picky than it previously could, yeah
youmukonpaku1337 has quit [Read error: Connection reset by peer]
Guest1323 has quit [Ping timeout: 480 seconds]
slattann has joined #dri-devel
ayaka_ has quit [Ping timeout: 480 seconds]
alyssa has left #dri-devel [#dri-devel]
karolherbst_ is now known as karolherbst
slattann has quit [Read error: Connection reset by peer]
slattann has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
mauld has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
itoral has quit [Quit: Leaving]
youmukon1 is now known as youmukonpaku1337
mauld has joined #dri-devel
slattann has quit [Read error: Connection reset by peer]
bmodem has quit [Ping timeout: 480 seconds]
slattann has joined #dri-devel
fab has quit [Quit: fab]
tristan has joined #dri-devel
tristan is now known as Guest1339
shashanks has joined #dri-devel
koike has joined #dri-devel
koike is now known as Guest1341
f11f12 has joined #dri-devel
sgruszka has quit [Remote host closed the connection]
shashanks has quit [Remote host closed the connection]
alyssa has joined #dri-devel
andrjohns has joined #dri-devel
andrjohns has left #dri-devel [#dri-devel]
Guest1341 is now known as koike
milek7 has joined #dri-devel
koike is now known as koike-lounge
koike has joined #dri-devel
Daanct12 has quit [Quit: WeeChat 4.0.4]
yyds has quit [Remote host closed the connection]
<zmike>
anyone know how I get an xserver instance to pick a different libGLX? glvnd seems to always load my system install
<MrCooper>
different filename, or just different path?
<zmike>
path
<zmike>
it's using /usr/ prefix and I want it to use /usr/local
<MrCooper>
LD_LIBRARY_PATH then?
<zmike>
tried that and it doesn't work
<MrCooper>
did you double-check that the Xorg process picked up the envvar?
alyssa has left #dri-devel [#dri-devel]
hansg has quit [Remote host closed the connection]
<zmike>
hmm
<zmike>
indeed it doesn't seem to be
<zmike>
not sure what to do about that if it's getting sanitized out by the loader scripts
<pq>
is it not sanitized out by setuid-root bits?
<pq>
do you actually need Xorg, or could e.g. Xwayland do?
mszyprow has quit [Ping timeout: 480 seconds]
<zmike>
I can't get a functional wayland system compositor to start on this machine for various reasons, so I'm working with what I've got
<pq>
would headless do?
koike-lounge has quit []
<zmike>
ideally not
klounge has joined #dri-devel
<pq>
on my machine, /usr/bin/Xorg seems to be a script that launches /usr/lib/xorg/Xorg.wrap which is set-gid root. Maybe that explains why LD_LIBRARY_PATH is dropped.
<pq>
or moving Xorg.wrap out or poking the script, assuming you don't actually need root
fab has joined #dri-devel
hansg has joined #dri-devel
hansg has quit []
<zmike>
oh ho
<zmike>
I think that did it
<zmike>
yea it did, thanks
Guest1339 has quit [Ping timeout: 480 seconds]
gildekel has joined #dri-devel
<MrCooper>
I'd argue that if /usr/local/lib* doesn't take precedence over /usr/lib*, the system is broken
<zmike>
shrug
<zmike>
pretty close to stock fedora
<zmike>
who can say
<MrCooper>
indeed, I added /etc/ld.so.conf.d/aa_local.conf for this
tristan has joined #dri-devel
tristan is now known as Guest1345
Manas has joined #dri-devel
guru_ has joined #dri-devel
sukrutb has quit [Ping timeout: 480 seconds]
oneforall2 has quit [Ping timeout: 480 seconds]
slattann has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
<emersion>
pq, i don't really agree, but am on leave rn, so won't reply
rasterman has quit [Quit: Gettin' stinky!]
<pq>
better to continue in email anyway
guru_ has quit [Ping timeout: 480 seconds]
nuclearcat2 has joined #dri-devel
mauld has quit [Ping timeout: 480 seconds]
An0num0us has quit [Ping timeout: 480 seconds]
rz_ has joined #dri-devel
rz_ has quit []
fab has quit [Ping timeout: 480 seconds]
rz has joined #dri-devel
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
rz has quit []
rz has joined #dri-devel
jewins has joined #dri-devel
Haaninjo has joined #dri-devel
mauld has joined #dri-devel
rz has quit [Quit: rz]
rz has joined #dri-devel
mauld has quit []
rz has quit []
rz has joined #dri-devel
<austriancoder>
is/should pep8 be used for python files in mesa?
kzd has joined #dri-devel
<koike>
austriancoder: we should have checks in the lint stage, let me see
yyds has joined #dri-devel
<zmike>
MrCooper: probably a q for you: why does my system refuse to use wayland for any of its sessions?
<zmike>
gdm uses xorg and even the default gnome session uses xorg
fab has joined #dri-devel
<koike>
austriancoder: looks like we don't, but if you grep for pep you can see a few comments on docs/relnotes, so I guess so
rz has quit [Quit: rz]
<austriancoder>
koike: 👍🏻
rz has joined #dri-devel
rz has quit []
<hakzsam>
to simplify some code in RADV, I would like to use sync2 in wsi but not all drivers seem to support it (like pvr). Would it be OK to use sync2 conditionally in WSI?
Ahuj has quit [Ping timeout: 480 seconds]
Guest1345 has quit [Ping timeout: 480 seconds]
youmukonpaku1337 has quit [Remote host closed the connection]
youmukonpaku1337 has joined #dri-devel
tristan has joined #dri-devel
yuq825 has left #dri-devel [#dri-devel]
tristan is now known as Guest1348
youmukonpaku1337 has quit [Remote host closed the connection]
youmukonpaku1337 has joined #dri-devel
<MrCooper>
zmike: usually it's because gnome-shell fails to come up in Wayland mode for some reason; I'd look for gnome-shell messages in "journalctl -b0"
<zmike>
looks like 'Running GNOME Shell (using mutter 44.3) as a X11 window and compositing manager' is the first message I get
Duke`` has joined #dri-devel
<MrCooper>
zmike: is the `WaylandEnable=false` line in /etc/gdm/custom.conf uncommented perhaps? Or is there an Nvidia GPU in the system?
<zmike>
no and no
<zmike>
I even set that option to true just to check
<MrCooper>
weird; in a VT console, does "dbus-run-session gnome-shell --wayland" work?
<zmike>
"unsupported session type"
<zmike>
is it not installed by default?
<zmike>
I thought it was at this point
youmukonpaku1337 has quit [Remote host closed the connection]
youmukonpaku1337 has joined #dri-devel
hansg has joined #dri-devel
<MrCooper>
certainly is
<MrCooper>
hmm, I can only find that string in Firefox/Thunderbird's libxul, so it might be a red herring; try redirecting stdout+stderr to a file
<zmike>
stdout+stderr from dbus-run-session?
<MrCooper>
yes
<zmike>
it's just that one line
<MrCooper>
huh, how about just "mutter --wayland" ?
<MrCooper>
(without dbus-run-session)
<zmike>
seems like it worked?
<zmike>
yeah I can launch stuff into it from ssh
<zmike>
that's good enough for me
<MrCooper>
k, so there's something weird with dbus-run-session on your system, not sure it's directly related to the original issue though
<zmike>
I just wanted some kind of wayland system compositor to run for testing, so this solves that problem
<zmike>
thanks for the ideas
<MrCooper>
no worries
<MrCooper>
FWIW, my grep failed because the string in mutter is "Unsupported session type"
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
jewins has quit [Ping timeout: 480 seconds]
<MrCooper>
zmike: in that VT console, does 'echo $XDG_SESSION_TYPE' print anything?
<zmike>
tty
danylo has quit [Quit: Ping timeout (120 seconds)]
danylo has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
<MrCooper>
k, not sure what's going on there :/
<MrCooper>
zmike: jadahl might be able to tell more if you show him the output of journalctl -b0
<zmike>
it seems to work fine on another machine I have here, so I'm gonna assume this one is just broken somehow
<zmike>
it's a test machine and I'm not too upset
djbw has joined #dri-devel
jewins has joined #dri-devel
<MrCooper>
yeah, my best guess is that maybe some environment variable is hardcoded system wide and messes up things
<jadahl>
that env var should be set by systemd or logind or something
<jadahl>
or no, it shouldn 't even be set IIRC
<jadahl>
it's something used to override what systemd tells us
<Company>
question for the nvidia experts: When I'm doing Vulkan stuff and my shader does invalid memory accesses, AMD GPUs reset themselves and take down my compositor and force me to reboot, while Intel just shrugs and I get VK_ERROR_DEVICE_LOST
<Company>
which makes Intel a lot less catastrophic to work with
<Company>
where is nvidia hardware on that spectrum?
<MrCooper>
jadahl: FWIW, a VT shell on F38 has $XDG_SESSION_TYPE=tty for me as well, and 'dbus-run-session gnome-shell --wayland' works
frieder has quit [Remote host closed the connection]
<jadahl>
MrCooper: interesting!
<jadahl>
I probably dreamt that it wasn't a real thing then
lynxeye has quit [Quit: Leaving.]
<zmike>
nvidia usually recovers fine
vliaskov_ has joined #dri-devel
vliaskov has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
kzd has quit [Quit: kzd]
Guest1348 has quit [Ping timeout: 480 seconds]
swalker__ has quit [Remote host closed the connection]
aravind has joined #dri-devel
yyds has quit [Remote host closed the connection]
bmodem has joined #dri-devel
An0num0us has joined #dri-devel
donaldrobson has quit [Ping timeout: 480 seconds]
<karolherbst>
on nvidia you just need a new context and everything is fine
<karolherbst>
they have hardware level isolation and all that stuff, even the VM is independent from the allocated GPU context
<karolherbst>
so on the driver level, you can allocate a new context and keep all your memory even and just continue (in theory)
<karolherbst>
there are some rare cases where the nvidia driver can't recover from a GPU fault
<karolherbst>
anyway, don't take AMD as a baseline for GPU recovery, they are afaik the worst in this regard across the big players
<Company>
I was mainly asking that question to judge which GPUs to recommend to other developers
<Company>
who want to work with Vulkan stuff
<karolherbst>
if you are risking crashing the GPU a lot, then I'd advise to not use AMD
<Company>
I guess for now nvidia isn't the best choice anyway because Mesa doesn't support it well
<karolherbst>
mhh yeah, that's fair
<Company>
yeah, but if you want to make sure your code is solid, test it on AMD
<karolherbst>
intel is solid enough, never had any issue with the driver (- some kernel data race which I've fixed) while hacking on OpenCL on the harwdare
<karolherbst>
yeah, testing should definetly be done on all relevant GPU drivers
<karolherbst>
just the developer experience isn't the greatest
<karolherbst>
it's very unfortunate, but that's how it is
<karolherbst>
and nothing the driver team can do much about as that's mostly due to lack on the hardware side
<Company>
yeah
<Company>
just good to know in advance when somebody asks
<Company>
as there's more and more stuff happening on the lower layers around gnome
<karolherbst>
nvidia is really good on the hardware side here as they have strong isolation between GPU contexts and normally you only have to remove the faulty one and all the others can continue their job
<Company>
with GTK4 going GL and Cairo being on its way out
<karolherbst>
yeah, fair
<Company>
most of the stuff that's happening so far is people trying to pass images around
<Company>
like the virtio stuff that the spice people have been doing
<Company>
or various video stuff with pipewire/gstreamer
<Company>
and there's a few custom shaders, but that's usually just simple copy/paste from shadertoy
anujp has quit [Ping timeout: 480 seconds]
anujp has joined #dri-devel
idr has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 480 seconds]
cmichael has quit [Quit: Leaving]
Manas has quit [Read error: Connection reset by peer]
i509vcb has quit [Quit: Connection closed for inactivity]
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
bmodem has quit [Excess Flood]
bmodem has joined #dri-devel
sukrutb has joined #dri-devel
junaid has joined #dri-devel
anujp has quit [Ping timeout: 480 seconds]
anujp has joined #dri-devel
<Lynne>
while working on the vulkan video stuff there was a time I was doing 20 reboots a day on my main and only system, this was not fun
<Lynne>
airlied: did you get a 7900?
kzd has joined #dri-devel
f11f12 has quit [Quit: Leaving]
<Company>
Lynne: a thing I did onmy desktop is get a ryzen with embedded GPU - so theoretically I have 2 GPUs in this thing, but I'm not sure how well it isolates the GPUs
<Company>
it works when I do stuff that causes OOMs or (near) infinite loops - I can keep using my box while the other one goes bad
hansg has quit [Quit: Leaving]
<Company>
but I feel like the memory sharing between the GPUs causes instabilities
i509vcb has joined #dri-devel
mszyprow has joined #dri-devel
mvlad has quit [Remote host closed the connection]
youmukonpaku1337 has quit [Remote host closed the connection]
youmukonpaku1337 has joined #dri-devel
oneforall2 has joined #dri-devel
idr has joined #dri-devel
ManMower has joined #dri-devel
oneforall2 has quit [Ping timeout: 480 seconds]
rz has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
<airlied>
Lynne: it's in the same country as me at least
Kayden has quit [Quit: -> lunch]
bmodem has quit [Ping timeout: 480 seconds]
<DemiMarie>
karolherbst: how good is Intel regarding isolation?
<karolherbst>
no idea
<DemiMarie>
suggestions for who to ask?
<karolherbst>
maybe to people on #intel-gfx or #intel-3d?
<dj-death>
DemiMarie: there is an actual set of pagetables per graphics context (usually)
mszyprow has quit [Ping timeout: 480 seconds]
<dj-death>
DemiMarie: so it's kind of hard to overwrite another process' data
<dj-death>
DemiMarie: that's on Broadwell+ only
<DemiMarie>
dj-death: what about registers and other state? is that flushed between contexts?
<agd5f>
memory isolation works fine on AMD as well since SI when we got vmid support. What's problematic is when you have multiple jobs executing on the GPU at the same time. If you have to reset the 3D engine, you lose the engine state for all processes that have jobs on that engine when it gets reset. That largely gets solved with per process queues (like ROCm uses today).
<dj-death>
DemiMarie: it should
<dj-death>
DemiMarie: we tend to get workaround where things don't work as expected
<dj-death>
DemiMarie: but it's not so much the state leaking as the HW hanging so...
<Lynne>
airlied: my opinion is that until the doorbell rings, it's on the moon
crabbedhaloablut has quit []
<DemiMarie>
dj-death: Are those workarounds enforced by the kernel to prevent cross-process information leak? HW hanging is “just” denial of service, which is not great but also not necessarily a complete dealbreaker.
<DemiMarie>
agd5f: why does graphics not use per process queues?
<dj-death>
DemiMarie: it's all over, part kernel part userspace driver
<DemiMarie>
dj-death: that is potentially a problem, then
<agd5f>
DemiMarie, they didn't exist until rdna3
<mattst88>
if, hypothetically, the answer was "isolation is terrible and everything is broken", what would you do with that information?
<mattst88>
(I don't understand the purpose of the questions)
<dj-death>
DemiMarie: given what I just read on this channel, it's a problem everywhere :)
<DemiMarie>
mattst88: trying to figure out if Qubes OS will ever be able to enable GPU acceleration, because GTK4 performance without it is garbage and the GTK4 developers are not interested in improving it.
<dj-death>
DemiMarie: if you expect a userspace driver not to be able to hang the HW, I think you can forget about any GPU stuff
<karolherbst>
"hanging" the machine is mostly just a question of how quickly you want to reap misbehaving jobs (stuck in an infinite loop) though
<DemiMarie>
dj-death: are you saying that GPUs do not have instruction-level preemption? Again, hangs are just denial of service, which while not great is not something Qubes OS would need to issue a security bulletin for. Information leaks and privilege escalation are.
<karolherbst>
DemiMarie: no GPU has it for evertyhinng
<karolherbst>
and instruction level preemption is quite expensive
<DemiMarie>
karolherbst: why do GPUs not have instruction-level preemption?
<karolherbst>
because it's a huge perf hit
<agd5f>
DemiMarie, they do for compute, but not for other engines like GFX and multimedia
<DemiMarie>
how big?
<DemiMarie>
do they have it for compute at least?
<agd5f>
fixed function hardware is the issue
<karolherbst>
yeah, for compute that's easier to do
<DemiMarie>
agd5f: multimedia I don’t care one iota about
<karolherbst>
and modern GPUs generally support it, at least I know that Nvidia (and also AMD?) supports it in compute
<agd5f>
yeah, with ROCm you can debug in gdb and single step through GPU programs
<mattst88>
"how big?" -- impossible to answer
<karolherbst>
but yeah.. it's mostly a debugging feature
<karolherbst>
though I guess for qubes OS it could be enabled always if it's an issue
<karolherbst>
just makes it slower
<karolherbst>
but processes can also DOS the machine by OOMing it
oneforall2 has joined #dri-devel
<DemiMarie>
otherwise the answer is likely to be “blow the context away, file bugs against the software that can’t handle a GPU reset, and ban that VM from using GPU acceleration until the user says otherwise”
<DemiMarie>
karolherbst: isn’t it also needed for memory management for long running compute workloads?
<karolherbst>
you just configure proper thresholds so you won't notice
<DemiMarie>
bingo
<karolherbst>
you could kill stuck jobs after one second and see if it's good enough
<karolherbst>
or something
<agd5f>
DemiMarie, yeah, that's why it's table stacks for ROCm. For GFX, the extra die area is too big a tradeoff for performance
<karolherbst>
I would honestly not worry too much about preemption and hanging the machine, that's always something you can let users decide how critical they thing it is
<karolherbst>
information leaks on the other hand are more critical :)
<DemiMarie>
karolherbst: exactly!
<DemiMarie>
hence why I need to know if the kernel enforces state clearing at GPU context switch, and if not, what would be needed
<DemiMarie>
IIUC this was the infamous “iGPU leak” bug
jani has quit []
jani has joined #dri-devel
<karolherbst>
I think the problem you are having is, that you can't rely on any userspace bits, so if context switching requires userspace to play nice in order to not leak information you kinda can't use it. I don't know if intel is _that_ terrible, but "involves userspace" is kinda a red flag (probably)
jani has quit []
antoniospg has joined #dri-devel
<karolherbst>
but not sure what was meant with that precisly
jani has joined #dri-devel
youmukonpaku1337 has quit [Remote host closed the connection]
youmukonpaku1337 has joined #dri-devel
oneforall2 has quit [Read error: No route to host]
jani has quit []
jani has joined #dri-devel
jani has quit []
youmukonpaku1337 has quit [Remote host closed the connection]
youmukonpaku1337 has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
gouchi has joined #dri-devel
junaid has quit [Remote host closed the connection]
jani has joined #dri-devel
jani has quit []
jani has joined #dri-devel
<gfxstrand>
Anyone familiar with deqp-runner: Does it support the multi-level testlists?
sima has quit [Ping timeout: 480 seconds]
<gfxstrand>
The Vulkan CTS no longer has everything in deqp-vk-defaul.txt and that's now just a reference to a bunch of other .txt files
<Sachiel>
gfxstrand: deqp-runner works fine with that
<gfxstrand>
Okay. I just re-built, maybe that'll fix it
<Sachiel>
yeah, it needed fixing but it was done a while ago
<gfxstrand>
Okay. I don't think I've pulled in a wahile
pa- has joined #dri-devel
pa has quit [Ping timeout: 480 seconds]
Kayden has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
oneforall2 has joined #dri-devel
alyssa has joined #dri-devel
<gfxstrand>
Sachiel: I'm seeing piles of "Failure getting run results: No results parsed. Is your caselist out of sync with your deqp binary?"
<gfxstrand>
Sachiel: I've never seen so many before
<alyssa>
mattst88: I'd like to use intel_clc-like stuff for non-Intel drivers .. not sure I have a question yet but this relates with !24983
<Sachiel>
gfxstrand: cts main by any chance?
<gfxstrand>
But also I just updated my deqp like 2 hours ago
<gfxstrand>
Sachiel: Yeah
<gfxstrand>
Sachiel: Do I need to "build" the caselist or somethign?