Skip to content
Snippets Groups Projects

ddraw: Make sure that sysmem surfaces remain coherent when not locked.

Merged Elizabeth Figura requested to merge zfigura/wine:mr4 into master
1 unresolved thread

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • Ghost User requested review from @jsikorski

    requested review from @jsikorski

  • Elizabeth Figura added 3 commits

    added 3 commits

    • 5e7699a6 - ddraw/tests: Add tests for map pointer coherency.
    • 8f3a2e15 - ddraw: Sync to sysmem after performing a color fill.
    • d67bd0fe - ddraw: Use the sysmem wined3d texture for sysmem surfaces if possible.

    Compare with previous version

  • I am confused - once upon a time, there would have been only a sysmem surface on the wined3d side, and wined3d does the clear directly on its system memory and reads the data from the source's system memory in the Blt() call.

    Nowadays we have a video memory draw texture for sysmem surfaces because one can use them for texturing on native ddraw.

    Is the issue here that ddraw accidentally made wined3d perform stuff on the vidmem draw texture rather than the 'original' system wiend3d_texture?

  • Author Developer

    d2d9f713 forces us to create a separate wined3d_texture for texturing or RTV usage. I don't know why it was done this way instead of just continuing to allow CPU textures to be used as a texture/RTV; unfortunately neither the commit message nor the patches as submitted on wine-devel give any explanation.

    Even at that point the offending Emperor texture wasn't created with any bind flags. (Despite the fact that a color fill uses an RTV, it wasn't created with WINED3D_BIND_RENDER_TARGET; we don't currently validate that.)

    ee7d047d forces all sysmem textures to get a draw texture. That means that the color fill acts on the draw texture instead of the sysmem texture, and the subsequent blits use ddraw_surface_get_any_texture() and hence pick the draw texture since that location is valid.

    It does slightly bother me that we're reimplementing all this logic on the client side, but I guess there was a reason for doing it this way...

  • Jan Sikorski
    Jan Sikorski @jsikorski started a thread on an outdated change in commit 8f3a2e15
1531 1531 src_impl ? &src_impl->IDirectDrawSurface_iface : NULL, flags);
1532 1532 }
1533 1533
1534 /* Emperor: Rise of the Middle Kingdom accesses the map pointer outside of
1535 * Lock()/Unlock(), and expects those updates to be propagated by a Blt().
1536 * It also blits to the surface, and color-fills it.
1537 *
1538 * This function is called after a blit or color-fill that might update the GPU
  • Elizabeth Figura added 2 commits

    added 2 commits

    • 2d724ea0 - ddraw: Sync to sysmem after performing a color fill.
    • c604f214 - ddraw: Use the sysmem wined3d texture for sysmem surfaces if possible.

    Compare with previous version

  • Jan Sikorski approved this merge request

    approved this merge request

  • Alexandre Julliard added 63 commits

    added 63 commits

    • c604f214...585e9d49 - 60 commits from branch wine:master
    • 48ecde18 - ddraw/tests: Add tests for map pointer coherency.
    • b712d6c8 - ddraw: Sync to sysmem after performing a color fill.
    • d6204ccd - ddraw: Use the sysmem wined3d texture for sysmem surfaces if possible.

    Compare with previous version

  • Alexandre Julliard approved this merge request

    approved this merge request

  • Please register or sign in to reply
    Loading