Chaos Computer Club - archive feed

At Swedish universities, students organize in clubs for spare time activities like photography, sports, music and also computers! Update is the student computer club loosely connected to Uppsala University. We started out in 1983 around what was then new shiny computers and have evolved into a caretaker of the old and precious. We have kept the very DECSYSTEM 2060 around which the club was formed as well as a VAX 8650, PDP-12, a running PDP-11/70 and many other things. The club is creeping up on its 40th birthday and we would like to present a retrospective with anecdotes and trivia. The future is uncertain as the university department paying for our rooms is moving and will no longer be able to accomodate Update. What will the next chapter for this old club be? And how can you help us? about this event: https://c3voc.de

Konrad Zuse wird heute weltweit als Konstrukteur und Erbauer des ersten Computers anerkannt. Am 12. Mai 1941 stellte er einer Delegation der DVL, also quasi der wissenschaftlichen Öffentlichkeit, seine funktioniernde Z3 vor. Die Vorgängerin, die mechanisch arbeitende Z1 von 1938, die noch nicht zuverlässig funktioniert hatte, war im Krieg zerstört worden. Zuse konnte sie nicht der Öffentlichkeit vorführen und also nicht beweisen, dass sie wenigstens prinzipiell funktioniert hatte. Im Jahr 1986 begann Konrad Zuse mit der Rekonstruktion der Z1 um quasi den Nachweis zu erbringen, dass die Z1 funktioniert haben könnte. Es wird kolportiert, dass Zuse die Rekonstruktion rein aus der Erinnerung durchführte. Dieses stimmt so nicht. In dem Österreichischen Patent 176686 von 1949 werden die Details der Z1 auf 188 Seiten mit sehr vielen Zeichnungen und Bildern beschrieben. Interessanterweise taucht dieses Patent in den Quellenangaben der bekannten Literatur von und über Konrad Zuse nicht auf. In dem Vortrag soll versucht werden, die Funktion des Zahlenspeichers der Z1 und des Rechenwerkes mit den Zeichnungen und Diagrammen aus diesem Patent zu erklären. about this event: https://c3voc.de

Die online Ausstellenden geben eine kurze Präsentation ihrer Ausstellung, geführt durch eine Moderation. about this event: https://c3voc.de

Bubble memory was a hot technology in the 1970s that was expected to replace both RAM and mass storage. At the beginning of the 1980s it was clear that it was made obsolete by faster RAM chips and cheaper HDDs. Still, this technology made it into a few computers in the early 1980s. The earliest of these computers is the Fujitsu Micro 8, a quite advanced home computer from 1981. We have a look at this model and its quirky (optional) bubble memory drive. about this event: https://c3voc.de

Zwischen 2012 und 2020 wurde im Signallabor der Medienwissenschaft an der HU Berlin ein Forschungsprojekt zur Archäologie der frühen Mikrocomputer und ihrer Programmierung durchgeführt, das als Promotion in der Informatik letztes Jahr abgeschlossen wurde. Pünktlich zum VCFB erscheint nun das Buch zum Projekt. In meinem Vortrag werde ich Projekt und Buch vorstellen, ein paar Beispiele der Retrocomputing-Experimente beschreiben/zeigen und Anekdoten aus der Forschungspraxis mit Studierenden der Medienwissenschaft berichten. about this event: https://c3voc.de

Die vor Ort im Pergamon-Palais Ausstellenden geben eine kurze Präsentation ihrer Ausstellung, geführt durch eine Moderation. about this event: https://c3voc.de

Begrüßung, Hinweise zum Ablauf. about this event: https://c3voc.de

Drucken, Kuli, einscannen? Danke ... PDF ausfüllen, editieren! Hier zeige ich in zwei Hauptgängen, wie Jedermann ganz simpel PDF-Dateien editieren, ausfüllen und anpassen kann. Kostet nichts extra und sieht schmackhaft aus: Professionelle Ergebnisse mit einfachen Zutaten. CLI als Dessert: PDF drehen, ausdünnen, zusammenstellen, kombinieren mit 'pdftk' auf der Command-Line - alles ganz simpel gehalten. about this event: https://www.chaospott.de

