When int is fed into opengl (say using glVertex3i) who converts to
float, CPU or GPU?  Assuming a decent/powerful GPU is used?

Thanks.

Reza.

On Sep 30, 8:41 am, RezaRob <Reza...@gmail.com> wrote:
> When int is fed into opengl (say using glVertex3i) who converts to
> float, CPU or GPU?  Assuming a decent/powerful GPU is used?
>

Quite often it's CPU - don't do it!


--
<\___/>
/ O O \
\_____/  FTB.     Remove my socks for email address.

fungus wrote:

> On Sep 30, 8:41 am, RezaRob <Reza...@gmail.com> wrote:
>> When int is fed into opengl (say using glVertex3i) who converts to
>> float, CPU or GPU?  Assuming a decent/powerful GPU is used?
>>
> 
> Quite often it's CPU - don't do it!

Well, if you do the conversion yourself, it's always the CPU.

On Sep 30, 10:19 am, Rolf Magnus <ramag...@t-online.de> wrote:
> fungus wrote:
> > On Sep 30, 8:41 am, RezaRob <Reza...@gmail.com> wrote:
> >> When int is fed into opengl (say using glVertex3i) who converts to
> >> float, CPU or GPU?  Assuming a decent/powerful GPU is used?
>
> > Quite often it's CPU - don't do it!
>
> Well, if you do the conversion yourself, it's always the CPU.

Bottom line: using the GPU's native format is always best.

On Sep 30, 9:41 am, RezaRob <Reza...@gmail.com> wrote:
> When int is fed into opengl (say using glVertex3i) who converts to
> float, CPU or GPU?  Assuming a decent/powerful GPU is used?
>
> Thanks.
>
> Reza.

In this case there is no performance difference, the two consume same
storage space. Fetcher, part of hardware which does, ummm, fetch the
data doesn't run slow or faster on different fetching modes. How much
memory and therefore bandwidth the fetching consumes is the leading
performance metric.

If the fetcher don't convert, then the transistors doing the
conversion are not doing anything. It might save a nanowatt of
power. :) :)

aku ankka wrote:

> In this case there is no performance difference, the two consume same
> storage space. Fetcher, part of hardware which does, ummm, fetch the
> data doesn't run slow or faster on different fetching modes. How much
> memory and therefore bandwidth the fetching consumes is the leading
> performance metric.
> 
> If the fetcher don't convert, then the transistors doing the
> conversion are not doing anything. It might save a nanowatt of
> power. :) :)
> 

The conversion from float to in is not free, it costs some cycled on the
CPU.

RezaRob schrieb:
> When int is fed into opengl (say using glVertex3i) who converts to
> float, CPU or GPU?  Assuming a decent/powerful GPU is used?
> 
> Thanks.

A powerful GPU should do the conversion.

Since Nvidia has lots of performance tips in their documentation, but
doesn't mention this (except that unsigned short should be used for
indices into vertex buffer objects) I suppose their GPU's can handle all
OpenGL vertex formats.

Looking at the r300 (Radeon 9500 - Radeon X850 XT) driver in Mesa it
seems the hardware supports at least float and unsigned char, there
seems to be some code for short or unsigned short as well (ATI's drivers
probably support more, the free drivers were created without documentation).

Intel doesn't support hardware tnl, so the drivers will do the
conversion to float on the CPU .

Philipp

I just looked at some ATI documentation (from their OpenGL sdk).
According to them the Radeon 9500/9600/9700/9800 supports:

1,2,3,4-component vectors of GLfloat,
2,4-component vectors of GLushort,
2,4-component vectors of GLshort,
4-component vectors of GLubyte,
4-component vectors of GLbyte

natively. They say that using other formats comes with a performance
penalty. Unfortunately there seems to be no such documentation for their
Xxxx and X1xxx cards.

Philipp

fungus wrote:

> On Sep 30, 10:19 am, Rolf Magnus <ramag...@t-online.de> wrote:
>> fungus wrote:
>> > On Sep 30, 8:41 am, RezaRob <Reza...@gmail.com> wrote:
>> >> When int is fed into opengl (say using glVertex3i) who converts to
>> >> float, CPU or GPU?  Assuming a decent/powerful GPU is used?
>>
>> > Quite often it's CPU - don't do it!
>>
>> Well, if you do the conversion yourself, it's always the CPU.
> 
> Bottom line: using the GPU's native format is always best.

