Announcement

Collapse
No announcement yet.

Intel Proposes Blackhole Render Extension For OpenGL / OpenGL ES

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • linuxgeex
    replied
    Originally posted by papajo View Post

    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.
    Great application, and that brought to mind that it could be used to more easily to chase down where CPU / MM improvements could be made in the state trackers and/or and rapidly/accurately benchmark them to detemine where one is doing a much better job than another, which is one of the better ways to find low hanging fruit for optimsations.
    Last edited by linuxgeex; 07 March 2018, 05:09 AM.

    Leave a comment:


  • Djhg2000
    replied
    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:


  • cybertraveler
    replied
    Originally posted by GreatEmerald View Post
    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!
    I think you've worked it out. No need for further speculation now

    Leave a comment:


  • papajo
    replied
    Originally posted by cybertraveler View Post
    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.
    Last edited by papajo; 05 March 2018, 06:17 PM.

    Leave a comment:


  • GreatEmerald
    replied
    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!

    Leave a comment:


  • ElectricPrism
    replied
    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:


  • linuxgeex
    replied
    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:


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

    Leave a comment:


  • doom_Oo7
    replied
    could they first start implement useful extensions such as GL_NV_PATH_RENDERING ?

    Leave a comment:


  • cybertraveler
    replied
    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

    Leave a comment:

Working...
X