04:42karolherbst: mupuf_: what would you think about adding rootless X support for reator, so that everybody can have their own user account?
04:44karolherbst: ohh that was easy to get ready :O
04:44karolherbst: I have it working locally now
05:49fairc: I cannot acces the matrix anymore: xorg.freedesktop.org/wiki/RadeonFeature/ is this only me?
05:50fairc: oops wrong channel
05:51fairc: however, I have another question: I have an old 9800 gtx+, what (if) for options do I have to underclock this thing?
05:51fairc: (its running on nouveau obviously)
05:55karolherbst: fairc: there are some problems with the fdo website, for whatever reasons, it works for some and for some not
05:55karolherbst: for me it doesn't work either
05:58sdfgdgd: just loaded for me
06:00fairc: where are you located? I'm in germany
06:00karolherbst: I am also in germany, but I am kind of routed throug telefonica
06:01karolherbst: I bet they don't like the hosting provider of fdo and are being a bitch
06:01karolherbst: as always
06:01fairc: ^^ +1 indeed
06:03fairc: quote from #freedesktop "teodor is down, running on reduced capacity" or maybe its this?
06:03karolherbst: no, this is unrelated
06:03karolherbst: the packages are just lost somewhere deep down
06:11ravior: Hi, sorry for the interuption, but I was wondering, is there any update for defect 71659 (https://bugs.freedesktop.org/show_bug.cgi?id=71659)?
06:12ravior: If someone is interested in looking into it, is there any way I can help with the debugging / testing process of this issue?
06:14karolherbst: ravior: what is your current kernel?
06:18ravior: karolherbst: The latest stable kernel: 4.4.3-1
06:19karolherbst: and also a nvd9 I assume
06:20ravior: NVIDIA Corporation GF119M [NVS 4200M]
06:22karolherbst: ohh okay
06:23karolherbst: and do you always get the same error message or only sometimes the pfifo thing?
06:23ravior: More or less. The freezes are usually preceded by those messages.
06:24ravior: Sometimes I get multiple error messages before the freeze.
07:04CME: hm, has anyone seen something like this with nouveau and steam (with and without steam runtime)? libGL: dlopen /usr/lib/i386-linux-gnu/dri/nouveau_dri.so failed (/usr/lib/i386-linux-gnu/libdrm_amdgpu.so.1: undefined symbol: drmPrimeHandleToFD
07:05CME: other 32bit opengl applications (like wine) work fine, though
07:07ravior: Nu mai este layer-ul
07:08ravior: If there is any scenario that I can test to get debug info, please tell me.
07:12CME: ah, it works fine with my own build of libdrm, weird
07:16karolherbst: CME: maybe you need to update mesa or libdrm?
07:19CME: karolherbst, yeah, it works fine with mesa master + libdrm master - mesa master + libdrm from debian sid is broken, too
07:19CME: just weird that steam is the only application that fails like that
07:20karolherbst: well there are seperated packages for 32bit usually
07:20cc_: hello people
07:20cc_: so, I've finally bought, received and tried my nvidia graphic card
07:21cc_: y'all little jokers you tried to scare me :D
07:21cc_: it works out-of-the box ! \o/
07:22cc_: no external driver, no nonfree shit to install, nothing !
07:22CME: karolherbst, yep, they are installed, other 32bit opengl applications work fine with mesa + libdrm from sid
07:22cc_: and all my games work great wirth decent perfs \o/
07:22CME: well whatever, it's working now ;)
07:23cc_: you guys are awesome \o/
07:23imirkin: cc_: did you enable reclocking (did you get a kepler?)
07:24karolherbst: cc_: which gpu? :D
07:24cc_: I have a Inno3D GeForce GTX760
07:24cc_: and not even the last kernel, I'm on 4.3
07:24cc_: debian testing
07:25imirkin: if you update to 4.4 you are likely to have working reclocking as well, if you boot with nouveau.pstate=1
07:25imirkin: which will allow you to flip the card into higher perf states
07:25cc_: imirkin: I will wait for it to come into testing ;)
07:26cc_: of course the FPS were not as high as with my radeon, but perfs were decent and everything was fluid
07:26imirkin: as it stands, that "decent perf" is coming from the lowest power state
07:26imirkin: highest pstate is probably 5x faster
07:27cc_: warsow had some trouble displaying one texture or two
07:27imirkin: it didn't crash?
07:27cc_: the texture of the grenade was grey instead of blue
07:27imirkin: warsow 2.0 is supposed to crash
07:27imirkin: unless you force single-threading
07:27cc_: imirkin: it didn't, at least in solo mode
07:27imirkin: maybe they added a workaround if they detect nouveau
07:28cc_: it's the 2.0.1 I have
07:28cc_: or 2.01
07:29AlexAltea: hmm, there's something unclear to me, envytools docs say at the PFIFO Puller section: > Methods 0-0xfc are special and executed by the puller
07:30AlexAltea: Wouldn't these methods overlap with the subchannel 0? At least 0x0000 certainly would
07:30AlexAltea: (talking about nv40-ish gpus)
07:31AlexAltea: I've noticed methods bound to a subchannel usually start from 0x100 or 0x180, so it would only make sense to me if methods 0x4-0xFC were reserved (not 0x0-0xFC as the docs say)
07:31cc_: anyway, thank you to all the devs, I feel free ! \o/
07:32cc_: perhaps even freer than with my radeon which still needs a nonfree firmware
07:33karolherbst: cc_: well if you need more perf I have some patches
07:36cc_: karolherbst: I don't need to increase the perfs right now, I will test the card again with a 4.4+ kernel when it comes into debian ;)
07:36karolherbst: well there shouldn't be perf changes in 4.4 though
07:38karolherbst: only when you reclock to the highest pstate there should be a stability fix
07:38AlexAltea: nvm I'm retarded, heheh
07:43cc_: so, now, do you know any project that aims to liberate VideoBIOSes ? :D
07:44karolherbst: mhh there is really no reason to do that on nvidia gpus
07:45cc_: karolherbst: why ?
07:45karolherbst: the vbios is more like a description of the gpu for the driver to setup things right. There are some scripts there which setup various stuff on the gpu, but there is no native code in there
07:45karolherbst: like the various c and p states are in the vbios
07:45karolherbst: or which voltage to set for each clock
07:45karolherbst: stuff like that
07:45hakzsam: imirkin, actually I have a pretty good ratio of success on gk208 :)
07:45mwk: AlexAltea: 0-0xfc are part of the subchannel
07:45karolherbst: or what port are on the gpu
07:46mwk: every subchannel, in fact, it doesn't matter on what subchannel you submit those
07:46cc_: karolherbst: ok, so it's more like data rather than executable code ?
07:46karolherbst: cc_: there is a tool called nvbios in envytools, which can parse a nvidia vbios
07:46AlexAltea: mwk, so, e.g. 0x0068 would be the same as 0x2068?
07:46karolherbst: it's only data
07:46mwk: here's how it works: 0x4-0xfc are interpreted by PFIFO, 0x100 and up are submitted to the engine, and 0... is both
07:47mwk: AlexAltea: subchannel number is *not part of the method*
07:47AlexAltea: ok, now it makes perfect sense
07:47karolherbst: with scripts which have to be parsed before, but they contain stuff like: write this into mmio reg b, read mmio reg a, write a into mmio reg c, stuff like that
07:47mwk: there is no such thing as method 0x2068
07:47cc_: karolherbst: so when the FSF folks are talking of the vbios issue, they mostly think about AMD and/or Intel ?
07:47karolherbst: mhh well
07:47karolherbst: for video acceleration we need nvidia binaries
07:47mwk: in fact, on Fermi, method numbers are expanded to 0-0x3ffc
07:47AlexAltea: mwk, true, I always forget that (my brain is poisoned by userland driver stuff)
07:47karolherbst: but these are firmware files for co processors on the gpu
07:47AlexAltea: thanks for the info btw
07:48karolherbst: and with 2gen maxwell, we have to use much more of these for other co-processors as well
07:48mwk: so 0x2068 is a valid method on these
07:48karolherbst: cc_: they are called "falcon", but most of the falcons are filled with nouveau files
07:49karolherbst: cc_: for example the pmu (power management unit?) gets its firmware by nouveau devs: https://github.com/skeggsb/nouveau/tree/master/drm/nouveau/nvkm/subdev/pmu/fuc
07:49imirkin: hakzsam: nice
07:49imirkin: hakzsam: btw, i think there's still some state issues somewhere
07:49imirkin: hakzsam: not clear if it's in your code though
07:49karolherbst: cc_: *.fuc are the source code files and *fuc[3-5].h are the blobs which get compiled from the fuc files
07:49hakzsam: imirkin, probably, but it's only the v1 :)
07:49imirkin: hakzsam: i recently added OES_gpu_shader5 support to mesa, and was seeing some odd failures on my fermi when i ran it one-by-one vs all-at-once
07:50imirkin: hakzsam: i highly recommend using the deqp runner instead of the piglit runner btw
07:50karolherbst: cc_: and on gen2 maxwell I doubt we can use any of the nouveau ones, because they have to be signed by nvidia
07:50hakzsam: imirkin, oh okay
07:50imirkin: hakzsam: but there's an issue that it's able to trigger, that i've fixed with https://github.com/imirkin/mesa/commit/3994e1d6c6bc429d7a3958adebb7fbbba93211a7
07:50imirkin: but i need to spend some time thinking whether that's the correct thing to do
07:51imirkin: so i haven't actually pushed it out yet
07:51karolherbst: cc_: well I am sure they also want to have free nvidia vbios files, but we would have a problem there, because we can't simply create such a vbios file on the fly
07:51karolherbst: cc_: because we don't know every nvidia gpu out there ,)
07:51hakzsam: imirkin, mmh okay
07:52imirkin: cc_: the issue the vbios solves is that every board is wired a little differently, and needs slightly different setup. there are probably over 1000 SKU's out there for a given generation, probably 5-10K SKU's if you could every nvidia generation
07:52imirkin: cc_: a vbios "freeing" project, would have to make things work on each and every one of those
07:53imirkin: cc_: that said, the vbios does include code, and it's non-free code.
07:53cc_: imirkin: by every one you mean every model from the different manufacturers ?
07:53karolherbst: imirkin: do you know if the vbios has a licensed attached to it?
07:53imirkin: every revision of every model.
07:53karolherbst: or just default copyright law?
07:53imirkin: karolherbst: not explicitly, which means it's covered by default copyright
07:53imirkin: aka "do not copy"
07:54karolherbst: mhh at least nvidia doesn't seem to care
07:54cc_: imirkin: ok, so it's not nvidia who make the vbios, but the company that makes the card ?
07:54imirkin: cc_: well, i think nvidia makes a tool that helps those companies make vbios's. but yeah, it's the board maker that ultimately puts it together.
07:55karolherbst: cc_: you should really push your vbios through nvbios, just to see what is in there ;) there are still many unknown bits, but these are usually not touched by nouveau
08:02hakzsam: imirkin, all shared+atomics tests work on gk208
08:03hakzsam: (with some minor changes)
10:16karolherbst: hakzsam: need any testing?
10:48hakzsam: karolherbst, no, I'm done
10:48karolherbst: k, nice :)
11:25Jayhost: karolherbst was able to replicate freeze on psp. Trying to valgrind trace what's going on
15:20espen_san: anyone want to start a reddit group for pledging xorg.nvidia open source drivers for mac OS X?
15:43joi: imirkin: https://www.warsow.gg/forum/thread/t/231528, "Changes from 2.0 to 2.01: .... Automatically disable multithreading if Nouveau graphics driver is detected (Linux)."
15:46imirkin: yeah, i suck =/
15:52loonycyborg: you guys plan to do vulkan implementation too? :P
15:54imirkin: might take a while
19:34Jayhost``: Is valgrind-mmt like mmiotrace where you should use it on kernel 3.
22:39Animeking: hey, so how is the 3d performance in the GM206, I acceleration started working a few days ago, I am guessing 100x worse than all the old cards? xD