01:07 Lyude: tracked down what looks like the problem
01:08 Lyude: (also airlied it turns out there was another irq debugfs thing I didn't have enabled)
01:08 Lyude: looks like that commit made it so we can get two MSI irqs allocated to the same vector
01:08 Lyude: which, obviously doesn't work very well
01:12 airlied: Lyude: that does seem suboptimal
09:15 karolherbst: uhh
09:15 karolherbst: we reuse the same memory locations on every run
09:15 karolherbst: I mean in vram
09:16 karolherbst: this makes testing... anoying
09:20 karolherbst: pmoreau: uhh local memory is also addressed with 64 bit pointers? annoying
09:21 pmoreau: If it’s s[], it’s 32-bit, but if you’re talking about l[], I would assume 64-bit, but I’m not sure.
09:21 karolherbst: pmoreau: st f32 # s[$r0d+0x0] $r4 (8)
09:21 karolherbst: your code
09:22 pmoreau: Yeah, because I haven’t fixed it
09:22 karolherbst: I see
09:22 karolherbst: wondering why my version fais then
09:22 karolherbst: *fails
09:22 karolherbst: ohhhhh
09:22 pmoreau: But if you look at the binary, it’s only using the low 32 bits.
09:22 karolherbst: the pointer is still passed as 64 bit
09:22 karolherbst: ....
09:23 karolherbst: pmoreau: not quite sure what you can actually fix here
09:23 karolherbst: because the input is 64 bit
09:23 karolherbst: I mean, you can just drop the high bits and hope it is alirght
09:23 karolherbst: *alright
09:24 pmoreau: I was planning on doing that, which should be alright since Nouveau should never return a pointer that addresses beyong 4GiB.
09:24 pmoreau: (For s[] that is)
09:25 pmoreau: Another way would be to add CAPS for the size of the pointers of the different storage class, and have clover use that information.
09:26 karolherbst: mhhh
09:26 karolherbst: we can't really do that
09:26 karolherbst: I mean
09:26 karolherbst: the input is still API defined, no?
09:27 karolherbst: we would just move the cutting bits part into gallium/spir-v/nir/whatever
09:30 pmoreau: Maybe I should just open an issue for that on the SPIR-V repo, to have some feedback from the working group.
09:30 karolherbst: yeah
09:31 karolherbst: I think it would make sense to add support for storage class in OpMemoryModel
09:31 karolherbst: OpMemoryModel Workgroup Physical64 OpenCL
09:31 karolherbst: OpMemoryModel CrossWorkgroup Physical32 OpenCL
09:31 karolherbst: maybe
09:31 karolherbst: uhm
09:31 karolherbst: 32/64 switched
09:32 pmoreau: Maybe
09:33 karolherbst: or a new opcode
09:33 pmoreau: I think a new opcode would be better, or have OpMemoryModel return an ID, and apply decorations on it.
09:37 karolherbst: maybe
10:05 karolherbst: pmoreau: do you know why get_global_id gets converted into a dvec3 thing?
10:12 pmoreau: karolherbst: dvec3, as in a vec3 of doubles?? Woot?
10:12 karolherbst: yeah
10:13 karolherbst: the declaration is like this: OpVariable (OpTypePointer UniformConstant (OpTypeVector (OpTypeInt 64 0) 3)) UniformConstant
10:13 karolherbst: and then has three decorations
10:13 karolherbst: pmoreau: https://gist.githubusercontent.com/karolherbst/0c233c3645d3c3ae2f6f30441ea0f576/raw/0b1b87374647d9b0c9465e8c200481d3630831c3/gistfile1.txt
10:13 pmoreau: BuiltIn should be one of them
10:14 karolherbst: yeah
10:14 karolherbst: just wondering why there are two more
10:14 karolherbst: and even unused ones
10:14 karolherbst: maybe we should run a dce on top of the spir-v before translation?
10:15 pmoreau: Well, that variable is constant indeed, so that makes sense.
10:16 karolherbst: mhh
10:16 karolherbst: meh
10:16 karolherbst: CFG is killing us again
10:16 pmoreau: As for the import, I know it is always there, but I’m not 100% sure why, and think in most cases it could be dropped.
10:18 pmoreau: In the SPIR-V linker, I actually ignore Import decorations on BuiltIn values.
10:19 pmoreau: Maybe the driver should be providing the linker with a SPIR-V module defining those built-ins instead.
10:44 karolherbst: uhh OpTypePointer Function
10:44 karolherbst: things start to get messy
18:28 shtrb: Can someone guide me with '[ERROR]Cannot access secondary GPU - error: [XORG] (EE) Failed to load module "mouse" (module does not exist, 0)' when running optirun (copies /etc/bumblebee/xorg.conf.nouveau to /etc/X11/xorg.conf.d/nouveau.conf , xorg.conf is missing (letting X to identify by itself)
18:28 shtrb: *running Debian
18:29 karolherbst: don't use nouveau.conf
18:29 karolherbst: don't use any x conf at all
18:29 shtrb: even without it getting the same error
18:29 karolherbst: don't use bumblebee with nouveau
18:29 shtrb: oh
18:29 shtrb: thanks!
18:30 karolherbst: there is DRI_PRIME=1 glxinfo
18:30 karolherbst: this should give you nouveau already
18:30 karolherbst: much less overhead and much easier to use
18:30 karolherbst: shtrb: https://nouveau.freedesktop.org/wiki/Optimus/
18:30 shtrb: thanks !
18:30 karolherbst: usually it should autoconfigure itself already
18:30 karolherbst: but sometimes you need to setup things
20:22 Babaorheum: Hi guys, I would like to try Nouveau 3D accelaration with my GTX670MX. But i have an optimus laptop. I must to use PRIME, right ?
21:11 danboyd: what does it mean if git says "error: unable to create file MAINTAINERS: device or resource busy" after I enter 'git bisect bad'?
21:12 danboyd: (trying to track down a nouveau glitch)
21:37 karolherbst: danboyd: maybe out of space? Or maybe some disc error?
22:19 danboyd: don't think so... is there a command I can run that will get it to retry?
22:19 danboyd: I'm like 5 iterations in already and don't want to start over
22:20 karolherbst: danboyd: you can always run git bisect log and see what you marked
22:21 danboyd: karolherbst: ok thanks for the help :)
22:21 karolherbst: danboyd: you can also just git checkout anything and mark it
22:21 karolherbst: or do git bisect --skip
22:21 karolherbst: or was it git bisect skip?
22:21 karolherbst: not quite sure
22:23 orbea: karolherbst: git bisect skip