My bottom line was actually: If the conversion has to be done anyway, let
the OpenGL implementation do it.

On Sep 30, 7:17 pm, My Name <n...@name.com> wrote:
> The conversion from float to in is not free, it costs some cycled on the
> CPU.

I love the smell of vague statements in the morning. You realize that
we were talking about int-to-float conversion, right?

Assuming that the fact that such instruction "costs some cycles" was
relevant, let's take a look shall we?

This was for glBegin(...), glVertex3i(...), right?

The data is copied to a buffer, which is then transfered to the
graphics processor so that it can use the data. So we must understand
that the data is read and written from local memory anyway. Best
practise would be that the glVertex3i() directly writes the data to
the buffer which is going to be transfered, still with me?

Instructions are going to be used to do that, agree?

void glVertex3i(GLint x, GLint y, GLint z)
{
  // WTF!?
}

What would you put in there..? Now you have to consider your
architecture for the Graphics Processor. There are many ways to skin
this cat. If the GPU has low-latency access to system memory a
dedicated fetch-conversion unit is a good idea. It can fetch-and-
convert the data straight from local memory. This is not practical
when the connection is something like PCI, PCI Express or such. I
assume we are discussing OpenGL on such system that GPU is being a
such bus (not OCP or similar used in integrated systems).

So transfering a block of memory at once is the way to go.

Pseudo-code would be then:

void glVertex3i(GLint x, GLint y, GLint z)
{
  GLfloat* ptr =
acquire_address_for_current_render_context(...blablaa..., 3);
  ptr[0] = x;
  ptr[1] = y;
  ptr[2] = z;
}

The "3" above says that we want to write 3 float's into the datastream
for gl_Position attribute. Note that interleaved layout would be more
efficient for transfering and using the data, so we might have some
stride there instead of immediate offsets.

We convert up to float here because glBegin() / glEnd() calls can use
ANY data types:

glBegin(GL_TRIANGLES);
glVertex3f(...);
glVertex2i(0, 1);
glVertex4s(0, 1, 0, 1);
....

It would be insanely inpractical to issue the format into the
datastream and parse it on the GPU, when we can simply promote all
data to float and be done with it. Downside is that we consume more
bandwidth when the data is only 8 or 16 bits per component. This is
something that we just have to live with immediate mode. It sucks
goats balls. Literally. If you are using it don't cry about low
performance, you already fucked up and threw the chances of high
performance out of the window. Display Lists correct the situation but
then the overhead doesn't matter now does it, as it is done only when
the list is being constructed so the point is again moot one.

OK, so we got a line of code like this:

ptr[0] = x;

What instructions you think might go in there? Apparently we are doing
conversion from GLint to GLfloat, we might or might not be using SSE.
Let's look at vanilla x87.

FILD, FSTP

What's the non-converting alternative?

MOV, MOV

How is that any better in practise? The expensive part here is writing
to the destination array, reading from the stack is cheap. Writing
into the destination array isn't particularly expensive either as the
instruction won't stall, and that address isn't read from any time
soon; the write will be issued much sooner than the read request will
ever come to that address.

Where's the "cost" !??! We must read and write to these memory
locations anyway.. doesn't really matter if it is FILD or MOV does it?
And we're still didn't even consider SSE which only increases
optimization opportunities.

If the performance is a problem, consider seriously moving to
programming model where the data can be cached in the GPU's local
memory. Immediate mode and performance in the same discussion is a
joke.

aku ankka wrote:
> On Sep 30, 7:17 pm, My Name <n...@name.com> wrote:
>> The conversion from float to in is not free, it costs some cycled on the
>> CPU.
> 
> I love the smell of vague statements in the morning. You realize that
> we were talking about int-to-float conversion, right?

And i like people who talk many but have nothing to say. Read my posting
again...

Ah...and by the way, conversion from int to float does also takes some
cycles. In this case, it has nothing to do with GPU, OpenGL or any
graphics card, it is just simple C.

