00:00 karolherbst: you need to change your compiler in stupid ways actually if you really want to support it as well
00:00 jenatali_: Good to know, though we don't really have any plans to implement SVM anytime soon
00:00 karolherbst: how could I forget about this stupid and silly thing
00:00 karolherbst: oh well
00:00 karolherbst: SVM is one area wher eyou clearly see the spec is just broken
00:00 karolherbst: fundamentally
00:02 karolherbst: oh well.. looking forward to your patches.. and good night :p
00:02 jenatali_: Yep, g'night
00:02 anholt_: oof. so, vulkan prebuilt shaders expand our container from 200M to 1.6G.
00:02 anholt_: (and build time on my local runner from 15 min to 50)
00:37 kisak: airlied: possibly a silly question, but did fedora ditch their glxinfo32 binary in Fedora 31? Happen to know if there is a simple replacement to exercise 32 bit opengl on new Fedora?
00:37 airlied:never knew we had a 32-bit glxinfo binary
00:37 airlied:goes and llooks at package
00:37 kisak: fair enough
00:38 kisak: it was in fedora 30, glx-utils i686
00:40 airlied: kisak: wierd the packages is in koji, I wonder did something else change wrt what 32-bit packages we ship
00:40 airlied: https://kojipkgs.fedoraproject.org/packages/mesa-demos/8.4.0/6.20181118git1830dcb.fc32/i686/
00:41 kisak: oh! then maybe it's just a website bug over at pkgs.org
00:41 kisak: sorry about the noise
00:42 airlied: looks like a compose issue though
00:42 airlied: since I can't dnf install it
00:42 airlied: I'll ask around
00:46 krh: wait a minute - gitlab commit view now has kb navigation to move between commits?
00:47 krh: that's new right? 'c' and 'x' to go prev/next commit...
02:31 airlied: yay a shouty Linus
02:40 krh: omg, are we ready for this? https://twitter.com/__simt__/status/1266138186289344512
02:42 airlied: once we have drm_io_uring we won't need the kernel to launch shaders :-P
02:43 HdkR: Oo, Olivier likes the interface
02:43 HdkR: :D
02:43 krh: airlied: next level indirect dispatch... run the driver on the gpu!
02:44 krh: although, I find that drm_uring, as cool as it sounds, it a lot less appealing because we already batch up everything in batch buffers
02:45 krh: io_uring makes a lot more sense because everything is a syscall for traditional io
03:23 airlied: krh: yeah we don't do as many ioctls alright, though would be nice for virt
03:23 airlied: and we have to keep up with the cool kids :-P
03:24 krh: airlied: shared ring buffers are cool again!
03:24 krh: (narrator: they were always cool)
03:25 airlied: dri1 was right all along :-P
03:42 jvesely: krh. there was a rocm version that could do generic syscalls from GPU.
03:42 jvesely: network, storage, mmap/munmap/madvise
06:12 danvet: bnieuwenhuizen, airlied am I blind or has the timeline syncobj stuff not landed in radv?
06:12 danvet: grep finds nothing
06:13 danvet: also nothing in amdvlk-pal
06:15 airlied: danvet: 88d41367b8aee961e6c47173a1e8848009e2215a
06:16 airlied: not sure what you were grepping for though :-P
06:17 airlied: danvet: libdrm_amdgpu wrappers probably tricked you :-P
06:18 danvet: airlied, DRM_CAP_SYNCOBJ_TIMELINE
06:18 danvet: still not finding that
06:19 danvet: or one of the new SYNCOBJ_TIMELINE ioctl
06:27 danvet: airlied, so even with the wrappers not finding anything
06:29 danvet: I did find it by now in pal, but not radv
06:30 danvet: at least git grep amdgpu_cs_syncobj_timeline gives me nothing
06:35 danvet: airlied, so this seems to be the non-shareable version only, which I did find :-)
06:57 airlied: danvet: oh maybe it doesn't share yet
07:06 airlied: danvet: the cap isn't used because it relies on the driver version for some other feature I believe
07:07 airlied: drmSyncobjTimelineSignal is call in amdgpu
07:09 danvet: yeah I found the amdgpu wrappers in drm
07:09 danvet: and amdvlk-pal does dlopen to get them and stuff them into some vtable
07:09 danvet: apparently linking is too hard
07:09 danvet: and then actually use it all
07:09 danvet: but for radv it seems all dead-ending in locally-only implementations
07:10 danvet: bnieuwenhuizen, ^^ accurate or do I get a prize for most blind user of git grep?
07:14 MrCooper: danvet: I understand it's "enabling cursor plane requires any other plane to be enabled as well", not necessarily primary; hwentlan correct me if I'm wrong
07:15 danvet: MrCooper, yeah but implementing that has potential for confusion
07:16 danvet: I think if we go with "cursor requires primary" then all the use-cases for planes should be doable (including overlay-only video and stuff like that)
07:16 danvet: but there's no mess with RMFB either
07:18 MrCooper: I was leaning towards just rejecting disabling the primary plane, unless there's an important use case for it
07:18 danvet: yeah that works too
07:18 danvet: important use-case is video with bars on mobile for power reasons
07:18 danvet: fullscreen video
07:20 MrCooper: I see
07:20 airlied: danvet: I'm not 100% sure but I think all signal/waiting is done via the execbuf
07:20 airlied: but probably best to wait for bnieuwenhuizen to show up :-P
07:25 jekstrand: danvet: Is now a good time for me to get grumpy about how we haven't landed dj-death's i915 patch yet?
07:47 danvet: jekstrand, always a good time I think
07:48 danvet: MrCooper, maybe trick someone from cros to care about that one :-)
07:48 danvet: airlied, well none of the other timeline ioctl are used either
07:49 danvet: and I haven't found a path from the local timeline thing to a kernel/fd one
07:50 pq: I tried to find where boot_vga attribute was documented...
07:51 danvet: haha
07:51 danvet: pq, it's the kernel, comes with finest docs
07:52 pq: Finland: zero points!
07:52 pq: I'm not even sure I found the code that creates the attribute
07:53 krh: MrCooper: yeah we do that
07:54 MrCooper: do you need the cursor plane to be enabled with that as well?
07:54 krh: MrCooper: yeah, if the cursor is visible
07:55 MrCooper: danvet: ^ there goes that plan :(
07:55 danvet: pq, pci-sysfs.c
07:56 danvet: MrCooper, uh ...
07:56 danvet: MrCooper, well tbh who cares
07:56 danvet: :-)
07:56 danvet: slightly more seriously, not sure how to fix this
07:57 danvet: e.g. if we assume fullscreen video on overlay, and cursor
07:57 danvet: and then TEST_ONLY fails
07:57 danvet: should trigger a fallback to splat it all into the primary plane with gl
07:57 danvet: maybe there's a better fallback
07:57 danvet: but eventually, the cursor will disappear
07:57 danvet: most people don't like to watch movies with the cursor fly on screen
07:57 pq: danvet, yeah, that's literally the only file with hits in the whole kernel tree when you grep for boot_vga, and there is no C string "boot_vga" in there, so I suppose it's some macro magic that creates it.
07:58 danvet: and then we can support the low power use-case
07:58 danvet: MrCooper, krh so I'm not too worried if "video overlay + cursor, but no primary plane" fails
07:58 pq: and the code for it is totally ??? in my eyes
07:59 danvet: .attr = { .name = __stringify(_name), .mode = 0444 }, \
07:59 danvet: 3 layers deeper
07:59 danvet: if I counted correctly
08:00 pq: emersion, I'm interested and lacking time, indeed
08:07 MrCooper: danvet: anyway, I'm not sure it would solve the problem: 1) CRTC enable=1 active=0 (e.g. legacy DPMS), cursor off 2) primary plane gets disabled because its FB is destroyed 3) legacy cursor ioctl tries to enable cursor → boom; is your idea that that the legacy cursor ioctl should disable the CRTC in this case?
08:08 danvet: MrCooper, hm
08:12 emersion: > <danvet> emersion, do you have someone to push all this for you? or want commit rights?
08:13 emersion: danvet: so clear answer to this is: no and yes, if possible :)
08:13 emersion: pq: i take it i can still continue to annoy you by cc'ing my uapi patches?
08:16 emersion: pq: is this worth a R-b or is it an A-b? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5238#note_514038
08:20 danvet: mripard, tzimmermann mlankhorst_ drm-misc commit for emersion for better docs and stuff?
08:21 pq: alyssa, Re: useless stack trace; on arm? missing debug info files maybe?
08:21 danvet: emersion, once you have some acks here pls file gitlab fd.o request to get you added
08:21 danvet: emersion, https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/new
08:21 danvet: new ssh account
08:21 danvet: if you don't have one yet
08:22 mripard: danvet: a-b :)
08:22 mripard: I've been playing around with the idea of a libdrm in rust recently, so I'm all for the work emersion did to clarify the UAPI :)
08:24 tzimmermann: mripard, https://bugzilla.opensuse.org/show_bug.cgi?id=1162283
08:26 tzimmermann: might become a problem at some point
08:30 mripard: at this point this is mostly to learn the language
08:30 mripard: so if it ever shows up in an suse bugzilla, it would already be quite an achievement to me :)
08:32 pq: emersion, sure, feel free to cc me with anything, and I feel free to ignore as necessary - just like so far ;-)
08:33 tzimmermann: mripard, lol
08:33 emersion: danvet: cool, will do!
08:33 pq: emersion, I'd say my comment on mesa!5238 is A-b at most. Definitely not R-b by my standards.
08:33 emersion: mripard: ah, nice!
08:33 emersion: pq: roger
08:34 emersion: pq: well, "at most" → should i include the A-b in the commit message?
08:35 pq: emersion, I dunno, I guess? Not sure how Mesa works.
08:36 pq: I'm fine with not adding anything for me, too
08:37 emersion: mesa still promotes adding tags in commit messages, even if that's not a hard requirement (apart from S-o-b ofc)
08:37 emersion: so i'm mostly asking because
08:37 pq: no, I mean, whether my comment counts as A-b or not.
08:37 pq: I'm not sure what A-b means in Mesa.
08:37 emersion: "at most" makes it sound like it's not quite an A-b :P
08:37 emersion: ah, ok
08:37 emersion: i'll just leave it alone to be safe, then
08:37 pq: so, maybe leave it out
08:38 emersion: thx
09:10 mlankhorst_: danvet: ack
09:32 MrCooper: danvet: rejecting disabled primary plane altogether avoids the WARNS when the FB is destroyed, but breaks 10 IGT kms_cursor_legacy sub-tests
09:33 MrCooper: all the *atomic-transitions* ones it looks like
10:08 baryluk: noob question, why I can't use Mesa -Degl with -Dglx=gallium-xlib ?
10:10 baryluk: or maybe alternatively, which combination I should use? Does it require different flags for using it inside X server itself (for glamour)?
10:14 MrCooper: it's not clear what exactly you're trying / what problem you're hitting
10:16 baryluk: It is just a question. I was building mesa for a long time with -Dglx=gallium-xlib, and it worked fine in all apps, and games, etc. But I added -Degl=true , because shader-db is using EGL, and Mesa started to fail to compile. -Dglx=dri works, but then I wonder what is recommened on Linux to use then.
10:20 baryluk: Or in other word, what are the drawbacks of using -Dglx=gallium-xlib in general, compared to -Dglx=dri?
10:22 danvet: MrCooper, hm might be unwarranted assumptions in those tests maybe
10:48 lynxeye: bnieuwenhuizen: etnaviv imports multi-planar resources the same way as other gallium drivers by having resource->next pointers set, so there shouldn't be any difference how you get to the right plane depending on lowered_yuv.
10:58 bnieuwenhuizen: lynxeye: oh is it just for YUYV?
10:58 karolherbst: how long does it usually take until new libdrm versions end up in CI?
10:59 bnieuwenhuizen: (a554b45d736073bbea4978118c02f7929f75cd77)
10:59 lynxeye: bnieuwenhuizen: right now it's just for interleaved, but there are patches to enable it for NV12 and I420
10:59 bnieuwenhuizen: lynxeye: and those patches set the next pointer?
11:00 lynxeye: still we don't change the gallium representation, so the planes are just resources chained together via the ->next pointer to the outside world
11:00 karolherbst: oh.. have to do it myself.. let's see
11:01 bnieuwenhuizen: lynxeye: got it. Sounds like I can remove the entire lowered_yuv tracking across images then. Thanks :)
11:04 lynxeye: bnieuwenhuizen: Yep, at the resource level multi-planar stuff look the same on etnaviv and other drivers. We just don't want the ST to do any lowering in the sampler/shader for us, as we have more efficient means to sample those textures.
11:26 karolherbst: ahh cool.. the container images can't be recreated anymore
11:26 karolherbst: https://gitlab.freedesktop.org/karolherbst/mesa/-/jobs/2877156
11:27 daniels: karolherbst: MrCooper fixed that I believe so it should just be a rebase
11:27 karolherbst: ohh..
11:27 karolherbst: let me try that
11:28 karolherbst: daniels: btw, this change looks fine or did I miss anything? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4580/diffs?commit_id=f43ab98a32f5823fdcd14cfb529cf6de14505518
11:28 danvet: pq, on the android "pick dri node from fb" I suspect it's a case with display drm + render drm node
11:29 danvet: and the solution is probably to not try and open the render node for display
11:32 pq: danvet, I would assume both devices have card nodes, then.
11:32 pq: so one should look at whether they have KMS resources
11:33 pq: IOW, weston's method should work
11:51 daniels: karolherbst: lgtm
11:56 karolherbst: daniels: mhh.. still broken https://gitlab.freedesktop.org/karolherbst/mesa/-/jobs/2877490
11:56 karolherbst: anyway.. will create a new MR just for the ci change
11:56 danvet: nashpa, [PATCH] drm/atomic-helper: reset vblank on crtc reset <- ping
11:57 bbrezillon: danvet: do you have a branch with the shmem stuff applied?
11:57 karolherbst: maybe I messed up
11:58 danvet: bbrezillon, yes, but also lots more
11:58 daniels: karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5002
11:58 danvet: bbrezillon, https://cgit.freedesktop.org/~danvet/drm/log/
11:58 danvet: that ok enough?
11:59 bbrezillon: yep
11:59 daniels: karolherbst: no, sorry, wrong link - https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5186
11:59 karolherbst: ahh, thanks
11:59 karolherbst: mhh
11:59 karolherbst: yeah.. maybe I messed up
12:17 MrCooper: daniels karolherbst: I fixed this for the x86_test-gl/vk images; I was hoping x86_build wasn't affected, but no such luck it seems :(
12:19 karolherbst: MrCooper: btw, I've created an MR here: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5254
12:20 karolherbst: mhh, yeah.. if you don't mind fixing it, you could then just push to this MR or give me the patch or something
12:20 karolherbst: otherwise I'll see what I can do
12:22 MrCooper: a short term fix requires pulling in GCC 8/9 packages from Debian testing
12:23 MrCooper: my longer term plan is https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5186#note_512350
12:24 MrCooper: though actually, upgrading GCC to 9 might be worth a shot
12:28 nashpa: danvet: I've managed to get hold of my Juno board from work yesterday, in the process of (re)setting up to test
12:36 danvet: nashpa, np, just wanted to know what's the plan
12:38 nashpa: I also owe Emil Velikov a test of his patch
12:40 MrCooper: karolherbst: please don't trigger unneeded CI jobs
12:40 karolherbst: MrCooper: yeah.. I know.. I just tried to get the CI stuff working
12:41 MrCooper: you can trigger only the jobs affected by your changes
12:44 karolherbst: MrCooper: which example are you refering to?
12:44 MrCooper: the MR we're talking about
12:46 karolherbst: mhh, right.. could have skipped the windows stuff
12:48 MrCooper: the *_test* jobs as well
13:31 emersion: danvet: just fyi, since you seem to have been dropped from CC: https://lists.freedesktop.org/archives/dri-devel/2020-May/267694.html
13:32 emersion: err
13:32 emersion: daniels: just fyi, since you seem to have been dropped from CC: https://lists.freedesktop.org/archives/dri-devel/2020-May/267694.html
13:58 danvet: bbrezillon, fix is at the other end
13:58 danvet: I'll send out a new version of patch 9 asap
13:58 daniels:rolls eyes
13:58 danvet: daniels, me?
13:58 daniels: no
13:59 danvet: amd?
14:00 daniels: i really wish all the stop energy directed at modifiers could be converted into thermal energy used to just burn navi
14:01 bbrezillon: danvet: at the other end of?
14:02 danvet: bbrezillon, I want to remove the fake pinning for dma-buf imports
14:03 danvet: that untangling is the point of the series, somewhat
14:03 danvet: so if I remove it both from import and from free_object, it's all good again
14:03 danvet: you hit the WARN splat because in free_object pages_count goes from 0 to -1
14:03 bbrezillon: because it's -1
14:03 bbrezillon: there was no check before the decrement op
14:04 danvet: because the usual get/put pages already has a WARN_ON(import_attach), which the series added
14:04 danvet: yeah but a decrement
14:04 danvet: bbrezillon, https://paste.debian.net/1149548/
14:05 bbrezillon: yeah, makes sense
14:06 danvet: bbrezillon, v3 on dri-devel and also pushed the branch
14:37 bbrezillon: daniels: do you have some time for drm_mm related questions?
14:37 bbrezillon: sorry, I meant danvet ^
14:37 daniels: bbrezillon: not really, but that's no loss as I'm the wrong person anway :P
14:37 daniels: ha
14:38 bbrezillon: daniels: too many nicks start with dan on this chan
14:39 emersion: agreed
14:40 daniels: I was here first
14:41 emersion: does that make you the deprecated Daniel?
14:41 danvet: brutal
14:41 danvet: bbrezillon, what's up?
14:41 danvet:appreciated some hand-crafted lockdep splat
14:43 danvet: bbrezillon, I just rejoined, so no idea what was right before your ping
14:43 bbrezillon: danvet: I have a problem when keeping BOs mapped in userspace and marking those BOs as purgeable
14:43 danvet: bbrezillon, with my patch series?
14:43 daniels: emersion: damn man :(
14:44 bbrezillon: danvet: no, unrelated to your patches
14:44 emersion: <3
14:44 danvet: bbrezillon, so what's the problem?
14:45 bbrezillon: well, I hit a warning when the shrinker kicks in an decide to free some BOs
14:45 bbrezillon: let me find the backtrace
14:45 bbrezillon: https://gitlab.freedesktop.org/snippets/1025/raw
14:46 bbrezillon: danvet: I was expecting drm_vma_node_unmap() to kill those userspace mappings
14:46 bbrezillon: but apparently some pages are still mapped
14:47 bbrezillon: after that call
14:47 bbrezillon: leading to the "Bad page cache" bug
14:47 bbrezillon: are my assumptions wrong?
14:48 bbrezillon: should userspace unamp BOs before marking them purgeable?
14:49 bbrezillon: (we used to do that, but alyssa reported that re-creating the mapping takes a non-negligible amount of time, and patched mesa to keep BOs in the userspace cache mapped)
14:50 danvet: yeah that shouldn't matter if the kernel is correct
14:50 danvet: I wonder whether you have something re-recreating the mappings
14:50 danvet: mmap handler doesn't seem to have any provisions for checking against purged objects
14:50 danvet: from a very quick look
14:52 bbrezillon: recreating the mapping between https://elixir.bootlin.com/linux/v5.7-rc7/source/drivers/gpu/drm/drm_gem_shmem_helper.c#L408 and https://elixir.bootlin.com/linux/v5.7-rc7/source/drivers/gpu/drm/drm_gem_shmem_helper.c#L416 ?
14:52 bbrezillon: you mean userspace do
14:53 bbrezillon: *doing that in our back?
14:54 bbrezillon: those mappings shouldn't be accessed from userspace until MADV(WILL_NEED) is called
14:54 bbrezillon: I was wondering if the MM layer could lock some pages, thus preventing drm_vma_node_unmap()
14:54 bbrezillon: to do anything
14:57 bbrezillon: danvet: I checked page_mapcount() before and after drm_vma_node_unmap()
14:57 bbrezillon: and it remains 1 on those 'locked' pages
15:00 danvet: hm then maybe something isn't wired up correctly with the address spaces and stuff at mmap time
15:00 danvet: bbrezillon, do you have some igt for this?
15:03 bbrezillon: danvet: I don't think we do
15:03 bbrezillon: robher: ^
15:03 danvet: well helper should do that
15:03 danvet: pretty much by default
15:03 bbrezillon: yep, that was my conclusion when looking at the code
15:04 danvet: so what I'd do is a small debugfs interface to purge all purgeable bo
15:04 danvet: bonus points if you annotate that with fs_reclaim_acquire/release and use exactly shrinker code
15:04 bbrezillon: interesting enough, I had hacked that when I was debugging the shrinker stuff
15:04 danvet: even more bonus if we have a shrinker in shmem helpers :-)
15:04 danvet: then test this with some igt
15:05 bbrezillon: but I' don't have this code anymore
15:05 danvet: with the debugfs you can then allocate 1 bo, mark it purgeable, and exercise exactly what you want
15:05 bbrezillon: yep, that's what I was doing, but manually
15:06 bbrezillon: (didn't plug that through igt)
15:06 bbrezillon: ok, I'll do that and come back to you
15:07 robher: what's igt? ;)
15:09 robher: There was some reason the shrinker couldn't be be completely in shmem helpers... Probably the drm_mm mapping IIRC.
15:10 bbrezillon: robher: the generic helper seems to handle that part
15:11 bbrezillon: it's mostly the locking that was problematic for panfrost IIRC
15:11 bbrezillon: and the fact that you have to tear GPU mappings down too
15:11 bbrezillon: which is GPU-specific
15:11 robher: yeah, locking for the shrinker is hard.
16:18 karolherbst: MrCooper: why is apt so annoying? :/ do I have to list all the dependencies or is there a magic flag?
16:19 MrCooper: I'm working on it, homing in on a solution
16:21 MrCooper: but yeah, one has to explicitly add dependencies it doesn't want to install to find out more about what the problem is
16:27 karolherbst: :/
16:27 karolherbst: I see
16:27 karolherbst: thanks for looking into it though
16:56 MrCooper: karolherbst: close, but haven't quite got it working yet; can it wait until next week? (note Monday is a holiday here)
16:56 karolherbst: it can
16:56 karolherbst: no worries
18:59 robclark: btw, what does it mean when marge says "I couldn't merge this branch: Merge request was rejected by GitLab: 'Branch cannot be merged'"
19:00 imirkin: i think it means that the branch could not be merged :)
19:00 robclark: (last time that happend I just re-assigned to marge, and since nothing else landed in the meantime (so there was a current green CI run), she just pushed it immediately)
19:01 robclark: imirkin: ahh, it is so much clearer now :-P
19:01 imirkin: Keyboard error. Press F1 to resume.
19:01 robclark: heheh
19:01 anholt_: robclark: showed up recently, the thought is it's a transient failure due to a recent unfortunate rebalancing of load on fd.o
19:01 anholt_: retry is the solution for now, hopefully the rerebalance can happen coming up, but there have been higher priorities
19:02 robclark: yeah, seen it a couple times recently.. no big worry, I can just re-assign.. just wanted to make sure that is what I should be doing
20:00 anholt_: finally. want to show off because it took so long to get here. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5266
20:04 shakesoda: anyone know if the no ssbo bindings in vertex shaders limitation is still present on rpi?
20:05 shakesoda: afair the issue was atomic counters, but not being able to read ssbos in vs essentially means i can't port my renderer, i don't even write to them in this stage :(
20:06 shakesoda: i'd test this myself, but my pi 4 won't be here for a while yet
20:06 anholt_: v3d_screen.c says PIPE_SHADER_CAP_MAX_SHADER_BUFFERS is 0 for VS/GS.
20:06 shakesoda: i see, argh
20:06 karolherbst: shakesoda: from where are you writing into the ssbos though?
20:07 shakesoda: i always write them in compute
20:07 anholt_: no hw limitation, even the software should be ready, just may require fixing testsuites.
20:07 shakesoda: or from cpu
20:07 shakesoda: it's useful to be able to write them in vs, but that's not how my rendering actually works anywhere since compute does the job more generally.
20:08 shakesoda: anholt_: that's a relief
20:09 anholt_: (this is assuming that multiple execution of your shader with these side effects is valid -- at the point where I was working on it some specs were unclear)
20:11 imirkin: shakesoda: if you only read, why not bind as a texture buffer?
20:11 karolherbst: shakesoda: couldn't you bind the buffer as an ubo instead as a valid workaround? Or wouldn't that work in your case?
20:11 imirkin: ubo may not work as it's often a smaller size
20:11 shakesoda: karolherbst: ubo is too small
20:11 karolherbst: I see
20:11 imirkin: texture buffer is usually sized much larger
20:12 karolherbst: yeah.. but I kind of understand that adding workarounds just to switch over to texture doesn't sound like a wisely spent time i the driver can be fixed easily
20:13 shakesoda: imirkin: buffer textures could work, i just don't have them wired up and the usage is a lot nastier.
20:13 shakesoda: so that's viable, just modestly annoying.
20:23 austriancoder: anholt_: what is cheza?
20:29 anholt_: austriancoder: freedreno a630 platform
21:36 daniels: anholt_, robclark: I already rebalanced it; any failure still happening is down to something else as there is enough capacity
21:37 robclark: hmm, I did hit it a couple times today (this morning, and ~1hr ago).. depending on how recent "already" is..
21:43 daniels: yeah, that's something else then. do you have the MR numbers to hand please?
21:43 anholt_: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5091
21:44 anholt_: relevant logs from marge
21:44 anholt_: 2020-05-29 18:04:18,019 INFO CI for MR !5091 passed
21:44 anholt_: 2020-05-29 18:04:20,186 INFO Ensuring MR !5091 is mergeable
21:44 anholt_: 2020-05-29 18:04:20,370 WARNING I couldn't merge this branch: Merge request was rejected by GitLab: 'Branch cannot be merged'
21:44 anholt_: 2020-05-29 18:04:20,370 INFO Unassigning from MR !5091
21:45 daniels: thanks
21:46 anholt_: looks like a string out of gitlab, not from marge herself
21:48 anholt_: would love to have marge in --debug mode to track more, but the log storage is too short
21:56 daniels: yeah it is out of GitLab
22:23 jenatali_: karolherbst: The result of our discussion from yesterday: https://gitlab.freedesktop.org/kusma/mesa/-/merge_requests/106
22:24 jenatali_: I'd be interested in high-level feedback on the approach, but it's probably still a bit early to go too in-depth
23:56 karolherbst: jenatali_: we don't have SYSTEM_VALUE_GLOBAL_INVOCATION_INDEX yet?
23:57 karolherbst: ohh wait
23:57 karolherbst: just missing in a few palces, nvm
23:59 karolherbst: yeah.. I will probably take a look tomorrow