Join us on the Linux Gaming community on Lemmy, the federated open source alternative to Reddit.

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: «2/2
  Go to:

pskosinski 19 Sep
I am using Manjaro and proprietary driver for NVIDIA GTX 1660Ti. On OpenGL I have 140+ fps (not really sure how many because I limit fps to 144). On Vulkan I have 15-30 fps. The difference is huge and Dota 2 on Vulkan is unplayable for me.

When comes to shader caching: it's not broken for last 3 weeks. It's broken for a year and it was being reported multiple times to Valve on GitHub, they didn't change anything in a year to fix shader caching process leaking memory until the operating system gets unresponsive. And now they want to force people to use it.

Edit. Okay… I just tried Vulkan again and it seems to work much better than 2 months ago, last time when I was trying it out.


Last edited by pskosinski on 20 September 2021 at 12:05 am UTC
omer666 20 Sep
Quoting: thedukesdYou 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.
I am not assuming anything. Of course it comes with a lot of inconvence for the end-user, what I am saying is that whether it's Mesa devs who are wrong is debatable.

About DXVK, it is now used in native Linux gaming, with great results. Also, Zink is used for native software as far as I know. This is not only about Wine gaming anymore, even if it is still DXVK's main use-case by far.


Last edited by omer666 on 20 September 2021 at 6:31 am UTC
thedukesd 20 Sep
Quoting: omer666I am not assuming anything. Of course it comes with a lot of inconvence for the end-user, what I am saying is that whether it's Mesa devs who are wrong is debatable.

A game coded 10 years ago (even 5 years ago Mesa was still not an option to take into consideration) that has one render path for nvidia proprietary drivers and one for flgrx (no point to take Mesa into consideration at that point in time) today it fails to run even if you try to use any of the 2 renders paths with Mesa.
At that moment in time the devs actually cared about the 2 real options, Mesa was not an option at that point. Game is still happy working with nvidia proprietary drivers and well with fglrx,on an antique distro in this last case, yet it's garbage at best with Mesa (when it doesn't plain crashes).

Who do you expect to fix such a game?
Mesa devs will say no.
If you managed to find someone that somehow maintain that game you will be told that it's Mesa job to fix the situation (telling you that Mesa didn't had the futures required by the game when they finished the game so they just couldn't take it into consideration).

