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