Blogging the Monkey

fedora 19 installer for nexus4

2013-06-05T13:38:00.001-07:00

As promised in my previous post, now there is an f19 installer for nexus4:

https://github.com/freedreno/nexus4-fedora

So if you have an n4 and a bit of free space, you can play around with accelerated open-source gpu goodness :-)

freedreno + gnome-shell on nexus4/a320

2013-06-02T16:42:00.001-07:00

We don't need no binary blobz :-)

gallium/freedreno + xf86-video-freedreno using XA gallium state tracker on fedora F18. Gnome-shell, compiz, xonontic, ioquake all work. Just need to clean up the patches for XA and freedreno a bit more before they are ready for upstream. And hopefully in the next couple days I'll have some time to put together a sort of make-shift installer for anyone else who wants to try.

gallium a3xx es2gears

2013-05-19T18:06:00.002-07:00

So, I've been working on the freedreno gallium support for adreno a3xx for the past few weeks or so, and now it is starting to take shape:

The full video here.

The code is on the a3xx branch on github.. still has a ways got go before I'm ready to go upstream with it, but now we're getting into the fun bits :-)

Special thanks to Benjamin Tissoires for getting the touchscreen going for me on the nexus4.

a320, first renders

2013-04-14T14:57:00.000-07:00

A while back, I got my shiny new nexus4 in order to start playing with the new a320 adreno gpu. It turns out, there are some quite significant changes in the new generation, in particular new shader ISA and all the registers around shader setup. Other registers are mostly shuffled around, with a few new registers for new features (like MRT) and a few tweaks here and there.

There is quite a lot more flexibility in the shader ISA (thank-you opencl), and some nice changes like moving vertex fetch out of the shader and a lot more flexibility in the positioning of outputs/varyings. Although as a result there was more that needed to be figured out to setup the shader related registers compared to a2xx.

At this point, I'm working with simple "fdre-a3xx" tests. Basically libfdre (freedreno reverse engineering) gives a very simplified gl-ish API, with shaders written in assembly, rather than full on GLSL compiler. I've got a pretty good shader assembler/disassembler, and cmdstream parsing utilizing envytools/librnn for parsing the register values. There is still some more work to do at the fdre level (depth, stencil, textures) before work on the gallium driver can start, but things are progressing well.

Fedora 18 + gnome-shell + Freedreno

2013-03-05T20:23:00.001-08:00

After fixing a handful of bugs, and adding support (still in a slightly hacky way) for some desktop GL (1.4) features (namely, GL_QUADS), I've got gnome-shell working with freedreno:

Full video here

I've also made a sort of fedora F18 installer for the touchpad, for anyone out there who wants to give it a spin:

https://github.com/freedreno/touchpad-fedora

Note that gnome-shell itself is not installed by default in the arm fedora builds.. so, 'sudo yum install gnome-shell'

fosdem demo

2013-02-08T06:40:00.000-08:00

