u-amarsh04 has quit [Quit: Konversation terminated!]
u-amarsh04 has joined #dri-devel
cheako has quit [Quit: Connection closed for inactivity]
yyds has joined #dri-devel
yyds has quit [Read error: Connection reset by peer]
Leopold_ has quit [Remote host closed the connection]
yyds has joined #dri-devel
Leopold_ has joined #dri-devel
u-amarsh04 has quit []
u-amarsh04 has joined #dri-devel
u-amarsh04 has quit []
u-amarsh04 has joined #dri-devel
adarshgm has quit [Read error: Connection reset by peer]
<u-amarsh04>
git bisecting
<u-amarsh04>
git bisect skip 18 times in a row was tedious
bmodem has joined #dri-devel
sarthakbhatt has quit [Quit: Leaving.]
anujp has joined #dri-devel
Company has quit [Quit: Leaving]
heat has quit [Ping timeout: 480 seconds]
sukrutb has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
sima has joined #dri-devel
anujp has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
yyds has quit [Ping timeout: 480 seconds]
<mareko>
zmike: the vertex shader input is an untyped 32-bit or 16-bit number. The input type doesn't matter, but only the number of bits matters. R8_UINT fully determines the contents of those bits, so in this case, R8_UINT is always zero-extended to 32 or 16 bits for the shader input.
kts has joined #dri-devel
<mareko>
zmike: while the shader input type doesn't matter for how the input is initialized, it does matter for algebraic instructions, for example, signed and unsigned integer comparison instructions behave differently if the top bit is 1
<mareko>
zmike: so the full input type is really for the shading language itself, not for the input initialization
<mareko>
zmike: so yes, it's legal to have mismatching vertex formats and shader input types
sukrutb has joined #dri-devel
GreaseMonkey has quit [Remote host closed the connection]
u-amarsh04 has quit [Quit: Konversation terminated!]
u-amarsh04 has joined #dri-devel
u-amarsh04 has quit []
damxo has joined #dri-devel
damxo has quit []
vliaskov has joined #dri-devel
u-amarsh04 has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<u-amarsh04>
still bisecting
benjaminl has joined #dri-devel
bolson has quit [Remote host closed the connection]
f11f12 has joined #dri-devel
pcercuei has joined #dri-devel
heat has joined #dri-devel
cmichael has quit [Quit: Leaving]
cmichael has joined #dri-devel
fab has quit [Quit: fab]
glennk has quit [Ping timeout: 480 seconds]
<countrysergei>
but intset of bitsets uses some division to understand the how to scan nodes from intervalfrom to intervalto.
<countrysergei>
but it might be only for debugging also, not sure
kts has joined #dri-devel
kts has quit [Remote host closed the connection]
robmur01 has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
rasterman has joined #dri-devel
Company has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
Jeremy_Rand_Talos has quit [Remote host closed the connection]
Jeremy_Rand_Talos has joined #dri-devel
<countrysergei>
it however seems something interesting, last definition in bitset seems to suggest that this is encoding that is made from basevalue as 64, so 64+1 is first bit but next ones i dunno yet, likely 64+2 etc. but bytes are done separately, min max has some while loops but can be overwritten once understood about the encoding.
<countrysergei>
This goes very close to what i had been suggesting, so i think the code is usable
<zmike>
mareko: I was afraid you were going to say that 🤕
<zmike>
what was your ask the other day? whether rgba8 with stride=1 was legal?
kts has quit [Ping timeout: 480 seconds]
<countrysergei>
the docs suggest that some primitive check-pointing is supported, have not inspected what it means, but technically one would want to get rid of the sparql or triplestore parsing overhead for openmath dictionaries.
heat is now known as Guest3003
Guest3003 has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
Jeremy_Rand_Talos has quit [Remote host closed the connection]
Jeremy_Rand_Talos has joined #dri-devel
<countrysergei>
also docs suggest some limitations that are not seeming very relevant to use case on 64bit architectures, so the biggest limitation is that arbitrary precision is not supported, but refinement id of 2 in power of 31 seems already incredibly large
<countrysergei>
fully bounded sparql queries do not support this splay cache , i looked from wikipedia what it means, so those are not needed either.
countrysergei was kicked from #dri-devel by ChanServ [You are not permitted on this channel]
yyds_ has joined #dri-devel
minecrell has quit [Quit: Ping timeout (120 seconds)]
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
kts has joined #dri-devel
kts has quit []
aravind has quit [Read error: Connection reset by peer]
yyds_ has quit [Read error: Connection reset by peer]
macromorgan_ has quit []
macromorgan has joined #dri-devel
yyds has joined #dri-devel
<Hazematman>
Hey, does anyone here happen to know the status of mesa on android? I'm messing around with the latest aosp main and trying to build a cuttlefish emulator image that includes mesa with latest mesa master (not the mesa main that its aosp, the latest on fdo gitlab) and when I try to build I get the error "FAILED: ninja: unknown target 'MODULES-IN-external-mesa3d'"
tzimmermann has quit [Remote host closed the connection]
f11f12 has quit [Quit: Leaving]
mbrost has joined #dri-devel
mripard has quit [Quit: mripard]
yyds has joined #dri-devel
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
anujp has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
mbrost_ has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
yyds has quit [Remote host closed the connection]
cmichael has quit [Quit: Leaving]
sukrutb has joined #dri-devel
<sima>
more people should know about drm_vblank_work
tobiasjakobi has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
tobiasjakobi has quit [Remote host closed the connection]
rasterman has joined #dri-devel
noord has left #dri-devel [...]
sarthakbhatt has joined #dri-devel
alyssa has quit [Quit: alyssa]
rasterman has quit [Quit: Gettin' stinky!]
glennk has quit [Ping timeout: 480 seconds]
<pepp>
sima: thx for your comments on the trace events series. Did you get a chance to look at v3?
<pepp>
sima: because it could answer your chained fences question with the addition made to dma_fence_chain_init
<sima>
pepp, oops missed that, was a bit chaos this week
<sima>
looking now
jkrzyszt has quit [Ping timeout: 480 seconds]
<sima>
pepp, doesn't really add any of the big design questions, since I still don't see how exactly you're going to tie it all together
<sima>
like what if you have a pile of apps and compositors rendering
<sima>
since I'm guessing you're guessing the actual dependencies through the processes that do stuff?
<sima>
or it's _extremely_ amdgpu specific, and that doesn't sound very useful
<sima>
or at least quite suboptimal design point since both atomic commit machinery and drm/sched is very generic by now and knows what's going on in driver-independent code entirely
<sima>
pepp, or put another way: if the generic events are only of use with the amdgpu specific stuff, they're not really generic
<sima>
(including existing amdgpu specific trace events imo)
<pepp>
sima: they shouldn't be amdgpu-specific. But it's also possible that I baked amdgpu-specific assumptions because that's the only hardware I can test on
<sima>
pepp, I mean if you can do the gpuvis dependency tracing with all amdgpu trace points disabled, then I think it's solid
<sima>
if you need any amdgpu specific events, then it doesn't look like a solid design yet
<sima>
that seems needed, and it definitely wont exist on other drivers which also use drm/sched, and so _do_ have the dependency information fully available in generic data structures
<sima>
and so the generic trace events should be able to get that out to userspace
<pepp>
no it's not needed; it also works fine without this. But the application doing the parsing needs to know how to transform a series of individual events into a list of jobs (= with a begin and an end)
<sima>
yeah, that's the part which doesn't really work
<sima>
and why I think we need a clear fence->fence trace event or it's just a mess
<sima>
and we kinda have that
<pepp>
even with a fence->fence event, the parsing app would have to determine which N-events form a job
<sima>
won't cover i915-display because despite that that's atomic, it hand-rolls this stuff still
<sima>
but not your problem imo
<sima>
also we have really annoying tracepoints because they're not even close to consistent with dumping stuff like fences or crtc
<sima>
but I'm not sure whether we can break them all or whether we need _v2 versions that are consistent
<sima>
so it's a pretty solid mess, but zero guessing needed for which dependencies belong to which work, that info is all there
<pepp>
sima: interesting, thanks!
<sima>
pepp, also I /think/ but not entirely sure that on the drm renderD side of things (not amdkfd) all the ttm memory management also goes through drm_sched_job
<sima>
so might instead want to annotate those better with "what is this" than add driver specific events
<sima>
pepp, I think what would be really great is uapi docs about how you need to use those, and how to assemble them back into meaningful stuff, in the drm uapi section
<sima>
so we can officiate this as "fully uapi tracepoints that we'll promise to never break
<sima>
I think that would also help a lot in reviewing the overall design and whether it is something drm can sign up to support for a close approximation of "forever"
<pepp>
sima: alright, makes sense. Getting feedback from gpuvis dev would probably be useful too
<sima>
oh absolutely, if we make this forever uapi we need userspace that's reviewed by the userspace project
<sima>
so if they're not happy about the bazillion different ways we dump dma_fence into tracepoints, that would be something we need to fix
<sima>
pepp, oh a really fun testcase would be a multi-gpu system
<sima>
like amd apu+discrete or so
<sima>
can't be i915 because that is neither using drm/sched and also hand-rolling too much atomic
<pepp>
sima: I've tested multi-GPU a couple of times, was working fine
<sima>
but xe.ko should be on board with all this
<sima>
pepp, like rendering on discrete and displaying on integrated?
<pepp>
yes
<sima>
that's the fun one ...
<sima>
nice :-)
<sima>
pepp, oh if it's not clear how to get the atomic commit dependencies - drm_atomic_helper_wait_for_fences has the authoritative answer
gallo[m] has joined #dri-devel
<pepp>
sima: noted, thanks
<sima>
or should have, and I /think/ all drivers except should be covered including any memory management fences
glennk has joined #dri-devel
<sima>
*except i915
<DemiMarie>
sima: is it reasonable for native contexts to `mlock()` all buffers passed to the GPU?
<sima>
if not that would be a good reason to fix these drivers by moving them to standard functions
<sima>
DemiMarie, it wont work for drm buffer objects
<DemiMarie>
sima: are those pageable?
<sima>
yeah
<DemiMarie>
can that be disabled?
<sima>
where's the fun in that :-P
<sima>
especially for discrete you'd probably break the world since this breaks vram swapping ...
<sima>
so I'd expect any gpu buffer object mlock to be somewhat driver specific :-/
<sima>
DemiMarie, my brain fails me and I can't remember why you need mlocked gpu memory?
<sima>
we chatted about how hard preemption is, but I forgot why mlock matters
<DemiMarie>
sima: First, it avoids taking a bunch of complex code paths in the driver that are likely to have bugs. Second, any memory that ever gets mapped into a Xen VM must be pinned. Third, any page _provided_ by a Xen VM will be (inherently) pinned.
<DemiMarie>
I expect most users to have iGPUs primarily, simply because those are the majority of GPUs on the market.
<DemiMarie>
So far, my understanding is that the two biggest concerns about virtio-GPU native contexts for Qubes OS are the rate of memory unsafety vulnerabilities in drivers and the lack of a mechanism to notify the security team when such a vulnerability is discovered.
<sima>
hm so not sure how much bugs you avoid, because we're still going to run all the code to prepare&map the memory
<sima>
maybe a few less corner cases
<sima>
DemiMarie, wrt security team, airlied&me aren't on that list, but we do get pulled in as needed for any gpu security issue
<sima>
so security@kernel.org should work for these too
<DemiMarie>
sima: so the context is that Qubes OS issues a Qubes Security Bulletin whenever a vulnerability is discovered that affects the security of Qubes OS. This includes vulnerabilities in Qubes OS’s dependencies.
<sima>
and aside from some really old hw horrors we do expect that if a drm driver has renderD nodes, each open file of that is isolated from the others
<sima>
ah yeah that one you wont get, simply because there's way too many of these and analyzing them all is hard work
<DemiMarie>
how many (give or take a factor of 2) do you mean?
<DemiMarie>
Obviously the total number of kernel vulns is huge, but only a small subset of those are relevant here.
<sima>
well I mean including all gotchas in drm code with uaf, locking fun that looks exploitable, input validation lolz and bugs you can probably break
<sima>
I'd expect a substantial part of cc: stable patches are exploitable for drm
<DemiMarie>
how many of those per year do you have roughly?
<sima>
assuming they are for a driver you care about
<Hazematman>
I'm trying to get llvmpipe&lavapipe building so I also had to make some changes to include a LLVM build that made them happy
<Hazematman>
Right now waiting for the image to build
<sima>
DemiMarie, ok some from a rough inaccurate git log the 6.1 lts kernel has ~65 fixes to shared drm core
<sima>
about every 5th looks real scary, most of the others are hw quirks and stuff like that
<Hazematman>
gallo: also thanks for the compliment :)
<sima>
real scary = might be exploitable, but I'm defintiely not going to make a fool of myself and guess
<sima>
DemiMarie, 6.1 is a bit older than a year
<sima>
I didn't look at drivers because a) that's much harder to asses and b) there's a lot more noise that's probably just fixing display issues but can't be exploited in any meaningful way
<sima>
so 10 per year for drm core code sounds about right, plus whatever is for the drivers you're using
<DemiMarie>
sima: 10 per year is about what we have for everything else in Qubes OS, plus the number of stuff in drivers which is about the same IIRC
<sima>
(bit aside, but that's what I expect the firehose of CVE's will also match with once the new kernel CNA gets going)
<DemiMarie>
hopefully that gets big companies (Google?) to throw more people at increasing overall code quality
<sima>
I think the expectation is that there'll be on the order of hundreds of CVEs for each kernel release
<sima>
ofc a really big amount only apply to specific hw support, but there's a _lot_
<sima>
DemiMarie, there's also the issue that with all the kernel hardening enabled, a lot of these are a lot less exploitable
<sima>
but since those are all Kconfig knobs, they all count
<sima>
plus you probably still want to patch, just in case someone figures out how to knock out the hardening
<DemiMarie>
sima: I wonder if companies will start pushing to rip out old code, simplify stuff, etc
<sima>
DemiMarie, old code is generally dead code
<sima>
and I think in practice the issue is a lot more that upgrading breaks too much, so I expect that users who care hopefully are a lot more motivated to build up _really_ good CI
<sima>
so that they can validate new upstream release faster
<DemiMarie>
which will in turn help everybody
<sima>
a leisurely year or so that even the good android vendors take to upgrade is just not going to work
<sima>
yeah
<sima>
and hopefully also catch issues faster and before they hit a release
<sima>
DemiMarie, for actual fundamental improvement I think weeding out the stupid "undefined behaviour lolz" in the linux kernel C flavor is going to help a lot more
<DemiMarie>
I also suspect enterprise distros will start trimming their Kconfigs.
<sima>
it's really hard, but a lot has been achieved already
<sima>
oh yeah
<sima>
plus probably enable a lot more hardening, even if it costs
<sima>
since it doesn't help with the flood, but it helps with the severity
<DemiMarie>
It is extremely obvious that a CVE does not affect a distro if the fix is to code that is not included in the build
<sima>
so you have a bit more time since it's not obvious stuff that even fools can exploit
<sima>
yeah
<sima>
so maybe also some build tools that generate the actual list of CVEs impacting your build
<DemiMarie>
For Qubes OS turning on GEM_BUG_ON() might be a good idea
<DemiMarie>
looks like it would catch at least one OOB write
<sima>
also I figure that stuff like CONFIG_VT=n will hopefully accelerate
<sima>
there's some really horrible stuff there
<DemiMarie>
syzbot is also going to start auto-assigning CVEs, IIUC
<sima>
yeah maybe
<sima>
although that one kinda boils down to "who pays for the work to fix stuff"
<DemiMarie>
enterprise distro vendors
<DemiMarie>
they will have no choice due to compliance requirements
<sima>
yeah maybe someone will find some budget hopefully
<sima>
plus disabling a lot of the old horrors like CONFIG_VT
konstantin_ has joined #dri-devel
konstantin is now known as Guest3039
konstantin_ is now known as konstantin
<DemiMarie>
at what point will non-enterprise distros be able to turn that off?
<sima>
entirely depends upon how hard they care about the kernel console
<DemiMarie>
the problem is that client hardware has no OOB management and no serial port
<sima>
I think most desktop distros are actually leading enterprise distros, since there's some infra work missing still that needs really recent kernels
<sima>
android/cros have it disabled since years
<DemiMarie>
So until userspace comes up you are booting up blind
<sima>
oh do not rely on drm for emergency logging
<sima>
it's entirely busted
<sima>
but we'll get a new drm panic handler to fix this properly for real, which is one of the infra issues
simon-perretta-img has quit [Ping timeout: 480 seconds]
<DemiMarie>
My long-term hope is for much of DRM and the GPU drivers to be rewritten in Rust
<sima>
DemiMarie, also defacto desktop distros load the gpu drivers from initrd, and at that point you can have a small userspace logger running too
<DemiMarie>
Heck, even a way to make use-after-free and OOB memory access defined at the cost of a 4x slowdown and serializing everything in the kernel might be a win for some setups.
<sima>
because of the entire fw issues
<DemiMarie>
sima: I think we will see stuff moving to a dm-verity volume for fw
<sima>
DemiMarie, all the integer math stuff is getting fully defined at least
<sima>
and I think range-validate arrays are coming, yay
<DemiMarie>
sima: if there was a way to have overflow trap in release builds that would be awesome
<sima>
compiler-checked range-validated arrays I mean
<sima>
DemiMarie, it's coming
<sima>
the issue is that there's a lot of integer math that intentionally overflows
<sima>
to check userspace input
junaid has joined #dri-devel
<sima>
so you can't oops on that or you just made an exploit :-)
<DemiMarie>
that still leaves UAFs and locking problems, though
<sima>
yeah
<sima>
although there's scope based automatic cleanup now
<DemiMarie>
you can solve those with fat pointers and a global lock but it means a 4x or more slowdown last I checked
<sima>
that should at least help a lot with bugs in error paths
<sima>
but ofc, huge amounts of work
Guest3039 has quit [Ping timeout: 480 seconds]
<DemiMarie>
ultimately, though, I think C needs to be replaced
<sima>
DemiMarie, yeah given that rcu use is growing steadily I don't think that'll work
<DemiMarie>
C is just not a viable language in the 2024 threat environment
<sima>
outside of some very niche cases
<sima>
yeah, but the issue is a bit that there's too much C
<sima>
so I think both improving C as much as possible and working on replacing it is needed
<sima>
there's some good stuff coming in C standards discussions afaik too
<DemiMarie>
And also deprivileging it by moving it to userspace
<DemiMarie>
Unfortunately for DRM/GPU stuff that fails miserably, because (at least in the Qubes OS threat model) the GPU driver is privileged by definition!
<sima>
oh yeah absolutely
<sima>
like config_vt=n is just a must
<sima>
DemiMarie, well if you look at the entire gpu stack we already have like 90% in userspace
<DemiMarie>
sima: I also mean stuff like networking, USB, Bluetooth, Wi-Fi, filesystems, etc
<sima>
yeah those are all fairly tricky
<sima>
DemiMarie, I wonder whether per-gpu-ctx processes on the host side for virtio-gpu would be doable
<DemiMarie>
sima: Maybe? How would it help?
<sima>
that way if you can exploit the userspace part of the hw driver, it should be a lot more limited
<DemiMarie>
sima: the current plan is native contexts, so the userspace part runs in the guest
simon-perretta-img has joined #dri-devel
<sima>
yeah that's another one, also should be faster
<DemiMarie>
The old virgl/venus stuff is never going to be supported in Qubes OS
<DemiMarie>
In fact one major reason that work for GPU accel in Qubes OS has not started yet is that native contexts are still not upstream except for Qualcomm last I checked
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
rah has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
Lyude has quit [Quit: Bouncer restarting]
simon-perretta-img has joined #dri-devel
Lyude has joined #dri-devel
junaid has quit [Remote host closed the connection]
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
jsa has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
<DemiMarie>
Google said (at XDC 2023) that 80% of KMD vulnerabilities are not exploitable in the native context case. So that reduces the flood from 20 VM escapes per year down to less.
tursulin has quit [Ping timeout: 480 seconds]
jsa has quit []
countrysergei has quit [Remote host closed the connection]
mvlad has quit [Remote host closed the connection]
mbrost has joined #dri-devel
sravn has quit []
sravn has joined #dri-devel
heat is now known as Guest3066
Guest3066 has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
rgallaispou1 has joined #dri-devel
rgallaispou has quit [Read error: Connection reset by peer]
rgallaispou1 has quit [Read error: Connection reset by peer]
mbrost has quit [Remote host closed the connection]
rgallaispou has joined #dri-devel
mbrost has joined #dri-devel
heat is now known as Guest3067
Guest3067 has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
flom84 has quit [Ping timeout: 480 seconds]
vliaskov has quit []
sukrutb has joined #dri-devel
sima has quit [Ping timeout: 480 seconds]
<karolherbst>
jenatali: sooo.. we need to support opencl-c.h with llvm-15+ afterall, because support for some extensions are missing if not using it (e.g. cl_intel_subgroups). Do you want to have a compile time switch to include it in the binary or should I just unconditionally embeded it with static llvm? It's like 800kb
<karolherbst>
ehh wait..
<karolherbst>
it's probably less after compression
<karolherbst>
though we only compress libclc?
<karolherbst>
anyway...
<karolherbst>
do you want a flip for the file? Though given that some AI/ML stuff just depends on that intel subgroup ext might as well already ship it...
<jenatali>
karolherbst: I don't care one way or another. It's a drop in the bucket compared to actual clang
<karolherbst>
true
<karolherbst>
makes it easier for me to always include it :)
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
jeeeun841351908 has quit [Remote host closed the connection]