ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<DemiMarie>
airlied: which compute workloads (other than ML) do _not_ need FP64?
<airlied>
let me turn that around, what compute workloads exist anymore that aren't ML :-P
<jtatz[m]>
airlied: physics simulations
co1umbarius has joined #dri-devel
<alyssa>
airlied: ray tracing
kzd has quit [Quit: kzd]
columbarius has quit [Ping timeout: 480 seconds]
<DemiMarie>
I did a cell growth simulation when I was an intern in college.
<airlied>
yeah I'm just trolling because running those with the fp64 emulation you get on nearly all modern desktop hw totally sucks
<HdkR>
alyssa: Raytracing is watertight in fp32 space until you're like a million points away from origin, it's fine :P
<DemiMarie>
Is the Asahi driver blocked on the same drm_sched issues that Xe and PanCSF are?
<DemiMarie>
As an onlooker it seems that drm_sched is a very bad API.
<airlied>
the only thing worse than a shader scheduler design is per-driver scheduler design
<airlied>
it's not really an issue, it's just necessary public design work
<DemiMarie>
“shader scheduler”?
<DemiMarie>
At the very least writing drivers that don’t UAF when unbound should not be so hard.
<airlied>
shared
<airlied>
I cannot type shared anymore, my fingers autocorrect it
<airlied>
you'd think it was simple, but turns out it's not, hence design
<DemiMarie>
Am I correct that the current design is bad?
<airlied>
the current design is fine for the things it was designed for
<airlied>
we are now trying to use it for new things
<airlied>
hence it needs redesign
<DemiMarie>
what about the lifetime problems with Panfrost Asahi Lina pointed out?
<airlied>
we are now trying to use it for new things
<DemiMarie>
and some old drivers had bugs
<airlied>
not sure what was unclear about that statement
<airlied>
the xe, asahi, pancsf, nouveau use case is all new things
<DemiMarie>
I’m referring to the Panfrost unbind bug
<DemiMarie>
Also I’m surprised that Nouveau is a new thing, considering that it is an old driver.
<airlied>
feel free to learn how it all works and suggest designs :-)
<DemiMarie>
yeah, as an infosec person I find that I am often more able to provide constraints than to solve those constraints
<Lynne>
radeon vii was nice, it had more fp64 units than pretty much everything consumer before or since, and even had hbm memory
<psykose>
i don't think i knew a single person that had one, for some reason
<Lynne>
it was in the shadow of the 1080, much like the 2080 was, nvidia dropped the ball and made a future-proof card
<DemiMarie>
I do hope that Xe will have fewer bugs than i915; bugs in i915 are the reason GPU acceleration in Qubes OS will need to be off by default even once it is implemented.
<airlied>
there are unreported security bugs in i915?
rz_ has joined #dri-devel
<q66>
i mainly hope xe will actually finally be merged into the kernel within my lifetime
<q66>
so that i can actually finally use my a750 for what i wanted to use it for (non-x86 computers)
rz has quit [Ping timeout: 480 seconds]
<emersion>
gildekel: i think the "bad cable" issue is not just with 0 modes, it also happens when the kernel has pruned some but not all modes
<emersion>
in that case as well you'd want to signal back to the user that _something_ is wrong
<emersion>
so i don't think using 0 modes as an indication that "something is wrong" works very well
<emersion>
a new prop might be better
<DemiMarie>
airlied: “no known unpatched security bugs” is not enough for Qubes OS. Qubes OS also cares about how many security bugs there have been in total, especially compared to the amount of effort put in to finding them.
<airlied>
DemiMarie: how do you use computers at all?
<airlied>
not saying GPUs are becaons of greatness, but total security bugs in the kernel or any other software surely swamps it
<DemiMarie>
airlied: I did `git log -p v6.1..v6.1.51 -- drivers/gpu/drm/i915` and looked at the individual commit messages to see what looked like a security bug. I found 13, one of which was GVT-g only (which would not matter for virtio-GPU native contexts) and 4 of which were mitigated by wrapping all ioctl() calls in a global lock. That leaves 8. Qubes OS has had 8 security bugs _total_ in the same time period.
peelz has joined #dri-devel
<airlied>
I think that means you aren't looking closely enough at other pieces of the kernel then :-)
peelz is now known as Guest2082
<DemiMarie>
airlied: nah, it’s because we don’t trust most of Linux to be a security boundary :-)
<DemiMarie>
You are absolutely correct about there being way more vulns elsewhere, but the vast majority of them don’t impact Qubes OS in any way.
<airlied>
do you pass any devices into the guest like you would the GPU?
<airlied>
or should you just figure out how to use venus?
<DemiMarie>
We use PCI pass-through for Ethernet and USB controllers. That’s all handled by the Xen hypervisor and various other Xen Project code.
<DemiMarie>
Venus is out of the question because it means running the shader compiler on the host.
<airlied>
I don't think xe will be any better there, or any gpu driver, the fact they fixed that many bugs surprises me
<DemiMarie>
I would absolutely love to be wrong about my analysis!
<robclark>
airlied: the situation isn't great for webgpu/webgl or anywhere that that gpu is exposed to hostile content.. (and vm is same sort of situation).. I think virtgpu native ctx helps because at least 2/3 issues seem to be handle lifetime which require attacker to control two threads with access to drm driver (which native-ctx doesn't give you) and the remainder require abusing ioctls in a way that you can't nearly as easily with
<robclark>
native-ctx.. For non vm case I'd really like to have webgl/webgpu mesa in dedicated sandbox without direct access to kernel but using something like native-ctx over a sort of hardened vtest
<robclark>
turns out, since flash was deprecated, the bad guys moved on to find the next easiest low hanging fruit
<DemiMarie>
robclark: thank you!!!!!! can you explain what you mean by “abusing ioctls”?
<DemiMarie>
Is this because native contexts basically validate everything again in userspace?
rz_ is now known as rz
xypron has joined #dri-devel
<robclark>
that could be things like passing impossibly long arrays or weird params.. not sure native-ctx protects everything but if it protects 90% then it makes a useful layer in the defense-in-depth perspective.. and the host part of it is an easy place to add extra protection/sanity-checking
<robclark>
I'm of the opinion that it is too easy to get code execution in UMD (mesa or otherwise) for that to be considered a layer in the sense of defense-in-depth
<robclark>
so UMD not having access to kernel is a a useful thing.. maybe small perf penalty but that is a useful tradeoff when you are exposing it to the interwebs
<airlied>
but what you give the umd access to would just be an API wrapping ioctls in ioctls?
<robclark>
(also, native-ctx and core virglrenderer is small enough that re-writing parts of it in rust over time is tractable)
<robclark>
umd would have access to a socket
<robclark>
to "vtest" server (well, vtest will serve as the prototype but we should re-write in rust)
<airlied>
yeah like I've considered we should have that for containers anyways
<airlied>
but also just virgl in case we don't have native drivers inside the container
<robclark>
yeah.. depends on degree of trust of thing using umd but if you don't trust it we want another layer.. umd should just be considered "crumple zone"
<robclark>
no vrend pls.. the vrp program is having a hay-day with vrend
<airlied>
well maybe the venus version rather than the glsl one :-P
<robclark>
vrend is just an express lane to what you don't want to have the bad guys get at
<robclark>
yeah, venus is more sane.. but still, expect to get code exe in umd and then once again you have access to kernel
<DemiMarie>
robclark: are you with ChromeOS?
<DemiMarie>
because if so then I think there is room for collaboration
<robclark>
DemiMarie: yes, CrOS gpu team
<DemiMarie>
robclark: THANK YOU
<DemiMarie>
(caps intentional)
<robclark>
I get to live with the terror that is vm's and web content exposed to gpu drivers ;-)
<DemiMarie>
Situation in Qubes is that we are caught between users someone might burn a 0day on and GUI toolkit authors who decide that software rendering eating 80% CPU is not a bug.
<robclark>
(and tbh.. I haven't looked at games that have user contributed content like roblox.. not sure if that should also be scary yet)
Company has quit [Quit: Leaving]
<robclark>
I'd recommend against enabling webgpu and probably webgl if you can.. since web is probably were users are most exposed.. toolkit, well that depends on if users are just running random apps, but I think there is less risk there.. you can more easily chose not to run $randome_exe than avoid malicious ads, etc..
<robclark>
but ofc depennds on users threat model
<DemiMarie>
robclark: In Qubes OS our assumption is that the villains have already popped your web browser.
<robclark>
some might want to stick to sw rendering in guest
<DemiMarie>
So 0days in Chrome, Firefox, etc are very much in scope
<DemiMarie>
And yes, I would very much prefer to stick with SW rendering, but unfortunately the GTK4 devs have decided that SW rendering eating tons of CPU is perfectly okay.
youmukon1 has joined #dri-devel
<DemiMarie>
robclark: mind if I DM you to avoid distracting the rest of the people here?
<robclark>
np
lemonzest has quit [Quit: WeeChat 4.0.4]
yyds has joined #dri-devel
youmukonpaku1337 has quit [Remote host closed the connection]
<airlied>
has anyone documented how slow/much cpu gtk4 is using?
lemonzest has joined #dri-devel
<q66>
considering i've successfully used gtk4 on a 2005 power mac, i don't think it's as significant of an issue as presented
youmukonpaku1337 has joined #dri-devel
feng_ has joined #dri-devel
<q66>
qubes os and similar folks are just great at creating an environment where everything is a footgun and then complaining they shot themselves in the foot
<airlied>
could probably expend some time to see if we can make gtk4 use llvmpipe linear paths more
<airlied>
once I finally get gnome-shell across the line
<DemiMarie>
q66: Qubes OS developer here, my hope is that GPU security can be more than just “don’t give GPU access to untrusted code”.
<DemiMarie>
airlied: that would be absolutely amazing, thanks!
<q66>
yes, you made it obvious enough already
<emersion>
DemiMarie: have you considered submitting GTK patches to optimize the software rendering paths?
<airlied>
or fixing llvmpipe to be faster
<emersion>
i think it's perfectly reasonable for GTK devs to not focus on the software rendering perf, since it's not used by most people
<q66>
the main typical cpu bottleneck in gtk4 is not software or gpu rendering, but overreliance on simd'ed paths through graphene
youmukon1 has quit [Ping timeout: 480 seconds]
<emersion>
as always in the open-source world, if you care, you can just submit patches
<q66>
if you compile graphene with scalar you will *actually* see your performance (in gnome shell and elsewhere) go down the drain
<psykose>
that makes total sense tho
<q66>
the annoying part is half the api implementations graphene exposes are in the header
<robclark>
I'm ok with exposing g-s to GPU (esp if you block extensions).. that doesn't terrify me as much as web browser.. I'm ok with exposing skia (or whatever ffox uses) to GPU for web browser.. but webgpu and to a _slightly_ lesser extent, webgl.. not so much
<DemiMarie>
emersion: GTK software rendering is deprecated, but airlied’s suggestion of speeding up llvmpipe is a worthwhile thought
<emersion>
have you found out why it is deprecated?
<emersion>
maybe it's because it's missing a maintainer?
<q66>
presumably because software rendering was using cairo and cairo sucks
<q66>
(not sure if that's the actual reason, but it sounds likely)
<q66>
for one it's been kinda dead for quite a while and for two its design is fundamentally flawed
<DemiMarie>
emersion: It's deprecated because it doesn’t support 3D transformations.
<emersion>
3D… in a UI toolkit?
<emersion>
oh well
<DemiMarie>
emersion: yup
Daanct12 has joined #dri-devel
<DemiMarie>
As far as submitting patches goes, is there a guide to getting started in Mesa anywhere?
<robclark>
there is https://docs.mesa3d.org/submittingpatches.html is you have patches to make llvmpipe running in guest / untrusted env faster.. but pls don't think of mesa as a hardened layer in defense
<DemiMarie>
kisak robclark: it’s less a matter of “what is the procedure used“ and more “how do I not get lost in millions of lines of code”
<robclark>
a journey of a million LoC starts with one LoC?
<q66>
emersion: what's weird about that
<q66>
being able to do generic matrix transformations is pretty useful
<q66>
and considering the toolkit is already opengl-driven, it makes sense
<robclark>
our docs are better than they've been in a long time.. but digging into a large code base is always going to be hard
<DemiMarie>
robclark: good point, maybe it is just a skill I should learn
<q66>
i mean, css allows them too for instance
<DemiMarie>
I did manage to dig into Linux and fix some Xen memory management issues after all.
<robclark>
I guess, for less trusted apps your focus would be on llvmpipe being a good-enough alternative... so profile and go from there?
youmukon1 has joined #dri-devel
<DemiMarie>
I guess the first place to start would be the algorithmic stuff airlied is working on
<robclark>
but always, these things are prioritizing.. what things are trusted enough that you can expose to gpu (after combining with native-context, etc).. what things are completely untrusted and you just want to live with llvmpipe, and such
<DemiMarie>
yup
<robclark>
some things 99% is good.. some things it takes 99.99999%, etc
<DemiMarie>
indeed
<DemiMarie>
and also some risk is unavoidable, and taking the risk might be worth it in some cases
<DemiMarie>
But at this point I think hypothetical discussion has gone as far as it can and I need to start thinking about where (and when) I can start actually doing stuff
<robclark>
:-)
youmukonpaku1337 has quit [Read error: Connection reset by peer]
<DemiMarie>
Thanks to everyone here for the feedback (extremely useful!) and for putting up with all of my questions.
xzhan34_ has quit [Remote host closed the connection]
<DemiMarie>
Sorry for taking up so much of people’s time.
xzhan34 has joined #dri-devel
<robclark>
np.. it is an interesting topic.. I think gpu security is getting better but at the same time as security has been improving in various places (such as deprecating flash) the bad guys don't retire, they just look for the next least-hard surface.. cat-and-mouse and all that
<DemiMarie>
yeah, that is my understanding too
<DemiMarie>
I do hope that newer drivers will at least have cleaner uAPIs that are easier to implement properly.
<robclark>
maybe rust in kernel will make handle lifetimes harder to screw up.. that is literally most of the issues I see go by (fortunately it is by defn a race condition issue which single threaded native ctx saves you from)..
<DemiMarie>
yeah
<DemiMarie>
Xe rewritten in Rust would be amazing
<emersion>
q66: matrix transformations can be 2D, not necessarily 3D
<emersion>
(just use 3x3 instead of 4x4)
egbert is now known as Guest2094
<q66>
emersion: yeah but it's handy to be able to do generic 3d transforms as well considering these days toolkits are not just strictly defined widget layouts but rather more generic/freeform graphics toolkits
egbert has joined #dri-devel
<DemiMarie>
BTW if you want the actual commits I thought were security issues I can send them to you robclark. They were all backported to stable and I assume that CrOS picked them up from there.
Guest2094 has quit [Ping timeout: 480 seconds]
crabbedhaloablut has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
<daniels>
Kayden: fwiw .gitlab-ci/bin/ci_run_n_monitor.py is what you want for triggering manual jobs, rather than hitting play a few times and cancel a million times
<Sachiel>
oh, that's good to know
<daniels>
for one it makes your life a lot easier, and for two the target regex avoids swamping hardware runners with unnecessary jobs which block marge
youmukonpaku1337 has joined #dri-devel
youmukon1 has quit [Remote host closed the connection]
<Kayden>
ah neat, so I can just pick a specific job I want to run and it'll get all the deps for that and not everything else?
<Kayden>
thanks for the tip :)
tristan has joined #dri-devel
tristan is now known as Guest2100
ngcortes has quit [Ping timeout: 480 seconds]
<daniels>
Kayden: correct, and np!
<airlied>
initial look suggests hitting the linear path for gtk4 shaders might be hard, the frag shaders are pretty complex
ZeZu has quit [Quit: off to see the wizard]
ZeZu has joined #dri-devel
kzd has joined #dri-devel
a-865 has quit [Ping timeout: 480 seconds]
ungeskriptet0 has quit []
ungeskriptet has joined #dri-devel
a-865 has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
jewins has quit [Ping timeout: 480 seconds]
youmukonpaku1337 has quit [Remote host closed the connection]
youmukonpaku1337 has joined #dri-devel
flynnjiang has quit [Ping timeout: 480 seconds]
flynnjiang has joined #dri-devel
Duke`` has joined #dri-devel
agd5f_ has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
kzd has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
kzd has quit [Quit: kzd]
itoral has joined #dri-devel
ngcortes has joined #dri-devel
kzd has joined #dri-devel
tzimmermann has joined #dri-devel
elongbug_ has quit [Read error: Connection reset by peer]
bmodem has joined #dri-devel
flynnjiang has quit [Ping timeout: 480 seconds]
flynnjiang has joined #dri-devel
sima has joined #dri-devel
kzd_ has joined #dri-devel
itoral_ has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
itoral has quit [Ping timeout: 480 seconds]
i-garrison has quit []
i-garrison has joined #dri-devel
<HdkR>
`[20147.176454] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx_0.0.0 timeout, but soft recovered` Nice, I found a game that has a crash on demand function
camus1 has quit [Remote host closed the connection]
camus has joined #dri-devel
illwieckz has joined #dri-devel
<karolherbst>
itoral_: soo.. I've fixed a bunch of other issues and I think the GPU can get into an invalid state through atomic operations. No idea _why_ but something weird seems to happen there
Haaninjo has quit [Quit: Ex-Chat]
<itoral_>
not sure what could be wrong with those, I've never seen any issues and there are plenty of tests for these in CTS... are those issues repeateable or do they happen randomly?
<itoral_>
I assume they are 32-bit atomics and the addresses are 32-bit aligned, right?
<karolherbst>
uhm.. didn't check
Guest2116 has quit [Ping timeout: 480 seconds]
Cyrinux9474 has quit []
Cyrinux9474 has joined #dri-devel
<karolherbst>
itoral_: the odd thing is, it might also be something else, because global atomics are not supported by the compiler anyway, but still the atomic tests are the one making the GPU go all weird
youmukon1 has quit [Remote host closed the connection]
youmukonpaku1337 has joined #dri-devel
<karolherbst>
ohhhh....
<karolherbst>
uhhh
<karolherbst>
itoral_: I know what's happening...
<karolherbst>
itoral_: sooo.. if the compiler hits an unknown intrinsics it continues compiling ...
<karolherbst>
and then throws a random broken shader at the GPU
<karolherbst>
and apparently the GPU doesn't like it
<austriancoder>
has somebody written an gpu opcode verifier? looking for inspiration before porting the old etnaviv one
Daaanct12 has joined #dri-devel
<karolherbst>
I'll throw in asserts and see if dealing with it fixes all the issues I've seeing
<karolherbst>
I wouldn't be surprised if the GPU gets into an infinite loop or other fun things
<itoral_>
yeah, could be
<karolherbst>
does the kernel driver handle those cases where the GPU is getting stuck with a job?
<itoral_>
I think the job would timeout and you would see a message in dmesg
<karolherbst>
mhh
<karolherbst>
well.. I didn't see a timeout at least
<karolherbst>
but userspace also waits infinitely
<itoral_>
either way, if we are submitting shaders with bogus load/store ops (due to unsupported intrinsics) I guess anything can happen :P
<karolherbst>
maybe something else is going on, but I'll do another full run and see if I still see the GPU getting stuck
<karolherbst>
yeah...
<karolherbst>
anyway, I'll probably create an MR with some initial patches tomorrow, because I already have a few things I might want to get some feedback on
<karolherbst>
mhh, still seeing the GPU getting stuck, let's see what it is this time
mauld has quit [Remote host closed the connection]
<kode54>
looks like Intel's compiler has an unreachable intrinsic check as well, but it only asserts if NDEBUG isn't set
<kode54>
unless unreachable() is just a crash
Company has joined #dri-devel
mauld has joined #dri-devel
<HdkR>
kode54: unreachable should be a SIGABRT or SIGILL depending on arch
<kode54>
gotcha
<kode54>
so the issue must be something else
<kode54>
the atomic mention above made me think that
<kode54>
some games using that on xe.ko seem to just crash the GuC easily
<kode54>
or perhaps it is something else
vliaskov has quit [Remote host closed the connection]
<tintou>
olv: Hi there! I have a question, when you introduced perfetto you added the "slow" category, but I don't find any user of it, what was the plan behind this?
jdavies has joined #dri-devel
jdavies is now known as Guest2130
Guest2130 has quit []
<karolherbst>
itoral_: how can I dump what shader is generated?
<karolherbst>
anyway.. the hang I'm seeing seems to be happen randomly with some of the buffer tests (which literally just try to do some global load/stores) but I'm also seeing some invalid memory accesses
<itoral_>
V3D_DEBUG=cs should dump NIR, VIR and QPU assembly for compute shaders
<karolherbst>
anyway.. the callback I've written for nir_lower_mem_access_bit_sizes is probably incorrect..
<itoral_>
do we need that? v3dv supports vk_khr_{16,8}bit_storage, so regular ubo/ssbo/shared load/store is supported
<itoral_>
or is that for unligned accesses?
<karolherbst>
CL has vec16
<karolherbst>
but you'll also see things like vec4x8 load/stores
<karolherbst>
it kinda sounded like that only single component load/stores are supported in 8/16 bit
<karolherbst>
but yeah.. CL also has unaligned accesses as it also has packed structs like C
<karolherbst>
it's kinda copied from asahi I think, but also adjusted
<karolherbst>
but I think the issue I'm seeing is something else...
<itoral_>
that code looks valid for us too, we are also in the bucket of only supporting 32-bit vector acccess
<karolherbst>
yeah...
<karolherbst>
I think something else is going very wrong, but I just don't know what.. maybe the way I've implemented load/store global is messing up with stuff
frankbinns has quit [Remote host closed the connection]
<karolherbst>
but it generally also works
frankbinns has joined #dri-devel
<itoral_>
if you can create an issue with details on how to replicate this I can try to give it a go tomorrow and see if I can figure out what is happening
<itoral_>
or rather next Monday, I won't be online tomorow :)
<karolherbst>
fair enough :D
<karolherbst>
mhh
<karolherbst>
maybe memory gets dealloacted while it's still in use...
<karolherbst>
which.. shouldn't happen
<tnt>
I'm a bit unfamiliar with the schedule for mesa releases but how/when is the cut-off for 23.3 features done ? Like how long would I have to get (non-bug-fixes) patches merged onto main for them to make it in 23.3 ?
<itoral_>
karolherbst:this is what I did when I added support for global_2x32 in our compiler, maybe it is a good reference to go through that and check if your global intrinsics are handled properly in all the right places
<zmike>
I guess I'll take your word for it since I can't see the reference?
tristan has joined #dri-devel
tristan is now known as Guest2134
youmukonpaku1337 has quit [Remote host closed the connection]
youmukonpaku1337 has joined #dri-devel
alyssa has quit [Quit: alyssa]
fab has quit [Quit: fab]
youmukonpaku1337 has quit [Remote host closed the connection]
youmukonpaku1337 has joined #dri-devel
heat has joined #dri-devel
<daniels>
yeah, I suspect a whole load of reference images fell out at some point, but the sheet music doesn't look great?
fab has joined #dri-devel
Daaanct12 has quit [Quit: WeeChat 4.0.4]
Daanct12 has joined #dri-devel
<zmike>
maybe that's how it's supposed to look?
<zmike>
not sure I've ever looked at results for this trace before
youmukonpaku1337 has quit [Remote host closed the connection]
youmukonpaku1337 has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
Daanct12 has quit [Quit: WeeChat 4.0.4]
vliaskov has joined #dri-devel
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
Guest2134 has quit [Ping timeout: 480 seconds]
<gildekel>
emersion: `a new prop might be better`
<gildekel>
I believe we reached an agreement in which a new link-status=TERMINAL is added, and the connector is marked as disconnected, as you suggested initially.
<gildekel>
There is still some debate around how to propagate this state down an MST topology, but I think that at this point, I'll write some code and the discussion can continue via the review process, or once people get a chance to digest the new approach.
yuq825 has quit [Remote host closed the connection]
youmukonpaku1337 has quit [Remote host closed the connection]
youmukonpaku1337 has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
fab has quit [Read error: Connection reset by peer]
pq has quit [Ping timeout: 480 seconds]
youmukonpaku1337 has quit [Remote host closed the connection]
youmukonpaku1337 has joined #dri-devel
kzd has joined #dri-devel
pq has joined #dri-devel
ap51 has quit [Ping timeout: 480 seconds]
danylo is now known as Guest2143
danylo has joined #dri-devel
enunes- has quit [Remote host closed the connection]
enunes has joined #dri-devel
youmukon1 has joined #dri-devel
periontus has joined #dri-devel
periontus was kicked from #dri-devel by ChanServ [You are not permitted on this channel]
Guest2143 has quit [Ping timeout: 480 seconds]
youmukonpaku1337 has quit [Read error: Connection reset by peer]
An0num0us has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
junaid has joined #dri-devel
mediaim has joined #dri-devel
<mediaim>
That technology is very safe, clock lines need emfi absorber protection, and there is a hw tpm and hw shifted base window i.e MMIO bar circulates all the time, and the procedure uses ciphered instruction to enter into secure enclave, where memory protection is toggled out on request, hence i had serious doubt that estonians got the satellite sent to anywhere, cause their first revision of the hw did not have mmu, but third revision had
<mediaim>
some ppram reram security in fact, which was in random phase. So this they specified later, maybe it was in the first revision too of the estcube, than technically it was possible that the satellite was orbiting , all in all you need to have some security to make those things , and self-driving cars and satellites can have very strong and basically non compromise able security, international space station relay too, cause security is
<mediaim>
theoretically at max, hw trojans should be scanned out from such hw, the last which would be the only way to compromise such systems.
kts has joined #dri-devel
jewins has joined #dri-devel
An0num0us has joined #dri-devel
Duke`` has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
<mediaim>
So what would be beneficial is to make some a category electrician and programming certificate, there is many opportunities, i have looked what boston robotics systems do, and have some British factory demo streams, as to how well things can be arranged, but human life is that it can not be so paranoid either, you want to live your life, not in cage like putin now has to do, so this is always a trade-off.
<mattst88>
mediaim: please stop spamming us. you've been doing this for 10+ years and we do not appreciate it
<mattst88>
we have tried to explain this to you. please stop spamming
<mediaim>
I do not think that people who assault behind the back consistently are doing well in life, you get torn too, you have been doing this all my existence. And your line count is way longer on IRC too, but your cunt actions deserve a penalty.
<mattst88>
please do not talk about off-topic things in our IRC channels
<mattst88>
it is not welcome here
<mediaim>
fair enough if you please stop being suicidal terrorist, we have an agreement!
<mattst88>
I agree. I will not be a suicidal terrorist
<mediaim>
ack, good bye.
mediaim has quit [Quit: Leaving]
mszyprow has quit [Ping timeout: 480 seconds]
<zmike>
mattst88 4 prez
* mattst88
is stunned
<idr>
WHAT HAPPEN?
<karolherbst>
:O
<DemiMarie>
kode54: Can you report the GuC crashes to Intel and have them fix them? GuC crashes smell of a potential security problem to me.
lynxeye has quit [Quit: Leaving.]
Guest2114 has quit [Remote host closed the connection]
<olv>
tintou, it was for trace events that was too heavy to be enabled by default. There is indeed no user.
donaldrobson has quit [Ping timeout: 480 seconds]
junaid has quit [Remote host closed the connection]
<robclark>
mattst88: wow
<mattst88>
robclark: all because I didn't have permissions to akick too :P
bmodem has quit [Ping timeout: 480 seconds]
kzd has quit [Quit: kzd]
<kisak>
For some reason I have trouble believing that both parties will honor that agreement, but best of luck to both of you.
<mattst88>
hahaha
<idr>
Lol
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
Jeremy_Rand_Talos__ has joined #dri-devel
tertl8 has quit [Quit: Connection closed for inactivity]
DemiMarie has left #dri-devel [#dri-devel]
kzd has joined #dri-devel
youmukonpaku1337 has joined #dri-devel
youmukon1 has quit [Read error: Connection reset by peer]
frieder has quit [Remote host closed the connection]
kzd has quit [Quit: kzd]
junaid has joined #dri-devel
kzd has joined #dri-devel
kzd has quit []
mbrost has joined #dri-devel
kzd has joined #dri-devel
kzd has quit []
Cyrinux9474 has quit []
Cyrinux9474 has joined #dri-devel
Ahuj has quit [Ping timeout: 480 seconds]
Ahuj has joined #dri-devel
Haaninjo has joined #dri-devel
Ahuj has quit [Ping timeout: 480 seconds]
Kayden has quit [Quit: to JF]
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
sukrutb_ has quit []
fab has quit [Quit: fab]
gouchi has joined #dri-devel
Kayden has joined #dri-devel
junaid has quit [Ping timeout: 480 seconds]
kzd has joined #dri-devel
youmukon1 has joined #dri-devel
youmukon1 has quit []
youmukon1 has joined #dri-devel
youmukon1 has quit []
youmukon1 has joined #dri-devel
youmukon1 has quit []
youmukonpaku1337 has quit [Ping timeout: 480 seconds]
heat has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
youmukonpaku1337 has quit [Remote host closed the connection]
youmukonpaku1337 has joined #dri-devel
junaid has quit [Remote host closed the connection]
rasterman has quit [Quit: Gettin' stinky!]
youmukonpaku1337 has quit [Quit: WeeChat 4.0.4]
youmukonpaku1337 has joined #dri-devel
gouchi has quit [Remote host closed the connection]
An0num0us has quit [Ping timeout: 480 seconds]
<karolherbst>
maybe it's something on the kernel side...
Cyrinux9474 has quit []
An0num0us has joined #dri-devel
frankbinns has quit [Remote host closed the connection]
Cyrinux9474 has joined #dri-devel
An0num0us has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
youmukonpaku1337 has quit [Read error: Connection reset by peer]
vliaskov has quit [Remote host closed the connection]
<mareko>
nah, he continues on #radeon
<Sachiel>
just tell him you will also not be a suicidal terrorist
mbrost has quit [Ping timeout: 480 seconds]
<Lynne>
yet another hard enough crash on amd to prevent reisub from working
<Lynne>
does the hardware have enough tools to allow for at least a full reset without restarting the entire system?
<karolherbst>
you shouldn't have to reboot your system, yes
fxkamd has joined #dri-devel
kzd has quit [Quit: kzd]
<Lynne>
something to look forward to, I guess
<Lynne>
how do windows users have less catastrophic crashes like these?
<Lynne>
and how do amd's pro drivers avoid crashing altogether? do they insert sanitation in shaders during compilations?
<bnieuwenhuizen>
amds pro drivers can generally crash just as much
<bnieuwenhuizen>
though difference in userspace drivers and version of the kernel driver can mean you're avoiding specific bugs
<bnieuwenhuizen>
the big issue with amd reset is often loss of VRAM, if you have something more than that, it is likely just the kernel driver being buggy again :|
<bnieuwenhuizen>
(the initial hang is likely userspace issue of the app or userspace driver of course)
<Lynne>
I meant their pro drivers for workstation GPUs, I think they had some guarantees about them not crashing
<bnieuwenhuizen>
linux amdgpu-pro is mostly just the open source amdgpu kernel driver (+ shim to support multiple kernels) + amdvlk (with the LLVM compiler swapped out for their internal one)
<bnieuwenhuizen>
not sure if they have a special distro for pro on linux outside of this these days?
kzd has joined #dri-devel
<bnieuwenhuizen>
windows wise I have no clue
<Lynne>
yeah, I think it was for windows
<bnieuwenhuizen>
might just be a more complete test matrix
<Lynne>
disappointing to hear that amdgpu-pro is just repackaged amdvlk, I was hoping it was another implementation of vulkan video which maybe I could have experimented with
<bnieuwenhuizen>
I mean it may have some extra bits
<Lynne>
ah
<bnieuwenhuizen>
like RT was for the longest time available in amdgpu-pro and not amdvlk
<bnieuwenhuizen>
but if amdvlk has vulkan video I doubt the impl will be meaningfully different on -pro
<bnieuwenhuizen>
(that said, -pro might have some amf bits)
kts has quit [Quit: Leaving]
<Lynne>
yup, pro has amf
<Lynne>
also amdvlk has the hdr bits wired up
<Lynne>
btw, airlied this happened with bwdif_vulkan, I'm guessing something still isn't entirely right, maybe sync-wise
<bnieuwenhuizen>
hdr swapchain bits, or is there something video related?
<Lynne>
the hdr swapchain bits
kzd has quit [Quit: kzd]
Danct12 has quit [Remote host closed the connection]