XDC 2024 in Montreal was another fantastic gathering for the Linux Graphics community. It was again a great time to immerse in the world of graphics development, engage in stimulating conversations, and learn from inspiring developers. Many Igalia colleagues and I participated in the conference again, delivering multiple talks about our work on the Linux Graphics stack and also organizing the Display/KMS meeting. This blog post is a detailed report on the Display/KMS meeting held during this XDC edition. Short on Time? Catch the lightning talk summarizing the meeting here (you can even speed up 2x): For a quick written...

Hey everyone! The 2024 Linux Display Next hackfest concluded in May, and its outcomes continue to shape the Linux Display stack. Igalia hosted this year’s event in A Coruña, Spain, bringing together leading experts in the field. Samuel Iglesias and I organized this year’s edition and this blog post summarizes the experience and its fruits. One of the highlights of this year’s hackfest was the wide range of backgrounds represented by our 40 participants (both on-site and remotely). Developers and experts from various companies and open-source projects came together to advance the Linux Display ecosystem. You can find the list...

We’re excited to announce the details of our upcoming 2024 Linux Display Next Hackfest in the beautiful city of A Coruña, Spain! This year’s hackfest will be hosted by Igalia and will take place from May 14th to 16th. It will be a gathering of minds from a diverse range of companies and open source projects, all coming together to share, learn, and collaborate outside the traditional conference format. Who’s Joining the Fun? We’re excited to welcome participants from various backgrounds, including: GPU hardware vendors; Linux distributions; Linux desktop environments and compositors; Color experts, researchers and enthusiasts; This diverse mix...

Igalia is preparing the 2024 Linux Display Next Hackfest and we are thrilled to announce that this year’s hackfest will take place from May 14th to 16th at our HQ in A Coruña, Spain. This unconference-style event aims to bring together the most relevant players in the Linux display community to tackle current challenges and chart the future of the display stack. Key goals for the hackfest include: Releasing the power of collaboration: We’ll work to remove bottlenecks and pave the way for smoother, more performant displays. Problem-solving powerhouse: Brainstorming sessions and collaborative coding will target issues like HDR, color...

Last week marked a major milestone for me: the AMD driver-specific color management properties reached the upstream linux-next! And to celebrate, I’m happy to share the slides notes from my 2023 XDC talk, “The Rainbow Treasure Map” along with the individual recording that just dropped last week on youtube – talk about happy coincidences! Steam Deck Rainbow: Treasure Map & Magic Frogs While I may be bubbly and chatty in everyday life, the stage isn’t exactly my comfort zone (hallway talks are more my speed). But the journey of developing the AMD color management properties was so full of discoveries...

A self-help guide for examining and debugging the AMD display driver within the Linux kernel/DRM subsystem. It’s based on my experience as an external developer working on the driver, and are shared with the goal of helping others navigate the driver code. Acknowledgments: These tips were gathered thanks to the countless help received from AMD developers during the driver development process. The list below was obtained by examining open source code, reviewing public documentation, playing with tools, asking in public forums and also with the help of my former GSoC mentor, Rodrigo Siqueira. Pre-Debugging Steps: Before diving into an issue,...

TL;DR: This blog post explores the color capabilities of AMD hardware and how they are exposed to userspace through driver-specific properties. It discusses the different color blocks in the AMD Display Core Next (DCN) pipeline and their capabilities, such as predefined transfer functions, 1D and 3D lookup tables (LUTs), and color transformation matrices (CTMs). It also highlights the differences in AMD HW blocks for pre and post-blending adjustments, and how these differences are reflected in the available driver-specific properties. Overall, this blog post provides a comprehensive overview of the color capabilities of AMD hardware and how they can be controlled...

TL;DR: Color is a visual perception. Human eyes can detect a broader range of colors than any devices in the graphics chain. Since each device can generate, capture or reproduce a specific subset of colors and tones, color management controls color conversion and calibration across devices to ensure a more consistent color reproduction. We can expose a GPU-accelerated display color management pipeline to support this process and enhance results, and this is what we are doing on Linux to improve color management on Gamescope/SteamDeck. Even with the challenges of being external developers, we have been working on mapping AMD GPU...

Hey, If you enjoy using upstream Linux kernel in your Raspberry Pi system or just want to give a try in the freshest kernel graphics drivers there, the good news is that now you can compile and boot the V3D driver from the mainline in your Raspberry Pi 4. Thanks to the work of Stefan, Peter and Nicolas [1] [2], the V3D enablement reached the Linux kernel mainline. That means hacking and using new features available in the upstream V3D driver directly from the source. However, even for those used to compiling and installing a custom kernel in the Raspberry...

In the previous post, I described how we enable multiple syncobjs capabilities in the V3D kernel driver. Now I will tell you what was changed on the userspace side, where we reworked the V3DV sync mechanisms to use Vulkan multiple wait and signal semaphores directly. This change represents greater adherence to the Vulkan submission framework. I was not used to Vulkan concepts and the V3DV driver. Fortunately, I counted on the guidance of the Igalia’s Graphics team, mainly Iago Toral (thanks!), to understand the Vulkan Graphics Pipeline, sync scopes, and submission order. Therefore, we changed the original V3DV implementation for...