The arguments of the glVertex3i functions are "called by value", so you
*need* a conversion. And a conversion does take time, because an integer
has an another binary format as a float.

Get it?

On Oct 1, 5:04 pm, My Name <n...@name.com> wrote:
> Ah...and by the way, conversion from int to float does also takes some
> cycles. In this case, it has nothing to do with GPU, OpenGL or any
> graphics card, it is just simple C.
>
> The arguments of the glVertex3i functions are "called by value", so you
> *need* a conversion. And a conversion does take time, because an integer
> has an another binary format as a float.
>
> Get it?

I don't think *YOU* get it, OpenGL in Windows for example uses stack
calling convention. The arguments are read off the stack in
glVertex3i. mov and fild take roughly the same amount of time to issue
as mov, fld or other instruction you might deploy for the task.

"mov" instruction for example takes time to issue. Reading the values
off the stack and placing them into location in memory where the
graphics processor can read the values takes roughly the same time, so
the "conversion" doesn't really "cost" any extra.

The biggest overhead here is any possible stall or latency from the
memory read request and write issue. Note that the arguments are in
stack, which has a high chance to reside in the high in the memory
cache hierarchy.

Get it?

Prove otherwise, please; I'm getting weary of your vague statements.
And please, don't quote some ancient 386/486 clock cycle charts, they
are meaningless on modern architectures.

aku ankka wrote:

> I don't think *YOU* get it, OpenGL in Windows for example uses stack
> calling convention.  The arguments are read off the stack in
> glVertex3i. mov and fild take roughly the same amount of time to issue
> as mov, fld or other instruction you might deploy for the task.
> "mov" instruction for example takes time to issue. Reading the values
> off the stack and placing them into location in memory where the
> graphics processor can read the values takes roughly the same time, so
> the "conversion" doesn't really "cost" any extra.
> The biggest overhead here is any possible stall or latency from the
> memory read request and write issue. Note that the arguments are in
> stack, which has a high chance to reside in the high in the memory
> cache hierarchy.
> 

Hey, please tell me something new about programming!

> 
> Prove otherwise, please; I'm getting weary of your vague statements.
> And please, don't quote some ancient 386/486 clock cycle charts, they
> are meaningless on modern architectures.
> 


Do you have ever shown a disassembly from you compiler?

Float-Array:
00401000  fld         dword ptr [ii+8 (403020h)]
00401006  call        _ftol2_sse (401810h)
0040100B  fld         dword ptr [ii+4 (40301Ch)]
00401011  push        eax
00401012  call        _ftol2_sse (401810h)
00401017  fld         dword ptr [ii (403018h)]
0040101D  push        eax
0040101E  call        _ftol2_sse (401810h)
00401023  push        eax
00401024  call        dword ptr [__imp__glVertex3i@12 (4020A4h)]

Int-Array:
00401000  mov         eax,dword ptr [ii+8 (403020h)]
00401005  mov         ecx,dword ptr [ii+4 (40301Ch)]
0040100B  mov         edx,dword ptr [ii (403018h)]
00401011  push        eax
00401012  push        ecx
00401013  push        edx
00401014  call        dword ptr [__imp__glVertex3i@12 (4020A4h)]

Visual Studio C++ 2005 Express Edition, Release Build, Full Optimization.

You see, i dont need any "antiquated" cycle chart for my vague
statements. Do you need more help on this topic?

> Float-Array:
> 00401000  fld         dword ptr [ii+8 (403020h)]
> 00401006  call        _ftol2_sse (401810h)
> 0040100B  fld         dword ptr [ii+4 (40301Ch)]
> 00401011  push        eax
> 00401012  call        _ftol2_sse (401810h)
> 00401017  fld         dword ptr [ii (403018h)]
> 0040101D  push        eax
> 0040101E  call        _ftol2_sse (401810h)
> 00401023  push        eax
> 00401024  call        dword ptr [__imp__glVertex3i@12 (4020A4h)]
>
> Int-Array:
> 00401000  mov         eax,dword ptr [ii+8 (403020h)]
> 00401005  mov         ecx,dword ptr [ii+4 (40301Ch)]
> 0040100B  mov         edx,dword ptr [ii (403018h)]
> 00401011  push        eax
> 00401012  push        ecx
> 00401013  push        edx
> 00401014  call        dword ptr [__imp__glVertex3i@12 (4020A4h)]

