New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[DON'T MERGE YET] Shadows #1547

Open
wants to merge 175 commits into
base: master
from

Conversation

Projects
None yet
@AnyOldName3
Member

AnyOldName3 commented Nov 7, 2017

Scrawl suggested I actually make a PR for this so that it's easier to keep track of while the last few things are sorted out.

Current issues (that I can think of):

Blockers

  • I've not decided which way to make the sky not receive shadows is best (https://github.com/AnyOldName3/openmw/tree/osgshadow-test-vdsm-sky-method-one versus https://github.com/AnyOldName3/openmw/tree/osgshadow-test-vdsm-sky-method-two) Scrawl likes method two and I trust his judgement above my own.
  • The minimap needs shadows turning off.
  • The character preview needs shadows turning off.
  • Interiors need shadows to not be cast by walls etc. (as they use a 'fake' light source which is blocked everywhere)
  • Settings need to be changeable by users instead of hardcoded.
  • Description of settings needs adding to the documentation
  • Turning on shadows should potentially somehow warn users that they might get issues with shaders off unless force shaders on, but maybe the documentation should suggest they want to do this
  • Assorted parameter tuning to make things look as good as possible.
  • Move as much as possible out of shadermanager.cpp
  • Separate MWShadow into two classes - a shadow technique class based directly on osgShadow::ViewDependentShadowMap and a shadow manager class handling interaction with the rest of the engine.
  • Work out why some Linux users are seeing issues that I'm not, and fix the problem. (This wasn't Linux-specific after all, and was just that distant land was on and broke things.)
  • Ensure that shadow map projection keeps shadow map texels roughly 1:1 with screen pixels.
    • Fix this when due to perspective errors.
    • Fix this when due to a high viewing distance.
    • Fix this when due to similar light and camera angles that wasn't the issue shadow maps being set up to cover non-existent objects under the ground.
      • Stop that fix from breaking first person meshes.
      • Stop that fix from sometimes making shadows disappear from near to the camera when the closest thing to the camera is terrain, not an object.
    • Fix this when due to similar light and camera angles as this issue seems to have reappeared never actually been solved?
      • See how easily this can be fixed by messing around with Cascading Shadow Maps.
      • Implement a maintainable and configurable implementation of Cascading Shadow Maps.
  • Ensure distant terrain causes no issues with the ComputeLightSpaceBounds visitor (which I'm not 100% sure is ever doing its job properly or we'd not have issues when increasing view distance but leaving distant terrain off... unless it's the same water-has-a-huge-bounding-sphere issue that means we can't do bounding volume based traversals).
  • Sort out excessive light space perspective transformation effect with RenderLeafTraverser<RenderLeafBounds>.
    • Stop distant terrain screwing up the ratio calculation.
    • Work out what's going on with this screenshot. The nearest shadow map (red) is excessively distorted, removing detail from the tree on the left. I didn't work out what was going wrong, but I fixed this by accident.
  • Resolve this issue #1547 (comment)
  • Fix this (yet) again #1547 (comment) but for OSG 3.6 maybe not OSG 3.6 @akortunov's mad computer which has issues no one else has reported. Not just akortunov's computer absolutely ridiculous viewing distances. Fixed the viewing distance issue yet another reason. the CLSB visitor giving erroneous results & the ConvexHull thing not considering shadow casters outside of the viewing frustum.
  • Fix disappearing first-person meshes. Video in #1547 (comment)
  • Fix wavy Balmora banners breaking things. https://youtu.be/oMpo6RYrFwg
  • Investigate issue 1 in this post: #1547 (comment) Solve issue where OSG's computed far plane is nearer than the most distant geometry. The computed far plane was fine all along. Solve distant (relatively speaking) shadows disappearing due to erroneous clipping.
  • Fix stateset weirdness.
    • Work out if there's a reason @akortunov had minimap and character preview issues after I fixed them for other people and if the magic fix that shouldn't have worked with CSM is reliable and identifiable.
    • Work out the cause of and then get rid of messages about an invalid OpenGL state.
  • Fix depth precision issues.
    • Reduce Peter Panning without increasing flicker on thin meshes like leaves and ferns.
    • Reduce flicker on thin meshes like leaves and ferns without increasing Peter Panning.
    • Fix evil flicker on a bunch of things (especially with CSM and uniform/log ratio at near 1.0 and a ridiculous viewing distance). Video in #1547 (comment). The root cause is all shadow maps sharing the same near/far planes so the near shadow map has basically no depth resolution. The actual root cause is that the terrain paging system regards all shadow cameras as maximally distant, so serves up the same single whole-of-Morrowind TerrainDrawable for each of them, and that forces all shadow maps to use the same near/far planes so the near shadow map has basically no depth resolution. This issue can be avoided by disabling terrain shadows, which are basically garbage anyway and will be until the issue is resolved. Attempts to do so have lead to weird crashes, so this is being backburnered for now.
  • Adjust the alpha test such that invisible actors cannot cast a shadow.
  • Fix animated things being culled for no reason #1547 (comment). Specifically, it seems that the direct parents of RigGeometries are getting falsely culled sometimes, but other times it's a more complex issue that I won't go into unless someone asked. Copying the bounds from a RigGeometry to its children (which contain the actual mesh) fixed the issue, though.
  • Solve yet another issue with indoor shadows not being everywhere they should be. Investigation suggests this is another LiSPSM issue. shows this is my ConvexHull::extendTowardsNegativeZ() function failing in common edge cases and the provided ConvexHull::clip(osg::Plane) function failing in edge cases made common by the extendTowardsNegativeZ function's introduction.

