03:31imirkin: Lyude: dboyan: i'm planning on pushing the following patches: https://github.com/imirkin/mesa/commit/353711266237985989146340099dcafd5105b6b8, https://github.com/imirkin/mesa/commit/6176cdb36a7012eabfa1dd3c2e4f634dcae51586
03:31imirkin: let me know if you disagree.
03:33dboyan: I don't mind if you think they are okay.
03:34dboyan: imirkin: oh, features.txt
03:34imirkin: ah right, yeah. will add.
03:39imirkin: i'm pretty sure it's fine, although would be good to get Lyude to double-check that the GL_ARB_shader_viewport_layer_array stuff really works -- no urgency around pushing it.
03:41dboyan: there hasn't been piglit test for the ARB extension. but it's not essentially different from two AMD ones except for tes
03:42imirkin: TES is the big difference
03:43imirkin: grrr... who added it without tests =/
03:43dboyan: nha said they tested against yet to be released cts
03:44imirkin: tests: port tests for arb_shader_viewport_layer_array
03:44imirkin: there's stuff on list.
03:44PyroSamurai: imirkin: I was re-reading our conversation from the other day and I guess I should specify what I need from openCL. I don't need any of the graphics capabilities, or shaders. I simply need the gpgpu abilities of opencl for parallel processing of tasks. That is what I want to implement.
03:44imirkin: PyroSamurai: gpgpu = shaders.
03:45dboyan: yeah, and image = graphics
03:45imirkin: (aka "compute shaders")
03:46PyroSamurai: that's kinda confusing for me since I do a bit of artwork as well and I think graphics when someone says shaders lol
03:46imirkin: it's all pretty inter-related
03:47PyroSamurai: computers are weird :3
03:48dboyan: If you know both modern opengl and opencl, you will find relations in concepts in both parts, under different names
03:50PyroSamurai: btw, does gpu model affect the way the software gets implemented or is cross-gpu
03:52dboyan: it depends, cross platform means more abstractions. you can compare opencl with cuda
03:55PyroSamurai: I meant more along the lines of having a GK104 and a G92 share code or is it custom software for each
03:57dboyan: they use diffent ISA, but the underlying logic is similar.
03:57dboyan: in nouveau we use the same IR for them
03:57dboyan: you can take a look at the codegen in nouveau
03:58PyroSamurai: point and I will look
04:02PyroSamurai: okay, great to finally see some code. I'm not much a theory guy, definitely prefer looking at code. It's midnight here though so I'm gonna hit the sack but look at the code there more tomorrow.
04:04mangix: PyroSamurai: so you want to make hashcat work?
04:04PyroSamurai: btw I have a GTX 760, 9800GT, 9500GT, and two HD7770 (I know amd stuff isn't really on topic but I saw mention of it backlogs, so yeah) if you need me to test anything
04:05PyroSamurai: mangix: lol close, I'm writing my own cracker.
04:05mangix: hahaha best of luck
04:06PyroSamurai: mangix: I'll assume that isn't sarcasm, thanks :)
04:08PyroSamurai: mangix: mine isn't for password hashes though, it's for archives. but same mechanics basically
04:15PyroSamurai: imirkin: dboyan: anyways, I look forward to working on nouveau with you all, hope the reason I'm helping doesn't rub anyone the wrong way.
04:15mangix: FWIW it'd be easier to add a format to hashcat. It has support for a few archive formats already.
04:17PyroSamurai: mangix: perhaps, but lets say I'm not a fan of the license they use. I planning to use AGPLv3, this type software can easily become a "cloud service" so I'd rather cover that angle.
04:22mangix:has no idea about licensing.
04:24PyroSamurai: I've become pretty good at licensing as a necessity of developing and RE. It isn't something I enjoy though. I don't think that even lawyers like it.
04:30PyroSamurai: mangix: For RE projects like nouveau licensing is very important. In other projects you can just paint everything black because nobody cares. Anyways, I've got sleep now, bud. I'll check the backlog tomorrow if you say something.
04:30PyroSamurai: got to*
07:51pmoreau: PyroSamurai: Indeed, looks like we are having troubles crossing paths. :-/
07:53pmoreau: PyroSamurai: https://phabricator.pmoreau.org/diffusion/MESA/ is my fork of Mesa, where I keep my local work, and `clover_binary` is the branch I am currently working on and should have everything.
07:54pmoreau: PyroSamurai: I'll update the instructions on how to configure everything to get it running (you’ll need a special fork of LLVM and clang to generate the SPIR-V binaries) and send you the link to it.
07:58pmoreau: PyroSamurai: You can start looking at how SPIR-V is structured (https://www.khronos.org/registry/spir-v/papers/WhitePaper.html, https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.html). The idea is to translate SPIR-V to the intermediate representation used by Nouveau.
08:00Teklad: pmoreau: You never sleep!
08:01pmoreau: Teklad: I do! :-D I went to bed like 10 hours ago, and woke up ~2-3 hours ago.
08:02Teklad: I didn't wake up til 9pm today.
08:02Teklad: 2100 hours.
08:03pmoreau: You were missing some sleep, or went sleeping "early"?
08:15Teklad: pmoreau: I think I was lacking a lot of sleep.... its unusual for me to sleep more than 6-7 hours.
08:34pmoreau: PyroSamurai: Here are the updated instructions for setting up everything: https://phabricator.pmoreau.org/w/mesa/testing_opencl_through_spirv/
13:01dboyan_: It seems nouveau hangs on my gp107 with drm-next
13:10skeggsb: dboyan_: can you try with nouveau.runpm=0 ?
13:11dboyan_: okay, wait a minute
13:15dboyan_: skeggsb: seems all right with nouveau.runpm=0
13:16skeggsb: cool. yeah, i noticed gp107 suspend/resume wasn't entirely working
13:16skeggsb: i had secboot issues (only sometimes?), which, i don't see in your log, which is interesting
13:18dboyan_: um well, mesa 17.0 doesn't support pascal?
13:18dboyan_: nvc0_screen_create:944 - Error allocating PGRAPH context for 3D: -22
13:19skeggsb: it might only have gp100 support
13:20skeggsb: it looks like 17.1.0-rc1 does
13:21dboyan_: yeah, gp107 uses GP102_3D_CLASS, 17.0 only has GP100_3D_CLASS
13:29dboyan_: well using drm-next has a side effect for me, the horrifying i915 bug in 4.10 is finally gone. Build me a git version mesa and I can play nouveau on pascal. yay!
14:49tstellar: pmoreau: I think a lot of the LLVM IR -> SPIR-V code in the llvm-SPIRV branch is unnecessary.
14:52pmoreau: tstellar: Mhh, which llvm-SPIRV branch are we talking about?
14:53pmoreau: Or do you mean the modifications done to LLVM and clang to translate LLVM IR to SPIR-V in https://github.com/KhronosGroup/SPIR and https://github.com/KhronosGroup/SPIRV-LLVM?
14:54pmoreau:has been debugging his LaTeX installation for far too long this afternoon…
15:20tstellar: pmoreau: I mean this branch: https://github.com/pierremoreau/SPIRV-LLVM/tree/spirv-3.6.1
15:25pmoreau: tstellar: Thanks for making me realise that than link is wrong :-D
15:26pmoreau: That branch though, is just a clone of the same branch from https://github.com/KhronosGroup/SPIRV-LLVM, with an extra patch from LLVM upstream to have llvm-config properly report -fnortti
16:09ccaione: uhm, what is RRRRRRRR returned by nvapeek?
16:15imirkin_: never seen that before. probably some kind of failure
16:20karolherbst: it means the reg is out of range
17:13PyroSamurai: thanks pmoreau
17:33pmoreau: PyroSamurai: I’ll be around if you have any questions
17:33PyroSamurai: pmoreau: okay
17:55Lyude: dboyan_: hey was just going through the review you did for one of my patches for adding AMD_shader_viewport_layer_array, do we have any tests for ARB_shader_viewport_layer_array in piglit? was just going to make sure my patches work against that extension but I don't see anything for it
17:57imirkin_: we don't ... dcbaker sent some but they werne't pushed
17:57imirkin_: but they also didn't include TES
17:58Lyude: ah, need me to fixup those tests or do you think we should be good?
17:59imirkin_: i think it should be fine
17:59imirkin_: just double-check that it's actually being exported
17:59imirkin_: or if there's some funny requirement we missed
18:00Lyude: alright, btw do you want me to send the patches weith those extra changes or just throow something on github for you to pull from? (the only change missing on the mailing list is moving the relnotes from 17.1 to 17.2
18:01imirkin_: check what i have in my tree
18:01imirkin_: if you hate it, let me know, and i'll adjust.
18:01Lyude: oh alright, gotcha
18:01imirkin_: top 2 commits here: https://github.com/imirkin/mesa/commits/cts
18:02Lyude: imirkin_: lgtm
18:03imirkin_: ok, i'll push tonight then. did you confirm that GL_ARB_shader_viewport_layer_array is exposed?
18:03Lyude: imirkin_: yep
18:05Lyude: karolherbst: about to start playing around a bit today with pascal, do you guys need any traces?
18:09Lyude: in addition to the stuff you asked for before
18:11Lyude: also general question: I'm about to play with power management related stuff on nouveau and I know that has a good chance of crashing the machine, but does anyone know if it crashes the machine hard enough the only thing that will reboot it is a watchdog?
18:12Lyude: I just realized the machine I left my pascal plugged into before I went to the office apparently doesn't actually have a working watchdog :(
18:15hakzsam: imirkin_: btw, I have a gtx 1060 too (in case you need something)
18:16karolherbst: Lyude: mhh, after the setback from yesterday I can hardly think about anything. I will write some code you could test when it is ready for reading out the voltage
18:16karolherbst: Lyude: what is sown for you through hwmon by the way?
18:16Lyude: karolherbst: I'm not sure I understand the last question
18:16karolherbst: if you execute "sensors"
18:16karolherbst: what is printed for nouveau?
18:17Lyude: lemme reboot into a newer kernel and see...
18:17karolherbst: what pascal gpu do you have by the way?
18:17karolherbst: did you upload your vbios already?
18:18karolherbst: k, because chances are the go106 has no power sensors and we could actually expose this on pascal already
18:18Lyude: no power sensors?
18:18karolherbst: there are no power sensors on low end GPUs usually, it's start somewhere in the middle field
18:19karolherbst: the vbios of the gp107 I have has no power sensors
18:19karolherbst: the gp104 have one
18:19karolherbst: allthough the one go106 I have here has one as well
18:20karolherbst: I will expose it for pascal, cause it should work
18:21Lyude: ah, alright. anyway, I will look into getting the vbios off of this
18:21Lyude: btw, did you see my earlier question about watchdogs?
18:21karolherbst: let me check
18:21karolherbst: don't worry, the GPU has fail safes
18:21Lyude: ahhh, cool
18:22karolherbst: corrupted FS is your biggest worry
18:22karolherbst: used btrfs
18:22karolherbst: got broke after a week
18:22Lyude: btrfs is always breaking somehow
18:22karolherbst: pro tip: no btrfs when doing nouveau dev
18:22Lyude: I just kinda had to stop using btrfs in general
18:22karolherbst: me as well, but maybe it is better now
18:22karolherbst: who knows
18:23Lyude: Mainly after my horrible experience of accidentally trying the dedup ioctl
18:23karolherbst: there was this super cool research on filesystem failures on unexpected data
18:23karolherbst: Lyude: https://events.linuxfoundation.org/sites/events/files/slides/AFL%20filesystem%20fuzzing,%20Vault%202016_0.pdf
18:23karolherbst: the "Time to first bug" table says it all already
18:24Lyude: "5s" LOL
18:25karolherbst: it's the time needed by the fuzzer to produce a bug
18:25karolherbst: and the fuzzer is good
18:25karolherbst: I also found bugs inside the mesa glsl parser with it
18:25Lyude: i'd imagine so, especially if it managed to get ext4 to trip up. I think I've only ever managed to break ext4 once in my life, even including test machines...
18:26karolherbst: Lyude: this is the best on by far, which I found: https://bugs.freedesktop.org/show_bug.cgi?id=98699
18:26karolherbst: it's important that there are 3 "+"s, doesn't work with an even number
18:31karolherbst: Lyude: do you use an out of tree nouveau module or simple one from the kernel?
18:35pmoreau: karolherbst: I have been using btrfs for Nouveau development without issues. I had more issues with ext4, though not that many
18:35karolherbst: pmoreau: how often do you crash the kernel?
18:36pmoreau: Nowadays, never
18:36pmoreau: Since I left toying with the kernel to play with Mesa ;-)
18:39Lyude: karolherbst: I build from the kernel module
18:40Lyude: e.g. just use a custom kernel
18:42Lyude: karolherbst: btw, sensors with nouveau doesn't report anything on my machine with the GP106
18:48Lyude: Also, can I just post the video bios? or is that a very bad thing to do
18:59karolherbst: Lyude: you can
19:01nyef: Hrm... Looks like the first signal that the HDMI input is enabling is a drop on GPIO 17. In this case at about 220.359815. Then, at about 220.361808, is an UNPLUG on the eDP panel. A few timer interrupts later, at 220.860195, the blob checks GPIO 11 (0xb) and starts monkeying with AUXCH, SOR, and PDISPLAY+0x20 and +0x24.
19:01nyef: A few more timer interrupts after that, and it starts poking PDISPLAY and AUXCH a bit more.
19:03nyef: And that's basically it?
19:04Lyude: karolherbst: got a gift for you https://people.freedesktop.org/~lyudess/archive/04-20-2017/gp106.rom.xz
19:06nyef: The disable seems to be a rise on GPIO 17 followed by a PLUG on the eDP.
19:08karolherbst: Lyude: thanks
19:09karolherbst: Lyude: nvapeek 101000
19:09nyef: Must be missing something, somewhere. Either there's magic in the PDISPLAY, AUXCH, and SOR parts, or there's some setup elsewhere that's getting smashed somehow.
19:09Lyude: 00101000: 00400080
19:11karolherbst: Lyude: k, your GPU has a power sensor
19:12Lyude: karolherbst: neat
19:13karolherbst: uhm... except that we read out the resistors wrongly... let me see
19:14karolherbst: mupuf: does it make sense to have 1280 ohm resistors?
19:14nyef: HDMI input cutover when a new signal is presented takes about seven seconds, and doesn't happen at the GRUB prompt (but does happen from Linux with neither nouveau nor the blob loaded), suggesting that it's an ACPI thing.
19:35nyef: Possible next approaches include dumping GPIO states pre-driver-load, post-blob-startup, while-hdmi-input-running-on-blob, post-nouveau-startup, and while-hdmi-input-running-on-nouveau... And enabling some amount of ACPI debugging.
19:40Lyude: karolherbst: do we by chance have a patch for doing PM re on nouveau that's more up to date then the one you linked me? ( https://github.com/mupuf/pdaemon_trace/blob/master/nouveau/0001-just-dump-the-clocks.patch )
19:40Lyude: trying to rebase it ontop of the latest nouveau driver but this is a very old patch
19:42karolherbst: Lyude: the patch is pretty useless for reing pm anyway
19:42karolherbst: and you don't need patches really
19:43Lyude: oh, cool
19:43karolherbst: there are several ways to go and running nouveau is usually the last thing you do :p
19:43karolherbst: you can compile nouveau as an userspace process
19:43karolherbst: and run it alongside nvidia for example
19:43Lyude: wait, what
19:43imirkin_: ben's repo has some crazy shit in it
19:43karolherbst: Lyude: I used it to re volting
19:43Lyude: that's really impressive, geez
19:44karolherbst: Lyude: https://github.com/karolherbst/nouveau/blob/awesome_tool/bin/nv_cmp_volt.c
19:44imirkin_: basically it's some userspace stubs to make all the mmio writes/etc work
19:44imirkin_: and then you're just twiddling the card, no reason nouveau can't run in userspace
19:45karolherbst: Lyude: it's perfect, because it also parses the vbios and so on
19:46karolherbst: but you have to be careful with it, cause it can also write registers and interfer with nvidia too much
19:47karolherbst: Lyude: but I have a nice task for you which might work on your GPU already, well pascal. Or other GPUs
19:47karolherbst: to reduce the power consumption
19:48Lyude: so, does it just only initialize certain parts of the card when nvidia's blob is running?
19:48Lyude: karolherbst: do tell
19:48karolherbst: check the code, you'll see it ;)
19:48imirkin_: you tell it what to do
19:48imirkin_: you can tell it to bring up only certain engines
19:48imirkin_: you kinda have to have intimate knowledge of all the parts in order to operate it that way
19:48karolherbst: dependencies for example
19:48imirkin_: have a look at some of the stuff in there
19:49imirkin_: most are pretty trivial things
19:49karolherbst: Lyude: clock gating: https://trello.com/c/fndxUee1/92-clock-gating-fermi
19:50karolherbst: being able to read out the current power consumption is a big help here :p
19:50Lyude: yesss, easy label
19:50karolherbst: well, it's less REing, because it's pretty much reed already
19:50karolherbst: but it is a good start to get used to kernel development
19:50karolherbst: I think
19:50Lyude: oh, lol
19:50Lyude: karolherbst: kernel dev is far from new to me :P
19:50karolherbst: you can concentrate more on the kernel crashes and so
19:51Lyude: still, might be a good thing to try working on
19:51karolherbst: Lyude: if you have an old GPU, there is always https://trello.com/c/IFXgU91I/169-clock-gating-pre-fermi
19:51karolherbst: or https://trello.com/c/Jd4FLlqf/43-pm-add-power-gating-support
19:52imirkin_: Lyude: what about the improved test case for ARB_post_depth_coverage?
19:52imirkin_: Lyude: or did you want me to write that for you?
19:52karolherbst: Lyude: or https://trello.com/c/Z3lSDA3m/148-adjust-clock-reading-code-to-changes-since-kepler2
19:52Lyude: imirkin_: ah, was taking a little break on that but I haven't forgotten about it :)
19:52Lyude: i still want to also work on opengl stuff since that is definitely an area I need to learn more about
19:53Lyude: is that alright with you?
19:55imirkin_: is what alright with me?
19:56imirkin_: your desire to work on opengl? that's quite alright with me...
19:56Lyude: hehe, nvm, I think I got the answer to that question :)
19:56imirkin_: or did you mean you'd rather i leave writing the test to you? that'd be alright with me too.
19:56karolherbst: Lyude: two newest patches from here: https://github.com/karolherbst/nouveau/commits/iccsense_pascal
19:57imirkin_: in fact, i can say definitively, that anything that causes me to have to do fewer things is alright with me.
19:57karolherbst: with that you should get the power consumption on your pascal card, no idea if the value will be correct though
19:57Lyude: imirkin_: yeah, I'm fine with writing the tests
19:59karolherbst: Lyude: you can apply those patches also from a kernel tree, just need to be in the correct path "/drivers/gpu"
19:59Lyude: yeah, git am --directory and that fun stuff
20:00imirkin_: Lyude: k, let me know when you run into problems with it. (i'm sure you will... it's a bit subtle.)
20:00Lyude: imirkin_: oh yeah I definitely have run into some issues with it :P, but I'm getting there. Unfortunately I don't remember what any of those issues are and I forgot to power on my skl sdp before leaving my apt for the office
20:42Lyude: btw karolherbst doesn't seem to be working
20:42karolherbst: Lyude: something inside dmesg?
20:43Lyude: karolherbst: [ 15.716682] nouveau 0000:01:00.0: iccsense: found invalid sensor id: 0, power readingmight be invalid
20:44karolherbst: does something appear in hwmon/sensors?
20:45Lyude: karolherbst: nope
20:45Lyude: lm_sensors was just hiding it on me
20:46Lyude: karolherbst: however, I am not seeing anything useful inside the hwmon entry for nouveau https://paste.fedoraproject.org/paste/NBz86blU~UZ~FuZKRtPeS15M1UNdIGYhyRLivL9gydE=/
20:46karolherbst: just run sensors ;)
20:47Lyude: karolherbst: like I said, I'm not seeing anything in sensors. power just has the usual stuff inside it as well
20:47karolherbst: ohh, wait
20:48karolherbst: k, now I understand what you mean
20:49karolherbst: Lyude: ohh, we don't expose it, if there is an error found ... wait a second
20:50karolherbst: Lyude: in drm/nouveau/nvkm/subdev/iccsense/base.c line 185
20:50karolherbst: "iccsense->data_valid = false;" make it true
20:50Lyude: karolherbst: gotcha
21:09Lyude: karolherbst: no dice
21:11Lyude: karolherbst: btw, mind if I take that clockgating card?
21:12Lyude: the post-fermi one, not pre-fermi (don't have the hw for pre-fermi unfortunately)
21:12karolherbst: Lyude: still no change? there should be a power entry though now
21:12karolherbst: ohhh wait, I am stupid
21:12karolherbst: guess what
21:12karolherbst: the "return NULL;" has to go as well
21:13karolherbst: Lyude: and no, you can go ahaead and take it :)
21:15Lyude: figured it'd give me a good intro into how that sort of stuff works on nvidia
21:15karolherbst: but could you try once again with the return NULL removed after the warn? :/ Allthough I expect, that the readings might be 0, I still kind of wanna know if we can actually use it
21:15Lyude: oh yeah i just finished reloading the mod
21:16Lyude: karolherbst: still nothing in sensors
21:16karolherbst: okay, now something is super wrong
21:16karolherbst: anything in dmesg?
21:17Lyude: karolherbst: https://paste.fedoraproject.org/paste/2g2ILGe-L4hTKY0LnqYQUF5M1UNdIGYhyRLivL9gydE= my whole dmesgbtw
21:17Lyude: in case I'm missing something silly
21:17karolherbst: Lyude: mind loading with debug=debug?
21:19Lyude: karolherbst: just to make sure you're talking about the debug option in nouveau's module right
21:19Lyude: k, let's see
21:21Lyude: karolherbst: https://da.gd/3JNS
21:21imirkin_: can you talk to whoever controls the fedora pastebin
21:22imirkin_: and inform them that the "end" key is a useful key
21:22imirkin_: oh, wow - the whole thing comes up as an editable thing, that's why it's messed up
21:22imirkin_:recommends using a diff pastebin
21:23Lyude: imirkin_: bleh, I honestly just use fpaste because it comes preinstalled and I can pipe text to it
21:23imirkin_: it used to be fine
21:23Lyude: yeah, they changed the service they use recently and i don't like the new one much either
21:23karolherbst: Lyude: uhm, by any chance, did you change the first or the second of ""iccsense->data_valid = false;"? :/
21:23imirkin_: this is a recent, uh, "improvement"
21:23Lyude: it lacks like, 90% of the syntax highlighting the old one had
21:24karolherbst: ... rephrasing needed, but meh
21:24imirkin_: sometimes i think people just sit there and think, "how can i annoy imirkin in the most subtle way possible"
21:24imirkin_: it's like a form of psychological warfare
21:24Lyude: karolherbst: second
21:24Lyude: line 185
21:24karolherbst: and you removed the return null in 187?
21:25Lyude: hastebin has a cli tool doesn't it?
21:25imirkin_: dunno. i just paste into it - easy enough - highlight + middleclick
21:25imirkin_: (and Ctrl+S)
21:25gregory38: imirkin_ do I need a recent version of xserver-xorg-video-nouveau
21:26gregory38: I have 1.0.11-1
21:26imirkin_: for ...
21:26imirkin_: yeah, you need .12 or .13, i forget
21:26imirkin_: yeah, .12
21:27karolherbst: ....... Lyude I am silly
21:27cytrinox: hi. is is possible to disable the warnings in kmsg/dmesg from nouveau: "nouveau 0000:02:00.0: DRM: skipped size 0"
21:27gregory38: thanks you for the info
21:27karolherbst: Lyude: find the mistake https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nvkm/subdev/iccsense/priv.h#L21
21:27imirkin_: cytrinox: yeah, just find the place where the kernel module logs that and comment it out
21:28karolherbst: Lyude: it has to be u16 of course...
21:28imirkin_: [or stop allocating zero-sized buffers... as that should never ever happen, it's definitely something to be concerned about.]
21:29Lyude: karolherbst lol
21:30karolherbst: I hope I didn't forget to replace it elsewhere
21:30cytrinox: imirkin_: it's flooding the kernel log while playing videos with mpv+vdpau
21:30imirkin_: are you using the GL output?
21:30Lyude: karolherbst: test again with the u16?
21:30karolherbst: Lyude: yeah, should work better with u16
21:30cytrinox: imirkin_: no, I use vo=vdpau
21:30gregory38: mareko: I'm sorry I won't be able to tell you for DRI3. I need to upgrade xserver-xorg-video-nouveau which then will likely require to upgrade xorg.
21:30imirkin_: well, with mplayer it all works fine.
21:31gregory38: So I think I should upgrade to the future Debian stable directly
21:31imirkin_: gregory38: nouveau should build against old X servers just fine
21:31cytrinox: imirkin_: I've found this message often via google, but no special question related, only "noise" from regular logs posted because of other failures.
21:32imirkin_: cytrinox: well clearly it's some kind of bug
21:32imirkin_: since a zero-sized-buffer should never be allocated
21:32imirkin_: and yet a request to the DRM is coming in
21:32imirkin_: asking for a zero-sized buffer
21:32gregory38: Ok. I will try but not tonight ;)
21:33cytrinox: I've this "issue" for years with my gentoo system, now switched to debian strecth this week and the same warnings appear
21:33cytrinox: yeah, make sense :)
21:33imirkin_: it's not like distros write their own software ... i don't see why you'd expect anything to be different with one set of backgrounds on your desktop vs another...
21:33Lyude: karolherbst: bad news :(
21:34Lyude: doesn't work at all
21:34karolherbst: it should
21:34gregory38: Hum the configure isn't happy: configure: error: Package requirements (xorg-server >= 1.8 xproto fontsproto libdrm ) were not met
21:34Lyude: karolherbst: also i am about to leave the office
21:34Lyude: i will try to remember to poke you when I get back
21:34imirkin_: gregory38: you're on a developer-hostile distro
21:34karolherbst: yeah, no worries
21:34Lyude: karolherbst: https://da.gd/1KcsI
21:34Lyude: anyway, see ya
21:34imirkin_: gregory38: i suspect you're missing headers
21:35karolherbst: Lyude: k, bye
21:35cytrinox: imirkin_: I have not checked the versions and gentoo/debian often include different patchsets, especially for X and drivers. so there was little hope that these warnings go away with another build ;)
21:35gregory38: ok better
21:35cytrinox: but now I assume the problem is mpv and its vdpau impl.
21:36imirkin_: cytrinox: so ... you were hoping that a small group of people responsible for hundreds/thousands of packages would have a better grasp on the issue than the people developing those packages themselves?
21:36imirkin_: cytrinox: either way, nothing wrong with hoping issues go away, but i'd hardly expect it
21:37imirkin_: cytrinox: this will require someone to debug where the requests for those zero buffers are coming from
21:37imirkin_: and figure out why it's happening
21:37imirkin_: i haven't seen it with mplayer -vo vdpau.
21:37cytrinox: imirkin_: no I was hoping that these warnings where introduced by one of the many patches gentoo uses for X/drivers :)
21:38imirkin_: ah - that's a much more logical hope
21:38nyef: The problem with hoping that issues go away is that they don't go away on their own: someone has to do the work.
21:38imirkin_: gregory38: success?
21:38gregory38: I think so, I just got a reset of my session when I overwritten the .so
21:39gregory38: libGL: Using DRI3 for screen 0
21:39cytrinox: nyef: but if I assume an issue was introduced by a patch from a specific distro and I change the distro (for other reasons)... ;)
21:41cytrinox: hm, I'll try to build mpv from master before any deeper look...
21:42imirkin_: it's nothing that mpv can do directly
21:42imirkin_: however it could be using the vdpau api "weirdly" that exposes a nouveau bug/shortcoming
21:42imirkin_: what GPU are you on btw?
21:42nyef: cytrinox: On the other hand, you've just given me a possible angle on one of my current software/driver problems, so thank you.
21:43cytrinox: imirkin_: VGA compatible controller: NVIDIA Corporation GF119 [NVS 315]
21:43imirkin_: ok, and i assume you've extracted the accel firmwar efrom the blob?
21:44cytrinox: have tried it with/without the firmware blobs
21:44imirkin_: i definitely don't remember any such issues with VP5. but my memory for such things can be short.
21:44imirkin_: [other than the h264 decoding issue, which affects all gens]
21:45cytrinox: search for "DRM skipped"
21:45imirkin_: well, vdpau on a G92 is extra-broken
21:45cytrinox: :D ok
21:46imirkin_: for some reason the bitstream decoding engine is DOA
21:46gregory38: mareko: DRI3 seem better but I would need to test it further to be sure
21:46imirkin_: only on G92, not on any other VP2-using chips
21:47gregory38: Will see tomorrow :)
21:47cytrinox: on the other hand, I can simply use vo=gl
21:48imirkin_: that kills the board much more reliably afaik
21:48cytrinox: I mean, everything is runnig fine, but dmesg becomes unusable with these skipped messages (hundreds/sec.)
21:49cytrinox: hm, better alternatives?
21:50imirkin_: cytrinox: debug where the stupid alloc comes from
21:53cytrinox: good idea ;)
21:53nyef: Heh. I'm reminded of trying to use the TRAP instruction on HPPA Linux. If it's not the specific form that GDB uses, the kernel reports an "oops", with full backtrace, but otherwise the semantics are fine.
21:56cytrinox: with vo=opengl there are only 1-3 skipped warnings during playback
21:57cytrinox: maybe it's not related to vdpau?
22:04cytrinox: hm it seems that is recommended to use opengl + hwdec=vaapi for mpv
22:09imirkin_: for maximal chance of GPU death, yes, that would definitely be my recommendation
22:09imirkin_: if you want vdpau-accel to actually work, use mplayer.
22:10AndrewR: anyone here tried qemu/virgl lately? For me (on 4.11-rc7 kernel compiled in 64-bit mode with 32-bit userspace at host, including qemu itself) it seems to work only with 64-bit guests ... on nouveau (with artifacts). 32-bit guest show kernel console/messages and then screen go black. (X + twm work, so, probably openGL usage by QT triggers this)
22:10imirkin_: virgl uses multi-threading afaik, which causes fail in nouveau
22:11skeggsb:should probably finish that work...
22:16AndrewR: should I add 'official' bug at freedesktop, and if yes - for mesa or for qemu?
22:16AndrewR: argh, qemu uses launchpad bugtracking
22:17skeggsb: i suspect in your case, it's not related to nouveau
22:18AndrewR: skeggsb, well, some time ago it worked with my own 'distro' (live DVD), it was 64-bit guest kernel + 32 bit guest mesa, but..for now I'm unsure was my host kernel 32 or 64...so, may be this is regression, but may be not.
22:21AndrewR: ah, well, there was no possibility of 32 host kern, because kvm need 64 host for 64 bit guest Linux ....on Linux ...x86.
22:21imirkin_: unless you're doing soft emu :)
22:22AndrewR: imirkin, soft tend to be ..'a bit' slow ....
23:59mooch2: would anybody here be interested in nv3 emulation in qemu?