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