00:15 jekstrand: bnieuwenhuizen: Do you have any option on https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3307 ?
00:15 jekstrand: robclark, you too? ^^
00:18 anarsoul: could anyone point me to the code in mesa that promotes GL_RGB FBO to 32bpp if driver doesn't support 24bpp formats?
00:19 anarsoul: I did quick grep for PIPE_FORMAT_R8G8B8_UNORM and MESA_FORMAT_RGB_UNORM8 but I can't find where it's done
00:19 imirkin_: anarsoul: st_format.c
00:20 robclark: jekstrand: so.. not sure I know enough about the different bar flags to make use of that.. the "documentation" I have is just which bits correspond to which glsl barrier intrinsics
00:20 imirkin_: for GL_RGB, it will try R8G8B8, then R8G8B8X8, etc
00:20 anarsoul: imirkin_: thanks!
00:20 imirkin_: https://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/state_tracker/st_format.c#n207
00:20 imirkin_: (and you can look at what DEFAULT_RGB_FORMATS is
00:20 imirkin_: note how it doesn't even try R8G8B8 :)
00:21 imirkin_: coz no one supports it. not worth trying :)
00:21 anarsoul: hm
00:22 imirkin_: (well, i guess the _code_ is st_choose_format below, but that's the table that drives most of it)
00:22 anarsoul: then I don't understand why https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3335/diffs?commit_id=cbbc9bc0f3245eca7d3a67c1c67203ad3c398c01 unbreaks chromium-based browsers :)
00:23 imirkin_: because there's probably some dumb path to get R8G8B8 textures, but then you can't render to them
00:23 imirkin_: and that's not how GL works -- GL_RGB is required to be renderable
00:24 imirkin_: for some reason RGB_INTEGER allows R8G8B8_SINT -- imo that's a mistake too
00:24 imirkin_: (and same for RGB8UI)
00:24 anarsoul: I see, thanks for explanation
00:37 jekstrand:can't wait for Marge to come bavck
00:40 anarsoul: jekstrand: yeah :(
01:14 airlied: jekstrand: did ibc ever land?
01:15 jekstrand: airlied: No, it's still WIP
01:37 bl4ckb0ne: what is swrast?
01:39 airlied: bl4ckb0ne: the software drivers
01:40 bl4ckb0ne: ty
01:41 bl4ckb0ne: im running a egl binary with the path to the egl in the mesa build with LD_LIBRARY_PATH
01:41 bl4ckb0ne: and I have this error with swrast and i965 `libEGL warning: MESA-LOADER: failed to open swrast (search paths /usr/lib/dri)`
01:41 bl4ckb0ne: i installed mesa-dri-swrast but it's still there
01:43 airlied: is /usr/lib/dri/swrast_dri.so there?
01:43 bl4ckb0ne: empty
01:44 bl4ckb0ne: might be -Ddri-drivers-path
01:44 airlied: /usr/lib64/dri?
01:44 bl4ckb0ne: im copy pasting the configs from the alpine package
01:46 bl4ckb0ne: airlied: dri libs wre in /usr/lib/xorg/modules/dri
10:15 daniels: jekstrand, anarsoul, anholt_: marge _may_ be fixed now - give it a try?
10:19 daniels: it also shouldn't get into degenerate conditions where CI stops happening and half the requests throw 502s anymore
10:35 Venemo: daniels: do you maybe have an idea about what is wrong with this one? https://gitlab.freedesktop.org/Venemo/mesa/-/jobs/1314016
10:36 daniels: Venemo: that runner was, at the time, very unhealthy, but I fixed it later
10:37 Venemo: dscharrer: so I should just hit the retry and forget about it?
10:37 Venemo: sorry tab fail
10:37 Venemo: daniels: so I should just hit the retry and forget about it?
10:37 daniels: Venemo: already hit retry for you!
10:37 Venemo: it is still in the failed state
10:38 Venemo: oh I see
10:38 Venemo: there is a different job now
10:38 Venemo: thanks
10:41 daniels: np
10:42 Venemo: it's a bit frustrating that something's always up with the arm ci, but I guess I gotta live with it
10:43 daniels: what else has happened with it?
10:45 Venemo: I saw a bunch of failures with it in the past
10:47 Venemo: basically almost every MR I had, the pipeline failed because of either the arm64 build or one of the arm gpu driver test runs. the latter are much more stable nowadays, so haven't seen such a failure in a while, which is nice
10:51 daniels: if the build fails for some reason, please let me know
10:51 Venemo: will do.
13:16 engys: pepp: the bug report I wrote yesterday only arise while desaturating the map .. no idea how someone would do this in OpenGL and why it works fine on Vega and Polaris but not on Navi?
16:39 robclark: it's kinda unfortunate that deqp doesn't have any coverage for YUV.. since we seem to be good at breaking that :-/
16:40 imirkin_: the two may even be correlated
16:41 robclark: that seems to be a strong possibility ;-)
16:42 robclark: (and debugging deqp or piglit crashes seems a lot more pleasant than debugging android stuff)
16:53 Kayden: yeah, we could really use some better testing in that area
16:53 Kayden: which reminds me there is piglit!113
16:54 Kayden: https://gitlab.freedesktop.org/mesa/piglit/merge_requests/113
16:56 robclark: that MR looks like it has some bonus tests? Or maybe it is a MR on top of a MR?
16:56 robclark: (but looks useful)
17:02 Kayden: huh, yeah, it does have bonus tests
17:02 Kayden: I was just thinking of the yuv patch in it
17:03 robclark: also, I seem to be unable to fetch the branch with the https url..
17:04 robclark: well, hopefully piglits existing yuv tests are enough to reproduce this..
17:06 daniels: robclark: hm, why can't you fetch?
17:06 robclark: well, it prompts me for a username, so I can't fetch as anon
17:06 robclark:building piglit on a machine that doesn't have my gitlab credentials
17:06 Kayden: it shouldn't...
17:09 imirkin_: is the remote git@gitlab.org?
17:09 imirkin_: or is the remote https://foo
17:09 imirkin_: if it's ssh, it'll prompt for credentials
17:09 imirkin_: oh hm. i still have this: git://anongit.freedesktop.org/mesa/mesa
17:09 imirkin_: works fine
17:14 robclark: I was using https://foo
17:19 robclark: well, ext_image_dma_buf_import-sample_yuv doesn't seem to trigger the crash :-(
17:20 daniels: robclark: prompting you for a username usually means that you've typoed something
17:20 daniels: (it could be a private repo that isn't accessible to anon, so it prompts you for a username and password)
17:21 daniels: anyway, marge-bot seems to be fixed now, so please try to use it again and let me know if it falls over
17:21 robclark: yup, margebot just managed to merge something for me
17:22 daniels: \o/
17:22 robclark: fwiw, try: git fetch "https://gitlab.freedesktop.org/jamesxio/piglit.git" "master"
17:22 imirkin_: probably not a public repo
17:22 robclark: anyways, probably not too important.. I don't think I need the additional tests it adds
17:23 daniels: it's not public, no
17:23 daniels: it's marked as 'internal', which means you have to be authenticated to access it
17:23 daniels: (why he's done that I have no idea)
17:23 robclark: ok, makes sense.. oh well
17:58 MrCooper: imirkin_: while that works, fetching from GitLab allows e.g. also fetching refs for MRs
17:59 imirkin_: MrCooper: ah ok. i was just checking what was in a mesa tree here
17:59 imirkin_: probably from before gitlab times in the first place
19:00 alyssa: Hmm, the jump from ES3.0 to ES3.1 doesn't look awful
19:00 alyssa: At least compared to the jump from ES2.0 to ES3.0
19:00 alyssa: (And ES3.1 to ES3.2 for that matter)
19:01 anarsoul: alyssa: wikipedia mentions that not all midgard GPUs can do ES3.1
19:01 alyssa: anarsoul: All can do ES3.1, not all can do ES3.2
19:04 alyssa: Arguably GPUs <t760 can't do anything higher than ES2 but they fudge it
19:05 endrift: oh dear
19:06 alyssa: endrift: They uh
19:06 alyssa: Don't have any support for MRT before t750
19:06 alyssa: *t760
19:06 karolherbst: most of the time wiki only lists what drivers expose, not what the hardware is capable of ;)
19:06 karolherbst: some vendors are lazy with enabling certain features on older hardware
19:07 karolherbst: (or don't want to wire up trivial software emulation)
19:07 alyssa: FWIW for panfrost, the goal right now is to support ES3 on T760+ only
19:07 anarsoul: alyssa: eh?
19:07 anarsoul: I thought that midgard was designed as ES3 GPU
19:08 alyssa: (If there's interest for ES3 on the older Midgards, that can happen down the line, but for now the focus is T860, and T760 ought to 'just work')
19:08 anarsoul: also I'm surprised that early midgard can't do MRT
19:08 alyssa: anarsoul: About that....
19:08 anarsoul: even utgard can have up to 3 render targets
19:32 endrift: I don't know what MRT is
19:33 jekstrand: multiple render target
19:33 jekstrand: Meaning you can render to multiple images simultaneously
19:33 jekstrand: *multiple color images
19:33 endrift: uhhh that's kind of important
19:34 jekstrand: yeah
19:34 endrift: I use that in mGBA's hwaccel mode
19:34 jekstrand: especially if one wants to write a deferred renderer
19:34 jekstrand: Yeah, it's kinda useful
19:35 endrift: So does that include the T720 not supporting it?
19:35 imirkin_: alyssa: ES3.1 is actually pretty big ... compute/ssbo/images, indirect draws
19:36 endrift: Making only half of gen 3 support it
19:36 imirkin_: alyssa: and to make it really useful, you have to support AEP, which is basically == ES 3.2
19:36 imirkin_: and includes little things like geometry / tess shaders
19:36 endrift: oh I see only the T760+ support Vulkan
19:38 endrift: well good thing the PBP has 4th gen :D
20:40 alyssa: endrift: Yeaah, MRT is kind of important for ES3
20:41 alyssa: jekstrand: Wee deferred rendering on mobile ;|
20:41 alyssa: imirkin_: I might be vastly underestimating the difficulty of images and indirect draws
20:41 alyssa: endrift: Mmyeah, PBP has T860 which is what I dogfood so it should be okay ;)
20:43 imirkin_: alyssa: well, depends how nicely your hw plays along
20:43 imirkin_: could be moderately easy. or could be quite annoying.
20:43 alyssa: Indirect draws will be excruciatingly painful, I think
20:44 alyssa: Images shouldn't be atrocious but we shall find out.
20:44 imirkin_: ideally with indirect draws, your command processor is smart enough to handle everything
20:44 alyssa: Yeah nope
20:44 imirkin_: otherwise you can always chicken out and do them direct
20:44 alyssa: It's a compute shader
20:44 alyssa: (with the blob)
20:44 imirkin_: wow, the compute shader can issue draws?
20:44 imirkin_: or the compute shader fixes up the command stream?
20:44 alyssa: I think #2
20:44 alyssa: I don't recall the exact details but it was ugly
20:44 imirkin_: lol. nothing can ever go wrong with that approach...
20:45 imirkin_: so i guess you'll be needing compute shaders
20:45 alyssa: We have basic compute support as is
20:45 alyssa: and basic SSBO support
20:46 imirkin_: oh, that's nice
20:46 imirkin_: do you handle atomics and barriers and whatnot?
20:46 alyssa: Not yet
20:46 endrift: T860 is also what the kevin has right?
20:46 alyssa: endrift: Correct. Kevin and PBP have the same SoC
20:46 endrift: that's what I thought
20:46 imirkin_: a lot of this stuff may be easier now than i rembmer it, since you don't have to do any of the intermediate bringup
20:47 imirkin_: i did a bunch of the work in the intermediate bringup (thankfully not much in the actual glsl frontend), so my recollectino could be tainted by that
20:48 alyssa: 200 lines of disassembly for the compute shader...
20:48 alyssa: is that worth writing a decompiler for XD
20:48 alyssa: kidding, the compute shaders used for geom and tess are worse
20:49 imirkin_: erm, those are implemented as compute? does the compute shader basically generate a new geometry to be submitted for rast?
20:50 alyssa: imirkin_: This is not entirely clear to me, but the midgard pipeline for GLES2 looks like...
20:50 alyssa: [VERTEX] ---vertices---> [TILER] ---polygonlists---> [FRAGMENT]
20:50 alyssa: so 3 different "jobs" in Mali lingo
20:50 imirkin_: all this has to come before tiling
20:51 alyssa: stuff in the arrows is just stored in main memory
20:51 imirkin_: since position is output only by the last stage
20:51 alyssa: So with a geometry shader it'd be something like
20:51 alyssa: [VERTEX] ---vertices--> [COMPUTE] ---vertices--> [TILER] --..
20:51 imirkin_: right, ok
20:51 imirkin_: so compute just produces a new geometry
20:51 imirkin_: delightful
20:51 alyssa: And I'm assuming somewhere in that giant compute shader they fix up the command stream to have the right vertex count
20:55 imirkin_: coz why not :)
20:56 airlied: it's like how metal tessellation works, uses compute as the frontend
21:01 imirkin_: yeah ... as it turns out, compute is better at this stuff. there's a bunch of tehcniques out there to compute new vertex lists
21:06 alyssa: `JOB_TYPE_NULL`
21:06 alyssa: I.. never thought I would see that in the wild.
21:06 alyssa: What do you do when a job has more than 2 dependencies even though the scoreboard only support 2 deps? Add fake jobs!
21:15 alyssa:writes on chalkboard, "I will not write a Midgard decompiler."
21:16 imirkin_: now write it 100 times, simpsons style
21:16 anarsoul: :)
21:16 alyssa: imirkin_: thatsthejoke
21:16 imirkin_: and no cheating with the musical notation thing
21:18 imirkin_: https://frinkiac.com/caption/S08E07/481563
21:25 Kayden: lol, I hadn't see that one
21:27 imirkin_: lisa falls in love with nelson
21:28 imirkin_: tries to change him, fails.
21:28 alyssa: Falling in love is appropriately rated.
21:30 imirkin_: (i definitely haven't wasted a good chunk of my life watching these things...)
21:31 alyssa:definitely hasn't wasted a good chunk of her life falling in love ;P
21:32 HdkR: alyssa: Falling in love with Midgard is cheating
21:32 alyssa: HdkR: ....Drat.
21:32 alyssa: what about with kevin
21:32 HdkR: Cheating on Midgard with Kevin now? :P
21:33 alyssa:is currently fighting with shaders
21:36 imirkin_: against who?
21:36 alyssa: Shadow tux
21:37 imirkin_: he'll never stand up to you and the other shaders
21:39 alyssa: anyone know off the top of their head which deqp-gles3 cases test indirect UBO access?
21:39 alyssa: I see indirect uniform access and direct UBO, but not indirect UBO..
21:41 anholt_: gles31's opaque_type_indexing had some
21:41 anholt_: dEQP-GLES31.functional.shaders.opaque_type_indexing.*
21:41 anholt_: pretty sure
21:42 alyssa: anholt_: Thank you
21:45 imirkin_: also supported on samplers and ssbo's, with some extensions potentially
21:46 imirkin_: (and images)
21:47 anholt_: oh hey GSes work better if I actually create the TGSI draw module shader for them.
21:47 alyssa: Weee
21:48 alyssa:isn't seeing anything in dEQP-GLES31.functional.shaders.opaque_type_indexing.*
21:48 anholt_: hmm.
21:48 imirkin_: *opaque_type_indexing* ?
21:48 imirkin_: that definitely _sounds_ right
21:48 imirkin_: also are you running with deqp-gles31?
21:48 imirkin_: (vs deqp-gles3)
21:49 alyssa: deqp-gles31 yes
21:49 alyssa: Other tests fail with NotSupported (GL_EXT_gpu_shader5 extension is required for dynamic indexing of interface blocks.: 'm_context.getContextInfo().isExtensionSupported("GL_EXT_gpu_shader5")' at es31fOpaqueTypeIndexingTests.cpp:752)
21:50 alyssa: So maybe that's why
21:50 imirkin_: try dEQP-GLES31.*opaque_type_indexing.*
21:50 imirkin_: what does this driver support?
21:50 imirkin_: also diff things are enabled in diff places
21:51 imirkin_: https://www.khronos.org/registry/OpenGL/extensions/OES/OES_gpu_shader5.txt
21:51 alyssa: idk, I'm probably just missing CAPs
21:51 imirkin_: ok yeah - looks like you need OES_gpu_shader5
21:51 imirkin_: (or EXT_gpu_shader5 - same thing)
21:52 imirkin_: that lets you do ubo's and samplers, but not images/ssbo's (which have to have a constant integral expression for an array)
21:52 alyssa: Hm, I wonder if this is a bug in STK then?
21:53 alyssa: (Doing dynamic UBO indexing without checking the extension?)
21:53 imirkin_: does the shader have a #extension for it?
21:53 anholt_: is it dynamic indexing of your UBO block array?
21:53 imirkin_: if so, the bug is not doing :require
21:53 anholt_: or dynamic offset in a block you're talking about?
21:53 alyssa: anholt_: dynamic offset
21:53 imirkin_: oh right - there's indirect into the ubo, and indirect into the array of ubo's
21:53 anholt_: dynamic offset should be gles3 afaik
21:53 imirkin_: yea
21:53 alyssa: ubo { bigarray[12345] }
21:53 alyssa: So.. a gap in deqp-gles3 then..?
21:54 imirkin_: ok yeah, that's just gles3
21:54 anholt_: you may also be accidentally triggering some lowering?
21:56 anholt_: you're setting INDIRECT_CONST_ADDR, seems like it should be fine
21:58 imirkin_: alyssa: check dEQP-GLES3.*uniform_array*
22:02 imirkin_: the dynamic and dynamic_loop variants should be indirect accesses
22:07 alyssa: Haha!
22:07 alyssa: Shadows work now!
22:08 imirkin_: alyssa and her band of shaders have defeated the shadows
22:08 alyssa: ---granted performance takes horribly but still
22:09 alyssa: They're doing an inline 3x3 box blur just in the middle of the shader..
22:09 imirkin_: you could do what gcc 2.96 used to do ... optimize loops by removing them entirely
22:10 imirkin_: (thanks, redhat)
22:10 alyssa: Admittedly it does make the shadows look way nicer
22:11 alyssa: "Soft shadows" I guess is the word for that?
22:11 HdkR: soft shadows, stencil shadows, contact hardening shadows, tons of techniques :D
22:12 alyssa: okay now onto less interersting bugs
22:12 alyssa: like "the sky is black"
22:12 alyssa: Throwback to NES emulation :D
22:12 imirkin_: sky is sometimes a cubemap
23:41 anarsoul: any ideas on why gallium doesn't do user clip planes lowering if PIPE_CAP_CLIP_PLANES is 0?
23:41 MaxLeiter: aha! http://avatar.playat.ch:9000/uploads/8617e5a00678ded2/IMG_0016.jpg thanks for whoever was helpng me yesterday, much appreciated
23:42 imirkin_: anarsoul: the frag-based impl is a fairly recent thing
23:42 imirkin_: and highly inefficient
23:42 anarsoul: yet panfrost somehow manages to pass dEQP-GLES2.functional.clipping.*
23:43 anarsoul: but it fails on lima :\
23:43 imirkin_: what does panfrost return for that cap?
23:44 imirkin_: you can look at freedreno for an example of how to do the fallback
23:44 imirkin_: a3xx had some limited hw support
23:44 imirkin_: while i think later gens just have nothing
23:44 anarsoul: 0
23:44 imirkin_: oh, well, i don't think GLES2 has clip planes either
23:44 imirkin_: so that clipping is about frustrum/viewport/whatever
23:45 imirkin_: ES 1.1 has clip planes
23:45 imirkin_: and there's a EXT_clip_cull_planes for ES
23:45 anarsoul: hm
23:45 imirkin_: er, probably s/planes/distances/
23:45 imirkin_: which is how modern hw implements it
23:46 imirkin_: but ES2/3/3.1/3.2 have none of that afaik
23:46 imirkin_: anarsoul: what's a sample test you're failing?
23:47 anarsoul: most of them
23:47 imirkin_: name one
23:47 imirkin_: gotta start somewhere :)
23:47 anarsoul: dEQP-GLES2.functional.clipping.point.wide_point_clip_viewport_center
23:47 imirkin_: ufff
23:47 imirkin_: ES rules for point clipping are ... not what some hardware implements.
23:47 imirkin_: are all the failures related to points?
23:48 anarsoul: let me find one with polygon...
23:48 imirkin_: basically if you have a wide point, should it disappear if the center of it is outside the viewport?
23:48 imirkin_: ES rules says no -- it shouldn't
23:48 imirkin_: some hardware disagrees
23:48 anarsoul: dEQP-GLES2.functional.clipping.polygon.poly_clip_viewport_center
23:49 imirkin_: that's better :)
23:49 imirkin_: so look at the failure / pass image
23:49 imirkin_: and try to figure out where you're failing
23:49 imirkin_: er, failure / reference images
23:49 anarsoul: it looks like my viewport is bigger than it expects
23:49 imirkin_: right
23:50 anarsoul: i.e. it still clips polygons
23:50 alyssa: anarsoul: panfrost has a mali_viewport structure in the command stream
23:50 alyssa: which contains scissoring/clipping/etc stuff
23:50 imirkin_: anarsoul: do you make use of ->translate / ->scale?
23:50 anarsoul: alyssa: yeah, and we have plbu commands to set viewport
23:50 imirkin_: anarsoul: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c#n390
23:51 imirkin_: obvious nvidia-specific, but one thing to note is that we set a viewport horiz/vert size
23:51 imirkin_: where the hw will clip everything outside of it, ideally
23:51 imirkin_: (size and offset ... it's packed together)
23:51 imirkin_: chances are reasonable that you have to do something similar
23:51 anarsoul: https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/gallium/drivers/lima/lima_state.c#L237
23:52 imirkin_: you have to be slightly careful -- otherwise your .left could be negative
23:52 imirkin_: (or perhaps you handle that)
23:54 imirkin_: anarsoul: where do you emit those into a cmdstream?
23:54 anarsoul: https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/gallium/drivers/lima/lima_draw.c#L838
23:54 imirkin_: yeah, just found it actually
23:55 imirkin_: i wonder if that scissors command should take viewport into account
23:55 anholt_: imirkin_: would appreciate a hand on finishing up the nouveau bits of !3355
23:55 imirkin_: i guess implicitly it should be doing the overlap anyways
23:56 imirkin_: anholt_: link? i'm not sure how to get to a MR
23:56 anholt_: I suspect there's a bigger refactor, but I couldn't figure out where to put the function and how to get it to link.
23:56 anholt_: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3355
23:56 imirkin_: thanks
23:56 imirkin_: hehe. fun one.
23:56 imirkin_: i'm trying to remember why i made it the GL enum at the time
23:56 anholt_: I keep getting stuck on deleting code by having to delete more code.
23:56 imirkin_: i had _some_ reason ... might have been related to laziness though
23:57 anholt_: nir only gave you the gl enum because history.
23:57 anarsoul: imirkin_: yeah, good idea
23:57 anarsoul: I'll check that, thanks
23:57 imirkin_: yeah, but i did the tgsi integration (before nir existed, i suspect)
23:57 imirkin_: er no, tgsi gets a PIPE_FORMAT
23:57 anholt_: tgsi is a pipe format
23:57 imirkin_: good.
23:57 anholt_: which is the thing we want now
23:57 imirkin_: oh - you're updating nir - you want karol - he wrote/maintains that part
23:58 anholt_: I really just need someone who can c++ and might care about function names in nir.
23:58 imirkin_: internally we just need a mapping onto https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp#n976
23:58 anholt_: I'm trying to move your tgsi function to not the tgsi part.
23:59 anholt_: (the bigger refactor I hint at is that that table sure looks like duplication of a bunch of fields of util_format_desc)
23:59 imirkin_: ok, looking...