01:30 mlankhorst: ah.. I need to use busid instead, but that doesn't work when one of the busid's is NULL
01:32 mlankhorst: meh I will add a special case to busid
01:58 mlankhorst: if my calculations are correct, https://mblankhorst.nl/etc/xorg-server-tegra.patch + http://paste.debian.net/161211/ ought to be enough to make tegra work, though I probably need to patch the nouveau ddx still :P
03:44 mlankhorst: almost working with some changes to the nouveau ddx, I'll poke it some more later
03:44 mlankhorst: drmSetMaster failing now
03:54 mlankhorst: Yeah! Loaded :D
04:02 mlankhorst: still fails further on
04:03 mlankhorst: [ 63403.042] (EE) NOUVEAU(0): Failed to allocate scratch buffer: -12
04:03 mlankhorst: [ 63403.043] (EE) NOUVEAU(0): Error initialising acceleration. Falling back to NoAccel
04:03 mlankhorst: [ 63403.043] (**) NOUVEAU(0): [COPY] acceleration disabled
04:03 mlankhorst: [ 63403.043] -12
04:03 mlankhorst: [ 63403.043] (EE) NOUVEAU(0): Error allocating scanout buffer: 0
04:03 pmoreau: mlankhorst: Please use pastebin for paster longer than 4 lines :p
04:04 mlankhorst: hah :p
04:04 pmoreau: What is -12? ENOMEM?
04:04 mlankhorst: yeah
04:04 RSpliet: mlankhorst: you don't need a copy engine right?
04:05 mlankhorst: no but the lack of scratch buffer seems more harmful
04:05 RSpliet: well, yeah, but if that's on account of trying to hook up with a non-existant copy-engine
04:06 mlankhorst: meh lets see if the glamor accel works
04:08 mlankhorst: fails too, I'll poke it more later
04:17 xexaxo: mlankhorst: wouldn't xf86_platform_odev_attributes(foo)->busid work (re your current patch) ?
04:18 mlankhorst: xexaxo: to xorg-server or ddx? :P
04:18 xexaxo: it will also preserve the drmCheckModesettingSupported call.
04:18 xexaxo: the ddx
04:18 mlankhorst: ah
04:18 mlankhorst: xexaxo: no it would break on older xorg-server 1.13
04:18 mlankhorst: afk..
04:18 mlankhorst: and we can remove the call, libdrm device create will fail on older nouveau
04:19 xexaxo: with some ifdef ODEV_ATTRIB_PATH guards around it of course
04:21 xexaxo: hmm let's check when busid was added.
04:24 xexaxo: there was some rework done recently, but afaict the equivalent variable should be reachable ?
04:26 Omar007: Any interest in a VBIOS dump from a Gigabyte GTX 970 G1 Gaming? I've got one that is on it now which doesn't seem to play nice with KMS. I should also have a backup of the factory default BIOS somewhere.
04:32 xexaxo: ok so the whole odev seems to be missing for pre 1.13, with the ODEV_ATTRIB_PATH it seems like it'll be fine.
04:47 xexaxo: mlankhorst: this is what I'm talking about - http://codepad.org/GR8QN2jK
04:48 xexaxo: ought to works with pre 1.13, plus simplify the whole nv_device_open/wrap.
04:50 xexaxo: keeping the drmCheckModesettingSupported call for unusual setups will be a plus.
05:23 xexaxo: http://codepad.org/wnbYmVdI << with a check if pcidev is null :]
05:42 Zolo: Hi, I´m that student that wroten here 2 weeks ago about how to begin programing graphics drivers. I found GeForce4 MX 440 at home, is it better for beggining, or begin with modern cards?
06:00 Zolo: ok,better question: mx 440 vs intel hd graphics 4000, whitch to begin?
06:15 glennk: Zolo, i'll suggest picking some presumably trivial feature, and figuring out how that is done from the app down to the hardware, without getting too distracted with unrelated bits
06:17 glennk: just randomly picking something, for instance something like glEnable(GL_CULL_FACE), what bits of hardware get frobbed when you set that from the app?
06:24 drowfx: i'm trying to debug a vdpau failure and i have a few questions regarding the trace (with demmt)
06:26 drowfx: first, what does "PB: 0x00107b00 size 4, subchannel 3 (class: 0x8297, desc: G84_3D, handle: 0xbeef5097), offset 0x1b00, increment
06:26 drowfx: PB: 0x00000000 G84_3D.QUERY_ADDRESS_HIGH = 0
06:26 drowfx: PB: 0x20217000 G84_3D.QUERY_ADDRESS_LOW = 0x20217000 [0x20217000]
06:26 drowfx: PB: 0x00000002 G84_3D.QUERY_SEQUENCE = 0x2
06:26 drowfx: PB: 0x1000f010 G84_3D.QUERY_GET = { MODE = WRITE_UNK0 | UNK4 | UNIT = CROP | SYNC_COND = NEQUAL | TYPE = QUERY | QUERY_SELECT = ZERO | COUNTER_SELECT = VFETCH_VERTICES | SHORT }" do? i get some complaints by the kernel driver that i think are related to this command
06:49 imirkin: drowfx: i _think_ that writes the value 2 to the specified address when processed by the fifo, but it's been a while since i've worked out all that query stuff
06:51 imirkin: drowfx: alternatively it stalls processing commands until that address gets the value 2 :)
06:56 drowfx: imirkin: are the reverse engineered commands documented somewhere?
06:57 imirkin: drowfx: not a lot of docs on the actual commands i'm afraid... mostly in people's leaky brains
06:57 imirkin: drowfx: you can look at envytools.rtfd.org and also rnndb
06:58 imirkin: drowfx: btw, what emits that 0x1000f010? i've seen it in logs but iirc it's only used by the GPU_FINISHED thing which no state tracker cares about...
06:58 drowfx: i looked on envytools.rtfd.org already, and got Todo: write me
06:59 imirkin: :)
06:59 drowfx: it's in the trace i get from mplayer with vdpau
07:00 imirkin: yeah, but how does it get in there? :)
07:00 drowfx: and if i'm parsing it correctly its related to the kernel generating a trapped write (reason: PAGE_NOT_PRESENT)
07:01 imirkin: you're probably on the right track
07:01 imirkin: since i've investigated that very same thing before
07:01 imirkin: but i couldn't figure out how that command would get emitted
07:01 imirkin: or if i did, i certainly don't remember now
07:03 imirkin: although i do have a wait for fence == 2, but it's using the VP's fence wait mechanism
07:06 imirkin: so anyways... yeah. i never worked out how that command gets into the command stream
07:06 drowfx: the docs say something that UNK4 is "used by NV for fences"
07:07 imirkin: fence == barrier btw
07:07 imirkin: which is == semaphore
07:07 imirkin: (but not semaphore in the mutex sense)
07:08 drowfx: and the offending command appears at the very end of the pushbuf, so that would make sense to have a fence there, right?
07:08 imirkin: basically it's used when you want to sync an engine with something else
07:08 imirkin: yeah, potentially
07:08 imirkin: that one's probably a thing to *write* the value 2
07:09 imirkin: oh, i wonder if it's inserted by libdrm or something...
07:10 imirkin: nope, it's not the suffix stuff... nevermind
07:15 drowfx: what i don't really understand is that the address belongs to a buffer of size 0x1000, the kernel complaint points to this instruction (class 0x8297, method 0x1b0c, data 0x1000f010), but the offending write happens at offset 0x1080
07:16 imirkin: that's... surprising
07:16 drowfx: so for some reason something writes past the buffers end. but from what i can get from the docs this command only writes 2 words (or 1, with SHORT) at the given address
07:16 imirkin: yeah, it's an 8-byte write
07:17 imirkin: do you see any buffer allocations at 0x20218000 ?
07:18 drowfx: i think i checked that and didn't find anything, but i'll look again...
07:20 imirkin: one easy thing to do is figure out which bo it is (in the code) and allocate 0x2000
07:22 drowfx: i just noticed that there isn't one, but two of these commands right after one another
07:22 drowfx: "PB: 0x00107b00 size 4, subchannel 3 (class: 0x8297, desc: G84_3D, handle: 0xbeef5097), offset 0x1b00, increment
07:22 drowfx: PB: 0x00000000 G84_3D.QUERY_ADDRESS_HIGH = 0
07:22 drowfx: PB: 0x20470000 G84_3D.QUERY_ADDRESS_LOW = 0x20470000 [0x20470000]
07:22 drowfx: PB: 0x00000001 G84_3D.QUERY_SEQUENCE = 0x1
07:22 drowfx: PB: 0x0000f010 G84_3D.QUERY_GET = { MODE = WRITE_UNK0 | UNK4 | UNIT = CROP | SYNC_COND = NEQUAL | TYPE = QUERY | QUERY_SELECT = ZERO | COUNTER_SELECT = VFETCH_VERTICES }
07:22 drowfx: PB: 0x00107b00 size 4, subchannel 3 (class: 0x8297, desc: G84_3D, handle: 0xbeef5097), offset 0x1b00, increment
07:22 drowfx: PB: 0x00000000 G84_3D.QUERY_ADDRESS_HIGH = 0
07:22 drowfx: PB: 0x20217000 G84_3D.QUERY_ADDRESS_LOW = 0x20217000 [0x20217000]
07:22 drowfx: PB: 0x00000001 G84_3D.QUERY_SEQUENCE = 0x1
07:22 drowfx: PB: 0x1000f010 G84_3D.QUERY_GET = { MODE = WRITE_UNK0 | UNK4 | UNIT = CROP | SYNC_COND = NEQUAL | TYPE = QUERY | QUERY_SELECT = ZERO | COUNTER_SELECT = VFETCH_VERTICES | SHORT }"
07:22 imirkin: don't flood the channel... use pastebin
07:23 drowfx: sorry, ok
07:23 imirkin: those are writes to diff places
07:23 imirkin: and the first one doesn't have the high bit set
07:23 imirkin: that one comes from nv84_query.c
07:23 imirkin: er
07:23 imirkin: nv84_video.c
07:23 imirkin: after it clears the RT
07:23 imirkin: *no clue* where the short one comes from
07:25 imirkin: it also kicks the channel right after writing those commands... i wonder if it's not the kernel fencing thing
07:25 imirkin: but how that would get into the user-visible pushbuf... dunno
07:26 imirkin: nope, that's not it either...
07:26 imirkin: is it.... the stupid kick handler?
07:27 imirkin: ah yes it is. nv50_screen_fence_emit
07:28 imirkin: and... genius. the driver never refs the fence bo to the pushbuf??
07:28 imirkin: that can't be right
07:30 imirkin: oh i see. it's referenced by the bufctx
07:31 imirkin: which... isn't used by the nv84_video stuff
07:33 imirkin: errr.... no. the bufctx *should* be attached
07:33 imirkin: except.... i rebind it in the nv84_video stuff? gr
07:40 imirkin: hrm, no. it all checks out. the "main" pushbuf has a bufctx attached which remains untouched
07:41 imirkin: and its kick handler is what emits that second fence
07:42 imirkin: the bsp/vp pushbufs don't have a kick notifier set, and don't ref the screen's fence bo, so it's all fine
07:42 imirkin: theoretically :)
08:03 mlankhorst: xexaxo: pci_dev is NULL for platform devices..
08:03 xexaxo: mlankhorst: see the follow up patch that checks it :P
08:04 xexaxo: mlankhorst: namely http://codepad.org/wnbYmVdI
08:04 mlankhorst: xexaxo: meh I think we should just check ABI version instead, if we do a check..
08:05 xexaxo: mlankhorst: can you be more specific ?
08:05 mlankhorst: sec
08:06 xexaxo: if you're talking about ODEV_ATTRIB_BUSID... that one is fun.
08:06 mlankhorst: I mean calling drmGetVersion
08:06 mlankhorst: just a sec
08:06 xexaxo: ack.
08:07 mlankhorst: in fact, that is what happens anyway..
08:07 mlankhorst: look at NVHasKMS
08:08 xexaxo: I'm sorry but look at what ?
08:08 xexaxo: you said just check ABI, but I'm struggling with which ABI you're talking about :\
08:08 imirkin: nouveau abi
08:09 mlankhorst: xexaxo: do you know of any nouveau version that is at least 0.16, but has no KMS support?
08:09 xexaxo: mlankhorst: don't tend to remember things that git & grep can find :P
08:09 mlankhorst: heh
08:10 xexaxo: how is that related btw ?
08:10 xexaxo: imirkin: there is the xserver one, which he could have been talking about :P
08:11 imirkin: good point
08:23 drowfx: i just noticed that, in the trace, it seems that the first decoder constructed is immediatly destroyed again, and then a new one is constructed (mplayer also outputs something about VO: [vdpau] ... twice
08:23 mlankhorst: xexaxo: but we don't need modesetting necessarily any more, just GEM :P
08:24 imirkin: drowfx: yeah, mplayer likes to do that
08:24 drowfx: could there be a race condition between nv84_decoder_destroy when it is called immediatly after nv84_create_decoder that the GPU is still doing stuff with the objects being destroyed? or is there some synchronization code that im not aware of
08:24 specing: hi
08:24 mlankhorst: xexaxo: 0.0.15 had modesetting
08:25 specing: How would I go about fixing my GPU (NV50) to a certain frequency?
08:25 imirkin: drowfx: you mean if you destroy a context too early?
08:25 drowfx: yes
08:25 xexaxo: mlankhorst: isn't this somewhat orthogonal to my patch ? I'm suggesting a shorter cleaner way to manage platform(non-pci) devices.
08:25 imirkin: specing: is it a literal NV50 or something in the family? what does 'lspci -d 10de:' say?
08:25 imirkin: drowfx: hmmm.... well in theory everything gets torn down properly... in practice... :)
08:25 mlankhorst: xexaxo: I'm just saying the check is not needed, you will fail to create a drm device without KMS :P
08:26 specing: imirkin: it is 0407 G84 (Geforce 8600M GT)
08:26 xexaxo: mlankhorst: I'm not adding any checks, but leaving things as is. if you want to remove it let that be a separate patch perhaps ?
08:26 imirkin: specing: no support at present, sorry. what kind of vram does it have? ddr2 or gddr3?
08:26 specing: imirkin: nvidia-settings allowed me to set core and memory frequencies
08:28 specing: imirkin: DDR2 in 4 chips
08:28 xexaxo: mlankhorst: if your point is that we can nuke NVOpenNouveauDevice altogether, I fear that's not (yet) an option. NVOpenDRMMaster needs it :\
08:29 specing: [ 63.619218] nouveau [ CLK][0000:01:00.0] 20: core 169 MHz shader 338 MHz memory 100 MHz
08:29 specing: [ 63.619225] nouveau [ CLK][0000:01:00.0] 21: core 275 MHz shader 550 MHz memory 200 MHz
08:29 specing: [ 63.619231] nouveau [ CLK][0000:01:00.0] 22: core 475 MHz shader 950 MHz memory 400 MHz
08:29 specing: [ 63.619280] nouveau [ CLK][0000:01:00.0] --: core 275 MHz shader 550 MHz memory 199 MHz
08:29 imirkin: specing: ok. if it were gddr3, RSpliet has a branch that begins to implement some of the stuff, but iirc no ddr2 support
08:30 RSpliet: imirkin: and it's unlikely to work for G84 as is... too many register writes :-P
08:30 specing: I don't need to change dram timing
08:30 specing: I'm interested in core
08:30 RSpliet: specing: you might want to reconsider that thought
08:30 RSpliet: DRAM is the most important factor in performance
08:31 specing: RSpliet: I don't want overclocking
08:31 RSpliet: not talking about "over"clocking
08:31 specing: My GPU is of the broken RoHS (solder) branch
08:31 specing: I need to keep the thermal swinging to a minimum
08:31 RSpliet: right... well, you should be able to change all the other clocks
08:32 RSpliet: with a slight modification of the kernel
08:32 specing: Actually, my question would be ... how to keep the GPU at a "fixed" temperature all the time, no matter the load
08:33 imirkin: put it in an oven :)
08:33 imirkin: it'll be _really_ hot the entire time
08:33 mlankhorst: xexaxo: meh I'll check how I made it work with the modesetting driver
08:33 specing: imirkin: that is what I have to do every two months
08:33 imirkin: hehe
08:33 imirkin: reflow-soldering on the cheap? :)
08:33 specing: imirkin: actually I am using a paint removal tool, not oven
08:33 mlankhorst: I had a stupid check specifically for modeset there
08:33 specing: imirkin: yes
08:34 RSpliet: hahahaha, soldering tin brulée
08:34 specing: RSpliet: What do I have to modify in the kernel to keep the GPU at say ... 275 MHz?
08:34 xexaxo: mlankhorst: not sure I understand what you mean. I'm guessing that your mind runs at x5 the speed on your fingers and something gets dropped out :P
08:34 imirkin: specing: nothing -- that's the frequency it stays at no matter what with nouveau
08:35 mlankhorst: xexaxo: I had a check for modesetting in the modeset driver that specifically checked modesetting, forgot which one though
08:35 specing: RSpliet, imirkin: :) [676056.784498] NVRM: GPU at 0000:01:00.0 has fallen off the bus.
08:35 RSpliet: imirkin: sure? all the load-based clock-gating stuff defaults to off?
08:36 imirkin: RSpliet: :p well definitely nouveau changes no clocks
08:36 RSpliet: well, no :-)
08:36 imirkin: RSpliet: and afaik we don't set up the clock gating stuff by default
08:36 specing: imirkin: ah ok, so it is already fixed and will not change?
08:36 xexaxo: mlankhorst: again cannot see the connection with my proposal :P
08:36 RSpliet: specing: it should be fixed... you can check actually if you have envytools
08:36 mlankhorst: xexaxo: the check was probably for nomodeset specifically
08:36 RSpliet: run the nvatiming tool and paste(bin) the output
08:37 rzyz85fr: Hello, can't i have help for make working nouveau on my ubuntu utopic 64?
08:37 mlankhorst: if not it's stupid ..
08:37 rzyz: my x log: http://pastebin.com/B8FzRhx2
08:38 RSpliet: rzyz: we normally don't help out with specific distributions, as they come with their own set of problems not caused by us. isn't #ubuntu being helpful?
08:38 xexaxo: mlankhorst: so you're thinking about "die drmCheckModesettingSupported die"/"why do we want/need drmCheckModesettingSupported" ?
08:38 imirkin: rzyz: [ 17.414] (EE) [drm] KMS not enabled
08:38 mlankhorst: xexaxo: more that we open a FD anyway, so die drmCheckModesettingSupported check..
08:39 pmoreau: rzyz: I bet you're booting with nomodeset or nouveau.modeset=0
08:39 imirkin: rzyz: you must have modeset=0 somewhere most likely
08:39 rzyz85fr: RSpliet,hello, thanks, i'm french, i've ask on #ubuntu-fr, #ubuntu, none answer, so i came here :)
08:39 imirkin: probably in a modprobe config file
08:39 imirkin: since i don't see it on the cmdline
08:39 xexaxo: mlankhorst: hmm I thought mentioned it before - if there is a pick with it why not leave it a separate change ?
08:40 mlankhorst: xexaxo: since the check was breaking for platform devices without busid :P
08:40 xexaxo: also we open the FD after the the check :P
08:40 rzyz85fr: imirkin, ok, i will looking how enable it.
08:41 imirkin: rzyz85fr: grep -r modeset /etc/modprobe*
08:41 xexaxo: mlankhorst: hmm platform devices should have a busid(unique). if that things is broken, we're in deep sh*t
08:41 specing: RSpliet: https://github.com/envytools/envytools this I suppose?
08:41 mlankhorst: xexaxo: that's only useful on PCI devices..
08:42 xexaxo: mlankhorst: "useful" is not the same as "it doesn't have one" :P
08:42 RSpliet: specing: yep
08:42 RSpliet: arch has a package for it, fedora doesn't, other distros I have no idea
08:43 xexaxo: mlankhorst: iirc mesa and others still use the ioctl, so it's not going anywhere any time soon.
08:43 rzyz: imirkin, here: http://pastebin.com/aCVigv4c
08:43 mlankhorst: xexaxo: I had a null pointer dereference for busid, might be because of some ubuntu patch though..
08:43 RSpliet: rzyz: /etc/modprobe.d/blacklist-nouveau.conf:options nouveau modeset=0
08:43 mlankhorst: but meh busid should die..
08:43 RSpliet: there's your problem
08:43 specing: RSpliet: Gentoo doesen't seem to have it
08:44 RSpliet: specing: heh, well, luckily you know how to build stuff :p
08:44 xexaxo: mlankhorst: speak with danvet about that one. I'm pretty sure he had enough fun with it :P
08:44 mlankhorst: xexaxo: It's not unique really..
08:44 mlankhorst: in case of USB devices, it can be an empty string
08:44 xexaxo: mlankhorst: I didn't come up with the name, so yeah... Don't shoot the messenger
08:45 RSpliet: pmoreau: don't forget to gather trace from your G96
08:45 mlankhorst: xexaxo: I think busid is a terrible handle to use and we already have the path, so we should use that
08:45 mlankhorst: if you want to keep the modeset check then I will add one
08:46 pmoreau: RSpliet: I thought I had time for that! :p
08:46 RSpliet: you do, but I wouldn't want to risk you postponing it to a moment where you don't have the card at hand :p
08:46 xexaxo: mlankhorst: so the argument is on the basis the "busid is bad, should never be used etc..." ?
08:46 pmoreau: RSpliet: Don't worry, I did not forget - well, at least not yet. I'll do that either this evening or tomorrow morning
08:46 RSpliet: great :-)
08:46 mlankhorst: xexaxo: and it can be completely wrong..
08:46 danvet: busid is only there because backwards compat with old libdrm on some ppc and alpha
08:47 pmoreau: I quite always have my laptop at hand, except at work
08:47 danvet: I mean the libdrm hook
08:47 mlankhorst: danvet: well it's used for PCI devices, but on !PCI devices it's stupid..
08:47 danvet: it's also utterly pointless imo
08:47 mlankhorst: indeed..
08:47 danvet: most newer drivers don't do anything useful with it
08:47 danvet: if you need anything to id your drm device from userspace
08:48 mlankhorst: but the nomodeset check can be useful for slightly older nouveau..
08:48 danvet: add a getparam ioctl
08:48 danvet: nomodeset?
08:48 xexaxo: danvet: I could be missing something but it seems that libdrm and at least the intel ddx still use it extensively ?
08:48 mlankhorst: danvet: yeah it still initialized the 3d crap on older drivers, but skipped the vga crap..
08:48 xexaxo: s/extensively/somewhat/
08:48 danvet: xexaxo, there's some backwards compat hilarity indeed
08:49 mlankhorst: meh then again there are devices for which nouveau is useful, but there is no modesetting involved (displayless d7 for example)
08:49 xexaxo: danvet: missed the quotes around hilarity :P
08:49 danvet: mlankhorst, the kernel skips modeset on older nouveaus?
08:49 mlankhorst: danvet: no i believe that nouveau could still initialize in the nomodeset case, but I think we should just skip nouveau altogether in that case..
08:50 imirkin: danvet: not all nvidia devices have display components
08:50 imirkin: danvet: although the overwhelming majority do
08:50 danvet: last time I checked there's no driver left with nomodeset
08:50 mlankhorst: danvet: yeah but nouveau still works on old kernels..
08:50 danvet: totally something different
08:50 danvet: you _have_ to initialize with DRIVER_MODESET
08:50 danvet: because that just means DRIVER_IM_NOT_FROM_THE_STONEAGES
08:51 xexaxo: danvet: that one's been done.
08:51 danvet: then just don't register any crtc/encoder/connector
08:51 mlankhorst: danvet: I know..
08:51 danvet: its what i915 does without modeset hw
08:51 xexaxo: I'm guessing mlankhorst is talking about booting with "nomodeset" ?
08:51 mlankhorst: yes
08:51 danvet: imo it's totally ok to cripple the box with nomodeset
08:51 danvet: we don't try to keep the gem side running either with nomodeset
08:51 xexaxo: last time I've checked we just stop loading nouveau, and return 0 (ok)
08:52 xexaxo: mlankhorst: ^^
08:52 xexaxo: that's in case of "nomodeset"
08:52 mlankhorst: xexaxo: so why do we need the modeset check then? :P
08:52 danvet: and we also kill the driver entirely with nomodeset when we could keep it (because its on a box where i915 doesn't do display)
08:52 imirkin: yeah, nomodeset == super-mega-disable all aspects of the driver
08:52 danvet: exactly
08:52 danvet: nomodeset = pls, pls, make my system boot
08:52 danvet: disabling harder is totally ok
08:53 xexaxo: mlankhorst: because people tend to want that if nouveau is causing them problems. i.e. cannot boot their favourite GUI
08:53 mlankhorst: I think on older drivers when booting with nomodeset DRM_MODE_GETRESOURCES will fail with EINVAL..
08:53 mlankhorst: so I'll just check if that call succeeds
08:53 danvet: you still need to init the modeset stuff
08:53 imirkin: mlankhorst: there's no /dev/dri* if nomodeset
08:54 danvet: just don't register anything
08:54 mlankhorst: imirkin: old kernels :P
08:54 mlankhorst: let me find it specifically
08:54 danvet: i915 did that
08:54 danvet: because i915 is stupid
08:54 danvet: but we killed it
08:54 imirkin: mlankhorst: oh hm... yeah, i guess pre-modeset there were still card nodes
08:54 danvet: trick to not get "you broke my system, this is a regression" reports:
08:54 danvet: keep module loading, silently fail to register the legacy drm node
08:55 imirkin: danvet: or just don't change anything, ever :)
08:55 danvet: X silently falls back to vesafb and software rendering
08:55 danvet: imirkin, yeah as if that's an option with gpu drivers ;-)
08:55 mlankhorst: meh
08:56 mlankhorst: v2.6.36 had no support for any nomodeset loading any more, v2.6.33 was the first one with abi 0.16
08:56 mlankhorst: afaict
08:57 xexaxo: danvet: if they are giving away awards for breaking stuff in the most elaborate ways, you'll get at least one :)
08:57 mlankhorst: longterm kernels supported are 3.2 and 2.6.32
08:57 mlankhorst: so...
08:57 mlankhorst: nomodeset check is useless
08:57 mlankhorst: QED
08:57 rzyz85fr: imirkin, RSpliet , i changed it to 1 (options nouveau modeset=1), and still have problem: x log : http://pastebin.com/PYTm6VWs
08:57 xexaxo: where elaborate - the user does not suspects a thing, and everyone is happy.
08:57 xexaxo: s/suspects/suspect/
08:58 mlankhorst: if you boot with nouveau.modeset=0 you probably want to load nouveau still, and that will work
08:58 danvet: xexaxo, the goal is to remove old code without getting caught
08:58 imirkin: rzyz85fr: did you reboot?
08:58 mlankhorst: xexaxo: yes you're breaking my goal :P
08:58 rzyz85fr: but, in the same file, i have: "blacklist nouveau" in first line before options nouveau modeset . i delete it?
08:58 danvet: mlankhorst, oh, so userspace has a nomodeset check?
08:58 rzyz85fr: imirkin, yes
08:58 imirkin: rzyz85fr: ah yeah, blacklist nouveau is no good. i'd just nuke the whole file if i were you
08:58 mlankhorst: danvet: but it was only useful between 2.6.33 and 2.6.36 :P
08:58 xexaxo: mlankhorst: why didn't you just write it down cleanly in the commit message. how am I supposed to know ?
08:58 danvet: yeah userspace indeed shouldn't need to check that ever with kms drivers
08:59 rzyz85fr: ok, let's test that
08:59 mlankhorst: xexaxo: :D
08:59 danvet: either the kms drm node is there or it can't do anything anyway
08:59 xexaxo: but seriously, what is the way if one wants to get the busid of the opened device danvet ?
09:00 mlankhorst: xexaxo: we have no need for it for platform devices!
09:00 danvet: either discovery with udev
09:00 mlankhorst: we can query the device path directly
09:00 mlankhorst: through uev :P
09:00 mlankhorst: udev*
09:00 danvet: yeah
09:00 mlankhorst: enough discussion, back to getting tegra to initialize..
09:00 xexaxo: *libudev aside ?
09:00 danvet: or if you have some bit of information that the kernel needs to give userspace drivers
09:00 danvet: then a getparam ioctl
09:00 mlankhorst: xexaxo: platform support in the ddx uses the results from udev..
09:00 danvet: we just exposed the pci revision for that
09:01 danvet: since userspace drivers need it to enable some w/a
09:01 xexaxo: mlankhorst: I'm asking in general, it's not related to X or its platform code
09:01 mlankhorst: oke
09:01 danvet: early skl apparently broke FMA opcodes ;-)
09:01 mlankhorst: in general if you want to check call drmModeGetResources..
09:02 rzyz85fr: imirkin, thanks, i'm back to 1900*1000 résolution :)
09:02 xexaxo: danvet: sounds like the fun is never ending.
09:02 danvet: oh usually we have piles of early chip w/a and then rip them out again
09:02 danvet: it's just the first time around there was one with a lot of severity and which needed to be handled in userspace
09:08 mlankhorst: pScrn->chipset = malloc(sizeof(char) * 25);
09:08 mlankhorst: argh!
09:09 imirkin: what goes into ->chipset?
09:09 mlankhorst: guess :P
09:09 mlankhorst: that code should have used asprintf
09:09 imirkin: [seems like a lot of characters]
09:09 mlankhorst: was referring to the sizeof(char)
09:10 imirkin: oh
09:10 imirkin: people like to be pedantic :p
09:10 imirkin: coz you know, C standard will switch to a 4-byte char *any time now*
09:12 specing: RSpliet: https://gist.github.com/anonymous/8b7059a28c8389299a35
09:15 xexaxo: am I the only one who doesn't see a problems with using sizeof(char) * number ? it's not like it causes any ambiguity, or makes the code that much longer/harder to read :)
09:16 rzyz85fr: imirkin, just for info: i'm on dell laptop(1900*1000) i7 2760QM with his own graphic + nvidia nvs4200M rev a1. Optimus technology deactivated in BIOS. 2 outputs on laptop: vga+hdmi. I plug my laptop at office on a "the dell baseboard", which give me 2dvi, 2DP + 1vga ( nouveau doesn't work well on ubuntu 114.04 trusty: switch between laptop and my 2 20" monitor), i'm restesing it on 14.10..
09:16 pmoreau: xexaxo: +1
09:16 specing: RSpliet: awaiting your interpretation
09:21 RSpliet: specing: sry mate, was out running some errands
09:22 RSpliet: looks like the clocks are stable
09:22 specing: stable?
09:22 RSpliet: they don't change
09:23 RSpliet: there's no exceptional low clock in there (well, apart from those 19,5MHz clocks, but no idea what they're for)
09:24 RSpliet: Set 6 and 7 seem to be your "core" and "shader" freq
09:25 specing: RSpliet: dmesg says core is 275MHz and shader 550MHz
09:26 specing: set 7 matches core, but set 6 is 450 MHz
09:27 specing: weird
09:27 specing: set00 * 4 rounded down to nearest 10 Mhz is 550MHz
09:28 specing: I'll boot up a game and see what happens
09:31 RSpliet: hmm, sorry, was looking at it from the top of my head
09:31 RSpliet: you're probably right, set 6 could just as well be the video decoding unit(s)
09:33 specing: GLX is not supported hmm
09:33 imirkin: specing: if you're switching between blob and open drivers, you probably didn't replace something
09:33 imirkin: like... libglx.so
09:33 imirkin: specing: eselect opengl set xorg-x11
09:35 specing: imirkin: that is broken too. Oh what a mess
09:35 specing: (was the first thing I tried)
09:35 specing: reports the same result
09:35 specing: maybe I have to restart xorg?
09:35 imirkin: well you have to restart X afterwards
09:35 imirkin: coz libglx.so is an X module
09:35 specing: ah ok
09:37 specing: Why is there a third eselect opengl option called 'opengl'?
09:37 specing: mesa stuff?
09:37 imirkin: uhh
09:37 imirkin: i only see 'nvidia' and 'xorg-x11'
09:38 DogsThisWay: Hello everyone
09:43 specing: AIGLX error: dlopen of /usr/lib64/dri/nouveau_dri.so failed (no such file)
09:44 specing: What else do I need in userspace? (Besides xf86-video-nouveau)
09:44 imirkin: specing: mesa
09:45 xexaxo: that path looks suspiciously like the default (not used by any distro)
09:45 imirkin: specing: and VIDEO_CARDS=nouveau
09:45 specing: Mesa is always installed no matter what
09:45 specing: VIDEO_CARDS=nouveau is set
09:45 xexaxo: s/any/many/ (as I've not checked gentoo) :P
09:45 specing: maybe a recompile of mesa is needed
09:45 imirkin: xexaxo: that's the location used by gentoo's new eselect-opengl stuff... it's a symlink to /usr/lib64/mesa/nouveau_dri.so
09:46 imirkin: specing: did you set it after compiling mesa for the last time?
09:46 specing: imirkin: yes
09:46 specing: I'm looking at -N world now
09:46 imirkin: specing: so... you need to rebuild it again for the setting to take effect :)
09:46 MAN-AT-ARMS: imirkin any other ideas regarding the black sceen on nv20
09:46 xexaxo: imirkin: iirc (open)suse, fedora and arch use /usr/lib/xorg/modules. with debian and derivatives a similar one.
09:46 specing: imirkin: it is lovely though, no more 24x80 in vty
09:46 imirkin: MAN-AT-ARMS: sorry, no =/
09:47 xexaxo: /usr/lib/xorg/modules/dri/ actually.
09:49 xexaxo: actually I'm completely off. seems like only arch is the special one here.
09:50 mlankhorst: ok I'm hitting some stupid issue with kepler
09:51 mlankhorst: tempted to just add #undef NOUVEAU_BO_VRAM #define NOUVEAU_BO_VRAM NOUVEAU_BO_GART..
09:52 imirkin: hehehehe
09:52 imirkin: well depending on the kernel version, all vram allocations will fail
09:52 mlankhorst: in fact doing that for platform devices is probably a good idea..
09:52 specing: btw, how fast is the mesa software rendering?
09:53 imirkin: specing: depends on the cpu powering it :p
09:53 specing: and does it support whole of OpenGL?
09:53 imirkin: llvmpipe supports GL 3.3 + some extensions
09:53 specing: imirkin: lets say 3 GHz ivy bridge 4-core
09:53 mlankhorst: imirkin: I'm on the most recent one, does that one have no VRAM domain?
09:53 imirkin: specing: http://people.freedesktop.org/~imirkin/glxinfo/glxinfo.html
09:53 specing: imirkin: I'll open it when I get xorg back :)
09:53 imirkin: mlankhorst: dunno which is the most recent one... ben's repo? that should have done away with VRAM afaik
09:53 mlankhorst: probably
09:54 mlankhorst: it's some snapshot of ben's repo anyway
09:54 imirkin: mlankhorst: although imo it should just make them GART allocs to let stupid software work
09:54 mlankhorst: imirkin: that can be handled in libdrm..
09:54 imirkin: i guess, yea
09:54 imirkin: the only thing that _has_ to be in vram is scanout afaik
09:55 mlankhorst: and there's none..
09:55 mlankhorst: oh on older < nvc0 cards some tiling formats have to be in VRAM
09:55 imirkin: oh right, the G80 doesn't support tiling in sysram
09:55 imirkin: G84 fixes all that nonsense though
09:57 mlankhorst: so if we did away with all of VRAM, how does nvea work? :P
09:57 imirkin: (and it's just the microtiling stuff... macrotiling all works)
09:57 imirkin: mlankhorst: there are mesa patches too
09:57 imirkin: to use GART instead of VRAM all over the place
09:57 mlankhorst: ah..
09:58 imirkin: not that much of it anyways... mostly it's dynamicly determined
09:58 imirkin: through the foo_bindings stuff
09:58 imirkin: sysmem_bindings/etc
09:58 mlankhorst: oh it just sets vram_domain = NOUVEAU_BO_GART, HAX
09:59 imirkin: so just clearing out the vram_bindings thing leaves a handful of small things
09:59 mlankhorst: ah that explains the failure I'm seeing with the ddx then :P
10:01 DogsThisWay: How can I enable hardware acceleration for gnome desktop ? My OS is Trisquel.
10:02 imirkin: DogsThisWay: which video card do you have?
10:02 DogsThisWay: Nvidia GTX 760
10:02 specing: RMS frees you from graphics
10:02 imirkin: DogsThisWay: should just work
10:02 imirkin: DogsThisWay: pastebin xorg log and glxinfo output
10:04 DogsThisWay: I see Gnome using Gallium acceleration, from what I heard it is software acceleration. Due that drawing of everything is just slowed down
10:04 DogsThisWay: I'll pastebin logs aswell, wait a minute
10:04 imirkin: if it says "Gallium on NVE6" or whatever, that means you're getting hw accel
10:05 imirkin: if it says "Gallium on llvmpipe" that means software
10:05 DogsThisWay: Gallium 0.4 on NVE4
10:05 imirkin: right. that's hardware accel
10:05 imirkin: note that by default the cards boot into a very low performance state
10:05 imirkin: and nouveau has no (automatic) way of changing it right now
10:05 DogsThisWay: Just everything is slow, I was sure that it was software rendering
10:06 imirkin: you can boot with nouveau.pstate=1
10:06 imirkin: and then play with the pstate file that appears in sysfs
10:06 imirkin: note that this is experimental
10:06 imirkin: and chances are that going to the highest level will cause your card to lock up
10:06 mlankhorst: imirkin: GK20A has the same shader ops as maxwell right?
10:07 DogsThisWay: Can you elaborate me on how to do this ?
10:07 imirkin: mlankhorst: no. GK208
10:07 imirkin: mlankhorst: and GK110
10:07 mlankhorst: oke
10:07 mlankhorst: does the ddx support those ops
10:07 imirkin: mlankhorst: yea
10:07 imirkin: look for nvf0
10:07 mlankhorst: ok
10:08 imirkin: you might need a diff GR class though
10:08 imirkin: check mesa
10:08 mlankhorst: yeah i fixed that part
10:08 mlankhorst: didn't push it yet
10:09 imirkin: k
10:09 mlankhorst: ah got those ops
10:10 imirkin: btw, i have 97% of a maxwell exa enablement patch for xorg...
10:10 mlankhorst: ah nice
10:10 imirkin: just missing the immediate -> vbo conversion
10:10 imirkin: for stupid blits
10:11 buhman: I hear skeggsb understands 97% of why gk106 is borked.
10:11 buhman: ;p
10:11 mlankhorst: I'm going to check if I can make relocs with NOUVEAU_BO_GART | NOUVEAU_BO_VRAM, then just fix up the allocations
10:11 imirkin: buhman: you mean _your_ gk106?
10:11 mlankhorst: i think the kernel sanitizes it anyway
10:11 buhman: well, not just mine
10:11 buhman: imirkin: he said devinit isn't the problem
10:11 imirkin: ok, but all the people's for whom it's timing out?
10:12 imirkin: anyways, there's no such thing as 97% understanding something
10:12 buhman: the timeout is because the gpc rejects the microcode upload
10:12 imirkin: there's just understanding the 97 things it isn't :)
10:12 imirkin: DogsThisWay: add nouveau.pstate=1 on the command line and reboot. come back when you've done that and await further instructions :)
10:12 buhman: imirkin: ;p
10:26 mlankhorst: meh lets see if using NOUVEAU_BO_APER works..
10:26 imirkin: whoa, never heard of that one
10:28 specing: Well
10:28 specing: Now Xorg stopped writing to Xorg.0.log
10:28 specing: And I have no idea what is wrong
10:29 specing: I can login on the SLIM login screen, but it just throws me back at login
10:29 imirkin: specing: you don't have systemd enabled or some bs like that?
10:30 mlankhorst: ugh.. that nouveau_device_wrap in NVOpenDRMMaster is evil!
10:31 specing: imirkin: nope
10:31 specing: imirkin: only systemd-udevd because I was too lazy to switch to eudev
10:31 specing: slim.log:
10:31 specing: slim: unexpected signal 1
10:31 specing: slim: connection to X server lost.
10:32 specing: repeats two times
10:33 imirkin: specing: oooh, i'll have to look into that eudev thing
10:34 imirkin: i've been wanting to purge my system of anything with 'systemd' in the name
10:34 imirkin: specing: anyways... try just running X directly
10:34 imirkin: i.e. what happens if you literally just run "X"
10:36 DogsThisWay: I guess I enabled nouvea.pstate=1, since I located pstate file where it have to be
10:36 imirkin: DogsThisWay: awesome
10:36 DogsThisWay: 07: core 405 MHz memory 324 MHz
10:36 DogsThisWay: 0a: core 405-967 MHz memory 810 MHz
10:36 DogsThisWay: 0e: core 405-1228 MHz memory 3004 MHz
10:36 DogsThisWay: 0f: core 405-1228 MHz memory 3004 MHz
10:36 DogsThisWay: --: core 405 MHz memory 324 MHz *
10:36 DogsThisWay: This is what it have
10:37 imirkin: so now you can switch between them by echoing those values into the file
10:37 imirkin: i.e. echo 07 > pstate
10:37 imirkin: etc
10:37 imirkin: note that 0e and 0f will most likely lock up your card
10:38 specing: imirkin: ah, X was still running
10:38 DogsThisWay: So, is it safe to choose 0a for example for gtx 760 ?
10:39 mlankhorst: ok recompiling..
10:40 specing: imirkin: NOUVEAU: [COPY] failed to load class is the first error
10:40 mlankhorst: nvc0_screen_create:692 - Error allocating PGRAPH context for 3D: -22
10:40 mlankhorst: much further :-D
10:41 specing: imirkin: but now it is just blackscreen
10:41 specing: imirkin: wait, it is not
10:41 specing: it just takes a long time for the login screen to appear
10:42 imirkin: specing: well X is *supposed* to just put up a black screen
10:42 imirkin: until you run something else, that's by design :)
10:42 specing: yeah...
10:42 mlankhorst: ok the nvc0_screen_create comes from mesa, trying without glamor accel..
10:42 imirkin: specing: what card do you have? i think the COPY error happens for pre-nva3 nv50-family cards
10:42 specing: imirkin: btw isn't it supposed to put a gray screen or something?
10:42 imirkin: and it's harmless
10:42 specing: imirkin: G84 (8600M GT)
10:43 imirkin: specing: nah, that mask is gone i think. it definitely used to, but not anymore
10:43 imirkin: not sure why they killed it
10:43 imirkin: mlankhorst: wait, why does nvc0_screen_create fail? do you have an old mesa?
10:43 specing: imirkin: I can login now
10:44 mlankhorst: imirkin: no idea..
10:44 imirkin: specing: ok cool
10:44 specing: imirkin: it took about 50s for the login screen to show up
10:44 imirkin: mlankhorst: what mesa do you have?
10:44 specing: imirkin: why?
10:44 specing: something is still broken
10:44 mlankhorst: imirkin: ah right... running as root resets LD_LIBRARY_PATH
10:44 imirkin: specing: no clue, but definitely nothing nouveau-related
10:44 specing: and if I don't fix it it will bite me in the ass in the future
10:44 mlankhorst: imirkin: ty :D
10:44 specing: imirkin: it didn't happen before with nvidia-drivers
10:45 imirkin: specing: yeah, but you messed something up and now some indeterminate component of this complex system is mad at you
10:45 imirkin: that's why i like to keep things simple
10:45 imirkin: DogsThisWay: it'll depend on the specific card... try it out and see :)
10:45 DogsThisWay: bash: pstate: Permission denied
10:45 imirkin: DogsThisWay: there's a reason it's experimental. worst thing that happens is your box hangs... so not a huge deal.
10:45 imirkin: well, you have to be root :)
10:45 specing: imirkin: how do you keep things simple with Xorg?
10:46 specing: impossible
10:46 imirkin: specing: unfortunately it's gotten harder
10:46 mlankhorst: imirkin: heh, crash in drmmode_fbcon_copy now :p
10:46 imirkin: used to be i could just use gdm
10:46 mlankhorst: I'm pretty sure that can never work..
10:46 imirkin: but now gdm3 is required and all the gdm2 stuff is gone
10:46 imirkin: i tried out lightdm recently, but i might just go back to xdm
10:47 imirkin: specing: alternatively you can just use startx
10:49 DogsThisWay: bash: echo: write error: Function not implemented
10:49 DogsThisWay: Weird
10:49 imirkin: DogsThisWay: what kernel are you on?
10:49 DogsThisWay: GNU Linux
10:49 imirkin: :p
10:50 imirkin: i was thinking of a version number
10:50 specing: imirkin: nothing in the xorg.0.log telling why it froze
10:50 specing: imirkin: I recall it froze for 50s on bootup as well
10:50 imirkin: specing: it didn't freeze
10:50 specing: imirkin: hung/whatever
10:50 imirkin: some process just took forever to start that actually requests X to display things
10:50 pmoreau: DogsThisWay: kernel version he meant
10:51 DogsThisWay: 3.13.0-46-lowlatency
10:51 specing: imirkin: from dmesg:
10:51 specing: [ 0.771600] tg3.c:v3.137 (May 11, 2014)
10:51 specing: [ 50.130136] ACPI: Battery Slot [BAT1] (battery present)
10:51 specing: it continued when I plugged the battery in
10:51 imirkin: DogsThisWay: ah yeah, you need something a lot more recent
10:51 specing: some clocking issues?
10:51 imirkin: specing: hmmmmm try booting with nouveau.config=NvMSI=0
10:51 mlankhorst: bleh, anyone feels like testing a patch for me?
10:51 specing: imirkin: I don't feel like re-booting ;)
10:51 imirkin: DogsThisWay: you need at least 3.17 iirc
10:52 buhman: mlankhorst: does it involve gk106? :3
10:52 specing: imirkin: nouveau is a module though
10:52 mlankhorst: sure if you want
10:52 buhman: :D
10:52 buhman: mlankhorst: pick me
10:52 specing: imirkin: what does that do?
10:52 imirkin: mlankhorst: he has an optimus setup and his gk106 doesn't work 97% of the time
10:52 mlankhorst: http://paste.debian.net/161254/http://paste.debian.net/161254/ patch your ddx with this..
10:52 buhman: mlankhorst: 100%
10:52 buhman: imirkin: ^
10:52 imirkin: specing: it tells nouveau not to try to use MSI interrupts (i.e. just uses regular interrupts instead)
10:52 mlankhorst: it should make GK20A mostly work
10:53 imirkin: usually long hangs like that mean that some sort of interrupt delivery is messed up? dunno
10:53 mlankhorst: kernel clips valid_domains anyway, so I don't see the point of doing it in userspace :P
10:54 buhman: http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=97c288c10334dfd0672e3c24d44955770352db0e huh
10:54 buhman: that looks interesting
10:54 specing: [ 0.694218] ------------[ cut here ]------------
10:54 specing: [ 0.694366] WARNING: CPU: 1 PID: 1 at /tmp/linux-3.18.7-gentoo/kernel/time/tick-sched.c:192 can_stop_full_tick+0x7c/0xb0()
10:54 specing: [ 0.694502] NO_HZ FULL will not work with unstable sched clock
10:54 imirkin: specing: please use pastebin
10:54 specing: just 3 lines
10:55 mlankhorst: imirkin: do you feel like testing that patch? :D
10:55 imirkin: yeah, but the remaining 30 lines are the interesting ones :)
10:55 imirkin: mlankhorst: not particularly :p
10:55 specing: imirkin: ok :)
10:55 mlankhorst: works on my GK20A
10:55 imirkin: so wtf is this APER thing?
10:55 mlankhorst: VRAM|GART
10:55 imirkin: oh
10:56 buhman: mlankhorst: erm, what repo does that apply to?
10:56 mlankhorst: I haven't fixed nouveau_xv yet, that one needs more thought
10:57 mlankhorst: buhman: it won't help you
10:57 imirkin: ben might have to look at this one
10:57 mlankhorst: imirkin: yeah was afraid so..
10:57 imirkin: esp that shared bs
10:57 imirkin: has to do with xrandr, offloading, etc
10:57 mlankhorst: imirkin: oh that one mostly has to do with dma-buf and optimus..
10:57 imirkin: aka things i don't understand
10:57 mlankhorst: I can probably test that one at home
10:58 imirkin: and if these buffers end up in GART it'd kinda suck
10:58 mlankhorst: no it's not really possible
10:58 mlankhorst: because of the kernel
10:58 imirkin: what does the kernel do?
10:59 mlankhorst: it checks valid domains against domains bo was allocated with
10:59 mlankhorst: and restricts it to those domains
10:59 imirkin: ah ok
10:59 imirkin: can a bo be allocated with APER?
11:00 imirkin: (otherwise i don't see the purpose of the flag)
11:00 mlankhorst: oh it's mostly to remove a bunch of ifs
11:00 mlankhorst: you can allocate a bo with aper, but that would degrade performance..
11:00 imirkin: right
11:00 imirkin: i was just trying to understand the api :)
11:01 mlankhorst: so in general you specify whether you want VRAM or GART
11:01 specing: imirkin: https://gist.github.com/anonymous/a7ed1c3240275ab2d7fd
11:01 mlankhorst: hence the vram_domain stuff in accel_common.c
11:02 mlankhorst: only in case of exported dma-bufs we always need to allocate in GART
11:02 imirkin: specing: doesn't seem like any serious issue there... nouveau just gets loaded pretty late
11:02 imirkin: specing: i assume it's amodule
11:02 mlankhorst: else we can't share them with other devices
11:02 imirkin: the unstable sched clock thing basically means you can't use a NO_HZ_FULL kernel
11:03 imirkin: that would explain the pauses as well
11:04 specing: imirkin: yes, it is a module
11:04 specing: imirkin: ok, I'll recompile
11:05 imirkin: basically NO_HZ_FULL super-disables all timer ticks
11:05 imirkin: and relies on various cleverness
11:05 imirkin: which relies on having a working HPET or whatever
11:07 specing: option be like "Say N here"
11:08 imirkin: yes
11:08 specing: it literaly says that
11:09 imirkin: hehehe
11:09 imirkin: and yet you said 'Y' :)
11:10 specing: there are so many options you can't read all the help
11:12 mlankhorst: oops
11:14 specing: imirkin: so, opening a game works
11:14 specing: but textures dont
11:14 imirkin: specing: install libtxc_dxtn
11:14 specing: more exactly, ... ok
11:14 imirkin: more exactly s3tc textures don't work? :)
11:14 specing: ground textures work, but buildings/units are untextured
11:16 specing: imirkin: https://i.imgur.com/vwZv1oU.jpg
11:17 imirkin: did you install libtxc_dxtn?
11:17 imirkin: should be a gentoo ebuild for that
11:17 specing: not yet
11:17 specing: this might not be that bad at all
11:17 specing: no textures -> better performance?
11:18 imirkin: mmmm.... not sure
11:18 imirkin: it's not "no textures"
11:18 specing: the game is using a lot of memory
11:19 imirkin: it's more like "some textures not being loaded"
11:19 specing: much more than with nvidia-drivers
11:19 specing: is this normal?
11:19 imirkin: not particularly, but memory accounting might be working differently
11:21 RSpliet: specing: I might have missed a bit of conversation, but did you triple-check you're using nouveau with that game?
11:22 RSpliet: what does glxinfo | grep render tell you about the "openGL renderer string"?
11:24 specing: imirkin: textures now work
11:24 specing: imirkin: also much less memory use
11:24 specing: why doesen't the mesa ebuild pull in this library
11:25 imirkin: patents
11:27 specing: what
11:28 imirkin: https://www.opengl.org/registry/specs/EXT/texture_compression_s3tc.txt
11:28 imirkin: i don't actually know which patent tbh
11:29 imirkin: but since they also managed to patent using floating point values stored in textures, i assume it doesn't say _that_ much
11:29 specing: this is bs
11:29 specing: since when was violating patents a problem for ebuilds?
11:30 imirkin:is not a gentoo ebuild maintainer
11:33 DogsThisWay: I'm not sure if it is right place to ask, but what differences between generic and lowlatency linux kernels ?
11:33 imirkin: if you have to ask the question, the answer is 'nothing at all'
11:34 imirkin: low latency kernels allow special processes to request special scheduling semantics that guarantee maximum scheduling latencies
11:38 specing: realtime kernels?
11:39 imirkin: yes
11:39 imirkin: that's what i assumed 'low latency' was in reference to
11:39 specing: microcontrollers with less control
11:40 mlankhorst: nice, xorg-server runs
11:41 imirkin: does it display too?
11:42 mlankhorst: no idea, lets find out..
11:42 specing: mlankhorst: beat you to it
11:43 mlankhorst: almost!
11:43 mlankhorst: Program received signal SIGSEGV, Segmentation fault.
11:43 mlankhorst: 0xb69dd0a8 in nouveau_bo_set_prime ()
11:43 mlankhorst: from /opt/nouveau/lib/libdrm_nouveau.so.2
11:45 specing: hah
11:45 mlankhorst: so it crashes on nouveau_bo_set_prime for some reason, else I would have gotten a display :P
11:45 specing: 50 million lines of C be segfaulting
11:45 mlankhorst: actually my previous problem was a gpu hang
11:48 mlankhorst: erm not really a gpu hang, but a cpu hang
12:16 specing: Now xorg hung
12:16 specing: I can see the active window and everything and move the mouse, but I cannot interact with anything
12:18 imirkin: anything in dmesg?
12:21 specing: [20636.941321] nouveau E[ PFIFO][0000:01:00.0] still angry after 101 spins, halt
12:21 imirkin: ah, there's a patch for that
12:21 specing: >_>
12:22 specing: why do I have to apply a million patches to Linux for it to become remotely usable?
12:22 imirkin: http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=c869d99187a356b886bdecc757caa0038d142844
12:23 imirkin: this is a recent issue
12:23 imirkin: our testing isn't perfect
12:23 imirkin: and ben has been really bad about sending patches to the fixes tree
12:23 imirkin: airlied: you should poke him :)
12:23 imirkin: skeggsb: --^
12:24 specing: is there a temporary workaround that doesen't require a reboot?
12:24 imirkin: mmm... you could probably poke a bunch of registers
12:24 imirkin: not sure which ones though
12:26 specing: btw it hung while I was scrolling on the glxinfo page you linked
12:27 imirkin: well, that page doesn't have any webgl stuff on it
12:28 imirkin: so it's probably the browser doing things
12:35 specing: slowfox
12:36 pmoreau: RSpliet: I'll eat and do the mmiotrace after that. Any recommendation on what I should do to get an *interesting* trace?
12:37 specing: imirkin: https://gist.github.com/anonymous/431123b12a1c88b9f977
12:37 specing: ugh
12:39 DogsThisWay: imirkin: 3.16 kernel version was enough, but seems like changing this value doesn't give effect at all
12:39 specing: root 13794 3.1 0.0 0 0 ? Ds 18:41 3:44 [X]
12:40 specing: this is 50 shades of broken
12:41 imirkin: DogsThisWay: pretty sure you need 3.17 or later if you want it to work
12:42 imirkin: DogsThisWay: the -- line represents the current settings... i'm guessing that doesn't change for you?
12:43 DogsThisWay: I'll look
12:44 imirkin: specing: you really want that patch.
12:44 DogsThisWay: imirkin: It changes
12:44 imirkin: DogsThisWay: oh. then what makes you think it "doesn't give effect at all"?
12:46 DogsThisWay: imirking: I'm not sure, but it seems like problems with gnome. I used Debian with same drivers and nothing was slowed down at all. By slowing down I mean that here are delayed draw of different elements and windows are following mouse slow, when I dragging them
12:47 imirkin: DogsThisWay: pastebin dmesg, xorg log, and glxinfo
12:48 DogsThisWay: imirkin: Ok, give me a minute
12:48 specing: gawd
12:48 specing: whole weekend lost to nouveau
12:49 pmoreau: That's not a bad week-end :)
12:49 imirkin: specing: what were you expecting from the switch exactly? seems like you had a bunch of misconfiguration in the kernel unrelated to nouveau, missing software, etc... not _all_ nouveau's fault
12:50 imirkin: that last issue you're encountering most definitely _is_ nouveau's fault
12:51 specing: imirkin: I switched because NVidia dropped support for NV50
12:52 imirkin: not really... you can just use the 340.x series
12:52 specing: G84, not whole NV50 iirc
12:52 specing: imirkin: yeah, but that limits me to old xorg
12:52 imirkin: no, they dropped everything pre-fermi
12:52 imirkin: (aka nvc0)
12:52 specing: which in turn limits me to old ...
12:52 DogsThisWay: imirkin: http://pastebin.com/gwn0E1sx (dmesg), http://pastebin.com/jrRftf1W (glxinfo), http://pastebin.com/YC8btMmK (xorg.log)
12:53 specing: I'll patch the 3.18.7 and recompile
12:53 imirkin: DogsThisWay: ok thanks, give me a few minutes to process
12:53 imirkin: specing: hmmmmm that patch might not apply to 3.18 very nicely. might have to munge some paths, things got moved around in 4.0
12:54 pmoreau: specing: I can use 340.x with xorg 1.17.1 which is not that old
12:55 specing: plus I believe nouveau is finaly mature enough to replace nvidia blobs
12:55 imirkin: specing: i suspect today's experience may have shaken that belief? :)
12:56 imirkin: DogsThisWay: hmmmmmm.... nothing _obviously_ wrong in there. i do think that 3.17 had some important changes to the reclocking stuff, but even without any reclocking, your board should be plenty fast to handle a plain desktop
12:56 imirkin: DogsThisWay: the only thing is that you have a pretty old mesa... mesa 10.1.x. but it's not _that_ old
12:56 imirkin: sorry, not sure why things would be sluggish
12:57 imirkin: perhaps the deblob thing modified something in an unfortunate way
12:57 specing: imirkin: so far only crashes?
12:57 specing: I was more worried of it not working at all
12:57 tobijk: not sure waht they want to deblob with nouveau though :>
12:57 specing: as opposed to hanging
12:57 imirkin: specing: there are very few pieces of hardware it just totally doesn't work on
12:58 DogsThisWay: imirkin: This problem so far occured only in ubuntu and its derivatives. Some people suggested me to setup KDE to solve my issue
12:58 specing: imirkin: does that include my chip?
12:58 imirkin: specing: generally you have to get creative... like sticking things into big-endian machines, or very odd hw
12:58 tobijk: DogsThisWay: can you try a live image on an usb ?
12:58 imirkin: specing: no, you have a garden-variety G84 mobile chip. should be fine.
12:59 DogsThisWay: imirkin: Live image of my current OS ?
12:59 imirkin: there were some G86's iirc that were missing PCRYPT units entirely that we weren't detecting, but that was fixed a while ago
12:59 tobijk: DogsThisWay: of another one, maybe really one with kde to see if its teh desktop
12:59 specing: imirkin: "garden-variety"?
12:59 imirkin: some Quadro NVS 140M's i think.
12:59 imirkin: it's a euphemism for "common"
12:59 specing: ok
13:00 specing: < imirkin> specing: generally you have to get creative... like sticking things into big-endian machines, or very odd hw
13:00 specing: I had a very unpleasant experience with radeon in a dual-xeon machine
13:00 DogsThisWay: tobijk: Alright, I'll give it a try. Thanks everyone who helped me :)
13:01 imirkin: e.g. there was a guy who was trying to get a PCIe -> PCI board to work in an really old machine that didn't have MSI support and linux doesn't handle that well, so no interrupts were making it through
13:01 tobijk: DogsThisWay: if teh problem persits, feel free to come back :)
13:01 imirkin: NvMSI=0 to the rescue on that one :)
13:03 mlankhorst: meh, some of the exa pixmap stuff is silly
13:04 imirkin: you're probably the first person looking at that code in 5y :p
13:06 tobijk: heh maybe we should try to go for galmor after all?!
13:06 tobijk: *glamor
13:06 imirkin: tobijk: fwiw i had a very bad experience with glamor on nouveau
13:06 imirkin: it messes up GLX somehow
13:07 imirkin: and GLX_ARB_create_context_profile or whatever doesn't get exposed
13:07 imirkin: so you can't get a core context anymore
13:07 tobijk: imirkin: after the great work that was invested recently? (the last year)
13:07 imirkin: tobijk: i'm sure glamor is fine. it's something in the nouveau hookup.
13:07 tobijk: :/
13:09 imirkin: at the time i was trying to get mesa on maxwell into better shape, so i wasn't too interested in why glamor was failing
13:09 imirkin: so i just disabled it and switched to a noop exa impl
13:10 imirkin: still need to do more work on maxwell... there's a vbo cache flush missing
13:10 imirkin: need to find that
13:11 tobijk: yeah that is a more urgent problem i guess, but in the log run i really would like to see a glamor backend
13:11 tobijk: a working one ^^
13:12 imirkin: meh, it's not too bad... just a few rendering artifacts in xonotic
13:12 imirkin: afaik that's the only application with obvious issues
13:13 specing: imirkin: is there a way for freedesktop webgit to give me a patch file?
13:13 imirkin: sure... just click the patch link
13:13 specing: copy-pasta doesen't preserve tabs
13:14 specing: I don't see any patch links
13:14 tobijk: click on "patch"
13:14 imirkin: or replace "commit" in the url with "patch"
13:14 imirkin: [use the browser's find function... it's there...]
13:15 mlankhorst: ok I can use glamor for now..
13:15 imirkin: mlankhorst: do you have the same issue with the GLX_ARB_create_context_profile missing?
13:19 specing: imirkin: oh
13:22 imirkin: specing: btw, if you want to play with other half-baked stuff, you can try the video acceleration stuff i did for VP2... should have h264 and mpeg2 working :)
13:23 specing: imirkin: drm/nouveau/nvkm/engine/fifo/nv04.c doesen't exist in 3.18.7
13:24 imirkin: specing: like i said... some stuff moved around
13:24 specing: oh, I thought it meant "inside the file"
13:24 DogsThisWay: LXDE version of same OS isn't lag at all. Seems like a problem exclusively with GNOME and ubuntu
13:24 imirkin: specing: also note that this is an out-of-tree module... the relevant file in that linux kernel would be
13:24 specing: imirkin: those that half-baked stuff crash?
13:24 imirkin: drivers/gpu/drm/nouveau/core/engine/fifo/nv04.c
13:24 tobijk: DogsThisWay: does LXE use a compositing thing? 3d effects or such?
13:25 imirkin: specing: well, for some people it's insta-hang. i think that's on G92's. but for most people it's just occasional artifacts in some videos.
13:25 specing: imirkin: I think I'll pass... :)
13:25 DogsThisWay: tobijk: How to verify ? First time using this. Earlier used only KDE and gnome.
13:25 DogsThisWay: tobijk: It looks like uglified gnome at all
13:26 tobijk: hehe i guess no effets then
13:27 specing: patching failed
13:28 specing: I found the code though
13:29 specing: imirkin: would there be a problem if I just replaced the whole function?
13:29 specing: Probably not
13:30 imirkin: specing: well, there have been api changes too
13:30 imirkin: stuff got renamed, etc
13:30 imirkin: look at what the patch was doing, and try to apply by hand
13:30 tobijk: DogsThisWay: you could try kde to see if that is sluggish, that one got plenty of effects ;-)
13:30 DogsThisWay: tobijk: Can you suggest me any free OS with KDE installed by default ?
13:31 tobijk: there are sure plenty :>
13:31 tobijk: i use opensuse for now, they go with kde as a default
13:34 DogsThisWay: tobijk: Ok, I'll give it a try. I'll report back soon
13:38 imirkin: specing: let me know if you run into trouble, i can probably generate the patch if you are
13:47 specing: pfft this guy switched from 'status' to 'stat'
13:51 specing: nouveau_fifo_uevent(&priv->base); renamed into nvkm_fifo_uevent(&priv->base);
13:51 specing: keeping old
13:51 imirkin: good move
13:51 tobijk: will break :D
13:56 specing: https://gist.github.com/anonymous/b7e32953eaa35d850e84
13:56 specing: final patch
14:00 imirkin: seems reasonable
14:00 mlankhorst: why does nouveau still use the exa wrapping stuff? seems to me we should really do away with it..
14:01 specing: Anything else I should patch in 3.18.7?
14:01 specing: ...while I'm in the mood
14:02 mlankhorst: I mean we have a memory manager and it's called TTM :P
14:02 tobijk: specing: i'd not patch too much, just go to newer versions if you like new stuff :>
14:03 imirkin: nothing too critical that comes to mind
14:05 specing: build went fine
14:06 specing: tobijk: there is rarely anything I'd really want
14:06 specing: Squashfs and F2FS are two examples
14:06 specing: Look at the new overlayfs
14:07 specing: that thing is so dumbed down I can't even begin describing
14:07 Omar007: If you want something to patch, I may have something for you to look into for 3.19? :P
14:07 specing: I want patches that remove crashes and hangs and whatnot
14:07 specing: not those that introduce them :)
14:08 imirkin: don't we all
14:08 Omar007: ^
14:08 imirkin: they're sadly very difficult to distinguish from one another
14:08 tobijk: well i dont see where an unused squashfs would introduce them but ok ...
14:10 Omar007: Sadly I don't have a patch for the particular problem I encountered, only a general idea of what direction to look in
14:11 imirkin: Omar007: you said you were having with outputs on a GM20x?
14:11 tobijk: Omar007: is it nouveau related or just something else?
14:11 Omar007: nouveau
14:11 Omar007: most likely
14:11 Omar007: KMS
14:11 imirkin: Omar007: try ben's latest tree, it has a patch which could help
14:12 Omar007: Basically I got a recent 970 with a very new BIOS (februari this year) basically breaks the KMS that works most of the time for older BIOS in 3.19.1
14:12 imirkin: specifically http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=de655120f864584262c9131cf595f4b4f599b9f0
14:12 Omar007: Had to fall back to the nvidia blob
14:12 Omar007: Lets see
14:13 imirkin: no idea if it helps your issue or not
14:13 Omar007: hmm probably not
14:13 Omar007: I dont use HDMI
14:13 imirkin: i think it affects more than just hdmi
14:13 Omar007: Let me see if I can pull up some older logs from before the switch to the nvidia blob
14:13 Omar007: it was something AUX related
14:14 Omar007: I should really set some time apart to write these things down somewhere... :/
14:14 imirkin: do you use DP?
14:14 Omar007: Yea
14:15 imirkin: so yeah, could be helped by this. but perhaps not, dunno
14:18 Omar007: nouveau E[ PDISP][0000:02:00.0] 06:0006:0f84: aux channel not found
14:18 imirkin: right, i think that patch could help with that
14:20 Omar007: Ok
14:20 Omar007: FYI, I basically receive it 3 times; 1 time for each monitor
14:20 Omar007: mrt 14 01:33:27 Omar-PC kernel: nouveau E[ PDISP][0000:01:00.0] 06:0006:0f84: aux channel not found
14:20 Omar007: mrt 14 01:33:27 Omar-PC kernel: nouveau E[ PDISP][0000:01:00.0] 04:0006:0f44: aux channel not found
14:20 Omar007: mrt 14 01:33:27 Omar-PC kernel: nouveau E[ PDISP][0000:01:00.0] 02:0006:0f82: aux channel not found
14:21 Omar007: where 2, 4 and 8 each are the DP connections
14:21 Omar007: *a DP
14:22 Omar007: Also, I think X does not like it when you arrange displays or something xD
14:23 Omar007: When I did, 1 screen started flashing black/image/black/etc. Seems fixed after changing the order in which they are connected so I don't have to arrange them in X.
14:23 Omar007: Since using nVidia anyway
14:23 Omar007: Had not seen that issue with nouveau
14:23 imirkin: sounds like a blob problem
14:23 Omar007: Yup
14:30 Omar007: Oh shit may have spoken too soon. I think my left monitor just blinked once. Did take a few hours though instead of instantly
14:30 Omar007: Or I imagined it lol
14:34 DogsThisWay: Trying Kubuntu live, seems no lags. It uses nouveau by default. Issue comes from gnome (ubuntu versions) for sure
14:38 tobijk: mh maybe a bad shader in the gnome effects
14:39 DogsThisWay: tobijk: that ubuntu's gnome problem for sure
14:40 tobijk: well or our shader compiler goes crazy on one of their shaders :>
14:41 DogsThisWay: I guess LXDE or KDE will be great solution. KDE on ubuntu looks even more beatifull than gnome
14:41 mlankhorst: imirkin: found it :D
14:41 mlankhorst: - if (!pNv->exa_force_cp && pNv->dev->vram_size <= 32 * 1024 * 1024)
14:41 mlankhorst: + if (!pNv->exa_force_cp && pNv->dev->vram_size && pNv->dev->vram_size <= 32 * 1024 * 1024)
14:41 imirkin: hehe
14:44 Karlton: Okay, imirkin, this what I see when I play the game terasology: http://postimg.org/image/xmtet1b43/
14:44 tobijk: mh no vram...
14:44 mlankhorst: imirkin: now to bug gnurou why I get a bus error when zero'ing out the scanout mapping..
14:44 mlankhorst: I had xeyes working with that call commented out :-D
14:44 imirkin: Karlton: heh, i'm pretty sure i didn't see that
14:45 imirkin: Karlton: but i didn't get very far
14:45 tobijk: looks like a default color to me
14:46 specing: https://gist.github.com/anonymous/7e68b98e24491c7d66f6
14:46 specing: on old kernel
14:46 mlankhorst: imirkin: do you want a glxinfo from the tegra?
14:46 imirkin: Karlton: do you have any special settings in video?
14:47 specing: after the angry after 101 iterations
14:47 imirkin: mlankhorst: no :p should be same as any other kepler
14:47 mlankhorst: but is it?! :o
14:47 specing: imirkin: those hangs are because of that loop, right?
14:47 Karlton: imirkin: no, I just ran the stable version in its source directory without changing anything
14:47 specing: imirkin: err traces
14:48 imirkin: Karlton: yeah dunno... worksforme. try updating mesa?
14:48 imirkin: specing: the "pfifo is angry after 101 acks" thing? yes
14:49 Karlton: imirkin: It must be only my card, I have an old telsa card here I might try to install and see if it works with it
14:49 tobijk: Karlton: you got the libdxtn for s3 texture compression?
14:50 imirkin: shouldn't cause things to turn purple
14:50 imirkin: Karlton: i'm on a different generation of card... fermi vs kepler
14:50 imirkin: could be we're messing something up on kepler somehow
14:50 specing: imirkin: ok, rebooting
14:50 imirkin: Karlton: the way forward is to generate an apitrace and see what's up
14:51 Karlton: imirkin: yeah I have never done that, but I going to try and older card first just to be sure
14:51 imirkin: Karlton: https://github.com/apitrace/apitrace
14:51 mlankhorst: meh..
14:54 airlied: mlankhorst: it wraps createpixmap because it wants to call back into the sdtack
14:54 airlied: to get whatever is installed below it like fb
14:54 mlankhorst: airlied: yeah nm, it was a stupid check in nouveau triggering :)
14:54 mlankhorst: if it had vram < 32 MB it didn't create a nouveau backing
14:54 mlankhorst: but the tegra has 0
14:56 mlankhorst: with the present extension I appear to get 1 fps..
14:57 imirkin: hehe
14:57 imirkin: success? :)
14:57 mlankhorst: I'm not sure it works correctly for gpu screens
14:57 imirkin: s/gpu//
14:58 mlankhorst: I've created it as optimus config, nouveau taking care of the screen, tegra display as output slave
14:58 imirkin: that's reverse-optimus
14:58 imirkin: er, reverse-prime
14:59 imirkin: could well be that tegra's missing something
14:59 mlankhorst: no reverse prime is having nouveau as slave
14:59 mlankhorst: it's the generic modesetting driver
14:59 mlankhorst: it's more likely that xorg is missing something..
14:59 airlied: no that is reverse prime
14:59 airlied: since the output is a slave
14:59 imirkin: output slaving is reverse prime.
15:00 specing: imirkin: on new kernel
15:00 mlankhorst: ah
15:00 imirkin: gpu offloading is regular prime
15:00 specing: imirkin: no boot delay
15:00 specing: imirkin: got into X11 without hickups
15:00 mlankhorst: but since it's nvidia hw, I'll just call it optimus
15:00 mlankhorst: :P
15:00 specing: optimus prime
15:00 specing: optimus composite?
15:01 imirkin: specing: where do you think the name 'prime' comes from?
15:01 mlankhorst: night all!
15:01 mlankhorst: hacking was fun :-)
15:01 imirkin: see ya
15:01 tobijk: good night :)
15:02 tobijk: i'd like to stay with prime, get rid of the nvidia marketing names :P
15:02 imirkin: yeah, but prime is based on the optimus nvidia marketing name :)
15:03 imirkin: or rather, connected to it via the transformers
15:03 tobijk: that really where it came from? ~_~
15:03 imirkin: i assume so
15:04 specing: tobijk: whoa- you need to get your eyes checked
15:05 nightfuri: hello guys. how can i contribute by running tests if i am running on a nvidia proprietary driver ? how do i get started
15:05 imirkin: nightfuri: what hardware do you have?
15:05 tobijk: specing: ?
15:05 nightfuri: Card: NVIDIA GT218 [GeForce 210] imirkin
15:06 tobijk: nightfuri: get piglit
15:06 imirkin: nightfuri: i dunno, i don't think there's a lot left to RE on that card, if anything
15:06 specing: tobijk: "~_~"
15:06 tobijk: ah ^^
15:07 pmoreau: imirkin: Power/clock gating?
15:07 tobijk: pmoreau: you really want him to trace that? :>
15:07 nightfuri: imirkin: RE ?
15:07 imirkin: pmoreau: reclocking works... running piglit tests on that card won't help with the remaining power bits
15:08 imirkin: nightfuri: reverse engineering
15:08 Omar007: Now that I'm on the nVidia blob anyway, want a 970 test? I also have a VBIOS
15:09 imirkin: Omar007: mmmm... actually i'm generally curious if GM20x has a different shader ISA or not
15:09 imirkin: Omar007: if you could get valgrind-mmt going, i'd love a short trace of something dumb... like glxgears or something
15:10 nightfuri: imirkin: oh ok
15:11 Omar007: imirkin, I'll see if I can figure it out ;P
15:11 imirkin: Omar007: http://nouveau.freedesktop.org/wiki/Valgrind-mmt/
15:11 Omar007: Yea I had just found that ;)
15:12 Omar007: Gotta close some work first though, just in case
15:12 imirkin: just like a second or 2 of glxgears running would be more than sufficient
15:12 specing: 210 seems really common
15:12 specing: cheapest card that can be bought, too
15:12 specing: 25 euro, passively cooled
15:13 imirkin: specing: yeah, and it comes in many gpu varieties... some are G84's, many are GT218's... i think a couple are G98's actually
15:13 imirkin: gotta love marketing!
15:13 specing: G84 with the broken solder or without?
15:14 nightfuri: thank you guys
15:15 imirkin: specing: probably without... that was an early manufacturing flaw
15:15 imirkin: specing: mostly in laptops too, iirc
15:15 imirkin: or am i mixing things up?
15:15 Omar007: imirkin, this stuff needs an update! My glib version isn't supported :P
15:15 imirkin: joi: --^
15:16 imirkin: i wish that check would just go away
15:16 imirkin: whenever it's updated, it's just a trivial "add version to list of supported versions"
15:16 Omar007: xD
15:16 pmoreau: I might have a patch somewhere, needed to bump the version number
15:17 imirkin: Omar007: are you using the mmt-3.10 branch?
15:17 Omar007: Yea
15:17 specing: imirkin: it was equally on desktops
15:17 Omar007: That's the default
15:17 specing: imirkin: its just easier to replace a desktop card than a laptop one
15:18 pmoreau: Omar007: Take the second file of that patch https://github.com/hakzsam/archlive-nouveau/commit/2d72ca76c87e4950cd3ff4ea1bc2a08ed49bbfbc
15:18 specing: imirkin: more frustrating, in my laptop the GPU is on a MXM2 card, but they don't make new GPUs for it anymore
15:18 specing: imirkin: all I could get is a wimpy radeon 5000 something
15:19 Omar007: pmoreau thx
15:19 imirkin: specing: radeon HD 5000 is a good card... DX11 support iirc
15:19 specing: and I rather reflow it every month than to fight with radeon drivers
15:19 specing: I hate software
15:20 imirkin: yeah... it's the worst. only thing worse than software is hardware
15:20 imirkin: coz with hardware you have to worry about the integrity of your solder connections to the board
15:23 specing: yeah, but fixing that takes 30 minutes a month
15:23 specing: whereas I could fight software indefinetely
15:24 Omar007: Say pmoreau.. Is this package on the Arch AUR by any chance?
15:25 pmoreau: Hum, not sure
15:25 pmoreau: Oh, it is! :)
15:26 pmoreau: https://aur.archlinux.org/packages/valgrind-mmt-git
15:26 Omar007: Thought that was the one. File nr 1 was a pkgbuild :P
15:26 Omar007: I'll try that on
15:26 Omar007: *one
15:28 pmoreau: Not sure what you mean by "File nr 1 was a pkguild". You'll also get a PKGBUILD for aur.
15:29 Omar007: I ment file nr1 from your patch link. That made me realize it would probably be on the AUR
15:29 pmoreau: And the one from AUR doesn't support glibc 2.21
15:29 pmoreau: Ah, ok
15:29 Omar007: Yea I just read that as well
15:29 Omar007: dependency <2.21
15:30 pmoreau: Just take the files from the patch link then ;)
15:33 Omar007: pmoreau Hmm there must be another location as it still fails :o
15:34 pmoreau: Meh... It works fine on my server
15:34 pmoreau: Probably in the configure file, but it should be generated by another command
15:35 Omar007: basically I run the autogen
15:35 Omar007: then I edit the configure file to use the code in that patch
15:35 Omar007: Yet the configure script still ends up failing with the glib message
15:36 pmoreau: Follow what the pkgbuild does: 1) patch configure.ac, 2) autoreconf -fi, 3) ./configure
15:38 Omar007: Ah I was missing the autoreconf
15:38 Omar007: /facepalm
15:39 pmoreau: :)
15:42 Karlton: imirkin: I cleaned out my pc and installed an older card "geforce gt 240"
15:42 imirkin: ok
15:43 Karlton: now I see this: http://postimg.org/image/uub76wq3v/
15:44 Karlton: the artifacts went away but the sky is black so I guess there are bugs between different cards
15:44 imirkin: i guess so. do you have a recent mesa?
15:45 Karlton: also the artifacts I saw on flightgear went away
15:45 imirkin: there's a known issue on nv50-era cards (such as yours) where if the shader includes a long loop (like 100 iterations), execution of the shader times out
15:45 imirkin: and you get random colors
15:45 Karlton: I have git version I compiled a few days go of mesa
15:46 imirkin: ok, well if you're interested in seeing these issues get fixed, create traces and file bugs
15:46 Omar007: Damn 5 second run == 30MB file
15:46 Omar007: 0.o
15:46 Karlton: okay, that is what I will work on next
15:46 imirkin: Omar007: xz -9. also half a second would be enough.
15:46 imirkin: Omar007: i just want to see like one shader :)
15:48 Omar007: imirkin: http://expirebox.com/download/987c57afa5d32cb2af9f57b45f57c232.html
15:50 imirkin: Omar007: hm, did you see stuff being displayed?
15:50 Omar007: I did
15:50 Omar007: 3 colored gears
15:51 imirkin: ok cool
15:51 imirkin: demmt doesn't like the trace, but i'll work on it
15:51 joi: imirkin: at least once updating that switch in configure.ac was not enough...
15:51 imirkin: oh, did you hit ^C?
15:51 imirkin: Omar007: i think ^C doesn't cause things to get flushed out... could hit hit Esc instead (which tells glxgears to exit)
15:51 Omar007: To close GLXGEARS I just pressed the X
15:52 Omar007: I'll try Esc for you
15:52 Omar007: In the mean time, VBIOS here if anyone wants it
15:52 Omar007: http://expirebox.com/download/8a27524b93c7e595fe62aaa4681c979f.html
15:53 Omar007: imirkin; new file, this time quit with Esc instead: http://expirebox.com/download/f9eca0f6f19fbddd40277351d70c35ad.html
15:54 imirkin: k thanks
15:55 imirkin: joi: take a look... the file from Omar007 makes demmt very unhappy. not sure what the issue is yet.
15:55 imirkin: joi: it's from a GM204
15:56 Omar007: Just to be sure this command is still correct, I ran it like so:
15:56 Omar007: valgrind --tool=mmt --mmt-trace-file=/dev/nvidia0 --mmt-trace-file=/dev/nvidiactl --mmt-trace-nvidia-ioctls --log-file=file-bin.log glxgears
15:56 specing: imirkin: Is there a tool that will report GPU temperature?
15:57 imirkin: specing: 'sensors'
15:57 specing: perfect
15:57 specing: 73'C
15:57 specing: not perfect
15:57 imirkin: hehe
15:58 specing: Y U SO HOT !?!?!
15:58 imirkin: it probably doesn't have a dedicated fan
15:59 joi: Omar007: can you redo the trace with --mmt-ioctl-create-fuzzer=1 ?
15:59 specing: imirkin: its a laptop, so no
16:00 Omar007: joi sure 1 one moment pls
16:02 Omar007: Joi, it does not like that
16:02 Omar007: X Error of failed request: BadValue (integer parameter out of range for operation)
16:02 Omar007: Major opcode of failed request: 154 (GLX)
16:02 Omar007: Minor opcode of failed request: 3 (X_GLXCreateContext)
16:02 Omar007: Value in failed request: 0x0
16:02 Omar007: Serial number of failed request: 29
16:02 Omar007: Current serial number in output stream: 30
16:02 joi: ok, try --mmt-ioctl-create-fuzzer=2
16:03 Omar007: joi: http://expirebox.com/download/9fefc549fcc5ca3b65a358e995ac5fe9.html
16:05 joi: thanks
16:17 joi: there are multiple issues with this trace, so it might take some time
17:29 joi: ok, fixed
17:31 imirkin: nice, thanks :)
17:34 joi: Omar007: just to be sure everything is correct, can you do one more trace with updated mmt? (without --mmt-ioctl-create-fuzzer=)
17:42 Omar007: Sure
17:42 Omar007: moment pls
17:51 Omar007: joi: http://expirebox.com/download/b05b29563307de8b760416dfd6223859.html
17:52 Omar007: Wait.. Did I need to use another branch no?
17:52 Omar007: *now
17:53 joi: no, the same
17:53 joi: the trace is fine, thanks
17:53 Omar007: :)
19:09 voxadam: I recently built a custom kernel for my workstation and switch back to Nouveau from Nvidia's proprietary driver. I almost immediately started seeing graphics lockups, the mouse would continue responding but nothing would respond to clicks. The system would also continue running, I could SSH in without issue.
19:09 voxadam: I remembered something about a nouveau.config option that I had been encouraged to try by someone here.
19:10 voxadam: A little searching of my IRC logs I found it was nouveau.config=PCE1=0. I just added that to my parameters list and so far things look good.
19:12 voxadam: What I'm wondering is why it's still needed. Some searching around indicates that a bit more than a year ago patch commit 226d63a1addea8cbe8fc671978e62dc84927b046 removed support for the second copy engine on GF116 cards.
19:31 voxadam: Looking at Nouveau in Linus's tree it would seem that nvc0.c was removed entirely at some point.
19:40 voxadam: Hmmm.... it looks like Ben Skeggs (airlied) may have refactored things sometime ago.
19:40 tibbs: Ben Skeggs and airlied are two different people....
19:40 voxadam: Oops.
19:41 voxadam: I'm not sure how I made that mistake. skeggsb is what I should have said.
19:43 voxadam: The Nouveau code is totally unfamiliar to me but I can't find any mention of copy1/PCE1 being disabled on GF116 adapters in the current code.
19:45 voxadam: Maybe I should simply invest in a newer, more powerful card.