06:50 deus_: hi
06:50 deus_: is there any way to get better performance with intel hd 2500 / i5 3470
06:50 deus_: I mean most of the drivers are made for nvidia
06:50 deus_: seems that intel-update-tool may be the one
06:50 deus_: but had dependencies problems
06:51 deus_: advice?
06:51 deus_: https://ark.intel.com/products/68316/Intel-Core-i5-3470-Processor-6M-Cache-up-to-3_60-GHz
07:20 GrayShade: Hi. I have a dual-graphics laptop with GNOME which probably uses i915. If nouveau is loaded the laptop hangs at reboot/poweroff, when running lspci and on suspend. I don't think I can help much debugging this, but is it worth filing a bug report with so little details?
07:39 GrayShade: filed as https://bugs.freedesktop.org/show_bug.cgi?id=103409
11:51 karolherbst: GrayShade: lspci reads from the pci config file... one hack you can do is to disable runpm for nouveau
11:52 karolherbst: GrayShade: you can boot with nouveau.runpm=0
12:43 hanetzer: question regarding mmiotrace. I'm having trouble determining if one needs to compile the traced module from source or what when using it.
12:44 pmoreau: hanetzer: You don’t need to compile from source to mmiotrace it.
12:46 hanetzer: pmoreau: ok, because one article (even mentioning nouveau by name) says it requires the gpl shim nvidia used to be compiled differently.
12:48 pmoreau: Ah, that could be if you are using a recent version of the NVIDIA driver, to avoid the mmiotrace from failing.
12:48 hanetzer: ah, interesting.
12:49 hanetzer: see, I've been eyeballing the mmiotrace kernel code and attempting to get into the right headspace to write something similar for ARM
12:50 karolherbst_: hanetzer: most parts should be able to stay pretty much the same though
12:51 hanetzer: karolherbst_: it looks like mostly pf_in.{c,h} would need to change
12:51 hanetzer: prollem is I don't know enough x86 assembly to at a glance know why those opcodes are read or write or immediate, so as to get a good grasp on what opcodes should be caught on arm
12:52 hanetzer: looks like a fair amount of LDR/STR would be needed.
12:52 karolherbst: hanetzer: everything which reads from/writes to memory
12:53 karolherbst: aka everything which might trigger a page fault or so
12:54 hanetzer: karolherbst: which is what mmiotrace does, correct? marks the memory as unavailable, takes the r/w, page faults, then re-runs the r/w with the memory available, no?
12:54 karolherbst: yeah
12:54 karolherbst: well
12:54 karolherbst: it single steps through the instruction
12:54 hanetzer: yeah. talking in broad strokes here.
12:54 karolherbst: right
12:55 karolherbst: in a perfect world we would emulate the instruction instead of single stepping
12:55 karolherbst: think about the repeat instruction
12:55 hanetzer: if only :)
12:55 karolherbst: which nvidia ends up using
12:55 hanetzer: heh.
12:56 hanetzer: in a perfect world none of this would be necessary in the first place :)
12:56 karolherbst: repeat is some super weird x86 instruction
12:56 karolherbst: http://x86.renejeschke.de/html/file_module_x86_id_279.html
12:56 hanetzer: yeah, I've been reading.
12:56 imirkin: hanetzer: i do think we need patches for recent blob driver shims coz they do something mmiotrace doesn't properly handle
12:56 karolherbst: imirkin: fun fact, it works on some machines nethertheless
12:57 hanetzer: honestly since arm is kinda simpler isa most of the mmiotrace code should be simpler (no funky prefix opcodes and such)
12:57 karolherbst: hanetzer: well, right
12:57 karolherbst: but what I would like to have is to move all that common code into a common place
12:57 karolherbst: and we need to rework the page handling anyhow
12:57 hanetzer: same. don't think I'm haxy enough for that yet.
12:58 karolherbst: I have put it on my todo list for next month actually
13:43 hanetzer: karolherbst: the refactoring?
13:43 karolherbst: yeah
13:44 hanetzer: well, I would appreciate you shooting me a line when that's happening :)
13:45 hanetzer: I'll prolly have to backport it to the vendor kernel, but hopefully that's not too much of an issue.
13:48 hanetzer: in the meantime I'll prolly keep cranking modules out for the stuff I have source code and/or actual documentation for.
16:11 Moiman: I get my system freezed when I use mpv with ewa_lanczossharp scaler (command "mpv --scale=ewa_lanczossharp clip")
16:11 Moiman: Here is dmesg https://paste.pound-python.org/show/YcfcF1T8m3jEJAbsOCtO/
16:14 imirkin_: are you using vdpau for decoding and GL for output?
16:15 Moiman: no vdpau just opengl
16:15 imirkin_: [or va-api]
16:15 imirkin_: is there anything before the gpu hang?
16:15 imirkin_: [i.e. failed to idle channel]
16:17 Moiman: nouveau 0000:05:00.0: mpv/vo[10502]: failed to idle channel 7 [mpv/vo[10502]]
16:18 imirkin_: right... anything before that?
16:18 Moiman: nope
16:19 imirkin_: =/
16:19 imirkin_: well, unfortunately "failed to idle channel" means "aaaah! gpu has hung!!!"
16:19 imirkin_: which provides little information.
16:19 imirkin_: ideally we'd have better recovery from gpu hangs
16:22 Moiman: I think it started happening after mpv started using compute shaders for ewa scaling
16:22 imirkin_: oh
16:22 imirkin_: this is the same problem as gl + vdpau
16:23 imirkin_: it's probably doing them from diff threads
16:23 imirkin_: that's known-broken with nouveau
17:44 mwk: well, here comes
17:44 mwk: if I broke compiling envytools for anyone with that piece of satan, please let me know.
17:48 mwk: ugh, fuck
17:48 mwk: readthedocs has Python 3.4, I used Python 3.5 feature...
17:53 imirkin_:hates python3
17:57 mwk: alright, seems to work now
17:58 mwk: documentation, C code, and XML all generated from a single file, good
17:58 mwk: should've done that ages ago
17:59 mwk: now would be a good time to clean up our cmake files, I suppose
18:01 mwk: any cmake experts here? the internets say nested CMakeLists.txt + add_subdirectory() are a spawn of satan and there should be a single CMakeLists.txt with lots of include() instead, does that sound right?
18:07 Tom^: convert it to a single standalone makefile
18:08 Tom^: cmake itself or most of the autotools are usually the spawn of satan imo :D
18:08 mwk: yeah, because that works so much better... no.
18:08 mwk: autotools are the spawn of satan, agreed
18:08 pmoreau: mwk: Dunno, I have used a root CMakeLists.txt + add_subdirectory(), but no include() yet.
18:09 mwk: but cmake manages to actually do useful things with relatively little pain
18:11 mwk: oh, and it can generate ninja files, which (as opposed to make) is a quite sane build system
18:12 imirkin_: cmake is the worst
18:12 imirkin_: autotools at least works
18:12 pmoreau: imirkin_: Do you have push rights for shader-db, or who should I ping instead? Otherwise, friendly ping for reviewing https://patchwork.freedesktop.org/series/31280/ or pushing it if you feel comfortable with it (Karol reviewed it).
18:12 imirkin_: i do.
18:12 imirkin_: but not this second
18:13 pmoreau: No worries :-)
18:13 pmoreau: (Link to the shader-db series: https://patchwork.freedesktop.org/series/31548/ which got Acked-by Karol)
18:13 imirkin_: as a user (i.e. someone who takes a released package and builds it), with autotools, it's always the same and it always works [almost]. with cmake, each one is a totally separate experience.
18:20 imirkin_: and universally a negative one
18:42 frikinz: Hi. I'm trying to get bumblebee to work and after failing with nvidia, I tried with nouveau. While the nouveau driver is loaded, I get nouveau: probe of 0000:04:00.0 failed with error -22
18:42 frikinz: Also optirun shows [ERROR]Cannot access secondary GPU - error: [XORG] (EE) [drm] Failed to open DRM device for pci:0000:04:00.0: -19
18:42 frikinz: I'm running debian stable.
18:45 frikinz: Card is a 720M: 04:00.0 3D controller: NVIDIA Corporation GF117M [GeForce 610M/710M/810M/820M / GT 620M/625M/630M/720M] (rev a1)
18:56 frikinz: Installing kernel from stretch-backport gives a nicer dmesg. Now optirun gives "fails to set drm interface version"
19:02 frikinz: I guess I have to pull other things from backports. Problem: I'm a noob with the graphic subsystem :D
19:25 frikinz: Fixed with nvidia-current-375.82 ...
20:46 pmoreau: imirkin_: I was trying to do `sym->setAddress(base_symbol, local_offset)` where base_symbol is in SHARED and has an offset of 0x10, but the offset is not passed onto sym. Should I set the offset of sym directly?
20:47 imirkin_:has no clue
20:48 imirkin_: have to go look at code...
20:48 imirkin_: and wtf setAddress is and does
20:48 pmoreau: It sets a base symbol and an offset, but it might be only used for indirect addressing.
20:48 pmoreau: the TGSI code does the offset manually, so I might want to do that as well.
20:49 Fervi: Hello. Sometimes application that go from windowed mode to fullscreen (like HTML5 player) freeze. Do you have any fix for that?
20:49 imirkin_: well, mkSymbol() does pass in an offset with setAddress
20:50 imirkin_: it's a question of wtf a symbol is, and why does it have an offset ;)
20:50 imirkin_: Fervi: nope.
20:50 imirkin_: pmoreau: i def remember some weirdness... but i don't remember the details
20:51 pmoreau: I have been assuming that a Symbol represents a pointer to some memory location, or a register.
20:51 pmoreau: OK
20:51 imirkin_: i don't think it's that simple.
20:51 pmoreau: :-'(
20:52 pmoreau: * :'-(
20:53 pmoreau: Mhhhh, I think I’ll hack around it for now and keep a note to investigate it further. Just want to get it running again on Tesla.
20:59 imirkin_: i don't think anything changed in that area...
21:04 pmoreau: My code changed, that’s it ;-)
21:04 imirkin_: o
21:04 imirkin_: that can happen
21:04 pmoreau: I re-wrote the memory management code a few times, and it is still messy as hell. :-/
21:05 imirkin_: hopefully getting better
21:05 pmoreau: It did get some more features (like padding), that is true, but lost Tesla support on the way. :-D
21:05 imirkin_: can't win 'em all
21:06 pmoreau: Looks like that
21:29 telli_eats_dix: Hi all
21:46 pmoreau: Hum, I need to check whether loads and stores can have g[$reg+imm on Tesla: NVIR happily prints it, but the immediate is not emitted.
21:47 imirkin_: nvdisasm is your friend
21:47 imirkin_: iirc yes
21:47 pmoreau: I checked with it, and the immediate is nowhere to be found ;-)
21:47 imirkin_: although the emission for gmem is most likely broken
21:47 imirkin_: since it's only for compute
21:47 imirkin_: which is basically only semi-kinda-sorta supported
21:47 pmoreau: Ah, OK
21:48 imirkin_: also perhaps the 4-byte variant is being improperly selected
21:48 imirkin_: what's the nvir op that you're trying to emit?
21:48 telli_eats_dix: Wat?
21:48 telli_eats_dix: I just wanted to know how to enable it in my kernel
21:49 pmoreau: `st u8 # g[%r0+0x4] %r2`
21:49 imirkin_: pmoreau: errrr... really?
21:49 imirkin_: that's pre-ra
21:49 imirkin_: (i hope!)
21:49 pmoreau: telli_eats_dix: How to enable what?
21:49 telli_eats_dix: Nouveau
21:49 telli_eats_dix: Driver
21:50 imirkin_: enable CONFIG_DRM_NOUVEAU
21:50 telli_eats_dix: In kernel config?
21:50 imirkin_: yes
21:50 telli_eats_dix: That's all?
21:50 imirkin_: yes.
21:50 telli_eats_dix: WoW that's INSAANE, thanks
21:51 pmoreau: That’s pre-RA indeed. In the final binary, `EMIT: st u8 # g[$r0+0x1] $r1`
21:51 imirkin_: pmoreau: how did it become +1?
21:52 pmoreau: Cause I picked a different value
21:52 imirkin_: o
21:52 pmoreau: :-D
21:52 imirkin_: ok, so ... that's wrong
21:52 imirkin_: it needs to be $a0
21:52 pmoreau: Let’s go with +1 in both cases
21:52 pmoreau: $a0... that rings a bell, somehow
21:52 pmoreau: It’s been a long time
21:52 imirkin_: i.e. it only takes address registers
21:52 imirkin_: can you paste the whole thing?
21:53 pmoreau: Yes
21:53 pmoreau: https://hastebin.com/miwurosepe.pl
21:54 imirkin_: right
21:54 imirkin_: so
21:54 imirkin_: (a) you can't have offsets it seems
21:54 imirkin_: and (b) you need to use the address file
21:54 imirkin_: perhaps you *can* have an offset though
21:56 pmoreau: So I should have something like g15[$a0]?
21:56 imirkin_: yes.
21:56 imirkin_: right, there are different gmem spaces.
21:56 imirkin_: forgot all about that
21:57 pmoreau: OK. I tried doing `add u32 $r1 $r1 0x1; st u8 # g15[$r1] $r2` and the hardware was happy about it, and gave me the correct result.
21:57 imirkin_: does nvdisasm print R1 or A1?
21:59 pmoreau: It prints R1
21:59 imirkin_: whoa
21:59 imirkin_: really?
21:59 pmoreau: yup
21:59 imirkin_: i don't believe you. pastebin it?
21:59 imirkin_: :)
22:00 pmoreau: https://hastebin.com/onunecimoh.scala
22:00 imirkin_: interesting.
22:00 imirkin_: what's the G2R?
22:00 pmoreau: No clue, I just saw that
22:01 imirkin_: anyways, ok, i guess i was wrong about the address registers
22:01 imirkin_: oh wait, that totally makes sense -
22:01 imirkin_: address registers are 16-or-so bits
22:01 pmoreau: Not completely, I’m quite sure I had to deal with some $aX things.
22:02 imirkin_: some ops probably take regs, others can't? dunno
22:02 imirkin_: i think shared offsets have to use $a
22:03 imirkin_: either way, indirect offsets - not allowed
22:03 imirkin_: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/codegen/nv50_ir_target_nv50.cpp#n396
22:03 imirkin_: the comment's predictions have come to pass.
22:04 pmoreau: :-)
22:04 imirkin_: i put in some opts to inline offsets
22:04 imirkin_: i guess it's a bit overly aggressive now
22:06 pmoreau: I was the one adding the offset, but maybe the compiler could un-inline offsets on Tesla?
22:06 imirkin_: well, even if you didn't, the opt would have inlined it ;)
22:06 imirkin_: the compiler never undoes stuff like that... pehraps it should
22:07 imirkin_: the idea is that you feed it the fully-out-of-lined thing
22:07 imirkin_: and then it will inline stuff
22:19 wifwj: mupuf: hi, are you there?
22:23 pmoreau: Ah, I also need to split 64-bit loads (and stores I assume) on Tesla. Will have to do that tomorrow.
22:23 alister123: imirkin_: semi-sensical is just about fine! if you know what i mean;)
22:24 alister123: that would not insult no one overly, neither add to much attention to the writer
22:24 alister123: *too
22:28 alister123: mart is not as good as he seems anyways, cause he invested all his time to gpu researching, he has other things to do to catch up with others. networking or whatever.
22:33 alister123: been all allmighty in computing is basically illusion, i mean computing field is so large, that everyone does mistakes anyways. making half sense in certain things that mart staudied forever is allready enough of a good result.
22:45 wifwj: what is the status of wayland on nouveau? does it work?
22:46 imirkin_: wayland doesn't care about the display specifics, it's just a protocol
22:50 gnarface: wifwj: sorry about imirkin_, he's trying to be helpful behind the pedantry. really he is. the answer you want is "we don't know but it was working last we heard, a couple days ago, aside from some weird flickering in dark colors, also you actually meant to ask about weston"
22:51 imirkin_: gnarface: good luck guessing what people are asking :)
22:51 gnarface: it's my specialty
22:51 imirkin_: i've long ago given up on that - it's a losing proposition
22:51 gnarface: 75 - 85% accuracy is good enough for government work they say
22:53 imirkin_: you have a bright future in politics
22:53 wifwj: imirkin_: any news on your patch? https://bugs.freedesktop.org/show_bug.cgi?id=102349
22:53 imirkin_: none
22:54 gnarface: you think? after their divorce, my aunt told me i should be a lawyer. i don't think she meant it as a compliment though.
22:54 imirkin_: wifwj: although i may be able to get some time this week... we'll see.
22:54 imirkin_: wifwj: but i hate promising and then not delivering, so definitely no promises
22:55 imirkin_: gnarface: i'd put a </sarcasm> tag, but that'd be lying...
22:55 wifwj: imirkin_: would be great if you could get some time this week for the issue
22:55 wifwj: thanks already for thinking about the issue ;)
22:56 imirkin_: wifwj: it's a little unfortunate that i'm in the position of being the only person willing/able to do anything about it =/ but sadly nouveau has ~0 developer time.
22:57 imirkin_: btw, wayland on nv4x is likely to end in tears, should you plan on trying it
23:00 wifwj: thats something i liked to know about. is there something hardware-required that stopps for example the chance to run wayland on nvidia TNT2?
23:01 imirkin_: it'll all run, just without hw accel
23:01 imirkin_: wayland really likes buffer passing and all that
23:01 imirkin_: also all the compositors require GLES2
23:02 imirkin_: nouveau_vieux only provides GL 1.2 (barely) on TNT2
23:02 imirkin_: you'll actually get a worse experience with nv4x, which *does* support GLES2, just poorly
23:03 imirkin_: since it'll try to do hw accel
23:04 wifwj: and thats something else i asked me some time ago. Is it possible to get opengl version 4.5 for example running on nv4x ? I have seen some free drivers getting higher opengl version support for some cards then the closed-source-driver did
23:04 imirkin_: only via a software impl
23:04 imirkin_: the hw doesn't have any support for most of the features since GL 3.0
23:05 imirkin_: that would only happen if the closed driver didn't support some hw features that were available
23:06 wifwj: but the gpu-power can be used for having those features ran on the GPU - still bad speed compared to more recent cards because the ASIC does not have the optimized calculations for that?
23:06 imirkin_: no
23:06 hanetzer: sounds legit. considering that 30% improvement to their drivers when amd started kickin' ass
23:08 imirkin_: nv4x doesn't support... tessellation, geometry, compute shaders. it doesn't support shader images or buffers, it doesn't support buffer textures, and probably 100 other things
23:08 imirkin_: it's stuff that's in the graphics pipeline. emulating it makes no sense.
23:09 wifwj: So on a GPGPU capable GPU you could emulate nearly everything?
23:09 imirkin_: sure, you could implement a full graphics pipeline on the compute portion of the gpu
23:10 imirkin_: you couldn't use any of the graphics portion of such a gpu though
23:10 imirkin_: which pretty much limits the usefulness to the nvidia tesla series, which was DX10 (i.e. GL 3.3) but also had compute
23:11 imirkin_: i guess i dunno - maybe R600/R700 had compute as well.
23:11 wifwj: yes, i asked exactly with thinking about NV50
23:11 airlied: nope, it has vertex shadesr for opencl
23:12 imirkin_: this would be *substantial* effort, for what i see as negligible usefulness
23:12 imirkin_: the cheapest DX11 gpu would blow such an impl out of the water
23:15 wifwj: it would be really that slow? A nvidia GTX285 would be slower in OpenGL 4.x then a Geforce GT420?
23:19 gnarface: don't forget about the lack of reclocking support, so essentially you're driving a full opengl implementation in software on a video card that's in power saving mode
23:19 gnarface: i can tell you by direct experience that pretty much any other option is faster
23:20 gnarface: because you're back to just being bottlenecked by raw fill rate at that point
23:20 imirkin_: wifwj: most likely, yes
23:20 imirkin_: actually GTX 285 should support reclocking just fine
23:23 wifwj: I had a GT200 chip card here. After it start crashing due to nouveau problems i gave it away. Fixing nv4x would probably already take enough time from me to report and test everything. I didnt like to open a new workspace with nv5x
23:24 imirkin_: well, G200 would work much better than a nv4x
23:25 wifwj: why is on this page https://nouveau.freedesktop.org/wiki/FeatureMatrix/ "video decoding accel (VDPAU/XvMC) " be set at "DONE" on NV40 but VP1 is listed here red TODO https://nouveau.freedesktop.org/wiki/VideoAcceleration/ ?
23:28 wifwj: btw, in the FeatureMatrix the PowerManagement is listed on NV40 as "stalled". I try to test and report as much as i can. Should it maybe be set to WIP?
23:29 wifwj: https://nouveau.freedesktop.org/wiki/PowerManagement/ -> NV40 "Fanspeed control" is defenetly WIP and not done. Every single nv4x card i tested until now had not a working fanspeed control. mupuf is been informed
23:30 wifwj: bugreport about that: https://bugs.freedesktop.org/show_bug.cgi?id=102352