🚀 go-pugleaf

Doug Chism wrote:

> Sound like you guys know your stuff. Now here is a tough one. The big reason
> Intel has such an FPU advantage right now is because the FPU is pipelined -
> i.e. the FPU can start the next instruction before finishing the first. How
> will this ( if at all ) carry over when the MMX type FPU instruction set is
> released? It may not change that much unless the Intel CPU can pipeline MMX
> FPU instructions. I have some hand written assembly code (ill provide if
> requested ) for a 4x4 vector transform optimized ( by Michael Abrash ) for
> the Pentium's pipelined FPU. Upon close inspection if this was rewritten to
> take advantage of an MMX type FPU optimization there would be a 30% speed up
> at best, since 3 instructions are being pipelined out of 4. This is ignoring
> the fact that there is setup involved in setting the CPU up for MMX or FPU
> MMX instructions. Of course well written code could avoid this by executing
> similar instructions in serial ( i.e. transform all the vertices in the
> scene in 1 loop ), but this often results in cache thrashing since its hard
> to store polygon and vertex data together unless strips and fans are used
> exclusively. If you were to go this route you would see a similar slowdown
> on objects that cannot be efficiently stored as strips and fans ( i.e.
> skinned animated mesh objects). This leads me to the conclusion that the K6
> 3D instruction set will not increase the FPU advantage over Intel CPU's by
> more than 15-20% even if the code is optimized for this instruction set. It
> also leads me to believe that Intel CPU's are not going to see a huge speed
> up also since I cant think of a way to pipeline a MMX instruction ( there is
> only so many registers in the FPU - certainly not enough to store that much
> data ). Maybe I am confusing the issue here since I am merly an implementor
> of techniques - not the designer - my job is to get the graphics running so
> I frequently grab code from here or there to get it running quick and fast
> instead of really studying whats really going on. What is your guys opinion
> of this dilemma?
>
> Doug Chism
> AKA AT$_Roid_Monkey

 Hello. Sorry for my English.
 Think it's not a great problem.
 If you want to do view and projection transformation manually, if the
 vertex array extension of DirectX6, OpenGL 1.1/1.2 is not suitable
 for you - try to read some proposition covered in this letter.


  //  Psevdo code sample

  struct TVertexBuf  {
    Point3 P;      // Vertex
    int ClipCode;  // View frustum clipping code
  } VertexBuffer[4096];  // 64K

  struct TMesh {
     TArray <TVert> Vertexes;
          TArray <TPoint3> <TexCoords>
     TArray <int> VIndexes;
     TArray <TFace> Faces;
     TArray <TPoint3> VertNormals;
     // etc.
  };


  // ....................  Render loop ..........................


  AnimateMesh(Obj, dt); // Animates mesh of a given object

  { // RenderObject
    // Force the current prj and view matrix to be One to One
    // On most accelerators without triangle startup this trick
    // improves performance about 2x-3x vs. default APIs transform

    LoadIdentityMatrixes();

    // You can transform the vertex array in one loop for one or all
    // objects with Clipcode generation
    TransformVertexes(Obj->Mesh, VertexBuffer); 


  for (all faces) {
   // Form triangle Ind0, Ind1, Ind2
   // analyze Clip code
   if ( Triangle_is_visible(Clip0,Clip1, Clip2)
     && BackFace(VertexBuffer, Ind0, Ind1, Ind2)==0) {
     // Transfer vertexes to API

      glVertex3fv(&VertexBuffer[Ind0]);
      glVertex3fv(&VertexBuffer[Ind1]);
      glVertex3fv(&VertexBuffer[Ind2]);
    }
  }
}



 3. About cache misses.
     Your processor have at least 32K of L1 and 256K of L2 cache
     If you provide sequential access to your data and make your buffers
     & tables to fit to this limits, the speed of memory access would be
    similar to internal processor registers.

 4. As I know, the transition between MMX/FPU takes no more than 50
    clocks. And some final 3D transformations an clippings are perfect 
    on MMX  with 16 bit fixed point accuracy (Because some objects 
    are too small in relative to whole scene).

 5. Memory requirements : The convention PC accelerators can't do 
    more than 10-50K triangles per frame at 30 Fps (this is practical 
    performance for Highlevel 3D APIs). If you store single vertex as 
    8 bytes (with signed short precision),  or 4xfloat the memory 
    requirements will be only 160-800k for all scene.
    Because that small vertex buffer is more preferable.

6. Use Intel(R) VTune in your optimization - this tool analysis program
   performance cache misses and more, with histogram/source/asm views.

Good luck!