8 Oct
2022
8 Oct
'22
8:33 p.m.
On Sat Oct 8 16:49:13 2022 +0000, **** wrote:
Zebediah Figura replied on the mailing list:
On 10/7/22 10:03, Stefan Dösinger (@stefan) wrote: > In the long run I will look into making wined3d a pe/so 32on64 aware thing. It'll matter a lot for ARM, but might also be a performance improvement for x86 32on64. In wined3d we have a few more options in part because d3d <= 11 doesn't have coherent mappings, but wined3d uses it for its own purposes. > Somewhat related to this, I had recently been thinking about trying to split up wined3d a bit more explicitly. The DLL is huge, and I think it can be difficult to understand what's done on the client and CS side, which is a pretty important distinction. I'd recently been thinking of a somewhat controversial proposal, that we might want to try splitting it into separate DLLs representing these, so that even if we don't eventually decide to split it into PE/Unix, we could have that additional clarity. Or maybe just have a source subdirectory for the CS part?
By and large I am in favor of splitting wined3d in a cs and client part. It doesn't need to be separate DLLs though.
A difficult enough start would be splitting the object implementation structures into a client, CS and possibly shared part. It can still be in the same struct fwiw; a /* This part is accessed only by the client */ and /* This part is accessed only by the CS thread */ separation. If nothing else it would help with cacheline bouncing.