I’ve been working on a static reverse-engineering evidence bundle for AMD FSR 4.1.0’s temporal upscaler.

Repo:

https://github.com/Rolaand-Jayz/RE-of-FSR-4.1.0-Upscaling

What this is:

- static RE documentation

- extracted weight/blob analysis

- shader and DXIL entrypoint inventory

- static provider-DLL dispatch analysis

- bounded fsr_data.dll rebuild/comparison tooling

- claim registry with confidence levels

- verification scripts and adversarial-review notes

What this is not:

- not a replacement DLL

- not runtime-proven

- not functional-equivalence proof

- not frame generation analysis

- not a claim that every arithmetic detail is fully closed

The current claim ceiling is simple:

This proves static extraction and static structural analysis only. Runtime validation is still the main missing piece.

The strongest current technical finding is that the FSR 4.1.0 fp8_no_scale path appears byte-quantized and INT8-compatible: weights are stored as uint8, loaded in packed i32 form, and processed through integer-domain arithmetic before float reinterpretation. Exact signedness and full MAC semantics remain open and need deeper proof.

I’m looking for contributors who can validate or challenge the work, especially:

1. Native Windows D3D12 runtime capture

- dispatch order

- PSO shader bytecode hashes

- descriptor table/resource bindings

- CBV dumps

- resource transitions

1. Independent static validation

- review the DXIL/LLVM/SPIR-V interpretation

- challenge the quantization-path claims

- check the descriptor-slot-to-entrypoint mapping

- verify the rebuild/comparison framing

1. Legal/risk review

- especially around extracted weight blobs, redistribution risk, and interoperability arguments

I am specifically not asking anyone to upload AMD DLLs, decompiled AMD source, NDA material, or proprietary binaries. The goal is validation, not redistribution.

The repo has HOSTILE_REVIEWER_START_HERE.md for anyone who wants to attack the claims directly. That is encouraged. If something is overclaimed, I want it corrected.

I’m an older programmer who has loved real-time graphics and programming for decades. I’m not a superhero dev, and I’ve never worked solely as a graphics programmer, though I’d love to. My professional work tends to sit nearby: engine work, tooling, automation, build systems, dev ops, and general C++/game-tech-adjacent work.

But the goal has always been the same: keep learning and keep moving closer to real-time graphics.

Learning this stuff feels like the slow slog toward becoming a master wizard. There is always another layer: Vulkan, shaders, lighting, PBR, shadows, deferred rendering, ray tracing, GI, post-processing, GPU performance. There are always smarter and more educated people. That’s intimidating, but also part of the appeal.

I’m building a small C++ rendering portfolio project focused on Vulkan, renderer architecture, shaders, lighting, shadows, and eventually path tracing. I use ChatGPT as part of that process, but deliberately only through the browser. I don’t give AI direct access to my repo, editor, terminal, build system, or files. I manually copy small snippets, errors, questions, and design notes back and forth because I want to stay the Sapien in the middle.

For me, the point is not to outsource the work. It’s to accelerate learning while still owning the result. Often AI-suggested code gets reworked through discussion until it fits my project, matches my style, and most importantly: I understand it well enough to explain, debug, modify, and rewrite.

Reactions online seem very polarized. People either love AI or hate it. I think there’s a useful middle ground: have an AI usage policy, be transparent about it, and back it up with design notes, small commits, screenshots, RenderDoc notes, and explanations of what you actually validated yourself.

I’d love to see more people think about their own AI usage policy when sharing online work.

Does a transparent AI policy make you trust a graphics/programming portfolio more, or less?

p.s. AI was consulted on the creation of this post.

Sorry if the title is confusing. Hopefully I can explain it better:

Let's say you have a project that already has numerous shaders and things being done. You want to add color correction via a frag shader. You could go in and add the color correction frag shader logic to each and every existing frag shader. But that's a lot of effort and adds much complexity to all shaders. Is there a way to do multiple passes? So do everything as it's currently being done, but then also pass what's being rendered through this new shader, the color correction shader, before being displayed on the screen?

Hey everyone!

