GZDoom 4.9.0 survey - the final rundown

Here, developers communicate stuff that does not go onto the main News section or the front page of the site.
[Dev Blog] [Development Builds] [Git Change Log] [GZDoom Github Repo]

Moderator: GZDoom Developers

Professor Hastig
Posts: 225
Joined: Mon Jan 09, 2023 2:02 am
Graphics Processor: nVidia (Modern GZDoom)

Re: GZDoom 4.9.0 survey - the final rundown

Post by Professor Hastig »

Ugh, I never knew it was that bad. I thought the open source drivers were better than the Windows ones, but apparently not. If it only happens on Linux maybe that is why there haven't been more frequent reports about the texture filtering issue. I found it a bit odd that you experience a problem nobody else seems to have.
Professor Hastig
Posts: 225
Joined: Mon Jan 09, 2023 2:02 am
Graphics Processor: nVidia (Modern GZDoom)

Re: GZDoom 4.9.0 survey - the final rundown

Post by Professor Hastig »

Rachael wrote: Fri Mar 17, 2023 12:49 am But with the latest bullshit I've been seeing from Apt in Ubuntu, it seems more and more like Canonical is seeking to commercialize Ubuntu (more than they already have) and that alone might make me jump ship and go to Arch, myself.

WTF???
https://discourse.ubuntu.com/t/ubuntu-f ... ults/34061

Read until the end... :? I guess it's really time to dump it for good.
User avatar
KynikossDragonn
Posts: 272
Joined: Sat Dec 12, 2020 10:59 am
Preferred Pronouns: He/Him
Operating System Version (Optional): Void Linux
Graphics Processor: Intel (Modern GZDoom)
Location: Independence, KS, USA
Contact:

Re: GZDoom 4.9.0 survey - the final rundown

Post by KynikossDragonn »

Professor Hastig wrote: Fri Mar 17, 2023 12:56 am Ugh, I never knew it was that bad. I thought the open source drivers were better than the Windows ones, but apparently not. If it only happens on Linux maybe that is why there haven't been more frequent reports about the texture filtering issue. I found it a bit odd that you experience a problem nobody else seems to have.
They're "bad" only in the sense that it seems virtually impossible to get actual problems to resolve without introducing dozens of regressions down the lane. Mind you, the "Windows" drivers aren't any better, there's plenty of people stuck on Intel Graphics, some a generation earlier than mine, who end up unable to run GZDoom whatsoever, where as it actually runs on Linux with the Mesa open source drivers.

If I had a identical NUC6i7kyk I would be more proactive in helping the developers resolve problems, but I don't and I use this system as a desktop, not as a dev guinea pig.
Professor Hastig
Posts: 225
Joined: Mon Jan 09, 2023 2:02 am
Graphics Processor: nVidia (Modern GZDoom)

Re: GZDoom 4.9.0 survey - the final rundown

Post by Professor Hastig »

KynikossDragonn wrote: Fri Mar 17, 2023 1:06 am Mind you, the "Windows" drivers aren't any better, there's plenty of people stuck on Intel Graphics, some a generation earlier than mine, who end up unable to run GZDoom whatsoever, where as it actually runs on Linux with the Mesa open source drivers.
That must be very broken computers. In my family I have access to systems with a HD4000, HD5500 and a more modern Iris GPU, and performance issues nonwithstanding GZDoom works fine on all of them.
Or is it that they use some crippled generic Microsoft driver that lacks proper OpenGL and Vulkan support?
User avatar
phantombeta
Posts: 2081
Joined: Thu May 02, 2013 1:27 am
Operating System Version (Optional): Windows 10
Graphics Processor: nVidia with Vulkan support
Location: Brazil

Re: GZDoom 4.9.0 survey - the final rundown

Post by phantombeta »

