01:47 HdkR: airlied: btw, would you know why llvmpipe would generate a VS/PS pair on a test app that only does a glDispatchCompute in a surfaceless EGL context?
01:48 HdkR: Noticed it a couple of days ago in testing
02:31 airlied: HdkR: probably internal blit shaders
02:31 HdkR: Rude, I'm not doing a blit :)
02:31 airlied: creating a context builds a bunch of stuff up front
02:31 airlied: because when you do ask for it, you really don't want to build it then
02:32 HdkR: Curiously it builds those shaders once I call glDispatchCompute rather than inside context creation
02:32 HdkR: So it must defer until any real work?
02:32 airlied: HdkR: oh that sounds like a bug
02:33 airlied: probably doing some derived state stuff it doesn't need to
02:33 airlied: code looks correct though, a backtrace from when it creates it would be good
02:34 HdkR: I'll see if I can capture where it comes from
02:35 airlied: anyone remember why heaven tess gives blue patches, need a hint where I'm going wrong
02:35 airlied: nearly passing all the deqp gles31 tess tests
02:38 imirkin: airlied: iirc i had problems with not flushing floats
02:38 imirkin: they do some a != 0 stuff, where a is a denorm
02:38 HdkR: airlied: https://hastebin.com/aputojopoy.shell If it gives you any information
02:38 imirkin: i forget precisely what artifacts that ended up in though
02:41 airlied: HdkR: okay so it's mesa doing it
02:41 airlied: generating a fixed func fragment shader
02:42 HdkR: fun
02:44 HdkR: Ah, looks like it is because it is a GLES 2+ context
02:44 HdkR: GL compat and GL core doesn't set that
02:44 HdkR: "MaintainTnlProgram"
02:48 airlied: uses GL core or GLES3 :-P
02:49 imirkin: airlied: actually i think the float flushign was a different artifact (weird white squares) ... i definitely remember getting blue triangles though
02:49 HdkR: Still generated with GLES3, I presume the API_OPENGLES2 actually means 2.0+ due to the autopromotion nonsense
02:50 imirkin: yeah, issue described here: https://bugs.freedesktop.org/show_bug.cgi?id=89455 ... sigh.
02:51 imirkin: o well. can't find any info about it. sorry.
02:52 imirkin: airlied: https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&date=2015-04-26
02:52 imirkin: at least i'm not crazy :)
02:52 imirkin: 12:29 imirkin: glennk: there are two separate issues. one is the axis-aligned squares, which happens without any tess in play as well
02:52 imirkin: 12:29 imirkin: glennk: another is blue triangles which pop up all over the place when tess is enabled
02:53 imirkin: the first one was the denorm flushing thing.
02:54 imirkin: and the next day, magically, "07:03 imirkin: airlied: heaven 4.0 works on my gl4-integration branch now"
02:57 imirkin: airlied: i remember for a while i had various issues with reading varyings in the eval shader ... i'd look for "basic" fail, since in my initial impl, i got it all sorted out without any explicit mention.
02:57 imirkin: airlied: do all the input/output tests pass?
02:58 airlied: imirkin: all tests are passing now
02:58 HdkR: "error: Compute shaders require GLSL 4.30 or GLSL ES 3.10" hm
02:59 HdkR: Confusing
02:59 imirkin: HdkR: do you have #version 310 es?
02:59 imirkin: airlied: that's unfortunate. does this include CTS and dEQP?
02:59 HdkR: I was testing with GL 3.3 core context, which exposes ARB_compute_shader
02:59 airlied: imirkin: my curernt guess is my vert/prim splitting handling
02:59 airlied: imirkin: just deqp
03:00 airlied: I should try gles cts
03:00 imirkin: airlied: well, i think blue triangle means "no fill", so lots of diff reasons why it could fail
03:01 imirkin: what caused my issue to get fixed will be lost in time. but i definitely had a lot of trouble with varyings, including reading other invocations' varyings in TCS
03:01 HdkR: I guess I'll just accept the VS/PS pair being generated for no reason
03:03 airlied:needs a tess demo that is somewhere between piglit and heaven :-P
03:05 imirkin: and the earliest gl4-integration branch i have in my mesa tree is from 2015-04-30, which is a few days after those comments...
03:05 imirkin: ooh, but i have a bunch of tess branches
03:07 airlied:also sees some heaven draws not producing any vertices, which may or may not be a bug
03:08 imirkin: does it work in wireframe mode?
03:13 airlied: doh I broke ts/gs, let me try now
03:14 imirkin: the most likely bit, based on my archaeology, is something related to fetching indirect varyings.
03:16 airlied: bit annoying we don't expose GLES 3.1 geom shaders without ARB_gpu_shader5
03:17 airlied: I wonder should I split the cap for that
03:45 airlied: wireframe doesn't look too healthy either :-P
08:03 MrCooper: airlied: have you tried GpuTest TessMark?
10:28 linkmauve: HdkR, for 3.3 compute you have to #enable ARB_compute_shader and whichever other extension you use (images or ssbo for instance) in the shader.
10:32 HdkR: linkmauve: Yea, it then complained that you can't enable ARB_compute_shader in a compute shader, maybe I typo'd
10:37 linkmauve: Hmm, I don’t remember having this issue on i965 when I tried it.
11:41 kusma: karolherbst: Not sure if you're the right person to ask, but I recently noticed that we claim to support the Addresses capability in Clover, but we do not handle OpCopyMemorySized. I assume that's just because we're not quite there yet. Do you know if there's any effort for this yet, or should I look into this myself since I need it?
12:03 HdkR: linkmauve: Could just be an llvmpipe quirk
12:05 linkmauve: Indeed.
12:31 karolherbst: kusma: ohh, mhh, I think robclark had a patch for it at some point somewhere
12:32 kusma: karolherbst: OK, thanks for the pointer!
12:34 karolherbst: kusma: I think airlied was it actually: https://gitlab.freedesktop.org/airlied/mesa/commits/sycl-env-hacks-shamrock
12:38 kusma: karolherbst: OK, thanks :)
12:43 kusma: karolherbst: Yeah, that's it. Thanks!
14:05 danvet: bbrezillon, f32df58acc68b is breaking htmldocs with some warnings/errors, pls fix
14:05 dj-death: what does the bcsel instruction stands for already?
14:05 danvet: ./include/drm/drm_atomic.h:1020: WARNING: Inline interpreted text or phrase reference start-string without end-string.
14:05 danvet: ./drivers/gpu/drm/drm_atomic.c:1099: WARNING: Inline interpreted text or phrase reference start-string without end-string.
14:05 danvet: ./drivers/gpu/drm/drm_atomic.c:1099: WARNING: Unknown target name: "bridge_funcs.atomic".
14:05 danvet: bbrezillon, narmstrong ^^ since your sob is on that patch too
14:06 danvet: bbrezillon, similar stuff for the bridge additions you've recently done
14:06 danvet: ./include/drm/drm_bridge.h:352: WARNING: Inline interpreted text or phrase reference start-string without end-string.
14:06 danvet: ./include/drm/drm_bridge.h:404: WARNING: Inline emphasis start-string without end-string.
14:06 danvet: ./include/drm/drm_bridge.h:412: WARNING: Inline interpreted text or phrase reference start-string without end-string.
14:06 danvet: ./include/drm/drm_bridge.h:482: WARNING: Unexpected indentation.
14:06 danvet: ./include/drm/drm_bridge.h:483: WARNING: Block quote ends without a blank line; unexpected unindent.
14:08 dj-death: forget it :) there is a description in src/compiler/nir/nir_opcodes.py
14:35 narmstrong: danvet: weird the ci didn't warn about it earlier
14:43 bbrezillon: danvet, narmstrong: I'm on it
14:53 danvet: narmstrong, it's me who noticed it just now building some docs locally
14:53 danvet: and yeah forget about 0day
14:54 danvet: it's so backlogged might as well assume it's dead
14:54 danvet: ime
15:15 bbrezillon: narmstrong, danvet: sorry for the noise
15:15 bbrezillon: v1 was still wrong
15:43 narmstrong: bbrezillon: building docs before applying
16:21 hopetech: karolherbst: Do you have a spirv shader that exercise CrossWorkgroup storage class? I'm on the spirv-to-nir issue
16:22 hopetech: And I'm wandering is this feature was already tested
16:22 hopetech: Vulkan don't support CrossWorkgroup
16:27 karolherbst: hopetech: global* causes it to be used
16:28 karolherbst: and there is a vulkan ext for it afaik
16:29 hopetech: So the current implementation is working for some cases
16:29 karolherbst: it should work for all cases :p
16:29 karolherbst: never had problems with crossworkgroup
16:30 hopetech: Well our issue is due to UniformConstant
16:30 hopetech: But it's lowered to a CrossWorkgroup
16:30 karolherbst: hopetech: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#VK_KHR_variable_pointers
16:31 karolherbst: doesn't that end up using crossworkgroup memory?
16:31 karolherbst: hopetech: yes...
16:31 karolherbst: the issue is that we have no way of telling if a pointer points to constant* or global* memory
16:31 karolherbst: and constant* has this weirdo data layout in clover right now
16:32 karolherbst: 8/24 bit layout where the high bits are the ubo index and low bits the ubo offset
16:32 karolherbst: but.. what happens if we point to actual constant memory?
16:32 karolherbst: do we need to have a "kernel ubo" containing all the constants?
16:33 karolherbst: mhh.. actually that might work
16:33 karolherbst: but I'd prefer to have a 32/32 bit layout for the ubo index/offset
16:33 karolherbst: less instructions at runtime
16:33 karolherbst: (even though we can do full 32 bit addressing of ubos in hardware or so)
16:34 karolherbst: imirkin: do you remember the details on how we could do an indirect on c0[$r0] and access other const buffers indirectly?
16:34 karolherbst: 16 bits offset and if you access 0x10000 it turns into c1[0x0]?
16:35 karolherbst: or was it 20 bits?
16:35 karolherbst: hopetech: anyway, I think we might be able to fix it if we fix constant memory in clover + lowering indirect constant accesses to a constant ubo
16:36 karolherbst: like we do with nir_opt_large_constants?
16:40 karolherbst: hopetech: actually... I have an idea
16:41 karolherbst: let's keep it simple for now and have a buffer of constants for each program. And just access it via global memory
16:42 karolherbst: I still have to figure out on how to deal with all the SVM interactions in such cases to actually use ubos
16:42 karolherbst: and the pointer will just get passed as an additional kernel arg hidden to the aPI
16:42 karolherbst: *API
16:43 karolherbst: could even be the first one, doesn't really matter
16:43 karolherbst: hopetech: if you want I could try to come with a patch tomorrow or something. Should be fairly easy to implement it
17:01 hopetech: Well I'm not against.
17:08 hopetech: But I'm not sure working on the clover side is a good idea actually. What's append when we will create a pipeline with cl_khr_il_program
17:12 karolherbst: we do the same
17:35 hopetech: Nice
17:37 imirkin_: karolherbst: 16 bits. max constbuf size is 64k, so it works out.
17:38 imirkin_: karolherbst: have to set a special bit to allow it though
17:38 karolherbst: on the instruction or shader?
17:38 imirkin_: LDC doesn't allow it, LDC.IS does.
17:38 karolherbst: ehh.. mhh
17:38 imirkin_: (don't ask me what "IS" stands for)
17:38 karolherbst: I see
17:38 karolherbst: but we need LDC for indirect loads anyway, right?
17:38 imirkin_: yes
17:39 imirkin_: blob doesn't set IS everywhere, and neither do i.
17:39 karolherbst: okay.. then passing a 32 bit handle for ubos might actually be a super nice idea
17:39 karolherbst: no and/shift/whatever needed to do the two level of indirection
17:42 imirkin_: karolherbst: note that UBO updates have to be done very carefully
17:42 imirkin_: (or you have to do a ton of flushing)
17:42 karolherbst: ohh, sure
17:43 karolherbst: we can only use ubos in OpenCL for constants inside the kernel anyway
17:43 imirkin_: ah ok.
17:43 imirkin_: and you actually probably don't have to be as careful for compute shaders. dunno.
17:43 karolherbst: well, we have to flush before each launch anyway
17:43 karolherbst: at least cb0
17:43 imirkin_: right...
17:58 pcercuei: gbm_dri doesn't implement .surface_lock_front_buffer()
17:59 pcercuei: Is that deprecated somehow?
18:00 pcercuei: I call gbm_surface_lock_front_buffer() and it segfaults within Mesa, because the callback doesn't exist and it doesn't do any error checking...
19:19 Venemo: Why does "Generating git_sha1.h with a custom command." take so long sometimes?
19:25 airlied: slow git tree?
19:31 airlied: hopetech, karolherbst : https://gitlab.freedesktop.org/airlied/mesa/commit/19edcbb53a75fc28436e3d2ddf6916eaeafe6eea
19:31 airlied: is what you were talking about
19:31 airlied: changes clover to use a uvec2
19:31 airlied: should solve hopetech problem
19:31 airlied: I knew I'd writteh some code in that aras, just forgotten where
19:32 imirkin_: airlied: did you work out the blue tris issue in heaven?
19:33 airlied: imirkin_: not yet, it's got a bunch of other crappy geometry, might spend some time just optimising heaven on llvmpipe so it's not slow bloody slow to debug :-P
19:33 karolherbst: airlied: I am sure it does not fix hopetechs issue :p
19:33 imirkin_: airlied: crappy as in wrong? or just annoying?
19:33 Venemo: airlied: what do you mean by slow git tree?
19:34 karolherbst: airlied: the issue is that having an array of constants in the kernel crashes in odd ways
19:34 karolherbst: and constants inside the kernel are treated equally as constant* input buffers
19:35 karolherbst: so you end up with a variable where you get loads from uniformconstant memory
19:35 karolherbst: its all very stupid
19:35 karolherbst: *it's
19:35 airlied: imirkin_: yeah lots of vertices in wrong places
19:36 airlied: karolherbst: that patch fixes that
19:36 karolherbst: are you sure?
19:36 airlied: using a ubo
19:36 karolherbst: it's not an ubo
19:36 karolherbst: I mean like constants inside the kernel
19:36 karolherbst: constant constants
19:36 imirkin_: airlied: even without tess? or with tess?
19:36 airlied: yes it puts thost constsants into a ubo
19:37 airlied: imirkin_: oh just with tess
19:37 airlied: karolherbst: using a nir pass
19:37 imirkin_: ah ok. so yeah... probably something awry somewhere, and that causes a bunch of things to go wrong
19:37 imirkin_: i think blue is just some background color
19:37 karolherbst: airlied: mhh, I don't see this part in the patch
19:37 imirkin_: so blue == tri didn't get drawn
19:37 airlied: karolherbst: I think iris already calls the nir pass
19:38 karolherbst: ohh, I see
19:38 airlied: or maybe I did it earlier
19:38 airlied: but it was definitely for that problem I wrote that patch
19:38 karolherbst: well, we would have to call it from inside clover then :/
19:38 karolherbst: okay, I see
19:38 karolherbst: well, I will take a look then
19:38 airlied: it's hacky as all hell
19:39 karolherbst: yeah... especially because we have to pass in constant* buffers as global memory
19:39 karolherbst: there is no way around that afaik
19:40 karolherbst: and again, what about code where you have a int constant* tmp = some_Flag ? kernel_input : &kernel_constant; thing?
19:43 karolherbst: or maybe we should indeed implement it always as ubos, even if we have an SVM pointer....
19:43 karolherbst: but ufff