https://bugs.winehq.org/show_bug.cgi?id=39057
swswine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #52830|0 |1 is obsolete| |
--- Comment #55 from swswine@gmail.com --- Created attachment 52947 --> https://bugs.winehq.org/attachment.cgi?id=52947 Patch to implement indexed vertex blending (updated), wine 1.8-rc2
(In reply to Matteo Bruni from comment #54)
I would probably drop indexed vertex blending with plain uniforms altogether, it looks too messy and e.g. allocating extra ~1KB for modelview_matrix_location[] for each GLSL shader doesn't seem justifiable.
I am not comfortable dropping it because the only person who actively tests my patch here is keen of running it under GL 2.1 :)). IVB might be used by old games working fine on old hardware, should not we attempt to support it? Actually I set only 150 matrices if no UBO, so it just 600 bytes. It can be further reduced by making it dynamic, so the space will be allocated only for the shaders which actually use IVB (if it is not too messy for these 600 bytes). It seemed to me that the most messy part is selective matrix update logic which is currently more tricky for the UBO part. But if you are sure that it is better to drop non-UBO support than I will of course drop it.
You should probably add a separate field in d3d_info.limits for the indexed limit (and avoid touching ffp_vertex_blend_matrices) and use it where necessary. You should also report 0 (or 8, but since there is real hardware on Windows returning 0 that is okay) indexed vertex blending matrices for devices not created with the D3DCREATE_SOFTWARE_VERTEXPROCESSING flag (I think you can look that up from device->create_parms.flags).
done. Considering D3DCREATE_SOFTWARE_VERTEXPROCESSING flag looks a bit messy as done outside the function where all the caps are filled in, but this function (wined3d_get_device_caps in directx.c) does not have access to device structure and thus can't get that flag. Changing its parameters is tricky as it is exported function and changing it will require fixing it's call across the tree. I've verified that the wined3d_device_get_device_caps in wined3d/device.c actually used in d3d9 GetDeviceCaps implementation, and tested that reported capabilities are those we expect.
I don't think you need a static variable (or a variable at all) to store the next update_id value, unless I'm missing something.
I've changed this part now: I figured out now how to get a link to a shader priv structure from the context update handler and replaced transform context update versioning with just a plain flag in shader_priv structure.