Announcement

Collapse
No announcement yet.

After ~70% FPS Boost For Zink, The OpenGL-on-Vulkan Code Is ~50% The GL Native Speed

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

  • Ruediix
    replied
    I suspect if it continues to get faster it might actually exceed native performance on some drivers in some applications. At this point, writing the OpenGL driver might become redundant.

    That said, there will always be application specific variations in speed, so I doubt it will ever reach the case of running faster 100% of the time over a highly optimized hardware OpenGL driver, even if it reaches the point of "slightly faster in many cases" which would be enough to stop producing OpenGL drivers for newer cards, or to ditch Compatibility mode support and support for OpenGL versions before OpenGL 3.0 FC (Core Context implied).

    Leave a comment:


  • grok
    replied
    Originally posted by mangeek View Post

    I believe this started back in the 1990s with the Pentium Pro/i686. My recollection was that the i586 and below were straight-up CISC processors, but the i686 sort of decoupled things and -emulated- a CISC CPU in microcode while everything really ran on a RISC-ish core with microcode.
    Cyrix 6x86 was good at that little game too while not being i686 compliant at all. (Cyrix 5x86 is a cut down variant of the 6x86 CPU). Might be recognized as i486 level of instructions support even.
    AMD K5 is another one, it suffered delays so it's not much remembered. AMD bought a competitor's design to make the K6 and so they pulled the plug. I'm sure I would have liked playing quake and duke on the K5.

    Leave a comment:


  • grok
    replied
    Hasn't microcode always existed? and microcode or otherwise, processors doing slow ass integer division etc. until a new one does it much better.

    Leave a comment:


  • rawr
    replied
    Originally posted by Amaranth View Post

    I think you're mixing up micro-ops and microcode. There is dedicated hardware in the chip for converting most x86 instructions in to micro-ops, microcode is a much slower programmable emulation of instructions.
    Isn't microcode defining which micro-ops to use for an instruction?

    Leave a comment:


  • rmfx
    replied
    50 percent of native driver speed with such a new project and all the mesa abstraction stuff, that leaves a good hope for a non-mesa base wrapper and further optimizations.

    Leave a comment:


  • Amaranth
    replied
    Originally posted by mangeek View Post

    I believe this started back in the 1990s with the Pentium Pro/i686. My recollection was that the i586 and below were straight-up CISC processors, but the i686 sort of decoupled things and -emulated- a CISC CPU in microcode while everything really ran on a RISC-ish core with microcode.
    I think you're mixing up micro-ops and microcode. There is dedicated hardware in the chip for converting most x86 instructions in to micro-ops, microcode is a much slower programmable emulation of instructions.

    Leave a comment:


  • mangeek
    replied
    Originally posted by curfew View Post
    comparable to how Intel is already emulating some ancient x86 instructions in their processors in exchange for simplifying / optimizing the hardware architecture.
    I believe this started back in the 1990s with the Pentium Pro/i686. My recollection was that the i586 and below were straight-up CISC processors, but the i686 sort of decoupled things and -emulated- a CISC CPU in microcode while everything really ran on a RISC-ish core with microcode.

    Leave a comment:


  • mangeek
    replied
    Originally posted by curfew View Post
    Emulation layer cannot be as fast as the native implementation that properly utilizes the underlying hardware.
    I think that with Gallium, everything is -already- being translated to an intermediary format. It's not like the software is sending OpenGL right to the hardware. I think you're right that Zink won't end up being as fast as OpenGL, but it might end up being -fast enough- to justify having a single 'OpenGL-on-Vulkan' path that always works well inside a bunch of 'Vulkan-on-hardware' implementations rather than a bunch of 'OpenGL-on-hardware' and 'Vulkan-on-hardware' implementations.

    Leave a comment:


  • wertigon
    replied
    Originally posted by oiaohm View Post
    It not impossible to be in compliance with Opengl and multithreaded but the fact this equals having own implementation features means existing applications can need to be hand picked or only for new applications to use multi-thread features.
    This. Just because it doesn't map to multithreading 1-to-1, does not mean it is impossible or even infeasible to use multiple cores to speed up the pixel pushing.

    Exactly how that should be done I have no clue, but it's not unheard of to have old ideas finally come back again because now we have the technology to implement such ideas. Fifteen years ago the idea of dedicating a single computer core to doing OS stuff was seen as laughable, today it is increasingly common on 8+ core systems.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by curfew View Post
    OpenGL does not allow for that because it is impossible to be both multithreaded and in compliance with OpenGL. Therefore Vulkan's multithreading is out of reach when emulating OpenGL.
    https://www.phoronix.com/scan.php?pa...etter-GLTHREAD
    To be horrible correct Opengl standard does not really have any clear statements on multithreading.
    https://www.khronos.org/opengl/wiki/...multithreading
    Its fairly much left down to the platform to write platform particular rules. So technically zink could add platform unique features to allow more Vulkan multi-threading in opengl for aware applications and still be in compliance with OpenGL

    Opengl compliance is just passing the OpenGL test suite that is only going to test out single threaded stuff.

    It not impossible to be in compliance with Opengl and multithreaded but the fact this equals having own implementation features means existing applications can need to be hand picked or only for new applications to use multi-thread features.

    Leave a comment:

Working...
X