As you may already know, we at Igalia have been working on several improvements to the 3D rendering drivers of Broadcom Videocore GPU, found in Raspberry Pi 4 devices. One of our recent works focused on improving V3D(V) drivers adherence to Vulkan submission and synchronization framework. We had to cross various layers from the Linux Graphics stack to add support for multiple syncobjs to V3D(V), from the Linux/DRM kernel to the Vulkan driver. We have delivered bug fixes, a generic gate to extend job submission interfaces, and a more direct sync mapping of the Vulkan framework. These changes did not...

Hi! I haven’t said Hi for a while when starting a post. I think the rush and the whirlwind of things happening during the GSoC made me a little agitated. This year, my project was the only one accepted for X.Org Foundation, and I felt a great responsibility. Well, this is the last week of the project, and I’m slowing down and breathing :) This report is a summary of my journey at Google Summer of Code 2020. Experience and technical reports can be read in more detail in the 11 blog posts I published during this period: Date Post...

I recently posted about a feature I developed for VKMS to consider the alpha channel in the composition of the cursor plane with the primary plane. This process took a little longer than expected, and now I can identify a few reasons: Beginner: I had little knowledge of computer graphics and its operations Maybe cliché: I did not consider that in the subsystem itself, there was already material to aid coding. The unexpected: the test cases that checked the composition of a cursor considering the alpha channel were successful, even with a defect in the implementation. IGT GPU Tools has...

As a newbie, I consider debugging as a study guided. During the process, I have a goal that leads me to browse the code, raise and down various suspicions, look at the changes history and perhaps relate changes from other parts of the kernel to the current problem. Co-debugging is even more interesting. Approaches are discussed, we open our mind to more possibilities, refine solutions and share knowledges… in addition to preventing any uncomplete solution. Debugging the operation of vkms when composing plans was a very interesting journey. All the shared ideas was so dynamic and open that, at the...

In the past few weeks, I was examining two issues on vkms: development of writeback support and alpha blending. I try to keep activities in parallel so that one can recover me from any tiredness from the other :P Alpha blending is a TODO[1] of the VKMS that possibly could solve the warning[2] triggered in the cursor-alpha-transparent testcase. And, you know, if you still have a warning, you still have work. Blend - blend value at vaddr_src with value at vaddr_dst * TODO: Use the alpha value to blend vaddr_src with vaddr_dst * instead of overwriting it. WARNING: Suspicious CRC:...

After a long debugging process, we finally reached an acceptable solution to the problem of running sequential subtests of IGT tests involving CRC capture using the VKMS. Despite all the time, uncertainty, and failures, this was, by far, one of the greatest lessons learned in my journey of FLOSS developer. With this experience, I learned a lot about how VKMS works, evolved technically, experienced different feelings, and interacted with people I may never meet in person. These people were sharing some of their knowledge with me in open and accessible communication. The interactions allowed us to build together a more...

In March, I inspected the coverage of kms_cursor_crc on VKMS to develop my GSoC project proposal. Using piglit, I present the evolution of this coverage so far: Result GSoC start Only accepted patches Fixes under development pass 7 22 24 warn 1 0 1 fail 2 3 0 skip 236 221 221 crash 0 0 0 timeout 0 0 0 incomplete 0 0 0 dmesg-warn 0 0 0 dmesg-fail 0 0 0 changes 0 0 0 fixes 0 0 0 regressions 0 0 0 total 246 246 246 + Instability in the sequential run of subtests; ie, although the statistic...

The first round just passed so fast, and what I did? The case: the IGT test kms_cursor_crc Being acquainted with a IGT test Anatomy of the test What: study, read the code, dive into each function, and describe its structure, steps, and functionality. To: be well aware of the code construction and, consequently, able to figure out and deal with problems. Patches to improve test documentation What: During the study of the kms_cursor_crc test, I realized that the subtests had no description that would help a newcomer to perceive the purpose of that subtest. To improve this documentation and some...

I spent the last week investigating the cause of two problems between VKMS and IGT that I have faced and reported in the development phase of my GSoC project proposal. One of the issues was a weird behavior, that I described as unstable, in the sequential execution of the kms\ _cursor\ _crc subtests or running the same subtest twice in a row: a subtest that passed in the first run failed in the second and returned to succeed in the third (and so on). At first, it was difficult to determine where was the error because: I had a very...

In this post, I describe the steps involved in the execution of a kms_cursor_crc subtest. In my approach, I chose a subtest (pipe-A-cursor-alpha-transparent) as a target and examined the code from the beginning of the test (igt main) until reaching the target subtest and executing it. This is my zero version. I plan to incrementally expand this document with evaluation/description of the other subtests. I will probably also need to fix some misunderstandings. As described by IGT, kms_cursor_crc Uses the display CRC support to validate cursor plane functionality. The test will position the cursor plane either fully onscreen, partially onscreen,...

