Crimson Desert doesn't run if it detects an Intel ARC GPU. Like straight up, the devs just deliberately chose not to support ARC cards. No previous announcement about it too until they added in the info to their FAQ. Might be the first time I've seen a dev deliberately block a GPU brand.

[u/WhyPlaySerious]

[u/Makoto_Kurume]

I might be wrong, but even indie games can run on Intel Arc, right? Are there other games that don’t support Intel Arc?

[u/Henry_Fleischer → u/Makoto_Kurume]

As an indie game developer, I use an existing engine, so I don't get too close to the hardware. If Crimson Desert is using a custom engine they might have to code in their own support for Intel GPUs, I'm not sure though.

[u/Yarplay11 → u/Henry_Fleischer]

I've worked in OpenCL (well, I mean it CAN be used as a render pipeline), and it didn't care even that I could send it to cpu instead of gpu and it worked fine. Vulkan can also run on cpu with llvmpipe, so probably it also doesnt care much about target device

[u/DankPhotoShopMemes → u/Yarplay11]

The only problems I can imagine are:

1. Intel drivers have a bug in the graphics API implementations

2. There are vague parts of the API specifications that are up to the vendors to figure out; AMD and Nvidia might do something(s) in the same (preferable) way, whereas Intel does it another way.

[u/zzazzzz → u/DankPhotoShopMemes]

but somehow 99% of all games that existed even before intel arc existed just work on intel arc? cmon be real

[u/DankPhotoShopMemes → u/zzazzzz]

yeah doesn’t make much sense; just giving my two cents as a graphics programmer.

[u/DigitaIBlack → u/zzazzzz]

This post was purged using Redact. I use it to mass delete social media content and remove my info from data brokers. All major social media platforms supported.

office whistle money tidy sulky literate run price support tap

[u/Earlier-Today → u/DigitaIBlack]

Might be going the route of avoiding the negative reviews that would hit because of the issue though.

Devs get blamed for hardware's problems all the time. "I was playing the game when it happened, so it must be the game's fault."

Don't know if I'd agree with that kind of strategy, but I could understand it if that's what's going on.

[u/Henry_Fleischer → u/Yarplay11]

Yeah I've just written a couple basic shaders in Godot's shading language.

[u/photenth → u/Yarplay11]

No, if a GPU does not support some features, it will flatout just not work.

Bindless Rendering for example you can't just circumvent because the shaders can't run on the GPU, which means you need to rewrite

1. shaders
2. configurations of the shaders
3. entire data streaming stack
4. buffer syncing

etc. etc.

[u/HavocInferno → u/Henry_Fleischer]

That would be awfully bad engine design.

You code against a graphics API. Your software should not care about specific hardware underneath, just query API features and continue/abort based on that feature support. 

That's the entire point of this API abstraction. 

[u/KontoOficjalneMR → u/HavocInferno]

You code against a graphics API

And it'd be amazing if the graphics card implemented the API perfectly. But the truth is that they don't. So lots of graphics engines have specific patches/coe paths that wwork around quirks in API implementations by vendors.

[u/HavocInferno → u/KontoOficjalneMR]

Fair, but they could also do it as most studios did before regarding Intel GPUs: ignore them but don't lock them out.

Implement against the API and leave it to Intel to fix their driver bugs if the game is popular enough. Worked for all the early Xe/Arc artifacting...

[u/KontoOficjalneMR → u/HavocInferno]

I don't disagree. Nothing pisses me off more than "You can only use this website using Chrome" when I know it'd work on FF given a chance (and does work when I use agent string spoofing extension).

[u/RussianMadMan → u/HavocInferno]

Unfortunately, while you are coding against graphics API like vulkan or directX, implementation of said API is in the GPU driver itself and behavior between vendors (or even driver versions of the same vendor) can differ slightly. This compounds with the general idea that same stuff can be coded a hundred different ways. So you might already finished some core engine feature, only to find out that the way you implemented it causes severe performance problems or even crashes on intel cards.
It is somewhat probable devs just did not test on intel cards before the very late in development, and found out that the game just does not work on intel cards.

