#dri-devel on 2023-01-28 — irc logs at oftc.irclog.whitequark.org

2022-12-21 00:45 ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar

00:04 <hakzsam> cmarcelo: hi, yes, I can check this on monday for sure

00:40 pcercuei has quit [Quit: dodo]

00:58 clever has quit [Ping timeout: 480 seconds]

00:59 pallavim has quit [Ping timeout: 480 seconds]

01:16 clever has joined #dri-devel

01:26 columbarius has joined #dri-devel

01:27 co1umbarius has quit [Ping timeout: 480 seconds]

01:43 tuxayo has joined #dri-devel

01:47 test-874815 has joined #dri-devel

01:50 jewins has quit [Ping timeout: 480 seconds]

01:52 Company has quit [Quit: Leaving]

01:54 camus has joined #dri-devel

01:56 test-874815 has quit [Remote host closed the connection]

01:56 tuxayo-webchat has joined #dri-devel

02:00 <tuxayo> Hi :)

02:01 <tuxayo> I'm testing upcoming Vulkan support for the 0ad libre game. My GPUs are an HD 4000 (gen7 ivy bridge) and an AMD 7950 (GCN 1.0) so basically the firsts Intel and AMD GPUs with Vulkan support (but incomplete/unofficial!). Right at the frontier in the middle of the minefield, so I should get a lot of trouble :D 💥 Then the devs will see how to handle these dodgy GPUs ^^"

02:01 <tuxayo> Anyway, with my HD 4000 I got on launch that I don't have support for VK_KHR_surface, but mesa matrix doesn't mention anything about partial support (like gen8+, hsw, etc) so where can I find for sure whether the HD 4000 should support or not VK_KHR_surface?

02:02 danvet has quit [Ping timeout: 480 seconds]

02:02 tuxayo-webchat has quit [Remote host closed the connection]

02:04 <kisak> with mesa 22.3 Ivybridge vulkan support split away from ANV into hasvk. That's where to look for Vulkan on that generation going forward.

02:10 <kisak> https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/intel/vulkan_hasvk/anv_device.c#L161 seems unconditionally enabled. You sure hasvk is being used and can render to the display?

02:14 mbrost has quit [Ping timeout: 480 seconds]

02:15 <tuxayo> Thanks kisak , I was trying to find where the split put the files.

02:15 <tuxayo> > You sure hasvk is being used and can render to the display?

02:15 <tuxayo> I can run vkcube and veloren (unplayable FPS of course) so I can definitely get vk stuff on my display.

02:15 <tuxayo> I have Mesa 22.3.3 so it could only be hasvk that is used I guess? (only one GPU on the system)

02:20 Emantor has quit [Quit: ZNC - http://znc.in]

02:20 Emantor has joined #dri-devel

02:20 mwk has quit [Ping timeout: 480 seconds]

02:24 fxkamd has joined #dri-devel

02:26 <mareko> or lavapipe

02:27 <tuxayo> I found about vulkaninfo! (I tried vkinfo but not vulkaninfo). So :

02:27 <tuxayo> Instance Extensions: count = 20

02:27 <tuxayo> [...]

02:27 <tuxayo> VK_KHR_surface : extension revision 25

02:27 <tuxayo> That might it's supported right?

02:27 nchery has quit [Ping timeout: 480 seconds]

02:27 <mareko> yes

02:27 <tuxayo> > or lavapipe

02:27 <tuxayo> oh right, maybe I have it by default somehow

02:34 * tuxayo tries to find how to which driver is used when running something

02:34 <tuxayo> *how to know

02:34 <tuxayo> That's still relevant to be sure hasvk is used, right?

02:36 <tuxayo> I'm running the AppImage build of the dev branch of the game. So it might mess up which driver/lib are used compared to directly running the game.

02:37 mwk has joined #dri-devel

02:49 <tuxayo> I found out about Vulkan Hardware Capability Viewer, ran the locally compiled version and the AppImage version and both don't list it.

02:49 <tuxayo> It might not be reliable. https://vulkan.gpuinfo.org/listextensions.php show only 0.16% of devices in the DB support it. Which seems wrong.

02:54 <tuxayo> Will keep digging, thanks for the help all :)

02:59 bluetail89482 has joined #dri-devel

03:07 bluetail8948 has quit [Ping timeout: 480 seconds]

03:08 genpaku has quit [Remote host closed the connection]

