[Bug 21515] VENDOR_WINE vs VENDOR_ATI with xf86-video-ati

[wine-bugs at winehq.org]

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





--- Comment #79 from P.Panon <ppanon at shaw.ca>  2010-02-25 04:47:49 ---
Thanks Cùran.

I must admit that I'm quite surprised that, 1 week after your cleaned up patch,
nothing seems to have happened with this patch even though Stefan had been
quite helpful in providing feedback earlier. Not sure if that means it's queued
up for testing or not but it's interesting to note that 1.1.39 has since been
released.

Regarding your results on attachments 26185/7, it looks like the card is being
treated as a CARD_ATI_RADEON_8500:
trace:d3d_caps:wined3d_guess_card Applying card_selector "Mesa AMD/ATI driver".
trace:d3d_caps:IWineD3DImpl_FillGLCaps FOUND (fake) card: 0x1002 (vendor id),
0x514c (device id)
The rendering string should be matching to set the device to
CARD_ATI_RADEON_9500, so the Mesa R300 driver must be failing one of the tests
that Wine is using to determine whether DirectX 9 3D support is possible, and
then defaulting to a card model that only supports DirectX 8. The
driver_version_table[] only contains entries for ATI and NVidia Directx9 cards
and therefore a default value is passed on to the Windows app. This correlates
with your observations in comment #52.

#define WINE_D3D9_CAPABLE(gl_info) WINE_D3D8_CAPABLE(gl_info) &&
(gl_info->supported[ARB_FRAGMENT_PROGRAM] &&
gl_info->supported[ARB_VERTEX_SHADER])
Since the card passes the D3D8 test and RadeonFeature indicates the R300 driver
should support Vertex and Fragment Shaders, The following trace lines would
make me think that those two features should be supported by the driver. Maybe
the driver's reporting something wrong in gl_info?
trace:d3d_caps:IWineD3DImpl_FillGLCaps Max ARB_FRAGMENT_PROGRAM float
constants: 256.
trace:d3d_caps:IWineD3DImpl_FillGLCaps Max ARB_FRAGMENT_PROGRAM native float
constants: 32.
trace:d3d_caps:IWineD3DImpl_FillGLCaps Max ARB_FRAGMENT_PROGRAM native
temporaries: 32.
trace:d3d_caps:IWineD3DImpl_FillGLCaps Max ARB_FRAGMENT_PROGRAM native
instructions: 96.
trace:d3d_caps:IWineD3DImpl_FillGLCaps Max ARB_FRAGMENT_PROGRAM local
parameters: 96.
trace:d3d_caps:IWineD3DImpl_FillGLCaps Max ARB_VERTEX_PROGRAM float constants:
256.
trace:d3d_caps:IWineD3DImpl_FillGLCaps Max ARB_VERTEX_PROGRAM native float
constants: 256.
trace:d3d_caps:IWineD3DImpl_FillGLCaps Max ARB_VERTEX_PROGRAM native
temporaries: 32.
trace:d3d_caps:IWineD3DImpl_FillGLCaps Max ARB_VERTEX_PROGRAM native
instructions: 255.

So I'm not sure why that test is failing. However it shouldn't be due to code
I've touched. A bigger question is why the vidmem settings aren't getting
passed back. I didn't see a similar screenshot from cruiseoverride, but if his
videomemory values are also zero, then those aren't being passed back somehow,
which might explain poor rendering performance if the benchmark app thinks it
doesn't have any card memory available.

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.