01:22 Yoshimo: does nouveau handle SLI with 2 cards?
01:37 hakzsam: imirkin, I'm interested :)
01:40 hakzsam: imirkin, are you going to implement ARB_shader_image_load_store after ssbo/atomics?
03:43 mupuf: hakzsam: oh dear, image load store is going to be fun :D
03:43 mupuf: at least it was for intel
03:44 hakzsam: mupuf, yep but it's required for GL 4.2 :)
03:46 mupuf: indeed, and it is quite a big part of it!
03:47 mupuf: it is also necessary for compute shaders since, in practice, compute shaders usually require it
03:47 hakzsam: yeah but I guess we can start working on compute shaders without images support
03:49 hakzsam: at least images are already mostly supported on kepler but we need to do it for fermi
03:50 jarnos: This graphics is working poorly, or what do you think yourself? https://youtu.be/jB_UNoxFBOg
03:50 hakzsam: fun :)
03:51 Tom^: jarnos: geforce 4 ? heh thats one old card :p
03:52 hakzsam: jarnos, is that a recent regression?
03:52 jarnos: Tom^, yes, and I have also a GeForce4 MX 420, which sucks really bad by nouveau: http://askubuntu.com/questions/375696/nvidia-geforce4-mx-420-13-10
03:55 jarnos: hakzsam, I have no Idea, I tried the integrated graphics of the old computer after I found out that GeForce4 MX 420 works so poorly by nouveau.
03:57 hakzsam: jarnos, which kernel are you using? is there something in dmesg?
03:58 jarnos: and GeForce4 MX 420 has been working poorly few years by ubuntu, it think as long as ubuntu changed to use nouveau instead of nv.
04:00 jarnos: hakzsam, 3.19.0-25-general (i386) That is ubuntu 14.04.3.
04:01 jarnos: ^generic
04:13 jarnos: Youtube lags more by the MX 420 than by the integrated MX IGP, though. By nouveau MX 420 succeeds to show approximately one frame per second and makes system unresponsive!
04:14 jarnos: That is on 144p video.
04:17 jarnos: I get somewhat faster show rate, if I lower display resolution, which was originally bigger than with the MX IGP.
04:18 jarnos: hakzsam, hard to say, I put the MX 420 back in after seeing the performance by MX IGP.
04:21 jarnos: I wonder why Xorg is taking so much CPU power?
05:00 hakzsam: sorry, I have to go to take my train and my bouncer is dead, see you later guys
05:05 jarnos: These kind of bug reports tend to expire: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/662383, https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/854985
05:06 jarnos: The latter is reported by me. I admit the description should be better as web pages change...
05:06 jarnos: And available Firefox versions, too. I suppose it was Xorg that took a lot of CPU, anyway.
05:16 Tom^: without exaggerating you are one among _very_ few who still use that card for normal desktop usage. so yea it probably wont be the easiest to find a solution for.
05:34 imirkin: Tom^: dunno, gf4 worked fine last time i tried it (not _that_ long ago)
05:34 imirkin: my guess is it's some ubuntu thing
05:47 Tom^: is there any particular reason you keep around such museum HW ;)
05:49 Tom^: you can probably get a refurbished laptop for like 50-100$ thats better. =D
05:50 imirkin: Tom^: it's not for the FPS :)
05:51 imirkin: Tom^: primarily to test nouveau
05:51 Tom^: hm well fair enough
05:52 imirkin: it's a bit anachronistic, but even a NV5 is able to drive my 1920x1200 desktop without issue
05:52 imirkin: (or hm, maybe i was only able to get 1680x1050 out of the NV5... i forget)
06:29 RSpliet: imirkin: does that framebuffer even fit in VRAM? double-buffered?
06:30 imirkin: RSpliet: hm? 1920x1200x4 = 9MB
06:30 imirkin: so... not double-buffered :)
06:31 imirkin: maybe that was the issue?
06:32 RSpliet: gheh, apparently there exist 32MB TNT2 cards
06:33 imirkin: don't think mine is one of them
06:33 imirkin: i have a TNT2 M64
06:33 imirkin: i believe the 64 is in reference to the GART window :)
06:34 RSpliet: 250nm production process... transistors the size of elephants :-D
06:34 imirkin: RSpliet: might be time to go to the zoo again
06:34 imirkin: double-check the size of an elephant :p
06:39 mwk: imirkin: there are 32MB M64s
06:39 mwk: I have a few
06:39 imirkin: hehe ok
06:39 imirkin: pretty sure mine was 16M though
06:40 mwk: matter of fact, I don't have a non-M64 one...
06:40 imirkin: mwk: some day... you'll be able to complete your collection and open The Museum (tm) :)
06:43 Tom^: ugh anything fun i can do with an probook with an intel only :/?
06:43 Tom^: i somehow managed to get a spare laptop with an i3 3310m :P
06:50 Tom^: imirkin: do you live in EU ?
06:50 imirkin: Tom^: not quite.
06:50 Tom^: :(
06:50 imirkin: or rather... quite not. i'm in nyc :)
06:51 imirkin: jarnos: have you tried disabling compositing on ubuntu? and/or not using gnome-shell?
06:52 imirkin: jarnos: i'm aware of some issues for GF2/4 IGP's in how clocks/etc are selected, but the regular cards all work fine afaik
06:53 imirkin: jarnos: pastebin dmesg + xorg log, i can look for anything that looks obviously weird
06:53 jarnos: imirkin, IIRC compositing is disabled in Mythbuntu live session. It uses Xfce, which have its own compositor.
06:57 RSpliet: imirkin: according to wikipedia those M64s are "NV6", is that a real existing thing?
06:57 imirkin: RSpliet: i mean........ there's a 5 in the BOOT0 bitfield
07:29 imirkin: jarnos: perhaps something is foolishly trying to use 3d accel anyways... try moving nouveau_vieux_dri.so out of the way and see if your situation improves.
07:46 jarnos: imirkin, do you also mean about the slowness of GF4 MX420? I have tried about disabling acceleration by boot option "nouveau.noaccel=1", but I am not sure, if it is effective.
07:46 jarnos: imirkin, How do you check it, if acceleration is in use?
07:47 disse: hey guys, after the recent update (1.0.21-1) I'm facing troubles with nouveau. But I was able to see a dmesg output before crashing the Desktop. I'm only able to move my mouse. I'm using the i3 windows manager and archlinux as distro. Here is the output: http://pastebin.com/yqie9wRr
07:47 jarnos: imirkin, glxinfo tells direct renderin: Yes, anyway.
07:48 disse: ah, I forgot, the system crashes after clicking on an image in firefox
07:54 disse: is there some advice to get more information
08:00 pmoreau: disse: Linking the full dmesg and the Xorg.0.log would be great! (But gtg, I'll have a look later.)
08:02 disse: ok
08:05 disse: I will again collect the logs and will paste it here. For that I have to open the image in browser which crashes the system while logs are copied.
08:05 imirkin: jarnos: you should def leave acceleration enabled
08:05 imirkin: jarnos: i was just talking about 3d accel
08:05 imirkin: jarnos: for which you should just move nouveau_vieux_dri.so out of the way
08:05 imirkin: jarnos: but like i said, please include your dmesg + xorg logs
08:12 Tom^: imirkin: you know where unigine valley stores its settings in ~ ?
08:12 jarnos: imirkin, like move nouveau_vieux_dri.so to some other directory and reboot?
08:12 imirkin: jarnos: yeah, or rename it to not_nouveau_vieux_dri.so :)
08:13 imirkin: Tom^: dunno. i use "strace -f -e open" to find such things out
08:18 imirkin: joi: hm, your trace also brings up a Conditional jump or move depends on uninitialised value(s) for me. might be something local to my tree.
08:19 imirkin: yep, it is.
08:20 disse: hey guys, I'm back with logs
08:21 disse: http://pastebin.com/UVGUyC9P
08:21 disse: Xorg.0.log
08:21 Tom^: imirkin: ah yea that worked thanks.
08:22 disse: http://pastebin.com/bckhsP5Y
08:22 disse: dmesg
08:24 imirkin: disse: well, looks like you're loading vesafb first... i'd certainly recommend against that
08:25 imirkin: disse: also what's your secondary GPU driven by modeset?
08:25 imirkin: oh, that's the intel. got it.
08:26 disse: ok
08:27 imirkin: btw, it appears that you're still on nouveau 1.0.11, not 1.0.12. nothing wrong with that, but just fyi.
08:27 disse: hm, where can I reorder the driver loading order? Isn't this a thing of mkinitcpio?
08:28 disse: but why does the pacman (packet manager) log tell me that the update happened?
08:29 disse: http://pastebin.com/UVGUyC9P
08:30 disse: ups
08:30 disse: [2015-12-27 09:26] [ALPM] upgraded xf86-video-nouveau (1.0.11+31+g1ff13a9-1 -> 1.0.12-1)
08:31 disse: ups was because I pasted the wrong
08:31 Tom^: disse: this isnt a partial upgrade then ? , make sure there is nothing todo with -Syu
08:31 imirkin: all i can say is that i see "1.0.11" in the xorg log you pasted
08:32 disse: so maybed something went wrong in the update
08:33 Tom^: "[ 122.560] Current Operating System: Linux viola 4.1.2-2-ARCH #1 SMP PREEMPT Wed Jul 15 08:30:32 UTC 2015 x86_64"
08:34 Tom^: that Xorg.0.log is old
08:35 disse: oh
08:35 disse: damned
08:37 disse: where do I get a newer logfile?
08:37 Tom^: check if ~/.local/share/xorg/Xorg.0.log exists, i dont remember when arch made X start as user perhaps its around then. so you are just posting the pre that change log :P
08:38 disse: aw
08:45 disse: so, after the last freeze I got now an updated Xorg.0.log
08:47 disse: http://pastebin.com/rPwigxh9
08:47 disse: sorry for the inconvienience
08:48 disse: I did not register that the logfile wasn't up to date
08:49 jarnos: imirkin, moving nouveau_vieux_dir.so is not effective as it is reseted after reboot. I am using a persistent USB live system (made by mkusb)
08:49 imirkin: jarnos: ah fun.
08:49 imirkin: jarnos: just restarting X should be sufficient
08:50 jarnos: imirkin, like how? :)
08:50 imirkin: however you normally restart X?
08:50 imirkin: disse: weird, no clue.
08:50 imirkin: disse: all seems fine
08:51 imirkin: disse: you could try bisecting the nouveau ddx git tree to see what caused it... not too many commits
08:51 disse: but the very last 2 lines of dmesg
08:51 imirkin: yeah, those just mean "something weird happened" :)
08:51 imirkin: they're not actionable
08:51 disse: :(
08:52 disse: do you want to try if your nouveau also crashes after the picture?
08:53 jarnos: imirkin, oh I think I was wrong. not_nouveau_vieux_dri.so remains there. locate was just not aware of the change.
08:55 Tom^: disse: is that the only place it crashesh ?
08:55 disse: no
08:55 karolherbst: jarnos: I stopped using locate because I couldn't trust it, ever :D
08:56 disse: but the case I could reproduce
08:56 Tom^: disse: because you could try just disabling hw acceleration in chromium, i simply have it off anyways.
08:56 Tom^: karolherbst: ah good morning.
08:56 imirkin: jarnos: and it's still slow?
08:56 disse: Tom it was in firefox
08:57 karolherbst: Tom^: :D
08:57 Tom^: disse: firefox has hw acceleration too , but yea ok :/
08:57 disse: but I'll try opening it with different browsers
08:57 disse: good idea
08:57 disse: ha, there it works fine
09:12 jarnos: imirkin, http://pastebin.com/SMZ6qfyx
09:14 jarnos: imirkin, http://pastebin.com/5TRVt8DS
09:16 imirkin: jarnos: seems happy enough =/
09:17 jarnos: imirkin, Playback by VLC seemded to work fine at 720p. Playback by Adobe Flash plugin in Firefox lagged bad at 144p and almost freezed computer even in not-full-screen. Xorg takes about 50-90% of CPU. 'll be back in 2 hours or so.
09:18 jarnos: imirkin, maybe I have time to give the logs for the IGP device as well sometime.
09:18 imirkin: jarnos: sounds like something flash is doing very oddly
09:18 RSpliet: jarnos: by default flash doesn't use hw acceleration for video decoding
09:19 imirkin: which in turn is greatly upsetting ... something
09:19 Tom^: well now, it all depends on what kind of cpu is in this machine
09:19 RSpliet: oh, NV17... heh
09:19 imirkin: RSpliet: well, the only accel he can get is mpeg2 xvmc, and i haven't implemented a libXvMCW helper lib that'll drive the VPE1 engine
09:19 RSpliet:silently backs off again
09:19 imirkin: and i'm sure vlc doesn't support it
09:20 jarnos: imirkin, also some volume level sliders took huge CPU in pavucontrol IIRC.
09:20 Tom^: he might be on a 1.3 ghz p4 , and rendering flash on that wont be fun :P
09:20 imirkin: or a p3-550 :)
09:21 RSpliet: still, flash does weird stuff with video buffers they always defended in the interest of drawing over a decoded video
09:21 jarnos: amd athlon xp something over 1 GHz
09:22 Tom^: heh
09:22 jarnos: But as you may see from the linked youtube video above, it runs smoother by the integrated graphics that I suppose is less powerful.
09:23 jarnos: I mean this https://youtu.be/jB_UNoxFBOg
09:23 jarnos: More than 1 frame / sec :)
09:24 Tom^: is it the browser hw acceleration spooking with you? like it perhaps starts using software rendering for its hw acceleration. :P
09:24 jarnos: 144p quality
09:24 karolherbst: yeah I would also say that sounds like sw decoding, but
09:24 karolherbst: jarnos: are you sure the video you play _can_ be hw accelerated decoded by your gpu?
09:24 karolherbst: often flash video contain mp4 data these days
09:25 karolherbst: especially on youtube these is the case
09:25 jarnos: karolherbst, no
09:25 Tom^: karolherbst: he is running on a geforce 4 :p
09:25 karolherbst: *this
09:25 karolherbst: yeah well
09:25 karolherbst: I doubt the hardware can handle that at all
09:25 karolherbst: I am 100% sure youtube deals with mpeg-4 videos
09:25 Tom^: jarnos: but yea disable hw acceleration in firefox
09:26 jarnos: karolherbst, nowadays its also VP8, VP9...
09:26 karolherbst: well
09:26 karolherbst: then it is even more unlikely your gpu can decode that
09:27 jarnos: karolherbst, but it is bad performance even if it is sw decoding.
09:27 karolherbst: jarnos: mpeg-4 is really heavy
09:27 karolherbst: jarnos: what cpu do you have?
09:27 RSpliet: Athlon XP 2400+, should be able to do 360p MPEG4
09:27 karolherbst: mhhh well mpeg-4 in general not so much, but h.264 is heavy
09:28 karolherbst: RSpliet: yeah, right
09:28 Tom^: RSpliet: *should* keep in mind it has to render X and some other stuff to right no :P
09:28 RSpliet: Tom^: no I'm speaking from experience
09:28 karolherbst: could be a lot of browser overhead though
09:28 Tom^: RSpliet: yea but he is running on swrast atm to limit out issues. =D
09:28 karolherbst: jarnos: could you try to download the video?
09:28 RSpliet: used to have a 2800+ doing 480p youtube videos
09:29 karolherbst: or did you do that already?
09:29 jarnos: Athlon XP 1600MHz, I think it could handle 144p, but not even close with nouveau
09:30 karolherbst: RSpliet: but the high cpu load tells us that the cpu is pretty much under load :D
09:30 Tom^: jarnos: the gpu shouldnt matter at all on flash, because its going to render on the cpu no matter what.
09:30 karolherbst: Tom^: well...
09:30 karolherbst: Tom^: guess who is displaying all the stuff
09:30 karolherbst: when the CPU is under heavy load decoding, even X won't get much anymore
09:30 RSpliet: Tom^: false, you can make Flash do *some* GPU accel (even VDPAU)
09:30 karolherbst: especially on single core machines this _is_ a problem
09:31 karolherbst: RSpliet: ohh I didn't know that either
09:31 RSpliet: not on NV17 obviously
09:31 Tom^: RSpliet: sure you *can* but its not even close to stable nor do i suspect it works at all on geforce 4
09:32 Tom^: not that its vdpau's fault or nouveau for not being stable, its just flash being flash. :P
09:32 karolherbst: idea!
09:32 RSpliet: Tom^: the flash part is stable, if we work out the nouveau mpeg4 issues it works fine on G80+
09:32 karolherbst: jarnos: https://www.youtube.com/html5
09:32 karolherbst: did you enable the html5 player here?
09:32 Tom^: RSpliet: even the blob crashes, enable gpu acceleration , open and close a few flash movies in a few different tabs and it will crash.
09:32 karolherbst: ohh wait
09:32 karolherbst: it is on by default now?
09:32 imirkin: mpeg4 is G98+. h264 is G84+.
09:33 RSpliet: imirkin: but... NV17 should be able to benefit from Xv, right?
09:34 imirkin: should, but someone was lazy
09:34 imirkin: i remedied half of that laziness
09:34 imirkin: but it turns out that i am also lazy
09:34 RSpliet: either everyone was lazy, or one person isn't :-P
09:35 imirkin: https://trello.com/c/begolWDd/3-add-xv-overlay-support-using-drm-planes-for-nv04-nv40
09:35 imirkin: so i solved *that* problem :)
09:35 imirkin: but hey, at least i added drm plane support to the nouveau kernel driver
09:36 RSpliet: ah hehe, okay
09:36 imirkin: it all used to work of course
09:36 imirkin: pre-drm days
09:36 imirkin: but then it got dropped in the drm shuffle
09:37 RSpliet: then I guess this is all flash can squeeze out of the NV17
09:38 imirkin: i feel bad for not finishing up the ddx bits
09:38 imirkin: but... not bad enough to finish them :)
09:39 RSpliet: if I felt bad for everything I didn't do
09:40 RSpliet: that'd be a depression so big you'd think it's fabricated in 250nm
09:40 imirkin: harsh
09:40 imirkin: i even started on it
09:40 imirkin: but... ugh
12:12 jarnos: karolherbst, yes, even Firefox uses HTML5-player by default, but there it seems to play AVC rather than VP9.
12:14 karolherbst: jarnos: uhh yes AVC might really be a bit much for your cpu :/
12:14 karolherbst: but as it seems there can be some sort of hw accell
12:18 jarnos: karolherbst, you can't choose Flash in the youtube.com/html5 page anymore in Firefox.
12:19 karolherbst: jarnos: well it doesn't change anything because you will get the same videos through flash
12:20 karolherbst: same encoding and everything
12:29 linkmauve1: jarnos, if you just want to watch the video, maybe use mpv’s youtube-dl integration.
12:29 linkmauve1: Or youtube-dl alone, with another video player.
12:29 jarnos: karolherbst, according to some people's experience HTML5 player consumes more resources (CPU, RAM), though. There is an extension to enable Flash player in youtube: YouTube Flash Player, but it doesn't seem to work anymore probably due to changes in Youtube.
12:30 karolherbst: yeah well, I am sure that's not true though
12:31 karolherbst: cause flash needs here 500MB :D
12:31 karolherbst: RAM
12:31 karolherbst: and this is 33% of the entire memory consumption of chromium
12:32 jarnos: karolherbst, Firefox uses an older version for Flash.
12:33 karolherbst: the more reason not to use flash on firefox
12:33 karolherbst: does firefox does extension sandboxing by now with flash?
12:35 jarnos: karolherbst, I don't know, but when I tried to use youtube when the YouTube Flash Player extension was enabled, it crashed Firefox.
12:50 jarnos: Now I found what make playback so sluggish: scaling. If I have 480p youtube in 480p window, it performs much better than 144p video!
12:58 karolherbst: :O
12:58 karolherbst: what about fullscreen?
12:58 karolherbst: well it makes somehow sense though
12:59 karolherbst: upscaling algorithms are pretty smart these days
12:59 karolherbst: jarnos: could you also try out 720p in the big player?
12:59 karolherbst: maybe this also kind of performs well
13:13 jarnos: karolherbst, when the player window is 720p, 720p video plays with somewhat better frame rate than 144p video. They both are far from smooth, though.
13:13 karolherbst: okay, but 720p does work in theory
13:13 karolherbst: it isn't just not nice enough to watch
13:19 jarnos: karolherbst, best works 360p video in 360p window. 720p with fps something like 3 can not be called video.
13:19 karolherbst: ohh
13:19 karolherbst: k
13:20 karolherbst: and 720p in a 720p window is also not good?
13:22 jarnos: karolherbst, effective frame rate is so low that it is not nice to watch.
13:22 karolherbst: jarnos: but I would assume that 360p ind a 360p window doesn't reach 24fps too then?
13:28 jarnos: karolherbst, it should be 25fps or it depend on video, I guess. The "stats for nerds" tells there are no dropped frames, but my eyes tell there are some, and some times quite a few, when it "looses it".
13:30 karolherbst: jarnos: mhh does the video play more nicely when you choose a lower display resolution?
13:31 jarnos: karolherbst, do you mean the 360p video?
13:32 karolherbst: yeah
13:43 jarnos: karolherbst, maybe a little more nicely, if I have a matching player window resolution.
13:48 jarnos: karolherbst, and I think fullscreen playback works better, when there are less pixels to draw. But if the player window does not match the video resolution, frame rate is never acceptable.
13:49 karolherbst: mhhh okay
13:50 karolherbst: I assume you have high cpu loads in either case
13:59 jarnos: They say the they have fixed scaling issue years ago, but maybe it has reappeared or the fixing was for Windows only: https://bugzilla.mozilla.org/show_bug.cgi?id=577843
14:07 imirkin_: karolherbst: btw, i finally pushed that patch to get rid of the leftover add foo, 0 from the mad optimization
14:07 imirkin_: karolherbst: helped a grand total of 57 shaders by 1 instructions in my shaderdb :)
14:16 karolherbst: :)
14:17 karolherbst: yay
14:21 jarnos: karolherbst, 360p on 360p, when it plays smooth; top tells CPU load: 65% firefox , 20% xorg, 4% pulseaudio
14:23 karolherbst: imirkin_: who does use GL_ARB_shader_draw_parameters?
14:23 imirkin_: karolherbst: piglit tests
14:23 karolherbst: right
14:23 imirkin_: i assume no one for real
14:24 karolherbst: well somebody felt it was right to have such an extension though
14:24 imirkin_: sure, it could be useful
14:24 imirkin_: but i barely get when ARB_draw_indirect is useful
14:24 imirkin_: and this is basically a way to retrieve those indirect parameters in the draw itself
14:25 imirkin_: mostly, i'm guessing, for the draw id in a multi indirect draw situation
14:28 karolherbst: imirkin_: ohh it seems like this extension can be used to tweak engine performance a bit :O
14:29 imirkin_: yeah maybe who knows
14:29 glennk: looks like gcn but not evergreen can do that extension
14:32 imirkin_: i certainly wasn't doing it for any sort of perf reasons
14:32 imirkin_: it was there and it was easy
14:34 imirkin_: i'm gonna look at doing multi_draw_indirect for real, and that indirect params thing
14:34 imirkin_: that will be nice.
14:34 imirkin_: and potentially actually useful
14:34 imirkin_: esp once compute shaders become a thing
14:35 glennk: heh, have to do a trivial kernel patch to support multidrawindirect, err, directly, for evergreen
14:35 imirkin_: glennk: should get that going
14:36 glennk: eh, bigger fires around
14:37 imirkin_: the fact that multi_draw_indirect is fake is just really bugging me
14:37 imirkin_: for no real rational reason
14:38 imirkin_: it'll be more macro hacking for me to get it going but... wtvr
14:38 glennk: i'd wait until i stumble on something that is limited by the lack of that
15:42 karolherbst: imirkin_: bioshock seems to use ARB_shader_draw_parameters :O
15:43 imirkin_: karolherbst: effectively?
15:43 karolherbst: no idea
15:43 imirkin_: karolherbst: how can you tell btw?
15:43 imirkin_: i.e. is it _actually_ using them?
15:43 karolherbst: no idea, I just now it is referenced
15:44 karolherbst: but some checking told me, that ARB_shader_draw_parameters can be used to reduce some CPU overhead
15:44 karolherbst: no idea if thats true
15:44 karolherbst: it is a OpenGL 5 candidate so it might make sense
15:46 karolherbst: imirkin_: I will do a benchmark with that ext enabled and disabled and check what really changes
15:46 karolherbst: or I could do an apitrace :D