03:08 genpaku has joined #dri-devel

03:13 clever has quit [Ping timeout: 480 seconds]

03:19 digetx has quit [Ping timeout: 480 seconds]

03:22 clever has joined #dri-devel

03:23 kzd_ has joined #dri-devel

03:29 kzd has quit [Ping timeout: 480 seconds]

03:48 Daanct12 has joined #dri-devel

03:53 genpaku has quit [Read error: Connection reset by peer]

03:53 genpaku_ has joined #dri-devel

03:59 genpaku_ is now known as genpaku

04:02 YuGiOhJCJ has joined #dri-devel

04:03 <cmarcelo> hakzsam: thanks!

04:04 ppascher has joined #dri-devel

04:17 fxkamd has quit []

04:23 randy__ has quit [Remote host closed the connection]

04:26 <hays> can someone here help me out to explain exactly the relationship between libEGL.so and libwayland-egl.so? it seems that GPU vendors are on the hool to provide libwayland-egl.so (maybe?) but wayland also generates this .so as part of the compilation process

04:26 <hays> s/hool/hook

04:27 <hays> I feel like im missing a concept in terms of the graphics stack

04:36 mbrost has joined #dri-devel

04:49 tlwoerner_ has quit []

04:49 tlwoerner has joined #dri-devel

04:56 kts has joined #dri-devel

05:12 ngcortes has quit [Ping timeout: 480 seconds]

05:21 Daanct12 has quit [Remote host closed the connection]

05:23 Daanct12 has joined #dri-devel

05:43 heat has quit [Ping timeout: 480 seconds]

05:53 camus has quit [singleton.oftc.net coherence.oftc.net]

05:53 Net147 has quit [singleton.oftc.net coherence.oftc.net]

05:53 Danct12 has quit [singleton.oftc.net coherence.oftc.net]

05:53 thaytan has quit [singleton.oftc.net coherence.oftc.net]

05:53 wens has quit [singleton.oftc.net coherence.oftc.net]

05:53 natto has quit [singleton.oftc.net coherence.oftc.net]

05:54 camus has joined #dri-devel

05:54 Danct12 has joined #dri-devel

05:54 natto has joined #dri-devel

05:54 Net147 has joined #dri-devel

05:54 wens has joined #dri-devel

05:54 thaytan has joined #dri-devel

06:17 camus has quit [singleton.oftc.net coherence.oftc.net]

06:17 Danct12 has quit [singleton.oftc.net coherence.oftc.net]

06:17 thaytan has quit [singleton.oftc.net coherence.oftc.net]

06:17 wens has quit [singleton.oftc.net coherence.oftc.net]

06:17 Net147 has quit [singleton.oftc.net coherence.oftc.net]

06:17 natto has quit [singleton.oftc.net coherence.oftc.net]

06:18 natto has joined #dri-devel

06:18 wens has joined #dri-devel

06:18 thaytan has joined #dri-devel

06:18 Danct12 has joined #dri-devel

06:18 Net147 has joined #dri-devel

06:18 camus has joined #dri-devel

06:21 camus1 has joined #dri-devel

06:21 camus has quit [Remote host closed the connection]

06:28 mbrost_ has joined #dri-devel

06:32 mbrost has quit [Ping timeout: 480 seconds]

06:33 kts has quit [Quit: Leaving]

06:35 kts has joined #dri-devel

07:07 fab has joined #dri-devel

07:13 junaid has joined #dri-devel

07:43 Duke`` has joined #dri-devel

07:58 sghuge has quit [Remote host closed the connection]

07:58 sghuge has joined #dri-devel

08:00 Daanct12 has quit [Ping timeout: 480 seconds]

08:04 junaid has quit [Ping timeout: 480 seconds]

08:44 ds` has quit [Quit: ...]

08:46 ds` has joined #dri-devel

08:51 JohnnyonFlame has joined #dri-devel

08:51 JohnnyonFlame has quit []

08:59 rasterman has joined #dri-devel

08:59 Haaninjo has joined #dri-devel

09:06 djbw has quit [Read error: Connection reset by peer]

09:18 kzd_ has quit []

09:26 Daanct12 has joined #dri-devel

09:41 Daanct12 has quit [Quit: Leaving]

09:44 junaid has joined #dri-devel

09:45 rmckeever has quit [Quit: Leaving]

09:47 Daanct12 has joined #dri-devel

