00:11jkucia: imirkin_, skeggsb_: It works in 11.2.0-devel (git-63b49e1). Thanks!
00:53mlankhorst: tagr: ok thanks :)
00:58mlankhorst: tagr: whats AVP btw?
00:58tagr: that's the Audio Video Processor, an ARM7 coprocessor used for, well, audio/video processing
03:27karolherbst: RSpliet: :D
04:31karolherbst: mhh those nvd7 vbios files are looking really like kepler ones for whatever reason
04:31karolherbst: just with some stuff missing
05:39imirkin: jkucia: if you do a (reverse) bisect, i can try to get the relevant change backported for 11.0
05:43RSpliet: karolherbst: that's well possible. iirc nvd7 has more similarities with kepler
05:44RSpliet: (was that not the first with the new display engine?)
05:44RSpliet: (oh, that might have been nvd9 instead... :-P)
05:45karolherbst: nvd9 looks much less like kepler
05:45karolherbst: I just noticed that the (currently) unk38 offset isn't read out for whatever reason
05:45karolherbst: but later it is
05:45RSpliet: nvd9's display block is very keplery, we didn't quite figure out how to get PMU to sync to vblank for those cards yet I think
05:45karolherbst: envy_bios_parse_power_unk38 doesn't ahve the offset, but envy_bios_print_power_unk38 has
05:47RSpliet: but yes, there is no guarantee that a given VBIOS version matches a specific generation of cards.
05:47RSpliet: (which, at the moment is not very well represented in the memory reclocking script)
05:58karolherbst: meh, I always thought by now devs stopped doing work in display threads, but oh well :/
06:07karolherbst: anybody against making those structs static? https://github.com/karolherbst/envytools/blob/master/nvbios/power.c#L58
06:07karolherbst: they get allocated everytime the function got hit ;)
06:10karolherbst: and now I found the error
06:10karolherbst: envy_bios_parse_power_cstep overwrites the offset of unk38?
06:11karolherbst: what a pain in the ass issue
06:11pq: karolherbst, but if they are static, they only get initialized the first call but not following? is that an issue?
06:11karolherbst: pq function static?
06:11karolherbst: they are initiliazed for every function call then
06:11karolherbst: just like global statics
06:12karolherbst: only inside function scope
06:14karolherbst: out of bound access :/
06:15pq: global statics get initialized just once, did you just contradict yourself? ;-)
06:16karolherbst: function statics are the same
06:16karolherbst: just scoped inside that function where they are declared
06:17pq: yes, I was asking, isn't that a problem as you initialize with a function argument?
06:17karolherbst: mhhh right, would need a bit of refactoring, but the thing is always the same
06:17imirkin: karolherbst: static const.
06:19karolherbst: pq: you can have something static inside the function depending on the function parameters
06:19karolherbst: but then only the first call ever counts
06:19pq: karolherbst, yes exactly, I was asking if that is a problem :-P
06:19karolherbst: I doubt that
06:20karolherbst: but to be clean it should be refactor, right
06:20pq: it's certainly very suprising for anyone going to call that function
06:20karolherbst: now I am too lazy for that :D
06:21karolherbst: this loop causes big troubles
06:21karolherbst: cstep->entriesnum is 8
06:21karolherbst: but cstep->ent1 is envy_bios_power_cstep_entry1
06:22karolherbst: and that totally ofervlows into the unk38 struct
06:25karlmag: karolherbst: envytools/info.c line 254; "bios->chipset = 0x117;" isn't chipset an int? (Sorry if I'm wrong, but I just found that a bit suspicious)
06:25karolherbst: what is wrong there?
06:25karolherbst: can't 0x117 be an integer?
06:26karlmag: if chipset is an int, then 0x117 > 0xff ?
06:26karolherbst: int is platform dependent
06:26karlmag: ah, right.. of course it is..
06:26karolherbst: it is at least a WORD I think, not sure though
06:26karolherbst: but any OS can do as they like usually
06:26karlmag: I just noticed that in bios.h it was defined as int, so I figured it was better to point it out than leave it in case it was wrong.
06:27karolherbst: int is 32bit on 32bit linux and 64bit on 64bit linux, not _quite_ sure though. Could be 32bit on both
06:27karlmag: I'm a real n00b when it comes to programming (C in particular)
06:27karolherbst: ohh no
06:27karolherbst: that was with long
06:27karolherbst: int is 32bit on linux
06:27karlmag: ok then, sorry for the interruption. Carry on. :-)
06:28karolherbst: karlmag: for example long is 32bit on 32bit linux and windows, and 64bit on 64bit linux
06:28karolherbst: so long is also 32bit on 64bit windows ;)
06:28karlmag: yeah, isn't it fun? :-P
06:29karlmag: In my world an int probably will (more or less) stay 8bit..
06:30karolherbst: imirkin, RSpliet: is this okay for you? https://github.com/karolherbst/envytools/commit/34999c5d36f6ad843582e358bf4870f8cd5e8904
06:31imirkin: karlmag: outside of programs compiled for 16-bit real mode, int is always 32-bit on x86. in those (very old) programs, it's 16-bit.
06:31imirkin: karolherbst: sgtm
06:32imirkin: karolherbst: are there other asserts btw? if not, i'd prefer some sort of nicer way of handling this
06:32imirkin: but ultimately i don't reallyc are
06:32karolherbst: I bet they are
06:32karolherbst: maybe not
06:33karlmag: imirkin: last time I did programming was around 15 years ago I think. Except a bit on arduino (which is 8bit) in later years. I guess I'm not quite up to speed to say the least :-P
06:34imirkin: karlmag: 15y ago was 2000. already well into the 32-bit heyday
06:34karolherbst: mhh before that I never used assert, but now I felt why someone should use them :D
06:35imirkin: karlmag: if you don't know about far pointers, _farmalloc, etc -- it was all before your time :)
06:37karlmag: imirkin: Not really sure I programmed in any language really requiring knowing that much about variable sizes.
06:38karlmag: Maybe I'll be able to sit down and learn enough to be useful at least to myself, hopefully to others too.. At some point
06:38karlmag: <- too many projects.. always.. I need to live till I become 350 or so I think.
06:38imirkin: nah, just get more hours in the day
06:38imirkin: that's what i do!
06:39karolherbst: who needs sleep anyway :p
06:40karolherbst: karlmag: may I intruduce you to the 6 day week?
06:40karolherbst: aka 28 hour day
06:40karlmag: imirkin: it's still limited to 24, and I've found that some are required for sleep (at least some of the days) and I need paying work, because otherwise I can't eat or buy cool stuff :-P
06:40karlmag: karolherbst: hehe
06:40karlmag: karolherbst: I've heard about it before. Unfortunately it doesn't play well with "normal" work..
06:41karlmag: and other "fixed" activities
06:41karolherbst: yeah well
06:41karolherbst: there is always a sacrifice to everything
06:44imirkin: karlmag: can't have it all
06:45karlmag: imirkin: oh, I do want... but yeah, I know that. Older and wiser (?) and all that :-P
06:57mwk: karlmag: int is guaranteed to always be at least 16-bit by C standard, and is 32-bit on any modern platform
06:58imirkin: was it 18- or 36-bit on those funky pdp's?
06:59karlmag: imirkin: might have ben even weirder values than that.
06:59karlmag: mwk: thinking about it, I might have mixed it up with "char" or whatever.
06:59imirkin: char is, amusingly, an unsigned short on java
07:00imirkin: the only unsigned type available
07:00karlmag: 36 is (8+1)*4 btw.. ECC ? :)
07:01imirkin: no, just 36-bit
07:01karlmag: I know
07:01imirkin: no fundamental reason for words to be a power-of-two bits
07:02karlmag: I seem to remember 41 bit words for some really weird type of machine too, but can't for my life remember which.
07:03karolherbst: mwk: no, there is none
07:03karolherbst: mwk: only int >= short
07:04karolherbst: ohh wait
07:04karolherbst: at least in C99 int has to be at least 16 bit
07:06karolherbst: imirkin: well char in C is neither signed nor unsigned, so this is also kind of weird ;)
07:09imirkin: i guess
07:16karlmag: a bit like quantum mechanics then. (Though you might not be sure even if you observe the char)
07:34RSpliet: karolherbst: good catch... valgrind or good old facedesk?
07:35RSpliet: I think it's acceptable, but check with mwk whether he minds assertions in nvbios (otherwise just do a conditional printf + return with an error code)
07:35karolherbst: RSpliet: mhh qtcreator debugger :D
07:35karolherbst: so facedesk
07:39karolherbst: RSpliet: I think the guess was right that the first byte is the pstate: -- entry 10, pstate = f, clock = 324 MHz, unk = 0 -- entry 11, pstate = 7, clock = 324 MHz, unk = 0
07:39karolherbst: and it makes somehow always sense
07:40karolherbst: RSpliet: my patch does something like that now https://gist.github.com/karolherbst/28fcfc36013873249077 (this is from a nvd7)
07:40karolherbst: any suggestions for the layout?
07:46karolherbst: RSpliet: I think this table isn't as kepler specific as I thought, I also found a nvc1 with it
07:49mwk: karolherbst: assertions in nvbios is a rather bad idea
07:49mwk: since we don't really know the bios format are are just guessing at many things, we'd want nvbios to print as much as it can
07:49karolherbst: yeah I can change it to an error print, I don't mind that big
07:49Tom^: karolherbst: sure im all free for testing various things on the weekend.
07:49mwk: if something fails, just error a single table and print the others
07:50mwk: assert is kind of at odds with that
07:50mwk: also, do not *ever* use assert for input validation
07:50karolherbst: so if and ENVY_BIOS_ERR?
07:50mwk: it has an annoying habit of being compiled out of non-debug builds
07:51karolherbst: yeah I know
07:51mwk: it's only ever ok to use to verify you did not mess something up in your own calculations
07:51RSpliet: karolherbst: that's a good start... but would you mind making that hierarchical? (eg print the clocks in a for (i = 0; i < secount; i++) loop)
07:52RSpliet: we haven't seen it yet, but the way it's written down obscures the fact that this hierarchy exists
07:56karolherbst: mwk: better? https://github.com/karolherbst/envytools/commit/3f240d2026711dadaff2c9815420f04227216876
07:56karolherbst: RSpliet: k
07:56RSpliet: good stuff!
07:59RSpliet: when you go and push upstream, make sure to squash the "remove asserts" patch into "don't go out of bounds" btw
08:00karolherbst: RSpliet: I already did pushed the one commit :/ sorry
08:00RSpliet: hmm okay, too late I guess
08:00RSpliet: well, don't worry about it then
08:01RSpliet: we'll just call it a "learning moment" then ;-)
08:12karolherbst: RSpliet: better? https://github.com/karolherbst/envytools/commit/1d15f0cd227e95dbe47398e987ea2e3f5898e471
08:13karolherbst: it will look like this now: -- entry 0, pstate = f, unk = 11781d4b, clock0 = 1725 MHZ
08:20karolherbst1: and this time it wasn't nouveaus fault that my kernel crashed
08:25karolherbst: Tom^: I managed to start the application with wine though
08:25RSpliet: karolherbst: better yes. I'd personally prefer a format like you see with the perflvl table or the training data because I hate arbitrary line wrapping (I often parse VBIOSes while in an 80x24 terminal :-P), but it's hard to understand what the data will be like once NVIDIA starts using the subentries (if...)
08:26RSpliet: so for all I know this might just be sufficient
08:26karolherbst: RSpliet: yeah, I just thought inserting a new line just in case there _might_ be more makes things somehow ugly for the general case :/
08:27karolherbst: did anybody of you get something like that: https://bugzilla.kernel.org/show_bug.cgi?id=104071 =
08:27karolherbst: maybe nouveau meses up something in the runpm parts
08:27RSpliet: with three clocks this line will wrap... we can always change that later I guess :-)
08:29RSpliet: graduately when we figure out what the two unknown 16-bit ints are for, formatting will change anyway
08:29karolherbst: I just ran evry vbios through this
08:29RSpliet: nitpick, it's MHz, not MHZ :-)
08:29karolherbst: ohh wait I have to run everything through that again
08:32karolherbst: RSpliet: maybe the subentries are used for dual core gpus?
08:32nchauvet_: hi, is it possible that running bbswitch kernel module would "lock" or permanently disable the nvidia gpu accross reboot in an optimus configuration ?
08:33nchauvet_: I'm reading this , but not sure if there is the info :http://nouveau.freedesktop.org/wiki/Optimus/
08:33karolherbst: nchauvet_: yes
08:33karolherbst: nchauvet_: the gpu has to be turn on _before_ the machine unloads the kernel
08:33karolherbst: same deal with kexec
08:34nchauvet_: okay, so that might explain why xrandr doesn't output the same as before
08:34karolherbst: usually bumblebee takes care of that
08:35RSpliet: apart from the nit: I'm not completely sure whether "base_clock" covers the contents well, but that'll easy end up in bikeshedding so I'm not going to make a suggestion there
08:35RSpliet: maybe tagr or gnurou want to drop the (semi-)official name if they care about consistency, otherwise I'll leave that to the veterans :-P
08:35RSpliet: with those minor issues addressed, I'm game for merging
08:35RSpliet: karolherbst: I... hmm... well, I'd assume each core has it's own VBIOS
08:35RSpliet: but who knows
08:36RSpliet: (shameless re-post after that little mass-pingtimeout coming up:
08:36RSpliet: apart from the nit: I'm not completely sure whether "base_clock" covers the contents well, but that'll easy end up in bikeshedding so I'm not going to make a suggestion there
08:36RSpliet: maybe tagr or gnurou want to drop the (semi-)official name if they care about consistency, otherwise I'll leave that to the veterans :-P
08:40nchauvet_: I don't understand what should handle the needed issue in upstream kernel with this oot module
08:40nchauvet_: (oot module is bbswitch here)
08:49Tom^: karolherbst: oh ok
08:52karolherbst: nchauvet_: bbswitch.unload_state=1
08:53nchauvet_: karolherbst, yep, but either why this bbswitch is not upstream or any other upstream module can take over this capability ?
08:54karolherbst: nchauvet_: no, except nouveau
08:54karolherbst: well acpi_call can also do it
08:54nchauvet_: or maybe there is plan to handle things differently with prime ? (never deal with software/mux) but disabling the dGPU with nouveau or else ?
08:54karolherbst: but then you need to do an acpi call
08:54nchauvet_: karolherbst, acpi_call isn't another oot module ?
08:54imirkin: nchauvet_: the upstream way is to use nouveau.
08:55karolherbst: nchauvet_: if you build your kernel yourself: you _need_ to enable vgaswitcheroo ;)
08:55imirkin: nchauvet_: acpi_call is provided by the kernel (potentially under acpi debug features)
08:55imirkin: nchauvet_: however if you use it, you're on your own
08:56imirkin: nchauvet_: nouveau will power your gpu on/off as needed
08:56imirkin: if you fight with it, your hw is likely to lose :)
08:56nchauvet_: okay, so bbswitch is nvidia only ?
08:56karolherbst: nchauvet_: bbswitch is neither
08:56imirkin: bbswitch can be used with whatever, you just have to be super-careful.
08:56karolherbst: bbswitch just does a acpi call
08:57karolherbst: nchauvet_: I have all of that stuff here in parallel for example
08:57imirkin: however i advise strongly against using bbswitch with nouveau
08:58imirkin: just coz karolherbst does it doesn't mean everyone should :) he does it because he (a) has a solid understanding of the underlying issues and (b) constantly switches between nvidia and nouveau
09:04karolherbst: not so much anymore though
09:04karolherbst: I mean switch between nvidia and nouveau
09:04karolherbst: just nouveaus runpm is a bit bricked
09:04karolherbst: worst case scenario: gpu hangs, clients are destroyed and nouveau just turns the gpu off while some nvioread operations are going on
09:04karolherbst: have to figure them out sometime
09:07karolherbst: mwk: so is this fixup fine? https://github.com/karolherbst/envytools/commit/3f240d2026711dadaff2c9815420f04227216876
09:07karolherbst: I don't think I got any answer from you :p
09:37nchauvet_: well, I need a distro package maintainer level of understanding, so basically for my own usage I would stick to nouveau for desktop, but I sometime needs nvidia binary for toying with cuda. But as an unfortunate distro package maintainer (of nvidia binary for fedora from rpmfusion.org) I need to handle all cases
09:37nchauvet_: sorry was away on dayjob tasks btw...
09:38nchauvet_: so as I understand bbswitch should only be usefull for nvidia binary driver, as there is no way to handle switching the dGPU from nvidia binary driver ?
09:41imirkin: nchauvet_: for the vast majority of users, yes
09:45karolherbst: nchauvet_: use bbswitch only with bumblebee for the general case
09:46karolherbst: the use should _never_ have to mess with bbswitch directly itself
09:46nchauvet_: karolherbst, yeah, but bumbleble is hacking our packaging of the driver in our back, so I might try to figure out what need to be changed
09:53karolherbst: nchauvet_: well, without bumblebee you can't use the nvidia gpu with the nvidia driver
09:53karolherbst: on laptops
09:53karolherbst: or when intel is the main gpu
09:54karolherbst: nchauvet_: and what do you mean by "hacking"? usually nvidia packages replace the mesa libgl, which is _not_ what the user want with a dual gpu setup where the main gpu is driven by mesa
09:54karolherbst: I already had the situation where I had to repair stuff on ubuntu machines because of that
09:55nchauvet_: karolherbst, right, but I can use cuda, using nvidia for OpenGL seems rather high level for me still( despite I try to toy with libglvnd)
09:55karolherbst: nchauvet_: you can of course
09:55karolherbst: cuda doesn't depend on X running on the nvidia ddx
09:55karolherbst: just the kernel module afaik
09:56karolherbst: but then you don't have the automatic power management anymore
09:56karolherbst: if you don't use bumblebee
09:56karolherbst: you want to use bumblebee if you want to stay user friendly, trust me
09:56nchauvet_: karolherbst, yep, but there are cuda apps using opengl, theses will fails apparently (don't know why)
09:57karolherbst: nchauvet_: yeah, but then you need to run them through optirun/primusrun
09:58karolherbst: I bet they use some nvidia extensions to share stuff between gl and cuda
10:10imirkin: nchauvet_: basically there are a few mutually-exclusive user scenarios. you need to allow switching between them.
10:10imirkin: nchauvet_: look at how gentoo does it... afaik that's the only distro that does it sanely
10:10nchauvet_: imirkin, thx, will have a look
10:10nchauvet_:going away for tonight
23:46gnurou: re : GM20X texture issue, we have confimed that this has nothing to do with shader operand scheduling (the conservative values used by Mesa are fine). Seems to have to do with texture setup instead?
23:47gnurou: I went as far as replacing the Mesa fragment shader with one generated by our driver, and behavior was identical
23:48gnurou: also attributes interpolation is correct, for some reason the TEX instruction just returns black...