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

  • onlyLinuxLuvUBack
    replied
    Originally posted by microcode View Post
    I think Zink can do very well and I'm excited to see the performance loss to trend toward zero, then toward negative infinity. :+ )
    You zink so ?

    Leave a comment:


  • brenohrocha
    replied
    Originally posted by tildearrow View Post
    Is it true that DXVK has approached/exceeded native DirectX speeds?
    This is something for you feast the eyes:
    https://www.youtube.com/c/FlightlessMango/videos

    Sometimes you will see something like this happening:


    personally I'm playing Witcher 3 perfectly (probably ~60fps) with everything maxed out and not a single frame hiccup yet.

    Leave a comment:


  • curfew
    replied
    Originally posted by ShFil View Post
    You make a wrong assumption here. It's not about emulating aka having the exact same behavior like other software, but to match the same specification. So under the hood it can do less and achieve the same results.
    Any native implementation can have exactly the same optimizations and then some more. Obviously. Whatever is not in the specification can be optimized by any implementation. And any behavior mandated by the spec must be built into every implementation. There is no way for a Vulkan-based implementation to magically be faster than the native platform that Vulkan, too, is built on top of.

    Leave a comment:


  • aufkrawall
    replied
    Originally posted by eydee View Post
    Mostly in select few games, when running under Windows, on AMD cards, due to bad Directx drivers. Generally, no. When running games in Wine under Linux, the performance hit is still very noticeable, in all games, often exceeding 50%. Many of the core components of Wine were written 20+ years ago, for old Pentiums, and they lack support for both multicore architectures and modern CPU instructions. This is also the reason why native Vulkan games tend to get a severe performance hit, like DOOM (2016) does.
    50% performance hit is only with Nvidia in select titles, it's usually hardly more than 15% with Radeons (and often far less).
    Doom (2016) runs faster in Wine than on Windows with Radeon when GPU bound, while CPU bound performance probably doesn't differ much...

    Leave a comment:


  • R41N3R
    replied
    Originally posted by DebianLinuxero View Post
    I don't see the point on this.

    I remember the 3dfx days, when voodoo hardware hasn't a native OpenGL implementation, but an OpenGL to Glide wrapper.

    Something like this Zink.

    That wrapper costed performance to the voodoos.

    I remember a press note of one 3dfx manager saying that the next drivers they'll do will be native OpenGL because of this.

    Too late I "Zink"
    Intel and radeonsi required years of development to reach their current state, so it is obvious that Zink will be slower than a native driver. But what if the OpenGL driver doesn't exist yet or is in a bad state? Then Zink would speed up the time to develop drivers massively as you could just focus on a Vulkan only driver and get OpenGL (+OpenGL ES) for free. This is the main advantage of Zink from my point of view.
    If Zink works reasonably well, I would probably use it as well instead of Intel/radeonsi as long as the frame rate will be OK.

    Leave a comment:


  • rawr
    replied
    Originally posted by ShFil View Post

    You make a wrong assumption here. It's not about emulating aka having the exact same behavior like other software, but to match the same specification. So under the hood it can do less and achieve the same results.
    Strictly speaking he would be right. An ideal specialised native driver will always be faster than a driver that has one more abstraction layer, since that abstraction layer might prevent certain optimizations or just is slower because of one more indirection.
    In reality drivers will have their own abstractions in there and depending on the architecture, some workloads will always be preferred to others.

    In the long run I would expect Zink to have comparable performance with a better GL implementation overall (given that the Vulkan specification and implementation are good enough)

    Sounds like that would be ideal for WebGL (I'm not a fan of it)

    Leave a comment:


  • microcode
    replied
    I think Zink can do very well and I'm excited to see the performance loss to trend toward zero, then toward negative infinity. :+ )

    Leave a comment:


  • Venemo
    replied
    Originally posted by DebianLinuxero View Post
    I don't see the point on this.

    I remember the 3dfx days, when voodoo hardware hasn't a native OpenGL implementation, but an OpenGL to Glide wrapper.

    Something like this Zink.

    That wrapper costed performance to the voodoos.

    I remember a press note of one 3dfx manager saying that the next drivers they'll do will be native OpenGL because of this.

    Too late I "Zink"
    The point is that, in theory, if Zink gets good enough, then future GPU vendors don't need to implement an OpenGL driver anymore, just Vulkan, and Zink would give them OpenGL “for free”.

    We already see examples of this on Windows, where a few vendors don't want to invest in OpenGL anymore. That is why Microsoft is now contributing an “OpenGL on DX12” layer in mesa.

    Leave a comment:


  • rawr
    replied
    Originally posted by George99 View Post

    You're right. Normally I don't care about spelling mistakes but the missing n changes the meaning to something funny. (If you speak German)
    Spelling of names do not always coincide with the spelling of regular words. Did you actually want to hint at the error (his name is actually Blumenkrantz) or just at the fun of the changed meaning?

    The correct spelling of the word itself would be Blumenkranz (without the t). I speak German.

    Leave a comment:


  • blackshard
    replied
    Originally posted by DebianLinuxero View Post
    I don't see the point on this.

    I remember the 3dfx days, when voodoo hardware hasn't a native OpenGL implementation, but an OpenGL to Glide wrapper.

    Something like this Zink.

    That wrapper costed performance to the voodoos.

    I remember a press note of one 3dfx manager saying that the next drivers they'll do will be native OpenGL because of this.

    Too late I "Zink"
    It depends a lot on the underlying library.

    Vulkan is a very low-level API, which is ideal if you want to build something at higher level, such as OpenGL. OpenGL instead is a giant state machine that abstracts a lot of the underlying features and capabilities of the hardware.

    Of course making an OpenGL driver directly on the hardware will make it much faster because you can access all the features of the hardware, but it is also a lot more of work to create the driver and also to maintain it when the underlying hardware changes.


    Leave a comment:

Working...
X