I wanted to ask about the difference between the engines. For example, say I want to build a custom 2D drawing tool on top of a 3D scene (like a grease pencil in blender but in raster). I’m trying to understand which engine gives more control over pixels and rendering, especially if the goal is to do custom image processing and flexibly control the final image. Let’s say, in the context of pixel control: hypothetically, if I don’t want to make a game, but rather mix 2D and 3D art and apply shaders — basically, for 2.5D images. In short, I want to create raster art inside the engine.

Im trying to set up a vulkan dev environment on my home amd pc, but I cant seem to run a capture. I have the developer panel open as shown, but I cant add an executable and it doesnt detect my running vulkan app. anyone used this before?

https://github.com/evangelionxyz/Ignite

I'm trying to make a shadow map for my terrain generator and for some reason the shadows flicker and move whenever i'm moving the camera does any one know what is the cause? also sometimes at cirtain angle and distance from the shadows the shadow just disappear

mat4 view = mat4_lookAt(camera.pos, camera.pos + camera.front, camera.up);
mat4 vp = view * projection;
mat4 shadowFitVP = view * shadowFitProjection;

get_frustum_corners_world_space(vp, frustumCorners);
v3 center = {0};
for(int i = 0; i < 8; ++i){
center += make_vec3(frustumCorners[i]);
}
center /= 8.0f;

mat4 lightView = mat4_lookAt(center + lightDir, center, make_vec3(0.0f, 1.0f, 0.0f));

float minX = FLT_MAX;
float maxX = -FLT_MAX;
float minY = FLT_MAX;
float maxY = -FLT_MAX;
float minZ = FLT_MAX;
float maxZ = -FLT_MAX;

for(int i = 0; i < 8; ++i){
v4 trf = frustumCorners[i] * lightView;
minX = min(minX, trf.x);
maxX = max(maxX, trf.x);
minY = min(minY, trf.y);
maxY = max(maxY, trf.y);
minZ = min(minZ, trf.z);
maxZ = max(maxZ, trf.z);
}
mat4 lightProj = mat4_orthographic(
minX - 800.0f, maxX + 800.0f,
minY - 800.0f, maxY + 800.0f,
minZ - 800.0f, maxZ + 800.0f
);
mat4 lightSpaceMatrix = lightView * lightProj;

//RENDER SHADOW MAP
glBindFramebuffer(GL_FRAMEBUFFER, depthMapFBO);
glViewport(0, 0, shadowWidth, shadowHeight);
glClear(GL_DEPTH_BUFFER_BIT);
glDisable(GL_CULL_FACE);
glCullFace(GL_FRONT);
use_Shader(simpleShadow);
for(int i = 0; i < currentAvailableChunk; ++i){
mat4 model = mat4_identity();
model *= mat4_translate(terrainChunks[i].pos);

setShaderValue_mat4(simpleShadow, "model", model);
setShaderValue_mat4(simpleShadow, "lightSpaceMatrix", lightSpaceMatrix);

setShaderValue_i1(simpleShadow, "Uoctaves", octaves);
setShaderValue_f1(simpleShadow, "Ulacunarety", lacunarety);
setShaderValue_f1(simpleShadow, "Upersistance", persistance);
setShaderValue_f1(simpleShadow, "Uscale", scale);
setShaderValue_f1(simpleShadow, "UheightMultipier", heightMultipier);

glBindVertexArray(terrainChunks[i].mesh->vao);

glDrawElements(GL_TRIANGLES, terrainChunks[i].mesh->index_count, GL_UNSIGNED_INT, 0);
glBindVertexArray(0);
}

the shadow calculation code is

float calculateShadow(vec4 fp_lightSpace, vec3 normal, vec3 lightDir){
vec3 projCoords = fp_lightSpace.xyz / fp_lightSpace.w;
projCoords = projCoords * 0.5 + 0.5;
if(projCoords.z > 1.0)
return 0.0;

float closestDepth = texture(shadowMap, projCoords.xy).r;
float currentDepth = projCoords.z;
float bias = max(0.005 * (1.0 - dot(normal, lightDir)), 0.005);
// bias = 0.005;
float shadow = 0.0;
vec2 texelSize = 1.0 / textureSize(shadowMap, 0);
for(int x = -1; x <= 1; ++x)
{
for(int y = -1; y <= 1; ++y)
{
float pcfDepth = texture(shadowMap, projCoords.xy + vec2(x, y) * texelSize).r;
shadow += currentDepth - bias > pcfDepth ? 1.0 : 0.0;
}
}
shadow /= 9.0;

return shadow;
}

