11:49karolherbst: is the lima CI sytem is down right now?
12:00daniels: karolherbst: yeah it's definitely unhealthy, it's being disabled now
12:28sravn: kusma: nice work on the web-site. I like the split between the marketing and the technical stuff.
16:01imirkin: Putti: you have to use kmsro which joins the display and render nodes into a single fake driver
16:08karolherbst: did anybody here experiment with a static table of constants which are used often? I have a potential opt for nouveau to improve shader performance if (long) immediates are replaced by const buffer reads, but that also requires reuploading a static table of constants for each shader and I was wondering if anybody here already did some analysis of constants used often by shaders
16:08karolherbst: maybe a static table already covers 95% of those and we could get away without needing to reupload
16:12imirkin: karolherbst: what about "linking" each shader to a growing table of such constants?
16:12karolherbst: imirkin: then you need to reupload if applications switch the shader
16:12imirkin: and doing fixups when the table needs to be redone
16:12karolherbst: yeah.. that's what I already have
16:12karolherbst: but I thought maybe a static table could be enough
16:13imirkin: what woudl the static table have? this is only for long immediates anyways
16:13karolherbst: if that could already cover 95% of the constants widely used, we can ignore the 0.01% perf we would get from dealing witht he other 5%
16:13imirkin: i.e. things which don't fit in 19-ish bits
16:13karolherbst: imirkin: not only
16:13karolherbst: there are instrucionts encoding taking an imm + cb, but not two imms
16:14imirkin: i guess
16:14karolherbst: so maybe something like 1.0 would else end up there
16:14karolherbst: but also things like pi or e
16:14karolherbst: .. dunno
16:14karolherbst: never checked what's used across multiple shaders
16:14karolherbst: but we have a lot of space
16:15karolherbst: our driver constbuf has still at least 32kb of space
16:15imirkin: iirc calim's original idea was to burn an extra constbuf and just have stuff in there
16:15imirkin: and probably have that data attached to each shader, effectively another "segment"
16:15karolherbst: but then we would report less than other drivers, except on maxwell+
16:16karolherbst: on maxwell we could have a 64kb table though
16:16karolherbst: imirkin: yeah, sure, but that comes with the cost of rebinding/reuploading that
16:16karolherbst: although if we burn a cb we could skip the reuploading
16:16imirkin: on fermi and kepler could use texture slots i think
16:16karolherbst: and how to read that out then?
16:16imirkin: oh wait, that defeats the purpose, envermind
16:17karolherbst: I already have the code for the per shader approach though: https://github.com/karolherbst/mesa/commit/4deecb06aacde3bb1eedf4fbf3f8c9cd2a81782d
16:17karolherbst: what we could also do is to have a per shader space for indirectly accessed constants
16:18karolherbst: but... then only enable that for shaders which need this
16:18karolherbst: and then we could also stick more constants into it
16:18karolherbst: mhh, seems like in this patch I only had a 0x1000b table
16:19karolherbst: anyway.. I kind of like the idea of a static table as this would get rid of most of the drawbacks.. if good enough
16:22karolherbst: imirkin: mhh.. we could also use c14 for it as long as the shader doesn't use that many...
16:22karolherbst: which.. I guess no shader will hit anyway
16:22karolherbst: or relevant shader at least
16:23karolherbst: mhh.. would just suck a little for compute
16:25imirkin: you know ahead of time which UBOs are used
16:25imirkin: so you could just not do it for shaders that use a ton of UBOs
16:26imirkin: iirc in the original impl it was called c14_immediates :)
16:27karolherbst: yeah.. I will still check how good a static table approach would be.. maybe that's really good enough.. we still have tons of space left in our driver constbuf
16:31karolherbst: imirkin: btw, any opinions on reporting two more ubos for maxwell or do we really want to use them for internal things like this?
16:31karolherbst: but.. no idea for what to use the second one
16:31imirkin: does blob do it?
16:31imirkin: then i'd leave it alone imho
16:52Putti: imirkin, thanks I have used kmsro. I got lima now running by using the lima mesa driver provided in debian testing, not quite sure yet what was the issue with debian 10 and mesa master. One of my guesses is that libdrm was too old in debian 10 since I had that as an issue with mesa master on AOSP.
16:53Putti: I will try later running mesa master with debian testing and then I guess we will know if something is wrong in my build or it was some library in debian 10 that was not compatible with mesa master
17:07dschuermann: is the ARM CI getting fixed or should we merge manually?
17:12daniels: dschuermann: what's broken?
17:14dschuermann: ah, sorry, didn't mean to sound rude, guess I misinterpreted the backlog for that's being a known issue: https://gitlab.freedesktop.org/daniel-schuermann/mesa/-/jobs/2339610
17:14daniels: let me see what I can do to fix that
17:14daniels: I think it's some of our nginx changes this afternoon
17:18dschuermann: yeah no worries, it's really urgent. I should better go enjoy the sun anyway :P
17:18dschuermann: *really not urgent
17:20Putti: imirkin, mesa master works now with debian testing so probably libdrm or some other library in debian was too old
17:20imirkin: Putti: cool
17:34daniels: oh dear, that's made it a lot worse
17:40TD-Linux: does glamor have some sort of heuristic to determine when to submit frames? I'm using a java app (ghidra) and it's unusable without disabling its xrender support (scrolling and animations don't update at all until they stop moving) and I'm not sure where to file the bug
17:40imirkin: depending on what precisely it does, glamor can be quite slow
22:39dschuermann: daniels: thx