10:45 karolherbst: mhh mhh jatson nano for CI...
10:45 karolherbst: *jetson
14:09 RSpliet: https://hastebin.com/cepunuzoxa.cs
14:09 RSpliet: That TTM "available graphics memory" line sounds a bit... bogus
14:09 RSpliet: [ 9.339507] [TTM] Zone kernel: Available graphics memory: 1664116 kiB
14:10 RSpliet: 0x6591D000 bytes? Could we be printing (using?) a non-initialised value?
14:13 RSpliet: Oh... it's just short of being generated by a RNG anyway, never mind.
14:14 RSpliet: totalram - totalhigh >> 1 (so limited to half the... what portion of my RAM? Anyway, whatever, it probs means nothing)
14:30 karolherbst: RSpliet: isn't it like limited by the mtrr entries?
14:30 karolherbst: or well whatever pte decides to do?
15:01 RSpliet: karolherbst: I don't dare to say. Old code that google came up with looks like it just grabs some random sysinfo RAM parameters and calculates a limit based on that. Didn't give it a closer look. Just found it an odd number and the combination with an ION IGP always makes me a little fidgetty. Consider these observations entropy ;-)
15:02 RSpliet: of course, when I say odd, I mean "even, but weird" :-D
19:11 ReinUsesLisp: if I want to inject custom shaders into nouveau (without modifying it), can I use program binaries? I don't care if the format may change in the future
19:15 HdkR: Does Nouveau even support program binaries?
19:20 HdkR: Isn't it only i965 or radeonsi that supports program_binary directly?
19:21 ReinUsesLisp: I mean glProgramBinary, unless it's stubbed
19:22 HdkR: That's exactly what I mean
19:22 HdkR: There is a loop hole in the extension spec that allows you to implement it fully but return 0 supported binary formats
19:22 HdkR: Which Apple took advantage of as well
19:23 ReinUsesLisp: good thing we use DSA to drop macOS :P
19:25 ReinUsesLisp: I guess I'll have to apply those patches on nouveau for Switch
19:27 HdkR: patches?
19:27 karolherbst: ReinUsesLisp: I think frameretrace might be the best option here
19:28 karolherbst: ohh, you mean you really want to do that inside the application?
19:28 ReinUsesLisp: yup
19:28 karolherbst: ReinUsesLisp: if you use the NIR path, you can use glProgramBinary I think
19:28 karolherbst: but you have to provide a NIR as a binary
19:29 karolherbst: but.. I guess if somebody is motivated enough, we could write up our IR as well
19:29 ReinUsesLisp: HdkR: there are two (iirc) patches that let you dump + inject shaders
19:29 karolherbst: or sass
19:29 HdkR: karolherbst: Yea, any reason not to emit both NIR and sass?
19:29 karolherbst: HdkR: there is no code for it
19:29 karolherbst: we need to come up with some header and stuff
19:29 karolherbst: we just didn't bother enough
19:29 HdkR: ah, so work :D
19:30 karolherbst: maybe the shader cache could work?
19:30 karolherbst: we could make a cold cache or something
19:30 karolherbst: dunno
19:30 karolherbst: anyway, it needs application support
19:30 karolherbst: or an offline compiler
19:30 karolherbst: otherwise all that is super useless
19:30 ReinUsesLisp: what I want to do is to be able to use a hand-written shader in an application
19:31 ReinUsesLisp: I want to use it for unit testing, dumping the results through ST.G
19:31 HdkR: Yea, if Nouveau's program_binary implementation supported sass in the returned binary then it seems reasonable to know how to inject in to it from someone toying :
19:31 HdkR: :P
19:32 karolherbst: ReinUsesLisp: I think then you are better of not targeting gl anyway
19:32 ReinUsesLisp: I would use NVN if I could :P
19:35 ReinUsesLisp: karolherbst: a "hardcoded" (I don't know how to call it) application is good idea, I guess I'll try going for that one - thanks
19:35 karolherbst: ReinUsesLisp: mhh, maybe CL could be of help here. It's possible to use clover witout llvm at all and you could provide a kernel spir-v to do stuff
19:35 karolherbst: or.. just talk with the driver directly ;)
19:35 karolherbst: less pain.. more code
19:35 karolherbst: mwk might have some skeleton for that
19:35 karolherbst: but he only use it for pre nv40 hardware afaik
19:35 ReinUsesLisp: I need it to run on a Switch anyways
19:36 ReinUsesLisp: Horizon might be lighter on the kernel space than Linux
19:38 ReinUsesLisp: thankfully I have a good offline compiler :P
23:42 imirkin: HdkR: fyi, nouveau presently supports program_binary just fine
23:42 imirkin: it should be moderately easy to use program_binary to replace a single instruction in a pre-analyzed shader
23:43 imirkin: looks like ReinUsesLisp left ... oh well. feel free to pass it on.
23:43 karolherbst: imirkin: but we only have the MESA format which is a binary NIR, no?
23:44 imirkin: it's a binary with glsl ir, tgsi, and a nouveau-supplied blob
23:44 karolherbst: ohh, interesting
23:44 imirkin: you'd have zero chance to create one by hand
23:44 imirkin: but modifying a "good" one should be easy
23:44 HdkR: imirkin: Ah! Good to know. I didn't realize Nouveau support for it was here as well :)
23:45 imirkin: (ok, i'm like only 99% sure about that ... almost certain that it all good hooked up, but now you guys are making me question my memory)
23:45 imirkin: even if it's not hooked up, should be easy to do so
23:45 karolherbst: I thought we only wired up nir for GL_ARB_get_program_binary
23:45 karolherbst: since we report 0 or 1 supported formats
23:45 karolherbst: where 1 being some NIR dump
23:46 karolherbst: imirkin: the issue is, if we define a new binary format, we also have to define a new GL extension defining that format
23:46 karolherbst: like we have GL_MESA_program_binary_formats for mesa right now
23:46 imirkin: nah, definitely not only nir
23:46 karolherbst: here was the initial support added: https://lists.freedesktop.org/archives/mesa-dev/2017-November/176095.html
23:47 imirkin: ok
23:47 karolherbst: it might be that somebody wired some gallium stuff on top of that though
23:47 karolherbst: I didn't really follow
23:47 imirkin: iirc it's all part of the shader cache
23:47 imirkin: same mechanism
23:47 karolherbst: yeah.. might be
23:47 karolherbst: I think only nir for i965 was wired up, but maybe we have support for more now
23:47 imirkin: originally, sure
23:48 imirkin: but that was ages ago
23:48 imirkin: iirc tarceri did the add-on work
23:48 karolherbst: well, last year
23:48 karolherbst: uhm
23:48 karolherbst: 1.5 years
23:48 imirkin: time flies.
23:48 karolherbst: ahh
23:48 karolherbst: okay
23:48 imirkin: let's see if i can find it...
23:49 imirkin: check the end of st_context.c
23:50 imirkin: hmmmmmmmmmm
23:50 imirkin: looks like only the TGSI is serialized
23:50 imirkin: not the final program blob :(
23:50 imirkin: that's rather surprising
23:51 karolherbst: well, it's good enough
23:51 karolherbst: and works for every driver
23:51 imirkin: not good enough for what that guy wanted
23:51 karolherbst: right
23:51 imirkin: i was SURE there was something to cache compilation results.
23:51 imirkin: but ... apparently i was mistaken.
23:51 imirkin: or it was propsed but never merged
23:51 imirkin: my bad :(
23:52 karolherbst: I mean, we could hook it up, but it's hard to make it work cross drivers..., which already doesn't work that well anyway I think
23:52 imirkin: could encode driver in there
23:52 imirkin: there's always fallbacks to recompile
23:52 imirkin: for various reasons
23:52 karolherbst: but yeah, we could write our own format and export our shaders or so
23:52 imirkin: like relinking, etc. at least for the cache
23:52 karolherbst: well the TGSI isn't really portable either :/
23:52 imirkin: exactly
23:52 imirkin: different driver options, etc
23:54 imirkin: shouldn't be hard to implement, basically ahve to serialize the program state object (with a driver hook). shouldn't be difficult in practice.
23:55 imirkin: anyways, i'm out. just came in to comment on the program binary situation