If there is a game setting for that, I can try it. Mesa/radeonsi doesn't have any special overrides for such features on the OpenGL level. There is only one for MLAA: https://www.mesa3d.org/postprocess.htmlSigilFey;n9645291 said:
I doubt it. These are normally controlled by flags directly through the GPU drivers. Hence Nvidia Inspector or something similar will be needed. (It may not even work the same way or be caused by the same thing in TW3. It sure looks similar, though.)Gilrond-i-Virdan;n9645591 said:
But that's right...Linux doesn't use default drivers? Or does it? Either way, that MLAA transparency filter you linked to sounds like it could be a lead. I know nothing about actually tweaking drivers, though. (Only how to follow instructions!
)
Last edited:
MLAA is just an optional morphological anti-aliasing filter that Mesa Gallium 3D supports (so it can be used when running with radeonsi OpenGL driver). It's mostly useful for older games, that don't have good AA at all. More about MLAA see here:SigilFey;n9645891 said:
http://www.cs.cmu.edu/afs/cs/academi...tov09_mlaa.pdf
http://www.iryoku.com/mlaa/
I doubt it's the issue here though. It's something that TW3 is already doing with antialiasing through DX11, that fails when translated to OpenGL by Wine.
Not sure what you call standard. Linux drivers situation is a bit confusing for Windows users who usually don't have any choice and use closed driver shipped by the GPU manufacturer.SigilFey;n9645891 said:But that's right...Linux doesn't use default drivers? Or does it?
...
I know nothing about actually tweaking drivers, though. (Only how to follow instructions!
To clarify the drivers situation, it's good to understand their architecture a bit. Graphics stack on Linux is split into kernel and userland parts. Kernel driver is what actually interfaces the OS with the hardware. It's low level hardware abstraction. Userland part of the graphics stack implements APIs like OpenGL, Vulkan and so on. That part itself uses the kernel driver.
On Linux there are 2 major approaches for graphics drivers delivery.
1. The standard approach. That means upstream and open source implementation of kernel driver, and open source implementation of the userland components (OpenGL / Vulkan).
2. Non standard approach. When driver is closed, and shipped separately from the system (that's common in the Windows world).
There is an open source project Mesa 3D, which implements graphics APIs like OpenGL and Vulkan for major GPUs (Intel, AMD, Nvidia and some others). However only Intel and AMD seriously contribute to it. Nvidia doesn't. Same goes for the kernel part. Intel and AMD produce open source kernel drivers, which are included in the upstream Linux kernel. Nvidia doesn't.
So in practice, we have full open source stack that's backed by Intel and AMD, and we have closed blobs from Nvidia (open source driver for Nvidia is developed by the community, but because Nvidia is complicating things by not releasing needed documentation and encrypting their GPU firmware, community releases for Nvidia GPUs lack reclocking, so they aren't feasible for gaming, so those who have Nvidia use their closed blob).
To complicate things, AMD also have a "hybrid" release of their closed OpenGL implementation, that uses the open kernel driver. They do it primarily for legacy customers who rely on compat profile. Normal Linux users don't need to use that, and should use open Mesa 3D which is supported by AMD as well.
Considering Intel isn't really a good gaming option, what's left if you want a proper open driver is basically AMD. So, some key terms for AMD open graphics stack:
amdgpu - name of the kernel driver for modern AMD cards.
radeonsi - name of the OpenGL implementation for AMD in Mesa 3D (supported by AMD).
radv - name of the Vulkan implementation for AMD in Mesa 3D (not exactly supported by AMD, mostly developed by other contributors, including Valve, RedHat and others).
radv is a bit of a special case, because while AMD wanted to open source their Vulkan implementation, it takes them a long time to do it, so several developers started working on radv without waiting for AMD, while AMD are still planning to open up theirs.
I'm using AMD RX 480 at present, so it's amdgpu / radeonsi / radv for me.
I hope that clarifies things a bit
For the reference, see also: https://mesamatrix.net
Last edited:
I was referring to the ability to use reference drivers direct from the hardware manufacturers. From the sound of what you say, the answer is, "Sorta."Gilrond-i-Virdan;n9646241 said:
Alright, that clears a few things up. In that case, I'm not sure how to refer to things like Nvidia Inspector or Radeon Pro in Linux-speak. Generally, any program that allows you to manually set flags and parameters for the present driver set. Do those programs function with the drivers you mention? (For example, NVInspector contains about 50 different "methods" of handling AA. Not all programs will even recognize the differences, but it's a pretty easy way of working around things like the Skyrim issue I referred to.)Gilrond-i-Virdan;n9646241 said:
Of course, I'm judging the book by its cover here, since the "glow" around the bushes certainly appears to be the same type of aura as seen around characters and some models in Beth games. I believe the more "advanced" forms of transparency AA blend the transparent textures further and further out from the actual model, resulting in (effectively) "clear" textures being smeared over the background. At least in Skyrim, this resulted in clear "auras" around certain things...and frost trolls becoming see-through...for whatever reason. The NVInspector flag for either transparency AA or temporal AA allowed for limited transparency blending (beeeaaauuutiful distant clouds and fog) without said errors.
Then again, it might also have nothing to do with it in TW3. Must shrug. (Shrugs.)
OK. AMD have such program for their hybrid (closed OpenGL/Vulkan) driver, but it's not available for Mesa. In Mesa, there are various environment variables that can be set to affect certain parameters, but they are quite barebones, far from some tools you mentioned above. At least there is nothing for tweaking transparency AA.SigilFey;n9648031 said:
Since this bug happens both with radeonsi (AMD open driver), and Nvidia blob, I assume that it's not a problem of the driver as much as it's an issue with Wine doing some DX11 → OpenGL translation incorrectly. But who knows, I'll wait for Wine developers to investigate it. It's not the most annoying bug. Worse ones are that alghoul distortion that happens on a few other monsters too, and some missing surfaces around areas with underground levels.
With mips and deferred context staging patches, the water finally looks beautiful:
Come on in. The water's fine. (Beware of drowners.)Gilrond-i-Virdan;n9653201 said:
Are hounds of the Wild Hunt supposed to be invisible? I wonder if it's by design, or it's a Wine bug.
Józef Kucia is doing some amazing work and is close to fixing invisible monsters bug:
To be honest, CDPR's communication is completely non existent, so we don't know what they think about anything reallypependos;n9893901 said:
Actually, they think rather a lot about video games, costume-play, desktop toys, cats -- and other fluffy animals -- coffee, sandwiches, chocolate, memes, and Gwent.Gilrond-i-Virdan;n9895151 said:
Still waiting for that distorted monsters patch to be fixed (so it wouldn't freeze on AMD), but the game is quite close to fully playable already.
Since it does not look like there are plans to release a port, the number is probably either still considered "not enough", or it is too late for major TW3 development. Perhaps there would be better chance with Cyberpunk 2077. But it is possible that CDPR lost interest in Linux, they might have had plans to port their games around 2013-2014 when it seemed promising as a gaming platform, but after seeing that it does not really take off, they dropped the idea.pependos;n9893901 said:
Linux took off a while ago. It's a growing gaming platform today. Take a look - more and more developers are releasing for it. If CDPR didn't get that and dropped the idea, I think Linux gamers should just drop interest in CDPR future games, since it's unlikely CDPR will pay attention to actual demand.sv3672;n10101461 said: