01:03gnarface: imirkin: hey, incidentally (RE: hardware decoding on G92 chips) with regards to this bug here, there's a final post at the end about him having some success doing an "mmiotrace" of the binary driver - would that file he posted in theory work for me? i'm not clear on how to use it https://bugs.freedesktop.org/show_bug.cgi?id=82835
01:05imirkin: gnarface: the success was in doing the mmiotrace of the blob, not in getting nouveau's vdpau stuff working
01:05gnarface: oh, so this trace doesn't help me one bit :(
01:05gnarface: i see now that its just a file with a bunch of numbers in it
03:40nyef: It occured to me tonight that further work on stereoscopy beyond the kernel-side work to expose the 3D modes to userspace is not specific to nouveau at all, even for the 3D vision thing.
03:41nyef: Obvious in retrospect, and probably means that at least some of you already knew it as well. (-:
03:43imirkin: yeah, there's a client cap which enables them
03:43imirkin: iirc you found that
03:45nyef: Yeah, but the practical upshot is that this is the wrong channel to discuss progress beyond the kernel driver.
03:46imirkin: mostly, yes :)
03:46imirkin: #dri-devel is the place that'll have all the relevant people...
03:46nyef: Thank you.
03:48nyef: And, changing the subject a very little, I just picked up a 3D Vision Ready monitor with DP and HDMI inputs, so I'm hoping to be able to get useful USB traces from the windows driver on it.
03:49nyef: The downside being that I managed to forget to bring the recovery disks for my hardware with me, so the closest to windows I'm going to be able to use for the next two weeks is ReactOS, and I don't think that's going to work too well.
03:50imirkin: you can usually download them from the manufacturer
03:51nyef: Hrm. That might be worth a try. Thank you.
04:04nyef: Between two machines, I have one "service tag". And apparently it's no good for getting a recovery image. /-:
04:05nyef: A two week wait won't kill me.
04:05imirkin: dmidecode should show the info
04:05nyef: ... no matter how hard it tries.
04:10nyef: Okay, dmidecode does show me the same service tag as is on the sticker on the bottom of the machine. Which means that I should be able to get another service tag from the other machine.
04:23nyef: No luck on the second service tag, either. So, while I wait to get access to the actual recovery CDs, it costs me little to try ReactOS, as much as I doubt that it'll help.
04:27nyef: (Not about to try downloading from a third-party source. Bad enough running windows, not worth the risk of getting non-manufacturer-supplied malware in the recovery images.)
04:27airlied: just get Windows 10, and have 90 days to activate it, and wipe it
04:30imirkin: nyef: if you have something new enough for win10, it should auto-activate based on the acpi tables
04:30imirkin: win7 as well actually
04:35nyef: Eh, two weeks still won't kill me, and should give me time to work on other stuff, like trying to figure out userland support for HDMI-based 3D, or there's a list of projects that I could work on in the meantime.
04:36imirkin: nyef: get your patches into upstreamable form for e.g. hdmi eld + audio
04:36imirkin: nyef: and also for the 3d mode setting stuff
04:36nyef: That, too.
04:37nyef: At this point, it's mostly reformatting the commit messages and adding a Signed-off-by line.
04:38nyef: The time-critical one is the HDMI ELD fix for gt215, as it's uncontroversial enough that it might yet go in during the 4.10 cycle.
04:38nyef: (One-character change, that fixes audio on some machines? Not anticipated to be a hard sell.)
04:39imirkin: it's not about the number of characters
04:39imirkin: it's about whether it makes sense or not
04:40nyef: Yeah, I know, and it does make sense.
04:45nyef: I saw something about needing compiler hackers for something with nouveau?
04:45imirkin: there are some compiler things that need improvement
04:46imirkin: we desperately need instruction scheduling logic
04:46imirkin: but that's a major project
04:46nyef: How major is major?
04:46imirkin: there's a trello board with some stuff - https://trello.com/b/ZudRDiTL/nouveau
04:47imirkin: i dunno - i figure it'd take a month of full time work to get it right. maybe 2 weeks for someone who was super-familiar with all aspects of it already.
04:49kingsley: An outfit named "Ministry of Freedom" says they sell a computer that ...
04:49kingsley: "comes with a high-end, libre-compatible NVidia GTX 660Ti or 670 with 2GiB Video RAM (we will ship the fastest one), fully supported by free software in Libreboot and the Linux kernel, using the nouveau driver"
04:50nyef: One-month major is a lot better than half-year major. (-:
04:50kingsley: How would you research how reliable its video is?
04:51imirkin: kingsley: define 'reliable'
04:51kingsley: imirkin: That's a good question.
04:51imirkin: kingsley: i assume it's just off-the-shelf hardware, so it should work as well as any kepler-class gpu with nouveau...
04:52kingsley: It seems to me that "reliable" is different than speed, and implies that no software crashes because nouveau is incompatible.
04:52imirkin: nouveau will crash. early and often.
04:53skeggsb: that's somewhat of an exaggeration...
04:53imirkin: a little
04:53imirkin: but depending on the software, things die
04:53imirkin: like the current kde situation
04:54kingsley: imirkin: Would you say that nouveau would crash early and often with NVidia GTX 660Ti or 670 cards?
04:54imirkin: i never get crashes, it's pretty rock-solid even in low-memory conditions. but i don't anything fancy (i.e. i have a 20-year-old desktop)
04:54nyef: Are the compilery bits in the mesa tree, or elsewhere?
04:55imirkin: nyef: mesa, yeah. src/gallium/drivers/nouveau/codegen
04:55kingsley: imirkin: I'm glad you mentioned kde. You reminded me that I use a kde based video editor, which I've noticed crashed more with nouveau.
04:55imirkin: kingsley: there are definitely ways to use it so that it's rock-solid. just that it's equally easy to crash if you do the "wrong" thing.
04:56kingsley: imirkin: When you wrote... "there are definitely ways to use it so that it's rock-solid", which "it" were you referring to? Nouveau?
04:57imirkin: kingsley: yeah, nouveau.
04:57imirkin: kingsley: if you want reliable open-source graphics, definitely go with AMD
04:58nyef: ... what a horrible sentiment. )-:
04:58kingsley: imirkin: Do you happen to have any thoughts on how I might research if the Ministry of Freedom's computer is one of those rock solid ways?
04:58nyef: It's not usually the hardware that's the easily-crashed bit.
04:58imirkin: kingsley: it has to do with the software you use every day, not on who slaps a piece of plastic with a logo on a china-made generic case.
04:59kingsley: imirkin: Ah. So perhaps the MoF's computer would work fine with Nouveau until I tried using a kde application.
04:59imirkin: kingsley: exactly.
05:00imirkin: kingsley: tbh i think that thing is completely ridiculous
05:02kingsley: imirkin: If I ask you nicely, will you please elaborate on which "thing" you think is completely ridiculous?
05:04imirkin: kingsley: the marketing and pricing around the box you pointed at
05:06kingsley: imirkin: For what its' worth, I also have some 20 year old parts in my desktop. It's like Frankenstein.
05:07imirkin: what i meant by 20-year-old desktop was the software underpinning my desktop experience
05:07kingsley: o i c
05:10nyef: ... That D16 desktop looks like it could be out powered by a couple of good laptops working in concert.
05:10nyef: Good *four year old* laptops.
05:12kingsley: nyef: Really? I read it supports 32 2 GHz cores. Maybe it'd be faster for parallelizable tasks that are not bottlenecked by a single executable thread.
05:16nyef: What are you really going to do that'd need that much CPU power and needs the full shared-address-space treatment?
05:16kingsley: machine learning
05:17imirkin: note that nouveau supports neither opencl nor cuda
05:17nyef: ... that's more towards the six-month-major project side, I presume? (-:
05:18imirkin: nyef: mmmmm ... probably less. opencl could be hooked up by teaching nv50 ir how to consume spir-v or something else that llvm can produce.
05:19imirkin: pmoreau's been working on it for the past year or so on and off
05:30kingsley: Thanks for your thoughts.
05:48nyef: ... Took a quick look at the codegen stuff. I'm fairly sure that I'm not going to be touching that this month, and will need to do some introspection and planning before I decide to touch it at all.
05:49imirkin: nyef: my advice is stick to shorter projects until you get your bearings
05:49imirkin: nyef: also, the other advice is do things that you find interesting. IME, that'll cause them to get done a lot more reliably than stuff that just needs to be done but that you don't care much about
05:55nyef: Right, plus there's the matter that compiler hacking is delicate work, and it takes a while before a regular (or semi-regular) contributor is really trusted to do major work.
05:58imirkin: if you can demonstrate that you understand what's up, it shouldn't take long to establish that trust. but yeah, the compiler is subtle and quick to anger.
05:59imirkin: anyways, gtg. do send your various hdmi patches :)
06:00nyef: I hope to have the first patch ready to send tomorrow^Wlater today.
06:01nyef: ... But it's unlikely to be this morning, between sleep and work stuff.
07:10gnurou: haagch: haven't tried yet, are you running into issues with it?
08:25haagch: gnurou: yes, it runs fine for a little while, but after some seconds or minutes clicking around, it throws some nouveau errors in dmesg and freezes the screen or locks up the whole system
08:26gnurou: haagch: can you open a bug on my github repo and paste these errors?
08:27haagch: first i'll have to reenable my systemd journald
08:30haagch: by the way, with the renderonly mesa I only have the permission problem with /dev/dri/card1, but not with /dev/dri/renderD128, so basically reverting https://github.com/Gnurou/mesa/commit/a97f868a806ab4f1aaab88c72d4b55bfb18cc3cc makes everything work
08:30gnurou: haagch: interesting, but beware of breakage - I don't know where, maybe with Wayland?
08:31haagch: yea, i guess only wayland uses FLINK, not sure
08:33haagch: i'm using upstream nouveau with 4.10-rc2 by the way, should I try your linux repo?
08:39haagch: this time it sorta recovered after some errors: https://gist.github.com/ChristophHaag/e8ce762d6187332bf8e71e5ce385b967
11:04haagch: well, I give up. kwin_x11 insists on shoing nothing but the fullscreen loading screen, even after I restart it with DISPLAY=:0 kwin_x11 --replace with ssh
11:04karolherbst: haagch: you mean the plasma loading thing?
11:05karolherbst: disable it in the systemsettings, cause it is super annoinyg
11:05haagch: the K in the gear on a black screen
11:05karolherbst: it also keeps displaying as long as a user sessoion application is starting
11:05karolherbst: or so
11:05karolherbst: disable it ;)
11:05haagch: ah i see, plasmashell didn't start
11:06karolherbst: start it by hand then :D
11:07haagch: then X segfaults
11:08haagch: i'll try after updating to 1.19 later
11:19funfunctor: haagch: hi
11:19funfunctor: kwin is unfortunately horribly un-maintained due to lack of developer mind share.
11:24karolherbst: funfunctor: which is totally untrue
11:25funfunctor: karolherbst: how so, relatively speaking its just marting pushing forward for kwin compared with the gnome community. I wish it was different as I much prefer plasma desktop!
12:01haagch: ouch, current fluctuation. router and pc went off for a second and I assume everything else too
12:01haagch: for being just one person, martin is doing a pretty good job
12:01haagch: even doing the wayland port
12:29karolherbst: it's unfair to say that he is doing it alone, because he doesn't do everything. A lot of stuff is also within qt or other KF5 components which gets shared. Anyway, kwin is pretty stable overall, so I doubt that there is actually a lot of development efforts required
12:31karolherbst: and anyway, there are other active authors as well
13:05haagch: with xorg 1.19 the renderonly gallium driver doesn't work anymore
13:06haagch: segfaults with ro being null: 0xb5b99620 in renderonly_scanout_for_resource (rsc=0x3fcf20, ro=0x0) at renderonly/renderonly.c:167
13:40tacchinotacchi: so the PMU codes
13:40tacchinotacchi: are they the same for every card?
13:41tacchinotacchi: Also, I can't find the PMU ISA option in envydis
13:41karolherbst: tacchinotacchi: it's a normal falcon
13:42karolherbst: but the SEQ opcodes are already implemented on the PMU
13:42karolherbst: or at least I don't think we need a new one, because we already have everything we need for kepler
13:42karolherbst: what needs to be done is to construct the fitting SEQ scripts which gets send to the PMU
13:43karolherbst: and this is done within the nvkm/subdev/fb/ram* files
13:53tacchinotacchi: https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-RISC-V-Next-Gen-Falcon ouchie
13:53tacchinotacchi: well my fermi still has falcon luckily
14:03karolherbst: tacchinotacchi: yeah, but that is pretty much irrelevant to memory reclocking right now. did you talk to RSpliet ?
14:04karolherbst: you should
14:04tacchinotacchi: my internet is coming and going
14:04tacchinotacchi: no chance
14:04tacchinotacchi: what should I talk to him about?
14:04karolherbst: fermi memory reclocking
14:05tacchinotacchi: should I ask him about something more specific or take him as a mentor for a while? lol
14:10karolherbst: he was working on it, he should know most about it
14:10haagch: well, I guess plasmashell has reasons not to start https://gist.github.com/ChristophHaag/29d9d9e44cd583eba0f4b2f4e759ecf4
14:17karolherbst: haagch: ohh tegra
14:17karolherbst: haagch: output of glxinfo
14:22haagch: glxinfo: https://gist.github.com/ChristophHaag/63b0979e9ac33b31d7c04807d4905ba1
14:22haagch: rebased the renderonly thing on mesa master: https://github.com/ChristophHaag/mesa-mesa/commits/renderonly
14:23haagch: wasn't nvc0 supposed to be on opengl 4.5? is it just for some series and not for kepler?
14:28karolherbst: haagch: you should get GL 4.3 at least
14:29karolherbst: but it could be that something is missing on tegra
14:29karolherbst: okay, it seems like that OpenGL works in theory?
14:29karolherbst: any problems running glxgears?
14:29haagch: yes, glamor and xfce with xfwin4 compositing is very stable
14:29karolherbst: I see
14:30haagch: but kde plasma...
14:30haagch: there are a couple of bug reports in the bug tracker that sound similar to the problems I've seen
14:30karolherbst: imirkin: do you have any idea? nouveau 57000000.gpu: gr: DATA_ERROR 0000000c [INVALID_BITFIELD] ch 12 [040066b000 plasmashell] subc 0 class a297 mthd 2380 data 07800000
14:31karolherbst: or gnurou ?
14:33gahhw: are there any news about fixing the full system crash on nouveau on many different older nvidia cards?
14:33gahhw: (on kde plasma)
14:34gahhw: you just have to download the recent daily kde-neon image, boot it and wait 10seconds for the crash
14:39austriancoder: haagch: kde5 is not stable on nouveau (at least for me)
14:41haagch: austriancoder: good to know that i'm not the only one, thanks
14:47karolherbst: gahhw: yeah, somebody is working on that afaik
14:47karolherbst: there are some multithreading issues which aren't that easy to fix
14:48tacchinotacchi: ok before i can talk to rspliet
14:49tacchinotacchi: anywhere i can read about ddr3 specs?
14:49tacchinotacchi: or does the way ram communicates with the board change from producer to producer?
14:49gahhw: karolherbst: its really bad that when you buy now a new computer and have a nvidia integrated gpu, you get this complete crash on plasma
14:50karolherbst: tacchinotacchi: there are specifications for each type of ddr3 ram, but RSpliet knows about most of it, so you would save you a lot of time if you wait for him to reply, or just write him an email
14:50tacchinotacchi: I'm kind of new to IRC, is direct message a good way to ask him?
14:51mupuf: tacchinotacchi: just write his name in this channel
14:52mupuf: he will answer when he has time
14:52karolherbst: gahhw: yeah sure, but you need for that to be fixed 1. devs who care to spend their spare time on this 2. devs who have access to such hardware (I have not, I was running it on my gpu and it never crashed on plasma, allthough there are still things I could try to let it crash) 3. devs who have actually enough time to spend to solve such a big issue
14:54gahhw: karolherbst: should i send you such hardware so that you also have it?
14:54karolherbst: gahhw: I have no desktop computer at all
14:55karolherbst: and also, I have poor knowledge about the userspace stuff, so I wouldn't be of big help to begin with
14:55gahhw: should i send you a desktop computer?
14:56karolherbst: gahhw: ping skeggsb, maybe he could send you some patches you could try out, but I have no idea in what state his work is so far. Last thing I heard was, he was warking on it and got decently far
14:58gahhw: karolherbst: here is a mainboard, when you buy it you would at the moment never be able to use nouveau+plasma: https://www.mindfactory.de/product_info.php/ASRock-N68C-GS4-FX-NVIDIA-nForce-630a-So-AM3--Dual-Channel-DDR2-DDR3-mATX_991396.html
14:59gahhw: karolherbst: here a cheaper version of it: https://www.mindfactory.de/product_info.php/Asrock-N68-GS4-FX-R2-0-fuer-AM3-AM3--nf630a-GF7025-VGA-Sound-retail_1131302.html
14:59tacchinotacchi: rspliet: they tell me this a better way to ask
14:59tacchinotacchi: oh is it case sensitive? .-.
15:01karolherbst: gahhw: I am well aware that this issue is like the most important one to a group of users. If I would be able to fix it, I would have already tried to do so. I am already planning to get me a desktop machine at some point, but I have for one other important issues to care about, secondly time is quite limited on my side anyhow
15:02tacchinotacchi: RSpliet: lel
15:02karolherbst: gahhw: there are devs who can fix such issues much better/faster than I am able to, but either they don't care or prioritize differently. At least skeggsb is working on it and he is getting actually paid for his work on nouveau, so waiting for him is most likely the best thing you can do
15:03gahhw: karolherbst: thanks for the information. i have wrote skeggsb :)
16:01imirkin: karolherbst: 2380 = CB_SIZE. max value is 0x10000. no way we're writing that into CB_SIZE. probably some multithreading fuckup.
16:03karolherbst: most likely
16:03karolherbst: let's see when skeggsb is done with his stuff
16:04imirkin: probably won't be for a while
16:04imirkin: i'm recommending people either don't use kde or don't use nouveau_dri.so.
16:04imirkin: i guess i should reach out to the kde folk to see if they have some better solution
16:04imirkin: do you know where their developers hang out by any chance?
16:05karolherbst: there are like 40 channels or so
16:06imirkin: well, if it's the same people that hang out in all of them, i don't really care
16:06karolherbst: most likely not
16:06karolherbst: #kwin is for kwin obviously
16:07karolherbst: and #plasma ist for plasma :D
16:07karolherbst: I think those should cover the most important ones regarding OpenGL
16:08karolherbst: by the way, the qt webengine patches aren't upstreamed afaik. It's the distributions job to apply those
16:08karolherbst: at least this is the last thing I've heard
16:10imirkin: i don't really care. i just want to get on the same page as them re advice that we/they hand out
16:11imirkin: and briefly, how are plasma and kwin related?
16:11imirkin: are they the same thing? diff things? competing things?
16:11karolherbst: plasma is the desktop and kwin is the window manager
16:12karolherbst: the desktop session is also part of plasma
16:14karolherbst: thing is, with plasma5 everything is pretty much decoupled, so you can run kwin without having a plasma session at all or vice versa
16:14gahhw: skeggsb: please dont forget to backport this system-freeze crashing fix to all LTS kernels available
16:14karolherbst: gahhw: ohh, there will be no backport, because it will be a frigging huge mess
16:14imirkin: gahhw: it's the LTS kernel maintainers' job to backport fixes, not the upstream developers'
16:15karolherbst: also, it's mostly userspace, so the kernel can't do much I guess
16:15gahhw: imirkin: ah, thanks for the information :)
16:15karolherbst: isn't most of the thinks already fixed on the kernel side anyway?
16:15imirkin: karolherbst: the things we know about? sure. but there are 100 things we don't know about... :)
16:15gahhw: karolherbst: but this is a critical issue on all the kernels. I dont think that "causing a system freeze" is not a serius issue that have to be backported
16:16karolherbst: gahhw: it's not only the kernel which is involved
16:16imirkin: gahhw: sure. the backport would look like "here is the 4.latest kernel. and a patch to change the version to the one you want it to read as."
16:16imirkin: [imo the whole backports thing is idiotic... wtvr]
16:17karolherbst: imirkin: anyway, at least on my system those crashes are like super rare and when they happen, I need to run a game for like an hour, which makes it hard to debug
16:17karolherbst: but those aren't mt related things most of the time
16:17karolherbst: except the one from last month or so
16:18imirkin: gahhw: my current advice to affected users is to not use kde, or not use nouveau_dri.so
16:18karolherbst: I need to setup that desktop rendering on nouveau offloading thing on my system
16:19karolherbst: maybe that triggers something
16:19imirkin: whichever is more palatable to you
16:43gahhw: imirkin: why didnt it helped to set in the kwinrc config file of plasma openglisunsafe=true and Backend=XRender
16:44imirkin: gahhw: dunno, i don't use kde. ask those guys.
16:44imirkin: [the kde guys]
16:44imirkin: what i *do* know is that i have no interest in dealing with the support burden they've created by starting to use GL from multiple threads in recent versions.
16:46karolherbst: gahhw: because kwin is just the window manager
16:46karolherbst: it doesn't affect what plasma does
16:47nyef: Is this the "per-context pushbufs" thing, or is that not-related or not-the-whole-of-it?
16:48imirkin: nyef: related. i don't think we really want per-context pushbufs. or if we do, it's really but a very small part of the solution.
16:49gahhw: karolherbst: thanks for explaining. This was some idea from a kde/plasma dev. I forwarded your answer :)
18:05mwk: alright, I give up on further T&L RE on Celsius for now
18:06mwk: until I figure out the rcp thing
18:06mwk: I suppose I could just stuff the whole 8M-entry result table into envytools, but that's not a particularly good idea...
18:17tacchinotacchi: mwk: what does T&L stand for?
18:22mwk: tacchinotacchi: transform & lighting
18:23mwk: vertex processing, ie. the thing that later evolved into vertex shaders
18:23tacchinotacchi: oh so you are working on an old card
18:24mwk: yeah, very old
18:25mwk: atm my goal is to RE everything there is to RE about NV1-NV40 cards
18:25mwk: or, at least their graphics processors
18:26mwk: recently working on NV10
18:26imirkin_: [aka GeForce 256]
18:27mwk: though I think I'll leave NV10 behind for now... I've mostly figured out its front-end processing by now, it's probably time to get NV20/NV30 up to par
18:27mwk: esp. since NV20/NV30 T&L is much more easily accessible :)
18:28tacchinotacchi: good luck
18:30tacchinotacchi: in nvkm/subdev/fb, what does fb stand for?
18:31tacchinotacchi: I'm thinking of framebuffer, but that's hardly relevant with reclocking
18:31mwk: which is a quite outdated name for what is really the mem controller
18:31tacchinotacchi: oh it was more straightforward than I though
18:31imirkin_: tacchinotacchi: well, the memory hangs off of PFB
18:31imirkin_: tacchinotacchi: really each subdev is an area of the gpu's mmio space
18:31imirkin_: it's not *quite* so clean and pretty, but that's the basic idea
18:32tacchinotacchi: so, subdev is subdevice, and the PMU is a subdevice? is this the idea?
18:32imirkin_: pmu is probably an engine
18:33imirkin_: could be a subdev though
18:33imirkin_: engines are things that also have contexts iirc
18:33mwk: basically, on NV1, FB was the GPU unit in charge of accessing VRAM and sending pixel data to the DAC
18:33imirkin_: so yeah - i guess pmu is a subdev.
18:33mwk: on NV3, it lost the "sending pixel data" part
18:34mwk: and VRAM slowly started to contain more and more stuff besides the framebuffer
18:34mwk: so the name is just an artifact now
18:35mwk: oh, and since Fermi, FB refers only to the central "hub" of memory subsystem, all interesting areas are separate units
18:36tacchinotacchi: well, my interest is reclocking now
18:36tacchinotacchi: and the files i'm looking at are in subdev/fb
18:37tacchinotacchi: so i'm wondering if we write the SEQ scripts to fb or to pmu
18:37mwk: to pmu
18:37imirkin_: the pmu has, among other things, a little cpu running a little rtos on it
18:37mwk: and of course the scripts themselves touch fb and lots of other shit
18:37tacchinotacchi: both core and memory reclock?
18:38imirkin_: the system's cpu sends commands to this little cpu's rtos to execute various tasks on the board
18:38imirkin_: since as you can imagine, memory reclocking requires doing very nasty things which are difficult to do properly over pci mmio
18:38tacchinotacchi: so many acronyms I got a headache
18:39tacchinotacchi: not really, I couldn't imagine that
18:39imirkin_: SEQ is the command language that nvidia's blob driver uses to send tasks to the little rtos that it has
18:39imirkin_: i believe nouveau's is called MEMX or something like that
18:40tacchinotacchi: But I guess there are advantages at letting mem reclocking be done by a small cpu instead of over pci
18:40imirkin_: yeah. like it works instead of not working.
18:40imirkin_: i'd say that's the biggest advantage ;)
18:40imirkin_:is the king of smooth
18:41mwk: tacchinotacchi: one thing that PMU has to do on memory reclocking is blocking all VRAM accesses
18:41mwk: doing that hangs the PCI-Express bus if anybody accesses VRAM through it
18:41mwk: if you were doing memory reclocking from the CPU, via the same bus... everything hangs
18:42mwk: but if you're doing reclocking from PMU, which is inside the card, the hung PCI-Express bus is not a problem, it'll just unhang once you're done reclocking
18:42tacchinotacchi: then it means the rtos uses a separate memory
18:43mwk: yeah, the PMU has its own code & data SRAM
18:43mwk: it's small, but not too small to do interesting things
18:44tacchinotacchi: if it can't use vram
18:48tacchinotacchi: any way I can check if my card has gddr3 or ddr3?
18:50imirkin_: if it's fermi, i think just ddr3 and gddr5 are options
18:50imirkin_: not 100% sure
18:50imirkin_: anyways, all that stuff is in straps iirc
18:56karolherbst: hakzsam: are you working on the gm206?
18:56hakzsam: karolherbst: no, just comparing deqp between nouveau and radeonsi :)
18:56hakzsam: but I'm almost done
18:56karolherbst: I see
19:19tacchinotacchi: imirkin_: I don't even know the difference(s) between ddr3 and gddr3 anyway lol
19:21imirkin_: the difference is a "G" :)
19:27Leftmost: Aww, gee.
19:29tacchinotacchi: so, when we write to pmu, is it in PIO mode or DMA mode?\
19:29tacchinotacchi: and do we write to PFIFO?
19:30imirkin_: you communicate in roughly-speaking pio mode
19:30imirkin_: you write commands to PDAEMON.DATA
19:30imirkin_: this iirc triggers an interrupt in the rtos
19:30imirkin_: where it grabs that data and does things with it
19:32tacchinotacchi: this PDAEMON.DATA, does pmu->subdev.device point to it?
19:32imirkin_: it's just a mmio register
19:34imirkin_: at least ... i think.
19:35imirkin_: the logic in nouveau's pmu code handles it already
19:35imirkin_: this is how reclocking works for tesla's and kepler
19:35imirkin_: the main thing that needs to be done is determining the contents of the script
19:35imirkin_: i.e. what values to write and where to get those values from
19:38nyef: It's not as simple as "PIO comes from the CPU, DMA comes from the device"?
19:38imirkin_: nyef: i mean, what values to write into the various memory timing registers
19:39imirkin_: there are a lot of tables in the vbios that tell us how to handle the various cases
19:39imirkin_: just have to figure out which bits mean what
19:39imirkin_: as well as any static tables we need in the driver
19:40nyef: ... Which could be a process of "simply" corrupting the ROM a piece at a time and seeing what response the blob has to the corruption.
19:40imirkin_: yeah, basically the thing skeggsb did for kepler was fuzz the vbios and look for differences in the reclocking scripts
19:41imirkin_: but even that's not perfect, since it's not 100% vbios-dependent
19:41imirkin_: (if only it were)
19:42imirkin_: those ram_* compose a script which is then sent to the pmu for execution
19:45imirkin_: and even with that, he wasn't done - karol finished it up by improving some timing calculation and then fixing up the voltage switching logic
19:45imirkin_: there are a lot of pieces, and you have to get *all* of them right
19:45imirkin_: or else it's hangsville, usa
20:04tacchinotacchi: *googling hangsville*
20:05imirkin_: it's an expression... *ville, meaning that it's as if you visited a city that was full of *
20:05mwk: hello there from hangsville!
20:06imirkin_: mwk doesn't just visit it, he lives there ;)
20:06mwk:is currently trying to determine the various reset bits on NV10/NV20/NV30
20:06imirkin_: and is in the market to buy even more property there
20:06mwk: mostly by submitting commands to various units and checking whether my computer hung or not
20:07tacchinotacchi: this "timing registers"
20:07tacchinotacchi: are they in the memory or in the mem controller?
20:07mwk: turns out the GPU can be quite surprised by having half the pipeline in reset and the other half not
20:07imirkin_: tacchinotacchi: memory controller
20:08imirkin_: er, well, sorta
20:08imirkin_: i'm not 100% sure how MRS/EMRS stuff works
20:08mwk: MRS and EMRS are registers on the DRAM chip
20:08mwk: they're write-only, but have RW shadows in the memory controller
20:08imirkin_: yeah, that makes sense.
20:16tacchinotacchi: what's the job of the memory controller then
20:18mwk: tacchinotacchi: which level?
20:19mwk: memory controller is... kind of a big thing
20:19mwk: at the lowest level, its job is to talk to DRAM
20:19tacchinotacchi: I'm going to read on wikipedia or some paper if it's a big topic
20:19mwk: there are all sorts of restrictions that need to be observed when talking to DRAM, since MC is the one in control of the whole process
20:20mwk: this is what memory timings are about
20:20mwk: eg. 'after opening a bank, you can't read/write from it until X cycles have passed'
20:20mwk: there are craploads of timing params like that
20:21mwk: memory controller is in charge of observing them, and queueing the accesses in optimal order
20:22mwk: if you program the timings wrong... well, the DRAM won't manage and accesses will corrupt data
20:22pmoreau: Should we buy shares in hangsville's real estate, with all those applications using GL from multiple threads? :-)
20:37RSpliet: tacchinotacchi: I don't really know what to tell you really... for (GDDR5) Fermi reclocking I've put a lot of bits in place in one of my github trees but the devil is in the details
20:37RSpliet: There's a gross of registers to touch, and I expect my tree to touch a handful of them inappropriately - so if you just blindly try out that code, your machine will hang
20:37RSpliet: for DDR3 I haven't started. There's some overlap in the two, but too little to re-use the code in any other way than copy-paste, throw half away and change the rest
21:27pmoreau: Grrr… It seems like I will always find stuff to fix/change in my patches, and will end up never submitting them… --"
21:29pmoreau: I guess I will fix the few remaining warnings, check variable naming conventions and remove any undesired debug messages and call it good for RFC.
21:48tacchinotacchi: RSpliet: I know it's in a bad state, I'd like to help
21:49tacchinotacchi: But I'd have to read a lot of docs and code
22:17mooch: mwk: do you think you could finish your tests on nv3 and nv4 please? i'd really like to be able to rasterize in my emulator
22:18mwk: mooch: working on it.
22:18mooch: k thanks
23:30franguer: hello there! just got my debian jessie running on my laptop (vaio with mobile geforce chip) with the nouveau drivers. everything fine except the brightness control. any clues on where to start looking?
23:31imirkin_: franguer: pastebin dmesg
23:34franguer: imirkin_: http://pastebin.com/KaYvmV5C
23:36imirkin_: franguer: ok, so, you're on a pretty old kernel. this backlight stuff has been done and redone like 20 times since then
23:36imirkin_: franguer: i believe for that kernel, you can boot with acpi_backlight=vendor
23:36imirkin_: i think!
23:37franguer: imirkin_: i'll give it a try, thanks!