Professor Hastig wrote: Fri Mar 17, 2023 1:12 amThat must be very broken computers. In my family I have access to systems with a HD4000, HD5500 and a more modern Iris GPU, and performance issues nonwithstanding GZDoom works fine on all of them.
Or is it that they use some crippled generic Microsoft driver that lacks proper OpenGL and Vulkan support?
No, not really. Intel users have been having issues with hard freezes for a while. There's multiple threads reporting it.
btw, the flickering polys issue has nothing to do with distro or even which drivers you're using- I had that exact same issue with my HD Graphics 630 with OpenGL on Windows:

It's some weirdness with Intel's architecture in general. No idea if it's something deep in their drivers or firmware, or if it's a hardware bug. My guess is that it's probably related to the mapped vertex buffers.
IIRC it only started happening after a certain version, but it was really long ago so I don't remember when it started happening.
User avatar
KynikossDragonn
Posts: 272
Joined: Sat Dec 12, 2020 10:59 am
Preferred Pronouns: He/Him
Operating System Version (Optional): Void Linux
Graphics Processor: Intel (Modern GZDoom)
Location: Independence, KS, USA
Contact:

Re: GZDoom 4.9.0 survey - the final rundown

Post by KynikossDragonn »

It makes me wonder why "INTEL_DEBUG=reemit" is such a solid "bug fix", the only description for that envvar is "mark all state dirty on each draw call", so what exactly does this mean for a moron like myself?
Professor Hastig
Posts: 225
Joined: Mon Jan 09, 2023 2:02 am
Graphics Processor: nVidia (Modern GZDoom)

Re: GZDoom 4.9.0 survey - the final rundown

Post by Professor Hastig »

That comment means that it does not try to cache any state info between draw calls and must recreate it over again each time at the expense of higher draw overhead. Which hints at a driver bug.
User avatar
KynikossDragonn
Posts: 272
Joined: Sat Dec 12, 2020 10:59 am
Preferred Pronouns: He/Him
Operating System Version (Optional): Void Linux
Graphics Processor: Intel (Modern GZDoom)
Location: Independence, KS, USA
Contact:

Re: GZDoom 4.9.0 survey - the final rundown

Post by KynikossDragonn »

I must not notice this "high draw overhead" because various things I've played don't suffer grave lag as a result of me playing with that debug variable enabled. I get the same performance with or without it.
Professor Hastig
Posts: 225
Joined: Mon Jan 09, 2023 2:02 am
Graphics Processor: nVidia (Modern GZDoom)

Re: GZDoom 4.9.0 survey - the final rundown

Post by Professor Hastig »

This sounds like a bullshit optimization that causes more problems than it solves.
User avatar
Ihavequestions
Posts: 163
Joined: Mon Jul 12, 2021 1:45 pm
Graphics Processor: nVidia with Vulkan support

Re: GZDoom 4.9.0 survey - the final rundown

Post by Ihavequestions »

Two things I'd like to add.

1. Open-source drivers are by no means 'automatically better' than closed-source ones. NVidia has had superior closed-source Linux drivers for many years, and while there's always a lot of ideological controversy around them, everyone is secretly thankful to NVidia for providing Linux gamers with good-quality drivers that typically will work out of the box.

2. The whole 'Ubuntu' thing here is highly misleading. It is Debian and its derivatives; the GZDoom/LZDoom packages use the Debian package format; and GZDoom/LZDoom should install and run prefectly on any Debian-based distro from those 'Ubuntu' titled packages. It really has nothing to do with Ubuntu.
User avatar
Chris
Posts: 2940
Joined: Thu Jul 17, 2003 12:07 am
Graphics Processor: ATI/AMD with Vulkan/Metal Support

Re: GZDoom 4.9.0 survey - the final rundown

Post by Chris »

