Intel Proposes Blackhole Render Extension For OpenGL / OpenGL ES

[phoronix]

Phoronix: Intel Proposes Blackhole Render Extension For OpenGL / OpenGL ES

The latest extension proposed for the OpenGL / OpenGL ES registry is INTEL_blackhole_render...

http://www.phoronix.com/scan.php?page=news_item&px=Intel-Blackhole-Render-OpenGL

[schmidtbag]

I'm not sure I understand what the point of this is. You can already specify which GPU does the rendering of a program. This feature doesn't have another GPU automatically pick up the slack, or at least that's not implied.

[willmore]

Is this some kind of debugging feature?

[cybertraveler]

I've got two guesses for the purpose of this:

1. For software testing.

1a. You could run tests on an almost unmodified version of your app, but with blackhole enabled. All the render calls would be created as normal. This may be useful for testing on systems which don't have a display, eg a server-based test/build farm. It may allow for integration testing where the app/game logic isn't being decoupled from the rendering.

1b. You may be able to find issues which only occur after a very long period of time. You could run a game with accelerated time and very high fps to more quickly find these issues.

2. For development of the server component of a client-server game engine. This extension may make it more convenient and low effort to share code between both the client and the server. This may be useful for anti-cheat mechanisms too. It may be desirable to have the server reproducing parts of the scene that the client rendered and then probing the scene to see if the client would have had line of sight on a particular object. This could help detect/prevent wall-hacks in first person shooter games.

With very little info available to me, these are just wild guesses. It was fun thinking about the possibilities though

[doom_Oo7]

could they first start implement useful extensions such as GL_NV_PATH_RENDERING ?

[Veerappan]

I guess its possible that this extension could also be used to get a reasonable measurement of driver overhead when choosing a rendering path.

[linuxgeex]

My guess is that this is for VGL clients which would have no other way to easily disable child GL work while the display for the client is disabled at the host.

[ElectricPrism]

This wouldn't theoretically have anything to do with remote game streaming services and headless displays would it?

(I'm truely ignorant beyond the basics in this area so take that with a heap of salt)

[GreatEmerald]

Nah, this is clearly for more realistic rendering of the projectiles that black hole guns (M-490 Blackstorm/Singularity Cannon/etc.) fire. After all, once you do fire it, it's supposed to suck everything in, including your camera!

[papajo]

I've got two guesses for the purpose of this:

1. For software testing.

1a. You could run tests on an almost unmodified version of your app, but with blackhole enabled. All the render calls would be created as normal. This may be useful for testing on systems which don't have a display, eg a server-based test/build farm. It may allow for integration testing where the app/game logic isn't being decoupled from the rendering.

1b. You may be able to find issues which only occur after a very long period of time. You could run a game with accelerated time and very high fps to more quickly find these issues.

This sounds also useful to be applied in deep learning/neural networks to either make better bots or beta test map geometry, dialogue/interaction bugs etc.