Recommended Posts

I've never really understood how people can be so loyal over a graphics binding API, in the end it all comes down to driver quality and how good the hardware is. The original blog post about the performance difference puts it down entirely to the Linux drivers and how Source uses OpenGL compared to Direct3D. It's not that OpenGL is "faster" than Direct3D, it's that Source spends a few microseconds extra when it talks Direct3D.

I would bet the vast majority of people wouldn't be able to tell the difference between a game using Direct3D and a game using OpenGL, simply because there should be no graphical difference if it's done right, the people who would notice a difference are those with buggy/non-existent drivers, or those that checked what the game engine uses.

Indeed Max Norris. Like I said previously, I'm all for gaming on Linux if it is genuinely faster, but this 1 flawed comparison isn't going to convince me. I'm not going to make the switch just on the thought/hope that it's faster like the Linux fanboys do, I prefer solid statistical evidence. Bring on a fair testing ground of OpenGL beating DX11/11.1 please with the exact same feature set.

I'm sorry but that's kind of a given considering it's pushing the GPU to do a lot more visually than DX9 games do. Uses a lot more memory and requires a lot more computational power to pull it off.. yea its going to require more horsepower to run. Newer stuff (games, apps, whatever) typically always need more horsepower to run, this is nothing new or specific to gaming, or even DirectX. I'm sure throwing a crapton of work at OpenGL 4 is going to make it a tad slower than OpenGL 1 too dont you think?

And so you'll get an even lower fps. So by using Direct3D 9, that fps is higher than it would be with 10/11. That was my whole point.

Ah, no, sorry again, fully supports DirectX 11. Look for yourself. Even shows visually how it makes it looks a lot better than DX9. They're embracing DX11 head on.

http://mycryengine.c...dex.php?conid=8

The whole engine isn't built around DX11 though. The console and PC versions will ship with DX9 rendering. And like Crysis 2, the DX11 will not be enabled by default.

Again, see above, that's a given.. more math makes more work. (You do know that most DX11 games have an option to turn those visuals off for those with underpowered GPU's yea?)

Again, the point is, by using DX9, Valve is actually giving Direct3D an advantage because it doesn't use the latest technologies, and therefore as you said, it's less demanding for the system. If DX10/11 was used, I'm sure the fps disparity would be even greater.

Congrats on one benchmark being faster. I can show some recent published benchmarks that's completely the opposite where Linux falls short in performance.

Break out the benchmarks ;) I'm always interested provided they are fair, balanced, and recent. And if you're talking about the Unigine benchmarks, I should say that some of the performance bottlenecks that were fixed after Valve's bug reports also apply to that engine, so I'd wait for the fixes to hit mesa before parading them.

The original blog post about the performance difference puts it down entirely to the Linux drivers and how Source uses OpenGL compared to Direct3D. It's not that OpenGL is "faster" than Direct3D, it's that Source spends a few microseconds extra when it talks Direct3D.

Some of it is down to GNU/Linux and some of it OpenGL (it runs faster than Direct3D on Windows too). And the extra time wasn't spent in the source engine, but the Direct3D batch processing in Microsoft's code.

I would bet the vast majority of people wouldn't be able to tell the difference between a game using Direct3D and a game using OpenGL, simply because there should be no graphical difference if it's done right, the people who would notice a difference are those with buggy/non-existent drivers, or those that checked what the game engine uses.

On lower spec machines, a 20% fps difference can make the difference between playable and unplayable.

Indeed Max Norris. Like I said previously, I'm all for gaming on Linux if it is genuinely faster, but this 1 flawed comparison isn't going to convince me. I'm not going to make the switch just on the thought/hope that it's faster like the Linux fanboys do, I prefer solid statistical evidence. Bring on a fair testing ground of OpenGL beating DX11/11.1 please with the exact same feature set.

This is not a flawed comparison:

1.- The blog post is about the performance increase on Linux from 6 to 315 FPS thanks to the work by Valve and the GPU vendors.

2.- The Windows 7 stats are there for reference. If you are working on improving performance on your Linux port you surely want to compare with your previously working implementation on another platform.

3.- So far I haven't seen anywhere what exact OpenGL version they are using on Linux. The claims about Valve using OpenGL 4 are just assumptions.