Ihavequestions wrote: Fri Mar 17, 2023 10:04 am 1. Open-source drivers are by no means 'automatically better' than closed-source ones. NVidia has had superior closed-source Linux drivers for many years, and while there's always a lot of ideological controversy around them, everyone is secretly thankful to NVidia for providing Linux gamers with good-quality drivers that typically will work out of the box.
Most people have been openly thankful to nVidia for providing Linux users with good quality drivers as they used to be the only ones to do so. Back in the before times, there were no open source drivers for nVidia, ATI, or Intel hardware that could do 3D acceleration. nVidia decided to make their Linux drivers use the same core code as their Windows drivers, with a little open source glue to interface a binary blob with the kernel and X. This provided a more consistent level of quality and features across OSs. ATI, later AMD, developed separate (closed source) drivers largely from the ground up for Linux, and were much buggier and lacking features compared to their Windows offerings. Consequently, nVidia drivers performed far better with comparatively few issues. People would happily focus their efforts on making sure their stuff worked with nVidia because it was the only way it could work well (if you wanted 3D acceleration, at least), and its behavior was roughly comparable as on Windows.

However, not everything stays the same forever. Times change, and at some point Intel decided to open source their drivers and provide documentation for their devices, working with the kernel devs and Mesa on their now-open-source drivers. This resulted in Intel graphics seeing a significant jump in stability and quality over time. AMD followed suit, providing documentation for their hardware and working with the kernel devs and Mesa for writing new open source drivers. This resulted in AMD graphics seeing regular improvements in stability and quality too. nVidia, in contrast, steadfast refused to provide any documentation or make any moves to having or allowing open source drivers, going business-as-usual. Sure their drivers may have been been relatively good since the outset, but this created a schism; the open source open source drivers were continually improving, and AMD and Intel would work with the Linux Kernel, Mesa, Xorg, and later Wayland, to fix problems and work out details for future development, while nVidia would stay in its own corner expecting others to do what they wanted.

Let's not forget Linus' infamous "nVidia, fuck you" middle finger, which was born as a result of nVidia's drivers creating many unnecessary issues and headaches for the kernel devs, amplified by the drivers being closed and nVidia not working with them like the other vendors do. There have been occasions like where Intel, AMD, the kernel devs, Mesa, and Wayland were in unanimous agreement on a new interface for Wayland's graphics management (GBM). nVidia was invited to those discussions where that decision was made, said they'd be there, then was a no-show. Some time later after everyone started working on and using that new interface, nVidia popped up saying they were supporting a different interface (EGLStreams). If you wanted a Wayland compositor to work on nVidia hardware, you basically needed a second implementation just for nVidia now, while AMD, Intel, and everyone else would all share the initial one. As Wayland was still under heavy development, that was extra unexpected work nobody was happy about. If you wanted to use Wayland on nVidia, you were in for a very rough time since that code ended up far buggier and less developed. nVidia eventually relented and began to support GBM too, but their support of it isn't the greatest. Wayland on nVidia is certainly better, but still hobbled.

