https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #60 from oiaohm oiaohm@gmail.com --- Cannot find that bug number but I can tell you this is a case that mainline wine might be running the program slow but there is no lock-up. Only after you do this incorrect form of patch does lock-up come. So flag alteration is causing harm.
If I was doing this I would not be creating a new pool entry.
enum wined3d_pool pool;<< this line is the start wrong total wrong.
First no TRACE or FIXME or WARN in your code to it cannot be debugged.
So the first thing that need adding is a TRACE on desc->access
TRACE("desc->access %d",desc->access); straight after existing TRACE. So we have the raw value before we play with anything. Next a new DWORD access; This would be straight under HRESULT hr; This is out scratch pad.
Due to prior being brute force I don't know what you were setting/unsetting and neither do you. Because I have no clue what access values you have been crushing/needing to crush I cannot write correct patch only provide guide.
access=desc->access; if(access== some filter so you don't in fact hit everything) if (desc->byte_width > 0x10000) {
Some bitwise operator/operators here setting/unsetting bits area1.
TRACE("modified desc->access %d",access); } else { Some bitwise operator/operators here setting/unsetting bits area2
TRACE("modified desc->access %d",access); }
Final bit is hook in the change. if (FAILED(hr = buffer_init(object, device, desc->byte_width, desc->usage, WINED3DFMT_UNKNOWN, access, desc->bind_flags, data, parent, parent_ops)))
Next you will be needing bytewise operations.
https://stackoverflow.com/questions/47981/how-do-you-set-clear-and-toggle-a-...
Due to prior being brute force I don't know what you were setting/unsetting.
Like area1 being desc->byte_width > 0x10000
WINED3D_RESOURCE_ACCESS_GPU does this bit need to be set. if to be set is access |=WINED3D_RESOURCE_ACCESS_GPU;
Do WINED3D_RESOURCE_ACCESS_CPU | WINED3D_RESOURCE_ACCESS_MAP need to be unset here if so access &= ~(WINED3D_RESOURCE_ACCESS_CPU | WINED3D_RESOURCE_ACCESS_MAP);
Are there any other bits that should be turned off.
In fact WINED3D_RESOURCE_ACCESS_GPU might be your test if you should or should not.
Area2 that is else to desc->byte_width > 0x10000 is simpler access |=WINED3D_RESOURCE_ACCESS_GPU | WINED3D_RESOURCE_ACCESS_CPU | WINED3D_RESOURCE_ACCESS_MAP This turns those 3 bits on.
Are there any other bits that should be turned off.
Even so this patch is still not going to be suitable for mainline but with the traces and careful control of what bits you are messing with will provide some information to attempt to back trace where this was set wrong in the first place.
My rough calc says you could need to make over 16 new patches based of what I just wrote to attempt to work out exactly what bit values are needing to be modified. Modify only the correct values might cure the lockup problem.
Please take a close look at the pool system memory mode. case WINED3D_POOL_SYSTEM_MEM
return WINED3D_RESOURCE_ACCESS_CPU | WINED3D_RESOURCE_ACCESS_MAP
You brute force was override this. So this now means WINED3D_POOL_SYSTEM_MEM requests are being given WINED3D_RESOURCE_ACCESS_GPU so sent to a GPU allocation as well most likely a bad thing and could cause nice lockups as applications attempt to allocate memory to avoid over filling the GPU and the old patches send them to the GPU anyhow.
This is why I am highy suspect that you should be filtering if WINED3D_RESOURCE_ACCESS_GPU is set if (access & WINED3D_RESOURCE_ACCESS_GPU) kind of thing before doing any change and if that is the case you don't need to be setting that bit again.
So somewhat correct patch is going to look absolutely different.
Reality is I have a lot of guess work because no data collected on what you were really changing so its impossible for someone without the game to correct the patch because not enough data.
Yes I know installing trace entries can slow thing down but at least if you had submit a lot with the extra value information someone could attempt to create more correct patch or attempt to locate where the incorrect values are coming from.
There are a lot of patches in staging lacking instrumentation like TRACE and FIXME and WARN entries. This means no data for anyone else to provide somewhat corrected patches.