f



Why can't I just use 'glPixelStorei(GL_UNPACK_ALIGNMENT, 1);' all the time?

I have few questions...


1. Why can't I just always use glPixelStorei(GL_UNPACK_ALIGNMENT, 1); if it works every time?

Could you give me an example where I have to use GL_UNPACK_ALIGNMENT other than 1?


2. Why does OpenGL require alignment? can't it just read memory one by one?


Thanks.
-- 
This post on narkive:
http://narkive.com/GRey4bF6

0
yj1214
9/3/2015 8:03:40 AM
comp.graphics.api.opengl 7074 articles. 1 followers. Post Follow

14 Replies
974 Views

Similar Articles

[PageSpeed] 54

> "yj1214" :
> 1. Why can't I just always use glPixelStorei(GL_UNPACK_ALIGNMENT, 1); if
> it works every time?
> Could you give me an example where I have to use GL_UNPACK_ALIGNMENT other
> than 1?

Could you give us examples of what doesn't work in your code ?


> 2. Why does OpenGL require alignment?

Because it's faster.


> can't it just read memory one by one?

It would be slower.
 

0
Jean
9/3/2015 1:01:01 AM
> Well, here you go.
> ( ... ) 
> glPixelStorei(GL_UNPACK_ALIGNMENT, 1);
> If I change both ALIGNMENT to other than 1

What values did you try to make glPixelStore fail ?


> they both won't work. 

What exactly didn't work :

- Did glPixelStore return an error code  ? 
  If yes, what was the error code value ?

- Or was the result of unpacking different from what you expected ? 
0
Jean
9/3/2015 1:01:01 AM
Jean-Christophe wrote:
> > "yj1214" :
> > 1. Why can't I just always use glPixelStorei(GL_UNPACK_ALIGNMENT, 1); if
> > it works every time?
> > Could you give me an example where I have to use GL_UNPACK_ALIGNMENT other
> > than 1?
> Could you give us examples of what doesn't work in your code ?
> > 2. Why does OpenGL require alignment?
> Because it's faster.
> > can't it just read memory one by one?
> It would be slower.


Well, here you go.

**********************************************************
GLubyte text[3] = {
	0xff, 0x30, 0xff
};
glPixelStorei(GL_UNPACK_ALIGNMENT, 1);
**********************************************************
This works fine.



**********************************************************
GLubyte something[15] = {
	0xc0, 0xc0, 0xc0, 0xc0, 0xc0,
	0xff, 0xff, 0xc0, 0xc0, 0xc0,
	0xff, 0xff, 0xff, 0xff, 0xff
};
glPixelStorei(GL_UNPACK_ALIGNMENT, 1);
*********************************************************
This also works fine.



If I change both ALIGNMENT to other than 1, they both won't work. Could explain the point of using GL_UNPACK_ALIGNMENT other than 1? thanks.
-- 
This post on narkive:
http://narkive.com/GRey4bF6.3

0
yj1214
9/3/2015 7:35:34 PM
Jean-Christophe wrote:
> > Well, here you go.
> > ( ... ) 
> > glPixelStorei(GL_UNPACK_ALIGNMENT, 1);
> > If I change both ALIGNMENT to other than 1
> What values did you try to make glPixelStore fail ?
> > they both won't work. 
> What exactly didn't work :
> - Did glPixelStore return an error code  ? 
>   If yes, what was the error code value ?
> - Or was the result of unpacking different from what you expected ?


It didn't return an error code. It just renders weird looking characters whenever I use GL_UNPACK_ALIGNMENT other than 1.

I just don't really get the point of using 2, 4 and 8 since 1 will always work. So I want an example of using 2, 4 and 8 alignment. Thanks.
-- 
This post on narkive:
http://narkive.com/GRey4bF6.5

0
yj1214
9/3/2015 9:07:07 PM
yj1214,

Both examples seem to use byte arrays.  A bytes alignment is always One.

Have you ever tried any other size, like d(ouble)words (4 bytes per element)
or q(uad)words (8 byte per element) ?

