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