00:52koz_: Is it normal to have a GPU temp of 60C?
00:53koz_: It seems a bit high.
00:54koz_: (it's not under load right now, unless running KDE is 'under load')
00:54imirkin: depends on the gpu
00:54imirkin: that's not crazy though
00:54koz_: imirkin: GeForce GTX 680.
00:54koz_: (I'm running it on boost 2 and 0f pstate)
00:55imirkin: ah yeah, definitely normal
00:55imirkin: i think we clock it to highest core clock possible
00:55koz_: Ah, I see.
00:55koz_: It must be burning power like mad, then.
00:56imirkin: (not dynamic yet)
00:56karolherbst: well, not the highest one though
00:56koz_: Does it also mean that it won't go up if I put it under load?
00:56karolherbst: we still just assume 95°C for now
00:56koz_: karolherbst: You can go higher than 0f?
00:56karolherbst: no, but depending on the temperature higher clocks can be used
00:56koz_: Ah, so I'm guessing that's overclock territory?
00:57karolherbst: the difference is rather small and should be ~40MHz at most
00:57karolherbst: overclocking is if you ignore the vbios
00:57karolherbst: we do honor what the vbios tells us
00:57koz_: Ah, I see.
00:57karolherbst: and 60°C is quite low
00:57koz_: What's considered a normal operating temp under load, then?
00:58karolherbst: the highest you should actually run your GPU on is round about 95°C on kepler
00:58karolherbst: then the driver should take some actions against that temperature
00:58karolherbst: there is a table in the vbios which is telling the driver when to throttle and when to stop
00:58karolherbst: and the "usual" throttle range is around 90°C-95°C
00:59koz_: OK, that's a relief - I was wondering if my system was under-cooled.
00:59karolherbst: koz_: well, intel CPUs boost until 100°C
00:59koz_: karolherbst: My CPU is currently doing 30 or so.
00:59karolherbst: ivybridge I think was even boosting to 105
00:59supermart: listen guys when all the banlist are fill with my entrus, it may cause some troubles in two ways , and both of them involve me, one is that i get directely treated again, there have not been too many success stories yet though say with successuful assaults on the streets
01:00supermart: but the other way could be the other way that you get into troubles and i get blamed for it, if i promise no longer to evade bans, can you empty the rich banlist, and lets finish it off friendly in public.
01:02supermart: i am sorry, i tried my best, and outcome some bended carrots , sometimes
01:03supermart: however sometimes i was able to understand what i meant, but no one oether was, due to quite
01:03supermart: some inchorent style of speaking
01:04koz_: karolherbst: OK, put under stress, my GPU hits ~75.
01:05koz_: (and by 'stress' I mean 'a workload that it can't even hit 60fps on')
01:05koz_: (damn those 512 Minetest textures)
01:08supermart: i knocked myself out with a sleeping pill called innovane now, so c ya, i think i am able to the code, on nouveau and readeon, but for some reason it looked ike you did not want a proper cheduling in low power mode
01:10supermart: i was into details this week and would need to discuss sometimes later if i still my end up giving the algorithm to open source, pointlessly easy stuff btw.
01:12supermart: but i need to sleep, i would want to merge this to smartphones too, like into the code of freedreno, will but i don't know if for free
01:12supermart: those three i have inspected, that it is possible for all of them
01:13supermart: i think it is also possible on all other chips, lika vivante or vc4 and stuff
01:14supermart: but i have couple of persons chill to shat with to decide what to do and how, lets just do that i come back after month when i have code
01:15supermart: i mean and if by then i decide to give it out free, which could be more sane
01:16supermart: i apoligsed in front of mannerov, cause in radeon work i crititized in unjustiyingy and found a usecase where on GL_POINT multipass and non multipass sometimes would still need mannerovs scheduler
01:16koz_: Welp, I finally bit the bullet and decided to report the perf problems to the Minetest team.
01:17koz_:braces for an avalanche of 'use nvidia driver [INSERT DEROGATORY TERM HERE]'.
01:20supermart: so basically sisched style of instruction ordering can be mixed with my solution, and i don't think it is wise to remove it later, allthough i can see soluyion on primitive other then GL_POINT i could to withouts mannerov reordering
01:38imirkin: koz_: what does minetest need for better perf, do you know?
01:39koz_: imirkin: I have no idea.
01:39imirkin: ah =/
01:39koz_: I'm not knowledgeable about drivers, OpenGL, or basically much at that level at all.
01:39koz_: I figured bringing it to the attention of the maintainers might at least give me a direction to feed data to.
01:40koz_: My complete-stab-in-the-dark guess is that it's an Irrlicht problem, but if that's the case, I need something more concrete to bring to them.
01:41koz_: And maybe the nice people behind Minetest can tell me what kind of data they'd want.
01:48imirkin: do you knwo if it makes use of bindless textures?
01:49koz_: imirkin: I don't even know what that means.
01:52koz_: Would that make a difference?
01:53imirkin: it could, if they use the feature
01:53imirkin: makes no difference if they don't
01:53imirkin: we don't currently expose it, but i have patches. those patches tend to crash a bunch of applications though
01:55koz_: I could ask?
01:56koz_: (I assume that's an engine-level thing?)
01:56koz_: (or rather, the engine is where such decisions would be made)
04:53orbea: koz_: irrlicht is just the 2d backend I thought
04:53orbea: the 3d should all be in the minetest engine?
04:54koz_: orbea: I'm not sure how that could possibly work. Irrlicht is a 3D engine last I heard.
04:54koz_: (although frankly I have no idea)
04:54koz_: (so you might be right)
04:55orbea: i might be wrong :P
04:56koz_: orbea: Something about the blind leading the blind may be appropriate here. :P
05:01orbea: yea, im just wrong...
05:01koz_: orbea: It's fine - I wanna hear back from the Minetest devs anyway. Hopefully they'll be receptive.
05:02koz_: (last time I asked about graphical issues with Nouveau, I got 'use nvidia n00b' as a response)
05:02koz_: s/nvidia/proprietary driver/
06:03imirkin: still end up with https://hastebin.com/ocogocugar.hs for the "load constbuf" change
06:03imirkin: stupid scheduling
07:11karolherbst: imirkin: well in long or mid term I will most likely work on scheduling, because we will need that for compute anyway sooner or later (allthough sooner or later is a question about 1 or more years)
14:00zukunf: what's the state of AA in nouveau? Is is optimized? Is it finished?
14:00zukunf: the game did work but massive slow down.
14:01zukunf: A ppsspp option.
15:33Aristar: hmm, is there a reason nouveau might try and load nv84 firmware on a nv86 chip even tho nv86_* stuff is present?
15:35Aristar: Direct firmware load for nouveau/nv84_xuc00f failed with error -2 \ vp: unable to load firmware nouveau/nv84_xuc00f \ Direct firmware load for nouveau/nv84_xuc103 failed with error -2 \ bsp: unable to load firmware nouveau/nv84_xuc103
15:35Aristar: 01:00.0 VGA compatible controller: NVIDIA Corporation G86M [GeForce 8400M GS] (rev a1)
15:47zukunf: Aristar: since when that card requires firmware?
15:48Aristar: zukunf: it's not upstream in kernel-firmware, was pulled from nv binary, but nouveau wiki says it needs firmware for power management and for video decode, IIRC
15:48Aristar: so i dumped the firmware to /lib/firmware/nouveau
15:49zukunf: Aristar: remove the unnecessary firmware to see what happens.
15:50Aristar: yeah that's not a bad idea
15:50Aristar: zukunf: this is the list of firmware i dumped if it helps http://sprunge.us/iTRP
15:51Aristar: unsure exactly wihch ones are related to nv86 only since some are weird names
15:52Aristar: although i guess stuff with 86 in the name can rule out anything similarly named without 86
15:53Aristar: also, the wiki page didn't seem to show instructions on how to load nouveau firmware on kernel cmdline or some such, and this isn't auto loaded until something attempts to use video decode, which means the bits for power management also aren't being loaded
15:54Aristar: and my firmwares aren't listed in `modinfo nouvea`so i assume it needs a specific argument to instruct it
15:54Aristar: (only the upstream kernel-firmware stuff)
15:58Aristar: hmm seems nv86_* -> nv84_* anyways
15:58Aristar: but still would like to know if there's a way to instruct nouveau to direct load certain firmware on boot
15:58Aristar: (ones that aren't listed in modinfo)
16:18mwk: Aristar: nv86 only needs video decode firmware
16:18mwk: and it's identical to nv84 video firmware, so nouveau just pulls nv84_* files
16:36imirkin: Aristar: nope. we could add the MODULE_FIRMWARE stuff -- but it's not an error not to have it, so i don't know if that's appropriate.
16:36imirkin: Aristar: i suppose we could also "optimistically" load that firmware
16:51tobijk: imirkin: can i get you to push this one: https://git.thm.de/tjkl80/mesa/commit/b0b1531447fa3d795c284e75675fbb2987c6cb96 ?
16:51tobijk: i wanted it to have it comit with your patch series, but you commited it already :/
17:01imirkin: tobijk: PrintPass(bool omitLineNum = false)
17:01imirkin: is this needed?
17:01imirkin: yes, it is.
17:01imirkin: hmmm... i wonder where Function::print gets called
17:02tobijk: imirkin: somewhere in the nv50 backend if i remember right
17:03imirkin: i just removed it, will see what complains ;)
17:03imirkin: aha, nv50_ir_ra
17:04imirkin: so ... ostensibly, that should get the same setting passed in, no?
17:04tobijk: mh it did not interfer with what i wanted to reach
17:05tobijk: but yeah if "info" is around we can just pass it
17:09imirkin: and then you can get rid of the default value on the PrintPass constructor arg
17:09imirkin: (which is ultimately the thing that rubs me the wrong way)
17:10tobijk: imirkin: yeah if that is the single last caller, np
17:13imirkin: urgh. i'm still annoyed that my little hacks haven't helped the "load constbuf" thing to actually prevail over the existing approach.
17:14tobijk: yeah, slow me
17:14imirkin: it does help instructions more, but i don't want to push it coz of the gpr's thing
17:15imirkin: and the overall changes are so very tiny that it doesn't *really* matter anyways
17:16imirkin: the ones i pushed out yesterday were pretty obvious wins
17:16tobijk: imirkin: yup
17:17tobijk: imirkin: but if the gpr regressions are not clustered in a small number of shaders it is fine imho
17:17imirkin: mwk: any idea what the hit is for loading a constbuf value that has already been loaded earlier in the shader?
17:18imirkin: tobijk: https://hastebin.com/egunanobuc.hs
17:19imirkin: most are single GPR changes, but the shadow-of-mordor ones are pretty huge.
17:19imirkin: i should probably look at those
17:19imirkin: not now though
17:22tobijk: imirkin: yeah the shadow of mordor changes are a bit much to take :/
17:23imirkin: of course on instructions helped, shadow-of-mordor also comes up, but on diff shaders
17:29tobijk: imirkin: https://git.thm.de/tjkl80/mesa/commit/5028f54cd3811f5270b7bcf550f91f70c8cafc6c
17:29imirkin: tobijk: get rid of the ? true : false thing, and i'll push
17:30tobijk: meh :D
17:30imirkin: bool = int will convert the int into a bool
17:31tobijk: yeah, yet i always like this to be verbose, but if you insist .D
17:35imirkin: i'll fix it up a bit
17:35imirkin: are you making that change? or do i need to?
17:35tobijk: imirkin: i can do it, np
17:35imirkin: also, whiel you're at it
17:36imirkin: if (omit) INFO(" "); else INFO("", serial);
17:36imirkin: [so that both paths do serial++ in a single place and it's obvious]
17:36tobijk: yeah right :D
17:37imirkin: [yeah, that's totally bikeshedding, but ... i think the result will look better and be more obviously correct.]
17:44tobijk: imirkin: https://git.thm.de/tjkl80/mesa/commit/efb977e28ce9fdcc945542614202534547d216ca
17:45tobijk: if you want you can just pull from that branch
17:45imirkin: nah, i just append .patch to the end of the url
17:45imirkin: and git am that
17:46tobijk: ah good to know :)
17:47imirkin: next time, try to take out the 'asdf' :p
17:52imirkin: pushed, thanks!
17:52tobijk: imirkin: thanks
19:36tobijk: yay, apitrace works wonderful with prime offloading lately :O
19:36feep: a pit race :D
19:37tobijk: something regressed badly :/
19:37imirkin: tobijk: did i accidentally the whole thing?
19:38tobijk: imirkin: ?
19:38feep: a car crash :(
19:38tobijk: imirkin: apitrace did not work for me last week either, so not your patches :)
21:08feep: welp, it crashed :(
21:08feep: stayed up for more than a day at least
21:10imirkin: zukunf: "AA" isn't a single thing ... if you mean MSAA, it should work fine.
21:10zukunf: imirkin: anisotropic and anti-aliasing options.
21:11zukunf: those two work flawlessly?
21:16imirkin: zukunf: i have no way of knowing what the application does when those options are enabled
21:16imirkin: i can say with some certainty that MSAA, SSAA rendering and AF texturing work just fine
21:17zukunf: slow down, ppsspp, a game emulater.
21:17imirkin: well, i'd certainly expect a slowdown - this stuff ain't free
21:17zukunf: I wanted to rule out that the slow down had anything to do with nouveau
21:18imirkin: i mean ... hard to say, depends on what ppsspp does exactly
21:18imirkin: make sure you have a moderately recent version of mesa
21:18imirkin: otherwise you may be missing features that will let the game do things faster
21:19orbea: i think ppsspp might be using gles for linux? https://github.com/hrydgard/ppsspp/pull/10113
21:19orbea: they are just now thinking about using a core profile?
21:19zukunf: ok, thanks will try again.
21:27feep: hm, path of exile runs really badly on my gt 645m in wine :( maybe I need to use the d3d9 branch? does that work with nouveau?
21:28imirkin: feep: yes
21:29feep: sweet, thanks