Skip to content

Status Update: libva-epiphany-driver

November 28, 2012

On the off chance someone actually looked at my github page and followed my info here…
I had been crunching getting a libva skeleton driver up and running, my initial hopes were to generate excitement for the parallella kickstarter. After I failed to get it done in time (but it got funded! yay!), I was still crunching to get a working demo up (to keep people excited). However, I hit a brick wall trying to debug my Huffman decoding routine, and quickly lost focus as my research drew my attention away. I had more in-progress work, including functional DRI output, that I hadn’t commited because I was trying to debug that routine.

I keep meaning to go back to it, but I still haven’t had any mental breakthroughs. Therefore, I decided to just go ahead and commit what I had. The skeleton driver works, it just doesn’t do anything :P

For some reason, I had insisted on coding the codecs from scratch (part pride, part licensing, etc…), but now I’m feeling more pragmatic. Therefore, I’ve decided to do a few things:

  1. Use libjpeg-turbo source as a reference and quickly finish up the JPEG decoding routines for the demo (concede pride).
  2. Approach problem differently! (possibly concede licensing).

The”problem” was one I made for myself: libva acts as a hardware mediator between applications and accelerated hardware, and it’s on the hardware that the codecs are implemented. The libva-driver gets requests and handles setting up and communicating with the hardware, shuffling data around and such. I knew I’d have to implement the codecs somehow, but foolishly decided to implement them in the driver.

I’ve recently decided to focus my efforts on porting existing codecs/libraries to utilize Epiphany, then just have the libva-epiphany-driver as a host program that loads the separate programs onto Epiphany. This should have the benefit of reducing my workload, simplifying libva-epiphany-driver, and making it possible to receive the benefits of my porting in non-vaapi applications. And of course, porting existing projects and contributing upstream will be better overall (upstream benefits from wider adoption, I benefit from upstream contributions, etc.).

I decided to start with libjpeg-turbo, as it’d be the simplest to work with (and wouldn’t have to worry about the BSD license).  Hopefully this approach will go much better.

From → Uncategorized

Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s