00:09 imirkin_: Lyude: i thought they were, maybe not hcecked in?
00:09 Lyude: must be, doesn't seem to be anything in upstream piglit
00:14 imirkin_: indeed
00:14 imirkin_: look for "[PATCH 2/3] arb_post_depth_coverage-multisampling: Add a multisampling test" among others
00:14 Lyude: gotcha
00:51 Satchelboi: karolherbst: So I should avoid making any more big changes until then?
01:10 dboyan: Satchelboi: I guess so, it takes time to review. Bigger changes generally need more time, and sometimes, more rounds.
04:50 imirkin: looks like superposition basically works on nouveau. nice.
04:54 imirkin: you do have to start it with a GL 4.5 / GLSL 450 override, otherwise it crashes.
07:32 ccaione: \
10:49 karolherbst: Satchelboi: yeah, concentrate on getting the patch fixed rather then adding more work
16:36 imirkin_: Lyude: the arb_post_depth_coverage tests got pushed
16:40 Lyude: imirkin_: cool, thanks!
16:41 imirkin_: thank the people who wrote/reviewed them ;)
17:53 imirkin_: Lyude: i'm guessing that 0xf1c is the post-depth coverage thing.
17:56 Lyude: imirkin_: oh, you're quick
17:56 Lyude: lol
17:59 pmoreau: RSpliet: I didn’t get the "invalid/missing rammap entry" when using `len < 0x0d`, but now I get "invalid/missing ramcfg entry" :-D
17:59 imirkin_: Lyude: given that the two settings are related, and that they're adjacent in the cmdstream ... it's a good indicator.
18:00 imirkin_: Lyude: just have to feed it through pipe_rasterizer_state
18:00 imirkin_: i think you know the drill by now :)
18:01 Lyude: yep
18:01 imirkin_: and for thigns like this where it's just flipping a bit, i also like to double-check it by artificially leaving the change out and double-checking that the tests fail
18:02 imirkin_: sometimes the tests aren't extremely well written, and confirmation bias is a nasty little devil
18:02 pmoreau: RSpliet: I’ll continue changing those max values until it stops complaining. :-)
18:07 Lyude: imirkin_: yeah, additionally: this test seems to be a little buggy with certain window sizes
18:07 imirkin_: Lyude: yeah, don't resize
18:08 imirkin_: leave it at default window size
18:08 imirkin_: most tests don't handle resizing
18:08 Lyude: yeah, it gets triggered by valgrind too but that looks like some weird race thing in nvidia's blob
18:08 Lyude: running it outside of valgrind works fine
18:08 Lyude: but the test looks the same either way so, heh
18:10 Manoa: what a nightmare this for you guys :x now I see what you going through
18:10 karolherbst: Manoa: you see it the wrong way, it's fun this way :p
18:11 Manoa: lel
18:13 imirkin_: Manoa: this is a tiny little feature. serious features require a ton more work.
18:43 RSpliet: pmoreau: hehe, I thought your ramcfg entry was of length 14...
19:35 karolherbst: mhh, anybody any ideas why Nvidia doesn't enable a PPDEC PMU counter on all cards?
19:45 karolherbst: mhh
19:45 karolherbst: what video engine was added with maxwell2?
19:45 karolherbst: PDAEMON.COUNTER_MASK[0x1] <= { PPDEC | PVENC | 0x400000 }
19:46 karolherbst: ohh, all others were merged into one, right?
19:53 imirkin_: maxwell2 lost the separate decoding engines
19:53 imirkin_: and gained a new "combo" decoding engine
19:53 imirkin_: er, maxwell1 did
19:54 karolherbst: mhhh
19:54 karolherbst: odd
19:54 karolherbst: the PMU counters are configured the same on maxwell1 as on kepler though
19:54 imirkin_: of course those engine id's may still be around, and just mean something else
19:54 karolherbst: only with maxwell2 there is the new field
19:54 imirkin_: or a single engine might generate multiple counters
19:54 imirkin_: no clue :)
19:54 karolherbst: might be
19:55 karolherbst: my results so far: https://gist.githubusercontent.com/karolherbst/1eb3759be936406734bcfa308c2652b2/raw/7d8f68f407abe0966595d2d47156d38c992f8dde/gistfile1.txt
19:55 karolherbst: I am wondering if there is something defined somewhere which tells the driver how to configure those
19:56 karolherbst: becuase sometimes the PPDEC counter isn't set
19:56 karolherbst: or other odd things like that
19:57 Lyude: bleh, looks like that arb_post_depth_coverage test passes regardless or whether or not the driver actually does the post depth coverage stuff correctly. I'm also seeing some weird errors from the other tests that I'm not sure how to address: https://paste.fedoraproject.org/paste/2pCanE7JO0msKN9yuhziWF5M1UNdIGYhyRLivL9gydE=
19:57 imirkin_: the basic test
19:58 imirkin_: or all the tests?
19:58 Lyude: that error happens for all but the basic test
19:58 imirkin_: Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable -- install libtxc_dxtn :)
19:58 imirkin_: for the latter... how many samples is it asking for??
19:58 Lyude: ooooh
19:58 imirkin_: nvidia only supports 8
19:58 imirkin_: but SKL supports 16
19:58 imirkin_: perhaps the test requires 16? that'd be sad.
19:59 Lyude: yes, it does
19:59 karolherbst: or this fany st2c library
19:59 karolherbst: *fancy
19:59 imirkin_: int samples[4] = { 2, 4, 8, 16 };
19:59 imirkin_: Lyude: oh, just add error checking - if you get an error with any of them, just break out of the loop
20:00 imirkin_: Lyude: or do glGetInteger(GL_MAX_SAMPLES) or something like that
20:00 Lyude: imirkin_: gotcha
20:01 imirkin_: Lyude: if the tests all still pass either way, then you'll need to figure out how they work and fix them
20:01 imirkin_: Lyude: the post_depth_coverage thing only applies to multi-sampled situations, so i'm not surprised that the basic thing worked either way
20:01 Lyude: ah
20:01 karolherbst: imirkin_: ohh wait, you are right, the other video engines disappeared, but nothing new came instead...
20:02 karolherbst: is there no PCOPY1 on maxwell? mhhh sometimes those counters make like no sense
20:03 karolherbst: maybe they indeed mean something different sometimes
20:03 imirkin_: Lyude: basically it just determines what value gl_SampleMaskIn takes. but that means that at least ONE fragment is lit. without msaa, there's only one frag per pixel, and it's either lit or not lit :)
20:04 imirkin_: Lyude: i also expect the sample-shading one to pass either way
20:04 imirkin_: Lyude: since there each frag invocation has a single sample to it, which is the same as the msaa = 1 case
20:06 Lyude: alright
20:07 imirkin_: (technically with sample shading, # invocations doesn't have to == # samples, but in practice, getting sample mask forces that to be the case.)
20:10 imirkin_: (why is this totally useless information in my head... oh well)
20:11 karolherbst: mwk, mupuf: when you were working on those PMU counters, did you notice any anything nvidia might have used to optionally enable/disable counting certain engine?
20:15 Lyude: imirkin_: btw, what is libtxc_dxtn?
20:15 imirkin_: txc = texture compression
20:15 imirkin_: dxtn = DXT1, DXT3, DXT5
20:15 imirkin_: aka s3tc
20:16 Lyude: ah, also I just noticed it says it right there :s
20:16 karolherbst: but why is the library needed anyway? I thought that hw usually have direct support for it?
20:16 airlied: karolherbst: encoding
20:17 karolherbst: ohhh
20:17 karolherbst: isn't s2tc the "better" alternative these days anyway?
20:19 airlied: if by better you means not as good
20:19 airlied: but less patenty
20:19 karolherbst: yeah
20:19 RSpliet: ASTC is quite non-patenty?
20:19 airlied: s3tc patents expire this year I think
20:19 karolherbst: RSpliet: well, but you can use s2tc as a drop in replacement for s3tc
20:19 karolherbst: afaik
21:06 imirkin_: desktop hw doesn't support ASTC though (except intel)
21:17 karolherbst: mupuf: mhh, I have two options now: 1. let the PMU ping the host every 0.1 seconds about new loads or 2. inform the PMU about currently set memory/core clocks :(
21:17 karolherbst: what is the less bad way to go?
21:17 imirkin_: have PMU send updated load info
21:18 imirkin_: it'll be useful to have anyways
21:18 karolherbst: but every 0.1 seconds?
21:18 imirkin_: that's decades for computers :)
21:18 imirkin_: (remember tron? :) )
21:18 karolherbst: true
21:18 karolherbst: mhh even on mobile chips it doesn't matter
21:18 karolherbst: true
21:19 karolherbst: I just implement a very smart algorithm on the PMU so that we get only informed about new updates if the host really needs it
21:20 karolherbst: but the way nvidia calculates the memory loads makes it all kaputt :(
21:20 imirkin_: if the gpu gets shut down, then fine
21:20 imirkin_: but as long as it's up ...
21:21 karolherbst: a wakeup every 0.1 second might have a noticable impact on power consumption, but on the other hand: which driver really cares anyway?
21:22 imirkin_: while the gpu is running? unlikely to be noticeable.
21:22 karolherbst: true
21:23 karolherbst: okay, so I go the simple way and just annoy the host the entire time
21:23 karolherbst: and then we can just use the last data for the current load
21:23 karolherbst: and we don't need to do any PMU commands in that case anymore reading those out
21:24 karolherbst: sounds like a plan
21:24 karolherbst: and this makes a lot of things less complicate as well
21:24 imirkin_: :)
21:25 karolherbst: so dyn reclocking should be ready in summer then :p
21:26 karolherbst: just need to figure out if there is any deeper logic in configuring those PMU counters or if we can simply set those depending on the chipset
21:42 karolherbst: Satchelboi: you should post the (final) patch today, otherwise it might not land in time. And try to react fast enough to reviews.
22:13 Satchelboi: karolherbst: I'll put a rush on that right now then. Sorry for my absence today, I've quite literally been on a wild kitten chase