Non-blockers

  • Improve the culling polytope used when allow shadow map overlap is enabled so performance doesn't fall linearly as more shadow maps are added.
  • Investigate this: https://forum.openmw.org/viewtopic.php?p=57721#p57721
  • At night shadows need to be tweaked in some way if anyone other than me starts complaining about them (as another fake light source is used at night, too).
    • Maybe the position of the light source should follow one of the moons.
    • Maybe the diffuse component of the light source should be reduced and the ambient one increased.
  • Investigate disabling lighting calculations when rendering the shadow map for a speed boost.
  • Consider using a big PCF filter as an option to soften shadows and/or make undersampling look less bad.
    • PCSS is probably the only good option for soft shadows as everything else involves blurring the parts of shadows that need to be hard.
  • Consider potential systems to avoid wasting shadow map space on distant stuff.
    • Maybe a heuristic in QuadTreeWorld based on maximum steepness in a cell and the angle of the sun in the sky which affects the ComputeLightSpaceBounds visitor.
    • Maybe just a boring maximum shadow map distance setting.
    • As distant statics don't exist yet, there's no good way to theorise about the ideal solution for these and if it's just going to be as simple as having a distant statics shadows setting.
    • Maybe see if there's a way to make terrain shadows separate for ECLD cells and terrain paging (distant) cells.
  • Sort out excessive light space perspective transformation effect with RenderLeafTraverser<RenderLeafBounds>.
    • Suppress unsolvable issues by finding the highest value for the minimum lispsm near far ratio setting which doesn't produce artefacts. Users can help with this, and may find playing with the values at the bottom of shadow.hpp in this branch useful. Remember that before telling me that a value is safe, it needs to work (meaning not look worse than a lower value) both with and without the CLSB applied (the thing that automatically toggles), with and without a high view distance, with and without distant terrain, with and without split shadow maps (look at the end bit of the terrain fragment shader if not using exactly three), in first and third-person view, and in various combinations of these settings. MOVED FROM BLOCKERS TO NON-BLOCKERS

Want to tell me how well this works on your machine? I'll need screenshots (ideally with the debug hud turned on), a description of your shadow settings and maybe a coc target and definitely to know whether distant terrain is on.

Testing both with and without this patch (including with and without shadows enabled) on a range of systems might be helpful to me. I know it makes a difference on Mesa, and no difference with AMD's and Nvidia's proprietary Windows drivers, but don't know for other situations.

Want to give me free money because you really like shadows? I have a Patreon at https://www.patreon.com/AnyOldName3

scrawl and others added some commits Apr 14, 2017

Tidy up the mess I made of lighting.glsl a bit by removing two single…
…-line functions that are only ever called in one location.
@AnyOldName3

This comment has been minimized.

Show comment
Hide comment
@AnyOldName3

AnyOldName3 Oct 18, 2018

Member

Looks like there is something wrong with Wraithguard:
screenshot001

