[Bug 44246] Call of Duty 4: GL_INVALID_OPERATION & GL_OUT_OF_MEMORY

WineHQ Bugzilla wine-bugs at winehq.org
Mon Dec 9 14:27:03 CST 2019


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

--- Comment #11 from Adrien Fernandes <adrien_fernandes2 at hotmail.com> ---
> The application doesn't run with 1 Gb less memory, some Wine component _asks_
> for less memory from the OS. It still uses the same amount of memory as before.
> You see, address ranges are reserved immediately, while the physical memory is
> allocated in pages on actual access.

I'm trying to understand how it works. Wine allocates memory in the first place
which is a fixed amount, whatever you use under Wine ? Like when you create a
virtual disk with VirtualBox and ask for the disk to actually TAKE the size you
set directly, without to wait to really write something in it (fixed size) ?

So how an application works then. Does it run inside the allocated space ? Or
on the side ? When I run "winecfg", I have this :

  PID USERNAME    THR PRI NICE   SIZE    RES STATE    C   TIME    WCPU COMMAND
 1345 Adrien2002    4  25    0  1520M    27M piperd   1   0:00   0,00% wine

Even if I can see 27M on RES, I still see 1520 allocated by Wine, it
corresponds to what you said.

> That 1 Gb was never read/written in the first place, as you can clearly see
> from the resident memory value in top.

Yes, I see ~1020M of RES on both "top" I saved.

> I was talking about the limits in dlls/ntdll/virtual.c, but that is definitely interesting. 

As you certainly guessed, I'm not a developer and my knowledges aren't great. I
usually try to do things by myself which is the best way to learn. I Googled
for a solution, reading many topics and articles to understand then apply and
that "solution" I found (which may not be a solution, I don't know), is what I
guessed was the solution. If I open a file as big as virtual.c, I'll just stand
in front of the screen, wondering what can be done.

I used the search function of vim to find, starting at line 2544, a section
speaking about LARGE_ADDRESS_AWARE but I didn't touch it yet since I wouldn't
know how to without to risk to break everything. Also, this thread here
https://bugs.winehq.org/show_bug.cgi?id=33858 makes me wonder if my problem is
really about the LARGE_ADDRESS_AWARE and not about Wine eating, exclusively,
too much on FreeBSD. The people in the thread say it's not a solution either to
globally change it and make every applications run with LAA since it may break
some applications. Is my problem really related to LAA ? Cause I didn't apply
LAA to Wine nor to any Windows executable but I can run Assassin's Creed and
Call of Duty now, just like in GNU/Linux, with the solution I found and apply.

But it would not make Far Cry 3 @ ultra settings works I suppose (which is the
topic of the thread I just shared with you). In the best case, I will have a
normal behavior of Wine, like in GNU/Linux and I would need my solution AND to
apply LAA to Far Cry 3 executable if I want to run it in ultra settings.

I have a Dell Inspiron with Arch Linux. I don't use it to play but I installed
Wine and checked the memory allocated by Wine when I run winecfg :

    PID UTIL.     PR  NI    VIRT    RES    SHR S  %CPU  %MEM    TEMPS+ COM.     
    693 adrien2+  20   0 1747,0m  15,8m   9,6m S   0,3   0,2   0:00.70
winedevice.exe

It's close to FreeBSD. Is it interesting and useful here ?

Sorry if I'm totally mistaken and didn't get anything correctly.

In any case, thank you very much for taking time to answer and explain how
things work, I appreciate it and I wish this thread can help other FreeBSD
users to play their bigger games.

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



More information about the wine-bugs mailing list