It is quite possible that transfer of d- or qwords goes quite a bit faster
when they are aligned.  And that speed has to do with how the processor
retrieves data from the memory (only needing to read that one element,
instead of (a hardware-reqired)  read of two aligned elements and than, deep
in the procesor, extract the unaligned element from them).

Next to that some kinds of data-transfer (like possibly from/to the video
card) of larger-than-byte elements may only be performed when the data is
aligned.

And lets not forget that OpenGL was written to be portable, which means it
should be able to run on something else than systems with an an 80x86
processor, with other, stricter requirements in regard to alignments.

Hope that clarifies it a bit,
Rudy Wieser


-- Origional message:
yj1214 <jxnw3jct-yj1214@user.narkive.com> schreef in berichtnieuws
GRey4bF6-RfFy50U77liI1CFW@narkive.com...
> Jean-Christophe wrote:
> > > "yj1214" :
> > > 1. Why can't I just always use glPixelStorei(GL_UNPACK_ALIGNMENT, 1);
if
> > > it works every time?
> > > Could you give me an example where I have to use GL_UNPACK_ALIGNMENT
other
> > > than 1?
> > Could you give us examples of what doesn't work in your code ?
> > > 2. Why does OpenGL require alignment?
> > Because it's faster.
> > > can't it just read memory one by one?
> > It would be slower.
>
>
> Well, here you go.
>
> **********************************************************
> GLubyte text[3] = {
> 0xff, 0x30, 0xff
> };
> glPixelStorei(GL_UNPACK_ALIGNMENT, 1);
> **********************************************************
> This works fine.
>
>
>
> **********************************************************
> GLubyte something[15] = {
> 0xc0, 0xc0, 0xc0, 0xc0, 0xc0,
> 0xff, 0xff, 0xc0, 0xc0, 0xc0,
> 0xff, 0xff, 0xff, 0xff, 0xff
> };
> glPixelStorei(GL_UNPACK_ALIGNMENT, 1);
> *********************************************************
> This also works fine.
>
>
>
> If I change both ALIGNMENT to other than 1, they both won't work. Could
explain the point of using GL_UNPACK_ALIGNMENT other than 1? thanks.
> --
> This post on narkive:
> http://narkive.com/GRey4bF6.3
>


0
R
9/4/2015 1:01:01 AM
yj1214,

> Or am I incorrect? Each row is 12 bytes long and it is
> divisible by 4, so shouldn't the alignment 4?

The alignment has got nothing to do with the number of elements/bytes in a
row, but everything with the size of a single element.

If your element has a size of 4 bytes the alignment is normally 4 bytes too.
Same for a size of 8 bytes.

Though sometimes an element of 2 bytes can be required to be aligned on a
4-byte boundary too.   Thats because that way those elements can than be
transferred two at a time, speeding the proces up.

Hope that clarifies it a bit.

Regards,
Rudy Wieser


-- Origional message:
yj1214 <wj7zsin4-yj1214@user.narkive.com> schreef in berichtnieuws
GRey4bF6-eecKvVlHQD0Zqk6R@narkive.com...
> I have my last question,
>
>
> If I have an array like this,
>
> int x[7] = {1, 2, 3, 4, 5, 6, 7);
>
> and the width of my pixel row is 3,
>
> glBitmap(3, etc...);
>
>
> then my alignment would be,
>
> glPixelStorei(GL_UNPACK_ALIGNMENT, 4);
>
> Or am I incorrect? Each row is 12 bytes long and it is divisible by 4, so
shouldn't the alignment 4?
>
>
> Thanks for the help, Jean-Christophe and R. wieser.
> --
> This post on narkive:
> http://narkive.com/GRey4bF6.7
>


0
R
9/4/2015 1:01:01 AM
> "yj1214" :
> It just renders weird looking characters whenever
> I use GL_UNPACK_ALIGNMENT other than 1.

Not a surprise, since your array's elements are bytes 
then the correct alignment shall be set to 1 indeed.


> I just don't really get the point of using 
> 2, 4 and 8 since 1 will always work.