In master branch it is invisible too, in older shadows branch too.

What's it supposed to look like?

Member

AnyOldName3 commented Oct 18, 2018

Looks like there is something wrong with Wraithguard:
screenshot001

In master branch it is invisible too, in older shadows branch too.

What's it supposed to look like?

@akortunov

This comment has been minimized.

Show comment
Hide comment
@akortunov

akortunov Oct 18, 2018

Contributor

What's it supposed to look like?

Well, right glove supposed to be transparent since player is invisible.

Contributor

akortunov commented Oct 18, 2018

What's it supposed to look like?

Well, right glove supposed to be transparent since player is invisible.

@AnyOldName3

This comment has been minimized.

Show comment
Hide comment
@AnyOldName3

AnyOldName3 Oct 18, 2018

Member

I also noticed something weird, it seems like perhaps there is some sort of rendering error with the new shaders that I didn't notice in the old version. This is in the vivec guild of mages, but it seems like textures and such are rendering weird, and especially is noticeable on the fires. This also has some effect even with the shadows off, but to less of an extent, like sometimes they will turn green and have graphical corruption and such. Here is a video of what I am talking about with the shadow overlay and hud on, though those might be unnecessary:

https://streamable.com/9buki

Can you compare before and after ce15369? That's the most likely culprit.

Member

AnyOldName3 commented Oct 18, 2018

I also noticed something weird, it seems like perhaps there is some sort of rendering error with the new shaders that I didn't notice in the old version. This is in the vivec guild of mages, but it seems like textures and such are rendering weird, and especially is noticeable on the fires. This also has some effect even with the shadows off, but to less of an extent, like sometimes they will turn green and have graphical corruption and such. Here is a video of what I am talking about with the shadow overlay and hud on, though those might be unnecessary:

https://streamable.com/9buki

Can you compare before and after ce15369? That's the most likely culprit.

@AnyOldName3

This comment has been minimized.

Show comment
Hide comment
@AnyOldName3

AnyOldName3 Oct 18, 2018

Member

Also a small addition to my previous screenshot with profiling in the Ebonheart:
When shadows disabled profilier shows near 600k of triangles in scene, when shadows enabled - near 3 millions of triangles in scene. Is it OK?

EDIT: I use the Better Morrowind Armor mod and every guard has near 30k of triangles without shadows and near 150k with shadows.
I wonder why result is so strange - I'd expect a twice more triangles (since shadows add an additional scene), but not the 5x difference.

EDIT2: From the other hand, if there is a separate scene for every shadow map, 100k of triangles per NPC is expected, but not welcome.

We've not got multiple scenes, but the profiler counts each traversal of the same scene separately. If you're using many shadow maps, you're going to have many triangles.

Member

AnyOldName3 commented Oct 18, 2018

Also a small addition to my previous screenshot with profiling in the Ebonheart:
When shadows disabled profilier shows near 600k of triangles in scene, when shadows enabled - near 3 millions of triangles in scene. Is it OK?

EDIT: I use the Better Morrowind Armor mod and every guard has near 30k of triangles without shadows and near 150k with shadows.
I wonder why result is so strange - I'd expect a twice more triangles (since shadows add an additional scene), but not the 5x difference.

EDIT2: From the other hand, if there is a separate scene for every shadow map, 100k of triangles per NPC is expected, but not welcome.

We've not got multiple scenes, but the profiler counts each traversal of the same scene separately. If you're using many shadow maps, you're going to have many triangles.

@AnyOldName3

This comment has been minimized.

Show comment
Hide comment
@AnyOldName3

AnyOldName3 Oct 18, 2018

Member

What's it supposed to look like?

Well, right glove supposed to be transparent since player is invisible.

I'd try testing before and after ce15369 for that too, then.

Member

AnyOldName3 commented Oct 18, 2018

What's it supposed to look like?

Well, right glove supposed to be transparent since player is invisible.

I'd try testing before and after ce15369 for that too, then.

@akortunov

This comment has been minimized.

Show comment
Hide comment
@akortunov

akortunov Oct 18, 2018

Contributor

I'd try testing before and after ce15369 for that too, then.

I reverted this commit and it fixed the issue.

Contributor

akortunov commented Oct 18, 2018

