<ishitatsuyuki>
if you have AMDVLK, uninstall it for sanity
<boofiboi>
yeah i dont even have amdvlko
<boofiboi>
amdvlk*
<ishitatsuyuki>
would be a good idea to check if you have RT capabilities in vulkaninfo first
<boofiboi>
Whats the ext name for that
<boofiboi>
VK_KHR_RAY?
<ishitatsuyuki>
VK_KHR_ray_{query,pipeline} but yes
<boofiboi>
Nope, grep returns nothing on that
<ishitatsuyuki>
actually doesn't work on my end too
<ishitatsuyuki>
lemme see why
<boofiboi>
yeah ikr
<boofiboi>
I played a bit of q2rtx the first time i tested it and now it isnt working for some reason
<boofiboi>
maybe the patch got removed?
<ishitatsuyuki>
I don't think so, might be some new ext
<ishitatsuyuki>
it got renamed
<ishitatsuyuki>
set RADV_PERFTEST=rt,emulate_rt instead
<boofiboi>
okay lemme try that
<boofiboi>
Oh yeah that works
<ishitatsuyuki>
if you can bother with looking at the source code, extension eligibility is described in radv_device.c at around line 400
<ishitatsuyuki>
you can then dig the condition from there :)
kts has quit [Ping timeout: 480 seconds]
boofiboi has quit [Remote host closed the connection]
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #dri-devel
boofiboi has joined #dri-devel
<boofiboi>
So I rebooted my PC cause my audio wasnt working
<boofiboi>
And i was hyped for doom eternal to work with it but it doesnt :D
<boofiboi>
Any idea on that? It should technically work as its Vulkan and it targets ray_query
<ishitatsuyuki>
what does it say
<boofiboi>
It doesnt even let me select the Ray Tracing option
Haaninjo has joined #dri-devel
<ishitatsuyuki>
no idea, try issue tracker or general google search
<boofiboi>
Lol turning on colorblind mode enables the option
<boofiboi>
But it crashes
<boofiboi>
Okay im gonna make an issue on the tracket
<boofiboi>
tracker
Akari has quit [Read error: Connection reset by peer]
Akari has joined #dri-devel
<boofiboi>
Oh my god lutris didnt save the environment variables
srslypascal has quit [Quit: Leaving]
sravn has joined #dri-devel
gouchi has joined #dri-devel
arisu has joined #dri-devel
Andy[m]1 has joined #dri-devel
Grillo[m] has joined #dri-devel
aura[m] has joined #dri-devel
bluepqnuin has joined #dri-devel
bylaws has joined #dri-devel
chema has joined #dri-devel
RAOF has joined #dri-devel
cleverca22[m] has joined #dri-devel
cmeissl[m] has joined #dri-devel
Eighth_Doctor has joined #dri-devel
cwfitzgerald[m] has joined #dri-devel
dafna33[m] has joined #dri-devel
dcbaker has joined #dri-devel
DemiMarieObenour[m] has joined #dri-devel
Anson[m] has joined #dri-devel
Guest586 has joined #dri-devel
doras has joined #dri-devel
danylo has joined #dri-devel
Dylanger has joined #dri-devel
EricCurtin[m] has joined #dri-devel
egalli has joined #dri-devel
ella-0[m] has joined #dri-devel
Ella[m] has joined #dri-devel
AlexisHernndezGuzmn[m] has joined #dri-devel
GeorgesStavracasfeaneron[m] has joined #dri-devel
frytaped[m] has joined #dri-devel
gallo[m] has joined #dri-devel
gdevi has joined #dri-devel
gnustomp[m] has joined #dri-devel
Guest603 has joined #dri-devel
halfline[m] has joined #dri-devel
hasebastian[m] has joined #dri-devel
hch12907 has joined #dri-devel
heftig has joined #dri-devel
zzoon[m] has joined #dri-devel
jasuarez has joined #dri-devel
Jean[m]1 has joined #dri-devel
jekstrand[m] has joined #dri-devel
jenatali has joined #dri-devel
JosExpsito[m] has joined #dri-devel
kallisti5[m] has joined #dri-devel
kunal10710[m] has joined #dri-devel
kunal_10185[m] has joined #dri-devel
kunal_1072002[m] has joined #dri-devel
KunalAgarwal[m][m] has joined #dri-devel
kusma has joined #dri-devel
Labnan[m] has joined #dri-devel
LaughingMan[m] has joined #dri-devel
mairacanal[m] has joined #dri-devel
martijnbraam has joined #dri-devel
masush5[m] has joined #dri-devel
Mershl[m] has joined #dri-devel
michael5050[m] has joined #dri-devel
Mis012[m] has joined #dri-devel
moben[m] has joined #dri-devel
mripard has joined #dri-devel
Vin[m] has joined #dri-devel
naheemsays[m] has joined #dri-devel
neobrain[m] has joined #dri-devel
Newbyte has joined #dri-devel
eyearesee has joined #dri-devel
nielsdg has joined #dri-devel
Nirvin[m] has joined #dri-devel
nyorain[m] has joined #dri-devel
DavidHeidelberg[m] has joined #dri-devel
onox[m] has joined #dri-devel
pac85[m] has joined #dri-devel
PiGLDN[m] has joined #dri-devel
pmoreau has joined #dri-devel
pushqrdx[m] has joined #dri-devel
r[m] has joined #dri-devel
ralf1307[theythem][m] has joined #dri-devel
ramacassis[m] has joined #dri-devel
reactormonk[m] has joined #dri-devel
robertmader[m] has joined #dri-devel
robertfoss[m] has joined #dri-devel
sigmoidfunc[m] has joined #dri-devel
sjfricke[m] has joined #dri-devel
Strit[m] has joined #dri-devel
Sumera[m] has joined #dri-devel
knr has joined #dri-devel
T_UNIX has joined #dri-devel
tintou has joined #dri-devel
underpantsgnome[m] has joined #dri-devel
tleydxdy has joined #dri-devel
tomba has joined #dri-devel
Tooniis[m] has joined #dri-devel
undvasistas[m] has joined #dri-devel
Soroush has joined #dri-devel
viciouss[m] has joined #dri-devel
MatrixTravelerbot[m]1 has joined #dri-devel
Weiss-Fder[m] has joined #dri-devel
x512[m] has joined #dri-devel
xerpi[m] has joined #dri-devel
YaLTeR[m] has joined #dri-devel
yshui` has joined #dri-devel
zamundaaa[m] has joined #dri-devel
znullptr[m] has joined #dri-devel
pmoreau is now known as Guest617
<boofiboi>
lol?
JohnnyonFlame has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
sleber_ has joined #dri-devel
sleber has quit [Ping timeout: 480 seconds]
CounterPillow has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
CounterPillow has joined #dri-devel
alanc has joined #dri-devel
iive has joined #dri-devel
Lucretia has quit [Read error: Connection reset by peer]
Lucretia has joined #dri-devel
sleber has joined #dri-devel
fxkamd has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
sleber_ has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
srslypascal has joined #dri-devel
boofiboi has quit [Ping timeout: 480 seconds]
eukara has quit []
mhenning has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
tobiasjakobi has joined #dri-devel
sleber has quit [Remote host closed the connection]
<Lyude>
MrCooper: did it? I thought I remembered there being a lot of resistance with the DC stuff going upstream
<Lyude>
hopefully i haven't been misremembering this, that's entirely possible
fxkamd has quit []
apinheiro has joined #dri-devel
<airlied>
robclark: btw be careful about exposing GL4.5 on freedreno if you haven't passed conformance
<airlied>
robclark: either add a warning that is a non-conformant impl or stick to 4.3 at the highest until you pass conformance
sysescool_ has quit [Remote host closed the connection]
sysescool_ has joined #dri-devel
srslypascal is now known as Guest650
srslypascal has joined #dri-devel
Guest650 has quit [Ping timeout: 480 seconds]
dcz_ has quit [Ping timeout: 480 seconds]
DemiMarieObenour[m] is now known as DemiMarie
fab has joined #dri-devel
JohnnyonF has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
imre has quit [Ping timeout: 480 seconds]
apinheiro has quit [Ping timeout: 480 seconds]
gouchi has quit [Remote host closed the connection]
mszyprow has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
<robclark>
airlied: hmm, that is slightly annoying for gallium drivers, since they don't know the api.. we shouldn't limit things to gl43 (at least on main, maybe it is ok on release branch) because that would reduce CI coverage. I suppose I could add a separate pipe cap for conformant GLSL version, or something along those lines, so mesa/st could print the appropriate warning.. idk, but not going to spend too much time thinking about that on a
<robclark>
sun afternoon ;-)
<jenatali>
airlied: Out of curiosity, what's your concern? Wondering if we need to do similar and limit ourselves until we redo conformance
mszyprow has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
lemonzest has quit [Quit: WeeChat 3.6]
* robclark
wonders what "conformance" actually means for layered drivers
<airlied>
jenatali: Khronos has explicit rules about conformance and advertising GL 4.4 and 4.5
<airlied>
they never had those rules before that point
<airlied>
robclark: nouveau does it somehow
pcercuei has quit [Read error: Connection reset by peer]
<jenatali>
airlied: Ah thanks, didn't know that
pcercuei has joined #dri-devel
<karolherbst>
uhhh.... please don't remember me about GL conformance on nouveau
<airlied>
I think adding a warning might also be okay
<jenatali>
robclark: For CL and GL we worked with them to add a definition
<airlied>
though re-reading the wording, they say for 3.3 and above you should submit
<jenatali>
IIRC it's two passing results on two different underlying drivers, at most one of which is software, and for CL it was added that if you want to claim conformance across CPU architectures you have to have results on multiple architectures
<robclark>
airlied: I don't see anything obvious in nouveau.. but then again nouveau probably doesn't care as much about gles vs gl
<karolherbst>
you can just force the GL version and are fine
<jenatali>
I should really do a 4.2 submission at some point... I think MSFT is an adopter for up to 4.4 IIRC
<airlied>
robclark: I think it just does GLSL version limits
<airlied>
so that forces the context version
<robclark>
karolherbst: yes, but no.. you also need to override individual extensions which is a pita
<karolherbst>
afaik you don't
<karolherbst>
those are all exposed already
<airlied>
robclark: if you limit the 4.3 glsl then you don't have to do anythng else
<karolherbst>
we even expose the SPIR-V ext, but are still on 4.3
<robclark>
airlied: correct, but glsl override doesn't control glsl version dependent extensions/limits that mesa/st exposes
<karolherbst>
heck, stuff is even fully implemented, but weirdo random bugs and *sigh*
<karolherbst>
which don't exist after 4.3 afaik
<robclark>
either adding new pipe cap or release branch patches to control the glsl version seem like the two least-bad options, IMHO.. but I haven't thought about it for too long (see previous comment about it being Sun afternoon)
<karolherbst>
what extension do you think would be left out if you force the version? But sure, you could also add another env var which overrides on the pipe cap level or something
<robclark>
OTOH khr advertises a list of conformant impls so maybe that is enough of a reason to not care, ie. someone can easily enough check the list to see if they are getting conformant vs hobbiest version ;-)
<karolherbst>
yeah well.. if you flip the switch for freedreno without being officiall conformant then I might as well expose 4.6 for nouveau
<airlied>
robclark: you can also just add a non-conformant cap maybe
<airlied>
and just have the version string say non-conformant or something
<airlied>
or have mesa/st emit a warning
<karolherbst>
or maybe just ask on the next GL group meeting what khronos would prefer?
<karolherbst>
should probably figure out the rules here or whatever
<airlied>
it also depends if you are getting conformance via X.org or company I suppose how you should ask
<karolherbst>
probably
<airlied>
I think in theory GLES has the same rules
<robclark>
karolherbst: check st_init_extensions() but a lot of extension decisions are based on non-overridden GLSL version.. re: nouveau gl46, I'm not exposing anything which completely doesn't work (and nouveau shouldn't either but if it mostly works modulo some random bugs, go for it).. my caring about desktop gl is really only with my weekend/hobbiest hat on, $dayjob really doesn't care about desktop gl ;-)
<karolherbst>
4.6 works on nouveau
<robclark>
airlied: yeah, non-conformant cap, or conformant-glsl-version cap was what I was kind thinking
<robclark>
airlied: as far as desktop gl conformance, that would probably be x.org, CrOS (modulo a small subset of x86 devices that support steam) don't really care so much about gl
<airlied>
but yeah someone could bring it up on a call and see, the wording around adopters is kinda nebulous, and what advertising GL 4.5 is
<karolherbst>
yeah, and nothing checks againts >=440 or anything higher inside st_init_extensions
<airlied>
like is glxinfo showing it, advertising it? I don't know
<karolherbst>
410 being like the highest check
<robclark>
heheh, we could patch glxinfo to show version # in quotes on drivers without conformance submission
<DemiMarie>
Which DRM drivers do not zero memory before assigning it to another process?
<robclark>
anyways, my main care-about is keeping it exposed on main so we have the CI coverage
<karolherbst>
DemiMarie: probably all with discrete mem
<karolherbst>
maybe intel doesn't, dunno
<karolherbst>
I'm not going into this bikeshed ever again
<DemiMarie>
karolherbst: just asking so I know where to file bugs
<robclark>
newly allocated shmem buffers should be zero'd, last I checked
<karolherbst>
uhh.. good question. Maybe just try it out and file if you hit it?
<robclark>
not sure about ttm
<karolherbst>
not shmem
<karolherbst>
literally just mem allocs
<karolherbst>
if you give me a tool, I can verify on amdgpu and nouveau
<karolherbst>
tomorrow or something
<DemiMarie>
shmem = CPU allocated buffers?
<karolherbst>
sh as in shared
<DemiMarie>
Ah okay
<DemiMarie>
Are there plans to add some sort of generic GPU virtualization support?
<karolherbst>
maybe I even have this old "exploit" (more like demo app, lol) which could retrieve old VRAM
<DemiMarie>
I remember hearing about them but wanted to check
<DemiMarie>
does that run the compiler on the host?
<DemiMarie>
looks like huge attack surface to me
<DemiMarie>
unless somehow it is smaller than the actual driver
<airlied>
have at it
<DemiMarie>
would it be accurate to say that strong isolation is not a priority for most DRM drivers?
<karolherbst>
I hope virgl at least zeroes VRAM?
<airlied>
virgl has no idea about vram
<robclark>
it is running the native gl (or vk) driver on the host.. and yes, that is a big attack surface.. there are other less generic options which are better in that regard but you asked about "generic GPU virtualization" ;-)
<karolherbst>
I mean like GL memory allocations
Haaninjo has quit [Quit: Ex-Chat]
<robclark>
karolherbst: if you care about security you don't run a GL driver in the VMM, so zero'ing your buffers is the least of your concerns ;-)
<DemiMarie>
robclark: which ones are you referring to? by “generic“, I mean “runs on hardware people actually have, using drivers that are (or will soon be) upstreamed”
<karolherbst>
right... just hope nobody uses virgl in production then
<DemiMarie>
robclark karolherbst: ChromeOS does
<airlied>
nobody that cares about container esacpes
<karolherbst>
"oops"
<airlied>
it's not a problem if you vm space is as trusted as your non-vm space
<robclark>
by "generic" I mean runs on any hw that supports GL, which is not (yet) true for ^^^
<DemiMarie>
airlied: IIUC crosvm explicitly considers the guest to be untrusted
<karolherbst>
anyway, not discussing this topic, because apparently nobody is willing to accept uncleared VRAM allocations as bugs
<karolherbst>
somebody should just try and file CVEs, probably the best course of action here
<airlied>
or write a good exploit
<karolherbst>
or that
<airlied>
not sure how to exploit it in a generically useful manner
tobiasjakobi has quit []
<robclark>
airlied: running gl/vrend in your vmm is a big problem if you care about guest<->guest process escapes.. you are running all your guest processes in same gpu address space and vrend has access to all guest memory.. it is fine if you are only concerned about protecting host from guest, but it pretty much sucks if you care about protecting different processes in guest from one another
<DemiMarie>
karolherbst: who would be the appropriate CVE Numbering Authority (CNA)?
<karolherbst>
airlied: probably AI and scan for interesting infos, like credit card info and upload on hits
<karolherbst>
but yeah..
<karolherbst>
needs like running stuff and so on
<karolherbst>
DemiMarie: dunno.. probably would need an exploit which does weird things first
<karolherbst>
and none of them will be interesting enough as you pretty much rely on RCE
<karolherbst>
or you install dubious games on steam
<DemiMarie>
karolherbst: at least in my experience a proof of concept is sufficient, and at least Snap on Ubuntu is considered a defended security boundary
<karolherbst>
yeah.. if you can make it work from within snap, great
<karolherbst>
I'm not in the position to say how bad or not bad that problem is, that's better left to experts. Just it feels like a potential big one which nobody probably abuses yet
<illwieckz>
I always find it weird when I load a broken GLSL shader and the game draw over what looks like a screenshot of my terminals (or just draw it), I sometime wonder what happens if a third-party app do that on purpose, dump the framebuffer as an image and run an OCR on the dumped image.
<illwieckz>
In fact right now both Chromium and Firefox display garbage from other apps on GNOME Shell, either at startup (Chromium), either on compositor restart (Firefox), but that may be the GNOME Shell compositor displaying the garbage until Chromium/Firefox actually (re)draw. Anyway recently whatever which piece of software displays uninitialized video memory, recently people started to tell me their browser looked broken and buggy.