Cieric

I would gauge properly testing on our card to be running the game occasionally on our cards throughout the whole development process. Currently it's been a lot of games 2 weeks out from release dropping a ton of issues on us to try and figure out. I don't even care if they don't do any optimization for our cards as long as they give us a fighting chance to figure out the issues on our side.

> Card devs also ought to respect that a game dev may have a good business reason for leaving his game running like crap on certain cards.

I can't agree with this though, business decisions getting in the way of gamers enjoying games should never be something that is settled for. If the hardware is literally to old and you just can't get it to work fine, but when a top of the line card is running below 60 fps that's just negligence.

I agree on the dropping compliance when asked for aspect, the problem I'm referring to more is the driver dropping compliance without the game asking for it. If the underlying system can randomly drop compliance when ever it thinks it's fine without telling the user and without the user asking, I would not consider that compliant.

Good question, I'm assuming it's due to the calculation happen across a memory barrier of some kind or due to all the branches in between so llvm is probably avoiding the optimization. It was quite a while ago so it is something I could re-investigate and actually try and fix. I would have to wait for downtime with all the other tickets I'm getting though. It's also just something that dxc itself should be doing, but I have no control over that.

I'm just going off what I was told there, I was forced to make the fix since the game developers no longer were partnered to the company that owned the license to the content.

Fair enough, I can't say anything I've done has ever caused an issue like that (A new ticket would have been made and sent to me.) But I also can't say that it has never happened, so I'm not really in a position to disagree. We do have a good QA team though and we have an "open" beta program that also catches a lot of issues before they become more widely public.

> Floating point calculations aren't IEEE compliant

To late to edit, but I want to half retract this statement, they are IEEE compliant, but due to optimizations that can be applied by the driver developers they aren't guaranteed to be. This is assuming that the accuracy of a multiply and divide are specified in the IEEE floating point spec, I'm seeing hints that it is, but I can't find anything concrete.

After a bunch of testing and looking around I think I should actually change my statement. GPUs do offer IEEE floating point compliance by default, but don't strictly adhere to it. Multiple optimizations that can be applied by the driver developers can massively effect the floating point accuracy.

This is all kind of on the assumption that the accuracy of floating point multiplication and division is in the IEEE spec, I was told before that it was but searching now I can't seem to find it one way or the other.

I believe one of the optimizations done by nvidia is to drop f32 variables down to f16 in a shader. Which would technically break the accuracy requirement (as before if it exists). I don't have anything I can offer as proof of that due to NDA sadly though. I will note that most of my testing and work is done in PIX for Windows, and most don't have anti-cheat so they're easy to capture.

I will note, half of the customer facing bugs I get are "works on nvidia." Only to find out that it is a problem with the game and not the driver. Nvidia allows you to ignore a lot of the spec and it causes game devs to miss a lot of obvious bugs. A few examples:

1) Nvidia allows you to write to read only textures, game devs will forget to transition them to writable and will appear as corruption on other cards.

2) Nvidia automatically work with diverging texture reads, so devs will forget to mark them as a nonuniform resource index, which shows up as corruption on other cards.

3) Floating point calculations aren't IEEE compliant, one bug I fixed was x/width*width != x, On Nvidia this ends up a little higher and on our cards a little lower. The game this happened on ended up flooring that value and doing a texture read, which as you can guess, showed up as corruption on our cards.

1 and 2 are specifically required by the microsoft directx 12 spec, but most game devs aren't reading that and bugs creep in. 3 is a difference in how the ALU is designed, our cards being a little closer to IEEE compliant. A lot of these issue are related to how the hardware works, so stays pretty consistent between the different gpus of a manufacturer.

Side note: I don't blame the devs for #3, the corruption was super minor and the full calculation was spread across multiple functions (assumed by reading the dxil). The only reason it sticks out in my brain though is because the game devs were legally unable to ever update the game again, so I had to fix it driver side. That game was also Nvidia sponsored, so it's likely our cards weren't tested till very late into the development. (I got the ticket a week before the game was to release.) That is all I'm willing to say on that, I don't want to get myself in trouble.

