dear all,

I have to render very large static point sets (20M points with color 
attributes). I have to use VBOs for performance reasons - but it seems 
like I cannot load a too large point set at once (my graphics car is a 
quadroFX 2800M).

should I break down the point set into smaller buffers?

do you recommend any tutorial / advice on this topic?

any help would be much appreciate,

pierre

On Sep 11, 8:54=A0am, Pierre Alliez <pierre.all...@sophia.inria.fr>
wrote:
> dear all,
>
> I have to render very large static point sets (20M points with color
> attributes). I have to use VBOs for performance reasons - but it seems
> like I cannot load a too large point set at once (my graphics car is a
> quadroFX 2800M).
>
> should I break down the point set into smaller buffers?
>

Yes.

Large buffers don't increase performance *at all* (in
fact they drag the whole machine's multitasking ability
down because the graphics card can't do anything else
until the buffer finishes rendering).

You can get full performance from buffers with 500
vertices or less and if you're using indices you
should *definitely* use 16-bit index values.

> Large buffers don't increase performance *at all* (in
> fact they drag the whole machine's multitasking ability
> down because the graphics card can't do anything else
> until the buffer finishes rendering).
>
> You can get full performance from buffers with 500
> vertices or less and if you're using indices you
> should *definitely* use 16-bit index values.

Thank you. I will try this today (several VBO's with 500 vertices -
although this will be many with my 20M points!).
I am not using any indices as I want to render just the points in
point mode.

best,

Pierre

On Sun, 12 Sep 2010 23:54:58 -0700, pierre wrote:

>> Large buffers don't increase performance *at all* (in
>> fact they drag the whole machine's multitasking ability
>> down because the graphics card can't do anything else
>> until the buffer finishes rendering).
>>
>> You can get full performance from buffers with 500
>> vertices or less and if you're using indices you
>> should *definitely* use 16-bit index values.
> 
> Thank you. I will try this today (several VBO's with 500 vertices -
> although this will be many with my 20M points!).

There shouldn't be a need to split the vertices across multiple VBOs; just
don't render the entire array in one go, but render e.g. 500 points per
glDrawArrays() call.

On Sep 13, 2:25=A0pm, Nobody <nob...@nowhere.com> wrote:
>
> There shouldn't be a need to split the vertices across multiple VBOs; jus=
t
> don't render the entire array in one go, but render e.g. 500 points per
> glDrawArrays() call.

OTOH if it doesn't all fit on the graphics
card then the driver's going to have to do
gymnastics to make it work.

None of the most popular video chips can
handle more than 65534 vertices in one go.
If you make bigger arrays it forces the
driver to do internal gymnastics.

(Yes, I said 65534 not 65536...)

On Mon, 13 Sep 2010 06:16:15 -0700, fungus wrote:

>> There shouldn't be a need to split the vertices across multiple VBOs; just
>> don't render the entire array in one go, but render e.g. 500 points per
>> glDrawArrays() call.
> 
> OTOH if it doesn't all fit on the graphics
> card then the driver's going to have to do
> gymnastics to make it work.
> 
> None of the most popular video chips can
> handle more than 65534 vertices in one go.
> If you make bigger arrays it forces the
> driver to do internal gymnastics.
> 
> (Yes, I said 65534 not 65536...)

There doesn't appear to be a query for the maximum (sane) size of a VBO.
There is a query for the recommended maximum number of vertices in a
single call, i.e. GL_MAX_ELEMENTS_VERTICES, but that's not the same thing.

20 million vertices in one buffer isn't necessarily a problem based upon
RAM alone (20 million vertices with 3 x 16-bit components would only need
120MB). If specific hardware imposes additional constraints, I don't know
how to query that.

On Sep 14, 11:17=A0am, Nobody <nob...@nowhere.com> wrote:
>
> 20 million vertices in one buffer isn't necessarily a problem

No...but it *might* be.

You gain nothing and you could lose a lot. Why do it?

> If specific hardware imposes additional constraints, I don't know
> how to query that.

There's no way in OpenGL AFAIK, OpenGL is supposed to
"just work", ie. the driver is supposed to do whatever's
needed to make it work. eg. It might make a second copy
of your massive array and split it up internally (using
double RAM).

In Direct3D you have to query every capability and the
driver is allowed to fail if you go over the limits.
Looking at the database for Direct3D cards can give
a lot of insight into OpenGL optimization. Many chips
can't do 32-bit indices and have limits on vertex buffer
sizes.

