[refactor, vk] DynamicState, ExtendedDynamicState and VertexInputDynamicState #3074
Maufeat
crueter
MrPurple666
MaranBr
DraVee
Lizzie
CamilleLaVey
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "true-eds"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This PR rewrites the DynamicState, ExtendedDynamicState and VertexInputDynamicState logic:
Nota de desarrollo #1:
Primeramente, dejar claro que este approach es una fase "en limpio" de lo que constituye "stuffmadeforfun", 2981 creció de manera exponencial, más allá de respetar los límites claros por los que se creó, el cual era dar un enfoque directo a drivers móbiles y seguir mejorando mi ya exitoso arreglo para stock drivers en adreno (veáse #2732 + #2981), sin embargo para tener certeza de las debilidades del driver stock en Adreno, se recurrió a iniciar pruebas de configuración de driver, configuración de comportamiento que permitiése encontrar razones verdaderas tras no solo las excepciones de utilidad encontradas en el device virtual, sino, confirmar que extensiones realmente se encontraban mal en su implemetación y no fuése culpa de un backend defectuoso:
Así inició este refactor para DynamicState, ExtendedDynamicState y VertexInputDynamicState (a los cuales nos referimos acortadamente como DS, EDS y VIDS); cambiando completamente la lógica en la que se manejaba su configuración, previamente solamente se verificaba si existía la extensión en driver, si driver reportaba soporte, se usaba directamente sin cacular los features reales disponibles, asumiendo que la extensión completa es funcional, sin tener en cuenta que hay drivers que realmente no reportan todas los features (veáse AMDVLKL vs RADV y QCOM vs Freedreno Turnip), los comandos se pasaban directamente a la creación de pipelines, pero al carecer de todas las features asumidas como válidas, generaba inconsistencia no solo en la estabilidad, pero también en los errores gráficos que se podría usar; solamente tras haber pasado el flag de cálculo de extensiones, recién se procedía con la anulación de features o extensiones reportadas (Yuzu) como erradas en los diferentes tipos de drivers (driver_ID) considerados en el device virtual.
No solamente era un approach completamente errado, sino, porque también tras la manipulación en Eden, se añadió un metódo de configuración (user friendly/ UI) dónde se permite cambiar entre 4 estados:
EDS O = Apaga todos los estados dinámicos, fuerza GPU a usar formatos emulados (esto parcialmente daba la sensación de dar mejor rendimiento para la mayoría de usuarios, pero el manejo en pipeline realmente omitía comandos de compilación de shaders en spir-v, generando errores múltiples a nivel de gráficos, estabilidad y añadir un overhead de formatos emulados innecesario), véase que los formatos emulados SScaled, realmente no están disponibles en Android, pero plataformas x86_64 (AMD/ Nvidia) no tienen este problema (veáse
2beb3051c1).EDS 1 - 3/ VIDS: Cómo la lógica previa lo estipulabla, se establecía que la extensión completa estaba disponible, sin embargo el orden entre el cálculo de features y la excepción de extensiones problemáticas, tenían no solo un orden erróneo, pero también, un uso impuesto que obligaba a los drivers (incluso si estaban removidos, a usar features que no debían) a mezclar EDS con VIDS, sin contemplar el handling adecuado entre reemplazar funciones con la extensión activa, la cuál se establecía/ activaba junto con el slider (if slider is 1), ocultando o enmascarando comandos en render, que al tratar de rastrear errores gráficos, dificultaba.
En sí, en un principio en Eden (y yo en particular) no estuvimos conscientes de que partes eran requeridas para la emulación de formatos, se asumió que los drivers de manera global carecían de los formatos disponibles en Switch, craso error, tras haber sido conscientes de que múltiples errores de render aparecían y no saber detectar la razón de estos, decidí por adentrarme más en las especificaciones según lo establece Vulkan para su uso; reconociendo que realmente los estados dinámicos requieren tener un uso granular, modular por driver y flexibles en el renderpass, para que así no solo se usen eficientemente, sino, para que reduzcan los errores que previamente aparecían tras usar mal el nivel del slider. Cómo verán, este pull request, contendrá más que un solo refactor y organización de features para estados dinámicos, busca reemplazar y solucionar de raíz problemas que actualmente son parcheados superficialmente, buscará entender mejor los errores en driver y abrirá mejor compatibilidad a drivers de manera general.
Recientemente se aplicó un parche para solucionar de manera temporal las explosiones vertex, flickering en objetos y modelos de personajes lejanos, sin embargo, al no contener todos los avances de la rama stuffmadeforfun, este pull request avanzará lento con mayor supervisión de reviewers y testers, en orden de brindar una implementación más estable, siendo que no solo se centrará en el refactor de estados dinámicos, sino, también arreglar problemas que surjan en el trayecto conforme se vea necesario para tener ExtendedDynamicState usable para todos.
@ -556,4 +544,1 @@}}if (extensions.extended_dynamic_state3 && (is_amd_driver || driver_id == VK_DRIVER_ID_SAMSUNG_PROPRIETARY)) {Need to remove the is_amd_driver here too
Samsung driver gets detected as AMD driver, hence the handling.
Why is the same thing being done but in a different place from usual?
// AMD/Samsung: Broken extendedDynamicState3ColorBlendEquation// Disable blend equation dynamic state, force static pipeline stateif (extensions.extended_dynamic_state3 &&(is_amd_driver || driver_id == VK_DRIVER_ID_SAMSUNG_PROPRIETARY)) {LOG_WARNING(Render_Vulkan,"AMD/Samsung: Disabling broken extendedDynamicState3ColorBlendEquation");features.extended_dynamic_state3.extendedDynamicState3ColorBlendEnable = false;features.extended_dynamic_state3.extendedDynamicState3ColorBlendEquation = false;}@CamilleLaVey wrote in #3074/files (comment):
Then it keeps the removal for normal AMD?
Removed AMD from the if instance, will requiere Exynos users which are detected/ considered as RDNA2 to properly acknowledge the extension without rendering issues.
@ -1118,0 +1178,4 @@features.vertex_input_dynamic_state.vertexInputDynamicState = false;}// Intel Windows < 27.20.100.0: Broken VertexInputDynamicStateAlready handled here:
switch (Settings::values.dyna_state.GetValue()) {case 0:RemoveExtensionFeature(extensions.extended_dynamic_state, features.extended_dynamic_state, VK_EXT_EXTENDED_DYNAMIC_STATE_EXTENSION_NAME);[[fallthrough]];This note is meant for the code below btw
Deleted double ban and aligining to my current ban order system.
why are you putting them in a lower place then they are usually, shouldn't it be consistent?
You're not understanding the logic of the device creation, file doesn't get read upside down, bans should be alocated before extensions validation and flag calculation for features, since the last step is runtime, this way we respect and use only features allowed per-driver and not assuming complete behavior.
I'm just saying you removed this from where it should be:
And added it later when you should have left it as it was before in the correct place:
No, it's right where it should be.
It’s not consistent and makes our code a pain to work with but sure
New commits pushed, approval review dismissed automatically according to repository settings
DraVee referenced this pull request2025-11-26 19:49:21 +01:00
[Refactor, vk] DynamicState, ExtendedDynamicState and VertexInputDynamicStateto [refactor, vk] DynamicState, ExtendedDynamicState and VertexInputDynamicState58b2a8a810de01ed6102de01ed6102b6e87794b2b6e87794b25d9014a59b9aa560c9445d9014a59b5d9014a59b68edde944af659d5b2b520b171ded39bba4db5dd04c29645a204c29645a2ba6a46c875ba6a46c8756e97c42f5d6e97c42f5db5c5794c96b5c5794c968ecc86f7bf8ecc86f7bf92e24b92d892e24b92d8e87e958909c6115a2d65d1e9419b9ad1e9419b9abe2deced5024488705af2968b42c8b2968b42c8b2df0adeacc