07:23leberus: skeggsb: Hi Ben! I got an e-mail from kbuild test robot. Looks like patch 2 is failing to build on arm due to invalid pointer type. Should I do something? Just asking because since the patch was already merged in your git branch. Thanks ;)
07:26xen: leberus: also fails to build on x64
07:27xen: or at least 2 days ago it did
08:16leberus__: I guess something has changes in the middle. I could send v9 solving those issues if Ben is fine with that
08:25pmoreau: leberus__: If Ben hasn't send your patches to Dave yet, he can still squash the current version he has with a fixup patch, rebase and pick the new version.
08:25pmoreau: *or rebase and pick
10:05leberus__: pmoreau: yeah, i guess that would be another option, much easier :)
10:23pmoreau: leberus__: On the other hand, the message was about Dave's tree having the warning, so you'll need to send a fix patch.
10:54leberus__: pmoreau: just a fixpatch or a whole v9? And in case a fixpatch, should I specify that mus be applied on top of the series I sent?
10:58pmoreau: leberus__: Meh, I misread the mail… Your patch has not been merged by Dave yet, it was just tested against his tree, so please ignore my previous comment
11:00pmoreau: No need to send the other patches of the serie if you are not modifying them, so a v9 of the failing patch should be fine I guess.
11:04pmoreau: leberus__: Btw, do you get that warning if you compile Ben's tree with your patches? It could be that you rely on some other patches that changed the type of `.read_string`, which the CI did not have as they were only in Ben's tree, but not in drm-next nor your series.
13:06dboyan_: hakzsam: I want to ask you some questions about AMD_perfmon with nouveau.
13:06dboyan_: What does "metric-issue_slots" mean? Why is it always smaller than "metric-inst_issued"?
13:07dboyan_: And also, "metric-ipc" and "metric-issued_ipc" is either 0 or 1 on my gk208. I don't know if it's expected.
13:08dboyan_: I'm using https://github.com/trtt/apitrace/ to inspect performance counters of draw calls.
13:20mupuf: dboyan_: you need to check the documentation from nvidia
13:21mupuf: the names come from there
13:45pmoreau: dboyan_: The NSight doc or the perf profiler one could help you, for example: http://docs.nvidia.com/gameworks/index.html#developertools/desktop/nsight/analysis/report/cudaexperiments/kernellevel/instructionstatistics.htm
13:47pmoreau: dboyan_: This can be hepful as well http://docs.nvidia.com/cuda/profiler-users-guide/index.html#metrics-reference
16:37biker_rat: Why can't I post on radeon channel?
16:38biker_rat: But, I can do so here?
16:40biker_rat: I would like permission to contact David Airlie on a private channel. I have a question about one of his testing branches.
16:52pmoreau: biker_rat: Maybe they restrict to logged in users, after there was too many spammers?
16:56mupuf: biker_rat: you likely need to register your nick
16:56mupuf: and then you'll be able to speak
19:07pmoreau: hakzsam: Didn't you add a pass in codegen to replace some `ld` by some `mov` instead, when loading from cmem with a known offset?
19:08pmoreau: s/a known offset/an immediate as offset
20:09pmoreau: hakzsam: Is it possible to do a `mov.b64 $r0d c0[0x0]`, or is it only possible to mov 32-bit values?
20:12pmoreau: codegen seems to go with the latter, but it splits `mov.b64 $r0d c0[0x0]` to `mov.b32 $r0 c0[0x0]; mov.b32 $r1 0x00000000`, which is not really what one would expect.
23:49imirkin: pmoreau: it should work ... you might not have set the type size of the c0 arg
23:50imirkin: pmoreau: i.e. there's a distinction between a 32-bit c0[0x0] and 64-bit c0[0x0]
23:50imirkin: and that distinction is very poorly shown in the IR
23:52pmoreau: imirkin: Ah, that could be the case! I was setting the type and size of the symbols before, similarly to other Value*, but decided to remove them, as usually the type of the op is used rather than the one og the Value.
23:52imirkin: yeah ... i think it plays for the split64bitops thing
23:52imirkin: but most of the time it doesn't really matter
23:54pmoreau: \o/ Working way better now! :-)
23:55pmoreau: Well, that part at least
23:55pmoreau: imirkin: Thanks! :-)
23:56pmoreau: I guess 2x consecutive mov from cmem is better than 1 ld.b64, as they have a fixed latency?