00:41yates: has anyone noticed that a system with an nvidia video card, the nouveau driver, and a dual-input monitor (hdmi), that the disconnect caused by switching monitors causes the video to die?
00:42yates: if you have the nvidia system selected while booting, it comes up fine, but after switching to an alternate computer, the video dies.
00:42yates: s/switching monitors/switching monitor inputs/
00:42yates: the system with nvidia card is f32/cinnamon, the other system had intel chipset and is lubunty 18.04lts/lxde
00:42yates: the lubuntu system comes back every time, no problem. i've switched cables and inputs and determined the problem is at the computer
00:42yates: here's my /var/log/Xorg.0.log. i don't see anything that i recognize as a problem. http://paste.ubuntu.com/p/DSxmSM8tCb/
00:44imirkin: yates: dmesg might be more instructive
00:45imirkin: i've not seen any issues flipping between diff hdmi inputs
00:45imirkin: but it'll depend on the specific monitor as to precisely what that does
00:45imirkin: oh interesting
00:46imirkin: can you confirm that 4k@60 is working as expected on this monitor?
00:46imirkin: i suspect that the monitor may be losing its SCDC settings when flipping between inputs, and nouveau doesn't realize it should re-set those
00:47imirkin: since it thinks that they're still set
00:47imirkin: that's just a quick guess based on 0 data
00:47imirkin: one quick way to check is if you change it to 4k@30 (or a lower resolution @60), these problems go away
00:48yates: imirkin: here is the dmesg output: http://paste.ubuntu.com/p/2RQcnXcmbr/
00:49yates: [13474.481587] nouveau 0000:01:00.0: DRM: DDC responded, but no EDID for HDMI-A-1
00:49imirkin: yeah, saw that. not ideal, but not necessarily fatal, since it might have responded a bit later
00:49yates: what is scdc?
00:49imirkin: it's like edid
00:49imirkin: but on a different i2c address
00:50imirkin: it controls scrambing and tmds clock division
00:50imirkin: which are both required to achieve > 340mhz pixclk's with hdmi
00:50imirkin: but both the source and sink must be in agreement abou tit
00:54yates: imirkin: what app can i use to change the monitor settings? i am ssh'ed in from another system with x11 ability so i can run a gui app from my second system and change it
00:54imirkin: DISPLAY=:0 xrandr -r 30
00:54imirkin: er no, that's right
00:54yates: as normal user?
00:54yates: or root?
00:54imirkin: as the same user who's logged in no the main thing
00:55imirkin: (that's the easiest)
00:55imirkin: if it's at the display manager, it's achievable to change it, but not easy
00:55imirkin: you're better off logging in
00:55yates: will that change it across reboots?
00:56yates: ok let me try that
01:00yates: that worked a couple times, then it died again..
01:01yates: seemed to be better
01:01imirkin: can you just try a lower resolution? it might decide to flip back to @60 for some reason
01:01imirkin: DISPLAY=:0 xrandr -s 1920x1080
01:07yates: imirkin: that didn't work right. the xrandr -x 1920x1080 made the display look "squashed". and then switching caused it to die again
01:07imirkin: not -x
01:07imirkin: (what's -x?)
01:07yates: due to this roblem, i'm having to reboot each time
01:07yates: yes, i meant -s
01:07imirkin: "squashed" is right, since we reduced the resolution
01:08imirkin: i bet that powering the display on/off would also fix it
01:12yates: no, powering the monitor off and on did not fix it
01:12imirkin: what about cable unplug/replug?
01:13imirkin: and what about, when it's in a broken state
01:13imirkin: DISPLAY=:0 xrandr -r 30
01:14yates: how can i do that in its broken state? i can't see!
01:15imirkin: you're ssh'd in no?
01:15imirkin: so ... do it over ssh
01:15imirkin: make sure you're in as the same user as the one who's logged in "locally" on the machine
01:16imirkin: otherwise the X credentials won't match up
01:16yates: Rate 30.00 Hz not available for this size
01:16imirkin: pastebin just "DISPLAY=:0 xrandr"?
01:17yates: that's different than it was!
01:17imirkin: and the monitor is plugged in?
01:17imirkin: that's not what the video card thinks :)
01:17yates: it's the same one i'm using now, with the lubuntu system
01:17imirkin: note how all the connectors say 'disconnected'
01:18imirkin: it has that 4k@60 mode left-over
01:18imirkin: but that's just an X internal detail
01:18yates: i see that now
01:18imirkin: that mode isn't really there
01:18yates: well, it IS disconnected - i have my monitor switched to HDMI2, which is my lubuntu system
01:19imirkin: oh i see, you only have one monitor total
01:19yates: that's where i'm sshing from
01:19yates: i do have another i could hook up
01:19imirkin: does it have picture-in-picture?
01:19imirkin: i used to do that a lot with an older monitor, hooking up the GPU i was working on to s-video or whatever
01:20yates: yes, i have one monitor with two hdmi inputs, one from my f32/cinnamon system, and one from my lubuntu-18.04lts/lxde system
01:21yates: it is the switching between these two that is the entire problem
01:22imirkin: does the monitor have a picture-in-picture setting
01:22yates: i could run the command when the HDMI1 is selected. shall i try that?
01:22imirkin: which allows showing both at once?
01:22imirkin: just like hit enter on the "other" machine
01:22imirkin: after you've switched
01:22yates: it doesn't appear to have PIP
01:23yates: ok here: http://paste.ubuntu.com/p/tS5YKntJGs/
01:24yates: did you want me to try "DISPLAY=:0 xrandr -r 30" in a similar manner?
01:25imirkin: btw, that's really bad of this monitor to do that. it's supposed to respond to EDID even if it's turned off
01:25imirkin: (with power supplied by the source)
01:27yates: it works for one switch, then it stops working. when i stopped working, i ran xrandr (no opts) and got this: http://paste.ubuntu.com/p/vZ2YwqxJTy/
01:28yates: so it seems to be switching back to 60
01:28imirkin: and to confirm, doing -r 30 "fixes" it that time right?
01:28imirkin: (i.e. no reboot required/etc)
01:28yates: right, no reboot required
01:28imirkin: so my money's on SCDC being messed up
01:29yates: you mean it's my monitor?
01:29imirkin: i mean, sorta
01:29imirkin: your monitor is doing something in a way that's different than other monitors
01:29imirkin: and all this HDMI 2.0 stuff hasn't gotten an immense quantity of testing on novueau in the first place
01:29imirkin: it's a somewhat awkward protocol
01:30imirkin: since it requires the sink and source to be in agreement
01:30yates: i just noticed that my lubuntu system is running at 30 Hz, so i guess that's why it always works?
01:30imirkin: probably, yeah
01:30imirkin: older GPU
01:30yates: i don't need 60 Hz, how to i force it to 30 Hz permanently? (on my nvidia system)
01:30imirkin: this is up to your DE
01:31imirkin: i don't know anything about ubuntu or its derivatives
01:31imirkin: i don't know anything about fedora or its derivatives
01:31yates: that's the one with the nvidia
01:31yates: hokay let me poke around
01:31yates: thanks much, imirkin
01:31imirkin: you can also force the issue
01:31yates: have you worked on the nouveau driver?
01:32yates: huh? force the issue?
01:32imirkin: i did the initial HDMI 2.0 impl, among other things
01:32imirkin: i think you can run with nouveau.hdmimhz=300 or something
01:32imirkin: whch will completely disallow the high-freq modes
01:32imirkin: let me double-check though
01:32yates: you mean in the kernel boot modeline?
01:32imirkin: cmdline, yea
01:32yates: well, let me try to configure first - that's easier
01:32imirkin: yeah, should work
01:33imirkin: nouveau.hdmimhz=300 will disallow modelines > 300mhz pix clk
01:36yates: ok so i configure it to 30 Hz permanently and it's working over multiple switches.
01:36imirkin: ultimately this is a bug in nouveau
01:36imirkin: but this works around it for you for now
01:36imirkin: which monitor is this ftr?
01:37yates: how can it be? if the monitor won't allow SCDC to be read
01:37imirkin: i doubt it's that
01:37yates: it's a 27-inch LG
01:37imirkin: i think it just loses SCDC settings
01:37imirkin: when nouveau doesn't think they'll get lost
01:37imirkin: and so nouveau is sending a scrambled / clock-divided signal
01:37imirkin: and the monitor isn't expecting it
01:37imirkin: (don't ask me wtf clock division is)
01:37yates: so it just needs to detect that scenario and then reestablish the setting if detected?
01:38imirkin: (and i know what scrambling is, but i don't really see how it helps in this case)
01:38yates: usually it means a higher frequency clock is divided down.
01:38imirkin: right, but ... what does that mean in practice? :)
01:38imirkin: so you have a 600mhz pixclock, and there's a 40x divider
01:38imirkin: so now you're sending a 15mhz or whatever clock ... but you still need to get the data across
01:39imirkin: er, 4x, not 40x
01:39yates: not sure - i'd have to dive into all the parameters to get my head wrapped around it.
01:39imirkin: those are the only two parameters
01:39imirkin: scrambling and div-clk-by-4
01:39yates: the pixclk and the divider ratio?
01:39imirkin: both need to be enabled for the higher rate modes to work
01:39imirkin: the division is always by 4 for the higher modes
01:40imirkin: this is like a HDMI-level thing
01:40imirkin: the cable can't handle the high-freq signals
01:40imirkin: so they play games
01:40imirkin: by being clever
01:40imirkin: but they're cleverer than me, at least when it comes to signals stuff in practice :)
01:40imirkin: so i don't worry about it too much
01:40yates: ultimately it comes down to more bandwidth required. no matter what tricks.
01:41yates: you can reduce clock rate by expanding the number of data lanes.
01:41imirkin: not what's happening here
01:41imirkin: same data lates
01:41imirkin: same everything
01:41imirkin: lower clock, scrambling, and more data
01:41imirkin: scrambling usually means that it goes through an encoder which ensures that you don't get too many strings of 1's or 0's in a row
01:42yates: perhaps they have a mode where the clock sent along the cable is lower, but they tell the monitor it has to double it
01:42imirkin: also leading/falling edge style cheating
01:42imirkin: who knows
01:42yates: DDR blah
01:43imirkin: pre-hdmi 2.0, hdmi was so simple
01:44yates: i thought about making my own hdmi device for my tv/audio system, til i heard they want you to ante up $10K for a license...
01:45yates: yes, scrambler or whitener
01:45yates: thanks again, much, imirkin
01:47imirkin: yates: can you get the exact model of the monitor? or just pastebin xrandr --verbose on it?
01:47imirkin: er nevermind
01:47imirkin: i have your EDID already in one of your pates
01:48yates: sure hang on
01:48imirkin: "LG Ultra HD"
01:48imirkin: is what it says in the EDID
01:48yates: ah ok
01:50imirkin: that was done when it wasn't plugged in, but it's fine, i got the edid from one of your earlier pastes
01:50imirkin: its dumped in xorg log
08:29pmoreau: imirkin: Here is what I ended up with to fix the spill offset issues; I think it makes sense, but would definitely not mind a second opinion on it especially from someone who knows a lot better than me how this is supposed to work. https://gitlab.freedesktop.org/pmoreau/mesa/-/commit/e12de28192cd6996646c00a87a28a749d727c701
09:48pmoreau: > Todo wtf is up with $a7?
09:48pmoreau: I agree with that statement from envytools; the hardware has been throwing at me some “Invalid opcode” for the following: `R2G.U32.U32 g[A7+0xd], R1; /* 0xe42047840c001a01 */` and `LST.S64 local[A7+0x0], R0; /* 0x60800784dc000001 */`.
09:49pmoreau: Both envydis and nvdisasm were happy to decode those instructions without issues, but the hardware was having non of it. So might need to restrict $a7’s usage.
16:59imirkin: pmoreau: instead of *2
17:00imirkin: pmoreau: you want * lval->reg.size / units
17:00imirkin: actually let me read over it more carefully
17:03pmoreau: imirkin: It sounds like `* lval->reg.size / units` will achieve the same thing but probably be more robust in case we later change the value of `units`.
17:03imirkin: pmoreau: so the subtlety is that nv50 has 16-bit colors and 32-bit regs are expressed as pairs of colors), while nvc0+ has 32-bit colors
17:03imirkin: pmoreau: unfortunately i don't remember how (or whether) this is reflected in e.g. compMask
17:03imirkin: the fixed * 2 seems bogus pretty much no matter how you slice it...
17:04pmoreau: Did you check the commit message? I tried to explain it there
17:04imirkin: i'm trying to grok it
17:04imirkin: but i'm wondering if it looks the same on e.g. nvc0
17:06imirkin: pmoreau: there's also some difference if e.g. a merge is being spilled
17:06imirkin: vs a component of a merge
17:06imirkin: the lval->reg.size might be different
17:07pmoreau: Okay, I understand better why I got those values on vn50: i thought the values would be expressed in bytes, not in 16-bit multiples.
17:07imirkin: lval->reg.size is expressed in bytes
17:07imirkin: so here's the question... what's the lval here?
17:07imirkin: is it the U64 which is being spilled?
17:07imirkin: or is it the U32 which is half of the U64?
17:09pmoreau: Let me see if I can remember…
17:10imirkin: i think the problem is that this logic works for one case but not the other
17:10imirkin: or something.
17:11imirkin: and compMask *is* done in terms of colors
17:11imirkin: so because on nv50 colors are 2x
17:12imirkin: you actually need to divide ffs(lval->compMask) by 2
17:12pmoreau: If I multiply by the register size, I agree.
17:12imirkin: although..... hm
17:12imirkin: oh right
17:12imirkin: on nvc0, it's 1 color per 32-bit
17:12imirkin: so this works out
17:13imirkin: actually this is just bogus
17:13imirkin: instead of * lval->reg.size
17:13imirkin: it should be * units
17:14imirkin: or something
17:14imirkin: << getFileUnit(). it's a shift :)
17:16pmoreau: Okay, let me try that out
17:18imirkin: and this works because compMask is expressed in terms of colors, not bytes. so e.g. a u64 value will just have more colors associated with it
17:18imirkin: so the offsets should all work out
17:19pmoreau: Awesome! I will change the commit message to reflect that. I knew I was missing something and a second pair of eyes would help. :-)
17:20imirkin: as with all matters of RA, i'm not 100% sure
17:20imirkin: so ... some testing would be prudent
17:20pmoreau: Do you happen to know how to avoid Nouveau from using $a7? I tried changing `TargetNV50::getFileSize()` for `FILE_ADDRESS` to return 3 (instead of 4), but that did not help.
17:21imirkin: looks like this was one of calim's last contributions: 2e9ee44797fcce10 -- i guess he missed it / forgot
17:22imirkin: if file size is 4, it should definitely never use a7 in the first place
17:22imirkin: if file size is 4 it should use 0..3
17:22imirkin: do you have a sample where this happens?
17:22imirkin: if so, can you pastebin the NV50_PROG_DEBUG=255 for it? (and please don't use gitlab snippet thing, or give me a raw link or something)
17:22pmoreau: I was thinking, maybe it is expressed in terms of 32-bit values and $a being 16-bit, a value of 4 would allow 8 of them.
17:23imirkin: i didn't even know there were 7 address regs
17:23imirkin: i only thought there were 4
17:23imirkin: i guess that's $c
17:23pmoreau: I have multiple samples where this happens. One sec.
17:24pmoreau: Me neither; I’ve been looking at https://envytools.readthedocs.io/en/latest/hw/graph/tesla/cuda/isa.html#registers
17:24imirkin: yeah, i don't think that's used
17:25imirkin: and internally, $a0 -> $a1
17:25imirkin: i.e. we will compute $a0, but then it will get fixed up to $a1 at emission time
17:33pmoreau: imirkin: Here you go; I just noticed that the emitter thinks it is generating `st u32 # s[$r6+0x3c] $r3` but in practice we get `st b32 s[$a7+0x3c] $r3`. https://gitlab.freedesktop.org/pmoreau/mesa/-/snippets/1921/raw/main/Out.txt
17:36pmoreau: Ah right, I added prints after each peephole pass. It looks like that weird stuff is coming from the IndirectPropagation pass, if I am not mistaken.
17:42pmoreau: Disregard my previous comment, I was looking at the wrong part of the code.
17:46pmoreau: Looks like it’s coming from splitting those 64-bit stores to local memory into 32-bit stores, and I’m quite sure I’m the one who wrote that… time to go and fix it! Thanks for the help. :-D
17:53pmoreau: Yup, now it works a lot better 😅
18:04tavvva: imirkin: sorry to interrupt your thoughts :] have you had a chance to look at the NVS 140 video thingy?
18:07tavvva: imirkin: I'll have to return the laptop soon and the chance to test the patches will drop
19:02imirkin: tavvva: not yet, sorry. i haven't been able to make progress on getting my test env set up
19:03imirkin: pmoreau: cool. yeah, it's important to see what the emitter thinks it's doing
19:04pmoreau: I usually do that, but for some reason I did not do it this time. :-/
19:04imirkin: yea no worries
19:06tavvva: imirkin: ok, should I try it later or you see it unprobable you could make progress with it?
19:06imirkin: tavvva: it's improbable, sorry
19:06imirkin: i dunno wtf is wrong with this G84, but it _really_ doesn't want to work
19:06imirkin: maybe i can just reset it... let's try that
19:08tavvva: imirkin: ok, thanks for your time anyway
19:08imirkin: yea, reset doesn't help
19:08imirkin: tavvva: sorry =/
19:09tavvva: imirkin: no need to be sorry ... that's life :]
19:11tavvva: imirkin: do you know anyone else who could look at the issue or you're the only one who has the required knowledge for that?
19:12imirkin: i definitely don't want to volunteer anyone else for it.
19:15tavvva: imirkin: may I know more about the blocker you were/are facing? can I help somehow?
19:16imirkin: tavvva: [274452.417103] nouveau 0000:04:00.0: bus: MMIO write of 0000003f FAULT at 00fd84
19:16imirkin: and related issues
19:16tavvva: imirkin: like giving you the access to the hardware or something
19:16imirkin: the VP2 engine seems like it's semi-dead
19:17tavvva: imirkin: does it mean it's a kind of regression that appeared recently?
19:17imirkin: i haven't tried it with this specific board ever, i think
19:17imirkin: i could also plug a different board in
19:17imirkin: but that requires reboots, etc
19:18tavvva: imirkin: and if I give you access to the hardware, would it help
19:18imirkin: tavvva: no, i'd rather do this locally
19:21tavvva: imirkin: ok, in that case I have no other ideas how to move forward ...
19:21tavvva: imirkin: I'll try to ask again in few weeks/months
19:21tavvva: thank you :]
19:23tavvva: c.u. guys
19:34imirkin: pmoreau: sounds like you're making good progress too?
19:34pmoreau: Fixed 6 tests over the weekend. :-)
19:35imirkin: 6 down, 70000 to go?
19:35imirkin: but this spilling fix should actually be good for everything
19:35imirkin: it's a pretty subtle problem
19:35imirkin: that said, spilling is less frequent on nv50 coz it has more regs
19:35pmoreau: Down to 13 for the basic test
19:36pmoreau: I am not sure about that: with the CTS I usually end up constrained to only 16 regs.
19:41imirkin: i mean for graphics
19:41imirkin: you get 128 regs
19:41pmoreau: Ah, ok
19:41pmoreau: Among the most annoying issues left for fixing some of the subtests of basic, are timeouts (“gr: TRAP_MP_EXEC - TP 0 MP 0: 00000008 [TIMEOUT] at 000398 warp 0, opcode f0000001 e0000001”) and still getting some LOCAL_LIMIT_WRITE despite the tls realloc working.
19:51imirkin: sounds tricky
20:35pmoreau: I am not impressed: the binary generated by NVIDIA for SM 11 `BAR.ARV.WAIT b0, 0xfff; /* 0x00000000861ffe03 */`, what my G96 thinks about it: “gr: TRAP_MP_EXEC - TP 0 MP 0: 00000010 [INVALID_OPCODE] at 0000e0 warp 10, opcode 861ffe03 00000000”
20:35imirkin: at least we're consistent!
20:38pmoreau: I guess I’ll need to try to follow the control flow to figure out what is going wrong with that kernel and why the last instruction is timing out for some of the warps.
20:40imirkin: pmoreau: hm, i wonder if there's some control flow around the barrier
20:40imirkin: and some threads exit before hitting it?
20:41pmoreau: There definitely is some control low around the barrier, as the barrier sits inside a do-while loop.
20:42imirkin: hm, scary
20:42imirkin: i don't know how barrier works tbh
20:42pmoreau: The conditional is based on the size of the block so all threads within the block should always have the same value there.
20:55pmoreau: I’ll leave that timeout be for now and focus on the LOCAL_LIMIT_WRITE errors instead: that way I can include it in my TLS rework series and submit it, though I’ll need to do some testing with graphics workloads too before that.
20:55imirkin: yeah, at least run like dEQP and KHR-GL33 test suites
20:56pmoreau: What is the scope of a nv50_screen BTW? Would it be possible on Tesla to get both a non-compute program and a compute program in the same screen?
20:56imirkin: i'd like to get us a standard "test set" that we can run easily, e.g. adocker thing
20:56pmoreau: That would be great!
20:56imirkin: with ES 3.1
20:56imirkin: with my patches, there are only a small handful of non-conformant situations with ES 3.1
20:57imirkin: the big one is textureGather with an explicit component
20:57imirkin: the hw just doesn't support that
20:57imirkin: earlier tesla's don't have texgather at all, and the later ones do only the 'r' component
20:57imirkin: other than that, i think the DX10.1 tesla's can handle it all.
20:58pmoreau: Okay, so I’ll need to make sure I support that case.
21:00pmoreau: There is no barrier between the different 3D stages, right? So a fragment shader could already start running before all vertex shader instances are done (as long as the vertex shaders for all the points of the primitive containing that fragment did finish).
21:00imirkin: in fact multiple draws can sometimes run in parallel
21:01pmoreau: And those draws being in the same screen?
21:02imirkin: but that shouldn't matter
21:02imirkin: i wouldn't worry _too_ much about the mixing stuff
21:02imirkin: usually it require explicit barriers
21:02imirkin: in order to work properly
21:03karolherbst: imirkin: you mean like different SMs run different shaders? Or just same shaders, but different parameters?
21:03imirkin: karolherbst: i don't know all the specifics.
21:03imirkin: the hw does it when it thinks it can
21:03pmoreau: Shouldn’t it? If both the vertex and fragment shader use local memory, we need to make sure they don’t run on each others toes.
21:03karolherbst: yeah.. I think the former thing is getting used more often the more SMs are on the GPU :D
21:03karolherbst: but the latter should be "always" possible I think?
21:04karolherbst: and also no idea how much impact the driver has here
21:04karolherbst: pmoreau: yeah, hence we reserve space per SM per thread
21:04karolherbst: per shader stage even?
21:05pmoreau: Not per shader stage IIRC, which is the problem
21:05imirkin: he means like let's say VS and FS both use lmem
21:05karolherbst: I get that
21:05imirkin: pmoreau: ultimately the shaders have to run somewhere
21:06karolherbst: I am just surprised we don't partition according to stage
21:06imirkin: the tls should be based on the size of the chip, i think
21:06karolherbst: I mean..
21:06imirkin: not based on the number of "different" shaders
21:06karolherbst: per SM per thread _should_ be enough
21:06pmoreau: We definitely give the same starting address into the TLS bo for all 3D stages, so even if it was per stage it wouldn’t matter.
21:07karolherbst: pmoreau: which should be fine
21:07karolherbst: do we even set more than offset+size?
21:07pmoreau: Not if the fragment shader can start running while instances of the vertex shader are still running.
21:07karolherbst: pmoreau: well...
21:07karolherbst: not on the same SM
21:08karolherbst: SM has to be done with its execution before it can load a different shader
21:08pmoreau: An SM can’t execute two different shaders?
21:09karolherbst: hard to say
21:09karolherbst: there is a concept of blocks..
21:10karolherbst: it doesn't matter
21:10karolherbst: as local memory is allocated per thread
21:10karolherbst: we might have to set the same size per thread across all stages?
21:11karolherbst: dunno what happens if the VS has 40k and the FS 80k
21:11karolherbst: and then a SM starts executing the FS while finishing the VS? if that's even possible
21:12karolherbst: but then again
21:12karolherbst: it doesn't matter what is possible on the same SM
21:12pmoreau: Okay, if we have the same size per thread for all stages, it’s indeed fine.
21:12karolherbst: I _think_ if one SM still works on a VS with a different local memory size than a differen SM running a FS...
21:12pmoreau: If we don’t have the same size, that could be trouble.
21:14karolherbst: I could see how that messes things up
21:14karolherbst: pmoreau: okay, cool
21:14karolherbst: next question, what happens if a CS runs in parallel :p
21:14karolherbst: I am sure that's not possible on your hw, but ... maybe that's supported with ampere? :D
21:14karolherbst: imirkin: do you know if any nvidia gen can run a grpahics pipeline alongside a compute pipeline?
21:15pmoreau: I think it’s only possible since Ampere
21:16karolherbst: so we might have to serialize in a few places.. great...
21:16pmoreau: Or allocate more memory :-)
21:16karolherbst: can't do it while stuff is running
21:17karolherbst: pmoreau: do you know what we should do? per stage tls space or whatever?
21:17karolherbst: I don't know how much possibilities we have here
21:17karolherbst: but it might make sense to just... split it
21:19pmoreau: > in fact multiple draws can sometimes run in parallel
21:19pmoreau: imirkin But those multiple draws would be using the same set of shaders, correct? Since the screen only contains up to one instance of each shader stage, if I am not mistaken.
21:19imirkin: i'm talking about the hw doing the parallelism
21:19imirkin: you can submit multiple draws
21:19imirkin: it won't necessarily wait for each draw to complete
21:19imirkin: before starting the next one
21:20karolherbst: I think if we change the TLS config we either WFI or we hope the command itself will do it?
21:20imirkin: yeah, probably
21:20karolherbst: the issue is.. are draw calls interfering with each other, or just shader stages
21:20imirkin: and perhaps the hw only does it if tls isn't used
21:20imirkin: i dunno
21:22karolherbst: too many unknowns here
21:23pmoreau: I’ll bail out for today; I’ll continue looking into fixing my non-parallel case tomorrow.
21:23pmoreau: At least the rework should already be an improvement over the current situation, even if it doesn’t address the parallel cases.
21:23karolherbst: I probablye review stuff tomorrow, so just throw links against me :D
21:24pmoreau: The clover series is still up :-) I added an additional patch today
21:25karolherbst: it's still open in a tab :D
21:27pmoreau: Some feedback on https://gitlab.freedesktop.org/pmoreau/mesa/-/commit/a9b4302544e4f076be0aad89573428ad8e9086f4 and https://gitlab.freedesktop.org/pmoreau/mesa/-/commit/80dc15dc8523c0e3d326cb94d0ac1f18788029f3 would be appreciated (note that in the latter.
21:27karolherbst: ohh yeah.. that API one
21:28karolherbst: pmoreau: CL_SUCCESS is 0 tw
21:28karolherbst: ehh wait
21:28karolherbst: return status >= 0 ? CL_SUCCESS : status; is.. ehh CL_SUCCESS
21:29karolherbst: or am I am missing something?
21:29pmoreau: So, status contains either an error code (< 0), CL_SUCCESS, or >0 like things like CL_QUEUED and others.
21:30karolherbst: pmoreau: you know what's the most annoying thing about clovers error handling? it throws random error values even if an API doesn't allow it :/
21:31karolherbst: yeah.. but ... no idea on how to "fix" it without rewriting the entire api layer
21:31karolherbst: probably fine as long as the CTS doesn't complain..
21:33pmoreau: And if you are desperate for things to look at, you could browse through this branch which contains all my current patches for NV50: https://gitlab.freedesktop.org/pmoreau/mesa/-/commits/nv50_improve_tls. I need to squash some patches there, and rework some of them to perform the transformation in the legalisation pass instead.
21:35pmoreau: Given the current status of OpenCL, I’m not sure rewriting the entire API layer is worth it, unless OpenCL gets picked up again as an API but I doubt it.