00:00imirkin: wait what? you're *manually* toggling the gpio to achieve the pwm?
00:00mupuf: IIRC, it was at a tick resolution
00:00mupuf: sure, on some old GPUs, we have to
00:06imirkin: that's crazy
00:06mupuf: THIS. IS. NVIDIA!
00:06imirkin: anyways, i think there is a workqueue mode that's the highest priority...
00:06imirkin: 300? :)
00:06imirkin: [or the south park...]
00:07imirkin: Les Bos
00:07mupuf: yep, that was a cool episode too
00:07mupuf: imirkin: well, I still need to get the callback called at the right time
00:07mupuf: and I do not think linux allowed for an accuracy higher than a tick
00:08imirkin: well, i guess i'm not clear on what the requirements are
00:08imirkin: i guess my point is... if you want to make a kworker, you better be sure nothing else can handle your needs
00:08imirkin: coz you're gonna be in for a fun time getting hibernate and such to play nice
00:10mupuf: ok, I will read up on it
00:10mupuf: but my process can be interupted any time
00:10mupuf: as long as it starts again :D
00:10imirkin: kworkers are funny.
00:10imirkin: i don't know all the constraints.
00:11imirkin: perhaps you can just set it to interruptible and then hibernate becomes all happy again
00:11mupuf: well, seems like I am in for a treat...
00:11imirkin: but ... i don't understand -
00:11mupuf: so, as for the diagnostic
00:11imirkin: if you need better than tick accuracy
00:11mupuf: the bios does not say how to drive the card
00:11imirkin: how can you end up doing it without just monopolizing the cpu?
00:11mupuf: nouveau reverts to reading what is in the perf table
00:11mupuf: imirkin: by having a kworker and sleeping in it
00:12mupuf: with sleep_range()
00:12mupuf: it is not ok to sleep in a workqueue
00:12imirkin: ok, but that'll just yield and you'll go back to your 1-tick accuracy
00:12mupuf: well, it is, but not if you never give back control
00:12mupuf: fortunately, the linux kernel is not tied to the ticks anymore
00:12mupuf: except for some old interfaces
00:13imirkin: mmm... i thought that was more around the ability to *skip* ticks
00:13mupuf: that was the first step
00:14imirkin: when was HWSQ added?
00:14mupuf: nv40 seems about right for HWSQ
00:15mupuf: hwsq does not have flow control, no loops!
00:16mupuf: there is no shying away from this :s
00:16imirkin: it couldn't have been the expectation that the kernel would flip the thing accurately at a rate of 10hz
00:16imirkin: i guess 10hz isn't so bad
00:16imirkin: 10khz would be bad.
00:16mupuf: well, it is 20 wake ups per second
00:16imirkin: that's not great, but it's well within doable range
00:17imirkin: so the reason that wq isn't a match is the timing aspect of it?
00:17imirkin: can you set a target time on a wq item?
00:17gsgf: The best single-gpu nvidia card you can get for money without signed nvidia crap is the Titan Z, right? Cards like the Nvidia 750 TI (GM107) need signed crap, right?
00:18imirkin: mupuf: there's a queue_delayed_work which takes a delay
00:18mupuf: imirkin: yep, and the delay is specified in ticks?
00:19imirkin: gsgf: GM107 does not require signed firmware. GM20x does.
00:19imirkin: mupuf: damnation. yes.
00:20mupuf: imirkin: I would have been glad if you could have proved me wrong though :s
00:20mupuf: sleep_range is the only solution I know ... and that requires a kworker :s
00:20imirkin: mupuf: well, more specifically jiffies. i think jiffies == ticks.
00:20imirkin: right, you can't sleep in a wq
00:20mupuf: you can, but you shouldn't block forever
00:20mupuf: which is what I need to do...
00:21gsgf: imirkin: thanks for the information. So Titan Z is still fastest card for nouveau to run without signed blobs. Titan X is
00:21gsgf: not possible any more
00:21imirkin: gsgf: not 100% sure - GTX 780 Ti might be faster.
00:21imirkin: gsgf: or hypothetically a K80. i know fairly little about that gpu.
00:21mupuf: or I could just be an ass and have an active wait for the ON time, switch to OFF, schedule another update, then wait the needed time before starting again the ON time
00:21mupuf: but hey, this is really ugly
00:22gsgf: imirkin: thats why i asked about single gpu. K80 is just two K40/780ti/titan-Z
00:23imirkin: is it? i wasn't sure.
00:24gsgf: yes, i read that before some minutes collecting informations before asking here :)
00:24gsgf: its like the AMD 7990 thats also just two 7970 cards
00:24imirkin: do note that nouveau doesn't support a lot of stuff... like CUDA or OpenCL. not sure what your goal is.
00:25imirkin: if you're looking for good open-source support, definitely would recommend AMD
00:27gsgf: what a huge FLOSS community would really LOVE to see is a free VBIOS replacement like this here tha noone seems to have really tested: https://sourceforge.net/p/openradeonbios/wiki/Home/
00:28mupuf: well, my patch is ... saying a giant fuck off to the BIOS whem it does not tell us what to do
00:28gsgf: then there would be a fully free device. free drivers and vbios. the AMD cards require closed microcode for longer time :(
00:29imirkin: does that matter?
00:29gsgf: mupuf: does nvidia cards work without vbios like some VIA and intel cards does?
00:29imirkin: are you concerned that the ASIC designs aren't open either?
00:29mupuf: imirkin: well, there was a time when Ben asked me to care about following the vbios to the letter
00:30mupuf: I guess this time has changed and a last-resort solution sounds like a good fallback
00:30imirkin: that was directed to gsgf, not you.
00:30mupuf: ah, ok
00:30gsgf: imirkin: i dont understand why they didnt open the ASIC design after for example 10 years to everyone under cc-by-sa
00:31imirkin: asic design is pretty much the same as the firmware
00:32imirkin: it's things they didn't feel like storing on the card itself, so you have to store it on your hd. doesn't seem like such a huge deal.
00:32imirkin: [i think the radeon situation may be different with atombios actually containing x86 executable code, which is not firmware.]
00:33gsgf: i think you can get many information out of the opensource implementarion of the atom bios here: https://sourceforge.net/projects/openradeonbios/
00:45mupuf: well, patch submited
00:45mupuf: now, I should probably prepare for going to sleep!
00:49gsgf: thanks a lot!
00:58mupuf: I really need to install icecast to reduce the compilation time of mesa on the g86 laptop
00:58mupuf: 26 minutes to compile something that should take 3 minutes is really too long
00:58mupuf: that means only 2 steps of bisect / hour
01:00gsgf: mupuf: did i understood right, that NV20 and older are technically not possible to controll their FANs?
01:05gsgf: see us :)
01:05gsgf: thanks again
08:34mupuf: this commit (https://cgit.freedesktop.org/mesa/mesa/commit/?id=b04ef3c) regressedspec@ext_framebuffer_multisample@accuracy all_samples color small depthstencil
08:34mupuf: from pass to fail
08:34mupuf: same for spec@ext_framebuffer_multisample@accuracy all_samples srgb small depthstencil
08:45karolherbst: mupuf: I guess your laptop told you?
09:01Jaga: I was checking nouveau reverse engineering documentation online and found that nouveau pages haven't been updated in 2-3 years, I think you might want to do something about that
09:02mupuf: Jaga: nouveau pages?
09:02mupuf: you mean the wiki?
09:03Jaga: mupuf: this for example https://nouveau.freedesktop.org/wiki/REnouveau/
09:03Jaga: "Last edited Sat Aug 24 18:49:22 2013"
09:04Jaga: not to mention how low it comes up in google search results >_>
09:05Jaga: (on a fresh browser session in private mode, no cookies, history or cache)
09:05mupuf: well, it is absolutely useless anyway
09:05Jaga: is it? so the info on the page is not up to date anymore?
09:05mupuf: it is, the tool has just been superseeded
09:06Jaga: then do update it with recent info :p
09:06pmoreau: mupuf: You should have a link to the valgrind-mmt page
09:06mupuf: we would never ask you to do a renouveau trace, so not an issue
09:06Jaga: especially if you're seriously gonna have a workshop at 33c3 :p
09:06mupuf: well, it is a much better use of everyone's time to write documentation on how to do stuff, rather than keeping useless pages noone reads up to date
09:07Jaga: well, at least updating the page jumps it in google search results from second page to first! still as the 7th item
09:07Jaga: mupuf: isn't that supposed to be the "how to do stuff" page?
09:07mupuf: pmoreau: done
09:08mupuf: is there such a page?
09:08pmoreau: mupuf: Thanks :-)
09:10Jaga: mupuf: idk, but why are you asking me?
09:10mupuf: well, you never know :D
09:10mupuf:may have missed it for years
09:14pmoreau: https://nouveau.freedesktop.org/wiki/Development/ has links to most of the relevant pages regarding REing and high level view of the driver, but I don’t think there is one that will tell you: "If you want to RE the kernel driver, use MMIOtrace + demmio; if you want to RE the userspace par, use valgrind-mmt + demmt."
09:19karolherbst: mupuf: awesome :)
09:20karolherbst: Jaga: yeah, we have like no kernel doucmentation as well … I know, we are bad
09:21Jaga: karolherbst: if you want to do the workshop, you'll have to do the documentation tip top before it
09:22Jaga: and it will be helpful for the future too
09:22karolherbst: … I know
09:22karolherbst: I am pretty much close to do that anyway, not close enough tnough
09:22Jaga: karolherbst: do you need a kick?
09:22karolherbst: but maybe I turn that workshop into a "crack secure boot" competition instead :D
09:23karolherbst: and the price will be glory forever!
09:23Jaga: why not both?
09:23karolherbst: and a "special thanks to" for 3 years in presentations!
09:23karolherbst: Jaga: well, that is the introduction part for the competition ;)
09:23Jaga: last event somebody was sitting cracking some gaming console to run linux
09:25karolherbst: I guess the newest runs or rather old ones?
09:26karolherbst: mupuf: run linux on a falcon! :O
09:26Jaga: something that hasn't been done before iirc, can't remember details
09:26mupuf: karolherbst: how about just explaining how to use our tools
09:26mupuf: and then aim at video encoding?
09:27Hoolootwo: you can run linux on a badger, but it would be very different to run it on a falcon
09:27karolherbst: Jaga: it was the ps4 :)
09:27mupuf: otherwise, just show the trello
09:27mupuf: and be like: Here you go!
09:27karolherbst: mupuf: no idea, didn't think it through yet
09:28karolherbst: Hoolootwo: sure, but still.. I think those flacons are too small anyway, except the PMU maybe
09:29mupuf: karolherbst: you can put the code in the vram
09:30mupuf: but we do not support this yet
09:30karolherbst: ohh, I see
09:30karolherbst: well, wouldn't it make more sense to have the kernel in the falcon and put the processes into vram?
09:31Hoolootwo: I think a falcon would have specific advantages over a dead badger, such as being able to fly, but I'm not sure if the hardware is supported yet
09:32Hoolootwo: (in reference to http://www.strangehorizons.com/2004/20040405/badger.shtml )
09:33karolherbst: Jaga: but yeah, I am all for it to finally be not annoyed by the secure boot thing anymore. I just have to hope that enough people are driven by the challenge itself to actually help out
09:33karolherbst: but then again, who wouldn't!
09:36Jaga: karolherbst: you will have to provide as much info in advance as possible and maybe start advertising it before the event itself tho
09:36Jaga: so it's going to be some work to get people into it I think
09:37karolherbst: yeah I think I will actually write some stuff
09:37karolherbst: still have to fix a nasty mmiotrace bug though :/
09:38Jaga: and the more well documented an OS project is, the more people are likely to join in
09:39karolherbst: yeah, I hope so, I doubt this will be that much true for nouveau, but yeah, it should improve things a little
09:40karolherbst: there aren't actually that many tools which are important for general usage, so
09:42karolherbst: mupuf: anything I miss besides mmiotrace, mmt and envytools?
09:42karolherbst: well maybe userspace nouveau might come in handy
09:42mupuf: yeah, there is everything
09:43karolherbst: Jaga: we have a little here as well: https://envytools.readthedocs.io/en/latest/
09:44karolherbst: but yeah, we should document somehow the binaries, they also miss a lot of --help things as well
09:45Jaga: karolherbst: if that page is more up to date, you might want to link to more visibly in your main page
09:46Jaga: also an into on the page would be nice, so people don't have to do detective work on the contents list
09:47karolherbst: mhh maybe we are already at the point where we should think about making complete new pages and just reuse what is useful
09:47karolherbst: allthough most pages are fine
09:47karolherbst: just heavily outdated
09:47Jaga: if they're heavily outdated, do make new ones, update, reuse and keep a habit of keeping them up to date
09:48Jaga: like, checking on them every half a year at least and updating steadily
09:49karolherbst: I know what we need! We need somebody dedicated to external documentation! :D
09:50karolherbst: otherwise as a dev I would also think it is a little bit of wasted time, cause I could use the time for REing things
09:51Jaga: karolherbst: you do know best how to do stuff, having somebody who doesn't trying to explain stuff might end with bad results
09:53karolherbst: I can explain things!… but yeah, we really should write it down :/ but explaining tools should be rather simple
09:53karolherbst: still, it would be nice to have somebody, who wants to deal with stuff like that and shout at us if something is missing or so
09:53karolherbst: just like you do! :D nice, person found
09:54Jaga: I'm nice enough to point things out to you, but I don't have the knowledge to do anything the stuff for you
09:58karolherbst: nah, just the pointing things out is enough
09:58karolherbst: this already helps
09:59Jaga: s/the stuff/of that stuff/
10:10karolherbst: I would really like to improve the situations with being understaffed all the time :) but personally I often fail to judge which are the points where somebody just stops wanting to help out, because they usually don't tell us why
10:11karolherbst: and if you see some points where you start to think "this sucks, I don't wanna anymore", then we would actually have some pointers what to improve, as we usually don't look up things anyway, or at least I don't
10:15karolherbst: well maybe I will find some time to write something today. Lets see if we have something related to vbios REing
10:15karolherbst: the dumping video bios page is outdated as well
10:16karolherbst: so I have a plan for this week!
10:16karolherbst: mupuf: any idea if that sysfs or dd dumping still works?
14:01pmoreau: karolherbst: And there is the fact that, once you have enough experience to start writing documentation, you kind of forgot what you missed when you started.
14:03pmoreau: One day (TM) I will fix my wiki access…
14:05ajax: is it not just git clone ssh://wiki.freedesktop.org/src/ikiwiki/git/nouveau ?
14:06karolherbst: pmoreau: :D
14:06pmoreau: ajax: Well, I only had an HTTPS access to it (no freedesktop account), and managed to lose the password. I might still have it somewhere though, maybe…
14:10pmoreau: Nevermind… Find it back!
14:10pmoreau: Silly me… --"
14:21pmoreau: There we go. Most important fix ever: adding the Pascal Titan X and fixing the name of the Maxwell version, to the code name page.
14:24jrun: zeq: ping!
14:36imirkin_: unfortunately pretty much all of the wiki docs are wrong
14:36imirkin_: i feel bad about the current state, but it was already pretty much all wrong when i started trying to fix it, like 3 years ago
14:37pmoreau: What's the policy for dead links? For example, the link to the IRC logs from 2006 is dead.
14:37pmoreau: Just remove it I guess?
14:37imirkin_: it should all just be rewritten from scratch
14:37imirkin_: i started writing stuff, but then lost it, and got discouraged.
14:38ajax: yeah, i've been trying to make a habit of fixup up the dri and xorg wikis as i go
14:38ajax: it's... frustrating
14:41jrun: hmm, compton is broken too (with glx backend). this worked on nvidia blob.
14:42imirkin_: jrun: compton is not the use-case most of nouveau was designed for
14:42jrun: ok, but does it give us a clue as to where to look for the problem i'm having with webgl?
14:43imirkin_: GL_EXT_gpu_shader4 is not supported in mesa
14:43imirkin_: nor will it ever be
14:43imirkin_: it's an extension meant as a stop-gap measure before GL 3.0 was released
14:43imirkin_: GL 3.0 has been out for some time now
14:43ajax: imirkin_: so, i know you're anti-glamor when it comes to running it on mesa/nouveau. is there a quick summary explanation?
14:43imirkin_: ajax: sure - the GL driver is crap
14:43ajax: imirkin_: like, if i found a month to hack on it, could it be acceptable
14:44imirkin_: ajax: the ddx paths are well-tested and handle errors. the GL paths are well known to have all sorts of issues, and lack of error handling is one of them.
14:45imirkin_: ajax: also the usual use-case for nouveau has been short-running applications like games (a 4hr gaming session is kinda the max)
14:45imirkin_: glamor (and compton, etc) run for much longer
14:45ajax: okay. that sounds like a bounded problem space at least.
14:46imirkin_: also the fact that the glamor in xorg 1.17 had some kind of undiagnosable issue with nouveau's GL backend that magically went away in Xorg 1.18 doesn't make me feel super-great
14:46imirkin_: [which is, again, a nouveau GL driver issue, but knowing that doesn't magically resolve the issue]
14:47imirkin_: ajax: lastly there's my personal use-case of "xlock -mode wator" sucks monkeynuts with GLAMOR. but apparently no one else cares [enough].
14:47ajax: nah, that's on my todo
14:47imirkin_: ah neat!
14:47imirkin_: ajax: you may also be interested to know that i965 also doesn't handle errors
14:48imirkin_: under certain conditions, it does exit()
14:48imirkin_: which isn't *super* great in an X server
14:48imirkin_: [things have to get pretty bad in order for that to happen, but it can and does happen. no opportunity to fall back to software rendering]
14:49ajax: yeah, amateur move to be sure
14:49ajax: from where i'm sitting i have two of three desktop gpu profiles where people are actively wanting glamor
14:49imirkin_: well, they seem pretty adamant about saying it's an ok thing to do
14:50ajax: so if i can make it three of three by putting some labor into it, well, i can do that
14:50ajax: just trying to get a feel for how much labor it'd be
14:51imirkin_: "make nouveau reliable" is a tall order
14:51imirkin_: the thing is that the DDX uses like ... 0.0005% of GPU functions
14:51imirkin_: whereas the GL driver is like ... 5%
14:51imirkin_: so a lot more opportunity to mess things up
14:52ajax: yeah well
14:52ajax: mesa was pretty bad at gl2 until suddenly people wanted to play doom 3
14:52imirkin_: and there's not solid recovery
14:52ajax: demand is a great motivator
14:52imirkin_: i've been leaving all that in Ben's corner
14:52imirkin_: and he's fixed up some of the more obvious fail
14:53imirkin_: but he also has things he's supposed to be working on, and apparently RH is paying him more than i am
14:54imirkin_: don't get me wrong - i'm all for fixing stuff
14:54imirkin_: i'm currently contemplating rewriting half the nouveau backend wrt how it handles BO's
14:54imirkin_: it's just ... it requires work :)
15:01karolherbst: imirkin_: so old/new wiki split and do it from scratch?
15:01imirkin_: step 1 is to figure out wtf to have in the wiki
15:02karolherbst: this we know somewhat
15:02karolherbst: I think
15:02imirkin_: one major unfortunate issue is that knowledge about all this stuff is ... lacking
15:02imirkin_: e.g. i have no idea how a lot of stuff works
15:02karolherbst: I think we should do it the right way and think before doing something
15:02imirkin_: even though one would likely say that i'm one of the more "knowledgeable" people
15:03karolherbst: but maybe we just begin from the broad view and get more specific over time
15:03karolherbst: so first we think about which topics the wiki should contain information about
15:03karolherbst: and go from there
15:03karolherbst: and if we have that, everybody can add information as far as the person knows the stuff
15:04pmoreau: How do we do the split? Keep the current wiki around while pushing to another common repo?
15:05ajax: the wiki has comments
15:06imirkin_: i would recommend hosting the wiki somewhere else
15:06imirkin_: the xorg wiki is very annoying for a lot of different reasons
15:06ajax: would be easy enough to add a magic comment to files saying "this has been updated for the grand rework"
15:06imirkin_: not the least of which is that the default style looks like ass and is not easy to change
15:07pmoreau: imirkin_: +2^64 for the style
15:08imirkin_: that's == 0 then due to wraparound? :)
15:08ajax: you don't have int128?
15:08imirkin_: if i didn't hate github with quite such a passion, i'd say github
15:09pmoreau: Damn, missed that -1.
15:11karolherbst: imirkin_: what page would you prefer? github wiki :D
15:11karolherbst: well I have no idea myself anyway
15:12pmoreau: github.io rather than github wiki most likely, but still.
15:13imirkin_: well, another annoyance with the xorg wiki is that account creation cost is very high
15:16karolherbst: Jaga: do you have any good ideas for good software for internal and external documentation? preferable wiki style (I just assume you know everything know, so :p )
15:17karolherbst: yeah, maybe github.io is nice
15:20ajax: fdo's account setup cost being high is a known bug
15:20ajax: not that we have a fix in progress, really, but
15:21imirkin_: ajax: iirc there's SOME way for random people (like me) to add a wiki account, but i can never remember how
15:31karolherbst: imirkin_: I think I know how, there is a page for that! :D
15:32karolherbst: https://wiki.freedesktop.org/sitewranglers/wiki/401/ !
15:38imirkin_: oh right. with a root account. nevermind. so i can't
15:42jrun: running chrome from cli i see this:
15:43jrun: ERROR:gles2_cmd_decoder.cc(2291)] [.RenderCompositor-0x4e6041e5c00]GL ERROR :GL_INVALID_OPERATION : GLES2DecoderImpl::DoBindTexImage2DCHROMIUM: <- error from previous GL command
15:43imirkin_: some sort of bug in chrome?
16:01jrun: cookies? just cleared the damn cookies and it works now.
16:01jrun: sorry for the noise
16:07ajax: imirkin_: so, i think i can make wator go _stupid_ fast if we bother to define an R1 texture format
16:07imirkin_: ajax: i'm down with that
16:07imirkin_: ajax: as long as you don't start trying to filter on it ;)
16:07imirkin_: (or render to it)
16:08ajax: heck of no
16:08imirkin_: afaik all DX10+ hw has R1 support
16:08imirkin_: at the very least that's true for nvidia
16:09ajax: no, bit-exact sampling is all i'd need
16:10ajax: all i'd be using it for is selecting the fragment color to emit
16:10imirkin_: it should be moderately easy to emulate that with R8_UINT no?
16:10ajax: if i have gpu_shader5 levels of bit extraction, yes
16:10ajax: which i don't know if i have on, say, vc4
16:13ajax: failing that i can expand to the fb format in software. which i can do entirely in xserver, and would avoid the fallback, but is like 32x the data to upload
16:14ajax: which isn't _that_ much i suppose. it's not different from having done it with zpixmap in the first place
16:15imirkin_: why do you need gpu_shader5 btw?
16:16ajax: that's the one that gives me bitwise &, right?
16:16imirkin_: what you need is native integer support
16:16ajax: (i don't actually know, i'm a glx nerd not a gl nerd)
16:17imirkin_: i'm not 100% sure tbh. i thought bitwise ops existed well prior to gs5
16:17imirkin_: gs5 adds bitfieldExtract and all sorts of bs like that
16:18imirkin_: you _may_ need GLSL 1.30 for reliable integers. dunno.
16:18imirkin_: you definitely need it for integer textures :)
16:18imirkin_: (since we don't support EXT_gpu_shader4, which is required for EXT_texture_integer to be useful)
16:18loa: nouveau support dri3 by default?
16:28loa: i need enable it when building module? and how stable it is?
16:28imirkin_: just in your xorg.conf
16:29imirkin_: not sure what your definition of 'stability' is
16:36waltercool: Hmmm I'm trying to compile nouveau on linux-4.8-rc8 using branch linux-4.8 from skeggsb repo, but I'm getting the following compilation error under gcc 5.4.0, do you guys knows what would it be? http://pastebin.com/Lm26hb8L
16:37waltercool: is a gcc or my kernel issue?
16:45imirkin_: waltercool: which repo? the linux repo?
16:46waltercool: imirkin_: yeah, torvalds/linux repo
16:47imirkin_: waltercool: probably need an older -rc :)
16:48waltercool: imirkin_: oh OK :-) I will try with an older one
16:48imirkin_: tbh i dunno
16:48imirkin_: hold on
16:48imirkin_: so the claim is that this was added in 4.8-rc6
16:48imirkin_: which means that you should be able to build against linux 4.8-rc8...
16:49waltercool: wait... let me check something
16:49imirkin_: bridge_d3 should be in there... so i dunno what's going on
16:50waltercool: yeah, my branch seems stucked at 18 sept, but the last commit seems to be at 22 Sept
16:51imirkin_: dates on commits aren't the most reliable things to look at
16:51imirkin_: one could foolishly attempt to extrapolate order from such dates, which would be ... foolish.
16:53tobijk: waltercool: huh? the standard linux repo should compile fine (rc1 - rc8)
16:53waltercool: yeah, and seems that's the case now, I'm compiling against that specific commit
16:53imirkin_: which specific commit?
16:54waltercool: I mean, just for testing proposes
16:54imirkin_: erm, ok
16:54imirkin_: shouldn't matter either way.
16:54waltercool: by some reason, default linux-4.8 branch wasn't working for me
16:54imirkin_: my comment is that your *linux* tree is out of date.
16:54tobijk: waltercool: maybe you should revert aff51175cdbf345740ec9203eff88e772af88059 , that causes problems :)
16:55tobijk: but anything else it should be fine
16:55tobijk: btw karolherbst, do you know if and when aff51175cdbf345740ec9203eff88e772af88059 will be reverted, or fixed?
16:59waltercool: wait... I think the problem may be kernel cache for a different branch
16:59waltercool: recompiling kernel&modules to see
16:59karolherbst: tobijk what was it again?
17:00tobijk: karolherbst: it kills mesa when using dri3
17:00karolherbst: ohh right, it was reverted
17:00tobijk: you pointed me to revert that commit, which fixed the issue
17:00karolherbst: i think
17:01tobijk: it is reverted? good then we'll see it sooner or later :)
17:01karolherbst: have to check at home
17:01Jaga: karolherbst: unfortunately I don't know much about the documenting part - there's lots of wiki-like stuff around, and I'd say it's a case of pick the one that's least tinkering, works out of the box with nice fonts and looks and good support for images/diagrams (you could use some to brighten the text)
17:02Jaga: karolherbst: companies are pretty much into Confluenza
17:02karolherbst: Jaga: I see, well good to know.
17:02imirkin_: lol, confluence is horrid
17:02karolherbst: mhh heard of it and no idea what that is
17:02Jaga: imirkin_: comes with Jira tho, and that one is quite wide-spread
17:03imirkin_: which is equally horrid
17:03karolherbst: jira :D
17:03karolherbst: have to work with it at worj
17:03karolherbst: it is horrible
17:03Jaga: imirkin_: got any better tool for scrum boards and ticketing?
17:03imirkin_: Jaga: "just say no to scrum"?
17:04Jaga: imirkin_: I worked in waterfall at one point, made me like scrum a lot
17:04imirkin_: anyways, if you want the stupid simplicity, use trello
17:04karolherbst: well scrum is fancy, so you have it in every startup :D
17:04imirkin_: scrum is a lot more than "not waterfall"
17:04karolherbst: yeah, trello is good enough for tasks
17:04imirkin_: it's endless and pointless meetings
17:04karolherbst: and for bugs we have bugzilla
17:05karolherbst: well, if people would do scrum right at least....
17:05Jaga: yes, it's more than "not waterfall", it's also very loose definition of work, and you could adapt it pretty much how you like it
17:05karolherbst: but i get the feeling, scrum is done 95% the wrong was usually
17:05Jaga: amount of meetings shouldn't be over the top, but shouldn't be none either imo
17:06karolherbst: well, we do 10 minutes each morning
17:06imirkin_: plus a 10000-hour planning meeting
17:06Jaga: I find that 10min every morning good
17:06karolherbst: ours is 2h :O
17:06karolherbst: every other week
17:06Jaga: imirkin_: depends where you are, in the team I'm in now there's... minimal planning
17:06imirkin_: and do you do that retrospective thing too?
17:06Jaga: I think it's 1h
17:07karolherbst: it is goos though, cause only 2 do the planning
17:07tobijk: so 2h:50min just for scrum? :O
17:07Jaga: there's no retros tho, pity
17:07karolherbst: imirkin: just team guy + product managet. no devs
17:07imirkin_: heh ok, that might be more manageable then
17:07karolherbst: so for me it is 50 minutes a week for meetings
17:07karolherbst: which is okay
17:08Jaga: also I've been to various teams and some did 1 week scrums... some 1 month
17:08imirkin_: 2h per week, if you count your planning meeting, at 2h/meeting
17:08Jaga: the smaller the team the longer the scrum
17:08karolherbst: 1 week? with retro and planning? :D
17:08waltercool: ok, false alarm imirkin_, my bad, wrong kernel cache was causing the issue
17:09karolherbst: imirkin: i dont plan :p
17:09Jaga: karolherbst: some people like it like that
17:09imirkin_: anyways, it has some good ideas, but afaik it's often most often implemented in a very rigid manner, which makes it more of a pain
17:09Jaga: imirkin_: yes, the "rigid" part is a bit wrong I guess, since it's supposed to be agile
17:09karolherbst: Jaga: yeah, i know, i am not completly serious anyway ;)
17:10karolherbst: well i can see the benefit in being able to adjust fast
17:10karolherbst: or do small release cycles
17:10Jaga: I get some larger teams might want 1 week if they have features and releases tied to them
17:11Jaga: and customer companies to deliver to, who are pushing stuff
17:11karolherbst: anyway, to get back to topic: we only need something for software/tools documentation
17:12Jaga: karolherbst: rule of thumb: pick something that looks good and takes no time to set up and maintain, so you have more time to write and maintain the actual documentation
17:12Jaga: you probably want it free and with revision
17:12karolherbst: mhh github wiki? but layout is bad there...
17:13karolherbst: and low control overall
17:14Jaga: do you have a place to host it or do you need a SaaS?
17:14karolherbst: we could host it, but we dont want to
17:15karolherbst: mupuf: or would it be okay for you?
17:15Jaga: then make sure it doesn't lock you in
17:15karolherbst: or somebody else?
17:15karolherbst: github wiki has the advantage of using git
17:16karolherbst: but I would prefer something else
17:17karolherbst: well I just hoped you know something really good, which you usually dont find with web search stuff
17:17Jaga: sorry to disappoint
17:18karolherbst: no worries
17:19karolherbst: we could also use some hosted docu wiki
17:19karolherbst: but well.... the syntax
17:21karolherbst: when i arrive at home, i will do some research then
17:38karolherbst: ohh mediawiki was the name
17:38karolherbst: http://www.wikimatrix.org/wizard.php !
17:38karolherbst: I need more stuff like that :D
17:38karolherbst: let see if this is any good
17:43Jaga: too much choice?
17:43karolherbst: well, if I have so much choice, I also care about license in the end
17:43karolherbst: and the list is a little outdate too
17:43karolherbst: so I ended up with a list of 21 and well
17:44karolherbst: imirkin_: what is so bad about the freedesktop wiki? just the account creation thing?
17:45karolherbst: ohh, I used redmine once
17:45karolherbst: redmine isn't too bad
17:46karolherbst: installing is just painful
17:47karolherbst: does anybody here also dislike trac a lot?
17:50imirkin_: redmine is nice
17:50imirkin_: trac is horrible
17:51imirkin_: karolherbst: account creation and styling badness
17:51karolherbst: imirkin_: I see
17:51karolherbst: well I would also go for redmine for now
17:51karolherbst: until somebody has a better suggestion
17:51imirkin_: like the level of styling i put in for the front page
17:51imirkin_: was a huge pain
17:51imirkin_: and makes the front page a pain to maintain
17:51karolherbst: isn't it like mainly html=
17:51imirkin_: which is fine, coz it's not like it changes a ton
18:04karolherbst: imirkin_: would you prefer to use redmine for more things than just wiki? like discussions stuff? I would think you would prefer a mailiong list for this anyway?
18:05ajax: imirkin_: so, this passes xts and looks like it renders correctly: https://github.com/nwnk/xserver/commit/62220b4f094cde1e8c6cb688c2df6c480482904d
18:06ajax: i can't really tell if it's still "sucks monkeynuts", i'm behind a few layers of vsync between wayland and Xephyr
18:07imirkin_: ajax: awesome. i'm in no position to review your patch (or approach), but i'll try to test it out
18:07imirkin_: fwiw you have to have a pretty big screen to get the suckage to be really visible
18:07imirkin_: in my case, that's 2400x1920
18:07imirkin_: but i'm sure other sizes can cause the effect too
18:08ajax: oh, sure, i can make a bigger Xephyr
18:08imirkin_: btw, i assume the only way to test is to rebuild an X server?
18:09imirkin_: there's no like libglamor or whatever?
18:09ajax: there's a glamor library, but it lives in the xserver tree, yes
18:09imirkin_: should this apply to a 1.18.4 tree?
18:10imirkin_: ok, i'll try to test it out in the net 6h or so
18:15imirkin_: ajax: btw, were you able to repro the issue? or are you just hoping this helps?
18:22ajax: imirkin_: even at 2048x1536 it doesn't seem "slow" to me
18:22ajax: even without the patch
18:23ajax: but i'm testing this on skl
18:23ajax: so probably readbacks aren't as painful
18:24ajax: and there's not an x11perf for xybitmap
18:30imirkin_: ajax: definitely a *vast* improvement. not *100%* there, but *way* better
18:30imirkin_: more like 95% of the way there
18:33ajax: imirkin_: awesome!
18:33imirkin_: and tbh, i don't even remember if the intel ddx is 100% there, so it could be a limitation of the screensaver/hw
18:34imirkin_: basically the fishes are supposed to update "atomically" turn to turn
18:34imirkin_: of course it just does a bajillion PutImage's and assumes they'll be atomic
18:35imirkin_: anyways, i'll keep running on modesetting for a bit (on this SKL) to see if there are any other unexpected issues
18:36imirkin_: iirc last time i ran it, i also got a ton of artifacts in emacs. but there have been a lot of GL-side fixes since then
18:37imirkin_: [but at the time, artifacts in emacs were way less annoying than xterm not working in the intel ddx [which has since been fixed]