I'd try testing before and after ce15369 for that too, then.

I reverted this commit and it fixed the issue.

@akortunov

This comment has been minimized.

Show comment
Hide comment
@akortunov

akortunov Oct 18, 2018

Contributor

Also I noticed a strange thing - shadows look much better when player's weapon is holstered in the 1st-person view with these settings rather than when weapon is drawn:

[Shadows]
enable shadows = true
object shadows = true
terrain shadows = true
number of shadow maps = 2
shadow map resolution = 2048
compute tight scene bounds = true
split point uniform logarithmic ratio = 1.0

Without "compute tight scene bounds = true" shadows are always crappy.

Contributor

akortunov commented Oct 18, 2018

Also I noticed a strange thing - shadows look much better when player's weapon is holstered in the 1st-person view with these settings rather than when weapon is drawn:

[Shadows]
enable shadows = true
object shadows = true
terrain shadows = true
number of shadow maps = 2
shadow map resolution = 2048
compute tight scene bounds = true
split point uniform logarithmic ratio = 1.0

Without "compute tight scene bounds = true" shadows are always crappy.

@AnyOldName3

This comment has been minimized.

Show comment
Hide comment
@AnyOldName3

AnyOldName3 Oct 18, 2018

Member

When the weapon is holstered, there's nothing which needs to receive shadows for the first ~600 units from the camera, but when it isn't, there's stuff right up until the near plane. This has a big effect on where shadow maps need to be and how much of a perspective transformation can be applied.

Member

AnyOldName3 commented Oct 18, 2018

When the weapon is holstered, there's nothing which needs to receive shadows for the first ~600 units from the camera, but when it isn't, there's stuff right up until the near plane. This has a big effect on where shadow maps need to be and how much of a perspective transformation can be applied.

@AnyOldName3

This comment has been minimized.

Show comment
Hide comment
@AnyOldName3

AnyOldName3 Oct 18, 2018

Member

The colour mode issues are fixed for me now.

Member

AnyOldName3 commented Oct 18, 2018

The colour mode issues are fixed for me now.

@JDGBOLT

This comment has been minimized.

Show comment
Hide comment
@JDGBOLT

JDGBOLT Oct 18, 2018

I can confirm that it seems to have fixed the issues with the rugs and the chest in the vivec guild of mages, but the fires are still purple with shadows on, and sometimes the fires will disappear outright or shift colors like shown in the video still.

JDGBOLT commented Oct 18, 2018

I can confirm that it seems to have fixed the issues with the rugs and the chest in the vivec guild of mages, but the fires are still purple with shadows on, and sometimes the fires will disappear outright or shift colors like shown in the video still.

@AnyOldName3

This comment has been minimized.

Show comment
Hide comment
@AnyOldName3

AnyOldName3 Oct 18, 2018

Member

What do they look like without the debug overlay and what do they look like in vanilla? Are they definitely not supposed to be magic multicoloured flames and are they definitely not only becoming weirdly coloured because of the overlay?

Member

AnyOldName3 commented Oct 18, 2018

What do they look like without the debug overlay and what do they look like in vanilla? Are they definitely not supposed to be magic multicoloured flames and are they definitely not only becoming weirdly coloured because of the overlay?

@JDGBOLT

This comment has been minimized.

Show comment
Hide comment
@JDGBOLT

JDGBOLT Oct 18, 2018

Yes, they still change colors without the debug overlay on. Also it does still have a bit of corruption even when shadows are turned off. These I think should be mostly vanilla assets. And normally they just render as flames with black smoke.

JDGBOLT commented Oct 18, 2018

Yes, they still change colors without the debug overlay on. Also it does still have a bit of corruption even when shadows are turned off. These I think should be mostly vanilla assets. And normally they just render as flames with black smoke.

@AnyOldName3

This comment has been minimized.

Show comment
Hide comment
@AnyOldName3

AnyOldName3 Oct 18, 2018

Member

I guess I'll need a save game then.

Also, you haven't confirmed whether or not they worked before ce15369

Member

AnyOldName3 commented Oct 18, 2018

I guess I'll need a save game then.

Also, you haven't confirmed whether or not they worked before ce15369

@JDGBOLT

This comment has been minimized.

Show comment
Hide comment
@JDGBOLT

