04:34newbie92: what does calling the FIRMWARE method do? i presume it uploads a new firmware to the card but that sounds dangerous and not something a normal application would want to do
09:35mslusarz: imirkin: yup, https://people.freedesktop.org/~mslusarz/traces/
10:33karolherbst: imirkin: why do we set PIPE_SHADER_CAP_SUPPORTED_IRS to 0 for nv50?
10:50karolherbst: ohh, I guess this is only for compute
11:06karolherbst: seems like the basic stuff already works on NV50 with NIR
11:07karolherbst: might just add support for it as well if the piglit run isn't that bad
12:02pabs3: I'm getting some GPU lockups, wondering if the crashes in my dmesg are interesting https://paste.debian.net/plainh/f7c600b2
12:15karolherbst: pabs3: can you somehow reproduce this directly?
12:16pmoreau: pabs3: Could you please try with 4.16-rc6, or any kernel >= 4.15 to which you apply the following patch: https://patchwork.freedesktop.org/patch/207896/ ?
12:16pabs3: right now just starting GDM will do it
12:17pabs3: only got 4.16~rc5-1~exp1 in Debian experimental
12:18pmoreau: It’s quite possible it won’t fix it, but at least it will rule that issue out easily.
12:18pmoreau: It might take a bit to show up, as it was tagged about 11 hours ago.
12:19karolherbst: pmoreau: nir on nv50 looks quite good by the way
12:20karolherbst: it doesn't have int64 support so I don't hit all the spilling fails kepler1 does....
12:21pmoreau: karolherbst: Awesome! I had my work working fine on it initially (well, as I was developing it on a Tesla card, it’d better work fine there), but broke the support at some point.
12:21pmoreau: I updated my old MBP with an SSD and 8 GiB of RAM, and boy is it faster than with the old spinning disk!!
12:22karolherbst: I hope you replaced the silly optical driver already :p
12:22pmoreau: Nope, I have CDs to extract
12:22karolherbst: external case will do :p
12:22pmoreau: Even if it’s an 9 year old laptop, I’d be ready to use it as my main laptop. Only the screen resolution is a bit annoying.
12:23pmoreau: Meh, I have nothing to put in place of the optical driver.
12:23karolherbst: there are some kits for replacing the optical driver with an old spinning disk (or ssd) and they usually come with external USB cases for the optical drive
12:23pmoreau: True, but that one SSD is enough (at least for now).
12:23karolherbst: I see
12:24karolherbst: ohh, there was something I wanted to try out...
12:24pmoreau: What is going to take most of the space will be: 1) games (but they won’t be that big, as the big ones require better hardware than what the laptop as), and 2) maybe some music.
12:25karolherbst: pmoreau: https://github.com/AlexeySotkin/SPIRV-LLVM/commits/master
12:25pmoreau: Sorry I didn’t get around to resend an updated patch for the clover series. Will do that tonight.
12:26pmoreau: At least I have a “hard” deadline for sending all the Nouveau patches. Otherwise they are going to be postponed by at least six months.
12:26pmoreau: Which would be annoying and sad.
12:26karolherbst: quite so
12:27pmoreau: Yeah, tomeu (or was it hopetech?) pointed out that branch last week. Haven’t tested it yet.
12:28karolherbst: yeah, me neither
12:28karolherbst: I think we will decide tomorrow on what base we want to continue
12:28karolherbst: but I think it would be fine to use that, and post patches for stuff we need
12:28pmoreau: Were you on the call last week?
12:29karolherbst: tom as well :)
12:29pmoreau: I think hopetech wanted to continue with his branch, as it had more history.
12:29karolherbst: more history doesn't mean better history :p
12:30pmoreau: But, but, we shouldn’t forget about the past! :-D
12:30karolherbst: as long as it is kind of feature complete we could just use that one and do merge requests there for missing things I guess
12:30karolherbst: I think the code is quite identical
12:30pmoreau: But yes, it would be great to get a common base.
12:30karolherbst: except the formatting
12:31pmoreau: They merged some memory leakage fixes on the spirv-3.6.1 branch, but they can always be rebased on the new branch.
12:32karolherbst: did you apply your formatting stuff on your branch?
12:32karolherbst: doesn't show up in the history
12:32pmoreau: I’m not sure.
12:33karolherbst: yours vs alexeys branch: 121 files changed, 27483 insertions(+), 26999 deletions(-)
12:33pmoreau: I don’t think so. I made it against the KhronosGroup/SPIRV-LLVM#spirv-6.0 branch
12:33karolherbst: your formatting stuff: +26,666 −26,154
12:33pmoreau: (the formatting stuff got merged in the spirv-6.0 branch btw)
12:33karolherbst: yeah, saw it
12:33karolherbst: he mentioned it
12:35karolherbst: anyway, would be nice if we could merge your stuff like this week
12:35karolherbst: and maube the nir stuff as well or next week
12:35karolherbst: there is just one patch which might break some stuff, I think imirkin wanted to look at it
12:35karolherbst: it is the one fixing some 64 bit stuff in RA
12:36pmoreau: The patch from Connor, regarding compounds?
12:38karolherbst: I didn't see anything weird doing a full piglit run with TGSI though
12:43pmoreau: Would there be someone else that could review your NIR patches? I haven’t made much progress in reviewing them (it takes even more time as I need to learn about NIR in the process), and my free time as decreased as well due to having some extra projects to take care of.
12:44pmoreau: I might still be able to review a few more patches, but I think someone else should take a look at them if you want to have them merge in a not too distant future.
12:44pmoreau: Plus having a second review is always better.
12:45karolherbst: I asked robclark
13:03karolherbst: pmoreau: around 50 regressions on nv50
13:03karolherbst: first run on nv50 :)
13:04karolherbst: most fails are related to 2 or 3 features, so I might be even able to fix those today
13:05hopetech: pmoreau: karolherbst: I'm fine with the Alexey branch. But I asked some changed on the Khronos ML
13:06karolherbst: ahh, k
13:07hopetech: And I will also ask if we can change the build to be able to compile it outside LLVM
13:07hopetech: Like we currently do. It will be easier for the packager
13:13pmoreau: hopetech: Ah, nice! Looking forward to work with the new master and submitting fixes to it. :-)
13:13pmoreau: karolherbst: Not too bad at all! I might be able to do some additional testing on NV50 if needed.
13:36tomeu: hopetech: I think you don't need to ask for the build system to be changed, that's already in the list of requirements
13:36tomeu: we just have to send a PR :)
13:44hopetech: tomeu: oups. True.
13:58pmoreau: hopetech: If you send a PR with the .pc file in it, please include this patch as well (or squash it in, whatever): https://github.com/pierremoreau/llvm-spirv/commit/55926aec1f8346ffb76c2efcf416493b89ed09db
14:13karolherbst: imirkin: any idea why gl_PointCoord might be 0?
14:17hopetech: pmoreau: ack.
14:18hopetech: Once we have an official repo, I will hunt patches from all the forks.
14:19karolherbst: imirkin: duh... in nir I get VARYING_SLOT_PNTC.xy, in TGSI VARYING_SLOT_GENERIC8 .. if I force that to be generic in nir, it works. wondering what is wrong with PNTC then
14:19karolherbst: PNTC is TGSI_SEMANTIC_PCOORD
14:21karolherbst: ah, PCOORD is used on the kepler GPU
14:35imirkin: nvc0+ handles it all a bit differently than nv50
15:06karolherbst: imirkin: and yeah, you were right about that "if (i->src(1).mod & Modifier(NV50_IR_MOD_NOT)) code |= 1 << 8;" thing being wrong for the limm form on nvc0
15:09karolherbst: it seems to be invalid for short imms as well though
15:10karolherbst: or nvdisasm is not telling the truth
15:11imirkin: well, i'm sure it's fine for LOGOP.PASS_B
15:12imirkin: although for simm, dunno
15:12imirkin: either way, an immediate really shouldn't have a NOT modifier
15:12imirkin: since we would have "fixed it up"
15:12imirkin: so an assert is fine
15:12imirkin: both limm and simm
15:15karolherbst: mhh, it is opted away on a glsl or tgsi level already :(
15:15karolherbst: tried to get a logop with a not immediate somehow
15:16karolherbst: right, I will just add an assert
15:22karolherbst: imirkin: this should be fine, right? https://github.com/karolherbst/mesa/commit/6c5a22c53c85103d6560c4f1f25ce9bc6b5b5f63
15:31karolherbst: imirkin: also LOP.PASS_B R0, R0, 0x7ffff.INV;
15:31karolherbst: but maybe the hardware allows it
15:31karolherbst: no idea
15:47pmoreau: karolherbst: Yeah, more mail! \o/
15:47HdkR: high five on the nir support
15:49karolherbst: yeah, I think I am pretty much done because the issues left with piglit and CTS aren't many and users trying that stuff out should get me more hints about what isn't really working out
15:49karolherbst: but generally I didn't find any broken application so :(
15:50HdkR: Obviously the only application worth testing is Dolphin *cough*
15:54karolherbst: I didn't do any perf comparison though
15:55karolherbst: I know that register usage is worse overall, but that's pretty much it
15:55pmoreau: karolherbst: When you change code that has been Rb’ed or Ab’ed and wasn’t mentioned as needing changes by that person during the review, you should drop their Rb/Ab.
15:55karolherbst: pmoreau: uhh right, forgot about that
15:55pmoreau: I’ll try to re-review/ack those patches
15:56karolherbst: okay, thanks!
19:00pmoreau:needs to read about all those ray tracing in games announcement at GDC.
19:40HdkR: pmoreau: Real time ray tracing yo
19:42loonycyborg: yet another plot to make people waste money on videocards while difference will be unnoticeable without examining image pixel by pixel :P
19:48pmoreau: HdkR: I still have my doubts about that, or they have a ton of restrictions on their ray tracing to make it suitable for games.
19:49feaneron: rt ray tracing?
19:49feaneron:searches about it
19:49pmoreau: loonycyborg: Depends what quality of ray tracing you get from it.
19:50HdkR: Maybe the Ageia name is going to come back, just slot in a ray tracing card in next to your GPU :P
19:51loonycyborg: I'd expect it to be really slow too, unless it uses some cool trick like in old Doom :P
19:52pmoreau: feaneron: NVIDIA had a couple of papers on real time ray tracing at SIGGRAPH last year, in one case they would ray trace an image under 10 ms, but it was only single bounce, with 1 sample per pixel, so meh. But still quite impressive
19:54feaneron: ray tracing is the kind of technology that i admire from a 10 foot distance. never had the hardware to get into it
19:55feaneron: and i kinda feel bad with anything related to nvidia these days. if it wasn't for nouveau, i'd have paid for an useless gfx
19:56feaneron: impressive nonetheless
19:57imirkin_: i implemented a (simple) raytracer in college
19:57imirkin_: fun stuff
19:59feaneron: sounds challenging
21:15Subv: mm, how do maxwell GPUs know which render target is the color buffer / depth buffer / others?
21:16stoatwblr: imirkin, any thoughts on that noaccel bug, how long a fix might take to show up?
21:21Subv: ah, RT_CONTROL, i see
21:22imirkin_: Subv: RT[n] = color buffers. ZETA = depth/stencil
21:22imirkin_: stoatwblr: mmmm ... iirc i was blaming skeggsb
21:23imirkin_: stoatwblr: not sure if he's back yet ... but if he is, i'm sure he has a ton of stuff to do
21:23imirkin_: stoatwblr: i'd file a bug so it doesn't get lost
21:24imirkin_: Subv: RT_CONTROL is the type of thing that probably seemed like a good idea, but afaik is never used in practice. it allows remapping the order of RT[n] vs the shader outputs.
21:24Subv: oooh, thanks!
21:24imirkin_: which is why it's set to a fixed 076543210 value
21:25imirkin_: [leading 0 == in octal]
21:29stoatwblr: I don't even know where to start on that, just "crashes if noaccel isn't set" won't be enough I'm betting.
21:30imirkin_: include dmesg including nouveau probe, xorg config, and xorg log
21:30imirkin_: (attach, don't link pastebin or some such)
23:20brian|lfs: I was told to come ask you all for a patch to do 1080-ti video cards in SLI
23:20brian|lfs: is there such a patch
23:32brian|lfs: I was told to come ask you all for a patch to do 1080-ti video cards in SLI
23:32brian|lfs: is there a patch for SLI sorry forgot I asked a question and rebooted
23:35brian|lfs: didn't think there was but figured worth a shot