00:35pinchartl: airlied: ping
00:38airlied: pinchartl: pong
00:38pinchartl: airlied: https://patchwork.kernel.org/patch/11303057/
00:39pinchartl: at least two other similar fixes have been submitted, it's an issue in -next
00:39pinchartl: could you please pick it up ?
00:39pinchartl: we tried to get it merged through drm-misc, but the offending patch wasn't in drm-misc-next yet
00:39airlied: pinchartl: okay let me drop it in now then
00:39pinchartl: thank you
00:42airlied: pinchartl: pushed out now
00:42pinchartl: thank you :-)
02:31MaxLeiter: i'm attempting to build mesa on an unconventional system and the only display used will be Xvnc
02:32MaxLeiter: should I trust `auto` when it comes to drivers and meson? or do I only need virgl?
02:32imirkin: will this be running in a VM which presents the virgl API?
02:32imirkin: if not, you just want swrast and nothing else
03:21MaxLeiter: imirkin any clue what I want `glx` to be set to?
03:21MaxLeiter: auto probably?
03:22MaxLeiter: currently config looks like https://paste.sr.ht/blob/722355bca7dc93c9c79b17b5c47ae6ae7a26e004
05:32airlied: jekstrand: oh man the risc-v thing is a can of worms :-P
05:33jekstrand: airlied: I know :)
05:33airlied:is loathe to mention vulkan-llvmpipe in that thread
05:33jekstrand: airlied: Maybe I can get them to open their can somewhere else? :P
05:33jekstrand: airlied: Feel free not to
05:33airlied:can't actually tell from his description if llvmpipe would be a better model for his hw
05:34airlied: or a special nir backend
05:34jekstrand: Given that the hardware is vaporware, I'd say it doesn't matter
05:34airlied: yeah hence my steering far away from it :-P
05:35jekstrand: Aparently, they've been trying to get it into LLVM
05:35jekstrand: But, yeah, all I'm doing is educating people about the perils of vec4
05:35jekstrand: That's pretty much where I plan to stop. :)
05:37airlied: okay I'll just elect not to engage :-P
05:37jekstrand: Good plan
05:38jekstrand: At least, since they're planning on it being 100% userspace, you won't have to worry about them writing a DRM driver for it.
05:38jekstrand: Unless they want to make their RISC-V GPU a PCI card...
05:39airlied: yeah I'm very vague on their execution methods :-P
05:39airlied: like will they have lots of threads to parallelise, or just one vector unit per CPU thread
05:40HdkR: Is it just a bunch of RISC-V CPU cores without anything special?
05:40HdkR: That sounds terrible slow
05:41krh: not engaging is definitely the way to go
05:43krh: jekstrand: tell them to do one better and use vec8
05:44airlied: krh: vec16 or bust
05:44airlied: or someone could explain the evergreen VLIW5 model
05:52krh: airlied: a cpu with vec16 instructions... isn't that AVX512?
05:54airlied: krh: pretty much!
05:55HdkR: SVE2048 or bust
05:57jekstrand: krh: You should suggest AVX2 and they can just use ksim!
05:58jekstrand: Then they can run ANV on it
05:58krh: finally a use for ksim
05:59jekstrand: krh: I don't know that I'd go so far as to call rendering on RISC-V "a use" :P
05:59krh: not the glorious future I'd envisioned for it
06:00airlied: maybe we can ask whether he wants a cpu rasterizer and/or texture units :-P
06:04krh: I should add simd 4x2 support to ksim
06:57airlied: chrisf: does swiftshader vulkan run any steam titles?
06:57chrisf: airlied, ive mostly focused on android
06:57airlied: chrisf: I suppose that makes sense :-)
06:58chrisf: airlied, is close to running dota though
06:58airlied:sees talos splash screen sometimes, other times it just dies in talos code
06:59chrisf: airlied, vulkan UB is rough from driver side though when all the apps are slightly wrong
07:08chrisf: airlied, our initial feature set was pretty much the minimum the spec allows, *lots* of unchecked assumptions in apps
07:13airlied: chrisf: yeah I'm working my way up the basic 1.0 features now
07:14chrisf: lots of unchecked assumptions in CTS :P
07:14chrisf: so those are good to force out
07:15airlied: some things like maint2 may need some deeper driver work, the depth/stencil read only styff
07:16airlied: and of course I still have to write multisample
07:24chrisf: i suppose i should try talos and see if we're in ok shape with it :)
07:28airlied: I seem to be getting some misc random memroy corruption, granted my WSI, semaphores, and fences are all pretty bogus at the moment
07:29airlied: once Talos does start I get some OOB crash in a ubo load
08:41airlied: down to 310 fails and 27 crashes in cts now
09:43engys: hi everybody
09:44engys: I have a tiny problem while using mesa on rx 5700 xt
09:45engys: do you see the blocks on the map?
09:47engys: no idea why qt when using mesa opengl creating this blocks
09:48engys: vega and polaris work without any problem in this case
09:55engys: by the way I am using mesa 19.3.1
10:06pepp: engys: can you test using mesa master?
11:02engys: pepp: building right now
11:06engys: pepp: still the smae with mesa 20.0.0-devel
11:06engys: sry *same
11:08pepp: engys: thanks for testing. Can you open an issue (https://gitlab.freedesktop.org/mesa/mesa/issues) please?
12:01engys: pepp: https://gitlab.freedesktop.org/mesa/mesa/issues/2333
12:45pepp: engys: thanks. Would be nice to add a way to reproduce the issue
13:08engys: pepp: will take a moment to create a git with an example .. I thought someone already saw this flipping texture blocks on other stuff
13:09pepp: engys: maybe you could do an apitrace capture if it's easier?
13:15engys: pepp: that also only happens if you tilt the map 45 degree
13:15engys: pepp: I have never done an apitrace capture
13:18engys: maybe a good idea to test webasm =P
13:20engys: but I think the webgl link is missing .. so many new fancy stuff to check and so little time
13:33engys: so many hot stuff coming up with this problem -> QT Quick WebGL streaming =P
13:36dolphin: airlied, danvet: I got a power outage in the middle of writing the PR, that's why the extra "-1" in the PR tag
15:26seanpaul: danvet, pq: ok, back to the drawing board for the kernel flight recorder. i'm thinking now of exposing dedicated debugfs and tracefs nodes for drm backed by ring_buffer... so basically the same circuitry but without the scaling issues that using trace events has
15:26danvet: scaling issues with tracing?
15:26danvet: do you mean scaling to multiple users?
15:26seanpaul: ie: if everyone wants to do this One Simple Trick, we'll overrun the trace ringbuffer
15:26danvet: ah yes that one
15:31pq: seanpaul, yeah, sounds much better to me.
15:31seanpaul: ok, thanks! i'll start writing it up
15:33pq: seanpaul, is it per subsystem or per device?
15:34seanpaul: pq: it's going to have to be subsystem wide
15:35pq: Individually sized flight recorder buffer per subsystem feels better than one buffer for all subsystems, because then one chatty subsystem cannot flood the others out. But then one could ask the same about subsystem vs. devices.
15:37pq: but then fragmenting it more may make it harder to choose the right amount of memory to reserve for the buffe
15:37pq: so I suspect that per subsystem is a good compromise
15:38seanpaul: pq: right, that, and we actually can't do per-device if we want to simply echo the drm log messages since the majority of them do not pass in device
15:39seanpaul: so that makes the choice easier :-)
15:39pq: they don't pass in device? how do humans then know which device the messages are for?
15:40pq: humans, reading the logs
15:40seanpaul: pq: usually the drm object id is printed
15:41pq: or is it the same answer like it is with Vulkan GPU picking: "do not have multiple devices and it'll be alright"? :-p
15:41seanpaul: well, that too
15:41pq: eh heh
15:43pq: wait, but object ids are not unique across devices?
15:46seanpaul: pq: true, so i guess the answer is one can usually identify the device by fingerprinting it using object id/type/function name, and by only having one device
15:46pq: oh look, it's time to go home!
15:47seanpaul: haha, how convenient
17:43sravn: danvet: "drm: panel: fix excessive stack usage in td028ttec1_prepare" is for drm-misc-fixes. Correct?
17:44sravn: danvet: Reading https://drm.pages.freedesktop.org/maintainer-tools/committer-drm-misc.html#where-do-i-apply-my-patch
19:36cmarcelo: robclark, anholt: trying to handle nir_intrinsic_scoped_memory_barrier in ir3_compiler_nir.c, there's a bit cat7.l that is not clear how I can infer from the data I have (the scoped barrier aprox the same kind of data provided by OpMemoryBarrier in SPIR-V). ideas?
19:37Venemo: the arm64 CI is at it again: https://gitlab.freedesktop.org/Venemo/mesa/pipelines/95502
19:44robclark: cmarcelo: tbh I've not looked at scoped barrier.. I guess it is not a thing that exists in gl? I suppose maybe we could get a cmdstream trace from blob..
19:50cmarcelo: robclark: for some context: I'm trying to reuse the same intrinsic we have for spirv in GL. the opmemorybarrier in spirv is supposed to be a superset of the various mem barriers in GL.
19:52robclark: so, the current barrier code is just based on what bits I saw blob setting with different types of barriers in gl test programs.. I guess we'd have to repeat the process getting traces from vk tests (maybe there are some cts tests we could use) and see what blob does
19:53Venemo: hey robclark if you have a couple of minutes to spare, can we get an A-B or R-B from you on MR 2420? AFAIK it might affect freedreno, so we'd prefer if you looked at it before we merge it.
19:58robclark: hmm, I guess that pass does more than what it started life as..
19:59robclark: so.. if varying loads in frag shaders move into somewhere that isn't uniform flow control.. I suspect that will need some special handling in the backend
19:59robclark: ie. since we need to signal to the hw once when we load the last varying
20:00robclark: hmm, but I guess the pass was already doing that..
20:00robclark:wonders if we've been getting lucky
20:01pendingchaos: it looks like you only sink load_const/undef
20:02pendingchaos: so I don't think the MR doesn't actually affects you
20:03robclark: ahh, right, some options bitmask were added to control that
20:03Venemo: pendingchaos: that's a double negative
20:03pendingchaos: *so I think the MR doesn't actually affect you
20:04robclark: yeah, that seems like it should be ok.. maybe at some point we should look at enablign some of the other options, but right now I don't think that MR would effect us.. a-b
20:21maccraft321: is there anyone working on nouveau code?
20:41bnieuwenhuizen: robclark: cmarcelo: I don't think you can trigger all the scoped barrier stuff from VK before the memory model extension can you?
20:42bnieuwenhuizen: especially wrt visibility/availability of variables not marked coherent
20:42Venemo: thx robclark :)
21:15cmarcelo: bnieuwenhuizen: that's correct, the mapping is roughly https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_gl_spirv.txt "Mapping of barriers"
21:16cmarcelo: note TCS barrier(), in NIR we actually consider the nir_var_mem_out mode. SPIR-V can only express that with MM enabled.
21:19maccraft321: pmoreau: hey do you know how to debug freeze/hang issues on integrated geforce 8300, nv50 family?
22:02anarsoul: looks like runners for arm_build and arm_test CI jobs are down
22:04anarsoul: e.g. https://gitlab.freedesktop.org/mesa/mesa/-/jobs/1314443
22:40MaxLeiter: hm, i'm getting the following while building mesa
22:40MaxLeiter: ../src/mesa/main/texcompress_s3tc_tmp.h:29:10: fatal error: 'OpenGL/gl.h' file not found #include <OpenGL/gl.h>
22:41MaxLeiter: doesn't mesa provide that?
22:45ccr: perhaps looking at the file gives a clue .. (there's a #ifdef __APPLE__ there)
22:47kisak: this one of the headers that moved to glvnd?
22:52MaxLeiter: yeah thats what I just figured ccr, thanks
22:52MaxLeiter: nah kisak im on iOS not OS X so some libs are different
22:52MaxLeiter: I do have an OpenGLES framework
22:53MaxLeiter: but unsure how that plays into mesa
22:53MaxLeiter: so just not going to mess with it nw
22:57jekstrand: MaxLeiter: That's unfortunate.....
22:57jekstrand: MaxLeiter: I don't think anyone builds there. It should work in theory but likely needs some tweaking
22:58jekstrand: MaxLeiter: It's looking for the desktop OpenGL headers which aren't going to be there on iOS
22:58jekstrand: I'm not sure why it uses the system headers and not the ones in mesa though. That's weird.
22:59tarceri: This job is stuck because you don't have any active runners online with any of these tags assigned to them: aarch64
22:59tarceri: Anyone know how to fix gitlab --^
23:01MaxLeiter: Iit works jekstrand :)
23:01tarceri: I can't merge because the arm jobs wont run
23:01MaxLeiter: I just removed the apple check and the default <GL/...> worked
23:01MaxLeiter: no X just yet to test with
23:01jekstrand: MaxLeiter: cool
23:01MaxLeiter: but seems to be fine
23:16anarsoul: tarceri: same here
23:17anarsoul: robclark: ^^ IIRC these jobs are for freedreno and I'm not sure whom else to poke
23:17robclark: it looks like it is the container builds that are blocked? I've got a CI run blocked atm too
23:18robclark: I think it is a daniels or anholt question? I'm not really sure
23:30daniels: think I know what this is
23:47robclark: hmm, my CI run seems to be making some progress now
23:50tarceri: yeah same. thanks daniels
23:53kisak: would it make sense to cull old staging/##.# branches in mesa? I'm thinking a once a year task, with 18.x to go soon, 19.1 to go in 2021 ... no real need to tightly schedule removal
23:53kisak: ^19.x to go away in 2021