The other part of the optimization issue is that you can't take to long to try anything and everything. Most of the optimizations happen on the driver side, and anything that takes to long will show up as shader compilation stutter. I can't say currently if this is or isn't done, it's just always something you have to think about.

I mean this already happened [1]. But it's either that or games running like crap because they're not properly tested on our cards.

[1] https://www.neowin.net/news/yandex-alleges-amds-windows-driv...

In the case that does happen, then we don't apply that setting. Most of the changes applied are extensively tested and toggles like that are more often used for already broken shaders.

That's specifically because gpus aren't IEEE compliant, and calculations will drift differently on different gpus. Double precision can help avoid divide by zero errors in some shaders because most don't guard against that and NANs propagate easily and show up as visual corruption.

I can't give details on how we do our selections (not nvidia but another gpu manufacturer). But we do have direct contacts into a lot of studios and we do try and help them fix their game if possible before ever putting something in the driver to fix it. Studios don't pay us, it's mutually benefital for us to improve the performance of the games. It also help the game run better on our cards by avoiding some of the really slow stuff.

In general if our logo is in the game, we helped them by actually writing code for them, if it's not then we might have only given them directions on how to fix issues in their game or put something in the driver to tweak how things execute. From an outside perspective (but still inside on the gpu space) nvidia does give advice to keep their competitive advantage. In my experience so far ignoring barriers that are needed as per the spec, defaulting to massive numbers when the gpu isn't known ("batman and tessellation" should be enough to find that), and then doing out right weird stuff that doesn't look like something any sane person would do in writing shaders (I have a thought in my head for that one, but it's not considered public knowledge. )

Finger printing based on shaders is quite rare, really most of the time we detect things like the exe name calling us or sometime, very rarely they will give us a better name through an extension. (unreal engine does this automatically). From there all the options are simple, but full shader replacements are one. In the api I work on the shaders have a built in hash value, so that along with the game identified means we know exsactly what shader it is. Most of the replacements aren't complicated though, it's just replacing slow things with faster things for our specific hardware. In the end we are the final compiler so us tweaking things to work better should be expected to a degree.

I don't work on the nvidia side of things but it's likely to be the same. Shader replacement is only one of a whole host of things we can do to make games run faster. It's actually kind of rare for use to do them since it boats the size of the driver so much. A lot of our options do change how shaders work though, like forcing a shader to use double precision floats instead of the single it was compiled with.

Firefox reader view seems to be a slight improvement since it removes the random right alignments in the article.

Yeah specifically when I signed up they did the a small charge then, I assumed it only ever do a single charge to check for the legitimacy of the card. If I ever wanted to do a paid tier, I would have changed the card details. But it was a week later that they did a second check even though I hadn't done anything that would incur a charge. The card I had setup with privacy was a charge once card that immediately closes after the first transaction is completed (including charges that are canceled.) So the second charge hit the card after the card was closed. At that point they decided the card must have been stolen and decided to permanently close my account with no recourse.

My guess in the end is they just don't care, I'm not the one that would be giving them lots of money, business contracts are. But they are wrong in the sense that I will never let any company I ever work for choose them if I have any say in the matter.

I've never really mentioned it elsewhere, but the last time I even considered doing something with oracle was I believe when they released the free-tier arm instance and I was just going to compile some of my projects to arm to see if they worked well.

