00:25karolherbst: sin * 0.5 + 0.5
00:25karolherbst: output should be in [0;1] right?
01:24iterati: Hi, so I use nouveau and it seems I can't start games like dota... it reports that it doesn't support opengl 3.1 Very strange.... also I can't switch to another console. Changed from the nvidia blob, I suppose missed some kernel options...
01:24sarnex: iterati: if you compiled mesa yourself you need --enable-texture-float also
01:25sarnex: and mesa only supports a compat profile of 3.0 maybe thats what its checking
01:27iterati: sarnex: thanks... OpenGL version string: 2.1 Mesa 11.2.2 is this normal ?
01:27sarnex: iterati: can you pastebin entire glxinfo
01:27sarnex: 2.1 sounds like you need texture-float
01:29iterati: sarnex: http://pastebin.com/5RUZP9dY
01:30iterati: fro the console switch issue, what it can be ? something with kms ?
01:30sarnex: iterati: not sure about the console, can you send dmesg
01:31sarnex: but yeah it looks like you need mesa with --enable-texture-float or if on gentoo -bindist
01:32sarnex: card supports up to 4.5 it seems, but mesa is only up to 4.3(?) on nouveau
01:33iterati: nvidiafb: unknown NV_ARCH
01:33iterati: this ?
01:33iterati: yeah, should be fine.. it only needs 3.1 or 3.3
01:33sarnex: no idea what that means
01:33sarnex: what distro are you on
01:34sarnex: can you pastebin equery u mesa
01:35sarnex: yeah as i thought
01:35iterati: it's bindist all right
01:35sarnex: so setting -bindist will fix opengl version
01:35sarnex: but i dont know about the vt switching
01:36iterati: vaapi is good idea or better without ?
01:36sarnex: vaapi is best on intel i believe, gallium drivers should use vdpau
01:36sarnex: but there is a vaapi-to-vdpau wrapper
01:36sarnex: so maybe vaapi is ok, if something supports vaapi but not vdpau you can still hwdec
01:37iterati: it's the issue with s3tc I guess ?
01:37iterati: about the opengl
01:38iterati: dmesg output
01:38sarnex: im not sure if s3tc is related to the texture float patents
01:38sarnex: i dont see anything sorry
01:41shabang_inc: talking about dmesg... anyone have a clue why I get a "DRM panic" when on noveau?
01:45iterati: the driver is crashing ?
01:45iterati: also how to use dri3 ? Is it possible with nouveau ?
01:47sarnex: iterati: yes set Option "DRI" "3" in your nouveau.conf
01:47sarnex: it might be default now through
01:47sarnex: send output of LIBGL_DEBUG=verbose glxears
01:48iterati: I have it: Option "DRI3"
01:48iterati: I guess wrong ?
01:48sarnex: thats a legacy option
01:48sarnex: it may or may not still work
01:48sarnex: it still works with radeon, Option "DRI" "3" is the official
01:49iterati: (WW) NOUVEAU(0): Option "DRI3" is not used
01:49iterati: yeah either it doesn't work or something is amiss :P
01:51iterati: I wonder if I have some nvidia leftovers also.. during boot first the console was low res and after that the screen went on & off 3-4 times
02:30iterati: sarnex: mesa without bindist did the trick... also I had framebuffer set as module, maybe that was the issue with the console
02:31iterati: it's doable to switch the clock based on perfomance, btw ?
02:32iterati: or for now just manually ?
02:33iterati: with the upstream I was unable to change the clock altogether, it was giving error raising voltage etc. With the patch: https://github.com/karolherbst/nouveau/tree/stable_reclocking_kepler_v5 it's ok
02:35sarnex: im not sure if it's automatic or if you have to cat pstate still
02:35sarnex: my guess is you have to cat pstate
03:08iterati: I receive a lot dmesg like "nouveau 0000:01:00.0: DRM: skipped size 0"... I searched the web, it appears it does that when you have vdpau enabled and watch some video
04:39imirkin: hakzsam: please check the patch i sent to mesa-dev for your GF119 situation. hopefully that fixes it. although that doesn't explain why non-32-sized results were messed up =/
04:40imirkin: oh wait. the 28 thing makes sense: nvc0_program_translate:594 - shader translation failed: -4
04:40imirkin: same with 29/30
06:01pmoreau: iterati: To use DRI 3 with Nouveau, the syntax is `Option "DRI" "3"`. See `man nouveau`.
06:03gnurou: RSpliet: thanks, let me check that!
06:04pmoreau: iterati: With 4.5+, nouveau.pstate has been removed, and the pstate file has been moved to debugfs: `/sys/kernel/debug/dri/X/pstate`, where X should be the same number as what you used in the old path `/sys/class/drm/cardX/device/pstate`.
06:08iterati: pmoreau: yeah, I achieved those. The issue know is that it outputs a lot of msgs "nouveau 0000:01:00.0: DRM: skipped size 0" when I attempt to play a video using vdpau with mpv
06:08pmoreau: iterati: And you could blacklist nvidiafb to prevent it from being used. The kernel should default to efifb or another one until nouveau takes over. nvidiafb seems quite old
06:11pmoreau: I have never tried using vdpau, and can’t help much. But, have you extracted the needed firmwares? (See https://nouveau.freedesktop.org/wiki/VideoAcceleration/)
06:12iterati: yep, it utilizes it anyway
06:12iterati: not sure if it's a player issue or driver... see: https://github.com/mpv-player/mpv/issues/2798
06:39pmoreau: imirkin: It probably works with `s32 * s64 + s32`, or similar, except that I am not properly aligning my memory accesses… :-D
06:40pmoreau: Since for now I have been putting them linearly and tightly, and ended up with: 64bit at c0[0x0], 32bit at c0[0x8] (so far so good), but then 64bit at c0[0xc] and 64bit at c0[0x14] :-/
06:57pmoreau: hakzsam: Is there any alignment done when pushing the kernel args to the GPU?
07:07pmoreau: Hum, maybe it should be/is done inside clover?
07:54hakzsam: imirkin, I guess this "glsl/images: bounds check image unit assignment" should also fix arb_shader_image_load_store-dynamically or something
07:54hakzsam: pmoreau, it's aligned to 256 IIRC
07:55pmoreau: I'm not talking about the whole CB storing the arguments, but rather of each argument. I doubt each of them is aligned to 256… ;-)
07:57hakzsam: pmoreau, so, no
07:58pmoreau: I guess clover takes care of it
08:00hakzsam: have a look at clover to be sure ;)
08:04pmoreau: Yeah, will do that tonight
08:04pmoreau: Trying to get rid of undesirable carries in my split patch
10:56karolherbst: we don't do loop unrolling, do we?
12:39kbingham: skeggsb: I'm getting a kernel oops on my hp-envy development laptop running ubuntu-15.10, and linux-4.2.0-36-generic kernel. I've enabled kdumps to get the panic log out, and it appears to be oopsing from gk104_fifo_intr. (http://paste.ubuntu.com/16862939/)
12:40kbingham: Google doesn't show anyone else getting anything like this yet, but I was wondering if you think it could be related to the issue you fixed in (drm/nouveau/fifo/gk104: fix race condition when updating engine runlists : 386ffd5e80d54fd6ecca0a81fc50abc97aeee73f)
12:41kbingham: I'm going to update to 16.04, and if it happens again, I'll file a bug-report, but was just wondering if it's a known issue.
12:48RSpliet: kbingham: this is not the right place for distribution-specific support. I don't know what this "16.04" will bring you, but make sure to test your machine with a kernel 4.6
12:50kbingham: RSpliet: Looks like ubuntu 16.04 is only on 4.4 kernel.
12:50RSpliet: if your problem isn't solved, try updating all the way to 4.6
12:53RSpliet: the nouveau dev team is too "under-staffed" to try and chase potentially solved bugs. I'm sure there's people in the Ubuntu community that can help you with upgrading to a 4.6 kernel (even if by means of compiling it yourself... but there's bound to be some packages lying around somewhere on the internet)
12:53kbingham: RSpliet: I can compile a kernel or two ;)
12:54kbingham: I was just as interested in tracking down the bug though.
12:55kbingham: As a kernel dev, experiencing a kernel panic on my dev machine is somewhat frustrating :)
12:55RSpliet: oh I fully understand, but the GPU driver world is moving faster than the Japanese bullet train
12:56RSpliet: I can't recall which fixes made it into kernels prior to 4.6 anymore, let alone their symptoms :-)
12:56kbingham: RSpliet: certainly understand that :)
12:57RSpliet: skeggsb might have a better memory, but either way it's better to look forward rather than backwards - hence we always ask people to try an up-to-date software stack
12:57karolherbst: RSpliet: maybe we could provide kernel trees with backported nouveau for the last 2-3 releases or something
12:57RSpliet: karolherbst: if people are interested in backporting fixes to LTS releases that'd be grand, but it needs to be coordinated
12:57karolherbst: I do it for myself anyways (well current kernel and sometimes current-1)
12:58karolherbst: RSpliet: I meant just skeggsb nouveau tree rebased on older drm-next commits ;)
12:58RSpliet: skeggsb is not going to have any spare time for things like eating, sleeping, showering or maintaining older drm-next trees until display and upload works on Pascal ;-)
12:59karolherbst: right :D
13:00karolherbst: well I could do it, but sadly it is a bit messy to automate things, because there are always stupid conflicts
13:01RSpliet: backporting is an art of cherry-picking
13:02karolherbst: I know, but this is something others would have to do :D, well we could always send trivial patches to stable kernels, but that's sometimes done already
13:02RSpliet: if someone is up for making that their responsibility, raise hands
13:03RSpliet:goes back to reading on blocking analysis of spin-locks in autosar
13:35imirkin: kbingham: quite likely to be fixed by those various race condition fixes, yes
15:23karolherbst: hakzsam: what GPUs are currently in reator?
15:24hakzsam: gk110 and gf119
15:26karolherbst: ahh okay
15:26karolherbst: when you don't need it anymore, I want to play around with the gk110 :)
15:27hakzsam: karolherbst, I'm done
15:31karolherbst: :) okay
15:32karolherbst: hakzsam: got the connection a bit worse again or is that me?
15:32karolherbst: and with worse I mean a little laggy
15:33karolherbst: I have a 0.4s input latency somehow
15:33karolherbst: ohh that's me
15:34karolherbst: 300ms ping to google. the hell
15:40karolherbst: hakzsam: reator is still based upon the 4.5 drm stuff or something between 4.6 and 4.5?
15:43hakzsam: no idea
15:44karolherbst: seems to be current drm-next now... or whatever skeggsb rebased on
15:49karolherbst: yeah, "power1: 84.58 W" that's more like it! :D
16:10karolherbst: mupuf: okay, now I read nearly the same value out as nvidia
16:10karolherbst: for odd reasons on low power consumption I got 12W and nvidia printed 13-14W, but on load it was the same :/
16:46karolherbst: Tom^: if you want, could you test this patch for reading out the power consumption? https://github.com/karolherbst/nouveau/commit/2efd5755dd8d57342bb67c964c7bac6f235bc75d
16:48imirkin_: RSpliet: just looked at your fuc fixes branch - impressive - sounds like you spent some time to really understand the logic :)
17:56RSpliet: imirkin: thanks. I had some time to do so in the light of my academic research
18:03karolherbst: RSpliet: can we dump like every falcon?
18:03karolherbst: the stack I mean
18:03karolherbst: RSpliet: maybe the dump stack thing could be generalized a bit and used for every falcon
18:18RSpliet: the stack dump can probably be generalised, but you'd have to be sure that there is mutual access to the data window registers
18:21mupuf: karolherbst: cool, you got a patch!
18:22RSpliet: I don't know which falcons expose the sp and pc though
18:22RSpliet: they seemed to have stopped doing so since 2nd gen Kepler (or started hiding them somewhere else)
18:23imirkin_: RSpliet: i have a GK208 at home, let me know if you want me to go hunting
18:24mupuf: karolherbst: nvidia changes the polling frequency when on the lowest perf level
18:24mupuf: from 10 to 1 Hz
18:25RSpliet: imirkin_: I have a 2nd gen kepler in the lab as well, sure I can nick it when I find time to push this forward
18:25karolherbst: mupuf: yeah, I noticed
18:25karolherbst: mupuf: on load I hardly get a value read out
18:28karolherbst: mupuf: as I understand stuff, there shouldn't be a second rail for the same power sensor at all, because otherwise the config would crash with the other rail, but it also explains a lot of things now and feels more right
18:28mupuf: ok, I should have a look
18:34karolherbst: mupuf: thanks (the nouveau patch looks less ugly than the envytools thing)
18:35mupuf: I will have a look, but first, I want to spend some time on the patch to fix imirkin's issue
18:35mupuf: the sun is messing up my system here
18:35mupuf: ~4h of "darkness" is really difficult for me :s
18:36karolherbst: well I have here rather long days too, but not that long :p
18:38Yury: hi guys , anybody here right now, with deep knowledge of driver? ))
18:38Yury: I have blank screen in X with nouveau , only there are no errors
18:39karolherbst: mupuf: ohh well 1:50 hours difference is quite something though in daylout (17:05 hours for me, 18:55 for you)
18:39mupuf: karolherbst: does not work like this
18:39Yury: yep - black and menu button doesn't produce menu... no errors (EE) in Xorg.log
18:39karolherbst: mupuf: yeah I know
18:39mupuf: the sun is never really out
18:40mupuf: sure-enough, the official time you can see the sun is pretty late
18:40mupuf: but it is never too far down
18:40karolherbst: mhh, well for me the sun is like 2 hours gone
18:40Yury: nouveau is from slackware-current, something around 2015-12-16 I think, Nvidia is GT610
18:40imirkin_: Yury: pastebin dmesg an xorg logs
18:40Yury: ..text consoles work
18:41imirkin_: Yury: fyi X defaults to showing black when nothing runs... are you sure you have a DM or something that starts when X starts?
18:42karolherbst: mupuf: well in any case, it is already much worse than anything in france here :p
18:42mupuf: yeah, must be :D
18:42Yury: I switched from proprietary.. just a moment, looking at pastebin interface
18:43imirkin_: well you have a GF108, that should be quite well supported, at least in terms of displaying stuff on the screen
18:44Yury: dmesg is at http://pastebin.com/d8ifay0b
18:45karolherbst: mupuf: compard to paris, hamburg is like 520km more north and helsinki hamburg is another 720km ;)
18:46Yury: xorg.log is at http://pastebin.com/stQA6T4v
18:46mupuf: karolherbst: I grew up next to spain :D
18:46imirkin_: Yury: you do not have a GT 610
18:47Yury: and what do I have?
18:47karolherbst: mupuf: then it is more like 1100km ;)
18:47imirkin_: most often marketed as a GeForce 9300 GS or 8400 GS
18:47imirkin_: it's a G98 gpu
18:47imirkin_: [which should also be supported just fine... but just sayin']
18:48Yury: it had more power than onboard Geforce 6150, tha much I know ))
18:48imirkin_: RSpliet: nouveau 0000:02:00.0: devinit: unable to compute acceptable pll values + nouveau 0000:02:00.0: devinit: failed pll calculation
18:48karolherbst: mupuf: but in june it is really bright the entire night except those two hours without the sun. and if you aren't carefull the sun is back up at like 4am
18:49imirkin_: Yury: that it does.
18:49mupuf: ah ah, it is already up at 3am now
18:49Yury: So about that pll calculation?..
18:49imirkin_: Yury: and it has dvi that nouveau can drive, unlike the 6150SE
18:49karolherbst: mupuf: yeah, as I said around 2 hours difference ;)
18:50Yury: ..anything I can do here?..
18:50imirkin_: Yury: i believe your proximate issue is that you have insufficiently uninstalled the nvidia driver
18:50imirkin_: [ 433.507] (II) Loading /usr/lib64/xorg/modules/extensions/libglx.so
18:50imirkin_: [ 433.627] (II) Module glx: vendor="NVIDIA Corporation"
18:50imirkin_: i'm suspecting that you're using some modern desktop which totally dies without GLX
18:50imirkin_: make sure you're using the libglx.so that shipped with xorg, and it should work fine
18:50imirkin_: (or at least better)
18:51karolherbst: can only be unity :D
18:51karolherbst: or gnome
18:51Yury: I believe I have it stamped out already... and Windowmaker isn't GLX-sensitive
18:51imirkin_: Yury: WM isn't, but is gdm which you use to log in?
18:52imirkin_: Yury: anyways, your xorg log says that you have the wrong libglx installed
18:52Yury: XDM is what I use... anyway, there was that same blank screen...
18:52Yury: ...I just didn't save the more recent set of logs...
18:52imirkin_: can i see a log with that fixed?
18:53imirkin_: and you really use the original xdm? does xdm show up ok?
18:53Yury: Of course. Like twenty minutes for that settings trip I think.
18:53Yury: I started with startx by the way
18:53imirkin_: ah ok
18:53imirkin_: can you check your .xsession-errors then?
18:53imirkin_: i really think this is a PEBKAC situation
18:54Yury: everything overwritten, am using vesa right now
18:54Yury: will get back ASAP with fresh logs
18:54Yury: bye for now, thanks
18:58dcomp: Pump activated for the
19:01RSpliet: imirkin_: I don't know why a PLL would be calculated on a G98 during devinit
19:01RSpliet: can we verify that it's not display-related?
19:02imirkin_: could be display-related
19:03RSpliet: oh it's part of the BIOS script stuff... maybe the VBIOS could provide some clues
19:04RSpliet: ... in case Yury comes back
19:16Yury: imirkin_: ok, back
19:17vita_cell: how good works gt730 gddr5 in GNU/linux with nouveau?
19:17Yury: xorg.log with no xorg.conf is at http://pastebin.com/hijjg1Gn (have also with xorg.conf) ; modes are logged after switching to text console (and back?)
19:18imirkin_: ok, glx seems happier
19:18imirkin_: Yury: i assume still having the same issues?
19:19imirkin_: and can you confirm that you have a 1680x1050 screen hooked up over VGA?
19:19Yury: it was working with nvidia proprietary driver yet today ))
19:19Yury: txt consoles work
19:20imirkin_: yeah... the interesting part is there's no real distinction between a "text" console and X
19:20karolherbst: vita_cell: kepler or fermi?
19:20vita_cell: I dont know
19:20Yury: yess.... BTW, only i have to put video=640x480 in kernel lilo.conf line
19:20karolherbst: vita_cell: ohh gddr5 should be kepler
19:20vita_cell: this is the question
19:20karolherbst: vita_cell: gk208 in lspci
19:21vita_cell: I think that it is Kepler
19:21imirkin_: Yury: oh, that could be interesting
19:21imirkin_: Yury: sounds like something goes wrong with the higher resolution
19:21vita_cell: I did not tested it with GNULinux
19:21karolherbst: vita_cell: well, it should be good enough, if you get issues while reclocking you can always use my reclocking patches
19:21Yury: ..couldn't it go 640x480 then?
19:21vita_cell: gddr5 with 64bits
19:21imirkin_: Yury: i note that you have a 59.9MHz and 60.0MHz mode in there... it prefers the 59.9MHz mode. i wonder if you should try the 60.0MHz mode
19:21vita_cell: yeah, thank you karolherbst
19:21imirkin_: that'll require some xorg.conf hackery
19:22Yury: what, modelines again????
19:22vita_cell: I musttr it wih GNULinux
19:22imirkin_: Yury: that's how the world works :) they're supplied in the EDID
19:23Yury: I've forgotten this stuff completely... can I take those from logfile?
19:23imirkin_: you should be able to just say "i want a 60hz mode" or something
19:23imirkin_: i forget the details myself tbh :)
19:23imirkin_: it's a lot easier to manipulate from within X with xrandr
19:23imirkin_: if you have another machine that you can ssh in from
19:23imirkin_: then you can adjust it more directly
19:23Yury: yes, using it right now
19:24imirkin_: i.e. start X
19:24imirkin_: and then do like DISPLAY=:0 xrandr from an ssh session
19:24Yury: ah, I tried that earlier today, it didnt work somehow
19:25Yury: ..had no that 'fake port ' available or something (X11 forwarding is on, I use that from time to time)
19:25Yury: okay, I'll try with modeline now. be back soon I hope
19:26vita_cell: karolherbst the problem I have with gtx770, that in windows that gpu crashes when relaunch any game (AssaultCube, CounterStrikeGO). If I relaunch any game waiting some minutes, (2-3min) it works
19:28vita_cell: gtx770 in GNULinux with Nouveau, never crashes, but it drops much FPS when shooting much, or launch much molotovs, much smoke, it can be from 250fps to 30fps
20:19Yury: well, I'll write something comprehensive tomorrow, I think. For now it seems nouveau.ko (and respective X driver, too?) can't switch the modes well...
20:21Yury: .. on this G98 adapter...
20:22Yury: "text" console uses 640x480x68Hz, 800x600 tries for 26.8/43 combination, 1024x768 for 21.6kHz/27Hz, higher res'es don't work at all ... keyboard works, only screen doesn't ))
20:23Yury: I can start X up to the 640x480 res, but then I can't switch nothing with xrandr -- either blank screen or stroboscoping screen (when tried for 640x480x60)
20:24Yury: ModeLines do not affect this... neither does /etc/fb.modes
20:25Yury: well, that seems to be all for today, bye all )))
22:26karolherbst: vita_cell: ahh you mean in csgo?
22:26karolherbst: vita_cell: I heard the 32bit version of csgo might help here
23:07karolherbst: meh stupid OC ricer guys, upload your damn 1080 vbios :D
23:08skeggsb: i'm not sure it's entirely possible to even get hw yet, nowhere has stock...
23:08karolherbst: there are already some guys modding the hell out of that card :D
23:08karolherbst: and also use a custom vbios
23:09skeggsb: lucky guys
23:09karolherbst: I only want the vbios :D
23:09skeggsb: if there's custom vbios around, can't you use that?
23:10karolherbst: guess what I try to find...
23:10karolherbst: but they don't show their vbios
23:10karolherbst: they just say they use a modded vbios...
23:11karolherbst: well I heard the 1080 has a second flash for the vbios
23:11karolherbst: so that you can flash on the second one ans witch if you messed it up though
23:11imirkin_: i heard it can fly
23:11skeggsb: some motherboards do that, so, it wouldn't shock me greatly
23:12karolherbst: ahh okay
23:12imirkin_: sure looks like it's available on newegg at least...
23:12karolherbst: ohh there are some models with two bios chips on the gpu itself
23:13imirkin_: err wait, no
23:13imirkin_: i got misled by their search results returning random things
23:13karolherbst: I am really disappointed in the OC guys not sharing the file yet... :D
23:17karolherbst: I really want to see the vbios so that I could adjust to differences in my reclocking/sensors patches so that at least those things are already taken care off
23:18karolherbst: or I at least know where we will fail
23:19karolherbst: ina3221 on the 1080
23:19karolherbst: at least no surprises there
23:20karolherbst: 1.8V fixed mem voltage?
23:22RSpliet: 1.8 sounds a bit high
23:22karolherbst: I think that's the overclocked voltage...
23:22karolherbst: I kind of read an article where they phyiscally overclock the card
23:22karolherbst: quite interesting though: https://xdevs.com/guide/pascal_oc/
23:23karolherbst: RSpliet: wanna safe that? https://www.micron.com/resource-details/a3cada97-b50f-46dc-bd2f-40a60a5f09ad
23:24RSpliet: meh, no MR values
23:25karolherbst: can't get them all
23:28karolherbst: skeggsb: by the way I heard you might have access to the vbios ;)
23:32skeggsb: karolherbst: that phoronix article does not speak the truth
23:33karolherbst: who said I was talking about that :p
23:33skeggsb: not sure where else that'd have come from!
23:36imirkin_: does any phoronix article speak the truth?
23:36skeggsb: rarely :P
23:45skeggsb: whoop - vpn disappeared.. so might've missed some messages
23:47karolherbst: skeggsb: I think we have to clean up the memory stuff a bit, maybe, not quite sure. Depends on how much code we can share between gddr5 and gddr5x
23:47imirkin_: good thing there's no gddr5x code
23:48skeggsb: it needs finishing / fixing / cleaning up for sure.. the latter can hold off until we know what the rest will look like :P
23:48RSpliet: that'll come straight after we can use it's PMU
23:48RSpliet: skeggsb: you didn't miss a thing btw, but do double-check the channel logs :-P
23:49skeggsb: i read the backscroll as far as irssi will let me :P
23:49RSpliet: oh I meant the online IRC logs that cbrill publishes :-D
23:51karolherbst: skeggsb: well the biggest change will be that gddr5x has three modes: 1x, 2x and 4x, where the latter is like the real addition to gddr5
23:51karolherbst: and this adds all the same pll insanity we have with gddr5 too
23:58RSpliet: wouldn't be surprised if NVIDIA keeps it in 4x mode always
23:58karolherbst: there is a minimal clock for the 4x mode
23:58karolherbst: and it is quite high