Well, you're using glVertex3i to pass three floats to OpenGL, which isn't  
appropriate. You should rather use glVertex3f for a realistic comparison,  
in which case aku ankkas argumentation holds (imho).

HTH

"My Name" <name@name.com> wrote in message news:fdoi75$okr$1@online.de...
> aku ankka wrote:
>
>> In this case there is no performance difference, the two consume same
>> storage space. Fetcher, part of hardware which does, ummm, fetch the
>> data doesn't run slow or faster on different fetching modes. How much
>> memory and therefore bandwidth the fetching consumes is the leading
>> performance metric.
>>
>> If the fetcher don't convert, then the transistors doing the
>> conversion are not doing anything. It might save a nanowatt of
>> power. :) :)
>>
>
> The conversion from float to in is not free, it costs some cycled on the
> CPU.

Yikes, you all are missing the scaling issue. While a Vertexi and VertexF 
are in the same range, color and normals are NOT and need to be re-scaled. I 
love to use, for example, short or smaller normals in some cases as it saves 
a huge amount of space. But, if the card doesn't take em as native (old ATI 
FIREGL for instance), well .... This argument extends to buffers as well as 
immediate mode calls.

As far as vertices go, I'd always use the most "natural" for your dataset, 
and use scaling matrices (and hopefully a GPU) and never, ever scale the 
data yourself. A regular grid with integer heights for example -- definitely 
use an integral type for XYZ.

jbw 

On Oct 1, 10:16 pm, My Name <n...@name.com> wrote:
> > Prove otherwise, please; I'm getting weary of your vague statements.
> > And please, don't quote some ancient 386/486 clock cycle charts, they
> > are meaningless on modern architectures.
>
> Do you have ever shown a disassembly from you compiler?

/Fa. Nuff sez.


> Float-Array:
> 00401000  fld         dword ptr [ii+8 (403020h)]
> 00401006  call        _ftol2_sse (401810h)

ftol, that's like float-to-int conversion.. where do we need float-to-
int conversion in glVertex3i ? At best, we need int-to-float
conversion and that is completely different beast, allow me to educate
you. Read on.

The need for expensive ftol is because the C compiler must preserve
the rounding mode and enable the rounding mode specified in the C
standard temporarily, then restore the current rounding mode. This is
expensive, sure, but it has ZIP, ZILCH, NADA, NOTHING, EI MIT=C4=C4N,
etc.etc. to do with the topic at hand: int-to-float conversion, if
even that.

All we know, the GPU does have fetch-convert unit that does it for
free so we can store the values as 32-bit signed integer in the GPU's
local memory after pulling the data from the system memory, or doing
the conversion-on-fetch if the architecture (integrated graphics cores
can do that easily for example) makes it practical.

There is no rounding mode in int-to-float conversion. 32 bit ieee-754
floating-point can present any 32 bit signed integer value precisely.
The conversion to this direction is dirt cheap. Get your facts
straight, please.

Also, you don't have to use static_cast<int> or (int) casting for
float-to-int casting when you are doing float-to-int conversion. If
you know your compiler and architecture, you know that invokes
overhead. You can use a custom written float-to-int conversion
routine, use intrinsic like _mm_cvtps_epi32 or invoke fistp or similar
directly. You can also extract the integer value for specific ranges
directly from mantissa bits and on and on. There is a lot of knowledge
to work around the C typecasting overhead on x86. I'm sorry if you are
fully aware of the topic you are arguing about.


> Visual Studio C++ 2005 Express Edition, Release Build, Full Optimization.

You should have shown the C/C++ source code that was compiled so that
it would have been more obvious that what you were doing was the wrong
thing. glVertex3i very clearly indicates integer input, how you get
float-to-int conversion in there, you must have made a mistake
somewhere. :)