10:02 junaid has quit [Remote host closed the connection]

10:23 Daaanct12 has joined #dri-devel

10:24 Daaanct12 has quit [Read error: Connection reset by peer]

10:25 <hays> It does appear the wayland-egl is essential for proper functioning of wayland.. I thought perhaps there might be a way to run without it

10:25 Daaanct12 has joined #dri-devel

10:25 <hays> (based on this https://upload.wikimedia.org/wikipedia/commons/thumb/2/2d/The_Linux_Graphics_Stack_and_glamor.svg/2880px-The_Linux_Graphics_Stack_and_glamor.svg.png)

10:26 Daanct12 has quit [Ping timeout: 480 seconds]

10:27 <hays> but then this graphic, which maybe is meant as a more detailed view--shows the wayland-egl.so https://upload.wikimedia.org/wikipedia/commons/a/a7/Wayland_display_server_protocol.svg

10:29 Daaanct12 has quit [Remote host closed the connection]

10:32 X512 has joined #dri-devel

10:34 <X512> libwayland-egl.so provides an API for using EGL with Wayland. It contains installable interfaces actually implemented in EGL drivers such as Mesa.

10:35 <X512> libwayland-egl.so is one of reasons why Wayland application using EGL can't be fully implemented in Rust.

10:40 kts has quit [Quit: Leaving]

10:46 X512 has quit [Quit: Vision[]: i've been blurred!]

10:53 <dottedmag> hays: Out of curiousity, what are symbols exported by wayland-egl.so.1 from Mali?

10:54 <hays> dottedmag: I am not sure exactly how to determine that

10:54 <dottedmag> hays: readelf -sW

10:56 pcercuei has joined #dri-devel

10:56 Daanct12 has joined #dri-devel

10:56 <hays> one sec-- in over my head a bit and don't want to ask uninteresting questions if possible

10:59 <hays> dottedmag: so.. I barely understand the readelf output. but I think the answer is that Mali doesn't name wayland-egl.so for any symbol table entry

10:59 <hays> there's stuff like this -- 10: 0000000000000000 0 FUNC GLOBAL DEFAULT UND dup@GLIBC_2.17 (2)

11:00 <dottedmag> hays: pls upload the output somewhere, say, to paste.debian.net

11:00 <hays> and stuff like this 28: 0000000000000000 0 FUNC GLOBAL DEFAULT UND wl_resource_set_implementation

11:00 <hays> ok

11:00 <hays> https://termbin.com/ettt

11:01 Daanct12 has quit [Read error: No route to host]

11:01 Daanct12 has joined #dri-devel

11:02 <hays> maybe interesting is grep wl_egl?

11:02 <dottedmag> Thanks. So this is a real library with a lot of code inside, not a wrapper like Mesa's one.

11:02 <hays> this is libmali.so

11:02 <hays> so yeah it supposedly does it all

11:03 <dottedmag> Aha. And what's in their libwayland-egl.so?

11:03 <hays> there are six functions in that readelf with name wl_egl*

11:03 <hays> so my guess its is those 6 functions

11:04 <hays> wl_egl_window_{release,retain,destroy,get_attached_size,create,resize}

11:05 <hays> so the intent I believe is to symlink libwayland-egl.so to this library

11:07 <hays> and maybe that works.. im in the process of grasping at straws trying to figure out why launching sway causes seatd to hang in kernel space --possibly waiting for IO from /dev/dri/card0

11:11 <kennylevinsen> last thing you shared was sway segfaulting

11:13 <kennylevinsen> hays: seatd sits idle in a poll most of the time, so waiting in the kernel is normal

11:13 <hays> yes but not responding to kill -9 is abnormal

11:14 <hays> which happens after sway talks to it the first time

11:15 <hays> so something happens--i don't know what--when sway tries to get a resource from seatd that causes sway to segfault and seatd to go into state "D"

11:15 rick has joined #dri-devel

11:16 <kennylevinsen> that is true and suggests kernel issues, but unless sway is waiting for seatd then those might not be related

11:16 <hays> which forgive me if you know this already--is: "State "D" indicates Uninterruptible sleep generally related to IO."

11:16 Leopold has quit [Remote host closed the connection]

11:16 rick has quit [Remote host closed the connection]

11:17 <hays> sway seems to segfault immediately and only hangs the second, third, fourth time it tries to talk to seatd, which I assume is not saying anything back

11:17 <hays> first time: segfault.. after that it sits there and segfaults after a Ctrl-C

11:17 <hays> precisely what "driver" in kernel space does a proprietary driver like mali need?

11:18 <kennylevinsen> debug the first segfault. If your driver is borked, maybe seatd hangs on the drm ioctls later?

11:18 <hays> do i need to recompile seatd with debug symbols

11:19 <hays> and run it with gdb?

11:20 <kennylevinsen> To see where it hangs, sure - but I think you should debug the sway segfault first as that is a clear crash

11:22 danvet has joined #dri-devel

11:22 <hays> yeah ive tried but there is no backtrace

11:22 TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]

11:22 TMM has joined #dri-devel

11:22 Leopold_ has joined #dri-devel

11:23 <hays> gdb --args sway, run, bt shows nothing

11:24 <kennylevinsen> then single-step to the crash. You can break at libseat_open_device and step from there.

11:34 ice9 has joined #dri-devel

11:40 mbrost_ has quit [Ping timeout: 480 seconds]

11:42 ice99 has joined #dri-devel

11:43 ice9 has quit [Read error: Connection reset by peer]

11:43 <MrCooper> nanonyme: some issues with glthread are bugs in Mesa, some are bugs in the GL API user; each case needs separate investigation

11:46 Daanct12 has quit [Remote host closed the connection]

11:46 Daanct12 has joined #dri-devel

11:48 Daanct12 has quit [Remote host closed the connection]

11:48 Daanct12 has joined #dri-devel

11:49 Daanct12 has quit [Remote host closed the connection]

11:52 X512 has joined #dri-devel

11:52 <X512> In theory wayland-egl.so is generic hardware-independent library.

12:17 X512 has quit [Ping timeout: 480 seconds]

12:17 X512 has joined #dri-devel

12:25 YuGiOhJCJ has quit [Quit: YuGiOhJCJ]

12:37 <daniels> yes, in older versions each EGL library provided its own implementation, but now libwayland has its own. the two are compatible so you just need to replace the Wayland one with the Mali one … or use Panfrost

12:51 ice99 has quit [Ping timeout: 480 seconds]

12:51 <X512> 2023 year now and vendor lib[E]GL.so still exists...

12:52 <X512> Use of glvnd should be enforced in distros I think.

12:52 <HdkR> If you're using the vendored Mali blob then libGL doesn't exist ;)