Using 1 _won't_ always work if array's elements are not bytes.


> So I want an example of using 2, 4 and 8 alignment.

BYTE      array (08 bits) => 1 byte aligment.
WORD   array (16 bits) => 2 bytes aligment.
DWORD array (32 bits) => 4 bytes aligment.
QWORD array (64 bits) => 8 bytes aligment.

Please note that some others mixes
are valid too, this page may help you :
https://www.opengl.org/sdk/docs/man/html/glPixelStore.xhtml 
0
Jean
9/4/2015 1:01:01 AM
I have my last question,


If I have an array like this,

int x[7] = {1, 2, 3, 4, 5, 6, 7);

and the width of my pixel row is 3,

glBitmap(3, etc...);


then my alignment would be,

glPixelStorei(GL_UNPACK_ALIGNMENT, 4);

Or am I incorrect? Each row is 12 bytes long and it is divisible by 4, so shouldn't the alignment 4?


Thanks for the help, Jean-Christophe and R. wieser.
-- 
This post on narkive:
http://narkive.com/GRey4bF6.7

0
yj1214
9/4/2015 8:46:35 AM
R.Wieser wrote:
> The alignment has got nothing to do with the number of elements/bytes in a
> row, but everything with the size of a single element.


Now i'm little confused...


According to these posts,

StackOverflow:
http://stackoverflow.com/questions/11042027/glpixelstoreigl-unpack-alignment-1-disadvantages

OpenGL and JOGL:
http://www.felixgers.de/teaching/jogl/imageStorageMode.html

OpenGL official website:
https://www.opengl.org/discussion_boards/showthread.php/197557-What-does-glPixelStore()-do?p=1279209#post1279209



It says alignment works with row, not with elements...

From OpenGL post,

*******************************************************************************************************************************
Suppose that you have texture data with GL_RGB format (3 bytes per component) and a width of 123, with no padding between rows (i.e. the first byte of the first pixel of one row immediately follows the last byte of the last pixel of the previous row). The stride between rows will be 3*123 = 369 bytes. Note that 369 is not a multiple of 2 or 4.

If GL_UNPACK_ALIGNMENT is 4, and you try to upload the texture data with glTexImage2D(), the implementation will round the length of each row up to the next multiple of 4 (i.e. 372 bytes).
*******************************************************************************************************************************

It says alignment will round up each row's length(byte) depends on GL_UNPACK_ALIGNMENT number. It didn't say it will round up each element's length...


I think this illustrates your explanation of how alignment works,

Let's say each pixel has value of RGB. So each pixel has 3 bytes.

GL_UNPACK_ALIGNMENT, 4;

<address- 1><address- 2><address- 3><address-4><address- 5><address- 6><address- 7><address- 8>
<myPixel-R><myPixel-G><myPixel-B><alignment><nextPixel-R><nextPixel-G><nextPixel-B><alignment>


This illustrates explanation of alignment from different posts.

GL_UNPACK_ALIGNMENT, 4;

<address- 1><address- 2><address- 3><address-4><address- 5><address- 6><address- 7><address- 8>
<myPixel-R><myPixel-G><myPixel-B><nextPixel-R><nextPixel-G><nextPixel-B><alignment><alignment>


Am I not correct? i'm really confused about how alignment works...

Again thanks for the help!
-- 
This post on narkive:
http://narkive.com/GRey4bF6.10

0
yj1214
9/4/2015 6:29:51 PM
Oops my illustration was too long...

Here is better one.


<address- 1><address- 2><address- 3><address-4>
<myPixel-R><myPixel-G><myPixel-B><alignment>

<address- 5><address- 6><address- 7><address- 8>
<nextPixel-R><nextPixel-G><nextPixel-B><alignment>

Pretend they are connected.


<address- 1><address- 2><address- 3><address-4>
<myPixel-R><myPixel-G><myPixel-B><nextPixel-R>

<address- 5><address- 6><address- 7><address- 8>
<nextPixel-G><nextPixel-B><alignment><alignment>


