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