> You see, i dont need any "antiquated" cycle chart for my vague
> statements. Do you need more help on this topic?

If you are trolling, you really need to learn more about the topic to
do that effectively; it's kind of sad if the troll knows less than the
so-called 'victim' of his.

On Oct 2, 4:36 am, "jbwest" <jbw...@comcast.net> wrote:
> Yikes, you all are missing the scaling issue. While a Vertexi and VertexF
> are in the same range, color and normals are NOT and need to be re-scaled. I
> love to use, for example, short or smaller normals in some cases as it saves
> a huge amount of space. But, if the card doesn't take em as native (old ATI
> FIREGL for instance), well .... This argument extends to buffers as well as
> immediate mode calls.

No, we're not actually: the glVertex3i isn't normalized.


> As far as vertices go, I'd always use the most "natural" for your dataset,
> and use scaling matrices (and hopefully a GPU) and never, ever scale the
> data yourself. A regular grid with integer heights for example -- definitely
> use an integral type for XYZ.

Smaller the data the better, because it reduces the bandwidth usage.
Using client-side arrays is not adviced: using them invokes extra
copying of the data. Reason: concurrency. More specificly, the OGL
drawing command cannot return until the client side data is fully
read, otherwise the client application could modify the data which
would be error.

The GPU works asynchronously with the host CPU, so, if we allow the
GPU to directly pull the data from the client array we must poll the
GPU from the CPU until the appropriate draw command is processed and
then return to the caller. This would take insane amounts of CPU time,
so the data is instead copied to memory location which is then freed
when the GPU has completed using the data. The freeing signal could be
interrupt for example. The CPU "knows" the order commands are issued
so the same interrupt could be used for signaling for all feedback
events from the GPU.

So, in short, if client side arrays are bad then it follows that
similarly using immediate mode is bad. It is worse since it basically
invokes overhead of constructing a temporary client side array.

If the OGL implementation has VBO rendering back-end, it would make
sense to use temporary VBO's for immediate mode and client-side array
rendering. So naturally it follows that using VBO directly from client
application would make a lot of sense.

Furthermore, usually client applications have a very poor vertex
layout even if interleaved, the hardware and driver might re-negotiate
a better layout and copy the data anyway for more efficient fetching.
Internally, the GPU's still have a bus and memory traffic going on
from place A to place B. Burst transfers are common, so it is
advantage if vertex fits into as few blocks as possible, so packing
the data is advantage. Sometimes. ;)

If the unpacking requires extra ALU operations it might turn into
disadvantage, it depends on how much bandwidth is used and how much is
available, and same with how many ALU's are being used and where the
bottlenecks are. Larger vertices also mean there are less available
slots in the vertex cache (implementations vary, but usually every
byte of fast local on-chip memory consumes gates and that means makes
the chip larger so the amount is limited in one way or other).

The thing is, the client application simply cannot KNOW all these
details, and it should not, so conclusion is that use the type that
best gets the job done. Smaller the better. If the backend only uses
floats, for example, you can be fairly sure that the implementation
has unpacking logic that isn't too much overhead to deploy, otherwise
the implementation wouldn't be competitive.

Dorian Weber wrote:
> Well, you're using glVertex3i to pass three floats to OpenGL, which
> isn't appropriate. You should rather use glVertex3f for a realistic
> comparison, in which case aku ankkas argumentation holds (imho).
> 

But the question was:

"When int is fed into opengl (say using glVertex3i) who converts to
float, CPU or GPU?  Assuming a decent/powerful GPU is used?"

Ok?

aku ankka wrote:

> You should have shown the C/C++ source code that was compiled so that
> it would have been more obvious that what you were doing was the wrong
> thing. glVertex3i very clearly indicates integer input, how you get
> float-to-int conversion in there, you must have made a mistake
> somewhere. :)

Maybe it is time you prove you argumentation with some code.

> If you are trolling, you really need to learn more about the topic to
> do that effectively; it's kind of sad if the troll knows less than the
> so-called 'victim' of his.

Hmm, at the moment i think i know more than you...

My Name wrote:

> "When int is fed into opengl (say using glVertex3i) who
> converts to float, CPU or GPU?  Assuming a decent/powerful GPU
> is used?" 

