08:01 asdqueerfromeu[d]: skeggsb9778[d]: So I guess it should be enabled by default to make more people battletest it (if there aren't any bugs filed against it already)
08:18 tiredchiku[d]: ermine1716[d]: what's the parameter?
08:21 asdqueerfromeu[d]: tiredchiku[d]: It's as simple as `atomic=1` (Actually it's `nouveau.atomic=1` in the cmdline)
08:25 tiredchiku[d]: seems to be undocumented on the website 😅
08:25 tiredchiku[d]: and am on phone
11:02 nef9324: Hi, does anyone know how I can work around a persistent "training failed" error? GTX 960 with DP -> HDMI adapter. TV goes black after a second of showing the regular boot messages. Arch Linux with latest (6.13.5) kernel. Please let me know if there's somewhere else I should be asking too. Thanks!
11:03 nef9324: The two relevant log lines:
11:03 nef9324: nouveau 0000:01:00.0: disp: outp 04:0006:0f44: training failed
11:03 nef9324: nouveau 0000:01:00.0: drm: [DRM/00000004:kmsOutp] [DP_TRAIN retrain:0 mst:0 lttprs:0 post_lt_adj:0 nr:4 bw:540000] (ret:-1)
12:24 nef9324: Oh, and the adapter works if I use the proprietary drivers or disable modesetting
14:58 snowycoder[d]: For instructions that work with `AttrAccess` (al2p, ald, ast), is it ok to swap the order of address and offset? It makes the code a bit easier and uniforms the ISA output with other memory operations: `[reg+imm]`. (also, what do these instructions do? they are not documented anywhere on the internet)
15:00 snowycoder[d]: short update for the parser: those are the only missing ops, so maybe in a few days we might have NAK unit-testing
16:29 gfxstrand[d]: Maybe? As long as all the `Src` stick together, it's okay.
16:30 gfxstrand[d]: But the only way the `AsSlice` trait works is if all of the `Src` and all of the `Dst` are consecutive
16:32 snowycoder[d]: gfxstrand[d]: I'm not talking about field reordering (although I did quite a bit of that since proc-macro follows field order by default).
16:32 snowycoder[d]: I was talking about output, `AttrAccess` ops always print `[imm+reg]` (because `imm` is the address and `reg` is the offset?), while other ops print `[reg+imm]`
16:38 gfxstrand[d]: Oh, yeah reg+imm is fine
16:49 mhenning[d]: snowycoder[d]: ald/ast are used for some things like vertex shader inputs/outputs
16:50 mhenning[d]: a lot of the graphics specific stuff is harder to find info about because anyone using CUDA doesn't care about it
16:50 mhenning[d]: take a look at nak_nir_lower_vtg_io.c if you want to see details
16:50 gfxstrand[d]: Side note: I kinda want to get rid of AttrAccess
16:51 gfxstrand[d]: I grouped some things like that early on because I thought there was more of a pattern to the ISA than there is.
16:51 gfxstrand[d]: But there are some fields that aren't used for certain instructions and we assert in the generator and pass dummy values in `from_nir`.
16:52 gfxstrand[d]: So it wouldn't so much be getting rid of it as flattening it into the ops themselves and removing the unused fields.
16:53 snowycoder[d]: If you want I can flatten it, it would also simplify parsing ops since it could then be auto-implemented
16:59 gfxstrand[d]: Go for it.
16:59 gfxstrand[d]: Feel free to make that an MR ahead of the parser if you want.
17:15 snowycoder[d]: al2p supports the `patch` flag but it's not touched during passes and in lowering there's an `assert!(!self.access.patch)`.
17:15 snowycoder[d]: Should I remove it and put the assert in from_nir?
17:39 gfxstrand[d]: The emit code has `assert!(!self.access.patch)`. Delete it.
17:40 gfxstrand[d]: (By which I mean delete `patch` from `OpAL2P`.)
17:45 gfxstrand[d]: snowycoder[d]: Basically, look at nak/sm70.rs and nak/sm50.rs for the `encode()` implementation of those ops and if both assert that one of the `AttrAccess` fields is a particular thing, then it can probably go.
17:46 snowycoder[d]: Yep, did that, I only hesitated since "patch" was used in the Display, so I thought I was missing something
23:48 gfxstrand[d]: mohamexiety[d]: Do you remember where this 128B stride limitation for render targets came from?
23:48 gfxstrand[d]: Did we just figure that out by poking at it?
23:48 mohamexiety[d]: for linear?
23:48 gfxstrand[d]: yeah
23:49 gfxstrand[d]: Because looking at the texture headers, it only appears to be 32B
23:50 gfxstrand[d]: And nouveau GL is handing me an image with a stride of 64B
23:51 mohamexiety[d]: checking back, it seems to have been just poking at it, yeah. we'd get GPC exceptions (trying to draw outside the image) until we tried 128B
23:51 gfxstrand[d]: kk
23:58 gfxstrand[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1346995304603451392/snapshot.png?ex=67ca36a2&is=67c8e522&hm=93329d978ca1f5d0af5588eaa8c860290208e0d2ff8f47471f77f0871ee6da75&
23:58 gfxstrand[d]: And here I thought we figured out a plan where dma-buf import from nouveau GL would work. 😭
23:59 airlied[d]: did you find the hole in the plan?
23:59 gfxstrand[d]: Well, I got a corrupted screenshot.
23:59 gfxstrand[d]: I haven't found the hole in the plan yet, though.