00:16 imirkin: with modesetting you're relying on the GL driver to be perfect
00:16 imirkin: the xf86-video-nouveau has no such dependencies
00:16 imirkin: it's very small, very controlled, very well-tested bit of code
00:54 dviola: I see
19:16 karolherbst: *sigh*, this took langer than it should have, at least I wrote all the code to at least nir in a upstreamable way, even if ut just fails to compile
19:17 karolherbst: but now the fun part starts
20:24 pmoreau: karolherbst: So, you got all the piping for passing NIR to Nouveau, I understand?
20:25 feep: yo
20:26 feep: playing factorio on a gt 645m and every time there's smoke onscreen it's a bit slow, I don't *think* this card should be slow when playing a not very complex 2d game? is this a known issue
20:26 feep: ... suspecting this is the wrong channel, but I don't know what the right one is.
20:29 pmoreau: feep: This channel is about Nouveau, so if you are using Nouveau rather than NVIDIA’s driver, this is the correct place.
20:30 pmoreau: Have you reclocked your card or not?
20:34 feep: yep, nouveau, and it's reclocked to max
20:34 feep: (albeit with light kernel patching)
20:34 feep: and it doesn't have a boost mode
20:34 feep: tbf this is with optimus and DRI_PRIME=1
20:39 feep: yep, fps drops by a factor of two when there's a lot of smoke onscreen
20:39 feep: I realize that alpha blending is slow but that's a bit much
20:43 feep: stats says this is with 9000 smoke sprites onscreen, but they're only about maybe 200x200 each
20:44 pmoreau: Even though performance counters have been reversed engineered, I don’t think we have a good way to debug performance issues yet.
20:46 feep: is there any other way I can figure out what's causing this?
20:47 pmoreau: You could make an apitrace of the game and add it to a bug report; if you add a save file, I could try playing it on my laptop which has a 750m (or on other cards).
20:49 feep: hm, I summed up the sprites and literally half the sprites onscreen are smoke
20:49 feep: so a factor two slowdown isn't implausible after all, sorry for the confusion
20:59 pmoreau: No worries. Even with reclocking, Nouveau does not achieve the same performance as the NVIDIA driver (though it can be close sometimes)>
21:02 karolherbst: pmoreau: yeah, check my nouveau_nir branch
21:02 feep: out of interest, what's limiting it?
21:03 karolherbst: feep: well, you could check how big the perf impact is with nvidia
21:03 karolherbst: various things
21:03 pmoreau: Most likely some missing compilation optimisations, and possibly some hardware features that are not exploited.
21:03 feep: yeah but the thought of going back to nvidia fills me with disgust and shame.
21:03 karolherbst: feep: just for testing I meant
21:04 karolherbst: sometimes some affects have a big impact on perf
21:04 karolherbst: even if it doesn't look like much
21:04 feep: from what I'm hearing in this case it's really just the fact that this game completely overkills its smoke budget
21:04 karolherbst: might be
21:05 karolherbst: today devs don't care much about perf in general, especially if it makes no difference for them
21:05 karolherbst: today they can just tell you to not use a crappy GPU :p
21:06 pmoreau: They have been doing a lot of optimising, but on the CPU-side mostly, as they are CPU bound by far!
21:06 feep: I mean... I am somewhat stuck on this gpu, being a laptop
21:06 feep: and yeah, the cpu optimizations in this game are insane
21:06 pmoreau: feep: Get rid of the burners/old furnaces and move to solar energy and electric furnaces! ;-)
21:07 feep: pmoreau: planning for nuclear, which won't exactly have this problem *less*.
21:08 pmoreau: Haven’t played since nuclear came out :-/
21:09 feep: wait for 0.16, it's coming out soon and it'll have fukken *CLIFFS*
21:09 pmoreau: I keep reading the FFF every Friday though.
21:09 feep: so hype
21:10 pmoreau: Yeah! And I completely agree that with the new terrain transition, you **need** animated water to go with it!
21:10 pmoreau: And the artillery train? I am not sure how much I would use it, but it looks damn cool. :-D
21:11 karolherbst1: pmoreau: I think I will have that nir_to_nvir pass pretty close to the TGSI and try to share some basic code between those. Not quite sure about it, but I think from a general point of view, those will be pretty much the same
21:12 pmoreau: Sounds good! I’ll continue working on a pull request for SPIRV-Tools.
21:14 karolherbst: pmoreau: I am even thinking about accepting tgsi and try a tgsi to nir to nvir compilation first and fallback to tgsi to nvir if something fails, just so that it might be easier to test what we already have there
21:15 karolherbst: but I think in the end we should just prefer TGSI, but accept both and be done with it
21:15 karolherbst: even if we prefer nir we sometimes get tgsi shaders
21:15 imirkin: i'd recommend avoiding trying to share too much code
21:16 imirkin: a ton of stuff is tgsi-specific in from_tgsi
21:16 karolherbst: imirkin: yeah I know
21:16 imirkin: in fact, almost all of it
21:16 karolherbst: but there is for example that subroutine tracking stuff
21:16 imirkin: the things that are generally useful tend to live in the build_util thing
21:16 imirkin: it was for tgsi subroutines, which btw never became a thing in general
21:17 imirkin: i believe it was done to support the never-finished d3d1x st
21:17 karolherbst: I see, I thought it would be used for functions in general as well, like if you have several functions inside a shader
21:17 karolherbst: or could be used for that as well
21:17 imirkin: (which in turn was way ahead of its time compare to the rest of the drivers)
21:17 imirkin: glsl inlines everything
21:18 karolherbst: well right, but I do that nir to nvir work not because of glsl
21:18 karolherbst: and I still want to be open about certain features anyway. If it isn't used, then it could be removed anyway
22:10 karolherbst: okay, so nir is much more function based than TGSI is
22:48 imirkin: karolherbst: not really
22:49 imirkin: still all one big happy function at the endo f the day
22:49 karolherbst: well, you have to deal with it while using the nir API
22:49 imirkin: right
22:49 karolherbst: vc4 for example asserts on the name being "main", so there is that
22:49 imirkin: exactly.
22:49 karolherbst: but you still have to kind of deal with it, that
22:49 karolherbst: 's what I mean
22:50 imirkin: ok
22:50 karolherbst: and nir is stricter typed than TGSI
22:50 karolherbst: there are even structs for each type of instructions
22:50 imirkin: i'm familiar with it.
22:50 karolherbst: and you basically have to switch over everything->type and so on
22:50 karolherbst: k
22:51 imirkin: i've interacted with nir via freedreno
22:51 karolherbst: ahh, I see
22:57 imirkin: it's got some good concepts
22:57 imirkin: the whole validation thing is a pretty good idea
22:57 imirkin: that way there's no question over "is this legal or not" kind of thing
23:00 karolherbst: yeah, that should make things easier in using it
23:00 karolherbst: I suppose nir can't be converted into a form where you don't have multiple components per def?
23:05 imirkin: there's a scalarize pass
23:05 imirkin: obviously something like tex will still have 4 defs
23:05 karolherbst: mhh, interesting
23:06 karolherbst: this would make things a bit more easier for us
23:08 karolherbst: there is nir_lower_alu_to_scalar and nir_lower_phis_to_scalar
23:09 karolherbst: mhh, well
23:09 karolherbst: we need to support both anyway
23:15 karolherbst: wow nice, it works :)
23:15 karolherbst: but now the output is rather silly
23:16 karolherbst: I guess we want some nir opts so that we kill those vector things
23:16 imirkin: why? nouveau should be able to opt everything out
23:18 karolherbst: I show you the code
23:18 karolherbst: https://gist.githubusercontent.com/karolherbst/806b468d28d452725da653f7596aa907/raw/d2b4d959466502732fdee70a3d468642fed71042/gistfile1.txt
23:19 karolherbst: I mean what is the point of wanting scalar things if the original stuff still stays being some vectors
23:20 karolherbst: I only plan to enable those opts/passes which make live easier for us, not to move opts into nir
23:21 karolherbst: now it is much better :) no vector things
23:25 karolherbst: so here is what I've enabled: regs_to_ssa (seems like we need this anyway), *_to_scalar, copy_prop (to move those vector components into the scalar values), dce
23:25 karolherbst: and from_ssa
23:36 karolherbst: I think we may remove that later if we see we don't need it, but for now it should make things easier to get starting