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