Bug 13335 [1] is basically "OpenGL games crash or run slow".
There's two symptoms here, and they're to do with proprietary video drivers.
When the nVidia driver fails to mmap stuff from /dev/nvidia0, it starts failing OpenGL commands with GL_OUT_OF_MEMORY.
When the FireGL driver fails to mmap or malloc (I don't know which), it falls back to indrect rendering.
The problem in both cases is because Wine mmaps most of the 32-bit memory space for itself and then parcels this back out through HeapAlloc and related methods.
When the GL libraries calls mmap and malloc themselves, for quite large blocks of memory, they fail because there's nowhere in the address space for those large blocks of memory to go.
The first linked patch [2] in bug 13335 fixes this by redirecting mmap calls into ntdll which unmaps a block of address space, and performs the mmap into that address space, effectively handing that address space over to the library for the duration of the mmap's existence.
I can't claim credit for that, I merely took Thunderbird's forward-ported version of Alexandre's original patch and forward-ported it further to 1.1.19.
The second linked patch [3] simply redirects malloc and related calls to RtlAllocateHeap, rather like the msvcrt malloc-type calls are handled.
The latter's almost certainly in the wrong place in ntdll, but it keeps ntdll from needing two copies of the pthread_functions structure.
The bug's staring to accumulate some feedback that this helps for games that otherwise tend to crash after playing for a little while, and I've not had any luck catching people on IRC to look over the patches, so I'm wondering if anyone would like to provide feedback on these patches, as to whether they are the right approach, and if there are things that could be handled more cleanly.
[1] http://bugs.winehq.org/show_bug.cgi?id=13335 [2] http://bugs.winehq.org/attachment.cgi?id=20483 [3] http://bugs.winehq.org/attachment.cgi?id=20484