Language Selection

English French German Italian Portuguese Spanish

Graphics: CoreAVI, X.Org Server 1.20.7, Wayland Adds Meson Build System Support

Filed under
Graphics/Benchmarks
  • CoreAVI Achieves Formal Khronos OpenGL SC 1.0.1 Compliance Running its VkCoreGL SC1 Library

    Core Avionics & Industrial Inc. (“CoreAVI”) announced today that it has achieved formal Khronos Group compliance for its VkCoreGL™ SC1 (OpenGL SC 1.0.1) application library running on its Vulkan-based VkCore™ SC graphics and compute driver. Successful passing Khronos’ conformance testing process ensures implementation quality and provides implementor protection via the Khronos Intellectual Property Framework.Adhering to open software standards is a key part of CoreAVI’s philosophy and this compliance provides customers with the standards-based confidence they require for safety critical software products. CoreAVI is the chair of Khronos’ Vulkan Safety Critical Working Group to define a formal safety critical version of Vulkan and is continually focused on driving forward new standards to support true safety critical compute capabilities using graphics processors.

  • CoreAVI VkCoreGL SC1 Hits Compliance For Ushering Vulkan Into Safety Critical Systems

    Vulkan could soon be used indirectly on safety critical military and aerospace displays thanks to CoreAVI's VkCoreGL SC1.

    While there is a Vulkan safety-critical working group with aims similar to OpenGL SC, at the moment there is no released Vulkan SC specification. But Military and aerospace supplier CoreAVI (who is also involved in the Vulkan SC effort) has developed VkCoreGL SC1 as an OpenGL SC library running on top of Vulkan.

    VkCoreGL SC1 is for transitioning OpenGL safety critical applications onto Vulkan-based systems. VkCoreGL SC1 is similar to Mesa's Zink and the other projects implementing OpenGL over Vulkan but with CoreAVI's commercial offering they are implementing the OpenGL safety critical specification. As of today, they are now formally deemed in compliance with OpenGL SC 1.0.1.

  • xorg-server 1.20.7
    A variety of bugfixes, primarily in modesetting, glamor, and Solaris
    support. This release also contains support for choosing the DRI driver
    via EGL_MESA_query_driver. Thanks to all who contributed with testing
    and fixes!
    
    Aaron Plattner (1):
          modesetting: Check whether RandR was initialized before calling rrGetScrPriv
    
    Alan Coopersmith (5):
          os-support/solaris: Drop ExtendedEnabled global variable
          Add ddxInputThread call from os layer into ddx layer
          Add xf86OSInputThreadInit call from common layer into os-support layer
          os-support/solaris: Set IOPL for input thread too
          ospoll: Fix Solaris ports implementation to build on Solaris 11.4
    
    Kenneth Graunke (2):
          glamor: Add a function to get the driver name via EGL_MESA_query_driver
          modesetting: Use EGL_MESA_query_driver to select DRI driver if possible
    
    Matt Turner (1):
          xserver 1.20.7
    
    Michel Dänzer (5):
          modesetting: Call glamor_finish from drmmode_crtc_set_mode
          xfree86/modes: Call xf86RotateRedisplay from xf86CrtcRotate
          modesetting: Clear new screen pixmap storage on RandR resize
          xwayland: Do flush GPU work in xwl_present_flush
          glamor: Only use dual blending with GLSL >= 1.30
    
    Peter Hutterer (1):
          Xi: return AlreadyGrabbed for key grabs > 255
    
    git tag: xorg-server-1.20.7
    
  • X.Org Server 1.20.7 Released With A Handful Of Fixes For GLAMOR + Modesetting

    With no sign of X.Org Server 1.21 on the horizon, the X.Org Server 1.20 point releases continue rolling on.

    Intel Linux graphics developer Matt Turner stepped up to release X.Org Server 1.20.7 as the latest point release, consisting of fourteen changes. The changes are mostly centered on the GLAMOR and xf86-video-modesetting driver bits but also some Solaris updates via Oracle's Alan Coopersmith.

    NVIDIA's Aaron Plattner added a check to the xf86-video-modesetting DDX around verifying RandR initialization, Intel's Kenneth Graunke now has the modesetting driver using EGL_MESA_query_driver to select the DRI driver if possible (needed for their Iris driver), and a few other modesetting fixes are in there too. Graunke also added a change to GLAMOR for querying the driver name as well via EGL_MESA_query_driver, again, good news for their Iris Gallium3D driver.

  • Wayland Adds Meson Build System Support

    While Wayland's Weston reference compositor has been using the Meson build system for about the past year, only this week did Wayland itself see Meson support introduced.

    Wayland has added Meson build system support for the same reasons most projects do: faster build times, cleaner than GNU Autotools, and tends to work better on other platforms especially with Windows.

    GNOME's Emmanuele Bassi added the support. For now the Meson build system support is living alongside the Autotools support. The plan is to drop Autotools once the Meson support has proven to be at least on-par with the existing build system support.

