| 03:18 | Coburn | Carrier One? |
| 03:18 | Coburn | Sounds like a ship |
| 03:19 | Coburn | Ah, the R-Pi-like board that snips a page out of the R-Pi design book |
| 03:21 | Coburn | heh, my CuBox ES has been running so stable, I've forgotten all about it |
| 03:21 | cbxbiker61 | yes, the beauty of soc's |
| 09:42 | dv_ | rabeeh, wumpus: the vivante GPU always is a problem, energy-wise? |
| 09:43 | dv_ | because, on the imx6, the GPU is how I display video |
| 09:44 | dv_ | but I do not see another way - does the vivante chip have something in its 2D engine for YUV output from physical buffers? |
| 10:00 | jnettlet | dv_, the libGAL can handle YUV formats |
| 10:03 | dv_ | hmm is it accessible from userspace? |
| 10:03 | dv_ | and can I associate rendered output with x11 windows in a safe manner? |
| 10:03 | jnettlet | yep. That is what we do with the PutTextureImage in the XV code. |
| 10:04 | dv_ | alright then. |
| 10:04 | dv_ | that will be another video sink I guess |
| 10:04 | jnettlet | the rendered output needs to get blitted to the output window by the 2d engine |
| 10:05 | jnettlet | but the engine does the YUV to RGB conversion |
| 10:05 | dv_ | so, first use GAL for YUV -> RGB, to an offscreen buffer? |
| 10:05 | dv_ | then from the offscreen buffer to the window? |
| 10:06 | dv_ | also, it sounds as if this wont work with x11 compositing enabled |
| 10:06 | jnettlet | I would go right to the window |
| 10:07 | dv_ | so when you say "to the window", what does this actually mean? would GAL copy the pixels directly to where the window is on the framebuffer? |
| 10:07 | dv_ | or would it copy into the window pixmap? |
| 10:07 | jnettlet | To the window pixmap, then it will work with compositing |
| 10:07 | dv_ | ah. good. |
| 10:08 | jnettlet | as the compositor may want it to be offscreen |
| 10:08 | dv_ | the former wouldnt have worked with (partially) occluded windows and compositing |
| 10:08 | dv_ | huh. perhaps I could also use this for the cubox. |
| 10:08 | dv_ | would be cleaner than going through the xv hack |
| 10:08 | jnettlet | are you working on dmabuf stuff? |
| 10:08 | dv_ | no |
| 10:09 | dv_ | well, not right now |
| 10:09 | dv_ | I am finishing imx gstreamer 1.0 plugins |
| 10:09 | jnettlet | doesn't the imx xorg driver do this already? |
| 10:09 | dv_ | do what already? |
| 10:10 | dv_ | the thing is how to display frames stored in physical buffers |
| 10:10 | jnettlet | use the XV textured adapter to do the conversion with the 2D engine |
| 10:10 | dv_ | without invoking an (implicit) memcpy |
| 10:11 | dv_ | since Xv has no official way to do this, you either need hacks like the one from marvell, or have to live with the copy |
| 10:11 | dv_ | the two ways I have found to work so far are: (1) use GLES with the Vivante direct textures (2) use the IPU to blit to framebuffer |
| 10:12 | dv_ | but (1) activates the GPU, which isnt nice for power saving, and (2) does not play nice with x11 and/or compositing |
| 10:34 | ralix | morning |
| 10:35 | jnettlet | morning |
| 11:02 | wumpus | dv_: you could also use the vivante 2d engine for the video from-yuv conversion and scaling, then again, I suppose that will have the same problem as the IPU |
| 11:05 | wumpus | at least when the window is obscured; you can't provide a list of quads to the 2d engine when doing the video filtering |
| 11:58 | jnettlet | wumpus, that is what we were talking about |
| 11:58 | wumpus | ok |
| 11:58 | wumpus | he talks about enabling the 3d enigne that should not be needed |
| 11:59 | jnettlet | wumpus, that was to use DIRECT_VIVANTE_GLES_TEXTURES |
| 11:59 | jnettlet | or whatever that is called :-) |
| 12:01 | jnettlet | wumpus, dv_, I was actually thinking about this during my walk and I think this may be a good way to go forward. This would then enable all Vivante hardware in all windowing environments a way to display a screen ready image through gstreamer |
| 12:02 | jnettlet | However there is also a gstreamer sink for KMS that may also work. I need to look at that. |
| 12:02 | _rmk_ | jnettlet: don't forget the scaling issue I ran into |
| 12:03 | jnettlet | _rmk_, I am actively looking at that. |
| 12:49 | _rmk_ | shesselba: something's up with your mailer |
| 13:35 | dv_ | wumpus: as jnettlet told me, the vivante 2d engine can blit into a window pixmap, which makes it play nice with compositors and obscured windows |
| 13:36 | dv_ | jnettlet: what is this kms sink? |
| 13:37 | wumpus | yes it can blit into pixmaps, doesn't need to go through any special tiled format like the 3d engine |
| 13:38 | jnettlet | dv_, the kms sink is a direct DRM client for gstreamer |
| 13:38 | dv_ | hmm I did not know about it! |
| 13:38 | dv_ | is it in 1.0 ? |
| 13:39 | dv_ | oh right, it is in -bad |
| 13:39 | jnettlet | I think it only works with overlays for now. |
| 13:39 | dv_ | obviously requires kms though, as in: not with the closed source vivante drivers |
| 13:40 | jnettlet | _rmk_'s driver uses KMS and vivante drivers. Two separate abstractions |
| 13:41 | jnettlet | KMS is memory and output management. Vivante is drawing acceleration |
| 13:42 | jnettlet | dv_, I like the idea of having a vivante gstreamer sink to use. It could be useful to all SOC's using all sorts of windowing devices without any extra overhead. |
| 13:43 | wumpus | is _rmk_'s stuff already available somewhere? (sorry to keep asking, but it would be terribly useful for us too, even if not compeltely finished) |
| 13:44 | jnettlet | wumpus, his xorg driver is up on his site. His vivante src is still awaiting liberation I believe. |
| 13:45 | jnettlet | haven't seen him around so I assume he is busy |
| 13:47 | wumpus | it's the vivante dmabuf stuff I'm mostly interested in |
| 13:48 | wumpus | kms support is one of the few things I really need before pushing my mesa driver upstream |
| 13:53 | dv_ | jnettlet: you mean my idea with using GAL? |
| 13:54 | jnettlet | dv_, yep. That would make it SOC and window'ing system independent. |
| 13:54 | dv_ | agreed |
| 13:55 | dv_ | well not entirely independent |
| 13:55 | dv_ | I still need to create a window :) |
| 13:55 | jnettlet | dv_, |
| 13:55 | jnettlet | sorry |
| 13:55 | dv_ | any GAL examples I can use? or perhaps documentation? |
| 13:56 | dv_ | oh wait. I forgot. there is this nice PDF from freescale |
| 14:01 | jnettlet | dv_, I am waffling a bit. |
| 19:00 | setuid | I just received my CuBox pro last night, plugged it in and am tinkering with it. The first thing that comes to mind, is that it's HORRIBLY SLOW with video. Redraws and repainting is painfully slow. |
| 19:01 | setuid | Is there anything at all that can be done? |
| 19:02 | setuid | The literature claims it can support flash and video, but there's no way this will work that way, it redraws video about 1-2 times every 10-15 seconds |
| 19:02 | setuid | I've been looking at the xorg.conf and dovefb/backing store tweaks, but it's not enough |
| 19:06 | setuid | Is this channel dead/full of bots? |
| 19:07 | jnettlet | I think everyone is working. |
| 19:08 | setuid | Ok, fair enough |
| 19:08 | setuid | What I rec'd was definitely not in line with what I saw in the youtube vids and on the website |
| 19:09 | setuid | The box looks the same, the innards appears to match, but what's installed and how slow it is, doesn't match with what I thought I was supposed to get |
| 19:09 | jnettlet | well it could be the image you are using. Did you use the Universal installer? |
| 19:09 | setuid | I just powered it up and used what was on it |
| 19:10 | jnettle | 19:10 * jnettlet doesn't even know what ships on it at this point. |
| 19:10 | setuid | It shipped with a pretty old version of Ubuntu |
| 19:10 | setuid | Lucid |
| 19:12 | jnettlet | Take a look at http://www.solid-run.com/mw/index.php/CuBox_Installer |
| 19:14 | setuid | Interesting.. I'll have to play with that. There's no way this is going to be usable beyond anything but remote ssh shells at this point, it's pretty slow. |
| 19:15 | jnettlet | I am working on an optimized distro that should be ready by the end of the month. I think you will be pleasantly surprised. |
| 19:16 | setuid | My whole goal for using the CuBox is to replace physical PCs here, so I can use rdesktop back to p2v instances of the original PC, living on my ESXi server now. |
| 19:17 | setuid | The rdesktop part works (after tweaking xorg.conf), but the screen redraw is unacceptable for desktop use |
| 19:18 | jnettlet | is this over wired or wireless? |
| 19:19 | setuid | There is no wireless on the CuBox, so it's just wired |
| 19:19 | jnettlet | well lots of people use usb dongles |
| 19:20 | setuid | Wireless laptops/PCs in the same segment can use rdesktop without an issue, nice and snappy |
| 19:20 | setuid | Moving a window on the CuBox, or remotely through rdesktop is a 2-3+ second redraw operation |
| 19:20 | setuid | It's like the video is being 100% software-rendered, in a few megabytes of video. Feels like it did when we used fbdev on 4M video cards. |
| 19:21 | jnettlet | that seems very wrong. Do you mind posting your Xorg log for me to peak at? |
| 19:22 | setuid | Let me try to rsync it up somewhere, one moment |
| 19:23 | jnettlet | you can just use fpaste.org if it is easier |
| 19:31 | setuid | Have to rsync it off the box first ;) |
| 19:31 | setuid | http://code.gnu-designs.com/CuBox/Xorg.0.log |
| 19:31 | setuid | There you go |
| 19:33 | setuid | http://code.gnu-designs.com/CuBox/Xorg.1.log |
| 19:33 | setuid | There's another, un-truncated |
| 19:38 | jnettlet | setuid, okay things are coming up properly. Like I said hold out a bit. I am trying to pull together all the optimization work that has happened over the last year and half. |
| 19:40 | setuid | *nod*, trying to use the Universal Installer now, looks like it doesn't like opening a serial port |
| 19:40 | setuid | I'm beginning to wonder if my unit is a mulligan, damaged unit or something |
| 19:41 | setuid | No /dev/ttyUSBx shows up at all when I load the appropriate modules on the client side |
| 19:41 | setuid | I'm using LInux -> usb-to-micro-usb -> CuBox |
| 19:41 | jnettlet | not out of the realm of possibility. Make sure to disable hardware flow control. |
| 19:41 | jnettlet | oh that is very odd |
| 19:42 | jnettlet | well I have to take care of some things. welcome to the channel and hang out a bit. we will make sure to get your unit up and running |
| 19:43 | rabeeh | setuid: which terminal emulation are you using? |
| 19:43 | rabeeh | it's not Universal Installer; it's called CuBox installer. |
| 19:46 | setuid | rabeeh, I'm following this: http://www.solid-run.com/mw/index.php?title=CuBox_serial_port |
| 19:46 | setuid | linked from this: http://www.solid-run.com/mw/index.php/CuBox_Installer |
| 19:47 | rabeeh | ok |
| 19:47 | rabeeh | you don't need to open serial port if you don't want |
| 19:47 | rabeeh | you can put the installer on a USB thumb drive (use SanDisk - they work for sure on the boot process) |
| 19:47 | rabeeh | then the installer should show up on the HDMI port too. |
| 19:48 | setuid | Looks like the instructions for OSX don't work/aren't relevant for current versions |
| 19:48 | setuid | This doesn't exist: "kextload /System/Library/Extensions/ProlificUsbSerial.kext" |
| 19:49 | setuid | I unzipped the image onto the USB stick, plugged it in, after about 15 minutes of blank screen on HDMI, it boots the installed (SD?) OS |
| 19:51 | setuid | Perhaps my expectations were too high for this device ;( |
| 19:52 | rabeeh | setuid: which usb stick is this? do you have a sandisk? |
| 19:52 | rabeeh | did you keep the /boot/ directory? |
| 19:52 | setuid | Yes |
| 19:52 | setuid | One sec, I'll pastebin/bot the details |
| 19:54 | setuid | Small paste: |
| 19:54 | setuid | # tree /media/2C6F-1020/ |
| 19:54 | setuid | `-- boot |
| 19:54 | setuid | |-- boot.scr |
| 19:54 | setuid | |-- boot.scr.serial |
| 19:54 | setuid | `-- uImage |
| 19:54 | setuid | That's what's on the USB drive |
| 19:55 | rabeeh | did you insert it on the top usb host? |
| 19:55 | setuid | Yes |
| 19:55 | rabeeh | and only then powered on? |
| 19:55 | setuid | Yes |
| 19:55 | setuid | I'll power down and do it again |
| 19:55 | rabeeh | have different usb sticks? i suggest you try others |
| 19:56 | rabeeh | u-boot is picky on the usb sticks brands |
| 19:56 | setuid | Is u-boot installed on the cubox already, such that it can identify the usb drive as a boot source? |
| 19:57 | rabeeh | yes. u-boot is part of cubox and resides in an internal SPI flash |
| 19:57 | rabeeh | when powered on the processor loads u-boot from the SPI flash; then it attempts to boot from usb, sdcard, esata and then tftp from network |
| 19:58 | setuid | I'd love this thing to tftp one of my ESXi images ;) but that's not going to happen just yet, not on 800Mhz and 2M of ram |
| 19:59 | rabeeh | 2G of ram |
| 19:59 | setuid | With only 2 USB ports, I'm going to have to be creative with how this works, either add a usb hub + bluetooth dongle, or something else, so I can use keyboard, mouse, peripherals with it. |
| 19:59 | setuid | Right, 2G, sorry |
| 20:00 | setuid | Runs pretty hot too, warmed up the USB drive hotter than I can hold in 10 minutes |
| 20:01 | setuid | Ok, powered off, removed power plug, plugged in USB drive into top port, plugged in power? still nothing on HDMI display |
| 20:02 | setuid | Maybe they screwed it up, and it's the bottom USB port? |
| 20:10 | rabeeh | did you try different usb stick? |
| 20:11 | rabeeh | it's the upper usb port |
| 20:11 | rabeeh | is the red LED on the front on? |
| 20:20 | setuid | Yep, the device physically works, boots to the SD card, just doesn't seem to want to run the u-boot => CuBox installer |
| 20:21 | setuid | Just dumped some OS X ._.Trash and other garbage files from the drive, trying another boot now |
| 20:21 | setuid | I don't have a lot of usb thumbdrives around, but I'll see what I can find |
| 20:21 | setuid | I have a usb adapter that takes a micro-SD card, maybe that will work |
| 20:23 | setuid | I have a feeling it's either not owrking, or it's working, but expecting a serial port, which doesn't work using OSX or Linux, because the kext isn't valid on current OS X (10.7.8) nor on Linux (usbserial no longer exposes ttyUSBx devices) |
| 20:27 | setuid | Trying another USB drive now, another SanDisk Cruzer Titanium |
| 20:28 | setuid | It light up (blue light) when I plugged in the CuBox, throbbed for a sec, then went out. CuBox's red light is lit, but no video over HDMI, no light on USB drive, just sitting there with a red light |
| 20:41 | setuid | Trying third and last usb dongle now |
| 20:41 | setuid | Yay1 |
| 20:42 | setuid | Which distro should I try here? |
| 20:43 | setui | 20:43 * setuid gives Ubuntu 13.x a try. If this fails, at least I can reboot and try it again |
| 21:44 | setuid | Can the CuBox Pro handle my Dell u3011's 2560x1600 resolution over HDMI? |
| 21:45 | setuid | Looks like it can't even handle 1900x1200, screen blacks out, only 1920x1080 is supported :( |
| 21:49 | _rmk_ | setuid: the NXP HDMI driver is rather "special" in that it only supports resolutions it knows of back when it was written |
| 21:50 | _rmk_ | the only 1200-line resolution it knows of is 1600x1200 |
| 21:50 | _rmk_ | and it knows nothing of 2560x1600 |
| 21:51 | setuid | It causes the display on the monitor to auto-scale, which is a bit blurry |
| 21:51 | dv_ | jnettlet: how can I associate a window with a galcore surface? |
| 21:51 | _rmk_ | there are (slow) efforts in progress to fix this by effectively rewriting the entire video backend |
| 21:51 | setuid | My Macbook Air 11" on the 30" Dell monitor at full resolution is downright BEAUTIFUL |
| 21:52 | _rmk_ | much of the slowness of that is because is very very hard to get anything into the mainline kernel |
| 21:52 | setuid | Requires a HDMI -> mini DisplayPort adapter to work on the MBA, but it does drive the full res. |
| 22:00 | _rmk_ | there's another complication with going over 1920 pixels on a line - the vertical scaling of video images is done by a RAM which has enough space for 1920 pixels x 3 lines |
| 22:03 | shesselba | setuid: also 2560x1200 most likely exceeds Cubox's clock generator max. frequency. 1920x1080 will be the max resolution you will get. |
| 22:04 | dv_ | _rmk_: somebody over at #etnaviv has expressed interest in vmeta vaapi support |
| 22:07 | _rmk_ | dv: heh :) |
| 22:07 | dv_ | how is yours going? |
| 22:07 | dv_ | and: slowly gearing up for imx development? |
| 22:09 | cbxbiker61 | dv_, i put a vote in for vmeta vdpau support |
| 22:09 | dv_ | vdpau is nvidia only |
| 22:10 | cbxbiker61 | no, it's an api |
| 22:10 | cbxbiker61 | open source radeon is using vdpau quite nicely |
| 22:10 | _rmk_ | dv: I think I have H264 going, but it won't work with vlc... too much CPU usage |
| 22:10 | _rmk_ | well, sort of going. |
| 22:11 | _rmk_ | H264 with vaapi can _only_ work if you manually decode the stream first and then define the stream "defaults" and rebuild the vaapi driver :( |
| 22:11 | _rmk_ | in other words, all the time that vmeta is closed source, it can't be made to work |
| 22:11 | _rmk_ | mpeg2 and mpeg4 can and do work |
| 22:11 | _rmk_ | mpeg1 is hosed by the vaapi being crap |
| 22:12 | _rmk_ | vc-1 I've stayed away from |
| 22:13 | _rmk_ | even vaapi on Intel can't decode mpeg1 |
| 22:13 | _rmk_ | I mailed the vaapi mailing list, and my mail went into the moderation queue and I suspect no one approved it |
| 22:13 | _rmk_ | so I've more or less given up any hope of vaapi being fixed in that regard |
| 22:13 | dv_ | hmm |
| 22:14 | dv_ | vdpau then? as cbxbiker61 suggested? |
| 22:14 | cbxbiker61 | mesa has a vdpau state tracker, so neouvo and radeon drivers use it |
| 22:14 | _rmk_ | from what I've seen in the vaapi, vaapi can be put on top of vdpau, which would probably also mean no h264 too |
| 22:14 | setuid | hrmph, looks like the default xorg.conf can't work with rdesktop without lowering it to 16bpp, which is a bit blocky, visually |
| 22:15 | setuid | and hwcursor doesn't work well over rdesktop, it renders the cursor as a white, non-anti-aliased arrow, ugly, no shadows |
| 22:15 | dv_ | no I mean using vdpau directly |
| 22:15 | dv_ | why vaapi btw? |
| 22:16 | cbxbiker61 | i'm tracking down a bit memory leak in xbmc git now somewere between 9/12 and 9/18 |
| 22:16 | cbxbiker61 | can't even watch one show to completion before it pukes |
| 22:17 | _rmk_ | my point is that if you can wrap vdpau up in vaapi, that means vdpau also doesn't get the elementary stream, which means you're running into the exact same problems wrt h264 |
| 22:19 | _rmk_ | yep, just looking in the vdpau driver, for H264 it just passes the decoded parameter set across to vdpau |
| 22:19 | dv_ | I think vdpau can use an elementary stream |
| 22:20 | dv_ | here: ftp://download.nvidia.com/XFree86/vdpau/doxygen/html/group___vdp_decoder.html#gae1d7dacb05aa8badbc9c38018e2e36c9 |
| 22:20 | dv_ | you pass in bitstream buffers |
| 22:21 | _rmk_ | ftp://download.nvidia.com/XFree86/vdpau/doxygen/html/index.html says otherwise |
| 22:21 | _rmk_ | "VDPAU is a slice-level API." |
| 22:21 | _rmk_ | The client application is responsible for: |
| 22:21 | _rmk_ | Extracting the slices from the bitstream (e.g. parsing/demultiplexing container formats, scanning the data to determine slice start positions and slice sizes). |
| 22:21 | _rmk_ | Parsing various bitstream headers/structures (e.g. sequence header, sequence parameter set, picture parameter set, entry point structures, etc.) Various fields from the parsed header structures needs to be provided to VDPAU alongside the slice bitstream in a "picture info" structure. |
| 22:21 | _rmk_ | Surface management (e.g. H.264 DPB processing, display re-ordering) |
| 22:22 | _rmk_ | the second point is where it falls down with vmeta (again) |
| 22:22 | _rmk_ | its the same problem as vaapi |
| 22:22 | _rmk_ | you can't reconstruct the H264 bitstream from that data accurately enough |
| 22:23 | _rmk_ | or in a way that meets the H264 spec so that vmeta will re-read the sequence parameter set and the picture parameter set with updated information for each picture |
| 22:26 | _rmk_ | note that the above page goes on to say: "It is recommended that applications pass solely the slice data to VDPAU; specifically that any header data structures be excluded from the portion of the bitstream passed to VDPAU." |
| 22:26 | _rmk_ | that seems quite definitive to me :( |
| 22:29 | _rmk_ | that basically means a VDPAU driver interfacing into vmeta needs to rebuild the elementary stream |
| 22:29 | _rmk_ | which is exactly what I'm doing with VAAPI |
| 22:31 | _rmk_ | I'm afraid all the time that the vmeta stuff is closed source, it's going to be crippled when trying to use any of these APIs |
| 22:40 | _rmk_ | btw, there's another reason I'm hessitant to try resubmitting the DRM stuff - that is, the SHM buffers I use for the pixmaps arguably should be part of the GPU based DRM driver, not part of the KMS driver, and I suspect David Airlie will not take kindly to it being removed if/when a GPU driver gets sorted |
| 23:20 | jnettlet | _rmk_, I was looking at all the various drivers today and saw the same problem. I think the best solution is to either add GEM support to the Vivante driver, or just use it's routines to allocate buffers in cached memory. |
| 23:21 | jnettlet | Then the KMS driver will only be responsible for allocate the scanout buffers, which will be totally acceptable |
| 23:21 | _rmk_ | jnettlet: the problem with doing that is then the pixmaps are all locked in memory and can't ever be swapped out |
| 23:22 | jnettlet | dv_, I have no idea how you do that off the top of my head. |
| 23:22 | jnettlet | _rmk_, do we want pixmaps swapped out? wouldn't it be better to just destroy them if we run out of memory and then have them recreated? |
| 23:23 | jnettlet | I assume you are meaning offscreen pixmaps |
| 23:23 | _rmk_ | how do you know that you need to destroy them? when another app gets a SIGKILL? |
| 23:24 | jnettlet | well this is usually handled by EXA :-) |
| 23:25 | jnettlet | it would be easy enough to check the heuristics they are using. |
| 23:25 | _rmk_ | its the "my X server has eaten all my memory" problem that used to happen pre-DRM |
| 23:26 | dv_ | jnettlet: know of any gal examples? |
| 23:26 | jnettlet | _rmk_, well that is where you can use the Vivante memory allocations that happen on driver init. |
| 23:27 | _rmk_ | then you're into the "how much memory do we set aside for the GPU" problem |
| 23:29 | jnettlet | well we could change the driver to set high and low thresholds |
| 23:30 | jnettlet | or like I said. change it to support GEM as a memory allocator |
| 23:31 | jnettlet | dv_, you just want to take physical memory have gal memmap it and then use the 2d engine to convert it to rgb and scale it? |
| 23:31 | dv_ | yeah |
| 23:31 | dv_ | gcoSURF_SetBuffer seemed interesting |
| 23:32 | dv_ | but what I am missing is a function that associates a window handle with a gal surface |
| 23:32 | dv_ | you said gal can blit to a pixmap so that it plays nice with the compositor |
| 23:36 | jnettlet | dv_, that was part of my waffling earlier. You can see in the xorg-x11-dove exa driver how a pixmap backed with a galcore image is created. You basically allocate the pixmap structure and then set the data pointer to the galcore surface. |
| 23:36 | dv_ | ah |
| 23:36 | dv_ | yes, makes sense |
| 23:36 | jnettlet | for doing the filter blit and yuv conversion, this does just what you are looking for...mostly. http://dev.laptop.org/git/projects/xf86-video-dove/tree/src/dovefb_xv.c#n3115 |
| 23:36 | dv_ | and what is the difference between a surface and a surface wrapper? |
| 23:37 | dv_ | does a surface allocate its own backing store? |
| 23:37 | dv_ | oh, and _rmk_, just found your favourite Vivante memcopy call with the error return code :) |
| 23:39 | jnettlet | dv_, here is a pixmap creation example. http://dev.laptop.org/git/projects/xf86-video-dove/tree/src/mrvl_exa_driver.c#n1859 |
| 23:40 | dv_ | ah btw the imx6 xorg driver seems to be much better than the dove one |
| 23:40 | jnettlet | although you don't need quite as much checking |
| 23:40 | dv_ | I see DRI, EXA code |
| 23:40 | dv_ | and cacheable pixmaps |
| 23:40 | dv_ | nice! thanks |
| 23:41 | jnettlet | dv_, yep I have a dove version of that here in my archives. Vivante gave me beta code. I built up additional functionality I needed and then they refused to allow us to release it. |
| 23:41 | jnettlet | Well Marvell says it was Vivante. regardless I was less than happy |
| 23:41 | dv_ | apparently, they gave freescale the go ahead |
| 23:41 | jnettlet | yep |
| 23:41 | jnettlet | which pissed me off even more |
| 23:41 | dv_ | my bet is on marvell's legal department being the culprit here |
| 23:42 | jnettlet | but their dri drivers is closed source as well. |
| 23:42 | dv_ | huh? I can see source code |
| 23:42 | dv_ | check out http://download.ossystems.com.br/bsp/freescale/source/xserver-xorg-video-imx-viv-3.5.7-1.0.0.tar.gz |
| 23:42 | jnettlet | the userspace version viviante_dri.so |
| 23:42 | dv_ | oh. right. |
| 23:43 | jnettlet | userspace library. |
| 23:45 | jnettlet | _rmk_, one of the discussions that has been floating around is to use the xf86-video-armsoc as a base for all arm drivers. Make that a generic KMS userspace driver and then support external graphics accelerator drivers. That really fits the hardware much better. |
| 23:46 | jnettlet | Then there can be one shared 2d driver for all SOC's the use Vivante GPU's that gets bolted into a generic KMS userspace driver. |
| 23:47 | dv | 23:47 * dv_ read this as xf86-video-asoc initially :) |
| 23:48 | _rmk_ | jnettlet: there should be little reason why that isn't possible - much of the DRM API is already fairly generic |
| 23:48 | _rmk_ | the bits which aren't are the Xv overlay stuff, and such a driver would never be able to do any zero-copy overlay |
| 23:48 | jnettlet | _rmk_, it looks like they have extended it beyond just exynos at this point. https://git.linaro.org/gitweb?p=arm/xorg/driver/xf86-video-armsoc.git;a=tree;f=src;h=6ffe522ae2a355bc6d10d26220feecc7a5e13031;hb=HEAD |
| 23:49 | _rmk_ | oh god, they're using exa |
| 23:49 | jnettlet | _rmk_, why not? |
| 23:52 | jnettlet | Wouldn't the zero copy XV Overlay just be. Get GEM buffer to draw video to, draw frame, point Overlay to location of frame. Update stuff to have overlay scale it properly? |
| 23:56 | _rmk_ | fine, exa provides a generic set of stuff for doing simple stuff such as "fill this area" and "copy this area". That's fine, but there's a load of render stuff which can be accelerated too - plus there's the getimage/putimage problem with image alignment - exa would need you to either do that operation completely using the CPU or repeatedly fix the source/destination buffer for each box |
| 23:57 | _rmk_ | then there's the whole gpu/cpu access tracking that I'm doing... which turns into a nightmare with render operations unless you recode a bunch of those |
| 23:58 | _rmk_ | jnettlet: what you're talking about there for zero-copy XV overlay is not using the Xv PutImage call at all |
| 23:58 | jnettlet | _rmk_, nope. |