01:14anholt_: hakzsam: how portable is the fossilize db?
02:00lrusak: anyone know how to update the github mirror for drm-tip? https://github.com/freedesktop/drm-tip
05:20udovdh: what to do with this message?
05:20udovdh: amdgpu 0000:0a:00.0: RAS: ras ta ucode is not available
05:22udovdh: what about this reset sequence?
05:22udovdh: timeout happened while box was sitting with screensaver
05:33udovdh: w.r.t. the ras ta ucode: latest linux-firmware is installed on my Fedora 31
10:24udovdh: what to do with this message?
10:24udovdh: amdgpu 0000:0a:00.0: RAS: ras ta ucode is not available
10:24udovdh: impact? solution? (on Fedora 31)
10:24udovdh: what about this reset sequence? (5.3.18)
10:25udovdh: timeout happened while box was sitting with screensaver
10:25udovdh: w.r.t. the ras ta ucode: latest linux-firmware is installed on my Fedora 31
15:44vv221: Hello World! I’m trying to learn regression testing with Mesa current build tools (meson/ninja). As I’m trying to build 32-bit libraries on a 64-bit system, would you say that a 32-bit chroot is a pain-free environment?
15:44vv221: (the host I’m working with is a Debian Sid)
16:20vv221: Well, it seems to be quite easy to build in a 32-bit chroot with meson/ninja + ccache, I should be able to test multiple versions quite quickly.
17:04AndrewR: hi all. I think I run into compilation problem with latest mesa git (x86, 32 bit). Part of error: https://pastebin.com/rvHbaejL I updated python to 3.7.2 /Mako was 1.0.8 rebuild /meson at 0.53.x ..no, error still here.
17:14romangg: vv221: Do you have a link with information how to do that (32-bit chroot for building mesa 32bit)?
17:15vv221: No, I didn’t follow any guide. Do you want me to paste somewhere what I did?
17:18vv221: There you go, it is a very simple process: https://paste.debian.net/plain/1133898
17:18romangg: sure. thanks!
17:19vv221: At the end, "chroot-sid-buildd-i386" is a chroot ready to build mesa from git.
17:20romangg: I'm trying to compile 32bit at the moment. On Arch it worked without issues but on Ubuntu once again some package fuckup prevents one from using multiarch-libs (libicu in this case) and until now I circumvented that with a full virtual machine but maybe this is less cumbersome.
17:21romangg: hmm, looks less cumbersome for sure. ;)
17:21vv221: I tried cross-compilation on the 64-bit host first, but like you got difficulties with multi-arch.
17:22vv221: But I tend to never use VM until I’ve at least given a try to a good old chroot ;)
17:26vv221: Once I had the chroot ready, I added a non-root user, bind mounted a git clone of Mesa repo in its home, then started the build with:
17:26vv221: meson --reconfigure --prefix="$PWD/build/install" build && ninja -C build clean && ninja -C build && ninja -C build install
17:26vv221: The bind mount is to have an easy access to the built libraries from outside the chroot.
17:26vv221: As I planned to do regression tests, so multiple builds, I installed `ccache` too.
17:27vv221: (in the chroot)
17:47vv221: I’m trying to generate a trace using `apitrace`, for the preparation of a bug report I plan to post. But for some reason I get an almost empty trace, cf. https://forge.dotslashplay.it/play.it/games/issues/84#note_15234
17:47vv221: The tested software is Memoranda, a 32-bit game.
17:48vv221: I don’t know if I’m doing something wrong with `apitrace` (it’s the first time I use it), or if this kind of output is expected in some cases.
17:54vv221: Nevermind, I worked around this following this guide: https://github.com/apitrace/apitrace/blob/master/docs/USAGE.markdown#tracing-manually
18:08vv221: And here goes my first Mesa bug report, I hope I did provide enough information: https://gitlab.freedesktop.org/mesa/mesa/issues/2611
18:08gitbot: Mesa issue 2611 in mesa "Memoranda + amdgpu — Segmentation fault on launch" [Opened]
19:13karolherbst: uff generic pointers uff...
19:27karolherbst: jekstrand: any opinions on how to implement generic pointers? I'd just treat generic as global and cast will convert the pointers via intrinsics. And then later we could optimize those away or so
19:45karolherbst: mhh.. actually maybe we just want them to be normal deref casts and lower_explicit_io deals with those casts accordingly
21:25imirkin: pepp: hey, so nouveau started hitting asserts with commit 24f2b0a8560f347 (gallium/video: remove pipe_video_buffer.chroma_format)
21:25imirkin: p_surf->templat.buffer_format == NV12, but chromatype == VDP_CHROMA_TYPE_422, so it goes boom
21:26imirkin: however from the looks of it, this assertion is doomed... the driver will always return some single format since the inputs to get_video_param are constant
21:26imirkin: whereas the chromatype is an input into the function, thus variable
23:58imirkin: anyone have a quick script to determine the commit date of each branch?
23:58imirkin: and maybe even sort :)