fungus wrote:
> On Sep 13, 2:25 pm, Nobody <nob...@nowhere.com> wrote:
>> There shouldn't be a need to split the vertices across multiple VBOs; just
>> don't render the entire array in one go, but render e.g. 500 points per
>> glDrawArrays() call.
> 
> OTOH if it doesn't all fit on the graphics
> card then the driver's going to have to do
> gymnastics to make it work.
> 
> None of the most popular video chips can
> handle more than 65534 vertices in one go.
> If you make bigger arrays it forces the
> driver to do internal gymnastics.

The solution is to split arrays, and render separately? Or just render 
big array in several passes?
Or completely avoid using arrays bigger then 64k vertices?

> 
> (Yes, I said 65534 not 65536...)
> 

What happens to 2 vertices?

On Sep 15, 4:32=A0pm, Vladimir Jovic <vladasp...@gmail.com> wrote:
>
> The solution is to split arrays, and render separately?

Yes.

>
> > 65534...
>
> What happens to 2 vertices?

I think it's only for index mode, and index
0xffff is reserved for something internal.

Maybe the chips can do 65536 vertices if
you're not using indexing but there's not
really any point risking it. It won't be
faster or easier to program than smaller ones.

> 20 million vertices in one buffer isn't necessarily a problem based upon
> RAM alone (20 million vertices with 3 x 16-bit components would only need
> 120MB). If specific hardware imposes additional constraints, I don't know
> how to query that.

16bit float types? cool - I have seen this type here
http://www.opengl.org/registry/specs/NV/half_float.txt
and will try this.

On Sep 17, 2:40=A0pm, Pierre Alliez <pierre.all...@sophia.inria.fr>
wrote:
>
> 16bit float types? cool - I have seen this type here
> http://www.opengl.org/registry/specs/NV/half_float.txt
> and will try this.

Not many graphics cards support that extension.

I'd only use it if you're in control of what
machines and graphics cards will be used to run
your program.

On Fri, 17 Sep 2010 14:40:26 +0200, Pierre Alliez wrote:

>> 20 million vertices in one buffer isn't necessarily a problem based upon
>> RAM alone (20 million vertices with 3 x 16-bit components would only need
>> 120MB). If specific hardware imposes additional constraints, I don't know
>> how to query that.
> 
> 16bit float types? cool

I didn't say anything about floating-point; I was thinking of
fixed point (i.e. normalized integers).

If you know the bounds of the data, there's no reason to waste space on an
exponent. You're usually better off quantising the range into 2^N equal
steps than having reduced worst-case precision just so that values which
are close to zero can have increased precision.

"Nobody" <nobody@nowhere.com> wrote in message 
news:pan.2010.09.18.06.04.48.828000@nowhere.com...
> On Fri, 17 Sep 2010 14:40:26 +0200, Pierre Alliez wrote:
>
>>> 20 million vertices in one buffer isn't necessarily a problem based upon
>>> RAM alone (20 million vertices with 3 x 16-bit components would only 
>>> need
>>> 120MB). If specific hardware imposes additional constraints, I don't 
>>> know
>>> how to query that.
>>
>> 16bit float types? cool
>
> I didn't say anything about floating-point; I was thinking of
> fixed point (i.e. normalized integers).
>
> If you know the bounds of the data, there's no reason to waste space on an
> exponent. You're usually better off quantising the range into 2^N equal
> steps than having reduced worst-case precision just so that values which
> are close to zero can have increased precision.
>


That's usually a waste of time; it's usually floating point (or less) 
internally anyway.

jbw

Pierre Alliez wrote:
> dear all,
> 
> I have to render very large static point sets (20M points with color 
> attributes). I have to use VBOs for performance reasons - but it seems 
> like I cannot load a too large point set at once (my graphics car is a 
> quadroFX 2800M).
> 
> should I break down the point set into smaller buffers?


Hi Pierre!!
Nice to see you on usenet!

I manage to render VBOs containing between 1 and 2 million 
vertices (+tangents+normals+index buffer) on a quite old 
GeForce (serie 8), using a unique VBO, for hair rendering. 
If I remmember well, I could manage to render more, and had 
decent framerates.

I just checked the code, there is nothing in particular in 
the code to handle large datasets - just standard calls to
glBindBufferARB, glBufferDataARB/glBufferSubDataARB, 
glVertexPointer, and the draw call that I used (with lines):
glDrawElements(GL_LINES, nbVertices, GL_UNSIGNED_INT, 0);

Just make sure to store your index buffer as an array of 
unsigned int (and not char) !

Cheers


-- 
Nicolas Bonneel
http://cs.ubc.ca/~nbonneel/