Long story short: there's no need to get butthurt, this is not a competition. They just released numbers to show how their work in these last months reflect on their ongoing Linux implementation compared to what was a "final", stable implementation (which just happened to be on Windows).

The whole engine isn't built around DX11 though. The console and PC versions will ship with DX9 rendering. And like Crysis 2, the DX11 will not be enabled by default.

That was kind of a given considering not everbody has the capability to run something that demanding yet.. I was just commenting to your quote where you said that it was not supporting it at all, which wasn't true, they're fully taking advantage of it.

Again, the point is, by using DX9, Valve is actually giving Direct3D an advantage because it doesn't use the latest technologies, and therefore as you said, it's less demanding for the system. If DX10/11 was used, I'm sure the fps disparity would be even greater.

You do know that by using DX11 doesn't automatically make it slower right? It's only when you start taking advantage of those new hardare specific features in the API that it starts to push the hardware more.. never mind some of the new features that actually improve performance even on DirectX 9 generation cards, little things like the new multitreading resource handling that works better with multicore CPU's than DX9, stuff like that?

Break out the benchmarks ;) I'm always interested provided they are fair and balanced.

Well I would think so since they're done by Phoronix, a Linux site. And before somebody points out the obvious, I did say that some are faster, some are slower, here's a couple of the faster ones from May. Universally saying one OS is faster than another is just fanboyism. And I'm personally waiting for a fair and balanced benchmark for this one specific case as well, it's not like Valve has an agenda or anything...

benchmark3x.png

benchmark2.png

benchmark1.png

That was kind of a given considering not everbody has the capability to run something that demanding yet.. I was just commenting to your quote where you said that it was not supporting it at all, which wasn't true, they're fully taking advantage of it.

You do know that by using DX11 doesn't automatically make it slower right? It's only when you start taking advantage of those new hardare specific features in the API that it starts to push the hardware more.. never mind some of the new features that actually improve performance even on DirectX 9 generation cards, little things like the new multitreading resource handling that works better with multicore CPU's than DX9, stuff like that?

Well I would think so since they're done by Phoronix, a Linux site. And before somebody points out the obvious, I did say that some are faster, some are slower, here's a couple of the faster ones from May. Universally saying one OS is faster than another is just fanboyism. And I'm personally waiting for a fair and balanced benchmark for this one specific case as well, it's not like Valve has an agenda or anything...

benchmark3x.png

benchmark2.png

benchmark1.png

Well, Ubuntu beats DirectX in two of the three Unigine benchmarks (without any of these recent improvements), but again as I stated before Valve's blog isn't about Linux' performance per se, but about how their recent work in cooperation with GPU vendors has provided awesome results (they went from 6 to 315 FPS).

Well, Ubuntu beats DirectX in two of the three Unigine benchmarks, but again as I stated before Valve's blog isn't about Linux' performance per se, but about how their recent work in cooperation with GPU vendors has provided awesome results (they went from 6 to 315 FPS).

Well I did say it's not 100% faster across the board, and that's just one engine that had the advantage, but again the point was that no single OS is faster than another. Arbitrarily saying "Linux is the best gaming platform ever" just because of one benchmark is absurd, especially when it's not looking at all the factors.

I do agree though, they obviously fixed something that was horribly busted. If they can improve Linux video drivers more (performance and stability) I'm all for that. On my particular hardware anyway, caught between a rock and a hard place.. slower open drivers, or buggy but faster closed drivers. He also says he's going to see if he can apply that same adjustment to DirectX as well.. so right now its apparently a bit one sided.

I've never really understood how people can be so loyal over a graphics binding API, in the end it all comes down to driver quality and how good the hardware is.
Depends on what the API is willing to provide you. Platform/license-wise, OpenGL gets the vote.

the only issue i have with linux and have ever had is the updates / distros so damn many of them every like 6 months you get a major version of your fav. Also its not 100% noob friendly.

Its also very easy to brake linux and it can be a pain in the ass to get working again most the time i just reinstall with windows i never have this issue. If linux had 1 major dev with 1 major build every day 1.5years and updates every now and then and the driver support was good then the OS would be grate. This will never happen though being open source.

You also have things like warentee, tech support issues and stuff.