In diesem Petit Foo zeigen wir wie man mit Schneidplotter und Bügelpresse Textilien wie T-Shirts, Hoodies oder Masken verzieren kann. about this event: https://www.chaospott.de

Was denken Leute über die Chaos Post? Ein Film der Chaos Post für die 40 Jahre Jubiläumsshow des CCC. about this event: https://www.chaospott.de

about this event: https://c3voc.de

Das “Bullet Journal” ist eine Mischung aus Todo-Liste, Gedankensammlung und Tagebuch in Stichwortform. Sucht man im Netz nach dem Schlagwort, findet man sehr viele Beispiele, die grafisch sehr ansprechend, aber auch sehr zeitaufwändig gestaltet sind. “Ich kann aber gar nicht malen” ist dann bei vielen die Reaktion. Der Vortrag widmet sich dem Bullet Journaling “ohne Blümchen”, also den wesentlichen Ideen dahinter. Es geht um persönliche Erfahrungen von 18 Monaten Bullet Journaling - und die reichen von der Adaption der Idee über die persönlichen Nöte während der Pandemie bis hin zur Entdeckung des “schönen Werkzeugs” beim Schreiben. All das mit dem Vorbehalt, dass es nicht das eine Bullet Journal gibt, sondern es eine Anregung sein soll, sich aus dem Baukasten an Ideen zu bedienen und es vielleicht selbst einmal zu versuchen. about this event: https://www.cccs.de/events/202109-bullet-journaling/

Closing Datenspuren about this event: https://talks.datenspuren.de/ds21/talk/VGRVVU/

Glühbirnen hacken, Tasmota in Smartbulbs nachrüsten, Wasserkocher und Steckdosen befreien. Glühbirnen hacken, Tasmota in Smartbulbs nachrüsten, Wasserkocher und Steckdosen befreien. about this event: https://talks.datenspuren.de/ds21/talk/PXJRXG/

Dieser Talk gibt einen Überblick über E2E-Verschlüsselung und stellt einen spannenden Ansatz vor. Oft ist unklar wer die Schlüssel zum Entschlüsseln vertraulicher Nachrichten besitzt. In diesem Talk werden jene fündig, die eher sich selbst vertrauen und eigene Schlüssen generieren. Jedoch der Clou dahinter ist die „Perfekte Sicherheit“. about this event: https://talks.datenspuren.de/ds21/talk/QKYFTX/

A basic encoding standard for content-addressed data. http://purl.org/eris ERIS is an encoding standard for content-addressed data. ERIS is intended for use in semantic web components as well as a for archiving bulk data. This talk will feature an brief popular history of content-addressing schemes, its problems, and why a basic standard such as ERIS is useful. There will be an explanation of ERIS, its cost and benefits, and its privacy and security implications. Following that are some hypothetical use-cases and demos. about this event: https://talks.datenspuren.de/ds21/talk/9XAG8W/

Nach der Pandemie haben Datenschützer es noch schwerer. Oder? Die Pandemie hat gezeigt, dass zentrale Register und Überwachung ausnahmsweise mal nützlich sein können. Auch Rufe nach Zwang und Überwachung aus bisher unbekannter Richtung wurden vernommen. Dazu muss sich das Chaos verhalten. Denken wir darüber nach. about this event: https://talks.datenspuren.de/ds21/talk/BL7Y7M/

Was ist dieses Fediverse und was soll so toll daran sein? Ein Überblick über das Netzwerk und ein Blick auf seine Besonderheiten, Vorstellung einzelner Dienste und ein kritischer Blick auf die Social Media Landschaft. Der Vortrag ist eine Erweiterung dieses Lightningtalks: https://video.dresden.network/w/fBf47fymjETZmF417pPgNF about this event: https://talks.datenspuren.de/ds21/talk/9LHGED/

Wie führt man ein vertrauliches Gespräch über einen unsicheren Kommunikationskanal? Im Podcast "Schlüsseltechnologie" erklären wir moderne Computertechnik von Grund auf. In dieser Live-Ausgabe soll es um den Diffie-Hellman-Schlüsselaustausch gehen. Dieses zu seiner Zeit revolutionäre Protokoll erlaubt es zwei Gesprächsparteien, ein gemeinsames Geheimnis zu vereinbaren, obwohl auf dem verwendeten Kommunikationskanal jeder mitlesen kann. Ein solches Geheimnis, meist eine strategisch gewählte Zufallszahl, ist dann der Schlüssel für eine vertrauliche Kommunikation zwischen beiden Gesprächspartnern, obwohl der Kanal eigentlich nicht vertrauenswürdig ist. Eine wahrhaftige Schlüsseltechnologie! about this event: https://talks.datenspuren.de/ds21/talk/ZH9SWA/

Erarbeitung eines Katalogs individueller Handlungsempfehlungen für eine nachhaltige Digitalisierung. Die aktuelle Implementierung der Digitalisierung ist dysfunktional: Sie verursacht mehr Probleme, als sie löst. Auf der Konferenz Bits&Bäume 2018 wurden mit Beteiligung u.a. des CCC, des FIfF, des BUND und der OKF [elf konkrete Forderungen](https://bits-und-baeume.org/forderungen/info/de) für eine nachhaltige Digitalisierung formuliert. Sie richten sich primär an Politik und Unternehmen - auf individueller Ebene lassen sie sich kaum (direkt) anwenden. Um diese Lücke zu schließen, soll kollaborativ und multiperspektivisch ein Katalog von individuellen Handlungsempfehlungen erarbeitet werden. Die dabei unvermeidlichen Diskussionen (z.B. “Ist Ecosia aus Datenschutz-Sicht vertretbar?”) werden dabei nicht als lästige sondern als wünschenswerte Begleiterscheinung aufgefasst und (ggf. Tool-gestützt) in Pro- und Kontra-Argumente strukturiert, sodass objektiv gute Vorschläge mit der Zeit möglichst klar erkennbar werden. In einem kurzen Inputvortrag geht es u.a. um die Motivation des Projekts, und um eine mögliche technische Umsetzung zur Strukturierung der Diskussion. Der überwiegende Teil des Workshops wird einem Brainstorming und der inhaltlichen Diskussion zu konkreten Handlungsoptionen gewidmet. Weitere Infos bei https://dresden.bits-und-baeume.org/ about this event: https://talks.datenspuren.de/ds21/talk/PQSDPT/

Ein Vortrag über die Facetten und Nuancen dessen, was das 'Hacker'-sein denn tatsächlich bedeutet. Ein als 'Hacker' bezeichneter Mensch weckt unwillkürlich immer das BIld einer über einem Computermonitor gebeugten Person, welche tagein, tagaus nichts anderes tut, als in besagten Monitor zu schauen und in den virtuellen Eingeweiden des Computers zu werkeln. Dieses Bild entspricht aber nicht der Wirklichkeit. Es gehören auch andere Dinge dazu, um ein 'Hacker' zu sein. In diesem Vortrag bemühe ich mich ein neues BIld zu erschaffen, was es denn heißt ein 'Hacker' zu sein und möchte mit Beispielen aufzeigen, dass es weit mehr sein sollte, als Arbeit und Freizeit am Computer zu verbringen. about this event: https://talks.datenspuren.de/ds21/talk/TDEBBE/

Vorstellung des Open Data Camps 2021 und des Coding da Vinci Kulturhackathons Ost³ 2022 about this event: https://talks.datenspuren.de/ds21/talk/ZEJBSR/

Keynote Keynote about this event: https://talks.datenspuren.de/ds21/talk/788GXF/

Opening der Datenspuren about this event: https://talks.datenspuren.de/ds21/talk/AHVJNX/

Lightning Talks for the 3rd day of the conference: - Rust in Mesa - Conclusions about BVH building with RADV and ANV - ...and more! about this event: https://c3voc.de

Your secretary's yearly report on the state of the X.org Foundation. Expect updates on the freedeskoptop.org, internship and student programs, XDC, and more! about this event: https://c3voc.de

In April of this year, Khronos released a provisional set of extensions: [VK_KHR_video_queue, VK_KHR_video_decoder_queue and VK_KHR_video_encoder_queue](https://www.khronos.org/blog/an-introduction-to-vulkan-video). They all aim for hardware accelerated video decoding and encoder with the Vulkan API. In this talk, we will introduce the basics of video decoding and give an overview of the concepts used to decode video via the new Vulkan extension, using as example the usage of the API in a GStreamer element. The talk will be educational and focus on helping others in the X/Mesa community to understand the new API concepts. about this event: https://c3voc.de

The CPU performance scaling is one of key parts in Linux Kernel, it is to manage the CPU frequency according to kernel and processor status and widely used by many user mode application to talk to the processors. The system information APIs in Wine will use the CPU performance scaling interfaces to manage the multi-core processor schedule timing compatibilities from windows application to Linux environment for VKD3D-Proton (the full Direct3D 12 API on top of Vulkan) on Steam. The original CPU performance scaling module is based on the legacy kernel common ACPI cpufreq driver on AMD processors. We found it was not very performance/power efficiency for modern AMD platforms. So this talk is to introduce a new CPU performance scaling design for AMD platform which has better performance per watt scaling on such as 3D game like Horizon Zero Dawn with VKD3D-Proton on Steam. The idea is inspired by co-working with Valve software guys for tuning animation slow down problem (https://github.com/ValveSoftware/Proton/issues/4125) of VKD3D-Proton on steam. about this event: https://c3voc.de

With Freedesktop's move to Gitlab every project not only got access to a lot of machine time, but they also got all the infrastructure to automate their runs, inspect the results, and provide automated testing reports of merge requests. This has led to a lot of projects adopting it to reduce regressions and maintenance costs to the point of almost bankrupting Freedesktop.org! The only downside of the current testing infrastructure is that it is meant to run in the cloud, not on the GPUs we develop drivers for! Of course, some efforts are underway to make even the DRM subsystem testable in the cloud (VKMS) but if we are to prevent regressions through pre-merge testing, we need at some point to run on the real hardware! Hardware-testing labs do exists, but they rarely seem to happen without a corporation to back them up as only they have the resources to pay for the development of the system interfacing with the hardware, its hosting, and its maintenance. In order to be within the reach of hobbyist projects, we estimate the cost should be limited to $1kUSD, one week-end of hardware set up time, and a couple of evenings of tweaking before reaching stability, and no more than an hour per week of maintenance after that. To reach this goal, we need to make the deployment as easy as assembling plastic bricks, keep maintenance costs down through self-configuration/healing, and running Gitlab CI jobs in the farm as easy as inheriting from a CI template and setting a couple of environment variables! While we have not yet fully reached this loafty goal, we already are operating 3 farms in 3 locations with the above properties mostly implemented \o/ In this talk, we are presenting how easy it is to deploy a kernel and run containers in our farm, show what it takes to set up a test farm at home, and what can be done to get hobbyist projects like Nouveau tested! about this event: https://c3voc.de

I'm going to present a summary of the last 10 years or so of participating to the moderation and animation of the xorg-security@ mailing lists. This is an opportunity for people interested in taking over this responsibility to have an insight of the kind of issues that are submitted and how we've been dealing with them. about this event: https://c3voc.de

Last year, it was fires everywhere. This year? well, it was also the same, sort of. In this talk, we will see what steps we took to reduce further more our bill for our gitlab hosting. We will also tell some jokes like "oh, BTW, we almost lost all of our storage", or something like "oops, I killed the entire cluster". Oh the fun we had. So yes, this is basically the continuation of the talk I gave last year to present the new infrastructure and the roadmap we have for gitlab.freedesktop.org. about this event: https://c3voc.de

The purpose of TTM is to provide buffer object contents in memory where it is mappable by the CPU and GPU when needed, and also to allow overcommitting by means of swapping or eviction. This talk will cover the process of moving memory management in i915 kernel driver to TTM. about this event: https://c3voc.de

The [big change][1] in KWinFT this year is the replacement of all its own hardware backend plugins for its Wayland session with a single backend talking to wlroots. This talk goes into detail on: - reasons for this strategic move, - technical realization, - outcome with advantages and disadvantages, - long-term impact on the ecosystem. [1]: https://gitlab.com/kwinft/kwinft/-/merge_requests/108/ about this event: https://c3voc.de

Due to its nature, the display stack can be hard to test. Indeed, the component we want to test often sends the pixels to an external display without any way to retrieve the image being output, let alone make sure it's correct. And while a human can perform some of those tests by looking at the screen, some issues can prove to be difficult to spot, such as colours being slightly off or pixels being offset. More complex tests can also be tedious to set up or hard to trigger. The ecosystem of devices that Linux supports also adds further constraints on the display interfaces we want to test, but also on the system size, the tools available, the connectivity of the device, etc. In this talk, we will first discuss the constraints and what makes testing the display stack unique. We will then talk about the existing solutions, their limitations, and what we have been working on to improve the situation. about this event: https://c3voc.de

While GPU multi-tenancy in the server world has grown rapidly, hostile multi-tenancy on single, commodity GPUs has been virtually unexplored. Existing multi-tenancy solutions for GPUs all fall short in at least one of the following areas: Minimizing attack surface, strongly isolating potentially hostile tenants, supporting consumer GPUs, and allowing parallel sharing of a single GPU between tenants. Containers and VirtualBox’s virtual GPU are not secure enough to protect against hostile workloads. VirGL, KVMGT, XenGT, and WebGL are all incredibly complex solutions with massive attack surface. AMD and NVIDIA already support GPU virtualization, but it is limited to costly enterprise cards and the NVIDIA solution requires proprietary drivers. Hyper-V GPU partitioning support is neither free software nor production ready. Finally, PCIe pass-through to a VM requires 1 GPU per tenant, which makes it insufficient for desktop partitioning solutions such as Qubes OS. This workshop is a twofold challenge: First, determine if hostile multi-tenancy on a single commodity GPU can be implemented securely. If it can, figure out how; if it cannot, determine what would be needed from GPU vendors. The goal is to begin work towards a secure, capability-based GPU multiplexer that runs on commodity hardware and is agnostic to the specific CPU-side isolation mechanism, whether it be a microkernel, a hypervisor, or something else entirely. about this event: https://c3voc.de

I'm going to present a summary of the last 10 years or so of participating to the moderation and animation of the xorg-security@ mailing lists. This is an opportunity for people interested in taking over this responsibility to have an insight of the kind of issues that are submitted and how we've been dealing with them. about this event: https://c3voc.de

Modern applications in areas like Machine Learning, Artificial Intelligence, and 3D Graphics, require a synergistic software/hardware ecosystem that allow developers to take full advantage of hardware accelerators. In this scenario, it is critical to have a low-level API that can easily support and adapt to any device, in order to minimize the impact in upper-levels of the software stack when exposing novel hardware capabilities to higher-level programming models and frameworks. Level-Zero API, part of Intel OneAPI product, defines a device-independent, vendor-agnostic, low-level, direct-to-metal interface to accelerator devices that abstracts users and upper-level components of the software stack from the specifics of the target devices, while providing them with the access needed to fully exploit their hardware capabilities. This is essential for Intel to expose new hardware features at a faster pace and to effectively compete against established CUDA-based ecosystem from NVIDIA. This presentation offers an overview of the rich set of interfaces defined in Level-Zero, focusing on capabilities such as unified-shared memory, peer-to-peer communication, and inter-process communication. Additionally, the status of the implementation of Level-Zero and its adoption by higher-level compiler, analysis tools, performance libraries and other frameworks are presented. about this event: https://c3voc.de

We talk about a new programming interface “Sysman” which is part of level zero library. Sysman (System Resource Management) is used to monitor and control the power, frequency, temperature etc , of accelerator devices. Sysman is an API that will, • Enable HPC (High Performance Compute) GPU servers to optimize/track power, temperature ,utilization, memory bandwidth & scheduling of Intel discrete graphics cards for the kind of workloads that run in those environments. • Provide system level monitoring of important telemetry like power, frequencies, temperature and updating the firmwares • Be integrated as part of OneAPI Level0 with hooks into the Level Zero UMD driver. about this event: https://c3voc.de

After the talk "SSA-based Register Allocation for GPU Architectures", this workshop will be for people considering implementing SSA-based register allocation or wanting to understand the ACO and Freedreno implementations. We can also go more in-depth with different strategies and heuristics used to optimize the register allocation problem, if there is interest. about this event: https://c3voc.de

This talk presents an overview of the KWinFT project in 2021. The following topics will be discussed: - original motives for founding the KWinFT project, - recap of previous developments in 2020, - overview of current developments, - project organisation and scaling, - embedding in the ecosystem: long-term plan for KWinFT as a C++ library collection for the creation of feature-rich Wayland (and X11) compositors. about this event: https://c3voc.de

At last year's XDC, Jason gave an overview of the VK_KHR_ray_tracing extensions and how they can be used to implement a ray-tracing render from a client POV. In this talk, Jason will discuss the implementation of those extensions in Intel's Linux Vulkan driver. We'll cover over-all architecture as well as detailed topics such as bindless thread dispatch on Intel HW, Shader call/return lowering, and BVH building with OpenCL kernels. Watching last year's talk as preparation is highly recommended. about this event: https://c3voc.de

Broken and flickering geometry, corrupted textures, and even hangs in real-world games and apps are common issues in open-source graphics driver development. While conformance tests are mostly narrow and confined, finding driver problems when running triple-A games can be a challenging task. This talk will show a major misrendering example when running a game and the steps taken to pinpoint the underlying problem in shader compilation using RenderDoc. We will briefly touch the taxonomy of different issues, typical causes, and generic methods to try. about this event: https://c3voc.de

Ever wondered what happens when you mix Emscripten, Graphviz, and a Vulkan driver? I couldn’t help myself and tried: What started as a simple visualizer for shader control flow has since grown into a port of Mesa’s shader compiler ACO running in the browser, capable of compiling thousands of shaders on-the-fly. Don’t believe it? Demo included! Putting this experiment into wider context reveals a landscape of powerful debugging tools rarely utilized in low-level programming: With robust and efficient code left at the core, external web-based tools benefit from quicker iteration cycles and easier UI prototyping. This talk doesn’t present ground-breaking ideas: At worst, you’ll see a cool tool made with love. At best, you’ll walk away with new ideas for creating debuggable systems. about this event: https://c3voc.de

With the ever-increasing focus on testing found in our community, let's try to coordinate the efforts of every individual. The main focus for this workgroup will be two-fold: - Ramp up the trace-based testing in Mesa CI / DXVK / ... - Bring kernel testing to more drivers than i915 Please ping mupuf on IRC on OFTC's #freedesktop to add additional topics or show interest in one. about this event: https://c3voc.de

One of the biggest user-facing issues facing wayland adoption is robustness. A crash in the compositor can take down the entire session and lead to data loss. With wayland being a constantly changing landscape and with more workload being put on the compositor process this doesn't seem to be going away. This talk showcases work across multiple libraries and toolkits to tackle this at the root with a method of "compositor handoffs" allowing clients to safely securely and seamlessly reconnect to a relaunched wayland compositor. This not only tackles the issue of robustness but also opens up a whole avenue of new opportunities that were previously impossible; such as freezing and resuming applications. We talk through the POC implementations made across multiple toolkits, and what changes are needed throughout wayland and mesa to support this. about this event: https://c3voc.de

Ich mache gerne Fahrradtouren und navigiere dabei mit meinem Handy auf Openstreetmapkarten. Allerdings verbraucht das Navigieren ziemlich viel Strom, sodass der Akku den Tag nur knapp durchhält. Daher habe ich überlegt, mein Handy über den Nabendynamo an meinem Fahrrad zu laden. Das Ergebnis stelle ich in diesem Petit Foo vor. about this event: https://www.chaospott.de

Lightning talks for the first day of the conference: - LibVF.IO & Hyperborea - new tech for VFIO graphics passthrough users - Another year, another ISA: Panfrost update - The Input Method Hub - Quick Overview of VK_EXT_multi_draw - SDL: The Quest for Wayland By Default about this event: https://c3voc.de

The Virtual Kernel Mode-setting(VKMS) driver aims to help with testing and development of graphics drivers without having to use actual graphics hardware. My work during Outreachy comprised adding support for emulation of virtual hardware in VKMS. This involved writing/refactoring code in IGT GPU tests as well. I want to talk about my journey as a newcomer in exploring DRM and IGT GPU tools, debugging mysterious errors, and working with the community to develop a solution. about this event: https://c3voc.de

CRIU a.k.a Checkpoint Restore in Userspace is the de-facto choice for Checkpoint and Restore but one of its major limitations is to Checkpoint and Restore tasks that have a device state associated with them and need the driver to manage their state which CRIU cannot control but provides a flexible plugin mechanism to achieve this. So far there is no serious real device plugin (at least in public domain) that deals with a complex device such as a GPU. We would like to discuss our work to support CRIU with AMD ROCm which is AMD's fully open source solution to Machine Learning and HPC compute space. This will potentially be extended to support video decode / encode using render nodes. CRIU already has a plugin architecture to support processes using device files. Using this architecture we added a plugin for supporting CRIU with GPU compute applications running on the AMD ROCm software stack. This requires new ioctls in the KFD kernel mode driver to save and restore hardware and kernel mode driver state, such as memory mappings, VRAM contents, user mode queues, and signals. We also needed a few new plugin hooks in CRIU itself to support remapping of device files and mmap offsets within them, and finalizing GPU virtual memory mappings and resuming execution of the GPU after all VMAs have been restored by the PIE code. The result is the first real-world plugin and the first example of GPU support in CRIU. While there were several new challenges that we faced to enable this work, we were finally able to support real tensorflow/pytorch work loads across multi-gpu nodes using criu and were also able to migrate the containers running gpu bound worklaods.In this talk, we'd like to talk about our journey where we started with a small 64KB buffer object in GPU VRAM to Gigabytes of single VRAM buffer objects across GPUs. We started with /PROC/PID/MEM interface initially and then switched to a faster direct approach that only worked with large PCIE BAR GPUs but that was still slow. For instance, to copy 16GB of VRAM, it used to take ~15 mins with the direct approach on large bars and more than 45 mins with small bars. We then switched to using system DMA engines built into most AMD GPus and this resulted in very significant improvements. We can checkpoint the same amount of data within 5 seconds now. For this we initially modified libdrm but the maintainers didn't agree to change an private API to expose GEM handles to the userspace so we finally ended up make a kernel change and exporting the buffer objects in VRAM as DMABUF objects and then import in our plugin using libdrm. We are going to present the architecture of our plugin, how it interacts with CRIU and our GPU driver during the checkpoint and restore flow. We can also talk about some security considerations and initial test results and performance stats. Further reading: https://github.com/RadeonOpenCompute/criu/tree/criu-dev/plugins/amdgpu#readme Our work-in-progress code: https://github.com/RadeonOpenCompute/criu/tree/amd-criu-dev-staging about this event: https://c3voc.de

Just a yearly status update about etnaviv (NIR, CI, ..). about this event: https://c3voc.de