00:08nyef: skeggsb: Welcome back.
09:34jarekin: o/ hey guys, i'm trying to play a game at @ 800x500 and the gpu is streching it to my monitors native resolution, which is cool, but it doesn't keep aspect ratio, any ideas howto fix that?
09:55pq: jarekin, in X? Look in xrandr --prop for a property to control that scaling.
09:56pq: jarekin, assuming your DE does not offer the setting.
09:59jarekin: hm, looks like transform is the right thing to use
10:00pq: jarekin, did it not list any properly with scaling in its name?
10:00jarekin: oh, thanks!
10:01jarekin: i didn't catch it initialy, so i went reading the manpage, and there --transform got my attention
10:05jarekin: pq: alright, thx, solved with: xrandr --output DVI-I-1 --set scaling 'Full aspect'
10:05jarekin: sry, correct command was: xrandr --output DVI-I-1 --set 'scaling mode' 'Full aspect'
10:05dboyan_: karolherbst: I applied the fix to increase tic and tsc count, but hitman is still crashing. It seems to crash later, though.
10:08dboyan_: karolherbst: I can also reproduce the piglit arb_gpu_shader5.textureoffsets crash. It crashes within glsl shader cache code. I mentioned it to tarceri but he said he didn't see it.
10:09karolherbst: dboyan_: you could try to even increase those values, but
10:09karolherbst: dboyan_: but you also need this patch: https://github.com/karolherbst/mesa/commit/078dc7a4012589aa156c0549cdbaf827e2ffc8a9
10:09karolherbst: I thought you were on my branch already and would incerase those vlaues
10:09karolherbst: be back later
10:16pq: jarekin, yeah, that's what I meant, nice :-)
11:32Chris|Laptop: imirkin: Can you paste the lspci command again for me?
12:16Chris|Laptop:is not liking LAPIC's.
12:28pmoreau: Chris|Laptop: I guess something like `lspci -vvv -d 10de:`?
12:29pmoreau: Chris|Laptop: There it is `lspci -vvvvnn -d 10de:`. (The channel is logged, look at the topic for a link to the logs.)
12:57Chris|Laptop: imirkin: https://pastebin.com/epmk0amQ
14:56imirkin: skeggsb: btw, let me know if you want me to do anything additional for the nv4a mmu thing, or if it's in "your court" for now.
14:56imirkin: [now i need to come up with some reasonable heuristic for when to put cmd/data bo's into vram in nouveau_video =/ ]
15:01karolherbst: imirkin: the last is related to the h.264 rendering issue?
15:01imirkin: karolherbst: no
15:02imirkin: it's related to trying to use pmpeg on a pci nv4a
15:02karolherbst: I see
15:02imirkin: since it wants a linear dmaobj, but the pci dmaobj is paged
15:02karolherbst: ahh okay
15:03imirkin: and adding cma support to nouveau seems ... unnecessary :)
15:08imirkin: in order to use linear memory via pci, since there's no remapping table, you have to have contiguous physical memory pages. that's what cma does.
15:17jamm: imirkin: hey, still stuck at the same AIGLX issue: could it be that my libglx.so isn't working well with nouveau?
15:18imirkin: jamm: not sure. i can't look at it right now.
15:18jamm: sure! no worries
15:19jamm: i'm guessing it's my mesa build - it doesn't seem to build its own libglx.so, afaics
15:48Chris|Laptop: imirkin: Has this output help you in any way?
18:46karolherbst: mupuf: I am sure you miss the occasional noises reator made while somebody was working on it
18:46mupuf: karolherbst: hehe
18:46mupuf: I did not even hear it
18:46mupuf: probably means my music is too loud
18:46karolherbst: most likely
18:52karolherbst: mupuf: I need a newer libdrm, how can I update stuff on reator with pacman?
18:53karolherbst: allthough I would only update libdrm anyway
18:53mupuf: I will do the complete update later
18:53karolherbst: well, when I want to do like 4 full piglit runs, later means like tomorrow :p
18:55mupuf: no worries
18:57karolherbst: mupuf: by any chance, do you have tons of broken HDDs you don't need anymore?
18:57mupuf: nope, why?
18:57karolherbst: sad, somebody I know wants to burn a pile down with thermit
18:58koz_: karolherbst: Someone you know has ready access to thermite?
18:59karolherbst: like that would be any hard..., but he is even legally allowed to use it
18:59karolherbst: and everything
19:04Lyude: imirkin: whenever you get a spare moment, does this look like the piglit tests you asked for on the ML so far? https://github.com/Lyude/piglit/tree/wip/nv_fill_rectangle-v2/tests/spec/nv_fill_rectangle/execution
19:05pmoreau: karolherbst: FYI, `pacman -Sy` to refresh what is the latest version available of each package, `pacman -S foobar` to install/upgrade the package foobar.
19:05mupuf: karolherbst: please don't update reator though, I want to know what state it is in
19:07pmoreau: mupuf: Have you considered moving to a single partition and have both Mesa and the blob installed, with glnvd?
19:07pmoreau: (or maybe you already did that)
19:12mupuf: pmoreau: I have
19:12mupuf: sounds very logical to do, now!
19:12pmoreau: Ah, nice! :-)
19:13mupuf: I really want to get this testing farm going first though
19:13pmoreau: I did that on my test computer as well, and it’s working pretty fine. Just need to remember to remove the blacklisting of nouveau, and blacklist nouveau on the command line if you want to use the blob.
19:14mupuf: you don't even need this, you can reload on the fly ;)
19:14mupuf: well, of course, provided you have no X running
19:14pmoreau: And tried reloading nouveau after the blob, it did not end very well :-D
19:14pmoreau: The other way round should work though
19:15mupuf: oh, funky!
19:15mupuf: well, maybe we would need to fix this, that sounds like a valid use case for us :p
19:15pmoreau: True :-)
19:21karolherbst: mupuf: any idea why running pilgit single threaded is so super slow?
19:22karolherbst: and I meant much slower than mt speed / core
19:22mupuf: karolherbst: because creating a channel takes forever?
19:22karolherbst: I see
19:23karolherbst: mind if I run piglit over the night? :O if this keeps up I need 7 hours for a run
19:23karolherbst: or I just do mt
19:25mupuf: if you do single threaded
19:25mupuf: at least, set --dmesg
19:25mupuf: karolherbst: have you upclocked the GPUs?
19:26mupuf: that will decrease the run time
19:29karolherbst: I just do it mt
19:29karolherbst: I might just need to resume it once or twice
19:29karolherbst: already at 8k/25k
19:30mupuf: it may not pass though :D
19:31mupuf: Nouveau never been working great with piglit MT
20:11karolherbst: mupuf: the first run had no issues :)
20:40karolherbst: mupuf: coming to sha17?
20:40RSpliet: karolherbst: RE patch 2/5
20:41RSpliet: is it _mandatory_ for MAD on NVC0 to have an immediate as one of it's params?
20:41karolherbst: why should it?
20:41RSpliet: because your test expresses this
20:41karolherbst: which one?
20:42imirkin_: RSpliet: it's explicitly trying to propagate an imm into a MAD
20:42karolherbst: RSpliet: pre RA we can only use the short imm form of MAD
20:42imirkin_: RSpliet: since the general encoding can't support it
20:42karolherbst: because for the LIMM form DST == SRC2
20:43RSpliet: imirkin_: I'm confused by the "else return" clause in that method then...
20:43karolherbst: so mad $r1 $r2 0xffffffff $r3 is illegal
20:43imirkin_: RSpliet: that means "bail, don't make changes"
20:43mupuf: karolherbst: what's that?
20:43karolherbst: ohh wait, 0xffffffff is a legal short imm value, isn't it?
20:43karolherbst: or mhh
20:43imirkin_: it is =]
20:44karolherbst: 0x12345678 then
20:44karolherbst: which is garbage IEEE float I assume
20:44karolherbst: ohh it isn't
20:44mupuf: ah, right! Probably not, I said I wanted to be less social this year, and I have done the exact opposite so far ;D
20:44karolherbst: mupuf: you have to get better, not knowing what sha17 is... seriously
20:45mupuf: see, exactly what I'm talking about! :D
20:46RSpliet: imirkin_: okay got it
20:46karolherbst: instead of "0xc0" I should put NVISA_GF100_CHIPSET
20:47RSpliet: karolherbst: my feedback then is: the method name is opaque :-P (although I suspect my nv50 one was equally?)
20:47karolherbst: see patch 1
20:48RSpliet: yeah... same feedback, the name "handleMAD" doesn't quite cover the purpose of the method
20:49karolherbst: uhm the class name does
20:49RSpliet: I was already typing sth similar
20:49karolherbst: we have so many handle* method names, so I kind of went with the flow
20:50karolherbst: and why is it opaque?
20:50RSpliet: fair enough
20:51karolherbst: the LoadPropagation is doing exactly the same for all kind of ops
20:51karolherbst: pre RA
20:51imirkin_: RSpliet: handleOPNAME is pretty common thing for a function to invoke when you hit that op in the instruction stream
20:52RSpliet: imirkin_: I know, I was already backing off
20:53imirkin_: anyways, the naming of stuff in those files is ... not-great
20:53imirkin_: but coming up with good names for all that stuff is quite a pain
20:53karolherbst: mupuf: I am planning on buying ticket(s) end of april and I will most likely drive there with others or maybe alone, no clue yet, you could combine it with a visit to hamburg :p
20:54RSpliet: mupuf: it's in Dutchland
20:54mupuf: RSpliet: yep, will be in the Dutchland in September, with pmoreau :D
20:54barteks2x: is nouveau reclocking safe to use? (ie. is it safe enough to not break my GPU)
20:54imirkin_: barteks2x: it almost definitely won't *break* your GPU
20:55imirkin_: barteks2x: that said, it may be wise to (a) save your work around reclocks and (b) monitor temperature if you switch to the highest perf mode
20:55barteks2x: any toold that can monitor GPU temperature?
20:55imirkin_: most GPUs have overheat protection and just shut themselves off
20:55imirkin_: anything that works with hwmon sensors
20:55imirkin_: if you run 'sensors' for example, it should report the info
20:57barteks2x: I tried to find it with google, is reclocking basically writing to /sys/kernel/debug/dri/1/pstate?
20:57karolherbst: barteks2x: you are on a laptop?
20:57imirkin_: make sure you only do it while the gpu is powered up
20:57imirkin_: or else, ka-boom
20:57barteks2x: I missed a few messages
20:58barteks2x: my last message before "or else, ka-boom" is "barteks2x: you are on a laptop?"
20:58barteks2x: and yes, it's a laptop
20:58karolherbst: "<imirkin_> make sure you only do it while the gpu is powered up"
20:58karolherbst: patches are pending though
20:58karolherbst: no idea when they will be merged :p
20:58imirkin_: hopefully for 4.12
20:59barteks2x: so I assume something is going to crash when I do it when do it when it's not powered up?
20:59karolherbst: mhh it shouldn't though
20:59karolherbst: it will most likely just mess up your bash process
20:59karolherbst: but if you are fast enough and power up the GPU, it should recover
20:59karolherbst: it's odd
20:59imirkin_: it'll hang the cpu, so ... not great
21:00karolherbst: mupuf: I am counting on you, I wanna do nouveau stuff on sha17 :p
21:01barteks2x: somehow even just using reclocking normally froze my system for a few seconds
21:01karolherbst: we should find a village and do some fancy RE workshop or so
21:01mupuf: hmm, that would actually be nice
21:01barteks2x: actually, it keeps freezing every few seconds
21:01mupuf: but REing with people around, sounds a bit interesting
21:01nyef: For the v2 HDMI 3D patch series, should I be CCing anyone, or just send it to nouveau@ and dri-devel@ ?
21:01karolherbst: _they_ do the REing, we should watch and give pointers :p
21:02karolherbst: I doubt it will work out that nicely though
21:02karolherbst: but it's a plan
21:02karolherbst: we should get some USB drives ready and chances are high that many have prime based systems, would be nice
21:03karolherbst: it doesn't have to be something new
21:03karolherbst: I mean the REing task
21:03karolherbst: but it could be quite nice to show some stuff and then let interested people do some RE stuff
21:04karolherbst: (and we should mention our maxwell2 problem *cough*)
21:04barteks2x: uh.... reclocking keeps freezing the whole system. After I change to highest performanc, everything will freeze for several seconds every few seconds
21:05karolherbst: mhh odd
21:05karolherbst: barteks2x: what kernel are you on?
21:05karolherbst: what gpu?
21:05barteks2x: nvidia geforce 740M
21:05karolherbst: ohhhh wait
21:05karolherbst: with 4.9 or 4.10 there was _weird_ syncing implemented inside the intel driver
21:05karolherbst: it sucks
21:05karolherbst: it annoys the hell out of me as well
21:06karolherbst: but I bet your freezes are something else
21:06karolherbst: barteks2x: what did you run on the GPU?
21:06barteks2x: I have both nouveau and intel driver, because nvidia optimus
21:06barteks2x: I just ran glxgears as a test
21:06barteks2x: with vsync off
21:07karolherbst: does it freeze with vsync on?
21:07imirkin_: nyef: to: ben, cc: nouveau, dri-devel, and if you want, linux-kernel
21:07barteks2x: I don't see it freezing
21:07karolherbst: barteks2x: k, I blame the i915 driver then
21:07barteks2x: but I will try to run something that actually uses the GPU a bit more
21:08karolherbst: but keep aware, that your desktop will be slown down if you the gpu can't keep up with 60 fps
21:08karolherbst: (it wasn't like this pre 4.9)
21:08barteks2x: even when my desktop uses intel GPU?
21:08karolherbst: because intel syncs with nouveau
21:09karolherbst: and... yeah
21:09karolherbst: it's a good idea to prevent tearing
21:09karolherbst: but has its downsides
21:09barteks2x: I generally have to use vsync with nvidia
21:09barteks2x: because otherwise I get glitches
21:09karolherbst: you will need to do the same with nouveau
21:11nyef: imirkin_: To ben directly and then cc the lists? I should be able to manage that. Now, to start calibrating my sense for this stuff, why?
21:11imirkin_: nyef: i dunno, that's just what i do. ultimately it's ben who applies the patch, the lists is just fyi
21:12barteks2x: is 75 gerrees C low or high for the nvidia GPU? (when used with max perf reclocking)
21:12imirkin_: on the high end of things. although chances are, with a laptop, it's EC-based fan control, not gpu-based
21:13nyef: Okay then. Thank you.
21:13barteks2x: did some recent version of nouveau suddenly get better support for multithreaded use or I was just lucky?
21:14imirkin_: barteks2x: there have been some improvements to handling of multiple *processes* not stomping all over each other int he kernel
21:14imirkin_: but not much in terms of multiple threads, in mesa, not messing things up
21:14barteks2x: so I was just lucky
21:15bambus: hey, is it possible to run Android x86 with 3D acceleration on Pascal GPUs since nvidia released signed binary blobs? :D
21:15barteks2x: so the freezing when reclocking should be gone after some future kernel update?
21:15imirkin_: bambus: yes.
21:16imirkin_: bambus: you need to grab airlied's drm-next branch, and an updated linux-firmware, as well as a recent mesa.
21:16karolherbst: barteks2x: no idea? Maybe switching over to DRI3 makes it goes away as well?
21:17barteks2x: I use dri3 already
21:17karolherbst: I never had this problem though
21:17karolherbst: maybe it is something within nouveau... who knows
21:17karolherbst: I just know that i915 added some odd syncing stuff
21:17karolherbst: and this part annoys me, because I hit it as well
21:17barteks2x: considering how "well" nouveau works for me witout vsync, it could be anything
21:18karolherbst: well it doesn't crash, :p
21:18bambus: imirkin_: thank you :D
21:19barteks2x: it's not very good when even chrome seems to run without vsync by default (so if I try to run chrome with DRI_PRIME=1 I get weird jumpiness)
21:19karolherbst: why do you want to run chrome on nouveau anyway?
21:19barteks2x: maybe some webgl stuff?
21:19barteks2x: or whatever it's named
21:20barteks2x: (for example using theshadertoy)
21:20karolherbst: compared to a 740m an intel HD4600 is quite fast as well
21:20imirkin_: is it ddr3 or ddr5?
21:21barteks2x: nouveau without reclocking manages to beat my intel GPU in performance
21:21karolherbst: what intel GPU do you have?
21:21barteks2x: no idea, I only know what CPU I have (if I look spomewhere in /proc)
21:21karolherbst: that would help as well
21:22barteks2x: Intel(R) Core(TM) i5-4200M CPU @ 2.50GHz
21:22karolherbst: especially 740m nouveau vs intel HD 4600 should be like super close in perf
21:22karolherbst: even on my system
21:23karolherbst: intel hd 4600 == nvidia 770m on 0a
21:23karolherbst: and the 770m is like 3x as fast as 740m
21:23barteks2x: is there some reasonably reliable benchmark I can try?
21:23koz_: karolherbst: I forget - what NVIDIA card are you running?
21:24karolherbst: barteks2x: uhm... no clue? test with real applications
21:24koz_: barteks2x: Try running StuntRally with maximum settings.
21:24barteks2x: would it take a long time to install on gentoo?
21:24koz_: barteks2x: It's a game written in C++. You tell me.
21:24karolherbst: barteks2x: I know some benchmarks related to certain bottlenecks, but this won't help you with general perf
21:25barteks2x: currently the most resource demandding game I have installed is minecraft
21:25karolherbst: that should be good enough
21:25karolherbst: because nouveau will most likely crash there
21:25koz_: barteks2x: I usually use Minetest as a measure.
21:25koz_:grumbles that he still can't get 60fps on 1080p with max settings and 512 textures...
21:25karolherbst: buy a faster GPU :p
21:26koz_: karolherbst: I have a 680. There's not far to go up from there.
21:26bambus: okay, how to grab airlied's drm-next branch, and an updated linux-firmware, as well as a recent mesa, and combine them to Android x86 iso? xd
21:26koz_: The weird thing is that on the blob, it can hit that without trying.
21:26karolherbst: koz_: the 780ti is like 60% faster or so :p
21:26barteks2x: with the settings I used and the wndiw size I used, 36-37 fps with nouveau without reclocking, testing with intel now
21:26koz_: karolherbst: In theory, or in practice?
21:27koz_: I might have to get me one of those then.
21:27karolherbst: the 780ti is a beast
21:27karolherbst: even under nouveau
21:27koz_: The main reason I went for a 680 is because at the time when I got it, Phoronix benches showed that the 780Ti wasn't a vast improvement on the 680.
21:27koz_: Mind you, this was *quite* a few kernel versions ago.
21:28koz_: I'm still confused why nouveau performs so much worse on Minetest than the blob.
21:28karolherbst: clocks aren't everything
21:29imirkin_: koz_: should be about 60-80% of blob perf. is that what you're seeing?
21:29koz_: imirkin_: I haven't tried on my specific card lately. I may just do that sometime soon.
21:30karolherbst: I was only able to get faster than nvidia in furmark :)
21:30imirkin_: koz_: could well be that minetest is taking advantage of a nvidia-provided ext as well, in which case it's not an apples-to-apples comparison.
21:30imirkin_: (like bindless, for example...)
21:31koz_: imirkin_: Fair enough - is there any way I can check this?
21:31koz_: (well, other than digging through the sauce code of Minetest's engine)
21:31koz_: I see.
21:31imirkin_: [not easily]
21:31karolherbst: I doubt they use bindless though
21:32koz_: karolherbst: It's build on top of Irrlicht.
21:32imirkin_: well, i heard 512 textures :)
21:32karolherbst: what advantage should it provides there
21:32karolherbst: imirkin_: I think he meant 512x512 textures
21:32koz_: karolherbst: Correct.
21:32karolherbst: as in size
21:33imirkin_:has no clue how minetest works
21:33koz_: imirkin_: To be fair, neither do I, or not really at least.
21:33koz_: I think I may also be about the only person in the world concerned about nouveau performance for that game.
21:33barteks2x: what I did notice with nouveau in minecraft now is that I need to wait much less time for everythign to be rendered
21:34karolherbst: barteks2x: most likely because the GPU has dedicated RAM
21:34imirkin_: koz_: nah, i think pq plays it too.
21:34karolherbst: and minecraft isn't exactly... carefull with RAM
21:35karolherbst: barteks2x: I wouldn't expect a big perf improvement in terms of FPS compared to intel though
21:35koz_: imirkin_ and karolherbst: I'll do a test soon and give you some feedback.
21:35barteks2x: and nouveau has 36 fps in my test case, while intel has 32 in the same test (+/- 1 fps). And it's without reclocking
21:35karolherbst: maybe 50% at most
21:35karolherbst: mhh, maybe memory bandwith is most important
21:35karolherbst: or only shader perf
21:35karolherbst: who knows
21:35karolherbst: but your intel GPU seems to be slow..
21:35barteks2x: when I enable reclocking, it caps to 60fps
21:35karolherbst: which is odd
21:36barteks2x: *with max performance
21:36karolherbst: barteks2x: do you have glxspheres installed?
21:37karolherbst: intel is liker super slow now
21:37karolherbst: the heck
21:37barteks2x: um... apparently I don't. I thought I have it
21:37karolherbst: it starts with 350MP/s and then falls down to 220
21:37imirkin_: karolherbst: i've observed that too.
21:38imirkin_: i think it clocks down
21:38karolherbst: mupuf: could you do a perf regression test on intel for 4.8 up to 4.10?
21:38imirkin_: i observed that way before 4.8
21:38imirkin_: like 4.5
21:38karolherbst: mupuf: 4.0 to 4.11 :p
21:38imirkin_: or even earlier (trying to remember which box it was on)
21:40karolherbst: imirkin_: ... it went down to 60 fps now....
21:40mupuf: karolherbst: what platform?
21:40karolherbst: intel hd 4600
21:40mupuf: what benchmark?
21:40karolherbst: perf in glxspheres... is like silly
21:40imirkin_: i think it's normal
21:40karolherbst: imirkin_: this is normal? https://gist.github.com/karolherbst/038bdb7275e4d1d80076d92ac52bb189
21:40imirkin_: starts out in effectively turbo mode
21:41mupuf: hmm, would need to add support for that in ezbench
21:41imirkin_: then slows down based on cpu load
21:41mupuf: imirkin_: that would be one heck of a turbo :o
21:41karolherbst: sounds like somebody was smarter than that person should have been
21:41imirkin_: karolherbst: vblank_mode=1?
21:41barteks2x: also another reason for me to use nouveau/nvidia instead of intel otheer than performance even without reclocking: the fog is actually a sphere
21:42imirkin_: i think you want 0
21:42karolherbst: it's the same with 0
21:42karolherbst: vsync on is 2/3
21:42imirkin_: barteks2x: are you saying that nouveau messes up rendering? or that intel does?
21:42barteks2x: intel has far worse looking fog
21:43imirkin_: may want to make a trace and report it to the intel guys (#intel-gfx)
21:43barteks2x: but that may be because there is some expension used on nvidia
21:43barteks2x: I can't reallu rule it out
21:43karolherbst: mupuf: I will check other stuff as well
21:43imirkin_: nouveau doesn't expose anything that intel doesn't
21:43barteks2x: basically, with intel the fog changes as I rotate
21:44barteks2x: with nouveau it doesn't. It stays perfect sphere
21:44imirkin_: barteks2x: report it to the intel guys
21:44barteks2x: it's been like that since forever on every OS I tried, it's not worth the effort of finding the right place for me
21:45imirkin_: same thing on windows?
21:45imirkin_: could be a mathematical equation that doesn't get enough precision on intel
21:45barteks2x: I was actually surprised when I saw the good fog on nouveau
21:45barteks2x: because I've never seen it loke that before
21:45imirkin_: i know that their sin/cos is broken
21:45barteks2x: it's more like they directly use the z value for fog
21:45imirkin_: (and occasionally returns values > 1 ... oops)
21:46barteks2x: when nouveau actually tries to calculate distance or something
21:46karolherbst: mupuf: intel_gpu_top: https://gist.githubusercontent.com/karolherbst/55d059c831c628e5c94dbebbb662c9e9/raw/06572ed75e2be43d9d8019791ed14f675601c8e2/gistfile1.txt
21:46imirkin_: barteks2x: well, GPUs don't make decisions about that stuff. they just do what the program asks them to do :)
21:48barteks2x: I remember you once mentioned patches to make multithreading work a bit better, right?
21:48imirkin_: barteks2x: i had to take them down
21:48barteks2x: oh :(
21:48barteks2x: what was wrong with them?
21:48imirkin_: some distros started to include them into their binaries
21:48imirkin_: and they were TOTALLY not ready for that
21:49barteks2x: for most users it was probably better than without these patches. I was going to attempt to use them
21:50imirkin_: for most users, using what's upstream is best
21:50imirkin_: because if they want to get help, that's what they have to be using.
21:52imirkin_: either way, as i had no interest in having this dicussion with distros, i took down my patches, and strongly requested that they not be included in distro builds in the cases i was aware they were being included.
21:53nyef: It'd be a whole other issue if the distros said "hey, we need these", and pitched in to fix them up properly, though, right? (-:
21:53imirkin_: there's no way to fix them up properly. that's why i abandoned them
21:53nyef: Fair enough.
21:53imirkin_: skeggsb is rewriting all the 3d driver wiring to do it "properly"
21:54nyef: Okay, here's hoping that I haven't managed to screw up this git send-email thing somehow...
21:54karolherbst: he is the only one with enough time for that anyway :p
21:54barteks2x: that seems like enough work that it will be done when I no longer have nvidia GPU
21:54imirkin_: it's no small talk, and not one that i had time to embark on myself
21:54imirkin_: nyef: you can send them to yourself first
21:55imirkin_: barteks2x: well, most of the hard parts of the 3d driver are done (i.e. the proper sequence of commands to send in order to achieve an effect)
21:55imirkin_: just ... all the wiring underneath needs to be redone
21:56barteks2x: I know nowhere near enough to be able to tell how much work it is
21:56karolherbst: imirkin_: on gm107: query-gl_clipping_input_primitives_arb-sync_cpu_read_after_cache_test-gl_unsigned_int was fixed? and ext_transform_feedback.order elements triangles fails
21:56karolherbst: it's the only difference for my postraloadpropagation on gm107
21:56nyef: ... Did I somehow screw up the message threading?
21:56imirkin_: karolherbst: probably just random...
21:56imirkin_: nyef: it's fine.
21:56karolherbst: nyef: ..... yes?
21:56imirkin_: nobody cares about that.
21:57imirkin_: nyef: fwiw, i usually use ben's RH address
21:57karolherbst: ohh wait, it's fine now
21:57karolherbst: my phone just went crazy for a moment
21:57nyef: I... don't know that I have his RH address?
21:57karolherbst: nyef: it's one the list
21:57nyef: I'll get this stuff right eventually, I'm sure.
21:58karolherbst: it doesn't matter
21:58karolherbst: the ML "fixes itself" usually
21:58karolherbst: nyef: https://lists.freedesktop.org/archives/nouveau/2017-March/thread.html
21:58karolherbst: last series, looks fine
21:59imirkin_: nyef: stupid question - are infoframes short enough to fit in 255 bytes?
21:59imirkin_: oh right, they're like 0x40 bytes... or 0x40 words?
22:00nyef: imirkin_: Oddly enough, there's a length byte in the infoframe header.
22:00karolherbst: imirkin_: gk110 seems fine as well, even when I did some messups within piglit, but the result looks okay
22:01pmoreau: karolherbst: When is sha17?
22:01karolherbst: imirkin_: 38104/38300 passes
22:01karolherbst: pmoreau: end auf august
22:03pmoreau: karolherbst: Ah, still some time left then, cool. I’ll get the ISO back on feet and at some stuff to it. It should be doable to make another one that is more targeted towards RE’ing than testing.
22:03karolherbst: pmoreau: well, you have to come as well though :p
22:04pmoreau: I’ll be finishing an internship in France, will have to do some courses before the university year starts again, and also update the labs before mid Sept., plus try to rush some more SPIR-V/OpenCL stuff before XDC.
22:05pmoreau: And *maybe*, take a few days off away from computers and Computer Graphics/GPUs and all that stuff
22:05karolherbst: well you can have fun at sha17 without computers as well....
22:08karolherbst: mhh, maybe I could help at build up/teardown, but I don't have many days left to take of from work :(
22:08karolherbst: oh well
22:10nyef: SHA 2017, huh? Presumably not this? https://sha.org/conferences/past-conferences/sha-2017-conference-fort-worth-tx/
22:11nyef: (Admittedly not the first hit on Google, but on the first page of results.)
22:11karolherbst: sounds like something pmoreau could visit as something computer _unrelated_ :p
22:21karolherbst: nyef: patches look fine, but I never touched that code, so that comment might be worthless
22:23karolherbst: I am sure you could be more smart about pack_hdmi_infoframe somehow... but meh
22:24karolherbst: nyef: you should compile it with compiler warnings enabled as well, I am sure gcc will complain about missing breaks or fallthrough comments
22:25karolherbst: nyef: and there is a handy check-patch tool as well in the linux source
22:26karolherbst: nyef: you also have a few lins above 80 char limit in 5/10
22:26karolherbst: but checkpatch will tell you this
22:27karolherbst: can't do any in depth reviews, cause I need sleep
22:28nyef: Okay, I'm going to have to take notes. Thank you for the initial review, and sleep well.
23:02skeggsb: imirkin: can't reprod the -ENODEV on nv34 btw, i'll try and fix it blind and send you patches to test (later)
23:03mangix: is driconf compatible with nouveau?
23:34imirkin: skeggsb: gyah! why not? :( are you attaching it to a chan?
23:37imirkin: skeggsb: to be clear, this is the code in nouveau_video.c: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nouveau_video.c#n550
23:44imirkin: and that passes?
23:44skeggsb: nv3x has different fifo code than nv4x though, so, i'm not too surprised
23:44imirkin: do you have a theory as to why it fails for me?
23:44imirkin: oh, ok
23:44imirkin: ohhhh right
23:44imirkin: it has to be the nv40 fifo dma thing
23:45skeggsb: yeah, i'll poke around and figure it out
23:45imirkin: i forgot about that bit.
23:53skeggsb: imirkin: merged your nv4a patch btw, i think that's the right choice, regardless of whether or not we change the conditions in mmu/nv41/nv44
23:55imirkin: skeggsb: ok sounds good
23:55skeggsb: imirkin: as for your heuristic in mesa... if i'd actually managed to get back to finishing/merging my mmu series, you'd be able to definitely decide what to do... in the meantime, i'm not sure what to suggest
23:55imirkin: skeggsb: well, just going to check for nv4a, and there's a way to get the bustype, so if it's nv4a && !agp
23:56imirkin: since i'm sure some genius took a nv4a with a agp <-> pci adapter, and stuck it on a pcie bridge.
23:56skeggsb: right, that'll work fine for defaults, not so much if someone decides on NvAGP=0 etc ;)
23:56skeggsb: but, that'll do for now
23:57imirkin: how so? if NvAGP=0, i think it'll return that it's a PCI card
23:57imirkin: not sure
23:58imirkin: either way, i just want something that works on *my* nv4a, so that *i* can test it
23:58imirkin: what others do... that's their problem =]
23:59skeggsb: nah, it'll return AGP still for bus type. but, i agree with you there :)
23:59skeggsb: i think i have a gp107 sitting in an unopened package on my desk btw, so, hopefully enable that properly today too