12:53 <X512> Mali blob don't use glvnd?

12:55 <HdkR> Well they don't support GL, so no reason to provide libGL

12:56 <HdkR> I've never actually thought about how glvnd works in that situation

12:58 <X512> glvnd have 2 parts with their own set of drivers: for GLX and for EGL.

12:59 X512 has quit [Quit: Vision[]: i've been blurred!]

12:59 X512 has joined #dri-devel

13:05 digetx has joined #dri-devel

13:43 luc4 has joined #dri-devel

13:52 X512 has quit [Ping timeout: 480 seconds]

13:57 <hays> daniels: Panfrost not available yet

13:58 <hays> they are working on it though--im stuck with rockchip-mali until that work completes

13:59 <hays> ok yeah disabling wayland EGL--as the rockchip buildroot does--doesn't work because it looks like wayland creates some header files that are needed

13:59 <hays> so my previous delete strategy seems right

14:01 <hays> still left with mystery of seatd--I'll get into gdb when I can to see what I can see

14:14 doomjoshuaboy has joined #dri-devel

14:18 <daniels> hays: ah right, gen10

14:20 <hays> this blob makefile is comically complicated

14:22 <hays> anyhoo thanks for the discussion on architecture it helped clarify some things

14:25 heat has joined #dri-devel

14:28 <daniels> np

14:30 <doomjoshuaboy> hi guys i am having a problem compiling mesa with zink on a mac os arm64 and the xcb/xcb.h, i already installed the hombrew stuff on it but still doesnt help. can anyone please tell me what to do also i am a developer of zandronum and opengl screwed zandronum up because of some opengl deprecated so i thought mesa could help with it

14:34 heat has quit [Remote host closed the connection]

15:00 Leopold_ has quit [Ping timeout: 480 seconds]

15:01 clever has quit [Ping timeout: 480 seconds]

15:04 ice9 has joined #dri-devel

15:06 Leopold_ has joined #dri-devel

15:07 clever has joined #dri-devel

15:07 <nanonyme> airlied, FWIW, we found out disabling LTO fixed dthe problem. So this https://gitlab.freedesktop.org/mesa/mesa/-/issues/7806 is probably quite wide-spread issue

15:08 <nanonyme> Seems to affect quite large amounts of AMD hardware

15:09 <nanonyme> MrCooper, glthread was red herring. We tried disabling it, it had no impact. There is a separate glthread bug, yes.

15:09 <kisak> nanonyme: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6911 is probably the issue report you want to keep an eye on

15:18 <hays> For those curious it seems like mali blob is at least supposed to work with wayland's version of wayland-egl.so: https://patchwork.ozlabs.org/project/buildroot/patch/20220924210221.1490924-1-thomas.petazzoni@bootlin.com/

15:18 <nanonyme> Okay, well, sounds like we will disable LTO for Mesa for now, it should allow doing further updates and hardware enablements

15:25 <MrCooper> yes, LTO is known unsafe for Mesa ATM

15:29 TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]

