00:12skeggsb: 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:13skeggsb: i started it a while back have been waylaid, got a few more things to upstream for ampere/prereqs first
00:14skeggsb: (next month, forgot the timeframe)
00:41imirkin: 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:42imirkin: 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:58FLHerne: az: You might want to test
00:58FLHerne: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8440
01:01FLHerne: az: > * karolherbst does verify his nouveau threading fixes against the android emulator
01:01FLHerne: <karolherbst> without the patches my system just goes down
01:02FLHerne: Maybe also https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8765 ?
05:10dviola: skeggsb: I just sent a patch
05:44az: FLHerne, thanks. Should I compile it from source or there is anther way to test it?
10:57FLHerne: az: You'd have to compile it
21:44imirkin: wtf. i just noticed we never attach screen->tls to compute bufctx??
21:44imirkin: how have we not been having huge issues
21:45RSpliet: have we not?
21:46imirkin: with compute? i don't think so
21:46imirkin: maybe
21:47imirkin: i'm just wondering if we attach it in some way i'm not seeing
21:48imirkin: ohhh yeah we do
21:48imirkin: but if we resize it, we never reattach it
21:48imirkin: sigh
21:51imirkin: yeah, this is just a pile of fail
21:51imirkin: we never update the tls area for compute
21:55juri_: is there a document somewhere saying what chips have what level of compute available?
21:56imirkin: juri_: i think nvidia puts out that sort of info. what are you curious about?
21:56juri_: I mean when using nouveau.
21:57imirkin: can you make a multiple choice of levels?
21:57juri_: 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:57imirkin: dunno what GHC is
21:58juri_: the gnu haskell compiler. think: llvm.
21:58imirkin: i see
21:58imirkin: well
21:58imirkin: in that case
21:58imirkin: the relevant famlies will be
21:58juri_: I'm just wondering what's working, and what will probably never work. I'm not someone using XOrg.
21:58imirkin: G80 - GT218
21:58imirkin: GF100-GF119
21:59imirkin: GK104 - GK107
21:59juri_: ok, neat. I can work with that.
21:59imirkin: GK110 - GK208
21:59imirkin: GM107 - GP10B
21:59imirkin: GV100 - TU117
21:59imirkin: GA100+ (i think has a new isa again)
22:00imirkin: of those, nouveau has support for everything but the first and last
22:00HdkR: Nah, GA has the same ISA as GV/TU
22:00juri_: yeah, i've got GF108, GF106, and GK107.
22:00skeggsb:sighs in relief
22:00imirkin: 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:00juri_: is there an entry point for this stuff, other than bugging you? :D
22:01HdkR: Just the scheduling has slightly changed if you want to maximize the dual issue support of GA
22:01imirkin: you can look at the compiler in mesa
22:01juri_: hmm. ok, i'll start poking around. thanks!
22:01imirkin: juri_: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/codegen
22:02imirkin: still not 100% sure what your goal is
22:02imirkin: but happy to answer nvidia hw-related questions
22:03juri_: write code, run it, get results? :D
22:03imirkin: hm ok
22:03imirkin: yeah, there's more to it
22:03RSpliet: 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:03juri_: preferably without starting XOrg, but. :D
22:03imirkin: that's not an issue
22:03imirkin: but you can do that today, with glsl compute
22:03imirkin: (for example)
22:03skeggsb: RSpliet: a bit of both :P
22:04juri_: imirkin: thanks for the pointers. i'll stop bugging you now. :D
22:05imirkin: 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:06imirkin: along with data to process, etc
22:07imirkin: there are a handful of ISA's which encode different instructions, but the instructions themselves are fairly similar across the GPU families (GF100+)
22:07imirkin: there are a few differences here and there of course
22:07imirkin: along with new features introduced in later generations
22:08imirkin: anyways, i'll bbiab. good luck. happy to answer questions you might have.
22:08RSpliet: 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:10RSpliet: Seems to me like there might be a more portable solution somewhere in that direction
22:52imirkin: oh i see. we never resize the tls.
22:53imirkin: and we dump it into CP_SCREEN
22:54imirkin: so all is well.