JDGBOLT Oct 18, 2018

This is some videos that were taken of the same place:
This one with shadows disabled and the current code: https://streamable.com/8onjt
This one with shadows on: https://streamable.com/e79j6
And this one is the patch before you started doing the changes to the shaders and such, think from a month ago or whatever it was, with shadows enabled: https://streamable.com/49xyt

JDGBOLT commented Oct 18, 2018

This is some videos that were taken of the same place:
This one with shadows disabled and the current code: https://streamable.com/8onjt
This one with shadows on: https://streamable.com/e79j6
And this one is the patch before you started doing the changes to the shaders and such, think from a month ago or whatever it was, with shadows enabled: https://streamable.com/49xyt

@AnyOldName3

This comment has been minimized.

Show comment
Hide comment
@AnyOldName3

AnyOldName3 Oct 18, 2018

Member

Okay, but can I have a savegame and a comparison of right before the linked commit and now? If your tests bundle in multiple changes, it doesn't tell me if it was that one specific commit which broke things. 😛

Member

AnyOldName3 commented Oct 18, 2018

Okay, but can I have a savegame and a comparison of right before the linked commit and now? If your tests bundle in multiple changes, it doesn't tell me if it was that one specific commit which broke things. 😛

@JDGBOLT

This comment has been minimized.

Show comment
Hide comment
@JDGBOLT

JDGBOLT Oct 18, 2018

Sorry, was getting a save game and disabling all the mods installed and such:
shadow-test.zip

Also will do a test bisect using your branch without any of my local patches/changes, though that will take some time so bear with me.

JDGBOLT commented Oct 18, 2018

Sorry, was getting a save game and disabling all the mods installed and such:
shadow-test.zip

Also will do a test bisect using your branch without any of my local patches/changes, though that will take some time so bear with me.

@JDGBOLT

This comment has been minimized.

Show comment
Hide comment
@JDGBOLT

JDGBOLT Oct 18, 2018

Okay, I can confirm that it was ce15369 which broke things, and another interesting thing, it looks like the colors changing are from the fix that I have to apply to the lighting.glsl file of 1 to 0 in the for loop for the framerate not to be 3 fps on my system. Though another interesting thing is that it has the same sorts of corruption with the blocks shown in the shadows disabled code that is shown in the https://streamable.com/8onjt video. So I think that change that I made by changing 1 to 0 just made it really apparent, and something was still broken underneath the scenes. Hopefully this helps.

JDGBOLT commented Oct 18, 2018

Okay, I can confirm that it was ce15369 which broke things, and another interesting thing, it looks like the colors changing are from the fix that I have to apply to the lighting.glsl file of 1 to 0 in the for loop for the framerate not to be 3 fps on my system. Though another interesting thing is that it has the same sorts of corruption with the blocks shown in the shadows disabled code that is shown in the https://streamable.com/8onjt video. So I think that change that I made by changing 1 to 0 just made it really apparent, and something was still broken underneath the scenes. Hopefully this helps.

@AnyOldName3

This comment has been minimized.

Show comment
Hide comment
@AnyOldName3

AnyOldName3 Oct 18, 2018

Member

Are you using this version of the mesa patch or one of the older ones? This is the only version which is correct for both per-pixel and per-vertex lighting.

Member

AnyOldName3 commented Oct 18, 2018

Are you using this version of the mesa patch or one of the older ones? This is the only version which is correct for both per-pixel and per-vertex lighting.

@AnyOldName3

This comment has been minimized.

Show comment
Hide comment
@AnyOldName3

AnyOldName3 Oct 18, 2018

Member

Apparently I'd linked the wrong ones in the post at the top, so it's possible that you're not using the right one.

Member

AnyOldName3 commented Oct 18, 2018

Apparently I'd linked the wrong ones in the post at the top, so it's possible that you're not using the right one.

@JDGBOLT

This comment has been minimized.

Show comment
Hide comment
@JDGBOLT

JDGBOLT Oct 18, 2018

Yep, that is the patch that I have been using.

Yeah, the patch that you put out certainly does seem to have fixed the issue of statics and other things changing and shifting colors. It specifically seems to be related to things that put out particle effects, such as flames from torches or candles or whatever, and also the sparks from sotha sil are also affected.

