| 01:20 | _rmk_ | damn it... damn damn double damn. |
| 01:21 | _rmk_ | the galcore stuff for mapping user memory to the GPU always wants the memory region to be writable - even if you intend to only read, otherwise it fails. |
| 01:21 | _rmk_ | this is a problem for Xv, because the XSHM buffer is mapped into the server read-only |
| 01:22 | _rmk_ | so... we can't use gcoOS_MapUserMemory() on it. |
| 08:32 | wumpus | _rmk_: I don't think the vivante mmu has a read only bit for pages |
| 08:34 | wumpus | _rmk_: although it is possible to install different page tables for the various modules, so it could be possible to install a certain page for texture use |
| 08:35 | wumpus | _rmk_: but the kernel module doesn't use this |
| 10:25 | _rmk_ | wumpus: it would be nice if it did, but... if you're only using it as a source for an operation (as I want to) |
| 10:25 | _rmk_ | otherwise it means I'm going to have to memcpy the Xv image data |
| 10:54 | wumpus | yeah I agree it sucks, there should be some way to map read only buffers |
| 11:04 | _rmk_ | I'll just do it as an extension, like I did for doing the dmabuf stuff |
| 11:06 | _rmk_ | they helpfully provided a call in the library to be able to call any ioctl number on the galcore device node |
| 11:27 | wumpus | do you have your modified kernel driver online somewhere? I'm interested in the dmabuf stuff |
| 11:29 | wumpus | soon going to need it too |
| 16:56 | _rmk_ | oh my, the vivante stretch blit is... horrid. |
| 17:07 | _rmk_ | and it can't do a clipped stretch blit either |
| 17:08 | _rmk_ | (it can, but only to one rectangle at a time) |
| 17:22 | jnettlet | _rmk_, I assume you are talking about the Vivante 2D engine. |
| 17:23 | _rmk_ | yea |
| 17:23 | _rmk_ | its also pixelating the video too |
| 17:23 | _rmk_ | with just a horizontal stretch |
| 17:24 | jnettlet | at 1080p? |
| 17:24 | jnettlet | or any video |
| 17:24 | jnettlet | or any resolution I should say. |
| 17:24 | _rmk_ | nope, this is 720x576 => 1024x576 |
| 17:25 | _rmk_ | I'm not sure if its the filterblit doing the yuv->rgb conversion doing this, or the stretch blit |
| 17:26 | _rmk_ | using overlay at the same destination resolution with the same yuv source frame results in a perfect picture |
| 17:27 | jnettlet | but that can semi be expected as the dove/pxa graphics hardware has some built in hardware smoothing. |
| 17:27 | jnettlet | I think the armada 510 has it. I think Marvell calls it qvideo or something |
| 17:28 | jnettlet | Qdeo |
| 17:28 | _rmk_ | I wouldn't call it "smoothing", i'd call it pixelating |
| 17:29 | _rmk_ | for example, diagonal lines look like they're drawn on a BBC micro. |
| 17:29 | jnettlet | this would be on the overlay not textured xv adapter |
| 17:29 | _rmk_ | no, overlay is fine |
| 17:30 | _rmk_ | I'm rapidly forming the opinion that using the GPU for video output is a hopeless case unless I find something wrong very soon. |
| 17:30 | _rmk_ | the picture looks _soo_ crap |
| 17:31 | jnettlet | I have definitely not noticed that problem on the XO screen. |
| 17:31 | jnettlet | Do you have a test video I can check with? |
| 17:33 | _rmk_ | I don't think it needs any particular video source... standard dvd is good enough to show it |
| 17:37 | _rmk_ | jnettlet: ah, I just found something: in the dovefb driver, they use the filterblit to also do the scaling |
| 17:37 | jnettlet | _rmk_, yep was just about to ask you about that |
| 17:38 | _rmk_ | which kinda makes the stretch blit redundant |
| 17:38 | jnettlet | I thought I had removed the stretch blit. |
| 17:38 | jnettlet | or it exists only if the filterblit isn't used |
| 17:42 | jnettlet | oh right it has the StretchBlit separate in the XV driver. |
| 17:43 | _rmk_ | yep |
| 17:46 | jnettlet | yeah I just went back and looked at the code. The stretchblit exists because sometimes we were seeing video not drawn to the edge of the window because of alignment problems. |
| 17:47 | jnettlet | you would get flickering on the right edge |
| 17:47 | jnettlet | it was just certain formats and sizes. |
| 17:48 | jnettlet | I think I fixed that when I went through and cleaned up all the alignments to match but never changed that blit back to a standard one. |
| 17:51 | jnettlet | Right...I bet if your blit source and destination are 64-byte aligned then they could look like shit. |
| 17:51 | jnettlet | s/are/are not/ |
| 17:55 | _rmk_ | I've seen what that does (with the DDX PutImage) and its not that |
| 18:11 | _rmk_ | hmm, the textured adapter in dovefb doesn't do any scaling in the filter blit, but the mixed overlay does |
| 18:23 | dv_ | what does "mixed overlay" actually mean? |
| 18:24 | dv_ | jnettlet: any progress on the flickering? |
| 18:28 | _rmk_ | heh, that didn't work. |
| 18:28 | _rmk_ | gcmERR_BREAK: status=-1 @ gcoHARDWARE_AllocateTemporarySurface(5396) in gc_hal_user_hardware.c |
| 18:28 | _rmk_ | gcmERR_BREAK: status=-1 @ gcoHARDWARE_FilterBlit(1659) in gc_hal_user_hardware_filter_blt_vr.c |
| 18:29 | dv_ | oh btw |
| 18:29 | dv_ | jnettlet: could userspace talk to the vivante 2d engine directly? |
| 18:30 | _rmk_ | noooooooooooooooooooo that's the wrong answer to the problem |
| 18:30 | dv_ | I think this is possible on freescale imx6 |
| 18:30 | _rmk_ | if you go down that route, you have no security what so ever on the platform |
| 18:30 | _rmk_ | (not that there's any security on the cubox because of this either) |
| 18:31 | dv_ | yep, security wasnt a big concern in the armada it seems |
| 18:32 | dv_ | neither was it for freescale apparently. their userspace API docs mention functions like gcoHAL_MapUserMemory() |
| 18:36 | dv_ | _rmk_: I get the impression that embedded device manufacturers simply dont care about exposing physical addresses. they expect the BSP to add layers that applications can then use, effectively hiding the physical addresses manually |
| 18:36 | dv_ | like android for example |
| 18:39 | _rmk_ | I think I'm going to put the idea of textured video on the back burner for the time being. |
| 18:53 | jnettlet | dv_, yes it is possible. There is an option in the kernel driver that needs to be enabled |
| 18:56 | jnettlet | but I agree with _rmk_that is not the answer we are looking for |
| 18:57 | jnettlet | freescale actually uses the same driver just with different gc_hal options. They actually tend to get the newer stuff before arm |
| 18:58 | jnettlet | sorry about the delay. I was working out front and got ambushed by the neighbors kids :-) |
| 18:58 | dv_ | jnettlet: I am suspecting that either the newer x driver or the x driver compiler flags I use need to be changed |
| 18:58 | dv_ | dsd told me he didnt see flickering |
| 18:59 | dv_ | so, perhaps reverting to the older driver could fix things |
| 18:59 | jnettlet | dv_, I definitely saw the flickering on XO hardware. |
| 18:59 | dv_ | yes, with my rootfs |
| 18:59 | dv_ | and therefore,with that driver |
| 19:00 | dv_ | dsd probably has a different version, and/or different compiler flags |
| 19:00 | jnettlet | dv_, nope on my XO-4 with your gstreamer 1.0 plugins compiled against the XO userspace |
| 19:00 | dv_ | oh |
| 19:00 | dv_ | then perhaps it was a coincidence |
| 19:02 | jnettlet | I attempted an XO overlay for openembedded over the weekend. I didn't get too far as my Danish studies are sucking the life out ofme. |
| 19:03 | _rmk_ | Danish studies? |
| 19:04 | jnettlet | _rmk_, They make you learn Danish as part of your Visa contract here. |
| 19:05 | dv_ | oh you are moving |
| 19:06 | jnettlet | I moved. Been in Denmark over a year now. |
| 19:07 | jnettlet | Canada kicked us to the curb with Harper's new immigration plan of 2012 |
| 19:08 | jnettlet | Maybe we can get a Cubox EU hackfest together at some point. |
| 19:12 | dv_ | heh |
| 19:12 | dv_ | in a box-shaped room :P |
| 19:13 | jnettlet | yep a perfect cube. And we will need cube shaped scotch glasses and pints |
| 19:18 | jnettlet | _rmk_, you are developing against a debian based image? |
| 19:19 | _rmk_ | ubuntu 12.04.1 |
| 19:25 | jnettlet | okay thanks |
| 20:01 | _rmk_ | ok, so if I understand this correctly, to make GPU-based Xv work with the vivante stuff, we need: |
| 20:01 | _rmk_ | 1. to convert from yuv to rgb - so a buffer for the converted image |
| 20:02 | _rmk_ | 2. to scale it appropriately - so another buffer for this |
| 20:02 | _rmk_ | 3. then blit it onto the drawable |
| 20:02 | jnettlet | 1 and 2 should be able to happen in one command |
| 20:02 | _rmk_ | (where 1+2 normally happen inside the filter blit, with the intermediate buffer allocated by the closed libs) |
| 20:02 | jnettlet | yep |
| 20:03 | _rmk_ | so we end up with the intermediate buffer allocated and freed multiple times with all the expense of that |
| 20:04 | _rmk | 20:04 * _rmk_ fails to see how this can be a good idea |
| 20:06 | jnettlet | That is how it works now, however I don't think that is really needed. |
| 20:08 | jnettlet | don't we really just need an intermediate buffer for each drawable allocated for the screen? So if we are page flipping two buffers we need two drawables. |
| 20:08 | jnettlet | even if we get more decoded frames than that we can't put them on the screen seamlessly |
| 20:10 | jnettlet | for a media player you don't get much benefit. The benefit for the XO was with rotating the screen while playing video. |
| 20:55 | ezequielgarcia | _rmk_: are you around? |
| 20:55 | _rmk_ | mmm? |
| 20:56 | ezequielgarcia | _rmk_: maybe you can help me understand why does orion_wdt need to clear the irq bridge cause |
| 20:56 | ezequielgarcia | _rmk_: you did a patch to fix the clearing, and i'm trying to remove the clear altogether. |
| 20:56 | ezequielgarcia | _rmk_: however i cannot understand *why* is that cleared in the first place |
| 21:06 | _rmk_ | unfortunately, the specs are really vague as to how the watchdog works, so I can't tell you much about it |
| 21:07 | _rmk_ | the only thing is... that's what's done on the other Marvell platforms, and I guess there must be a reason for it |
| 21:07 | _rmk_ | My best guess for it is this: if the interrupt bit is set, and we enable the timeout to cause a hardware reset, could we end up with an immediate system reset at that point... |
| 21:08 | ezequielgarcia | _rmk_: hm... |
| 21:20 | jnettlet | I can ask James over on olpc-devel about it. He did the Openfirmware implementation of the watchdog on the XO platforms. I know he spent a decent amount of time exchanging emails with Marvell about it. |
| 21:21 | ezequielgarcia | jnettlet: James ? |
| 21:21 | jnettlet | ezequielgarcia, James Cameron. His irc handle is Quozl |
| 21:21 | ezequielgarcia | hm... ok. i'll definitely keep this in mind. |
| 21:23 | jnettlet | He was our QA guy but picked up the OFW flag under the mentoring of MitchBradley |
| 21:23 | jnettlet | doesn't do too much at the kernel level but has done a bunch of work at the firmware level. |