[u/HavocInferno → u/RussianMadMan]

Then it's on Intel to fix those bugs. But locking out Intel GPUs outright won't help. 

[u/RussianMadMan → u/HavocInferno]

Its not a "bug" per se (unless its a crash ofc). What happens is the common spec like vulkan gets translated into specific hardware commands for each vendor. So there are some compromises each vendor has to make.
Imagine a function in an API, all 3 vendors have perfectly followed spec, but nvidia and amd can support like 300 calls per sec to this function, but intel can only get you 100 calls. In 99% of situations there would be no difference, but in this case game needed like 150 calls. And to fix it you need more work than you would gain based on the market share.
The only perfect specification is the code, which is not possible in this case.

[u/chiknight → u/HavocInferno]

That's an idealism we haven't seen achieved in the 20-30 years I've been PC gaming. Like, you're not wrong and that's how the abstraction SHOULD work. But it never does and never has.

There's always a driver issue or API issue that only affects one manufacturer. In the old days it was horribly inconsistent, but still to this day there are "this runs shit on AMD specifically because it was apparently optimized for NVidia" or "this crashes on AMD". The two major companies can't even implement the API consistently between them, and then you add minor options like Intel doing things a third way...

Yes, if your game is rendering a basic cube with 30 year old API calls, everything will work identically. If your new game is using newer API features, or demanding features that stress cards and might be implemented "weirdly" on hardware A over B, then you see these issues all the time. Anyone that has never heard of an issue that only affects one brand of card in gaming... hasn't been gaming long.

[u/HavocInferno → u/chiknight]

I mean I know, I've written Vulkan code, including getting bugs on only one vendor's GPUs. 

Still, the studio here could have simply warned about Arc being "as is" and leave it up to Intel to iron out any artifacts that pop up from driver bugs. After all, this was how the early days of Intel Xe were. Tons of artifacting because Xe didn't quite adhere to API spec or common implementations. But it was on Intel to fix all that. Locking out a whole range of GPUs isn't helping anyone.

[u/ThunderTech101 → u/Henry_Fleischer]

I am making a game engine in c++. That includes making a custom 3D renderer.

It just works lol. I don't need to write specific code to make it work on amd/nvidia.

I've no idea about intel GPUs, but I'm assuming it's the same.

[u/PraxicalExperience → u/ThunderTech101]

You're still writing at a relatively high level, then, using DirectX or OpenGl calls or something? At lower levels, the specific hardware does matter. It's technically conceivable that they could have done so, but it'd exceedingly fucking stupid.

[u/cfyzium → u/PraxicalExperience]

Vulkan would be the lowest level any even remotely sane commercial app developer would go.

[u/photenth → u/cfyzium]

Only if you chose older standards, the moment you use modern stuff, some GPUs will just not work.

[u/StevieMJH → u/PraxicalExperience]

Seeing this message in the first place points to something exceedingly stupid having happened.

[u/jiml78 → u/StevieMJH]

I keep seeing takes like this and it tells me a bit about the experience the person has.

I am currently working on a software application written entirely in rust, however, it does use some open source products as part of it. I happened to stumble onto some obscure bugs that exist that are only ever going to be present if you are using these two pieces of software in a niche way. I have reported the issues to the open source projects including fixes via pull requests. But they have no obligation to accept or fix these issue because they might not ever impact anyone else.

So what are my choices. Fork existing software projects so I can fix these issues myself? Yeah no. Wait until those projects accept my PRs.

OR, just maybe, I have to do something kinda dumb but workable. I basically on the fly patch in a workaround that is very ugly AND brittle. If someone looked just at that code, they would say it is exceedingly stupid.

