00:00 mupuf_: and that should be about it for the most important features
00:06 imirkin: gnurou: i assume that the fw for gm20b won't Just Work on a desktop gpu?
00:06 imirkin: (you sort of address that in your cover letter, but just confirming)
00:08 mupuf_: gnurou: by the way, the support for the jetson landed in envytools
00:08 mupuf_: you may be interested in fixing it a little for your dev board
00:08 gnurou: imirkin: nope, it definitely won't
00:09 gnurou: mupuf_: seen that, thanks! I will give it a try
00:09 mupuf_: it may just work, if the device tree kept the name GPU for the device
00:09 mupuf_: if not, then changes will have to be made
00:09 mupuf_: but that should be trivial
00:59 pmoreau: imirkin: Oh, that's what those indices are for! I was wondering, cause CB are not like GLOBAL, where you have an array of them, so I couldn't see where the index was being used.
00:59 imirkin: hehe
01:02 pmoreau: gnurou: \o/ Good to hear about progresses on signed fw! :-)
01:03 gnurou: pmoreau: yeah, it's about f***ing time eh? :)
01:03 pmoreau: ;-)
01:03 pmoreau: You'll feel better once it's done! :D
01:08 pmoreau: Oh, I hadn't seen the patches on the ML. :-)
01:16 gnurou: pmoreau: that's only the kernel part though, the FW files themselves are still not ready *sigh*
01:17 pmoreau: At least some bits here and there are coming to Nouveau. :)
01:17 gnurou: yeah, that one is the big chunk
01:19 pmoreau: gnurou: When you were talking about the firmwares being in different format, were you talking about the different firmwares for one chipset, or each chipset having its own firmware format?
01:19 pmoreau: (Or maybe both…)
01:20 gnurou: different FWs for the same chipset
01:20 gnurou: for instance, GR and PMU FWs come from different people, working differently, releasing them in different formats
01:20 pmoreau: :/
01:20 gnurou: I will try to harmonize them, but am not sure yet whether it is possible
01:20 gnurou: at worst it just means we need to load them differently, it's not too big a deal
01:21 pmoreau: Ok
01:21 gnurou: FWs for the same falcons on different chips should be loaded the same way, fortunately
01:21 pmoreau: Ouf! :D
01:21 gnurou: at least, until some big change, but the Maxwell generation should be safe
01:22 pmoreau: Let's hope Pascal doesn't come in the way, and redo everything
01:33 gnurou: that's precisely what I am praying for everyday
01:41 pmoreau: gnurou: Going to a Japanese shrine and putting some coins? :D
01:42 pmoreau: (Makes me wanting to come back to Japan…)
01:42 gnurou: pmoreau: there's one right next to our office, very convenient ;)
01:43 pmoreau: ;-)
01:43 pmoreau: Coincidence or not?
01:51 gnurou: well they are just everywhere, so...
03:31 karolherbst: mupuf_: regarding future proof: shall I add message handling, so that it is easier to add new message later on?
07:59 karolherbst: mupuf_: new version of the patches: https://github.com/karolherbst/nouveau/commits/pdaemon_counters
09:54 buhman: can't xf86-video-intel and xf86-video-nouveau be used at the same time?
09:58 imirkin: sure
10:10 imirkin: skeggsb: looks like my theory about the bit T table having max clocks for hdmi was bogus =/ someone says they can get 297MHz on a GF106 but that table says 225.
10:11 imirkin: skeggsb: what about just unilaterally upping the max to 297mhz?
10:36 imirkin: skeggsb: sent an info request... we'll see if we get any info
10:47 karolherbst: imirkin: what would happen if the chip doesn't support it by the way?
11:16 pmoreau: karolherbst: That's quite a bit of code! :-)
11:16 karolherbst: :)
11:16 karolherbst: well
11:16 karolherbst: fuc binaries
11:16 pmoreau: Haven't looked at it yet, only the cover letter
11:17 karolherbst: one new fuc file for gk104 is alone 1869 lines
11:17 karolherbst: + 4 times 750 lines for the others
11:18 karolherbst: it is basically only around 200 loc maximum
11:18 pmoreau: Whoah, ok :D
11:20 karolherbst: imirkin: good catch
11:27 karolherbst: mhhh
11:27 karolherbst: --in-reply-to= didn't work :(
11:28 imirkin_: karolherbst: did you read over the code you sent?
11:28 karolherbst: yes
11:28 karolherbst: why?
11:28 imirkin_: karolherbst: because there's a glaring bug in it
11:29 karolherbst: ohh, which one?
11:29 imirkin_: hint: it's on this line:
11:29 imirkin_: + u32 result[2], ret;
11:29 karolherbst: :O
11:29 karolherbst: now I see it
11:33 karolherbst: imirkin_: should be better now
11:35 imirkin_: indeed
12:03 karolherbst: imirkin_: I am used to use one line for each variable, so I think I need some experience with lining them up like used in nouveau usually
12:13 pmoreau: I guess having nv50->num_resources == 0 is not really what I want
12:13 imirkin_: not really.
12:14 imirkin_: you want to call ->set_compute_something
12:14 pmoreau: But it's strange, cause resource_create was called at some point
12:14 imirkin_: that's not what num_resources tracks
12:14 pmoreau: set_compute_resources?
12:14 imirkin_: yeah, why not
12:15 imirkin_: that whole api is subject to change btw
12:15 pmoreau: Oh
12:15 imirkin_: as compute shaders become more of a thing in GL
12:15 pmoreau: So, it's going to change in a good way then :-)
12:15 imirkin_: is there change in a bad way?
12:16 pmoreau: But, do you mean, just the Nouveau side of it or everything?
12:16 imirkin_: everythign
12:16 pmoreau: :D
12:16 pmoreau: Are there some patches landing alreay that I missed?
12:16 pmoreau: Or some discussions about it on the ML?
12:17 imirkin_: nnnot really
12:17 imirkin_: marek and i have discussed a bunch how images/buffers should be handled in shaders
12:17 imirkin_: there are new set_shader_buffers/images calls (or something liek that)
12:18 pmoreau: Ok
12:18 pmoreau: So, probably better for me to stay with the current version, hack around, try to understand what's going on, and then later move to the new architecture
12:19 imirkin_: yup
12:23 pmoreau: Hmm… set_compute_resources is called with a size of 0 and a nullptr…
12:24 imirkin_: maybe it's the set_global_resources? dunno
12:24 imirkin_: this stuff has immensely bitrotted in nouveau if it ever even worked in upstream code
12:25 pmoreau: :D
12:25 pmoreau: There is a set_global_bindings
12:26 pmoreau: But it's not defining any GLOBAL.ADDRESS_HIGH & co.
14:15 karolherbst: RSpliet: I really don't know what to do with you nitpick, sorry :D
14:16 karolherbst: it's somehow too minor to just modify the commit just for that
14:16 imirkin_: karolherbst: move the #endif up
14:16 imirkin_: instead of #if/#if/#endif/#endif do #if/@endif/#if/#endif
14:17 karolherbst: imirkin_: I got that part, for me it is just a too minor thing to actually care about it, but if that's some kind of rule which should be followed I will change it, but well, as long as nobody _really_ cares about that, I am kind of "meh"
14:18 imirkin_: pretty easy to change, and nested preprocessor is always harder to understand than non-nested
14:22 pmoreau: So… global is not considered to be a resource, neither by clover nor by Nouveau, but, Nouveau will never "bind" the global, cause that logic depends (and is executed upon) the number or resources…
14:56 pmoreau: Ok, got the global bound at the expected address. :-)
15:07 pmoreau: imirkin_: Do I need to set something to have it look in GLOBAL[0] rather than GLOBAL[x], or does it work automatically?
15:08 imirkin_: not sure what you're talking about
15:08 imirkin_: the fileIndex controls the index encoded into the instruction
15:09 pmoreau: There are 15 different GLOBALS[], so how do you pick the correct one, as there doesn't seem to be a g0[] or gX[]
15:09 imirkin_: ?
15:09 imirkin_: there is a g0[]...
15:10 imirkin_: or i dunno what you're tlaking about
15:10 pmoreau: Oh, doesn't appear in the prog->print then
15:10 pmoreau: But right, I remember seeing one in the envydis output
15:11 pmoreau: Then that should be good…
15:11 imirkin_: prog->print isn't authoritative
15:11 imirkin_: iirc it doesn't print the fileindex if it's 0
15:11 imirkin_: but it only prints what it's trying to encode, not what actually gets encoded
15:11 imirkin_: esp on nv50 there are a lot of errors in the emitter
15:12 pmoreau: ok
15:12 pmoreau: I haven't paid any attention to the fileindex
21:53 Guest66265: ACPI Warning: \_SB_.PCI0.PEG0.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150619/nsarguments-95)
21:53 Guest66265: ^ I think this is causing me no ends of trouble
21:54 imirkin: just an annoying warning
21:54 avi__: well, then something else is causing me no ends of trouble
21:55 avi__: (hi again, you helped me before with dithering)
21:55 imirkin: apparently every vendor has decided to go against the spec
21:55 imirkin: so what's the trouble now?
21:55 avi__: I am either able to load with optimus disabled, and then I get bad graphics output and occasional hangs
21:55 imirkin: optimus disabled == intel only or nvidia only?
21:56 avi__: (that I can't conclusively blame on nouveau, but it seems likely)
21:56 avi__: nvidia only
21:56 imirkin: when in doubt, blame nouveau!
21:56 avi__: or with optimus enabled, I get low backlight, without the ability to increase it, and some chome tabs do not get rendered
21:57 imirkin: with optimus enabled, nouveau is doing basically nothing
21:57 avi__: well, there is still disk activity and the caps lock light gets lighted, so it's not a full panic
21:57 imirkin: just powering off the gpu, and that's it
21:57 imirkin: unless you're explicitly telling it to do things
21:57 avi__: I'm sure I don't know how to do that
21:57 imirkin: like hooking up a screen that's only connected to the nvidia adapter, or doing 3d offloading
21:58 imirkin: do you use some sort of user-friendly DE?
21:58 avi__: how can I tell what's going on?
21:58 imirkin: those things are death traps
21:58 avi__: user-friendly? this is linux
21:58 avi__: I can barely see the screen now due to the dimmed backlight
21:59 avi__: Provider 0: id: 0x8d cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 4 outputs: 3 associated providers: 2 name:Intel
21:59 avi__: Provider 1: id: 0x66 cap: 0x7, Source Output, Sink Output, Source Offload crtcs: 2 outputs: 5 associated providers: 2 name:nouveau
21:59 avi__: Provider 2: id: 0x66 cap: 0x7, Source Output, Sink Output, Source Offload crtcs: 2 outputs: 5 associated providers: 2 name:nouveau
21:59 avi__: I can't tell why there are three providers, or which one is active now
22:00 avi__: 1 and 2 seem very similar to my untrained and unbacklit eyes
22:01 imirkin: avi__: i'm thinking like gnome/kde
22:01 avi__: oh, gnome 3, standard Fedora install
22:01 imirkin: ah, that's one of the death ones i think :) aka i have no clue what all it tries to do.
22:02 imirkin:prefers to be explicit
22:02 imirkin: anyways...
22:02 avi__: (sorry)
22:02 imirkin: nouveau's not driving your screens
22:02 avi__: how can I tell that?
22:02 imirkin: so your issue with backlight is that linux/gnome/something decides to use the wrong backlight control
22:02 imirkin: there's been a parade of kernel module params to help with it
22:03 avi__: ooh
22:03 imirkin: dunno what the latest is
22:03 imirkin: you can look in /sys/class/backlight
22:03 imirkin: and echo things into successive controllers until you find The One True Backlight
22:03 avi__: ls /sys/class/backlight/
22:03 avi__: intel_backlight nv_backlight
22:03 imirkin: intel_backlight i assume should do the trick
22:03 imirkin: if it doesn't, you want the acpi_video ones
22:04 imirkin: oh, also, pastebin the output of 'xrandr'
22:05 avi__: success! you were right
22:06 imirkin: as for all the provider stuff, that's for if you want to attach displays to the nvidia adapter but have it all be part of the one happy xrandr family
22:07 imirkin: sort of like new-age xinerama
22:07 avi__: http://fpaste.org/283953/44592237/
22:07 avi__: yeah, what I was wondering, is how to tell which one is active
22:07 imirkin: LVDS2 = intel
22:07 imirkin: how do i know? coz intel doesn't stick -'s in its connector names
22:07 imirkin: (yeah, real scientific)
22:08 imirkin: all the FOO-1 ones are on the nvidia adapter
22:08 imirkin: chances are you're getting the stupid ACPI warning messages when gnome/whatever decides to poll the VGA connector
22:08 imirkin: and i bet you don't even have a VGA connector on there in the first place
22:08 imirkin: but nouveau thinks there is a ghost one there
22:09 imirkin: and the gpu gets woken up for no reason every 30s
22:09 avi__: actually I do have a vga connector
22:09 imirkin: you can "fix" that by booting with video=VGA-1:d
22:09 imirkin: is it hooked up to intel or nvidia?
22:09 imirkin: (see how each one has its own VGA connector)
22:09 avi__: I can get a screwdriver and open up this thing
22:09 imirkin: easier to plug something in
22:09 avi__: how can I tell?
22:09 imirkin: and see where it shows up
22:10 avi__: well I have nothing to plug it in to here
22:10 imirkin: so just disable it and move on with life ;)
22:10 avi__: oh, I don't mind the error
22:10 avi__: I just blamed all my life's problems on it
22:10 imirkin: but i bet you mind the reduced battery life
22:10 avi__: yeah
22:10 avi__: I'll try it
22:11 imirkin: anyways, it's just a guess -- i've seen other laptops not suspend the nvidia gpu because of a phantom vga output
22:11 imirkin: that something decides it'd be a great idea to keep polling over and over
22:12 imirkin: should you want to offload 3d for a particular app, you can do that with DRI_PRIME=1 in its env. but the intel chip should be more than sufficient for most needs.
22:14 avi__: imirkin, only apps I use are browsers and editors
22:14 imirkin: right, i figured
22:15 imirkin: also without reclocking (which requires some experimental stuff), the intel chip is faster than nvidia in all likelihood as well
22:15 avi__: both are faster than me
22:15 avi__: well thanks a lot, I am better off than before, though still having problems
22:15 avi__: but these are due to chrome and/or intel, not nv
22:16 imirkin: try #intel-gfx
22:16 imirkin: the intel guys are generally helpful (although most likely presently asleep)
22:16 imirkin: too late for portland, too early for finland
22:16 avi__: yeah, google says this is a known chrome issue on intel
22:17 imirkin: what's the issue? something with tooltips?
22:17 imirkin: i use chrome on intel/haswell at work, haven't seen any serious issues except the gpu process needs to be kicked after xlock
22:17 avi__: no, tab doesn't get rendered when switching
22:18 avi__: https://code.google.com/p/chromium/issues/detail?id=516679 probably
22:18 imirkin: huh weird. well i'm using mesa 10.3.7 there
22:21 avi__: well, disabled gpu for chrome, let's see how it goes
22:21 imirkin: good luck!