Schlagwort: graphics

  • Vulkan update: we’re conformant!

    Vulkan update: we’re conformant!

    Reading Time: 2 minutes

    Today we have a guest post from Igalia’s Iago Toral, who has spent the past year working on the Mesa graphic driver stack for Raspberry Pi 4.

    It’s been nearly a year since we first announced that we were developing a Vulkan driver for the latest generation of Raspberry Pi devices (Raspberry Pi 4, Raspberry Pi 400, and Compute Module 4).

    Sascha Willems’ Vulkan radial blur demo

    In June we released the source code for our prototype driver, and last month we announced that the driver had been successfully merged to Mesa upstream.

    Today we have some very exciting news to share: as of 24 November the V3DV Vulkan Mesa driver for Raspberry Pi 4 has demonstrated Vulkan 1.0 conformance.

    Khronos describes the conformance process as a way to ensure that its standards are consistently implemented by multiple vendors, so as to create a reliable platform for application developers. For each standard, Khronos provides a large conformance test suite (CTS) that implementations must pass successfully to be declared conformant; in the case of Vulkan 1.0, the CTS contains over 100,000 tests.

    Vulkan 1.0 conformance is a major milestone in bringing Vulkan to Raspberry Pi, but it isn’t the end of the journey. Our team continues to work on all fronts to expand the Vulkan feature set, improve performance, and fix bugs. So stay tuned for future Vulkan updates!

    Website: LINK

  • Vulkan update: merged to Mesa

    Vulkan update: merged to Mesa

    Reading Time: 2 minutes

    Today we have another guest post from Igalia’s Iago Toral, who has spent the past year working on the Mesa graphic driver stack for Raspberry Pi 4.

    Four months ago we announced that work on the Vulkan effort for Raspberry Pi 4 (v3dv) was progressing well, and that we were moving the development to an open repository.

    vkQuake3 on Raspberry Pi 4

    This week, the Vulkan driver for Raspberry Pi 4 has been merged with Mesa upstream, becoming one of the official Vulkan Mesa drivers. This brings several advantages:

    • Easier to find: now anyone willing to test the driver just needs to go to the official Mesa repository
    • Bug tracking: issues/bugs can now be filed on the official Mesa repository bug tracker. If the problem affects other parts of the project, it will be easier for us to involve other Mesa developers.
    • Releasing: v3dv will be included in all Mesa releases. In due course, you will no longer need to go to an external repository to obtain the driver, as it will be included in the Mesa package for your distribution.
    • Maintenance: v3dv will be included in the Mesa Continuous Integration system, so every merge request will be tested to ensure that our driver still builds. More effort can go to new features and bug fixes rather than just keeping up with upstream changes.

    Progress, and current status

    We said back in June that we were passing over 70,000 tests from the Khronos Conformance Test Suite for Vulkan 1.0, and that we had an implementation for a significant subset of the Vulkan 1.0 API. Now we are passing over 100,000 tests, and have implemented the full Vulkan 1.0 API. Only a handful of CTS tests remain to be fixed.

    Sascha Willems’ deferred multisampling demo

    This doesn’t mean that our work is done, of course. Although the CTS is a really complete test suite, it is not the same as a real use case. As mentioned some of our updates, we have been testing the driver with Vulkan ports of the original Quake trilogy, but deeper and more detailed testing is needed. So the next step will be to test the driver with more use cases, and fixing any bugs or performance issues that we find during the process.

    Website: LINK

  • Design game graphics with Digital Making at Home

    Design game graphics with Digital Making at Home

    Reading Time: < 1 minute

    [youtube https://www.youtube.com/watch?v=ehpeIuMlfvc?feature=oembed&w=500&h=281]

    Join us for Digital Making at Home: this week, young people can explore the graphics side of video game design! Through Digital Making at Home, we invite kids all over the world to code along with us and our new videos every week.

    So get ready to design video game graphics with us:

    Check out this week’s code-along projects!

    And tune in on Wednesday 2pm BST / 9am EDT / 7.30pm IST at rpf.io/home to code along with our live stream session to make a Space Invaders–style shooter game in Scratch!

    Website: LINK

  • Vulkan update: now with added source code

    Vulkan update: now with added source code

    Reading Time: 4 minutes

    Today we have a guest post from Igalia’s Iago Toral, who has spent the past year working on the Mesa graphic driver stack for Raspberry Pi 4.

    It is almost five months since we announced the Vulkan effort for Raspberry Pi 4. It was great to see how many people were excited about this, and today we would like to give you a status update on our progress over these last months.

    When we announced the effort back in January we were at the point of rendering a coloured triangle, which required only minimal coverage of the Vulkan 1.0 API in the driver. Today, we are passing over 70,000 tests from the Khronos Conformance Test Suite for Vulkan 1.0 and we have an implementation for a significant subset of the Vulkan 1.0 API.

    Progress so far, in pictures

    While I could detail here all the features that we have implemented, I am sure that list would get long and boring very quickly for most of you. So, instead, we would like to show you our progress through pics taken from a bunch of the popular Vulkan demos by Sascha Willems running on Raspberry Pi 4:

    Hopefully that is more entertaining than a feature checklist and will help you visualize better where we are now compared to January’s coloured triangle.

    Before you get too excited though, while these demos are nice, they are still a far cry from actual games and applications. We still have a lot of work to do before the driver can handle these more complex workloads. Even some of Sascha’s demos don’t run yet, whether because of driver bugs or unimplemented Vulkan features. We still have a lot of work ahead of us.

    Next up

    I would also like to give you an overview of some of the things we will be working on in the coming months:

    Our first priority is to support the basic Vulkan 1.0 feature set. This will involve, at least, supporting compute shaders, input attachments, texel buffers, storage images, pipeline caches, and multisampling. There are some other features that we need to support in Vulkan 1.0, such as robust buffer access etc, but those are probably the largest ones we are currently missing.

    Once we are feature-complete we will probably move focus to CTS conformance, which will be all about bugfixing, and making sure we handle spec corner cases. And once we are close to conformance, the driver should hopefully be stable and robust enough that we should probably start testing actual Vulkan applications and games to drive further bugfixing work.

    Finally, there will be a lot of performance tuning and optimization work that we will probably tackle in the last stages of development.

    So as I said before, we still have a long way to go!

    Moving development to an open repository

    Before we end this post, I would also like to share another important piece of news: starting today, we are moving development of the driver to an open repository. You can find instructions on how to build and install the driver here. I know this is something that many of you have been asking for, and I am sorry that it took us a few months to get here. But I think that now that we have a more stable driver infrastructure in place, and we don’t feel like we are constantly making large changes every other day, development should be a lot friendlier to external contributors than it may have been a few months ago.

    So that’s everything we wanted to share today – I hope you are still excited about Vulkan and looking forward to future updates. In the meantime, if you have questions or are interested in contributing to the driver, join us on irc.freenode.net, #videocore channel.

    Website: LINK

  • Vulkan is coming to Raspberry Pi: first triangle

    Vulkan is coming to Raspberry Pi: first triangle

    Reading Time: 2 minutes

    Following on from our recent announcement that Raspberry Pi 4 is OpenGL ES 3.1 conformant, we have some more news to share on the graphics front. We have started work on a much requested feature: an open-source Vulkan driver!

    Vulkan

    Standards body Khronos describes Vulkan as “a new generation graphics and compute API that provides high-efficiency, cross-platform access to modern GPUs”. The Vulkan API has been designed to better accommodate modern GPUs and address common performance bottlenecks in OpenGL, providing graphics developers with new means to squeeze the best performance out of the hardware.

    First triangle

    The “first triangle” image is something of a VideoCore graphics tradition: while I arrived at Broadcom too late to witness the VideoCore III version, I still remember the first time James and Gary were able to get a flawless, single-tile, RGB triangle out of VideoCore IV in simulation. So, without further ado, here’s the VideoCore VI Vulkan version.

    First triangle out of Vulkan

    Before you get too excited, remember that this is just the start of the development process for Vulkan on Raspberry Pi. While there have been community efforts in the direction of Vulkan support (originally on VideoCore IV) as far back as 2018, Igalia has only been working on this new driver for a few weeks, and we still have a very long development roadmap ahead of us before we can put an actual driver in the hands of our users. So don’t hold your breath, and instead look forward to more news from us and Igalia as they make further development progress.

    Website: LINK

  • Historical high-resolution graphics on Raspberry Pi

    Historical high-resolution graphics on Raspberry Pi

    Reading Time: 3 minutes

    Raspberry Pi Trading engineer James Hughes recently pointed out a project to us that he’d found on the Raspberry Pi forum. Using a Raspberry Pi, forum member Rene Richarz has written a Tektronix 4010, 4013, 4014, 4015, and ARDS terminal emulator. The project sounded cool, but Helen and I didn’t 100% get it, so we asked James to write an introduction for us. You can find that below, followed by the project itself. James’s intro is amazing, because, despite this heat messing with my concentration, I understand the project now! That James – what a treasure. And here he is:

    Those of a certain age will remember the vector graphics display of arcade games like Battlezone and Asteroids, and the subsequent colour displays of Star Wars and Tempest. Even earlier than these games came the less sophisticated Tektronic storage tube terminals used by the pioneers of computer graphics, combined with the PDP-11s and Vax’s that were the staple of computer graphics labs of the era.

    Unlike the raster displays that everyone uses now, these terminals used a steerable electron beam (the ‘write gun’) to draw lines directly on the phosphor of the monitor, which were kept illuminated by a secondary ‘flood gun’. These devices had very high resolution, up to 1024×1024 pixels, but the big problem was that you could not erase just a bit of the display — you had to erase the whole image!

    Rene Richarz’s project emulates these fascinating old displays, even down to the speed of drawing: because the display needed to be charged, the electron gun could only travel at a limited speed of 1500–4000 vector inches/second!

    Once memory prices started dropping, the cost of raster displays also dropped significantly, meaning these early computer graphics vector displays were consigned to the annals of history. But their memory lives on, not only in the project we see here but in many of the algorithms and techniques developed in those early years that are still used today.

    PiDP-11 with tek4010 Tektronix 4014 emulator

    This video shows the blinking PiDP-11 (https://obsolescence.wixsite.com/obsolescence) running the historical 2.11 BSD Unix (https://github.com/rricharz/pidp11-2.11bsd) with the Tektronix 4014 emulator tek4010 (https://github.com/rricharz/Tek4010). Late 1970s Blinkenlight action and storage tube display action.

    As Rene explains on the GitHub repo, his project “makes an effort to emulate the storage tube display of the Tektronix 4010, including the bright drawing spot. It can be used to log into a historical Unix system such as 2.11 BSD on the PiDP-11 or a real historical system. It can also be used to display historical plot data.”

    You can see more information on the project, and join in the community discussion, on our forum, and find all the relevant code and instructions for creating your own on GitHub. And if you’d like a primer on how the bistable storage CRTs that Rene is emulating work, you could do worse than take a look at how Tektronix explained it to their customers in the July 1972 issue of Tekscope magazine.

    We’ll close with this underappreciated reflection on the virtues of vector displays:

    Yes raster is faster, but raster is vaster, and vector just seems more correcter.
    Reproduced from old.carto.net; attributed to Dana Tomlin, 1990

    Website: LINK