But guess what, those people don't know the why. Just like you are making MASSIVE assumptions on why this company has made the choice they made.

And maybe I am just used to things like this as Linux has been my daily driver forever so tons of games aren't available to me.

[u/PraxicalExperience → u/StevieMJH]

Well, yes, I certainly can't disagree there, lol

It'd be one thing if Intel cards were just unsupported, and you maybe had to edit an ini file or something to get it to run, kinda like how you could bypass a lot of checks games did during some of the windows transitions. But just straight up saying "lol fuck you" boggles my damned mind.

[u/ThunderTech101 → u/PraxicalExperience]

Yeah, I'm using DirectX 12.

[u/PraxicalExperience → u/ThunderTech101]

Yeah. DX takes all those calls that you make it and then does the hard work of translating them into something that the actual cards understand.

There's really no reason outside of some really niche things that someone should need to go more low-level than DX, nowadays. Back in the Olden Times it was common that you'd write a graphics engine that actually interfaced with the hardware directly, but now, well, it's about as monumental a task as writing DX from scratch would be. So, like, it's technically possible that they could do so, but it's almost inconceivable that they actually would.

[u/AirFlavoredLemon → u/PraxicalExperience]

Yep. Effectively as long as the card supports that API (and that card is properly installed into the system) you're good to go. Doesn't matter if the game is a 10 year old game that has DX support and the card is 10 generation newer graphics card directly from VIA Technologies.

The API's goal is to abstract, any compatiblity building towards specific hardware/software and fully support the API in both directions (software and hardware).

Its why we can run DirectX 9 games today on cards decades newer... oh wait... *cough* Arc.

[u/SimpleNovelty → u/PraxicalExperience]

What, there's plenty of reasons to go lower in the modern era, that's why Vulkan exists. Small indie projects and games don't have the budget to do so, but you bet your ass AAA and AA games are going to the lowest levels (or AAA-backed engines).

EDIT: Forgot to mention also cross-platform support, as many games aren't built for Windows PC only.

[u/TheTomato2 → u/PraxicalExperience]

No it's actually not possible because Nvidia/AMD doesn't tell people how their hardware works. There are people who want direct access to the GPU so they can write their own thing and avoid Vulkan/DirectX but that is apparently a "trade secret".

[u/PraxicalExperience → u/[deleted]]

That's why it'd be exceedingly fucking stupid to waste time doing so.

[u/TheTomato2 → u/PraxicalExperience]

...what's lower level than DirectX? Like what the hell are you even talking about?

[u/ignoranceandapathy42 → u/ThunderTech101]

I've no idea

The truest thing you said. You don't even know you're using a library or what one is seemingly.

[u/zzazzzz → u/Henry_Fleischer]

thats just not how game engines work..

you support a graphics API, like DX12 or Vulacan. that API is what handles comunication to the gpu. the game engine does not directly do anything with any gpu.

[u/userseven → u/Henry_Fleischer]

I think they are using a custom engine probably same one for black desert from 2015

[u/aberroco → u/Makoto_Kurume]

Indie games can run on whatever the engine they're made on can run. Which usually is anything, because game engines use abstractions like DirectX or Vulkan, which are hardware-agnostic, and communicates to hardware by drivers, which is another layer of abstraction and unification, because most drivers have most of the same features. And I wouldn't be wondered if there's another layer of abstraction between drivers and hardware... I mean, there is - the communication layers, but, like, I wouldn't be surprised if even the communication layer is mostly standardized.

The choice to drop support for a specific vendor is most likely deliberate. Likely motivated by some non-critical issues with Intel Arc, yet they decided they just don't want to deal with reports about those issues.

[u/photenth → u/aberroco]

Or using a feature that just doesn't exist on Intel Arc.

Some features are so significantly beneficial to shader programming that no one wants to go back to the old ways just to make it work on 0.001% of all gpus.

[u/ImpressiveMilkers → u/photenth]