JDGBOLT commented Oct 18, 2018

Yep, that is the patch that I have been using.

Yeah, the patch that you put out certainly does seem to have fixed the issue of statics and other things changing and shifting colors. It specifically seems to be related to things that put out particle effects, such as flames from torches or candles or whatever, and also the sparks from sotha sil are also affected.

@AnyOldName3

This comment has been minimized.

Show comment
Hide comment
@AnyOldName3

AnyOldName3 Oct 18, 2018

Member

I can't replicate the glitter smoke or the colour changing flames with out without shadows enabled, with or without the Mesa patch. Is just loading that save enough to trigger the issue for you, or do you need to do something like go outside and inside again?

If not, can you record an APITrace of the issue so I can see if I can play it back at my end? If it shows up during playback on your machine but not mine, then it's either a driver bug, or something's relying on undefined behaviour.

Member

AnyOldName3 commented Oct 18, 2018

I can't replicate the glitter smoke or the colour changing flames with out without shadows enabled, with or without the Mesa patch. Is just loading that save enough to trigger the issue for you, or do you need to do something like go outside and inside again?

If not, can you record an APITrace of the issue so I can see if I can play it back at my end? If it shows up during playback on your machine but not mine, then it's either a driver bug, or something's relying on undefined behaviour.

@JDGBOLT

This comment has been minimized.

Show comment
Hide comment
@JDGBOLT

JDGBOLT Oct 18, 2018

Here is a trace that will hopefully work, where I basically just load the save game right in front of the flames. https://mega.nz/#!sShxkILK!I3QV2Znn-Q6D1BElwZHdNYAVSmxBJuwavdV_GAcOjoo

JDGBOLT commented Oct 18, 2018

Here is a trace that will hopefully work, where I basically just load the save game right in front of the flames. https://mega.nz/#!sShxkILK!I3QV2Znn-Q6D1BElwZHdNYAVSmxBJuwavdV_GAcOjoo

@AnyOldName3

This comment has been minimized.

Show comment
Hide comment
@AnyOldName3

AnyOldName3 Oct 18, 2018

Member

The bugs aren't visible in that trace, so it's either Mesa's fault, or the correct behaviour is reliant on something undefined or implementation-dependent. Bugger. That might be a nightmare to track down.

Member

AnyOldName3 commented Oct 18, 2018

The bugs aren't visible in that trace, so it's either Mesa's fault, or the correct behaviour is reliant on something undefined or implementation-dependent. Bugger. That might be a nightmare to track down.

@lysol90

This comment has been minimized.

Show comment
Hide comment
@lysol90

lysol90 Oct 19, 2018

Contributor

Built again, and the coloring on the Silt Strider is gone but the smoke from Seyda Neen's chimneys are still flickering in blue. So yes, might be a mesa bug since I'm also on those... Haven't tried the patch yet.

Contributor

lysol90 commented Oct 19, 2018

Built again, and the coloring on the Silt Strider is gone but the smoke from Seyda Neen's chimneys are still flickering in blue. So yes, might be a mesa bug since I'm also on those... Haven't tried the patch yet.

@AnyOldName3

This comment has been minimized.

Show comment
Hide comment
@AnyOldName3

AnyOldName3 Oct 19, 2018

Member

I'm inclined to assume it's a Mesa incompatibility rather than a Mesa bug just because I'm pretty sure Mesa is meant to have better compliance than most other OpenGL drivers, so a bug is less likely.

