Page 2 of 5 FirstFirst 1234 ... LastLast
Results 11 to 20 of 42

Thread: pascal and learning 3d

  1. #11
    Quote Originally Posted by laggyluk View Post
    Should I use packed records for this purpose? the interweb says it has slower access performance than 'unpacked'
    Packed record are usually only required when you need to load/save data in a consistent way between different compilers or even languages, or when passing to programming API routines.
    Besides that, I haven't noticed any slowdown when using packed records compared to normal records

  2. #12
    PGDCE Developer Carver413's Avatar
    Join Date
    Jun 2010
    Location
    Spokane,WA,Usa
    Posts
    206
    a packed record prevents the compiler from inserting any space into your record if the compiler were to somehow change the size of your record then opengl would not understand these changes and would not work as expected.

  3. #13
    I figured out that for the world made of cubes it might be worth a try to feed points to the vertex shader instead of triangles and build cubes in the geometry shader. So I did and it seems to work. But only on the integrated graphics card I have 2 in my laptop and when I switch to nvidia all I see is darkness. Integrated driver says it's opengl 3.1 and nvidia's is 4.3. Can I somehow force nvidia to work in 'older' mode? all the tuts I've seen either use glew or glut (which i don't) to initialize the context so I'm confused how to do that

  4. #14
    Can you show shader code? Graphics cards are very picky about that.

  5. #15
    hey, you were right i've run test with simplest shaders which resulted in black screen also so after some tinkering with syntax now everything works. too bad that shader linker didn't bother with reporting any problems

  6. #16
    Quote Originally Posted by laggyluk View Post
    Should I use packed records for this purpose? the interweb says it has slower access performance than 'unpacked'
    Example you quoted says packed, but it is actually byte-aligned to 32 and 64 bit, so it wouldn't make any difference.

    Code:
    TRGB1 = packed record
      r, g, b: byte;
    end;
    This is not aligned. But if you make it an array and compare size:
    Code:
    TRGB2 = record
      r, g, b: byte;
    end;
    
    arr1: array[0..255] of TRGB1;
    arr2: array[0..255] of TRGB2;
    The arr1 is 256-1280 bytes smaller than arr2. This is because if you take sizeof(TRGB1) you would get 3, but sizeof(TRGB2) would give you 4 or 8 depending on if you compile with 32 or 64 bit compiler, i guess... Now if you're dealing with OpenGL functions, you need to tell it exactly the structure of the data you are using. For that there is usually a "stride"-parameter, to describe the spacing. If you would send it color data, you should use TRGB1 style with size 3 bytes. All the data is in tight sequence without spaces in between. But actually you will notice that most records will be byte aligned anyway.

    For example shader vertex-data, that will propably be the most time-critical array of them all, is byte-aligned no matter how you twist it:
    Code:
      TModelVertex = packed record
        v, n: TVector; // 12+12 bytes
        uv: TVector2f; // 8 bytes
      end; // = 24+8 = 32 => 32/8 = 4 => aligned to 64 bits

  7. #17
    Quote Originally Posted by User137 View Post
    Example you quoted says packed, but it is actually byte-aligned to 32 and 64 bit, so it wouldn't make any difference.

    Code:
    TRGB1 = packed record
      r, g, b: byte;
    end;
    This is not aligned. But if you make it an array and compare size:
    Code:
    TRGB2 = record
      r, g, b: byte;
    end;
    
    arr1: array[0..255] of TRGB1;
    arr2: array[0..255] of TRGB2;
    The arr1 is 256-1280 bytes smaller than arr2. This is because if you take sizeof(TRGB1) you would get 3, but sizeof(TRGB2) would give you 4 or 8 depending on if you compile with 32 or 64 bit compiler, i guess... Now if you're dealing with OpenGL functions, you need to tell it exactly the structure of the data you are using. For that there is usually a "stride"-parameter, to describe the spacing. If you would send it color data, you should use TRGB1 style with size 3 bytes. All the data is in tight sequence without spaces in between. But actually you will notice that most records will be byte aligned anyway.
    Err, you got it wrong. For the sake of completeness I've just put your data types into FPC/Lazarus (1.0.2) and Delphi XE 3, and SizeOf(arr1) = SizeOf(arr2) = 768; SizeOf(TRGB1) = SizeOf(TRGB2) = 3.

    Data alignment works by aligning starting offset of your data, not the size of your data. I also believe that for such cases, "packed" keyword is deprecated, at least in Delphi. What you probably meant was data padding, but I don't see how it can be useful for TRGB1/TRGB2 in terms of performance.

    Edit: according to $Align option manual, I could reproduce data padding in the following example:

    Code:
    type
     TSomeRecord = record
       TinyValue: Byte;
       BigValue: Word;
     end;
    
     TSomeArray = array[0..9] of TSomeRecord;
    In above example, "packed" keyword does seems to have effect, specifically for "TinyValue".
    Last edited by LP; 30-11-2012 at 02:25 PM.

  8. #18
    I don't know exactly how it goes, but i tested a bit too after your comment. TRGB2 is indeed 3 bytes for some reason.

    But these are both 8 bytes, and 5 if packed. Same with Lazarus and Delphi.
    Code:
    TRecord1 = record
      a: single;
      b: byte;
    end;
    
    TRecord2 = record
      b: byte;
      a: single;
    end;
    So it doesn't matter if the value is last one. Having only 1 variable type in record seems to be special case, that is not adding any padding.
    Last edited by User137; 30-11-2012 at 03:48 PM.

  9. #19
    By the way, I'm mistaken regarding packed being deprecated, after checking manuals again, I did not find any references to it. I remember reading about it somewhere since release of XE 2, but perhaps got it confused with something else. Sorry.

  10. #20
    Packed records or packed arrays are used when you wnat to decrease the memory needed to store theese. Packed comes into effect if the records or arrays contains variables which by default aren't alined to 2, 4, 8 bit alingment. Default alingmnets for variables differ by variable type and is defined so that it offers optimized performance for working with theese variables.
    But with the usage of Packed command you can override theese default alignments and pack data closely together thus lowering the memory consumption. Doing so also decreases the peformance of working with theese variables a bit since they are no longer optimally aligned. Unles you are using large record or large array difference in performance probably won't even be noticable.

    Using of Packed records is sometimes necessary if you are sending some data to another application which is developed with different compiler since not all compilers use same data aligment for reaching optimal performance. In some cases using non packed records can cause for data in other program to be read incorectly.
    So always make sure to check program documentation as of which type of records it can recieve. Same goes for varios API functions.

Page 2 of 5 FirstFirst 1234 ... LastLast

Bookmarks

Posting Permissions

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