Thanks.
-- 
This post on narkive:
http://narkive.com/GRey4bF6.11

0
yj1214
9/4/2015 6:32:45 PM
yj1214,

> Now i'm little confused...
>
> According to these posts,
[snip]

And rightly so.

What you see there is a problem where a row of elements (pixels) does not
need to be a multiple of the required alignment.   Just think of 24-bit (3
byte) pixels.   If you just put the first pixel of the second line directly
behind the last pixel of the first line it might not start on an alignment
boundary.   In such cases the video card may require (to speed up
processing) every line of pixels being started on an alignment boundary
(padding the previous line of pixels to become a multiple of the alignment).

Actually, if you take a look at the BMP file format, thats exactly how an
image is stored in it (a single line of pixels is padded to become a
multiple of the alignment, in this case 4 bytes). :-)

> I think this illustrates your explanation of how alignment works,
[Snip]
> Am I not correct? i'm really confused about how alignment works...

Well, although that wasn't exactly what I ment (I was thinking about the
alignment of a full block of data/pixels, not its individual elements), I
can imagine that a per-pixel alignment could be possible/required somewhere
too (it could speed up the provcessing).   It all depends on how the data is
used (which functions are going to use the stored data/how its provided to
the video-card).

In short, an alignment is a requirement of called functions, and below that
of the hardware under it (the video-card or other).  There is therefore no
strictly defined rule about when to use an alignment, and which alignment is
needed.

Regards,
Rudy Wieser


-- Origional message:
yj1214 <vmgxbq2b-yj1214@user.narkive.com> schreef in berichtnieuws
GRey4bF6-cBOyBtTByvUa2boH@narkive.com...
> R.Wieser wrote:
> > The alignment has got nothing to do with the number of elements/bytes in
a
> > row, but everything with the size of a single element.
>
>
> Now i'm little confused...
>
>
> According to these posts,
>
> StackOverflow:
>
http://stackoverflow.com/questions/11042027/glpixelstoreigl-unpack-alignment
-1-disadvantages
>
> OpenGL and JOGL:
> http://www.felixgers.de/teaching/jogl/imageStorageMode.html
>
> OpenGL official website:
>
https://www.opengl.org/discussion_boards/showthread.php/197557-What-does-glP
ixelStore()-do?p=1279209#post1279209
>
>
>
> It says alignment works with row, not with elements...
>
> From OpenGL post,
>
>
****************************************************************************
***************************************************
> Suppose that you have texture data with GL_RGB format (3 bytes per
component) and a width of 123, with no padding between rows (i.e. the first
byte of the first pixel of one row immediately follows the last byte of the
last pixel of the previous row). The stride between rows will be 3*123 = 369
bytes. Note that 369 is not a multiple of 2 or 4.
>
> If GL_UNPACK_ALIGNMENT is 4, and you try to upload the texture data with
glTexImage2D(), the implementation will round the length of each row up to
the next multiple of 4 (i.e. 372 bytes).
>
****************************************************************************
***************************************************
>
> It says alignment will round up each row's length(byte) depends on
GL_UNPACK_ALIGNMENT number. It didn't say it will round up each element's
length...
>
>
> I think this illustrates your explanation of how alignment works,
>
> Let's say each pixel has value of RGB. So each pixel has 3 bytes.
>
> GL_UNPACK_ALIGNMENT, 4;
>
> <address- 1><address- 2><address- 3><address-4><address- 5><address-
6><address- 7><address- 8>
>
<myPixel-R><myPixel-G><myPixel-B><alignment><nextPixel-R><nextPixel-G><nextP
ixel-B><alignment>
>
>
> This illustrates explanation of alignment from different posts.
>
> GL_UNPACK_ALIGNMENT, 4;
>
> <address- 1><address- 2><address- 3><address-4><address- 5><address-
6><address- 7><address- 8>
>
<myPixel-R><myPixel-G><myPixel-B><nextPixel-R><nextPixel-G><nextPixel-B><ali
gnment><alignment>
>
>
> Am I not correct? i'm really confused about how alignment works...
>
> Again thanks for the help!
> --
> This post on narkive:
> http://narkive.com/GRey4bF6.10
>


