00:01vv222: I’m going to give it a new try with LLVM 7, that seems to be closer to what Mesa 17 could expect.
00:01vv222: (previous tries were with LLVM 9)
00:16vv222: It seems I went one step further by adding the missing include, it is now failing in some xvmc_bench.c: https://paste.debian.net/plain/1161797
00:16vv222: It it is only a test file that can not be built, I’m OK with skipping them but did not found a configure option for that.
01:15vv222: I finally got a build \o/
01:15vv222: But it seems I missed something related to the radeonsi driver: https://paste.debian.net/plain/1161799
01:33vv222: Done, I was missing a --enable-dri3 ;)
01:34vv222: OpenGL version string: 2.1 Mesa 17.3.9 \o/
09:33MrCooper: DPA: right, so etnaviv needs to keep a duplicate of the original DRM FD passed in for creating the pipe_screen, and generate GEM handles valid for that, similar to iris or radeonsi's amdgpu winsys
13:24ickle: /win 18
14:16klys: hello. I was just looking at libdrm and noticing there is no virgl code in there.
14:17klys: should virtio-gpu be pretty easy to support in libdrm?
14:30careta: hey guys, not sure if this is the right place to ask, but I'm having trouble getting my Intel 520 laptop to output 4k@60 Hz
14:30careta: the problem is that Windows works fine, but Linux craps out
14:32careta: the farthest I have gotten was to add a special mode in xrandr that I found in the depts of the Internet
14:32careta: it does output 4k@60 Hz but image quality is crap, and there's flickering in the last 100 px of the screen to the right
14:34klys: careta, have you adjusted it with a modeline calculator?
14:36botto: klys, careta here, my connection went down - do you mean cvt? I basically just used cvt to create a mode, that didn't work, then used the mode I found on the Internet
14:37klys: there are various modeline calculators available.
14:38botto: klys, any suggestion?
14:42careta: a windows utility?
14:42careta: ok I'll run and check
14:46careta: xrandr: Configure crtc 1 failed
14:47klys: were you using this?: Modeline "3840x2160x60.00" 713.295360 3840 4152 4576 5312 2160 2164 2168 2238 -HSync +VSync
14:47careta: yes, exactly that\
14:47careta: it's very similar to the one calculated by cvt
14:48klys: have you tried for interlacing yet?
14:48careta: no, I'll try now
14:49careta: same error
14:50klys: okay what's your mode that you have?
14:50careta: works perfectly 4k@30hz: 3840x2160 30.00*+ 25.00 24.00 29.97 23.98
14:50careta: the mode that kind of works but looks like crap is: "3840x2160_60" 534.010 3840 3982 4027 4064 2160 2170 2180 2190 +hsync +vsync
14:55klys: careta, try something like this yet?: umc 3840 2160 534000000
14:58klys: careta, when I did that it gave me: Modeline "3840x2160x45.70" 534.010000 3840 4128 4552 5264 2160 2164 2168 2220 -HSync +VSync
15:13careta: klys, I get "resolution not supported" on the TV
15:15klys: careta, try pumping it up to say, 600000000 ?
15:15klys: Modeline "3840x2160x51.05" 600.000000 3840 4136 4560 5280 2160 2164 2168 2226 -HSync +VSync
15:19careta: klys, I get a blueish screen with everything frozen; also tried pumping to 650 but it says again resolution not supported
15:19careta: is there any way to extract this mode when running windows?
15:19careta: I mean, the mode that Windows is running on
15:32careta: klys, appreciate your help - is there another point of contact? should I use the mailing list perhaps?
15:33careta: since it works on Windows I'm pretty sure this is a Linux problem
15:37klys: careta, maybe the mailing list would help, I'm not on the list myself. It's more active than IRC though. I would say try some of the other options and keep testing.
15:38kisak: klys: maybe try 594? https://gitlab.freedesktop.org/drm/intel/-/issues/2195
15:58careta: kisak, hangs on a blueish screen
15:59careta: if there's a way to extract timing info from Windows, then that's a guaranteed win
18:44airlied: klys: libdrm is just utility code, virtiogou has ni need for code n it
18:46klys: airlied, thank you. I've been trying to compile sdl
22:22karolherbst: ahh.. I am getting defeated by nir serialize :/
23:00airlied: karolherbst: found another bug?
23:01karolherbst: airlied: no.. just playing around on how to mark alu ops as requiering CL precision
23:03karolherbst: airlied: I was thinking about adding a "cl" flag to nir_alu_instr, but now I can't serialize it...
23:06karolherbst: I am wondering if we need an entirely new approach on how we serialize nir, because how it's right now is a complete mess if you want to add anything ...
23:16karolherbst: mhh.. I have an idea
23:17karolherbst: I guess we can write another uin8_t for kernels ..
23:35karolherbst: "vec1 32 ssa_29 = fdiv.cl ssa_20, ssa_28" :)