Announcement

Collapse
No announcement yet.

The Khronos Group's Vulkan, SPIR-V & OpenCL 2.1 Presentations

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

  • #11
    Originally posted by smitty3268 View Post
    In the video, someone in the audience complains that Vulkan is still a C API rather than C++ during the Q&A, i guess that's what he's referring to.

    The presenters pretty much blew him off and said everyone wanted a C api, and that if people wanted something in c++ it should be trivial for a library to wrap it around Vulkan.
    yea make C++ wrapper for C API is much easier than making C wrapper for C++ API. You can make OO API with C just fine. See g_object used in GNOME. Also there is no standart ABI for C++ so it would be absolutly mess to link against vulkan lib.

    Comment


    • #12
      Why, just why does a graphics group upload 360p videos in 2015..

      Comment


      • #13
        Originally posted by mark45 View Post
        Why, just why does a graphics group upload 360p videos in 2015..
        Disclaimer: This video is taken directly from our impromptu live stream. Better quality will be uploaded in a few days.

        Comment


        • #14
          Originally posted by Marc Driftmeyer View Post
          I absolutely could care less with this abstraction C++ decision from Khronos. C++ as a layer of abstraction is a giant pig on top of C.
          Spoken like someone living in the 90's...show me modern evidence that C++ is slower than C doing the same job.

          Comment


          • #15
            Originally posted by AnonymousCoward View Post
            yea make C++ wrapper for C API is much easier than making C wrapper for C++ API. You can make OO API with C just fine. See g_object used in GNOME. Also there is no standart ABI for C++ so it would be absolutly mess to link against vulkan lib.
            Some thing like :-

            Code:
            #ifndef VULKAN_HPP
            #define VULKAN_HPP
            namespace vk {
              extern "C"{
                #include <vulkan.h>
              }
            }
            #endif
            Well I'm just kidding. But anyway, despite the fact that creating C++ wrapper is quite easy, I'd like to see 'official wrapper' from Khronos instead of everyone creating their own wrapper.

            Comment


            • #16
              Originally posted by sbolokanov View Post
              Disclaimer: This video is taken directly from our impromptu live stream. Better quality will be uploaded in a few days.
              31C3 had HD streams and that's an noncommercial event with massive attendee numbers?

              Comment


              • #17
                Originally posted by mr_tawan View Post
                Well I'm just kidding. But anyway, despite the fact that creating C++ wrapper is quite easy, I'd like to see 'official wrapper' from Khronos instead of everyone creating their own wrapper.
                It's quite plausible that they'll do it.

                Comment


                • #18
                  That's great.

                  Originally posted by sbolokanov View Post
                  Disclaimer: This video is taken directly from our impromptu live stream. Better quality will be uploaded in a few days.
                  There were a lot of issues with that live stream, so that is good news. However, what of the first session, which is broken up into parts on Ustream, and has such bad color issues?

                  Comment


                  • #19
                    Do we know if Vulkan on Linux will be independent of X like egl so that it can be used by Wayland compositors and applications? Currently I think applications need glx for regular openGL and thus can't run on Wayland, or am I wrong?

                    Comment


                    • #20
                      Originally posted by cbxbiker61 View Post
                      Spoken like someone living in the 90's...show me modern evidence that C++ is slower than C doing the same job.


                      cpp does not give you absolute control over memory management, so it will never be as fast as C
                      (and no, i don't count heavy hacks or using C as cpp)

                      Comment

                      Working...
                      X