0
R
9/5/2015 1:01:01 AM
On Thu, 03 Sep 2015 08:03:40 +0000, yj1214 wrote:

> 1. Why can't I just always use glPixelStorei(GL_UNPACK_ALIGNMENT, 1); if
> it works every time?
> 
> Could you give me an example where I have to use GL_UNPACK_ALIGNMENT other
> than 1?

You have to use it if you have padding bytes between rows. Otherwise
OpenGL will try to read the padding bytes as the start of the following
row.

> 2. Why does OpenGL require alignment? can't it just read memory one by
> one?

It can. That's what setting GL_UNPACK_ALIGNMENT to 1 does. But if that
couldn't be changed, the application would be forced to pack rows
(without padding, even when that results in mis-aligned rows (which has a
negative impact upon performance).

0
Nobody
9/7/2015 12:34:07 AM
Nobody wrote:
> On Thu, 03 Sep 2015 08:03:40 +0000, yj1214 wrote:
> > 1. Why can't I just always use glPixelStorei(GL_UNPACK_ALIGNMENT, 1); if
> > it works every time?
> > 
> > Could you give me an example where I have to use GL_UNPACK_ALIGNMENT other
> > than 1?
> You have to use it if you have padding bytes between rows. Otherwise
> OpenGL will try to read the padding bytes as the start of the following
> row.
> > 2. Why does OpenGL require alignment? can't it just read memory one by
> > one?
> It can. That's what setting GL_UNPACK_ALIGNMENT to 1 does. But if that
> couldn't be changed, the application would be forced to pack rows
> (without padding, even when that results in mis-aligned rows (which has a
> negative impact upon performance).
....

> You have to use it if you have padding bytes between rows. Otherwise
> OpenGL will try to read the padding bytes as the start of the following
> row.

I thought alignment works with every single pixels, not every rows.


Let's say I have 7 pixels like below.

[1][2][3][4][5][6][7]

This is a single row, right?

Now let's say each single pixel is 3 bytes long. (GL_RGB for example)

and this is my alignment setting,

glPixelStorei(GL_UNPACK_ALIGNMENT, 4);


And this is what I think how alignment is done,

(this is single pixel)
[address-1][address-2][address-3][address-4]
[pixel-----R][pixel-----G][pixel-----B][  padding  ]

And this goes to every single pixels...


But if alignment works with every rows. not every pixels like my example above, how does alignment done with every rows?
-- 
This post on narkive:
http://narkive.com/GRey4bF6.14

0
yj1214
9/7/2015 1:29:14 AM
On Mon, 07 Sep 2015 01:29:14 +0000, yj1214 wrote:

> I thought alignment works with every single pixels, not every rows.

No, the pack/unpack alignment refer to the start of each row.

> But if alignment works with every rows. not every pixels like my example
> above, how does alignment done with every rows?

Suppose that you have the data for 3x3 GL_RGB texture (3 bytes per pixel).
Each row is 9 bytes long. 9 isn't a multiple of either 2 or 4.

If the unpack alignment was 2, you'd need 1 padding byte between each
row to round the row length up to 10 bytes, which is the next multiple of
2. So the bytes would be:

0   1   2   3   4   5   6   7   8   9   10  11  12  13  14
|       |       |       |       |       |       |       |
R00 G00 B00 R01 G01 B01 R02 G02 B02 pad R10 G10 B10 R11 G11...

If the unpack alignment was 4, you'd need 3 padding bytes between each
row to round the row length up to 12 bytes, which is the next multiple of
4. So the bytes would be:

0   1   2   3   4   5   6   7   8   9   10  11  12  13  14
|               |               |               |        
R00 G00 B00 R01 G01 B01 R02 G02 B02 pad pad pad R10 G10 B10 ...

If you wanted to align individual pixels, you'd just use GL_RGBA rather
than GL_RGB.

0
Nobody
9/8/2015 4:01:20 AM
Reply: