-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Remove "hardware" skinning #16345
Remove "hardware" skinning #16345
Conversation
This will affect bleach the heat soul 7 and monster hunter games in my mali 450 gpu #10775 |
Oh right, we tried this once before, I forgot... |
Just weird to me that it makes such a difference in those games. Wonder if anything has changed.... |
I will test again using the recently build on my mali 450 gpu phone. |
Well, still noticeable for sure. Although it'll only affect some games, and only one some old phones... Undecided, heh. |
@@ -823,15 +823,6 @@ static void check_variables(CoreParameter &coreParam) | |||
g_Config.bHardwareTransform = true; | |||
} | |||
|
|||
var.key = "ppsspp_software_skinning"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, this doesn't actually remove the option in the other file I think?
-[Unknown]
GPU/GPUCommon.cpp
Outdated
// Changing the vertex type requires us to flush. | ||
{ GE_CMD_VERTEXTYPE, FLAG_FLUSHBEFOREONCHANGE | FLAG_EXECUTEONCHANGE, 0, &GPUCommon::Execute_VertexType }, | ||
// Changing the vertex type requires us to flush, unless we just change the weight count - need to handle in a func. | ||
{ GE_CMD_VERTEXTYPE, FLAG_EXECUTEONCHANGE, 0, &GPUCommon::Execute_VertexTypeSkinning }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: We should probably just rename it.
-[Unknown]
Hm, 25% is a lot. I feel like that's probably a case where it's using the same bones for a lot of (maybe offscreen?) drawing, which is the best case for hardware skinning I can imagine. I wonder if there's a world in which we could decode using threads (for large draw calls, if that game even uses large ones) to close the gap? I like the binding thing, though. -[Unknown] |
2bd42ef
to
c8d6d68
Compare
@@ -168,6 +168,13 @@ void SoftwareTransform::SetProjMatrix(float mtx[14], bool invertedX, bool invert | |||
projMatrix_.translateAndScale(trans, scale); | |||
} | |||
|
|||
static void ReadWeightedNormal(Vec3f &source, VertexReader &reader, u32 vertType) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess we can still have this func, but don't really need it now. If we do keep, we should probably use it for the initial read too.
-[Unknown]
Just to note MH games probably show the most difference in the village area that have a lot of NPC with bones. That area is just a management hub so not really terrible if it lag a bit on old device. AFAIR on my old phone HW was 30% slower than SW tho' (but many many build ago). |
Extract the Vulkan descriptor binding cleanup from #16345
After this, we only skin directly during decode. Much simpler, and is fast enough. "Hardware" (vertex shader skinning) didn't make good use of the hardware due to OpenGL limitations, and it's not really worth making a faster Vulkan implementation since skinning is never really a bottleneck these days.
Part of option cleanup - and as a benefit, lets us get rid of quite a large amount of code.
Will only reconsider if someone can show a popular device with a game that runs noticeably faster with hardware skinning than software skinning, which I think is unlikely.