Quoting: TheSHEEEP

Quoting: x_wingI really fail to see how forcing that the activation of a key on every country of the EU will not translate in the same rule for anyone that wants to buy a game using a VPN and a foreign credit card.

Thankfully, that fear has been proven wrong over the last decade and if you look at the store, somewhat varying prices within the EU are normal (for devs/publishers that bother to set them up to begin with, which some don't).
Laziness / convenience trumps everything - as long as Steam does not on its own and automatically offer you the cheapest price you could legally get, such a scenario won't happen.

Bare in mind that most of the time is not only related to the laziness of one user. If you ban the majority of the counter measures a store can use, there is a chance that a third party can exploit this backdoor and create a business around it that will definitely simplify the steps that a user has to follow in order to get their games for cheaper. Eventually there will be a unique aftermath: In EU countries with higher income will get prices slightly down and the in countries with lower incomes will get them slightly up (the market will search for that point were a third party cannot get profit). And of course, is kinda sad that the ones that more have get a discount at expense of lower incomes markets.

IMO it's always better to keep things as simple as possible. So, maybe the rule should have been that if you get a key that you cannot activate in your country, the seller is obligated to refund your money.

View this comment - View article - View full comments

Quoting: minfaerTo everybody discussing the sense of regional pricing: That is still legal and all in the EU. The only thing they are no longer allowed to do is preventing people from buying their games in other EU countries by refusing key activation (aka geoblocking).

Interestingly, from the latest law that obliges online business to let people from the EU access the offers from any EU country and forbids denying a sale based on location in the EU, digital goods "audiovisual services" (I believe this includes games and movies) are exempt. Definitely movie-industry lobbying in action there.
See here [External Link]

Edit: More precise about exemption, added source.

From what I can understand on your source, what the EU is doing is to limit the tools that have some online sellers in order to filter which users are allowed to buy something on their market place. The EU may not actually banning regional pricing but if you ban the tools that allows the enforcement of this limitations, you may end up making impossible the regional pricing (ipso facto: many stores may end up removing regional pricing).

Your source is definitely more oriented for physical goods but based on the current article, it seems that in the near future the plan is to force all license to work in every country of the UE. And unless they create an specific rule for software licenses, I really fail to see how forcing that the activation of a key on every country of the EU will not translate in the same rule for anyone that wants to buy a game using a VPN and a foreign credit card.

View this comment - View article - View full comments

Quoting: LordDaveTheKindI'm pretty sure Valve and Publishers alike did it for market reasons, not out of charity. Regardless of their intentions, blocking the access for someone from a different EU country to the same discounts is illegal.

Of course it's for market reasons. From a publisher perspective, selling a copy on Germany or India has the same cost so the price that will maximize earnings on each market is completely different.

I understand the idea of enforcing the UE as one country but is kinda difficult to understand this mindset when the same UE doesn't enforce a minimum wage for all their members.

View this comment - View article - View full comments

Quoting: ElectricPrismIt's funny looking back, back in the 90s "cheats" used to be a "feature" you literally paid extra money for a players guide or game shark or whatever to get special new capabilities.

There is still a market for that. Not long ago I watched a interview with a cheater that mentioned paying around 100 USD per month in order to get cheats for PUBG.

View this comment - View article - View full comments

Quoting: Liam DaweWorking with Mesa doesn't mean working with NVIDIA proprietary drivers though :)

I know, but you wrote "it's not clear if this will work on Linux though". The feature per se works on Linux but Nvidia has to use it in their drivers.

View this comment - View article - View full comments

NVIDIA will also be supporting "Resizable BAR" with the 30xx series, an advanced feature of PCI Express that can increase performance in games. It's not clear if this will work on Linux though.

The feature is already working on Linux (upcoming Mesa 21 already has the patches to make use of it on AMD GPUs). AFAIK, It's 100% up to them to make use of the feature on their Linux driver.

View this comment - View article - View full comments

Quoting: Alm888

Quoting: BielFPs…not following the standard of the linux support is…

I believe nVidia follows the standards, both Linux and Khronos Group.

There are many examples of games that doesn't work on Mesa because they seem to be only tested with Nvidia drivers and they don't follow the standard. You can believe what you want, but the facts are still there.

Quoting: Alm888Ideally, "their cards" shall not stop to "work well because of an update" because that, quite frankly, is against Linux rules. Or, more specifically, against Linus Torvalds' rules as he has always said "Do Not Break ABI". Sadly, other (both X.Org and Linux) developers are not so strict and situations when a GPU has stopped working due to kernel/xorg update breaking API (with subsequent recompilation failure) are not that rare.

I believe that you misunderstood what Linus said. First of all, the exact quote is "We do not break user-space", which means that a new kernel version should not break a program that was working fine with a previous version. As in this case we're discussing about a kernel driver then this phrase doesn't apply.

View this comment - View article - View full comments

Quoting: BrisseI've had both RADV and AMDVLK installed for a long time and it always used to be RADV that loaded first unless I specifically asked for AMDVLK using environment variable. I think the reason for this is that the icd loaders resided in different folders and the folder with the mesa drivers was checked first so it didn't matter that "r" as in "radeon" comes after "a" as in "amd".

This behaviour seems to have changed lately however, because when a saw this thread I decided to check again by launching a game in Lutris and checking the DXVK_HUD. Without specifying a driver by environment variable, it was now running AMDVLK for some reason.

I wonder if there was an update that changed the folder structure at some point. The AMDVLK loader is currently in /etc/vulkan while the RADV one is in /usr/share/vulkan.

Never tested with different directories, so my comment is probably isolated to ICD files loaded in the same directory (at least at the time of my testing).

For the curious out there, this are the directories that the vulkan loader searches by default: https://github.com/KhronosGroup/Vulkan-Loader/blob/master/loader/LoaderAndLayerInterface.md#icd-discovery-on-linux [External Link]

View this comment - View article - View full comments

Quoting: torbidoAMDVLK is now used by default? I do not like that at all.

If I remember correctly, installing AMDVLK or AMD Proprietary Vulkan drivers along side RADV makes them the default driver due that Vulkan Loader exposes the icd files in alphabetical order. This means that if an application selects the first available driver, it will default to AMDVLK. So, the problem is related to having the AMDVLK icd file name as "amd_icd64.json" while RADV driver icd named as "radeon_icd.x86_64.json". The solution: rename "amd_icd64.json" to "zamd_icd64.json" and RADV will be once again the default driver (bare in mind that if you installed your AMDVLK driver using some sort of distro package, this change will break a little bit the update/removal of the package).

But as strycore mentioned before, installing AMDVLK system wide is kinda pointless as RADV works better in 99% of cases.

View this comment - View article - View full comments

Quoting: pageroundI am happy AMD are contributing code, however I've been sticking with Mesa+RADV on my 5600 Fedora laptop as its been working great. Plays everything I can throw at it. Maybe with this change I'll try out AMDVLK in the future. Thanks for the heads up, Liam!

FYI, you can try AMDVLK and the AMD closed source Vulkan implementation by just installing these libraries into a specific directory of your system and playing around with VK_ICD_FILENAMES in order to switch from one driver to another. You will probably end up using RADV for everything, but I think it's always welcome to have the option to test the other vulkan implementations (in my experience, it can help to detect driver bugs or game bugs).

View this comment - View article - View full comments