15:29 TMM has joined #dri-devel

15:30 <nanonyme> MrCooper, there wouldn't by any chance be information if these LTO issues are all with GCC12? There are other libraries as well (dav1d) which are suffering of incorrect code generated by GCC 12 LTO (to the extent of crashes)

15:33 X512 has joined #dri-devel

15:33 <X512> MrCooper: Why? Mesa use come undefined behavior code?

15:36 <jenatali> Since at least in some cases it's caused by adding more drivers to the build, it sounds like I correct folding of different static functions with the same name

15:36 <jenatali> Incorrect*

15:37 <MrCooper> nanonyme X512: the reasons are unclear, the best lead so far is the thread starting at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20375#note_1732688

15:41 <ishitatsuyuki> which drivers are concerned with the LTO issue?

15:41 <X512> Some question about EGL: should context be selected when eglSwapBuffers is called?

15:46 <nanonyme> Yeah. But thanks for confirmation. We will proceed with release maybe next week with LTO disabled. Apparently there's quite a few RDNA 3 users already that need their hardware supported :)

15:46 <nanonyme> (that is, it was good to find out it was related to LTO, not LLVM 15 bump)

15:56 <MrCooper> X512: yes, eglSwapBuffers requires a current context (and the swapped surface to be bound to that context), in contrast to glXSwapBuffers

16:01 doomjoshuaboy has quit [Remote host closed the connection]

16:18 X512 has quit [Ping timeout: 480 seconds]

16:51 agd5f_ has joined #dri-devel

16:57 agd5f has quit [Ping timeout: 480 seconds]

16:58 agd5f has joined #dri-devel

17:00 agd5f_ has quit [Ping timeout: 480 seconds]

17:07 junaid has joined #dri-devel

17:19 bluetail89482 has quit [Read error: Connection reset by peer]

17:19 junaid has quit [Ping timeout: 480 seconds]

17:21 bluetail89482 has joined #dri-devel

17:28 <nanonyme> Does AMD RDNA 3 use radeonsi or Zink?

17:30 gouchi has joined #dri-devel

17:30 X512 has joined #dri-devel

17:31 <X512> RADV -> Zink path work for at least Radeon SI+ GPUs.

17:31 <X512> Don't know about Gallium radeonsi driver.

17:32 <kisak> mesa/radeonsi 22.2+ supports RDNA3

17:33 Jeremy_Rand_Talos has quit [Remote host closed the connection]

17:34 Jeremy_Rand_Talos has joined #dri-devel

17:39 <nanonyme> Okay, that doesn't explain then why the corruption only seemed to be happening for users of older chipsets

17:41 <kisak> if you're just now moving to llvm 15, then the RDNA3 users could have been on llvmpipe

17:41 <kisak> ^ with llvm 14.0

17:47 Mangix has quit [Ping timeout: 480 seconds]

17:47 kzd has joined #dri-devel

17:48 <nanonyme> kisak, well, they reported the didn't have properly functioning GL until LLVM 15 update. And they didn't see the corruption.

17:48 <nanonyme> Sample size is not large

17:49 <nanonyme> It of course could be mere coincidence if some codepath used by RDNA 3 in radeonsi was less broken than for older ones...

17:50 <kisak> the intent of my last comment was just to highlight that mesa 22.2+ needed to be built against llvm 15 for the RDNA3 support to get turned on.

