00:02 slacka123: anyone here working on the pstate? Do they need any help testing or hw info?
00:04 imirkin: slacka123: karolherbst (not here right now) has some fixes to improve gddr5 reclocking, but it's still not quite there
00:04 imirkin: he has a tree at https://github.com/karolherbst/nouveau
00:04 imirkin: not sure which is the right branch
00:04 slacka123: yeah that's what I have. I'll try to build it and test it out
00:11 slacka123: imirkin: there was one more system freeze bug. virtualbox with 3D accel will lock with nouveau but works with proprietary. You know about that one?
00:12 imirkin: i've heard about stuff with vbox
00:12 imirkin: afaik vbox does all sorts of nasties, i stay away from it
00:22 slacka123: When the proprietary drivers crash, you can still use the virtual consoles. Why does nouveau or mesa tend to lock up the system? Could this be improved?
00:23 imirkin: proprietary drivers know how to recover, nouveau doesn't
00:23 slacka123: could we RE what they do?
00:24 slacka123: I'm a master at crashing things :)
00:25 imirkin: not sure who 'we' is referring to
00:26 imirkin: the group of people that does not include you?
00:26 slacka123: reverse engineer...recover the same way the proprietary recover
00:26 imirkin: go for it
00:27 imirkin: there were some patches in fact to reduce one source of hang recovery fail
00:36 pmoreau: RSpliet: Damn it! I went to bed to early!! :D
00:36 pmoreau: RSpliet: Going to try that right after breakfast. :-)
01:19 pmoreau: RSpliet: So... 0e behaves like 0f did, minus the flickering and corruption (could be that this was the case before, but I didn't let it run long enough not notice it)
01:20 pmoreau: RSpliet: As for 0f... Well I don't even see the gears! It goes straight to a grey background, and the whole display freezes
01:21 pmoreau: And GR is in grrrrrrrrrrr mode
01:25 pmoreau: RSpliet: 05--0e: https://phabricator.pmoreau.org/P35, 0f: https://phabricator.pmoreau.org/P34
01:35 pmoreau: imirkin: When is EXIT supposed to be placed in NV50 IR? Is it at the end of a function or of the module?
01:36 pmoreau: Most likely at the end of the module, as function will have a return, but just want to be sure.
01:50 karolherbst: pmoreau: I don't think this is the case in general, I saw some programs where the exit instructions was somewhere in the middle of a function
01:50 karolherbst: it is at the end of one BB though
02:08 pmoreau: karolherbst: Oh! Ok. But then, what's the difference with a RET?
02:09 karolherbst: pmoreau: didn't saw ret yet, but I think it is the same?
02:11 pmoreau: Cause in the TGSI -> NV50 IR, if a RET is encountered but it is at the end of the function (or BB, don't remember), then then no NV50 RET is generated, but and EXIT will be generated when TGSI END is encountered.
02:12 pmoreau: I've been following the RET behaviour in my SPIR-V -> NV50 IR, but there is no opcode END in SPIR-V, (maybe it's the FunctionEnd instead?)
02:33 karolherbst: pmoreau: I think ret/exit are basically the same
02:33 karolherbst: either you return something or not, so
02:34 karolherbst: and also function could have different return statements, so it may make sense to have also multiple rets inside a function
02:47 pmoreau: karolherbst: Yeah, I understand having multiple rets inside a function.
02:52 mwk: pmoreau: nv50 EXIT instruction will halt the current shader / compute thread, no questions asked
02:52 pmoreau: Kind of a KILL?
02:52 mwk: you can run this instruction from a function with 10 levels deep call stack, and when you do, shader ends *now*, and everything disappears
02:52 mwk: no
02:52 mwk: it's entirely unlike KILL
02:53 mwk: the KILL instruction, or discard as it's called in envydis, does *not* end the shader
02:53 pmoreau: Ah!! KILL == DISCARD, didn't know that
02:53 mwk: it merely marks the pixel as killed
02:53 mwk: although it *may* end the shader *if* all threads in a quad/warp/whatever are killed, not sure
02:54 pmoreau: Ok! Thank you for the explanation. :-)
02:54 mwk: the exit instruction is like, well, exit(0) from C
02:54 mwk: it's normal termination
02:54 pmoreau: Understood
02:54 mwk: whatever happens to be in the output registers at the moment is the return value of the whole shader, if any
02:55 mwk: as for ret, it pops a call stack entry
02:55 pmoreau: Makes sense
02:55 mwk: but, as a special case, it can behave as exit if the call stack is empty
02:55 mwk: so at the top level, you can use either ret or exit to end execution
02:57 pmoreau: As a *convention*, is it better to use ret or exit at the top level?
02:57 mwk: I'd say exit
02:57 pmoreau: Ok
02:58 mwk: IIRC there's a flag that disables the empty-ret-as-exit behavior
02:58 pmoreau:always used return in C programming...
02:58 pmoreau: mwk: Btw, did you had time to look at the updated pull requests? O:-)
03:00 mwk: ah right
03:00 mwk: not yet
03:02 pmoreau: Ok. Whenever you have time
03:12 RSpliet: pmoreau: hmm, your trace shows no trace of touching GPIOs
03:12 pmoreau: I could redo one if you want
03:13 RSpliet: well, that would just end up with the same result
03:14 RSpliet: I do wonder why nv50_ram_gpio() bails
03:14 pmoreau: In theory at least :)
03:16 RSpliet: it's too bad the gpio code isn't riddled with debugging printf's
03:18 RSpliet: oh, and it's not nice not having a card with those GPIOs myself :-P
03:23 RSpliet: pmoreau: are you working with a 1-on-1 copy of my tree, or rather did you apply the patches onto some other tree?
03:23 RSpliet: I'd first like to verify the tree is in order if we can :-)
03:31 pmoreau: RSpliet: It's a clone of your tree
03:32 RSpliet: hmm...
03:32 pmoreau: Or rather, I cloned airlied's tree, added your repo as a remote, and switched to your branch
03:33 pmoreau: Which should be equivalent to a clone
03:33 RSpliet: could you push the end result to a web-visible git tree for me to look at please?
03:33 pmoreau: Sure! :-)
03:34 pmoreau: Probably going to take a **long** time though
03:35 RSpliet: sorry for that, I'm staring at some GPIO code in the meanwhile, but can't imagine it being wrong without everything falling over
03:36 pmoreau: I do have my EXT_TAG patch on top of yours, but I don't see why it would break it
03:37 RSpliet: I'll look at it while checking out the tree then :-)
03:37 RSpliet: bbiab
03:39 pmoreau: RSpliet: It will be available at https://github.com/pierremoreau/linux branch: RSpliet__master, once it's done pushing
03:57 karolherbst: pmoreau: your tesla cards are booting both in pcie v2 mode, right?
04:02 karolherbst: tizbac: do you still have your tesla card?
04:03 karolherbst: nv92
04:04 karolherbst: mwk: and do you have your nv98 card?
04:04 karolherbst: I need some teslas to test v1 => v2 transition with my patches
04:04 karolherbst: RSpliet: ohh you have a tesla card which boots with v1, too?
04:11 pmoreau: :D
04:11 pmoreau: karolherbst: Wanna test 'em all?
04:12 pmoreau: karolherbst: iirc, the G96 is, but the MCP79 doesn't seem to be in any PCIe mode as it is integrated
04:13 karolherbst: lspci -vv for both cards
04:13 karolherbst: and sure they are both using pcie
04:14 karolherbst: they should have something like Capabilities: [78] Express (v2) Endpoint, MSI 00 or Capabilities: [78] Express (v1) Endpoint, MSI 00
04:14 karolherbst: if they are both at v2, then testing my patches won't do anything
04:16 pmoreau: https://phabricator.pmoreau.org/P36
04:17 karolherbst: the one gpu is off :(
04:17 pmoreau: Oops
04:17 pmoreau: It's true I played with switcheroo just before
04:18 karolherbst: mhhh
04:18 karolherbst: why doesn't lspci show the speed for the integrated gpu :( wierd
04:18 karolherbst: I guess I will have fun with those
04:19 karolherbst: ohhh indeed
04:19 pmoreau: I updated the paste; same address
04:19 karolherbst: pmoreau: can you peek 0x088460 on your MCP one?
04:19 pmoreau: ...
04:19 karolherbst: yep, the g96 is booting in v2 mode
04:20 karolherbst: mhhh
04:20 karolherbst: okay
04:20 karolherbst: side not for me: integrated gpus are working differently
04:20 karolherbst: there is 0x00154c though on that
04:23 pmoreau: bbiab: don't want my lunch to magically disappear surrounded by smoke :D
04:53 karolherbst: mlankhorst: do you still have your nvc0? It seems it is a fermi card which boots in v1 mode, which is kind of uncommon
05:25 RSpliet: pmoreau: is your push still running? :-P
05:25 mlankhorst: karolherbst: I do
05:27 karolherbst: mlankhorst: do you want to check if the card is in v1 mode with lspci?
05:28 karolherbst: I have some patches which should bring the card into v2 mode (which is a pre-requierment for pcie speed increases)
05:29 karolherbst: mlankhorst: seems your nvd9 card also boots with v1
05:30 karolherbst: nv your nvc8 :/ there are indeed more fermis which do that
05:30 karolherbst: *and
05:30 mlankhorst: ok
05:35 karolherbst: pmoreau: the entire MCP chip is "one" device kind of somehow, isn't it?
05:36 mwk: karolherbst: well, it's a single chip, obviously...
05:36 karolherbst: pmoreau: could you try to bring your mcp gpu into higher pcie speeds with the blob and trace it for me?
05:37 mwk: and there is no pcie speed
05:37 karolherbst: mwk: yeah, but some "devices" of it have different pcie widths
05:37 karolherbst: mhhh
05:37 mwk: MCP* integrated GPUs are *not* pcie defices
05:37 karolherbst: ohhh okay
05:37 karolherbst: I could imagine that the chip itself can be speed increased somehow
05:38 mwk: *shrug*
05:38 mwk: there is some kind of a bus between the GPU and other parts
05:38 karolherbst: at least his lspci output indicates that
05:38 mwk: hmm, link?
05:39 karolherbst: https://phabricator.pmoreau.org/P36
05:39 karolherbst: but everything is set to 2.5
05:39 karolherbst: but v2
05:39 karolherbst: and as far as I know his chip should be able to do 5.0
05:39 mwk: wait
05:39 karolherbst: but I don't know if nouveau is the place to do that for his chip
05:39 mwk: are you talking about the MCP79 GPU
05:39 mwk: or the G96 GPU?
05:40 karolherbst: the mcp79 one
05:40 karolherbst: the g96 is no problem
05:40 mwk: then there's no speed
05:40 mwk: 03:00.0 doesn't have pcie capability, as expected
05:40 karolherbst: yeah not for the gpu, but the chip itself
05:40 mwk: you mean one of the PCIE root ports?
05:40 karolherbst: yeah for example
05:41 karolherbst: but for example on my system, when I change the pcie speed of my kepler, the same goes for the root port
05:41 mwk: hmm
05:41 karolherbst: so I am thinking if it does change anything for the gpu, when the chip is getting a speed up
05:42 karolherbst: should be, because commands are getting faster to the mcp chip
05:42 mwk: well, they should negotiate the highest speed supported by both
05:42 karolherbst: they usually don't do that on their own
05:42 karolherbst: if the driver doesn't do anything, the chip won't
05:42 karolherbst: that's why some gpus stuck in v1 mode, even when the system supports v2
05:43 mwk: weird
05:43 mwk: I suppose there could be some funny control regs
05:43 karolherbst: there are
05:43 mwk: likely in the root port's PCIE config space
05:43 karolherbst: I usually know most of them
05:43 mwk: but that's none of nouveau's business
05:43 karolherbst: there is 0x00154c for the mcp one
05:43 karolherbst: [1] 38.144390 MMIO32 R 0x00154c 0x000000e5 PBUS.HWUNITS_1 => { PCIE_VERSION = 2 | PCI_CLASS = DISPLAY | PDISPLAY | UNK3 = 0 | PVLD | PSEC | PCIE_SPEED = FULL }
05:44 karolherbst: and this reg is used to control lnkcap speed and pcie version of tesla gpus
05:44 karolherbst: and this reg doesn't contain garbage on the mcp one
05:44 karolherbst: as you see
05:44 mwk: I think it does
05:44 karolherbst: but the other regs aren't there
05:44 pmoreau: RSpliet: It finished pushing, now Github is digesting it. :-)
05:44 mwk: at least in the PCIE bits
05:45 karolherbst: mwk: same reg for his g96 gpu: [0] 21.501941 MMIO32 R 0x00154c 0x000000fd PBUS.HWUNITS_1 => { PCIE_VERSION = 2 | PCI_CLASS = DISPLAY | PDISPLAY | UNK3 = 0x3 | PBSP | PCIPHER | PCIE_SPEED = FULL }
05:45 mwk: I seriously doubt the integrated GPU bits have any influence on the root ports
05:45 karolherbst: yeah, the more important regs aren't there
05:45 karolherbst: 0x088460 is used to config the speed
05:45 mwk: karolherbst: this reg exists because it controls other things
05:45 karolherbst: but its empty
05:45 mwk: only two bits there control PCI
05:46 karolherbst: I bet you can change the pcie version
05:46 mwk: nvidia tends not to bother removing unused regs
05:46 mwk: and they bother even less with removing unused bits
05:46 pmoreau: RSpliet: It's alive!
05:46 mwk: so - don't worry about 154c, it shouldn't do anything of consequence with PCIE on MCP*
05:47 karolherbst: pmoreau: want to try to poke 0x00154c 0x000000e4 on your mcp gpu? just to try that out
05:47 karolherbst: mhhh, I am really not sure about it
05:47 mwk: I'm serious
05:47 karolherbst: I know you are
05:47 karolherbst: did you try it?
05:47 mwk: you want to change the root ports' behaviour, look at root port registers
05:47 mwk: or perhaps one of the many "memory controller" PCI devices
05:48 pmoreau: What should I peek afterwards?
05:48 mwk: better yet, make sure MCP79 is actually supposed to support 5GT/s
05:48 karolherbst: the thing is, I saw other mcp gpus where the blob did it
05:48 karolherbst: pmoreau: same reg and check lspci -vv
05:48 mwk: perhaps the software is willing, but the hardware is weak
05:49 mwk: karolherbst: where it poked the register?
05:49 karolherbst: mwk: nva0 is mcp, right?
05:49 mwk: nope
05:49 pmoreau: No
05:49 pmoreau: NVAC
05:49 karolherbst: ohhh, okay
05:49 pmoreau: and MCP77 is NVAA
05:49 mwk: it's G200, the biggest tesla GPU
05:49 karolherbst: there are no traces :O
05:50 pmoreau: No traces of?
05:50 karolherbst: of nva* mcps
05:51 pmoreau: https://phabricator.pmoreau.org/P37, 0x154c contains 0xe4
05:51 pmoreau: Well, there is trace of MCP79 inside of my reclocking trace of G96
05:52 pmoreau: And most likely, the MCP79 was the one driving the screen
05:52 karolherbst: yeah I know, I meant some dedicated traces
05:53 karolherbst: okay, it seems like this reg is indeed useless for me for mcp gpus
05:56 karolherbst: pmoreau: you could try to check if the blob does anything regarding pcie speeds for both your gpus or your mcp chips itself or anything
05:56 karolherbst: I know that your MCP chipt itself should be able to do 5.0
05:59 pmoreau: I'll reboot on the blob in a few minutes
05:59 karolherbst: okay thanks
06:11 pmoreau: karolherbst: There is no reference to PCIe speed inside the PowerMizer tab for the MCP79
06:14 pmoreau: karolherbst: For the G96, only the PCIe width changes, and the speed stays at 2.5
06:25 karolherbst: mhh okay
06:25 karolherbst: seems like you really only have 2.5 support, but wait
06:26 karolherbst: ohhhh I see why
06:26 karolherbst: your card supports 5.0
06:26 karolherbst: but your board/cpu/whatever doesn't
09:50 darlac: Hi. I have GT220M (nv96) and GTS450 (nvc3). If there is need I can run some tests
10:01 Karlton: p
10:05 karolherbst: darlac: I would have some if the card is in pcie v1 mode after loading nouveau
10:06 karolherbst: but that would require you to build your own kernel module :p
10:09 karolherbst: I think I will finish fermi pcie reclocking stuff and then I need a tesla card :) mupuf: could you put the nv86 or nv84 into reator?
10:31 darlac: karolherbst: From which branch I have to build nouveau?
10:36 karolherbst: first check if your card is in pcie v1 or v2 mode
10:38 karolherbst: with lspci -vv
10:41 darlac: i'm on binary blob now
10:41 pmoreau: It shouldn't affect the result of lspci
10:43 darlac: v2
10:45 tobijk: pmoreau: it should not? i guessed the blob switches to v2 directly :)
10:46 karolherbst: tobijk: +1 :)
10:46 karolherbst: the blob even tries when the card obviously can't go into v2 :D
10:46 karolherbst: for NV84+ cards that is
10:48 tobijk: karolherbst: btw i have a nv86 with pcie1 mode, not sure if it does pcie2 at all though :)
10:49 karolherbst: tobijk: wait
10:49 karolherbst: tobijk: right, the blob tries though
10:50 karolherbst: tobijk: but your card seems to support 5.0
10:50 karolherbst: only the board doesn't seem to support it
10:50 tobijk: :/
10:50 karolherbst: if it is the same you used for your trace
10:50 tobijk: it is
10:50 karolherbst: [0] 71.601986 MMIO32 R 0x088460 0x30601220 PPCI.CONFIG_LINK => { TARGET_SPEED = 5_0GT | CARD_SPEED = 5_0GT | SYSTEM_SPEED = 2_5GT | UNK16 = 0x60 | UNK28 = 0x3 }
10:50 karolherbst: :(
11:17 imirkin: darlac: in general, if you notice bugs while using nouveau, feel free to report them
11:18 darlac: I will check fermi tomorrow
11:25 imirkin: there are a handful of known issues, but 3d rendering should in general be pretty spec-compliant
11:26 pmoreau: karolherbst, tobijk: I read to quickly and was thinking of the capabilities, rather than the version currently used.
11:32 karolherbst: pmoreau: nah, it is fine, my pcie patches can't do much for your gpus anyway, except if you get your mcp ship to use somehow v2 at 5.0 speed
11:33 karolherbst: pmoreau: which cpu do you have
11:33 pmoreau: Core2Duo
11:33 karolherbst: which one
11:33 karolherbst: Core2Duo are like three differen families
11:33 karolherbst: *t
11:33 karolherbst: uname -a should show you (as long as it wasn't messed up)
11:34 pmoreau: "Linux testlinux 4.3.0-rc1-nouveau-146569-g935f033-dirty #159 SMP PREEMPT Sun Sep 27 09:44:26 CEST 2015 x86_64 GNU/Linux"
11:34 karolherbst: like I hate those :(
11:34 karolherbst: then /proc/cpuinfo
11:34 pmoreau: "model name : Intel(R) Core(TM)2 Duo CPU T9600 @ 2.80GHz"
11:35 karolherbst: there is no point why uname should print crap like that, seriously
11:35 pmoreau: uname -m only returns x86_64
11:35 karolherbst: this is right
11:35 karolherbst: uname -p should return something usefull
11:36 karolherbst: -m is just the arch
11:36 pmoreau: unknown
11:36 karolherbst: p the cpu
11:36 pmoreau: and uname -i is also unknown
11:36 Yoshimo: for most people the kernel isn't compiled on your computer so shouldn't have more than version and architecture
11:36 karolherbst: ohhhh right, your CPU doesn't have pcie support yet
11:37 pmoreau: Yoshimo: I did compile this one though
11:37 pmoreau: (and on the very same laptop)
11:37 karolherbst: Yoshimo: what interface does uname parse so that it doesn't get anything usefull at all?
11:39 karolherbst: ohh it seems like it depends with what you built coreutils
11:39 karolherbst: not the kernel
11:39 pmoreau: I didn't build coreutils
11:39 karolherbst: I don't understand why ... I mean.... whatever
11:43 darlac: Why LnkCap and LnkCtrl2 are 5GT/s but LnkSta is 2.5GT/s?
11:49 karolherbst: darlac: this is normal
11:50 karolherbst: on kepler the blob usually sets LnkCap and LnkCtrl2 to the maximum speed supported by your card and pcie slot
11:50 karolherbst: and LnkSta is the actual speed
11:52 karolherbst: darlac: what cards do you have?
11:52 darlac: gt220m
11:52 karolherbst: If you have a kepler card you can try out my pci speed patches
11:53 karolherbst: ohh that's tesla :/
11:53 karolherbst: this will take me a while
11:53 karolherbst: next is fermi
11:53 darlac: i have tesla and fermi
11:56 darlac: and GeForce 2 MX ;p
12:07 karolherbst: pmoreau: what is your mainboard chip? the MCP one?
12:07 pmoreau: karolherbst: Yes, the G96 is a discrete one
12:08 karolherbst: I meant like is this also your mainbaord controller
12:09 karolherbst: wierd
12:09 karolherbst: this chip should support 5.0
12:09 karolherbst: I can't figure of any reasons why it shouldn't
12:09 pmoreau: It has some USB controller, Memory and some other
12:10 pmoreau: And a PCIe bridge
12:11 karolherbst: it was a mid 2009 macbook pro?
12:12 pmoreau: Yes
12:15 karolherbst: it is like hell to find any official information on that one though
12:16 pmoreau: Compared to other MBP or to other laptops?
12:16 karolherbst: in general
12:24 karolherbst: I actually never find anything on the topic how to raise pcie speeds on linux though
12:25 karolherbst: so maybe nobody really cared about it and the linux driver simply won't ever bump your speed. But actually the speed should be increased when a device requests this
12:26 pmoreau: The blob doesn't bump it at least
12:26 pmoreau: No idea if it gets bumped under OS X
12:26 karolherbst: see this? https://gist.github.com/karolherbst/f72abf9ee449b03386e1
12:27 karolherbst: the host controller also reduces speed when the gpu is reducing it
12:28 pmoreau: Indeed
12:29 karolherbst: on fermi this would look different though
12:30 karolherbst: you may have oticed that lnkCap and lnkCtrl2 both stay at 8.0
12:30 karolherbst: on fermi this is a bit different
12:30 karolherbst: 1. lnkCtl2 is always 2.5
12:30 karolherbst: 2. lnkCap == lnkSta
12:30 karolherbst: I assume it is the same on tesla
12:30 pmoreau: Sta is for?
12:30 karolherbst: Status?
12:30 karolherbst: don't know
12:31 pmoreau: Could be :)
12:31 karolherbst: anyway lnkSta is the important speed
12:31 karolherbst: now I do some magic
12:32 karolherbst: ohh wait
12:32 karolherbst: the host controller simply doesn't care about the pcie version of the gpu :D
12:38 karolherbst: pmoreau: do you still have a mac os x partition?
12:38 pmoreau: I do
12:38 pmoreau: When I need to enjoy some decent battery life
12:42 karolherbst: uhhh
12:42 karolherbst: maybe the system profiler will tell us :)
12:42 karolherbst: ohh wait, there should be lspci on mac os x :O
12:43 karolherbst: ioreg
12:43 karolherbst: mhhh
12:43 karolherbst: okay, system profiler it is :D
12:48 pmoreau: I'll have a look when I reboot
12:54 karolherbst: thanks
12:55 pmoreau: Thanks for looking into it :)
12:55 karolherbst: no problem
12:56 karolherbst: sooner or later there will be bug reports about this anyway
12:56 karolherbst: so I will fix this before forgetting about most of it
12:56 pmoreau: ;)
12:58 RSpliet: https://www.pugetsystems.com/labs/articles/Gaming-PC-vs-Space-Heater-Efficiency-511/
12:59 karolherbst: :D
13:01 karolherbst: I have to buy better fans for my laptop :/
13:01 karolherbst: so that the cpu can consume more power!!!
13:02 pmoreau: "we ended up needing a gaming PC with three NVIDIA GTX Titans in triple SLI running Furmark to match the power draw"
13:02 pmoreau: Sounds tempting to replace all heaters by 3 Titans :D
13:02 karolherbst: :D
13:02 pmoreau: Might not for the budget though
13:02 karolherbst: 3 titans are a bit expensive though
13:02 karolherbst: hey, why not buying 9 cheaper gpus and three mb
13:03 karolherbst: and do a crazy NUMA setup
13:03 karolherbst: and just use all 9 gpus
13:03 karolherbst: :)
13:03 karolherbst: 3 for OpenCL stuff, 3 SLI for actual gaming and the other 3 for fun
13:03 pmoreau: But does it heat enough?
13:03 pmoreau: The 3 last for PhysX
13:03 karolherbst: which is cuda/OpenCL
13:03 karolherbst: I doubt any game does both
13:03 karolherbst: so either CL or cuda
13:04 pmoreau: You could have some rendering in Cuda / CL
13:04 karolherbst: yeah well
13:04 karolherbst: if you have 3 dedicated gpus just for this stuff I doubt any game would need more power
13:05 karolherbst: maybe if you ran at 8K+ displays
13:05 karolherbst: or a 3 8K monitor setup
13:05 karolherbst: :D
13:05 pmoreau: 3x8K... O.O
13:05 karolherbst: yeah, why not
13:05 karolherbst: if you have 9 gpus?
13:05 pmoreau: Let's go for 6 then!
13:05 karolherbst: they should still be able to driver 4x8K
13:06 karolherbst: maybe not on 4xSSAA though
13:06 karolherbst: ...
13:06 karolherbst: just try to think about what internal resoultion is used
13:08 karolherbst: 4x4x8K ...
13:09 karolherbst: but hey didn't nvidia invented TXAA exactly for this?
13:09 pmoreau: TXAA?
13:09 karolherbst: yeah
13:09 karolherbst: some kind of improved MSAA
13:10 pmoreau: Oh ok
13:10 karolherbst: http://www.geforce.com/hardware/technology/txaa
13:10 RSpliet: temporal filters... so basically using the previous FB for your samples in addition to the current?
13:11 karolherbst: somehow
13:11 karolherbst: it needs both hardware and API support though
13:11 karolherbst: "This technology is a mix of a temporal filter, hardware anti–aliasing, and custom CG film–style anti–aliasing resolves. "
13:12 karolherbst: it's the new shit in other words :p
13:12 karolherbst: I tested it and it looked pretty decent
13:13 karolherbst: http://international.download.nvidia.com/geforce-com/international/comparisons/watch-dogs/watch-dogs-anti-aliasing-comparison-1-4x-txaa-vs-8x-msaa.html
13:17 RSpliet: same as the old shit?
13:17 karolherbst: well it is a bit blurry :D
13:17 karolherbst: I think the best is still 4x SSAA, but who can actually use this
14:05 pmoreau: Generating the report…
14:08 karolherbst: mhh reg 0x88088 seems strange
14:08 karolherbst: I think this shows the _actual_ speed
14:09 pmoreau: According to the report, the MCP79 is on a PCI bus, and the G96 on a PCIe one.
14:09 karolherbst: mhh okay
14:09 karolherbst: but does it say the speed?
14:10 pmoreau: Trying to find it
14:14 karolherbst: yeah, nice
14:14 karolherbst: 0x88088 shows the current hardware state of the pcie speed
14:14 karolherbst: so even if the actual config reg already contain the "requested" speed, but aren't commited, you can use 0x88088 to get the _real_ speed
14:14 pmoreau: Not found...
14:15 karolherbst: some fermi traces seem to indicate, that the config reg may already be at 5.0, but the hardware speed is still only 2.5 even when all requiernments fit
14:15 karolherbst: pmoreau: :/
14:15 karolherbst: wait
14:15 pmoreau: Could the 0x88088 work on my laptop?
14:15 karolherbst: this reg doesn't _work_
14:16 karolherbst: the bits I am interested here are read-only
14:16 pmoreau: Hum
14:16 pmoreau: What do you mean then by "you can use 0x88088 to get the _real_ speed"?
14:16 karolherbst: bit 16:17 shows the current actual speed
14:16 karolherbst: the negotiated speed
14:16 karolherbst: which is currently active
14:17 pmoreau: Get as retrieve, not as achieve
14:17 pmoreau: ok
14:18 karolherbst: it works even on kepler
14:18 karolherbst: and maybe on tesla
14:18 pmoreau: Do you want me to test something?
14:18 karolherbst: nice
14:18 karolherbst: it's there on tesla
14:19 karolherbst: nah, not now. the traces in the repo are usually enough
14:19 karolherbst: only for uncovered cases I need real hardware
14:19 karolherbst: like putting my kepler into v1 mode
14:19 karolherbst: :)
14:19 karolherbst: no kepler boots in v1 mode
14:19 karolherbst: so I had to especially create a trace for that
14:19 pmoreau: :-)
14:19 karolherbst: and somehow the blob could handle that
14:20 karolherbst: that's why the kepler code is currently pretty big, because it can handle the currently known worst case scenario :D
14:20 karolherbst: I hope it is enough for 99.9% of the setups
14:21 karolherbst: there are lspci ports for mac os x though
14:21 pmoreau: I'm off, see you tomorrow
14:21 karolherbst: okay :)
14:52 CapsAdmin: i have a game engine that runs fine on intel mesa and proprietary drivers but very poorly on "OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.6, 256 bits) OpenGL version string: 3.0 Mesa 11.0.0"
14:52 CapsAdmin: using a gtx970
14:53 CapsAdmin: i'm kinda new to this stuff so i'm wondering if anyone can point me to a direction or something
14:54 imirkin: CapsAdmin: llvmpipe is not nouveau... it's a cpu-based driver
14:54 imirkin: CapsAdmin: gtx 970 won't work with acceleration with nouveau... GM20x isn't supported due to requiring signed firmware uploads
14:54 imirkin: CapsAdmin: as before, best course of action is to create an apitrace that renders properly with i965 but not with llvmpipe, and file a bug
14:55 CapsAdmin: oh..
14:56 CapsAdmin: well it renders almost properly. looks like i forgot to clear a buffer or something but overall performance is very slow but that makes sense
14:57 CapsAdmin: imirkin, is there any way to use this signed firmware somewhere from a development repository?
14:59 imirkin: CapsAdmin: not to my knowledge.
14:59 imirkin: CapsAdmin: llvmpipe is a whole lot slower than any even semi-modern gpu, so slowness is to be expected
15:00 imirkin: turns out fixed function rasterizer helps a lot :)
15:00 CapsAdmin: it was faster than i expected to be software at least
15:00 CapsAdmin: i'm using plasma 5.5 which also feels very smooth
15:01 CapsAdmin: but yeah that sucks. i have some older gtx 275 that i guess would work (?)
15:03 imirkin: CapsAdmin: yeah, GTX 275 should be quite functional
15:03 imirkin: although there are a bunch of people complaining that plasmashell doesn't work with nouveau
15:03 imirkin: so... ymmv
17:17 karolherbst: okay, pcie stuff is indeed easier on fermi/tesla than on kepler+ :D
17:50 karolherbst: ohh haha, testing on fermi will be funny when reclocking isn't supported :(
18:05 karolherbst: wait, what?
18:11 karolherbst: :O
18:11 karolherbst: impossible
18:11 karolherbst: this fermi requests pcie 8.0 speed at 0xf pstate
18:12 karolherbst: ohh there are 3.0 fermis
18:12 karolherbst: no, they are keplers
18:12 karolherbst: wait
19:25 Hello71: mupuf: yaourt -S nouveau-fw says "Uncompressing NVIDIA Accelerated Graphics Driver for Linux-x86 325.15NVIDIA-Linux-x86-325.15.run: line 974: /tmp/makeself.NsS5hXCq/xz: No such file or directory"
19:52 Hello71: hm, you need to have the "which" command installed.
23:59 karolherbst: is there a way to wait for a reg change in nouveau?
23:59 karolherbst: or do I have to poll