00:41imirkin: ok, i know why xvmc doesn't show osd on nv30... an unsupported format is getting used for the subpictures. gr.
00:43imirkin: gr. this thing is just like explicitly designed to not work with nv30 :(
00:44imirkin: every choice it makes is the wrong one
00:47pmoreau: It is consistent in trying to fail :-D
00:47imirkin: well like the palette format is rgbx, while only bgrx is supported
00:48imirkin: and the surface format is l4a4 while only rgba4 or l8a8 is supported
00:48imirkin: now i'm trying to see if this is easily changed
00:49pmoreau: Good luck with that :-)
01:00imirkin: yeah. it looks doable. just ... a bit of work.
01:12imirkin: the whole R4A4 thing is annoying - it seems dumb to have to "manually" convert to 8-bit formats, but ... there's not some vastly better solution. i guess rgba4444 is going to half the memory.
06:20Manoa: is it normal for DRI3 to use mutch more CPU than DRI2 ?
06:27Manoa: on DRI3 the CPU used by Xorg is 2-4 times more, fps on DRI3 is higher but not by mutch, because of this situation CPU of core on which the Xorg runs reaching 100% and when this happen it reduces fps, can see it by GALLIUM_HUD
06:54pq: Manoa, and how much is the cpu-capped framerate with dri3 for you?
06:57Manoa: higher, from 222 fps to 230 fps
06:58pq: ah, not in the thousands, good - I mean, sounds like a valid question
08:02Manoa: I think this mybe because of my X server, I going to rebuild him and see what hapen
08:39Manoa: yep, now with the new X server I have less than 10% CPU used with DRI3 :)
08:40karolherbst: Manoa: forgot -O3? :p
09:14Manoa: no, forgot --enable-dri3 in the X server xD
10:21Manoa: how would I start about isolating stuttering problems ?
10:21Manoa: the strange ones, when fps is high but it feels very slow
10:25karolherbst: Manoa: any difference with vsync enabled/disabled?
10:25karolherbst: what about window manager?
10:25karolherbst: you could run without a window manager and see there
10:25karolherbst: play around with the window manager settings as well, because they also do some tearing prevention stuff in different ways
10:31Manoa: it's the DDX, weird: I tried all the options in nouveau's man page for device section, none worked, now I tried loading modesetting instead and the stutter is all gone, wtf ?
10:38Manoa: I was under the impression that nouveau was the best for nvidea as DDX
10:39Manoa: it possible that because I used a relatively new version of DDX for a X server that is relatively old (1.17.4) while the modesettings driver came with X server is designed more for that X server ?
11:21Manoa: is there a way to limit fps from mesa ?
11:50karolherbst: Manoa: not afaik
11:51karolherbst: Manoa: did you checked your window manager?
11:53karolherbst: Manoa: but I think I have to agree with skeggsb here. If modesetting gives you a better experience, just use this one.
11:54skeggsb: karolherbst: i understand imirkin's objections, the ddx *is* simpler and less potential problems than the 3d driver, but, the reality is - we aren't maintaining it, and modesetting outstrips it in basically every way
11:54karolherbst: skeggsb: I know
11:55skeggsb:would, ideally, like to make the f26 patch to switch to modesetting by default upstream
11:55skeggsb: but, that's not just my call :P
11:55karolherbst: somebody has to check the pros and cons
11:56karolherbst: and a technical standpoint has nothing to do witht hat. Personally, if something works better for the user, it's the way to go, even if there is a technical superior _idea_
11:56skeggsb: right :)
11:56karolherbst: if there is a better idea, do an implemention, which also _works_ better ;)
11:57skeggsb: i *will* finish the mesa multithreading stuff soon, which brings with it better recovery behaviour too
11:57karolherbst: nice :)
11:57skeggsb: but, fixing display issues has priority
11:57karolherbst: skeggsb: I posted new PMU counter patches, but this work was done mostly on saturday (I basically wrote it from scratch, except the debugfs parts)
11:57karolherbst: and I hit weird issues implementing the notification/thresholds part
11:57karolherbst: like registers were suddenly overwriten
11:57skeggsb: yeah, i did take a quick look when you posted it on IRC, but, i was heading to bed when i noticed it :P
11:58skeggsb: oh, that's... weird?!
11:58skeggsb: any idea what causes that?
11:58karolherbst: call(send) most likely?
11:58karolherbst: something there
11:58karolherbst: not _quite_ sure
11:58karolherbst: was too tired to figure it out
11:58karolherbst: but I couldn't see the same effect on the series I posted
11:58karolherbst: so the notifications are strongly related to the issues
11:59karolherbst: maybe some registers saving missed out?
11:59skeggsb: it appears to basically implement what we discussed, so, i'm happy with it once the bugs are ironed out :P
11:59karolherbst: the bugs don't hit there
11:59karolherbst: mhh, maybe reclocking might be able to mess it up?
12:00karolherbst: I will try to take a deeper look and see what is odd
12:00karolherbst: the issue just causes the actual loads to get overwritten, so super uncritical
12:00karolherbst: the kernel just got spamed with notifications about load being below 0x00..... at least that was the code I wrote
12:03karolherbst: skeggsb: at first I wanted to have a GET_SLOT(slot) interface like thing, but there was a good reason this didn't work out late, which I already forgot. I guess it was about sideeffects like you don't get all values from one readout, but they could be from severals... stuff like this. I also sent the raw values in the beginning, but this would only make the not reading out in one step thing more problematic
12:03karolherbst: but we can read out 8x 8bit values in one go, and we don't need higher precision anyway
12:08imirkin: skeggsb: not sure what makes you say that the ddx is unmaintained... when there are bugs identified, i will at least try to provide patches to fix it. i'd say it's more maintained than modesetting, since that relies on the GL driver and when that has weird issues, we just throw up our hands and say "weird, dunno". if you're talking about DP-MST... when someone shows up complaining that it's not supported, i'll figure out what
12:08imirkin: the 10-line patch is to enable it.
12:08karolherbst: skeggsb: also don't bother writing comments regarding line length and so on. I will push all patches to the kernel style checking script when cleaning up the patches
12:08imirkin: skeggsb: fact is, it requires a LOT less maintenance
12:09karolherbst: imirkin: it's not only about fixing bugs
12:09karolherbst: if user say, they have less problems with modesetting, then modesetting is what they should use
12:10imirkin: user should use whatever works best for them
12:10karolherbst: also, skeggsb pointed out, that the nouveau DDX can't really handle MST displays?
12:10imirkin: see what i said above.
12:10karolherbst: so that would be a feature which needs to be added to nouveau as well
12:11karolherbst: you are technically correct, but this is a terrible standpoint from a distribution perspective
12:11imirkin: when someone shows up willing and able to test it, i'll write the trivial patch
12:11imirkin: until then, i'm assuming that no one needs it
12:11karolherbst: I got told, that (modern) laptops use MST through dock stations
12:12imirkin: that they do
12:12imirkin: they also use intel IGP's
12:12karolherbst: not all
12:12karolherbst: some ports are jut wired to the nvidia GPU
12:12imirkin: enough that no one's showing up complaining about it :)
12:12karolherbst: on some even all
12:13imirkin: whereas for intel, the complaints started coming in pretty quickly
12:13imirkin: i'm not saying it's a useless feature -- it's quite useful. and it's not like MST isn't supported. just MST hotplug isn't supported.
12:13imirkin: which effectively means "laptop docks"
12:13imirkin: or rather, "laptops"
12:13karolherbst: aka important feature for some
12:13imirkin: and very few laptops have a DP port wired to the nvidia chip
12:13karolherbst: so it should be implemented
12:14imirkin: not arguing against it
12:14imirkin: just saying it's not as critical of a feature as some try to make it out to be
12:14karolherbst: I think the bigger problem here is that this isn't done proactively, but rather like "we are waiting for issues and fix it then" -> bad for distirbutions
12:14karolherbst: and if this stays this way, I would also rather use the modesetting ddx
12:14imirkin: well, interested distributions can pony up the hardware to test it with
12:15karolherbst: okay, so there is just basically lack of communication in the end
12:16imirkin: no, plenty of communication
12:16imirkin: too much of it, in fact
12:16imirkin: and unfortunately contradictory
12:16karolherbst: I don't see much of having too much communication
12:16imirkin: so people listen to who yells loudest, for they must be right
12:17karolherbst: this isn't about who is (technically) right though, but what works the best
12:17imirkin: let me put it this way - if someone shows up here with modesetting issues, i say "haha, you get what you deserve". anyone else is welcome to provide support to such users.
12:18karolherbst: that's a pretty arrogant answer
12:20skeggsb: not much more than my "use modesetting or i don't care" answer ;)
12:20karolherbst: I mean, I understand your standpoint and everything, still telling the user basically it's their fault to use modesetting isn't something which should like _ever_ happen
12:20karolherbst: skeggsb: :p
12:21imirkin: karolherbst: i'm not providing paid support to these people... this isn't a job for me... when open-source stops being fun it becomes an unpaid job.
12:21karolherbst: maybe the solution would be simple to have somebody caring enough to actually do a really good nouveau DDX, which is superior to modesetting?
12:21karolherbst: imirkin: same for me
12:21RSpliet: karolherbst: in a development project with less than a handful of contributors, this is what should happen all the time
12:22RSpliet: pick your battles
12:22imirkin: i have no way of debugging or reasoning about what GLAMOR does [which is really the issue... the modesetting thing is perfectly fine]
12:22karolherbst: RSpliet: I was more talking about attitude now though
12:23RSpliet: attitude is an extension of this observation
12:23RSpliet: no need to point-and-laugh, but neither is beating around the bush
12:23imirkin: well, i most likely wouldn't use those words with an actual person having an actual problem
12:23karolherbst: RSpliet: right
12:23imirkin: but the end-result would be the same
12:23karolherbst: imirkin: I know
12:28karolherbst: dunno. I think I just started to care about the project more than before and knowing that users might get annoyed by devs telling contradicting things in such a way (without having _good_ arguments) isn't something I really like to see. "use modesetting, cause maintained" or "use nouveau, cause less complex".... like the user cares about any of this. They don't. They care about what works and so this should be the
12:28karolherbst: focus of the reasoning.
12:29imirkin: use nouveau, coz stable
12:30imirkin: not sure how the reasoning of "modesetting is maintained" comes about. maybe the high-level driver is maintained. but the rest of the stack is ... not so much.
12:31karolherbst: general statements fall are also not quite good, cause they are never true
12:31karolherbst: "coz stable" -> "I found modesetting is bette rhere" -> "blah blah blah" ....
12:32imirkin: perhaps stable means diff things to diff people?
12:32imirkin: to mean stable means "doesn't crash"
12:32imirkin: [or hang the box]
12:36karolherbst: I really don't want this to get technical, I already said that from a pure technical standpoint you are right.
12:36pq: I'm certainly going to follow imirkin's recommendation and not buy nvidia next time I need a beefy GPU. Going to see what the color is on the other side of the fence.
12:37karolherbst: pq: or simply have one of each :O
12:37imirkin: that's definitely best all around
12:41dboyan: imirkin: What do recommend me to do these days? I've been busy with schoolwork these days but I think I can start doing some work from now on.
12:42imirkin: ah yeah, i've been busy too :)
12:43imirkin: dboyan: first, send out a thing to nouveau@ and mesa-dev@, saying who you are (although many will already know you from your prior contributions), and what you plan on doing. say what you've looked at, what kind of approach you're planning on taking, solicit advice, etc
12:44karolherbst: dboyan: I also have super crappy WIP stuff for the instruction scheduler stuff
12:44dboyan: yeah, that's a good advice
12:45karolherbst: it worked (tm), but didn't do any good in terms of performance
12:45dboyan: karolherbst: I knew that, although I haven't had time to look through
12:46karolherbst: wait a second.. I think I went uber smart and did a "ohh dboyan will work on that, so I can remove that branch"....
12:46imirkin: dboyan: ftr, my "job" of mentor isn't so much to tell you what to do, as much as help direct your efforts in the right directions and grease the wheels of communication, so to speak.
12:46karolherbst: imirkin: well you don't have to do any technical related at all
12:47karolherbst: everybody could give directions to the technical problem, that's the "normal" job of the community
12:47karolherbst: even with a GSoC project
12:47imirkin: dboyan: that said i'm also the (relative) domain expert on nouveau codegen, so i'll also be helping you with that, but not with my mentor hat on.
12:48dboyan: yeah, I get what you're expressing.
12:48karolherbst: I think I removed that branch... silly me
12:48karolherbst: oh well
12:51dboyan: There are mainly two works for now: learn about instruction scheduling itself, or come up with metrics to measure (with performance monitor)
12:52karolherbst: dboyan: one thing up ahead: don't do "1 month learning phase + 1 month implementing phase + ...."
12:54karolherbst: best would be to work on the basic infrastructure to do instruction scheduling at all. Implement it in a way, that you can play with _any_ algorithm to pick instructions to schedule and make sure there is no regression
12:54karolherbst: that's what I basically did
12:55karolherbst: if this is done and implemented, you could start to implement an algorithm according to some theories/etc... and messure that. But best would be to not push the implementations phases back, "cause I have to read up on stuff"
12:55dboyan: ok I think I will study passes in codegen first
12:55karolherbst: start of the project is kind of start of june, isn't it?
12:56karolherbst: or is it already now?
12:56dboyan: officially starts on may 30
12:56karolherbst: I think it's community bonding, isn't it?
13:14RSpliet: dboyan: did you bookmark the few resources I linked on insn scheduling for CPUs in the past few weeks? There's one in the trello card that could be interesting to bear in mind the more advanced challenges. I think there's some lecture slides @ Cambridge uni that could provide a bit of insight in the basics
13:15RSpliet: (explaining analysis, optimisation targets and the conflict between instruction scheduling and RA)
13:16dboyan: Yeah, I saved some docs you mentioned
13:16RSpliet: I can dig that latter one up if you please, unless you found more interesting resources on the topic already :-)
13:16karolherbst: mhh, maybe he should start somewhere before that. That's what I wrote and what imirkin also told me to do in the past when I tried to work on that: keep track of live values (aka a list of schedulable instructions) and check if you can schedule them in random order without breaking anything
13:16karolherbst: in SSA form this is much easier, but I actually did this after RA
13:17RSpliet: karolherbst: that requires the right analysis. Don't know whether codegen already has the right kind implemented
13:17karolherbst: RSpliet: true, but this is unrelated to any paper usually
13:17karolherbst: and of course it has
13:17karolherbst: it's just not there useable with a simple method
13:18karolherbst: you can reorder instructions in codegen already, sometimes you simply break things
13:18karolherbst: dboyan: also, this needs to be done on a per BB base
13:18karolherbst: so you can't move things into different BBs
13:19dboyan: karolherbst: yeah, basic block scheduling is the most basic form
13:19karolherbst: and then there are things like "fixed" instructions, bra at the end of BBs (SSA, not always the case post SSA), phi at the beginning (SSA)
13:19karolherbst: dboyan: we can't do anything else anyway I think
13:19karolherbst: or it would be _too_ complicated
13:20karolherbst: we could have other passes moving instructions into other BBs to optimize loops and so
13:20karolherbst: we don't need to do it in a scheduler pass
13:21karolherbst: allthough if statements might remove too much freedom actually
13:21RSpliet: karolherbst: your "of course it has" implies you know which of (live variable, available expressions, reaching definitions, very busy expression) analysis you need, and verified it's implemented ;-)
13:21karolherbst: RSpliet: ohh, I thought you meant the basics needed to write that
13:22karolherbst: dboyan: important is, that the results doesn't need to be "perfect", so focusing on scheduling inside BBs for now is a good idea? dunno, I let imirkin decide on such project details
13:23karolherbst: and imirkin needs to stop me when I talk too much about GSoC stuff, because the project I wanted to mentor didn't work out, so I still have too much motivations left to help out
13:24dboyan: I think scheduling within bb is the first step, and I think is what most open drivers do
13:24RSpliet: dboyan: I agree ;-)
13:24karolherbst: dboyan: beware the shaders with more BBs than instructions!
13:25RSpliet: crossing BBs means reiterating on liveness analysis, sounds expensive
13:25karolherbst: well maybe I nevver saw one with more BBs, but close
13:25karolherbst: got one once with 300 BBS and 400 instructions....
13:26karolherbst: RSpliet: not if you can express inter instruction dependencies and can just run analyses over all possible instructions at once
13:26RSpliet: karolherbst: you still need the in- and out-sets per BB to be valid to do proper RA
13:26karolherbst: aka you can express the graph inside those depenencies
13:27karolherbst: RSpliet: sounds like a good abstraction to me
13:29RSpliet: shaders with 300BBs and 400 insn either do too much branching, or nouveau codegen does something naively. Either way they sound like a hopeless corner case to deal with at the insn sched level ;-)
13:31MikeB_: Hello. I'm still learning how VDPAU uses hardware h264 decoding with nouveau. I hope you don't mind me asking a few more trivial questions.
13:31MikeB_: I understand that when it comes to video decoding there is no open-source implementation and blobs extracted from nvidia drivers are used instead.
13:31karolherbst: RSpliet: just a crap load of ?: which gets optimized away and leaves empty BBs
13:31MikeB_: May sound silly, but what I don't get at all is what uses these blobs from /lib/firmware/nouveau/ - is it VDPAU or Nouveau itself?
13:32karolherbst: MikeB_: the kernel module
13:33RSpliet: karolherbst: completely empty BBs isn't a big issue. Whether you're optimising 300BBs of which 200 are empty or 100 BBs isn't going to make a big difference
13:33RSpliet: not in the end result at least, it might have a very modest impact on compilation time :-)
13:33karolherbst: but there are enough passes to check for BBs...
13:33karolherbst: and don't do opts if instructions are in different BBs
13:33karolherbst: and if every BB in between is empty....
13:34RSpliet: it might be nice to see if you *can* cull and merge BBs, but that sounds like an orthogonal problem
13:34karolherbst: I tried that already
13:34karolherbst: was messy
13:34RSpliet: the code, or the problem? :-P
13:34karolherbst: Flattening couldn't deal with it leaving joins randomly
13:35karolherbst: the code is basically done, just cleaning up the fallout wasn't something I found worth enough to care more about this pass
13:36imirkin_: MikeB_: the nvidia gpu is a complex beast
13:36RSpliet: would you know whether NVIDIA supports conditional (predicated) execution. I recall it does, and that might help reduce the number of BBs further
13:36imirkin_: it is composed of multiple sub-parts, called engines
13:36imirkin_: each engine is, in turn, also a complex beast
13:36karolherbst: RSpliet: predicated executions are still BBs in nouveau
13:37RSpliet: karolherbst: for now ;-) Another cool project to add to the Trello board!
13:37karolherbst: that's why I wrote that bras are not always at the end of a BB in post SA
13:37imirkin_: the video decoding engines have (a) a mini-cpu and (b) a complex fixed function engine to do the decoding
13:37karolherbst: RSpliet: but basically the instruction setting the predicates becomes the bra instructions, so ...
13:38imirkin_: the firmware is for that mini-cpu to run a RTOS on to take in commands from the fifo engine and twiddle the proper bits on the internal fixed function engine
13:38imirkin_: dboyan: when looking at generic compiler stuff, listen to what RSpliet says, not me :)
13:39imirkin_: dboyan: i have some ideas about how to make it go, but i haven't read a ton of literature about it all
13:39karolherbst: RSpliet: also, we do that bra elimiation in RA I think
13:39karolherbst: or somewhere after doing the SSA opts
13:41MikeB_: Then I'm totally lost. F.e. I've got nouveau, vdpau and mplayer. When I run h264 movie with -vo vdpau -vc ffh264vdpau what's the "calling-chain" ? Mplayer -> VDPAU -> ?? -> firmware nv blob -> ??
13:43imirkin_: MikeB_: perhaps you can give a bit of background about yourself, and i can tailor the answers in a way that you can better understand? i mean like level of familiarity with these sorts of things.
13:43karolherbst: MikeB_: it still goes through mesa and the nouveau parts of it and the novueau kernel part
13:43karolherbst: MikeB_: but the firmware still runs on the engines on the GPU
13:50MikeB_: Most thankful for that. imirkin_ :Starting from the begining I'm an IT student and for one of my classes I'm supposed to prepare analysis of the way how nvidia cards decode h264 videos + some use case examples. To be honest I have no experience with hardware and low-level programming.
13:50imirkin_: gotcha. so then your questions/confusion makes sense :)
13:51imirkin_: so, at a high level, there's a video decoding engine, and you feed it data, and it feeds you NV12 frames
13:52imirkin_: the data you feed it are, iirc h264 NAL type 5 ... NALs
13:52imirkin_: along with the decoded picparm/etc settings
13:52imirkin_: you also have to keep track of things like reference frames and such for its decoding
13:53imirkin_: the surrounding vdpau implementation logic does all that, and the vdpau api takes that data in
13:53imirkin_: it's pretty much 1:1 at that level -- what vdpau feeds you is precisely what the hw needs
14:10MikeB_: but the only part of code of vdpau we can see are headers with some usage description? There's no info how GPU's engine uses the data provided via vdpau? What I'm missing the most is the part where the actual decoding process is called and how (where inside the code) nouveau followed by blobs extracted from nvidia drivers are used by vdpau. (Propably my view on the whole infastructure is too narrow)
14:13imirkin_: vdpau is an api
14:13imirkin_: there are two sides to the api
14:13imirkin_: there's the client application, e.g. mplayer, and the api implementation
14:13imirkin_: in this case the api implementation ends up being provided by mesa
14:14imirkin_: the blobs are necessary to make the hardware go, but they have nothing to do with vdpau or any API's.
14:14imirkin_: the blobs run on a CPU *inside* the GPU chip, not on the system cpu
15:27imirkin_: skeggsb: so briefly, what do i have to get VPE1 working? just make some nvif for command submission and that's it right?
15:43imirkin_: skeggsb: and all that would do is take a userbuffer of commands and copy them into the "global" ring of commands
15:43imirkin_: skeggsb: iirc that fifo has no way of jumping around, although i'll double-check
15:48imirkin_: skeggsb: or should i do something more like where you have to send a separately nvif() cmd for each op? i'm thinking just a single buffer makes most sense. although the DATA_SEEK command could potentially be dangerous? dunno
15:51imirkin_: skeggsb: i'm doing this with an eye to a separate libXvMCnvpe1.so or something, entirely outside of mesa, which uses Xv for display. (and then there's another part of this plan which would use overlay planes for xv)
16:11Mortiarty: i got vdpau acceleration to work on an G84GLM [Quadro FX 570M] with kodi but I have trouble watching anything with vdpau acceleration. This is, what the kernel spits out: https://pastebin.com/9VRuwrm2
16:13imirkin_: Mortiarty: try mplayer
16:13Mortiarty: Well - I mean it compiled all and everything seems fine... only kodi stutters first and hangs and/or terminates
16:27imirkin_: Mortiarty: the issue i believe is that kodi tries to use GL to display the video, in a separate thread, and nouveau doesn't handle that
17:04Manoa: I have no problem with using the nouveau DDX, on the other hand I whant a full windows replacement so I could use Option "stutter" "false", to that end if you need testing, now that I am on linux all the time, I can do some no problem, I know compiling very good and dont have problem with compiling code, even some modifications too, and yhe I knew nouveau DDX is the best for nvidea, it always was, that being said, now that I use modesettings it very afraid
17:04Manoa: me to have system crash :x
17:05imirkin_: Manoa: are you using DRI2 or DRI3 when you experience the stuttering with the nouveau ddx?
17:05imirkin_: what happens if you use DRI2?
17:05Manoa: the problem is the same
17:05imirkin_: hrm =/
17:06Manoa: I tried all documented DDX options none of them had any effect
17:07imirkin_: well - use what works best for you - nothing against that
17:07imirkin_: GLAMOR flushes a *ton*, so perhaps it just papers over some issues
17:07Manoa: uhm I thing the log sayd EXA
17:07imirkin_: with modesetting, it's glamor
17:07Manoa: when I tried to turn on glamor it didn't take the option
17:07Manoa: mybe that the problem ?
17:08Manoa: I meen with the nouveau
17:08imirkin_: re-read what i said.
17:08Manoa: ok thx
17:09Manoa: this meens that one of the reasons modesetting is not good is because it use glamor ? Im not sure I understand :x
17:11Manoa: so you think it the (lack of) flushing that cause the nouveau DDX to stutter ?
17:13Manoa: you are sure that there is no chance of incompatibility between version of X server and the nouveau DDX ? because they are quite far apart in terms of version, the DDX is very recent got it from git just a week ago, while the X server is 1.17.4
17:14Manoa: whay the nouveau DDX doesn't take the option accelmethod "glamor" ? if glamor workx for modesetting whay not use it also for nouveau ?
17:14Manoa: mybe that the problem
18:02Mortiarty: imirkin_, mplayer with vdpau works to a certain degree.. mpv too, but only with xv and hwdec=vdpau. All in all it does not matter which program. vo=vdpau or hwdec=vdpau lets the system freeze often too
18:03imirkin_: Mortiarty: mplayer -vo vdpau should work fine. everything else won't.
18:03imirkin_: to be clear, when i say 'mplayer', i really do mean 'mplayer', not 'fork of mplayer which breaks various functionality'
18:05Mortiarty: imirkin_, ok - i just thought i give it a try :D
18:06imirkin_: ok :) so no mpv, no mplayer2, no not-really-mplayer
18:11leberus: mupuf: Hi. I just though something. What about if all therm->attr_get/attr_set ops are being done within nouveau_temp/fan/in/pwm_read/write functions? So we could remove all other functions like nouveau_hwmon_critical/emergency/max/min_temp, nouveau_hwmon_get_in0_min/max/input. As you suggested for nouveau_hwmon_set_pwm1/_enable.
18:11imirkin_: Mortiarty: i haven't seen hangs in mplayer
18:11imirkin_: that said, i don't use vdpau a *ton*, and esp not on those older gpu's
18:11mupuf: leberus: not so sure how it would look like, give it a try :)
18:18leberus: ok, sure
18:33Mortiarty: imirkin_, alright. mplayer with vo=vdpau works. and just mplayer - as you stated :D
18:34imirkin_: ok cool
18:48Mortiarty: imirkin_, just checked dmesg and found a lot of these entries: [Mon May 8 20:32:27 2017] nouveau 0000:01:00.0: fifo: CACHE_ERROR - ch 5 [mplayer] subc 2 mthd 0628 data 002038b0
18:48Mortiarty: [Mon May 8 20:32:27 2017] nouveau 0000:01:00.0: fifo: CACHE_ERROR - ch 5 [mplayer] subc 2 mthd 062c data 00040000
18:48Mortiarty: [Mon May 8 20:32:27 2017] nouveau 0000:01:00.0: fifo: CACHE_ERROR - ch 6 [mplayer] subc 2 mthd 01b8 data beef0201
18:49Mortiarty: imirkin_, should that bother me?
18:49imirkin_: a little...
18:49imirkin_: i think it's related to an undiagnosed issue across all tesla-family cards
18:52Mortiarty: ok nevermind. I have been watching movies with kodi and opengl and that worked quite well... only now i wanted to see some 1080p clips and they lag so gave vdpau a try... which lagged too... so i will go back to opengl with kodi then. thanks for the support
18:53imirkin_: that CACHE_ERROR thing will happen with everything tho
19:01AndrewR: imirkin, hello. I saw your patch for st/xvmc (for making OSD work on nv4x). I tried it on my main machine/card (nv92 pcie) but unfortunately it seems to hang after few seconds of playing (probably hang unrelated to pacth itself, it was hanging before, but apparently after longer play. OSD from mplayer was visible for few seconds it played normally, with NOUVEAU_PMPEG=1 set for speed). Does your nv92 still play at least mpeg2 w/o hanging?
19:02imirkin_: AndrewR: from what i could tell with my nv92, the VP engine works just ifne
19:02imirkin_: AndrewR: which means that mpeg2 should decode just fine with both the VP2 engine and PMPEG
19:03imirkin_: AndrewR: i do have one plugged in, i was going to play with it tonight
19:04imirkin_: AndrewR: it's possible i messed something up with that patch
19:04AndrewR: imirkin, then I probably have more problematic nv92. Does your mplayer set for multithreaded decoding by default? I have threads=4 in mplayer config for faster software decoding, for h264 on different card it printed warning about unstability of such combination, not sure if it also applies to xvmc + mpeg2
19:04imirkin_: oh, threads will definitely destroy the universe
19:04imirkin_: i didn't know that mplayer supported such a beast
19:05AndrewR: imirkin_, lavdopts=threads=4 in ~/.mplayer/config
19:42marc_: Does nouveau support CUDA?
19:48karolherbst: marc_: no
21:05Lyude: btw, anyone know if that vulkan skeleton driver for nouveau ever got posted by skeggsb?
21:06imirkin_: i'm not aware of it.
21:06airlied: not sure he's written any of the skeleton yet
21:06Lyude: just curious
21:08airlied:mostly remembers the typing at that stage
21:17pmoreau: RSpliet: Grrrr… I found more bugs with my memory handling: It works fine for global memory, but not always for local. :-/
21:18RSpliet: pmoreau: :-( Well, I hope I gave you some nice challenges :-P
21:18pmoreau: Yeah :-D
21:18RSpliet: Any particular cases that fail?
21:19pmoreau: Indexing an array of local memory defined in the kernel. But indexing if it was dynamically outside the kernel works
21:21leberus: mupuf: I've sent v6 with the fixups. I've added you as a reviewer ;)
21:21pmoreau: It comes from the indexing process: I add to the pointer an offset, which works fine for the second case above, as the address is stored in a register. But in the first case, I end up with `add $r4 s[0x0] 0x00000004` for example, which is slightly different from `add $r4 $r5 0x00000004`, with $r5 containing the inital offset in s.
21:22karolherbst: leberus: if you have to tell the persons you've added them as reviewers, you did something wrong
21:22karolherbst: leberus: even the persons says it is okay, or it isn't okay
21:23RSpliet: karolherbst: but if the person says "with these comments addressed, the patch is: Reviewed-by: XYZ <XYZ@ABC.COM>", then it sounds fair to me to follow those instructions
21:24RSpliet: which is precisely what mupuf said
21:24karolherbst: RSpliet: true
21:25imirkin_: pmoreau: the way indirect addressing is hadnled is a bit weird
21:25imirkin_: pmoreau: should probably use the various helpers :)
21:26imirkin_: only the offset is stored in the Value*, while the indirect components are stored in the Instruction (and maybe ValueRef, but i'm not even sure)
21:26pmoreau: imirkin_: What? Somebody had the problem before, wrote a solution for other to use, and I should be using that? Madness, I say! :-p
21:27pmoreau: I haven’t had a look at the code handling TGSI yet, for the indirection. I remember being confused about it, and never looked further… Maybe now is the time :-)
21:27imirkin_: there can also be multiple dimensions of indirection
21:28imirkin_: e.g. inside a constbuf and across constbufs
21:28pmoreau: Jus to confuse you even more? :-D
21:28imirkin_: pretty much
21:28pmoreau: Seems like a reasonable goal
21:29imirkin_: with some success, i might add
21:30pmoreau: ah ah
22:16pmoreau: Seems that the TGSI code is manually tracking that using SrcRegister and DestRegister classes. I’ll probably do something similar too.