Checking Hardware Acceleration Availability? (Testing Available)

Test if Hardware Acceleration has been enabled for a CSS animation?

Overview

A CSS property transition on an element is hardware-accelerated if all these conditions are met:

  1. Hardware-accelerated layer compositing is enabled in the browser
  2. The CSS property being transitioned is acceleratable
  3. The element has been given its own compositing layer

Generally, the requirements for these conditions are:

  1. The relevant hardware-acceleration options must be enabled, and the device's GPU and graphics drivers must not be blacklisted
  2. Only compositing CSS properties (opacity, transform: translate / scale / rotate, etc) are acceleratable
  3. Each browser has specific reasons for deciding whether to give an element its own compositing layer (or it can be forced by using a "go faster" hack like transform: translate3d)

Hardware-accelerated layer compositing

To identify whether this is enabled:

Chrome

1. General acceleration

  • Go to chrome://settings
  • Click the + Show advanced settings button
  • In the System section, inspect the status of the Use hardware acceleration when available checkbox

If acceleration is enabled, then:

2. Accelerated compositing

  • Go to chrome://gpu
  • In the Graphics Feature Status section, inspect the value of Compositing. This will be one of the following:

    • Hardware accelerated
    • Software only, hardware acceleration unavailable

More details on the Software Compositor from the docs:

In some situations hardware compositing is infeasible, e.g. if the device's graphics
drivers are blacklisted or the device lacks a GPU entirely. For these situations is
an alternative implementation to the GL renderer called the SoftwareRenderer

(Note: Chrome also has a Legacy Software Rendering Path, which is "still lingering as of May 2014, but will soon be removed entirely in Blink.")

Here's a great article with more info: Accelerated Rendering in Chrome.

Firefox

1. General acceleration

  • Go to Firefox's Preferences
  • Go to the Advanced tab
  • Go to the General subtab
  • Inspect the status of the Use hardware acceleration when available checkbox

If acceleration is enabled, then:

2. Layer acceleration

  • Go to about:config
  • Search for layers.acceleration.disabled

If layer acceleration is enabled (if the value is false), then:

3. GPU accelerated windows

  • Go to about:support
  • In the Graphics section, inspect the value of GPU Accelerated Windows

If it does not begin with 0/, and a rendering API is shown (eg. OpenGL, Direct3D), then GPU acceleration is active.

Safari

  • Enable Safari's debug menu by running this command in the Terminal:

    defaults write com.apple.Safari IncludeInternalDebugMenu 1
  • Open (or restart) Safari
  • In Safari's Debug menu, inspect the status of the Disable Accelerated Compositing option in the Drawing/Compositing Flags submenu

Acceleratable CSS properties

The only CSS property transitions which can be hardware-accelerated are those which occur in the compositing stage of the rendering process. For example:

  • opacity
  • transform: translate and its friends: translateX, translateY, translateZ, translate3d
  • transform: scale and its friends: scaleX, scaleY, scaleZ, scale3d
  • transform: rotate and its friends: rotateX, rotateY, rotateZ, rotate3d