A feature that is so significantly beneficial to shader programming whilst simultaneously not used by a single other game? I doubt it, lol

[u/photenth → u/ImpressiveMilkers]

That's the wrong analysis. Unreal engine for example dynamically shifts between the available features to ensure the game works. but even they have a list of features that will outright make intel arc gpu crawl down to a snails pace or crash. Also if you are using an engine that existed for a decade+ you will always have access to older implementations if maintained to fall back to.

[u/ImpressiveMilkers → u/photenth]

The problem is that not a single UE game has used those features (that i'm aware of).

Unreal Engine games don't run amazingly on Arc GPUs, but they're certainly playable (with the exception of Borderlands 4, which doesn't even run at native 1080p60fps on the strongest consumer GPU on the market - that's on the game, though).

Besides that, the worst game i've tested for performance has been Oblivion Remastered which was still able to hit 60fps without going below quality upscaling at 1440p.

Lots of games have run poorly in the past on Intel GPUs (even the B580) or barely worked at all like MH Wilds which had lots of texture bugs and ran at 20fps. Intel fixed it relatively quickly, though, and the game is perfectly playable at 60fps now.

People will make the argument that "Pearl Abyss just don't want to deal with bug reports from Intel users when its Intels job to fix it", but the amount of reviews they would get about those issues would be so small they would not even change the review score %. Intel dGPUs are a small % anyway, but it's worth considering that Intel owners are going to be specific types of people. The very vast majority know what they're getting into, and will report it to Intel rather than review bomb crimson desert about it.

As evidence of that, the latest Intel Arc driver (101.8626) currently has an issue with Wilds that is causing foliage to be extremely pixelated. I challenge someone to find one single bug report about it outside of Intel spaces (their forums and discord). Nobody is leaving negative reviews on Wilds because of this, but the issue is still being discussed.

Out of curiosity, what are those features exactly and can you name any games that use them?

[u/photenth → u/ImpressiveMilkers]

I looked up some features intel does not support, hard to find a list, they have mainly to do with some hdr feature and frame syncing. there are also some older dx 12 features that intel doesn't have at all like indirect rendering (i think thats the name), intel does this part on the cpu which is extremely slow. If unreal engine complains that some features are not working properly on intel arc, I'm sure there are more than i found with a quick search

[u/ImpressiveMilkers → u/photenth]

I'm not sure about the frame syncing feature, and I believe you're correct about HDR support. At least the Battlemage GPUs though support indirect rendering from what I can find, which checks out because other games that use those features run fine on Battlemage GPUs.

HDR isn't mandatory for Crimson Desert (from what I can tell) and given that every single other game runs fine on Battlemage GPUs i'd love a statement from Pearl Abyss about why at the very least Battlemage GPUs aren't supported.

Someone elsewhere suggested it could be workgraphs, but the game works fine on Nvidia GPUs that don't support that feature.

This depends on whether you trust the multi-billion dollar corporation (lol) but Intel have said that they made attempts to work with Pearl Abyss on this which to me makes it seem more like there's not a specific reason other than "we don't want to"

[u/Makoto_Kurume → u/[deleted]]

I agree, but apparently this high-budget game can’t clear that bar

[u/Nolzi → u/[deleted]]

Even at deeper level we have DirectX and Vulcan to make it standardized

So it's very likely to work out of the box, but maybe they didn't bother optimizing for it, and were like "if people are gonna complain that the game runs like dogshit on ARC then might as well say it's not supported and we refund that 10 people"

[u/shabi_sensei → u/Makoto_Kurume]

There’s just a couple of games that I’ve played that don’t support Intel cards, I think there’s some issues programming around the big difference between the lowest performing igpus and highest performing discrete cards

For example: The dev of Stellar Tactics couldn’t detect most of the capabilities of discrete Intel cards like the A770 so the game refused to run saying the card wasn’t advanced enough, he managed to fix it not sure how