01:19gnurou: imirkin_: https://github.com/envytools/envytools/pull/33 , let me know if anything needs reworking
01:21gnurou: imirkin_: you will see that the new format is very... polymorph?
01:22gnurou: the XML might make it difficult to understand which fields are available for a given version, but from this data it should be easy to generate something better :)
01:27gnurou: also code using .h generated from g80_texture is going to be affected - let me know if you want me to update Mesa accordingly
05:41imirkin: gnurou: great stuff.... i guess i'll send comments on github, oh well. in general i much prefer email.
06:29mwk: gnurou: I gave you some inline comments
06:29mwk: the variants stuff is also rather confusing
06:29mwk: and multiple copies of eg. "4" with overlapping variants won't work right with the tools
06:30mwk: IMO it'd be better to merge all reg32s with the same offset, and tag individual bitfields with the variants
06:31imirkin: i generally agree, but i also don't want to burden gnurou with learning all the right ways to do things to work well with our tools...
06:31imirkin: happy to merge something that's mostly there and fix it up later
06:31mwk: that's true
06:32gnurou: imirkin: mwk: thanks guys! I will respin and resend tomorrow, these issues should be quick to address, except maybe the chip variants for which the document I used is lacking... but we must have that info somewhere
06:32imirkin: gnurou: well if you can't find the info then wtvr
06:32gnurou: and since I'd like to continue on that trend, I don't mind learning the right way to work with envytools
06:33imirkin: basically for any question that starts with "did the G80 support", the answer will almost always be "no"
06:33gnurou: haha, ok
06:35gnurou: urgh, and it seems like that contrary to my plans, the GM20X firmwares won't be released before the end of year... so sorry about that :(
06:35imirkin: and those fancy ETC2 formats clearly also came later... they appeared as part of ES 3.0, which wasn't a thing probably until GF100 came out, and it was mobile-only so it probably didn't have it either
06:36gnurou: it's independent from my will, on my end the kernel code is ready and working... :( it's just a long and fragile chain to get everything signed off
06:36imirkin: gnurou: well, for whatever little consolation it is, we don't blame you
06:36imirkin: just the universe we live in :)
06:41gnurou:straps his cilice tighter
07:29RSpliet: gnurou: does it make any sense mailing the firmware upload code to the ML (if you haven't already, sorry, I'm a bit behind) so we can do a bit of static analysis, code conventions etc?
07:30RSpliet: realising I haven't been very good at this in the past, considering the large stream of e-mails that roll past my eyes and the tiny fraction of them I respond to...
07:38pmoreau: imirkin: Are the changes we added yesterday to get the RA going on Tesla considered "good" changes or just "not a proper fix"?
07:39pmoreau: So should I search for a proper fix or are those fine? Or will you take care of submitting patches?
07:44karolherbst: does anybody want to check the fsrm validation code for gf119 and keplers? https://github.com/karolherbst/nouveau/commit/2691e938616567567db40c2a5d027202a18a2953
07:45karolherbst: ohh wait, I should stop to use nvkm_info in _init functions :D
08:04Tom^: i want to, but how. ? :p
08:10karolherbst: just apply the patch and rebuild :p
08:11karolherbst: but I don't think this works on nvf1 cards :/
08:11karolherbst: maybe it does, who knows
08:17Tom^: did you say keplers?
08:19karolherbst: well yes, but with nvf* ones it seems to be different
10:35imirkin_: pmoreau: those fixes are pretty unsatisfactory, but so was the reason for my lval->defs.size() == 0 check
10:35imirkin_: pmoreau: so i'd be ok with pushing those to master
10:36imirkin_: pmoreau: perhaps with a /* XXX figure out where these RIG nodes come from */
12:11pmoreau: imirkin_: I'm fine with investigating those issues further. :-) Especially if I'm the only one experiencing those, so there is no need for an urgent fix.
12:12imirkin_: pmoreau: your call
12:12imirkin_: pmoreau: it's the same level of bs-ness as the lval->defs.size==0 check, and i had to add that for real code
12:13imirkin_: pmoreau: i don't see how either can happen, and yet here we are
12:32hakzsam: imirkin_, hey, still didn't review the edgeflag and the coherent things? :)
12:32imirkin_: coherent things?
12:32imirkin_: oh that one
12:32imirkin_: i thought i had
12:33hakzsam: but not the v3
12:33hakzsam: I didn't get your Rb or not ;)
12:33imirkin_: ah right
12:33imirkin_: need to have another look
12:53hakzsam: imirkin_, fast!
12:53imirkin_: i'm good at short obvious changes
12:54imirkin_: less good at changes that will potentially destroy the universe
12:54hakzsam: I'm pretty sure that we have the same problem on nv50 (but a little bit different)
12:59karolherbst: Tom^: can you check whether these regs are set on your nvf1 card with nouveau and with the blob? https://gist.github.com/karolherbst/1854da8068b510d4cc14
13:04hakzsam: imirkin_, definitely, this patch is not my friend...
13:06imirkin_: hakzsam: it's a tricky one
13:07imirkin_: you see the sadness i was referring to, or do i need to be more explicit?
13:07imirkin_: i like to be a *little* cryptic in my feedback in the hopes that the patch author will think a bit more about the code
13:07imirkin_: but it's a fine line
13:08hakzsam: imirkin_, I guess, that this texture coherent flag needs to be reset even when views[i] is NULL, right?
13:36karolherbst: the fsrm has three stages? :O
13:36imirkin_: hakzsam: did you ever look at printing TIC/TSC on kepler+ ?
13:37karolherbst: oh meh, the fsrm works three stage based :/
13:38hakzsam: imirkin_, not yet
13:56hakzsam: imirkin, not very confusing for me, I could try to improve it but only when global perf counters will be merged
13:56imirkin_: hakzsam: yeah don't worry about it
13:56imirkin_: i'm happy to be confused :)
13:57imirkin_: can you reply to your nv50 patch with instructiosn on how to test? i'll give it a shot tonight
14:00hakzsam: imirkin_, GALLIUM_HUD="instructions" valgrind --leak-check=yes glxgears &> valgrind.output
14:00hakzsam: this should be enough
14:00hakzsam: ah ok reply :)
14:02imirkin_: ah ok
14:02imirkin_: i can handle that
15:23hakzsam: skeggsb, "multiple sw classes" is the reason why SUBCHAN_OBJECT is not currently really needed, that makes sense
15:23hakzsam: thanks for this new version, I'll try to test it tomorrow
15:25skeggsb: hakzsam: cool. it's no different from the last spin except for libdrm handling NVIF_CLASS_SW_* for old kernels + mesa not removing the sw object
15:26hakzsam: yeah, I saw that
15:26hakzsam: just want to make sure it still works and make a proper review if I find time before vacations :)
15:28skeggsb: yeah, i've got way too much to try and get through before then too :P
15:29hakzsam: no rush, global perf counters still need more work to be upstream
15:30hakzsam: skeggsb, btw, did you see the new software methods interface for managing those perf counters the pas ? If so, what do you think of it?
15:30hakzsam: *the past week
15:31skeggsb: i did see it, but haven't yet had a chance to review properly. i still need to get to karolherbst's patches too - but rhel comes first :P
15:31karolherbst: always those excuses :p
15:32hakzsam: hehe :)
15:32karolherbst: skeggsb: got my message about the ptimer thingy?
15:32karolherbst: I am really curious about this, because that thing causes troubles all over the place with runpm enabled
15:32karolherbst: or when the gpu is really messed up
15:33skeggsb: yes well, we should fix those problems. if timer isn't functional, the gpu is really fucked and we're going to hit many other problems
15:34karolherbst: yeah, that I hit
15:34karolherbst: I am not against using the timer in general
15:34karolherbst: just sometimes you get always the same value from a read
15:34karolherbst: and so hang a kworker
15:34karolherbst: which is really bad
15:35karolherbst: so I was thinking if you just want to wait like 2 seconds, just don't use the timer from the gpu, because that's somehow a big overhead
15:35karolherbst: and error prone
15:35skeggsb: we shouldn't be waiting 2 seconds anyway
15:35skeggsb: those are being lazy and not figuring out real timeouts
15:35karolherbst: I meant for timeouts
15:35karolherbst: ohh I see
15:36karolherbst: skeggsb: well we had an issue here, where nouveau hang inside the nvkm_pmu_init function with a wait function :/
15:36karolherbst: directly after waking up the gpu
15:36karolherbst: which caused the Xserver to freeze completly
15:37skeggsb: yes, so fix whatever is causing pmu init to fail :P
15:38karolherbst: skeggsb: so back to my question: should nvkm_*sec depend on the ptimer?
15:38karolherbst: or use the ptimer
15:38karolherbst: why is it implemented that way
15:38karolherbst: this is the thing I want to understand
15:38skeggsb: yes, it should. it's implemented that way because it's what nvidia does, and certain wait conditions have turned out to work better that way in the past
15:39skeggsb: (probably because of the reg reads to different units, i guess)
15:39karolherbst: skeggsb: yeah right, that should be fixed, but messing up the system that hard, isn't good at tool. the wait shall timeout, even when the gpu is messed up hard and print an error in dmesg
15:41karolherbst: for the sake of a stable system alone I wouldn't use the ptimer at all, because I just found too many situations myself, where nouveau messed up just waiting for the ptimer regs to return something usefull, but nouveau got stuck forever
15:42skeggsb: nouveau hardly *ever* messes up like that unless you're developing new code, in which case, it's a not-so-subtle sign things have gone *horribly* wrong
15:43skeggsb: i'll make a note to do *something* about handling that case, but seriously, time would be better spent on fixing the causes of such things
15:44karolherbst: I think there are some race conditions somewhere
15:44karolherbst: or also sometimes the use_counter isn't increased right
15:44karolherbst: something like that
15:44karolherbst: never bothered to dig that deep into it thought
15:46karolherbst: skeggsb: maybe the nvkm_*sec functions could also check the host for the time? or add something like that with a bigger wait
15:46skeggsb: it doesn't matter how big the wait is, if timer is stuck, the gpu has most likely fallen off the bus completely, and any length of wait will be fail
15:46karolherbst: yeah right
15:47karolherbst: but we can return in such a case when we detect this
15:47skeggsb: yes, i'll do something like that
15:47karolherbst: and leave the host in a less messed up state
15:47karolherbst: k :) thanks
17:10imirkin: hakzsam: this is what i see without your change: http://hastebin.com/lavawehovu.vhdl
17:16imirkin: hakzsam: hm... the fragprog leak goes away, but i don't understand why
17:30imirkin: hakzsam: btw, a minor improvement opportunity: http://hastebin.com/ugegehurep.avrasm
18:19gnurou: RSpliet: I had submitted a first version of it, v2 is on the way - it now supports dGPU secure boot, excepted, well, the firmware is not available publicly :/
18:26imirkin: with that logic though, we could potentially extract the fw
18:51imirkin: hakzsam: btw, consider something like http://hastebin.com/uvoxuyaquy.coffee in that logic...
19:35imirkin: gnurou: if you can't find the proper documents about what formats became available when, don't worry about it... we'll work it out... eventually
19:36imirkin: my personal guess is that etc2/eac was gm107, and astc is gm200 (or maybe even exclusively gm20b)
19:54gnurou: imirkin: let me have a look - now is the right time to figure this out, and we must have the information somewhere
20:20imirkin: the empirical method works just as well... i know GK208 doesn't have it, so... :) i guess GK20A might have the ETC2 stuff
20:21imirkin: (it's a format introduced in GLES 3.0)
20:22imirkin: (and in case you weren't aware, GLES is the mobile thing everyone appears to love, and what android exposes to applications, so i'm guessing of some concern to the tegra guys)
20:39imirkin: gnurou: any clue what "native 8/16bit snorm components forced to FP16 format" means?
20:39imirkin: or is my guess as good at yours, if not better?
20:47gnurou: your guess is probably better than mine :)
20:58imirkin: bleh. so you're telling me i'm incompetent? sad :( i'll have to look at why the ETC2 stuff failed. perhasp i got the formats wrong. or perhaps i did something else dumb :(
20:58imirkin: tbh, i *did* see *some* signs of life from those formats, but i wasn't sure if it was just stale buffer contents
21:02gnurou: I'd take my variants suggestions more as hints than absolute truths, especially for formats - finding the exact chip where these appeared turns out to be harder than one would expect...
21:03imirkin: i don't suppose you have per-chip docs and you just look at newer and newer chips until you find one that has the format?
21:04imirkin: it could be that the sampler format expects some sort of alignment i wasn't providing it
21:05imirkin: or... it could be that we have some blockheight/width assumptions somewhere... hm, are those 4x4 formats?
21:06imirkin: yep, looks like they are
21:06gnurou: it is difficult to find accurate information for pre-Fermi things, actually
21:09imirkin: is that why support for pre-fermi got dropped? lost all docs? :)
21:10imirkin: gnurou: Z16 is G200+
21:10imirkin: gnurou: pretty sure the coverage ones that come after it are G200+ as well
21:10gnurou: rather than that, the docs are somewhere else and I don't know where to look :)
21:10gnurou: ok, go for G200+ then
21:11gnurou: hell, I don't even know what they mean or what they are for :P
21:13imirkin: oh, different AA modes
21:14imirkin: coverage is where you store a mask of the covered samples somewhere
21:14imirkin: so you use 8 bits if you have msaa x8
21:14imirkin: obviously that doesn't work with SSAA
21:14gnurou: interesting, I'd have expected AA to be a property of the sampler, whereas the TIC would only store texture properties...
21:14imirkin: but it's part of the format
21:15imirkin: so like let's say you have depth 24, coverage 8 (Z24C8 -- not 100% sure it's an actual format)
21:15imirkin: the sampler needs to know which bits are which
21:15imirkin: it also has to do with memtypes, how things are accessed, etc
21:16imirkin: lots of stuff i don't understand
21:16imirkin: what i do understand is one thing -- don't lie about formats, or pgraph will find you out!
23:06gnurou: v2 of Maxwell TIC documentation on https://github.com/envytools/envytools/pull/33 - Github seems to be doing a crap job at handling forced-pushs on pull requests...