01:04 orbea: Cool,hardware decoding using the nvidia firmware works with nouveau on my gtk 780 ti
01:04 orbea: gtx*
10:28 orbea: Is there any reason to use a nvidia version newer than 325.15 as in these instructions? https://wiki.freedesktop.org/nouveau/VideoAcceleration/#firmware
10:28 orbea: I recall seeing a list where it says the firmware doesn't really change form version to version, but I cant find it again...
10:28 orbea: *from
10:32 orbea: Oh, its in the extract_firmware.py...
10:32 pmoreau: The main reason for using 325.15 rather than a newer version, is that the firmware might be located somewhere else in the `.run` file.
10:32 pmoreau: in later version
10:35 mupuf: the problem is also that nvidia deleted support for the older cards
10:35 mupuf: and maxwell video decoding is not supported
10:43 orbea: thanks, I submitted a slackbuild for it to SBo, there was some concern I should of used a newer version of the nvidia drivers
10:43 pmoreau: <=304.xx to get Curie support, <=340.xx for Tesla support
10:45 mupuf: pmoreau: we don't need firmwares for curie, do we?
10:45 mupuf: In any case, it was only accelerating mpeg1 and 2 and pmpeg does that too
10:47 pmoreau: mupuf: No idea, I never interacted with a Curie card. I just know that the previous support drop was after 304.xx.
10:50 mupuf: hehe
10:52 pmoreau: ;-)
10:56 pmoreau: mupuf: I shall discuss with you during the coming week about Reator and hardware.
10:56 mupuf: You shall :D
10:57 mupuf: <with the joker's voice>why so formal?
10:58 pmoreau: Hum… dunno :-D
10:59 Tom^: and thus future discussions has been concluded to occur at a coming future week.
11:05 pmoreau: Tom^: Other discussions can still take place now :-p
11:26 karolherbst: pmoreau, orbea: this is for the video firmware, right?
11:26 orbea: yea
11:27 imirkin: you might notice some h264 fail on occasion
11:27 imirkin: no idea why, not enough of an h264 expert to investigate. i suspect we're feeding it NAL's it doesn't like.
11:28 orbea: I haven't tested it with many videos yet, worked with the one's I did try
11:28 imirkin: yeah, it ends up fine for most videos
11:29 imirkin: but some videos have major artifacts
11:29 imirkin: seems like movie trailer videos are especially affected
11:29 karolherbst: imirkin: the linux divinity original sin ee port needs GL_ARB_shader_image_load_store, do you know anything about how far that is done for gallium?
11:29 imirkin: karolherbst: yeah, i know a ton about how far that is done for gallium: not at all ;)
11:30 imirkin: karolherbst: i'm planning on tackling it after i get atomic/ssbo all finished up
11:30 imirkin: there's actually a bunch of the backend work done on nouveau for images, but hardly everything
11:30 karolherbst: ahh nice
11:30 imirkin: anyways, i suspect i'll start looking at it in early feb, and it'll probably take me a couple months
11:30 karolherbst: there was another one who wanted to check that, but he said he doesn't know much about mesa internals, but I think he is using an amd card
11:30 imirkin: so... april? dunno
11:30 karolherbst: mhhh
11:31 karolherbst: imirkin: well I think this is mostly a software extension
11:31 imirkin: not that any of it is _that_ hard, i'm just not working on it fulltime
11:31 karolherbst: and most of the piglit tests are already passing (the glsl stuff)
11:31 imirkin: yeah.... no.
11:31 imirkin: it's a _ton_ of glsl junk, but you also have to have your backend stuff in order
11:31 karolherbst: ahh okay
11:31 imirkin: and naturally fermi and kepler are *entirely* different
11:31 karolherbst: I see
11:31 imirkin: kepler is all bindless
11:32 imirkin: while fermi is all bind-ed
11:32 imirkin: and i don't even want to think about maxwell
11:32 imirkin: which i'm _sure_ is again different somehow
11:32 karolherbst: okay, so not anytime soon
11:32 imirkin: well, i suspect it's a week of actual full-time work
11:33 karolherbst: I looked over the intel changes
11:33 karolherbst: and most of that was inside the mesa core and glsl parts
11:33 imirkin: right
11:33 imirkin: there was a lot of that
11:33 imirkin: but it's all in nir-land
11:33 imirkin: so i gotta redo it all for tgsi
11:33 imirkin: god i wish intel would just use gallium
11:33 imirkin: so much more opportunity for reuse
11:34 karolherbst: :/
11:34 karolherbst: yeah
11:34 karolherbst: imirkin: only the lexical glsl parser is shared between classic and gallium?
11:34 imirkin: anyways, it should actually be a lot easier than ssbo/atomic for the tgsi bits
11:34 karolherbst: (in glsl land)
11:35 imirkin: well, mesa/main is too
11:35 imirkin: so all the api bits
11:35 karolherbst: yeah...
11:35 imirkin: things like images aren't *just* glsl
11:35 imirkin: but there's also a bunch of api stuff, etc
11:35 imirkin: and that's all shared
11:35 karolherbst: but the API stuff isn't _that_ much right? so the benefit of sharing this isn't all that great
11:36 imirkin: but invariably the glsl ir stuff gets done in a way that's easier for intel (e.g. all the images/ssbo stuff is done as ir_call intrinsics, instead of adding actual nodes, or even adding a stupid ir_intrinsic node)
11:36 imirkin: the api stuff is a huge pain
11:36 imirkin: tons of error checking
11:36 imirkin: making sure textures are complete
11:36 imirkin: and other bs
11:36 karolherbst: ohh right
11:36 imirkin: (actually i guess they probably don't have to be complete for images)
11:37 imirkin: it took curro something like a year to land images on intel
11:37 karolherbst: uhh
11:37 imirkin: admittedly a bunch of it was due to internal infighting
11:38 imirkin: [i didn't bother to try to understand who was being the jerks in those discussions... but it just went 'round and 'round]
11:39 karolherbst: mhh and we would need a new libdrm release :/, well I could also use git libdrm, but well :D
11:39 imirkin: in other news, i ended up getting a free copy of grid autosport from feral =]
11:39 imirkin: oh yeah, i'm just going to roll all that back for now
11:40 imirkin: airlied: let me know if you plan on doing a libdrm release today. if not, i'll just revert all of ben's changes for now and roll them forward when you get a chance.
11:41 karolherbst: imirkin: if you want, you could give me a list of games you need and I could try to get some giveaways for them
11:41 imirkin: karolherbst: nah, i'd rather just get these from the game companies
11:41 karolherbst: yeah I know
11:41 karolherbst: but this is no work for me
11:41 imirkin: karolherbst: i don't really want the games in the first place :) but i do want the game companies to play nice with mesa, so i try to encourage that any way i can.
11:41 karolherbst: I know
11:42 imirkin: i remember when games used to fit on a floppy
11:42 imirkin: this thing is 13.7GB
11:42 karolherbst: and this is not _that_ big
11:42 imirkin: seriously?
11:42 karolherbst: yeah
11:43 karolherbst: I got a 30GB game somewhere
11:43 imirkin: wow
11:43 karolherbst: most of the newest titles are around 10GB
11:43 imirkin: it better make coffee if it takes up that much space
11:44 karolherbst: imirkin: witcher 2 needs 19GB
11:44 imirkin: wow
11:44 karolherbst: but that might be beacuse of traces inside the folder :D
11:44 imirkin: btw, i think i saw in the logs that some game ran like ass on nouveau?
11:44 karolherbst: just saw that my bioshock infinite folder is 40GB big :/
11:44 karolherbst: imirkin: all eon games run like crap
11:44 imirkin: saints something?
11:44 karolherbst: yeah
11:45 karolherbst: saints row IV
11:45 imirkin: well... like *especially* crap :)
11:45 karolherbst: witcher 2 also runs only with <50% perf
11:45 imirkin: if you have a trace you want me to look at, let me know where to grab it from
11:45 karolherbst: but saints row is the worst
11:45 karolherbst: only 33% for me
11:45 airlied: imirkin: let me try right now
11:45 karolherbst: imirkin: I have one
11:45 imirkin: airlied: ok cool. wow, didn't expect you to be awake
11:45 karolherbst: imirkin: yep, bioshock is 40GB big
11:46 karolherbst: no traces there
11:46 imirkin: airlied: if you can't, no big deal... git revert works pretty easily :)
11:46 karolherbst: imirkin: I have a steam library on my third hdd and the folder is like 122GB big, with 8 games ;)
11:46 imirkin: hehe
11:46 imirkin: i had to put my steam library on another disk too :(
11:46 imirkin: i stuck it on my XFS partition
11:47 karolherbst: well
11:47 karolherbst: you don't have to
11:47 imirkin: but apparently steam doesn't do 64-bit inodes
11:47 karolherbst: you can split the library
11:47 imirkin: so a bunch of games didn't start
11:47 karolherbst: you can just add new folders and choose on install between them
11:47 imirkin: [which happens if your disk is over a few TB]
11:47 karolherbst: ohh
11:47 karolherbst: mhh
11:47 karolherbst: maybe btrfs makes most sense for steam?
11:47 imirkin: only with XFS though
11:47 karolherbst: cause of the compression
11:48 imirkin: dunno. i have XFS though.
11:48 karolherbst: disc io is so unimportant for games
11:48 karolherbst: it is all cached in ram anyway
11:48 imirkin: yeah, but i don't have an infinite quantity of drives that i can configure with whatever filesystems
11:48 karolherbst: :D
11:48 karolherbst: right
11:48 imirkin: this raid array is XFS. it is what it is.
11:48 Tom^: karolherbst: loading screens. :P
11:48 imirkin: of course now i can buy a single 8TB drive which is bigger than the whole damn thing =/
11:49 karolherbst: Tom^: yeah how important :D
11:49 Tom^: reduces blood pressure and stress levels.
11:49 karolherbst: longer loading screens or shorter ones?
11:49 Tom^: or well increases.
11:49 karolherbst: :D
11:50 karolherbst: imirkin: http://www.file-upload.net/download-11148812/SaintsRow4.i386.trace.xz.html
11:51 imirkin: gr, stupid site checks referers
11:51 karolherbst: yeah :/
11:51 imirkin: wget --referer fixed it right up
11:51 karolherbst: :D
11:53 karolherbst: but sadly this game uses this one gl extension apitrace can't really handle :/
11:53 karolherbst: the trace replays with around 15fps here though
11:53 karolherbst: and 48fps on nvidia
11:53 imirkin: which one? ARB_copy_image?
11:53 karolherbst: not quite sure
11:53 imirkin: i have a local patch to "fix" it
11:53 karolherbst: but it shouldn't matter finding the cause of the perf
11:53 imirkin: https://github.com/apitrace/apitrace/issues/404
11:54 airlied: imirkin: done!
11:54 imirkin: airlied: fantastic, thanks!
11:54 airlied: just caught be in my eat breakfast before going to hospital phase :)
11:54 imirkin: airlied: merry xmas :)
11:54 karolherbst: imirkin: but it might be cpu bottleneck in the end
11:55 karolherbst: because I noticed _big_ slow downs file have high cpu load in the background
11:55 imirkin: oh, looks like jose actually pushed out a semi-fix
11:55 karolherbst: usually I don't feel much in other games
11:55 imirkin: [using my semi-fix]
11:57 imirkin: is btrfs actually usable now? it used to eat your data with little recourse for _quite_ some time
11:59 imirkin: oh my... apitrace uses std::map
11:59 imirkin: that's not good.
12:02 imirkin: hmmmm... came out all black for me too
12:02 imirkin: karolherbst: does it actually work when you play the game?
12:05 karolherbst: imirkin: well I use btrfs for my main partition, but yeah I already lost some data with an older kernel
12:05 karolherbst: I won't store my own data on btrfs though
12:05 imirkin: hehe ok
12:06 karolherbst: imirkin: what do you mean? I can play yes, but just horribly slow
12:06 imirkin: that's what i thought... give it a few more years to stew
12:06 karolherbst: and the replay is also black
12:06 imirkin: karolherbst: well... i mean it's not "all black" :)
12:06 imirkin: karolherbst: i have a suspicion i might know what's a contributing factor here
12:06 imirkin: gimme a few
12:08 mupuf: I stopped using btrfs on my / some time ago. I kept my real data on ext4 but wanted to test it on my root fs
12:12 imirkin: hm no, that's not it
12:18 karolherbst: mupuf, imirkin: I use btrfs mainly because it can be mounted as rw on boot, because btrfs doesn't need to be fscked at all :/ no idea if that's a good thing or not, but it works much better than a year ago
12:34 imirkin: airlied: btw, ping me again when you get back to bindless textures... i think roughly everything i told you about nvidia was a lie.
12:35 imirkin: but on the bright side, i think i have a solid understanding of how texture handles/etc work now. which was not the case before.
12:36 karolherbst: imirkin: how many fps do you get replaying the trace? :D
12:36 imirkin: karolherbst: mmmm... 14? i might have paused it in gdb though
12:36 imirkin: karolherbst: note that it's a GF108, not reclocked, DDR3
12:36 karolherbst: 14 avarage?
12:37 karolherbst: strange, because I get around 14 fully reclock
12:37 karolherbst: ed
12:39 imirkin: Rendered 3123 frames in 164.762 secs, average of 18.9546 fps
12:39 imirkin: Core i7-920
12:39 imirkin: model name : Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz
12:51 karolherbst: mhhh
12:52 imirkin: i guess my GF108 is faster ;)
12:52 karolherbst: maybe it is really a cpu overhead issue
12:52 imirkin: is your cpu slower than mine?
12:52 karolherbst: no :D
12:53 imirkin: hehehe
12:53 karolherbst: i7-4700MQ
12:53 karolherbst: boosting around 2.6GHz
12:53 karolherbst: or higher
12:53 imirkin: heh. so 4th generation, where mine is 1st
12:54 karolherbst: will check if the pstate changes anything locally
12:54 imirkin: i did catch it in a wait once or twice in gdb
12:54 karolherbst: but most of the trace is also loading and game menu and stuff :/
13:02 karolherbst: imirkin: mhh while retracing I don't see any high load on the gpu
13:02 karolherbst: but the one with the radeon card also said something like that
13:03 karolherbst: ohh wait, this was the part with the main menu I assume :D
13:04 karolherbst: imirkin: or maybe I did something wrong, cause I got "Rendered 3123 frames in 99.9353 secs, average of 31.2502 fps" on 07 now
13:05 karolherbst: "Rendered 3123 frames in 60.3747 secs, average of 51.7269 fps" 0f
13:05 karolherbst: mhh
13:13 karolherbst: imirkin: glMapBufferRange: MAP_COHERENT_BIT unsupported (https://github.com/apitrace/apitrace/issues/232)
13:14 imirkin: karolherbst: ah yeah... that'll cause problems for replaying traces
13:14 karolherbst: I created a new trace now with more ingame frames , so that the fps aren't that high
13:14 karolherbst: more then double size, I think this should be enough
13:15 imirkin: karolherbst: try recording 640x480 :p
13:15 karolherbst: nah, I want to have high load
13:15 imirkin: try recording it without GL_ARB_buffer_storage
13:15 imirkin: that should fix the coherent thing
13:15 karolherbst: ahh k
13:16 karolherbst: the game also uses a extension on nouveau which radeon doesn't support yet :/
13:17 imirkin: ARB_clear_texture? you could nuke that if you want the radeon guys to replay it
13:17 imirkin: or marek could stop being lazy and write the 2 lines of code required
13:18 karolherbst: imirkin: without GL_ARB_buffer_storage the performance is even worse :/
13:19 imirkin: well yeah, drawing things takes more time than not drawing them
13:21 karolherbst: well, but should it be the difference between 15 fps and 15 spf? :D
13:22 imirkin: yes.
13:22 imirkin: on trace replay you mean?
13:22 imirkin: or in-game?
13:22 karolherbst: in game
13:22 karolherbst: while tracing
13:22 imirkin: mmmm... no.
13:22 imirkin: i'm guessing they messed something up
13:23 imirkin: because they only target drivers with buffer storage
13:23 karolherbst: emulation of extensions?
13:23 imirkin: they're probably doing horrible things
13:23 imirkin: and triggering tons of unnecessary synchronization
13:23 karolherbst: I have high disc io
13:23 karolherbst: but even after quitting the game
13:23 karolherbst: also
13:24 karolherbst: the trace is now 5.2GB vs 300MB
13:24 imirkin: yeah coz now it's recording data
13:24 imirkin: :)
13:24 karolherbst: :D
13:24 karolherbst: then I shall trace it into ram
13:35 karolherbst: imirkin: I did a replay with gpu profiling once and saw some high draw calls, but also a glLinkProgram every frame + glReadPixels
13:36 imirkin: glLinkProgram on *every* frame?
13:36 imirkin: that's very sad.
13:36 imirkin: hopefully that's a no-op
13:36 imirkin: otherwise that means we end up compiling a fresh program on every frame
13:36 karolherbst: yeah I thought so too
13:36 karolherbst: and yes
13:36 karolherbst: _every_ frame
13:36 imirkin: glReadPixels is also unfortunate... that means it has to block for the draw to complete
13:36 imirkin: yeah, but e.g. if the program is already linked, i suspect it's a no-op
13:37 karolherbst: it isn't
13:37 imirkin: well then they're huge jerks
13:37 karolherbst: guess how I found it
13:37 imirkin: :)
13:37 karolherbst: yeah well
13:37 karolherbst: it is eon
13:37 imirkin: i bet it's the same program over and over too
13:37 karolherbst: also apitrace throws a lot of perf warnings
13:38 imirkin: but there's no shader cache in mesa
13:38 karolherbst: shader might recompile depending on gl state
13:38 karolherbst: something like that
13:38 imirkin: mmmmm... with nvidia?
13:38 imirkin: or with nouveau?
13:38 karolherbst: I could check both
13:38 imirkin: there should be no shader variants with nouveau
13:38 imirkin: at all
13:38 imirkin: except the stupid glDrawPixels stuff
13:38 imirkin: but that's unavoidable
13:39 imirkin: (or rather, difficult to avoid)
13:39 karolherbst: well the dev are not cooperative anyway, which I really don't understand, they just gave that bs argument that nvidia is best cause of this parallel optimization, but the game itself doesn't even use more than one core
13:39 karolherbst: ....
13:40 karolherbst: imirkin: thats with nvidia: "api performance issue 131218: Program/shader state performance warning: Fragment shader in program 3 is being recompiled based on GL state."
13:40 imirkin: yeah, nvidia apparently does recompiles based on state
13:41 imirkin: which is weird
13:41 imirkin: i dunno what they're doing or why
13:41 karolherbst: mhhh
13:41 imirkin: coz i don't have to do variants with nouveau
13:41 karolherbst: maybe some even more funky optimizations?
13:41 imirkin: probably
13:41 karolherbst: I think I saw stuff like that happening in mmts sometimes
13:41 imirkin: one obvious optimization is that if you only have a handful of uniforms, and they're not often updated
13:41 imirkin: you can bake those uniforms into the shader directly
13:42 karolherbst: now i have a good trace "Rendered 4301 frames in 151.337 secs, average of 28.4199 fps" with nvidia :D
13:42 imirkin: the problem is that it's the sort of thing that might or might not help
13:42 imirkin: and it's not particularly easy to do
13:43 imirkin: and i have highly limited time to futz with this stuff
13:43 imirkin: and we have much bigger pants-on-fire problems
13:43 karolherbst: mhhh
13:43 karolherbst: with newest mesa my nouveau is broken? :/
13:43 imirkin: i figure if we're at 50% perf in a clock-for-clock situation, we're not doing too badly
13:44 imirkin: i'd like to spend time to understand why that is, but it's just as likely it's due to us missing some features
13:44 imirkin: so i might as well spend time on feature dev
13:44 karolherbst: "libGL error: failed to load driver: nouveau"
13:44 imirkin: hm, worksforme
13:44 pmoreau: Need a newer libdrm I guess?
13:45 imirkin: i'm at git head + a few local commits that are wholly unrelated to anything like that
13:45 karolherbst: imirkin: I would really like to have a way to feed mesa with binaries compiled from nvidia and see how the performance behaves this way
13:45 imirkin: you need libdrm 2.4.66 though (just released)
13:45 karolherbst: yeah I already am on 2.4.66
13:45 imirkin: karolherbst: yeah... that actually shouldn't be too difficult
13:45 imirkin: karolherbst: but unfortunately it won't work
13:46 imirkin: karolherbst: because those shader binaries make references to things
13:46 imirkin: say... textures
13:46 imirkin: so the driver has to ensure those textures are set up in the same way that the blob would have set them up
13:46 imirkin: and other things like that
13:46 imirkin: blob feeds shaders a *ton* of useless uniforms
13:46 imirkin: [ok, not useless. i just haven't quite figured out the use]
13:47 imirkin: however we should have some way to do binary shader replacement
13:47 imirkin: since while shaders wouldn't work as-is, they should be easy to "touch up" to work with nouveau
13:48 karolherbst: mhh weird, I thought current mesa enabled tess for hsw?
13:48 imirkin: no, patches on mailing list though
13:48 karolherbst: ohhh
13:48 karolherbst: k
13:48 imirkin: haven't tested myself, but ken seems to think they pretty much work
13:48 karolherbst: maybe divinity works on intel then
13:49 imirkin: http://patchwork.freedesktop.org/series/2076/
13:49 imirkin: you can "download mbox", and then "git am" it
13:50 karolherbst: it needs 4.2 though (divinity)
13:51 imirkin: well, assuming that it doesn't want fp64, you can just force 4.2
13:51 imirkin: on intel
13:53 karolherbst: well it wen't further on intel while forcing 4.2 anyway
13:53 karolherbst: it just crashed later
13:53 imirkin: have you applied the tess patches?
13:54 karolherbst: no
13:54 imirkin: apply the tess patches.
13:54 karolherbst: will do it now
13:54 karolherbst: :D
13:54 karolherbst: the devs have to clean up some mess anyway
13:54 karolherbst: because it doesn't check if it was possible to create a 4.2 context
13:54 karolherbst: and then it just initialize glew and calls the function callbacks
13:54 karolherbst: *function pointers
13:55 imirkin: good times.
13:55 karolherbst: yeah
13:55 karolherbst: and I tried to find out which function pointers
13:55 karolherbst: and just noticed this too late
13:59 karolherbst: imirkin: but it is weird, I mean they say they don't care about mesa, which I think not many game devs really do. But the big performance gap is still bigger than usual, which I think is a bit strange :/
14:16 karolherbst: imirkin: I am having a nice linker warning: https://gist.github.com/karolherbst/4ba52512b781fac6b0c5
14:17 imirkin: karolherbst: that's not a problem though...
14:17 karolherbst: yeah I know
14:17 imirkin: what's complaining about it?
14:18 karolherbst: linker
14:18 imirkin: heh
14:18 imirkin: what binary
14:18 karolherbst: all gallium drivers
14:18 imirkin: ld? gcc? some llvm thing?
14:18 imirkin: gold?
14:18 imirkin: what binary prints that message
14:18 karolherbst: g++
14:19 imirkin: lame.
14:19 karolherbst: :D
14:19 karolherbst: gcc-5.3 by the way
14:19 imirkin: i'd take a patch to stick an anonymous namespace around it
14:19 imirkin: which iirc should fix the glitch
14:19 imirkin: but maybe not
14:20 karolherbst: something like that could cause really odd issues though
14:20 imirkin: nope. the structs are private to those files.
14:20 karolherbst: ohh okay
14:21 karolherbst: yeah well, even with the patches I am still stuck with 3.3 on intel
14:21 imirkin: as expected.
14:21 imirkin: no fp64.
14:21 karolherbst: ohh right
14:21 karolherbst: but tesseleation isn't also in the extension list
14:21 imirkin: that means you messed up
14:22 karolherbst: I am sure I did not :/
14:22 imirkin: i am sure you did :p
14:22 imirkin: are you looking in the right list?
14:23 imirkin: should be only in the core list
14:23 imirkin: not the compat list
14:23 karolherbst: glxinfo | grep -i tes
14:24 karolherbst: well nouveau still messed up
14:24 karolherbst: ohhh wait, maybe my system mesa is somehow messed up
14:25 karolherbst: what the...
14:25 karolherbst: why is there a i965_dri.so file from Sep
14:25 karolherbst: ...
14:25 karolherbst: now I have tesselation
14:26 imirkin: the prophecy is fulfilled
14:26 karolherbst: see I did not mess up (at least not today) :D
14:26 imirkin: hehehehe
14:26 imirkin: yeah, a robber came, hacked into your comp, and placed that file there. and then disappeared into the night.
14:26 karolherbst: who knows
14:27 karolherbst: nouveau is still messed up though
14:30 karolherbst: k, llvmpipe still works
14:33 karolherbst: imirkin: some ioctl get EACCES and ENOENT
14:33 karolherbst: on nouveau
14:34 karolherbst: imirkin: https://gist.github.com/karolherbst/2522044a88ce840c4152
14:34 karolherbst: ohhh
14:34 karolherbst: I need kernel support for the libdrm changes?
14:34 imirkin: no
14:34 imirkin: it should work
14:34 karolherbst: mhh
14:34 karolherbst: okay
14:34 imirkin: worksforme on 4.3
14:35 karolherbst: k
14:38 imirkin: fwiw i'm using dri2 right now
14:38 imirkin: stupid gentoo keeps sticking stupid things into my module path
14:39 imirkin: which overrides my clever settings to load my own ddx
14:39 imirkin: but now that 1.0.12 is out, i'm just installing that
15:19 imirkin: i'm thinking of substantially remaking the feature matrix page
15:20 imirkin: into basically 2 sections - "here is what is by and large supported" and "here are a lot of the caveats to that support"
15:20 karlmag: imirkin: :-)
15:20 imirkin: does that sound reasonable to people? are there other opinions?
15:20 imirkin: or do people like the contents of that page?
15:21 imirkin: or maybe a per-gpu family "what works and what doesn't" sort of thing
15:22 mooch: so i'm coming back to the riva tnt emulation
15:22 mooch: and i'm thinking it's a problem with rma
15:22 mooch: since it likes to repeatedly access the index register without writing to 3d0h
15:23 karlmag: imirkin: I guess it's not too bad, as is, but a question is what do you want to replace it with I suppose.
15:23 imirkin: karlmag: i don't think the current one really conveys useful information
15:23 mooch: but are there any other registers on the riva tnt that control rma?
15:23 karlmag: imirkin: cram more info into it?
15:23 imirkin: karlmag: no, reorganize
15:25 mooch: mwk: do you know of any registers on the riva tnt that control rma besides 3d0, and 3d4 index 38?
15:26 karlmag: I guess one of the first questions to ask yourself; who is the audience? As it is I have an idea what about half the left-most column means. But then again, I think it's ment to be a bit technical in it's descriptions.
15:26 karlmag: "the audience" as "intended audience"
15:27 imirkin: karlmag: yeah, exactly. i'm thinking people go to that page to find out if xyz works
15:27 imirkin: and i doubt that xyz is ever "Dual-link DVI"
15:27 karlmag: yeah, I'm pretty sure they do. That's what one would expect from such a matrix, in general.
15:28 imirkin: and there are always a million caveats to this stuff
15:28 karlmag: Not so often I guess, but stuff like "sli" and "power management" might be interesting
15:29 karlmag: what "multicard" really means I'm not sure.
15:29 imirkin: exactly :)
15:29 imirkin: and what does "power management" mean
15:29 karlmag: I guess "not sli" since sli is indicated on it's own.
15:29 imirkin: even i don't know
15:29 karlmag: that too
15:30 karlmag: In general people want to know; what aspects of my card(s) can I assume will work/not work and to which degree
15:31 imirkin: right
15:31 imirkin: and people have varying definitions of 'works'
15:32 karlmag: that too I suppose.
15:34 karlmag: I guess a couple of those matrices are needed. One "basic" one for those who want the quick overview, and one more technical/detailed one for those who want to know a bit more about the knitty-gritty?
15:39 karlmag: imirkin: I'm just coming with thoughts and ideas. Feel free to ignore any or all of them :-)
15:39 imirkin: karlmag: no, it's useful to get other opinions :)
15:40 imirkin: i'm not exactly a typical consumer of this stuff =/
15:43 karlmag: I know how it might be. Kind of getting into your own little bubble. Everything seems so obvious (to yourself), but might be a unknown language to others. Yeah, been there :-P
15:44 imirkin: pretty much
16:05 karolherbst: imirkin: usually people want to know what is supported by their actualy gpu, so this should be the key to find the entry
16:06 imirkin: as you're well aware, there's no great mapping between gpu marketing name and which one it actually is =/
16:06 karolherbst: I know
16:06 karolherbst: but lspci can usually tell you
16:06 imirkin: yeah
16:06 imirkin: i can do it based on the GKxxx/etc names
16:07 karolherbst: or just write something like this: (GK106 mid-high 600, 700M)
16:08 karolherbst: so you tell which gpu that might are, but not which exactly
16:08 imirkin: hehe
16:08 karolherbst: and if you see mid-high something twice you know you have to check what you really have
16:09 imirkin: or i can just be "run lspci first"
16:10 karolherbst: well
16:10 karolherbst: yeah
16:27 karlmag: Actually, you could do a; "Don't know which series GPU you have? Run lspci and look here <link to CodeNames page>" That should suffice, really.
16:27 karlmag: (though one could argue that page might not be 100% ideal either I suppose.
16:28 karlmag: But not too bad either though :-)
16:30 karlmag: I guess those darn marketing people are to blame for complexity (and that goes for nearly every type of item you can buy these days :-/ )
17:02 karlmag: imirkin: can something like this be useful? http://pastebin.com/VNRTa7mn
17:04 karlmag: basically trying to make a "reverse map" of the CodeNames page
17:11 imirkin: karlmag: heh i dunno
17:11 imirkin: it's too much stuff, too easy to get it wrong =/
17:12 karlmag: That is kind of true.
17:13 karlmag: Especially since I don't know if the info there is correct and also might not interpret everything there correctly either :-P
17:13 karlmag: Might be a starting point for something though.
17:16 karlmag: The main idea behind it is that you can "hide" lots by using sub pages (or other more modern web methods of hierachy) to present it.
17:27 karolherbst: yeah css
17:27 karolherbst: you can hide stuff on a css click event right?
17:27 karolherbst: if not there are also css hover events :D
17:29 karlmag: I have *no* idea.. but I bet *someone* have :-)
17:30 karlmag: hmm.. quadro nvs 280, both nv18 and nv34? That's how I read it. :-P
17:31 imirkin: karlmag: yeah there's some confusion
17:38 karlmag: oh well.. I think I'll go to bed now and do the rest tomorrow or something.
17:49 karolherbst: karlmag: ohh css doesn't have a state, so click events doesn't exist at all
17:49 karolherbst: only pressed
17:49 imirkin: karolherbst: if you're clever, it can be done.
17:49 karolherbst: not in css
17:50 imirkin: in css.
17:50 karolherbst: ohh wait
17:50 karolherbst: there is a checkbox hack :O
17:51 imirkin: here's a simple one: http://jsfiddle.net/Jeremyjjbrown/rv5PR/
17:51 imirkin: er wait
17:51 imirkin: sorry, ignore
17:52 karolherbst: :D
17:52 karolherbst: imirkin: http://stackoverflow.com/a/32721572
17:52 imirkin: i'm looking at this one: http://stackoverflow.com/questions/21919044/css3-transition-on-click-using-pure-css
17:53 imirkin: this is a neat one too: https://jsfiddle.net/k86b81jv/
17:54 karolherbst: but active is like pressed?
17:54 karolherbst: ohh it is presed
17:54 karolherbst: ohh wait
17:55 karolherbst: :target mhh
17:55 imirkin: clever right?
17:55 karolherbst: wow :D
17:56 karolherbst: why use JS at all anymore :D
17:56 karolherbst: imirkin: http://www.w3schools.com/cssref/tryit.asp?filename=trycss3_target_modal
17:56 karolherbst: :D
17:56 RSpliet: to benchmark JIT compilers
17:58 karolherbst: anyway, for visual stuff somebody shouldn't need to use javascript
17:58 karolherbst: well webgl is a different thing, but generally
18:24 imirkin: heh, so grid autosport can't keep up on my GF108 :) except on ultralow, where i get an avg fps of 15fps. but for anything higher than that, i get an artificial 12.5fps but in reality it just goes slower.
18:52 karolherbst: :D
18:52 imirkin: just realized it was a -O0 build... trying again with -O2
18:53 imirkin: on the bright side it led to me noticing a potential source of fail
18:53 imirkin: that was fun
18:53 imirkin: (fix pushed already)
18:54 karolherbst: is there an issue with grid on nouveau or just really bad perf?
18:54 imirkin: well, i did run into a minor issue, but i pushed a patch
18:54 imirkin: i have some extra asserts in my tree and they got hit
18:55 karolherbst: k
18:55 imirkin: there was another issue with tess + sso, but that got fixed a few weeks ago iirc
18:55 imirkin: note that my gpu is total crap, so don't take that as some sort of perf measure
18:55 imirkin: it's (a) not clocked up and (b) total crap to begin with
18:56 imirkin: GeForce GT 620 :)
18:57 imirkin: maybe i'll get one of those spiffy GM20x's when they get going on nouveau
19:02 karolherbst: the 620 looks like crap even compared to intel gpus :D
19:02 karolherbst: and there is still a 610 and a 605 :D
19:03 mooch: lol
19:03 mooch: my geforce gt 520 still beat my intel hd 4000 ivy bridge gpu
19:03 karolherbst: how?
19:05 mooch: well, it had better performance in dolphin
19:05 karolherbst: ...
19:05 karolherbst: dolphin optimizes for binary driver
19:05 mooch: oh
19:05 karolherbst: because intel ones aren't fast enough to begin with
19:06 karolherbst: maybe radeon mesa would make sense
19:06 karolherbst: and then you have games where even my 770m with binary driver can't get full fps :/
19:06 mooch: crysis 3?
19:07 karolherbst: I meant for dolphin
19:09 imirkin: karolherbst: the only good thing about it is that i have 2GB of vram
19:09 imirkin: karolherbst: btw, didn't you say you had a game that you thought kept getting slower and slower as you went along?
19:09 imirkin: or was that someone else? Tom^ maybe?
19:10 Tom^: cs:go
19:10 imirkin: Tom^: build from mesa-git and try it again
19:10 imirkin: i noticed a potential resource leak and plugged it
19:10 Tom^: nice
19:10 imirkin: note that you'll need libdrm 2.4.66 if you want to build from mesa-git
19:10 Tom^: i sort of solved it by removing all mussle flash from the guns, with various settings. :P
19:11 imirkin: hehe
19:11 Tom^: so to me it sounds/feels like some sort of shader issue that leaked
19:11 Tom^: on the mussle flash
19:11 Tom^: but then again i dont know the slightest what im talking about
19:12 mooch: karolherbst: like last story?
19:13 karolherbst: mooch: I was thinking of nfs u2
19:13 karolherbst: or was it the one after that?
19:13 karolherbst: Tom^: I can't pm you :D
19:14 Tom^: O_o
19:14 karolherbst: yeah well konversation is handling the "^" a bit odd
19:14 imirkin: Tom^: in this case blit's were potentially leaking things
19:14 karolherbst: when I click on your name a tab for "Tom%5E" is opening
19:14 karolherbst: :D
19:14 Tom^: karolherbst: get weechat. :P
19:46 orbea: mmm, weechat
22:19 baegle: Hello! Is the latest version of Nouveau 1.0.12?