ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<zmike> DavidHeidelberg[m]: is there any way to see the log for trace jobs? I wanted to look at https://gitlab.freedesktop.org/mesa/mesa/-/jobs/47941379 but there's no info
JohnnyonFlame has joined #dri-devel
heat has joined #dri-devel
Guest431 is now known as nchery
youmukonpaku133 has quit [Read error: Connection reset by peer]
youmukonpaku133 has joined #dri-devel
<anholt> zmike: you mean other than the problems html from the URL it prints to look at?
<anholt> the python doesn't print useful info, it's all in the generated results.
benjaminl has quit [Ping timeout: 480 seconds]
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
youmukonpaku133 has quit [Read error: Connection reset by peer]
youmukonpaku133 has joined #dri-devel
sravn_ has joined #dri-devel
sravn has quit [Ping timeout: 480 seconds]
youmukonpaku133 has quit [Read error: Connection reset by peer]
youmukonpaku133 has joined #dri-devel
enunes has quit [Ping timeout: 480 seconds]
sravn_ has quit [Remote host closed the connection]
sravn_ has joined #dri-devel
yyds has joined #dri-devel
enunes has joined #dri-devel
youmukonpaku133 has quit [Ping timeout: 480 seconds]
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
Daanct12 has joined #dri-devel
oneforall2 has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
crabbedhaloablut has joined #dri-devel
Daanct12 has quit [Quit: WeeChat 4.0.3]
lemonzest has quit [Quit: WeeChat 3.6]
Company has quit [Quit: Leaving]
Daanct12 has joined #dri-devel
lemonzest has joined #dri-devel
lemonzest has quit []
lemonzest has joined #dri-devel
yuq825 has joined #dri-devel
oneforall2 has joined #dri-devel
bmodem has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
sima has joined #dri-devel
fab has joined #dri-devel
bmodem has joined #dri-devel
aravind has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
bgs has joined #dri-devel
zzoon_2 has joined #dri-devel
i-garrison has quit []
i-garrison has joined #dri-devel
Duke`` has joined #dri-devel
youmukonpaku133 has joined #dri-devel
fab has quit [Quit: fab]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
pcercuei has joined #dri-devel
frieder has joined #dri-devel
fab has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
bgs has quit [Remote host closed the connection]
thaytan has quit [Ping timeout: 480 seconds]
<tnt> Does anyone know what intel mean by Q Pitch ?
sgruszka has joined #dri-devel
thaytan has joined #dri-devel
lynxeye has joined #dri-devel
swalker_ has joined #dri-devel
swalker_ is now known as Guest466
fab has quit [Remote host closed the connection]
fab has joined #dri-devel
swalker__ has joined #dri-devel
f11f12 has joined #dri-devel
<austriancoder> karolherbst: thanks - vec8/vec16 are gone now \o/
Guest466 has quit [Ping timeout: 480 seconds]
fab has quit [Read error: Connection reset by peer]
Duke`` has quit [Ping timeout: 480 seconds]
donaldrobson has joined #dri-devel
vliaskov has joined #dri-devel
jkrzyszt has joined #dri-devel
<karolherbst> nice
<karolherbst> I've updated my patch, because there were a few corner cases, not sure if you tried the latest version
<karolherbst> austriancoder: ^^
<karolherbst> ohh, I guess you did
<karolherbst> but yeah, they are also all gone on my end
<austriancoder> karolherbst: pulled your branch about 40 min ago
<karolherbst> I kinda hate how it's done as it relies on copy_prop not being smart enough to reverse the things...
<karolherbst> kinda have to sit down and rethink the entire process, but if you are e.g. before io lowering, you still have vec8/16 derefs and we can't split them up... or if the vec4 is based on anything else which is still a vec8 copy prop might reverse it
<karolherbst> like imagine you have hardware which can do a vec16 load (like if your loads are actually byte based and you can do a 16 byte load, vec1x16)
donaldrobson has quit [Read error: Connection reset by peer]
donaldrobson has joined #dri-devel
ungeskriptet has joined #dri-devel
mripard has joined #dri-devel
kts has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
rgallaispou has joined #dri-devel
JohnnyonFlame has quit [Read error: Connection reset by peer]
fab has joined #dri-devel
_rgallaispou has joined #dri-devel
rgallaispou has quit [Ping timeout: 480 seconds]
zzoon_2 has quit [Remote host closed the connection]
zzoon_2 has joined #dri-devel
_rgallaispou has quit [Quit: WeeChat 4.0.4]
zzoon_2 has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
rasterman has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
<DavidHeidelberg[m]> zmike: it seems like downloaded traces not matching checksum, pretty happy to see that it works sometimes. Otherwise it would run the trace and probably generated incorrect screenshot due to damaged trace. But yes - no logging for piglit.
fab has quit [Quit: fab]
youmukonpaku133 has quit [Ping timeout: 480 seconds]
youmukonpaku133 has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
glennk has quit [Remote host closed the connection]
glennk has joined #dri-devel
<zmike> DavidHeidelberg[m]: not sure exactly what that means?
<zmike> why did it crash
donaldrobson_ has joined #dri-devel
donaldrobson has quit [Ping timeout: 480 seconds]
<DavidHeidelberg[m]> zmike: the downloaded file doesn't match the checksum provided by S3, so the file was (probably) damaged
<DavidHeidelberg[m]> this shouldn't usually happen, maybe some corruption of filesystem on runner
<DavidHeidelberg[m]> zmike: the "crash" here is only wait to communicate here, because it's not fail, pass or timeout
illwieckz has quit [Ping timeout: 480 seconds]
<zmike> ahh ok
<zmike> also would it be possible to change the output to not have the ' at the end of the problems.html link
<DavidHeidelberg[m]> zmike: I have it in not-yet-merged MR :D
<DavidHeidelberg[m]> I got pissed by it few times already :P
bmodem has quit [Ping timeout: 480 seconds]
* DavidHeidelberg[m] sneaked the commit into 6.4 kernel uprev, but there was some fighting with Cheza boards in the last minute before merge :)
JohnnyonFlame has joined #dri-devel
<zmike> it's always bothered me
<zmike> but not enough to do anything about it
<zmike> DavidHeidelberg[m]: also have you had time to look at that blender trace?
<DavidHeidelberg[m]> zmike: would you mind make the trace performance-testing compatible? (3x2 frames)? I checked, it works for me, but crashes iris when I try to replay it in perf mode)
<DavidHeidelberg[m]> if I dropped last frame (which probably does some cleaning) I think it would work
<DavidHeidelberg[m]> s/3x2/initial frame + 3x2)
<zmike> so...7 frames?
<DavidHeidelberg[m]> yup
<DavidHeidelberg[m]> previous Blender traces didn't work reliably in performance testing, but maybe recent Blender builds will be better
<zmike> ok updated
<DavidHeidelberg[m]> nice, look good. loop=1500, no extra memory consumption, 33 fps on Intel.. so far so good
<DavidHeidelberg[m]> hehe, 150 runs 60 fps.. I think I need improve my laptop cooling :D
lynxeye has quit [Quit: Leaving.]
tonyk has quit []
tales-aparecida has quit []
mairacanal has quit []
novaisc has quit [Quit: Ping timeout (120 seconds)]
grillo_02 has joined #dri-devel
grillo_0 has quit [Ping timeout: 480 seconds]
gcarlos has quit [Ping timeout: 480 seconds]
grillo_02 is now known as grillo_0
tales-aparecida has joined #dri-devel
novaisc has joined #dri-devel
tonyk has joined #dri-devel
dviola has quit [Read error: No route to host]
yyds has quit [Remote host closed the connection]
lynxeye has joined #dri-devel
gcarlos has joined #dri-devel
fab has joined #dri-devel
mairacanal has joined #dri-devel
kts has joined #dri-devel
greenjustin_ has joined #dri-devel
Daanct12 has quit [Quit: WeeChat 4.0.4]
thellstrom has joined #dri-devel
crcvxc has quit [Read error: Connection reset by peer]
Duke`` has quit [Ping timeout: 480 seconds]
greenjustin__ has joined #dri-devel
greenjustin_ has quit [Ping timeout: 480 seconds]
yuq825 has quit [Remote host closed the connection]
kts has quit [Quit: Konversation terminated!]
<karolherbst> gfxstrand: I got told, that for Vulkan SPIR-V it's technically valid to use vec8 and vec16? I was kinda under the impression it's all vec4 at most.
<zmike> I'm not sure the first part of that is accurate
<zmike> vec16 is only legal with the Kernel cap, and that cap is not legal in vulkan afaik
<zmike> vec8 is a bit more nebulous, but I imagine if you try to use a vec8 somewhere then vvl will tell you why you can't
mbrost has joined #dri-devel
Duke`` has joined #dri-devel
kzd has joined #dri-devel
Haaninjo has joined #dri-devel
kts has joined #dri-devel
vliaskov has quit [Read error: Connection reset by peer]
mbrost has quit [Ping timeout: 480 seconds]
f11f12 has quit [Quit: Leaving]
bgs has joined #dri-devel
flynnjiang has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
flynnjiang has quit [Remote host closed the connection]
flynnjiang has joined #dri-devel
flynnjiang has quit [Remote host closed the connection]
frieder has quit [Remote host closed the connection]
frieder has joined #dri-devel
guru_ has joined #dri-devel
frieder has quit [Remote host closed the connection]
frieder has joined #dri-devel
idr has quit [Ping timeout: 480 seconds]
guru_ has quit [Remote host closed the connection]
sgruszka has quit [Remote host closed the connection]
illwieckz has joined #dri-devel
frieder has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
frieder has joined #dri-devel
frieder has quit [Remote host closed the connection]
frieder has joined #dri-devel
guru_ has joined #dri-devel
guru_ has quit []
guru_ has joined #dri-devel
oneforall2 has quit [Ping timeout: 480 seconds]
youmukonpaku133 has quit [Ping timeout: 480 seconds]
youmukonpaku133 has joined #dri-devel
benjaminl has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
guru_ has quit []
youmukonpaku133 has quit [Ping timeout: 480 seconds]
oneforall2 has joined #dri-devel
<karolherbst> nah, it's actually in the spir-v spec, it's just a bit hidden :D
<karolherbst> "Vector types must be parameterized only with 2, 3, or 4 components, plus any additional sizes enabled by capabilities."
<zmike> yes
<zmike> that's not hidden
<zmike> and Vector16 requires the Kernel cap
<zmike> Vector8 doesn't seem to exist in the base spirv spec
<karolherbst> well.. you won't find it if you search for "OpTypeVector" :D
<karolherbst> well..
<zmike> sounds like someone needs to improve their spec-fu
<karolherbst> Vector16: Uses OpTypeVector to declare 8 component or 16 component vectors.
<zmike> mm fair enough
<zmike> still not useful
<karolherbst> yeah..
<karolherbst> it's kernel only :)
alyssa has joined #dri-devel
<alyssa> DavidHeidelberg[m]: panfrost-g52-vk job seems slow
kzd_ has joined #dri-devel
<alyssa> given that we've sunsetted the g52 vk experiment (and would remove the code from tree if not for $politics), it really shouldn't be a premerge job imho
<alyssa> (It has 0 users and, unless I'm very mistaken, is not being developed.)
youmukonpaku133 has joined #dri-devel
<zmike> careful, those sound like the words of a panfrost developer
<DavidHeidelberg[m]> Give me numbers or links:) i'll try to look at it today :)
<alyssa> I don't understand why the job is running in pre-merge at all, the driver is not shipped and not intended to be shipped, it's served its purpose
kzd has quit [Ping timeout: 480 seconds]
<zmike> karolherbst: there's a few more in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24839 that seem like they could easily be merged
<DavidHeidelberg[m]> 20min is still +- in 15min range
<karolherbst> probably
<alyssa> DavidHeidelberg[m]: Um, wasn't it a 10 minute limit?
<alyssa> Since when was 20 minutes ok?
<DavidHeidelberg[m]> I guess because it's supported HW?
junaid has joined #dri-devel
<DavidHeidelberg[m]> Nah, we have 15min, but some jobs are ranging 10 - 20
<alyssa> Ok, it should be 10 minutes
<alyssa> Also, the job is super flaky because panvk on g52 is broken
<karolherbst> zmike: you are free to rb any of those patches and I might extract more of them
<alyssa> and again, nobody is going to be fixing it because it's not a developed project
<DavidHeidelberg[m]> Hmmm..... and now back to reality ...
<DavidHeidelberg[m]> Well, then we should remove it from mesa if it has no users
<alyssa> DavidHeidelberg[m]: Yes, at least when I was still at Collabora, that was in the cards
<alyssa> It's being kept in tree because deleting it would cause $problems, but the driver as upstreamed is unused and should not be in CI
<karolherbst> zmike: if you think the global_binding one is in order, then yeah, I guess
<karolherbst> _but_
mripard has quit [Ping timeout: 480 seconds]
<karolherbst> I think it's causing issues with anv
<DavidHeidelberg[m]> daniels: ^^ Alyssa message
<karolherbst> or maybe that was something else
<alyssa> and again, 20 minutes is unacceptable for the job
<alyssa> that's not 20 minutes due to a retry, that's 20 minutes of actual deqp-runner time
<alyssa> if we bumped the expectation from 10 minute limit, that was a mistake.
<zmike> I think 10 has always been aspirational
<DavidHeidelberg[m]> kk, we'll talk about it tomorrow, anyway in worst case I'll xut it to 15
<DavidHeidelberg[m]> *cut
<alyssa> so now that job has flaked after 20 minutes (because panvk is known broken) is now being retried
<alyssa> so that will be 45 minutes for a job that is providing no value
<alyssa> also, for some reasons t860-traces is running too?
<alyssa> since when is that not manual?
<alyssa> does marge run manual jobs now?
<alyssa> I see it listed as panfrost-midgard-manual-rules but it was triggered in https://gitlab.freedesktop.org/mesa/mesa/-/jobs/47991577
<alyssa> frankly i don't know why we have these jobs at all, they're not providing value
<alyssa> but zmike is right, i'm sounding like a panfrost developer
<alyssa> I thought we had a simple rule, jobs go into premerge if we expect them to provide significant value, to take 10 minutes or less of execution time not including setup/teardown overhead, and to be robust against flakes
<alyssa> something like panfrost-g52-vk fails all 3 principles. I dont know why it's there. Adding testing for the sake of adding testing is actively counterproductive.
<alyssa> and we have a lot of that.
<alyssa> but i should shut up before i get yelled at again for acknowledging the problems that lots of people are thinking
<alyssa> so... never mind
<karolherbst> could send an MR to disable it and then we merge it (or something)
<alyssa> mesa ci is perfect, please don't punish me again like last time.
alyssa has left #dri-devel [#dri-devel]
kzd_ has quit [Ping timeout: 480 seconds]
<zmike> karolherbst: I did some other reviews
youmukonpaku133 has quit [Read error: Connection reset by peer]
youmukonpaku133 has joined #dri-devel
<karolherbst> cool, thanks
frieder has quit [Remote host closed the connection]
swalker__ has quit [Remote host closed the connection]
paulk-bis has joined #dri-devel
donaldrobson has joined #dri-devel
JohnnyonF has joined #dri-devel
paulk has quit [Read error: Connection reset by peer]
donaldrobson_ has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<DemiMarie> alyssa: what is the problem with panvk?
<Lynne> does any hardware offer real 8-component vectors anyway?
eukara has quit []
eukara has joined #dri-devel
<jenatali> Fwiw I think the dzn jobs are closer to a 15 minute average, which I was told was fine when deciding what level of fraction to use
donaldrobson has quit [Ping timeout: 480 seconds]
<gfxstrand> Lynne: Some Mali hardware does (-:
<gfxstrand> vec4, f16vec8, and u8vec16 (-:
idr has joined #dri-devel
JohnnyonFlame has joined #dri-devel
<Lynne> what about 16-component vectors?
<DemiMarie> https://github.com/gpuweb/gpuweb/wiki/implementation-status Is there something wrong with GPU drivers on Linux that causes Chrome to disable WebGPU there?
<DemiMarie> And if so, is this specifically the Nvidia problem?
JohnnyonF has quit [Ping timeout: 480 seconds]
<robclark> DemiMarie: given vk's lack of guarantees about undefined behavior, do you _really_ want webgpu enabled without separate sandboxes for the usermode driver?
<DemiMarie> robclark: what makes desktop Linux different than ChromeOS in this regard, especially with lacros?
<DemiMarie> the answer to your question is of course “no”, but desktop Linux being inconsistent with ChromeOS is confusing.
kts has quit [Quit: Konversation terminated!]
<robclark> I guess the main difference w/ CrOS is we know what drivers we ship and are in control of uprev'ing them... I'm also not sure what the status of gpu-process sandbox is w/ chrome/ium on desktop linux
<robclark> (but even in the CrOS case I think we need more hardening)
<DemiMarie> robclark: If you decided “we don’t support WebGPU with X11 or with non-Mesa drivers” I would support that. It’s the inconsistency that is confusing.
mbrost has joined #dri-devel
<robclark> I don't think x11 really changes much.. as much as the random unknown driver thing.. even with mesa drivers we know what versions we ship and can push out an update... that said, I wasn't involved in this decision wrt. linux vs cros, just speculating
<robclark> w/ distro linux, it could be some ancient version of mesa, for ex..
mbrost_ has joined #dri-devel
youmukonpaku133 has quit [Ping timeout: 480 seconds]
youmukonpaku133 has joined #dri-devel
<DemiMarie> robclark: _insert rant about LTS distros here_
<robclark> ;-)
<DemiMarie> Simplest solution for the user-space drivers would be to ship Chromium as a Flatpak and use the up-to-date version of Mesa in the relevant runtime.
<DavidHeidelberg[m]> Demi: that will haunt me in my dreams :D
<DemiMarie> David Heidelberg: what will?
<robclark> webgpu haunts me in my dreams
<DavidHeidelberg[m]> but if I get it right, you can give Chromium flatpak some beta runtime with recent Mesa
mbrost has quit [Ping timeout: 480 seconds]
<DemiMarie> the stable ones do not have recent Mesa? That’s a problem.
Kayden has quit [Quit: to JF]
<DemiMarie> Anyway, I’ll stop so that this does not take away people’s time any more than it has.
<DavidHeidelberg[m]> I've been told you can somehow use the system ones, just haven't took notes how :D
<DavidHeidelberg[m]> *system Mesa3D
<DavidHeidelberg[m]> GPU-Viewer reports 23.1.4
junaid has quit [Ping timeout: 480 seconds]
<robclark> The real thing would be to have webgl/webgpu canvas's spin off their own private sandboxed gpu-process.. we don't really want usermode part of gpu stack to need to be a security barrier
junaid has joined #dri-devel
<robclark> (ofc the sandbox thing itself takes a bit of maintenance and sometimes needs to change with mesa versions)
junaid has quit [Remote host closed the connection]
<DemiMarie> Should Mesa have its own built-in sandbox?
vliaskov has joined #dri-devel
<robclark> I'm not _entirely_ sure how that could work.. I mean if dri_foo.so is dynamically linked against something that hasn't been allowed then we can't even load mesa in the first place.. but there are plenty others who know the mechanics of deploying the sandbox better than I do
<robclark> usually that sort of thing doesn't change _too_ often so it hasn't been enough of a pain point for CrOS to try to come up with something better.. but as they say, patches welcome ;-)
<austriancoder> robclark: had you time to have a look at the isaspec doc poc !23763 ? If we could define what information should be shown how I can spend some time on it
junaid has joined #dri-devel
<robclark> austriancoder: idk if we could generate table, and then example syntax (which might just be dumping the display str w/ instruction name plugged in??).. I think that would be easier to read.. ie:
<austriancoder> robclark: images .. hmm .. lets see
<robclark> (that is from arm arm, fwiw)
sravn_ has quit []
benjamin1 has joined #dri-devel
sravn has joined #dri-devel
benjaminl has quit [Ping timeout: 480 seconds]
benjaminl has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
junaid has quit [Remote host closed the connection]
dviola has joined #dri-devel
junaid has joined #dri-devel
qyliss has quit [Quit: bye]
qyliss has joined #dri-devel
qyliss has quit [Remote host closed the connection]
qyliss has joined #dri-devel
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
youmukonpaku133 has quit [Ping timeout: 480 seconds]
youmukonpaku133 has joined #dri-devel
gouchi has joined #dri-devel
youmukonpaku133 has quit [Ping timeout: 480 seconds]
youmukonpaku133 has joined #dri-devel
crabbedhaloablut has quit []
apteryx has joined #dri-devel
Company has joined #dri-devel
oneforall2 has quit [Read error: No route to host]
oneforall2 has joined #dri-devel
<apteryx> are there free drivers for the likes of Matrox M9128 GPUs?
<Lynne> airlied: ping on the scaling list PR
<gfxstrand> apteryx: Given that that's obviously a server card, it almost certainly on Linux (they wouldn't be able to sell it otherwise) and probably out-of-the-box.
<gfxstrand> apteryx: I wouldn't call it a GPU, though.
oneforall2 has quit [Quit: Leaving]
oneforall2 has joined #dri-devel
<gfxstrand> It looks like pretty much just a display card.
<airlied> yeah I've no idea, matrox kinda fail
<airlied> but a lot of their gpus are now just rebadged other people's gpus
<karolherbst> apparently it supports GL 2.0 :D
<apteryx> karolherbst: if it works without proprietary binary firmware blobs, that's already better than AMD!
<karolherbst> ehhhh....
<karolherbst> no
<apteryx> (for my needs)
<karolherbst> yeah, if you all need a display then yeah.. probably
<gfxstrand> And D3D9!
<karolherbst> though I suspect not on linux
<karolherbst> but also kinda depends on what GPU that actually is
<gfxstrand> But only Windows 7 and earlier because no WDDM2 (-:
<karolherbst> it's probably some old AMD gpu
<karolherbst> or something
<gfxstrand> Could be a GeForce2 or similar
<karolherbst> DDR3 128bit ehhhh
<karolherbst> *DDR2
anujp has quit [Ping timeout: 480 seconds]
<apteryx> gfxstrand: vista support is advertized for what it's worth: https://video.matrox.com/en/media/957/download
<karolherbst> I kinda hate that they just don't say what it is
<apteryx> could still be their own ASIC
<karolherbst> mhhh... maybe
<airlied> could be a g450 in disguise :-P
<karolherbst> maybe it's also just software gl
<airlied> probably one of their P series
<airlied> which they never supported
* apteryx is giving them a call
<karolherbst> would be cursed if they have actual GL and if it is their own ASIC and somebody does write a mesa driver for it
rasterman has quit [Quit: Gettin' stinky!]
anujp has joined #dri-devel
<milek7> >High-resolution two DisplayPort monitor support: Support resolutions up to 2560x1600 per output
<milek7> high resolution, yeah...
<karolherbst> well.. that's a 2012 card
<karolherbst> or something
<ids1024[m]> When they advertise "Native PCI express x16 performance" and Windows XP support, would that be PCIe... gen 1?
youmukonpaku133 has quit [Ping timeout: 480 seconds]
<karolherbst> I wonder what they mean by "native PCI express" though there were a bunch of GPUs which just had a PCIe to PCI bridge on the board
youmukonpaku133 has joined #dri-devel
<apteryx> their 2008 line looks very similar in terms of supported resolutions and memory, and was made of their own ASICs: https://www.techpowerup.com/64033/matrox-introduces-five-new-quadhead-graphics-cards
<ids1024[m]> My interpretation of "Native PCI express x16 performance" is that it actually uses 16 PCIe lanes?
fab has quit [Quit: fab]
<apteryx> couldn't get them on the phone
<apteryx> otherwise from what year did the mainstream GPUs (AMD, nVIDIA) started requiring signed firmware?
bgs has quit [Remote host closed the connection]
<apteryx> seems their latest offering is powered by Intel ARC: https://www.phoronix.com/news/Matrox-Intel-Arc-Graphics
<glennk> apteryx, https://vgamuseum.info/images/demiurge/m9128/img0062.jpg looks like one of the parhelia variants
<apteryx> how hard would it be to make a crappy 2D video card using an FPGA?
<glennk> anything newer than that card from matrox is probably rebranded radeons or geforce
<karolherbst> apteryx: probably easier to use the CPU for that
<karolherbst> (and more power efficient)
<apteryx> karolherbst: I guess that's stops being true the minute I'd want to implement video acceleration?
<karolherbst> depends
<karolherbst> you'd have to compete with modern CPUs or whatever CPU you have with all their SIMD units
<karolherbst> it's probably not hard to be smart about all of it and make it power efficient
<karolherbst> but these days we also don't really have any 2D APIs
<karolherbst> and it's all going through 3D _anyway_
<apteryx> oh!
<karolherbst> I think nvidia is the only GPU vendor still haveing a native 2D interface
<karolherbst> and it hasn't been updated for 10+ years
<karolherbst> so if you want acceleration you have to think about 3D and potentially shaders and....
<apteryx> hm, and that raises the bar for entry
<karolherbst> at which point it's a hell of a project and you'd have to consider if it's worth spending time on :D
<karolherbst> though
<karolherbst> with X you still can get 2D
<karolherbst> but then you need to write your own X driver
<airlied> and it's kinda pointless
<airlied> since most modern stuff uses paths that really need a 3d accel path
Duke`` has quit [Ping timeout: 480 seconds]
<airlied> not seeing anyone implementing Xrender in hw :-P
<karolherbst> I wonder if we could implement Xrender on top of nvidia's 2d stuff :D
<karolherbst> I'm sure nvidia has done it
<airlied> no I don't think their 2d engine is that featureful
<karolherbst> it even has polylines
<airlied> that's ancient X core rendering, not X render
<karolherbst> ahh, fair enough
<karolherbst> so more blending stuff?
<airlied> alpha blending and compositing
<karolherbst> let's see...
<glennk> trapezoids with compositing and masking
<karolherbst> yeah, it supports blending
<karolherbst> it even has two blend modes, but I never fiugred out how to actually use it
<glennk> i think all those methods are firmware emulation
<glennk> shader turtles all the way down
<karolherbst> maybe
<karolherbst> but also not likely
<karolherbst> or maybe it would be
<karolherbst> dunno
<glennk> silicon validation is pricy
<karolherbst> sure, but if you layer it on shaders, why even keep it in hardware?
<glennk> backwards compat for old os:es
kzd has joined #dri-devel
<karolherbst> on newer GPUs?
<karolherbst> also.. nothing talks with it directly, it all goes through drivers
<karolherbst> it also doesn't invalidate any of the 3D or compute state using that stuff
<glennk> host visible state
<karolherbst> given that all state generally lives in buffers, that's hard to believe
<apteryx> seems one approach is going straight to vulkan: https://www.phoronix.com/news/Libre-RISC-V-February-Designing; would that be usuable for a general purpose video card?
<karolherbst> anyway, it makes more sense to be it their dedicated stuff for fast path certain operations
kzd has quit []
<karolherbst> generally in memory
<airlied> apteryx: yeah those guys not really know what's going on
<apteryx> back to the boring real world: I'm recommended this for a cheap, free software friendly GPU: https://www.phoronix.com/review/asus-50-gpu
<apteryx> It seems an AMD RX 580X would also be a fine choice, running the radeon driver
<karolherbst> Intel burned a lot of money on making their CPU ISA viable for 3D
<karolherbst> the conclusion was: don't do it
sima has quit [Ping timeout: 480 seconds]
<karolherbst> anyway
<karolherbst> are they still doing this RISC-V GPU thing or is that abondened?
<karolherbst> ahh, looks like it's dead
<apteryx> this must be keeping Luke's busy: https://redsemiconductor.com/
<apteryx> Luke*
<agd5f> in the R600 days we actually had a set of shaders and that emulated the old 2D engine. You could actually use the old 2D pm4 packets if you loaded the right state and shaders. not sure if it ever got productized.
Kayden has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
Adrinael has quit [Ping timeout: 480 seconds]
<Lynne> karolherbst: there's some EU funded project for a custom from scratch GPU using the PPC ISA
gouchi has quit [Remote host closed the connection]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<airlied> yeah they got distracted into some sort of network accelerator sidetrack as well
<Lynne> as for risc-v, it's still young, give it time, right now there are no CPUs out that you can buy with the vector extension
<Lynne> though I do feel like the vector ISA may be a bit too flexible/rigid for a GPU
<Lynne> they'd have to noop every instruction to set the vector size, and swizzles are afaik not supported
<airlied> yeah like doing a risc-v gpu should really just be more around the effort of an open isa than reusing the risc-v isa
<airlied> and creating a gpu/compute isa
<airlied> that is scalar
Adrinael has joined #dri-devel
junaid has quit [Quit: leaving]
junaid has joined #dri-devel
<Lynne> pretty much all popular RISC ISAs are unsuitable for as a GPU ISA base I think, they all use 32-bit instructions which leaves no room for immediates to allow for swizzles
<Lynne> x86 may still be the most optimal general purpose ISA to build a GPU ISA around, avx 512 has the right ideas about swizzles via k-registers which most instructions support
<Lynne> as long as each wavefront has a decently sized uop cache the decoder footprint wouldn't be larger than a CPU's
<karolherbst> no
<karolherbst> it's not
<karolherbst> the best thing about GPUs ISAs are that they are scalar
<airlied> yeah scalar with subgroup ops seems to be the winner
<karolherbst> you don't need swizzles
<karolherbst> so that's a pointless argument against RISC
<Lynne> really? what about vectors?
<karolherbst> they don't exist
<karolherbst> only in memory load/stores
<karolherbst> thats all
<HdkR> Vectors are a figment of your imagination~ They can't hurt you anymore~
<ccr> "there is no spoon."
<karolherbst> nvidia is purely scalar since nearly forever
benjamin1 has joined #dri-devel
<Lynne> huh, I was under the impression GPUs had vector units for 4-component float vectors
<karolherbst> I think pre nv50 is vectorized?
<karolherbst> Lynne: silly GPUs do
<karolherbst> but scalar GPU ISAs are always the winner
<karolherbst> because vectorized ISA are just evidence of wrong mindset
<Lynne> ah, alright, I stand corrected then, RISC-V is a good base, especially with compressed instructions
<karolherbst> well
<karolherbst> no
<karolherbst> the thing is, that most of the "let's use CPU ISAs on GPUs" miss the point on what makes GPUs fast
<karolherbst> and it's not the ISA
<karolherbst> it's the programming model
<karolherbst> it's a mood point, because running CPUs code on GPUs is a lost battle
<karolherbst> GPU programming model is fast on GPUs, because parallelism is _implicit_
<airlied> wish someone would tell that to luxcore :-P
<karolherbst> like you run a shader per primitive and only think of each primitive of a scalar program
<karolherbst> and the parallelism happens under the hood
<karolherbst> in theory you can do great things even with x86 SIMD units, but you won't achieve it if you are using C as your language
idr has quit [Quit: Leaving]
<karolherbst> because C's programming model maps poorly to GPUs and compilers rely on auto vectorization (which GPUs don't even need)
<Lynne> so what happened to VLIW GPUs?
<karolherbst> they are dead
<gfxstrand> They're a bad idea
<Lynne> they explicitly specify parallelism
<Lynne> what replaced them?
<karolherbst> scalar ISAs
benjaminl has quit [Ping timeout: 480 seconds]
<Lynne> oh, I read implicit as explicit
<karolherbst> ahh, yeah
<karolherbst> Lynne: anyway, I can recommend reading this series of blog posts: https://pharr.org/matt/blog/2018/04/18/ispc-origins it's not _that_ technical, but it explains the problems pretty well and what's the _actual_ problem
<karolherbst> in theory you can also make SIMD ISAs work, they are just pointless and have drawbacks you can't really fix
<karolherbst> at least for GPUs
<airlied> yeah the auto vectorise story is great
* gfxstrand looks at Intel's ISA
<gfxstrand> The "best" SIMD...
<Lynne> thanks, that looks very interesting
junaid has quit [Remote host closed the connection]
<Lynne> why did they split SPIR-V into kernel and non-kernel mode btw? did it have something to do with opencl and silly vector GPUs?
<karolherbst> llvmpipe even uses the masked SIMD instruction thing described later in the series as well
<karolherbst> yeah
<karolherbst> CL is... weird
<karolherbst> so
<karolherbst> the main differences are that CL has vec8/vec16 types
thellstrom has quit [Ping timeout: 480 seconds]
<karolherbst> and that CL doesn't require a structured CFG
<karolherbst> everything else being different are just details
<karolherbst> those are the two major things
<karolherbst> but you can implement CL just fine on Vulkan SPIR-V
<karolherbst> it's just more work
<HdkR> gfxstrand: The best SIMD because you have effectively infinite encoding space to fix past mistakes :P
<Lynne> I still think vectors have a place in GPUs, if you're the type of maniac who hand-writes assembly :)
<karolherbst> no
<karolherbst> it just doesn't make sense for GPUs
<karolherbst> it makes sense for a couple of instructions, but not for general ALU stuff
<karolherbst> the problem is really, what if you can't make use of the full vector hardware? then it's just wasted silicon with no inherent benefit, as evertyhing is already threaded anyway
<karolherbst> high end GPUs run like 10k+ threads at once
<HdkR> Just scale the scalar GPU hardware wider if you need a wider "SIMD" unit :)
<karolherbst> at which point SIMD just doesn't make a difference
<karolherbst> the entire GPU is already a huge "SIMD" unit, you just describe what each of those threads do
<karolherbst> (divergency is bad on GPUs though for this reason)
<Company> so you're saying the maniacs should code stuff with more threads instead of with more SIMD?
<airlied> I did wonder if we should just do an enable "some kernel SPIRV" in vulkan, instead of trying to do all the CL stuff
<Company> like, one thread for each color channel instead of using SIMD for rgba?
<karolherbst> yeah... but...
<airlied> find the most interesting ibts, though I suspect the CL extended instruction set is probably a lot of it
<karolherbst> airlied: though maybe the middle ground is to allow the CL extended instruction set
<karolherbst> but...
<airlied> karolherbst: yes that + vec8/16 but definitely structured cfg :-P
<karolherbst> yeah.. thing is... we can also just handle it in the driver for everybody instead :D
<karolherbst> not if they would do anything different
alyssa has joined #dri-devel
<karolherbst> GPU optimized libclc might be a good argument
<karolherbst> but then you can also just write a vk extension adding that instruction set
<karolherbst> but yeah... we'll see how it turns out
<karolherbst> I really should upstream rusticl on zink and file for official conformance :D
<karolherbst> radv is just being a bit annoying with more crashes then anv or lvp
<karolherbst> *than
<karolherbst> and running on nvidia is kinda slow for whatever reason
crcvxc has joined #dri-devel
<alyssa> karolherbst: ruzticl conformance .. i hope that deprecates clvk >:)
<karolherbst> heh
<karolherbst> I'll just try to be conformant before them
<karolherbst> I think I ignored it for long enough
<karolherbst> this xdc conformant rusticl on zink?
<alyssa> >:)
<alyssa> 30 day window, yeah you could make it
<karolherbst> I don't have _that_ much time
<karolherbst> but also
<karolherbst> I think I need to fix like one or two bugs?
<karolherbst> I'm mostly there
<karolherbst> there are just annoying things to figure out
<karolherbst> "Pass 2374 Fails 69 Crashes 11 Timeouts 0" on anv, where 60 fails are CL_FILTER_NEAREST fails, which the conformance test doesn't check at all
<alyssa> nice
<karolherbst> so 9 fails and 11 crashes out of 2400
<alyssa> karolherbst: when you get a chance btw I want to talk CL on M1 >:)
<karolherbst> radv is causing more issues.. and I manage to crash Nvidia
<karolherbst> alyssa: I should upstream my branch :D
<alyssa> we now have ES3.1 class compute/images + working 8-bit/16-bit/64-bit tested against dEQP-VK
<karolherbst> yeah...
<alyssa> right now the thing I'm most worried about are float controls
<karolherbst> I have it all working
<alyssa> I have no idea if there's flush-to-zero in hardware, if it's always on, never on, if we can control in the driver..
<alyssa> I'm nervous abut those contractions tests
<karolherbst> ohh, that's fine
<alyssa> can't.
<alyssa> won't.
<alyssa> shouldn't.
<karolherbst> you don't need flush-to-zero supported
<karolherbst> it's entirely optional
<alyssa> the problem is that our libclc build assumes ftz
<alyssa> and I don't want to sign up for building a denorm-aware libclc
<karolherbst> ohhh...
<alyssa> for Mali, I had to enable the hardware ftz to pass the contractions tests
<karolherbst> uhhh...
<karolherbst> I don't think I had issues with that?
<alyssa> I know it's not an opencl requirement but I think it effectively is a rusticl one ..
<karolherbst> yeah.. at this point I don't support denorms yet
<alyssa> karolherbst: See b261a185508 ("panfrost: Honour flush-to-zero controls on Valhall")
<bnieuwenhuizen> dcbaker: what happened to 23.2? I see rc2 happened more than 3 weeks ago. Any issues we can help with?
<alyssa> karolherbst: Presumably, you don't see issues because the float_controls_execution_mode is honoured by the underlying drivers
<karolherbst> alyssa: mhh.. I can certainly take another look, now that I have working vec8/16 to vec4 lowering
<alyssa> karolherbst: what's that got to do with anything?
<alyssa> AGX is scalar
<alyssa> vec8 stuff gets lowered via alu_width + mem_width
<karolherbst> not all of it
<karolherbst> uhh
<karolherbst> maybe it does now
<karolherbst> but you were left with some leftoever vec8/16 stuff
<karolherbst> I never bothered checking actually
<karolherbst> anyway
<karolherbst> I have some leftover patches I can submit an MR for
<DavidHeidelberg[m]> btw. Intel gles + vk StarWars tellusim engine crashes on recent mesa (but I have nightly build without debug). Btw. it worked on stable mesa
<DavidHeidelberg[m]> I'll compile with debug and drop logs
<karolherbst> alyssa: though what I really need is a proper agx_get_compute_state_info implementation
<karolherbst> specifically that `max_threads` property
<kisak> DavidHeidelberg[m]: file an issue report on gitlab if it hasn't been already so that your findings aren't buried in the backscroll.
<DavidHeidelberg[m]> kisak: sure sure, I also asked for more update version, if there is any from Tellusim (this is 20221109), anyway still it should work, let me compile one beatiful mesa with intel vk and iris :P
Kayden has quit [Quit: home]
<alyssa> karolherbst: should be easy
<alyssa> In the compiler agx_occupancy_for_register_count gives you the max_threads (grep for it in the src)
<karolherbst> nice
<alyssa> so just need to add that to agx_shader_info and then you'll get the value as part of the agx_compiled_shader
<karolherbst> yeah, that should be good enough
<alyssa> can't 1000% guarantee correctness but it should be a good enough approximation
<karolherbst> the CTS will run into issues if that value is too high
<alyssa> good, I want to hear about those since if I got this wrong, perf will suffer
<illwieckz> speaking about rusticl on zink, once terakan works, would it be possible to use rusticl on zink to get opencl on terascale?
<illwieckz> or the vulkan version/features supported would not be enough?
<karolherbst> uhhh
<karolherbst> if it supports bda
<illwieckz> what's bda?
<karolherbst> real pointers
<illwieckz> ah ok
<karolherbst> which I doubt terascale could support
<karolherbst> not sure
<karolherbst> you kinda need an MMU for that and all that
<illwieckz> now that you say it I feel like I already asked and we already had this conversion 🤷‍♀️️
<karolherbst> because with CL you can use arbitrary pointers
<karolherbst> probably
<illwieckz> the information flows in my brain like if that's not the first time it happened
youmukonpaku133 has quit [Ping timeout: 480 seconds]
kzd has joined #dri-devel
pcercuei has quit [Quit: dodo]
shashanks__ has joined #dri-devel
shashanks_ has quit [Ping timeout: 480 seconds]
crcvxc has quit [charon.oftc.net kinetic.oftc.net]
sravn has quit [charon.oftc.net kinetic.oftc.net]
paulk-bis has quit [charon.oftc.net kinetic.oftc.net]
novaisc has quit [charon.oftc.net kinetic.oftc.net]
tonyk has quit [charon.oftc.net kinetic.oftc.net]
i-garrison has quit [charon.oftc.net kinetic.oftc.net]
enunes has quit [charon.oftc.net kinetic.oftc.net]
ungeskriptet has quit [charon.oftc.net kinetic.oftc.net]
frankbinns1 has quit [charon.oftc.net kinetic.oftc.net]
jenatali has quit [charon.oftc.net kinetic.oftc.net]
Mis012[m]1 has quit [charon.oftc.net kinetic.oftc.net]
Hazematman has quit [charon.oftc.net kinetic.oftc.net]
masush5[m] has quit [charon.oftc.net kinetic.oftc.net]
pushqrdx[m] has quit [charon.oftc.net kinetic.oftc.net]
shoffmeister[m] has quit [charon.oftc.net kinetic.oftc.net]
samueldr has quit [charon.oftc.net kinetic.oftc.net]
swick[m] has quit [charon.oftc.net kinetic.oftc.net]
EricCurtin[m] has quit [charon.oftc.net kinetic.oftc.net]
sergi1 has quit [charon.oftc.net kinetic.oftc.net]
pankart[m] has quit [charon.oftc.net kinetic.oftc.net]
doras has quit [charon.oftc.net kinetic.oftc.net]
Newbyte has quit [charon.oftc.net kinetic.oftc.net]
siddh has quit [charon.oftc.net kinetic.oftc.net]
bylaws has quit [charon.oftc.net kinetic.oftc.net]
exp80[m] has quit [charon.oftc.net kinetic.oftc.net]
moben[m] has quit [charon.oftc.net kinetic.oftc.net]
vidal72[m] has quit [charon.oftc.net kinetic.oftc.net]
Sofi[m] has quit [charon.oftc.net kinetic.oftc.net]
DavidHeidelberg[m] has quit [charon.oftc.net kinetic.oftc.net]
YaLTeR[m] has quit [charon.oftc.net kinetic.oftc.net]
Anson[m] has quit [charon.oftc.net kinetic.oftc.net]
tomeu has quit [charon.oftc.net kinetic.oftc.net]
kallisti5[m] has quit [charon.oftc.net kinetic.oftc.net]
DUOLabs[m] has quit [charon.oftc.net kinetic.oftc.net]
kusma has quit [charon.oftc.net kinetic.oftc.net]
KunalAgarwal[m][m] has quit [charon.oftc.net kinetic.oftc.net]
Ella[m] has quit [charon.oftc.net kinetic.oftc.net]
nick1343[m] has quit [charon.oftc.net kinetic.oftc.net]
gnustomp[m] has quit [charon.oftc.net kinetic.oftc.net]
K0bin[m] has quit [charon.oftc.net kinetic.oftc.net]
lcn_ has joined #dri-devel
skinkie has joined #dri-devel
xerpi[m] has quit [charon.oftc.net kinetic.oftc.net]
ram15[m] has quit [charon.oftc.net kinetic.oftc.net]
lplc has quit [charon.oftc.net kinetic.oftc.net]
linkmauve has quit [charon.oftc.net kinetic.oftc.net]
glehmann has quit [charon.oftc.net kinetic.oftc.net]
dtmrzgl has quit [charon.oftc.net kinetic.oftc.net]
libv has quit [charon.oftc.net kinetic.oftc.net]
mstoeckl has quit [charon.oftc.net kinetic.oftc.net]
phryk has quit [charon.oftc.net kinetic.oftc.net]
aleasto- has quit [charon.oftc.net kinetic.oftc.net]
opotin65 has quit [charon.oftc.net kinetic.oftc.net]
MrCooper has quit [charon.oftc.net kinetic.oftc.net]
rsalvaterra has quit [charon.oftc.net kinetic.oftc.net]
romangg has quit [charon.oftc.net kinetic.oftc.net]
xantoz has quit [charon.oftc.net kinetic.oftc.net]
lumidify has quit [charon.oftc.net kinetic.oftc.net]
Scorpi has quit [charon.oftc.net kinetic.oftc.net]
mriesch has quit [charon.oftc.net kinetic.oftc.net]
any1 has quit [charon.oftc.net kinetic.oftc.net]
Lynne has quit [charon.oftc.net kinetic.oftc.net]
gruetzkopf has quit [charon.oftc.net kinetic.oftc.net]
dliviu has quit [charon.oftc.net kinetic.oftc.net]
xroumegue has quit [charon.oftc.net kinetic.oftc.net]
urja has quit [charon.oftc.net kinetic.oftc.net]
neobrain has quit [charon.oftc.net kinetic.oftc.net]
invertedoftc0969 has quit [charon.oftc.net kinetic.oftc.net]
samuelig has quit [charon.oftc.net kinetic.oftc.net]
hakzsam has quit [charon.oftc.net kinetic.oftc.net]
konstantin has quit [charon.oftc.net kinetic.oftc.net]
gallo72 has quit [charon.oftc.net kinetic.oftc.net]
skinkie_ has quit [charon.oftc.net kinetic.oftc.net]
Rayyan has quit [charon.oftc.net kinetic.oftc.net]
moony has quit [charon.oftc.net kinetic.oftc.net]
tjaalton has quit [charon.oftc.net kinetic.oftc.net]
pa has quit [charon.oftc.net kinetic.oftc.net]
Guest8608 has quit [charon.oftc.net kinetic.oftc.net]
lcn has quit [charon.oftc.net kinetic.oftc.net]
jmondi has quit [charon.oftc.net kinetic.oftc.net]
glennk has quit [charon.oftc.net helix.oftc.net]
milek7 has quit [charon.oftc.net helix.oftc.net]
ajhalaney[m] has quit [charon.oftc.net helix.oftc.net]
zzxyb[m] has quit [charon.oftc.net helix.oftc.net]
naheemsays[m] has quit [charon.oftc.net helix.oftc.net]
Quinten[m] has quit [charon.oftc.net helix.oftc.net]
viciouss[m] has quit [charon.oftc.net helix.oftc.net]
JosExpsito[m] has quit [charon.oftc.net helix.oftc.net]
dabrain34[m]1 has quit [charon.oftc.net helix.oftc.net]
ofirbitt[m] has quit [charon.oftc.net helix.oftc.net]
tales-aparecida has quit [charon.oftc.net helix.oftc.net]
vliaskov has quit [charon.oftc.net helix.oftc.net]
grillo_0 has quit [charon.oftc.net helix.oftc.net]
T_UNIX has quit [charon.oftc.net helix.oftc.net]
znullptr[m] has quit [charon.oftc.net helix.oftc.net]
isinyaaa[m] has quit [charon.oftc.net helix.oftc.net]
nyorain[m] has quit [charon.oftc.net helix.oftc.net]
ella-0[m] has quit [charon.oftc.net helix.oftc.net]
MotiH[m] has quit [charon.oftc.net helix.oftc.net]
fkassabri[m] has quit [charon.oftc.net helix.oftc.net]
kelbaz[m] has quit [charon.oftc.net helix.oftc.net]
nicofee[m] has quit [charon.oftc.net helix.oftc.net]
aradhya7[m] has quit [charon.oftc.net helix.oftc.net]
onox[m] has quit [charon.oftc.net helix.oftc.net]
egalli has quit [charon.oftc.net helix.oftc.net]
nekit[m] has quit [charon.oftc.net helix.oftc.net]
talcohen[m] has quit [charon.oftc.net helix.oftc.net]
exp80 has quit [charon.oftc.net helix.oftc.net]
leandrohrb5 has quit [charon.oftc.net helix.oftc.net]
jeeeun841351 has quit [charon.oftc.net helix.oftc.net]
jfalempe has quit [charon.oftc.net helix.oftc.net]
nuclearcat2 has quit [charon.oftc.net helix.oftc.net]
yoslin has quit [charon.oftc.net helix.oftc.net]
jernej has quit [charon.oftc.net helix.oftc.net]
Kwiboo has quit [charon.oftc.net helix.oftc.net]
lucaceresoli has quit [charon.oftc.net helix.oftc.net]
ndufresne has quit [charon.oftc.net helix.oftc.net]
LaserEyess has quit [charon.oftc.net helix.oftc.net]
bbhtt has quit [charon.oftc.net helix.oftc.net]
fahien has quit [charon.oftc.net helix.oftc.net]
gerddie has quit [charon.oftc.net helix.oftc.net]
deathmist has quit [charon.oftc.net helix.oftc.net]
alarumbe has quit [charon.oftc.net helix.oftc.net]
fdu has quit [charon.oftc.net helix.oftc.net]
marex has quit [charon.oftc.net helix.oftc.net]
kj has quit [charon.oftc.net helix.oftc.net]
cazzacarna has quit [charon.oftc.net helix.oftc.net]
APic has quit [charon.oftc.net helix.oftc.net]
CME has quit [charon.oftc.net helix.oftc.net]
ced117 has quit [charon.oftc.net helix.oftc.net]
tango_ has quit [charon.oftc.net helix.oftc.net]
Prf_Jakob has quit [charon.oftc.net helix.oftc.net]
FLHerne has quit [charon.oftc.net helix.oftc.net]
kgz has quit [charon.oftc.net helix.oftc.net]
kbingham has quit [charon.oftc.net helix.oftc.net]
tjaalton_ has joined #dri-devel
mstoeckl_ has joined #dri-devel
phryk has joined #dri-devel
neobrain has joined #dri-devel
alarumbe has joined #dri-devel
FLHerne has joined #dri-devel
Lynne has joined #dri-devel
xantoz has joined #dri-devel
jmondi has joined #dri-devel
fdu has joined #dri-devel
frankbinns1 has joined #dri-devel
sravn has joined #dri-devel
MrCooper has joined #dri-devel
moony has joined #dri-devel
ungeskriptet has joined #dri-devel
invertedoftc0969 has joined #dri-devel
Prf_Jakob has joined #dri-devel
Rayyan has joined #dri-devel
aleasto has joined #dri-devel
jernej has joined #dri-devel
tango_ has joined #dri-devel
dtmrzgl has joined #dri-devel
ced117 has joined #dri-devel
urja has joined #dri-devel
lplc has joined #dri-devel
deathmist has joined #dri-devel
i-garrison has joined #dri-devel
leandrohrb5 has joined #dri-devel
yoslin has joined #dri-devel
xroumegue has joined #dri-devel
jeeeun841351 has joined #dri-devel
lcn_ is now known as lcn
pa has joined #dri-devel
Kwiboo has joined #dri-devel
CME has joined #dri-devel
milek7 has joined #dri-devel
fahien has joined #dri-devel
glennk has joined #dri-devel
any1 has joined #dri-devel
gruetzkopf has joined #dri-devel
glehmann has joined #dri-devel
paulk-bis has joined #dri-devel
hakzsam has joined #dri-devel
rsalvaterra has joined #dri-devel
ndufresne has joined #dri-devel
vliaskov has joined #dri-devel
novaisc has joined #dri-devel
jfalempe has joined #dri-devel
opotin65 has joined #dri-devel
lucaceresoli has joined #dri-devel
dliviu has joined #dri-devel
APic has joined #dri-devel
cazzacarna has joined #dri-devel
konstantin has joined #dri-devel
mriesch has joined #dri-devel
kbingham has joined #dri-devel
bbhtt has joined #dri-devel
tonyk has joined #dri-devel
thecollaboran36 has joined #dri-devel
LaserEyess has joined #dri-devel
grillo_0 has joined #dri-devel
BobBeck is now known as Guest530
thecollaboran36 is now known as BobBeck
gallo72 has joined #dri-devel
ndufresne is now known as Guest540
bbhtt is now known as Guest531
Rayyan is now known as Guest555
kgz has joined #dri-devel
tales-aparecida has joined #dri-devel
samuelig has joined #dri-devel
exp80 has joined #dri-devel
gerddie has joined #dri-devel
heat has joined #dri-devel
Guest540 is now known as ndufresne
enunes has joined #dri-devel
<karolherbst> do gallium drivers expect the frontend to call nir_lower_pack?
nuclearcat2 has joined #dri-devel
<karolherbst> at least the glsl linker does it mhhh...
libv has joined #dri-devel
marex has joined #dri-devel
lumidify has joined #dri-devel
kj has joined #dri-devel
<karolherbst> at least zink seems to expect that..
Scorpi has joined #dri-devel
youmukonpaku133 has joined #dri-devel
romangg has joined #dri-devel
JohnnyonFlame has joined #dri-devel
greenjustin__ has quit [Ping timeout: 480 seconds]
alyssa has quit [Quit: alyssa]
oneforall2 has quit [Ping timeout: 480 seconds]
Kayden has joined #dri-devel
<Lynne> airlied: tests passed, but I think someone needs to press the rebase button