Last weekend was fosdem, where I showed a few more things working on freedreno (compiz, q3a). The recording of the talk is provided by phoronix. Although unfortunately the mic was closer to the audience than me (and I'm not really a loud speaker), and the camera remained pointed at the projector while I was showing the demo, so you miss the exciting bits.

So I re-ran the demo and captured it with my advanced cinematic skillz, and without the backlight hickups which plagued the original demo (but had nothing to do with freedreno... have I mentioned before that drivers/video/msm is made of fail?).

Full video here.

I still need to fix support for mip-map textures (which you may have noticed in the q3a part), and there are a couple rendering bugs with the unity plugin in compiz, but at least the other compiz plugins I've tried so far seem fine. Until now I have not put much (or really, any) focus on performance and there is definitely some low hanging fruit on the performance front. Unfortunately some of the issues, like proper synchronization between xorg and gl/dri2 client, and flipping rather than doing fullscreen presentation blits, will I think require a proper drm kernel driver. Although I suspect there is room for some compiler optimization and a few other things.

freedreno gallium update

2013-01-19T16:27:00.000-08:00

Just a quick update, and a sneak-peak at what is in store for FOSDEM. The freedreno gallium driver has made a lot of progress since the last post (sorry, been too busy hacking to blog about it). But now finally xbmc is working with freedreno:

Full video here.

Special thanks to Ricardo Salveti for building a working version of xbmc for 12.10. You can find it in his PPA.

es2gears!

2012-12-10T16:44:00.000-08:00

Another quick update, since it has been a while. I've been working for the last month or so on a gallium driver for freedreno, and now it is finally showing signs of life with es2gears:

There are still a lot of little missing pieces (textures, not translating a lot of tgsi shader opcodes, and it won't work for anything that isn't glClear()ing the color/depth/stencil buffers each frame. Although these shouldn't be too hard to add, just takes time.

The work-in-progress mesa code is on github:
git://github.com/freedreno/mesa.git

freedreno update

2012-10-23T17:19:00.001-07:00

Just a quick update, since it has been a while and I haven't had time to update the old blog:

I managed to get stencil buffer working just before XDC, a bit over a month ago.. no exciting looking demo, but the stencil test (which is based on the stencil example in opengles-book-samples) is now working
Since then I have been starting to get things into shape in order to start on a gallium driver. I've written a libdrm_freedreno module to include the common code for interfacing with the kernel driver, needed by xf86-video-freedreno, fdre, and the eventual gallium driver. Eventually we will need a proper DRM kernel driver, but libdrm_freedreno abstracts this well enough that I can concentrate on the 2d/3d userspace parts. The eventually plan is that when there is a proper DRM kernel driver (supporting a pushbuffer type interface, and synchronization between 2d and 3d pipes), libdrm_freedreno will be the point where we support talking to either the new driver or the existing QCOM kernel driver.
I've fixed the problems that were preventing batching in the 2d driver, so now the performance is starting to be decent for xf86-video-freedreno. There is still some room for improvement (we fall back to sw for some sorts of blits that the hardware should be able to support, but libC2D2 does not, primarily blits with mask surfaces.. but I think I understand enough of the 2d registers to implement the missing blits. And also there is probably some room to optimize the cmdstream a bit for batches of blits.)
I've implemented DRI2 support in xf86-video-freedreno and fdre, so now we have: dri2 lols cats:

So the next step, which I should hopefully be starting on in a week or two is the gallium driver! Of course this is still going to be a lot of work, but things are coming along nicely so far :-)

Open Source lolscat!

2012-08-15T20:27:00.001-07:00

Last weekend I fixed a few issues w/ the assembler to make more complex fragment shaders work, added support for VBO's. And now I've pushed support to enable GL_BLEND. And as a result, I give you open source lolscat:

The model was borrowed from glmark2, the fragment shader uses phong lighting. And two textures are alpha blended in front to give the text.

textured cube (fullscreen!)

2012-08-05T19:46:00.002-07:00

managed to bang out some basic texture support.. and also multi-tile rendering so I'm not limited to render targets that can fit in GMEM (512KiB on the a220 that I have in my touchpad), and of course this is using the freedreno shader assembler (no need for the binary blob):

maybe some day I'll figure out how to make better quality videos :-P

freedreno moves to github

2012-08-02T20:16:00.002-07:00

just a quick update: I've move freedreno to github: http://freedreno.github.com/

I've started to add some wiki pages to document what I've learned so far, and the gitorious wiki was just too useless to deal with.

freedreno update: first renders shader assembler!

2012-07-29T18:58:00.001-07:00

For the last month or so, I've been working on deciphering the adreno shader instruction set and creating a disassembler, and now assembler. I've hooked it up in fdre and now I can run all the test apps with shaders assembled from the fdasm assembler syntax, rather than requiring pre-compiled shaders from the adreno binary blob! This means now I can run 3d tests with no dependency on the binary blob!

No new pictures, everything looks the same as before, including the spinning cube. I've updated the cube test with some comments in the shader assembly to make it a bit easier to follow.

First renders

2012-06-25T18:02:00.000-07:00

Just a quick update about the freedreno project.. after a month or so of not having much time to work on it due to travel and other projects, last weekend I finally had some time to spend on 3d and fdre, a simple library to drive the gpu (similar to limare) and some test apps, and now we have first renders for a few simple test apps.

quad-flat:

triangle-quad:

and triangle-smoothed:

The shaders are currently just binary, extracted via cffdump from egl/gles test apps written to use the same shaders. And for now I'm sticking to smaller render target sizes which can be handled in a single pass without resorting to binning (basically splitting the render up into parts that can each fit within the built in GMEM).

It is of course a long ways from a full blown mesa driver, but I'm making some good progress on figuring out the command stream. No where near the progress of the lima guys, who already have textures working and are pretty far on the vertex and shader compilers.

Fighting back against binary blobs!

2012-04-14T10:17:00.025-07:00

So I'm a big fan of opensrc graphics.. and one thing that has frustrated me for a long time is lack of open graphics on ARM platforms. I'm a big fan of open source in general, and that is why I love TI (and Linaro). TI has been very focused on publishing public TRMs getting support for the OMAP platform in the upstream kernel tree. I can build Linus's kernel tree and get something pretty well functional on my pandaboard. The display and omapdrm support in the upstream kernel is progressing pretty well. Which is great. The rpmsg framework is merged in the mainline for 3.4, which is the first step in getting multimedia (video decode/encode) support in the upstream kernel.

But one area where our hands are tied is graphics acceleration. I'd love nothing more than to be working on an opensrc and upstream driver for the SGX GPU used on OMAP platforms. But due to what I know and have access to about the inner workings of the IMGtech GPU's, that would not be possible without IMG's approval. I hope someday they warm up to the open source community, but for now I am forced to look elsewhere to contribute.

But wait.. what about the GPL pvr kernel driver? Well, the fact is that userspace and kernel are not independent. I love not only the linux kernel but the whole gnu/linux system of which a userspace that is developed in a collaborative open fashion is an integral part. And this is especially true in the realm of graphics drivers.. no where else are there such complex interactions between userspace and kernel. I am not strictly against having a closed userspace GL stack provided there is an open userspace alternative that is at least able to exercise the same kernel APIs. If there is an open userspace, that gives anyone who wants to, the freedom to start hacking and contributing and making things better. That is the great thing about the open source! With only a closed userspace, there is no freedom to fix the kernel parts. And the interaction between userspace and kernel parts of a graphics are too complex to be able to accept and properly review a kernel driver for acceptance into the upstream kernel tree without some open userspace that can exercise those APIs provided by the kernel part of the driver. Simply slapping some GPL headers on a kernel module that is ridden with OS abstraction layers and NIH re-invention of infrastructure provided by the upstream kernel isn't going to cut it here. And without an open userspace, there is no room for the open source community to refactor and fix anything.

But I'm not one to sit around and complain about a problem indefinitely without eventually trying to do something about it. One thing that gave me a glimmer of hope is the lima project. The first real (non vaporware) opensrc graphics effort on ARM. With that as a piece of needed inspiration, what could I do to help the cause? Well, with ARM as a member company of Linaro, and coming into contact with ARM folks working on mali, as well as engineers from other Linaro member companies who use mali, it seemed like direct contribution to the lima project might be a bit of a gray area. I don't think I really know any internal s3cr3ts of how mali works (and certainly not more than the lima folks have already figured out). But I don't want to get Linaro in trouble with it's member companies and it seemed like a potential conflict of interest. So what could I do? Pick another ARM platform that I know nothing about, and go to town!

This really leaves two big players. Of the two, I had a friend who could loan me a dragonboard to hack on, so that pretty much clinched the deal. (Although I have hopes that someday someone will figure out how to get something based on the nouveau driver running on tegra.)

Methodology

The approach I took is quite similar to, and strongly inspired by, the approach that Luc Verhaegen took with the lima driver project. It basically amounts to using a LD_PRELOAD shim to intercept system calls, digging through the kernel code to understand the existing userspace<->kernel API, and figuring out how to observe and log the interesting bits.

I've started with 2d acceleration support, mainly because that seemed like a good "warm-up" exercise, and also because there is currently no publicly available acceleration for x11 for the snapdragon platform (binary blob or otherwise). Most of the time so far has gone into figuring out the kernel APIs, and writing some utility code to log and post-process the results of running some simple test apps using the closed src binaries available for android, obtained from a cyanogenmod filesystem (because qualcomm does not provide any userspace support for gnu-linux (non-android) userspace, at least not to the general public). I used some linker tricks to link the test code against the android binary blob libs, and android libc, etc, within a ubuntu 11.10 filesystem. (Fwiw, I use 11.10 because that was prior to the switch over to armhf and based on the 3.0 kernel, which was what I had available from codeaurora git trees.) The good news is, from what I've been able to figure out from the GPL kernel driver, a lot of the infrastructure like pixel and cmdstream buffer allocation, and cmdstream submission, appear to be similar for 2d and 3d, so I think a lot of the work done so far for 2d accel will be useful when it comes to working on the 3d part.

The libwrap code I wrote logs information about the blits (cmdstream, and various parameters like gpu addresses, surface dimensions, blit coords) to a simple .rd log file (which amounts to a sequence of type/length/value fields). These .rd files get processed with a utility I wrote called "redump", to generate a reports showing side-by-side comparisons of the cmdstream, with similarities and parts of dwords that appeared to match surface and blit parameters highlighted. It isn't a perfect disassembly of the command stream, but it certainly helps to spot patterns.

Once I had a reasonable collection of tests for the types of blit operations which are important for an x11 EXA driver, I started varying parameters to figure out the limits, ie. what is the largest blit x, y, width, height, max surface width, height, stride, etc, to establish how many bits are used to encode different fields in the command stream. In some cases, I noticed there were multiple encoding options so parameters could be packed if fewer dwords if less bits where needed to encode the parameters. (For the current EXA driver I'm pretty much using the worst case encoding options so far, to keep things simple.)

With these tests, and the corresponding redump reports, I started work on implementing the EXA accel fxns for the xf86-video-freedreno driver. The work on the EXA driver really only started about 1.5 weekends ago (and most of the time at the beginning was just getting a skeletal driver setup, which is based on a stripped down and simplified xf86-video-msm).

Current Status

So far, I've got the basic solid/copy/composite operations implemented. There are some limitations still in the composite code, such as operations with masks are rejected. (There is an awkward limitation in libC2D2 that there is no way to specific independently mask and src coordinates.. I'm not sure yet if this is a limitation of the hw, but we will be a bit on our own to figure out this via experimentation with the cmdstream. One option to deal with this is ptr arithmetic on the mask surface gpu addr.) And there are still some lesser used color formats that I haven't tackled.

The next big thing, however, will be to deal properly with submission of multiple blits at a time, and not having to block until submitted blits are completely. Without this, performance is (as you would expect) quite bad. But that is easy enough to fix later. There is some awkwardness with the current kernel interface (see NOTES in freedreno tree about how context switch restore works). But that can be fixed by enhancing the kernel part to take separate ptrs in a single ioctl. And of course deciphering the context restore packet would be needed to properly support context switching if you have multiple processes using 2d (but this isn't too important for having a single xserver running so I think we can come back to it later).

A quick note on the kernel: the existing driver from qualcomm is what I'd call a semi-DRM driver. It is using GEM buffers, so it gives us what we'd need eventually for DRI2 and 3d. But not mode setting (which is handled via fbdev driver, also opened by xserver), and not a batchbuffer sort of interface for cmd submission.. cmd submission is handled via separate kgsl-2d/3d devices which are not aware of GEM buffer handles, so mapping buffers to the GPU cannot be handled as part of the cmd submission. So far I'm leaving the kernel driver mostly as-is (sans maybe some minor backwards compatible enhancements), because it is essential to be able to run test code based on the existing binary blob libraries back to back with work-in-progress xorg/mesa drivers. One approach to cleaning up the kernel part might be to provide an emulation layer to emulate the old interfaces, although for now there are enough other things to do that I haven't given this much thought yet. Of course, volunteers are always welcome ;-)

The git trees can be found at: https://gitorious.org/freedreno/

And an IRC channel on freenode at #freedreno

So far there are no mailing lists (I'm not really sure where they could be hosted) or web page other than the wiki pages at gitorious.

Disclaimer

This is a project that I've been working on in my own free time, not using the resources or time of my employeer or Linaro. It is something I've been working on of my own accord because quite simply I want to see advancement of the state of open source graphics in linux. I hope that Linaro will be supportive of this effort, and of open source graphics on all ARM platforms. And I know that a lot of the individual people that make up Linaro are quite passionate about open source. But I realize that dealing with the business concerns of all various member and potential member companies is a difficult balancing act. And as always, the opinions expressed here in my blog are those of my own and not necessarily those of my employer or of Linaro.

ubuntu-tv 1080p on omap4 panda

2012-01-14T19:13:00.001-08:00

you can find a higher resolution video at: http://www.youtube.com/watch?v=HJuyNrVOS1I
needs a bit of cleanup, but patches are here: https://github.com/robclark/qtmobility-1.1.0

update: and as usual Ricardo has a nicer looking video at his blog

omap5 at CES

2012-01-12T20:27:00.000-08:00

http://www.engadget.com/2012/01/12/ti-omap-5-exclusive-demo-laptops-ultrabooks-ces-2012-video/

xbmc update

2012-01-05T20:29:00.000-08:00

of course I've been too busy to write anything, but Ricardo has updated his blog w/ a note about xbmc progress:

http://rsalveti.wordpress.com/2012/01/06/hw-video-decode-and-xbmc-ubuntu-linaro/

Catchin up..

2011-11-27T11:32:00.000-08:00

just catching up on some news since last posting:

First, TI/OMAP PPA for ubuntu 11.10 now contains support for hw video codecs via DCE and gst-ducati. (decoders: h264, mpeg4, mpeg2, vc1; encoders: h264, mpeg4). Yah!

But lately I've been mostly working on omapdrm, a DRM/KMS display driver for omap, corresponding X11 driver (xf86-video-omap). The kernel driver is now queued up in the staging tree for 3.3. But not forgetting multimedia, I've been also working (as a linaro assignee) on extending dri2 protocol for more efficient video rendering (see linux-video.pdf) and UMM/dmabuf for sharing buffers between multiple devices (camera+drm, or multiple drm devices for a prime type setup).

And lastly, been doing some hacking trying to get xbmc working nicely with the hw video codecs for hw accel hd playback.. but more on that shortly when I have something work.

Building DCE firmware

2011-06-23T13:36:00.000-07:00

Now, thanks to public release of codec libraries, and after some slacking on my part, all the bits and pieces needed to build your very own ducati (cortex-m3) firmware are available. I've put together a wiki page with instructions of where to find all the pieces, and how to build, for 2.6.38 kernel:

http://www.omappedia.org/wiki/DistributedCodecEngine

This is using syslink-2.0, tiler-2.0, and GA codecs/FC/etc.. but now at least, if you want to use a kernel with a different version of syslink, you can rebuild the firmware with appropriate corresponding bios-syslink on the coprocessor side.

better late than never

2011-04-17T12:09:00.000-07:00

haven't had time to post for a while, so just getting caught up on a few things (in reverse chronological order)

ffmpeg vp8 decoder

Mans Rullgard has improved the original neon vp8 patches, and pushed them into the main tree:

VP8: ARM NEON optimisations for dsp functions

omap drm/kms display driver

A while back I started experimenting with the DRM display driver framework, and now have a basic driver which implements the KMS part of DRM. It uses a plugin API for SGX/PVR driver to register and handle it's own set of ioctls related to 2d/3d acceleration. Still TBD is overlay support, and cleaner way to handle buffer allocation (GEM?).

Now with the userspace pvr xorg driver, basic XRandR is working (change resolution, setup multi-monitor virtual display, etc). Being able to change resolution without cryptic sysfs cmds is nice for a change.

universal buffer allocation/management BoF

There was a BoF at ELC last week on the topic of common buffer allocation/management APIs to support zero copy buffer passing between various IP blocks (display, GPU, codecs, ISP, etc). Currently each SoC vendor has some custom API (CMEM, PMEM, NVMEM, TILER.. etc). Google is introducing ION. Most of the rest of the linux world (ie. desktop) uses GEM and/or TTM, which admittedly are somewhat GPU-centric.

In the desktop world, 3d/codec accelerators and display are all on the graphics card. But in the embedded/SoC world, you might have several vendors who use a common 3d block (for example), but each with their own unique display controller. And different video encode/decode accelerators. And different ISPs.. and so on.

For me, right now GEM is interesting as a way to expose allocating of TILER buffers on OMAP4 for video encode/decode and display. DRI already provides a path in userspace to pass GEM buffers and use DRM to handle the authentication duties (although GEM/DRM are perhaps not strictly required.. but they are something that exists in upstream kernel tree today). But short of mapping buffers into userspace process, there is currently no good way to pass these buffers to a v4l2 camera, or IVAHD video encoder/decoder. Possibly interface to video encoder/decoder IP can be thru the DRM display driver (another plugin, perhaps). Although that still leaves camera.

And there was also a bit of discussion on the related topic of how to expose display to userspace.. fbdev is ancient legacy, v4l2 MCF is the new kid on the block, but DRM/KMS is what is used in the desktop world. It seems like MCF should be more flexible for building different sorts of graphs, and to handle oddball features like writeback-pipe on OMAP4. Although DRM/KMS is already handling hotplug, EDID parsing, and provides sufficient flexibility for building display graphs (fb -> crtc -> encoder -> connector). At this point I prefer sticking with DRM/KMS for mode setting so that normal uses can be exposed to userspace in normal ways.

At this point, it isn't clear what the conclusion will be. A more modularized DRM with buffer management more easily split out (or at least shared with other devices)? ION or GEM or some merger of the two? The BoF was just a short 1hr session to better define the problem. The next step will be follow up sessions during the Linaro Developer Summit in Budapest.

Announcing libdce and gst-ducati

2010-11-27T09:15:00.000-08:00

And now it is time to take the wraps off of a weekend/evening project I've been working on for the last couple weeks. Last weekend, I wrote libdce which is a small library to allow for remotely accessing the codec-engine API from linux (without needing OpenMAX). And in the last few evenings plus weekend, I wrote a GStreamer plugin, gst-ducati, to decode video using the codec-engine via libdce.

So far, the following decoders are working:

ducatih264dec - H.264 (bp/mp/hp)
ducatimpeg4dec - MPEG-4
ducativc1dec - VC-1 (sp/mp/ap)
ducativp6dec - On2 VP6
ducativp7dec - On2 VP7

(The H.264 and MPEG-4 decoders are provided in libdce/firmware/dce_app_m3.xem3 which replaces base_image_app_m3.xem3.. for the other codecs, contact your TI representative.)

Why do this, when (a heavily patched) gst-openmax is providing support for hw accelerated decoding? The main answer is that I thought it would be a fun project, and it gives me a way to play with the codecs directly without OpenMAX getting in the way.

Currently libdce is working with L24.9 versions of syslink and kernel, since that seems to be the versions commonly packaged. But next step I'll update libdce to L24.11 for those who like the bleeding edge.

---

Update: latest master libdce is working on L24.11.. for L24.9 use the corresponding git tag.

enna + gst + omap4

2010-09-20T18:03:00.000-07:00

So.. I've been thinking for a while now that a great project would be an omap4 based media-center-pc. Hardware accelerated 1080p playback (including h264 high profile), dual cortex-a9 SMP, fast 3d acceleration, etc.. quite a worthy replacement for my aging, (ahem, umm.. "upgraded") appletv.

With that in mind, I found enna from the geexbox project. (Check out the slick looking screenshots.) It is built on the collection of EFL libraries for slick looking user interface (with both unaccelerated backend and gles backend for faster UI). It uses libplayer as the backend for media player(s), and libvalhalla for clever stuff like extracting and downloading media metadata (such as album/dvd cover art and info) automagically.

Since I'm currently working with an ubuntu filesystem, I decided to skip for now building the entire geexbox filesystem, and instead just build the equivalent versions of EFL libs, plus enna, libplayer, libvalhalla, etc, for ubuntu. The advantage being that I already have here setup gdb, oprofile, and all the other tools that I find so useful. Plus, it is the filesystem I'm working with day to day, so I don't have to constantly rebuild the userspace components of our multimedia stack for two different filesystems on a regular basis.

Enna's default theme, out of the box, has plenty of eye-candy and effects.. but is a bit sluggish unaccelerated. Especially because the elm_slideshow widget seems to be somehow causing the background images to be repeatedly rescaled, instead of cached.. it doesn't help that the smooth rescale code in evas is not neon optimized. But hopefully getting the SGX package installed and gl backend running will fix all that. But now, as of yesterday, there is a new 'stb' theme which is much more lightweight and fairly snappy without acceleration.

Since libplayer has a GStreamer backend, the goal would be to have accelerated video playback in enna. Although the current gst libplayer backend is experimental. But I've started hacking away to try and get the gst backend into good shape. The results of what I have are here:

http://github.com/robclark/libplayer/

video/audio playback is now integrated and working, and things like pause/seek seem to basically work. Some of the more advanced stuff like TV turner or DVD navigation are missing. But it's a start.

My here is my handy script to build this all: build-enna.sh

And here is my config file (to go in ~/.enna): enna.cfg

(hint: click on the raw or download links)

------

update: the libplayer patches for better GStreamer support have been merged a couple weeks ago.. so you can pull libplayer from geexbox/openbricks tree.

ffpv8 + neon = 720p24

2010-08-23T20:13:00.000-07:00

btw, been a long time since I had a chance to update the blog.. so I just thought I'd drop a quick note about something I've been playing with for the last few weekends.. the new ffvp8 decoder!

I've started writing the neon dsp functions for the VP8 decoder, as an excuse to learn a bit more about sw video codecs, neon, and VP8. At this point, not all of the dsp functions are implemented, but all the important ones for all the VP8 clips that I can find are implemented (loop filter, bicubic MC functions, and some misc other functions). Most of the major other ones, such as the bilinear MC functions, don't seem to be used in the clips that I can find, but should not be too hard to add when I find clips to test with.

The result is some 15-20% faster than libvpx, mostly thanks to ffvp8 being more cache friendly than libvpx decoder, and not doing silly things like memcpy of reference frames, rather than my hard-core neon optimizing skills.. and this is even without ffvp8 being a multi-threaded decoder, which is something that would benefit an SMP cortex-a9 platform like OMAP4 if done properly. And all this should be possible to get a bit faster by spending some time tweaking the instruction order to avoid stalls and some other tricks like that. (And hopefully I'll learn a few tricks in the process as the patches are reviewed.)

The result so far is here:

http://github.com/robclark/ffmpeg/commits/vp8-4

Current status is that it is all working, and producing bit exact output compared the plain 'C' versions of the DSP functions for all the test clips I have. I'll update again when I add more or when the patches are in upstream ffmpeg.

I also have some work-in-progress patches for gst-ffmpeg to avoid a memcpy for codecs that don't support edge emulation, although these depend on rowstride and some of the other related features that we've added to GStreamer for omap4.

git format-patch for specific commit-ids

2010-03-08T11:38:00.000-08:00

for revision ranges, appending ^! (which appropriate escaping) to a commit-id causes it to represent that range beginning/ending with that commit-id inclusively instead of exclusively. So for specifying a revision range consisting of exactly one specific revision (let's call it r1), you can specify r1^! r1

And if you want to generate a patch from all your commits while ignoring all other commits:

for c in `git log --author=Clark | grep ^commit | awk '{print $2}'`; do

git format-patch "$c^\!" "$c";

done