00:20imirkin: gr. stupid game of whack-a-mole. i fix one thing, another starts failing. GL45-CTS.compute_shader.resource-texture used to pass. now it fails on gk208 at least.
00:21imirkin: aaand of course it's now passing again.
00:30RSpliet: imirkin: pidgin tests make an excellent PRNG
00:31imirkin: i know that was meant to cheer me up, but ... not seeing it :p
02:28dboyan: imirkin, are you there?
02:28imirkin: looking at your bug... very odd.
02:28imirkin: it does work fine on maxwell.
02:34dboyan: That's really strange. I once looked at the mmt trace of the blob driver, and compared it with nouveau, but I was confused by the different handling of compute state.
02:35imirkin: yeah, unfortunately mmt is in a bit of disrepair as far as handling nouveau, and also some of the blob stuff
02:36dboyan: The blob driver uses tsc and tic of 0x310-0x312 as textures of compute program and writes those numbers to the upload data. afaik about nouveau, it's using 0-2 and I don't know how it sets texture bindings for compute programs
02:37dboyan: The content of tsc and tic of nouveau seems all right
02:37imirkin: for kepler+, it's all bindless
02:37imirkin: you upload the tsc/tic descriptors
02:37imirkin: but then you can reference them willy-nilly
02:38imirkin: there is a special CB (designated by the TEX_CB_INDEX) which is read into by the TEX instruction, and will use TSC/TIC values from there
02:38imirkin: [or you can use the other variant, where you supply that value directly, not read out of a CB]
02:39nyef```: So, yay: I managed to obtain the DP->HDMI adaptor that I need, and a PCI soundcard that has an "internal SPDIF" output. No indication as to which of the three pins on the output do what, though.
02:39dboyan: well, that was out of my knowledge. By the way, what is "CB"?
02:39nyef```: Citizens Band? (-:
02:40dboyan: I saw a lot of them in mmt trace
02:40nyef```: (CallBack? Count of Bytes?)
02:41imirkin: dboyan: CB = constbuf (aka uniforms)
02:42imirkin: nyef```: trying to get hdmi audio working reliably on pre-gt215?
02:42nyef```: imirkin: Making sure that I have the equipment to be able to make the attempt.
02:44imirkin: cool. let me know before you start, i may have some suggestions.
02:45nyef```: I suspect that I'll find that the audio infoframe will need to be adjusted based on the format coming from the SPDIF interface, and that the SPDIF interface will have to be told which formats are accessible based on the EDID, and that the mere fact that a system can (probably *will*) have more than one SPDIF interface will screw things up.
02:47nyef```: (And I know that you can do bidirectional communication over a two-wire interface, even if one of them is ground, but I suspect that SPDIF might *not* be doing that, which just makes things more "interesting".)
02:47nyef```: It'll be at least a week before I get started.
02:51dboyan: imirkin, do you remember the "starter project" I mentioned yesterday?
02:51imirkin: i do.
02:52imirkin: dboyan: ok, so ... here's one thing you could do... right now we kinda phone it in for some fp64 precision. would you be interested in fixing some of the accuracy issues there?
02:53dboyan: okay, what exactly are the issues?
02:54imirkin: well, the hardware only computes the top half of a rcp() and rsq()
02:54imirkin: so we need to (a) do newton-raphson steps for those, and (b) sqrt needs to be reimplemented.
02:54imirkin: since 1/rsq isn't really accurate enough for fp64
02:55imirkin: the blob also does some clever range compression things for rsq and rcp, to get the most accuracy possible out of the hw.
02:56nyef```: I suppose that one question is how many newton-raphson steps you need to do?
02:57imirkin: however many the blob does
02:57nyef```: Fair enough, I guess.
02:57imirkin: they know what they're doing. we don't. (at least i don't.)
02:57dboyan: Ah I see.
02:58dboyan: So the main point is to write programs with these operations and observe what the blob do, and try to implement them in codegen?
03:04dboyan: Okay, I'll try to do that the following days
03:05nyef```: Does the concept of a GK104M with DDR5 make sense, or is it more likely to be a GM107M?
03:08dboyan: imirkin, I still have a question, why are there different code path of shared atomic lowering for Kepler and pre-Fermi, i.e. handleSharedATOM and handleSharedATOMNVE4.
03:08dboyan: I bet they do the same things, and the blob generate code like handleSharedATOM (the pre-Fermi path) on my gk208
03:09imirkin: nyef```: GDDR5 should be a thing for both of those.
03:10imirkin: dboyan: the instructions changed... fermi had one way of doing load lock/unlock, kepler has a different way
03:10imirkin: (one that can fail more)
03:10imirkin: the resulting control flow is nasty, and we're not emitting it quite as beautifully as we might
03:10imirkin: but the logic is identical.
03:12nyef```: Damn. So I don't know which one I've got until I get it mounted on a heatsink and installed.
03:13nyef```: Damn nVidia for re-using model numbers.
03:13imirkin: nyef```: do you have any specs about it?
03:13imirkin: like wattage, or number of shader cores, or anything else?
03:14nyef```: Either it's a GK104M or a GM107M. In both cases, it's useful, but I think that I'd rather have the GM107M.
03:16imirkin: yeah dunno
03:17nyef```: For the other two video cards I've got coming I managed to find either a model which refers to only one possible chip type, or the range of possibilities is such that they are all suitable for what I need.
03:19imirkin: dboyan: starting maxwell, there's an actual ATOMS instruction which can be used for atomics rather than the disgusting hacks used on kepler and fermi
03:20dboyan: yeah, I know, that instruction seems really handy.
03:21imirkin: but all the prior stuff is trying to lock memory locations, and then retrying when that fails
03:22dboyan: maybe nvidia guys also got fed up by those hacks
03:24dboyan: so they move it to hardware (or microcode, who knows...)
03:45imirkin: either way, we don't have to worry about it
09:24HayKunSun: listen mwk: i am fairly done with you stupid idiots , i publicly threatted you shithole
09:26HayKunSun: there is no problem to knock out you or imirkin while you keep abusing and violating users, it is not at all a problem we have, and it will be done
09:26HayKunSun: fucking diseases such
09:34HayKunSun: i've read about such conflicts, and it is not about what moods or PMS you face, you've been several times said get your shit together, users do not care about your moods, take me responsible along with linus for threattening morans, yeah yeah after all you have not violated yourself
09:37HayKunSun: every day someone dies cause of shitty technology, how do you try defending yourself wasting time for banning especially the one who comes to make things better? what the hell do you waste time on?
09:39HayKunSun: do you at all understand, it is not a question about ego or moods, it is a question about tehcnlogy
09:44HayKunSun: i do not attend here, yo get respect neither to get some award, cause all which i talked has been made theoretically ten years back and before i even had clue
12:35leonn: i’m having an issue with nouveau in debian testing (stretch) that leads to random desktop freezes (X display freezes, mouse cursor still moves, ssh into machine still works), with log output like that http://paste.fedoraproject.org/555015/14869021/
12:35leonn: on another instance, i got this output http://paste.fedoraproject.org/555020/48690265/
12:36leonn: the problem is that this is an end-user system that i can’t really afford to leave unstable for any longer, so i guess i’ll have to move to the proprietary drivers as a workaround
12:36leonn: my question is, would it still be helpful to report a bug?
13:01karolherbst: leonn: plasma5 does trigger some multi context related issues on nouveau
13:01karolherbst: we are aware of the problem
13:03leonn: karolherbst, ah, good. is there an open bug or something that i could keep an eye on so i could notice once it’s fixed?
14:37HelloPeople: If someone here could lead me in the right direction that would be cool. Looking for the newest Nvidea card that is 100% libre, meaning free software drivers and free software firmware. I know it'll probably be a pretty old card, but I don't mind.
17:02clean: Is this the best place to ask about prime?
17:03imirkin: depends on the question...
17:03clean: I'm setting DRI_PRIME=1 to get my games rendering on the discrete nvidia card, which works. However sound only works when I have them render on the integrated intel/
17:04clean: One game even gives error about no sound card detected when run with DRI_PRIME=1 in env
17:05imirkin: that's the first time i'm hearing of such an issue...
17:05imirkin: i like it though :)
17:09imirkin: does this happen with multiple games? the only reason i can think of is that they're trying to do something very smart, like finding the hdmi audio device associated with the nvidia gpu or something
17:10gnarface: clean: is the sound HDMI?
17:10gnarface: oh, imirkin already said that, sorry
17:11clean: gnarface: well my speaker is plugged into front audio, they are all up in alsamixer.
17:12clean: Wait... it appears to be working in openmw. I just finished installing it.
17:12imirkin: it's something weird those games are doing to themselves
17:12imirkin: question is what and how to defeat it
17:12clean: It might be specific to wine actually. I think the only games I tried out prior to this were wine games.
17:16clean: I'll try out a few more games in wine anyway.
17:40AeroNotix: hi anyone around?
17:41AeroNotix: I get this error whe running things with optirun/primusrun: glxgears -info
17:41AeroNotix: [ 2522.210088] [ERROR]Cannot access secondary GPU - error: [XORG] (EE) Unknown chipset: NV117
17:41AeroNotix: [ 2522.210118] [ERROR]Aborting because fallback start is disabled.
17:41AeroNotix: But https://nouveau.freedesktop.org/wiki/CodeNames/ lists NV117 as supported. What do I need to fix?
17:45imirkin: you could grab xf86-video-nouveau from git
17:45imirkin: although that won't really fix your issues
17:45imirkin: if what you're trying to do is prime offload
17:46imirkin: you may be interested in https://nouveau.freedesktop.org/wiki/Optimus/, esp the dri3 section
18:17AeroNotix: imirkin: --listproviders has the second output named: modesetting
18:17AeroNotix: I don't have nouveau listed there
18:17imirkin: that's fine.
18:17imirkin: AeroNotix: first off, i recommend using dri3 rather than dri2 for offloading
18:18imirkin: secondly, you can get dri2 offloading working as well - just run xrandr --setprovideroffloadsink 1 0
18:18AeroNotix: DRI_PRIME=1 glxinfo | grep "OpenGL vendor string" outputs: OpenGL renderer string: Gallium 0.4 on NV117
18:19imirkin: great - you're done.
18:19imirkin: note that i'd also recommend grabbing kernel 4.10 so that you can reclock your GPU
18:19imirkin: otherwise it'll likely be much slower than your intel one
18:19AeroNotix: DRI_PRIME=1 glmark2 gives me worse performance than intel
18:20imirkin: see above :)
18:20AeroNotix: So, I'm runnin kernel 4.9.8
18:20AeroNotix: will try to get 4.1
18:21imirkin: ok. it's still a manual process in 4.10, but at least it's possible.
18:21AeroNotix: What do you mean still a manual process in 4.10?
18:22imirkin: you have to manually switch between perf levels
18:22imirkin: by echo'ing stuff into debugfs
20:50AeroNotix: imirkin: right i have 4.10 installed. Performance is the same. Re-reading the lin kyou game me above
20:51imirkin: AeroNotix: while the gpu is powered up (e.g. you have glxgears running on it), you can echo stuff into /sys/kernel/debug/dri/1/pstate
20:51imirkin: you can cat it to see the available options. the last line, AC(/DC) shows the current state.
20:52AeroNotix: ok trying that now
20:53AeroNotix: imirkin: wait, I don't understand. I don't have that path on my system.
20:54imirkin: AeroNotix: you need to have debugfs mounted... also the exact path may be different depending on driver load order, etc
20:54AeroNotix: I have /sys/kernel/debug
20:55AeroNotix: You're saying with 4.10 I should have /sys/kernel/debug/dri/**/* something?
20:55AeroNotix: that I can use to echo settings into?
20:55imirkin: well, that should be there on older kernels too
20:55imirkin: but on 4.10 you can actually use it to change perf levels :)
20:56AeroNotix: Do you have an example? The page you linked above doesn't use the dri debug interface. Just the vgaswitcheroo one
20:56imirkin: an example of using "cat" and "echo"? there's lots of those on the internet...
20:57AeroNotix: No, I mean, an example of the options available and where those files are supposed to be
20:57imirkin: i told you where the pstate file is supposed to be. the options available will vary by gpu.
20:58AeroNotix: [root@xenocorp debug]# find | grep prstate
20:58AeroNotix: [root@xenocorp debug]# pwd
20:58AeroNotix: I have no idea why I read prstate before
20:58AeroNotix: What are the numbers?
20:59imirkin: which numbers?
20:59AeroNotix: e.g. dri/0/pstate
20:59imirkin: those are identical files... the fact that there's 2 is an artifact of ... stuff.
20:59imirkin: card0 vs renderD128
21:00AeroNotix: Right so now I can see the clock speeds of the card whilst it's running things. You're saying to echo changes to these values to increase performance?
21:01imirkin: yes. so often on your gpu's generation the highest level will be 0f
21:01imirkin: so you can echo 0f > .../pstate
21:01imirkin: which will switch to that
21:01AeroNotix: ok got you
21:01AeroNotix: but only on 4.10?
21:01imirkin: [you should make sure the gpu is powered on for this... so run glxgears or something]
21:02AeroNotix: What happens if you do it whilst the gpu isn't running?
21:02imirkin: crash iirc
21:02AeroNotix: and these changes don't persist after the gpu powers down?
21:02imirkin: no, they should.
21:02karolherbst: I have patches to fix that
21:03imirkin: when the gpu turns back on it should go back to the previously-configured power state. i thought.
21:03karolherbst: imirkin: they don't
21:03imirkin: but karolherbst would know for sure.
21:03karolherbst: the module still things a higher pstate is set though
21:04AeroNotix: Either way, I don't think this will fix my issue. I am just trying to get a game working well. Running it with DRI_PRIME=1 or optirun/primusrun makes the game not even start. But wanted to see how to improve nouveau benchmarks at least. I feel satisfied with what you've taught me here for that, at least.
21:05imirkin: oh, and as you're on a maxwell, i very much recommend grabbing mesa-17.0-rcN
21:05imirkin: that could improve perf another 2x or so
21:05AeroNotix: ok, will look at that another time. I simply want to play a game on linux :)
21:05AeroNotix: on the intel chip it runs like shit
21:05AeroNotix: but trying to force it to use the nvidia chip, it won't even start.
21:06karolherbst: imirkin: I guess I will make a branch with just the nvkm_clk_update stuff to fix all those annoying issues
21:06AeroNotix: What is the biggest issue with graphics drivers on Linux for you guys/gals working on the drivers?
21:07user51_: I can't find the K2000M quadro on the codename list
21:07user51_: Oh wait, my bad
21:08user51_: It strangely has an [M] there, but at the next line there's K2100M which confused me
21:13karolherbst: imirkin: https://github.com/karolherbst/nouveau/commits/clk_update
21:13karolherbst: I think there might be a silly bug in this code though, but I think I might have fixed it
21:13karolherbst: it was related to reclocking while gpu is suspended or so
21:27AeroNotix: imirkin: echo 0f > pstate causes system instability
21:28AeroNotix: it *does* increase the fps but there are occasional hangs. I can move the mouse but the UI and gl benchmark freeze
21:28AeroNotix: but still, the FPS gain is still lower than the intel chio
21:29karolherbst: AeroNotix: do you have a recent meas-17?
21:29karolherbst: AeroNotix: and what are you comparing
21:29AeroNotix: karolherbst: no I don't have that package
21:30AeroNotix: karolherbst: I am just comparing performance between my intel and nvidia chip.
21:30karolherbst: you do, it's just called differently
21:30karolherbst: yeah, what application?
21:30karolherbst: fir enough
21:30AeroNotix: Also, I've tried xrandr --listproviders which gives me an Intel named output and an output named "modesetting"
21:31AeroNotix: I tried xrandr --setprovideroffloadsink modesetting Intel then DRI_PRIME=1 glmark2
21:31karolherbst: AeroNotix: glxinfo | grep "OpenGL version string"
21:31AeroNotix: karolherbst: OpenGL renderer string: Gallium 0.4 on NV117
21:31imirkin: AeroNotix: dri3 should provide for better perf. also an app like glmark2 will often be bound by things that aren't gpu performance
21:31AeroNotix: with DRI_PRIME=1
21:31imirkin: like ... pci bus bandwidth, etc
21:31karolherbst: AeroNotix: do it on intel
21:32AeroNotix: ~ glxinfo | grep "OpenGL renderer"
21:32AeroNotix: OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile
21:32karolherbst: glxinfo | grep "OpenGL version string"
21:32AeroNotix: OpenGL version string: 3.0 Mesa 13.0.4
21:32AeroNotix: for intel
21:32karolherbst: you need something newer
21:33AeroNotix: I'm running archlinux, I would assume the packages are relatively up-to-date. Which version would you recommend?
21:33karolherbst: 17 something
21:33karolherbst: try to build it from git master
21:34AeroNotix: link to git repo, please?
21:34karolherbst: I am sure there are ways on arch for this
21:34AeroNotix: yeah I just need to figure out which actual package to replace
21:34karolherbst: installing mesa system wide is a bit messy, I would suggest you to use a PKGBUILD for that
21:34karolherbst: no idea how it is called on arch
21:34karolherbst: the library is called mesa
21:34karolherbst: some call it libgl something
21:35karolherbst: AeroNotix: this maybe? https://aur.archlinux.org/packages/mesa-git/
21:35karolherbst: ohh wait
21:35karolherbst: it is version taged
21:35karolherbst: forget it
21:36AeroNotix: that's not the official package
21:36karolherbst: I know
21:36imirkin: karolherbst: when you get a chance, could you get a mmt trace of blob with deqp-gles31 --deqp-case=dEQP-GLES31.functional.texture.border_clamp.formats.depth24_stencil8_sample_stencil.nearest_size_pot ?
21:36whompy: Search for lcarlier's mesa-git arch repo. It's on pkgbuild.com I think.
21:36imirkin: [and also make a note of whether it fails or not... if it fails, i don't want the trace. i already know how to fail the test ;) ]
21:37whompy: AeroNotix: ^
21:38AeroNotix: whompy: thanks, searcing
21:43karolherbst: "general protection fault: 0000"
21:44karolherbst: imirkin: nvidia overwrites some stack frame protection stuff :D
21:44imirkin: although i must admit - not the answer i was going for.
21:44karolherbst: it is unrelated
21:44karolherbst: it already happens on loading time
21:45karolherbst: I have CONFIG_CC_STACKPROTECTOR_REGULAR set for some time now
21:57karolherbst: nvidia can't be used with CONFIG_CC_STACKPROTECTOR_REGULAR enabled....
21:59karolherbst: imirkin: okay, nvidia passes that test
22:01imirkin: could i get a mmt?
22:02karolherbst: I doubt it, mmt fails
22:03imirkin: i guess it needs to be adjusted for new blob
22:04karolherbst: ohh wait
22:04karolherbst: I messed with my local valgrind
22:05karolherbst: okay, same error
22:08karolherbst: there are updates in the repository
22:08karolherbst: let me try with those
22:16karolherbst: imirkin: http://filebin.ca/3CBRDffGF5CZ/mmt.log.xz