I do agree though, they obviously fixed something that was horribly busted. If they can improve Linux video drivers more (performance and stability) I'm all for that. On my particular hardware anyway, caught between a rock and a hard place.. slower open drivers, or buggy but faster closed drivers. He also says he's going to see if he can apply that same adjustment to DirectX as well.. so right now its apparently a bit one sided.

That's the point, and that's why going all defensive about the FPS numbers posted on the Valve blog article is an exercise of butthurtness.

This is what they said, exactly:

After this work, Left 4 Dead 2 is running at 315 FPS on Linux. That the Linux version runs faster than the Windows version (270.6) seems a little counter-intuitive, given the greater amount of time we have spent on the Windows version. However, it does speak to the underlying efficiency of the kernel and OpenGL. Interestingly, in the process of working with hardware vendors we also sped up the OpenGL implementation on Windows. Left 4 Dead 2 is now running at 303.4 FPS with that configuration.

So what does this mean?

1.- Working with GPU vendors was great, since they achieved going from 6 to 315 FPS.

2.- The Linux kernel and OpenGL work great, since they managed to get great performance with less effort than they spent on the Windows version.

3.- While working on the Linux port they learned some tricks that also helped to improve Windows performance with OpenGL.

4.- They also found out that there was something going wrong with DirectX, so they can now try to fix that and improve the performance there as well.

If anyone feels like drawing other conclusions from that article and starting a platform war that's his problem. I'm not seeing anything other than an update of the work-in-progress of their port of L4D2 to Linux.

That's the point, and that's why going all defensive about the FPS numbers posted on the Valve blog article is an exercise of butthurtness.

Not sure where you're getting "defensive" and "butthurt" from. Aside from the fact I don't care regardless how fast they make it on Linux as I wouldn't use it anyway, I'm just pointing out the blatantly obvious that this is one benchmark in one scenario, and that other benchmarks show differerent numbers in different situations.. IE pointing out to those that are saying "Linux is universally better at gaming" just because of one benchmark and completely ignoring other factors is just nonsense.

1.- Working with GPU vendors was great, since they achieved going from 6 to 315 FPS.

Again, no arguments, always good when somethings fixed (especially something that was obviously broken badly), I don't give a rats ass which OS it's on. I'm not a fanboy, if they can improve something that's used by other people then by all means that's a good thing.

3.- While working on the Linux port they learned some tricks that also helped to improve Windows performance with OpenGL.

4.- They also found out that there was something going wrong with DirectX, so they can now try to fix that and improve the performance there as well.

And once they actually get the various video drivers adjusted on the Windows side with these improvements lets try that benchmark again. Right now it's a skewed benchmark... we fixed a driver issue on one side, didn't touch the other side, so obviously the other side is inferior. Brilliant.

Do you have a source for the exact OpenGL version they are using or are you just making it up?

To expand on this, we don't even know what version of Direct3D they were running in such a comparison.

Publically released versions of Source only support 9, but there are a number of references to 10 in both dxsupport.cfg, and the existance of shaderapidx10.dll.

So until they release what versions of the APIs they were using, crying that Valve wasn't fair to your beloved Microsoft is futile.

Not only that, but being intellectually dishonest in such a fashion doesn't help Valve make a better product either.

And once they actually get the various video drivers adjusted on the Windows side with these improvements lets try that benchmark again. Right now it's a skewed benchmark... we fixed a driver issue on one side, didn't touch the other side, so obviously the other side is inferior. Brilliant.

That's part of the point though isn't it? If they can directly contribute fixes to the graphic drivers rather than having to go through the vendor and ask them to fix it for them, then that proves that the openness of the Linux ecosystem makes development easier for Valve.

Not sure where you're getting "defensive" and "butthurt" from. Aside from the fact I don't care regardless how fast they make it on Linux as I wouldn't use it anyway, I'm just pointing out the blatantly obvious that this is one benchmark in one scenario, and that other benchmarks show differerent numbers in different situations.. IE pointing out to those that are saying "Linux is universally better at gaming" just because of one benchmark and completely ignoring other factors is just nonsense.

Sorry if it seems that I was pointing at you when talking about "butthurtness", I just meant the overall trend about how a benchmark where Linux beats Windows must be obviously unfair and skewed, more so when this isn't even an actual benchmark but an update about the current state of the port.

