12:14Nopraz: Hello, i am new in the nouveau IRC and i did the piglit test on my GPU with Nouveau.
12:14Nopraz: To who i need to send my results ?
12:14Nopraz: Thank you in advance ! 😁
12:14Nopraz: Sorry for the bad english i'm french
14:29imirkin: Nopraz: we don't really collect piglit results anymore
14:54Nopraz: Oh, okay np
14:55Nopraz: I wanted to contribute to the project , how can i do that ?
14:56RSpliet: Nopraz: thanks, that's much appreciated! I think the first question is: do you have any problems with using your NVIDIA graphics card (which one?) on nouveau?
14:58RSpliet: And the second question would be: do you have the skills to fix them yourself (with some guidance), or do you consider yourself mainly a user? Don't worry either way, bug reports are valuable too :-)
15:07Nopraz: Actually no i don't have problems on my GPU which is a GTX 1070 Ti, the only problems that i have are performance-wise in games but i think thats normal (3d performance are incomparable with nvidia proprietary drivers), i'm just a user who wants to see nouveau becoming better and better, thats why i wanted to do the test with piglit.
15:07Nopraz: What i am glad is that Nouveau with wayland manages way better the fact that i have two different monitors with different frequencies on GNOME. Also KDE/Plasma suffers from the Nvidia proprietary drivers because of their different way of doing things (I think?).
16:42RSpliet: Nopraz: the unfortunate thing is that there's little we can do about the performance thing. The single biggest factor holding nouveau back is voltage/frequency scaling, for which we'd need firmware that's cryptographically signed by NVIDIA. They're not releasing that, nor would they sign ours.
16:59raket: RSpliet: What about the Kepler cards? are they open documentation?
17:21Nopraz: RSpliet i didn't know about the voltage/frequency scaling, thats disappointing from Nvidia.
17:21Nopraz: I mean, AMD just clearly released open source drivers and they are pretty good (at least thats what i heard).
17:22RSpliet: raket: for Kepler and older we implemented our own firmwares to perform these tasks.
17:23RSpliet: It's all manual, nobody's looking at it at the moment
17:23RSpliet: But it largely works on Kepler
18:19imirkin: Nopraz: as an end user, the best thing you can do for nouveau is report issues that you run into
19:26shadow: Nopraz: regarding AMD the RX580 (Polaris) is solid although some issues with passthrough to VM's, and the new favorite seems to be RX5500 / RX5600 / RX5700 which just has a hardware bug with reset but otherwise is said to work great with VM passthru
19:26imirkin: yeah, i mean, the other thing you can do as an end user is stop giving NVIDIA money and perhaps they'll change their policies
19:30RSpliet: ^ that, although your mileage may vary. Linux-users that _insist_ on open-source drivers yet require the performance of a discrete GPU are a bit of a niche...
19:37RSpliet: But at least you'll get what you want in the meanwhile, even though there's AMD printed on the heat dissipator rather than NVIDIA :-)
19:37imirkin: just get a marker and fix it :)
21:09karolherbst: imirkin: right now trying to get my head around on how we cound inputs... I see that there are 32 generic inputs for vertex shaders and I assume we support 32 ones for doubles as well? Meaning each double input also takes just one slot?
21:10raket: Lyude: any progress on the GK110 issue with >120hz? The 2k monitor really change to 144hz (and it even changes to 165hz) but nothing is displayed.
21:10karolherbst: uhhh.. now I see
21:10karolherbst: there are 32 varyings, but only 16 vertex atribs being "generic"
21:11karolherbst: but still.. a dvec4 would take one full attrib not two, right?
21:11imirkin: karolherbst: in glsl or in tgsi?
21:11imirkin: it's SUPER confusing
21:12karolherbst: I know
21:12imirkin: so here's the thing
21:12karolherbst: and it's broken with nir, that's why I am trying to fix it
21:12imirkin: for VS inputs
21:12karolherbst: gallium seems to try to fix something
21:12imirkin: there are "locations" and "attribute counts"
21:12imirkin: so a dvec4 takes up a single "glsl location"
21:12imirkin: but it would count as 2 attributes
21:12karolherbst: this is what I get.. and also shows what the test tries to do
21:13imirkin: so when you say "i support 16 attributes"
21:13imirkin: that means 8 dvec4's :)
21:13karolherbst: that's... well... confusing :D
21:13imirkin: yes, very
21:13imirkin: so that's why the "count inputs" thing takes the stage
21:14imirkin: anyways, this is all normalized in tgsi
21:14imirkin: whereby a dvec4 will get decomposed into 2 inputs
21:14imirkin: i _assume_ something like that exists for nir, but i don't know tbh
21:15karolherbst: the problem is just.. gallium is doing the weird stuff.. so probably I just need to fix some weirdo cap
21:17imirkin: this all works fine for nouveau
21:17karolherbst: yeah.. it used to even with nir :p
21:17imirkin: oh, this is with nir? yeah, you might be missing a step. dunno.
21:17imirkin: or have one step too many ;)
21:18karolherbst: so... wha's happening is that a dvec3 takes up 4 slots
21:18karolherbst: I think..
21:18karolherbst: I can't dump the vs because gdb is dumb
21:18imirkin: dvec3 should take up 2 slots
21:18karolherbst: how can I print the full string in gdb?
21:19imirkin: print the-string?
21:19karolherbst: a char* value
21:19karolherbst: gdb cuts it off...
21:19imirkin: with "print"? hm
21:19imirkin: "help print"
21:19imirkin: there might be a /full switch or something
21:20karolherbst: p -elements unlimited -- vs
21:21karolherbst: layout (location = first_input_location) in dmat2x3 in_vs_first;
21:21karolherbst: layout (location = last_input_location) in dmat2x3 in_vs_last;
21:21karolherbst: soo.. 4 slots is actually correct
21:22karolherbst: first_input_location is 0 and last_input_location is 14
21:22karolherbst: and... the 14 gets turned into a 28
21:22karolherbst: so the in_vs_last ends up taking an invalid attrib slot
21:25karolherbst: ehh.. in TGSI it seems like the explicit location is ignored
21:25karolherbst: so 0-7 are getting used
21:26karolherbst: which might not even be a bad idea in general...
21:26karolherbst: still odd
21:27karolherbst: or.. maybe that's... just overflowing in a weird way
21:29imirkin: karolherbst: it's all pretty confusing :)
21:29imirkin: thanks to airlied for figuring it all out
21:29imirkin: i even sorta understood it back when i reviewed it
21:29imirkin: but that was many years ago
21:34karolherbst: okay.. seems like at leas the glsl ir is fine...
21:34karolherbst: (declare (location=16 shader_in ) dmat2x3 in_vs_first)
21:34karolherbst: (declare (location=30 shader_in ) dmat2x3 in_vs_last)
21:34imirkin: those glsl locations have various offsets built into them too
21:35imirkin: so you can't compare it 1:1 to gallium input locations
21:35karolherbst: I know
21:35karolherbst: 16 is GENERIC0
21:35karolherbst: and 30 is GENERIC14
21:35karolherbst: so that's fine
21:35karolherbst: now I am wondering why this turns to 0 and 4 for TGSI and 0 and 28 for nir :)
21:36karolherbst: which... both doesn't sound correct imho
21:36karolherbst: but I guess the runtime fixes it up so the driver deals with it
21:36karolherbst: for TGSI at least
21:36imirkin: there's a function that maps glsl inputs to tgsi inputs somwhere
21:36imirkin: to semantic,index
21:37karolherbst: but then you would have 0 and 14 still
21:37karolherbst: I wrote the TGSI to GLSL ones :p (or at least some of them)
21:38karolherbst: uhm.. wait
21:38karolherbst: actually MESA to TGSI.. this way
21:39karolherbst: I think there is something more "smart" going one
21:42karolherbst: st_prepare_vertex_program looks like to be the place
21:44imirkin: you're on your own for the nir stuff =]
21:45karolherbst: yeah... uff... I think we have a debug there with TGSI though.. but it never shows because we ... don't care about the actual vertex attrib type
21:46karolherbst: and with TGSI that might not even matter
21:46imirkin: yeah, attribs are typeless
21:46imirkin: as far as the shader is concerned
21:46karolherbst: okay.. so with TGSI the attribs always start at 0
21:47karolherbst: and and just continue until all inputs are handled without having any gaps
21:47imirkin: yeah, of course
21:47imirkin: well, no attrib slot gaps
21:47imirkin: there could be individual components which are unused
21:48karolherbst: okay.. at least I understand the problem now
21:49imirkin: the problem is that you've decided to mess with GL. the solution is to go enjoy the beach.
21:54RSpliet: Ahh yes, those famous beaches of Germany
21:55RSpliet: Also known as "the Netherlands"
21:55karolherbst: ahh.. okay, found a nir which is still fine:
21:55karolherbst: decl_var shader_in INTERP_MODE_NONE dmat2x3 in_vs_first (VERT_ATTRIB_GENERIC0.abcdef, 0, 0)
21:55karolherbst: decl_var shader_in INTERP_MODE_NONE dmat2x3 in_vs_last (VERT_ATTRIB_GENERIC14.abcdef, 0, 0)
21:55karolherbst: imirkin: anyway, thanks for the help.. I am still fuzy on most of the actual GL stuff
21:55imirkin: RSpliet: on the north, no?
21:55RSpliet: imirkin: I know, I'm trolling. Although it's always a bit chilly up north I reckon
21:56karolherbst: RSpliet: from where I come from, that's part of the "south" already :p
21:56imirkin: i went to the baltics as a child ... that's even further north than germany
21:56imirkin: should be ok in summer
22:10karolherbst: ahhh.. "nir_remap_dual_slot_attributes" yeah..
22:10karolherbst: should have cought that before
22:15karolherbst: ahhh... it's broken with iris as well
22:16imirkin: well, i think tests pass on iris
22:16imirkin: so careful with that assumption
22:17karolherbst: I know
22:17karolherbst: but nouveau also crashes for a stupid reason
22:17karolherbst: crashes inside vert_attrib_to_tgsi_semantic
22:17karolherbst: and we don't care about the semantic anyway I guess...
22:18imirkin: yeah, vs inputs don't have semantics
22:18karolherbst: just thinking about how to keep nouveau happen...
22:18karolherbst: maybe I just ignore setting those at all
22:19karolherbst: I still need to handle TGSI_SEMANTIC_EDGEFLAG
22:19karolherbst: but I can check against the MESA enum value as well
22:19imirkin: skip it
22:19imirkin: it does nothing for nouveau
22:19karolherbst: tells me otherwise
22:20karolherbst: we derive the location from the semantic
22:20karolherbst: and index
22:20imirkin: edgeflag inputs aren't supported
22:20imirkin: we do use the presence of the edgeflag attribute to know if we need to do the edgeflag workaround logic
22:20karolherbst: that's what I meant ;)
22:20imirkin: which basically manually scans the values of that attribute and breaks it up into draws
22:21imirkin: but the shader itself couldn't care less.
22:21karolherbst: setting info->io.edgeFlagIn
22:22karolherbst: ufff.. this issue is just so annoying
22:24karolherbst: and even 14 as the last location is just plain wrong
22:25karolherbst: well.. except you treat dvec4 as only taking one slot
22:25imirkin: nouveau doesn't even know about dvec4's
22:26karolherbst: that's fundamentally broken on a glsl level :p
22:26karolherbst: how can you have 16 dvec4 vertex attribs?
22:26karolherbst: or is that like supported?
22:27imirkin: it is not
22:27imirkin: but glsl allows for this
22:27imirkin: since vs in attribute slot
22:27karolherbst: so.. but because the application uses 14 for a mat2x3 we spread it across slots [14:17]
22:27imirkin: can take up multiple "real" attributes
22:28imirkin: however you can totally have
22:28karolherbst: and 16 and 17 simply don't exist
22:28imirkin: (location=0) dvec4 foo
22:28imirkin: (location=1) dvec4 bar;
22:28imirkin: and that's legal
22:28imirkin: and it has to do with the ID's that are passed into glBindAttributeLocation or whatever
22:28imirkin: not to do with the literal shader input layout
22:29imirkin: so just has to be done a bit carefully
22:29karolherbst: so we essentially should just do the same what happens with tgsi and simply start counting from 0 and move on
22:38imirkin: dunno how nir works, might not make the most sense
22:40karolherbst: well.. right now it's broken :p
22:41karolherbst: decl_var shader_in INTERP_MODE_NONE dvec3 in_vs_first (VERT_ATTRIB_GENERIC0.xyz, 0, 0)
22:41karolherbst: decl_var shader_in INTERP_MODE_NONE dvec3 in_vs_first@0 (VERT_ATTRIB_GENERIC2.xyz, 2, 0)
22:41karolherbst: decl_var shader_in INTERP_MODE_NONE dvec3 in_vs_last (UNKNOWN.xyz, 4, 0)
22:41karolherbst: decl_var shader_in INTERP_MODE_NONE dvec3 in_vs_last@1 (UNKNOWN.xyz, 6, 0)
22:41karolherbst: but.. maybe it simply doesn't matter
22:41karolherbst: the number shows the actual driver_location
22:41karolherbst: maybe... I can just use that and handle the special types differently
22:51karolherbst: imirkin: uff.. I have a dirty hack.. I check if the attrib is >= GENERIC0 and rebase with the real location and then I am fine...
22:51karolherbst: I find this hack ugly.. but ufff
22:52karolherbst: anyway.. bed time :p