06:50kloofy: so for the scheduling, it should be quite easy , i can't pull myself together too much conspiracy and conflicts, i think i am starting to leave from the scenes, there is not much useful going on on the channels to me
06:50kloofy: and i have bit of the more complex stuff to do, where i finally need to find/compose myself
07:14karolherbst_work: okay, I think I found the current issue with the PMU on maxwell2: the PMU performs the secboot sequences for the FECS and GPCCS falcons and gets disabled afterwards. It is a bit badly designed, that this happens in the secboot subdev, where the pmu is controlled in the pmu subdev. Maybe I could come up with a better design, but I would rather not change anything there at all and rather leave it to gnurou.
09:19karolherbst_work: skeggsb: how well do you know the secboot process?
09:41mmaret: imirkin, I'm not use to play with perf. Any particular cmdline you want me to record ?
09:42mmaret: cat /proc/interrupts show that irq are executed on lats cpu
09:42mmaret: so something like perf record -g -C 7 ?
10:03kloofy: mmaret: imirkin is sleeping not in timezone
10:39karolherbst_work: I was sometimes thinking about having something like a nouveau staging tree, where we can simply push new experimental stuff, so that users get stuff earlier for testing purposes, but I fear that this wouldn't work out due too high management overhead, kind of like wine and wine-staging or so, just where nouveau-staging would be rolling release like. Or maybe it could be just a simple collection of patches and through a config file t
10:39karolherbst_work: Just a wild idea
10:39karolherbst_work: I doubt I care enough for this though
11:07mupuf: hakzsam: do you have tme to wokr on the abstract?
11:07mupuf: pmoreau: let's talk about it here
11:08mupuf: the current plan was: I talk about the kernel, with karol if he wants, because Ben is not too enthusiastic about giving presentations
11:08mupuf: then, samuel speaks about the userspace
11:09mupuf: mostly GL features actually
11:09mupuf: and you would talk about your work on SPIR-V and objectives
11:09mupuf: and Hans could talk about his work on opencl
11:09mupuf: if not, then pmoreau may be talking abpout it
11:11pmoreau: mupuf: I asked Hans, and he was not planning on talking about his stuff as he hasn’t made much progress since FOSDEM.
11:13pmoreau: Plan seems good.
11:13pmoreau: How much do you think the whole presentation will last? For my part, I think 15 min for everything should be enough.
11:16mmaret: kloofy, thx!
11:35hakzsam: mupuf, not sure if I will have time today
11:38karolherbst_work: mupuf: I would join the talk
11:39karolherbst_work: If I talk about my stuff in the general nouveau presentation I would need maybe 5minutes for hwmon + pcie
11:39karolherbst_work: and a bit reclocking, so maybe 10
11:40karolherbst_work: performance figures of kepler+maxwell gpus would be nice
11:41karolherbst_work: mupuf: also, we need to check if we really can't adjust the fan, because while playing with your gm206 yesterday, the fan was between 900 and 960 rpm
11:43pmoreau: mupuf: So how do we do for the abstract? The deadline is at 17:00 if I am not mistaken
11:44karolherbst_work: pmoreau: deadline for formal acceptance ;)
11:44pmoreau: Ah, there is the informal as well? :-D
11:44karolherbst_work: everything else
11:44karolherbst_work: formal accepted stuff will be allowed to present
11:44karolherbst_work: and the remaining time is filled with everything else
11:45karolherbst_work: "Presenters will be selected from those who submit before the deadline. There is usually time left for late talk proposals, but do not count on it."
11:45karolherbst_work: "If you don't want to follow the formal talk submission with the https://www.x.org/wiki/Other/Press/CFP2016/ you can also just list your talk below. Some proposals are marked as "formally accepted", this means they got submitted to the board of directors before the deadline and got accepted by the election committee."
11:45hakzsam: well, writing an abstract takes only 30 minutes :)
11:45hakzsam: I will try to do it
11:45pmoreau: For the whole thing then?
11:46karolherbst_work: and as long as my talk isn't formally accepted it might be, that I won't be able to give the talk
11:46karolherbst_work: well, at least this is the way I understood it
11:46karolherbst_work: but maybe mupuf already made it clear that there _will_ be a nouveau status talk :p
11:53karolherbst_work: pmoreau: do you think you might find some time to check reclocking on your maxwell2, too? I would like to know if there are problems when actually running a display
11:54mupuf: hakzsam: ok, I can write a small abstract
11:54pmoreau: karolherbst_work: Yes, I should be able to test
11:54mupuf: pmoreau: 10 minutes, since it is prospective work mostly, and you can then tell what features are supported and missing
11:54karolherbst_work: pmoreau: awesome :) if you want to test it, you just need my usual branch and built two versions of nouveau, but I could give you a detailed description if you want
11:55pmoreau: mupuf: With the 15, I was also including any questions
11:56mupuf: karolherbst_work: I would say that you keep your talk about power, let's concentrate on the rest of the kernel. The point would be to summarize all the changes that were done. Power is just a few lines
11:56pmoreau: But 10 min otherwise should be good too
11:56karolherbst_work: mupuf: right, I didn't plan to actually talk about it
11:56pmoreau: karolherbst_work: I’ll probably ask for the details when I am actually in a position to try it. :-)
11:57karolherbst_work: pmoreau: k
11:57hakzsam: mupuf, 10/15 minutes are large enough for the userspace part as well
11:57mupuf: the formal approval is : Let's wait for all the proposals, select them if we have a shortage of timeslots, and tell who has been accepted
11:57mupuf: all of them will likely be accepted
11:58mupuf: because they are all in the scope of the conference
11:58mupuf: so, all is well!
11:58mupuf:needs to write two abstracts, so, if you can write the one for noiuveau, I would appreciate it
11:59hakzsam: mupuf, I will do
11:59Tecan: where can i check available video modes for nouveau
11:59mupuf: Tecan: xrandr?
12:14hakzsam: karolherbst_work, pmoreau, what about this http://hastebin.com/lavikorizu.pas ?
12:15pmoreau: hakzsam: line 3, you are missing an "update" after "status"
12:15Tecan: ok i have 2 lcd monitors flipped vertical but the screen mode wont allow for things running fullscreen across both, while using nvidia i had some of the video modes in the xorg.conf file, is that where they go for nouveau aswell ?
12:17pmoreau: hakzsam: Otherwise sounds good.
12:17pmoreau: Thanks for writing right
12:17karolherbst_work: hakzsam: a bit general, but I am fine with that
12:18hakzsam: karolherbst_work, yeah, it's an abstract :)
12:18hakzsam: karolherbst_work, maybe you prefer that one https://www.x.org/wiki/Events/XDC2015/Program/#courbot_peres_nouveau ? :p
12:19karolherbst_work: much better, straight to the point
12:19karolherbst_work: but it would be nice to show some gtx 980 heaven benchmark results…
12:19karolherbst_work: will be troublesome to get some though
12:20karolherbst_work: but hey, it is just 165W we are talking about
12:20hakzsam: I'm going to send the abstract to the board members
12:21karolherbst_work: mhh you want to say "status" or "status update"?
12:21karolherbst_work: "give you a status of the Nouveau driver since" wounds odd
12:21mupuf: karolherbst_work: who has access to a GTX 980?
12:21mupuf: give you the status
12:21mupuf: or give you a status update
12:21hakzsam: or "give you a status update"
12:21karolherbst_work: mupuf: no idea, this is part one of the troubling parts :D
12:22hakzsam: mupuf, :)
12:23karolherbst_work: mupuf: but if I don'T find anything else, I can still roast your 960 :p
12:24karolherbst_work: but what we really need is a 980 ti benchmark
12:24mupuf: what for? to show it performs pretty well? We just need to show a diff between nvidia and nouveau
12:25hakzsam: abstract sent
12:27karolherbst_work: mupuf: right
12:28karolherbst_work: mupuf: well, I have no clue how hot the gpu gets when running unigine though and how I can start it over ssh. Maybe I just run the gputest benchmarks or so
12:28karolherbst_work: allthough nouveau gets pretty high results there in general, so it would be a bit of cheating
12:28mupuf: use ezbench, it will dump metrics such as power usage and temperature
12:28mupuf: (Yes, finally!)
12:28karolherbst_work: ohh right
12:28karolherbst_work: I guess I use this then
12:29mupuf: and then you can use it to compare between mesa and the blob
12:29mupuf: and you will get the gaps in performance
12:29karolherbst_work: if something smells burnt then in the next days, no worries, it is just me doing benchmarks :p
12:29mupuf: lovely :D
12:29karolherbst_work: but I actually got the rpm values from the fans
12:29karolherbst_work: that keeps me wondering
12:30mupuf: karolherbst_work: that it may work out of the box?
12:30mupuf: well, I would be surprised all of it works. The fan readout may not be super accurate
12:30karolherbst_work: mupuf: no, that we might be able to actually control the pwm fans, maybe
12:30karolherbst_work: no clue
12:30mupuf: you will see with ezbench
12:30mupuf: nope, I tried again...
12:30karolherbst_work: maybe we can from the pmu
12:31mupuf: even the GPIO is not accessible
12:31mupuf: yes, from a privileged PMU
12:31karolherbst_work: yeah, that won't fly
12:31karolherbst_work: if I have the secboot subdev enabled, I couldn'T do shit with the pmz
12:35karolherbst_work: mupuf: just the one pwm gpio? mhh
12:37mupuf: yeah, I wondered if I could do bang the gpio myself
12:41karolherbst_work: I think I will try something with an unprivileged pmu then. did you actually check, that the pmu is up and working?
13:00karolherbst_work: does anybody work on the fermi on reator this week? Otherwise I would like to do benchmarks over the week for kepler, maxwell1 and maxwell2
13:00karolherbst_work: ohh wait
13:00karolherbst_work: wasn't there a kepler?
13:00karolherbst_work: don't mind me then, I will check later today
13:08mupuf: karolherbst_work: I can put anything
13:08mupuf: and hakzsam will be busy with his GTX 750 soon. I ordered one for him
13:08mupuf: for him to continue his excellent work
13:09mupuf: pmoreau, karolherbst_work, hakzsam: here we go, abstract posted
13:09mupuf: now, my turn :D
13:09hakzsam: karolherbst_work, and I will probably don't have time this weekend to work on nouveau
13:09hakzsam: mupuf, yep, thanks!
13:09mupuf: 19 talks already!
13:11karolherbst_work: mupuf: k, then I wish for your fastest maxwell1 (hihi) and the coolest maxwell2
13:14karolherbst_work: mupuf: nice, and most of them indeed sound interesting as well
13:25pmoreau: mupuf: Great, thanks!
13:27imirkin: Tecan: try to find a guide about it generically - nothing nouveau specific in monitor configuration (unlike with nvidia, who invented their own thing)
13:33Cloudef: pardon my ignorance but what are the technical implications of having vulkan on nouveau
13:35imirkin: Cloudef: step 1: implement. step 2: celebrate.
13:37karolherbst_work: I heard it is a crap load of work
13:39karolherbst_work: Cloudef: well, new contributors are always welcomed :)
13:43Cloudef: I'm sort of lost what exactly it means to implement hw support on nouveau for vulkan though. How does mesa fit on the picture for example. I see mesa has "vulkan support" but what does that really mean, it implements the API and provides some backend such as software rendering?
13:43Cloudef: Vulkan also has this runtime that is completely alien to opengl, I would really need to read more I guess
13:46Cloudef: also wondering is there already some sort of low level graphics API that is portable between open source drivers that is just used to implement opengl / vulkan on top of
13:46imirkin: tbh, i never felt like mesa + vulkan were a good match
13:47imirkin: no, having a "low level api" wouldn't really work with vulkan
13:47Cloudef: imirkin: I'm having same feeling when I'm reading about mesa tbh, it seems to originally designed to just be opengl implementation (software one on that)
13:47imirkin: the reason people are stuffing vulkan into it is to share compiler-related bits
13:47pmoreau: Isn’t anv only living in the Mesa tree, but not depending on any Mesa API, apart from NIR maybe?
13:48imirkin: when/if i eventually start a vulkan impl, it'll definitely be outside mesa
13:48Cloudef: (brb, will visit shop, but will read backlog in case of interesting discussion sparked by this)
13:49Cloudef: imirkin: shader compiler bits you mean?
13:49karolherbst_work: imirkin: that was kind of the original plan anyway: 1. move the compiler put 2. make a new vulkan project … or something along these lines
13:49mupuf: pmoreau: it depends a lot on the DRI bits too
13:49imirkin: karolherbst_work: indeed, that was my original plan ;)
13:49mupuf: imirkin: we would need to split out the dri-related bits out of mesa
13:50imirkin: Cloudef: yes, shader compiler bits
13:50imirkin: mupuf: indeed. i'm hoping they are few.
13:50karolherbst_work: imirkin: I am sure you made up your plan later :p
13:50pmoreau: mupuf: Oh, ok. I thought Jason was saying it could stand on its own.
13:50Cloudef: assuming dri == drm, there are quite few, what I've explored
13:50imirkin: dri != drm
13:51Cloudef: do you mean the X driver infrastructure parts then?
13:51imirkin: dri == X extension
13:57mupuf: pmoreau: yeah, but only if you split mesa out a bit
15:03karolherbst_work: mupuf: do you know by any chance how to drop the PMU from HS mode to sane mode again?
15:03mupuf: sane mode?
15:03mupuf: high security?
15:03mupuf: sane = untrusted?
15:04mupuf: there is doc from nvidia about this, isn't there?
15:04karolherbst_work: ohh right, the official name is NS for non-secure
15:04karolherbst_work: ohhhhh right
15:04karolherbst_work: totally forgot about that
15:06karolherbst_work: the thing is, according to the comment in gm200.c, no falcon stays in HS mode after secboot completes
15:06karolherbst_work: maybe I just need to run the pmu subdev stuff _after_ secboot and be done with it
15:17iterati: Hi, which branch supports kepler reclocking with 4.7 kernel ?
15:22karolherbst_work: iterati: https://github.com/karolherbst/nouveau.git -b https://github.com/karolherbst/nouveau/tree/stable_reclocking_kepler_v5
15:22karolherbst_work: stupid url replace thingie
15:23iterati: thanks karolherbst_work
15:25siro__: karolherbst_work: is it possible to expose gpu freq and gpu load to display it using GALLIUM_HUD, like it's possible on radeon ?
15:25karolherbst_work: sure it is, but where is the point currently?
15:25karolherbst_work: no idea how radeon does that though, I guess some radeon only drm interfaces
15:26karolherbst_work: well, I am all for actually implementing it also in nouveau though
15:28stratact: I'm running on dual monitors and both monitors are mirroring the same output, is there a way to fix this so that each monitor is a separate screen?
15:30karolherbst_work: stratact: configure it via xrandr or any gui frontend
15:30karolherbst_work: (aka systemsettings - display, settings - whatever, arandr)
15:32siro__: karolherbst_work: yes, it's done via drm interfaces. I find it very useful to find performance bottlenecks within mesa or wine
15:34stratact: karolherbst_work: thanks for the hint. ;)
15:42siro__: karolherbst_work: do you use gpu load / perf counters for dynamic reclocking ?
15:43karolherbst_work: siro__: yes, but different ones than the ones from gallium_hud
15:43karolherbst_work: siro__: but I guess this interface is radeon only? mhh I would really like to have a more generic one for everyone, but that would mean some stupid string -> value mapping
15:44karolherbst_work: still makes sense
15:45imirkin_: siro__: "load" isn't a clearly easy thing to measure, diff gpu's will always present it in different ways
15:46karolherbst_work: Majestik MÃžÃžse the hack :O
15:50imirkin_: in any case, it would be nice to expose those pmu load counters, as they'll definitely be needed to allow implementing user-space reclocking policies
15:52karolherbst_work: well, from the kernel side it is pretty much done, just no drm/nvif interface done yet
15:52karolherbst_work: imirkin_: tell me what you want, and I build it
15:53imirkin_: i want!
15:53imirkin_: me wantee!
15:53karolherbst_work: well, if you just want: pmu_counters branch
15:53karolherbst_work: debugfs gets a current_load file :p
15:53imirkin_: is there uapi for it?
15:53imirkin_: ok, that's ... annoying
15:53imirkin_: it has to be ioctl-based, or ... something. debugfs is obviously out.
15:53karolherbst_work: as I said: no nvif/drm interfaces
15:53imirkin_: although if it's debugfs, chances are there's uapi for it
15:53imirkin_: in the new world
15:54karolherbst_work: just tell me how you want that interface to be and I implement it
15:54karolherbst_work: isn't there some nice drm interface for that already?
15:54karolherbst_work: and currently I just added core/mem/pcie/video counters
15:54imirkin_: i haven't fully thought that through, but i think just a plain getter should be enough there
15:55imirkin_: i dunno. ask people more in touch with the drm world. like ben or dave.
15:55karolherbst_work: thing is, currently it reads from the pmu every single time
15:55karolherbst_work: and this is… slow
15:55karolherbst_work: really slow
15:55karolherbst_work: seriously, I asked ben multiple times already about that
15:55imirkin_: ok, so then you want an event-based thing
15:56imirkin_: to keep track of the current values in the kernel
15:56imirkin_: and just send them out when hitting a get ioctl
15:56karolherbst_work: the pmu should just tell the host every second or so
15:56karolherbst_work: or something along those lines
15:57karolherbst_work: I don't want to create many interrupts though
15:57karolherbst_work: but the pmu will tell the host often enough due to reclocking anyway
15:57karolherbst_work: have to check how nvidia handles that
16:00imirkin_: once per second is basically free in computer tersm
17:55karolherbst: mupuf: are you home today? I might need you to verify fan noise or so, maybe I won't need you at all ;)
18:37karolherbst: mupuf: clock gating under full load: 65W -> 58W
18:38karolherbst: I am sure some engines are still unused
18:38karolherbst: well wtvr
18:41mlankhorst: imirkin_: depends how much you value your battery life. ;-)
18:41imirkin_: mlankhorst: well, if the gpu is suspended it wouldn't unsuspend just for that
18:42imirkin_: mlankhorst: but in a laptop with an nvidia gpu that is being used, i don't think that's going to make a dent in battery life
18:43karolherbst: 9fps pixmark_piano on the 960
18:43karolherbst: 54fps furmark
18:43karolherbst: with furmark: 110W :O
18:44karolherbst: but gpu never hotter than 80 °C
19:00tobijk: karolherbst: real scheduling is missing to get your gpu to the boilingpoint :)
19:00karolherbst: and it isn't mine
19:00tobijk: mh well that gpu
19:01karolherbst: maxwell sucks soo hard
19:01karolherbst: furmark: 1616 vs 5099 points
19:01tobijk: yeah damn that guy ;-)
19:02tobijk: karolherbst: reclocked vs not reclocked?
19:02karolherbst: nouveau full reclocked vs nvidia
19:02karolherbst: something is out of place
19:02karolherbst: big times
19:03tobijk: yeah, is it really reclocked? doesnt look like
19:04tobijk: or they gave us slow vbios images ;-)
19:04imirkin_: we provide pretty pessimal scheduling information in shaders
19:04karolherbst: but, so bad?
19:04karolherbst: pixmark_piano: 263 vs 2936
19:05imirkin_: apparently :)
19:05karolherbst: have to check on nouveau with only engine reclocking
19:06karolherbst: it is so bad, that can't be right...
19:09karolherbst: furmark: without memory reclocking: 243, with memory reclocking: 1616, nvidia: 5099
19:10karolherbst: imirkin_: I guess you are right about the scheduling information
19:10karolherbst: and I thought that at least maxwell1 is in a pretty much usable state, but I guess performance will be really bad there too
19:11imirkin_: it's usable :)
19:11imirkin_: no one has really looked at any of that yet
19:11karolherbst: mhh, now the fan is 1110 rpm...
19:12karolherbst: maybe we could hack a high fan speed through loading nvidia, doing stuff and then unload it
19:16karolherbst: results for gputest: https://gist.github.com/karolherbst/d003e257cb625931008fd4a7f586b9f1
19:49jvesely: with reclocking, my nv117 is only 10% slower than integrated skylake gpu
19:50Yoshimo: karolherbst: wasn't the primary goal get it working and worry about speed and optimizing later?
19:51karolherbst: Yoshimo: always speed :p
19:52Yoshimo: you're the speed guy i get that
19:52Yoshimo: many cards wouldn't be as fast as they are now without your work
19:53karolherbst: moar speed
19:54Yoshimo: 9fps with a maxwell2 in world of warcraft could indeed need a little more work ;)
19:58karolherbst: Yoshimo: well, at least that we are sure that maxwell reclocking works, we can begin to care more about maxwell
20:00Yoshimo: well the 560ti which i also own, is more accessible and also isn't reclocking yet, so id say that card is more accessible and should be cared about more
20:00karolherbst: I've done enough on the fermi side :p
20:02imirkin_: jvesely: that's pretty neat - we supply totally bogus scheduling info into the shaders
20:02Yoshimo: is that all part of current mesa & kernel 4.7?
20:02imirkin_: jvesely: so i wouldn't expect it to be anywhere close to max perf
20:02karolherbst: Yoshimo: sure
20:02karolherbst: imirkin_: well even on kepler, if you really put garbage into the sched opcodes, you are still pretty good
20:02Yoshimo: last time i tried the reclock file wasn't there
20:02karolherbst: Yoshimo: ohh, I thought you asked me if I tested on that
20:03karolherbst: no, it isn't mainlined yet
20:03imirkin_: karolherbst: i think maxwell relies on it a LOT more
20:03karolherbst: and no, maxwell2 won't come soon
20:03karolherbst: imirkin_: apperantly
20:03imirkin_: karolherbst: kepler actually has a mode where you don't feed it the data at all
20:03imirkin_: pretty sure
20:03karolherbst: is it faster than what we do?
20:04Yoshimo: well karolherbst since i mixed 560 and a maxwell too, what can you expect for 4.7 & current mesa for the 560?
20:04imirkin_: don't think so
20:04karolherbst: Yoshimo: nothing :p
20:04Yoshimo: at least i won't be disappointed then
20:04karolherbst: Yoshimo: the point is, as long as you don't want to roast your maxwell2, nothing will be mainlied and fermi, well, somebody just needs to find a lot of spare time
20:04karolherbst: Yoshimo: :D
20:05karolherbst: you can if you want reclock the engines on fermi
20:05karolherbst: but they boot with such ridiculous low memory clocks, it ain't fun
20:06Yoshimo: mhmm it sounded more promising reading about fermi work
20:07karolherbst: yeah, guess why I especially wrote that memory reclocking isn't supported
20:07karolherbst: and with my patches I mainly fix volting issues, nothing more
20:08karolherbst: (well, implementing gpu boost on the way, but that goes hand in hand really)
20:08Yoshimo: memory was the main factor for performance, wasn't it?
20:11karolherbst: it depends
20:14jvesely: imirkin_: it beats intel in openarena :)
20:37amfern: what is the secure boot and how do i check that GPU actually did a secure boot?
20:37imirkin_: amfern: secure boot is for GM20x gpu's
20:38imirkin_: it's required to load firmware into the GPU that can perform some of the duties necessary for acceleration to work reasonably
20:40amfern: thanks, and how do i check if my GPU successfully loaded the firmeware?
20:40imirkin_: amfern: i dunno if we print anything in success cases
20:40imirkin_: "things work ok" is how you check :)
20:41imirkin_: and "there aren't tons of messages talking about impending doom in dmesg"
20:41karolherbst: amfern: short, if glxinfo prints nouveau, then it should be fine
20:43amfern: this is very accurate :)
20:44amfern: i am experiencing this issue https://bugs.freedesktop.org/show_bug.cgi?id=94990#c60
20:45amfern: any suggestion how to debug it, where to start?
20:45karolherbst: we know the issue
20:45imirkin_: amfern: it's already fairly well understood
20:45imirkin_: amfern: sit tight and wait :)
20:45karolherbst: (I have a hack though for this, by limiting the vram to 3GB)
20:46amfern: i am curious what is the issue? and how can i get your hack?
20:47karolherbst: the issue is, that nvidia is stupid
20:47karolherbst: the 970 is the gpu with the 224 + 32 bit memory parts
20:47karolherbst: where the last 512MB are just connected through 32bits
20:49amfern: do you know why it cause the GPU to fail during firmware upload, does it hit the last 512MB space?
20:49karolherbst: because the firmware is uploaded into vram
20:49karolherbst: so yeah, it might hit the last 512mb, maybe
20:49karolherbst: maybe it fails somewhere else
20:50karolherbst: the point is: it fails, we know fairly well why, we just have to detect the situation without false positives
20:51amfern: karolherbst: thanks, can i have a look at your hack?
20:53imirkin_: amfern: it fails because it sticks the firmware into the top of memory, and that part of memory is misconfigured, so we get all manners of errors
20:53karolherbst: amfern: well, you would need to rebuild your kernel or nouveau for that. It would be really the best idea to just wait, except you really need the very little performance right now
20:54amfern: i have spare time, and i want to play with the code
20:55amfern: if its too much effort, nvm
20:56karolherbst: I am just saying it is rather pointless, because one dev already is trying to fix the issue and he has indeed a very high insight in the issue. You would only need to change one line in "drm/nouveau/nvkm/subdev/fb/ramgf100.c": "u32 parts = nvkm_rd32(device, 0x022438);" => "u32 parts = 3;"
21:03amfern: thanks, i am just fascinated with GPU driver so looking for places to start
21:03amfern: if you have any documentation for nouveau even as small as file structure outline, this would be a great help
21:05karolherbst: if you really want to take care of that issue, you should discuess things with skeggsb, but to be honest, there are much better issues/task to begin with, but I don't know what you want to do at, so maybe it is just blabber for you
21:07amfern: i don't think i have the technical skill yet to take care of that issue, if you have issues a newbie can take care of i would like to try, can't promise anything
21:07orbea: so, this crash with openmw is not a nouveau issue, right? they closed it saying nouveau is not supported.... https://bugs.openmw.org/issues/3502 http://pastebin.com/7SWxqMQd
21:07orbea: prolly should of just not mentioned nouveau lol
21:08karolherbst: they are so funny
21:09karolherbst: does it even run with radeon?
21:11karolherbst: orbea: well, it crashes within the state_tracker..
21:11karolherbst: orbea: try to start it with LIBGL_ALWAYS_SOFTWARE=1
21:12orbea: karolherbst: that starts the game. It being in the state tracker would mean its a general mesa issue or would it implicate nouveau too?
21:12karolherbst: no clue
21:12karolherbst: but if it works with llvmpipe, maybe it is indeed a nouveau issue
21:13imirkin_: orbea: openmw is not supported. try reporting to openmw developers.
21:13orbea: lol :P
21:13imirkin_: [this is how i deal with such comments]
21:13karolherbst: maybe they use an extension wrongly, who knows
21:14imirkin_: find a different open-source game that's not so antagonistic to other open-source projects
21:15karolherbst: orbea: try to open a bug
21:15karolherbst: if you ask on IRC there is always this kind of asshole
21:15imirkin_: like me? :)
21:16imirkin_: i'm on email too :p
21:16karolherbst: well, if you would start it, then you would be :p
21:16karolherbst: now you are just being sulky :D
21:17imirkin_: "a period of gloomy and bad-tempered silence stemming from annoyance and resentment."
21:17imirkin_: that sounds right.
21:17orbea: karolherbst: i did open a bug
21:17karolherbst: orbea: link pls
21:17orbea: oh, you mean for nouveau?
21:17karolherbst: for openwm
21:17orbea: it got rejected because of that kind of asshole
21:17karolherbst: "Rejected" that sounds harsh
21:18imirkin_: [btw, it's 100% an issue in mesa, probably not specific to nouveau]
21:18karolherbst: yeah, most likely
21:18imirkin_: no amount of wrong api usage should be able to lead to an assert()
21:18imirkin_: however based on that comment that they don't support nouveau, i have absolutely no interest of investigating
21:19imirkin_: and will similarly turn down any future openmw-related bugs
21:20karolherbst: best come back ever :D
21:21imirkin_: i tend to operate on the golden rule - treat others like they treat me
21:21karolherbst: I didn't mean you though
21:21karolherbst: but how fast he just closed the issue
21:21karolherbst: he couldn't have time to even understand it
21:24karolherbst: st_renderbuffer(fb->Attachment[BUFFER_DEPTH].Renderbuffer)->surface is null
21:24karolherbst: I guess there is no depth buffer
21:25imirkin_: if i had to guess, it's a bug triggered by marek's recent rework of dirty state tracking
21:25imirkin_: could be something that'd been around longer though
21:25karolherbst: might be
21:25karolherbst: I think I will bisect it
21:25imirkin_: you know i won't be looking at it :)
21:25karolherbst: well, will be easy I think
21:32karolherbst: simple rule, if you behave like a child, you get treated like one :D
21:33orbea: this is silly and a shame considering how well the game used to work...
21:33karolherbst: it is
21:33karolherbst: it is most likely a regression or something
21:33karolherbst: but it is no reason to be an asshole about it
21:33kloofy: i am a policeman, children please bahave:)
21:34kloofy: karolherbst: we have some work to do, i told you i have a job for you, first i make you a millionaire, if i did not allready, then we need to get rid of shit
21:34karolherbst: openmw doesn't even compile with lto enabled
21:35kloofy: we have a worldwide known shit to offer , here in my country, it's basically in the interest of whole world that we get rid of this shit
21:36kloofy: because as far as i am concerned it has touched too many people world wide, to be honest i have list
21:36kloofy: of those scammers who made it happen
21:36karolherbst: orbea: link time optimizations
21:37kloofy: karol is so silly
21:37kloofy: remember the bad boys movie, when will said ouh your so silly, so what your wearing?
21:39kloofy: 1995 this movie was a big deal in my life
21:39kloofy: i gotta say allthough negros, it's one of my all time favorite
21:40kloofy: it was atuhored so well, and it covered all the baiscs in life
21:44kloofy: well it seems kyrie irving had a bit trouble too at olympics, you can imagine how big of a trouble that would be if aivar kuusmaa was playing
21:44kloofy: i have seen personaly how he did 7 in a row three pointers in a game
21:44kloofy: 1992 i think it was
21:51kloofy: i had a long conversation with mgo: his like karol on steroids:)
21:52kloofy: very lovely and smart german
21:53kloofy: suprised me in a way that i had to log a conversation and second time in a row
21:57kloofy: i am not well connected with german ethnic groups, who are basically one to one what i am, the childhood has been more like for yanks and all that, but overseas for german girls i was a hot stuff
21:59kloofy: sometimes gets me thinking how sweet my lovely german and aussie blonds were
22:00karolherbst: orbea: how do I have to start openmw? :D
22:00kloofy: it's like french go 15k meters to see one of theirs, it's all the same when i go to germany and australia
22:01kloofy: pretty much the same ethnic groups
22:01orbea: karolherbst: openmw, openmw-laucher and openmw-wizard. Wizard is for installing game data
22:02karolherbst: ahh crap, I don't own mw
22:02karolherbst: only oblivion and skyrim
22:02kloofy: orbea: can you state some sort of a problem you are facing, like formulate or something?
22:02orbea: not sure how far you can get without the data...
22:02orbea: btw, is it safe to ignore kloofy ?
22:03tobijk: its kind of entertaining actually
22:04karolherbst: orbea: seems like you have to bisect mesa then
22:04orbea: im making sure a stable mesa works first
22:11orbea: karolherbst: stable mesa crashed too, then it hit me.... LIBGL_DRI3_DISABLE=1 lol
22:11orbea: its a dri3 issue..
22:13kloofy: neither of us really understood what the language was but we were staring at eachother like we had something in common, almost like maybe in 17century germans did some stuiff with estonian women too
22:13kloofy: my german blonds were one to one finding their happiness looking at my face
22:17tobijk: orbea: can you run that game in gdb and see if you can get a backtrace of some sort?
22:17tobijk: or did you already do that :/
22:18orbea: tobijk: http://pastebin.com/7SWxqMQd
22:21kloofy: i was talking to mgo: and we decided to take over the world
22:22kloofy: now orbea can you really state the problem it's that nasty boost showing up, this crazy c++
22:23kloofy: looks like this openwhathefuck uses it
22:23kloofy: orbea: be aware that things are ok actually
22:24kloofy: i mean like don't be very anxious about stuff
22:24tobijk: orbea: mhm no surface, but we should have one...dang
22:26kloofy: can you through a real error at me, cause i don't see one from the logs
22:27kloofy: though i gotta say there is nothing more complex then c++ sort of debug stuff
22:27kloofy: and boost on top of that horror
22:28kloofy: i once tried to compile some sort of boost bitset with llvm, ouh mother god what it generated
22:29kloofy: and i gave up pretty quick
22:30kloofy: llvm ir was fullfilled with crazy stuff, and in very healthy extent
22:32kloofy: i got a hold on to my past friend, and tomorrow we will decide how to divide the zones
22:32kloofy: like which part of the world will belong to us etc.:D:D muhahaaa
22:32tobijk: orbea: lets try a guard first, simple but may work: http://hastebin.com/binadejoni.avrasm
22:34kloofy: halfline: how are you?
22:35kloofy: i am not quite sure if that's the guy who started this bluemouth or something like this based of kms
22:36kloofy: it was later integrated into driver but this daemon back the times did fast vt switch
22:37kloofy: i am a bit zombie i apologise, i am sad and little bit happy too, mostly sad though
22:37kloofy: i go to sleep
22:39kloofy: basically what i had planned to do is land a bit of optimizations into the mix, but i don't seem to care about those platoforms, but the optimisations are very very big ones
22:42kloofy: most the time it gets me thinking that when you have somehthing that generate hw blobs, then from that point vulkan is just a waste of time
22:42kloofy: we can make a precompiler
22:43kloofy: so basically all the runtime glsl compilation will be annulated
22:45orbea: tobijk: my ssh (irc) was down for a little bit, trying now
22:45tobijk: orbea: np, take your time :)
22:46kloofy: for instance opengl mandates that the strings are of shaders are const, you write into the linker
22:46kloofy: that i want the blob of that shader, you grab a blob and store that in the harddrive
22:47kloofy: now instead of calling the glsl shader and having the cpu ovearhead, we know feed the ringbuffer with hw commands
22:48kloofy: and it will be like heaps of faster along with scheduler, basically to compare it would make so that gt730 would be the gtx750 in current terms
22:49kloofy: maybe there are some ring buffer calling differences, but how you get the blob is just grab the memory with a linker
22:53kloofy: that is the notion of a precompiler, it leaves the cpu code intact, and precompiles all the opengl program into hw blobs
22:54kloofy: llvm guys have done some crazy work , where with their linker it's actually very easy task
22:56kloofy: so this vulkan and dx12 they do not make much sense
22:56orbea: tobijk: doesn't crash anymore! thanks, however seems to still not like dri3, there is no mouse cursor in the openmw menu screen (makes its kind of hard to select anything)
22:57orbea: dri2 still works though
22:57tobijk: orbea: maybe i have just "fixed" the cursor to not show :D
22:58tobijk: it is a custom curser ?
22:58kloofy: hell no when people want to write in vulkan api, that meands another plumbing to be done, which is totally unneccessary
22:58orbea: yea, its a custom cursor
22:59orbea: could be their mouse cursor + dri3 = bad
23:00tobijk: orbea: we have a texture of some sort which is not available, thus crashes. It could possibly the cursor, but everythnig else
23:00tobijk: is anything missing else?
23:01orbea:looks closer to see if there was anything less obvious
23:02kloofy: tobijk: is it like you understand anything i talk about, i talked with mgo, he enlightened me, but i was not too sure about if he really got my point
23:02orbea: oh!, its not so much that the cursor is missing, but that its been reduced to two tiny ".." which are kind of hard to see
23:02tobijk: openmw was it?
23:02kloofy: that is suppose to be another kit
23:03kloofy: high level c++ opengl + input
23:03kloofy: in other words their bugs are basically off-topic here, but so am i:)
23:04kloofy: i was suicidal today, but people nowdays ignore me instead of banning
23:04tobijk: orbea: man i'm blind, it is stated in your backtrace already: SDLUtil::SDLCursorManager::_createCursorFromResource
23:05orbea: it seems only the cursor is wrong
23:06kloofy: painted as chamapign bottle?
23:06tobijk: orbea: now put it on the openwm shoulders ;-)
23:06kloofy: i am asking for a ban, please can someone ban me, i am drunk?
23:07orbea: yea, I guess I could make a new issue about it
23:08kloofy: tobijk: but basically you understand when you have one api to generate hw stuff, then you can inteporse that api a little to work with blobs straight right?
23:08tobijk: orbea: actually i was kidding, it is mostly mesa, as we handle the dri2 path fine and not so fine in th dri3 path
23:22tobijk: orbea: care to give me your mail address? i'd include you as reporter to my "fix", so more experienced devs can ask you some more questions to actually fix this :>
23:22orbea: its already posted everywhere..
23:24tobijk: was not aware of that, sorry
23:24orbea: no, I meant that I dont care if its shared, not that you should of known :)
23:29tobijk: orbea: care for the full name? :D
23:30orbea: my full name? Its already in all my slackbuilds...
23:30orbea: kind of hard to have anonymity now, oh well
23:31tobijk: long gone for me :)
23:37tobijk: damn my git send-email settings are gone :(
23:44orbea: nouveau reclocking is fun lol http://dpaste.com/3QE3C6Z
23:46tobijk: yep it is and makes your cards usable (if you are lucky)
23:46tobijk: that is a nveX?
23:47orbea: I have a GK110B
23:48orbea: so nvf1
23:48tobijk: right :)
23:50tobijk: orbea: mh bandwith limited: 71670 frames in 5.0 seconds = 14333.859 FPS with a slow nve7 :D
23:50neoraider: Speaking of reclocking, does anyone know if it works yet on NVD9/GF119M [Quadro NVS 4200M]?
23:51orbea: i like how it dri3 seems to make a bigger impact with reclocking
23:51orbea: err, that grammar failed lol
23:52tobijk: english is my second language as well, havent noticed :D
23:52tobijk: neoraider: i'm not certain, but i think it should work
23:53orbea: its a problem when english is my first language, something about irc screws up my writing lol
23:53neoraider: Nice, so I guess I'll try nouveau again when I have some spare time :)
23:53tobijk: neoraider: you have to manually reclock anyway, not auto reclocking
23:54tobijk: its too dangerous, as it coul render many cards unusable
23:54neoraider: Yeah, I know. Still better than the nvidia driver :P
23:57tobijk: neoraider: maybe i'm stating the obvious, but make sure you have a recent kernel :)