And I said "butthurtness" because the whole reason this thread has 15 pages so far is that Linux scored higher. If it hadn't you wouldn't have had so many people trying to make up OpenGL versions and other excuses to try to disprove that, at this point in time, Valve managed to get better performance with L4D2 on Linux than they do on Windows.

Again, no arguments, always good when somethings fixed (especially something that was obviously broken badly), I don't give a rats ass which OS it's on. I'm not a fanboy, if they can improve something that's used by other people then by all means that's a good thing.

That's the spirit (Y)

And once they actually get the various video drivers adjusted on the Windows side with these improvements lets try that benchmark again. Right now it's a skewed benchmark... we fixed a driver issue on one side, didn't touch the other side, so obviously the other side is inferior. Brilliant.

It's not skewed (let alone not being a benchmark): L4D2 on Windows is a final released version while L4D2 on Linux is a yet uncomplete port.

Of course you would always be comparing a port against your released version: the later shows the performance levels you expect to be able to reach with your port.

Also they fixed the OpenGL implementation on both platforms and gave the final numbers they got (303.4 on Windows vs 315 on Linux). The DirectX overhead issue is something they have just spotted, and giving the DirectX results just points that there's something wrong there that they'll have to look into but haven't yet figured out how to mitigate.

...

Some of it is down to GNU/Linux and some of it OpenGL (it runs faster than Direct3D on Windows too). And the extra time wasn't spent in the source engine, but the Direct3D batch processing in Microsoft's code.

...

I assumed the overhead was in Source, since I thought Microsoft would have noticed the performance hit compared to OpenGL, if the issue has been around for a decade. But of course it's always possible for such a small difference to vanish into the "noise"

Valve provided answers to some of the questions posted in this thread in the comments section of their blog (as people were asking those same questions there as well):

The Linux version of Left 4 Dead 2 has all graphical features enabled. Obviously, there are still some bugs we are working on but overall, the stability and quality of the rendering is on par with the Windows version.
Image quality for L4D2 on Linux with OpenGL is on par with L4D2 on Windows with Direct3D.
This test used OpenGL version 3.x.

This is great news.. great work Valve.

The problem with Linux was never the OS - it's light, it's fast. It's all about the apps. Bring the apps and more people will use it!

the only issue i have with linux and have ever had is the updates / distros so damn many of them every like 6 months you get a major version of your fav. Also its not 100% noob friendly.

Its also very easy to brake linux and it can be a pain in the ass to get working again most the time i just reinstall with windows i never have this issue. If linux had 1 major dev with 1 major build every day 1.5years and updates every now and then and the driver support was good then the OS would be grate. This will never happen though being open source.

You also have things like warentee, tech support issues and stuff.

If everyone that's somewhat computer savvy (gamers that use Steam I would consider in this category) just sat down, read some tutorials and got acclimated to the Linux environment, they would find themselves more knowledgeable about the inner workings of a computer and less likely to need to use tech support or warranties (at least for non-hardware issues).

But no, we can't expect people to know how to use a computer.

If everyone that's somewhat computer savvy (gamers that use Steam I would consider in this category) just sat down, read some tutorials and got acclimated to the Linux environment, they would find themselves more knowledgeable about the inner workings of a computer and less likely to need to use tech support or warranties (at least for non-hardware issues).

But no, we can't expect people to know how to use a computer.

Because it's not that simple with Linux.

Also, you don't learn "the inner workings of a computer" with Linux. You just learn about the modules in your distro.

Furthermore, you give up a lot of hardware choices by moving to Linux. Sure, they work on Linux but it's not uncommon for certain features to be non-functioning or non-configurable.

Furthermore, you give up a lot of hardware choices by moving to Linux. Sure, they work on Linux but it's not uncommon for certain features to be non-functioning or non-configurable.

Not if you buy from a GNU/Linux OEM. They ensure the hardware is compatible with the OS. It works the opposite way around as well. If hardware is designed to work in Linux, and you try and use Windows on it, there's no guarantee it will function properly.

I feel sorry for those people genuinely thinking about switching to Linux over some flawed comparison next to hundreds of other benchmarks which say the opposite.

Do you really feel that cool doing 10x more complex stuff to achieve the same?