Well since I'm not in the business of trusting a lot of corporations I decided to use a privacy.com virtual card that only had a one time transaction and would close afterwards. Well after signing up and starting the instance and doing some quick tests. I ended up coming back to it a bit later and found out the account was just out right terminated. After a while of going through support and looking around at what logs I could get, turns out they tried to do a $0.01 charge on the card and since it failed marked the card as stolen (or something similar.) And even with a long conversation with support they told me there was literally nothing that could be done, not even with proof of identification or anything. Even making a new account didn't work since something was matching and they were rejecting me making a new account (don't know if it was address, ip or my name.)

At this point I share the opinion that others here are sharing, no matter the reason never work with oracle. I'm just lucky they made the decision for me and I never even have to consider the choice again.

My personal problem is that I self host and the updated extension just completely fails to connect to my vaultwarden instance. I probably just need to repull the updated docker container, but it's something I would have rather not thought about. But since the extension auto updated I'm forced to think about it.

Alloca is allocations on the stack, seems the kernel might be stack based, but the os itself has it's own implementation of malloc. Which is heap based. https://github.com/google/pebble/blob/main/src/libos/include...

I'm also seeing references to rtos as the true underlying os though.

This sounds really cool, I'm less then an amateur photographer (I have a weird camera that I like writing software for.) But most of my images are stripped of Exif data as others have mentioned, could you provide an example on the page that I could test it out with?

This makes me want to go back to making a custom keyboard again. The feature to scan your hands is interesting, but I can't seem to get it to work at all. I got it to measure the length of my digits, but when it came to measuring how flexible they are I could never get it to complete. On top of that the detection seemed to freak out a lot and the right hand model was screwed up. Overall this does seem really cool, but more something I'll bookmark to try later.

I love the idea of this, but sadly I can't get it to work in Firefox, Chrome or Edge on my work pc, probably because I can't find "--enable-features=Vulkan" equivalent in the about:flags and the argument doesn't appear to work on windows. I'm actually a bit more curious about a standalone application that skips the webgpu part and goes straight to Vulkan as I would love to be able to experiment with some Cuda only applications.

Not to take anything away from the info you've provided since it is all interesting. But it seems francisco's gender is pretty debated. There are a few that talk about them being a female with certainty, but without any reasoning I also take their info with a grain of salt.

While I've used c-reduce before, I've never done it in a way where it could be destructive. However speculating based on what I do know. I think the 2 things I would do would be in the interesting-ness test, grep for already known harmful instructions and force them to be uninteresting (returning 1). And then if I was still unsure of the potential harm of the program and I had to run it to determine if it's interesting or not (segfault or something similar). I think I would hoist the binary/script into a docker container and run it there. That way the log and result can still be checked, but it's access to actual file system is minimized as much as possible.

TLDR; C-Reduce just gives you text to run/compile, if you're worried about things like that sandbox as much as possible.

That depends completely on the interesting-ness test that's provided. If you're looking for a compiler bug (like I do often for my language), then the interesting-ness test checks the compile logs for information like the "Segmentation Fault" text, no need to run the actual executable. You could also hoist everything into docker if you really want to, or ship it off to another device to run.

Not the parent, but seems this is the source code for the blog. https://github.com/FrostKiwi/treasurechest

Found it by going to the comments since the comments are GitHub issues the "x comment" is a link to the issues page.

Opening on Firefox 132.0.2 (all extensions disabled) I get a Content-Security-Policy error, on Edge 131.0.2903.51 (stock) in the issues panel reports 40 Errors and 147 Warnings (With Top Browsers selected). Downloading chrome 131.0.6778.86 just to test they also have a different error "Define @import rules at the top of the stylesheet" which specifies that the @import is ignored due to it not being at the top. They're just hidden in the issues, so same as edge.

This might be more down to the browser you're using and not the extensions present (while extensions like ublock origin do cause more errors.) Not even chrome has 0 problems with their own default home page.

I remember when I was looking into this at one point in time. I was trying to figure out a good implementation that didn't require you to store multiple different positions. The most I really ever got was a reverse order transparency [1] which employs some stuff similar to the article.

My plan was basically render everything opaque first, then render transparency front to back till the layer became opaque (discard all pixels under an already opaque pixel), and of course exclude everything further away than the depth buffer of the opaque layer.

Might be interesting to actually go and finish the implementation to test it out, I just never had a good test scene with a lot of transparency (with an opaque layer since half my benefit comes from that.)

[1] https://www.shadertoy.com/view/msyGDR

Some google searching brought up this. https://learn.microsoft.com/en-us/cpp/build/profile-guided-o... I'm only reading over it now, but I'm going to test it out a bit when I can.