| 09:05 | dv_ | _rmk_: I stumbled upon the 1024x1024 limit btw |
| 09:05 | dv_ | it also applies to non-180degree rotations |
| 09:06 | dv_ | so if you have a 720p picture for example, and want to rotate its contents by 90?, no can do. 180?, no problem. |
| 09:06 | dv_ | funny thing is, flipping and mirroring also work fine, so 90? can be achieved by doing one flip and one mirror. |
| 09:07 | dv_ | also, the fact that 1:1 copies are considered an error sucks >:( |
| 09:13 | unununium_ | Good morning. |
| 09:13 | unununium_ | jnettlet: You were right. I can change the order! :) |
| 09:18 | jnettlet | unununium_, great. |
| 09:27 | dv | 09:27 * dv_ needs to look up these "tiling" formats for the IPU |
| 09:27 | dv_ | is it worth doing so? or should I just restrict rotations to 180? ? |
| 09:28 | jnettlet | dv_, If you are using the freescale ipu driver it should be doing it automagically I believe. |
| 09:28 | dv_ | jnettlet: I am referring to the blitter |
| 09:29 | dv_ | if I rotate the output, and size is > 1024x1024 , it doesnt work |
| 09:31 | jnettlet | dv_, is this for your gstreamer sink plugin for the imx6? |
| 09:31 | dv_ | yes, but for the videotransform element |
| 09:32 | dv_ | I noticed how 90? rotation of a 720p video failed and produced dmesg error logs |
| 09:35 | jnettlet | dv_, what is the interface to that blitter? Is there and api to use from userspace? |
| 09:35 | jnettlet | I haven't had a chance to dig into that part of the imx hardware yet. |
| 09:36 | dv_ | no userspace api. you need to use kernel headers. this is a problem freescale knows about. |
| 09:37 | dv_ | there is an ipu-lib, but it works only for imx5 and older |
| 09:37 | dv_ | control goes over ioctls |
| 09:44 | dv_ | there is unfortunately not much documentation on how to use the blitter. I gathered the info from examples scattered around in the imx-test package. perhaps my code is useful to look up how to do things: https://github.com/dv1/gstreamer-imx/blob/master/src/ipu/blitter.c |
| 10:02 | jnettlet | dv_, I just looked at the kernel source a little bit more. Looks like you only get the automagic tiled rotation handling if the format is IPU_PIX_FMT_TILED_NV12 |
| 10:05 | jnettlet | make that isn't IPU_PIX_FMT_TILED_NV12 sorry |
| 10:06 | jnettlet | http://fpaste.org/57099/43191138/ |
| 10:06 | jnettlet | this is under check_task() which happens when you submit the task. |
| 10:14 | rabeeh | dv_: for IPU; the following register does magic on xbmc - |
| 10:14 | rabeeh | devmem 0x020e0018 32 0xffffffff |
| 10:15 | rabeeh | this marks all IPU AXI QoS transactions with 0xf towards DDR thus marking them as real time stream |
| 10:15 | rabeeh | i.e. it bypasses all GPU, CPU and other transactions to be first. |
| 10:16 | rabeeh | for C1 solo 512MB x 32bit width it makes xbmc very much usable |
| 11:10 | rabeeh | guys. looks we have made it. we will start shipping the systems tomorrow Thursday |
| 11:10 | rabeeh | 3 days earlier :) |
| 11:11 | rabeeh | s/guys/guys & girls |
| 11:17 | lioka | \o/ |
| 11:24 | dv_ | jnettlet: correct |
| 11:24 | dv_ | rabeeh: hmm that could be useful for speeding up video transformations |
| 11:25 | jnettlet | dv_, and you are saying that is failing? |
| 11:25 | dv_ | yes. I am not using tiled format.s |
| 11:25 | dv_ | for example, rotating 720p frames with I420 video format by 90 degrees fails |
| 12:10 | jnettlet | dv_, I will have to play with that. if a 90 degree rotation is failing that means the split code in the ipu driver isn't working properly. |
| 12:10 | jnettlet | or something else is going wrong. |
| 12:27 | oliver_ | Hey hey. do all boxes ship? (i am waiting for the pro .... |
| 13:05 | rabeeh | oliver_: when did you order? |
| 13:05 | rabeeh | oh; oliver_ is gone. |
| 16:13 | krovy | hello |
| 16:13 | krovy | any new updates wit the shipment |
| 16:13 | krovy | ? |
| 16:31 | _rmk_ | jnettlet: what's the story behind the addition of the ALLOC_ALIGN_BYTES checks? |
| 16:32 | _rmk_ | yes, there's a restriction on the pitch, but it seems in practise - maybe its just on the GC600 - that the address itself doesn't need to be aligned |
| 17:17 | jnettlet | _rmk_, It is practice vs docs. I too have never run into a problem in testing but Vivante's docs do specify the offset alignment. |
| 17:18 | jnettlet | really we are only talking about maybe 20 large consecutive chunks. You are really not losing much if any memory by requiring it on the off chance there is some hardware requirements for it. |
| 17:19 | jnettlet | In varying source released from Vivante you will see the offset alignment requirements bounce back and forth. Sometimes the alignment is set to 8 with a comment that this may need to change. |
| 17:21 | _rmk_ | just watching my script do the massive rebase of cubox branches onto v3.12 atm.. and fixing up the odd conflict |
| 17:22 | _rmk_ | jnettlet: so sometimes its 8 and sometimes its 64 ? |
| 17:23 | jnettlet | _rmk_, those are the two numbers that are generally used if something is explicitly set. |
| 17:23 | jnettlet | I go with 64 as that covers the 8 |
| 17:23 | _rmk_ | unfortunately, that breaks my PutImage acceleration |
| 17:24 | _rmk_ | 8 wouldn't though. |
| 17:24 | jnettlet | well give it a go, I am not hard set on those values. More than anything I was just following the "safest" value that followed mismatched docs and implementations |
| 17:25 | _rmk_ | as I say, it works fine on gc600 |
| 17:26 | jnettlet | I have tested with 8 and also not found a problem. I am open to changing it with a comment that this may need to go back or become configurable if problems are reported. |
| 17:28 | _rmk_ | maybe change it to 8 and stick a comment there saying /* Verified alignment of 8 works on the GC600 rev 19 */ |
| 17:28 | jnettlet | are you updating your libvmeta to use libphycontmem? |
| 17:29 | jnettlet | I can do that. I am going to hack on this more in the morning. Now that we have possible multiple consumers it makes sense to get it into proper community shape. |
| 17:30 | _rmk_ | I will be at some point... though your revelation that ion's user api isn't that stable... |
| 17:31 | _rmk_ | are you looking at my libvmeta for that? |
| 17:31 | jnettlet | well that is why I actually give credit to Marvell for creating libphycontmem. Horrible name but it is a needed abstraction that can buffer the churn of the kernel api's |
| 17:31 | _rmk_ | that depends whether you have my miscdev vmeta of course |
| 17:32 | jnettlet | I do have your miscdev vmeta, and have a couple of patches on top of it based on my uio-vmeta. |
| 17:32 | _rmk_ | can you send me those too? let's try to keep the delta minimised :) |
| 17:35 | jnettlet | yep, after morning cleanup. The client API hasn't changed much. It is most just trying to sort out clocks properly. All the Marvell clocks for these power islands need to be rewritten so prepare/unprepare handles powering the island on and then enable/disable just manages the clocks. |
| 17:36 | jnettlet | I have fixed that for the GPU clocks as well. |
| 17:37 | jnettlet | This will be a fun project to get running on the Cubox/Cubox-i hardware. https://01.org/dleyna/blogs |
| 17:37 | jnettlet | an HTML5 app has received full DLNA certification. |
| 17:37 | jnettlet | Intel has written the entire stack. |
| 17:39 | jnettlet | _rmk_, with the ION changes the plus side is that the map_fd (should probably rename it) descriptor is a dma-buf file descriptor. |
| 17:42 | jnettlet | dv_, if I am going to hack on libphycontmem/vmeta stuff tomorrow is there anything specific that you need added? |
| 17:42 | dv_ | just a notice when I should update the OE layer |
| 17:43 | jnettlet | and have you gotten vblank working? If not I can finish my patch now. |
| 17:43 | dv_ | ah, and some sort of #define or version number to check that the updated libphycontmem is present |
| 17:43 | dv_ | no, not yet |
| 17:43 | jnettlet | good call. |
| 17:43 | dv_ | I tried calling this macro, but it didnt block as expected |
| 17:44 | dv_ | I looked into the driver source briefly, and perhaps the fb mode is wrong (the ioctl is ignored unless its in BLANK_UNBLANK mode) |
| 17:45 | dv_ | yeah, a #define so I can do #ifdef NEW_PHYCONTMEM_STUFF #else |
| 17:45 | jnettlet | I was wondering about that when reading the source. Still haven't consumed all the freescale idiosyncracies yet. |
| 17:45 | dv_ | also, since phycontmem allows for write-combine, I can finally offer other gstreamer elements the DMA buffer pools. but again, this must be disabled if older codebases (not using phycontmem) are used |
| 17:47 | jnettlet | could that just be a compile time detection? |
| 17:47 | jnettlet | and map_fd, should that become dmabuf_fd or just dmabuf? |
| 17:50 | dv_ | compile time detection, thats what I mean, yes |
| 17:51 | jnettlet | dv_, I will add a proper automake and a .pc file to make that easier. |
| 17:54 | jnettlet | yes I know you prefer waf. Maybe I should just use waf for libphycontmem.....hmmm |
| 17:54 | dv_ | just use whatever you prefer |
| 17:55 | dv_ | a .pc file with some clear versioning or some other metadata inside to unambiguously identify the updated libphycontmem works for me |