WineD3D texture bug

[Raphael]

On Sunday 05 February 2006 22:44, Stefan Dösinger wrote:
> Hi,
>
> > To summarize 3dmark2001 possibly uses incorrect d3d8 code but the code
> > works fine on Windows. I tried to test the behaviour using a test
> > (perhaps not a good test) and windows appeared to work correctly and the
> > same for wine. Further oliver had the same problem in maxpayne2 (it uses
> > the same 3d engine I think) and he used a similar hack.
>
> One thing that I've learned since I started working on Wine is not to trust
> the MSDN. During my ddraw/d3d work I've seen a lot of such things, and the
> ddraw code contains a lot of comments which state that the msdn is
> incorrect. And at the university I've met some windows application
> developers which thought that the msdn is horrible.
>
> In this case, what speaks against simply allowing rendering from sysmem
> textures? In wine this doesn't make much difference(as we 'only' forward to
> GL).
>
> For Windows I'd say that this might depend on the driver. Perhaps in MS
> design sysmem textures can't be used for rendering, but most drivers
> eighter ignore the sysmem property completely(and place everything into
> vidmem), or they are just able to render from sysmem textures. If you are
> unlucky, you might have a driver which can't do so, and some apps are
> broken.

Hi,

No, i think "system memory pools" is only used as optimisation flag by 
drivers.
For me it means that Game developer use:
 - "video memory pools": preference for texture to be always in video card 
mem.
 - "system memory pools" : your texture may be not always in video card mem

So drivers should load first "video mem pool" and if GC mem remains "system 
mem pool" (who can be swapped out when needed)

It think many drivers also do some optimisations as tagging as "video memoy 
pooled" some intensivelly used textures (and untagging textures that are 
never used)

It's why Oliver done a lot of work about "memory pooling" 
but now we need a "memory" scheduler (knowing size of GC mem) :)

Keep you good job :)

Regards,
Raphael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20060206/124be26d/attachment.pgp