To fully benefit from acceleration, no non-compositing properties must be transitioned. For example:

  • A transition on just transform: translate can receive the full benefit of acceleration (because the element's layer can simply be recomposited by the GPU).
  • A transition on both transform: translate and width will receive almost no benefit from acceleration (because a transition on width causes the element's layer to be repainted by the CPU for every animation frame).

Compositing layers & coloured borders

The browser's rendering engine decides (based on user preferences, CSS styles, etc) whether or not to give an element its own compositing layer.

For example, Chrome has this list of reasons, and also has this option in chrome://flags:

Compositing for RenderLayers with transitions
Enabling this option will make RenderLayers with a transition on opacity, transform or filter have their own composited layer.

If an element has not been given its own layer, then no CSS transitions on that element will be accelerated.

transform: translate3d (the "go faster" hack) generally forces an element to be given its own layer.

But even if an element has been given its own layer, transitions on non-compositing properties (width, height, left, top, etc) still cannot be accelerated, because they occur before the compositing stage (eg. in the layout or paint stages). @ChrisSpittles This is why you saw no visual improvement after adding transform: translate3d.

Most browsers can display coloured borders around composited layers, to make them easy to identify for development/debugging:

Chrome

Displaying the borders of composited layers can be done in one of two ways:

  • For all pages — Go to chrome://flags and enable Composited render layer borders ("Renders a border around composited Render Layers to help debug and study layer compositing"). You'll need to relaunch Chrome for this to take effect.
  • For individual pages — Open the Developer Tools, then open the Drawer, select the Rendering tab, and enable Show composited layer borders. Now, opening the Developer Tools on any page will cause layer borders to be shown on that page.

Now trigger the CSS transition on the element. If it has a coloured border, then it has its own compositing layer.

The border colours and their meanings are defined in debug_colors.cc. More details here and here.

Firefox

To draw the borders of composited layers:

  • Go to about:config
  • Search for layers.draw-borders and enable it

Now trigger the CSS transition on the element. If it has a coloured border, then it has its own compositing layer.

The border colours and their meanings are defined in Compositor::DrawDiagnosticsInternal.

Safari

(This does not work for me with Safari 7.0.3, but it seems it did work for some people as recently as last year.)

Launch Safari from the Terminal with the CA_COLOR_OPAQUE boolean environment variable set:

$ CA_COLOR_OPAQUE=1 /Applications/Safari.app/Contents/MacOS/Safari

Alternative method:

$ export CA_COLOR_OPAQUE=1 
$ /Applications/Safari.app/Contents/MacOS/Safari

Apparently, hardware-accelerated layers should be coloured red. More details here and here.

Update:

Here's an alternative method which works for me in Safari 7.0.3 (credit to David Calhoun):

  • In Safari's Debug menu, enable Show Compositing Borders in the Drawing/Compositing Flags submenu

Now trigger the CSS transition on the element. If it has a coloured border, then it has its own compositing layer.


References

For more details, check out these excellent articles:

  • http://blogs.adobe.com/webplatform/2014/03/18/css-animations-and-transitions-performance/
  • http://www.html5rocks.com/en/tutorials/speed/high-performance-animations/
  • http://www.html5rocks.com/en/mobile/optimization-and-performance/
  • http://ariya.blogspot.co.uk/2011/07/fluid-animation-with-accelerated.html

JavaScript detect if hardware acceleration is enabled

Like all other browser-specific capabilities, probably the best thing you can do is to devise some sort of feature test and actually measure the performance of what matters to you.

You can do when the first page on your site is loaded and then set a cookie with the setting so you only have to do it every once-in-a-while and don't have to do it again for awhile as long as the cookie is present.

Depending upon what type of performance you care the most about, you can devise a test that's pretty specific to that. For example if you cared a lot about image scaling, you could devise a JS test that scales an image among a bunch of different sizes in a big enough loop to get a measurable time and then decide what your timing threshold is.

Not only would this be better than a single binary choice of accelaration on or off, but it would also be able to test the specific features you care about and be able to see how fast they actually are.

flash player 11 check GPU acceleration

You must obtain a Context3D to view it's driverInfo:

trace("3d mode: " + context3D.driverInfo);

For me, this indicates:

context3d

Easiest to test for software rendering, hardware accelerated GPU would be indicated by DirectX or OpenGL.

This could be implemented as such:

package
{
import flash.display.Sprite;
import flash.display.Stage3D;
import flash.display3D.Context3D;
import flash.display3D.Context3DRenderMode;
import flash.events.Event;
import flash.system.ApplicationDomain;
import flash.system.Capabilities;

public class X extends Sprite
{
public function X()
{
super();

if (ApplicationDomain.currentDomain.hasDefinition("flash.display.Stage3D"))
{
stage.stage3Ds[0].addEventListener(Event.CONTEXT3D_CREATE, onContext3DCreate);
stage.stage3Ds[0].requestContext3D();
}
}

private function onContext3DCreate(event:Event):void
{
// obtain context
var t:Stage3D = event.target as Stage3D;
var context3D:Context3D = t.context3D;

// detect software mode
if ((context3D.driverInfo == Context3DRenderMode.SOFTWARE)
|| (context3D.driverInfo.indexOf('oftware') > -1))
{
trace("Software mode detected!");
}

trace("Flash Version: " + Capabilities.version);
trace("3D mode: " + context3D.driverInfo);
}

}
}

For GPU accelerated StageVideo, you listen for StageVideoAvailabilityEvent to confirm StageVideoAvailability.AVAILABLE.

This could be implemented as:

package
{
import flash.display.Sprite;
import flash.events.StageVideoAvailabilityEvent;
import flash.media.StageVideoAvailability;

public class X extends Sprite
{
public function X()
{
super();
stage.addEventListener(StageVideoAvailabilityEvent.STAGE_VIDEO_AVAILABILITY, onStageVideoState);
}

private function onStageVideoState(event:StageVideoAvailabilityEvent):void
{
if (event.availability == StageVideoAvailability.AVAILABLE)
trace("available");
}

}
}

Once you have a StageVideo, render state is indicated by StageVideoEvent.RENDER_STATE.

var stageVideo = stage.stageVideos[0];
stageVideo.addEventListener(StageVideoEvent.RENDER_STATE, stageVideoStateChange);

function stageVideoStateChange(event:StageVideoEvent):void
{
trace("Render State: " + event.status);
}

Render state is derived by StageVideoEvent.status and includes:

  • VideoStatus.ACCELERATED - Decoding and presentation both occur in hardware. (Best performance.)
  • VideoStatus.SOFTWARE - Presentation in hardware, decoding in software. (Acceptable performance.)
  • VideoStatus.UNAVAILABLE - No GPU resources are available to handle video, and nothing is displayed. Fall back to a Video object.

Electron Linux Video Hardware Acceleration

This has been solved. The main issue was the VaAPI driver needing to be installed on the hardware running the application. Secondly the only flags needed was the following:

app.commandLine.appendSwitch('enable-features', 'VaapiVideoDecoder')

How to tell if tensorflow is using gpu acceleration from inside python shell?

No, I don't think "open CUDA library" is enough to tell, because different nodes of the graph may be on different devices.

When using tensorflow2:

print("Num GPUs Available: ", len(tf.config.list_physical_devices('GPU')))

For tensorflow1, to find out which device is used, you can enable log device placement like this:

sess = tf.Session(config=tf.ConfigProto(log_device_placement=True))

Check your console for this type of output.

Sample Image

How do I check if PyTorch is using the GPU?

These functions should help:

>>> import torch

>>> torch.cuda.is_available()
True

>>> torch.cuda.device_count()
1

>>> torch.cuda.current_device()
0

>>> torch.cuda.device(0)
<torch.cuda.device at 0x7efce0b03be0>

>>> torch.cuda.get_device_name(0)
'GeForce GTX 950M'

This tells us:

  • CUDA is available and can be used by one device.
  • Device 0 refers to the GPU GeForce GTX 950M, and it is currently chosen by PyTorch.


Related Topics



Leave a reply



Submit