hundreds of other benchmarks which say the opposite.

Some do, some don't.

It'd be certainly weird to switch just because of L4D2 (unless that's all you played), but if you found that the games you play worked on Linux with about the same performance and you didn't need anything that you couldn't do with Linux already, why shouldn't you at the very least consider switching? Not that you have to, but it's a perfectly reasonable option.

Do you really feel that cool doing 10x more complex stuff to achieve the same?

YMMV, but some of the reasons why I use Linux are:

- It makes my work a whole lot easier.

-The extra options in window management (even simple stuff like alt+drag) that make the environment more comfortable.

- It looks better (not really an important feature, I know, but it's a nice plus).

So no 10x complexity over here (quite the opposite actually).

Again, YMMV.

Not if you buy from a GNU/Linux OEM. They ensure the hardware is compatible with the OS. It works the opposite way around as well. If hardware is designed to work in Linux, and you try and use Windows on it, there's no guarantee it will function properly.

Awesome. Throw away your gaming rig and buy a new one even though OEMs don't really sell gaming-rig Linux PCs.

Also the last bit about hardware designed for Linux not working well in Windows; that is so rare it's almost non-existent in the PC realm.

This topic is now closed to further replies.
  • Posts

    • BATorrent 3.0.2 by Razvan Serea BATorrent is a lightweight, open-source BitTorrent client built with modern C++ and Qt 6, offering a clean, fast, and privacy-focused alternative to traditional torrent apps. It supports magnet links, .torrent files, resume data, sequential downloading, per-file priorities, and even imports from qBittorrent. Power users benefit from integrated RSS auto-download with regex filtering, duplicate detection, and automatic tracker lists from Stremio. Streaming is seamless thanks to auto-detected players like VLC and IINA. BATorrent includes robust VPN tools—interface binding, auto-detection for WireGuard-based services like Mullvad and NordLynx, kill switch, proxy support, and IP filtering. A full WebUI enables remote control, while integrations with Plex, Jellyfin, and Emby automate library updates. With themes, speed scheduling, system-tray alerts, and cross-platform support for Windows, Linux, and macOS, BATorrent delivers a polished, high-performance torrenting experience. BATorrent features: Core .torrent file and magnet link support Resume data — picks up where you left off after restart Import torrents from qBittorrent Create .torrent files from any file or folder Sequential download mode Per-file priority control (skip, low, normal, high) Seed ratio limits with auto-pause DHT, PEX, UPnP, NAT-PMP RSS Auto-Download Subscribe to RSS feeds — automatically download new torrents as they appear Regex filters — match only what you want (e.g. 1080p|720p, S01E\d+) Per-feed settings — custom save path, check interval (5–1440 min), enable/disable Auto-download — matched items are downloaded automatically in the background Supports magnet links, .torrent URLs, and tags Tray notifications when items are auto-downloaded Duplicate detection — never downloads the same item twice Stremio Stremio Addon System pre-installed — works out of the box Auto tracker list from ngosang/trackerslist Streaming Play while downloading — stream video files before the download is complete Supports mp4, mkv, avi, mov, wmv, flv, webm, m4v, ts Auto-detects installed players (VLC, IINA, system default) VPN & Privacy Interface binding — lock torrent traffic to a specific network interface (e.g. tun0) Auto VPN detection — identifies VPN interfaces (tun, tap, WireGuard, Mullvad, NordLynx, ProtonVPN) Kill switch — automatically pauses all torrents if the VPN interface drops Auto-resume — resumes only the torrents paused by the kill switch when VPN reconnects Proxy support — SOCKS5 and HTTP proxy with optional authentication IP filtering — load P2P blocklists to block unwanted IP ranges Protocol encryption (enabled / forced / disabled) WebUI Remote management — control torrents from any browser at http://localhost:8080 REST API with JSON responses Add torrents via magnet link or .torrent upload Pause, resume, remove torrents remotely View peers and files per torrent Dark theme matching the desktop app HTTP Basic Auth with SHA-256 password hashing Configurable port and remote access (localhost vs 0.0.0.0) Interface 3 themes: Dark, Light, Midnight (bat/vampire aesthetic) Real-time speed graph Detailed panel with tabs: General, Peers, Files, Trackers Filter bar: search by name, filter by state (Active, Downloading, Seeding, Paused, Finished) Drag & drop .torrent files and magnet links Drag & drop reorder in torrent list System tray with notifications (download complete, kill switch events, RSS auto-downloads) Splash screen with bat animation Bilingual: English and Portuguese (BR), auto-detected from system locale Bandwidth Scheduler Alternative speed limits — set different download/upload limits on a schedule Time range — configure active hours (e.g. 01:00 to 07:00), supports overnight ranges Per-day control — choose which days of the week the schedule applies Automatically switches between normal and alternative speeds Media Server Integration Plex — automatically trigger library scan when a download completes Jellyfin / Emby — same automatic library refresh via API Configure server URL and authentication token/key in Settings System Cross-platform: Windows, Linux, macOS Auto-shutdown — automatically shut down PC when all downloads complete (60s cancellable countdown) Auto-update system (AppImage on Linux, installer on Windows, DMG on macOS) CLI arguments: pass .torrent files or magnet: URIs directly Keyboard shortcuts: Space to toggle pause, Ctrl+A to select all, Ctrl+O to open BATorrent 3.0.2 changelog: Phone pairing & WebUI The browser WebUI was reskinned to match the desktop app — same dark palette, Inter font, flat surfaces, the real BATorrent logo (it was a random bat before), and a proper magnet icon. It now looks like the same product, not a separate dashboard. Pairing is one tap and zero typing: the generated WebUI password is now copyable, and the QR code carries the credentials — scanning it from your phone logs straight in (no typing the IP or password), then drops the credentials from the address bar. Search Two new providers: RuTor (CIS sources, no login, via a public TorAPI relay) and Torrents-CSV. Results are sorted by seeders (healthiest first), and each search now times out after 15 s so one dead provider can't hang the UI. Files & trackers Per-file priority is back: right-click a file in the detail panel to set Skip / Low / Normal / High. Rename an individual file inside a torrent (double-click or the file menu), separate from renaming the torrent. Remove a tracker from a torrent (the ✕ on a tracker row); adding was already there. Smart Paste on Ctrl+V — paste a magnet, a 40-char info-hash, or a .torrent URL straight from the clipboard and it's added immediately (text fields still paste text normally). Covers & titles Anime fansub naming ([Group] Title - NN) now resolves to the right show. Audio channel layouts in titles (DDP5.1, 7.1, …) are stripped so they don't pollute cover matching. Under the hood The legacy QWidget interface is gone. QML had been the only UI since 3.0.0 (reachable old code lived behind a hidden --legacy flag); with parity confirmed, the entire QWidget layer — main window, every dialog, the theme manager — was removed (~13,400 lines). The four restored actions above were features that backend already supported but the QML port had never wired. macOS: the WebUI password hash moved out of the keychain into app settings, so launching the app no longer pops a login-keychain password prompt on unsigned builds. The actual password still lives in the keychain. Cleanup: ~400 orphaned translation strings and a batch of dead code removed; internal duplication collapsed; an ARCHITECTURE.md added for contributors. Unit / security / memory tests and the ASan/UBSan/TSan sanitizers stay green. Download: BATorrent 3.0.2 | 30.5 MB (Open Source) Download: BATorrent Portable | 42.3 MB Links: BATorrent Website | Screenshot Get alerted to all of our Software updates on Twitter at @NeowinSoftware
    • How about a global switch to turn the awful things off instead of a registry hack? Then everyone wins.
    • This doesn't strike me as so shocking when... " IT admins do have some control over this rollout. If they choose to opt out, devices in their tenant won't automatically get the dreaded Copilot app"
  • Recent Achievements

    • Mentor
      grik went up a rank
      Mentor
    • Dedicated
      JKR earned a badge
      Dedicated
    • One Year In
      CHUNWEI earned a badge
      One Year In
    • Conversation Starter
      FBSPL earned a badge
      Conversation Starter
    • Week One Done
      I2D earned a badge
      Week One Done
  • Popular Contributors

    1. 1
      +primortal
      468
    2. 2
      PsYcHoKiLLa
      257
    3. 3
      Skyfrog
      79
    4. 4
      ATLien_0
      60
    5. 5
      FloatingFatMan
      60
  • Tell a friend

    Love Neowin? Tell a friend!