[Bug 42592] The Witcher 3 has poor performance

[wine-bugs at winehq.org]

https://bugs.winehq.org/show_bug.cgi?id=42592

--- Comment #60 from oiaohm <oiaohm at 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-single-bit

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.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.