00:00 imirkin: (the only other situation is binding a layer of a 3d texture as a rendertarget, but there's a special RT[].BASE_LAYER setting just for this situation
00:01 imirkin: Lyude: is it a GTX 660?
00:03 Lyude: imirkin: that's a question for nrr who will be here in a sec
00:03 Lyude: (they are the one having the issue)
00:03 nrr: imirkin: negative. it's a quadro k2000.
00:03 imirkin: GK106 though?
00:03 Lyude: GK107
00:03 imirkin: =/
00:03 Lyude: I'm assuming, anyway
00:04 Lyude: i have the bios for that let me check
00:04 imirkin: looks like it based on the pci.ids file
00:04 karolherbst: Lyude: I have such a Kepler GPU doing that weirdo ctxsw messup
00:04 imirkin: anyways, i was hoping that it was likely to be the "nouveau firmware screws up on some boards sometimes" issue
00:04 imirkin: but i dunno if i've seen it on a gk107
00:04 Lyude: karolherbst: oh?
00:04 karolherbst: yeah
00:04 imirkin: GTX 660's appear to be the most prone to it
00:04 karolherbst: it is a GTX 660
00:04 karolherbst: I didn't had time to verify it
00:04 karolherbst: but it is quite high on my todo list
00:05 imirkin: but there's nothing that *should* be special about them
00:06 Lyude: karolherbst: is the issue imirkin is talking about the same one as you've been seeing/
00:06 imirkin: [yes, it is]
00:07 Lyude: ah... do we ship firmware from nvidia for those?
00:07 Lyude: or is this some of the falcon code we wrote
00:08 skeggsb: we don't ship nvidia firmware before gm200
00:09 imirkin: Lyude: extractable using my script
00:09 imirkin: https://nouveau.freedesktop.org/wiki/VideoAcceleration/#firmware
00:09 Lyude: i mean, I was moreso curious because I was wondering if it was some sort of regression in our fw or not
00:09 imirkin: Lyude: nope, been happening since the dawn of time
00:10 Lyude: Oh.
00:10 karolherbst: yep
00:10 karolherbst: and for some reasons only really affects some GPUs
00:11 imirkin: only *some* GTX 660's, and i think there were reports on a handful of other models, but much rarer
00:11 imirkin: carefully avoiding the ones skeggsb owns, naturally
00:12 imirkin: skeggsb: just double-checking if you saw https://lists.freedesktop.org/archives/nouveau/2018-June/030566.html
00:12 skeggsb: imirkin: yup
00:12 Lyude: well nrr is a friend of mine so if you guys need any kind of info from someone with a card that's showing that issue they can get you it
00:13 imirkin: Lyude: can you check if it starts to work with the nvidia firmware?
00:15 Lyude: checking\
00:15 imirkin: you have to use that specific blob version btw
00:16 imirkin: otherwise my script doesn't pick up the ctxsw firmware.
00:17 Lyude: uhhh, that might be a bit more difficult
00:18 Lyude: I don't imagine they'd want to go through the effort of setting that all up..., is it possible we might be able to get a memory dump from the gpu and use that to adjust your script so it works for newer blob verisons?
00:18 Lyude: or, hm, would that firmware be the same for any old GTX660/670?
00:19 imirkin: huh?
00:19 imirkin: just follow the instructions
00:19 imirkin: it's like 5 commands in a shell
00:19 Lyude: Oh!
00:19 Lyude: i'm sorry, looking at that I thought for some reason you had to install the nvidia driver...
00:19 Lyude: nvm then, that should be easy
00:20 Lyude: i will pass them the instructions and let you know what happens
00:20 imirkin: you have to also boot with nouveau.config=NvGrUseFW=1
00:20 imirkin: and make sure that the firmware is available at nouveau load time
00:20 Lyude: gotcha
00:21 nrr: Lyude: i'm right here. (:
00:21 Lyude: nrr: ^ well, that's what I was about to ask you on telegram
00:22 imirkin: nrr: fwiw my hopes for this are low -- i've really just seen this help people with GTX 660's
00:22 nrr: imirkin: i'm not holding my breath. this is a crash that's been plaguing me for a while, and it's only a real pain when i decide to use the framebuffer on that box.
00:23 imirkin: but like i said, we don't actually understand the conditions that cause it to be necessary, so nothing precludes other boards from being helped
00:23 nrr: right.
00:24 nrr: okay, so, this all said, aside from booting with nouveau.config=NvGrUseFW=1, what else do i need to do to give this a shot? or is that it?
00:24 imirkin: Lyude: if you really want to extract stuff by hand, there's always these instructions :) https://nouveau.freedesktop.org/wiki/NVC0_Firmware/
00:24 imirkin: nrr: make sure those files are in /lib/firmware
00:24 imirkin: and accessible when the nouveau module loads
00:25 imirkin: which is another way of saying that if nouveau is built in, it has to be in EXTRA_FIRMWARE. if nouveau is loaded off initrd, it has to live in initrd.
07:55 BootI386: Hello, just wondering why reclocking isn't supported on Fermi
07:57 BootI386: Are there specific things that prevents it to be enabled, or it hasn't got enough love?
12:35 RSpliet: Booti386: Incomplete code is a good reason for it not being enabled yet ;-)
12:36 RSpliet: Ben and I have made big strides forward with supporting that a little while ago, but I just have no time or energy to invest in it right now.
12:36 RSpliet: And it's largely untested code, quite a lot still to do before it's ready for even ballsy end-users
12:36 karolherbst: RSpliet: btw, did you test skeggsb latest code?
12:37 RSpliet: karolherbst: I tried on the DDR3 NVD9 a while ago, but it needs more love for that. I sent him a patch not long ago to split off NVD9 as that requires handling the new display engine and the altered wait-for-vblank methods that go with it
12:38 RSpliet: But that only solved one issue
12:38 karolherbst: I see
12:38 RSpliet: I have an NVC... something, with GDDR5 lying around that I just didn't get round to testing
12:39 RSpliet: PhD is draining my will to contribute, after all that research day in day out I can't really get myself to do even more computer stuff, and if I do I tire myself too much to perform well as a researcher
12:39 RSpliet: So I had to make the hard decision of putting nouveau on the backburner for a while...
12:42 RSpliet: The sooner I finish, the sooner I'll be on the job market... then we can talk again ;-) Until then, expect little output from me.
14:19 opal: i have a backtrace from a program that received a SIGBUS while trying to do something with the xorg nouveau driver, but nouveau_dri.so itself doesnt seem to have symbols compiled in. the driver is from my system package manager. should i compile the driver myself, with symbols, before bothering to submit a bug report anywhere?
14:19 opal: im guessing the answer is yes but other than that i have a full traceback in the calling program
14:22 opal: last line that actually has useful information is an opengl call
14:24 karolherbst: opal: usually you can install a debug info package
14:25 opal: not in alpine
14:25 karolherbst: why not?
14:25 opal: isnt one available
14:25 karolherbst: okay sure, but why not? Sounds like a bad decision to me
14:25 opal: im not a package maintainer so i dont know
14:26 opal: my best guess would be that the desktop environment doesnt get as much attention as the server/embedded side
14:26 opal: that and... [ ~root ] # apk search -- -dbg | wc -l
14:26 opal: 74
14:26 karolherbst: maybe, but usually those debug info things are not hard to add or should be there by default in the first place
14:26 karolherbst: ouch
14:26 opal: yeah idk either
14:26 karolherbst: well
14:27 orbea: so ask an apline related community how to get debugging symbols?
14:27 karolherbst: it might help if you are able to tell us how to reproduce your issue in a reliable way
14:27 opal: let me see if i can invoke it again
14:28 karolherbst: in the end reproducibility is more important, because it makes things a lot easier to fix
14:31 opal: i'll hold on to the coredump until i re-encounter the issue
14:31 opal: and i'll ask a maintainer about debug symbols
14:56 opal: yeah with my luck it might not be easily reproducible. the crash was in dolphin-emu and now i'm able to play the game a bit before i encounter unrelated errors
15:55 orbea: opal: are you sure its not a dolphin-emu bug?
15:55 opal: i'll check with them too
15:56 orbea: dolphin-emu usually works fine here with nouveau, sometimes slowly
16:48 opal: for the record: my system is using an NVIDIA GeForce GT 730 card
22:26 karolherbst: imirkin: do you remember my dual issueing scheduler?
22:27 HdkR:parks up to learn about a dual issuing scheduler
22:28 karolherbst: HdkR: score change in pixmark piano: score: 1021 -> 1056
22:28 karolherbst: so around 3.5%
22:29 HdkR: Neat. Did it attempt scheduling instructions closer together that could be scheduled simultaneously?
22:29 karolherbst: it is basically a Post RA scheduler reordering instructions in a way, that the compiler is able to dual issue more isntructions
22:29 karolherbst: yes
22:29 HdkR: Ah, post-RA ordering even
22:29 karolherbst: yeah
22:29 karolherbst: won't hurt GPR coun
22:29 karolherbst: so t
22:29 karolherbst: *t
22:30 HdkR: Makes sense
22:30 karolherbst: so that's a big advantage
22:30 karolherbst: we want a real scheduler to run before RA
22:30 HdkR: What hardware did it effect?
22:30 karolherbst: and a dual issue scheduler post RA anyway, kind of
22:30 karolherbst: Kepler
22:30 karolherbst: and fermi
22:30 karolherbst: HdkR: https://github.com/karolherbst/mesa/commit/647ca63d2f56d825c6fbd0fb8633fb2bb02f7c95
22:30 karolherbst: it isn't _that_ much code
22:30 karolherbst: but I think it is a bit broken
22:30 karolherbst: and I want to take a different approach
22:31 karolherbst: HdkR: the other neat benefit is, that it tries to build an infinite chain
22:31 karolherbst: not pairs
22:31 HdkR: Beautiful
22:31 karolherbst: so you should even get the benefit of reduced instruction latenciy
22:32 HdkR: karolherbst: Well with Maxwell you can take advantage of the reuse keyword more effectively in those instances?
22:34 karolherbst: reuse is something else
22:34 karolherbst: if you use the same source in multiple instructions, you can tell the hw that it doesn't need to refetch the content
22:35 HdkR: Right, but if you've moved ops together that could dual-issue, surely you get some of that for free?
22:35 karolherbst: if you dual issue a pair of instructions making use of the reuse thing
22:35 karolherbst: it won't help
22:35 karolherbst: because both instructions have to wait until the reg is fetched anyhow
22:35 HdkR: I'm thinking more of the chains that would naturally occur
22:35 karolherbst: sure, but I think we already do that
22:35 HdkR: ah
22:35 karolherbst: not _quite_ sure
22:35 karolherbst: but yeah, that would be something we may be able to take into account when doing a pre RA scheduler
22:36 karolherbst: in a post RA scheduler you know the reg being used so you can make a better decision
22:36 HdkR: Right
22:36 karolherbst: but you have less freedom moving instructions
22:38 HdkR: I have a weird desire to get better at instruction scheduling
22:39 HdkR: Anything instruction scheduling related I like seeing :D
22:44 karolherbst: :D
22:55 RSpliet: Fermi doesn't do dual issue afaik
22:56 karolherbst: ohh right
22:56 karolherbst: well
22:56 karolherbst: it does
22:56 karolherbst: because even g90 did
22:57 karolherbst: but implicit
22:58 karolherbst: it is all kind of weird anyway
22:59 karolherbst: I think the only hw having a "real" scheduler being able to issue two instructions at once are on SM 2.1 - 3.7 or something
23:00 RSpliet: It issues one insn per warp per cycle, but from two warps concurrently per SM. There's no "dual issue" concerns for the scheduler, but all the other regular scheduling problems still have relevance
23:02 RSpliet: Not sure about the issue latency of the various instructions on Fermi. Could be that if you issue a SFU instruction in cycle 1, you can't issue one for 4 cycles. Best to try and fit a few FP instructions in between to avoid pipeline stalls... that kind of thing
23:02 RSpliet: (where 4 is a completely fictional number :-D)
23:03 karolherbst: sure
23:03 karolherbst: and usually it is more complex than that
23:03 karolherbst: you might be able to issue 3 SFU instructions after each other, but then you have no slots left
23:04 RSpliet: Yeah, but because there's two warp schedulers that may or may not be running in lock step with each other, run-time behaviour is not deterministic from a compiler perspective anyway.
23:06 karolherbst: I think this is well defined actually
23:06 karolherbst: or maybe not, never really gotten into this kind of stuff
23:07 RSpliet: Different warps could have different run-time behaviour due to e.g. variable # iterations in loops. It might resynchronise every work-group (ehh... there's a CUDA equivalent term for that :-D) on Fermi
23:08 RSpliet: Blocked resources could cause warp schedulers to run out of sync too. Only one can issue an SFU instruction at the time. And considering there's not one per work-item in the warp, an SFU insn is probably blocking for multiple cycles
23:09 RSpliet: This is all really fun stuff to work out for working out the benefits and limitations of an insn scheduling pass :-)
23:09 karolherbst: right
23:42 karolherbst: imirkin: any thoughts on how to remove the need of gallium definitions inside codegen or the input/output slotting stuff?
23:43 karolherbst: worst case I duplicate definitions and just add codegen versions and map from TGSI or mesa/core to that