Jump to content
  • Advertisement

pixeljetstream

Member
  • Content Count

    16
  • Joined

  • Last visited

Community Reputation

277 Neutral

About pixeljetstream

  • Rank
    Member

Personal Information

  1. Why are you using pushconstants for the matrices directly, if you intend to change them?   Alternative is to use UNIFORM_BUFFER_OFFSET for example or use a pushconstant that encodes a matrix index, and then have all matrices stored in a TBO.   that way you can update the buffer content just fine without re-creating command-buffers. https://github.com/nvpro-samples/gl_vk_threaded_cadscene makes use of various approaches
  2. Hi,   does it fit the renderpass semantic? for the OIT recording, would say no. The render passes are mostly designed to provide easy access of a previous pass output. Accessing the current framebuffer pixel atomically as you render is a different use-case.   The resolve pass does fit the semantic to a degree, as you express dependencies on the recording pass, however as you said there is no easy expression to express the K values you want to have on-chip per-tile.   http://on-demand.gputechconf.com/gtc/2014/presentations/S4385-order-independent-transparency-opengl.pdf (presentation that maybe contains some useful ideas for other OIT approaches)
  3. Would not generalize the choice of one vendor to drop 24-bit mode, for the future of all other GPU vendors.
  4. pixeljetstream

    Vulkan Resources

    several GL/Vulkan samples from NVIDIA here https://github.com/nvpro-samples   https://github.com/nvpro-samples/gl_vk_chopper https://github.com/nvpro-samples/gl_vk_threaded_cadscene https://github.com/nvpro-samples/gl_vk_bk3dthreaded https://github.com/nvpro-samples/gl_vk_supersampled   still rely on NVIDIA extensions, but we are working on making them "core vulkan"   articles https://developer.nvidia.com/engaging-voyage-vulkan https://developer.nvidia.com/vulkan-shader-resource-binding https://developer.nvidia.com/vulkan-memory-management https://developer.nvidia.com/opengl-vulkan   and another set of samples https://github.com/McNopper/Vulkan
  5. pixeljetstream

    Vulkan is Next-Gen OpenGL

    agreed, that's unfortunate, a simple "most" instead of "any"... it was an optimistic statement in good faith. However, that briefing imo is not an official commitment by any vendor about the level of support they want to give for certain hardware (obviously that doesn't help anyone who is now disappointed)
  6. pixeljetstream

    Vulkan is Next-Gen OpenGL

    Can confirm that it's Kepler and above. The presentation Matias refers to was from the early Vulkan days and plans do change. The driver engineer presenting just like myself is an engineer foremost, so what we say is not like press release type statements and final commitments. My statement here is what to expect driver-wise when Vulkan gets released. As for an official support commitment about operating systems and which hardware exactly, you have to wait until release. Sorry for this, but I hope you as developers understand that until something really ships, there is always some changes compared to what was originally planned.
  7. pixeljetstream

    Vulkan is Next-Gen OpenGL

    Vulkan requires Kepler and higher. We should have such lists once it comes out, and http://gpuinfo.org/ will get a nice vulkan section about capabilities.
  8. pixeljetstream

    Vulkan is Next-Gen OpenGL

    Two new articles out When you benefit from Vulkan over OpenGL https://developer.nvidia.com/transitioning-opengl-vulkan How to use OpenGL in a more Vulkan like way https://developer.nvidia.com/opengl-vulkan   While most cross platform engine developers will go Vulkan for the extra performance and control, others may need to take a few more considerations into account. Vulkan doesn't make OpenGL obsolete, and can also be overkill if you just want to play with graphics. Just want to stress that Vulkan is not a magic bullet solution, it takes more work to make use of it than GL, whether that work is "worth" the outcome really depends on the individual situation. If you start fresh project or already have data-driven designs and are more into engine technology, than of course you will like the low-level and clean api aspect of it a lot, plenty new things to explore :)
  9. pixeljetstream

    Vulkan is Next-Gen OpenGL

    And another one :)  sorry for the tease, as in an advent calendar, opening door by door, not that many topics left so ;)   https://developer.nvidia.com/vulkan-memory-management
  10. pixeljetstream

    Vulkan is Next-Gen OpenGL

    New blog post on shader resource binding in Vulkan https://developer.nvidia.com/vulkan-shader-resource-binding   As for the discussion around Vulkan/OpenGL, want to add my own personal opinion (not speaking for my employer, but I am obviously biased with being involved): There is no longs peak risk this time, we have running applications, tons of software people involved with early access... it's "for real". Despite the donation of Mantle as starting point, something that is written for exactly one hardware architecture just doesn't work for all of the vendors, it takes time to iron this out. Vulkan's goal was to do away with OpenGL/ES differentiation as well, so it's a lot more hardware vendors than just the usual desktop suspects. Also Mantle is "one" approach by a few individuals to modern APIs, Metal another, DX12 another and Vulkan another. Not disrespecting the Mantle design, but I would say it's fair to say that api was improved by the help of many.There is also an ugly legal aspect, that you cannot just write some headers + basic manpages and be done, a lot of work goes into specing out all details as it's relevant to IP issues.   Now on the OpenGL and AZDO situation. OpenGL does indeed provide fast-paths that may not be known to some, and it may indeed be "good enough" for a lot of folks to use that, rather than rewriting everything for vulkan. Saying OpenGL doesn't suck in its entirety or has no existence value, doesn't mean Vulkan is not needed either. As someone mentioned before MS also keeps DX11 next to DX12. Khronos (as in the companies involved) do message that Vulkan coexists next to OpenGL.   There is no black/white situation here imo. OpenGL has many known flaws being a grown cluster-fuck, but it also has some strengths that probably will be more obvious once people realize what they have to write in vulkan themselves.   As phantom mentioned, there is not gonna be that single api to work with, if your render engine has to serve many markets, you will need to take care of many APIs. End of story. The good thing is that at least with the new round of apis they all offer somewhat similar models when it comes to threading, command submission... that is a clear win over the past.   So imo the "good enough" doesn't sound hypocrit, as just pointing to yes certain things we can do really well in OpenGL, doesn't mean that solves every issue of the api.We are all engineers and now that there is always tradeoffs here and there. Even if you don't use extensions in vulkan, it still means certain hardware will like certain "values" and setups more than others. That moment where you care about squeezing the most out of the hw, you have to prepare for hw specific coding. It's your choice, and the good thing about vulkan is that you get this choice and responsibility now. There is nothing "evil" in using OpenGL if it serves the job either. Those apis don't exist for their own purpose but to serve something else.
  11. pixeljetstream

    Vulkan is Next-Gen OpenGL

    yes reworded it after seeing the confusion around it. As for development stage, I used that wording, as paperwork, polish, conformance tests... is part of the process as Khronos said in their December statement. If you just mean the header, yes that was frozen a while back.
  12. pixeljetstream

    Vulkan is Next-Gen OpenGL

    SPIR-V is mandatory for Vulkan, this extension will allow usage of GLSL strings. Both extensions mentioned in the article target people with existing OpenGL code, who want to have a quicker go on evaluating Vulkan for their needs, or transitioning to it. For final applications, or applications made from scratch it is much more likely you would be using the open-source SPIR-V tools such as Google's https://github.com/google/shaderc
  13. pixeljetstream

    Vulkan is Next-Gen OpenGL

    Here is a new blog post on Vulkan https://developer.nvidia.com/engaging-voyage-vulkan
  14. pixeljetstream

    Vulkan is Next-Gen OpenGL

    thanks for posting those @Infinisearch, worked on that extension and several slides and demos  also from this year http://on-demand.gputechconf.com/gtc/2015/presentation/S5135-Christoph-Kubisch-Pierre-Boudier.pdf the samples can be found  https://github.com/nvpro-samples/gl_commandlist_basic and https://github.com/nvpro-samples/gl_cadscene_rendertechniques once vulkan goes public we will have a sample that showcases both commandlist and vulkan in a threaded scenario (how both compare code wise), it will be a modified version of the latter sample and was used to demo vulkan so far.
  15. pixeljetstream

    Vulkan is Next-Gen OpenGL

    People using Dx12 or Vulkan have good reasons for either, any sort of X is better than Y is not worth to brawl over. Dx12 will have a lot to speak for it for Windows (MS providing tools, SDKs...). Vulkan and OpenGL have it "harder" as they rely on a platform holder to "allow them" in the first place...          Who is "they"? Khronos can't do anything about Apple doing their own thing. If someone decides they want to control their platform alone, nothing will stop them. In the contrary if some big platform holder decides to push something, it does accelerate things. Valve being the biggest platform holder for Vulkan for the longest time (Linux SteamOS) until Google jumping on board. With someone like Google weighing in and the market that can be addressed, it's easier for the companies to justify urgency. It has nothing to do with "oh those Khronos guys are lazy or whatnot", it's the same companies that work on DirectX as well ;) It's only about the business. MS will put in the money for conformance testing, promoting Win10 and DX12, need to have that for Vulkan as well. Khronos pockets are not that deep ;) but Steam and Google are the bigger players for that.     Whether people will use Vulkan natively for Windows rather than Dx12 to target Dx11-hardware will depend on how the ecosystems develop, we will see if the open-sourcing of all the tools around Vulkan will be beneficial. On that front Vulkan's success depends a bit more on the community.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!