this post was submitted on 22 Nov 2023
1 points (100.0% liked)

AMD

25 readers
1 users here now

For all things AMD; come talk about Ryzen, Radeon, Threadripper, EPYC, rumors, reviews, news and more.

founded 11 months ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[โ€“] [email protected] 1 points 10 months ago (3 children)

I don't really understand the tone. The guy seems to understand roughly how the rendering pipeline works and the pros and cons of each solution. By doing it, he sort of answers his own question of why did AMD decide to go with this, and so I don't understand why he sounds so dumbfounded about it.

I am not here to defend AMD but working in the industry I can say that there are plenty of reasons for why AMD did what they did: competitive, managerial, technical, budget and, of course, developer relations.

For one, it takes a lot less time to address this issue by developing a library that hooks to every game possible and make it faster without ever needing to talk with the developer. Is it a hack? Of course it is and they know it. But it may have been necessary for AMD to give a quick and cheap answer to players in a competive market. Their answer does come with lots of caveats but it probably achieves 80% of quality with 20% effort as compared to Nvidia. Enabling it by default is bad I guess, especially because it can break games. However, not all games are played competitively online nor have anti-cheat software, so I don't understand either why just focus on CS and whatnot. Again, it should not have been the default and it should come with CAPS disclaimer that the feature can result in banning. Especially if they know what games are, they can even have made it impossible to turn on the DLL for such games. With that, I agree.

Back to the question. Gamers in general and people doing these reviews often downplay the magnitude of the work involved in creating a stable foundation. Let's say all of a sudden a company has to engage with 100 game developer companies about a "potentially new SDK prototype". It's not simply "hey, we developed this, use it". It takes time to first build something that's barely usable, understand and get feedback of how it can integrate in the developer's workflow, ask developers to add another dependency and another level of testing which incurs in costs both for AMD/Nvidia and the developers. While all of that is happening you have your boss knocking on your door asking "why are we losing to the competitor?". That applies to mid-level management as to game developers.

AMD using the described method (injecting DLLs into the games' processes) is as terribly hacky as it is a good of a short/mid term plan. Of course, that doesn't rule out the long term plan of talking with developers for a proper, longer term plan.

At the end of the day I find it quite positive that we have at least 2 companies with 2 different strategies for the same problem. If anything, that means we learn with it and we have more variety to choose from.

[โ€“] [email protected] 1 points 10 months ago

I work in Software Dev, not the games industry but the approach really shocked me, it seems a bit too cowboy for a big company, what you said may make sense from a project manager point of view but I would have expected the developers to push back with concerns about:

  • It being easier for them to produce an SDK that can be offered to partners than produce a library and find hook points in games to inject it into (might end up being a bit easier than this work being multiplied per game as these hooks probably exist at the engine level)
  • Hooking into DLL function calls being an extremely fragile way to build software. I'd be surprised if any tech lead signed off on this approach.
  • Anti-Cheats in the games they are trying to inject code in are designed to attest that the game's memory has not been modified and it's integrity is maintained. How is our solution compatible with this?
    • Research task is created and developers / project managers reach out to partners to discuss.
  • Legal concerns, hooking into DLLs in most proprietary games as well as any other modifications are often banned in the EULA.
    • Task created to reach out to legal.

On the communication side, I can see that being something that got missed, it often breaks down when there is far too much pressure to deliver but most devs really care about the quality of their software so the technical counterpoints would surprise me if they weren't raised. I imagine they probably were but somewhere high up a decision was made to go ahead regardless.

load more comments (2 replies)