In immediate mode: Probably the CPU:

glBegin(...)
glVertex3d(...);
glVertex3f(...);
glVertex3i(...);
glVertex3s(...);
glEnd();

You see, in immediate mode you can freely mix the avaliable
variants, so the data sent to the GPU must be the smallest
common denominator. Most GPUs can't deal with double precision
floats for vertices, so everything ends up in a buffer of
floats, which is then sent to the GPU.

BTW: The depictions of the guessworked code of glVertex was so
utterly wrong. I've only seen vertex coordinates copied into a
buffer. However glVertex actually only triggers the copy process
of several "global" (well actually OpenGL context local)
variables to the buffer - OpenGL is a state machine. Technically
a call to glVertex could be rewritten (if those functions would
exist) into

glVertex(...) =^= glPosition(...), glYieldVertex();

All the code I've seen so far miss this point, i.e. the fact,
that you can freely mix glVertex call variants in immediate
mode, but the driver simply can't know in advantage, which
variants will be actually called. So the allocated buffer will
become the smallest common denominator the used GPU can deal
with, which is in most cases single precision float. And since
the buffer must be filled by the CPU the conversion will happen
on the CPU.

The big difference are vertex arrays: Here the divers knows
exactly, of what type all the data is, and can thus set the
appropriate fetch conversion unit of the GPU, if the GPU got one
of these, and I bet they have. However on the developer sites of
NVidia and ATI you can find precise tables, which data formats
bring the best performance, so the conversion on the GPU doesn't
come without some cost, and on some GPUs it's a serious
performance hit.

Wolfgang Draxinger
-- 
E-Mail address works, Jabber: hexarith@jabber.org, ICQ: 134682867

On Oct 2, 1:54 pm, My Name <n...@name.com> wrote:
> Maybe it is time you prove you argumentation with some code.

Post some code, check (hint: yesterday).


> Hmm, at the moment i think i know more than you...

You just keeping it to yourself...

On Oct 2, 2:13 pm, Wolfgang Draxinger <wdraxin...@darkstargames.de>
wrote:
> The big difference are vertex arrays: Here the divers knows
> exactly, of what type all the data is, and can thus set the
> appropriate fetch conversion unit of the GPU, if the GPU got one
> of these, and I bet they have. However on the developer sites of
> NVidia and ATI you can find precise tables, which data formats
> bring the best performance, so the conversion on the GPU doesn't
> come without some cost, and on some GPUs it's a serious
> performance hit.

Pretty good evaluation. The cost is only magnified when using
programmable hardware, when the data is read from a memory location it
needs to be converted. The configuration of the conversion could mean
that the microcode needs different encoding, so the code must be at
least patched to provide the correct configuration depending on the
arrays that are bind to the current rendering context.

In other words the generated microcode could potentially be dependent
on the input data. One way to reduce this dependency is to have
separate fetch logic to pull the data into internal memory layout that
is fixed when the microcode is generated.

The hardware isn't designed in a vacuum and there is already few years
of existing practice so in that regard the client shouldn't be too
worried. There might be some corner cases that are not handled very
efficiently and the lessons learned have been carried into the next
generation products, including the OpenGL itself as the OpenGL 3 has
abandoned the immediate mode and client side arrays in favor of the
new object model.

On Oct 1, 4:27 pm, My Name <n...@name.com> wrote:
> aku ankka wrote:
> > On Sep 30, 7:17 pm, My Name <n...@name.com> wrote:
> >> The conversion from float to in is not free, it costs some cycled on the
> >> CPU.
>
> > I love the smell of vague statements in the morning. You realize that
> > we were talking about int-to-float conversion, right?
>
> And i like people who talk many but have nothing to say. Read my posting
> again...

You wrote, quote: "The conversion from float to in is not free, it
costs some cycled on the
CPU. "

You rant how the float-to-int conversion isn't free, so what if it
isn't used?

For your information, "I talk many", because what I write is based on
all that "many informations", not fabricated on the spot.

>From my point of view, the statement I quoted was completely
irrelevant; state clearly where that conversion is needed in
glVertex3i, please.