Suffice to say, while nVidia may have been considered superior, that was a relative assessment when the alternatives were all utter crap. But AMD and Intel are both more viable now than ever, and plenty of people are no longer tolerant of nVidia's my-way-or-the-highway attitude. People don't have to kowtow to nVidia as much anymore, resulting in more code being written with a focus on AMD and Intel, and exposing more issues for nVidia. On a technical level, nVidia's drivers do have some advantages, but fewer people are willing or able to mask nVidia's BS these days. There are non-ideological reasons to see AMD and Intel as superior, as their drivers integrate into the system far better than nVidia's, the drivers being part of the kernel where they're expected to be and using a common graphics stack, creating a nicer user experience. Whether or not that's something that matters to you depends on what you care about, of course, but it's not the forgone conclusion it used to be,
Ihavequestions wrote: Fri Mar 17, 2023 10:04 am 2. The whole 'Ubuntu' thing here is highly misleading. It is Debian and its derivatives; the GZDoom/LZDoom packages use the Debian package format; and GZDoom/LZDoom should install and run prefectly on any Debian-based distro from those 'Ubuntu' titled packages. It really has nothing to do with Ubuntu.
Ubuntu isn't Debian, it is a derivative sharing some (but not all) packages. In this particular case, the issue largely stems around having Flatpak support by default for distro-agnostic packages, and especially statements like:
Canonical’s community team had reached out to flavor leads for an open discussion on default packaging in Ubuntu flavors. In each conversation, we presented our point of view regarding these changes and were open to discussion. While there were differences in initial agreement, in most cases the flavor representatives signaled willingness to make the changes by the end of the conversation.
If that isn't coded language for "Kubuntu, Xubuntu, etc, wanted to support Flatpak by default, we "listened" but forced them not to", I don't know what is. "Differences in initial agreement" is a really funny way to say "we disagreed", and "the flavor representatives signaled willingness to make the changes by the end of the conversation" smacks of double-speak to me (I mean, saying something like "don't do that or we won't allow you to keep using the Ubuntu trademark" would certainly create a "willingness to make the changes"; not saying that is what happened, but it gives off that vibe). At a time when Flatpak seems to be gaining the most traction as a distro-agnostic package system/format, Ubuntu is pulling further away from it to focus on using Snap as a more proprietary alternative that far fewer people are enthused about. Canonical has historically had a NIH (Not Invented Here) problem, but this is taking it to a new level by forcing Ubuntu flavors to not support Flatpak by default too. Sure you can still install the apt packages to support Flatpak, but that's an unnecessary manual step that people are going to increasingly run into as Flatpak support continues to grow. Better to have the packages installed by default so it Just Workstm for users, but Canonical doesn't want that and is now forcing other distros to follow them.
User avatar
Rachael
Posts: 13527
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: GZDoom 4.9.0 survey - the final rundown

Post by Rachael »

Canonical's fuckery lately has been leading me more and more to push towards Arch Linux. I am not quite there yet in terms of actual usage of it, but suffice to say I'm getting kind of tired of corpo-junk and advertisements appearing on my command line. My only reason for using Ubuntu lately is because it's the distro that I know and I can depend on it being stable, but that's really about it. Linux Mint might be a good alternative, too, though, but I'll have to look into that.
User avatar
Ihavequestions
Posts: 163
Joined: Mon Jul 12, 2021 1:45 pm
Graphics Processor: nVidia with Vulkan support

Re: GZDoom 4.9.0 survey - the final rundown

Post by Ihavequestions »

Chris, I was talking about the fact that the GZDoom/LZDoom packages on zdoom.org are in the Debian package format but titled 'Ubuntu' and that this is misleading. You do not need any kind of Ubuntu to install them, just the Debian package manager (dpkg) that comes with any Debian-based distro.

What does that have to do with Flatpak?
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49053
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: GZDoom 4.9.0 survey - the final rundown

Post by Graf Zahl »

What a mess. As if Linux didn't have enough problems already, now that a solution to one of the biggest is gaining some acceptance, a corporate bully comes along and destroys everything. Well done!
User avatar
Rachael
Posts: 13527
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: GZDoom 4.9.0 survey - the final rundown

Post by Rachael »

Ihavequestions wrote: Sat Mar 18, 2023 10:09 am Chris, I was talking about the fact that the GZDoom/LZDoom packages on zdoom.org are in the Debian package format but titled 'Ubuntu' and that this is misleading. You do not need any kind of Ubuntu to install them, just the Debian package manager (dpkg) that comes with any Debian-based distro.
While that is true, I don't know what the big issue is, this seems needlessly pedantic and particular. Why is it *so* important that it specifically be named Debian? - It's not compiled on Debian, it's compiled and made with Ubuntu, though some effort goes into making it work on other distros. In fact it's very likely to work on other distros that have some form of deb reader/converter. Ultimately it's harmless, if it works it works if not you have other options.
Post Reply

Return to “Developer Blog”