Do you have a test application for this?

Patch submissions are not accepted on bugzilla, to discuss your implementation I would suggest to ask for comments on the wine-devel mailing list:
https://www.winehq.org/mailman/listinfo/wine-devel

When you think the implementation is good enough, you can also send it to the wine-patches mailing list, take a look here for additional guidelines regarding patch submission:
http://wiki.winehq.org/SubmittingPatches

(In reply to super_man from comment #1)
> Do you have a test application for this?

AFAIK it affects most of Illusion games (example WineHQ forum discussion: https://forum.winehq.org/viewtopic.php?f=8&t=24954)

I've tested it on one of those (AG3: https://appdb.winehq.org/objectManager.php?sClass=application&iId=7352).

(In reply to Sebastian Lackner from comment #2)
> Patch submissions are not accepted on bugzilla, to discuss your
> implementation I would suggest to ask for comments on the wine-devel mailing
> list:
> https://www.winehq.org/mailman/listinfo/wine-devel
> 
> When you think the implementation is good enough, you can also send it to
> the wine-patches mailing list, take a look here for additional guidelines
> regarding patch submission:
> http://wiki.winehq.org/SubmittingPatches

Thank you for your comment. I realize that the patch won't be accepted from here.
I actually just wanted to file a bug (as 6955 is already closed). I also wanted to put patch here for now if it is possible (like numerous patches for bug 6955 were attached for different wine versions previously). Maybe someone will test it first, or include into PlayOnLinux as a separate build.

Created attachment 52718 [details]
strange shadow

Thanks for this patch i can test BattleRaper2, it almost working but still have problem, it shows some strange shadow when edit first role in the game. wine 1.5.28 with software vertex blending patch works fine without this problem. Maybe need to continue upgrade this patch.

My test environment:
wine 1.7.54
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Mobile Intel® GM45 Express Chipset 
OpenGL version string: 2.1 Mesa 10.3.2
OpenGL shading language version string: 1.20

Created attachment 52722 [details]
Patch to implement indexed vertex blending support (wine 1.7.54)

I've updated the patch for wine 1.7.54 and further increased the number of world matrices. Hope that helps.

It's working after apply new patch for wine 1.7.54. nice work!

Bug 38326 resolved with this patch.
Thank you!

*** Bug 38326 has been marked as a duplicate of this bug. ***

Bug 38326 looks unrelated to this patch, seems like nothing in this patch that could help with shader compile warnings listed there. Perhaps something else has also changed between your 3DMark tests.
I've run 3DMark03 with stock wine 1.7.53 without any custom patches (with -nosysteminfo option, without which it does not work due to some COM related issues). It worked for me without any problems or warnings like yours.

I thought I had already commented here but apparently that's not the case :/

Not going into the details of the patch, the main issue here is that, on Windows, indexed vertex blending is only supported with software vertex processing - MaxVertexBlendMatrixIndex is 0 for hardware devices and 255 for software devices on all the boxes I tested. So this feature should be only exposed for software vertex processing but at the moment wined3d ignores that flag entirely. That should be fixed, in some measure, before implementing indexed vertex blending.

It's probably okay to think about implementing software VP and indexed vertex blending with GLSL. There's the issue you encountered with the large amount of uniforms needed. I think requiring and using uniform buffer objects for that is the way forward.

Thank you very much for clarification.

I will get back to this and try implementing this patch through uniform buffer objects within a couple of weeks when I have more time.

Regarding software & H/W vertex processing, the games I've seen using indexed vertex blending (IVB) had configuration option to choose between software and hardware vertex processing, but IVB was used in both modes. I had MaxVertexBlendMatrixIndex constantly set to 0 initially in my patched wined3d (updated this field setting in the patch later), this was ignored by these games, they used as much VB matrices they wanted without any error. So is it possible that at least some (or many) Windows drivers advertise 0 matrices in H/W mode but actually support up to 256 if requested? If yes, should not wine d3dx9 just do the same: just support IVB with 256 matrices in H/W mode (and in software mode when it is in place) but advertise 0 in H/W mode (or let this value to be configured)?

BTW I came across similar issue with number of supported uniforms in HLSL shader. DX9 advertises max of 256 uniforms. I came through some games failing to compile HLSL vertex shader under wine due to excessive number of uniforms they were trying to use. I worked that around by simply increasing the constant for max number of uniforms in wine d3d9, it worked. Apparently these games work on Windows which means that Windows drivers do support bigger number of uniforms per HLSL shader while advertising 256. Should not wine do the same: advertise 256 but allow up to the limit actually supported by underlying GL driver?

(In reply to swswine from comment #13)
> Thank you very much for clarification.
> 
> I will get back to this and try implementing this patch through uniform
> buffer objects within a couple of weeks when I have more time.
> 
> Regarding software & H/W vertex processing, the games I've seen using
> indexed vertex blending (IVB) had configuration option to choose between
> software and hardware vertex processing, but IVB was used in both modes. I
> had MaxVertexBlendMatrixIndex constantly set to 0 initially in my patched
> wined3d (updated this field setting in the patch later), this was ignored by
> these games, they used as much VB matrices they wanted without any error. So
> is it possible that at least some (or many) Windows drivers advertise 0
> matrices in H/W mode but actually support up to 256 if requested? If yes,
> should not wine d3dx9 just do the same: just support IVB with 256 matrices
> in H/W mode (and in software mode when it is in place) but advertise 0 in
> H/W mode (or let this value to be configured)?

If that's the case, yes. Notice that the game might create the device with D3DCREATE_MIXED_VERTEXPROCESSING when the "hardware" mode is selected (you can check that from a +d3d9 trace). Ultimately this needs tests to figure out what exactly is supported in every vertex processing mode.

> BTW I came across similar issue with number of supported uniforms in HLSL
> shader. DX9 advertises max of 256 uniforms. I came through some games
> failing to compile HLSL vertex shader under wine due to excessive number of
> uniforms they were trying to use. I worked that around by simply increasing
> the constant for max number of uniforms in wine d3d9, it worked. Apparently
> these games work on Windows which means that Windows drivers do support
> bigger number of uniforms per HLSL shader while advertising 256. Should not
> wine do the same: advertise 256 but allow up to the limit actually supported
> by underlying GL driver?

That should only happen with the so-called "software vertex shaders" i.e. https://msdn.microsoft.com/en-us/library/windows/desktop/bb147365%28v=vs.85%29.aspx#Software_Vertex_and_Pixel_Shaders , which AFAIK are also only supported with SOFTWARE or MIXED vertex processing. I think those should also be implemented via GLSL + UBOs but that's probably quite a bit harder than the related fixed function stuff (i.e. indexed vertex blending) in current wined3d.

Notice that I don't want to discourage you (far from it ;) and your work on this is very much appreciated.

Created attachment 52746 [details]
Patch to implement index version support (using UBO, wine 1.7.55)

I updated the patch to use UBOs to transfer blend matrices, and now all 256 possible matrices are supported. The patch is for wine release 1.7.55.

Vertex blending without indices also use UBO with this patch. The patch is still not optimal in a sense that there are much of extra updates of the buffer with all the 256 matrices on any transform matrix change or view matrix change (and even for every shader which is redundant as UBO is common for all shaders). But this is in place only if vertex blending is actually requested by application. If not, UBO is not created (and '#extension GL_ARB_uniform_buffer_object' is not added), and glsl shader is even simplified a bit compared to current release version. So I hope this patch should not introduce any regression for the applications not using vertex blending.

Neater solution on matrix update is of course possible but requires getting deeper into glsl pipeline update logic.

Created attachment 52747 [details]
Patch to implement indexed vertex blending support (using UBO, wine 1.7.55)

(In reply to swswine from comment #15)
> Created attachment 52746 [details]
> Patch to implement index version support (using UBO, wine 1.7.55)

In principle it seems okay, although the first thing to do is to test the various things I mentioned in my previous post. You could write a d3d9 test checking for the value of MaxVertexBlendMatrixIndex for devices created with the different D3DCREATE_*_VERTEXPROCESSING values.
This also needs a test for the actual indexing vertex blending functionality. It should be easy to create one by copying and modifying test_vertex_blending() in d3d9/tests/visual.c.

> Vertex blending without indices also use UBO with this patch.

That's probably not okay, it would mean losing non-indexed vertex blending support if the driver / GPU doesn't support UBOs. It's not the most critical issue here though.

> The patch is
> still not optimal

Yeah, it will have to be made somewhat smarter with not uploading all the data every time.

A few more things from a quick look. You shouldn't report indexed vertex blending when the ARB_uniform_buffer_object extension isn't around (or for hardware vertex processing, unless the tests disagree). You shouldn't change MAX_VERTEX_BLENDS but create a separate define: MaxVertexBlendMatrices is 4 even for software devices. And please, try to fix formatting and indentation.

BTW, I strongly suggest you to setup a Wine git repository clone and base your work on it. You'll find it much easier to maintain your patches as Wine changes, generate diffs etc.

(In reply to Matteo Bruni from comment #17)
Thank you for the review. I will follow your recommendations and hopefully will  come up with production level patch eventually. Everything is clear and doable by me except for the following: 

> In principle it seems okay, although the first thing to do is to test the
> various things I mentioned in my previous post. You could write a d3d9 test
> checking for the value of MaxVertexBlendMatrixIndex for devices created with
> the different D3DCREATE_*_VERTEXPROCESSING values.

I do not have Windows in place and much of various GPU hardware.  Do you know some realistic way to check native DirectX responses without Windows? Is it some place to post d3d9 test so that someone will run it and send responses?

(In reply to swswine from comment #16)
> Created attachment 52747 [details]
> Patch to implement indexed vertex blending support (using UBO, wine 1.7.55)

Hi swswine.

I applied this patch for wine 1.7.55. then test the game battleraper2 crash when it start. Could you review the error log? It seem calling shader_glsl_select cause crash.

----------------------------------
err:dmloader:IDirectMusicLoaderImpl_SetObject : could not attach stream to file
fixme:dmime:IDirectMusicPerformance8Impl_InitAudio (0x1d5a4b8, (nil), 0x6efebc, 0x1004a, 1, 64, 3f, (nil)): to check
fixme:dmime:IDirectMusicPerformance8Impl_Init (iface = 0x1d5a4b8, dmusic = (nil), dsound = 0x1d5a8b4, hwnd = 0x1004a)
fixme:dmime:IDirectMusicPerformance8Impl_CreateStandardAudioPath (0x1d5a4b8)->(1, 64, 0, 0x1d5a684): semi-stub
fixme:dmime:IDirectMusicAudioPathImpl_Activate (0x1d7c9b8, 0): stub
fixme:dmime:IDirectMusicPerformance8Impl_GetDefaultAudioPath (0x1d5a4b8, 0x6efed0): semi-stub (0x1d7c9b8)
err:quartz:GetClassMediaFile Media class not found
fixme:d3d:wined3d_device_set_software_vertex_processing device 0x1c5ef0, software 0 stub!
wine: Unhandled page fault on read access to 0x00000000 at address (nil) (thread 0009), starting debugger...
Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x00000000).
Register dump:
 CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
 EIP:00000000 ESP:0032f4cc EBP:0032f548 EFLAGS:00210246(  R- --  I  Z- -P- )
 EAX:01da4c80 EBX:7ebd8b30 ECX:00000000 EDX:7eb99a6f
 ESI:01da4c80 EDI:001bf5d0
Stack dump:
0x0032f4cc:  7eb058b2 00000006 0015c5e0 0000000f
0x0032f4dc:  7eb16f5c 001bf5d0 00000006 00000001
0x0032f4ec:  00127ec4 00000002 7d0a11b4 7d6958a4
0x0032f4fc:  7d45e16f 7cf942d4 7d0a11b4 0032f514
0x0032f50c:  7d359d7d 7ebdc659 00127eb0 7d45e04b
0x0032f51c:  00000000 01d9bdec 7eb99a48 001bf5d0
Backtrace:
=>0 0x00000000 (0x0032f548)
  1 0x7eb18f22 shader_glsl_select+0x1ba1() in wined3d (0x0032f668)
  2 0x7eadfc45 context_apply_draw_state+0xf84() in wined3d (0x0032f6d8)
  3 0x7eb0066c draw_primitive+0x1eb() in wined3d (0x0032f928)
  4 0x7eae12d3 wined3d_cs_exec_draw+0x22() in wined3d (0x0032f958)
  5 0x7eae0596 wined3d_cs_st_submit+0x25() in wined3d (0x0032f978)
  6 0x7eae14dd wined3d_cs_emit_draw+0x3c() in wined3d (0x0032f998)
  7 0x7eaf1615 wined3d_device_draw_indexed_primitive+0x74() in wined3d (0x0032f9e8)
  8 0x7ebf7804 d3d9_device_DrawIndexedPrimitive+0xb3() in d3d9 (0x0032fa38)
  9 0x004da2a2 in battleraper2 (+0xda2a1) (0x0032fb20)
  10 0x004db4f3 in battleraper2 (+0xdb4f2) (0x0032fc9c)
  11 0x004daca6 in battleraper2 (+0xdaca5) (0x0032fcb0)
  12 0x004017cd in battleraper2 (+0x17cc) (0x0032fcdc)
  13 0x004063fd in battleraper2 (+0x63fc) (0x0032fd38)
  14 0x0059b913 in battleraper2 (+0x19b912) (0x0032fe60)
  15 0x7b85bfec call_process_entry+0xb() in kernel32 (0x0032fe78)
  16 0x7b85cf7a start_process+0x59() in kernel32 (0x0032fea8)
  17 0x7bc7a7c0 call_thread_func_wrapper+0xb() in ntdll (0x0032fec8)
  18 0x7bc7d581 call_thread_func+0xb0() in ntdll (0x0032ffa8)
  19 0x7bc7a79e call_thread_entry_point+0x11() in ntdll (0x0032ffc8)
  20 0x7bc50cc7 start_process+0x16() in ntdll (0x0032ffe8)
  21 0xf76211bd wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000)
  22 0xf7621320 wine_switch_to_stack+0x1f() in libwine.so.1 (0xffdaa748)
  23 0x7bc567e5 LdrInitializeThunk+0x1f4() in ntdll (0xffdaa788)
  24 0x7b862d43 __wine_kernel_init+0x9b2() in kernel32 (0xffdab678)
  25 0x7bc575a3 __wine_process_init+0x152() in ntdll (0xffdab6e8)
  26 0xf761ee33 wine_init+0x292() in libwine.so.1 (0xffdab738)
  27 0x7bf00d6a main+0x79() in <wine-loader> (0xffdabb78)
  28 0xf7455a63 __libc_start_main+0xf2() in libc.so.6 (0x00000000)
0x00000000: -- no code accessible --
Modules:
Module  Address                 Debug info      Name (119 modules)
PE        400000-  845000       Export          battleraper2
ELF     7a800000-7a92d000       Deferred        opengl32<elf>
  \-PE  7a820000-7a92d000       \               opengl32
ELF     7b800000-7ba61000       Dwarf           kernel32<elf>
  \-PE  7b810000-7ba61000       \               kernel32
ELF     7bc00000-7bce9000       Dwarf           ntdll<elf>

(In reply to swswine from comment #15)
> Created attachment 52746 [details]
> Patch to implement index version support (using UBO, wine 1.7.55)
> 
> I updated the patch to use UBOs to transfer blend matrices, and now all 256
> possible matrices are supported. The patch is for wine release 1.7.55.
> 
> Vertex blending without indices also use UBO with this patch. The patch is
> still not optimal in a sense that there are much of extra updates of the
> buffer with all the 256 matrices on any transform matrix change or view
> matrix change (and even for every shader which is redundant as UBO is common
> for all shaders). But this is in place only if vertex blending is actually
> requested by application. If not, UBO is not created (and '#extension
> GL_ARB_uniform_buffer_object' is not added), and glsl shader is even
> simplified a bit compared to current release version. So I hope this patch
> should not introduce any regression for the applications not using vertex
> blending.
> 
> Neater solution on matrix update is of course possible but requires getting
> deeper into glsl pipeline update logic.

(In reply to gamiljydcome from comment #19)
> (In reply to swswine from comment #16)
> > Created attachment 52747 [details]
> > Patch to implement indexed vertex blending support (using UBO, wine 1.7.55)
> 
> Hi swswine.
> 
> I applied this patch for wine 1.7.55. then test the game battleraper2 crash
> when it start. Could you review the error log? It seem calling
> shader_glsl_select cause crash.
> 

Did you check that the game starts without the crash if using wine 1.7.55 (released) without this patch built and installed the same way? If yes, could you please run the game crashing with patch with WINEDEBUG=+d3d,+d3d_shader,+winedebug and attach gzipped output (it should produce a lot of output)?

Created attachment 52753 [details]
WINEDEBUG=+d3d,+d3d_shader,+winedebug error log

This is winedebug log, Please review it.

Original wine 1.7.55 can run this game without any crash, broken 3d model of course.

(In reply to gamiljydcome from comment #21)
> Created attachment 52753 [details]
> WINEDEBUG=+d3d,+d3d_shader,+winedebug error log
> 
> This is winedebug log, Please review it.
> 
> Original wine 1.7.55 can run this game without any crash, broken 3d model of
> course.

I see... Your Mesa driver 10.3.2 supports GL 2.1, while GL 3.1 is required to support UBOs. The crash in this situation is a bug in the patch (a function from GL 3.1 specification is called unconditionally which apparently results in NULL pointer call if not supported). I will fix it later to do something more reasonable in such a case along with the other improvements. But this won't help you in your current configuration: it will still not work.

So you can do one of the following:
1. Upgrade Mesa drivers to some later version which supports at least OpenGL 3.1
2. Stay with wine 1.7.54 with my previous patch for running this game

> So you can do one of the following:
> 1. Upgrade Mesa drivers to some later version which supports at least OpenGL
> 3.1
> 2. Stay with wine 1.7.54 with my previous patch for running this game

My video card (mobile intel gm45) HW just support GL2.1, so i keep using the patch for wine 1.7.54, and expect you will continue working on new patch.

Thanks.

(In reply to swswine from comment #18) 
> I do not have Windows in place and much of various GPU hardware.  Do you
> know some realistic way to check native DirectX responses without Windows?
> Is it some place to post d3d9 test so that someone will run it and send
> responses?

There is testbot.winehq.org but that's unfortunately not too helpful with d3d stuff since it only has the software-emulated WARP device (that's in the Win8 and Win10 VMs) which is in general not a good reference for Windows behavior.

I guess you can post your test here, on the wine-devel mailing list or on #winehackers and someone will hopefully run the test for you...

(In reply to swswine from comment #22)
> 2. Stay with wine 1.7.54 with my previous patch for running this game

No problem to rebase this patch for 1.7.55

Created attachment 52787 [details]
Same patch rebased to wine-1.7.55-38

(In reply to Matteo Bruni from comment #24)

> There is testbot.winehq.org but that's unfortunately not too helpful with
> d3d stuff since it only has the software-emulated WARP device (that's in the
> Win8 and Win10 VMs) which is in general not a good reference for Windows
> behavior.
> 
> I guess you can post your test here, on the wine-devel mailing list or on
> #winehackers and someone will hopefully run the test for you...

I have updated dlls/d3d9/tests/visual.c to support indexed vertex blending testing and to print MaxVertexBlendMatrices and MaxVertexBlendMatrixIndex caps. The test is performed for each relevant device creation flag: D3DCREATE_HARDWARE_VERTEXPROCESSING, D3DCREATE_SOFTWARE_VERTEXPROCESSING and D3DCREATE_MIXED_VERTEXPROCESSING. The test is run regardless the MaxVertexBlendMatrixIndex caps to see if indexed vertex blending is actually working or not even if caps suggests it should not. I am adding attachments with patch and with Windows .exe (compiled with 'make crosstest'). The patch also comments out all the other visual tests so it is quicker to run for its purpose. I hope someone can run it on some real Windows machines (not under virtual machines) and send me the full output. 

Apart from this I studied MSDN docs for indexed vertex blending. It suggests that 256 matrices can always be used in case of software vertex processing, and implicitly suggests that it is up to hardware (driver) otherwise, and MaxVertexBlendMatrixIndex should be checked (see here, for instance: https://msdn.microsoft.com/en-us/library/windows/desktop/bb206316(v=vs.85).aspx ; Determining Indexed Vertex Blending Support paragraph). Maybe I can just set MaxVertexBlendMatrixIndex to 255 regardless of vertex processing mode?

Created attachment 52803 [details]
Test to run on Windows machine to verify indexed vertex blending native behaviour

To be run as 'd3d9_crosstest.exe visual'

Created attachment 52804 [details]
IVB test added to d3d9/tests/visual.

This patch was used to build https://bugs.winehq.org/attachment.cgi?id=52803&action=edit
Other tests are commented out.

Created attachment 52807 [details]
Output test visual in Windows 7 X64, Nvidia 9600GT

Created attachment 52810 [details]
visual.exe test win7 32bit, mobile Intel GM45

Created attachment 52812 [details]
There is broken image if no index blending support

Just making the patch for 1.7.54 I have good image.

Created attachment 52816 [details]
Patch to implement indexed vertex blending (updated), wine 1.8-rc1

I updated the patch. The changes are:

1. Reporting capabilities
MaxVertexBlendMatrices is always 4. MaxVertexBlendMatrixIndex is 255 if ARB_UNIFORM_BUFFER is supported, 0 otherwise.

2. Actual IVB support
If ARB_UNIFORM_BUFFER is supported (opengl 3.1+), UBOs are used to store matrices for IVB. UBO is declared in shader and created only if IVB is requested by application.
If ARB_UNIFORM_BUFFER is not supported, it still tries to support IVB if actually requested by application. In this case (and only in this) it works the same way as my initial patch by transferring matrices through plain uniforms. It does not affect vertex blending without indexes (only 4 matrices is declared if IVB is not requested by SetRenderState(... D3DRS_INDEXEDVERTEXBLENDENABLE). The existing functionality should not be affected so far. 

3. Finer uniforms update granularity
Patch adds mask to context which gets bits indicating which world matrices were updated. Besides, the "update version" number is stored for these updates. When processing uniforms updates for shader the mask is checked: only changed matrices are updated. This also relates to vertex blending without indexes.

UBO is updated only if the update version in context was not processed yet (this eliminates redundant updates of UBO when processing uniform updates for multiple shaders). Maybe it would be more straightforward to link UBO update to some other place rather than glsl shader backend, but till now I did not find a better place with relevant update infrastructure. 

While this reduces some of redundant updates, there is still quite a lot of them as shader gets view*model matrices. So when view matrix is updated all the matrices have to be updated also. This cannot be reduced any further if not to move raw model matrices into the shader instead of view*model. But I think it is not a good idea for general case as there will be extra mat4*vec4 multiplication in shader for every vertex in IVB.

If IVB is not requested by application then no UBO or extra matrices are defined or transferred.

4. Conformance test for IVB was added. It tests IVB support in 3 modes (software, hardware and mixed vertex processing). If   MaxVertexBlendMatrixIndex < 7 or MaxVertexBlendMatrices < 4 then the test for the mode is skipped.

Created attachment 52819 [details]
error rendering 3d model not broken with patch for wine 1.8rc1

I've test new patch for wine 1.8rc1.
With card support GL3 (mobile firegl v5700) it works fine.
With card only support GL2.1 (mobile intel gm45) it looks strange as screenshot posted.

So this new patch has some bug for non-ubo maybe.


besides,
I tried modify patch for wine 1.55, replace ubo to vao/vbo(that's supported by GL2.1/glsl1.2), but got totally wrong renderring so i give it up. Could you have a try if you interested?

(In reply to gamiljydcome from comment #34)
> Created attachment 52819 [details]
> With card only support GL2.1 (mobile intel gm45) it looks strange as
> screenshot posted.
> 
Could you please reproduce this with WINEDEBUG=+d3d,+d3d_shader,+d3d9 and attach a gripped output?

Which game is it?

Created attachment 52829 [details]
WINEDEBUG=+d3d,+d3d_shader,+d3d9 trace log, ~400M uncompressed



The game SexyBeach3(plus) runs ok by patch for wine 1.7.54 too. So new patch has some bugs with non-ubo.

Created attachment 52830 [details]
Patch to implement indexed vertex blending (updated), wine 1.8-rc1

(In reply to gamiljydcome from comment #36)
> 
> The game SexyBeach3(plus) runs ok by patch for wine 1.7.54 too. So new patch
> has some bugs with non-ubo.

I found bug for the case when ARB_UNIFORM_BUFFER_OBJECT is not supported. Could you please try with the updated patch?

Created attachment 52835 [details]
wrong renderring  screenshot but not sure because of vertex blend

> I found bug for the case when ARB_UNIFORM_BUFFER_OBJECT is not supported.
> Could you please try with the updated patch?

The bug fixed, nice work!

At least for now, i tested new patch for wine 1.8rc1:
Radeon firegl v5700(GL3.3)  Intel GM45(GL2.1)

BattleRaper2: works fine (ubo, non-ubo)
SexyBeach3: works fine (ubo, non-ubo)
schoolmate2: not working (ubo, non-ubo both)

I'm not sure schoolmate2's problem really caused by vertex blending although the game enabled it. Could you review the trace log?

Created attachment 52836 [details]
WINEDEBUG=+d3d,+d3d_shader,+d3d9 wrong renderring trace log, ~410M

(In reply to gamiljydcome from comment #39)
> Created attachment 52836 [details]
> WINEDEBUG=+d3d,+d3d_shader,+d3d9 wrong renderring trace log, ~410M

I think this is likely not related to IVB. This game uses excessive number of HLSL shader constants (there was a discussion of this also in this bug comments above):
> warn:d3d_shader:shader_record_register_usage Shader using float constant 771 which is not supported.


I suggest you open a separate bug for this (I would call it something like "Support bigger number of shader constants") and put log and maybe screenshot there. 

If you send me the link to this bug I will upload quite a different (and small) patch tomorrow that fixes similar problems for me in a quick and dirty way. Then maybe I will be enhancing it somehow. A quick and dirty way that works is just increase constant limits (it is 256, while your card supports at least 1024).

> I think this is likely not related to IVB. This game uses excessive number
> of HLSL shader constants (there was a discussion of this also in this bug
> comments above):
> > warn:d3d_shader:shader_record_register_usage Shader using float constant 771 which is not supported.
> 


I've reported this bug? (sort of not be i think). Please see https://bugs.winehq.org/show_bug.cgi?id=39578 

The big float constants warning shows in BattleRaper2 trace log too such as c771,c890 etc, but it's tested ok as you know.

Created attachment 52845 [details]
Temp fix: constants number increase for testing purposes

(In reply to gamiljydcome from comment #41)

> 
> I've reported this bug? (sort of not be i think). Please see
> https://bugs.winehq.org/show_bug.cgi?id=39578 
> 
> The big float constants warning shows in BattleRaper2 trace log too such as
> c771,c890 etc, but it's tested ok as you know.

Still I think the reason I suggest is possible. Look at this comment here: https://bugs.winehq.org/show_bug.cgi?id=8051#c118

I am attaching temporary patch here (just for testing purposes) which does the same (but actually there is yet another place in the code to increase the constants to make it work), and adds some debug warnings which are not related actually to the case. 
Can you test with this patch applied on top of my latest IVB patch? I did not see this game but I know this fixes some other Illusion games, AA2 for instance.
If this won't help, I will dig further.

> I am attaching temporary patch here (just for testing purposes) which does
> the same (but actually there is yet another place in the code to increase
> the constants to make it work), and adds some debug warnings which are not
> related actually to the case. 
> Can you test with this patch applied on top of my latest IVB patch? I did
> not see this game but I know this fixes some other Illusion games, AA2 for
> instance.
> If this won't help, I will dig further.

Nice, new patch is work!

swswine. to keep this bug post focus on IVB patch, could you please view https://bugs.winehq.org/show_bug.cgi?id=39578? I have a little questions.
Thank.

My test is also successful. Image is no more broken.

Just for info there are many repeated messages
---
fixme:d3d:resource_check_usage Unhandled usage flags 0x10.
fixme:d3d:resource_check_usage Unhandled usage flags 0x10.
fixme:d3d:resource_check_usage Unhandled usage flags 0x10.
---
It means
#define WINED3DUSAGE_SOFTWAREPROCESSING                         0x00000010

May be with this patch we should mark that SOFTWAREPROCESSING is handled?

(In reply to Sergey Isakov from comment #44)

> #define WINED3DUSAGE_SOFTWAREPROCESSING                         0x00000010
> 
> May be with this patch we should mark that SOFTWAREPROCESSING is handled?

No. I think it is really difficult discussing software/hardware processing without going deeper into DirectX architecture and its implementation in Wine (I am in fact not an DirectX or wined3d expert either). And software processing flags affect really nothing in Wine currently (maybe except for some debug messages).

Actually software or hardware processing is just a sort of hint which application sets to DirectX. This hint affects some feature availability and their limits in DirectX though (e. g., number of matrix indices supported for IVB). Applications are not directly affected by supporting or not supporting actual processing of vertexes and shaders on CPU (software) rather than on GPU in wine. They are affected by the limits explicitly set or imposed by implementation, e. g. number of supported constants in shaders. 

Please see Comment #12 here by Matteo. Software vertex processing in an exact meaning of this is not in Wine and is not going to appear there soon. What I am   trying to do here is to implement (some of) software vertex processing features with GLSL (which is analogous of native directx "hardware" processing). Though as we know now IVB is supported in hardware processing also in native Wine with less number of indexes allowed (thank you and gamiljydcome@gmail.com for running my test).

a question
Why matrix-template differs from 150+?
---
+    {STATE_TRANSFORM(WINED3D_TS_WORLD_MATRIX(148)),              {STATE_TRANSFORM(WINED3D_TS_WORLD_MATRIX(148)),              glsl_vertex_pipe_vertexblend }, WINED3D_GL_EXT_NONE    },
+    {STATE_TRANSFORM(WINED3D_TS_WORLD_MATRIX(149)),              {STATE_TRANSFORM(WINED3D_TS_WORLD_MATRIX(149)),              glsl_vertex_pipe_vertexblend }, WINED3D_GL_EXT_NONE    },
+    {STATE_TRANSFORM(WINED3D_TS_WORLD_MATRIX(150)),              {STATE_TRANSFORM(WINED3D_TS_WORLD_MATRIX(150)),            glsl_vertex_pipe_vertexblend }, ARB_UNIFORM_BUFFER_OBJECT},
+    {STATE_TRANSFORM(WINED3D_TS_WORLD_MATRIX(151)),              {STATE_TRANSFORM(WINED3D_TS_WORLD_MATRIX(151)),            glsl_vertex_pipe_vertexblend }, ARB_UNIFORM_BUFFER_OBJECT},
----
WINED3D_GL_EXT_NONE <-> ARB_UNIFORM_BUFFER_OBJECT
What is the count=150?

(In reply to Sergey Isakov from comment #46)

> WINED3D_GL_EXT_NONE <-> ARB_UNIFORM_BUFFER_OBJECT
> What is the count=150?

matrices 151-255 are available only if ARB_UNIFORM_BUFFER_OBJECT GL extension is supported (see constants in wined3d_private.h). Structure initialization is messy, but I followed the style that was already in there.

It weird. The matrix should be created dynamically.

Hi swswine .

I'm retrying to add vao/vbo support to your IVB patch that ext feature GL2.1/glsl1.2 supported.
The problem is howto make glsl var "uniform mat4 ffp_modelview_matrix[256]" communicate with vao/vbo. 
i was tried to redefine  "attribute mat4 ffp_modelview_matrix[256]" but glsl1.2 don't support attribute array, must above glsl1.5.

So is there anyway change glsl code to make  "uniform ffp_modelview_matrix[256]" could communicate with vao/vbo or it's not possible?

Thanks.

(In reply to gamiljydcome from comment #49)

> So is there anyway change glsl code to make  "uniform
> ffp_modelview_matrix[256]" could communicate with vao/vbo or it's not
> possible?
> 

It is clearly not possible. "V" in VAO/VBO stands for Vertex. OpenGL < 3.1 can use buffers for per vertex data and not for uniforms (which stand for the values used by shaders which are common for all vertexes). The meaning of ARB_UNIFORM_BUFFER_OBJECT extension is to allow buffers to be used for uniforms. No such extension, no buffers for uniforms: just plain uniforms with accompanying limits. Those limits are not as bad as 256 though, even for your rather old card it is 4096 as we found out.

> It is clearly not possible. 

Fine, i give up.

Thanks.

I also want to say that
d3dx9_36_test visual
affected by this bug.
It is too fast to see something but if set pauses the we can catch broken geometry.

(In reply to Sergey Isakov from comment #52)
> I also want to say that
> d3dx9_36_test visual
> affected by this bug.
> It is too fast to see something but if set pauses the we can catch broken
> geometry.

Sorry, d3d9_test visual
As well there are log messages as noticed in bug 38326.
It seems to be MacOSX specific bug.

Created attachment 52920 [details]
Test output on a Radeon HD 2600

I'm attaching the output of your test on my Windows XP + Radeon HD 2600. I also ran the test on Windows 7 + Nvidia GTX 970 and that matches the previous test results you got here (i.e. MaxVertexBlendMatrixIndex=8 for hardware / mixed vertex processing).

About the patch: cool stuff. Not going into the details, again, but here are some more high-level comments. Ah, BTW, these are my opinions, Henri (aka the wined3d maintainer) might disagree...

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.
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).
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.

Created attachment 52947 [details]
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.

Created attachment 52951 [details]
Patch to implement indexed vertex blending (updated), wine 1.8-rc2

New patch works fine with my intel/radeon card.

So after more testing and bug checking sould make this patch merge into mainline?

I am very sorry for the bad news but there is something i didn't understand.
See bug 39674. It is resolved by reverting some commit. OK, 3DMark03 works.
Then I decided to check how your patch will work with this application.
It failed. 3DMark03 is not started again with log
~~~
err:winediag:nulldrv_CreateWindow Application tried to create a window, but no driver could be loaded.
err:winediag:nulldrv_CreateWindow The explorer process failed to start.
~~~

To check I reverted this patch and the application is working again.
How it is possible? Why this patch may influence?

Anybody can check the application with this patch?


PS. About including into mainstream take into account that 1.8 will not accept new codes. "Code freeze". Will wait for 1.9.

(In reply to Sergey Isakov from comment #58)
> See bug 39674. It is resolved by reverting some commit. OK, 3DMark03 works.
This is all very strange. See this: https://appdb.winehq.org/objectManager.php?sClass=version&iId=7133
WineHQ suggests that 3DMark03 does not work without -systeminfo at least since 1.7.46. Anyway, I do not think it can have any relation to this IVB patch.

> Then I decided to check how your patch will work with this application.
> It failed. 3DMark03 is not started again with log
> ~~~
> err:winediag:nulldrv_CreateWindow Application tried to create a window, but
> no driver could be loaded.
> err:winediag:nulldrv_CreateWindow The explorer process failed to start.
> ~~~
> 
> To check I reverted this patch and the application is working again.
> How it is possible? Why this patch may influence?
> 
> Anybody can check the application with this patch?
> 
I've tested 3DMark03 with -nosysteminfo, it works without any problem for me with this patch (without it as well).
Are you testing with 3DMark -nosysteminfo? Are you testing the latest 1.8-rc2 version and presence of this patch is the only difference between it works and don't work? Without -nosysteminfo 3DMark03 does not work in 1.8-rc2 without this patch either.

Thank you for your attention and test.
> WineHQ suggests that 3DMark03 does not work without -systeminfo at least since 1.7.46
In the bug 39674 I made an attempt to start 3DMark03 WITHOUT -no-systeminfo. And I have a success in bug 38411 fixed in 1.7.46 and in bug 39674 fixed by reverting commit b6710c2a006234ac1a729881e7ca75d34cffb474

> Are you testing the latest 1.8-rc2 
Yes!

> and presence of this patch is the only difference between it works and don't work?
Yes!

> Without -nosysteminfo 3DMark03 does not work in 1.8-rc2 without this patch either.
Repeat: fixed by reverting commit b6710c2a006234ac1a729881e7ca75d34cffb474


But now I got new result:
wine-1.8-rc2 + patch-1.8-rc2-ivb
+ patch from bug 34166 comment 23.
Works!
Without patch 34166 I have very dirty screen at start and it seems this influents on uninitialised variables/cash/stack/buffers.
Very strange and this I can't explain.
OK, I resolved my problem.
As well your patch is tested in some applications and it works, images are good and not broken.
Thanks! Hope your patch will be in next wine version.

Created attachment 53162 [details]
Patch to implement indexed vertex blending, wine 1.8

Rebased to 1.8 and fixed some formatting.

Tested game Tony Hawk's Pro Scater HD 2012 and see
~~~
fixme:d3d_shader:print_glsl_info_log     ERROR: 0:28: Index 244 beyond bounds (size 241)
fixme:d3d_shader:print_glsl_info_log     ERROR: 0:29: Index 243 beyond bounds (size 241)
fixme:d3d_shader:print_glsl_info_log     ERROR: 0:69: Index 242 beyond bounds (size 241)
fixme:d3d_shader:print_glsl_info_log     ERROR: 0:70: Index 242 beyond bounds (size 241)
fixme:d3d_shader:print_glsl_info_log     ERROR: 0:84: Index 241 beyond bounds (size 241)
fixme:d3d_shader:print_glsl_info_log     ERROR: 0:88: Index 251 beyond bounds (size 241)
fixme:d3d_shader:print_glsl_info_log     ERROR: 0:91: Index 241 beyond bounds (size 241)
fixme:d3d_shader:print_glsl_info_log     ERROR: 0:95: Index 241 beyond bounds (size 241)
fixme:d3d_shader:print_glsl_info_log     ERROR: 0:96: Index 241 beyond bounds (size 241)
~~~
Is it related to this bug?

(In reply to Sergey Isakov from comment #62)

> ~~~
> Is it related to this bug?

Does the same problem happen without this patch also? Could you please reproduce the problem with WINEDEBUG=+d3d,+d3d_shader,+d3d9 and attach gzipped output?

Created attachment 53402 [details]
Patch to implement indexed vertex blending, wine 1.9.1

rebased the patch for 1.9.1

Created attachment 53581 [details]
Patch to implement indexed vertex blending, Wine 1.9.3

Created attachment 54151 [details]
Patch to implement indexed vertex blending, Wine 1.9.7

Created attachment 54152 [details]
Constants number increase for testing purposes, Wine 1.9.7

Created attachment 54568 [details]
Patch to implement indexed vertex blending, Wine 1.9.11

Created attachment 54569 [details]
Constants number increase for testing purposes, Wine 1.9.11

I'm not sure how much bearing it has on this bug, but I tested the latest version of your patch with Wine master (1.9.12+) and Dark Age of Camelot, which uses vertex blending. It was crashing before, and the patch didn't appear to have any impact one way or the other.

However, an old patch from bug 6955 fixed the issue once I rebased it (see bug 40801). Maybe it's worth integrating with your changes.

(In reply to Hans Petter Jansson from comment #70)
> I'm not sure how much bearing it has on this bug, but I tested the latest
> version of your patch with Wine master (1.9.12+) and Dark Age of Camelot,
> which uses vertex blending. It was crashing before, and the patch didn't
> appear to have any impact one way or the other.
> 
> However, an old patch from bug 6955 fixed the issue once I rebased it (see
> bug 40801). Maybe it's worth integrating with your changes.

Description on WineHQ suggests disabling GLSL. This patch (unlike patch in 6955) implements indexed vertex blending in GLSL backend and has no effect if GLSL is disabled. Were you testing with GLSL enabled? If yes, could you please attach gzipped output with WINEDEBUG=+d3d9,+d3d,+d3d_shader? Or is the game or its demo available for download so I could look?

Good news: With GLSL enabled, your patch fixes the crash. The other patch fixes the GLSL disabled case.

I generated a log with GLSL enabled and your patch applied anyway. However, it's almost 4GB with a couple of minutes of gameplay. XZ compressed it's 19MB, which is still too big for Bugzilla, so I uploaded it here:

http://s000.tinyupload.com/index.php?file_id=80369659748657653148

Will the patches mentioned here be added to the development version of Wine? I have two games that need "glsl=disabled" to be set in order to run properly.

If need be, I can provide logs for how things look with "glsl=disabled" versus when glsl=enabled.

Created attachment 55919 [details]
Patch to implement indexed vertex blending, Wine 1.9.20

added minor changes for the patch to apply cleanly to 1.9.20

this is all work done by swswine@gmail.com

I tested the 1.9.20 patch against 1.9.23
and it applied fine.

will try with 2.0 as soon as I can

Created attachment 57046 [details]
diff to the wine-1.9.20 and wine-2.0 patch

tiny update to the 1.9.20 patch that will make it apply against 2.0 source tree

The author of this patch could you start trying to upstream the patch? Even some parts of it? Even on wine-staging? The patch sitting here helps only people who can compile wine themselves.

(In reply to winetest from comment #77)
> The author of this patch could you start trying to upstream the patch? Even
> some parts of it? Even on wine-staging? The patch sitting here helps only
> people who can compile wine themselves.

I am currently away but I will think of it. As I understand there were some plans to introduce UBOs in wined3d in a systematic way, I am not sure how well this patch would fit in in its current state. Meanwhile if anyone wants to do anything with upstreaming this issue please feel free to use this patch in any way.

Created attachment 57070 [details]
Patch to implement indexed vertex blending (rebased, git 28.01.2017)

Created attachment 57145 [details]
Patch to implement indexed vertex blending (rebased for Wine 2.1)

Created attachment 57893 [details]
Patch to implement indexed vertex blending (rebased for Wine 2.6)

still outside 2.x? it's useful after all.

(In reply to swswine from comment #81)
> Created attachment 57893 [details]
> Patch to implement indexed vertex blending (rebased for Wine 2.6)

This patch fixes also bug #9337

Hi community,

And thanks for the efforts to implement vertex skinning animations. Various LithTech engine games had this feature and issues in wine.

I has checked in Die Hard Nakatomi Plaza, LithTech engine 2.x. With wine-staging 2.16, that include improve patch for this feature. But this it not show the character models correctly. I has added 3 screen-shots, from the intro cut-scene(full game last official patch). 

You can check with a demo version:
https://www.fileplanet.com/84666/80000/fileinfo/Die-Hard:-Nakatomi-Plaza-Demo

Thanks in advance,

David Gámiz Jiménez

Created attachment 59189 [details]
Die Hard Nakatomi Plaza - Wine-staging-2.16_2

Created attachment 59190 [details]
Die Hard Nakatomi Plaza - Wine-staging-2.16_1

Created attachment 59191 [details]
Die Hard Nakatomi Plaza - Wine-staging-2.16_3

(In reply to David Gámiz Jiménez from comment #84)
> Hi community,
> 
> And thanks for the efforts to implement vertex skinning animations. Various
> LithTech engine games had this feature and issues in wine.
> 
> I has checked in Die Hard Nakatomi Plaza, LithTech engine 2.x. With
> wine-staging 2.16, that include improve patch for this feature. But this it
> not show the character models correctly. I has added 3 screen-shots, from
> the intro cut-scene(full game last official patch). 
> 
> You can check with a demo version:
> https://www.fileplanet.com/84666/80000/fileinfo/Die-Hard:-Nakatomi-Plaza-Demo
> 
> Thanks in advance,
> 
> David Gámiz Jiménez

I've tested the demo and was able to reproduce the glitch, it can be seen right on the first cut scene after starting new game.

The glitch is not there with the original patch attached to this bug. The relevant difference is that original patch always uses maximum supported indexes regardless of software or hardware vertex processing mode selected (which does not look like correct behaviour either), while Staging version supports max index of 7 in HWVP and 255 in SWVP mode only. If to make it use SWVP mode path only, the glitch goes away (* see note below).

The game uses d3d8 interface and creates mixed vertex processing (MVP) device. The way of setting SWVP in MVP for d3d8 is done through D3DRS_SOFTWAREVERTEXPROCESSING render state, unlike d3d9 SetSoftwareVertexProcessing call (which is not there for d3d8). This render state is not taken into account, but this is not the reason for this glitch actually: the demo never sets this state. I did not test how many indexes are de facto supported in MVP mode on Windows, but can guess that it might be different from what is reported through capabilities.

* The core GL profiles must not be used for indexed vertex blending in Staging to work, that is, HKEY_CURRENT_USER\Software\Wine\Direct3D\MaxVersionGL registry entry must not be set or set to something below 3.2. This is due to glVertex... and similar functions which are used in 'software emulation' codepath are not supported on opengl 3.2+ core profiles.

Indexed Blender patchset seems has problem in wine-staging 3.4. I have similar glitch in my game.

OK I found it, wine has enable CSMT by default, CSMT will cause Indexed Vertex patch glitch. I need to disable CSMT to let it work.

I found the issue, one of the settings in my game cause glitch. now the only issue is Indexed Vertex Patch performance seems slow.

Seems like newer drivers for both NVidia (396 and higher) and AMD (AMDGPU) don't like registers that are this high: https://devtalk.nvidia.com/default/topic/1036629/linux/-quot-nvidia-396-gl_invalid_operation-error-generated-quot-when-compiling-1024-vertex-shaders/

Created attachment 62605 [details]
Patchset for supporting SW shaders and indexed vertex blending (through glsl)

(In reply to Alexandr Oleynikov from comment #92)
> Seems like newer drivers for both NVidia (396 and higher) and AMD (AMDGPU)
> don't like registers that are this high:
> https://devtalk.nvidia.com/default/topic/1036629/linux/-quot-nvidia-396-
> gl_invalid_operation-error-generated-quot-when-compiling-1024-vertex-shaders/

I am attaching a rebased draft patch set from what I was testing a while ago, which includes the following:
- Support for UBO instead of uniforms for shader constants;
- Support for software vertex shaders (through glsl backend);
- Support for indexed vertex blending (through glsl backend).

It should probably work with newer NVIDIA drivers (as it minds GL capabilties for uniform arrays' sizes). I didn't test with the newest drivers though, some bugs are possible. If it is still does not work as is for some reason, setting HKEY_CURRENT_USER/Software/Wine/Direct3D/consts_ubo (DWORD value) to 1 in registry might help.

Oh great!
Do you mind looking at the patch for Sims 2 from https://bugs.winehq.org/show_bug.cgi?id=8051 ? It seems to be the same thing but slightly different, I think.
Would really appreciate it!

(In reply to Alexandr Oleynikov from comment #94)
> Oh great!
> Do you mind looking at the patch for Sims 2 from
> https://bugs.winehq.org/show_bug.cgi?id=8051 ? It seems to be the same thing
> but slightly different, I think.
> Would really appreciate it!

That bug covers a bunch of different issues, including the software vertex shaders which are (in draft) addressed by the patchset I put here in the previous message. If you are referring your patch there (https://bugs.winehq.org/attachment.cgi?id=61321) and that was the one you needed for Sims 2 to work, I think you can leave just the part adding a stub for undocumented shader validator interface (changes in d3d9_main.c), drop everything else from it and use it together with the latest pacthset from here.

Thanks! Still a few artifacts just like in Die Hard Nakatomi Plaza, but at least it's working :D

Created attachment 63583 [details]
Patchset for supporting SW shaders and indexed vertex blending

Rebased for Wine 4.2.

This is a great patch and I always include it into my compilation because of game
https://bugs.winehq.org/attachment.cgi?id=52812
Why it is still not in mainstream?

(In reply to Paul Gofman from comment #97)
> Created attachment 63583 [details]
> Patchset for supporting SW shaders and indexed vertex blending
> 
> Rebased for Wine 4.2.

Good job. This patch is working for both Vietcong demo and full version (fixes bug #9337). Would be nice to replace current wined3d-Indexed_Vertex_Blending patchset from staging, since it has rendering issues since 3.9 (bug #45278)

(In reply to Sergey Isakov from comment #98)
> This is a great patch and I always include it into my compilation because of
> game
> https://bugs.winehq.org/attachment.cgi?id=52812
> Why it is still not in mainstream?

Probably because nobody has submitted it.

*** Bug 9337 has been marked as a duplicate of this bug. ***

Fixes a broken player geometry in Max Payne when acceleration set to D3D Software T&L.

No plan to submit the patchset? Because bug still occurs with vanilla wine-6.19.

I was testing Max Payne with 8.0-rc3 and I encountered the bug described in comment 102, I will try the latest patch to see if it still works

I tried to apply the patch in comment 97 but it causes various conflicts with the current Wine version. The glitches can be seen in the demo for the game (https://archive.org/details/MaxPayneDemo), I tried to record a video but it didn't work for some reason.

Created attachment 74556 [details]
Broken image in Crossover

Created attachment 74616 [details]
Max Payne with Software T&L on Wine 8.10

This is a video of what Max Payne looks like with the Software renderer on Wine 8.10.

(In reply to Zeb Figura from comment #100)
> (In reply to Sergey Isakov from comment #98)
> > This is a great patch and I always include it into my compilation because of
> > game
> > https://bugs.winehq.org/attachment.cgi?id=52812
> > Why it is still not in mainstream?
> 
> Probably because nobody has submitted it.

As I shown just now the bug is still present in Crossover 22.1.1. Can't check it in WineHQ because the game is 32bit which is not supported by wineHQ.
But I applied Staging patchset for Index Vertex Blending to crossover sources and got only 10 chunks rejected. All of them I successfully applied and got fully working wine without the bug.
I think Codewears employees should do this for their Crossover.
I can help, I can provide revised patchset exactly for Crossover 22.1.1.
Not sure if there is any sense for WineHQ.