As the GSoC coding time officially started this week (01/06/2020), this post is a line between my activities in the period of community bonding and the official development of my project. I used the last month to solve issues in my development environment, improve the tool that supports my development activity (kworflow), and study concepts and implementations related to my GSoC project. Communication Besides e-mail, IRC chat, and Telegram, my mentor (Siqueira) and I are meeting every Wednesday on Jitsi, where we also use tmate for terminal sharing. We also use, together with Trevor, a spreadsheet to schedule tasks, report...

Meanwhile, in GSoC: I took the second week of Community Bonding to make some improvements in my development environment. As I have reported before, I use a QEMU VM to develop kernel contributions. I was initially using an Arch VM for development; however, at the beginning of the year, I reconfigured it to use a Debian VM, since my host is a Debian installation - fewer context changes. In this movement, some ends were loose, and I did some workarounds, well… better round it off. I also use kworkflow (KW) to ease most of the no-coding tasks included in the...

I submitted a project proposal to participate in this year’s Google Summer of Code (GSoC). As I am curious about the DRM subsystem and have already started to work in contributing to it, I was looking for an organization that supports this subsystem. So, I applied to the X.Org foundation and proposed a project to Improve VKMS using IGT GPU Tools. Luckily, in May 4th, I received a e-mail from GSoC announcing that I was accepted! Happy happy happy! Observing a conversation in #dri-devel channel, I realized that my project was the only one accepted on X.Org. WoW! I have...

I finished my last post talking about a patch to fix the XRGB operation in compute crc function (VKMS). [PATCH] drm/vkms: use bitfield op to get xrgb on compute crc I was waiting for the community feedback and I received a review with good suggestions to simplify the solution. Unfortunatelly, despite the correct and useful guidance, the comment was really rude. What is the necessity of someone to give this kind of opinion? This behavior have no benefits, for who send, who receive and for the community. This kind of approach is able to discourage new developers. I know the...

After I began a simple change in the cursor behavior in VKMS, many related issues started to appear. My initial task seemed simple, sending a proposal to enable cursor by default when loading the vkms module. However, I have now spent a lot of time untangling issues that troubled me to validate that change. This initial task arose after I have asked on the dri-devel IRC channel for suggestions to contribute to VKMS because I am interested in participating in this year’s Google internship program (GSoC). As VKMS’s mentor is Rodrigo Siqueira, he suggested this warm-up task. Each day, I...

In this post, I talk a little about my first steps to introduce myself to the DRM community, a Linux subsystem from which I am looking to learn more and develop skills. In my opinion, sending contributions is the best way to start to fit in. We can also send questions or interact about an idea, but as nobody knows you there, showing your potential and your interest in practice leads to a more fluid relationship. Well, I can say that a safe way to start contributing code to a subsystem of which we are little acquainted is by sending...

Hello again! I’m moving. I mean, I’m moving to another subsystem. As a new step in my journey to develop Linux development skills, I will start contributing to DRM. To start this process, I asked Siqueira for advice about the first steps. We are now geographically distant, me in Portugal and he in Canada, so sometimes it is not very simple to match time to stablish some conversation since we are five hours apart and he is working full-time. Since the USP time, Siqueira is always a guy willing to learn, teach and also pass on knowledge. This knowledge transfer...

2019 was a year of deepening and maturing my MSc research on FLOSS. It was also a year of introduction to the universe of contributions to the kernel Linux. I had my first achievements as a newcomer to the community. I sent eight patches to the IIO, the first one was a code-style contribution, but in the others, I made some improvements for an IIO driver that was (and still is) in the staging tree. These patches helped me to understand a little of the logic and complexity involved in Linux kernel development. I believe one of the patches that...

The year is coming to an end, and although it was a year of new experiences in the FLOSS community, I have shared little about this new universe that I am still beginning to know and understand. I have always worked with free technologies in different contexts. Not only do I use GNU / Linux since my college days, but after having graduated, I worked sometimes using free technologies to create service solutions, sometimes directly developing a free software project. So when I decided to do a master’s degree, nothing more expected than opting for the FLOSS universe for my...

In my time of contribution to IIO, I had some fun and learning situations. These things probably happen frequently to newcomers, but as common as they are, you are many times unprepared for them. “HTML mail is not permitted on the Linux Kernel Mailing List” I always send patches using neomutt (again, Siqueira has well-made setup files for neomutt here: https://github.com/rodrigosiqueira/myConfigFiles/tree/master/roles/neomutt/files/mutt). I find the neomutt a cleaner and more efficient mail client to format patches with all the necessary information. Moreover, it provides a second chance to revise the code and messages before sending it. It also helps the developer...

I’ve already started my contribution journey. However, I forgot to write about it earlier. In this post, I present my memories of this previous phase: (1) Before being in person with the FLUSP group, my attempts to understand the Linux project flow and how to start to contribute; (2) Developing initial skills with support from FLUSP (people and materials); (3) Sending my first path; Activities before FLUSP Because I was not at USP, I have remotely started to set my development environment. To this, I follow instructions of Rodrigo Siqueira (the most experient Linux developer of my study laboratory) via...