google-code-export / angleproject

Automatically exported from code.google.com/p/angleproject
0 stars 0 forks source link

Aquarium Doesn't work on Intel 945 GM in Win XP #101

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Run Aquarium on Intel 945 GM in Win XP

see screeshot

---

GPU Info
Chrome Version
Data exported   Thu Jan 13 2011 23:37:56 GMT-0800 (Pacific Standard Time)
Chrome version  10.0.638.0 (Official Build 71284) canary build
Driver Information
Initialization time 56
Vendor Id   0x8086
Device Id   0x27a2
Driver version  6.14.10.4436
Pixel shader version    2.0
Vertex shader version   0.0
GL version  0.0
Diagnostics
0
b3DAccelerationEnabled  true
b3DAccelerationExists   true
bAGPEnabled true
bAGPExistenceValid  true
bAGPExists  false
bCanRenderWindow    true
bDDAccelerationEnabled  true
bDriverBeta false
bDriverDebug    false
bDriverSigned   false
bDriverSignedValid  false
bNoHardware false
dwBpp   32
dwDDIVersion    9
dwHeight    800
dwRefreshRate   60
dwWHQLLevel 0
dwWidth 1280
iAdapter    0
lDriverSize 36990
lMiniVddSize    1353820
szAGPStatusEnglish  Not Available
szAGPStatusLocalized    Not Available
szChipType  Intel(R) Calistoga Graphics Controller
szD3DStatusEnglish  Enabled
szD3DStatusLocalized    Enabled
szDACType   Internal
szDDIVersionEnglish 9 (or higher)
szDDIVersionLocalized   9 (or higher)
szDDStatusEnglish   Enabled
szDDStatusLocalized Enabled
szDXVAModes 
szDescription   Mobile Intel(R) 945GM Express Chipset Family
szDeviceId  0x27A2
szDeviceIdentifier  {D7B78E66-64E2-11CF-A962-ECA1A2C2CB35}
szDeviceName    \\.\DISPLAY1
szDisplayMemoryEnglish  128.0 MB
szDisplayMemoryLocalized    128.0 MB
szDisplayModeEnglish    1280 x 800 (32 bit) (60Hz)
szDisplayModeLocalized  1280 x 800 (32 bit) (60Hz)
szDriverAttributes  Final Retail
szDriverDateEnglish 12/17/2005 03:08:00
szDriverDateLocalized   12/17/2005 03:08:00
szDriverLanguageEnglish English
szDriverLanguageLocalized   English
szDriverName    ialmrnt5.dll
szDriverSignDate    
szDriverVersion 6.14.0010.4436
szKeyDeviceID   Enum\PCI\VEN_8086&DEV_27A2&SUBSYS_81E6104D&REV_03
szKeyDeviceKey  \REGISTRY\Machine\System\ControlSet001\Services\ialm\Device0
szManufacturer  Intel Corporation
szMiniVdd   ialmnt5.sys
szMiniVddDateEnglish    12/17/2005 03:08:00
szMiniVddDateLocalized  12/17/2005 03:08:00
szMonitorMaxRes 1600,1200
szMonitorName   Plug and Play Monitor
szNotesEnglish  No problems found.
 To test DirectDraw functionality, click the "Test DirectDraw" button above.
 To test Direct3D functionality, click the "Test Direct3D" button above.

szNotesLocalized    No problems found.
 To test DirectDraw functionality, click the "Test DirectDraw" button above.
 To test Direct3D functionality, click the "Test Direct3D" button above.

szRegHelpText   
szRevision  
szRevisionId    0x0003
szSubSysId  0x81E6104D
szTestResultD3D7English Not run
szTestResultD3D7Localized   Not run
szTestResultD3D8English Not run
szTestResultD3D8Localized   Not run
szTestResultD3D9English Not run
szTestResultD3D9Localized   Not run
szTestResultDDEnglish   Not run
szTestResultDDLocalized Not run
szVdd   n/a
szVendorId  0x8086

