GPU accelerated decoding

It’s pretty amazing to see one VMS company aggressively promoting something that we’ve had in our client since v1.0 (IIR ca. 2007). When released, I was told that requiring Direct3D capable GPU was crazy, and that the client was a “resource hog”.

Back then, most clients were based on Win32 or MFC, using Microsofts GDI API to draw stuff. The entire decoding pipeline would happen on the CPU (with a C), from compressed JPEG to decoded YCrCb planar to BGR chunky pixels. Then a common function to call would be ::StretchDIBits (…) to draw the (upside down) BGR pixels on a window. This archaic way of doing things allowed the client to run on almost any old PC. Since our client required a dedicated GPU, the logic was that the Ocularis client was a “resource hog”. Well, yes, a bicycle is certainly more lightweight than a semi truck, but if you are going to haul 20 tonnes of bricks, which vehicle would you chose?

These days, some of our competitors have moved to WPF (a monumental mistake in my opinion), which is Microsoft’s successor to WinForms. It uses GPU acceleration to draw buttons etc, and offers the world’s shittiest/weirdest layout engine. It requires a lot more resources than our lightweight rendering engine if you want to do anything more than just rudimentary stuff.

Apple uses OpenGL for their UI rendering (they are moving to Metal, which is closer to the … metal … than OpenGL), and most modern browsers offer GPU acceleration when drawing on the screen – and not just 3D stuff. Images etc. are drawn using the GPU. Because that is what the GPU is intended for!

So basically, some of the VMS vendors are now catching up, and have started using the parts of the PC the way it was designed to be used. Better late than never I guess.

Advertisements

4 thoughts on “GPU accelerated decoding

  1. Alex says:

    Hi
    How would prove to customer that YOUR VMS is using GPU accelerated decoding
    Which tools ?
    Thx

    • prescienta says:

      Tough.

      On my laptop, a Asus UX32V, I have 2 GPUs, one is a discrete nVidia GeForce GT 620M. It comes with a tool that shows “GPU Activity”, but that does not “prove” that the decoding is accelerated via the GPU, just that the GPU is doing something while your app is running.

      In our case, we have support for the old-school GDI pipeline (via our SDK), so you could write an app that would run in either mode, and then compare the CPU usage. We actually only recently added CPU only decoding/rendering (don’t ask…)

  2. Alex says:

    I was using/playing with GPU-Z.0.8.2, GPU Shark-0.9.4.1 and few more
    They all show GPU activity about 8-10 %
    that all
    so can I assume that decoding done by CPU ?
    Right ?

    • prescienta says:

      I would not make that conclusion. In the Ocularis Client, we do some on the cpu and some on the gpu. We could move more towards the gpu, using CUDA for example, but we saw some pretty severe congestion issues when running many streams simultaneously. So if the gpu is very strong, compared to the cpu, then the part running on the gpu will be a much smaller percentage of the gpus full potential.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s

%d bloggers like this: