Roderick Colenbrander a écrit :
Roderick Colenbrander a écrit :
I tried to play Supreme Commander using pbuffer option instead of fbo.
I
was quite happy with it, since I gained quite a bunch of performance (I mean, something I really COULD see), but after a while, the performance dropped dramatically, to ~4-5 fps.
I tested quite a few thing, and I finally found that pixel bufers were not taken in account when calculating available texture memory. The
game
then allocated more textures, and good opengl didn't dare complain when putting them in system memory.
Attached is a patch which should solve the problem.
For those who are curious, try setting VideoMemorySize to 200 instead
of
- It works just like a charm.
I think the basic idea of the patch is good but the calculation itself
should take into account double buffering. In wine we don't use double buffering on pbuffers but we might be receiving a WGL pixel format which uses double buffering, so in that case the amount of video memory would be a factor 2 too low.
Something like this would give you the double buffering capability from
a d3d device:
This->adapter->cfgs[iPixelFormat]->doubleBuffer
Roderick
OK. Here is a new one, more readable I think. I'll send it to wine-patches once I manage to configure git-send-email :)
Hi,
I think it would be best to add an attribute 'pbuffer_size' or something like that to the WineD3DContext storing the size of the pbuffer. This is needed because GetPixelFormat won't work on a pbuffer. The problem with this call is that GetPixelFormat doesn't see 'offscreen pixel formats' (like e.g. floating point ones and there are others) which can be used for pbuffers. Further I think it is nicer to not have to recalculate its size. I don't think there is a way to get the pixel format from a pbuffer.
Roderick
Patch sent...