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