Page 1 of 2 12 LastLast
Results 1 to 10 of 12

Thread: Request for fix in Wine

  1. #1
    Join Date
    Sep 2009
    Posts
    7

    Default Request for fix in Wine

    Hi guys,

    I don't know where to post this as I don't know if it's a bug or what. This has been bothering me for months, all I want to do is play System Shock 2 in Wine but there appears to be a bug or something that makes it go at like 2 fps.

    More about problem here:
    http://www.codeweavers.com/support/t...ct=unable;sort[status]=ASC%29

    same problem here:
    http://bugs.winehq.org/show_bug.cgi?id=17900

    It seems to be the consensus it is an ATI only problem. The thing is way earlier this year when I still had a Radeon 4670 and Catalyst 8.12 drivers, SS2 played perfectly fine like on a real Windows 98 machine. Since then I needed more power and upgraded to a 4770 and sold the 4670 to one of my friends and I can't downgrade my kernel or Catalyst version because 4770 will not support it. Please all I want to do is be able to play this, it's my favorite game and I have no other way of playing it. I don't want to have to buy an nvidia card, I like the one I have. What can I do to get this ironed out?

    Here is my glxinfo if it is any help (Catalyst 9.10). Thank you.

    Code:
    bash-3.1$ glxinfo
    name of display: :0.0
    display: :0  screen: 0
    direct rendering: Yes
    server glx vendor string: ATI
    server glx version string: 1.4
    server glx extensions:
        GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, 
        GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_OML_swap_method, 
        GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGIS_multisample, 
        GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group
    client glx vendor string: ATI
    client glx version string: 1.4
    client glx extensions:
        GLX_ARB_create_context, GLX_ARB_get_proc_address, GLX_ARB_multisample, 
        GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, 
        GLX_MESA_allocate_memory, GLX_MESA_swap_control, 
        GLX_MESA_swap_frame_usage, GLX_NV_swap_group, GLX_OML_swap_method, 
        GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, 
        GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
        GLX_SGIX_swap_barrier, GLX_SGIX_swap_group, GLX_SGIX_visual_select_group, 
        GLX_EXT_texture_from_pixmap, GLX_EXT_framebuffer_sRGB, 
        GLX_ARB_fbconfig_float
    GLX version: 1.4
    GLX extensions:
        GLX_ARB_create_context, GLX_ARB_get_proc_address, GLX_ARB_multisample, 
        GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, 
        GLX_MESA_swap_control, GLX_NV_swap_group, GLX_OML_swap_method, 
        GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, 
        GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
        GLX_SGIX_swap_barrier, GLX_SGIX_swap_group, GLX_SGIX_visual_select_group
    OpenGL vendor string: ATI Technologies Inc.
    OpenGL renderer string: ATI Radeon HD 4770 
    OpenGL version string: 2.1.9026
    OpenGL shading language version string: 1.40
    OpenGL extensions:
        GL_AMDX_vertex_shader_tessellator, GL_AMD_draw_buffers_blend, 
        GL_AMD_performance_monitor, GL_AMD_texture_texture4, 
        GL_AMD_vertex_shader_tessellator, GL_ARB_color_buffer_float, 
        GL_ARB_copy_buffer, GL_ARB_depth_buffer_float, GL_ARB_depth_texture, 
        GL_ARB_draw_buffers, GL_ARB_draw_buffers_blend, GL_ARB_draw_instanced, 
        GL_ARB_fragment_program, GL_ARB_fragment_program_shadow, 
        GL_ARB_fragment_shader, GL_ARB_framebuffer_object, 
        GL_ARB_framebuffer_sRGB, GL_ARB_geometry_shader4, GL_ARB_half_float_pixel, 
        GL_ARB_half_float_vertex, GL_ARB_instanced_arrays, 
        GL_ARB_map_buffer_range, GL_ARB_multisample, GL_ARB_multitexture, 
        GL_ARB_occlusion_query, GL_ARB_pixel_buffer_object, 
        GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_provoking_vertex, 
        GL_ARB_shader_objects, GL_ARB_shader_texture_lod, 
        GL_ARB_shading_language_100, GL_ARB_shadow, GL_ARB_shadow_ambient, 
        GL_ARB_texture_border_clamp, GL_ARB_texture_buffer_object, 
        GL_ARB_texture_compression, GL_ARB_texture_compression_rgtc, 
        GL_ARB_texture_cube_map, GL_ARB_texture_env_add, 
        GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, 
        GL_ARB_texture_env_dot3, GL_ARB_texture_float, 
        GL_ARB_texture_mirrored_repeat, GL_ARB_texture_non_power_of_two, 
        GL_ARB_texture_rectangle, GL_ARB_texture_rg, GL_ARB_texture_snorm, 
        GL_ARB_transpose_matrix, GL_ARB_uniform_buffer_object, 
        GL_ARB_vertex_array_object, GL_ARB_vertex_buffer_object, 
        GL_ARB_vertex_program, GL_ARB_vertex_shader, GL_ARB_window_pos, 
        GL_ATI_draw_buffers, GL_ATI_envmap_bumpmap, GL_ATI_fragment_shader, 
        GL_ATI_meminfo, GL_ATI_separate_stencil, GL_ATI_texture_compression_3dc, 
        GL_ATI_texture_env_combine3, GL_ATI_texture_float, 
        GL_ATI_texture_mirror_once, GL_EXT_abgr, GL_EXT_bgra, 
        GL_EXT_bindable_uniform, GL_EXT_blend_color, 
        GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate, 
        GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_compiled_vertex_array, 
        GL_EXT_copy_buffer, GL_EXT_copy_texture, GL_EXT_draw_buffers2, 
        GL_EXT_draw_instanced, GL_EXT_draw_range_elements, GL_EXT_fog_coord, 
        GL_EXT_framebuffer_blit, GL_EXT_framebuffer_multisample, 
        GL_EXT_framebuffer_object, GL_EXT_framebuffer_sRGB, 
        GL_EXT_geometry_shader4, GL_EXT_gpu_program_parameters, 
        GL_EXT_gpu_shader4, GL_EXT_multi_draw_arrays, GL_EXT_packed_depth_stencil, 
        GL_EXT_packed_float, GL_EXT_packed_pixels, GL_EXT_pixel_buffer_object, 
        GL_EXT_point_parameters, GL_EXT_provoking_vertex, GL_EXT_rescale_normal, 
        GL_EXT_secondary_color, GL_EXT_separate_specular_color, 
        GL_EXT_shadow_funcs, GL_EXT_stencil_wrap, GL_EXT_subtexture, 
        GL_EXT_texgen_reflection, GL_EXT_texture3D, GL_EXT_texture_array, 
        GL_EXT_texture_buffer_object, GL_EXT_texture_compression_latc, 
        GL_EXT_texture_compression_rgtc, GL_EXT_texture_compression_s3tc, 
        GL_EXT_texture_cube_map, GL_EXT_texture_edge_clamp, 
        GL_EXT_texture_env_add, GL_EXT_texture_env_combine, 
        GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic, 
        GL_EXT_texture_integer, GL_EXT_texture_lod, GL_EXT_texture_lod_bias, 
        GL_EXT_texture_mirror_clamp, GL_EXT_texture_object, 
        GL_EXT_texture_rectangle, GL_EXT_texture_sRGB, 
        GL_EXT_texture_shared_exponent, GL_EXT_texture_snorm, 
        GL_EXT_texture_swizzle, GL_EXT_transform_feedback, GL_EXT_vertex_array, 
        GL_EXT_vertex_array_bgra, GL_IBM_texture_mirrored_repeat, 
        GL_KTX_buffer_region, GL_NV_blend_square, GL_NV_conditional_render, 
        GL_NV_copy_depth_to_color, GL_NV_explicit_multisample, 
        GL_NV_primitive_restart, GL_NV_texgen_reflection, GL_SGIS_generate_mipmap, 
        GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_SUN_multi_draw_arrays, 
        GL_WIN_swap_hint, WGL_EXT_swap_control
    (bottom part of glxinfo cut out to comply with max post length)

  2. #2
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,464

    Default

    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 at 10:19 AM.

  3. #3
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,796

    Default

    "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?

  4. #4
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    Quote Originally Posted by RealNC View Post
    "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?
    very similar problem and the problem called fglrx :-)

    opensource Radeon will save us all..

    |||||All your base are belong to us||||||||||

  5. #5
    Join Date
    Dec 2007
    Location
    Merida
    Posts
    1,102

    Default

    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.

  6. #6
    Join Date
    Sep 2009
    Posts
    7

    Default

    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.

  7. #7
    Join Date
    Dec 2008
    Posts
    991

    Default

    Quote 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

  8. #8
    Join Date
    Oct 2007
    Location
    Under the bridge
    Posts
    2,146

    Default

    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!)

  9. #9
    Join Date
    Sep 2009
    Posts
    7

    Default

    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

  10. #10
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,464

    Default

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •