| 01:04 | DHowett | frilled: what sort of raid box? |
| 01:05 | DHowett | I'm considering http://www.amazon.com/dp/B003YFHEAC/ |
| 08:35 | frilled | DHowett: http://www.sharkoon.com/?q=en/node/1809 |
| 08:36 | frilled | I'm very pleased with it. |
| 08:54 | jnettlet | frilled, what RAID mode are you running that box in? |
| 09:08 | frilled | 5 |
| 09:16 | jnettlet | decent performance? |
| 09:19 | frilled | no benchmarks. samba does like 5mb/s which is sufgicient for me |
| 09:19 | frilled | 35 lol |
| 09:19 | frilled | sry, touchscreen |
| 09:21 | frilled | nfs should be somewhat faster, but i didnt measure it yet |
| 09:24 | frilled | gotta run, laters |
| 09:31 | DHowett | frilled: ah, thanks! |
| 09:52 | frilled | I particularly like that the box does not need mounting frames for the disks. Open door, insert disk, close door .-) |
| 10:46 | dv_ | jnettlet , so any word on the x11 / vmeta stuff? |
| 10:47 | dv_ | and _rmk_, be sure to get the latest patch from rabeeh's kernel, which gives vmeta a huge performance boost |
| 11:28 | _rmk_ | dv: yes, that's a problem I identified when I rewrote all that stuff |
| 11:28 | _rmk_ | UIO vmeta can't be merged into mainline - gregkh has refused it because it abuses the UIO interface |
| 11:29 | _rmk_ | I use a miscdevice version of the driver instead here |
| 11:29 | _rmk_ | which is even further optimised for vmeta's purposes |
| 11:31 | _rmk_ | dv: the problem is that the vmeta userspace doesn't acknowledge the interrupt after a poll by reading from the fd - rabeeh's "fix" is a hack which adds more abuse on top of the already present abuse of uio |
| 11:33 | shesselba | _rmk_: I ve not checked vmeta stuff yet. But what about a true v4l2 driver? |
| 11:34 | _rmk_ | I don't see any point |
| 11:34 | _rmk_ | that would mean working out all the ins and outs of how to drive the vmeta hardware itself |
| 11:35 | dv_ | _rmk_: so, the miscdevice is a replacement for what is currently in rabeeh's kernel? |
| 11:35 | shesselba | sure, but there are people working on gpu also. I am not saying it will be easy but for the long run, it would be nice |
| 11:36 | _rmk_ | db: no, I've published the userland bits of the change, but I never got around to digging out the kernel patch from my tree |
| 11:36 | _rmk_ | err dv |
| 11:36 | dv_ | _rmk_: what I mean is, there is a chance that vmeta will work nicely in future kernels without the uio_vmeta stuff ? |
| 11:37 | _rmk_ | shesselba: I don't have a religious obsession with everything being open source as long as it works for me. I really don't have a problem with stuff being closed provided its in a usable form. |
| 11:37 | dv_ | it would be nice to not be limited to patched kernels |
| 11:37 | dv_ | (which usually dont follow upstream much afterwards) |
| 11:38 | _rmk_ | dv: theory is my miscdevice thing should be able to get merged into mainline - but that's a question of whether I want to put myself in another religious war about open/closed source |
| 11:39 | _rmk_ | even though the kernel side is open, and the library which talks to it in userspace is also open, some kernel devs have a problem with there being any closed source stuff |
| 11:39 | dv_ | the other option is to put vmeta and galcore/vivante stuff in kernel modules |
| 11:40 | dv_ | the vivante stuff will hopefully be eventually replaced by etnaviv, but if vmeta doesnt work out, well, it could still do as a module.. |
| 11:41 | _rmk_ | well, its likely that any vivante rewrite will probably be incompatible with my dove drm stuff |
| 11:41 | _rmk_ | so I'll probably stick with the closed source userspace vivante stuff |
| 11:43 | _rmk_ | I mean, they'll probably go down the route of having everything in uncacheable memory, which sucks |
| 11:43 | _rmk_ | I have everything but the framebuffer in cacheable memory |
| 11:44 | _rmk_ | as the vivante GPU can't do every operation (the render stuff especially is a problem for it) we still need the s/w backend to do stuff, so having the pixmaps cacheable makes a big difference |
| 11:45 | _rmk_ | particularly alphablending |
| 11:46 | dv_ | you should ask wumpus about that |
| 11:47 | dv_ | he is one of the etnaviv devs |
| 11:48 | _rmk_ | no point, I put six months of work into what I have, and I did that mainly for myself so I could have a nice and usable platform which works reliably. Totally unfunded, and no one interested in funding it, so I've zero motivation to release any of the DRM/X/Vivante changes |
| 11:48 | _rmk_ | as I've said recently to someone else, I'm no charity anymore |
| 11:48 | dv_ | hmm :/ |
| 11:49 | dv_ | so your kernel changes also stay closed source? |
| 11:49 | dv_ | related to vmeta I mean |
| 11:49 | _rmk_ | I put the work in so that I could have working vlc for my mpeg transport streams |
| 11:50 | _rmk_ | dv: those are much smaller than DRM/X/Vivante and I've no problems with that stuff |
| 11:51 | _rmk_ | the userspace libraries are already here, and have been for months: http://ftp.arm.linux.org.uk/git/ |
| 11:52 | _rmk_ | but... one of the issues there is I sent Rabeeh a bunch of patches to remove some of the hacks he has in his kernel in August/September, which never got applied, which some of this stuff needs. |
| 11:53 | dv_ | probably plenty busy |
| 11:54 | _rmk_ | they're now soo far removed from his kernel that it'll be a lot of effort for me now |
| 11:54 | dv_ | I dont really understand the charity argument though. you could call most opensource development "charity work" , no ? |
| 11:54 | wumpus | nah, i'm "not a charity" either, but realize you're building on top of a lot of stuff that people did provide for free, so it's nice to contribute something back right... |
| 11:55 | _rmk_ | wumpus: except if you rewrite the X driver from scratch, and a DRM driver from scratch too |
| 11:55 | wumpus | if everyone was going at it alone, open source would be a total failure |
| 11:55 | wumpus | yes, it's up to yourself of course |
| 11:56 | wumpus | if you think you can somehow earn more by keeping it closed, freedom also means you can do that :) |
| 11:56 | dv_ | okay, thats a lot of work, and I understand the desire to get some kind of compensation for that |
| 11:56 | wumpus | sure, but getting compensation is orthogonal to releasing it as open source |
| 11:57 | wumpus | think of all the poor underpaid linux kernel developers at large companies such as IBM :P |
| 11:57 | dv_ | hmm. on the other hand, there is the real possibility that keeping it closed means that it just stays on some hard drive, gathering dust, eventually being deleted by accident |
| 11:57 | wumpus | indeed! |
| 11:58 | _rmk_ | no it isn't; once you release something as open source, there's no chance anymore of getting anything back... that's the economic reality of the financial mindset |
| 11:58 | _rmk_ | unless it's for ongoing maintanence |
| 11:58 | dv_ | I have seen this happen a lot with customer middleware, which they kept tightly wrapped. it eventually died, and the stuff that was depending on it had to keep old buggy copies |
| 12:00 | dv_ | yeah, thats true. but is it any easier if it remains closed? |
| 12:00 | dv_ | btw wumpus, any word on the uncacheable memory? |
| 12:04 | _rmk_ | dv: the answer to that is yes, because then you don't have to deal with other people's bug reports and figuring out what's going on in userland with multiple different versions of stuff :) |
| 12:05 | _rmk_ | I know what people's expectations of someone who releases something are (been there when I first released arm linux) - everyone wants you to do all the work for them. |
| 12:05 | _rmk_ | maybe peoples attitudes on that have changed since the 1990s tho |
| 12:07 | dv_ | um, problems with various combinations still exist with closed source stuff. what if they use different Xorg versions, different compositing managers etc. the difference is that nobody can look into the driver and be sure its that |
| 12:08 | _rmk_ | exactly, which means you either end up ignoring bug reports or chasing around trying to find the source for their specific versions and work out what's going in there too |
| 12:08 | dv_ | for example, I bet nvidia gets a lot of reported "bugs" which are actually not caused by their drivers |
| 12:09 | dv_ | so open/closed is no factor there |
| 12:11 | dv_ | as for "everyone wants you to do all the work for them", that problem exists, yes. it depends on the team. ideally, many people contribute, and this is the case in many opensource projects. but if there is only one developer (or a few), and 99% of the feedback is "I want feature X", then the case you described applies. |
| 12:12 | dv_ | but this does not seem to be all that common to me. eventually, somebody starts sending in patches etc. just look at how often pull requests are issued in github |
| 12:17 | _rmk_ | dv: my attitudes are coloured by _years_ of trying to get arm linux off the ground, and having nothing but a constant stream of bug reports and requests for stuff which I just couldn't satisfy, people telling me what I should and shouldn't be doing, meanwhile working hard to try and get stuff moving forward... and not one person willing to actually download any userspace source and provide a patch. |
| 12:19 | dv_ | what projects were you involved with, exactly? |
| 12:19 | _rmk_ | dv: what was utterly insulting is that when I eventually wrote up the history of ARM Linux, people came back and said it was a pack of lies. |
| 12:20 | dv_ | I ask because people's attitudes vary wildly from project to project |
| 12:22 | dv_ | and I thankfully havent seen behavior like that happening so far |
| 12:22 | dv_ | I can see how demotivating and disappointing it can be though |
| 12:24 | _rmk_ | dv: basically from around 1994 the ARM Linux kernel, including getting things like binutils and gcc working for the features Linux wanted (Richard Earnshaw was only doing the ARM support but ARM + Linux support together is quite different), a.out shared libraries in a similar way to x86, X11 support, and the first almost installable ARM distribution |
| 12:25 | dv_ | oh, wow |
| 12:27 | _rmk_ | I still have the very first ARM machine which Linux ran on here though it's more a museum piece than anything else now |
| 12:27 | dv_ | I dimly remember that the arm-linux history was not exactly without conflicts |
| 12:28 | _rmk_ | I might even have the RISC OS archives of the kernel source somewhere, but the media has probably degraded now (would've been floppy disks) |
| 12:29 | dv_ | but _rmk_ , you cant really apply stuff like this to other projects. for every project, there is a different community. some communities are run by cool, level-headed people, some are filled with asshats. |
| 12:29 | dv_ | (I have seen both9 |
| 12:31 | _rmk_ | dv: anyway, my main problem now (as it always has been) is limited time... there's lots of things I would like to do but today, just keeping on top of 6500 emails a month (even with just scanning them) is quite an effort. |
| 12:32 | _rmk_ | I was away for a total of 6 working days and four weekend days in April... it took me a week to catch up with email from that alone :( |
| 12:33 | dv_ | _rmk_: oh, the time problem I understand :) |
| 12:33 | dv_ | its okay, I just ask that you give this community a chance |
| 12:33 | _rmk_ | and I'd said I wouldn't catch up, and I was told that was "unacceptable" :( |
| 12:34 | dv_ | by whom? |
| 12:36 | dv_ | I mean, by somebody from an opensource community, or by your employer? |
| 12:36 | _rmk_ | someone from the community |
| 12:39 | dv_ | and you explained that you are plenty busy? because many are, and people should (and usually do) understand that |
| 12:40 | _rmk_ | oh they well know I am, but apparantly because of my position I'm not allowed to dump stuff for any reason, because that's not being a good and effective maintainer... |
| 12:40 | _rmk_ | I'm rather dreading being away for 9 days at the end of May for the same reason |
| 12:43 | dv_ | you should talk to maintainers of other opensource projects, how they deal with all of this |
| 12:58 | dv_ | btw. was the person who said "unacceptable" an active developer or a contributor or a regular user or .. ? |
| 13:10 | dv_ | _rmk_: watch this : http://www.youtube.com/watch?v=-F-3E8pyjFo |
| 13:13 | wumpus | I certainly recognize your pain |
| 13:15 | wumpus | I've also stopped taking feature requests for open source code that I maintain, too many cheapasses that demand everything but give nothing in return... those people aren't useful to have in the community anyway, those that actually contribute will come with code |
| 13:21 | wumpus | dv_: yes all the video memory is uncachable at the moment, that's how vivante implemented it (at least for the dove driver)... don't know why |
| 13:22 | wumpus | could be it's for simplicity of implementation, they don't want to explicitly flush cache before having the gpu read the memory |
| 13:23 | wumpus | at least I think it's a software choice not a hardware one |
| 13:24 | _rmk_ | it is a software choice; all my pixmaps are cacheable including those which get passed to the gpu |
| 13:26 | wumpus | ok |
| 13:26 | _rmk_ | and of course I avoid cache flushing by keeping track of who owns each pixmap |
| 13:27 | _rmk_ | so cache flushes only happen on ownership changes |
| 13:27 | wumpus | yes, that makes sense |
| 13:29 | _rmk_ | I just wish that the vivante gpu could do the alphablending which the xrender extension wants |
| 13:30 | dv_ | so the thing about cacheable/uncacheable bit involves both the Xorg driver and the DRM vivante support? |
| 13:30 | wumpus | I must say I don't know much about the 2d engine, but it supports various kinds of alpha blending, what specific one is missing? |
| 13:30 | _rmk_ | its alphablending is very limited in its capability, nowhere near what X wants for even doing stuff like blending text |
| 13:32 | wumpus | ok |
| 13:32 | _rmk_ | I can't recall the details off the top of my head, but basically text doesn't come out right (source, mask, dst) because it doesn't have the ability to do the transformations |
| 13:33 | _rmk_ | dv: strictly the cacheable/uncacheable bit is nothing to do with DRM, the closed libraries already support cacheable objects |
| 13:33 | _rmk_ | and you can do everything required with the closed libs (because I am) |
| 13:34 | wumpus | if you can get them to work on your kernel at all... |
| 13:34 | _rmk_ | you can even have all your pixmaps except the scanout buffer in normal system memory too with the closed lib. |
| 13:34 | dv_ | closed libs = galcore, EGL ? |
| 13:34 | _rmk_ | yep |
| 13:34 | _rmk_ | wumpus: I fixed the kernel API to match what the libs wanted, and also fixed a whole ton of bugs in the kernel side :) |
| 13:34 | wumpus | ok, I'm convinved, I'm stopping etnaviv development |
| 13:36 | dv_ | oh dear |
| 13:38 | _rmk_ | http://www.home.arm.linux.org.uk/~rmk/cubox/maps is what my Xorg /proc/*/maps looks like... look at all those luvly cacheable "/drm mm object" mappings :) |
| 13:39 | dv_ | now I've killed etnaviv :[ |
| 13:39 | wumpus | well at least it's open source so everyone can take it over... |
| 13:39 | wumpus | just kidding dv_ |
| 13:39 | dv_ | let me wallow in my fake sadness! |
| 13:39 | dv_ | :P |
| 13:39 | wumpus | hehe |
| 13:52 | dv_ | _rmk_: x11 compositing must be lovely with this |
| 14:08 | wumpus | in any case, the 2d parts of the closed source driver are relatively small and straightforward, it should be less work than the 3d engine |
| 14:10 | wumpus | we could even offer an equivalent interface as the closed source driver, though I'd rather not as the gc user headers are not gpled |
| 14:51 | _rmk_ | wumpus: there are many reasons why I don't want to move away from the closed source userspace libs for vivante stuff and that's one of them - having the 3d userspace still capable of working I think its a plus point |
| 14:59 | wumpus | that's fine, I'm only working on this because I have an interest in how GPUs work, not because I'm trying to get everyone to use open source drivers... |
| 21:40 | _rmk_ | oh wow, this is a classic: |
| 21:40 | _rmk_ | + for (err = 0; err < 10; err++) |
| 21:40 | _rmk_ | + udelay(1000); |
| 21:40 | _rmk_ | + mdelay(10); |
| 21:41 | _rmk_ | 20ms delay? CEC wants 10ms. mdelay(10) will give you that roughly but not guaranteed |
| 21:41 | _rmk_ | irqs are at least off, but still, it's not guaranteed to be 10ms - only approximately 10ms because of the way the calibration works (which has to operate with irqs running) |
| 21:42 | _rmk_ | that results in all udelays being slightly shorter than desired |
| 21:44 | _rmk_ | however, CEC wants a 10ms +/- 1% |
| 21:51 | _rmk_ | the funny thing about the above though is... mdelay(N) is implemented as a loop of N udelay(1000)'s |
| 22:19 | dmitrijus | :D |