Announcement

Collapse
No announcement yet.

Request for fix in Wine

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • monraaf
    replied
    Originally posted by BlackStar View Post
    I distinctly recall a gamedev.net discussion on glReadPixels suddenly getting really slow on catalyst 9.1. I also *think* that FireGL cards where not affected, indicating a "product segmentation" reason for the slowdown, rather than a technical one.

    Unfortunately, I haven't been able to find the link, so I could be wrong (if I am please shoot me!)
    Interesting, I just noticed one of the few fglrx bug reports that actually did get some feed back. And it looks like you are right. They intentionally crippled fglrx glReadPixels performance for consumer cards.

    http://ati.cchtml.com/show_bug.cgi?id=1755

    Leave a comment:


  • narwhals
    replied
    Originally posted by bridgman View Post
    Is 16 bpp depth something you can choose or is that hard-coded in the app ? I didn't think we supported 16bpp operation...
    Yes, 16 bpp is part of the game. This came out at a time before 32 bpp was common.

    Leave a comment:


  • bridgman
    replied
    Is 16 bpp depth something you can choose or is that hard-coded in the app ? I didn't think we supported 16bpp operation...

    Leave a comment:


  • narwhals
    replied
    UPDATE: Just tried SS2 again with the latest Catalysts. Still have the same problem but now I have new D3D shader errors (in bold).

    Code:
    fixme:win:EnumDisplayDevicesW ((null),0,0x32f630,0x00000000), stub!
    fixme:win:EnumDisplayDevicesW ((null),0,0x32f628,0x00000000), stub!
    fixme:x11drv:X11DRV_desktop_SetCurrentMode Cannot change screen BPP from 32 to 16
    fixme:d3d:WineD3D_ChoosePixelFormat Add OpenGL context recreation support to SetDepthStencilSurface
    fixme:d3d_shader:print_glsl_info_log Error received from GLSL shader #3:
    fixme:d3d_shader:print_glsl_info_log     Fragment shader(s) linked, vertex shader(s) linked. 
    fixme:d3d_shader:print_glsl_info_log     WARNING: warning(#276) Symbol 'gl_FrontColor' usage doesn't match between two stages
    fixme:d3d_shader:print_glsl_info_log     WARNING: warning(#276) Symbol 'gl_FrontColor' usage doesn't match between two stages
    fixme:d3d_shader:print_glsl_info_log      
    err:ddraw:PixelFormat_WineD3DtoDD Can't translate this Pixelformat 19
    err:ddraw:PixelFormat_WineD3DtoDD Can't translate this Pixelformat 64
    err:ddraw:PixelFormat_WineD3DtoDD Can't translate this Pixelformat 70
    fixme:d3d_surface:surface_load_ds_location No up to date depth stencil location
    err:d3d_surface:IWineD3DSurfaceImpl_ModifyLocation 0x141cc8: Surface does not have any up to date location
    err:d3d_surface:IWineD3DSurfaceImpl_ModifyLocation 0x141cc8: Surface does not have any up to date location
    err:d3d_surface:IWineD3DSurfaceImpl_ModifyLocation 0x141cc8: Surface does not have any up to date location
    err:d3d_surface:IWineD3DSurfaceImpl_ModifyLocation 0x141cc8: Surface does not have any up to date location

    Leave a comment:


  • BlackStar
    replied
    I distinctly recall a gamedev.net discussion on glReadPixels suddenly getting really slow on catalyst 9.1. I also *think* that FireGL cards where not affected, indicating a "product segmentation" reason for the slowdown, rather than a technical one.

    Unfortunately, I haven't been able to find the link, so I could be wrong (if I am please shoot me!)

    Leave a comment:


  • monraaf
    replied
    Originally posted by bridgman View Post
    Wine uses glDrawPixels and glReadPixels calls to implement the "Lock Render Target" operation. Those calls are not normally used in performance-critical code but it sounds as if accelerating those calls could help with this specific game. I wonder if anyone has tried System Shock 2 on the open source drivers ?
    Yeah, I tried it, the game is also slow with the open source drivers

    See also this bug:

    http://bugs.winehq.org/show_bug.cgi?id=9509

    Leave a comment:


  • narwhals
    replied
    Hi Bridgman. Thank you for helping to try and assist me in this.

    In the support ticket Stefan suggested the following for System Shock - what happened when you tried that ?

    Quote:
    Render target locking can be disabled with the following registry key on
    CrossOver: HKEY_CURRENT_USER/Software/Wine/Direct3D/RenderTargetLockMode = "disabled" .
    This should make SS2 run fast, but the crosshair will be gone.
    I should have been more clear that I did try this and can confirm that this is where the problem lies as the game itself is playable at regular speed by setting RenderTargetLockMode to "disabled" but this has nasty side effects on other things. There is no in game HUD and you can't get Esc back to the menu (black screen) so it is not a viable solution to the problem.


    Here is a sample log from my terminal of what actually happens when the game itself starts, after the intro. (This is regularly, without the registry hack)
    Code:
    fixme:win:EnumDisplayDevicesW ((null),0,0x32f630,0x00000000), stub!
    fixme:win:EnumDisplayDevicesW ((null),0,0x32f628,0x00000000), stub!
    fixme:x11drv:X11DRV_desktop_SetCurrentMode Cannot change screen BPP from 32 to 16
    fixme:d3d:WineD3D_ChoosePixelFormat Add OpenGL context recreation support to SetDepthStencilSurface
    err:ddraw:PixelFormat_WineD3DtoDD Can't translate this Pixelformat 19
    err:ddraw:PixelFormat_WineD3DtoDD Can't translate this Pixelformat 64
    err:ddraw:PixelFormat_WineD3DtoDD Can't translate this Pixelformat 70
    fixme:d3d_surface:surface_load_ds_location No up to date depth stencil location
    err:d3d_surface:IWineD3DSurfaceImpl_ModifyLocation 0x19c860: Surface does not have any up to date location
    err:d3d_surface:IWineD3DSurfaceImpl_ModifyLocation 0x19c860: Surface does not have any up to date location
    err:d3d_surface:IWineD3DSurfaceImpl_ModifyLocation 0x19c860: Surface does not have any up to date location
    err:d3d_surface:IWineD3DSurfaceImpl_ModifyLocation 0x19c860: Surface does not have any up to date location
    err:d3d_surface:IWineD3DSurfaceImpl_ModifyLocation 0x195bd0: Surface does not have any up to date location
    err:d3d_surface:IWineD3DSurfaceImpl_ModifyLocation 0x195bd0: Surface does not have any up to date location
    err:d3d_surface:IWineD3DSurfaceImpl_ModifyLocation 0x195bd0: Surface does not have any up to date location
    err:d3d_surface:IWineD3DSurfaceImpl_ModifyLocation 0x195bd0: Surface does not have any up to date location
    I just noticed your comment that performance was much better on a 4670 with Cat 8.12 drivers than with 4770 and more recent drivers. That's a really useful clue - you might want to update the old support ticket you linked to and mention that.
    I'm not sure how this would do much good as they closed the bug on the specific reason that this is only a problem with ATi videocards.

    If it turns out that there has been a serious performance regression on glReadPixels/glDrawPixels (which we don't know yet) then it wouldn't hurt to file a ticket at ati.cchtml.com.
    Sure. I would be happy to file a ticket but I am not too sure exactly what to tell them. I can attest though that with Slackware 12.2 - 2.6.27 kernel/ Radeon 4670/ 8.12 catalysts, SS2 worked ok. Something went wrong early in the 9.x series as I switched back to 8.12 right away cause I start having numerous display/wine problems. However I can only go back to 9.8 catalysts with my current kernel and gpu now though. The only improvement I have seen regarding 9.10 catalysts is the game actually loads (it crashed wine on 9.8 and I think 9.9).

    If you think I should file a ticket with ati, can you please help me as to how to address the problem specifically? Thank you.

    Leave a comment:


  • Melcar
    replied
    I was able to launch a ToEE game using radeonhd 1.3 . It ran slow as hell (software renderer on my hd4870) but it ran nonetheless.

    Leave a comment:


  • RealNC
    replied
    "requiring that the framebuffer be pushed back and forth between system and video memory every frame"

    Is it just me, or does this look very similar with the "slow window resizing with compositing" thingy?

    Leave a comment:


  • bridgman
    replied
    Stefan's analysis was that the game alternates drawing with CPU and GPU, requiring that the framebuffer be pushed back and forth between system and video memory every frame. This is one of those applications are *never* supposed to do, where the performance and results are usually implementation specific so the code ends up being non-portable. Stefan mentions that the game could run >10x as fast if not for the CPU accesses to framebuffer :

    System Shock 2 is an old game, and it does something really nasty: It Locks the back buffer every frame, that means it writes to the framebuffer with the CPU. For us this means that we have to download the framebuffer from the graphics
    card with glReadPixels, then pass it to SS2, and reupload it with glDrawPixels.

    This is slow, and Microsoft put a big warning sticker on this feature in Direct3D 8 and 9. On sane drivers(Windows, and nvidia), it gives 30-60 fps, whereas SS2 would otherwise go into hundreds or thousands of frames per secound on modern hardware. Unfortunately, glDrawPixels and glReadPixels are terribly slow on fglrx, so you get 1 frame per secound at best.
    In the support ticket Stefan suggested the following for System Shock - what happened when you tried that ?

    Render target locking can be disabled with the following registry key on
    CrossOver: HKEY_CURRENT_USER/Software/Wine/Direct3D/RenderTargetLockMode = "disabled" .
    This should make SS2 run fast, but the crosshair will be gone.
    Wine uses glDrawPixels and glReadPixels calls to implement the "Lock Render Target" operation. Those calls are not normally used in performance-critical code but it sounds as if accelerating those calls could help with this specific game. I wonder if anyone has tried System Shock 2 on the open source drivers ? Their implementation is sufficiently different from fglrx that the performance of these specific calls might be higher. Alternatively, there may be a different (faster) set of GL calls which Wine could use to move the frame buffer back and forth between video and system memory.

    EDIT - I just noticed your comment that performance was much better on a 4670 with Cat 8.12 drivers than with 4770 and more recent drivers. That's a really useful clue - you might want to update the old support ticket you linked to and mention that. If it turns out that there has been a serious performance regression on glReadPixels/glDrawPixels (which we don't know yet) then it wouldn't hurt to file a ticket at ati.cchtml.com.

    There may be a bigger issue here as well; from another discussion of glReadPixels it seems that using the call to read the screen may be an undefinied operation. Haven't gone through it completely yet but the ticket is at :

    http://ati.cchtml.com/show_bug.cgi?id=549
    Last edited by bridgman; 10-30-2009, 10:19 AM.

    Leave a comment:

Working...
X