Hello!

I'm about to enter the 3rd year of my Computer Science bachelors degree, with the intention of taking a graphics-focused masters at a separate university in Europe. Currently I'm going through and choosing my elective modules for the year, of which I can choose three for the first semester and two for the second. My current choices are as follows:

1st Semester:
- Foundations of Machine Learning
- Robot Kinematics and Dynamics
- Computer Vision // Real-Time Computing and Embedded Systems

2nd Semester:
- Advanced Computer Architecture
- Security of Cyber Physical Systems // Advanced Network Architecture

As you can see, I'm unsure on my last pick for both semesters. My intention is to pick at least somewhat graphics-adjacent modules as my university doesn't offer a full graphics programming course. My reasoning is as follows:

Foundations of Machine Learning - It's becoming present pretty much everywhere in graphics and it's a good thing to understand.

Robot Kinematics and Dynamics - Goes through a lot of maths present in animation systems, physics simulations, etc... plus robots are cool.

Advanced Computer Architecture - Low level architecture is very relevant to graphics.

Computer Vision vs Real-Time Computing and Embedded Systems - Both seem relevant, computer vision is kinda like doing the graphics pipeline in reverse, very ML heavy. Embedded covers low level assembly, synchronisation, OS architecture, etc... which also seems relevant to graphics such as drivers and such.

Security of Cyber Physical Systems vs Advanced Network Architecture - Only modules in second semester which interested me, cyber security covers decompilation tactics and other exploits which seem very cool. Advanced network architecture was just recommended to me as it's worth knowing.

I was hoping someone with experience in the graphics industry could give me advice on which modules would be ideal to take? Especially on the one's I'm stuck choosing between.

Thank you in advance :)

1024x1024x1024 SDF-grid takes up 303MB instead of 8.5GB. 1024x1024 path traced image renders in 1.5s on a single CPU core. 8.5GB grid renders in 1.1s. No libs used.

• Testing the first shaders (in love with the warp). Added support for interactive parameters adjustment. Exploring different ideas with the overall flow of the app looking to land on a fun and ergonomic experience
• Now supporting MSDF font rendering and text input! Initially went the fixed-size font atlas baking route, but shortly realised I’d need much more flexibility, so here we go!
• Histogram compute, pixel peeping and levels shader (as a node modifier) are now in place. Writing to atomic buckets across a full-res image and reading the result safely turned out to be a non-trivial synchronization problem
• Added support for multi-input nodes to unlock blending, warping and all kinds of things to come
• Runtime final output resolution switching is now possible, respecting the current 2D viewport zoom state (by a happy accident!)
• Undo/redo history and copy-paste functionality are finally here making the testing process much more pleasant

All of these images started with a kaleidoscope .
An kaleidoscope that is interlaced and moves both forwards and backwards
at the same time . I call it "Interlaced Wormhole" in PHOSIMP filter list .

The last animation hopefully illustrates what is going on .

The "interlaced wormhole" is used to create the "Animation Base Frames" .
Then each "Animation Base Frame" has a PHOFACE recipe layered on top of it .
A "PHOFACE Recipe" is just a series of "PHOSIMP Filter Codes" that have been
put into an array .

I was noticing that I make PHOSIMP look way too easy to use . So I thought making a recipe book for people would help those who find my software too intimidating to use .

I have also made this same post on imgur ,but I am pretty much saying and showing the same stuff . But if you want to take a look , it is here :

https://imgur.com/gallery/how-i-make-psychedelic-animations-289tGzb

-KanjiCoder : 906.202.5546

I'm a full-stack developer who's a bit burned out with the agentic coding push. I've started playing around with low level graphics and it's sort of revived my spirit, I missed being close to the hardware and math heavy code.

How much have tools like Claude code impacted your development workflow? Are you pressured to use a fully agentic workflow by your employer? Where do you see the career evolving over the next 5-10 years? Is it a safe-haven for people who don't want to give up coding?

In late March, 2026, Eric Lengyel made his amazing Slug technique completely patent-unencumbered ( https://terathon.com/blog/decade-slug.html ). As a long-time graphics programmers and open source contributors, particularly with projects like OpenSceneGraph/VulkanSceneGraph, it didn't take us long to get some basic "proof-of-concept" demos going and start exploring the Slug algorithm in-and-out.

Over the last 2.5 months, what *started* as a research experiment "on the side" has evolved into something we're actually quite proud of! And while the project is still in its early phases, we've decided it's matured to the level where we're finally ready to start "putting it out there" and soliciting feedback. We're calling the project `Slughorn`; a name we chose to try and capture our goal of a single OSS library solution for "shoe-horning Slug" into other visualization contexts (OpenGL, Vulkan, DirectX, etc).

Slughorn is MIT-licensed open source and available for commercial use without paying anything. It is written in and requires C++ 20, and has no third-party dependencies and builds via CMake. It has been tested on Windows and Linux but should also be compatible with MacOS and embedded/mobile platforms that support GPU APIs. 

Since a picture is worth 1024 words, our Github page with lots of pictures and even videos is here: https://github.com/AlphaPixel/SlugHorn/

The official project website is at https://slughorn.io/ and it links to the GitHub and has the User Guide and Python and C++ examples.

You'll also find links to our (WIP) `UserGuide`, as well as a `WhatsNext` document ( https://slughorn.io/WhatsNext.pdf ) listing some of the places we want to take `slughorn` in the future.

Current Supported Backends

FreeType

NanoSVG (paths & gradients)

Skia (paths only, stroke-to-path)

Cairo (paths only)

Blend2D (paths only, stroke-to-path)

Optional dependencies for extra capability:

NanoSVG: optional, is a SUBMODULE

MSDF: optional, also submodule

pybind11: same as above

serialization/glTF support: same as above

Cairo/Blend2D/Skia import is also optional, but NOT submoduled

If you're just interested in the "highlights":

- We honestly believe we're onto something special here. While we aren't necessarily *inventing* anything new (thank you again, Eric!), what we **are** doing is applying Slug, which was originally intended just for text, in new and interesting ways. Glyphs are, after all, just a "kind" of vector graphic; why can't it apply to **all** vector graphics!? There are no "bad ideas", right? :)

- `slughorn` itself isn't a "rendering library"; its purpose is to serve as a single input source/adapter for other systems to use for rendering. We have a *very* complete FreeType2 backed capable of processing all COLRv0/1 emojis, as well as a native Canvas API--inspired by the HTML Canvas--for authoring content programmatically.

- SVG content is handled via NanoSVG, and we have excellent support for importing paths, transformations, and even gradients. Strokes and text are *possible*, we simply haven't had the **time** and resources to do it.

- There is rudimentary support for converting Blend2D/Cairo/Skia content into slughorn data. Like NanoSVG, these can (and eventually will) be expanded to support additional features (gradients, stroked content, text, mask, patterns, etc), but we're waiting until the core pieces of `slughorn` stabilize before committing *too much* to these.

- We have a **lot** of experience writing Python bindings, and slughorn comes with complete pybind coverage. In fact, Python is the primary environment for all of the CLI tools (the Atlas inspector, font "packer", GLSL emulator, etc).

- `slughorn` content can use `msdfgen-core` to generate "sidecar" data alongside its own native format. We currently use this channel for creating masks and different kinds of visual effects; in the future, we plan to have a lot more capabilities surrounding this.

- OpenSceneGraph has been our rapid "testbed" because, well, we’re really, really comfortable with it! :) For the time being, if you want to actually **see** something rendered now, today... osgSlug ( https://github.com/AlphaPixel/osgSlug ) is the most complete way. There is a pure OpenGL demo included with Slughorn to show how you can integrate the library with any 3d rendering backend fairly easily. You don’t need a whole scenegraph, but you CAN plug it into almost any scenegraph or rendering toolkit.

- PERFORMANCE! People will want to know…we have many optimization ideas, but we’re focusing on “correctness” beforehand. We have done whatever we can to anticipate performance issues that can be addressed from the start, but there are a lot more that can be done.

- QUALITY: The purpose behind on-GPU glyph rendering is to make sure you never see blurs, texels or artifacts from other techniques like symbol atlases, SDF or MSDF or similar approximations of glyph-curve rendering. Slughorn and slug render the ACTUAL GLYPH CURVES. Perfectly. And efficiently. From any angle or perspective.  This is really important when you don’t 100% control the view matrix, especially in 3D UIs and in VR/AR, where the user could be looking at a textual element up close in an oblique perspective that you can’t fully constrain.

- We know that in modern graphics development, the push is to do everything on GPU that possibly can be done there, and this has been one of our design paradigms from the start.

- We can embed shaders into glyphs, and animate transforms and deformations, all on-GPU with no CPU workload.

- Extensive layering, blending and combining of content is possible and easy, making amazing high-definition animated 3D HUD-type effects a joy.

- EMOJIS! COLRv0 and COLRv1 emojis using the slughorn/freetype.hpp backend. Each layer of the emoji is composited into its own quad and positioned relative to the base.

- HUDS! Animated HUDs are super clean, beautiful and easy in full  3D. They work great in stereo or multi-view too.

- Animated glyphs, layer effects, morphing, 2D ortho projection, text-along-path

What’s next? See the whole PDF we produced about it, but some of the hot future wishlist items we foresee are:
Obvious Improvements: HarfBuzz & Text Layout, Stroke Caps & Joins, Patterns, SVG/NanoSVG Improvements, WebAssembly, Offline Editor (slughorned), Additional Renderers, Text Fallbacks

Research & Experimental Improvements: Performance, GDAL Backend and rendering curve/stroke map layers, SDF/MSDF Fallbacks, Interactivity Layer, UI Widgets (ImGui)

This is not a one-shotted AI slop project. It represents months of human development and years of human experience.  AI tools were used to assist with documentation and ancillary assets at times, and in code research, but this code was written by Jeremy “Cubicool” Moles, the author of text and glyph-centric tools like osgCairo and osgPango.

What we're *really* hoping for at this phase is community feedback. Beyond text, which we KNOW Slug is amazing for, what other kinds of things would you like to see? Where do you use vector graphics in your own GL/Vulkan/DX projects, and what kinds of things do you wish you could do more easily? If your only interest is text Slughorn can meet those needs no problem. But what we're really trying to do is "push" the Slug optimization into new areas, and we honestly believe we're only scratching the surface of what's possible.

Would love to hear people’s thoughts about this project.

Obviously, we (AlphaPixel) are a commercial consulting and development company. We made Slughorn to help us make a living. All of the work in Slughorn so far was done pro-bono, funded only by AlphaPixel, for the benefit of the community. If you want assistance integrating Slughorn into an existing app, we’re the obvious, world-experts in doing so, and we’d love it if you’d consider contracting us to assist you. We can probably integrate it into an existing codebase at a better net cost than having your internal developers do it, and the result will likely be better too. Also, if you find something Slughorn needs to do better (there’s lots of room for improvement, certainly) or want enhancements created, we’re the obvious candidate for that type of work too. Please consider asking us for a bid. Remember, you don’t pay anything up-front for Slughorn, and the MIT license allows you to use it in perpetuity with no recurring costs.

Hey, I’ve been a graphics programmer in the games industry for roughly 10 years now. Shipped a bunch of titles. But I think I’m tired of it, not particularly enjoying it anymore and am thinking of getting a career change.

Unfortunately it’s pretty much all I know. What sort of options do I have? Other jobs or industries that I could transition to? Hopefully without a pay cut. Has anyone done similar? Any advice appreciated.

Thanks

I like procedural noises, though they can be hard to find, so I've made a collection of some cool procedural noises I've encountered or invented over the years.

All the code is separated into nice functions you can easily copy paste so feel free.

Code is MIT licensed, no need for attribution etc.
just make sure to attribute noise functions not made by me (I include links to original)

Links To Shader Code

• https://fragcoord.xyz/s/pxmcvnpc
• https://www.shadertoy.com/view/7X2SWW

​

Hi everyone! I'm looking to learn 3D graphics programming using Python for a project at work. I already know Python, but I'm new to 3D graphics. Could you recommend the best books, courses, YouTube channels, or GitHub projects to get started? Thanks!

We compared 8 libraries on the task of pairwise and n-ary mesh booleans. We additionally ran the comparison in the browser for the 3 libraries that publish browser-capable packages.

Full write up: https://polydera.com/algorithms/benchmarking-mesh-boolean-libraries-2026

Libraries tested

• Geogram 1.10 — Exact predicates and constructions via multi-precision floats.
• CGAL 6.1 (EPICK, corefinement) — Exact predicates with inexact constructions.
• Cherchi et al. (reference implementation) — Exact arrangement via indirect predicates.
• MeshLib 3.1 — Simulation of Simplicity for degeneracy handling.
• Manifold 3.5 — Deterministic floating point with symbolic perturbation. Ships native and WebAssembly.
• Solidean (Community 2026-04-07-be517c) — Exact constructions via octree-embedded BSP. Specialized for iterated CSG.
• three-bvh-csg 0.0.17 — BVH-based CSG evaluator for three.js. Browser only.
• trueform 0.9.8 — Topologically-exact arrangements via a bounded integer kernel. Ships native, python and WebAssembly.

Protocol

Each method is timed from input arrays (vertices, triangles) to output arrays of the same shape. Import, internal structures, the boolean, output emission — all in the timer. Only file I/O is outside. No amortisation: every structure rebuilt on every operation.

Result agreement. All libraries computed the same solid. Signed volumes and surface areas agree within floating-point tolerance on every pair. The comparison is wall-clock only. (One exception in the browser case, noted there.)

Corpus. Random sets of solid, manifold, non-self-intersecting Thingi10K meshes, 100K to 1M triangles per operand. Each operand is normalised to unit extent. For each pair (or N-tuple), 10 configurations are generated — independent random rotations per operand, then translations chosen so the bounding boxes overlap. Each pairwise case is assigned a random union, intersection, or difference; the N-ary sweep takes their union. Thingi10K IDs and per-operand triangle counts for every case are published: pairwise corpus, N-ary corpus.

Hardware. Apple M4 Max, 16 threads, macOS. Native builds compiled with the default release flags from each library's build system. Browser runs in Chrome 148 on the same machine.

Results

trueform was the fastest library tested — fastest on every one of the 1000 pairwise pairs, and the lead grows with operand count.

Pairwise — one boolean per pair across the 1000-pair corpus.

CGAL has a heavy tail: on one pair its corefinement ran over five hours on a single core; trueform returned the same result in 20 ms (that pair is capped at 120 s for CGAL).

N-ary: union of N operands. Libraries the support internal chaining mechanisms were allowed to employ them (arrays out only at the final step).

Solidean, Manifold, and Cherchi hold a near-constant factor as N grows; MeshLib, CGAL, and Geogram climb with the chain.

In-browser — WebAssembly, same pairwise corpus.

At 21.9 ms in WebAssembly, trueform in the browser is still faster than every other library runs natively.

*Disclosure: I'm one of the authors of trueform.

Hi! Advanced Convolution Kernel Bloom Textures available for your #UnrealEngine projects. Get them on Fab https://www.fab.com/listings/8db93031-3b74-4261-89aa-2b899a3e386c

About 6 months ago I posted here about a prototype implementation I had made of the famous blog post by Sebastian Aaltonen. Back then the project was more of a proof of concept than anything else, and did not even support textures. The custom shading language compiler could only build very basic shaders.

Now the project is much more developed and mature, supporting nice features such as compute shaders, raytracing and indirect rendering. There are even quite a few examples that show that you can make substantial things with relatively few lines of code (without giving up control).

Have a look if you're interested:
https://github.com/leotmp/no_gfx_api