alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
pcercuei has quit [Quit: dodo]
pa has quit [Ping timeout: 480 seconds]
co1umbarius has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
columbarius has quit [Ping timeout: 480 seconds]
flynnjiang has joined #dri-devel
maxzor has quit [Remote host closed the connection]
maxzor has joined #dri-devel
yyds has joined #dri-devel
kts has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
maxzor has quit [Ping timeout: 480 seconds]
flynnjiang has quit [Read error: Connection reset by peer]
heat has quit [Ping timeout: 480 seconds]
seninha has joined #dri-devel
seninha has left #dri-devel [#dri-devel]
macromorgan has quit [Read error: Connection reset by peer]
pa has joined #dri-devel
Company has quit [Quit: Leaving]
kts has quit [Ping timeout: 480 seconds]
macromorgan has joined #dri-devel
<DemiMarie>
If someone could exploit Firefox or Chromium by using WebGL or WebGPU to trigger a bug in Mesa, would this be a Mesa vulnerability or a Firefox/Chromium vulnerability?
<DemiMarie>
I don’t think “only receives trusted input” is a reasonable assumption for Mesa’s compilers anymore, unless browsers all switch to having 1 GPU process per origin.
<DemiMarie>
In this (hypothetical) example, there is certainly a vulnerability somewhere (website can compromise end user’s system) and certainly a bug in Mesa (undefined behavior triggered via valid API usage).
Daanct12 has joined #dri-devel
aravind has joined #dri-devel
bmodem has joined #dri-devel
<jenatali>
FWIW the Windows team's perspective is that a graphics API isn't a security boundary. Security needs to be managed at the web, kernel, or hardware levels
macslayer has quit [Ping timeout: 480 seconds]
<immibis>
that makes no sense from a principled perspective
<immibis>
or is it a "kernel-coloured glasses" problem?
<immibis>
i.e. from a kernel perspective, the kernel can't stop the graphics API having vulns - kernel security boundaries are processes and tokens. But from a graphics API perspective, API calls should only draw on the screen, not format your hard disk
crabbedhaloablut has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
bmodem has quit [Excess Flood]
bmodem has joined #dri-devel
glennk has joined #dri-devel
Duke`` has joined #dri-devel
flynnjiang has joined #dri-devel
HerrSpliet has joined #dri-devel
RSpliet has quit [Read error: Connection reset by peer]
fab has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
flynnjiang1 has joined #dri-devel
flynnjiang has quit [Read error: Connection reset by peer]
i-garrison has quit [Remote host closed the connection]
i-garrison has joined #dri-devel
flynnjiang has joined #dri-devel
flynnjiang1 has quit [Read error: Connection reset by peer]
ungeskriptet has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
fab has quit [Quit: fab]
kts has quit [Ping timeout: 480 seconds]
sima has joined #dri-devel
itoral has joined #dri-devel
tzimmermann has joined #dri-devel
frieder has joined #dri-devel
i509vcb has quit [Quit: Connection closed for inactivity]
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
fab has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
bmodem has quit [Excess Flood]
bmodem has joined #dri-devel
sgruszka has joined #dri-devel
rasterman has joined #dri-devel
flynnjiang has quit [Ping timeout: 480 seconds]
jsa has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
mripard has joined #dri-devel
jsa has quit []
<mripard>
sima: so, there's a missing SoB (from the committer) in drm-misc-next, for one of our patches. What should we do about it?
<dj-death>
sorry to probably ask again
jsa has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
<dj-death>
in the DGC extension, each group of token (containing elements like VkBindIndexBufferIndirectCommandNV, etc...) is stored in the stream buffer given by VkGeneratedCommandsInfoNV::pStreams
<dj-death>
where is the stride between each of those group of token?
heat has joined #dri-devel
bmodem has joined #dri-devel
bmodem has quit [Excess Flood]
bmodem has joined #dri-devel
bmodem has quit [Excess Flood]
bmodem has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
<sima>
mripard, uh that would generally mean someone pushed ignoring dim ...
<sima>
or a bug in dim
<sima>
imo debug with the committer why this happened
<sima>
and then just leave it at that (with the missing sob supplied on the m-l maybe) since we can't really rebase drm-misc-next for this
<sima>
I guess we might need to add cherry-pick to the list of things that are off-limits for committers in that bullet I quoted ...
aravind has joined #dri-devel
<mripard>
yeah, it looks to me that it's not clear to most
jsa has quit [Read error: Connection reset by peer]
bmodem has quit [Ping timeout: 480 seconds]
<javierm>
sima: another advantage of using dim cherr-pick is that it traverses the Fixes: and wanrs you if you need to cherry-pick another fix (because the "fix" caused a regression too)
<sima>
javierm, yeah, but cherry-pick is more meant for adding a bugfix to -fixes that landed in -next first
<sima>
the other way round really should be a backmerge with explainer what you're pulling in & why
bmodem has joined #dri-devel
<javierm>
sima: ah, I see. Yeah, I don't think that cherry-picks should be done in -next
vliaskov has joined #dri-devel
<javierm>
but backmerges as mripard and you said
<sima>
javierm, but we also have dim backmerge with some checks, so "use dim" still applies :-)
<javierm>
sima: yeah :)
Kayden has quit [Remote host closed the connection]
<jfalempe>
for VGA, as it's not possible to know reliably if something is connected, the BMC virtual connector has no added value.
<tzimmermann>
jfalempe, the bmc comes with any connector
<tzimmermann>
i'm going to rework the connector code
<tzimmermann>
i guess, we have to go back to your original proposal and support the bmc transparently
bmodem has quit [Ping timeout: 480 seconds]
<tzimmermann>
for vga, if we detect an EDID, we assume a monitor, otherwise not. and if theres no monitor, we return the bmc resolutions
<tzimmermann>
i'm not so super happy about user space failing us, but well
<jfalempe>
I though there was some VGA monitor without EDID.
<tzimmermann>
what?
<tzimmermann>
back to the 80s!
<mripard>
also, some VGA cables don't have the DDC signals wired
<tzimmermann>
userspace ignoring anything but the first connector would probably already resolve the issue
<tzimmermann>
we'd still get the bmc resolutions
jkrzyszt has joined #dri-devel
<tzimmermann>
otherwise it'd would just be 1024x768
flynnjiang has joined #dri-devel
<tzimmermann>
i though the original problem was that this rsolution was too low?
<jfalempe>
the original problem is with DP output. if nothing is connected, it set 640x480
<tzimmermann>
that's really a bit low
<tzimmermann>
640x480 was the DP standard's default, right?
<jfalempe>
tzimmermann, yes it's the default from the standard. But most monitors fails with 640x480, and works with 1024x768
dliviu has quit [Ping timeout: 480 seconds]
<tzimmermann>
monitors cannot do 640x480 any more?
<jfalempe>
at least some of them don't.
dliviu has joined #dri-devel
donaldrobson has joined #dri-devel
<jfalempe>
and some userspace don't support 640x480, notably the anaconda installer.
flynnjiang1 has joined #dri-devel
<tzimmermann>
jfalempe, i want to rework the connector code anyway. i'd post a patchset soonish. for non-DP we'll see what we can do. having consistent behaviour would be nice, of course
<tzimmermann>
maybe someone from gnome meanwhile reacts to the ticket
flynnjiang has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
tzimmermann has joined #dri-devel
<jfalempe>
tzimmermann, sounds good. yes a fix in mutter would be good too.
itoral has quit [Ping timeout: 480 seconds]
heat has quit [Ping timeout: 480 seconds]
crabbedhaloablut has quit []
Ahuj has joined #dri-devel
crabbedhaloablut has joined #dri-devel
itoral has joined #dri-devel
HerrSpliet is now known as RSpliet
<tzimmermann>
jfalempe, FYI i've just asked in irc://irc.gnome.org/gnome about the problem
Kayden has joined #dri-devel
<MrCooper>
tzimmermann: FYI, the canonical GNOME channels are on Matrix, the IRC ones currently aren't bridged
<tzimmermann>
MrCooper, thanks
flynnjiang1 has quit []
<jfalempe>
tzimmermann, another way to fix that would be to report the BMC virtual connector as "connected" only when the other connector is disconnected. That way only one connector would be on at a time.
<tzimmermann>
depends on gnome. IDK if gnome 'understands' that
<emersion>
it should…
<tzimmermann>
i mean, even if the connector is disconnected, it is still there
<emersion>
yeah
<emersion>
that's a common thing
<tzimmermann>
gnome still seess two conenctors
digetx_ has quit [Ping timeout: 480 seconds]
digetx has joined #dri-devel
<emersion>
on your laptop maybe you have a DP and HDMI connectors, without anything plugged in userspace still sees them as disconnected
<emersion>
yet userspace doesn't go and try to use them
<tzimmermann>
i can easily test this here by hard-coding the bmc to disconnected. give me a minute...
<jfalempe>
that way we can even report more resolutions as valid, when the bmc connector is "connected"
<MrCooper>
tzimmermann: mutter doesn't try to use disconnected connectors
<eric_engestrom>
MrCooper: ack, and thanks for the ping :)
<emersion>
eric_engestrom: how should i go about marking a series of commits which should be backported, with only the last commit actually fixing a bug?
<emersion>
Fixes for all?
<eric_engestrom>
I would say `cc: mesa-stable` for those that only need to be backported because of the one with `fixes: $commit`
<emersion>
ack
<eric_engestrom>
`fixes:` for all would be a bit "wrong" IMO
<eric_engestrom>
since these don't actually do a fix
<emersion>
indeed
<emersion>
but it would make it easier to know which stable branches they should be backported to
<emersion>
like, there's a chance to misunderstood this, backporting all Cc commits to all branches, and Fixes to the last one only
<tzimmermann>
sounds like a good idea then. if that works, we can adopt it with a lengthy comment explaining the thing.
<emersion>
hm actually it sounds like Backport-to is the thing to use now?
<MrCooper>
eric_engestrom: no worries; JosExpsito[m]1 is going to create an MR to fix it
kxkamil2 has quit []
kxkamil has joined #dri-devel
<eric_engestrom>
emersion: cc goes to all active stable branches, fixes goes to all active stable branches *that contain the fixed commit* (or a backport thereof)
<emersion>
right, so cc isn't good here
<emersion>
i've done Backport-to with an explicit version number
<eric_engestrom>
and yeah, we added backport-to: to make it only backport to specific branches, but there's a bug in that code that I haven't had time to fix yet so I have to check for that one manually right now to make sure I'm not missing anything tagged with that
<emersion>
hm
<emersion>
well, just let me know what you prefer. the tl;dr is that everything should be only backported to 23.3
<sima>
tzimmermann, jfalempe I think if we do a hack in the kernel then default to off modparam would be good
<sima>
really not super keen to encode this as uapi expectations because gnome dies
<sima>
maybe airlied has a different take (when he's back from lpc)
<sima>
tzimmermann, we could also do a drm knob where you only get a maximum of #crtc of connectors reporting as connected
<sima>
since the bug can happen in other drivers too
<sima>
drm.limit_connector_to_crtc or something like that
<eric_engestrom>
emersion: since you're specifying a single branch in your `backport-to:` it should work (the bug is when you have multiple of it) but I'll make sure it's backported 👍
<emersion>
ok thx!
maxzor has joined #dri-devel
<jfalempe>
sima, I see this as a temporary fix, the time for userspace to handle this case. As the BMC connector is already in 6.6, this can avoid breaking user's expectation.
<javierm>
jfalempe: there's nothing more permanent than a temporary fix :)
<MrCooper>
sima: I'd say in this particular case it makes sense by default, since the BMC connector was only added for when the real connector isn't connected in the first place
<sima>
ah if it was added then yeah we've hit the inglorious "it's a regression rule" ...
<sima>
still means that if we put this in now it's probably going to be forever :-/
<jfalempe>
yeah, and it's probably there for a long time already.
<javierm>
sima: agreed. But according to MrCooper it may be the correct thing to do (if is meant to only be connected when the other connector is not connected)
<emersion>
it all depends if the use-case have having both connectors displaying the output at the sae time is important to you
<emersion>
same*
<jfalempe>
using BMC and the real monitor at the same time is very unlikely.
<emersion>
right, so sounds reasonable to just have one of the two marked as connected then
tyalie has quit []
tyalie has joined #dri-devel
<tintou>
Do we know who is pushing the Mesa builds to Coverity?
<MrCooper>
emersion: the BMC connector doesn't actually do anything, it's just so that generic user space doesn't fail to start up when the real connector isn't connected, so remote access via the BMC works
<emersion>
... really?
<emersion>
because starting up without any connector connected sounds like a pretty basic thing to handle
<MrCooper>
maybe I'm mis-remembering the details, jfalempe?
<emersion>
my understanding is that the BMC connector is used for remoting
<emersion>
and then a physical connector can be used as well
<emersion>
if it's just about headless startup i'd really rather see userspace fixed
<emersion>
it's not a new situation and can come up pretty regularily
<emersion>
like, you start a rpi or something
maxzor has quit [Remote host closed the connection]
maxzor has joined #dri-devel
<jfalempe>
Yes the problem is when nothing is connected to the display port, the default resolution is 640x480, so we added this "virtual" BMC connector, to overcome that.
lynxeye has quit [Quit: Leaving.]
<jfalempe>
and previously for userspace the DP connector was seen as always connected
<emersion>
jfalempe: when no external connector is connected, you still want user-space to display something right? and then grab this and send it for remoting?
<jfalempe>
emersion, yes because you may want to access the server remotely, it's the main use-case for aspeed card.
<emersion>
right
<emersion>
okay
<emersion>
can you detect if someone is using the remoting part?
<jfalempe>
emersion, no, there is currently no way to know that. It's even not possible to know if the hw can handle remoting (as some cards don't).
<emersion>
i see
<emersion>
right, so 2 connectors with only a single connected at a time, that makes sense to me
<jfalempe>
Also some cards have DP output, and older have VGA, and on VGA it's not possible to reliably detect if it's connected. But I don't think that's a real problem.
<pq>
jfalempe, how does the remoting actually work in the first place? Is there some dedicted mini-computer reading the BMC output and arranging that to be available via RDP or whatever using its own independent OS?
<jfalempe>
pq, it's an ARM chip, actually the VideoRAM is the RAM of the ARM processor. there is a web server running on it, that send the content of the framebuffer on the internet.
<pq>
I see.
maxzor has quit [Ping timeout: 480 seconds]
<tzimmermann>
sima, whatever we do, it has to be on by default. our we simply declare this a gnome bug, which is actually is
<sima>
tzimmermann, yeah I think since the bmc connector got added later on it's on the kernel to paper over this :-/
<sima>
maybe in another lts or so we can try to revert, if we know the known-broken compositors are fixed
<pq>
jfalempe, is it hardwired such that the physical output and the remote output always use the same FB to read from? which would be why you need to model it as one CRTC driving two connectors?
<tzimmermann>
jfalempe, hard-coding the bmc to disconnected brought back the old behaviour. nice :) i'd strongly prefer that solution over the other possible workarounds.
<tzimmermann>
it's transparent to userspace, automatic, and we can easily remove it
<pq>
kode54, sounds like you are either laughing at them, or assuming bad intentions. Neither is nice. Reviewers will catch it in due time.
<emersion>
usually they are people not used to GitLab
<MrCooper>
this one so far seems immune to feedback though
<jfalempe>
tzimmermann, thanks, so I can do the patch, or if you prefer do that with your encoder refactoring ? But we may need that in misc-fixes for 6.6 ?
<emersion>
yeah :/
<pq>
close the MR instead of point and laugh, right?
<emersion>
indeed
<MrCooper>
they might just create another one, as they did instead of updating the original one
<pq>
if that's too much, there is a process for spam
<MrCooper>
not sure it's malice, might be just very clumsy
<pq>
it's hard to imagine that "get a load of this guy" is ever appropriate to say
<emersion>
tbh i was not sure how to parse this
<karolherbst>
yeah, or language barrier, or....
<karolherbst>
emersion: it's a meme
<emersion>
i assumed "i get a load of MRs from this guy"
<emersion>
oh, i'm just too old then
<karolherbst>
from friends
<karolherbst>
the tv series
<pq>
I don't recall the meme, but I have the impression it's derogative phrase
<karolherbst>
though the history seems older.. anyway
<karolherbst>
seems like it's not from frinds actually.. I just saw it with that picture usually.. anyway
<kode54>
yikes, that spawned a whole conversation on the etiquette of link dropping?
<karolherbst>
I'm just here to explain
<pq>
kode54, not link dropping but the "load" phrase
<kode54>
ah
<kode54>
one of the earlier sources was possibly Wayne's World
<karolherbst>
yeah.. it's meant in a more humourus way usually, but I'd be careful with pointing out new contributors this way
<kode54>
right
<ccr>
I'm fairly sure that saying is way older than Wayne's World tho.
<ccr>
(irrelevant factoid, I know)
<kode54>
I do guess I'm doing exactly the wrong things I regularly expect others are doing to me
<karolherbst>
that's a common misconception, yes
<karolherbst>
I mean.. it always depends on the environment
<kode54>
I regularly expect everyone is pointing and laughing at me when I'm not there to see it
<karolherbst>
here we at least pretend to act more professional
<karolherbst>
nobody meant malice here anyway I hope
heat has joined #dri-devel
cmichael has joined #dri-devel
<kode54>
no, I wasn't meaning malice intentionally
sgruszka has quit [Remote host closed the connection]
<kode54>
also I originally thought that malice comment was related to me possibly suggesting the user was malicious
<kode54>
maybe making a rookie mistake
<kode54>
but doesn't look malicious
<kode54>
though it is a bit strange they decided to reconfigure the global CI to accept more rebuild actions
<kode54>
or at least, it looked like that's what it does
<pq>
that may just have been an attempt to get CI to run at all
<pq>
anyway, all good - careful with memes and popular phrases
airlied has joined #dri-devel
kts has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
lynxeye has joined #dri-devel
bmodem has joined #dri-devel
<tzimmermann>
jfalempe, patch sent
<eric_engestrom>
tintou: I think it's brianp or vlee (they are the admins of the mesa project on coverity, which I think means it has to be one of them)
Daanct12 has quit [Quit: WeeChat 4.1.1]
<airlied>
pretty sure it's vlee
kts has quit [Quit: Konversation terminated!]
itoral has quit [Quit: Leaving]
kts has joined #dri-devel
<tintou>
Alright, emailed them both then :)
kts has quit []
airlied_ has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
<tintou>
(I wanted to know which driver were being compiled because I don't see virgl there so that's suspicious 😅)
<emersion>
agd5f hwentlan__: is it fine to merge the amd patches for atomic async page-flips via drm-misc-next?
rasterman has quit [Quit: Gettin' stinky!]
Ahuj has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
heat has quit [Read error: No route to host]
heat has joined #dri-devel
airlied has quit [Ping timeout: 480 seconds]
airlied has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
airlied has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Konversation terminated!]
<tjaalton>
dcbaker: when can we expect mesa 23.2.2?
maxzor has quit [Ping timeout: 480 seconds]
airlied has joined #dri-devel
<agd5f>
emersion, fine with me
<emersion>
ty
alyssa has left #dri-devel [#dri-devel]
sghuge has quit [Ping timeout: 480 seconds]
jkrzyszt has quit [Ping timeout: 480 seconds]
airlied has quit [Ping timeout: 480 seconds]
cmichael has quit [Quit: Leaving]
heat_ has joined #dri-devel
heat has quit [Read error: No route to host]
Kayden has quit [Quit: -> JF]
Aura has quit [Ping timeout: 480 seconds]
<eric_engestrom>
tintou: `-D gallium-drivers=all -D vulkan-drivers=all` is what we want for builds like coverity; you can tell them that in your email conversation :)
<eric_engestrom>
also, I'd be interested in helping maintain the "components" list, it's in dire need of tlc
<eric_engestrom>
could you cc me (eric@engestrom.ch) into the conversation with these two notes?
lynxeye has quit [Quit: Leaving.]
<tintou>
Alright, I'll cc you when I get a reply 🙂
mripard has quit [Quit: mripard]
flom84 has joined #dri-devel
airlied has joined #dri-devel
rasterman has joined #dri-devel
frieder has quit [Remote host closed the connection]
<karolherbst>
sadly the AI model returns bogus values with mesa :')
<karolherbst>
and no idea what's up there
<jenatali>
karolherbst: That seems like the right solution. I don't know the code well enough to give you any kind of review though...
airlied has joined #dri-devel
<karolherbst>
yeah...
<karolherbst>
I'll probably rebase it on the main branch and see what people say about it
<jenatali>
I really need to finish getting CLOn12 up to 100% conformance and then figure out a way to get CTS into some automation somewhere so it stays that way
<karolherbst>
yeah...
<karolherbst>
I kinda want to CI on the CTS as well
<jenatali>
Gotta figure out the right subset of it at least. Because there's no way you're running the whole thing in any kind of reasonable timeframe
<karolherbst>
so intel says the picture I have is 66.5% a minivan, it isn't really, looks more like a "normal" car, but rusticl on iris says 2.2% combination lock and nothing higher :')
<karolherbst>
that's roughly 5-10 minutes depending on the driver on a decent 12/20 core intel CPU
<karolherbst>
20 threads
<karolherbst>
ehh
<karolherbst>
8+4/20 I mean...
<karolherbst>
ehh quick + wimpy
<jenatali>
Cool
<karolherbst>
I only use that for testing
<karolherbst>
once I did a full run with zink I had like 4 fails, mostly MT related
<karolherbst>
so it's good enough
<karolherbst>
one bug with denorms only showing with longer runs
<jenatali>
Then the question is, do I put that in our GitHub project or do I try to onboard it to Mesa CI? And which component has to deal with ABI breaks between the compiler and runtime? Or do I try to move, or maybe even abandon the separate runtime? Idk
<karolherbst>
my script also can use the offline compiler to test the spir-v path and then with 3 drivers each online/spirv and each native/zink it takes like 2 hours in total across all combinations
<karolherbst>
and that's 12 runs i think
gouchi has joined #dri-devel
<jenatali>
I wish I could just adopt rusticl, but there's so many shenanigans in making CL-sourced nir usable for D3D (e.g. global => SSBO) that I don't think it's realistically feasible
<karolherbst>
yeah.. would have to move it all into the gallium driver
<jenatali>
Which is impossible if rusticl doesn't send me the buffers that the global addresses came from
<karolherbst>
or you just use it through zink :D
rasterman has quit [Quit: Gettin' stinky!]
<karolherbst>
I benchmarked it against nvidia CL and zink got 92% performance
<jenatali>
Requires BDA, doesn't it?
<karolherbst>
yeah
<jenatali>
Yeah, we can't do that in Dozen
<karolherbst>
pain
<jenatali>
Yep
<jenatali>
Maybe someday
<karolherbst>
anyway.. openvino runs but gives wrong results atm :')
<karolherbst>
this will be fun to debug now
<jenatali>
Yeah, good luck
<karolherbst>
but at least no funky spir-v validation errors anymore
airlied has quit [Ping timeout: 480 seconds]
vliaskov has quit [Remote host closed the connection]
<karolherbst>
wouldn't surprise me if something with the compiler, but uhhh... those kernels are like huge
<karolherbst>
or maybe it's just broken on non intel
<karolherbst>
they have subgroup emulation code which isn't used on intel's stack obviously
<karolherbst>
I should check against nvidia on my desktop tomorrow
<karolherbst>
and AMD
greenjustin_ has joined #dri-devel
greenjustin has quit [Ping timeout: 480 seconds]
airlied has joined #dri-devel
airlied has quit [Ping timeout: 480 seconds]
airlied has joined #dri-devel
aravind has joined #dri-devel
mvlad has quit [Remote host closed the connection]
Haaninjo has quit [Quit: Ex-Chat]
airlied has quit [Ping timeout: 480 seconds]
tursulin has quit [Ping timeout: 480 seconds]
a-865 has quit [Quit: ChatZilla 0.17.1 [SeaMonkey 2.53.17.1/20230917131154]]
Kayden has joined #dri-devel
a-865 has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
aravind has quit [Ping timeout: 480 seconds]
AnuthaDev has quit []
gouchi has quit [Remote host closed the connection]