00:12imirkin: skeggsb: any ideas? http://hastebin.com/pemajoniru.xml
00:12imirkin: [that's on a nv44]
00:14imirkin: it appears to ask for enough ring space...
00:15imirkin: but the error is on ffffc90000078000 which is a "next" page
00:15imirkin: so something's not mapped somehow?
00:51imirkin: hm, so the faulting instruction is
00:51imirkin: mov %r12d,(%rax)
00:51imirkin: RAX: ffffc90000078000
00:51imirkin: R12: 0000000080000003
00:51imirkin: and curiously RDX: ffffc90000068000
00:52imirkin: and since the allocated pushbuf is 0x10000, that lends credence to some sort of space "leak" going on
00:55imirkin: that data is weird too... not sure where the 0x80000003 would be coming from
00:57imirkin: oh, that's NvDmaTT. ok, makes sense.
00:58imirkin: skeggsb: ideas welcome ;)
01:12imirkin: skeggsb: i've audited the rest of the code and the only other inconsistency is in nvc0_fbcon where it asks for 60 but only uses 58
01:21imirkin: i think the patch i sent explains my hang on nv44 though
06:20sooda: hi there. i'm (slowly) attempting to plug in some new features, and for some, struggling to find where exactly to do that (in the kernel driver). this DRM_NOUVEAU_NVIF/usif_ioctl/.../ofuncs->mthd path seems useful (i'm looking at gf100_fermi_mthd as an example), but i can't find any uses of it in mesa/mesa-drm and DRM_NOUVEAU_NVIF isn't even defined in userspace's nouveau_drm.h. what's up with this exactly?
06:22sooda: it'd be nice to be able to call that from userspace directly - some parts of the kernel driver go the mthd path, but a new ioctl to work as a trampoline for that seems unnecessarily complex
06:23mupuf: sooda: that's the entire point of nvif
06:23mupuf: having ONE ioctl that would allow to interact wit hthe different objects within nouveau drm
06:23sooda: yeah, that i deciphered, just starting to try out how to actually use it
06:24mupuf: and it is not tied to an ioctl, it will also be used for hypercalls
06:24mupuf: so as nouveau could be run inside a virtual machine
06:24sooda: what's a hypercall?
06:24mupuf: it will only work on xen though
06:24mupuf: but yeah, almost no performance cost
06:25sooda: just wondering why i can't quite find any uses for this yet
06:25mupuf: you mean, in the userspace?
06:25mupuf: it is not exposed
06:25mupuf: hakzsam_ has an implementation
06:25mupuf: for the performance counters
06:26sooda: ok so it's just so new that not really used for much?
06:33mrfurio: hi, having trouble finding info on this; fedora22, quadro k2200, dell 2715h monitor, can't get full resolution working even though IIUC the mode is detected at startup. How would I track down *why* the mode is getting rejected?
06:33mrfurio: not seeing any links in Xorg.0.log that look obvious
06:34mupuf: sooda: yes!
06:34mupuf: that's exactly that
06:35sooda: good, thanks, then i should be safe to play around. was wondering if this would be just either too experimental or something old :P
06:37sooda: (i might soon ask how to fill in the path info from userspace or something, let's see...)
06:40mupuf: it is not too experimental and not too old :)
06:41mupuf: no idea where the libdrm patches are to expose nvif, but hakzsam_ can provide them to you
06:41mupuf: found them
06:42sooda: wow much thanks
06:42hakzsam_: this is more up to date :)
06:42hakzsam_: have fun!
06:43mupuf: sooda: https://github.com/hakzsam/mesa/commit/c1171217863d705f4a5411ebe3c7e1deb4faeb80 <-- an example of how to use nvif
06:44mupuf: mrfurio: try the kernel logs
06:46sooda: btw these are my first words here, might as well introduce myself properly. working for nvidia in the tegra business, in helsinki/finland, just playing with some initial simple-ish patches and still not quite sure what i'm doing. got some patches that i might soon post to the mailing list for general criticism
06:47hakzsam_: so, welcome :)
06:48mupuf: sooda: nice! I am also in the capital area ... in the Intel office in Espoo :)
06:49mupuf: so I do pass by the NVidia office quite often :)
06:49sooda: heh, a competitor
06:49mupuf: A competitor who is allowed to work on nouveau on his spare time :p
06:50mrfurio: ok, so nv110 family on the chipset, but is that likely to have anything to do with the modes or should I look elsewhere?
06:50mupuf: But I have not worked too much on it aside from helping hakzsam_ in merging his performance counter work
06:50mrfurio: it's not finding the firmware, but I was thinking that's not a problem for finding a mode
06:51mupuf: mrfurio: can I see the kernel logs please?
06:52mupuf: sooda: in any case, welcome! And you had the right reflex asking people here
06:53mupuf: gnurou is in a very different tz, so fire your questions on irc first
06:53mrfurio: mupuf: thanks for taking a look into this: http://pastebin.com/WJ2x07r1
06:53mupuf: and we may be able to help before he can
06:54mupuf: mrfurio: what kernel is this?
06:54sooda: yeah, i've been mailing with him internally already :P
06:54sooda: better just start talking here more
06:54mrfurio: mupuf: 4.0.5-300.fc22
06:54mupuf: anyway, don't be afraid of asking stupid questions, you will ask a ton of them!
06:55mupuf: try your best, and when you get stuck, just ask the damn question
06:55mupuf: right, ping me if I don't answer, I am not monitoring this channel too often
06:56mupuf: I am recompiling stuff right now, so I do have some time to chat
06:56sooda: some concerns i've been having: channels getting stuck when something bad happens (e.g. mmu fault) - trying to force-kick some fences in these conditions; getting some more detailed errors from the drm driver to userspace (we call this "error notifier" internally, a shared buffer that gets an error code for mmu fault / some gr errors / whatever) for robustness extension, etc.
06:56mupuf: mmu faults are poorly handled, at least they used to
06:56sooda: yeah, and any proper error recovery is kind of completely missing compared to the official driver. that's also being worked on :)
06:56mupuf: someone from nvidia gave us the meaning of some of the IRQs we could get for it
06:57sooda: error handling must be one of the most difficult things to do without any inside information :p
06:57mupuf: and imirkin added them to our drm driver
06:57mupuf: it is hard to force the driver to have one of those, I guess :D
06:57mupuf: I have not worked on this aspect
06:58mupuf: this work would be awesome :)
06:58mupuf: and the error reporting is definitely something canonical asked me to do ... 4 years ago
06:58sooda: woop great
06:59mupuf: so as they could recover when the entire gpu would hang
06:59sooda: my biggest problem with it was to poke the information from the nvkm layer to the drm/ioctl part
06:59mupuf: and yes, the robustness extension would be great!
06:59mupuf: poking or peeking?
06:59mupuf: nvif sounds like an ideal place, indeed!
07:00sooda: i now have something that uses the event mechanism to talk from different engines to the nouveau_channel thing that then stores that
07:00mupuf: mrfurio: can you try a kernel from rawhide?
07:00mupuf: like the 4.1?
07:00sooda: didn't really use the nvif thing that yet
07:00mupuf: the 4.1 should have proper support for the nv117
07:00mrfurio: mupuf: sure, why not =)
07:01mupuf: as for the display, I indeed do not see any error when reading the EDID
07:01mrfurio: yeah, edid seems good
07:01sooda: but this event/notify stuff that i'm not so sure about, just copied code around and it started working heh. i should clean up the patch a bit and then just post it for review :p
07:01mrfurio: I tried a combo of cvt and xrandr and it kills the gnome-session probably because it can't use that mode
07:01mupuf: release early, release often
07:02mupuf: the FLOSS development mantra
07:02sooda: some typical finnish shyness and stage fright is my problem
07:03mupuf: The finns think they are shy, I would say that they are mostly ... silent :)
07:03mupuf: anyway, don't worry, we are friendly
07:03mlankhorst: finns are awesome, can't wait to see the country
07:04sooda: just get here soon, it's gonna get cold
07:04mupuf: mlankhorst: agreed, come get your ass here for vacation! I have a much bigger flat than I need usually
07:04imirkin: sooda: error recovery is largely lacking... we try when we detect a hung context, but often fail.
07:04mupuf: sooda: it just got "warm" today :p
07:04imirkin: er, s/context/channel
07:04sooda: too warm for me
07:05sooda: the finnish summer is short and not too snowy
07:05mupuf: but 80C sauna is cold :D
07:05imirkin: the hangs are detected because we stick a fence at the end of every pushbuf submit. if those fences don't get reached, then we decide it's hung.
07:05sooda: (dunno how "vähäluminen" would translate)
07:06imirkin: pushbuf submit would also be a fairly natural place to report failures... dunno, haven't really thought about it.
07:06sooda: imirkin: yeah, i found a hack for that. it's probably not good but does what i need for this small experiment
07:06hakzsam_: mupuf, what is "warm" for you? we are going to have 41°C in Bordeaux tomorrow :)
07:06mupuf: sooda: probably no translation for this in english since it is a finnish thing
07:06mupuf: hakzsam_: it felt like 25 today, with a lot of sun
07:07mupuf: but google says 17
07:07sooda: submit isn't that good for that. the proper way would be to force-finish the fences and then let the userspace know if things went wrong or not
07:07sooda: submits should be async, so you can't know there if the job failed if it's just starting :p
07:08mupuf: sooda: apps supporting the robustness extension should be known to the kenrel
07:08mupuf: so as we would not just kill them
07:08sooda: huh 41°C is good for a cold sauna but just destroys all intellectual brain activity
07:08mupuf: but you are right, a first good step is to manage to reliably kick the channels out
07:09mupuf: the problems may be cross-channel communications through semaphores
07:09gnurou: sooda: hey, nice to see you here!
07:09mupuf: skeggsb talked about this some time ago
07:09sooda: gnurou: o/
07:09gnurou: sooda: see, this channel has much more answer than I can possibly provide ;P
07:10sooda: hehe yes
07:10mupuf: my bad, google says 20.
07:10gnurou: you will get to the point much faster by just asking here
07:10sooda: my outside temperature meter says 32°C. sun is probably shining at it
07:11sooda: inside is 28°C (horrid student apartment)
07:11gnurou: besides, many of you seem to be in Helsinki
07:11sooda: this work office is much better tho
07:11mupuf: oh, right, I have the same problem. That's what you get when you have windows as big as the wall
07:11mupuf: gnurou: many?
07:12mupuf: I know Lauri and Laurent
07:12mupuf: that's it
07:12mupuf: Laurent Pinchard
07:12gnurou: mupuf: well there's you, sooda, Laurent, Lauri, ...
07:12gnurou: Lauri was here last week btw :) and Laurent 3 weeks ago
07:12gnurou: it's a small world
07:12sooda: lauri is in the same office
07:13mupuf: gnurou: nice :) I need to see Laurent at some point, I have presents for him from Ian
07:13mupuf: sooda: I know :)
07:13mupuf: we may actually come to your office or the opposite to work on some egl extensions together, for wayland
07:14mupuf: especially since this is what Lauri really is into
07:14mupuf: and we need to coordinate since we have a common need
07:22imirkin: mrfurio: your Xorg log should provide the full mode list. it should become apparent why some modes are pruned. mind pasting that?
07:26mrfurio: imirkin: I would but I've been installing rawhide kernels =) There was nothing in there that seemed to be relevant, 'tho I am not an expert
07:26imirkin: mrfurio: well, it should print the EDID and the parsed results
07:27imirkin: or... what mode were you trying to set?
07:27mrfurio: imirkin: yeah, EDID seems good; manually adding the mode kills the gnome-session
07:27imirkin: connected over...
07:27mrfurio: that's a fun story; HDMI
07:27imirkin: (DVI, HDMI, DP)
07:28imirkin: yes, that sure sounds funny :p
07:28mrfurio: (plugged into DP port with an adapter; yes, it could be the adapter)
07:28imirkin: the adapter is unlikely to prune out modes
07:28mrfurio: trying to figure out if there's a software reason
07:28imirkin: however my recollection is that the DP-to-HDMI (and -to-DVI) adapters are single-link
07:28imirkin: which means no 2560x1440
07:29mrfurio: The monitor has DP, but it goes into powersave mode if I use that
07:30mrfurio: this appears to be a problem people see in Windows so I wasn't about to try to debug that since it's been forever since I've mucked with X configs
07:32imirkin: from wikipedia:
07:32imirkin: However, Dual-mode DisplayPorts are designed to transmit a single-link DVI or HDMI 1.2/1.4 TMDS protocol across the interface through the use of an external passive adapter
07:32imirkin: i assume that means a single 170MHz or whatever TMDS link
07:32imirkin: which means... no 2560x1440
07:33glennk: or 30Hz
07:33imirkin: "A notable limitation of dual-mode is that it can only transmit single-link DVI (and HDMI), as the number of pins in the DisplayPort connector is insufficient for dual-link connections."
07:33imirkin: although it also has this: "In January 2013, a new VESA specification was released called DisplayPort Dual-Mode Standard version 1.1, which brings dual-mode capabilities on par with HDMI 1.4, allowing a TMDS clock rate of up to 300 MHz,"
07:34mrfurio: imirkin: well, consarn it =P didn't know there was a single/dual link HDMI distinction; thought it might have to do with the cable and maybe the overall support for HDMI was not up to 1.4 standards
07:34imirkin: but of course there's some lead time between "vesa releases spec" and "i have hardware in hand"
07:35mrfurio: could not even find enough info on the adapter to tell what it can do
07:35mrfurio: welp, the whole thing's new, might still be time to get 'em to swap me out the k2200 for a firepro or summat
07:35imirkin: additionally even if there's full support for this in the hw, nouveau might not be aware of this new reality and may not have logic to support the dual-linkness....
07:36mrfurio: don't even need the high horsepower, this is a 2d workstation
07:36imirkin: just go with the integrated intel then
07:36mrfurio: I would but it's got xeons in here
07:37imirkin: well-supported, has decent drivers, and their recent stuff is getting pretty speedy
07:37imirkin: ah yeah, to get an expansion board you'd have to go down to the i740, which i do not recommend ;)
07:38glennk: the intel graphics decelerator!
07:38mrfurio: hey, that's how you get back down from orbit, don't knock it =)
07:38glennk: wonder who wins the slowdown between a s3 virge and a i740
07:39imirkin: s3 virge was good back in the day, no?
07:39RSpliet: gives a whole new meaning to "drag race"
07:39imirkin: it had yuv overlays and all
07:39mupuf: ﬁrst gpu I ever had
07:40mupuf: with the Gateway computer we bought in 1996 or 1997
07:40imirkin: ah gateway.
07:40mupuf: fond memories? :D
07:41imirkin: of companies past
07:41mrfurio: the DP issue is maddening because it has nothing to do with X, can't even get the monitor out of powersave mode if I switch VTs
07:42imirkin: mrfurio: does the monitor know about DP 1.2?
07:42imirkin: if so, try flipping that on and off
07:43imirkin: mrfurio: you can also get more debug info with nouveau.debug=DISP=debug,I2C=debug,VBIOS=trace,DRM=debug drm.debug=0xe
07:44imirkin: (i.e. if you boot with ... )
07:44mrfurio: imirkin: will do, the monitor is quite cruel about showing the OSD
07:44imirkin: like if it's power saving no way to get it back?
07:45imirkin: if you unplug the cable, that'll usually jog it
07:46mrfurio: you'd think so
07:47imirkin: i would!
07:47mrfurio: the effect in this case is: monitor shows the "entering powersave mode" dialog again
07:57mrfurio: the whole thing is crazy-making. new workstation, spiffy xeons, spiffy monitors, spiffy GPU and ... well, here's your degraded gui experience.
07:57mrfurio: thanks for all your help folks, look like I'm gonna end up calling this a hardware issue
07:57imirkin: 2048x1152 wtf is that mode
07:57mrfurio: yeah exactly
07:58mrfurio: wouldn't even mind that if it didn't mangle the terminal text
07:58imirkin: well, chances are pretty good that the nvidia blob driver would fully support this configuration
07:58mrfurio: funny story there
07:59mrfurio: gnome-shell won't start. The error screen is very crisp, though
07:59imirkin: library conflict with mesa perhaps?
08:00imirkin: too many libGL's for one system
08:00mrfurio: should probably look into that
08:00imirkin: most distros manage that very poorly
08:00mrfurio: I mean, gdm won't even start
08:00imirkin: does it give a reason?
08:00mrfurio: not that I can find, I am new to systemd
08:01mupuf: what's the link here?
08:01imirkin: oh good luck with that
08:01mupuf: dmesg + Xorg.0.0log should have all the info
08:01imirkin: mupuf: the link is that systemd makes systems unusable :p
08:01imirkin: mrfurio: can i interest you in gentoo?
08:01mupuf: imirkin: lol
08:02mupuf: s/makes/can make/
08:02imirkin: i assume it just stands for SystemDestroy
08:02mrfurio: imirkin: another couple of hours of this and maybe so
08:02mrfurio: this is making OS X look good by comparison
08:02mupuf: make sure the nouveau module is not loaded
08:03mupuf: and then you should be able to load nvidia
08:03mrfurio: yeah I purge it
08:03mupuf: show us the logs
08:03mupuf: dmesg + Xorg.0.0log
08:03mrfurio: trying again with nvidia drivers
08:04mrfurio: oh right
08:04mrfurio: forgot about this part
08:04mrfurio: can't get into X, switch to VT, "a start job is running for Wait for ..." where the "Wait for .." part is supposed to be the name fo the jbo
08:05imirkin: Keyboard Error. Press F1 to resume.
08:06mrfurio: nvidia blob rpms from rpmfusion appear to blacklist the nouveau driver in the grub config
08:06mupuf: sounds like a good way of making sure
08:06imirkin: there's also libglx, libGL, etc
08:06mrfurio: yeah, that's what imirkin was suggesting too
08:07mrfurio: as a problem
08:07imirkin: anyways... this is lots of talk... the logs will have all the info
08:10mrfurio: no pastebin: "Failed ot initialize GLX extension (Compatible NVIDIA X driver not found) ... but up above it said it was loading the driver from the nvidia directory
08:11mrfurio: Loading /usr/lib64/nvida/xorg/libglx.so
08:11imirkin: ls -l /dev/nvidia*
08:12imirkin: that means the nvidia driver isn't loaded
08:12imirkin: (i.e. the kernel module)
08:13mupuf: mrfurio: modprobe nvidia :D
08:13mrfurio: FATAL =)
08:16mrfurio: oh ho
08:16mrfurio: looks like the latests shipped modules are for 4.0.4
08:16imirkin: aren't binary distros great?
08:17RSpliet: mrfurio: akmods?
08:18mrfurio: RSpliet: yep, looks like the rpmfusion pulled that in
08:18mupuf: imirkin: Why the heck doesn't fedora have proprietary drivers in a package? I mean, it is not like nouveau worked in all cases
08:18RSpliet: akmods --kernels <kernel-version> should rebuild drivers (nvidia, wl) for your kernel
08:18RSpliet: mupuf: policy; no closed source packages in Fedora
08:19Karlton: mupuf: they only allow non-free firmware
08:19RSpliet: and only if the redist license is clear
08:19mupuf:prefers the policy of not having a non-free driver installed by default :)
08:20mrfurio: would love to have all this working with OSS drivers
08:21mupuf: not that it would impact me though ... since nouveau does not work by default on arch aside from kms
08:21imirkin: mrfurio: DP is a fickle beast. getting those debug logs i mentioned may help skeggsb figure out what's wrong
08:23mrfurio: as soon as I stop bouncing back and forth 'twixt kernels and drivers I will be sure to provide it
08:23imirkin: i personally know fairly little about it, and don't have any nvidia boards with DP outputs
08:24mrfurio: my searching indicated that it's a problem for Windows peeps to tho
08:25mrfurio: could be a problem with Dell's monitors
08:27mrfurio: ok, this is kinda getting funny: blob driver is giving me the same resolution
08:28mrfurio: which would appear to lend support to imirkin's idea that it might have something to do with the connector (am back on HDMI)
08:33mrfurio: well, OK then; blob driver + dp 1.2 enabled on monitor, and we have full resolution
08:37mupuf: mrfurio: what is the full resolution?
08:37mupuf: is it some 4k screen?
08:38mrfurio: it was using 2048x1152 which led to jaggies w/terminal font
08:38mrfurio: and this is before trying to drive a second monitor
08:39mrfurio: so, with all that going, I have a dual head setup at full resolution working
08:40mrfurio: I will try to find some time this afternoon to get that debug info for what nouveau sees
08:40mrfurio: where should I send that?
08:48imirkin: mrfurio: bugs.freedesktop.org Xorg -> Driver/nouveau
09:11mogorva: imirkin: hi, i have some games that crash in wine with an identical backtrace, would you mind checking this: http://pastebin.com/d77VD46J
09:12imirkin: gah, vbo. that's the one module of core mesa that i've managed to stay away from
09:13imirkin: if you can make a repro, ideally in the form of a trace, file a bug against mesa core
09:13mogorva: looks like it's different than bug 91118 because none of the patches from that bug helps
09:13imirkin: (do confirm that it suffers a similar fate with LIBGL_ALWAYS_SOFTWARE=1)
09:13mogorva: yes, it crashes with software too
09:15imirkin: i have no idea how the vbo module works
09:16imirkin: and aim to keep it that way for as long as humanly possible
09:17mogorva: if your time permits, could you try to reproduce it with the demo on Steam (150 MB): http://store.steampowered.com/app/57200/
09:21imirkin: were you unable to make an apitrace?
09:22mogorva: i'll make it available soon
09:22imirkin: mogorva: actually that assert may be non-fatal...
09:22imirkin: i.e. it's checking to make sure the program's not doing anything disallowed by GL
09:22imirkin: like drawing while buffers are mapped
09:23imirkin: so i think this might be a wine fail
09:23imirkin: however assert seems a bit... harsh
09:28mogorva: here is the trace: https://drive.google.com/open?id=0B-tTbLKBl-tOOVQ5bDl4emRocVU&authuser=0
09:32imirkin: and replaying the trace also fails i presume?
09:32mogorva: the trace simply ends at the point where the game crashes
09:33imirkin: gah, so replaying the trace doesn't crash?
09:33imirkin: can you check your apitrace version? the one i have definitely works nicely with crashes
09:33imirkin: i have apitrace 6.1
09:34mogorva: mine is apitrace-6.1-3.fc22.i686
09:35mogorva: there's a 'context mis-match in pipe_sampler_view_release()' in the terminal when the trace ends
09:36mogorva: this is the whole output: http://pastebin.com/VhPVKQia
09:37imirkin: anyways, gtg
09:50jakllsch: is it possible to load nouveau after bootup?
09:51jakllsch: or how do i debug why it didn't load?
09:51jakllsch: 07:00.0 VGA compatible controller: NVIDIA Corporation G71GL [Quadro FX 1500] (rev a1) (10de:029e (rev a1))
09:51jakllsch: should be supported in linux 3.16 right?
09:52jakllsch: modprobe nouveau
09:52jakllsch: modprobe: ERROR: could not insert 'nouveau': No such device
09:53jakllsch: or, is there any way to get it to tell me why it didn't find the device?
10:13jakllsch: could it be because my system doesn't have ACPI?
10:33glennk: jakllsch, did you previously have the binary driver installed?
10:51glennk: ok, so the module isn't blacklisted then
11:44imirkin_: jakllsch: pastebin dmesg
11:44imirkin_: it should tell you... given that it's a G71, i'm betting it's using PCIROM as vbios source instead of PROM or PRAMIN, which have a checksum error
11:45jakllsch: i didn't see much of anything in the dmesg...
11:45imirkin_: could i trouble you to pastebin it anyways?
11:46jakllsch: maybe in a bit
11:46imirkin_: whenever :) i'm not the one looking for help
12:04andril: i need help installing the drivers for 01:00.0 VGA compatible controller: NVIDIA Corporation GF108GLM [NVS 5200M] (rev a1) on my Jessi install,pls
13:27imirkin_: joi: did you ever make progress on the "bin/arb_uniform_buffer_object-rendering offset" issue?
13:45joi: imirkin_: no, I ran out of ideas
13:45imirkin_: ok =/
13:46pmoreau: So let's see: on the secondary card's PDISP, I only to enable hotplug interrupts and polling for external displays, which requires a connector per entry in the DCB table and an EVO core channel?
13:46pmoreau: fb and cursor should not be needed, right?
13:49imirkin_: joi: well this fixes it: http://hastebin.com/uwimolotih.coffee -- but i hardly want to do something like that
13:49imirkin_: pmoreau: uhm... fb handles ram
13:50imirkin_: pmoreau: cursor is needed if you plan on using displays on that card too
13:50imirkin_: pmoreau: but perhaps i'm misunderstanding what you mean
13:50pmoreau: Right, but I guess I could enable cursor only if a screen gets connected to that card
13:50pmoreau: And otherwise not have it
13:50imirkin_: pmoreau: right. well cursor is connected to crtc iirc
13:51imirkin_: and crtc == screen (basically)
13:52pmoreau: So you mean I shouldn't have a cursor to begin with, cause I wouldn't have a screen attached?
13:52imirkin_: except fbcon might force the issue somehow
13:52imirkin_: cursor might hang off fb
13:52imirkin_: and fbcon might create a fb that's not attached to anything
13:52imirkin_: i dunno how those datastructures are laid out exactly... sadly there isn't a single logical way
13:53pmoreau: ... Can't find where I saw about the cursors...
13:54pmoreau: vblank should be disabled
13:56pmoreau: Hum... vblank is init'ed only if (dev->mode_config.num_crtc), so only if a screen is attached, right?
13:56pmoreau: Could be then that a non-existing screen is detected
13:56imirkin_: well, num_crtcs will be 2 here
13:57imirkin_: actually i dunno
13:57imirkin_: sorry, i haven't really looked at that code in depth in a while. i'll just shut up :)
13:57pmoreau: Meh, you still know more than I do! :)
13:57imirkin_: but there are provisions to deal with GPUs that have all of PDISPLAY disabled
13:57imirkin_: and i believe that check is for those
16:08imirkin_: skeggsb: did my patch to fbcon make sense?
16:08imirkin_: [esp make sense as the cause of my crash]
16:08imirkin_: [or rather, the solution to]
16:44skeggsb: imirkin_: yeah, i shall merge it later on ;)
16:46imirkin_: skeggsb: ok cool. should i also send a patch to reduce the nvc0 push_space one?
16:50skeggsb: ah crap, yep..
16:50skeggsb: i really should get around to making that stuff less insane, finally
16:51imirkin_: still insane... just less
16:52skeggsb: probably :P
16:53imirkin_: the other comments i made last night about things being off-by-one were wrong, i'm pretty sure
16:53imirkin_: that code is *very* subtle though
16:53imirkin_: like dma.max is actually max-1
16:54skeggsb: yeah i know, it's *really* shitty, fixing all that was part of what was coming with atomic (i was using the same submissing stuff for evo channels too, instead of yet another home-brewed one)
16:54skeggsb: buuut i haven't finished that yet
17:44imirkin: skeggsb: nvc0 patch also sent
17:45imirkin: skeggsb: ugh, the nv50 one is also off-by-one. and it doesn't have a FIRE_RING -- hm?
17:45skeggsb: imirkin: got it, i'll send those as a -fixes soonish
17:46imirkin: (should it have a FIRE_RING?)
17:46skeggsb: it doesn't really matter either way, it'll happen eventually anyway
17:50imirkin: skeggsb: only the nv04_fbcon one needs to be backported fwiw
17:50imirkin: i don't think the others will cause problems, just waste a few words on the first run through the pushbuf
18:01imirkin: grrrrr... we really need a nv30 disasm
18:02imirkin: the one i wrote is crap and doesn't work
18:03airlied: I question whether you really need an nv30 anything :-P
18:05imirkin: airlied: certainly helps when trying to read the stupid code it's generating
18:05imirkin: which i'm sure is wrong
18:06imirkin: also, wtf is a create_vertex_elements_state with 0 vertex elements??
18:10zerwas: I have a Geforce GT 610 (NVC0 family, code name NVD9 (GF119)) and would like to try reclocking. Is there any page you can link to which has instructions on this?
18:11imirkin: zerwas: there's no reclocking support for fermi
18:11zerwas: imirkin: Oh, okay. Thank you
19:31imirkin: skeggsb_: btw, FIRE_RING doesn't count as a command right?
19:31imirkin: (for PUSH_SPACE purposes)
19:56imirkin: ok, things are looking a little better... on nv44: crash: 10, dmesg-fail: 2, dmesg-warn: 20, fail: 199, pass: 3953
20:00briocalter: so, how much help did the header files from nvidia?
20:01imirkin: not at all afaik... but it's a nice gesture.
20:01imirkin: it might turn into something with a bunch of work though
20:04briocalter: I've been reading some material about mesa/graphics for ages, but have no idea where to start helping
20:08imirkin: briocalter: what are you interested in?
20:08imirkin: briocalter: and what hardware do you have on-hand?
20:09imirkin: skeggsb: your client was bouncing when i asked this, not sure if you saw it -- FIRE_RING doesn't count as a command for PUSH_SPACE purposes right?
20:09skeggsb: imirkin: nope, it doesn't
20:09imirkin: ok, didn't think so
20:10briocalter: imirkin, would like to learn about anything I guess, opengl extensions seems cool
20:10imirkin: briocalter: what hw do you have on-hand?
20:11briocalter: imirkin, nvc0, 660ti
20:11imirkin: well you can take a look at https://trello.com/b/ZudRDiTL/nouveau to see if anything strikes your fancy
20:11imirkin: or if you've encountered bugs, we can work on fixing them, etc
20:13briocalter: nice, thought you guys used freedesktop bugzilla
20:14imirkin: we do... for bug tracking
20:14imirkin: this is for like... "note to self" :)
20:22airlied: I should get a trello board for myself :-P
20:22imirkin: airlied: it's free :)
20:23skeggsb: i setup myself a local one (not trello, kanboard, but same deal) ages back, which i forgot about :P ~/todo text file for me
20:23imirkin: skeggsb: what's the status of the gddr5 gt215 -- i need to stick a nv50 board in, is it going to work at all, or not?
20:24imirkin: (i.e. enough to replay traces, test stuff out, etc)
20:24airlied: I get depressed when I enumerate things in too much detail :-P
20:24skeggsb: it'll work, but i think it has some niggly rendering glitches still that i wasn't able to track down yet
20:24imirkin: what's a "niggly" rendering glitch?
20:25imirkin: should i just plug it in and see? :)
20:25skeggsb: iirc, random flickering rendering artifacts
20:25imirkin: i have some prelim patches enabling gddr5 reclock on those btw... not sure if they're owrth sending
20:26skeggsb: if it works, why not :P
20:26imirkin: well, totally untested and def can't work yet since it's incomplete
20:26skeggsb: right :)
20:26imirkin: hence "prelim"
20:26imirkin: anyways, brb
20:37imirkin: skeggsb: yeah, looks like there's a bit of fail flicker every so often, but nothing huge
20:37imirkin: skeggsb: i suspect that getting reclocking on there for real will help
20:38imirkin: well, it's probably the ram that's slightly misconfigured
20:38skeggsb: that was a possibility i considered, but i also wondered if maybe there's more "this feature is fucked on gddr5 boards" bits that need flicking
20:38skeggsb: like the one that fixed the immediate gr hang that we used to see
20:38imirkin: yeah, could be =/
20:38imirkin: yeah, that was a good one.
21:04starkid: Hello. I need some help. First of all, I'm not even sure my graphics card is supported because the CodeNames page is difficult to read. I have a GF116M [GeForce GT 550M].
21:04imirkin: GF116 = NVCF = supported
21:05imirkin: however for a lot of older kernels we enabled non-existent engines on it... should be fixed in 3.18+... maybe that fix got backported too, not sure
21:06starkid: Thank you! I have nouveau installed already. Do I need to configure it or something? I was given the webpage http://get.webgl.org/ as a test and I can't see the graphics. I'm on Debian Jessie x64.
21:06starkid: and using firefox browser
21:06imirkin: pastebin glxinfo output
21:07imirkin: i know at least chrome blacklists nouveau for webgl, not sure about firefox
21:07skeggsb: oh weird, why does chrome do that?
21:07skeggsb: chromium doesn't, btw
21:07imirkin: skeggsb: yeah it does
21:08skeggsb: unless i overrode that so long ago i don't recall
21:08imirkin: skeggsb: you just force-disabled the blacklist 100 years ago and forgot
21:08imirkin: skeggsb: it does that because nouveau crashes
21:08imirkin: or at least did when they disabled it
21:08imirkin: and since code never changes, clearly still does
21:09starkid: that's taking me a while because glxinfo is not a recognized package...
21:10imirkin: starkid: probably have to install mesa-demos or mesa-utils or whatever your distro calls it
21:10imirkin: skeggsb: neat, first time i see this one:
21:10imirkin: [ 2021.200918] nouveau E[ PGR][0000:04:00.0] TRAP DISPATCH_QUERY
21:10imirkin: [ 2021.200921] nouveau E[ PGR][0000:04:00.0] no stuck command?
21:11starkid: starkid@starkid:~$ glxinfo
21:11starkid: name of display: :0.0
21:11starkid: Error: couldn't find RGB GLX visual or fbconfig
21:11imirkin: starkid: pastebin xorg log
21:15imirkin: Module glx: vendor="NVIDIA Corporation"
21:16imirkin: you need the xorg one, not the nvidia one
21:16imirkin: looks like you had the blob installed before and didn't sufficiently uninstall it
21:18starkid: yes. for shame :( but Xorg.0.log and Xorg.0.log.old are the only two files in /var/log pertaining to xorg, so I don't know how to get an xorg log otherwise.
21:18imirkin: the log's not stale
21:19imirkin: the libglx.so that your xorg is loading is from the nvidia blob driver
21:20starkid: I don't know what that means/what to do.
21:21imirkin: you didn't properly uninstall the nvidia blob and install the open drivers
21:21imirkin: this file: /usr/lib/xorg/modules/linux/libglx.so -- is the nvidia one. it needs to be the xorg one.
21:23starkid: I purged nvidia. I tried to unload drm modules, but couldn't. What else should I try?
21:23airlied: reinstall distro X.org packages
21:23imirkin: find a guide for your distro and follow it
21:26starkid: you mean the xorg nouveau package? Or the whole xorg window system?
21:26imirkin: whatever provides libglx.so
21:26starkid: I see.
21:56starkid: imirkin: http://pastebin.com/NjHACg4q
22:08imirkin: starkid: much better
22:09imirkin: starkid: that should give you 3d accel on your intel gpu
22:10imirkin: if you want to use your nvidia gpu for accel (it likely won't be much faster with nouveau, since it probably boots to very low clock speeds and we can't change them)
22:10imirkin: then you need to either enable DRI3 or remove your intel driver config from your xorg.conf
22:11imirkin: starkid: also, Current Operating System: Linux starkid 3.2.0-4-amd64 -- that's waaaaay too old. nouveau won't work particularly well.
22:12starkid: I was just reading up on the risks of updating the kernel.
22:15starkid: So besides upgrading my kernel, should I expect to do anything else to get nouveau to work? I still don't understand if it's just an install-and-it-works sort of software.
22:15starkid: I mean routine things like configuration.
22:16imirkin: starkid: well, nouveau isn't really a single piece of software
22:16imirkin: it's a bunch of components that come together
22:17imirkin: you're going to have to update a lot of stuff to get it all working well
22:17imirkin: you appear to be on a very out-of-date system
22:17starkid: I don't know why that is. I just upgraded to the newest stable version of Debian.
22:17imirkin: or maybe not "very", but out-of-date enough
22:17imirkin: stable versions of debian tend to be fairly out of date.
22:18starkid: ok. I will figure out about updating this kernel first. thanks for your help
22:19imirkin: but first you should identify what your goal is
22:19imirkin: it might not be worth going through the pain of updating to something that's newer than what your distro provides
22:19starkid: I need to be able to view webgl graphics for a course
22:19imirkin: if at the end you won't get the expected benefit
22:20imirkin: ok, then your integrated intel gpu should be more than sufficient
22:20imirkin: and it should be working now...
22:20imirkin: (pastebin glxinfo)
22:20starkid: name of display: :0.0
22:20starkid: Gen6+ requires Kernel 3.6 or later.
22:20starkid: glxinfo: ../../../../src/mesa/main/context.c:1541: handle_first_current: Assertion `ctx->Version > 0' failed.
22:21imirkin: heh. ok, well i guess you're stuck updating your kernel either way then ;)
22:21imirkin: i'm surprised that the new debian stable uses kernel 3.2
22:21imirkin: i thought the old one had that
22:21starkid: thanks again and goodnight
22:22RAOF: starkid: Yeah, Debian stable has 3.16, which should be good for you.
22:22starkid: not according to glxinfo...
22:22RAOF: (Jessie, which is Debian stable as of april this year)
22:22imirkin: you probably have a stable grub entry
22:22imirkin: which is booting your old kernel
22:23Karlton: 3.2 is too old even for debian
22:23RAOF: Oldstable was 3.2
22:23RAOF: So it was new enough for Debian stable as late as April this year :)
22:24starkid: I don't know. When I search in the repository, linux-image-3.16 is the latest version that shows up.
22:24imirkin: 3.16 is fine
22:24imirkin: but you're running 3.2
22:24starkid: oh you're right. 3.2.04 is there at the bottom of the list.
22:25starkid: so I need to change a grub kernel entry
22:25RAOF: Probably you just need to reboot; alternatively, you can remove the 3.2 kernel with apt and then reboot.
22:26starkid: ok. trying it now.
22:37gnurou: mmm, having an interesting issue bringing up Mesa for GM20B...
22:37gnurou: 2D and DMA_COPY classes are working fine, but all 3D operations are no-ops on the color buffer, even though they are pushed without any error
22:38gnurou: has someone met a similar situation before?
22:38skeggsb: gnurou: have you verified that the kernel side is correct with a simple test app or something?
22:40imirkin: gnurou: some bit of init missing?
22:41imirkin: gnurou: you need to update a lot of places to recognize 0x120 family in mesa btw
22:41gnurou: skeggsb: nope, since you got GM206 to work I was expecting GM20B would as well, since both are using the same classes
22:41imirkin: right now it just knows about 0x110
22:41gnurou: imirkin: yep, I got a patch from skeggsb that does this (after my own attempt where I missed a few places)
22:42gnurou: what is interesting is that GR does not throw a single error... also the contents of the PB seems correct
22:42skeggsb: gnurou: well, the kernel side of my gm206 stuff isn't entirely the same as you gm20b stuff :)
22:42gnurou: cannot confirm that init is done properly though
22:42skeggsb: you have secure boot and proper fecs/gpccs, for starters...
22:43imirkin: perhaps gm20b is more sensitive to some thigns too... for example our sched bits are totally wrong
22:43gnurou: skeggsb: right... however I have been able to use the 3D engine under different conditions, it seems to only be Mesa
22:43imirkin: gnurou: try just doing a clear or something
22:43gnurou: imirkin: precisely what I cannot get to work :)
22:43skeggsb: gnurou: ah, that's what i meant by a test app, something directly on libdrm :P
22:44imirkin: so the 3d engine processes the commands, fences get reached, everything works fine, but nothing gets drawn?
22:45gnurou: imirkin: exactly... well at least the FE eats the commands and fences get reached - I cannot speak for the 3D engine but I see no reason why it would not receive and process the commands
22:45gnurou: however I cannot see any side-effect from it
22:46gnurou: fences, 2D commands and DMA copies all work fine
22:46imirkin: sounds like something very dumb
22:46gnurou: yep, like everything coming from me :)
22:46skeggsb: TWOD sticks a lot of units into bypass mode that MAXWELL doesn't, so it's still possible that there's some setup problems
22:46imirkin: all i can say is look at your program that works
22:46imirkin: and start adding its command stream to mesa's init
22:47imirkin: until it starts rendering
22:47imirkin: then bisect ;)
22:47gnurou: yep, let's try this
22:48gnurou: I just wanted to check whether someone had a quick suggestion before trying the more menial way :)
22:49starkid: hello. I am back and confused. Reboot didn't change anything. I didn't uninstall the kernel because I received a warning about the system becoming unbootable. I don't understand why RAOF thinks that my current kernel is sufficient if glxinfo says that it isn't, and I don't know what else to try at this point.
22:49RAOF: starkid: The kernel you have *installed* is sufficient. The kernel that you've booted isn't.
22:49RAOF: You've got a bunch of kernels installed, at least one of which is the 3.2 kernel that you've booted and which is too old.
22:50RAOF: If you remove that kernel you then won't boot it next boot (obviously!), and assuming that you *do* have linux-image-3.16-whatever installed your next boot will be with a working kernel.
22:51starkid: but removing the kernel 3.2 while I'm in it is dangerous, no?
22:51RAOF: starkid: No.
22:52RAOF: Well, only dangerous in that it's the only kernel that you *definitely* know boots (because it's just booted ☺)
22:53starkid: I don't understand why you say 3.2 is too old. Isn't 3.16 older?
22:53RAOF: 16 > 2
22:53starkid: Oh, lol. I was reading it 3.1.6
22:53RAOF: 3.16 is 3 point 16, not 3 point 1 point 6 :)
22:54starkid: ok. I'm off again
23:01imirkin: gnurou: yeah, nothing too obvious comes to mind... mesa generally sets up the state it's aware of.
23:07gnurou: imirkin: no problem, I'll figure it out. thanks!
23:09briocalter: been wondering, does nouveau or even nvidia supports cec over hdmi?
23:12imirkin: briocalter: dunno about nvidia, but there have been recent efforts to get something into the linux kernel
23:12imirkin: don't really know more detail than that though.
23:12airlied:isn't sure CEC is even wired up on lots of boards
23:12imirkin: yeah, the linux effort is in conjunction with embedded boards
23:13briocalter: libcec is usable with raspi/videocore, but dunno about other gpus
23:13airlied: I looked into it years ago for intel
23:13airlied: and the CEC line didn't even seem wired to a GPIO
23:14airlied: like there was no reason the host couldn't control it, but I think there was some licenseing issues
23:14airlied: like my Apple TV doesn't do CEC, but my PS3 does
23:14airlied: I suspect you have to pay 0.0005c more to use CEC or something
23:15briocalter: it figures
23:18briocalter: I've been testing my tv, pressing the arrow keys shifts the desktop
23:18briocalter: think there's some wiring
23:20briocalter: dunno where to look at for more info
23:46pmoreau: There are a couple of regs that changes in PNVIO and PDISPLAY when setting 0x8841c to 28400, I'll have a look at those.
23:47pmoreau: Also interesting is, if I suspend the G96 before switching to it, I only get a black screen but absolutely no Nouveau errors. If I switch without suspending, then I get a display.
23:48pmoreau: And when switching back to the MCP79, the G96 will fail tu suspend (PDISP fini timeout).
23:50pmoreau: So, could be some bits are not brought back on resume, and as I have the 0x8841c = 28400 trick while resuming, it's something else.