00:12 skeggsb: imirkin: i'll try and release a skeleton + a very very hackish kernel interface of some sort to give the features needed to go further. it's about then i think i'll get to being able to properly work on that side again
00:13 skeggsb: i started it a while back have been waylaid, got a few more things to upstream for ampere/prereqs first
00:14 skeggsb: (next month, forgot the timeframe)
00:41 imirkin: skeggsb: ok ... you've been sitting on this for a while, so i don't want it to languish too much longer. i don't think the initial bringup is that difficult if you ignore the kernel api bit of it.
00:42 imirkin: in the meanwhile i may try to hook up GL compute for nv50, maybe with a goal of ES 3.1 there -- might be achievable
00:58 FLHerne: az: You might want to test
00:58 FLHerne: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8440
01:01 FLHerne: az: > * karolherbst does verify his nouveau threading fixes against the android emulator
01:01 FLHerne: <karolherbst> without the patches my system just goes down
01:02 FLHerne: Maybe also https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8765 ?
05:10 dviola: skeggsb: I just sent a patch
05:44 az: FLHerne, thanks. Should I compile it from source or there is anther way to test it?
10:57 FLHerne: az: You'd have to compile it
21:44 imirkin: wtf. i just noticed we never attach screen->tls to compute bufctx??
21:44 imirkin: how have we not been having huge issues
21:45 RSpliet: have we not?
21:46 imirkin: with compute? i don't think so
21:46 imirkin: maybe
21:47 imirkin: i'm just wondering if we attach it in some way i'm not seeing
21:48 imirkin: ohhh yeah we do
21:48 imirkin: but if we resize it, we never reattach it
21:48 imirkin: sigh
21:51 imirkin: yeah, this is just a pile of fail
21:51 imirkin: we never update the tls area for compute
21:55 juri_: is there a document somewhere saying what chips have what level of compute available?
21:56 imirkin: juri_: i think nvidia puts out that sort of info. what are you curious about?
21:56 juri_: I mean when using nouveau.
21:57 imirkin: can you make a multiple choice of levels?
21:57 juri_: tl;dr: i have a bunch of cards, and would like to target them from under linux with GHC, but.. have no idea where to start with that.
21:57 imirkin: dunno what GHC is
21:58 juri_: the gnu haskell compiler. think: llvm.
21:58 imirkin: i see
21:58 imirkin: well
21:58 imirkin: in that case
21:58 imirkin: the relevant famlies will be
21:58 juri_: I'm just wondering what's working, and what will probably never work. I'm not someone using XOrg.
21:58 imirkin: G80 - GT218
21:58 imirkin: GF100-GF119
21:59 imirkin: GK104 - GK107
21:59 juri_: ok, neat. I can work with that.
21:59 imirkin: GK110 - GK208
21:59 imirkin: GM107 - GP10B
21:59 imirkin: GV100 - TU117
21:59 imirkin: GA100+ (i think has a new isa again)
22:00 imirkin: of those, nouveau has support for everything but the first and last
22:00 HdkR: Nah, GA has the same ISA as GV/TU
22:00 juri_: yeah, i've got GF108, GF106, and GK107.
22:00 skeggsb:sighs in relief
22:00 imirkin: ah ok. then we support all but the first - the original tesla one, while RE'd, is not fully supported yet, because the GPUs aren't capable of exposing the functionality outside of OpenCL
22:00 juri_: is there an entry point for this stuff, other than bugging you? :D
22:01 HdkR: Just the scheduling has slightly changed if you want to maximize the dual issue support of GA
22:01 imirkin: you can look at the compiler in mesa
22:01 juri_: hmm. ok, i'll start poking around. thanks!
22:01 imirkin: juri_: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/codegen
22:02 imirkin: still not 100% sure what your goal is
22:02 imirkin: but happy to answer nvidia hw-related questions
22:03 juri_: write code, run it, get results? :D
22:03 imirkin: hm ok
22:03 imirkin: yeah, there's more to it
22:03 RSpliet: skeggsb: is that relief over not having another ISA to RE, or the fact that GHC doesn't stand for the GNU Hadron Collider? :-D
22:03 juri_: preferably without starting XOrg, but. :D
22:03 imirkin: that's not an issue
22:03 imirkin: but you can do that today, with glsl compute
22:03 imirkin: (for example)
22:03 skeggsb: RSpliet: a bit of both :P
22:04 juri_: imirkin: thanks for the pointers. i'll stop bugging you now. :D
22:05 imirkin: juri_: if your goal is to write a compiler which generates byte code you can send directly to the gpu, you will also need to come up with a way to send it directly to the gpu.
22:06 imirkin: along with data to process, etc
22:07 imirkin: there are a handful of ISA's which encode different instructions, but the instructions themselves are fairly similar across the GPU families (GF100+)
22:07 imirkin: there are a few differences here and there of course
22:07 imirkin: along with new features introduced in later generations
22:08 imirkin: anyways, i'll bbiab. good luck. happy to answer questions you might have.
22:08 RSpliet: Mr. GNU might hate me for saying this, but you may have more luck compiling to SPIR-V and using existing OpenCL hooks for the runtime bits?
22:10 RSpliet: Seems to me like there might be a more portable solution somewhere in that direction
22:52 imirkin: oh i see. we never resize the tls.
22:53 imirkin: and we dump it into CP_SCREEN
22:54 imirkin: so all is well.