Registar

User Tag List

Likes Likes:  0
Página 1 de 6 123 ... ÚltimoÚltimo
Resultados 1 a 15 de 86
  1. #1
    Moderador Avatar de Winjer
    Registo
    Feb 2013
    Local
    Santo Tirso
    Posts
    12,672
    Likes (Dados)
    30
    Likes (Recebidos)
    208
    Avaliação
    4 (100%)
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)

    Vulkan - Next-Gen OpenGL

    Next-Gen OpenGL To Be Announced Next Month


    The Khronos Group has shared details about their BoF sessions to be hosted next month during SIGGRAPH and it includes detailing the next-generation OpenGL / OpenGL ES specifications.

    The next SIGGRAPH is in August in Vancouver (Canada) and there's a total of seven tracks during this important graphics conference where Khronos is to be involved. The Khronos BoFs were publicized today on Khronos.org.

    Perhaps the most interesting BoF to Phoronix readers will be their OpenGL (OpenGL ES) BoF where the next GL standard is to be announced. The description reads, "Hear how OpenGL ES and OpenGL are evolving to meet the needs of next-generation 3D applications, providing lower overhead and greater graphics richness on mobile and desktop platforms."

    Hearing about "lover overhead OpenGL" is hardly a surprise given it's been an increasing focus amongst game developers and hardware vendors. Microsoft DirectX 12 will focus on lower-overhead, Apple's Metal API is about low-overhead, and it's the main focus of AMD's Mantle API. Intel, NVIDIA, and AMD have all been investing in lowering the driver overhead for OpenGL.

    Given that this next GL revision is expected to be major, the version bump will probably take it to become OpenGL 5.0 rather than OpenGL 4.5. The OpenGL 4.4 specification is now one year old (generally OpenGL revisions get announced every 6~12 months) while on the mobile/embedded side OpenGL ES 3.1 is just a few months old but perhaps if a major overhaul lands there immediately it will become OpenGL ES 4.0.

    Details on the new OpenGL / OpenGL ES at the SIGGRAPH BoF are taking place on the evening of 13 August. Khronos will also be talking at SIGGRAPH Vancouver about WebGL, WebCL, OpenCL, SPIR, SYCL, and their other royalty-free industry standards.
    Está a ser uma altura interessante a nível de APIs. Entre o DX12, o mantle e o novo OpenGL, há muita coisa nova e muita disputa para ver quem é o melhor.
    Última edição de Winjer : 03-03-15 às 10:54
    Ryzen R5 3700X / Noctua NH-D15 / B550 AORUS ELITE V2 / Cooler Master H500 Mesh / 16Gb DDR4 @ 3800mhz CL16 / Gigabyte RTX 2070 Super / Seasonic Focus GX 750W / Sabrent Q Rocket 2 TB / Crucial MX300 500Gb + Samsung 250Evo 500Gb / Edifier R1700BT


  2. #2
    Moderador Avatar de Winjer
    Registo
    Feb 2013
    Local
    Santo Tirso
    Posts
    12,672
    Likes (Dados)
    30
    Likes (Recebidos)
    208
    Avaliação
    4 (100%)
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    Ryzen R5 3700X / Noctua NH-D15 / B550 AORUS ELITE V2 / Cooler Master H500 Mesh / 16Gb DDR4 @ 3800mhz CL16 / Gigabyte RTX 2070 Super / Seasonic Focus GX 750W / Sabrent Q Rocket 2 TB / Crucial MX300 500Gb + Samsung 250Evo 500Gb / Edifier R1700BT


  3. #3
    Tech Ubër-Dominus Avatar de Jorge-Vieira
    Registo
    Nov 2013
    Local
    City 17
    Posts
    30,121
    Likes (Dados)
    0
    Likes (Recebidos)
    2
    Avaliação
    1 (100%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Graphics Developers: Help Name Next Generation OpenGL

    The Khornos Group probably wants some advice from graphics developers because they ultimately want to market to them, as the future platform's success depends on their applications. If you develop games or other software (web browsers?) then you can give your feedback. If not, then it's probably best to leave responses to its target demographic.

    As for the questions themselves, first and foremost they ask if you are (or were) an active software developer. From there, they ask you to score your opinion on OpenGL, OpenGL ES, and WebGL. They then ask whether you value “Open” or “GL” in the title. They then ask you whether you feel like OpenGL, OpenGL ES, and WebGL are related APIs. They ask how you learn about the Khronos APIs. Finally, they directly ask you for name suggestions and any final commentary.
    Now it is time to (metaphorically) read tea leaves. The survey seems written primarily to establish whether developers consider OpenGL, OpenGL ES, and WebGL as related libraries, and to gauge their overall interest in each. If you look at the way OpenGL ES has been developing, it has slowly brought mobile graphics into a subset of desktop GPU features. It is basically an on-ramp to full OpenGL.
    We expect that, like Mantle and DirectX 12, the next OpenGL initiative will be designed around efficiently loading massively parallel processors, with a little bit of fixed-function hardware for common tasks, like rasterizing triangles into fragments. The name survey might be implying that the Next Generation OpenGL Initiative is intended to be a unified platform, for high-end, mobile, and even web. Again, modern graphics APIs are based on loading massively parallel processors as directly as possible.
    If you are a graphics developer, the Khronos Group is asking for your feedback via their survey.
    Noticia:
    http://www.pcper.com/news/General-Te...eration-OpenGL
    http://www.portugal-tech.pt/image.php?type=sigpic&userid=566&dateline=1384876765

  4. #4
    Tech Ubër-Dominus Avatar de Jorge-Vieira
    Registo
    Nov 2013
    Local
    City 17
    Posts
    30,121
    Likes (Dados)
    0
    Likes (Recebidos)
    2
    Avaliação
    1 (100%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Valve to show off Khronos glNext at GDC next month

    The next version of the OpenGL graphics API is set to be revealed next month at the Game Developers Conference, with Valve to give the presentation. The event page for the conference has been updated with a new session listed, titled ‘glNext: The Future of High Performance Graphics’.
    The session will be hosted by Valve. The description for the presentation reads: “Join us for the unveiling of Khronos’ glNext initiative, the upcoming cross-platform graphics API designed for modern programming techniques and processors. glNext will be the singular choice for developers who demand peak performance in their applications”.

    “We will present a technical breakdown of the API, advanced techniques and live demos of real-world applications running on glNext drivers and hardware.”
    Valve supporting OpenGL makes sense, given that the company has been trying to usher in a Windows-less age of PC gaming, free from ties to Microsoft and DirectX. Valve is also expected to give us some updates on the Steam Machine initiative along with SteamOS at GDC, which takes place between the 2nd of March and the 6th of March this year.
    Noticia:
    http://www.kitguru.net/components/gr...dc-next-month/
    http://www.portugal-tech.pt/image.php?type=sigpic&userid=566&dateline=1384876765

  5. #5
    Moderador Avatar de Winjer
    Registo
    Feb 2013
    Local
    Santo Tirso
    Posts
    12,672
    Likes (Dados)
    30
    Likes (Recebidos)
    208
    Avaliação
    4 (100%)
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    Esta nova API devia ser mostrada no Source 2, a correr o Half Life 3.

    Anda lá Gabe, já estamos à espera há muito tempo por ele.
    Ryzen R5 3700X / Noctua NH-D15 / B550 AORUS ELITE V2 / Cooler Master H500 Mesh / 16Gb DDR4 @ 3800mhz CL16 / Gigabyte RTX 2070 Super / Seasonic Focus GX 750W / Sabrent Q Rocket 2 TB / Crucial MX300 500Gb + Samsung 250Evo 500Gb / Edifier R1700BT


  6. #6
    Tech Ubër-Dominus Avatar de Jorge-Vieira
    Registo
    Nov 2013
    Local
    City 17
    Posts
    30,121
    Likes (Dados)
    0
    Likes (Recebidos)
    2
    Avaliação
    1 (100%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Citação Post Original de Horus-Anhur Ver Post
    Esta nova API devia ser mostrada no Source 2, a correr o Half Life 3.

    Anda lá Gabe, já estamos à espera há muito tempo por ele.
    Espero que os deuses do gaming te ouçam
    http://www.portugal-tech.pt/image.php?type=sigpic&userid=566&dateline=1384876765

  7. #7
    Tech Membro Avatar de MAXLD
    Registo
    Mar 2013
    Local
    C.Branco
    Posts
    2,326
    Likes (Dados)
    0
    Likes (Recebidos)
    0
    Avaliação
    0
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Excelente, isto abre boas perspectivas sobre os próximos jogos da Valve... daqui a 10 anos.




    Mas é bem, esperemos que seja Top e meta o DX12 um bocado mais na gaveta.

  8. #8
    Tech Ubër-Dominus Avatar de Jorge-Vieira
    Registo
    Nov 2013
    Local
    City 17
    Posts
    30,121
    Likes (Dados)
    0
    Likes (Recebidos)
    2
    Avaliação
    1 (100%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Oh shit... mais 10 anos à espera de HL 3
    http://www.portugal-tech.pt/image.php?type=sigpic&userid=566&dateline=1384876765

  9. #9
    Tech Ubër-Dominus Avatar de Jorge-Vieira
    Registo
    Nov 2013
    Local
    City 17
    Posts
    30,121
    Likes (Dados)
    0
    Likes (Recebidos)
    2
    Avaliação
    1 (100%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    glNext Initiative Unveiled at GDC 2015

    The first next-gen, released graphics API was Mantle, which launched a little while after Battlefield 4, but the SDK is still invite-only. The DirectX 12 API quietly launched with the recent Windows 10 Technical Preview, but no drivers, SDK, or software (that we know about) are available to the public yet. The Khronos Group has announced their project, and that's about it currently.

    According to Develop Magazine, the GDC event listing, and participants, the next OpenGL (currently called “glNext initiative”) will be unveiled at GDC 2015. The talk will be presented by Valve, but it will also include Epic Games, who was closely involved in DirectX 12 with Unreal Engine, Oxide Games and EA/DICE, who were early partners with AMD on Mantle, and Unity, who recently announced support for DirectX 12 when it launches with Windows 10. Basically, this GDC talk includes almost every software developer that came out in early support of either DirectX 12 or Mantle, plus Valve. Off the top of my head, I can only think of FutureMark as unlisted. On the other hand, while they will obviously have driver support from at least one graphics vendor, none are listed. Will we see NVIDIA? Intel? AMD? All of the above? We don't know.
    When I last discussed the next OpenGL initiative, it was attempting to parse the naming survey to figure out bits of the technology itself. As it turns out, the talk claims to go deep into the API, with demos, examples, and “real-world applications running on glNext drivers and hardware”. If this information makes it out (and some talks remain private unfortunately although this one looks public) then we should know more about it than what we know about any competing API today. Personally, I am hoping that they spent a lot of effort on the GPGPU side of things, sort-of building graphics atop it rather than having them be two separate entities. This would be especially good if it could be sandboxed for web applications.
    This could get interesting.
    Noticia:
    http://www.pcper.com/news/Graphics-C...eiled-GDC-2015
    http://www.portugal-tech.pt/image.php?type=sigpic&userid=566&dateline=1384876765

  10. #10
    Tech Ubër-Dominus Avatar de Jorge-Vieira
    Registo
    Nov 2013
    Local
    City 17
    Posts
    30,121
    Likes (Dados)
    0
    Likes (Recebidos)
    2
    Avaliação
    1 (100%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Valve to present glNext: High Performance Graphics at GDC

    Games software creation and distribution firm Valve will present a special session at the upcoming Game Developers Conference (GDC), all about the next generation of OpenGL. The session is called 'glNext: The Future of High Performance Graphics' and takes place during the GDC, San Francisco, starting at 10am on Thursday 5th March.

    The glNext API will be an effort to rebuild the multi-platform graphics API specification from the ground up - to be a low-overhead modern graphics API. It is perhaps felt that something radical needs to be done with OpenGL in the face of new 3D gaming APIs from AMD (Mantle) and Microsoft (DirectX 12).
    A teaser for the presentation says:
    "Join us for the unveiling of Khronos' glNext initiative, the upcoming cross-platform graphics API designed for modern programming techniques and processors. glNext will be the singular choice for developers who demand peak performance in their applications. We will present a technical breakdown of the API, advanced techniques and live demos of real-world applications running on glNext drivers and hardware."
    While Valve presents the session, it will be joined by developers and graphics architects from the likes of Epic Games, Unity Technologies, EA (Frostbite Team) and Oxide Games.

    What has excited some industry observers, in the short term, concerns speculation about what the live demos and real-world applications on show will be. There has even been talk that this GDC session will be the first official confirmation and glimpse at Half Life 3, Portal 3 or Left 4 Dead 3 in glorious glNext action.
    While those long awaited blockbuster PC games might not make a showing at GDC remember that Valve has promised to give Steam Machines a 'front and centre' presence at GDC. We also expect to see a finalised Steam Controller design and more news of SteamOS development.
    Noticia:
    http://hexus.net/tech/news/software/...-graphics-gdc/
    http://www.portugal-tech.pt/image.php?type=sigpic&userid=566&dateline=1384876765

  11. #11
    Tech Ubër-Dominus Avatar de Jorge-Vieira
    Registo
    Nov 2013
    Local
    City 17
    Posts
    30,121
    Likes (Dados)
    0
    Likes (Recebidos)
    2
    Avaliação
    1 (100%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    GDC 15: What Is Vulkan (glNext), SPIR-V, and OpenCL 2.1?

    Who Should Care? Thankfully, Many People

    The Khronos Group has made three announcements today: Vulkan (their competitor to DirectX 12), OpenCL 2.1, and SPIR-V. Because there is actually significant overlap, we will discuss them in a single post rather than splitting them up. Each has a role in the overall goal to access and utilize graphics and compute devices.

    Before we get into what everything is and does, let's give you a little tease to keep you reading. First, Khronos designs their technologies to be self-reliant. As such, while there will be some minimum hardware requirements, the OS pretty much just needs to have a driver model. Vulkan will not be limited to Windows 10 and similar operating systems. If a graphics vendor wants to go through the trouble, which is a gigantic if, Vulkan can be shimmed into Windows 8.x, Windows 7, possibly Windows Vista despite its quirks, and maybe even Windows XP. The words “and beyond” came up after Windows XP, but don't hold your breath for Windows ME or anything. Again, the further back in Windows versions you get, the larger the “if” becomes but at least the API will not have any “artificial limitations”.
    Outside of Windows, the Khronos Group is the dominant API curator. Expect Vulkan on Linux, Mac, mobile operating systems, embedded operating systems, and probably a few toasters somewhere.
    On that topic: there will not be a “Vulkan ES”. Vulkan is Vulkan, and it will run on desktop, mobile, VR, consoles that are open enough, and even cars and robotics. From a hardware side, the API requires a minimum of OpenGL ES 3.1 support. This is fairly high-end for mobile GPUs, but it is the first mobile spec to require compute shaders, which are an essential component of Vulkan. The presenter did not state a minimum hardware requirement for desktop GPUs, but he treated it like a non-issue. Graphics vendors will need to be the ones making the announcements in the end, though.
    Before we go further, some background is necessary. Read on!
    What Is A Graphics / Compute API?

    Applications are bundles of instructions that operate on data, either packaged with it or gathered as the application runs. CPUs follow these series of instructions very quickly, pretty much one at a time, and in order. These are called threads, and modern CPUs can do multiple of them at any given time. It is common to find consumer CPUs that can do anywhere from two to eight threads at once.
    Sometimes, your application runs across big tasks, like “calculate the color of every pixel” or “move every point (vertex) in a 3D model by some amount”. These tasks add up to a lot of math, but each task is made up of mostly similar instructions. Modern GPUs can be thousands of cores, which is great when you are dealing with screens that have two million pixels (1080p) or more, many of which are calculated multiple times because of overlapping geometry and so forth, as well as 2D and 3D scenes that are made up of thousands or millions of triangles, each with three vertexes (albeit many are shared with neighboring triangles).
    To do this, stages in the drawing of 3D objects are introduced to inject programmable, called “shaders”. These shaders are associated with a material, such as water, or stone, or dirt. To achieve any given effect, software engineers think of what series of instructions will result in what effect they're trying to go for, be it based in real-world physics, or even nonsense that creates something fantastical (or looks realistic but is just a hacky trick).
    Some common shaders are:

    1. Vertex shader


    • A series of instructions for every affected vertex (give or take)
    • It is the first programmable rendering stage for an object


    1. Geometry shader


    • A series of instructions for every affected primitive (triangles, lines, points, etc.)
    • It usually runs after tessellation, which runs after the Vertex shader


    1. Fragment (Pixel) shader


    • A series of instructions for every rasterized pixel
    • It runs after the Geometry shader


    1. Computer shader


    • A series of commands for every whatever-the-programmer-wants.
    • It runs on its own, outside the typical rendering process

    If you wish to see a Fragment shader in action, a single 185-line script generates an ocean scene complete with a sky, waves, sub-surface scattering, and so forth. It is available at Shadertoy and should run in any WebGL-compliant browser. It runs once per canvas pixel. You can also edit the values on the right and click the play button at the bottom left of the text box to see how your changes affect the scene (or break it).
    For some reason, my Firefox locks up after a few seconds of this, but Google Chrome works fine. I am not exactly sure what either Shadertoy or Firefox is doing wrong, but it happens a lot at their site unfortunately.
    So What Does Vulkan Do Better and How Does It Differ from Mantle?

    A graphics API's primary job is to do all of the tasks required for a developer to submit their objects to be drawn, according to their geometry and materials. Mostly, this means keeping the unified shader cores of the GPU loaded with as much relevant work as they can. This helps increase the number of batches per frame, which is often one batch per object, per material.
    This is what Mantle and DirectX 12 flaunts: lots of draw calls for lots of objects on scene. It also allows reduced CPU usage as each thread is easier, and multiple cores can pitch in, all of which leads to less power consumption (especially useful for mobile apps that draw a lot of simple objects). Vulkan does all of this. Creating “Command Buffers” can be done on multiple threads while another thread assembles and manages a queue of commands to push to the GPU.

    Vulkan even allows the game developer to disable most of the error checking for production code. Rather than having the API look over the game code's shoulder to make sure it's not going to crash itself, like OpenGL and OpenGL ES does, all of that debugging cruft can be unhooked from shipped games. With this, the driver can be simple and the developer does not need to wait for the driver to make sure that the developer isn't doing what the developer already checked to make sure didn't happen before it sent its request to the driver. Wow, that sentence seems like an awful waste of time, doesn't it?
    But all of that makes the CPU side more efficient
    The Khronos Group has also tweaked the GPU side as well. Before now, we had a war between GLSL in OpenGL and HLSL in DirectX. HLSL was quite popular because Windows and Xbox were very popular platforms to target a game for. When AMD made Mantle, one of their selling points was that the Mantle shading language was just HLSL. This meant that game developers could keep using the shader language that they know, and AMD would not need to maintain a whole separate compiler/interpreter chain.
    When you are not bound by draw call limitations, another bottleneck might just be how much you can push through the shader cores. A good example of increasing the load on shaders would be increasing resolution (unless you run out of video memory or video memory bandwidth first). When AMD chose HLSL, it meant that they could make shaders for Mantle run just as fast as shaders for DirectX. This means that they would not be sacrificing top-end, GPU-bound performance for low-end, draw call-bound, CPU performance.
    Khronos is doing something else entirely.

    Rather than adopting HLSL or hoping that driver developers could maintain parity between GLSL and it, they completely removed shader compilation from the driver altogether. Pulling in their work in OpenCL 2, shaders in Vulkan will be compiled by the game developers into an LLVM-derived bytecode, called SPIR-V. All the driver needs to do is accept this pre-compiled intermediate representation and apply it for their architecture.
    This means a few interesting things. First, the game developer can write their source code in pretty much any language they want. HLSL and GLSL are based on a subset of C, while SPIR-V can be a subset of C++, some proprietary scripting language, or even HLSL. Khronos is currently working on a GLSL-to-SPIR-V compiler.
    Not only does this decrease shader compilation time, because SPIR-V is pre-compiled, but this probably means that a SPIR-V shader will be much more simple than either GLSL or HLSL. These shader languages have constructs for various vector and matrix maths, texture processing, and so forth. To see what I mean, check out pages 9 through 12 of the OpenGL 4.5 Quick Reference Card.
    Yes, I said four pages of a quick reference card.
    While I have not seen the SPIR-V spec, it sounds a lot like most of this will be relegated to libraries that can be compiled into the program. This lets the developer choose the sort of math algorithms that their Vulkan application will use to perform any arbitrary computation. I asked the presenter if Khronos would provide libraries for developers to use in their Vulkan shader application, and they said that it already existed for OpenCL 2.0, and an optimized version ships with OpenCL 2.1.
    Rephrasing the above paragraph: rather than baking all the complex math functions into the driver, such as complex matrix operations, the developer will have a much reduced set of instructions that they can do. They are allowed to combine those however they want, or choose an existing package to do what they want from Khronos, a graphics vendor, or even a friend. I'm not sure exactly what the simpler baseline will be, though.
    So What About OpenCL 2.1?

    The other part of this discussion is OpenCL 2.1. They added a few interesting things to the spec, but frankly Vulkan is the main thing our readers are here for. What I will discuss here, though, is that both OpenCL 2.1 and Vulkan accept the same SPIR-V bytecode. While Khronos did not mention this, it should mean that an efficient SPIR-V bytecode interpreter for OpenCL 2.1 could carry over optimizations to Vulkan, much like how AMD reused DirectX shader optimizations in Mantle (only Vulkan and OpenCL do not need to worry about the compiler half -- just the interpreter).

    OpenCL 2.1 still accept OpenCL 1.x kernel code too. This is probably for developers who have old code that they don't want to compile into SPIR-V, and would instead rather to use the legacy route.
    But this is why I said the announcement was heavily overlapped. OpenCL and Vulkan both use SPIR-V bytecode as their “send it to the GPU” language. From what I understand, OpenCL is a bit less relaxed that Vulkan in terms of error checking and, because it doesn't care about graphics, allows it to be used on FPGAs, CPUs, and other compute devices. Vulkan is more designed for workloads which mix high-performance graphics with compute.
    The Death of OpenGL and OpenGL ES? No. (And Conclusions)

    Khronos Group has also stressed that OpenGL and OpenGL are not going away. Some people will want to write applications on a platform that performs error checking and so forth. These APIs are still important to them, and will evolve as Khronos continually finds new directions for them to go.

    One last thing: earlier, we mentioned that Vulkan would allow shipped products to unhook its error checking code. If it will crash, let it crash. I asked the presenter whether this meant that they would unhook various robustness features. They said no. Vulkan apps will not be able to hang the GPU or break into other application's memory space to spy on them. I believe the quote was: “Oh yeah. We know how to do robustness.” This is very important for applications like web browsers, which accept arbitrary code from equally arbitrary places on the internet.
    In all, this could be interesting. Unlike DirectX, Khronos is allowing Vulkan to evolve outside of OpenGL. This could let them experiment in directions that Microsoft might not be able to. With DirectX 12 being “the next DirectX”, they seem to be admitting that it will need to be suitable for all developers once DirectX 11 gets deprecated. This might leave Microsoft with error-checking overhead that Khronos can chuckle at from the sidelines.
    We will see as GDC goes on how this will play out.
    OpenCL 2.1 and SPIR-V specs have been released today. Vulkan has not, but they feel the urgency and know that it must be out before the end of 2015. The presenter was also hinting that “before the end of 2015” might be much sooner than it sounds.

    Noticia:
    http://www.pcper.com/reviews/General...-and-OpenCL-21
    http://www.portugal-tech.pt/image.php?type=sigpic&userid=566&dateline=1384876765

  12. #12
    Moderador Avatar de Winjer
    Registo
    Feb 2013
    Local
    Santo Tirso
    Posts
    12,672
    Likes (Dados)
    30
    Likes (Recebidos)
    208
    Avaliação
    4 (100%)
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    The Khronos Group Officially Reveals Vulkan – Next-Gen OpenGL Open-Standard API

    The Khronos Group, an open consortium of leading hardware and software companies, today announced the availability of technical previews of the new Vulkan open standard API for high-efficiency access to graphics and compute on modern GPUs used in a wide variety of devices.As the press release reads, this ground-up design, previously referred to as the Next Generation OpenGL Initiative, provides applications direct control over GPU acceleration for maximized performance and predictability, and uses Khronos’ new SPIR-V specification for shading language flexibility. Vulkan initial specifications and implementations are expected later this year and any company may participate in Vulkan’s ongoing development by joining Khronos.
    Valve’s Gabe Newell said:
    “Industry standard APIs like Vulkan are a critical part of enabling developers to bring the best possible experience to customers on multiple platforms. Valve and the other Khronos members are working hard to ensure that this high-performance graphics interface is made available as widely as possible and we view it as a critical component of SteamOS and future Valve games.”
    Khronos is offering special preview sessions for insights into the Vulkan architecture.
    Vulkan: The Future of High Performance Graphics – hosted by Valve
    Thursday, March 5 at 10-11AM
    Venue: Room 2006 in the West Hall of the GDC Conference
    A technical preview of the Vulkan API, with advanced techniques and live demos of real-world applications running on Vulkan drivers and hardware
    Vulkan: the Next Generation Graphics and Compute API
    Thursday, March 5 at 12-1:30pm and repeated at 2–3:30pm
    Venue: SF Green Space at 657 Mission Street, Suite 200 – five minutes’ walk from GDC
    Vulkan overview, demos and direct interaction with working group members
    Ryzen R5 3700X / Noctua NH-D15 / B550 AORUS ELITE V2 / Cooler Master H500 Mesh / 16Gb DDR4 @ 3800mhz CL16 / Gigabyte RTX 2070 Super / Seasonic Focus GX 750W / Sabrent Q Rocket 2 TB / Crucial MX300 500Gb + Samsung 250Evo 500Gb / Edifier R1700BT


  13. #13
    Tech Ubër-Dominus Avatar de Jorge-Vieira
    Registo
    Nov 2013
    Local
    City 17
    Posts
    30,121
    Likes (Dados)
    0
    Likes (Recebidos)
    2
    Avaliação
    1 (100%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Vulkan nerve pinches DirectX in mobile



    Live long and render
    While it seems that the world+dog is rushing to back Microsoft's new DirectX API there are ructions in the force which have opened the way for a new rival.

    The alliance behind the OpenGL video standard has been showing off Vulkan API, an open standard that lets app writers take direct control of graphics chips and wring out extra performance on many devices. The software depends on good developers to make good use of it, but it could easily lead to richer visuals and smoother frame rates without demanding beefier hardware. The tech is still in a preview stage, but it already has some pretty noteworthy support, especially from Valve who wants it for its Steam Machines.
    AMD, ARM, Imagination and NVIDIA also see Vulkan doing wonders with their platforms, although Microsoft's efforts are going towards DirectX 12 and Apple is going towards Metal [Surely plastic. Ed], but Mantle only works with AMD GPUs, DirectX 12 only works in Windows, and Metal only works in iOS. Vulkan will span both GPU and operating system vendors, continuing in the footsteps of the cross-platform, vendor-neutral OpenGL before it.
    The new API was created to make it a better fit for modern hardware: GPUs are complex, highly programmable devices, and CPUs have abundant cores and multithreading support.
    Vulkan is also intended as suitable for both mobile and desktop development. This is in contrast to OpenGL, which has the OpenGL ES variant for mobile and embedded systems. The duality is in part due to OpenGL's age; it includes old features that aren't really relevant to modern 3D programming, but which nonetheless remain part of the specification. OpenGL ES removes many of these to be a little slimmer and more streamlined. Vulkan will similarly do away with them, eliminating the need for a special mobile API variant.
    With Vulkan, the way shader programs are compiled is changed. Traditional OpenGL requires each display driver to contain a full compiler for shader programs written in the C-like GLSL shader language. This is complex, with ample room for bugs. Microsoft's Direct3D took a different approach; shader programs are compiled once, by the developer, into a bytecode. Display drivers only need to process this bytecode, which is simpler.
    Noticia:
    http://www.fudzilla.com/news/graphic...ectx-in-mobile
    http://www.portugal-tech.pt/image.php?type=sigpic&userid=566&dateline=1384876765

  14. #14
    Tech Ubër-Dominus Avatar de Jorge-Vieira
    Registo
    Nov 2013
    Local
    City 17
    Posts
    30,121
    Likes (Dados)
    0
    Likes (Recebidos)
    2
    Avaliação
    1 (100%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    AMD’s Mantle Lives On In Vulkan – Lays The Foundation For The Next OpenGL

    The Khronos Group has chosen the best and brightest parts of AMD’s Mantle to serve as the foundation for “Vulkan,” the next OpenGL. This revelation came via an announcement by AMD and Khronos just recently. Mantle 1.0 is far from dead and will in fact live on and form the foundation of the next chapter of the latest cross-vendor OpenGL graphics API dubbed Vulkan.

    The vision for Mantle from the get go was to develop a leading edge graphics API that pushes the entire industry forward. Thus it had to succeed not only in surpassing other APIs in performance but it also meant that it had to be open. AMD quickly succeeded in achieving the first goal and now the second goal has finally been met and even superseded by something much more remarkable.
    AMD’s Mantle Lives On In Vulkan – Lays The Foundation For The Next OpenGL

    The benefits of Mantle 1.0 can now be enjoyed cross-vendor, across all hardware and operating systems. This includes hardware from AMD, Nvidia, Intel and even mobile players such as ARM and Qualcomm. It also means that the benefits of Mantle 1.0 can now extend to other operating systems beyond Windows such as Linux through Vulkan.
    The reduced rendering latency, reduced GPU power consumption, improved utilization of multi-core CPUs, and advanced multi-GPU features like split-frame rendering advents of Mantle 1.0 have all made their way to Vulkan through close collaboration between AMD and the Khronos group.


    John McDonald @basisspace Follow
    I'm so excited to finally share details of #Vulkan with my peers at #GDC. Also, huge thanks to @AMDRadeon for the gigantic leg up.



    John McDonald is a developer at Valve and one of several presenters including Tom Olson the Chair of the Working Group at Khronos who will talk about Vulkan in a session titled glNext: The Future of High Performance Graphics at GDC on March 5th.


    AMD goes on to state that :
    “Open” and “flexible” technologies are an essential piece of AMD’s DNA, and we have a long history in supporting those ideals. Our co-development of the Vulkan API through contributions like Mantle is another chapter in that open technology tale for AMD, an exciting evolution of Mantle, and a big step forward for PC gamers alike.
    AMD states in its recent announcement that this development speaks to the company’s aspiration for Mantle to become an industry-standard graphics API. It’s easy to see now why AMD had outright said two days ago to developers who were interested in Mantle 1.0 functionality to use DX12 and Vulkan instead.
    The lead graphics engineer behind Civilization Joshua Barczak and the lead architect for the Frosbite engine, Johan Andersson both made an astute observation about the name Vulkan.


    Joshua Barczak @JoshuaBarczak
    The word 'Vulkan' is German for 'Volcano'. A 'Volcano' is what happens when the 'Mantle' breaks through the 'Crust'. Well done guys...

    Johan Andersson @repi
    Follow
    @JoshuaBarczak pretty happy with the name it is also volcano in Swedish, Norwegian and Serbian (and probably more)
    San Francisco, CA, United States


    Vulkan embodies the fulfillment of AMD’s promise to stick to its core ideology of openness and support of industry standards. However Robert Hallock, AMD’s head of global technical marketing at AMD made it clear that Vulkan only represents one of multiple outcomes of the API’s evolution. We will get to explore and discover all the other future avenues that AMD has planned for Mantle tomorrow, as they’re announced during the company’s next keynote at GDC.


    http://www.portugal-tech.pt/image.php?type=sigpic&userid=566&dateline=1384876765

  15. #15
    Tech Membro Avatar de MAXLD
    Registo
    Mar 2013
    Local
    C.Branco
    Posts
    2,326
    Likes (Dados)
    0
    Likes (Recebidos)
    0
    Avaliação
    0
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Está a decorrer a apresentação da Khronos no GDC neste momento. Não creio que haja streams, mas vai-se sabendo algumas coisas pelo tweeter.



    @repi é o Johan Andersson da DICE.

 

 
Página 1 de 6 123 ... ÚltimoÚltimo

Informação da Thread

Users Browsing this Thread

Estão neste momento 1 users a ver esta thread. (0 membros e 1 visitantes)

Bookmarks

Regras

  • Você Não Poderá criar novos Tópicos
  • Você Não Poderá colocar Respostas
  • Você Não Poderá colocar Anexos
  • Você Não Pode Editar os seus Posts
  •