14:52 karolherbst: pmoreau: you didn't look at my patches :'(
14:55 karolherbst: imirkin: do you have any "vision" of how the split/merge thing should have been implemented? currently I have the feeling I fight more against current limitation of the RA code than actually working on the issue itself. Maybe it would make more sense to just rework it
15:00 pmoreau: karolherbst: I haven’t… I tried adding those to my kernel when I updated it to 4.13, but they wouldn’t apply and I just moved on. :-/
15:01 karolherbst: uhh yeah, my branches are based on master rebased on latest releases
15:01 karolherbst: so usually compiling out of tree is easier
15:02 pmoreau: Let me swap the GM206 in my desktop to a Kepler card, and compile an out of tree.
15:03 karolherbst: awesome
15:03 karolherbst: thanks
15:05 pmoreau: And I’ll have a look at the patches as well.
15:06 karolherbst: pmoreau: the branch where most of my stuff is on is "master_karol" don't really know the state of the other ones yet
15:07 pmoreau: I was thinking of just using the patches you sent to the ML.
15:07 karolherbst: this might work as well, yeah
15:26 pmoreau: imirkin: Where should I send patches for shader-db?
15:47 pmoreau: Duh, need to rebuild the kernel from scratch as I don’t get a working keyboard nor mouse once booted. --"
15:48 karolherbst: :(
15:48 karolherbst: I have those super odd steam download issues again, super annoying
15:48 pmoreau: :-(
15:49 pmoreau: Where the download speed suddendly drops ti a few kB per second?
15:49 karolherbst: yeah, it does DNS overflodding
15:49 karolherbst: because .... DNS load balancing....
15:50 karolherbst: it's just stupid
15:51 karolherbst: I would just put all the steam hosts into my hosts.conf file, but they have like thousends of sub domains...
16:02 imirkin: pmoreau: mesa-dev with [shader-db] prefix
16:03 imirkin: karolherbst: sorry, i haven't spent a ton of time thinking about it
16:03 karolherbst: imirkin: ohh, I thought you had an idea already
16:04 karolherbst: but maybe I just end up with fixing the last issue I have and then everything is fine, allthough I doubt it
16:04 imirkin: karolherbst: could be that splits/merges should be handled differently
16:04 imirkin: e.g. if you have a merge, put things together, but if you have a split, add constraint moves. dunno.
16:04 karolherbst: !
16:04 imirkin: or vice-versa
16:05 karolherbst: putting constraint moves for splits would fix my last issue
16:05 karolherbst: I think
16:05 imirkin: either way, that's not really RA's problem either way
16:05 karolherbst: there is some oddness going on though
16:05 karolherbst: not really
16:05 imirkin: it's the problem of the way the IR works right as it comes into RA
16:05 imirkin: RA does what you ask it to
16:05 karolherbst: mhh kind of
16:05 karolherbst: there is some odd SPLIT/MERGE handling going on there
16:06 karolherbst: especially when the splits gets eliminated and the register ids replaced
16:06 imirkin: one problem is that it doesn't properly unmerge nodes when retrying
16:06 imirkin: nah, that stuff is fine
16:06 karolherbst: oh well, I think I fix that unmerging issue already
16:07 imirkin: highly unlikely.
16:07 imirkin: it did not seem easy
16:07 karolherbst: is it that makeCompound part?
16:07 imirkin: i tried a few easy things and it wasn't enough
16:07 pmoreau: imirkin: Ok, will send the patch for nv-report then. :-)
16:07 imirkin: it's the thing where you copy all the defs into one master node
16:08 karolherbst: you mean that extending of liveRanges?
16:08 imirkin: btw, you guys need to not rely on me -- my time for contribution has largely dried up. i'm still on irc, but i don't have time to do anything of significance.
16:08 imirkin: karolherbst: no, the literal copy of lval->defs into the merged lval's defs.
16:08 karolherbst: okay, let me check
16:08 karolherbst: yeah, I don't do it anymore for merges
16:08 karolherbst: or splits
16:09 imirkin: uhhhhhh
16:09 imirkin: ok
16:09 imirkin: well that'll definitely "fix" things, although it'll break a lot of others ;)
16:09 karolherbst: fix by elimination ;)
16:09 karolherbst: yeah
16:09 karolherbst: but I think I fixed most of the stuff I broke
16:09 karolherbst: only one last thing missing
16:09 imirkin: that could well be.
16:09 karolherbst: and it's the step where the splits gets eliminated
16:09 karolherbst: than the register allocation is broken
16:11 karolherbst: imirkin: this is basically the issue I am fighting with: https://gist.githubusercontent.com/karolherbst/57d91f1c7cb634cf0599641efd7c3a2c/raw/9c7cbf81dde99ac36f388c585953ea02e7c9074c/gistfile1.txt
16:12 imirkin: yeah you can't do that ;)
16:12 karolherbst: ;)
16:12 imirkin: the live range needs extending
16:12 imirkin: that's why the defs got merged
16:13 karolherbst: yeah, I know
16:13 karolherbst: but if they get merged, we can't spill anymore
16:13 karolherbst: and because we can't remove spilling, I thought removing the merging is one way out
16:13 imirkin: ok, well this isn't a situation you can solve with random programming
16:13 imirkin: you have to sit down and properly reason about the issues
16:13 imirkin: and come up with solutions to them
16:13 karolherbst: yeah I know
16:14 karolherbst: but at least the random programming gave me enough knowledge that I kind of understand the code better
16:15 imirkin: yeah. i'm a big fan of just trying things to see what happens and to gain a better understanding
16:15 karolherbst: I already thought about have two kinds of live ranges
16:15 karolherbst: *having
16:15 karolherbst: but mhh, that sounds troublesome
16:16 karolherbst: and would only be a workaround
16:16 karolherbst: okay, but basically the issue was something like that: the split values were marked to be spilled, but not the master node and we ended up with no spilling at all
16:17 karolherbst: that's more or less the issue
16:18 karolherbst: imirkin: kind of sad that you won't have much time anymore, but maybe I will find time to get new talanted people on board :)
16:20 karolherbst: Nouveau shouldn't end up being a two men show
16:20 imirkin: yeah, it's possible things will ease up in a few months, dunno
16:22 karolherbst: no worries though. I am sure things will get better next month anyhow and maybe somebody can convince one or two students to do some EVoC projects or so, because somebody might live in a perfect place for this
16:22 imirkin: and i'm still generally around on irc, so it's not like i'm totally gone
16:23 karolherbst: exactly
16:23 karolherbst: helping with knowledge is very important in the end
16:25 imirkin: what little of it i have...
16:34 karolherbst: imirkin: ohh I think of the OpenGL stuff you know the most from us, I think
16:35 karolherbst: and hopefully on the compiler side I will get close over the next months soon :)
19:25 duttasankha: Previously I saw a list where all the GPUs on which nouveau is tested has been listed. But I am not able to find it. Does someone know the link? Or if someone could provide me a GPU name that you guys have used and fully tested it.
19:45 imirkin: duttasankha: that list was hopeless out of date. i think i killed it ~4 years ago
19:49 imirkin: might still exist though... maybe i just delinked in
19:49 imirkin: it*
20:14 duttasankha: imirkin: Thanks for the information. Can you then please let me know a GPU which is fully verified. Actually I was discussing with my advisors and they asked me to let them know about such a GPU. So can you please tell me a GPU where everything is verified and fully RE. I was thinking about GTX480.
20:16 imirkin: not sure what you're looking for, but i think that i can say with some certainty, "none"
20:16 imirkin: closest to being fully re'd is probably the Riva 128? not sure.
20:39 duttasankha: Sorry for not being clear..I am looking for CUSDA enabled GPUs which is fully re'd or which has been max re'd
20:39 duttasankha: *CUDA
20:41 imirkin: i think it'd make more sense if you set out your goals, and given those goals, i can recommend an nvidia gpu supported by nouveau
20:41 imirkin: [but really if you're looking for open-source support, you should definitely go with AMD]
20:42 imirkin: currently the best supported GPU's all around are the second-generation keplers, i.e. GK110 (high end) / GK208 (low end)
20:43 imirkin: you get reclocking with those, and you also get 256 registers which doesn't stress our RA quite as much
20:46 imirkin: [i mean 256 ISA registers... the total registers per SM on all keplers is 64K... except apparently the K80 which has more. but we've never tested on such a gpu.]
21:00 karolherbst: imirkin: how much should the K80 have?
21:00 imirkin: karolherbst: iirc it has like 128K or 96K. i forget.
21:01 imirkin: but i don't even know how to identify it
21:05 duttasankha: imirkin: I actually cannot go for AMD....I have to stay with nvidia....I am working towards the GPGPU aspects of GPU rather than the graphics and primarily CUDA...
21:06 imirkin: ok. there's no support for CUDA on nouveau (unless you count gdev, but i've never personally played with it)
21:11 duttasankha: no that I know...but if I can get a GPU where I know most of the details regarding MMIO and all other internal details that is mentioned in envy then I can carry on with what I am doing....what I am trying to say is for example yesterday I was working on the signals in PCOUNTER and I was using Tesla C2070...but I came to know that the signals have not been RE for that generation of GPU
21:12 duttasankha: so I am looking for a GPU where the details that have been mentioned is valid
21:13 imirkin: ok. i'm less familiar with the counter stuff. i'll let others comment. i thought we had it for all chips.
21:13 imirkin: but perhaps that's a different counter
21:13 imirkin: global counters vs sm counters? dunno
21:13 duttasankha: the details that are pertaining to nvidia hardware...and a nvidia hardware where CUDA is supported
21:14 imirkin: ok. i guess i have no clue what you're asking. ignore everything i've said - nevermind.
21:16 duttasankha: I apologize if I am not clear to you....regarding a separate topic..can you tell me where can I find the PPEPHOLE section of the code?
21:16 duttasankha: PEEPHOLE
21:17 duttasankha: either in envy/nouveau
21:20 imirkin: yeah... it's a way to access vram through mmio
21:21 duttasankha: yeah...I have seen that...I have written my code to test it as well..but it didn't worked as expected...so I was thinking to look for the code....
21:21 imirkin: duttasankha: http://envytools.readthedocs.io/en/latest/hw/memory/peephole.html
21:21 imirkin: the latter part of the table comes out a little wrong on there
21:22 imirkin: you can read it a little better here: http://envytools.readthedocs.io/en/latest/_sources/hw/memory/peephole.rst.txt
21:23 duttasankha: okay..thanks for the docs....I will go through it...but I am thinking to go through the code...I couldn't find it...do you know where the PEEPHOLE code is located if it written?
21:24 duttasankha: I have gone trough the first one...but the later onw was unknown to me...
21:31 imirkin: just look for that register usage
21:35 imirkin: duttasankha: https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nvkm/engine/sw/gf100.c#L49
21:35 imirkin: that's an example of using peephole to write vram
21:37 duttasankha: okay..thanks so much.. i would look into it...