ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<Company>
if somebody comes with some closed source game where the Vulkan renderer performs much worse on some GPU than the GL renderer, how would you guys debug why?
kzd has quit [Quit: kzd]
<HdkR>
profiling
<Company>
oh yeah: I'm assuming the GPU load is different
<HdkR>
Profile CPU and GPU time, see where the bottleneck is. Then make it go faster
<Company>
what GPU profiling tools do you use?
<airlied>
Company: do you have evidence the games vulkan renderer is faster on other drivers?
<airlied>
but yeah probably try and narrow down a frame that is slower and use renderdoc
<Company>
the question is a big vague because what I'm trying to do is understand better how GPUs work by learning about what parts of my code could be improved
<Company>
to be faster on GPUs
<Company>
in concrete: I've been working on my own (Vulkan) renderer for GTK, mostly for experimenting and prototyping fancy features
kzd has joined #dri-devel
<Company>
and then there's GTK's GL renderer, which is solid, fast, but works entirely different than mine
<Company>
and on this particular test, mine is 3x slower (200 vs 650fps)
<Company>
but it's only 50% CPU load
<Company>
and now I'm trying to understand what I do different that might take 3x longer on the GPU
<Company>
am I batching wrong? Are my memory barriers wrong? Should I order stuff differently, stuff like that
<Company>
or is it just that the Intel Vulkan stuff is slower than the GL stuff for what GTK is doing?
<airlied>
you are probably at the point where getting another gpu involved might be useful
<airlied>
not sure renderdoc would work with gtk though, it's pretty frame based
<Company>
it does (well, apart from me using fancy new Vulkan extensions atm)
<Company>
which might also contribute to the problem
<airlied>
so you'd probably want to use renderdoc to get some timings from that test, another option might be to see how it works on zink
<Company>
zink is at 300fps, I tried that
<airlied>
but yeah getting comparison timings from another driver platform (radv/nvidia) might be another tactic
<Company>
I should do that - I work on my laptop usually, but have an AMD gaming desktop right here
<Company>
renderdoc is not in Fedora, right?
<airlied>
not that I know off
<Company>
so you guys compile it from git?
<Company>
I did that and it works fine, but I'm wondeirng if there's config flags or something I should know about
<Company>
and distro packages would usually have them turned on already
<zmike>
always build renderdoc from git
Jack has joined #dri-devel
<airlied>
yeah I think that is the advice I normally get, always build from git
Jack is now known as cornelius
penguin42 has quit [Remote host closed the connection]
<cornelius>
So I'm a fedora user who's trying to diagnose and issue:
<cornelius>
I'm having an issue with what I think it the latest amdgpu drivers from Mesa. I'm using SteamVR to run my Valve Index and it has an issue where if the headset disconnects the system hard locks up. Like I can't use ctrl+alt+f3/4/5/etc to switch to tty. Even just typing in my login information, as if the display just isn't working does not work.
<cornelius>
I also have a similar issue with OBS, using it's replay feature to let me record the last five minutes, causing crashes too. I occasionally get problem reports from ABRT reporter. 9 times out of 10 the "reason" listed will be:
<cornelius>
WARNING: CPU: 6 PID: 5583 at drivers/gpu/drm/drm_vblank.c:728 drm_crtc_vblank_helper_get_vblank_timestamp_internal+0x28c/0x3a0
<cornelius>
or something similar
<cornelius>
My question is is how do I debug this further? I can't access the tail end of dmesg or journalctl when my system hard locks because... well... it's hard locked :/ so I'm at a loss as to where to go from here to fix this
<cornelius>
also my version of mesa is 23.1.3-1.fc38 and llvm version 16.0.5-1.fc38
<airlied>
seems likely to be a kernel bug
<cornelius>
That could very well be, Fedora is pretty agressive with its versions of the kernel
<airlied>
have you something you can ssh in from, and leave dmesg -w running, you might get more backtrace
immibis has quit [Ping timeout: 480 seconds]
<cornelius>
That's a smart idea, yeah I have a few spare computers I could use to SSH into this one. I'd have to setup SSH on this machine though, that'd take me a minute to figure out
<airlied>
but trying some older kernels might help (like a 6.2.x if you are on 6.3.x)
thellstrom1 has quit [Ping timeout: 480 seconds]
<cornelius>
I had a similar issue on Nobara with, iirc, 6.2.x, so I'd probably start with something older first
<cornelius>
the OBS issue is really inconsistant so that one is really hard to debug, there's really no rhyme or reason, and I've even tried using alternative plugins for VAAPI encoding but ended with the same results
<haagch>
journalctl -k -b -1 shows the kernel log from last boot
<cornelius>
@haagch that's a huge help, thanks!
immibis has joined #dri-devel
cornelius has quit [Quit: Konversation terminated!]
cornelius has joined #dri-devel
cornelius has quit []
jack has joined #dri-devel
jack is now known as cornelius
aravind has joined #dri-devel
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
phire_ has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
phire is now known as Guest5202
phire_ is now known as phire
Guest5202 has quit [Ping timeout: 480 seconds]
phire has quit [Quit: No Ping reply in 180 seconds.]
phire has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
benjamin1 has quit [Remote host closed the connection]
benjamin1 has joined #dri-devel
benjamin2 has quit [Ping timeout: 480 seconds]
benjamin1 has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
benjamin1 has joined #dri-devel
benjamin2 has joined #dri-devel
phire has quit [Read error: Connection reset by peer]
phire has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
benjamin2 has quit [Ping timeout: 480 seconds]
Lyude has quit [Read error: Connection reset by peer]
Lyude has joined #dri-devel
cornelius has quit [Quit: Konversation terminated!]
illwieckz has quit [Ping timeout: 480 seconds]
benjamin1 has joined #dri-devel
benjamin2 has joined #dri-devel
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
aravind has joined #dri-devel
illwieckz has joined #dri-devel
crabbedhaloablut has quit []
benjamin1 has quit [Ping timeout: 480 seconds]
benjamin2 has quit [Ping timeout: 480 seconds]
phire has quit [Read error: Connection reset by peer]
phire has joined #dri-devel
jewins has joined #dri-devel
benjamin2 has joined #dri-devel
benjamin1 has joined #dri-devel
benjamin2 has quit [Ping timeout: 480 seconds]
benjamin1 has quit [Ping timeout: 480 seconds]
benjamin1 has joined #dri-devel
benjamin2 has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
benjamin2 has quit [Ping timeout: 480 seconds]
ngcortes has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
YuGiOhJCJ has joined #dri-devel
benjamin2 has joined #dri-devel
benjamin1 has joined #dri-devel
benjamin1 has quit [Remote host closed the connection]
benjamin1 has joined #dri-devel
Duke`` has joined #dri-devel
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
benjamin1 has quit [Remote host closed the connection]
benjamin1 has joined #dri-devel
benjamin2 has quit [Ping timeout: 480 seconds]
benjamin1 has quit [Ping timeout: 480 seconds]
benjamin2 has joined #dri-devel
JohnnyonF has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
Leopold has quit [Ping timeout: 480 seconds]
benjamin2 has quit [Ping timeout: 480 seconds]
a-865 has quit [Quit: ChatZilla 0.16 [SeaMonkey 2.53.16/20230320105641]]
oneforall2 has quit [Remote host closed the connection]
sima has joined #dri-devel
oneforall2 has joined #dri-devel
airlied has quit [Ping timeout: 480 seconds]
benjamin1 has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
benjamin1 has quit [Ping timeout: 480 seconds]
airlied has joined #dri-devel
fab has joined #dri-devel
benjamin2 has joined #dri-devel
benjamin2 has quit [Ping timeout: 480 seconds]
Guest5112 has quit []
Danct12 has joined #dri-devel
benjamin1 has joined #dri-devel
tzimmermann has joined #dri-devel
junaid has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
kzd has quit [Ping timeout: 480 seconds]
benjamin2 has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
benjamin2 has quit [Ping timeout: 480 seconds]
smaeul has joined #dri-devel
a-865 has joined #dri-devel
yuq825 has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
benjamin1 has joined #dri-devel
Cyrinux9 has quit [Ping timeout: 480 seconds]
benjamin1 has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
fab has quit [Quit: fab]
Cyrinux9 has joined #dri-devel
benjamin2 has joined #dri-devel
benjamin1 has joined #dri-devel
benjamin2 has quit [Ping timeout: 480 seconds]
benjamin1 has quit [Ping timeout: 480 seconds]
thellstrom has joined #dri-devel
<arnd>
tzimmermann: I've dug through the history of screen_info across architectures some more and come up with a cleanup: https://pastebin.com/raw/S2h26jPp
<arnd>
I found that on the older architectures (alpha, mips, sparc, ...), it was originally set because it was required by the tty code, but that all moved into vga_console over time, so we can remove a bunch of them completely
<arnd>
I also isolated the platforms that are actually able to use vga_con to the ones that both initialize conswitchp=&vga_con and allow configuring CONFIG_VGA_CONSOLE, so that's now a much smaller opt-in list instead of a long and incorrect opt-out list
<arnd>
the arm screen_info usage in dummycon is also purely related to vgacon as far as I can tell, and this is now only used on the ancient footbridge/netwinder machine, which we'll probably remove in a few years
<arnd>
a couple of other architectures copied the 'if DUMMY_CONSOLE || VGA_CONSOLE' check from arm, but they don't actually need that
thellstrom has quit [Ping timeout: 480 seconds]
<tzimmermann>
arnd, amazing
<tzimmermann>
thank you
<tzimmermann>
could you turn that into a patchset?
<tzimmermann>
i'd rebase my patches on top of that (if they'd still be useful)
tursulin has joined #dri-devel
<tzimmermann>
i also want to go through drivers to limit the use of the global screen_info
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
<arnd>
tzimmermann: sure, I can do that. I didn't want to get in your way, but if you want to rebase on top of my changes that works.
aravind has quit [Remote host closed the connection]
<arnd>
is there anything in drm-next that's not in linux-next but might conflict with this?
aravind has joined #dri-devel
<tzimmermann>
i think the recent work on fb_pgprotect and the fb I/O helpers is not yet in upstream, but probably in drm-next
<tzimmermann>
or it enters upstream with 6.5
<tzimmermann>
but those conflicts should be minimal, if any
<tzimmermann>
i intend to merge the include-cleanups for screen_info.h today. shouldn't conflict much
benjamin1 has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
<MrCooper>
zmike: alpha may be != 1.0 in other parts of the texture image (glamor handles the 1.0 everywhere case differently), it just needs to end up as 1.0 when loading data in a specific case
<MrCooper>
anyway, the workaround I did seems cheap, I was just surprised it was necessary
aravind has quit [Remote host closed the connection]
aravind has joined #dri-devel
kts has joined #dri-devel
Haaninjo has joined #dri-devel
<emersion>
swick[m]: do you know if there's any progress wrt KMS backlight?
pcercuei has joined #dri-devel
benjamin1 has joined #dri-devel
jkrzyszt has joined #dri-devel
sgruszka has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
lynxeye has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
Ahuj has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
columbarius has joined #dri-devel
benjamin2 has joined #dri-devel
benjamin1 has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
i509vcb has quit [Quit: Connection closed for inactivity]
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
benjamin1 has quit [Ping timeout: 480 seconds]
benjamin2 has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
apinheiro has joined #dri-devel
MrCooper has quit [Remote host closed the connection]
<dakr>
bbrezillon: That's convenient, thanks a lot!
<bbrezillon>
dakr: np
<alyssa>
bbrezillon: why the panthor name btw? :D
benjamin2 has quit [Remote host closed the connection]
<alyssa>
is Thor G610? I forget the codenames
* alyssa
does vaguely recall a tTHx
benjamin2 has joined #dri-devel
<robmur01>
Thor was T620 :D
<alyssa>
oh god was T620 CSF based?
<alyssa>
is that why it never worked for me?
<alyssa>
:~P
<robmur01>
enjoy your nightmare tonight...
<alyssa>
jokes on you i wasn't going to be able to sleep anyway /s
<alyssa>
:P
<bbrezillon>
alyssa: dunno, I guess we were searching for a more inventive name that was still keeping refs to the northen mythology. That's the result of a long brainstorming, and I don't want to do it again :-)
<alyssa>
haha fair enough
<zmike>
MrCooper: what did you end up doing?
<bbrezillon>
so let's pretend T620/Thor never existed, please
<Company>
MrCooper: wouldn't you want that per client?
<Company>
or do other clients not mind that insertion being triggered?
<MrCooper>
not sure what you mean; it would mean the display effectively runs at half the refresh rate, with every other physical refresh cycle being all black
benjamin1 has joined #dri-devel
<Company>
I'm wondering if the app should just submit a black frame every other frame
<MrCooper>
(or possibly even multiple black cycles between non-black ones)
<Company>
so that the app has black frames but the rest of the windows don't
<MrCooper>
as discussed in the issue, that's not as reliable as doing it in the KMS driver or at least the compositor
<Company>
yeah, that's true
<MrCooper>
it also wouldn't do anything for the compositor's own drawing
<Company>
but it allows finer-grained control
<MrCooper>
if it fails to reliably hit every physical refresh cycle as intended, it'll look pretty bad
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<Company>
xdg_black_frame_this_surface_plz
<Company>
:)
<MrCooper>
hehe
Haaninjo has quit [Quit: Ex-Chat]
benjamin1 has quit [Ping timeout: 480 seconds]
<Company>
that ufo test is fun
<Company>
my hdr monitor looks terrible, my 10 year old one on WIndows looks okay - because Linux can't do vsync in Firefox I guess?
<MrCooper>
e.g. src/gallium/drivers/zink/ci/zink-anv-tgl-flakes.txt
<eric_engestrom>
MrCooper: oh, do you mean in the middle of tests, like `dEQP-VK.foo.*.bar.*` ?
<MrCooper>
yep
<robclark>
DavidHeidelberg[m]: tbh I've no idea how kernel config change could cause *that*.. is it only turnip/vk fails with the different kernel config?
<eric_engestrom>
ah right, yeah those I just ignore becuase it makes no difference and I feel like it's easier to read
krushia has joined #dri-devel
<MrCooper>
unless it puts the brain in glob mode :)
<eric_engestrom>
fair point, actually
<MrCooper>
not a big deal, anyway
<DavidHeidelberg[m]>
robclark: yes, only turnip, nothing else
<eric_engestrom>
also, anholt does anyone really use the regex-ness of these, or should we make them globs instead?
<DavidHeidelberg[m]>
I think maybe it's just something a bit different triggering "existing" bug
<MrCooper>
just some random Friday beer'o'clock musings
<eric_engestrom>
indeed, and good point about the time I should go ^^
<MrCooper>
alternatively, could keep the explicit dots as '\.', that would prevent accidentally matching something the glob pattern wouldn't have
<DavidHeidelberg[m]>
robclark: because the bug pop up also with kernel 6.3.4 in MesaCI, also with 6.3.1 in gfx-ci/linux build, where 6.3.1 work in MesaCI without this issue
<eric_engestrom>
MrCooper: yeah, that's the problem, we need to escape all these dots everywhere every time we move these lines from fails to flakes/skips, but since we don't we're left with regex `.` everywhere :/
<robclark>
DavidHeidelberg[m], maybe it could be bisected? Or maybe danylo or anholt has an idea? (But seems like danylo is only in #freedreno)
<Guest4888>
I'm here
<robclark>
oh, heh but your nick is wonky
<DavidHeidelberg[m]>
robclark: my guess is the bug is (probably) present in 6.3, timing/barriers?
<DavidHeidelberg[m]>
maybe I could try compile kernel with Os or something to slow it down a bit if it disappears
<Guest4888>
Did anyone run these tests with ASAN/UBSAN?
Jeremy_Rand_Talos__ has joined #dri-devel
<robclark>
danylo, yeah there was link to asan run on the gitlab issue
<Guest4888>
from their look they should be reproducible
Jeremy_Rand_Talos_ has quit [Ping timeout: 480 seconds]
Danct12 has quit [Quit: A-lined: User has been AVIVA lined]
<daniels>
jenatali: yeah, I was actually just talking with David (not even prompted by this) about how we need something better for tracking 'temporarily' disabled jobs
<jenatali>
+1
<DavidHeidelberg[m]>
jenatali: on a phone, ack for reenable
benjamin1 has quit [Ping timeout: 480 seconds]
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
jewins has joined #dri-devel
Hazematman1 has joined #dri-devel
<Hazematman1>
Hey, has any one else dealt with issues related to format promotion in gallium drivers with renderbuffers? O
<Hazematman1>
I'm trying to fix a bug with fbo-blending-formats for RGB16F textures, and the root of the issue is the format is promoted to RGBA16F that the driver does blending behind the scenes on garbage data if the blending mode using DST_ALPHA. I've tried to fix it by "faking" support for RGB16F textures and then trying to work around them in the driver, but ran into a lot of issues with mesa st treating the data in the texture as RGB16F instead
<Hazematman1>
of RGBA16F
<Hazematman1>
I'm wondering if any other drivers have ran into this issue and how they fixed them. I'm tempted to expose the original texture format when a pipe_resource is created, just so the driver can handle things behind the scenes and mask the alpha channel properly. But that would be a mesa level change instead of a just a change to the driver in gallium :/
dtmrzgl has joined #dri-devel
<zmike>
which driver is this
junaid has quit [Remote host closed the connection]
<zmike>
you probably need PIPE_CAP_RGB_OVERRIDE_DST_ALPHA_BLEND
<Hazematman1>
zmike: thanks, i'll check that out! This is on v3d
benjamin1 has joined #dri-devel
<alyssa>
zmike: why is this a CAP again and not just the default
<zmike>
look I don't know all the answers
<zmike>
I only know like 1-2 answers tops
<alyssa>
because it depends on CAP_INDEP_BLEND_FUNC apparently
<karolherbst>
some caps are really a mistake
<karolherbst>
we should probably remove all which are 1/0 and are tight to a callback being provided.. I think we have a couple of those around
<zmike>
I never understood why that was a thing
<karolherbst>
same
<karolherbst>
at least there is a plan to ditch all compute caps :D
<zmike>
compute caps are one of those things I did at some point and pray I never have to touch again
glennk has quit [Read error: Connection reset by peer]
<austriancoder>
Passed: 38/38
benjamin1 has joined #dri-devel
<alyssa>
Whoop
benjamin1 has quit [Ping timeout: 480 seconds]
jewins has quit [Quit: jewins]
jewins has joined #dri-devel
jewins1 has joined #dri-devel
benjamin2 has joined #dri-devel
glennk has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
Peuc has quit [Ping timeout: 480 seconds]
Peuc has joined #dri-devel
benjamin2 has quit [Ping timeout: 480 seconds]
benjamin1 has joined #dri-devel
<Hazematman1>
I'm waiting for CI to run on my commit removing PIPE_CAP_RGB_OVERRIDE_DST_ALPHA_BLEND š¤ Hoping I didn't break every driver in the process :P
<alyssa>
gl
ngcortes has joined #dri-devel
<DavidHeidelberg[m]>
jenatali: damn, I did these changes when Win farm was fown
<jenatali>
These changes?
<DavidHeidelberg[m]>
The container manual/automazic if marge trigger
benjamin1 has quit [Ping timeout: 480 seconds]
<DavidHeidelberg[m]>
(rules)
dsrt^ has joined #dri-devel
benjamin2 has joined #dri-devel
benjamin1 has joined #dri-devel
jewins has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
benjamin1 has quit [Ping timeout: 480 seconds]
benjamin2 has quit [Ping timeout: 480 seconds]
jewins1 has quit [Ping timeout: 480 seconds]
benjamin2 has joined #dri-devel
jewins1 has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
benjamin2 has quit [Ping timeout: 480 seconds]
tnt has joined #dri-devel
<tnt>
Hi. I'm trying to get rusticl on intel (12th gen iGPU), so I'm doing `RUSTICL_ENABLE=iris clinfo`. But this ends with 'LLVM ERROR: Broken module found, compilation aborted!' (full error output https://pastebin.com/y2tFKiZC ).
benjamin2 has joined #dri-devel
benjamin2 has quit [Ping timeout: 480 seconds]
sima has quit [Ping timeout: 480 seconds]
jewins has joined #dri-devel
jewins1 has quit [Ping timeout: 480 seconds]
<penguin42>
tnt: I don't know what it means, but the 'attribute does not match module context' sounds like the earlier nasty sounding error
junaid has joined #dri-devel
<tnt>
penguin42: yeah ... but I also have no idea what it means :/
manuel has joined #dri-devel
benjamin2 has joined #dri-devel
<penguin42>
tnt: I don't see that error in mesa source, so I guess it upset llvm somehow
<DavidHeidelberg[m]>
robclark: I know weekend is coming... thou I revieved a530_gl (added skips for stuff killing GPU) and in one (only one) run I got all UnexpectedPass on this "series of tests": https://gitlab.freedesktop.org/okias/mesa/-/jobs/45107061#L1142 I suspect, that some other parallel test set something right, and then these pass until something else set other value or ... ?
<penguin42>
tnt: Poor upset llvm
Duke`` has quit [Ping timeout: 480 seconds]
<DavidHeidelberg[m]>
Why am I bringing this up, that usually one or two tests are fail/pass, but this is much larger "flake series" if I compare to normal
<manuel>
hello, I want to contribute to mesa 3d, which part of the mesa3d project should i look to study and debug? if i can do it in a 4th gen i3 laptop would be ok
danct12_ has quit [Remote host closed the connection]
Daanct12 has joined #dri-devel
<robclark>
DavidHeidelberg[m]: those links are 404.. I guess I don't have permissions?
benjamin1 has joined #dri-devel
<DavidHeidelberg[m]>
robclark: that's weird, everyone should have access, daniels (I checked settings, it's for everyone incl. CI/CD)
Daanct12 has quit [Remote host closed the connection]
benjamin1 has quit [Ping timeout: 480 seconds]
<DavidHeidelberg[m]>
jenatali: when re-enabling Windows farm, are you ok triggering container build by hand or should I implement check for marge OR make it `always`?
<DavidHeidelberg[m]>
(ofc only when re-enabling farm, not always like for each run)
<jenatali>
I think always is fine
<DavidHeidelberg[m]>
jenatali: ok, only disadvantage will be it'll run twice (once for you locally, second for Marge)
<DavidHeidelberg[m]>
but it's easiest and cleanest change
<jenatali>
Yeah but I'd do that anyway
<DavidHeidelberg[m]>
nice! :) love when problems has simple solutions
<jenatali>
E.g. I had to add 3 additional changes to get it back working, each time I triggered CI to find the next one / make sure it was fixed
junaid has quit [Remote host closed the connection]
<DemiMarie>
On Intel GPUs, how bad is it to not load the HuC firmware?
<DemiMarie>
I know that hardware accelerated media will break, but I wonder if anything else will break.
<zmike>
renderdoc is packaged on most distros, but its development speed usually exceeds its packaging
<DemiMarie>
zmike: should it be part of Mesa git?
<zmike>
no
<DemiMarie>
Iām asking because the HuC handling header parsing smells like a complex binary format being parsed by a proprietary C blob running with high privilege, which is pretty much always a very bad idea.
<DemiMarie>
This attack surface could easily be a dealbreaker if SR-IOV or virtGPU native contexts are used for isolation, so I am wondering if it is okay to just disable hardware media processing.
<DemiMarie>
It might well be that the alternative is no GPU virtualization at all, which is even worse, so I am not concerned about the performance impact.
DMJC has joined #dri-devel
benjamin1 has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
<robclark>
DemiMarie: the question is what the HuC thing has access too.. like are gpu pgtables visible to it or any other fw or cmdstream (that would be kinda bad) or could the HuC do anything to change what memory is visible to the GPU... if all it has access to is other gpu memory of the same guest process, then that is kinda no concern from security standpoint
<DemiMarie>
robclark: my understanding is that there is only 1 HuC shared between all guests
<robclark>
sure.. but each guest process has it's own gpu virtual address space
<robclark>
the question is how context switches happen
<DemiMarie>
so the question is then whether the HuC uses only GPU VAs or if it has its own memory
<robclark>
(I've looked at that quite closely on adreno.. not on intel)
<DemiMarie>
yes
<DemiMarie>
what is the answer on adreno?
<robclark>
yeah
benjamin1 has quit [Ping timeout: 480 seconds]
<robclark>
for adreno, the context switch happens on on kernel controlled ringbuffer (ie. the thing that gets commands "branching" to userspace cmdstream) with some special commands that are no-op if they are in anything other than the kernel ringbuffer
<DemiMarie>
Why did the scratch buffer overwrite exploit require a microcode fix to patch? Or was Freedreno never vulnerable in the first place?
<DemiMarie>
My assumption here is that the HuC is a microcontroller with its own RAM that is not context switched by the host, in which case the security concerns would apply.
<robclark>
so there were a couple issues fixed with that sqe update..
<robclark>
one was a use of unitialized reg in sqe which with right combination of commands could let userspace cmdstream disabled protected mode (ie. access registers that it shouldn't, including related to context switch
<robclark>
the other was insufficient memory protections on kernel scratch buffer.. upstream wasn't really vuln to that simply because we hadn't implemented context switching for a6xx
<DemiMarie>
SQE?
<robclark>
sqe is the microcontroller thing
ngcortes has joined #dri-devel
alyssa has quit [Quit: alyssa]
benjamin1 has joined #dri-devel
carbonfiber has quit [Quit: Connection closed for inactivity]
manuel has quit [Quit: Leaving]
benjamin1 has quit [Ping timeout: 480 seconds]
fxkamd has joined #dri-devel
benjamin2 has joined #dri-devel
shashanks__ has joined #dri-devel
benjamin2 has quit [Ping timeout: 480 seconds]
<DavidHeidelberg[m]>
anholt: I looked at my changes to the farm on/off handling and I don't see the possible interference with the nightly manual jobs. I disable/trigger stuff only when .ci-farms-disabled/ is touched, which shouldn't be the case of nightly runs
shashanks_ has quit [Ping timeout: 480 seconds]
<DavidHeidelberg[m]>
nevermind, it's one of the GitLab perks... "A rules: changes job is always added to those pipelines if there is no if that limits the job to branch or merge request pipelines." so I assume "changes: [ .ci-farms-disabled/ ] when: never" is triggered always on scheduled pipelines
pcercuei has quit [Quit: dodo]
<DavidHeidelberg[m]>
wrong snippet "rules: changes always evaluates to true when there is no Git push event."