14:52karolherbst: pmoreau: you didn't look at my patches :'(
14:55karolherbst: 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:00pmoreau: 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:01karolherbst: uhh yeah, my branches are based on master rebased on latest releases
15:01karolherbst: so usually compiling out of tree is easier
15:02pmoreau: Let me swap the GM206 in my desktop to a Kepler card, and compile an out of tree.
15:05pmoreau: And I’ll have a look at the patches as well.
15:06karolherbst: 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:07pmoreau: I was thinking of just using the patches you sent to the ML.
15:07karolherbst: this might work as well, yeah
15:26pmoreau: imirkin: Where should I send patches for shader-db?
15:47pmoreau: Duh, need to rebuild the kernel from scratch as I don’t get a working keyboard nor mouse once booted. --"
15:48karolherbst: I have those super odd steam download issues again, super annoying
15:49pmoreau: Where the download speed suddendly drops ti a few kB per second?
15:49karolherbst: yeah, it does DNS overflodding
15:49karolherbst: because .... DNS load balancing....
15:50karolherbst: it's just stupid
15:51karolherbst: I would just put all the steam hosts into my hosts.conf file, but they have like thousends of sub domains...
16:02imirkin: pmoreau: mesa-dev with [shader-db] prefix
16:03imirkin: karolherbst: sorry, i haven't spent a ton of time thinking about it
16:03karolherbst: imirkin: ohh, I thought you had an idea already
16:04karolherbst: but maybe I just end up with fixing the last issue I have and then everything is fine, allthough I doubt it
16:04imirkin: karolherbst: could be that splits/merges should be handled differently
16:04imirkin: e.g. if you have a merge, put things together, but if you have a split, add constraint moves. dunno.
16:04imirkin: or vice-versa
16:05karolherbst: putting constraint moves for splits would fix my last issue
16:05karolherbst: I think
16:05imirkin: either way, that's not really RA's problem either way
16:05karolherbst: there is some oddness going on though
16:05karolherbst: not really
16:05imirkin: it's the problem of the way the IR works right as it comes into RA
16:05imirkin: RA does what you ask it to
16:05karolherbst: mhh kind of
16:05karolherbst: there is some odd SPLIT/MERGE handling going on there
16:06karolherbst: especially when the splits gets eliminated and the register ids replaced
16:06imirkin: one problem is that it doesn't properly unmerge nodes when retrying
16:06imirkin: nah, that stuff is fine
16:06karolherbst: oh well, I think I fix that unmerging issue already
16:07imirkin: highly unlikely.
16:07imirkin: it did not seem easy
16:07karolherbst: is it that makeCompound part?
16:07imirkin: i tried a few easy things and it wasn't enough
16:07pmoreau: imirkin: Ok, will send the patch for nv-report then. :-)
16:07imirkin: it's the thing where you copy all the defs into one master node
16:08karolherbst: you mean that extending of liveRanges?
16:08imirkin: 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:08imirkin: karolherbst: no, the literal copy of lval->defs into the merged lval's defs.
16:08karolherbst: okay, let me check
16:08karolherbst: yeah, I don't do it anymore for merges
16:08karolherbst: or splits
16:09imirkin: well that'll definitely "fix" things, although it'll break a lot of others ;)
16:09karolherbst: fix by elimination ;)
16:09karolherbst: but I think I fixed most of the stuff I broke
16:09karolherbst: only one last thing missing
16:09imirkin: that could well be.
16:09karolherbst: and it's the step where the splits gets eliminated
16:09karolherbst: than the register allocation is broken
16:11karolherbst: imirkin: this is basically the issue I am fighting with: https://gist.githubusercontent.com/karolherbst/57d91f1c7cb634cf0599641efd7c3a2c/raw/9c7cbf81dde99ac36f388c585953ea02e7c9074c/gistfile1.txt
16:12imirkin: yeah you can't do that ;)
16:12imirkin: the live range needs extending
16:12imirkin: that's why the defs got merged
16:13karolherbst: yeah, I know
16:13karolherbst: but if they get merged, we can't spill anymore
16:13karolherbst: and because we can't remove spilling, I thought removing the merging is one way out
16:13imirkin: ok, well this isn't a situation you can solve with random programming
16:13imirkin: you have to sit down and properly reason about the issues
16:13imirkin: and come up with solutions to them
16:13karolherbst: yeah I know
16:14karolherbst: but at least the random programming gave me enough knowledge that I kind of understand the code better
16:15imirkin: yeah. i'm a big fan of just trying things to see what happens and to gain a better understanding
16:15karolherbst: I already thought about have two kinds of live ranges
16:15karolherbst: but mhh, that sounds troublesome
16:16karolherbst: and would only be a workaround
16:16karolherbst: 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:17karolherbst: that's more or less the issue
16:18karolherbst: 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:20karolherbst: Nouveau shouldn't end up being a two men show
16:20imirkin: yeah, it's possible things will ease up in a few months, dunno
16:22karolherbst: 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:22imirkin: and i'm still generally around on irc, so it's not like i'm totally gone
16:23karolherbst: helping with knowledge is very important in the end
16:25imirkin: what little of it i have...
16:34karolherbst: imirkin: ohh I think of the OpenGL stuff you know the most from us, I think
16:35karolherbst: and hopefully on the compiler side I will get close over the next months soon :)
19:25duttasankha: 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:45imirkin: duttasankha: that list was hopeless out of date. i think i killed it ~4 years ago
19:49imirkin: might still exist though... maybe i just delinked in
20:14duttasankha: 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:16imirkin: not sure what you're looking for, but i think that i can say with some certainty, "none"
20:16imirkin: closest to being fully re'd is probably the Riva 128? not sure.
20:39duttasankha: 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:41imirkin: 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:41imirkin: [but really if you're looking for open-source support, you should definitely go with AMD]
20:42imirkin: currently the best supported GPU's all around are the second-generation keplers, i.e. GK110 (high end) / GK208 (low end)
20:43imirkin: you get reclocking with those, and you also get 256 registers which doesn't stress our RA quite as much
20:46imirkin: [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:00karolherbst: imirkin: how much should the K80 have?
21:00imirkin: karolherbst: iirc it has like 128K or 96K. i forget.
21:01imirkin: but i don't even know how to identify it
21:05duttasankha: 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:06imirkin: ok. there's no support for CUDA on nouveau (unless you count gdev, but i've never personally played with it)
21:11duttasankha: 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:12duttasankha: so I am looking for a GPU where the details that have been mentioned is valid
21:13imirkin: ok. i'm less familiar with the counter stuff. i'll let others comment. i thought we had it for all chips.
21:13imirkin: but perhaps that's a different counter
21:13imirkin: global counters vs sm counters? dunno
21:13duttasankha: the details that are pertaining to nvidia hardware...and a nvidia hardware where CUDA is supported
21:14imirkin: ok. i guess i have no clue what you're asking. ignore everything i've said - nevermind.
21:16duttasankha: 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:17duttasankha: either in envy/nouveau
21:20imirkin: yeah... it's a way to access vram through mmio
21:21duttasankha: 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:21imirkin: duttasankha: http://envytools.readthedocs.io/en/latest/hw/memory/peephole.html
21:21imirkin: the latter part of the table comes out a little wrong on there
21:22imirkin: you can read it a little better here: http://envytools.readthedocs.io/en/latest/_sources/hw/memory/peephole.rst.txt
21:23duttasankha: 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:24duttasankha: I have gone trough the first one...but the later onw was unknown to me...
21:31imirkin: just look for that register usage
21:35imirkin: duttasankha: https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nvkm/engine/sw/gf100.c#L49
21:35imirkin: that's an example of using peephole to write vram
21:37duttasankha: okay..thanks so much.. i would look into it...