Originally posted by papajo
View Post
Announcement
Collapse
No announcement yet.
Intel Proposes Blackhole Render Extension For OpenGL / OpenGL ES
Collapse
X
-
Last edited by linuxgeex; 07 March 2018, 05:09 AM.
-
IIRC headless graphics can already be done on Intel platforms with vPro (renders to a networked buffer) or a virtual machine with VT-d (which is also a part of the vPro package but doesn't require a full vPro implementation). Besides, can't you already do offscreen render?
I am very confused as to what the practical application would be for an extension like this.
Leave a comment:
-
Originally posted by GreatEmerald View PostNah, 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!
- Likes 2
Leave a comment:
-
Originally posted by cybertraveler View PostI'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.Last edited by papajo; 05 March 2018, 06:17 PM.
Leave a comment:
-
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!
- Likes 3
Leave a comment:
-
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)
Leave a comment:
-
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.
Leave a comment:
-
I guess its possible that this extension could also be used to get a reasonable measurement of driver overhead when choosing a rendering path.
- Likes 3
Leave a comment:
-
could they first start implement useful extensions such as GL_NV_PATH_RENDERING ?
- Likes 1
Leave a comment:
-
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
- Likes 6
Leave a comment:
Leave a comment: