e

  • 0 Posts
  • 71 Comments
Joined 3 years ago
Cake day: June 15th, 2023
  • AdrianTheFrog@lemmy.worldtoLinux@lemmy.world•This is Alyssa Rosenzweig. She reverse-engineered Apple's M1 GPU with no public documentation and also developed an open-source Linux driver.English
    521·
    4 days ago

    lol I randomly searched for a page from collabora about how they reverse engineer GPU drivers (since I’ve seen that they’ve done that for other GPUs) and the very first page I went to was written by this person. Apparently this was a side project while she did fairly similar work on Mali GPUs at Collabora.

    Anyways, here’s what she said about the process:

    Typically, for Linux or Android driver reverse-engineering, a small wrap library will be written to inject into a test application via LD_PRELOAD that hooks key system calls like ioctl and mmap in order to analyze user-kernel interactions. Once the “submit command buffer” call is issued, the library can dump all (mapped) shared memory for offline analysis…

    it took some elbow grease to identify the three critical calls: memory allocation, command buffer creation, and command buffer submission…

    With those obstacles cleared, we can finally get to the shader binaries, black boxes in themselves. However, the process from here on out is standard: start with the simplest fragment or compute shader possible, make a small change in the input source code, and compare the output binaries. Iterating on this process is tedious but will quickly reveal key structures, including opcode numbers.

    From https://alyssarosenzweig.ca/blog/asahi-gpu-part-1.html , there’s a lot more details about the subsequent parts of the process in the next articles but they’re harder to summarize

  • AdrianTheFrog@lemmy.worldtolinuxmemes@lemmy.world•Ken Thompson Hack 2.0English
    8·
    9 days ago

    I think it’s supposed to be that how AI turns high level instructions into code is compared to how compilers turn code into assembly. Implying that using AI is just a natural extension of the handing off work to the computers that we’ve already been doing.

    I wonder if you gave different AI models some c++ or something and told them to write assembly based on it how well they would do compared to an actual compiler

  • AdrianTheFrog@lemmy.worldtolinuxmemes@lemmy.world•foss nerds stop being condescending to those who don't know the same things you do challenge (impossible)English
    5·
    4 months ago

    Conflicted on filename extensions. For the average person it works just fine, and I suppose that’s what probably matters. It’s not very common for not knowing the details of how they work to matter. It’s just silly that the same information is also in the start of the file 99% of the time. It is nice though to have a readable, usually reliable label, and then have a signature anyways for when different names overlap. Wikipeda lists 4 completely unrelated types with a .mod extension, for example.

    Pretty much any application will correctly open any file type it supports, regardless of the extension. So it is quite unintuitive that you could have a file named “.png” that seems to work completely fine yet is actually a jpeg or something. But that hopefully isn’t a case that people run into very often, so it probably doesn’t matter.

  • AdrianTheFrog@lemmy.worldtoOpen Source@lemmy.ml•Original Apollo 11 code open-sourced by NASA — original Command Module and Lunar Module code repos are now public domain resourcesEnglish
    3·
    5 months ago

    As an amateur computer graphics person, the best way to draw accurate stars is to just pre render it onto a cubemap. But if you really need that subpixel worth of parallax to be completely accurate for every star, there are a couple ways I can think of off of the top of my head. With any you’d want to make sure you only store position, size, and color, since stars are all spheres anyways. With effort, you can be very flexible with how these are stored. (4 bits color temperature, 4 bits size, 3*32 bits coordinates maybe)

    • splat each star into the screen texture with atomics
    • some sort of tiled software rasterization thing, like in Gaussian Splatting

    Worse ideas:

    • instanced hardware rasterization
    • ray tracing

    This is not that well suited to most usual rendering techniques, because most stars are probably going to be much smaller than a pixel. Ray tracing would mean you need to just hit every star by chance (or artificially increase star size and then deal with having tons of transparency), hardware rasterization is basically the same and additionally is inefficient with small triangles. I guess you could just live with only hitting stars by chance and throw TAA at it, there’s enough stars that it doesn’t matter if you miss some. That would react badly to parallax though and defeats the purpose of rendering every star in the first place.

    It’s much more efficient to do a manual splatting thing, where for each star you look at what pixel(s) it will be in. You can also group stars together to cull out of view stars more efficiently. Subpixel occlusion will be wrong, but it probably doesn’t matter.

    This is all just for the viewport, though. Presumably there are other objects in the game besides stars, which need to have reflections on them of the stars. Then that becomes an entirely different problem.

    The real answer though is that you wouldn’t try to render all of the stars, even if you want parallax. Maybe some of the closer and larger ones as actual geometry, simplify a ton of stuff in the background, render things as volumes or 2d billboards, have a cubemap for the far distance, etc

    Edit: also ofc this presumes you know the position, scale, temperature of every star

    I also like the idea of baking all of the stars into a volume in spherical coordinates, centered around the origin

  • AdrianTheFrog@lemmy.worldtoTechnology@lemmy.world•Artemis II Astronauts Have ‘Two Microsoft Outlooks’ and Neither WorkEnglish
    1·
    5 months ago

    It’s clear that several people in charge of the youtube livestream have no idea about how to do that correctly. I think the difference is just effort. Viewership was tiny compared to Apollo 11, as was the hype leading up to it. It’s clear that NASA could provide a whole lot better footage if even some random youtuber (Everyday Astronaut) can beat them. So that aspect is, as you said, because as a society we don’t really care about the Artemis launch. SpaceX does put a fair amount of effort into their livestreams, and you can easily tell by watching them.

    For the recorded footage, film often has a lot higher dynamic range than digital cameras and usually looks a whole lot better when recording a launch up close.

    Far shots are limited by atmospheric distortion and physical limits from diffraction for a given aperture size. None of that can change.

    IDK anything about the quality of the original live broadcast of Apollo 11, so i don’t have anything to compare in that regard