07:21night199uk: anyone around that can explain more about the BIT ‘d’ and ‘U’ table layout?
07:27mupuf: night199uk: more thqn is already found in nvbios and nouveau's codeM
07:28night199uk: DP and U tables seem to be very similar
07:28night199uk: i actually just wanted a more high level view
07:28night199uk: both tables seem to consist of ‘output’ entries and ‘config’ entries
07:28night199uk: trying to understand the purpose more than anything else of each type of entry
07:28night199uk: high level
07:29night199uk: and what is DP vs U since they are so similar
07:36night199uk: and e.g. what is a cfg entry and what is an output entry
07:36night199uk: there is also some hashing going on in the UEFI gop driver that i don’t understand
08:56Manoa: I know that SLI does not exist at the moment for the driver
08:57Manoa: but I was wondering that when it does exist, would it be possible to do SLI between different cards ? like for example a GTX 480 and a GTX 580 ?
08:58Manoa: or maybe lesser combinations such as a GTX 470 and a GTX 480 ?
08:59Manoa: that would totally rox0r the box0rz
09:01Manoa: what's even more appealing is the ability to do SLI between 2 different brands of cards
09:07mupuf: Manoa: SLI makes no sense for nouveau right now
09:07mupuf: we have a lot of room for improvement in performance already on one GPU
10:15sangmank: hi nouveau people, is there anyone who knows how the cuda debugger api works internally?
10:16sangmank: i am mostly interested in attaching & inspecting the running kernel
10:47vnd: mupuf: any progress maybe? :)
12:55Manoa: yhe mupuf not right now, but I wonder if nouveau will be able to exceed the limitation on SLI, the architecture of DRM can be modified and support in nouveau could be added - together I wish and hope that the possibilities will exceed the current multicard limitation, I only imagine acceleration of multiple cards from different brands
12:58Manoa: it's such a shame that my system has 4 x16 PCI-E slots and only one of them is used and I can't use my older cards to increase the available video performance
12:59Manoa: I am running some pretty heavy games that are begging me for more video performance, and that performance is just sitting there gathering dust
13:00Manoa: I have already given some hardware to people I know because they needed it, but there is still some left and it is unused
13:00tobijk: concerning nouveau that is not the performance bottleneck, not reclocking the cards to their highest performance level is...
13:00Manoa: yhe I know that too, I realize it is far too early for what I am talking about
13:01Manoa: I will wait, patiently until nouveau/drm/mesa are developed, but the open source potential is very apealing
13:03tobijk: i wouldn't hope for sli too much, there is just piles of work and not many developers to do that work
13:48vnd: would it be safe if I copy the nouveau module from kernel branch 3.14 to branch 3.18?
13:49vnd: I mean override
13:59vnd: mupuf: I’ve already checked kernel 3.18 and the problem still remains there
13:59vnd: you’ve asked me yeasterday to check it
14:30mupuf: vnd: good!
14:30mupuf: well, that means that the problem is quite specific to the c1
14:30mupuf: everyone reports it for the c1
14:30vnd: heh, I’m just trying to hack 3.18 and include nouveau from 3.14 :)
14:31mupuf: good luck, that will be a lot of work
14:31mupuf: you would need the whole drm
14:31vnd: yup, I’ve copied it
14:31vnd: ah, drm
14:31vnd: I’ve just copied nouveau
14:31vnd: but it seems it compile a bit
14:31mupuf: a bit, yeah
14:31mupuf: with the whole drm it will help more
14:32RSpliet: oh boy... that's going to be messier than a buffet with the weather girls
14:32mupuf: but instead of doing that, try bisecting
14:32mupuf: RSpliet: ... ? What does that even mean?
14:32vnd: mupuf: single commits?
14:32mupuf: yeah, but git will do that for you
14:32RSpliet: vnd: no, bisect... every step reduces the search space by half ;-)
14:33mupuf: tell it to bisect all the changes in the nouveau directory
14:33tobijk: git bisect start -- the/path/you/want
14:33vnd: ok… I haven’t tried it before
14:33tobijk: if you end up wuh 10 steps its a huge bisect :>
14:35mupuf: RSpliet: ooooooohhhhh, those weather girls :D
14:35mupuf: raining men
14:36mupuf: So, I was not supposed to have the internet at home at least until the end of the week ... but I actually got it today!
14:36mupuf: And it is freaking fast! http://www.speedtest.net/result/4091790554.png
14:36mupuf: I was first stuck at 30Mbit/s
14:36mupuf: and then I realised I was using wifi, silly me :D
14:36RSpliet: that's... I can't beat that
14:37tobijk: <-- 6Mbit/s ;-)
14:37RSpliet: I'm stuck with a mere 90MBit
14:37mupuf: archlinux updates are not going to take long :D
14:38mupuf: anyway, that means that I should be able to make reator available in the coming days
14:42mupuf: so, let's have a look at my nvc1 and see if they have a PWM fan
14:42mupuf: I doubt that
14:42mupuf: but hey, who knows
14:50infinity0: does anyone know why dota 2 on native-linux steam would be running slowly?
14:51tobijk: infinity0: what is slow? low framerate? ...
14:51infinity0: i mean, of course not precisely why, but any general things i can explore myself
14:51infinity0: yeah, low framerate, like 10 fps
14:51tobijk: dpends on many things...
14:52tobijk: if you use nouveau, most likely is missing reclocking of the card
14:53infinity0: ah ok thanks
14:53infinity0: i will experiment with that
14:53infinity0: so nouveau by default runs the card at a lower clock rate?
14:53tobijk: at the boot clocks, whatever these are
14:53tobijk: depends on the card
14:54infinity0: oh ok, but that would be the same for nvidia-glx? or does that do the clocking automatically
14:55skeggsb_: pmoreau: reverting it will make other kinds of random hangs for some people, they appeared with fence changes
14:55tobijk: i'd think nvidia does auto reclocking, but i dont know for sure (the nvidia driver never worked for me)
14:55skeggsb_: pmoreau: the fifo 100 spins loop thing is bong-hits anyway, from a time way back when it was common for us to get random interrupts we couldn't handle
14:57skeggsb_: i suspect that everything else is fine, and it's the fact we even *have* that loop there that's the issue, i'll do something about it today
14:59airlied: there have been some changes to the generic fence go past last week I think
14:59airlied: to fix some issues on radeon
15:00skeggsb_: airlied: this issue was that we started keeping an event handler around for the lifetime of a channel, rather than creating one every time we needed to wait on a fence. it showed up an interrupt handler bug where we'd ack at the wrong time, and then stop getting interrupts and fences would time out a lot on optimus setups
15:01tobijk: skeggsb_: didnt you solve this already?
15:01skeggsb_: tobijk: yes, but the fix has showed up another bug
15:02tobijk: oh :/
15:02skeggsb_: the fix is correct, i'm sure. but, i do need to remove some crazy stuff from long ago, and hopefully that'll stop the hangs that some people see
15:06tobijk: skeggsb_: if you need a tester, just let me know :)
15:12infinity0: "Expect low 3D performance Fermi GPUs" damn
17:37xexaxo: hmmm should we increase the NV_OBJECT_CLASS (mask) ?
17:37xexaxo: currently it's 0xffff, the lower 8 bits for the idx, and the upper 8 for the chipset.
17:38skeggsb_: xexaxo: no, ignore it, it's all dodgy.. i've been working towards fixing a lot of those mistakes, but it's complicated and will take a while to finish
17:38xexaxo: how does it handle the nv1xx ones ?
17:39skeggsb_: simple, it doesn't matter at all
17:39xexaxo: humble one "it's _all_ dodgy"
17:41xexaxo: skeggsb_: can you put in a sentence what the planned fix is ?
17:42skeggsb_: i shall once i know for sure what it'll be, i've scrapped about 3 approaches so far