flynnjiang has quit [Remote host closed the connection]
flynnjiang has joined #dri-devel
flynnjiang has quit []
flynnjiang has joined #dri-devel
flynnjiang has quit [Remote host closed the connection]
benjaminl has quit [Read error: Connection reset by peer]
benjaminl has joined #dri-devel
jrelvas has quit [Remote host closed the connection]
ninjaaaaa has quit [Read error: Connection reset by peer]
simondnnsn has quit [Read error: Connection reset by peer]
ninjaaaaa has joined #dri-devel
simondnnsn has joined #dri-devel
glennk has joined #dri-devel
krushia has quit [Quit: Konversation terminated!]
lanodan has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
stalkerg has quit [Quit: Konversation terminated!]
lanodan has joined #dri-devel
ninjaaaaa has quit [Read error: Connection reset by peer]
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
ninjaaaaa has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
anujp has quit [Ping timeout: 480 seconds]
ninjaaaaa has quit [Read error: Connection reset by peer]
simondnnsn has quit [Read error: Connection reset by peer]
ninjaaaaa has joined #dri-devel
simondnnsn has joined #dri-devel
Company has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
glennk has quit [Ping timeout: 480 seconds]
nea_ has joined #dri-devel
flynnjiang has joined #dri-devel
flynnjiang has quit [Remote host closed the connection]
junaid has joined #dri-devel
flynnjiang has joined #dri-devel
Duke`` has joined #dri-devel
flynnjiang has quit [Remote host closed the connection]
mbrost has joined #dri-devel
flynnjiang has joined #dri-devel
mbrost has quit [Read error: Connection reset by peer]
flynnjiang has quit [Remote host closed the connection]
nea__ has joined #dri-devel
nea_ has quit [Ping timeout: 480 seconds]
junaid has quit [Quit: leaving]
flynnjiang has joined #dri-devel
itoral has joined #dri-devel
Jeremy_Rand_Talos has quit [Remote host closed the connection]
Jeremy_Rand_Talos has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
xroumegue has quit [Ping timeout: 480 seconds]
xroumegue has joined #dri-devel
surajkandpal has joined #dri-devel
nashpa has joined #dri-devel
simondnnsn has quit [Read error: No route to host]
simondnnsn has joined #dri-devel
ninjaaaaa has quit [Ping timeout: 480 seconds]
dliviu has quit [Ping timeout: 480 seconds]
jsa has joined #dri-devel
ninjaaaaa has joined #dri-devel
sukuna has quit [Remote host closed the connection]
nea_ has joined #dri-devel
sukuna has joined #dri-devel
nea__ has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
frieder has joined #dri-devel
<mripard>
mlankhorst: we got build failures in a driver we merged yesterday and we probably don't want to send that as part of the PR. I'm working on fixing them up
Leopold_ has quit []
Leopold_ has joined #dri-devel
ced117_ has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
ced117 has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
tzimmermann has joined #dri-devel
pzanoni has quit [Read error: Connection reset by peer]
sukuna has quit [Ping timeout: 480 seconds]
davispuh has quit [Ping timeout: 480 seconds]
Leopold__ has joined #dri-devel
sukuna has joined #dri-devel
Leopold_ has quit [Ping timeout: 480 seconds]
lplc has quit [Ping timeout: 480 seconds]
glennk has joined #dri-devel
junaid has joined #dri-devel
lplc has joined #dri-devel
junaid has quit [Remote host closed the connection]
<pq>
Does anyone else think that driving keyboard and mouse RGB leds through DRM KMS UAPI is... not a good fit at all? Even when you could show patterns individually addressed key lights.
<pq>
*patterns through individually
<emersion>
isn't there a new LED subsystem proposal?
<pq>
that one got a reply "arbitrary data backdoor, should use actual display interfaces instead"
<pq>
which I then replied to
luc has joined #dri-devel
<javierm>
pq: I haven't followed that long thread, but there's also this auxdisplay subsystem for segment LCDs and other kind of "auxiliary displays"
<emersion>
oh i see, i'm behind then
<emersion>
i agree with your reply, pq
<javierm>
pq: maybe it can fit in that subsys ?
<pq>
I did see auxdisplay mentioned, but I know nothing of it
<pq>
emersion, thanks
<javierm>
pq, emersion: there was someone in this channel that mentioned that had a driver for a dot-matrix panel controller that was in fact a matrix of servos to control a robot :)
<emersion>
lol
<javierm>
where each monochrome pixel was to turn on and off the servo. I can't decide if is brilliant or crazy
<emersion>
oh monochrome only? they should use RGB for the next version, and use the color channels as (X, Y, Z) coordinates for the robot arms orientation
<javierm>
emersion: haha, maybe it was 2bpp? Since at least you need 3 states: motor off, motor on in one direction, motor on in the inverse direction
zf has quit [Ping timeout: 480 seconds]
<emersion>
nice
tursulin has joined #dri-devel
<pq>
don't servos usually position by PWM duty cycle? So a pixel value can control the duty cycle, which translates to servo position.
<javierm>
it certainly is thinking outside the box :)
<mripard>
there was someone that was using the sun4i DPI output as a glorified DAC at some point too
<mripard>
I can't remember for what application it was exactly, but something similar :)
<pq>
oh, steppers
<pq>
glorified DAC; since pixel clocks can be 300 MHz or more, I've been thinking that you could generate a radio signal directly without any oscillator or anything
<Company>
I think it's a great idea that Matt Parker's Christmas tree can soon be supported with this
vliaskov has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
vliaskov has quit [Remote host closed the connection]
vliaskov has joined #dri-devel
KetilJohnsen has joined #dri-devel
<javierm>
Company: haha, I didn't get that reference and had to search online
simon-perretta-img has quit [Read error: Connection reset by peer]
simon-perretta-img has joined #dri-devel
<Company>
it could finally be a reason to introduce 3D dmabuf formats (or do those exist already?)
<Company>
see also: Vegas Sphere
jkrzyszt has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
mvlad has joined #dri-devel
simon-perretta-img has joined #dri-devel
yuq825 has quit []
yyds has quit [Remote host closed the connection]
heat has joined #dri-devel
<pac85>
pq: yes people have turned USB VGA adapters into cheap SDRs, they even have a low enough impedance to just attach an antenna directly to them
KetilJohnsen has quit [Remote host closed the connection]
<emersion>
hm
<emersion>
airlied: so… i pushed a patch to drm-misc-next but should've pushed it to drm-misc-fixes
<emersion>
but i have a more general question about the branches now
<emersion>
patch 1 is a fix, patch 2 is not, both need to be pushed, patch 2 depends on patch 1
<emersion>
what is the best way to push these?
simon-perretta-img has quit [Ping timeout: 480 seconds]
<javierm>
emersion: both patches are in drm-misc-next now right ?
<emersion>
yeah
<javierm>
emersion: so I would just dim cherry-pick #1 in drm-misc-fixes
* emersion
is at loss without sima showing the way
<javierm>
then the fix could make into the current release and #2 would be in the next one
<emersion>
ok, thanks for the advice! i'll wauit for a bit to leave the chance for someone else to protest
simon-perretta-img has joined #dri-devel
<mripard>
emersion: for your first question, the ideal way would have been to merge the first in drm-misc-fixes, ask us to backport it into drm-misc-next, and then apply it to drm-misc-next
<emersion>
i see
<javierm>
yeah, or wait for drm-misc-next to get a backmerge and then push #2
<emersion>
yeah, since it's not super important patches, it could've waited for a backmerge
<javierm>
emersion: but it happens, I also got confused a couple of times and had to dim cherry-pick... the problem there is that it pollutes the git log since the commits are duplicated
<emersion>
indeed
nea_ has quit []
<mripard>
javierm: committers shouldn't cherry-pick, and we shouldn't encourage them to
<mripard>
it's not a big deal when it happens
<mripard>
because, well, it happens on a regular basis indeed
<mripard>
but it's not something to encourage
<emersion>
yeah, i think javierm was strictly replying to my "oops i messed up" message
<emersion>
not saying it's a good thing to do in general, just saying it's a solution for my mistake
simon-perretta-img has quit [Read error: Connection reset by peer]
simon-perretta-img has joined #dri-devel
<javierm>
mripard: yes, my intention wasn't to encourage emersion, but rather to assit him on how to fix when it happens
<javierm>
or do you mean that cherry-pick should only be done by drm-misc maintainers and individual devs ask them to do so ?
<javierm>
(when they make a mistake I mean)
fab has quit [Ping timeout: 480 seconds]
<pq>
pac85, ha! awesome
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
kts has joined #dri-devel
kts has quit [Remote host closed the connection]
<emersion>
mripard: ^ let me know if that's what you meant or not
<emersion>
will hold off cherry-picking until i hear back from you
Mangix has quit [Read error: Connection reset by peer]
Mangix has joined #dri-devel
<mripard>
emersion: I'm not entirely sure what the policy is anymore, so go ahead and cherry-pick it with my Ack :)
<emersion>
ty
fab has joined #dri-devel
<emersion>
ah yes of course…
<emersion>
dim: FAILURE: Could not merge drm-misc/drm-misc-next
aravind has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
<emersion>
alright i hope i didn't mess anything up when resolving the conflict…
<daniels>
airlied: do you need to do any DRM PRs or anything in the next couple of days?
<daniels>
airlied: you can take it as heavily implied that the ideal answer is no :P
<mripard>
daniels: iirc airlied sends the drm fixes PR on fridays
KetilJohnsen has joined #dri-devel
<tzimmermann>
mripard, do you have comments to the v2 of the renesas fix? i'd like to have it in the drm-misc-next PR today
<daniels>
mripard: aha
<mripard>
tzimmermann: no, that's fine, do you want me to merge it?
<KetilJohnsen>
I'm investigating user submission of GPU work (Panthor), and was looking for a mechanism to notify user space about certain GPU events, like HW queue errors. I stumbled across drm_send_event(), which seems like a good match. The only "problem" I have is that it doesn't seem to be much used, so I'm worried this isn't the right way to go about. Any comments or pointers?
itoral has quit [Quit: Leaving]
<daniels>
KetilJohnsen: it depends how often you need to sync back
<daniels>
the usual way to report things like HW queue errors is an error back from your CS ioctl
<daniels>
but I guess with userspace submit, unless you're doing memory (un)bind ops, the only time you'd need to check in with the kernel would be for fence management
<tzimmermann>
mripard, yes i merge it in a bit. i'm going to add a Fixes tag as well
<daniels>
so if you do have one of those regular sync points then you could use that, otherwise a DRM event could be apt - but the problem with DRM events is that they're not in any way isolated and will appear as readable to anyone with the drm_file description, so you'd have to figure out how that isolation should work in the presence of e.g. multiple independent queues
junaid has joined #dri-devel
jkhsjdhjs has quit [Quit: Error: Leaving not permitted]
jkhsjdhjs has joined #dri-devel
<KetilJohnsen>
I don't think I have regular sync points which I can rely on.
<KetilJohnsen>
Not sure I quite understood your worry about isolation. I mean, I only plan to report HW queue issues to the process (fd) owning the queue. Shouldn't that give you the isolation needed?
<mripard>
tzimmermann: thanks!
<daniels>
KetilJohnsen: I guess you'd just report DEVICE_LOST for the whole device rather than trying to make errors granular to individual queues?
Leopold__ has quit [Remote host closed the connection]
ungeskriptet is now known as Guest552
ungeskriptet has joined #dri-devel
Leopold has joined #dri-devel
Guest552 has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<rodrigovivi>
mripard: ack!
Dr_Who has quit [Ping timeout: 480 seconds]
junaid has quit [Remote host closed the connection]
ungeskriptet is now known as Guest554
ungeskriptet has joined #dri-devel
mareko_ has joined #dri-devel
<mripard>
tzimmermann: this was the last drm-misc-next PR, right?
fab has quit [Ping timeout: 480 seconds]
mareko has quit [Ping timeout: 480 seconds]
Leopold__ has joined #dri-devel
Guest554 has quit [Ping timeout: 480 seconds]
Leopold has quit [Ping timeout: 480 seconds]
junaid has joined #dri-devel
gio_ has quit [Remote host closed the connection]
gio_ has joined #dri-devel
Mangix has quit [Read error: Connection reset by peer]
Mangix has joined #dri-devel
junaid has quit [Remote host closed the connection]
mripard_ has joined #dri-devel
mripard has quit [Ping timeout: 480 seconds]
<KetilJohnsen>
daniels: you got a fair point there, reporting errors would not need to be very granular. But I would still need a reliable mechanism to provide that, given that user space (at least in theory) could be submitting work without ever interacting with kernel driver.
junaid has joined #dri-devel
<KetilJohnsen>
But it is not just about errors, I would also want a way to notify user space about "memory fences" when they are updated. This would probably be the main thing to handle.
<DemiMarie>
KetilJohnsen: why do you want userspace submit? I know that getting rid of dma-fence is good, but userspace submission to firmware queues seems like something to avoid unless there is a very good reason for it, and IIUC Panthor doesn’t require it.
rgallaispou has quit [Remote host closed the connection]
mareko_ is now known as mareko
<daniels>
perf
kts has joined #dri-devel
frieder has quit [Remote host closed the connection]
junaid has quit [Quit: leaving]
junaid has joined #dri-devel
junaid has quit [Remote host closed the connection]
rasterman has quit [Quit: Gettin' stinky!]
emersion has left #dri-devel [#dri-devel]
emersion has joined #dri-devel
kzd has joined #dri-devel
<tzimmermann>
mripard, there should be an rc6 on sunday, so yes, it's the final -next PR for this cycle
ungeskriptet has quit [Quit: Ping timeout (120 seconds)]
ungeskriptet has joined #dri-devel
surajkandpal has quit [Ping timeout: 480 seconds]
rgallaispou has joined #dri-devel
bryanodonoghue has joined #dri-devel
<sravn>
tzimmermann: If I ack/rb the patched for atmel-hdlc "Add support for XLCDC to sam9x7 SoC family", can you then push them to drm-misc?
<tzimmermann>
sravn, sure
<sravn>
I have lost my local infrastructure to push to drm-misc
<sravn>
thanks!
<tzimmermann>
oh
ced117_ has joined #dri-devel
ced117 has quit [Read error: Connection reset by peer]
linusw has quit [Quit: Connection closed for inactivity]
<DemiMarie>
daniels: does the perf matter in practice for reasonable frame rates, as opposed to demos that display frames much faster than a human can detect?
<DemiMarie>
For virtio-GPU native contexts I am thinking of forcing a copy of the commands, mostly because of TOCTOU concerns.
<daniels>
sure, if you need to ban userspace submission or add more copies or stick validation in the middle, those are all reasonable approaches
<DemiMarie>
This copy would be in virglrenderer.
<daniels>
but yeah, the impact is actually measurable, it's not just something people are doing because they're bored
anujp has joined #dri-devel
alyssa has joined #dri-devel
<DemiMarie>
Do you have a rough idea of how big the impact is?
<alyssa>
..guess we don't have hash_table_u64_foreach?
<daniels>
DemiMarie: depends on the workload and the hardware and ...
<DemiMarie>
daniels: hence the “rough”
<DemiMarie>
Are we talking a few percent or a factor of 2?
ced117_ has quit [Ping timeout: 480 seconds]
<DemiMarie>
I’m trying to figure out if “measurable” means “noticeable by real users”.
* alyssa
guess she's writing one
<DemiMarie>
Or is this a “we don’t know”?
<DemiMarie>
I’m not too worried, BTW, as per prior discussion in this channel the firmware code should be quite simple.
<sravn>
tzimmermann: All patches are a-b, have sent a mail to the list where I mention that I asked you to apply them. Thanks again
ced117 has joined #dri-devel
simondnnsn has quit [Read error: No route to host]
ninjaaaaa has quit [Read error: No route to host]
ninjaaaaa has joined #dri-devel
simondnnsn has joined #dri-devel
ungeskriptet is now known as Guest565
ungeskriptet has joined #dri-devel
Guest565 has quit [Ping timeout: 480 seconds]
ced117 has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
junaid has joined #dri-devel
<daniels>
DemiMarie: it is noticeable by real users when you're doing demanding workloads, yeah - on less demanding workloads you're obviously not going to be limited by job submission rate
aravind has quit [Ping timeout: 480 seconds]
ungeskriptet has quit [Quit: Ping timeout (120 seconds)]
ungeskriptet has joined #dri-devel
karolherbst has quit [Remote host closed the connection]
Dark-Show has joined #dri-devel
<robclark>
DemiMarie: the problem is you'd need to parse the cmds to find what other cmds/shaders/buffers they point to.. but OTOH if TOCTOU is a problem, then it is an overall GPU kernel issue.. in fact there can be legit cases for userspace (guest or not) modifying buffers passed
karolherbst has joined #dri-devel
<robclark>
opencl and vk with some extension even has raw pointers, so you pretty much need to have process isolation correct
<DemiMarie>
robclark: Ah, I see. So userspace command submission doesn’t allow userspace to do anything it could not do already, because of self-modifying code?
ungeskriptet has quit [Quit: Ping timeout (120 seconds)]
<robclark>
right
ungeskriptet has joined #dri-devel
dliviu has joined #dri-devel
<robclark>
I think for older hw where cmdstream validation was required, the (host) kernel must have copied the cmdstream.. but fortunately most of those old GPUs are gathering dust these days
davispuh has joined #dri-devel
nashpa has quit [Ping timeout: 480 seconds]
<DemiMarie>
robclark: I did not realize that userspace had write access to the command stream the kernel was sending to the firmware.
ungeskriptet is now known as Guest571
ungeskriptet has joined #dri-devel
_rgallaispou has joined #dri-devel
rgallaispou is now known as Guest572
_rgallaispou is now known as rgallaispou
<DemiMarie>
robclark: Asahi GPUs absolutely require that the firmware’s command stream is not writable from userspace. Apple’s drivers let userspace write it, and Lina used that and a firmware bug to get root privileges.
<robclark>
yeah.. not sure about other drivers, but freedreno maps cmdstream as gpu readonly when we don't expect it to be modified (mostly just for sanity, so a driver bug doesn't scribble over cmdstream and make things harder to debug)
bolson has joined #dri-devel
<robclark>
DemiMarie: so on adreno side, there is kernel controlled ringbuffer cmdstream, which has more privs like being able to set the pgtables... that is absolutely not writable or even visible to userspace
<robclark>
(or, well, I guess it is visible to userspace via the gpu but not writable.. it is also mapped gpu r/o)
ungeskriptet has quit []
<robclark>
in the asahi case, it sounds like a kernel bug, at any rate
ungeskriptet has joined #dri-devel
<DemiMarie>
robclark: It was a (macOS/iOS) kernel bug indeed
<DemiMarie>
What I’m wondering is if userspace command submission is something to worry about
<DemiMarie>
The other problem is that MMIO doorbells must not be mapped into guests under any circumstances.
<DemiMarie>
I don’t even think Xen allows that.
<DemiMarie>
So the doorbells will need to be proxied.
Guest571 has quit [Ping timeout: 480 seconds]
<robclark>
there are certainly things that you could do incorrectly in host kernel to cause security holes.. but I don't think it is anything that virglrenderer could stop (and those are all things that would be a big problem even if VM was not in the picture, so I think driver dev's give it some attention)
<DemiMarie>
robclark: I’m mostly concerned about TOCTOU or buffer overflow in firmware command buffer parsing
ungeskriptet is now known as Guest573
ungeskriptet has joined #dri-devel
<robclark>
it shouldn't cause any more problem than just a gpu crash... userpace (guest or host) is always allowed to shoot it's own foot, as long as it can't shoot another process
<DemiMarie>
What about memory corruption in the firmware?
Guest573 has quit [Ping timeout: 480 seconds]
<robclark>
fw memory gets reset when we reset the gpu to recover from gpu crash..
<soreau>
I see with apitrace, a program calls eglMakeCurrent(dpy, 0, 0, 0); followed a bit later by a call to eglMakeCurrent(dpy, 0, 0, ctx);. Does this mean context switching is in play? or is it only expensive to switch between two valid contexts
<robclark>
DemiMarie: btw, I'm not as familiar with the apple gpu+fw, but I'd make the general argument that _if_ the cmdstream needs to be copied to prevent TOCTOU issues, it should be done in the host kernel driver
<Lynne>
airlied: how did you test the av1 decode mr?
<alyssa>
apple doesn't do userspace submission, at least not on m1 + 13.x
<alyssa>
what lina found was a bug, not a fundamental design hole
pzanoni has joined #dri-devel
pzanoni has quit []
pzanoni has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
ungeskriptet is now known as Guest576
ungeskriptet has joined #dri-devel
alyssa has quit [Quit: alyssa]
Kayden has quit [Quit: -> JF]
Guest576 has quit [Ping timeout: 480 seconds]
<DemiMarie>
robclark: that assumes one cannot use FW exploits to compromise other contexts on the GPU
mripard_ has quit [Remote host closed the connection]
gouchi has joined #dri-devel
<airlied>
Lynne: cts
ungeskriptet has quit [Read error: Connection reset by peer]
ungeskriptet has joined #dri-devel
ungeskriptet has quit []
ungeskriptet has joined #dri-devel
ungeskriptet has quit []
<airlied>
daniels: i send fixes pull in next 8 hrs usually
<airlied>
then i have to wait for Linus
<daniels>
airlied: aight, will try to move the repo to gitlab on the weekend then
<airlied>
daniels: early next week is fine also
<airlied>
although i do some stuff on monday its not important
tursulin has quit [Ping timeout: 480 seconds]
<rodrigovivi>
abhinav__: done
<Lynne>
airlied: ah, cts has some issues
<robclark>
DemiMarie: my point is more that if there is a bug like that, it needs to be handled in host kernel (and/or fw), GPUs are sufficiently flexible that if you could trigger a bug like that by evil guest userspace modifying cmdstream after submission then you could also trigger it by evil guest userspace using a shader that generated cmdstream or something like that.. I kinda group possible exploits into "gpu exploits" and "cpu
<robclark>
exploits" (the latter being more frequent, like a UAF in host kernel driver).. nctx gives you some reasonable protection against the latter category, but the former category nothing in userspace is really going to be able to save you, you need to fix in host kernel. Fortunately the former category is much more rare.
<DemiMarie>
robclark: I see, thanks! I did not realize that GPUs had self-modifying code like that.
<robclark>
it varies a bit, not all do, but I know some do. But I think anything modern has general purpose load/store instructions in the shader, for example. Once you have that, you need to have proper isolation..
<airlied>
yeah there a vulkan exts go generate cmds on the gpu
sukuna_ has joined #dri-devel
<abhinav__>
rodrigovivi thanks!
<DemiMarie>
airlied: wow! I wonder if at some point we will see applications mostly written in shading languages.
<robclark>
I remember a few yrs back someone got a shader to do disk i/o via io_uring
<robclark>
in general, it's maybe not the ideal fit for many apps (which would prefer faster single threaded performance over massive SIMT thruput), but kind of a fun demo
<jenatali>
Demi: command buffer formats vary per-GPU and based on firmware, so unlikely to see user-generated command buffers shipped in an app. Shipped in a driver though is a different story
<robclark>
the concern is less well behaved normal app and more malicious app which decides it wants to bypass driver and build evil cmdstream directly, etc
fireburn has quit []
fireburn has joined #dri-devel
<airlied>
Lynne: yeah we can fix it up later, just want to merge it to avoid rebasing forever
ced117 has joined #dri-devel
Kayden has joined #dri-devel
junaid has quit [Remote host closed the connection]
Company has quit [Quit: Leaving]
iive has joined #dri-devel
hays has quit [Remote host closed the connection]
luc has quit [Remote host closed the connection]
Leopold__ has quit [Remote host closed the connection]
Leopold has joined #dri-devel
junaid has joined #dri-devel
hays has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
junaid has quit [Remote host closed the connection]
hays has quit []
hays has joined #dri-devel
sima has quit [Ping timeout: 480 seconds]
Dark-Show has quit [Quit: Leaving]
sarthakbhatt has joined #dri-devel
rgallaispou has quit [Quit: WeeChat 4.2.1]
gouchi has quit [Remote host closed the connection]
jkrzyszt has quit [Ping timeout: 480 seconds]
cheako has quit [Remote host closed the connection]
zdobersek has quit [Remote host closed the connection]
cheako has joined #dri-devel
zdobersek has joined #dri-devel
yrlf has quit [Ping timeout: 480 seconds]
fjdegroo has joined #dri-devel
yang is now known as Guest588
yrlf has joined #dri-devel
krushia has joined #dri-devel
Guest588 is now known as yang3
mvlad has quit [Remote host closed the connection]
Haaninjo has quit [Quit: Ex-Chat]
sarthakbhatt has quit []
jsa has quit []
glennk has quit [Ping timeout: 480 seconds]
fjdegroo has quit [Read error: Connection reset by peer]