Check out our Monthly Survey Page to see what our users are running.

With The International 2021 tournament fast approaching Valve has given an update on the future of Dota 2 with some major underlying tech changes planned to come in.

For most players you won't see many issues, since the vast majority of machines are already 64bit and support Vulkan. Valve say they're making changes to " keep the game and the Source 2 engine fresh". For Linux it means Vulkan by default, no 32bit and they're also swapping from XAudio over to SDL Audio. Windows will also be bumped up to DirectX 11.

There's no date set on when other than in the coming months.

As for the upcoming TI 2021, tickets will go on sale on September 22 and will require attendees to by fully vaccinated against COVID-19 and you will need to bring a mask too. There's more outlined in the FAQ. When open, tickets will be available from this link.

The International Dota 2 Championships at National Arena begin with Group Stage October 7 - 10, with the Main Event at National Arena October 12 -17.

Some other in-game changes are coming too with free access as of now to the The International 2021 Compendium, allowing everyone to collect Player Cards and check out the Talent roster, with more of it unlocking as the event gets closer plus there will be some special event items too. On top of that Valve also updated the Spectator HUD, the Camera, some improvements were also made to Graphs as well.

Article taken from GamingOnLinux.com.
Tags: Event, MOBA, Upcoming, Update, Valve | Apps: Dota 2
11 Likes
We do often include affiliate links to earn us some pennies. We are currently affiliated with GOG and Humble Store. See more here.
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly.
See more from me
17 comments
Page: 1/2»
  Go to:

Naib 17 Sep
View PC info
  • Supporter Plus
Interesting,
That might explain why the vulkan cache feature has been broken for the last 3weeks... Something is in the works

It's a bit annoying having to play with cache disabled at the moment as it takes a good few minutes for the interface and game to smooth out, but this is all completed before stuff really happens
mphuZ 17 Sep
SDLAudio? Not FAudio?
t3g 17 Sep
If they are going through the effort with Vulkan on Linux and upgrading Windows to DirectX 11, why not just use use Vulkan on Windows too? Figured having to target one renderer would make things easier.
WildCoder 17 Sep
@t3g you took the words right out of my keyboard! Why not Vulkan use everywhere and maintain one renderer going forward...
Skipperio 17 Sep
Quoting: t3gIf they are going through the effort with Vulkan on Linux and upgrading Windows to DirectX 11, why not just use use Vulkan on Windows too? Figured having to target one renderer would make things easier.
well for one there are more GPUs supporting officially DX11 than Vulkan. It would be stupid to loose player base/income stream just because you feel like it. On Linux it makes sense because GPUs that can run DotA with proper framerate usually have already vulkan support(plus they can experiment more with us )


Last edited by Skipperio on 17 September 2021 at 3:16 pm UTC
hagabaka 17 Sep
View PC info
  • Supporter Plus
I hope it will make the download size smaller!
Phlebiac 18 Sep
Quoting: t3gIf they are going through the effort with Vulkan on Linux and upgrading Windows to DirectX 11, why not just use use Vulkan on Windows too? Figured having to target one renderer would make things easier.

I suspect they are using DXVK for the Vulkan support (like the previous version used ToGL rather than native OpenGL support).
thedukesd 19 Sep
Vulkan only in Linux => less players

Did they ever made Dota 2 to work properly with DX11 and AMD gpus? Because the Windows AMD gpu drivers are pure trash when it comes to DX11 since DX11 was released and situation will never improve because AMD never cared about DX11 to begin with.

DX11+ in Windows => less players
Vulkan implementation in Windows is affected by texture corruption that was never ever fixed (affects all gpu not limited to AMD).

Amd has open sourced drivers only because it's not capable to make decent drivers. Mesa devs expect developers to fix their games to work with Mesa, ignoring that maybe nobody works at that game and that the path for Mesa is trash bcause maybe Mesa was unusuable when the game was finished...
Even now the mentality of Mesa devs is problematic because well they care only about academical tests and surprise surprise nobody in the gaming industry gives a coin on their engine following academical papers...
And you start to wonder what is the purpose of Mesa when almost nothing follows the academical papers...
When you expect others to change their code to work with your stuff you should start to use your head and understand that maybe others also expect you to change your code so their stuff works with your stuff. If you take the force possition you gonna find out that well your work is not really usefull...
(If we play the game of numbers there are more people not working for Mesa expecting Mesa to change their code to work with their stuff than Mesa devs/coders/contribs and if we use democratical rules then well Mesa should adjust their code... just following some academical rules and not caring about real world situation makes your work not that usefull, theory and practice are miles away).
Curent Linux desktop market share is the result of the situation with the drivers in Linux and the 101 changes that make your stuff plain not work on a new kernel,x.org version. Compared it to windows, such compatibility issues don't happen at such scale (exclude here win 11 with their artificial cpu req, we had same retarded discussion in some linux distros also so no surprises, i assume having 2 kernels one for fancy new hardware and one legacy is well really hard if they really want to go that route, but well that requires to use the brain a bit something that those days looks to be something extremely hard)...

