#dri-devel on 2022-12-30 — 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:00 agd5f has quit [Read error: No route to host]

00:03 ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]

00:05 agd5f has joined #dri-devel

00:24 Didgy has joined #dri-devel

00:25 Didgy has quit [Quit: Konversation terminated!]

00:25 Didgy has joined #dri-devel

00:25 Didgy has quit []

00:26 Didgy has joined #dri-devel

00:32 <Didgy> Heya folks, I'm trying to get started learning driver development, preferably Vulkan. I'm familiar with C/C++ and how to write Vulkan applications, now I want to learn the other side of the stack. Do you have any recommendations on where to start reading? My initial plan is just to study the RPi4 and Intel Vulkan drivers, and see what I can figure out

00:40 <airlied> the intel and amd drivers are probably simpler to understand than the rpi one

00:40 <airlied> though may also have more features

00:40 <airlied> there is also the main vulkan driver and the shader compiler

00:41 ngcortes has joined #dri-devel

00:42 <airlied> Lynne: I'm not sure how much more is needed on the driver side for P frames

00:46 pcercuei has quit [Quit: dodo]

00:51 <Lynne> not a lot, I'm almost done

00:52 lemonzest has quit [Quit: WeeChat 3.6]

00:54 ngcortes has quit [Ping timeout: 480 seconds]

00:55 Didgy has quit [Quit: Konversation terminated!]

01:00 <Lynne> airlied: pushed

01:00 <Lynne> 2-frame gop, first frame in slot 0 is key, second frame in slot 1 is a p-frame

01:01 <Lynne> btw I asked this yesterday, but do you know of any drivers or devices where layout conversions aren't actual noops?