17:51 <nanonyme> Sure. We had LLVM 14 + Mesa 22.3.2 (which worked with LTO) and then updated to LLVM 15 + Mesa 22.3.3 (which broke for everyone else but these RDNA 3 users with LTO)

17:53 <nanonyme> Separately rebuilding everything with LLVM 14 was not enough to get rid of corruption with LTO.

17:53 <nanonyme> (that is, Mesa with LTO)

17:54 Mangix has joined #dri-devel

17:59 lemonzest has quit [Quit: WeeChat 3.6]

18:06 Leopold__ has joined #dri-devel

18:11 Leopold_ has quit [Ping timeout: 480 seconds]

18:11 luc4 has quit [Ping timeout: 480 seconds]

18:14 kts has joined #dri-devel

18:19 fxkamd has joined #dri-devel

18:23 imre has quit [Quit: leaving]

18:26 kts has quit [Quit: Leaving]

18:39 alanc has quit [Remote host closed the connection]

18:39 alanc has joined #dri-devel

18:41 <Ristovski> Hmm, why do amdgpu HW block IPs have multiple "segments"? What does that even mean, I can't find any docs

18:42 <X512> Do you mean instance ID? It seems not used yet.

18:43 <Ristovski> X512: I'm talking about this: https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/amd/include/renoir_ip_offset.h#L198 (note line)

18:43 <Ristovski> I am not sure which base to use for reading registers (via `debug/dri/0/amdgpu_regs`)

18:45 <Ristovski> The instance ID is used for certain IPs, for example `ip_discovery/die/0/CLKA/` has `0, 1, 2`

18:46 <Ristovski> but then each instance itself has multiple base addresses (in the case of CLKA, two "segments" for each instance)

19:12 junaid has joined #dri-devel

19:34 fab has quit [Quit: fab]

19:36 fab has joined #dri-devel

19:59 Jeremy_Rand_Talos_ has joined #dri-devel

20:04 Jeremy_Rand_Talos has quit [Remote host closed the connection]

20:07 jluthra has quit [Remote host closed the connection]

20:07 jluthra has joined #dri-devel

20:15 lumidify has joined #dri-devel

20:25 the_sea_peoples has joined #dri-devel

20:26 doomjoshuaboy has joined #dri-devel

20:29 doomjoshuaboy has quit [Remote host closed the connection]

20:42 JohnnyonFlame has joined #dri-devel

20:46 Leopold__ has quit [Ping timeout: 480 seconds]

20:54 Leopold_ has joined #dri-devel

20:56 fxkamd has quit []

21:13 kzd has quit [Quit: kzd]

21:19 kzd has joined #dri-devel

21:36 bluetail894825 has joined #dri-devel

21:40 bluetail894825 has quit [Read error: Connection reset by peer]

21:43 bluetail89482 has quit [Ping timeout: 480 seconds]

21:46 ice9 has quit [Ping timeout: 480 seconds]

21:52 agd5f_ has joined #dri-devel

21:56 Duke`` has quit [Ping timeout: 480 seconds]

21:58 agd5f has quit [Ping timeout: 480 seconds]

22:19 Leopold_ has quit [Ping timeout: 480 seconds]

22:24 Haaninjo has quit [Quit: Ex-Chat]

22:26 Leopold_ has joined #dri-devel

22:28 kzd has quit [Quit: kzd]

22:30 kzd has joined #dri-devel

22:32 jewins has joined #dri-devel

22:37 fab has quit [Quit: fab]

22:40 gouchi has quit [Remote host closed the connection]

22:46 Jeremy_Rand_Talos_ has quit [Remote host closed the connection]

22:46 Jeremy_Rand_Talos_ has joined #dri-devel

22:47 jernej_ has joined #dri-devel

22:47 jernej has quit [Read error: Connection reset by peer]

22:48 junaid has quit [Ping timeout: 480 seconds]

22:50 rasterman has quit [Quit: Gettin' stinky!]

22:54 luc4 has joined #dri-devel

23:02 vidal72[m] has joined #dri-devel

23:06 mbrost has joined #dri-devel

23:09 alarumbe has quit [Ping timeout: 480 seconds]

23:10 alarumbe has joined #dri-devel

23:25 mbrost has quit [Read error: Connection reset by peer]

23:28 mattst88 has quit [Quit: leaving]

23:37 mattst88 has joined #dri-devel

23:53 jewins has quit [Ping timeout: 480 seconds]