00:03 benjaminl: karolherbst: you mentioned earlier that XMAD is faster than IMAD, even for a full 32 bits. Should I also use XMAD instead of IMUL?
01:35 fdobridge: <g​fxstrand> IDK about that...
01:35 fdobridge: <g​fxstrand> The NVIDIA blob uses IMAD all over on Turing
01:35 fdobridge: <g​fxstrand> Like maybe XMAD is faster on Maxwell? IDK.
01:35 fdobridge: <g​fxstrand> I wouldn't obsess over that at the moment.
01:40 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> What does MAD mean?
01:42 fdobridge: <g​fxstrand> Multiply+Add
01:42 fdobridge: <g​fxstrand> https://tenor.com/view/chesirecat-wereallmad-gif-5339636
01:44 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> So it's basically the same thing as FMA?
01:44 fdobridge: <g​fxstrand> Not to be confused with FMA which is "fused multiply add" which is a floating-point mul+add with a bit of extra precision on the multiply
01:44 fdobridge: <g​fxstrand> Jinx!
01:47 fdobridge: <g​fxstrand> Some hardware (AMD, I think. Maybe others?) has both FADD and FFMA ops. On NVIDIA, if you don't want the extra precision of FFMA, you have to do FMUL+FADD
01:47 fdobridge: <g​fxstrand> Same with Intel.
01:49 fdobridge: <g​fxstrand> Some hardware (AMD, I think. Maybe others?) has both FMAD and FFMA ops. On NVIDIA, if you don't want the extra precision of FFMA, you have to do FMUL+FADD (edited)
02:21 benjaminl: is there a reason that NAK IR prints the registers as a range even with only one component?
02:22 benjaminl: my current understanding is that zero components isn't valid, so I kinda want to change this
02:40 fdobridge: <m​henning> I fixed the silly offset mistake in my opcode script
07:08 fdobridge: <d​adschoorse> amd only has ffma since rdna2
07:09 fdobridge: <d​adschoorse> amd has only ffma since rdna2 (edited)
07:58 fdobridge: <k​arolherbst🐧🦀> yeah, it's a maxwell/pascal only thing
08:58 fdobridge: <k​arolherbst🐧🦀> and it is significantly faster, but yeah, just an optimization
09:36 mupuf: Anyone knows who Philipp Stanner is?
09:36 mupuf: anyway, I answered some of his questions on the ML
09:36 mupuf: (related to the GSP)
09:36 karolherbst: yeah, works for RH on compute stuff
09:36 mupuf: Ack :)
09:37 karolherbst: was it an old email? If so, we probably discussed all the topics internally already
09:37 mupuf: well, in the email, I sent an invitation for people to ask me if they need some help figuring out some of the context for the kernel driver
09:37 mupuf: no, from yesterday
09:38 karolherbst: ohh patch review, I see
09:38 mupuf: Right
09:38 mupuf: I don't think I can't help much, but it is clear that Philipp is a newcomer to the codebase
09:38 karolherbst: yeah
09:39 mupuf: but I am sure that Lyude or Danylo would be better people to introduce him to it if he wants to contribute
09:39 karolherbst: yep
09:39 mupuf: but regardless, if need be, feel free to ping me for stuff that happened up to 2016
09:39 karolherbst: I'll have a meeting where Philipp is also on on Monday, so I can suggest that there
09:39 karolherbst: or something :D
09:39 karolherbst: cool, thanks
09:40 mupuf: I mean, I'm sure most of you guys knew you could contact me... but better re-iterate
09:48 karolherbst: yeah :) In theory Ben also said to be available in the future, but that's something we shouldn't rely on :D
09:49 mupuf: no, Ben should be contacted as a last resort, and probably through a friend, like airlied
09:49 karolherbst: yeah
09:49 karolherbst: I know, it's just something that Ben himself said
09:50 karolherbst: but we'll have to see if Ben will be around or not
09:50 karolherbst: and if not, that's also fine
12:05 dakr: mupuf: Philipp is relatively new to the kernel in general and just starts exploring the DRM subsystem and Nouveau as a specific driver - I'm serving as his mentor.
12:39 mupuf: sounds great!
12:39 mupuf: dakr: well, at least, I definitely like his attention to commit messages
12:49 fdobridge: <g​fxstrand> Not especially. We could change it easily enough
12:56 fdobridge: <k​arolherbst🐧🦀> fyi, the bridge doesn't resolve replies, this was for benjaminl ^^
13:42 fdobridge: <g​fxstrand> Oops
13:45 fdobridge: <g​fxstrand> Ugh... CCTLT
13:45 fdobridge: <g​fxstrand> IDK what it is
13:45 fdobridge: <g​fxstrand> Time to look at the blob...
13:49 HdkR: Cache...Control...Tilt-a-LiTtle
13:59 fdobridge: <k​arolherbst🐧🦀> texture
14:00 fdobridge: <k​arolherbst🐧🦀> @gfxstrand it's to invalidate caching of descriptor metadata
14:00 fdobridge: <k​arolherbst🐧🦀> _not_ content
14:01 fdobridge: <k​arolherbst🐧🦀> and also _texture_ not sampler
14:01 fdobridge: <k​arolherbst🐧🦀> mhh..`.IVALL` should invalidate all data as well I think.. `.IVTH` is for a single texture header
15:46 dakr: mupuf, well, it's not that long ago that I discussed with him commit message design in the kernel and stuff. Now, he stumbles across this series and, legitimately, starts wondering... :-)
15:46 mupuf: hehe
15:46 mupuf: yeah, ben wasn't known for his lenghy prose in commit messages
15:50 fdobridge: <g​fxstrand> Gah! I'm getting `ILLEGAL_INSTR_PARAM` on `BAR_SYNC` and my encoding is almost identical to NVIDIA's. 🤦🏻‍♀️
15:58 fdobridge: <k​arolherbst🐧🦀> do you emit the output predicate?
15:58 fdobridge: <k​arolherbst🐧🦀> ehh wait.. it's an input predicate
15:58 fdobridge: <k​arolherbst🐧🦀> my bad
15:59 fdobridge: <k​arolherbst🐧🦀> also.. it might require the general purpose barrier registers :ferrisUpsideDown: so if you don't use one of those it might error
15:59 fdobridge: <k​arolherbst🐧🦀> but besides that I don't have more information
16:01 fdobridge: <m​henning> I think that error can also mean you didn't allocate the barrier correctly
16:02 fdobridge: <k​arolherbst🐧🦀> mhhhhh
16:03 fdobridge: <g​fxstrand> Found it
16:03 fdobridge: <k​arolherbst🐧🦀> I don't think that exists?
16:03 fdobridge: <g​fxstrand> I did an oops
16:03 fdobridge: <k​arolherbst🐧🦀> you always have all barrier regs, just the membar stuff needs to be allocated
16:03 fdobridge: <k​arolherbst🐧🦀> ehh
16:03 fdobridge: <k​arolherbst🐧🦀> bar
16:03 fdobridge: <k​arolherbst🐧🦀> not membar
16:05 fdobridge: <m​henning> Yeah, Faith is talking about BAR.SYNC, which is an execution barrier, right?
16:06 fdobridge: <k​arolherbst🐧🦀> I think it was about BSYNC
16:06 fdobridge: <k​arolherbst🐧🦀> :ferrisUpsideDown:
16:06 fdobridge: <k​arolherbst🐧🦀> that's all not confusing at all
16:26 fdobridge: <g​fxstrand> Yeah, BAR.SYNC
16:27 fdobridge: <k​arolherbst🐧🦀> ahh yeah.. that ones has funky parameters/sources
16:29 fdobridge: <g​fxstrand> Not if you use the simplified encoding
16:29 fdobridge: <g​fxstrand> Different opcode
16:29 fdobridge: <g​fxstrand> No parameters
16:29 karolherbst: ahh
17:42 fdobridge: <g​fxstrand> I think I might have 1.1 now.
17:46 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> What's next? Memory model?
18:00 fdobridge: <p​homes> @asdqueerfromeu do you still test games on nvk? If you do then I would love to hear if !25550 breaks any of them 🙂
18:03 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> The new uAPI kinda broke my testing cycle
18:03 fdobridge: <g​fxstrand> Oh? 😢
18:03 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> Did something crash? :triangle_nvk:
23:18 biker_rat: is nvk now in mesa release candidate and will it work with kepler?
23:46 fdobridge: <a​irlied> If you have a new enough kernel