Vulkan/OpenGL Next Generation Initiative: unified API for mobile and non-mobile devices.

Discussion in 'Rendering Technology and APIs' started by ToTTenTranz, Aug 11, 2014.

  1. mczak

    Veteran

    Joined:
    Oct 24, 2002
    Messages:
    3,019
    Likes Received:
    115
    Nvidia should do it since G80 (the interpolation is done in the SFU, the whitepaper saying "Plane equation unit generates plane equation fp32 coefficients to represent all triangle attributes". Intel always did (since gen4, i965) interpolation in the shader (with the help of a PLN instruction), however they only switched to barycentric with Gen6 (Sandy Bridge).
    Mobile could be different though. From the freedreno sources, it seems adreno (since 300 series) also does some kind of barycentric interpolation, but from a quick glance the barycentric coordinates may not be available as ordinary registers (the driver issues OPC_BARY_F instructions). Not sure though it was a very quick glance, and no idea about others...

    I don't have any idea. Intel doesn't publish throughput numbers for the extended math functions ever since these were no longer a true external shared unit (the dreaded MathBox), so not since Sandy Bridge. The last numbers thus are for Ironlake - the docs are saying throughput 3 rounds per element for quotient, 4 for remainder. Note this is for a _scalar_ element, so dead slow (at least i965 only had one MathBox for the whole gpu, IIRC a very frequent bottleneck). For comparison, sqrt was also quoted to need 3 rounds per element, and things like sin/cos, pow being much slower still. (The docs are actually saying one round has 22 clock cycle latency, I don't know if I should believe what I think this really means, as it would be really awful...) In any case it's probably best not to extrapolate anything from these values to more modern chips, wouldn't be surprising imho if some operations now have less or more throughput compared to others.
     
    sebbbi likes this.
  2. Dominik D

    Regular

    Joined:
    Mar 23, 2007
    Messages:
    782
    Likes Received:
    22
    Location:
    Wroclaw, Poland
    @ToTTenTranz: Sure. Still: it was about how (supposedly) DDIs for previous D3Ds hinder driver robustness and D3D12 on its own would be the right approach.
     
  3. eastmen

    Legend Subscriber

    Joined:
    Mar 17, 2008
    Messages:
    11,155
    Likes Received:
    2,221
    What hardware ? AMD already supports it on all the cards its currently supports through its drivers. Nvidia is doing the same. I'm also fairly sure intel will support it through at least the core line.

    What else needs to support it ?
     
  4. Dominik D

    Regular

    Joined:
    Mar 23, 2007
    Messages:
    782
    Likes Received:
    22
    Location:
    Wroclaw, Poland
    If you're saying that AMD and Nvidia support D3D12 (with whatever feature level) for most of the cards out there, then I stand corrected. :)
     
  5. willardjuice

    willardjuice super willyjuice
    Moderator Veteran Alpha

    Joined:
    May 14, 2005
    Messages:
    1,385
    Likes Received:
    299
    Location:
    NY
    But will anyone think of all the DX11 VIA igpus!?! :razz:
     
  6. ToTTenTranz

    Legend Veteran Subscriber

    Joined:
    Jul 7, 2008
    Messages:
    11,077
    Likes Received:
    5,628
    It seems that John Carmack is also concerned with Google being absent from Vulkan's supporters:

    https://twitter.com/ID_AA_Carmack/status/575693181519429633


    Going through VIA's page is like a trip to the past!
    Vista? Meaning it could even play Halo 2??

    And their top-of-the-line x86, the Via QuadCore:
    Such performance, much efficiency. Wow.
     
  7. sebbbi

    Veteran

    Joined:
    Nov 14, 2007
    Messages:
    2,924
    Likes Received:
    5,293
    Location:
    Helsinki, Finland
    Oh please, no! We don't need another RenderScript. Vulcan has everything I need (= compute shaders + multidraw). Google API would certainly miss many important features and be way too generic.
     
  8. willardjuice

    willardjuice super willyjuice
    Moderator Veteran Alpha

    Joined:
    May 14, 2005
    Messages:
    1,385
    Likes Received:
    299
    Location:
    NY
    Why do you think Google is incapable of developing a competitive graphics API?
     
  9. ToTTenTranz

    Legend Veteran Subscriber

    Joined:
    Jul 7, 2008
    Messages:
    11,077
    Likes Received:
    5,628
    Perhaps not as incapable as unwilling.
    99.99% of Android's games are either 2D or use very simple 3D graphics.
     
  10. willardjuice

    willardjuice super willyjuice
    Moderator Veteran Alpha

    Joined:
    May 14, 2005
    Messages:
    1,385
    Likes Received:
    299
    Location:
    NY
    Ah you can't have it both ways; if we only care about Angry Birds then ogl es 3.1 is far more than you need! In this case Google wouldn't need to bother with Vulkan or a custom API.

    Regardless, that wouldn't change my question. Let's pretend the android store only has AAA console games: why do you think Google is incapable of developing a competitive graphics API?
     
  11. liquidboy

    Regular Newcomer

    Joined:
    Jan 16, 2013
    Messages:
    416
    Likes Received:
    77
    Sadly the only people that want standards are those that are behind in their own ecosystems, developers like the ones here on this forum! ...

    Once you have your own strong ecosystem, like Apple, Microsoft, Google, Samsung (almost) you'll want to control everything all the way down to api's and HW ..

    So its only a matter of time till Google does what it did with forking Webkit and go it alone with a low level graphics api (like Apple did recently with Metal)..

    It's the sad truth of the situation where ecosystems want to make it as hard as humanly possible to port apps/games between ecosystems..

    p.s. I bet you there are meetings going on behind closed doors in Google land talking about how to prevent Microsoft from running android apps and chrome extensions/apps in their ecosystems .. Right now its looking like MS is going to do this ...
     
  12. lanek

    Veteran

    Joined:
    Mar 7, 2012
    Messages:
    2,469
    Likes Received:
    315
    Location:
    Switzerland
    Its not that they want to control the HW/API/everything .. they want to control the ecosytem and the consumers/ professional ecosystem who will buy or developp in it..

    Google will developp an Android " low level API".... Apple provide an API for their ecosystem.. included for develop games, because it was and it still an easy way to get developpers ( and non developpers ) involved on developping apps, games for their ecosystem ( mostly to create a new market at start, but this have change since the smartphones / mobiles games have rise so well on money side ( this said, apps are so bad coded, games are so badly optimized, because here the word is, make small games, who cost the minimum possible to developp and bring a lot of money ( Candycrush as example )..

    For Apple this is a money cash system. Google will love to get this as a cash system too. This said, i hope this market will change quickly.... its so brutal how innovation have take a break in this domain.

    The mobile ecosystem made by the actual brands ( ) is the worst things who have never been created for innnovation developpement and technology access.. everything is closed to proprietary systems, each actors want to control everything... for keep the consumers on their road of milking them up.

    The only left innovations are on the hardware side, because they all need it.

    And they will continue to try again and again to get the solution who will make that everyone want to only buy their device.. If its only available on our ecosystem, and if you need it, you will need to get our devices ... Dont wait anything from them, from this sector on this side.. Technology innovation is here, but not used for make is way to everyone, just for make a maximum of money.

    Look the payment system of Apple: you get NFC, you get standard bank card system ( National bank, private bank, shops, credit card system ) who use all one system, well implemented and available ( i can pay with simple NFC by linked by visa card on my smartphone, on every shop who accept visa, mastercard card ).. you get the smartphone market who is divided with a 85% for Android bases system, and 11-12% for Apple ecosystem.. you still see Apple release a payment system by their smartphone after refused since 4 years to include NFC in their smartphone ( still their new system is based on NFC and Token, similar to other ), trying to licence, make their payment NFC system the only one possible to use when you go on a shop, just for create a need to have their devices... outside Asia who use NFC payment since 10years ( even for metro, bus, shops, administration etc ), in other country, you end now with different systems of payment and the adoption rates is really really slow. ( All based on the same technology ).

    WHy will you imagine they think differently for " damn small, low cost 4$ games " on their system ? Do you really think, they want to drive the next evolution on gaming ? On the financial side, money yes.. on the quality ? innovation ? .. lol, all the rest is only marketing..

    I have take the example of Apple, as it was easy, but i dont attack Apple, the whole mobile industry is the same...

    We have pass from Innvoation on technology to a sad scenario, well worst than the MS vs Linux vs Open vs.. well you get the message. Thinking that their decisions about Vulkan will be drived by open standard ", innovation, simplicity or made for the developpers and for offer new possibility on the mobile market is a completely wrong assumption.. they just want to do money.

    Sorry was a bit offtopic.
     
    #112 lanek, Mar 12, 2015
    Last edited: Mar 12, 2015
  13. sebbbi

    Veteran

    Joined:
    Nov 14, 2007
    Messages:
    2,924
    Likes Received:
    5,293
    Location:
    Helsinki, Finland
    They certainly do have the performance programming talent (just look at their search algorithms they use in their data centers). I am not questioning about that.

    What I am questioning is their history of preferring to hide all the hardware details on low power mobile devices, where every cycle counts. It is a strange choice that Java was chosen to be the core application development language on performance and power constrained devices running on a small battery. It took awfully long time until even simple apps were running at smooth 60 fps on Android. Random garbage collection stalls still occur even on devices equipped with 8 core CPUs and 3 GB of memory. Google prefers their own high level RenderScript (Java API) instead of the industry standard OpenCL, because OpenCL is too hardware specific.It wasn't a problem for them that RenderScript was not even available for NDK, since Java development is the main way to write apps for their platform. Call me cynical, but I don't have high hopes for Vulkan on Android. It would only benefit the NDK developers, and NDK has never been a high priority for Google. Historically the compiler support for NDK has always lagged behind other platforms (for several years). C++ was not even officially supported for a long time (NDK officially only supported C). Things have lately improved on the compiler front, and that makes me happy. I am hoping that Carmack keeps pushing Google to the right direction, since he understands the meaning of efficient CPU and GPU usage and the implications of input/display latency. Latency is very important for VR technology. Oculus + Samsung is pushing their joint Android mobile VR tech heavily, meaning that they likely give Google lots of good feedback how to improve their platforms for high performance (and low latency) VR development. All these improves should benefit games (and NDK development) in general on Android.

    VR is a big buzzword right now, and if Carmack says VR needs Vulkan, it might be hard to disregard that.
     
  14. forumaccount

    Newcomer

    Joined:
    Jan 30, 2009
    Messages:
    140
    Likes Received:
    86
    What justification would he even have for making a statement like this? Vulkan doesn't offer anything that can't be done in OpenGL already. It's just a better-thought-out API which should result in better CPU performance. So "VR needs Vulkan" translates to "VR requires weak CPUs"?
     
  15. Rodéric

    Rodéric a.k.a. Ingenu
    Moderator Veteran

    Joined:
    Feb 6, 2002
    Messages:
    4,031
    Likes Received:
    898
    Location:
    Planet Earth.
    It would rather mean that VR requires higher performance to be good and therefore any API that waste cycles is a bad idea.
    (ie even on your i7 behemoth you need to spare as many cycles as you can and get CPU & GPU to run asynchronously instead of traditional master & slave relationship.)
     
  16. Alexko

    Veteran Subscriber

    Joined:
    Aug 31, 2009
    Messages:
    4,515
    Likes Received:
    934
    Plus, I don't think you can assign one GPU to each eye in OpenGL or D3D11, so there's that. It's still a matter of performance, but not CPU-related.
     
  17. sebbbi

    Veteran

    Joined:
    Nov 14, 2007
    Messages:
    2,924
    Likes Received:
    5,293
    Location:
    Helsinki, Finland
    Explicit resource management makes it possible to run the GPU and CPU closer to lock step, reducing the latency. In high level APIs there's a lot of buffering happening (in driver threads) for various reasons. DX 12 and Vulkan will certainly reduce the latency on PC and mobiles (closing the gap significantly to consoles).

    High level APIs also have various stalls (frame spikes) because of automatic resource management, shader compilation (because of state changes), data transfers and format conversion abstraction.

    Also Vulkan is much more CPU efficient compared to OpenGL. This is critical when you are rendering two scenes (both eyes) simultaneously. On a power constrained SOC, the TDP is shared, meaning that Vulkan can clock the GPU higher, allowing higher frame rates (60 fps is the absolute minimum for reasonable VR experience).
     
    #117 sebbbi, Mar 13, 2015
    Last edited: Mar 13, 2015
  18. firstminion

    Newcomer

    Joined:
    Aug 7, 2013
    Messages:
    217
    Likes Received:
    46
    It means that VR needs low latency and predictable performance and Vulkan aims for those.
     
  19. rpg.314

    Veteran

    Joined:
    Jul 21, 2008
    Messages:
    4,298
    Likes Received:
    0
    Location:
    /
    Importance of sorting draw calls by state in vulkan/dx12?

    Is it still important? IMG used to recommend sorting by state changes instead of depth for obvious reasons, but is that going away?
     
  20. DmitryKo

    Regular

    Joined:
    Feb 26, 2002
    Messages:
    805
    Likes Received:
    833
    Location:
    55°38′33″ N, 37°28′37″ E
    Sorry for a late reply.

    Well, that's strange, but again DX8-era features are cheap to emulate on current hardware with has like 200x the processing power of 2001-era parts. I don't see "lots of fixed funtion features" in DDI9 part of WDDM and I don't think they can be a major cause of driver problems in current D3D11 applications.

    I beg to differ.

    With latest GPUs like GCN, we have massively multi-core, general-purpose MIMD CISC processors, and the WDDM driver has to interpret the intermediate shader language to remap it onto the processor architecture used: things like physical registers, machine instructions, virtual memory tables and descriptor tables.

    In regard to machine instructions - which are decoded internally to very simple ALU and/or load-store micro-ops - there is offten very little incentive to biuld complicated "do it all" operations into machine codes, unless the operation is extremely common and warrants the effort for designing high-performance processing units just for a couple of specific micro-ops.

    So it's often preferable to just require several successive machine codes for some complex operation, and design micro-op decoders and schedulers for effective parallel execution, or use large caches to hide the memory latency. In effect, you will have essentially the same performance as you would achieve with a very complex machine instruction, but you don't risk going over your micro-op budget and over-engineering your scheduler - all to account for a very small percentage of usage cases.


    So it seems perfectly legitimate when shader functions are not directly mapped one-to-one to equivalent hardware instructions - if that was the original intention of the designers of the arhitecture in the first place. Of course, it's only OK as long as that arhitectural decision doesn't severely impacts real-world performance - which could be a problem when a certain shader code requires tens or several dozen machine instructions. That was my point about "killing the performance", so it's probably a matter of finding a good balance between complexity and performance.

    I wouldn't exactly call these implementation-specific details "emulation" - even the remains of the DX8 era like the hardware pixel fog or shader models 1.0/2.0 which are still required in DDI9 part of WDDM drivers.

    However I didn't have the chance to run shaders with graphic debugging tools and see how the high level code is mapped to actual machine instructions of the underlying processing architecture, so I'd like to see more details on this.


    Still I'm certain you positively can't or shouldn't try to "emulate" features that require not just a few more machine instructions to translate your shader code to, but certain physical hardware blocks, registers, page/descriptor tables, micro-ops and operands.

    Things like CPU virtual memory addressing (requires virtual page tables and TLBs to support 64-bit memory pointer size), unordered access views (require segmented addressing mode and descriptor tables), tiled resources (require virtual page tables and CPU host-based background memory tracking, Tiers 2 and 3 require specific additions to page table format), conservative raserization and rasterizer ordered views (require programmable rasterizer processor stage), typed resource formats and texture compression formats (require direct support for specific formats in the machine codes), etc.

    I wouldn't insist if I wasn't taught Processor Design during my engineer degree studies... I still have my lecture notes around and the basics still hold for any von Neuman architecture CISC processor, even advanced one like GCN...
     
Loading...

Share This Page

  • About Us

    Beyond3D has been around for over a decade and prides itself on being the best place on the web for in-depth, technically-driven discussion and analysis of 3D graphics hardware. If you love pixels and transistors, you've come to the right place!

    Beyond3D is proudly published by GPU Tools Ltd.
Loading...