Thursday, February 07, 2008

OpenVG and accelerating 2D

I tend to break a lot of keyboards. Not because I release all the aggression that I hold deep within me on them, but because I drool a lot. It's not my fault, I really do love graphical bling. Since I'm one of the people who flourishes not when he's doing well, but when others are doing just as badly I've thought about getting other people on the "excessive drooling" bandwagon.

I've tried it in the past. First with my "you ain't cool, unless you drool" campaign, which was not as successful as I've seen it be in my head. It made me realize that marketing is unlikely one of my superpowers. That was a real blow especially since it came a day after I've established that there's like a 95% chance that I can't fly and if I can, then my neighbor will be seriously pissed if I keep landing on his car. You'd think they'd build them stronger, but I digress. After that I went with my strengths and had two technical efforts. The first one led to Exa the second to Glucose. Both are acceleration architectures that try to accelerate Xrender - the API which we use for 2D on X. What Xrender is very good at is text. What Xrender is not so good at is everything else.

Furthermore what one really wants to do nowadays is use the results of a 2D rendering in a 3D environment as a texture or simply implement effects on top of the 2D rendering with shaders. Wouldn't it be nice to have a standard and simple API for all of that? You bet your ass it would. In this particular case "you bet your head" would be a more suitable expression, since by a simple act of reading this blog it's clear you already gave up on your ass and stake your future on your head. I endorse that (both the head more important than ass theory and better api idea). Currently, through the magic of DRM TTM and GLX_texture_from_pixmap one could achieve partially that (we'd need GLX_pixmap_from_texture to finish it), but if you've seen Japanese horror movies you know they got nothing on the code one ends up with, when doing that.

I already mentioned in my previous post that we can lay any number of API's on top of Gallium3D. In fact in the last diagram I already put the two graphics API's that interest me on top of it. OpenVG and OpenGL. In my spare time I've started implementing OpenVG on top of Gallium3D. I'm implementing 1.1 which hasn't been officially released yet. While OpenVG 1.0 is essentially useless for our drool-causing desktops because it doesn't even touch the subject of text handling, 1.1 does and that in itself makes it a great low-level 2D vector graphics api.

We already have OpenVG engines for Qt and Cairo which should make the switch fairly painless. "Hey", you say and I swiftly ignore you, because I have a name you know. "Sunshine", you correct yourself and I smile and say "Huh?". "I want my KDE 4 fast and smooth! Gallium3D has this 3D thing in the name and I have hardware that only does 2D, what about me?". Nothing. You need to use other great solutions. "But my hardware can accelerate blits and lines!". Awesome, then this will likely rock your world. As long as you won't try to run any new applications of course. Even embedded GPU's are now programmable and putting the future of our eye-candy on a technology that predates 2 year old embedded GPU's is an exercise in silly which my chiseled pecs refuse to engage in.

OpenVG standard says "It is possible to provide OpenVG on a platform without supporting EGL. In this case, the host operating system must provide some alternative means of creating a context and binding it to a drawing surface and a rendering thread." which is exactly what we want. That's because we already have that layer, it's GLX. GLX will do the context creation for us. This also means that we'll be able to seemingly combine 2D vector graphics and 3D and manipulate the results of vector rendering the same way we would normal 3D.

Finally 2D graphics will be accelerated the same way 3D is and those hours which you've spent playing 3D games thinking "how the hell is it possible that putting a clock on my desktop makes it choppy when this runs at 400fps?" will be just a story you'll get to tell your grand-kids (while they stare at you with the "please god, let me be adopted" look). As a bonus we get two extremely well documented API's (OpenGL and OpenVG) as our foundation and instead of having two drivers to accelerate 2D and 3D we'll have a single driver.

So what happens with Glucose? Alan and José are still working on it a bit and in a short-term it does provide a pretty enticing solution but long term OpenVG/OpenGL combo is the only thing that really makes sense.

With much love,
Drool Coordinator

14 comments:

scroogie said...

This sounds very good, especially the part about transforming Vector output like usual 3D. But the aim of future X architecture is still quite unclear to me. You mention to use GLX. I thought EGL is the future way to go? And doesn't GLX use OpenGL libraries and Mesa/DRI again? I thought you want to replace extactly these. I'm a bit confused, sorry.

Anonymous said...

What?

Chris C said...

> What?

Yup. This post apparently brought to the world courtesy of enough coffee to knock out a small mule.

(as an aside, no blockquote tags allowed?)

- Chris

Tim Whitbeck said...

Great! I love your posts, Zack. Always humorous, but more importantly, they make me excited. It's great to hear about the work you're doing.

Jon Smirl said...

If you're working on a text API consider client side layout and server side rendering - a model where both the client and server use the identical font file. We're very close to having font generation from shaders and you want to be able to support that in your API. X has never done fonts right in a dozen tries.

When working with OpenVG take into account the final window transform since this will alter antialiasing decisions in the OpenVG code. If you are drawing into a twisted window, don't draw into a rectangle and then twist it. Apply the twist transform to OpenVG before the window is drawn, that way the anti-aliasing will be right. This has big impacts on fonts.

Anonymous said...

Re Tim Whitbeck:

Excited?! You pervert!

zuh said...

If you weren't a Qt zealot, I'd want your babies. But I'll settle for casual sex.

I agree completely that unifying the graphics API to something hw vendors see as worth supporting is The Way to go. God knows XRender doesn't seem to attract any interest.

Andreas Pokorny said...

Where can I get the draft openvg-1.1 spec?

Anonymous said...

Hi Zack,
I've only recently come across your work - but find it very interesting.
Use of OpenVG is great but one of the challenges a lot of us have is mapping existing 2D drawing APIs to OpenVG.

Are you still in Japan? Spend anytime in London? I'm in London but should be in Tokyo 23rd April-1st May. Fancy a beer? mail me graphicsninjabeer atnojnkbillpinnell fullstopcom

Anonymous said...

Theoretically, we want a usable OpenGL accelerated back end for Cairo, right? Right now, Cairo uses XRender a lot.

XRender is implemented in the driver...we have no control over how it's implemented in closed source drivers...performance can be sketchy.

XGL implements XRender on GL, Glucose should allow this do be done on the same X server, bypassing all the problems XGL generates, correct? I can't wait for this.

On the topic of the Cairo OpenVG backend...someone could implement OpenVG using GLX(indirect?)?

Isn't that like...far into the future....almost a pipe dream?

Anonymous said...

Also...I don't understand...can libXRender essentially be rewritten to use OpenGL, instead of calling things in the XServer? Why does the X server need to be modified if aiglx is supported?

Anonymous said...

What's the difference between GL-ES and openVG? I'm totally confused by all these overlapping graphics standards!

Anonymous said...

What about OpenRT?

Anonymous said...

What's the difference between GL-ES and openVG? I'm totally confused by all these overlapping graphics standards!

OpenGL-ES is a subsets of OpenGL and it's mainly designed to accelerate 3D graphics on embedded systems.

OpenVG is the API to accelerate 2D vector graphic.

Maybe you're confused by some "OpenVG on OpenGL-ES" implementations like AmanithVG or ShivaVG.