| 10:50 | mikelangeloz | hi |
| 10:50 | mikelangeloz | rabeeh, are you there? |
| 11:10 | _rmk | 11:10 * _rmk_ notes galcore complained again last night about a dropped event... but I don't think it was actually dropped, I think its another race. |
| 11:16 | _rmk_ | yep, that works: _GetEvent writes the head first, then the source, then the stamp, which means if the head has been written but nothing else, and we context switch to the galcore thread to handle an event, we'll mess up. |
| 11:38 | rabeeh | hi mikelangeloz |
| 11:53 | _rmk | 11:53 * _rmk_ notes that's the third race in the galcore event code which I've fixed |
| 12:12 | wumpus | _rmk_: do you have your updated galcore code online somewhere? (I'm especially interested in the dmabuf stuff, but of course also bugfixes) |
| 12:13 | _rmk_ | wumpus: no, I don't tend to push my development git tree out as the commits aren't stable in it. |
| 12:14 | wumpus | ok... |
| 12:14 | _rmk_ | if you'd like a combined patch, or maybe a series of patches, I can generate those |
| 12:14 | _rmk_ | a patch series will be very large though, and against some version of rabeeh's kernel |
| 12:15 | wumpus | yes if you can send a patch(set) + starting commit that's great too |
| 12:15 | wumpus | my mail is [email protected] |
| 12:15 | _rmk_ | hmm, actually a patch series probably isn't practical because of the merging of mainline into rabeeh's kernel |
| 12:16 | _rmk_ | I guess we'll see :) |
| 12:16 | wumpus | yeah I have no idea what git will produce in that case |
| 12:17 | jnettlet_ | _rmk_, I wouldn't mind perusing that as well. |
| 12:17 | jnettlet | 12:17 * jnettlet_ is looking forward to the 3.10 long term kernel release |
| 12:19 | _rmk_ | I will need to push a couple of recent galcore changes down into the appropriate branch - that one I've just done hasn't been committed (or even tested) yet |
| 12:19 | wumpus | I soon need to write an etnaviv 2d driver and I think the dmabuf and drm stuff will really help |
| 12:22 | jnettlet_ | wumpus, I don't know if you care, but when you are updating documentation the OLPC hardware is XO-4 has a GC1000 and the XO-1.75 has a GC860 |
| 12:22 | wumpus | jnettlet_: yes I care :) |
| 12:24 | wumpus | adding them to the readme, both are supported by etnaviv, afaik |
| 12:26 | jnettlet_ | both 2d and 3d engines? |
| 12:26 | wumpus | yes, though the 2d stuff consists of only tests for now, there is no driver |
| 12:27 | wumpus | https://github.com/laanwj/etna_viv/tree/master/native/test2d |
| 12:29 | wumpus | the 3d part is much more advanced already, we're using it to render a few games on the gcwzero (see https://blog.visucore.com) |
| 12:29 | _rmk_ | well, it looks like it passed the reboot test |
| 12:29 | _rmk_ | now need to load up the apps which were running last night (vlc, rhythmbox, eog doing a slideshow) |
| 12:29 | wumpus | that has a gc860, btw |
| 12:30 | wumpus | okay cool |
| 12:31 | _rmk_ | ... though I think it took all night to show that bug |
| 12:31 | _rmk_ | it did it at 8:33am this morning and again at 10:02 |
| 12:32 | jnettlet_ | the use of 2d is important for the XO as the 3D core in the GC1000 sucks a bunch of power. |
| 12:32 | wumpus | yes hard-to-reproduce bugs are terrible |
| 12:33 | dv_ | jnettlet_: I will try something else regarding the flickering. I'll write a simple xv test program, to see if I still see this effect then. |
| 12:33 | dv_ | because I just cannot find a reason for why this flickers that bad |
| 12:33 | wumpus | the 2d engine is very easy to program compared to the 3d one, so I don't think a EXA driver is necessarily very far away, I just have tons of other things to do too |
| 12:34 | dv_ | so perhaps something inside the modified xv sink is the cause, perhaps overwriting frames too early etc. |
| 12:34 | _rmk_ | EXA driver... eww. |
| 12:35 | dv_ | ah yes, speaking of it, what is the benefit of EXA for the x11 dove driver? |
| 12:35 | jnettlet_ | dv_, possible |
| 12:35 | wumpus | _rmk_: what's so eww about that? is there a newer, better interface already? |
| 12:35 | wumpus | I'm not really up to speed with Xorg really... |
| 12:36 | _rmk_ | from what I've read of EXA, it's just a generic GPU layer which allows you to easily plug in primerily fill and copy operations |
| 12:36 | wumpus | I first wanted to write a wayland driver, but as I understood they don't have 2d support at all |
| 12:36 | wumpus | _rmk_: isn't that exactly what the 2d engine does? |
| 12:37 | wumpus | the vivante 2d engine is very simple don't expect openvg kind of stuff from it (gc2000 on the other hand has a vg engine) |
| 12:37 | dv_ | that sounds like what the freescale IPU does |
| 12:37 | _rmk_ | while true at the basic level, I found it much easier to go in at the native X level instead |
| 12:37 | wumpus | I really want to avoid diving too far in X |
| 12:38 | wumpus | dv_: and the freescales have both the vivante 2d engine and the IPU:) |
| 12:38 | dv_ | yeah |
| 12:38 | _rmk_ | I don't mind - I've written an X DDX back in the early 90s which wasn't even using XFree86 :) |
| 12:38 | dv_ | the IPU is pretty powerful though |
| 12:38 | dv_ | copies 1080p like its nothing |
| 12:38 | wumpus | well copying is no problem, the vivante core can do that fine :) |
| 12:39 | dv_ | btw. freescale has docs for the vivante 2D API |
| 12:39 | dv_ | so they expose that, which _rmk_ isnt too happy about :) |
| 12:39 | wumpus | with scaling and arbitrary separable 9-tap filters |
| 12:39 | jnettlet_ | yeah freescale has gotten much better treatment from Vivante |
| 12:39 | dv_ | their API is also slightly different |
| 12:40 | jnettlet_ | they just have the newest drivers |
| 12:40 | dv_ | for example, the direct texture extension expects void** instead of void* for physical addresses |
| 12:40 | wumpus | there is also some document for TI GC320 which has all kinds of info about the 2D engine |
| 12:40 | _rmk_ | pointers are dumb for physical addresses :) |
| 12:40 | wumpus | OMAP4 I think |
| 12:41 | dv_ | _rmk_: what would you use? uintptr_t ? unsigned long? it kinda makes sense to use them if you wanna keep a somewhat generic interface |
| 12:41 | wumpus | size_t |
| 12:42 | wumpus | using a pointer gives the wrong indication to the user |
| 12:42 | _rmk_ | an integer type is best, and if you're looking at platform independence, then create a phys_t or something like that which can be appropriately typed |
| 12:42 | dv_ | wumpus: so does size_t :) |
| 12:42 | wumpus | well at least you cannot dereference it |
| 12:42 | wumpus | you can call it otherwise, obviously |
| 12:42 | _rmk_ | ^^^^^^^ that's the whole point :) |
| 12:42 | dv_ | okay, fair point |
| 12:42 | _rmk_ | you shouldn't be able to dereference a physical address, ever, not even by accident |
| 12:43 | dv_ | then a typedef uintptr_t sounds okay |
| 12:43 | _rmk_ | not necessarily :) |
| 12:44 | _rmk_ | take LPAE Aarch32. >32-bit physical address space, but 32-bit pointers |
| 12:44 | _rmk_ | and RAM on those tends to be above 4GB |
| 12:44 | dv_ | ... oh. forgot about PAE. |
| 12:44 | wumpus | I think one of those should be 64 |
| 12:44 | wumpus | ohh >23 |
| 12:45 | _rmk_ | this is why I said phys_t because its platform dependent :) |
| 12:45 | wumpus | but phys_t is also available to userspace? |
| 12:45 | dv_ | okay the fundamental problem is that userspace has access to physical memory. but that wont go away any time soon. |
| 12:45 | wumpus | in the v4 drivers vivante uses 64 bit handles for everything |
| 12:46 | _rmk_ | dv_: quite :) |
| 12:46 | _rmk_ | hopefully with etnaviv it will be going away |
| 12:46 | wumpus | at least after BSP 4.0 fror imx6 |
| 12:46 | dv_ | weeeellllll.... ther eis vmeta |
| 12:46 | dv_ | and the imx6 vpu also expects them |
| 12:47 | dv_ | the ipu too |
| 12:47 | _rmk_ | dv_: yea, I don't see what we can do with vmeta :( |
| 12:47 | dv_ | but yes, at least the GPU could be sane |
| 12:47 | wumpus | and I agree, exposing physical addresses to userspace is completely dumb |
| 12:47 | dv_ | _rmk_: there might be a chance with the imx6, since the imx-lib is opensource, and is mostly made of ioctl's |
| 12:47 | wumpus | yes, all imx6 stuff is open source except for the vivante driver |
| 12:48 | dv_ | and you are fixing that ;) |
| 12:48 | wumpus | yep |
| 12:48 | dv_ | now if there were a way to improve the VPU's weird buffer registration system, dmabuf could be used to its full extent |
| 12:50 | _rmk_ | dv_: oh, I did some digging with my vmeta libva stuff - it really is the case that the vmeta hardware is programmed with the stream buffers, and then the libraries poke at various registers to read the headers from the bitstream |
| 12:51 | _rmk_ | dv_: the hardware has the ability to be asked "give me the next N bits from the bitstream" and it does this for the mpeg2 sequence/picture headers |
| 12:51 | dv_ | oh |
| 12:51 | dv_ | so most of the intelligence is in the hard/firmware |
| 12:51 | dv_ | interesting |
| 12:52 | dv_ | but what does the libvmetahal then do? |
| 12:52 | _rmk_ | I haven't analysed all the register reads/writes, but I think I've seen evidence of it writing the IQ matrix into the vmeta registers after its read it out of the headers |
| 12:53 | wumpus | uploading the appropriate firmware and such |
| 12:53 | _rmk_ | libvmetahal is the main library - you can do all the decode and encode with just that if you use the API in vdec_api.h |
| 12:53 | _rmk_ | the other libraries just seem to be shims around that to give a simpler interface |
| 12:53 | wumpus | yep it has all the decoding blocks |
| 12:53 | dv_ | the ipp stuff definitely is |
| 12:54 | dv_ | did you see anything related to h264 mvc? |
| 12:54 | wumpus | I didn't look at that level of detail |
| 12:55 | dv_ | I am thinking of changing my decoder to use vdec_api.h directly |
| 12:55 | dv_ | since some parts like mvc dont seem to be exposed at the ipp level |
| 12:56 | dv_ | its not a major point though, because gstreamer doesnt have proper mvc support yet |
| 12:57 | _rmk_ | it also looks like at some points it just polls the hardware rather than having an interrupt it could wait for |
| 12:59 | dv_ | _rmk_: got any answers to your questions about video/x-surface from the gstreamer crowd? |
| 12:59 | _rmk_ | I haven't tried progressing that one yet :p |
| 13:00 | _rmk_ | oh, I didn't mention... so I showed the cubox off a few weekends ago... |
| 13:00 | dv_ | also, I've been talking to the wayland devs, and there is room for a wayland extension that allows you to pass over a dmabuf fd, plus some metadata (stride, plane offsets, width, height, pixelformat), and ask it "please draw this" |
| 13:01 | _rmk_ | the let-down was audio (it took three reboots in total) but otherwise it performed ok. |
| 13:01 | dv_ | audio is your nemesis :P |
| 13:02 | _rmk_ | I left some of my debug in the gstreamer vmeta decoder, so when someone double-clicked on some of their mp4's and got totem up, they didn't play very well |
| 13:02 | dv_ | what distro did you use? |
| 13:02 | _rmk_ | other than that, it worked fine - it must have played around 5 hours of video in total. |
| 13:02 | _rmk_ | ubuntu 12.04.1 lts |
| 13:03 | dv_ | next time, try it with my decoder - I want the free testing ;P |
| 13:05 | _rmk_ | what I do need to do is to replace this cheapo spdif decoder box with something a bit better... or fix it so it correctly syncs to the spdif bitstream |
| 13:06 | _rmk_ | esp. as the new tv I now have can only give audio out via: toslink, hdmi arc or headphone socket |
| 13:08 | dv_ | hmm |
| 13:08 | dv_ | well, gotta run. keep me posted about vmeta! |
| 13:36 | Marmotte | does anyone know why I have to unplug/replug the ethernet cable to make tftp work on u-boot ? |
| 13:37 | Marmotte | exactly, I have to try a tftp transfer, then stop it, unplug/replug the cable, and the next transferts will work |
| 13:37 | Marmotte | never understood why |
| 15:16 | dbsx | Marmotte: same with my uboot. I dont know why either. You need to convince Rabeeh that it happens. |
| 15:18 | Marmotte | ok, I'm not alone :D |
| 15:19 | Marmotte | when you know how to make it work, it's not really blocking ^^ |
| 15:22 | _rmk | 15:22 * _rmk_ keeps looking at your nick and reading it as Marmite :p |
| 16:03 | dbsx | Marmotte: One workaround I tried was to add the ping command and ping before the TFTP (it solved a similar problem on Sheevas), it made no diff on the cubox. |
| 16:32 | Marmotte | I didn't have any problem on my sheeva |
| 16:32 | Marmotte | but I don't use the Marvel u-boot on the sheeva, I use the denx version |
| 16:53 | dbsx | http://www.denx.de/wiki/view/DULG/TFTPTimeout |
| 18:02 | Marmotte | _rmk_: oops, I didn't see :D |
| 18:02 | Marmotte | why "Marmite" ? :o |
| 20:41 | _rmk_ | Marmotte: because of the similarity in spelling |
| 20:42 | _rmk_ | well, no sign of the GPU event handling bug yet. |