And next time someone that worked a this game will be asked about Linux support you might get an answer like "Linux sucks" and nothing else. And that person is partially right, there have been companies that well didn't wanted to release the documentation for their product but hired 2-3 coders to get a driver for linux (they don't have to release the documentation) and canceled the entire linux support in 1 year because their coders were busy to get the code they already done to actually work with the latest kernel... basicaly what they were building was being partialy destroyed... When such behaviour will stop in linux world things will be better, but I don't think it will happen before the kernel will end up poluated with code that follows Linus coding rules but is almost unusuable with the hardware that it supposed to support (wonder how many years have to pass until some realtek code is removed from kernel because it's totaly unusuable with the hardware it supposed to support since it was upstreamed, not realtek code btw).
When they will accept the idea of exposing stable API for drivers that will never be upstreamed hardware support might improve conderable, might cause some might just not believe that the stable API will actually be stable. This will actually help people that want to upstream their drivers, because they will not have to rework over and over parts of their code when someone has an idea that happy breaks backward compatibility. It will actually get more open source drivers for hardware that totaly lacks support atm. But ofc nobody cares about what's not upstreamed and they expect the manufacturer to release complete documentation.
The hole point is that this behaviour is not Mesa specific, comes from Linus himself... And it's totaly wrong and doesn't produce anything good (because people will just ignore you and prefer something that well doesn't look like moving sands...)

I've read some people accusing realtek for making a couple of drivers for a couple of kernels (kinda never the latest), not trying to get it upstreamed and at some point just stopping. Well picking a LTS kernel and making a driver it is the way to actually finish the driver. The resources you allocated to make a driver for a LTS kernel are considerable less compared to the attempt to get it upstream (due to the work needed to make your already existing code work with the latests kernel that happy broke something in your already existing code...).

If to code a driver takes 1 year for a LTS kernel, to get it upstream it's in the area where it doesn't worth the effort...

Quoting: omer666About DXVK, it is now used in native Linux gaming, with great results.

That's not what I call native Linux client.
Translating the call will increase the system requirements considerable compared to a decent native implementation.


Last edited by thedukesd on 20 September 2021 at 7:00 pm UTC
omer666 21 Sep
Quoting: thedukesd
Quoting: omer666About DXVK, it is now used in native Linux gaming, with great results.

That's not what I call native Linux client.
Translating the call will increase the system requirements considerable compared to a decent native implementation.
Still the large majority of Linux ports use an API translation layer (Valve uses ToGL and Feral have their own technology for this.)

About kernel compatibility, the only game I had trouble running recently is Enemy Territory Quake Wars. I honestly don't know how good Mesa support is in general, and I get your argument about compatibility, but it sounds more like a rant against Linux development model than a real discussion about graphic APIs and how they are handled in Linux.
pskosinski 21 Sep
Just tried playing a full game on Vulkan and it's pretty much as bad as it was a year ago. On OpenGL 144+ fps, on Vulkan around 40 and sometimes dropping even to 1 frame per 3 seconds. GTX 1660 Ti and i5-9400F. Additionally, I noticed that when I alt+tab out of Dota to other window then Dota starts leaking memory and my system freezes, but only when using Vulkan, it doesn't happen on OpenGL. Seems like I will need to leave Dota when they drop OpenGL.
thedukesd 22 Sep
Quoting: omer666Still the large majority of Linux ports use an API translation layer (Valve uses ToGL and Feral have their own technology for this.)

The fact that it's often used doesn't make it a good thing...

Quoting: omer666About kernel compatibility, the only game I had trouble running recently is Enemy Territory Quake Wars. I honestly don't know how good Mesa support is in general, and I get your argument about compatibility, but it sounds more like a rant against Linux development model than a real discussion about graphic APIs and how they are handled in Linux.

It's not only the kernel. Even compilers are a problem. There have been cases when compiler xyz in version .13 (minor version) was failing to compile the code for it's prev version something that sorry to say but it's totaly dumb.
The problem i talk about is not Mesa only, the entire Linux enviroment is affected by it. And it's actually a big problem.

If you have a problem with your engine you will get no help at all from Mesa devs (answer is something like not our problem we don't care (what is the purpose of your project if you don't care when stuff doesn't work on it?!? only thing that can come out of this is the devs of the game posting a screenshot with the discussion they had with someone from Mesa and telling they don't support Mesa in those conditions and everything related to game not working with Mesa closed with a link to this post and next time not even taking Linux into consideration (this is exactly why you have a low number of native Linux games))) on the other hand Nvidia will happy help you get your code working with their proprietary drivers (won't really work with something else :p)...

If you want to talk about kernel, the kernel type is now a big problem. Expanded to support too many architectures despite the fact that it totaly lacks any real way to control that the code submited by other people actually works with the hardware it say it supports (and this is how there have been drivers upstreamed that are for years there despite the fact that not even basic functionality works. When Linus picked the kernel type he totaly ignored that the hardware he will support will make it impossible for him to actually find out if the code he is receiving for others actually works with the hardware or not.
Worst part regarding such situation is that bug reports regading such cases are ignore and the crap stay in kernel for years...

Something like hd 7750 that is capable to run dota 2 at decent fps with OpenGL will not really run this game with Vulkan.

The drop for 32 bits is debatable also. The are some cpus (amd pre ryzen) that despite having full support for 64 bits underperform when runing 64 bits applications (both in linux and windows...). Those cpu are capable to run Dota 2 at 1080p.

In linux it often looks like they don't want to make things actually work based on how bug reports are answered... (and it's not wanting when you have 100+ people reporting the same issue and you as single dev answer that it's their particular enviroment totaly ignoring that they have 100 enviroments while you have only one, and refuse to even add a driver parameter to control that function despite having tones of reports regarding it causing problems, hiding that function behind debug functions only to make it damn hard to disable it despie reports after reports after reports of it causing problems. and after 6 years of destroying his own work, there are 6 years of trash changing in this case, he moved to another project that is in a similar awfull situation... and he is considered a reputable linux contrib... maybe the code looks clean, but that code is pure trash when it comes to actually working with the hardware...).

A code that is not clean but works fine with the hardware can be fixed by someone that doesn't have access to that hardware, a code that is clean but doesn't really work with the hardware can't be fixed by someone that doesn't have access to that hardware. What happens now in Linux is part of Linus fail theory regarding the quality of code, he just looks if the code is clean and not if it actually works with the hardware, in ideal conditions you want both, in practice you prefer code that works fine with the hardware cause you or someone else can make it clean later...
When you look at the first one (code is clean) you pick the easiest and useless way... Linus is in this situation because he refused to do some things that he was asked several times...


Last edited by thedukesd on 22 September 2021 at 6:41 am UTC
omer666 22 Sep
Quoting: thedukesd
Quoting: omer666Still the large majority of Linux ports use an API translation layer (Valve uses ToGL and Feral have their own technology for this.)

The fact that it's often used doesn't make it a good thing...
It's not used "often," it's used, like, almost all the time.
Quoting: thedukesdIt's not only the kernel. Even compilers are a problem. There have been cases when compiler xyz in version .13 (minor version) was failing to compile the code for it's prev version something that sorry to say but it's totaly dumb.
The problem i talk about is not Mesa only, the entire Linux enviroment is affected by it. And it's actually a big problem.
I'm aware of this, but binary and/or compiler compatibility come at a price too. Take Windows for example, there is an even greater deal of bugs, quirks and outdated technologies that are carried from revision to revision for the sake of binary compatibility. If that's what matters to you, you are free to use Windows, it is the best OS in that respect.


Last edited by omer666 on 22 September 2021 at 3:17 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.

Livestreams & Videos
Community Livestreams
Latest Forum Posts