More in Tux Machines

Raspberry Pi 4 V3D Driver Reaches OpenGL ES 3.1 Conformance

  • Raspberry Pi 4 V3D Driver Reaches OpenGL ES 3.1 Conformance

    The V3D Gallium3D driver that most notably offers the open-source graphics support for the Raspberry Pi 4 is now an official OpenGL ES 3.1 implementation. Consulting firm Igalia has continued working on the V3D driver since Eric Anholt left Broadcom. Igalia had ironed out OpenGL ES 3.1 support and last month also went on to begin tackling geometry shaders and more.

  • Iago Toral: I am working on the Raspberry Pi 4 Mesa V3D driver

    Yeah… this blog post is well overdue, but better late than never! So yes, I am currently working on progressing the Raspberry Pi 4 Mesa driver stack, together with my Igalian colleagues Piñeiro and Chema, continuing the fantastic work started by Eric Anholt on the Mesa V3D driver. The Raspberry Pi 4 sports a Video Core VI GPU that is capable of OpenGL ES 3.2, so it is a big update from the Raspberry Pi 3, which could only do OpenGL ES 2.0. Another big change with the Raspberry Pi 4 is that the Mesa v3d driver is the driver used by default with Raspbian. Because both GPUs are quite different, Eric had to write an all new driver for the Raspberry Pi 4, and that is why there are two drivers in Mesa: the VC4 driver is for the Raspberry Pi 3, while the V3D driver targets the Raspberry Pi 4.

  • Raspberry Pi 4 V3D driver gets Geometry Shaders

    I actually landed this in Mesa back in December but never got to announce it anywhere. The implementation passes all the tests available in the Khronos Conformance Tests Suite (CTS). If you give this a try and find any bugs, please report them here with the V3D tag.

  • Raspberry Pi 4 V3D driver gets OpenGL ES 3.1 conformance

    So continuing with the news, here is a fairly recent one: as the tile states, I am happy to announce that the Raspberry Pi 4 is now an OpenGL ES 3.1 conformant product!. This means that the Mesa V3D driver has successfully passed a whole lot of tests designed to validate the OpenGL ES 3.1 feature set, which should be a good sign of driver quality and correctness. It should be noted that the Raspberry Pi 4 shipped with a V3D driver exposing OpenGL ES 3.0, so this also means that on top of all the bugfixes that we implemented for conformance, the driver has also gained new functionality! Particularly, we merged Eric’s previous work to enable Compute Shaders.

today's howtos

Software tips for nerds

I use Vim for almost a decade now, which is probably the longest I’ve sticked to some application. During that time, I repeatedly tried to use it as an IDE but inevitably failed each time. Let’s remember eclim as my Java IDE. I work almost exclusively on projects written in Python, which can be beautifully done in Vim but because of a gap in my skills, I was reliant on PyCharm. Thankfully, not anymore. My biggest issue was misusing tabs instead of buffers and poor navigation within projects. Reality check, do you open one file per tab? This is a common practice in other text editors, but please know that this is not the purpose of tabs in Vim and you should be using buffers instead. Please, give them a chance and read Buffers, buffers, buffers. Regarding project navigation, have you ever tried shift shift search in PyCharm or other JetBrains IDE? It’s exactly that thing, that you wouldn’t even imagine but after using it for the first time, you don’t understand how you lived without. What it does is, that it interactively fuzzy-finds files and tags (classes, functions, etc) that matches your input, so you can easily open them. In my opinion, this unquestionably defeats any other way of project navigation like using a file manager, NerdTree, or find in the command line. Fortunately, both of these problems can be solved by fzf.vim, which quickly became one of my most favorite Vim plugins. Please read this section about fzf plugin. I am forever grateful to Ian Langworth for writing VIM AFTER 11 YEARS, EVERYTHING I MISSED IN “VIM AFTER 11 YEARS” and VIM AFTER 15 YEARS articles. If you are a Vim user, those are an absolute must-read. Read more

today's howtos