grosvenor

Members
  • Content count

    11
  • Joined

  • Last visited

Community Reputation

149 Neutral

About grosvenor

  • Rank
    Member
  1. DrawIndexedPrimitive & ATI driver

    Interesting theory. Not entirely impossible that somebody would do something like this. [img]http://public.gamedev.net//public/style_emoticons/default/biggrin.png[/img]
  2. DrawIndexedPrimitive & ATI driver

    @Hodgeman: I have looked directly at the index values in the V&I-buffers. As far as I can see, the conditions you state are met. Anyway, I am curious: why should I expect a driver to run into trouble when you pass an overly generous vertex range. I mean, besides, "you never know" ... [img]http://public.gamedev.net//public/style_emoticons/default/laugh.png[/img] Passing a vertex range that is too limited will cause trouble, if the driver actually uses this information, sure. @mhagain: Right, that would work. But nothing I am too eager to do. And the ATI driver problem might still remain.
  3. DrawIndexedPrimitive & ATI driver

    It's cracy, there is this awesome hardware with hundreds of features you usually do not even use, and then one has to struggle with these things. Using a single big index & vertex buffer is a actually a good move. I remember there was an NVIDIA talk, where they suggested doing this (DX9 was hot and new at the time). But then again, risking compatibility issues with 32-bit index buffers would make me a bit nervous. Yes, I can imagine it is a pain to arrange support for 16-bit-index-buffers in such a scenario. Fortunately, in my case, using DRAWPRIMITIVE as a cure is not a big deal. It will probably use up a little more GPU RAM and be a little slower because vertex caching becomes useless.
  4. DrawIndexedPrimitive & ATI driver

    Card is a ATI HD2600 mobility. The vertexbuffers are XYZ|NORMAL|UV, i.e. 32 bytes per vertex.
  5. DrawIndexedPrimitive & ATI driver

    I experimented with different start vertex and index indices before. If I remember correctly, it delayed the occurrence of the bug or shifted it to other triangles. But it wasn't a reliable behavior. Nevertheless, I reinstalled the most recent ati driver and tried what you suggested. Added 100 vertices to the beginning for padding, changed the index buffer accordingly and then rendered with minVertex=100. Exactly the same behavior as before. How exactly did you do it? If all else fails, one thing seems to do the job: using DrawPrimitive instead of DrawIndexedPrimitive. Which should be available from the options menu through "Enable embarrasing ATI pampering" ;)
  6. DrawIndexedPrimitive & ATI driver

    Sounds promising - it would be great if you could post this change.
  7. DrawIndexedPrimitive & ATI driver

    1) I did another test: run Dragon Age:Origins. Result: same artifacts occurring as in my engine. Not so with the old HP driver. 2) AMD/ATI says that you should use a tool provided by them to determine if your specific notebook is compatible to the catalyst mobility driver. Unfortunately, this site is currently unreachable. Internet rumor says to stick to the notebook manufactures gpu drivers. These are from 2009, but both my game and DA:O run without problems. Also, using the ATI driver I also experienced a minor, but unprecedended issue with power managment, which might be another clue for compatibility issues. So, for now I am going to conclude that it is the driver after all. L. Spiro's reasoning to take on the opportunity to find flaws in the engine is a good one. But all considered, I would say that the chances are minimal that there is something insightful to find here. Unless somebody else has encoutered the same problem and found a solution to it. So, thanks for your help. Cu, - Matt
  8. DrawIndexedPrimitive & ATI driver

    I am aware that there is a performance impact through redundant SetRenderStates and so on. But nothing beats "good enough". So, as long as it doesn't hurt the driver I won't change it. If I am ever considering performance issues, I might look into this aspect again, but not now. So here is a simplified shader, that shows the same behavior (tris disappearing after 512 frames): [CODE] float4 PS_ConstantColor(VS_OUTPUT pixel) : COLOR { float4 col; col.rgba=Color; return col; } VS_OUTPUT VS_NoLight( float4 position : POSITION0, float3 normal : NORMAL0, float3 texCoord : TEXCOORD0 ) { // calculate the pos/normal using the "normal" weights // and accumulate the weights to calculate the last weight float3 skinPosition = float3(0.0f, 0.0f, 0.0f); float3 skinNormal = float3(0.0f, 0.0f, 0.0f); skinPosition = mul(float4(position.xyz,1.0), World); skinNormal= mul(float4(normal.xyz,0.0), World); skinNormal = normalize(skinNormal); // normalize normal float3 diffuse = Ambient; // transform position from world space into view and then projection space VS_OUTPUT pixel; pixel.Position = mul(float4(skinPosition.xyz, 1.0f), ViewProjection); pixel.Diffuse = float4(diffuse,1); pixel.TexCoord = texCoord; pixel.CamView = normalize(skinPosition - CameraPosition) ; pixel.Normal = skinNormal; return pixel; } technique cc_shader { pass p0 { VertexShader = compile vs_3_0 VS_NoLight(); PixelShader = compile ps_3_0 PS_ConstantColor(); } } [/CODE] Another bit of information: the bug does not appear with the reference rasterizer.
  9. DrawIndexedPrimitive & ATI driver

    Empty macro, as in [CODE] #define VERIFY(x) (x) [/CODE] (but you're right to ask for a clarification, it could also have been like [CODE] #define VERIFY(x) () [/CODE] ) @mhagain: Using debug runtime, all validation cranked up to maximum. The only thing reported are warnings of redundant SetRenderState and SetTextureStageState calls. So this is probably what L. Spiro meant by "Are you doing redundant-state checking on your end?". The answer is no, I just set all states required every frame. - Matt
  10. DrawIndexedPrimitive & ATI driver

    Hi L. Spiro, [quote="L. Spiro"]Are you rendering on second thread?[/quote] It's the main thread. [quote="L. Spiro"]Are you doing redundant-state checking?[/quote] Uhh... sounds pretty general. Anything specific I should be looking for? [quote="L. Spiro"]Why not some screenshots of this omitting of triangles?[/quote] Right, why not... [attachment=9899:missing_triangles.jpg] So, this is where the buffers are bound: [CODE] VERIFY(Get3DDevice()->SetFVF( m_VertexFormat.GetVertexFormatID() )); VERIFY(Get3DDevice()->SetStreamSource(0, m_VertexBuffer.m_D3D9VertexBuffer, 0, m_VertexFormat.GetVertexSize())); VERIFY(Get3DDevice()->SetIndices(m_IndexBuffer.m_D3D9IndexBuffer)); [/CODE] ... and this is the render call [CODE] //actual rendering: assert(pEffect); if (pEffect) { unsigned int numPasses = 0; VERIFY(pEffect->Begin(&numPasses, 0)); for (unsigned int pass = 0; pass < numPasses; ++pass) { VERIFY(pEffect->BeginPass(pass)); HRESULT hr; hr = Get3DDevice()->DrawIndexedPrimitive(D3DPT_TRIANGLELIST, 0, 0, m_VertexBuffer.m_NumVertices, index0, numIndices/3); if (hr!=D3D_OK) { sys::Output(DXGetErrorString(hr)); sys::Output(DXGetErrorDescription(hr)); assert(false); } VERIFY(pEffect->EndPass()); } VERIFY(pEffect->End()); } [/CODE] Btw, the effect does not care which model I take. It happens the same with a tesselated sphere. It happens in-game and it happens in the modelviewer. [quote]What does PIX say you are passing to the call? Is it not the correct number of triangles for the primitive type (triangle list/triangle strip)?[/quote] 148 <0x064A5970> IDirect3DDevice9::DrawIndexedPrimitive(D3DPT_TRIANGLELIST, 0, 0, 4688, 0, 2612) 66862329856 I can even hardcode the parameters in this call to these values, the missing triangles bug appears not before the 512th frame. To be honest, I used PIX the first time now that you mentioned it. [quote]Are the correct vertex buffers bound?[/quote] Probably. When I launch the modelviewer, there is only one vertex buffer and one index buffer thats get set at all, so there is not much chance of mixing it up, I guess. From the pictures I would rather guess the index buffer to be the problem, but it 's no definite saying, because the polygons don't share vertices. [quote]It is unlikely an ATI driver bug. More likely they have made fixes which have exposed some error on your side, and you should be glad for this chance to find and fix it.[/quote] That's right. But I am really curious. This one would really be a long time lurker. Thanks for helping, Matt Edit: the VERIFY doesn't do anything. It's only an empty macro in this configuration.
  11. I have a strange problem with my DirectX9 engine and ATI drivers - and no idea how to track this further: After I installed the latest ATI driver on my computer directX-DrawIndexedPrimitive calls starts to ommit some triangles while rendering. This behaviour starts exactly after 512 calls to DrawIndexedPrimitive. I have run under maximum debug settings, debug directx, nothing conspicious is reported. This only happens using the latest ATI drivers. I'm using my own a 3D game engine which has already been used in a few commercial releases, DirectX 9, shader model 3.0. System is Windows 7, 64bit, a HP 8510p notebook with a ATI HD 2600 mobility GPU. The code works fine with the Windows 7 stock drivers, and the original HP drivers from 2009. But not with the current ATI drivers. So far I said, well, forget the ATI drivers. However, yesterday I installed the indy game "starfarer", that does not even get the device up at all using the windows 7 or HP driver, but does so using the ATI one. It would really suck if I had to say to my eventual customers "you might not be able to play your other games, but my game will work fine if you roll back your gpu driver.". So has anybody had similar experiences? Are there known issues with the DrawIndexedPrimitive and ATI? Any ideas what to try? - Matt