By the way (and I'm not necessarily saying you two should actually do anything with this information as then I lose my best Mesa testers) isn't there a new open-source AMD GPU driver for Linux called AMDGPU, and isn't it much faster than regular Mesa? I thought there was and it used a lot of code which AMD opened up from their proprietary Windows driver, so was taking advantage of years of extra optimisation effort.

Member

AnyOldName3 commented Oct 19, 2018

I'm inclined to assume it's a Mesa incompatibility rather than a Mesa bug just because I'm pretty sure Mesa is meant to have better compliance than most other OpenGL drivers, so a bug is less likely.

By the way (and I'm not necessarily saying you two should actually do anything with this information as then I lose my best Mesa testers) isn't there a new open-source AMD GPU driver for Linux called AMDGPU, and isn't it much faster than regular Mesa? I thought there was and it used a lot of code which AMD opened up from their proprietary Windows driver, so was taking advantage of years of extra optimisation effort.

@psi29a

This comment has been minimized.

Show comment
Hide comment
@psi29a

psi29a Oct 19, 2018

Member

@AnyOldName3 I use AMDGPU on my hybrid laptop. DRI_PRIME=1 openmw (to run on AMD)

Member

psi29a commented Oct 19, 2018

@AnyOldName3 I use AMDGPU on my hybrid laptop. DRI_PRIME=1 openmw (to run on AMD)

@JDGBOLT

This comment has been minimized.

Show comment
Hide comment
@JDGBOLT

JDGBOLT Oct 19, 2018

The AMD situation on Linux is a bit complicated, I am in fact using AMDGPU. The thing with the AMD situation on linux is that there are multiple layers that go along with it. You have the drivers within the kernel which is what talks to the hardware itself, which is either the older Radeon driver, which might be the only way for some older cards to work at the moment, and the newer AMDGPU driver which supports things like the Southern Island cards and Polaris and Vega. Then on the Userspace side of things you have Mesa which is the actual OpenGL library, and this consists of various drivers for different hardware, such as RadeonSI I think for AMD, i965 for Intel, etc... So when people say Mesa, if they are running recent hardware, underneath within the kernel it's the AMDGPU module running things. Then you have the confusion of 3 different Vulkan drivers and also AMDGPU-Pro which is what the proprietary drivers are now, which have better compatibility with some commercial software workloads and is kept around now mostly for those sorts of things. You might also be thinking of AMDVLK, which is a vulkan driver put out by AMD which is based in part on their proprietary vulkan implementation, and one of the 3 vulkan drivers I mentioned, the others being Radv and the one built into AMDGPU-Pro. Then there is the Shader compiler contained within LLVM, and various other bits and pieces that keep things running. I don't blame you for thinking otherwise, it's a lot of different layers to keep track of.

JDGBOLT commented Oct 19, 2018

The AMD situation on Linux is a bit complicated, I am in fact using AMDGPU. The thing with the AMD situation on linux is that there are multiple layers that go along with it. You have the drivers within the kernel which is what talks to the hardware itself, which is either the older Radeon driver, which might be the only way for some older cards to work at the moment, and the newer AMDGPU driver which supports things like the Southern Island cards and Polaris and Vega. Then on the Userspace side of things you have Mesa which is the actual OpenGL library, and this consists of various drivers for different hardware, such as RadeonSI I think for AMD, i965 for Intel, etc... So when people say Mesa, if they are running recent hardware, underneath within the kernel it's the AMDGPU module running things. Then you have the confusion of 3 different Vulkan drivers and also AMDGPU-Pro which is what the proprietary drivers are now, which have better compatibility with some commercial software workloads and is kept around now mostly for those sorts of things. You might also be thinking of AMDVLK, which is a vulkan driver put out by AMD which is based in part on their proprietary vulkan implementation, and one of the 3 vulkan drivers I mentioned, the others being Radv and the one built into AMDGPU-Pro. Then there is the Shader compiler contained within LLVM, and various other bits and pieces that keep things running. I don't blame you for thinking otherwise, it's a lot of different layers to keep track of.

@wareya

This comment has been minimized.

Show comment
Hide comment
@wareya

wareya Oct 19, 2018

Contributor

AMDGPU is only for new graphics cards. You can't use it with a 5770 for example.

By the way (and I'm not necessarily saying you two should actually do anything with this information as then I lose my best Mesa testers) isn't there a new open-source AMD GPU driver for Linux called AMDGPU, and isn't it much faster than regular Mesa? I thought there was and it used a lot of code which AMD opened up from their proprietary Windows driver, so was taking advantage of years of extra optimisation effort.

Contributor

wareya commented Oct 19, 2018

AMDGPU is only for new graphics cards. You can't use it with a 5770 for example.

By the way (and I'm not necessarily saying you two should actually do anything with this information as then I lose my best Mesa testers) isn't there a new open-source AMD GPU driver for Linux called AMDGPU, and isn't it much faster than regular Mesa? I thought there was and it used a lot of code which AMD opened up from their proprietary Windows driver, so was taking advantage of years of extra optimisation effort.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment