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