Original issue reported on code.google.com by g...@chromium.org on 14 Jan 2011 at 7:39

Attachments:

GoogleCodeExporter commented 9 years ago
Please test again with a recent revision. There have been some significant 
changes to the geometry management code.

It looks like these artifacts might be caused by the lack of support for 32-bit 
indices by the hardware. Previously we faked support for it in ANGLE, but that 
code was untested. The latest code won't expose support for 32-bit indices 
unless supported by the hardware.

Note that this might mean it doesn't render at all now... The application would 
have to use 16-bit indices if this is the case.

Original comment by nicolas....@gmail.com on 20 Jan 2011 at 7:57

GoogleCodeExporter commented 9 years ago
I don't see how that's possible. OpenGL ES 2.0 does not support 32bit indices 
and our emulation of it has never supported 32bit indices.

Original comment by g...@google.com on 20 Jan 2011 at 6:48

GoogleCodeExporter commented 9 years ago
Core OpenGL ES 2.0 doesn't support 32-bit indices, but it has been exposed as 
the GL_OES_element_index_uint extension for a very long time now. So I believe 
some WebGL samples do use 32-bit indices.

Original comment by nicolas....@gmail.com on 28 Feb 2011 at 3:38

GoogleCodeExporter commented 9 years ago
Nicolas: yes it's available as an extension for GLES2, but I don't think that 
extension has been exposed via WebGL yet.  Until that's done it shouldn't be 
possible for a webgl app to pass in 32-bit indices.

Original comment by dan...@transgaming.com on 28 Feb 2011 at 6:23

GoogleCodeExporter commented 9 years ago
Correct, GL_OES_element_index_uint has not been exposed in WebGL, and as it 
isn't supported on any iOS hardware to date there are no current plans to 
expose it.

Original comment by kbr@chromium.org on 28 Feb 2011 at 6:58

GoogleCodeExporter commented 9 years ago
This demo does not and never has used 32 bit indies. WebGL doesn't even support 
32 bit indices.

It still gets on same results on Chrome 14.0.835.186 m

Original comment by g...@google.com on 22 Sep 2011 at 7:43

GoogleCodeExporter commented 9 years ago
The artifact goes away when toggling off 'fog' in the controls on the left. The 
fog calculations essentially consist of clamp(pow(z / w, 14.5), 0, 1), in the 
fragment shader. Unfortunately the GMA 950 can't handle a large range of 
floating-point values in the pixel shader, which leads me to believe it 
overflows/underflows seemingly randomly and this causes some triangles to have 
maximum fog while others have none (with a 'reset' happening between 
triangles). This is just speculation, but in any case it seems doubtful that 
it's an ANGLE bug causing this. The GMA 950 definitely has severe hardware 
limitations and driver stability issues.

That said, glGetShaderPrecisionFormat currently reports full 32-bit 
floating-point precision, since there is no way to tell what the supported 
precision is for Shader Model 2.0 hardware through Direct3D 9 (Shader Model 3.0 
has to support 32-bit precision). We could report the lowest known precision 
for Shader Model 2.0 hardware, but that won't automatically fix the actual 
WebGL application of course. Any thoughts on changing 
glGetShaderPrecisionFormat?

Note that with Chrome the GMA 950 is actually blacklisted and it falls back to 
SwiftShader, which renders things at the same performance (on a Core Duo 1.66 
GHz), but flawlessly.

Original comment by nicolas....@gmail.com on 4 Jun 2012 at 6:50

GoogleCodeExporter commented 9 years ago
I don't think it's worth changing the results of glGetShaderPrecisionFormat -- 
as you mention, doing so won't actually solve anything.

Blacklisting this GPU and falling back to SwiftShader sounds like the best 
workaround.

Original comment by kbr@chromium.org on 4 Jun 2012 at 7:12

GoogleCodeExporter commented 9 years ago
Closing as wont fix since it already appears to be blacklisted.

Original comment by dan...@transgaming.com on 5 Jun 2012 at 6:01