03:14imirkin: fincs: so can you get me info for that viewport_relative thing?
03:19imirkin: fincs: also, for the passthrough, how is gl_Layer handled? does it just emit it 3x? something else?
12:45fincs: imirkin: I haven't got around testing what viewport_relative does yet, sorry
12:45fincs: As for passthrough, from what I can tell it just codegens what's in the main function without any funny business (i.e. doesn't emit 3x)
12:58fincs: Register 0x47C0 seems to be viewport_relative (bool)
12:59fincs: Regardless of viewport_relative, passthrough gsh with only "gl_Layer = 42;" in its main function codegens to
12:59fincs: MOV R0, RZ ; MOV32I R1, 0x2a ; AST a[0x64], R1, R0 ; EXIT ;
13:00fincs: Looks easy
13:01fincs: Err not 0x47C0
13:01fincs: Register 0x11FC
13:01fincs: Err whoops I fail at math
13:01fincs: [0x47C] which is register 0x11F0
13:42orly_owl: is it possible to get audio out over hdmi on 80-10684 / 10684 / P684?
13:42orly_owl: with nouveau
15:15karolherbst: orly_owl: it should just work
15:15karolherbst: that's nothing nouveau need to support directly
15:16karolherbst: sometimes userspace is missconfigured though
15:16karolherbst: that HDMI stuff was always messy
15:50orly_owl: karolherbst: so audio over hdmi is handled by sound stuff like pulseaudio/alsa?
15:50orly_owl: seems logical
16:31orly_owl: alright thanks
16:40imirkin: fincs: yeah, i did some more reading on that passthrough ext, basically any varyings are broadcast to every vertex. so gl_Layer should work fine too.
16:41fincs: I hope what I posted is useful
16:41imirkin: fincs: ok, so 0x11FC is to enable viewport relative, and the shader binary itself doesn't give a shit, right?
16:41imirkin: and presumably viewport_relative is only a thing for gl_Layer?
16:41fincs: 0x11F0 (sorry)
16:41fincs: And yes, read the extension
16:46imirkin: fincs: yeah, i did a cursory read-through last night
16:46imirkin: before i had barely glanced at it
16:47imirkin: ok, and 0x11f0 = 1 / 0, right?
16:47imirkin: i'm going to do NV_viewport_array2 first coz that's a very small amount of glsl changes
16:48imirkin: passthrough will require more thought as to how to correctly implement it
16:48fincs: Yes, it's a bool reg
16:48imirkin: it's at least nice that they outlaw stuff like xfb and sso
16:48fincs: And yeah, even NV_viewport_array2 alone would be useful
16:48imirkin: since that would be a disaster to implement together...
16:49imirkin: still, i don't look forward to the linker changes
16:49imirkin: there's lots of "if gs, then everything is arrayed" type logic
16:49imirkin: perhaps it'd be cleaner to just create a new stage
16:49imirkin: and then you can optionally have GS or PGS in the program
17:09fincs: Nvidia calls it FastGS apparently
17:09fincs: So... maybe?
17:25imirkin: i guess SlightlyFasterGS wasn't pity enough?
17:54imirkin: useless. they add all the layer/viewport stuff to TCS, but that does exactly nothing =/
17:54imirkin: i'm thinking of skipping that
17:55fincs: Hmm, wdym?
17:57imirkin: not sure how to phrase it another way
17:57imirkin: what would writing gl_Layer in a TCS do?
17:58imirkin: other than annoy me, which it does quite admirably
17:59fincs: gl_Layer is writable in TCS, or is that only when NV_viewport_array2 is active?
17:59imirkin: forget extensions
17:59imirkin: let's say it's all always allowed
17:59imirkin: what would it have an effect on?
17:59imirkin: how would it be observable from anywhere in the render pipeline?
18:00imirkin: TCS just generates patches. those never go to the rasterizer.
18:00fincs: Writing to gl_Layer is intended to be used with cubemap rendering
18:00imirkin: i'm not talking about writing gl_Layer in theory
18:00imirkin: i'm talking about writing to it from TCS specifically
18:00imirkin: where would it go?
18:00imirkin: what would see that value?
18:01fincs: Fragment shader can read gl_Layer
18:01fincs: And well
18:01imirkin: however TCS never goes to fragment shader
18:01imirkin: TCS generates patches
18:01imirkin: which are then processed by the tessellator
18:01imirkin: and evaluated by the TES
18:01fincs: You can't have a TCS without having a TES
18:01imirkin: whose outputs can in turn be seen by the rasterizer and FS
18:01fincs: If you could write to gl_Layer from TCS, it would just set the layer for the primitive
18:02imirkin: which primitive?
18:02imirkin: TCS generates patches! :)
18:02fincs: The one the TCS is processing, in the same way that it's setting the tessellation levels
18:02fincs: Input prim that is
18:02imirkin: tess levels are inputs into the tessellator
18:02imirkin: TES can set a gl_Layer. if it doesn't, it's spec'd to be 0.
18:02imirkin: [pretty sure, at least]
18:03imirkin: [or undefined]
18:03fincs: If TCS wrote to gl_Layer, I'd expect it to set the layer for all primitives generated by the tessellator
18:03imirkin: now, there is _one_ spot where it can go ... with various NV exts, you can actually have a TES-less pipeline, and you could hook that up to XFB, adn read the gl_Layer value out with XFB
18:03imirkin: but that's the _only_ place it would show up afaik
18:04imirkin: and that seems like ... not that important of a use-case :)
18:04imirkin: note how ARB_shader_viewport_layer doesn't add gl_Layer/gl_ViewportIndex to TCS for the same reason
18:04fincs: Xfb as a whole seems to be unofficially "deprecated"
18:04imirkin: especially for weirdo pipelines that can't actually render anything
18:04fincs: You mean ARB_shader_viewport_layer_array?
18:05imirkin: i was close =]
18:05fincs: Apparently this extension adds it to VS and TES
18:05imirkin: and not TCS, for the reason i said -- it goes nowhere.
18:06imirkin: i'm just going to ignore that bit
18:06fincs: However in the NV extension
18:06fincs: "The gl_ViewportMask output is available in vertex, tessellation control, tessellation evaluation, and geometry shaders. gl_ViewportIndex and gl_Layer are also made available in all these shader stages."
18:07imirkin: yeah, they do add it. but say nothing about the additional functionaliy you're referring to.
18:07imirkin: of it being an input into the tessellator, etc
18:08fincs: I would assume setting gl_Layer in TCS would be the same as setting it in VS
18:08imirkin: setting it in VS when you have a TCS/TES/GS also does nothing.
18:08fincs: Ahhhhh I get what you mean now
18:08imirkin: but VS can be the last vertex stage before rast, so it makes sense
18:08imirkin: same with TES
18:08fincs: Because it only uses the last VTG stage to write to it
18:08imirkin: (and obviously GS)
18:08fincs: And you can't have TCS without TES
18:09fincs: Unless you have some xfb related bullshit apparently as you said?
18:09imirkin: i think in DX, TCS/TES are somehow combined in one mega-shader?
18:09fincs: No idea
18:09imirkin: so this probably doesn't come up, and someone was lazy at spec-writing. dunno.
18:09fincs: I have never looked at DX
18:11imirkin: ah ok
18:12fincs: Either way, it doesn't look like writing to gl_Layer is illegal in TCS, even though it's useless
18:13imirkin: hence me being annoyed.
18:13fincs: Nvidia seems to allow all sorts of stupid shit to happen though
18:24imirkin: that they do
18:28fincs: (Also, ThreadsPerInputPrimitive seems to be 1 for passthrough-gs)
18:28fincs: (probably same as regular gs, can't remember rn)
18:33fincs: StreamOutMask on the other hand only has the first one enabled (so, combined with the magic fastgs bit from before, 0x11000000 should be the first word of the shader header)
18:33fincs: (I mean the top 8 bits of the word of course)
18:37fincs: I think OutputTopologies (upper 4 bits of word) obeys the section "For the purposes of OpenGL API queries..." in the extension spec
18:38fincs: (err, lower 4 bits of upper byte of word)
18:38fincs: MaxOutputVertexCount is 1
19:04imirkin: yeah, makes sense.
20:32imirkin: all this shader linking stuff is such a disaster
20:32imirkin: been such a long time since i looked at it
20:32imirkin: so many cases to consider... SSO, multiple shaders of the same program type, etc
20:33fincs: I find the concept of shader linking itself really disgusting
20:33imirkin: yeah, but when you have eons of different use-cases piled on top of each other ...
20:33imirkin: makes for something that should be trivial end up actually really complex
20:34imirkin: i've lost a lot of context on the various mesa structures too
20:34imirkin: shader, linked shader, program
20:34imirkin: i sorta get it (again), but still not 100% like i was some years back
20:34fincs: It's a bit of a labyrinth
20:35imirkin: all this just to pass the stupid viewport_relative thing through
20:35imirkin: and like what if there are 2 GS shaders, and one delcares it with the attrib and another without
20:35imirkin: do i have to error?
20:36imirkin: yeah. probably. but that's a pile more work =]
20:36imirkin: although maybe not
20:36imirkin: we'll see.
22:11Lyude: karolherbst: jfyi-edp backlight working on nouveau (also-apparently modesetting was working with nouveau on the x1 after all)
22:32imirkin: fincs: lol, looks like redeclaring gl_Layer multiple times is just plain disallowed anyways
22:33imirkin: at least by the mesa compiler
22:34fincs: Personally, if someone thinks redeclaring gl_Layer multiple times in multiple shaders with incompatible qualifiers is sane, they should be legally banned from being anywhere near computers
22:38HdkR: This has to be why the GLSL spec says that the later stage's qualifiers override the previous stage's qualifiers :P
22:50imirkin: HdkR: same stage
22:50imirkin: multiple shaders
22:50imirkin: it's a thing
22:51HdkR: Oh right, I always forget that's a thing
22:52fincs: It shouldn't, really :p
22:52fincs: (much like spirv support in GL 4.6)^H^H^H^H^H^H
22:53RSpliet: Can't we just ditch OpenGL and start all over agai... oh
22:54fincs: Still kinda annoyed at how much stuff (that is natively supported by GPUs, especially Nvidia GPUs) was left out of Vulkan
22:55imirkin: well, that's half the battle.
22:55fincs: Nice :)
22:55fincs: So I supposed you had to make up a new tgsi property for that
22:56imirkin: that's not the hard part
22:56RSpliet: fincs: it either returns in some form, or a few HW generations from now it'll be cut in favour of adding even more FPUs in the same HW budget... or sth
22:56imirkin: the hard part is piping it all the way through
22:56imirkin: error: all gl_Layer redeclarations must have identical viewport_relative settings
22:56fincs: RSpliet: As long as legacy APIs (GL/D3D) live, hw will continue supporting this shit natively :p
22:56imirkin: and i even handled that bit :)
22:57fincs: imirkin: Good stuff :)
22:57fincs: I mean, I've been told Turing has native alpha test support
22:57RSpliet: fincs: why'd you think there's so many "DirectX over Vulkan", "GL over Vulkan", "GLES over Vulkan" projects?
22:57fincs: All of them with performance problems when legacy features are used because Vulkan doesn't expose them
22:58fincs: So at the end of the day you're better off with an actual native impl
22:59RSpliet: That's exactly the choice that hardware vendors will have to make: Is legacy software performance worth wasting transistors on?
22:59fincs: So far looks like the answer is yes :p
22:59fincs: (at least for Nvidia)
23:00fincs: Because after all, that makes people go "Look this old game from X years ago runs great on card A but terrible on card B! What a piece of shit card B is!"
23:01fincs: And popular games tend to be ones which can run even in a potato
23:01RSpliet: fincs: But that brand new Vulkan game that every site benchmarks runs a lot better on card B!!!
23:01RSpliet: I don't know, this might finally fuel some competition on the GPU market again ;-)
23:01fincs: Also, I still find it funny how so much of what you pass into Vulkan is basically "lol don't care" for Nvidia
23:02fincs: But I digress
23:03imirkin: fincs: all GPUs have native alpha test support... since like nv30
23:03imirkin: nv50 needs some help for non-blendable RT formats
23:03fincs: Nvidia seems to support it natively since like forever
23:03fincs: Not even dead in turing
23:04imirkin: why bother
23:04imirkin: just copy the block and move on
23:04imirkin: changing it takes effort
23:51karolherbst: Lyude: cool!