00:14imirkin: skeggsb: with 2d engine blit -- pass
00:14imirkin: skeggsb: any opinion on advantages of m2mf over 2d engine blit?
00:15imirkin: (for nv50-class hw)
00:16skeggsb: i actually don't know tbh, i presume there is one though as nvidia seem to prefer it where possible iirc. not even sure if it's a separate bit of hw or the class is a simpler interface to the same hw
00:19imirkin: i'll do some poking around to work out the conditions under which m2mf bails
01:14mwk: there's a separate bit of hw alright
01:16mwk: m2mf is separate and basically is a simple piece of hw using a simple version of the memory interface; 2d engine mostly reuses 3d pipeline, and is thus heavily distributed, using texture units to fetch source and ROP units to write destination
01:16mwk: ie. 2d means more bandwidth, more latency
01:41imirkin: mwk: ah ok. are you aware of the 64kb restriction i ran into?
01:41imirkin: mwk: basically if one line is > 64kb (or if the offset is >= 64kb for tiled), then it does weird things
01:42imirkin: it feels like it has a 16-bit counter, and so it just drops the upper bit and so you get 2 mirrored copies if you have 128kb-wide lines
01:47mwk: don't recall that
01:47imirkin: and if you try to set a source "X" value > 64kb, you get a launch error (XY_OUT_OF_BOUNDS)
01:48mwk: hmm, right, there was something like this
01:48mwk: that's 2d, right?
01:48imirkin: 2d works fine
01:48mwk: ISTR it had larger max
01:48mwk: but okay, apparently it doesn't
01:48imirkin: this is with a tiled source
01:48imirkin: perhaps that plays into it
01:48imirkin: (i.e. blocklinear)
01:49imirkin: 8k wide, rgba32ui
01:49mwk: that could be it, yes
01:52imirkin: i'm going to play with it later, maybe over the weekend, figure out the parameters
01:53imirkin: i.e. where m2mf maxes out
02:18imirkin: karolherbst: https://hastebin.com/wevehaquru.css -- i think cube stuff is coz lack of seamless, the rast stuff is coz lines are meant to get clipped differently in ES
02:18imirkin: karolherbst: dEQP-GLES3.functional.fbo.invalidate.sub.unbind_blit_msaa_stencil - that one looks weird.
02:18imirkin: msaa stencil is a good spot for nouveau to have issues though
02:23imirkin: fun. errors in some weird sub-triangle. sigh...
02:59imirkin: and of course apitrace doesn't support dumping msaa surfaces in ES
04:11imirkin: ffs. that test fails, i think, because of "what happens if you have a depth test but no depth surface" issue
04:11imirkin: "DONT DO THAT!"
04:26imirkin: "If there is no depth buffer, it is as if the depth buffer test always passes.", which i think is what the hw does...
05:30imirkin: looks like 3d blitter fails at depth blit =/
05:30imirkin: and it works on nvc0 coz there it goes via 2d blitter
05:31imirkin: if i force it to go via 3d blitter, same issue.
06:15imirkin: WFI FTW
08:15karolherbst: imirkin: yeah... msaa is a bit broken in some areas :)
15:38imirkin: karolherbst: had absolutely nothing to do with msaa as it turns out
15:39imirkin: or rather, very little
15:39imirkin: msaa triggered the 3d blit logic
15:39imirkin: which in turn needs WFI's (aka serialize) when blitting zeta surfaces as colors.
15:44imirkin: the fix applies to nvc0 as well
15:44imirkin: even though that particular test wasn't broken as it didn't hit the 3d path, forcing it to go via 3d path caused it to be broken
15:53imirkin: running KHR-GL33 from cts now.
16:18imirkin: hm, just get the following errors with KHR-GL33. didn't run GTF... https://hastebin.com/gesomujuva.css
16:18imirkin: iirc the texture swizzle thing is something i determined was a hardware fail
16:18imirkin: the pipeline stats thing is known too, although i haven't quite worked out what's going on
16:19imirkin: the first one is new. perhaps my earlier grep's were for Fail
16:19imirkin: <Text>Texture Size Promotion Test have approached error.</Text>
16:19imirkin: thanks, CTS. that was very useful information.
17:09imirkin: ugh, looks like that one is coz we don't support 8x msaa on rgba32f
17:30karolherbst:should get back to fixing CTS issues as well at some point
17:30imirkin: given those were the only fails, i think we're doing relatively well on g84 at least
17:31imirkin: i need to do a bit of RE on m2mf, and i'll post more patches
17:36karolherbst: yeah, more thinking about nvc0 here
17:37karolherbst: but first I want to fix multithreading :D
18:41imirkin: karolherbst: how do you want your r-b's? @redhat? or @gmail?
18:41karolherbst: ehhhh... whatever you prefer. Usually using @redhat because that's what is set up on the machine :D
18:42imirkin: doesn't matter to me. just have to know what to type.
18:42imirkin: i'll use @rh since that's what you seem to prefer nowadays
18:42karolherbst: yeah... I just don't care enough either way :D
18:43RSpliet: TIL I overthink these things. Company e-mail if the company paid for the work, private otherwise :-P
18:43karolherbst: RSpliet: well, sure, but I am way too lazy for that
18:43imirkin: that's what i generally do too
18:44RSpliet: Hahahaha, yeah, lazy is an excellent motivation
18:44karolherbst: one exceptions is when I think the change itself _could_ cause political garbage issues
18:44imirkin: but ... i also don't care
18:44karolherbst: then I use my private one
18:47karolherbst: mhhh.. actually there seems proper browser extensions for text snippets which don't suck..
18:48karolherbst: ehhh, nvm, they require some garbage accounts
18:48karolherbst: maybe I should just write one myself
18:51karolherbst: ahhh, I think I got something
18:54karolherbst: nice, it works
19:04imirkin: i'll dig up a gt21x to make sure i didn't break things too much for the later-gen boards
19:04imirkin: but i'm pretty sure it should be fine
20:11imirkin: karolherbst: next batch: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8396
20:11imirkin: karolherbst: and there will be another one over the weekend at some point i think
20:11imirkin: would be nice to get this in before 21.0 branchpoint
20:50karolherbst: okay, will take a look before then
22:02imirkin: hmmm ... hopefully i have a GT21x?
22:02imirkin: i have that GDDR5 GT215, maybe that'll work fine