I don't really like what I see here https://steamcharts.com/app/570 regarding the players numbers. After those changes those numbers will be lower.
Those numbers are already extremely problematic to properly calculate the elo/mmr of a player (most don't even play ranked and if you need 10 players to start a ranked game you are either forced into 30+ min waiting time to match similar elo/mmr player or mix low and high elo/mmr players in same game making the experience infuriating for everyone).


Last edited by thedukesd on 19 September 2021 at 4:53 am UTC
omer666 19 Sep
Quoting: thedukesdEven now the mentality of Mesa devs is problematic because well they care only about academical tests and surprise surprise nobody in the gaming industry gives a coin on their engine following academical papers...
And you start to wonder what is the purpose of Mesa when almost nothing follows the academical papers...

From a pure engineering point of view, they are right: implementing quirks inside graphics drivers is not convenient and complicates maintenance, which is even more of a problem for an open source project. You take the example of Windows but even in that case, there are many workarounds in games depending on your GPU type, so you are looking at two moving targets

That's where Zink and DXVK enter the scene.
My understanding is that you can't make a non-standard implementation of Vulkan, so it has no workarounds in-driver. The translation layer, on the other end, can maintain all those quirks. To me, this is the best solution from a technical point of view: Mesa takes care of implementing the latest standards, and Zink and DXVK take care of maintaining compatibility.
thedukesd 19 Sep
Quoting: omer666From a pure engineering point of view, they are right: implementing quirks inside graphics drivers is not convenient and complicates maintenance, which is even more of a problem for an open source project. You take the example of Windows but even in that case, there are many workarounds in games depending on your GPU type, so you are looking at two moving targets

You are assuming here again that the game was developed when Mesa was at some sort of use. Back in fglrx times Mesa was not usabled.
You are assuming that games developed during those times still have the people that worked at those engines alive. Sorry to inform you that some of them are dead.
In such situation you are the project coming from behind and you are the one fixing the crap, because it's Mesa crap cause it was in that unusuable state.
When those games have maybe 1 person working at them that well is not familiar at all with the 3d engine you do realise that well that single person already has problems keeping that code still running due to how well the linux enviroment is not capable to keep backward compatibility. (It goes with newer compiler not really compiling the code, old compilers not really working with the other new things, patched libraries to fix some vulnerabilities that totaly brake backward compatibility and so on...).
Usually the people that worked at the 3d engine are the first ones to move to another project (maybe working for someone else) (once the engine is done their job is mostly done, if you don't assign them to another project your financial department will get them fired)... So you gonna have someone not familiar with that code trying to fix it at best, as if that will really work...

If you take something compiled 10 years ago for Windows it will probably still work, if you take something compiled 10 years ago for Linux it will not really work. This is why the first is more appealing. And the linux devs are not really helping at all, starting with their attitude.

Quoting: omer666That's where Zink and DXVK enter the scene.
My understanding is that you can't make a non-standard implementation of Vulkan, so it has no workarounds in-driver. The translation layer, on the other end, can maintain all those quirks. To me, this is the best solution from a technical point of view: Mesa takes care of implementing the latest standards, and Zink and DXVK take care of maintaining compatibility.

Both zink and dxvk implementation are incomplete and I really doubt you will ever see a complete implementation (zink because you will first need to have every bloody obscure opengl extension that ever existed implemented in mesa (i'm unwilling to help mesa devs due to the only interaction i had with some of their devs; applies to kernel also due to one interactions with Linus himself; when they will show me they learn to behave i will think about it, not exactly sure how this can happen when i kinda refuse to interact with them; only thing i will say about this is that if i want to see wild animals i go in the wild or at zoo, i also can't treat humans similar with wild animals because if i treat them like wild animals then i will shoot humans at first sign of aggresion), dxvk because well there are some things about dx that you will never find in the documentation, you are free to reverse engineer that part with the legal problem that comes with such thing).

I don't consider dxvk, zink or similar as a real solution. It opens the door for things that just shouldn't be allowed.
Wine, proton are one of the worst thing that could happen in linux. (Why would a dev even take into consideration to get something native for linux when it can start will get win/proton work with my windows version...)

Ofc you can implement a Vulkan engine in a weird way.


Last edited by thedukesd on 19 September 2021 at 8:39 pm UTC
While you're here, please consider supporting GamingOnLinux on:

Patreon, Liberapay or PayPal Donation.

This ensures all of our main content remains totally free for everyone with no article paywalls. We also don't have tons of adverts, there's also no tracking and we respect your privacy. Just good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
Login / Register

Or login with...
Sign in with Steam Sign in with Twitter Sign in with Google
Social logins require cookies to stay logged in.