01:01 <Lynne> (my rewrite from earlier eliminated most layout conversions, since the DBP doesn't need any)

01:02 ybogdano has quit [Ping timeout: 480 seconds]

01:03 <bnieuwenhuizen> are we talking vulkan image layout?

01:04 <bnieuwenhuizen> if so, AMD, just only for compressed surfaces, which we only support for tiled images (and in particular haven't implemented for multiplanar images)

01:08 <Lynne> huh, curious

01:08 <Lynne> how does it work, is there a GPU memcpy to convert between the layouts?

01:09 <bnieuwenhuizen> most of it is just decompressing (or moving it to a somewhat more decompressed state, e.g. with clear colors)

01:11 <bnieuwenhuizen> generally happens in place (either by a fullscreen draw where we tell the color target unit to decompressed or by compute shader)

01:15 <Lynne> must be nice having enough registers and vector sizes to store and decompress block-wise

01:15 <airlied> Lynne: typo? .pictureType = pic->type == FF_VK_FRAME_P ? STD_VIDEO_H264_PICTURE_TYPE_I :

01:16 <bnieuwenhuizen> the block wise decompression is done by using LDS/shared memory in a workgroup (though a block is 256 bytes for decompression so that would fit in a single invocation if needed)

01:17 <Lynne> airlied: yup, a typo, fixed that, now P-frames have a "reference overflow 49 > 15 or 0 > 15" error when decoding

01:17 <Lynne> it's progress

01:17 <bnieuwenhuizen> actually never mind, we don't even use shared memory, just a workgroup barrier

01:18 <Lynne> on a related note, for gsoc, I'm planning on getting someone to write some hybrid vulkan encoders/decoders for simple codecs like vc2/dirac and prores

01:20 * airlied is considering openh264/lavapipe crossover at some point, could also do av1 I suppose

01:32 co1umbarius has joined #dri-devel

01:32 camus has joined #dri-devel

01:32 <Lynne> do you really need it? practically everything comes with h264 decoding these days

01:33 <kisak> if you want to expose Vulkan video via lavapipe, you have to back it with something. bolting on an existing implementation is easier than reinventing the wheel

01:33 columbarius has quit [Ping timeout: 480 seconds]

01:34 <airlied> Lynne: I have to make things work in wierd places for completion :-P

01:35 <kisak> airlied: is openh264's license compatible with mesa?

01:35 <kisak> oh, 2 clause BSD license, less strange than I expected

01:37 <jenatali> We've got internal versions of our software rasterizer that do D3D12 video for testing purposes by bolting on software dec/enc. Makes a lot of sense

01:37 camus1 has quit [Ping timeout: 480 seconds]

01:47 <airlied> Lynne: I'm missing something, how do I know the dpb slot of the current image I'm encoding? or is that not something I need?

01:53 <airlied> Lynne: some more conformant frames now

01:58 <Lynne> it's via the picture slot in encode info

01:58 <Lynne> pSetupReferenceSlot

02:04 <airlied> ah not sure how I missed that, thanks!

02:06 <Lynne> making the quantizer higher in radv_enc_rc_per_pic reveals what's happening

02:06 <Lynne> *lower

02:06 <Lynne> the reference used seems to be at an offset

02:07 <Lynne> in that objects towards the middle of the frame are pushed to the left in the ref

02:18 <airlied> Lynne: is frame_num == 0 always correct?

02:18 HerrSpliet has joined #dri-devel

02:22 RSpliet has quit [Ping timeout: 480 seconds]

02:23 <airlied> pushed some minor cleanups

02:34 <Lynne> no, frame_num should be 1 for the p-frame

02:39 <airlied> okay I'm seeing a 0 there

02:39 <Lynne> checked, it's a 1 on my end for I-frames

02:41 <airlied> https://paste.centos.org/view/raw/16d23f54

02:43 <airlied> Lynne: frame_num is used uninit at line 618?

02:45 <airlied> setting frame_num to 0 gets me a frame num of 1

02:47 <airlied> https://paste.centos.org/view/00be9215 is my current diff

02:48 <airlied> oops the second one is in your tree

02:48 <Lynne> oh, that frame number

02:48 <Lynne> it's meant to be zero, because your keyframe is at slot 0

02:49 <airlied> yeah but for the P frame you had prev->is_reference to it so it should be 1?

02:50 <airlied> ^had^add

02:50 <airlied> in any case adding to an uninit var is wrong :-)

02:57 <Lynne> uninit var? where

02:58 <Lynne> also, that frame number is in the reflist

02:58 <Lynne> there, it should be zero, because it's referencing the keyframe

02:58 <airlied> Lynne: int frame_num; then you have frame_num = frame_num + prev->is_reference;

02:59 <airlied> in the non key frame path

02:59 <airlied> vulkan_encode_h264.c:618

03:07 <Lynne> ah, I'll fix it in a bit

03:14 <airlied> Lynne: should you be setting pictureType to IDR for key frames?

03:14 <airlied> i.e. is there a difference between I + idr_flag = true and IDR pictureType?

03:15 <airlied> since the header defines STD_VIDEO_H264_PICTURE_TYPE_IDR

03:23 <Lynne> oh, it does?

03:26 <airlied> yeah slice type is p/b/i but picture type is p/b/i/idr

03:26 <airlied> though I think you get the slice_type wrong

03:27 <airlied> since you use the spec values not the STD_VIDEO one

03:27 <Lynne> ah, no, I looked at that, the standard is wrong

03:27 <Lynne> slice types above 5 indicate that all following slices are going to be coded in the same slice type

03:27 <airlied> okay so the vulkan spec needs fixing?

03:28 <Lynne> yup, I'll add a SPEC note

03:29 <Lynne> pushed

03:30 <Lynne> if you need a reference, look at vaapi_encode_h264_init_picture_params in vaapi_encode_h264.c

03:31 <Lynne> since I did copy some code out of it

03:34 <airlied> Lynne: is there a vaapi command I could run to reproduce the behaviour we are doing for vulkan?

03:43 <Lynne> yeah, "./ffmpeg_g -init_hw_device "vaapi=vp:/dev/dri/renderD128" -i SAMPLE_720.nut -filter_hw_device vp -vf format=nv12,hwupload -c:v h264_vaapi -g 2 -keyint_min 2 -vframes 2 -rc_mode CQP -qp 20 -y test.ts"

03:48 jernej- has quit []

03:48 jernej has joined #dri-devel

03:49 <DemiMarie> <tleydxdy> "not before nv go out of business" <- I wonder if some Linux kernel dev has made it so that one cannot write a GPU driver without `EXPORT_SYMBOL_GPL` APIs.

03:51 <Lynne> no, there are more elegant ways of doing this, like breaking the floating-point enabling api on every release or so

03:56 camus has quit [Remote host closed the connection]

04:05 <ccr> I'm sure the magic will just move onto closed firmware and userspace blobs.

04:11 <airlied> it's already moved

04:12 <airlied> they have an GPL compatible kernel module now

04:13 <ccr> not mainlined yet .. or has that progressed in some significant way?

04:14 <airlied> that doesn't matter to them

04:14 <ccr> yah, I suppose not.

04:15 <airlied> the kernel devs changing GPL symbols won't affect them anymore

04:15 <airlied> well once they make it default

04:22 <airlied> Lynne: pushed a few more changes one for qp again

04:22 <airlied> hmm throwing my horror ff trailer at it gets me a free gpu lockup

04:23 <airlied> oh and possibly some vmfaults

04:23 <DemiMarie> What is the Intel Protected Xe Path? The documentation I have found is utterly useless.

04:26 <Lynne> airlied: hm, nope, changing the QP in ffmpeg still doesn't change it on the output

04:26 <Lynne> I also had a hangup when I messed around with the slots

04:27 <Lynne> (and an epic hangup when I ran video commands on a general queue by accident)

04:28 <ccr> sounds like happy fun debugging times :P

04:29 <DemiMarie> airlied: did you see my message?

04:30 <DemiMarie> wanting to maek sure it made it to IRC

04:31 <hays> are you all ok fielding a question about errors when linking against mali blobs?

04:32 <hays> if so, https://h0c.us/v/P1phLA/r im trying to understand if there is a fix for this kind of error. getting it on a few things

04:53 <airlied> DemiMarie: yeah no idea about PXP

04:54 <airlied> Lynne: wierd I'd have expected that to do something :-P

04:55 <Lynne> speaking of crashes, I wonder if my one-liner ffmpeg command to hard-freeze intel gpus still works

04:56 <Lynne> they had an issue with SIMD and workgroup barriers

05:23 bmodem has joined #dri-devel

05:25 rcf has quit [Ping timeout: 480 seconds]

05:32 <DemiMarie> airlied: Thanks!

05:40 rcf has joined #dri-devel

05:44 <Frogging101> PXP sounds like something for DRM

05:50 JohnnyonF has quit [Ping timeout: 480 seconds]

05:51 elongbug_ has quit [Remote host closed the connection]

05:52 elongbug_ has joined #dri-devel

05:54 <DemiMarie> It does, but Microsoft seems to be considering using PXP with SGX for hybrid CPU/GPU enclaves.

05:55 <airlied> yeah it's probably more confidential compute stuff

06:13 bmodem1 has joined #dri-devel

06:18 bmodem has quit [Ping timeout: 480 seconds]

06:19 elongbug_ has quit []

06:20 jewins has quit [Ping timeout: 480 seconds]

06:21 elongbug has joined #dri-devel

06:22 <elongbug> airlied: thanks for merging 6.2 rc1 to drm-next.

06:34 lemonzest has joined #dri-devel

06:51 Company has quit [Read error: Connection reset by peer]

06:51 kts has joined #dri-devel

07:01 heat has quit [Ping timeout: 480 seconds]

07:13 kts has quit [Read error: Connection reset by peer]

07:19 YuGiOhJCJ has joined #dri-devel

07:25 srslypascal is now known as Guest763

07:25 srslypascal has joined #dri-devel

07:28 Guest763 has quit [Ping timeout: 480 seconds]

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

07:39 alanc has joined #dri-devel

07:45 macromorgan is now known as Guest764

07:45 macromorgan has joined #dri-devel

07:46 ahajda has joined #dri-devel

07:48 kts has joined #dri-devel

07:53 Guest764 has quit [Ping timeout: 480 seconds]

07:56 bmodem1 has quit [Ping timeout: 480 seconds]

08:02 srslypascal is now known as Guest767

08:02 srslypascal has joined #dri-devel

08:03 Duke`` has joined #dri-devel

08:08 Guest767 has quit [Ping timeout: 480 seconds]

08:21 bmodem has joined #dri-devel

08:44 dantob has joined #dri-devel

08:45 mvlad has joined #dri-devel

08:54 rasterman has joined #dri-devel

09:05 jkrzyszt has joined #dri-devel

09:32 elongbug_ has joined #dri-devel

09:32 elongbug has quit [Read error: Connection reset by peer]

09:37 sh-zam has quit [Ping timeout: 480 seconds]

09:37 sh_zam has joined #dri-devel

09:50 Didgy has joined #dri-devel

09:52 <Didgy> I understand there's many helper functions and tools in Mesa. Is there an overview or API reference to these? I'm particularly interested in the ones related to Vulkan

09:53 <ishitatsuyuki> didgy: If you are interested in the common Vulkan entrypoints for drivers, maybe searching for the respective merge requests would help

09:54 YuGiOhJCJ has quit [Quit: YuGiOhJCJ]

09:56 bmodem1 has joined #dri-devel

10:02 bmodem has quit [Ping timeout: 480 seconds]

10:02 <Didgy> So it seems there's gone a lot of work into making reusable components that can be reused in various drivers. How do you keep track of which functions you can use?

10:06 camus has joined #dri-devel

10:19 <kusma> didgy: Are you looking at Gallium drivers or Vulkan drivers? The philosophy is a bit different between those...

10:20 Duke`` has quit [Ping timeout: 480 seconds]

10:21 Duke`` has joined #dri-devel

10:21 <kusma> For gallium drivers, most "reusable components" are in src/gallium/auxiliary, whereas for Vulkan, you can find most helpers in src/vulkan

10:21 fab has joined #dri-devel

10:31 <Didgy> I'm mostly looking for Vulkan, that is my area of interest

10:37 HerrSpliet has quit [Quit: Bye bye man, bye bye]

10:39 RSpliet has joined #dri-devel

10:53 Haaninjo has joined #dri-devel

10:54 Duke`` has quit [Ping timeout: 480 seconds]

10:54 Duke`` has joined #dri-devel

11:03 fab has quit [Ping timeout: 480 seconds]

11:08 Duke`` has quit []

11:12 Duke`` has joined #dri-devel

11:13 <Didgy> How did you guys get started with GPU driver development?

11:24 sgruszka has joined #dri-devel

11:25 Duke`` has quit []

11:31 <ishitatsuyuki> I started with messing around performance with Radeon GPU Profiler, then I digged into the non-shader side of stuff when trying to get a game working properly on Linux

11:57 <kode54> elongbug_: your patch series merges just fine into 6.2-rc1

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

12:22 <kode54> elongbug_: I thought the patch crashed my startup

12:22 <kode54> but it turns out it was a big mistake to downgrade linux-firmware to the stable release

12:22 <kode54> 2022-12-16 snapshot works

12:29 <jani> tomba: cheers, any DSI insight on why a single-link panel would behave like this: https://gitlab.freedesktop.org/drm/intel/-/issues/7717 ?

12:30 <jani> tomba: I know the Intel GPU part does not interest you in the least, but any ideas on the DSI level? I'm a bit baffled, since it's not dual-link

12:40 bmodem has joined #dri-devel

12:41 pcercuei has joined #dri-devel

12:44 bmodem1 has quit [Ping timeout: 480 seconds]

13:07 <kusma> didgy: I got hired by Falanx Microsystems (now ARM Norway) back in the early days, where a friend through the demoscene was already the only person on the driver development team, and I had been helping him with the robustness and performance for the SW T&L clipping code...

13:09 bmodem has quit [Ping timeout: 480 seconds]

13:10 JohnnyonFlame has joined #dri-devel

13:11 warpme_____ has joined #dri-devel

13:27 elongbug_ has quit []

13:27 elongbug has joined #dri-devel

13:28 kts has quit [Remote host closed the connection]

13:29 <elongbug> kode54: could you share your crash log or dmesg?

13:36 Company has joined #dri-devel

13:57 q4a has joined #dri-devel

13:57 agd5f has quit [Remote host closed the connection]

13:59 <q4a> Is there any news about this bug https://gitlab.freedesktop.org/mesa/mesa/-/issues/7688 ? Looks like it's not only rusticl problem

14:14 kts has joined #dri-devel

14:21 kts has quit [Quit: Leaving]

14:23 Akari has joined #dri-devel

14:54 rmckeever has quit [Quit: Leaving]

14:57 <tomba> jani: is there just a vertical split, or also a horizontal split? hard to say from the pic. in any case, nothing on the DSI level comes to mind causing this. there could, e.g, be two pixel packets per line, and for some reason the other one is broken. but I can't really say anything sensible with these details (and no understanding of the display controller).

15:00 bmodem has joined #dri-devel

15:10 bmodem has quit [Ping timeout: 480 seconds]

15:15 jkrzyszt has quit [Remote host closed the connection]

15:21 <Didgy> kusma: That's cool, I had an interview with Arm Norway this summer, I'm hoping to maybe get a job there after I'm done with my degree

15:24 Surkow|laptop has quit [Ping timeout: 480 seconds]

15:30 jkrzyszt has joined #dri-devel

15:30 Surkow|laptop has joined #dri-devel

15:34 heat has joined #dri-devel

15:35 ADS_Sr has joined #dri-devel

15:39 paulk-bis has joined #dri-devel

15:39 paulk has quit [Read error: Connection reset by peer]

15:42 turol has quit [Ping timeout: 480 seconds]

15:51 turol has joined #dri-devel

15:52 agd5f has joined #dri-devel

15:55 arnd_ has quit []

15:56 arnd has joined #dri-devel

16:01 jewins has joined #dri-devel

16:03 bmodem has joined #dri-devel

16:14 kts has joined #dri-devel

16:17 kts has quit []

16:34 gouchi has joined #dri-devel

16:48 tobiasjakobi has joined #dri-devel

16:49 tobiasjakobi has quit []

16:56 JohnnyonFlame has quit [Ping timeout: 480 seconds]

17:16 ADS_Sr_ has joined #dri-devel

17:17 fab has joined #dri-devel

17:19 ADS_Sr__ has joined #dri-devel

17:19 ADS_Sr_ has quit []

17:30 ADS_Sr is now known as Guest802

17:30 ADS_Sr__ is now known as ADS_Sr

17:32 Guest802 has quit []

17:46 fab has quit [Quit: fab]

18:03 Akari has quit [Quit: segmentation fault (core dumped)]

18:16 egbert has joined #dri-devel

18:24 jkrzyszt has quit [Ping timeout: 480 seconds]

18:26 Duke`` has joined #dri-devel

18:47 camus has quit [Remote host closed the connection]

18:47 camus has joined #dri-devel

18:52 bmodem has quit [Ping timeout: 480 seconds]

19:09 JohnnyonFlame has joined #dri-devel

19:12 sarnex has quit [Quit: Quit]

19:15 ADS_Sr has quit [Remote host closed the connection]

19:16 ADS_Sr has joined #dri-devel

19:22 sarnex has joined #dri-devel

19:23 ADS_Sr has quit [Remote host closed the connection]

19:23 ADS_Sr has joined #dri-devel

19:24 sarnex has quit []

19:30 sarnex has joined #dri-devel

19:31 ngcortes has joined #dri-devel

19:39 ADS_Sr has quit [Read error: Connection reset by peer]

19:43 sarnex has quit [Quit: Quit]

19:46 warpme_____ has quit []

19:48 ADS_Sr has joined #dri-devel

19:48 sarnex has joined #dri-devel

19:49 ngcortes has quit [Ping timeout: 480 seconds]

19:54 camus has quit [Remote host closed the connection]

19:55 camus has joined #dri-devel

19:56 ADS_Sr has quit [Read error: Connection reset by peer]

19:58 ADS_Sr has joined #dri-devel

20:06 camus1 has joined #dri-devel

20:11 camus has quit [Ping timeout: 480 seconds]

20:26 <airlied> Lynne: dreamt up a problem in the dpb setup, pushed a fix, still not prefect I don't think

20:28 fab has joined #dri-devel

20:28 camus1 has quit [Remote host closed the connection]

20:29 camus has joined #dri-devel

20:35 <airlied> at least fixes the lockups/faults with my ff trailer

20:39 <Lynne> airlied: found out I'm not locking the previous reference frame, nor supplying its semaphore

20:40 <Lynne> tried to, but it doesn't get signalled

20:43 Akari has joined #dri-devel

20:45 <Lynne> pushed to my branch

20:46 <Lynne> if I just ref the keyframe while it's being encoded so its reference leaks, and I do a sleep() before I do the query, the results look different

20:46 <Lynne> still corrupt, but it looks like the image is correct beneath the corruption, movement happens correctly

20:51 camus has quit [Remote host closed the connection]

20:51 rmckeever has joined #dri-devel

20:52 <airlied> Lynne: will that frame locking work okay with layered dpb?

20:53 camus has joined #dri-devel

20:54 mvlad has quit [Remote host closed the connection]

20:55 camus has quit [Remote host closed the connection]

20:57 camus has joined #dri-devel

21:00 <Lynne> aaaah, you're right, I have to add a check for that

21:02 <Lynne> also I just noticed the quantizer setting works

21:03 <Lynne> did someone fix this?

21:03 <Lynne> pushed

21:04 m00nlit[m] has joined #dri-devel

21:05 <airlied> Lynne: maybe fixing the dpb fixed it

21:13 <Lynne> ah, the driver didn't report any dpbs were supported

21:13 <Lynne> yeah, that would do it

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

21:16 <Lynne> the image does look okay with regards to prediction

21:16 ADS_Sr has quit []

21:16 camus has joined #dri-devel

21:16 <Lynne> just not with the random patches of translucent magenta around

21:16 ADS_Sr has joined #dri-devel

21:17 <airlied> Lynne: thinjk I got it

21:17 <airlied> fix in my branch

21:18 sarnex has quit [Quit: Quit]

21:19 <Lynne> almost, it's slightly better now

21:19 * airlied doesn't have purple patches anymore

21:20 <Lynne> let me test with a nicer video

21:22 ADS_Sr has quit [Read error: Connection reset by peer]

21:23 <Lynne> airlied: I do

21:23 <Lynne> the luma is 100% fine

21:23 <Lynne> the chroma has the corruption

21:23 sarnex has joined #dri-devel

21:24 <Lynne> I take that back, the luma has minor corruption, occasionally

21:24 <airlied> okay must still be some alignment issues in there

21:24 <Lynne> brb, gotta go to the store before it closes

21:25 fab has quit [Ping timeout: 480 seconds]

21:25 <airlied> Lynne: okay one more fix in there

21:25 <airlied> cool go store, let me know later, I'm pretty much finished in terms of time to do anything more before hols :-)

21:30 ADS_Sr has joined #dri-devel

21:30 <Lynne> airlied: IT WORKS!

21:32 <Lynne> 100% fine now, no corruption when comparing frame by frame

21:32 <airlied> yay happy dance! in your face other vendor who we shall not mention

21:32 <psykose> hurra

21:33 <Lynne> I'll be sure to insert my brand of snide in the issue when I casually mention it

21:33 <airlied> okay I think B frames will have to wait until post holidays :-P

21:33 <Lynne> I'll get everything ready, and get past 2-frame gops, which should be possible with the current driver

21:34 <Lynne> since p-frames may only have a single ref

21:36 <kode54> elongbug: the crashbug was unrelated to your patch

21:36 <kode54> and it wasn't a crashbug

21:36 <kode54> it was GuC failing to upload

21:37 <kode54> possibly related to the bug on the tracker for failing to upload after suspend

21:37 <kode54> except in my case, it was after a soft reboot

21:38 <kode54> I posted a bug to the i915 tracker on gitlab

21:38 <kode54> but it was not what I thought, so I closed it and linked to the other issue

21:38 <kode54> (the two firmware versions didn't change anything i915 related)

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

22:07 ybogdano has joined #dri-devel

22:13 ADS_Sr has quit [Remote host closed the connection]

22:18 ADS_Sr has joined #dri-devel

22:22 ADS_Sr has quit [Remote host closed the connection]

22:22 camus has quit [Remote host closed the connection]

22:23 camus has joined #dri-devel

22:23 ADS_Sr has joined #dri-devel

22:25 <Lynne> airlied: replicated the AV1 decoding issue, "amdgpu: The CS has been rejected (-22), but the context isn't robust." is what gets printed on stderr

22:34 ADS_Sr has quit [Read error: Connection reset by peer]

22:42 zaratustra has quit [Quit: zaratustra]

22:48 oneforall2 has quit [Remote host closed the connection]

22:50 oneforall2 has joined #dri-devel

22:52 zaratustra has joined #dri-devel

22:55 camus1 has joined #dri-devel

22:56 <airlied> Lynne: dmesg should have more info

22:59 camus has quit [Remote host closed the connection]

23:00 Haaninjo has quit [Quit: Ex-Chat]

23:02 <Lynne> nothing in dmesg

23:02 gouchi has quit [Remote host closed the connection]

23:04 <Lynne> ah, it's mesa printing this

23:09 <airlied> ah so doesn't sound like a gpu hang then just something getting miscoded

23:11 inverted has quit []

23:11 invertedoftc has joined #dri-devel

23:31 ngcortes has joined #dri-devel

23:38 camus1 has quit [Remote host closed the connection]

23:39 camus has joined #dri-devel

23:47 lemonzest has quit [Quit: WeeChat 3.6]

23:51 rasterman has quit [Quit: Gettin' stinky!]

23:52 ngcortes has quit [Ping timeout: 480 seconds]

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

23:58 cef has quit [Quit: Zoom!]