glDrawElements without indices?

Started by
15 comments, last by JohnnyCode 9 years, 9 months ago

Thanks again to both of you. It is now much more clear!

Advertisement

As I said, let the driver page in and page out memory. No game needs 2 GPU memory managers.

This, basically.

I'll add: just because you can it doesn't mean that you should. The idea is that this should never even happen. Just as you shouldn't write your own GPU memory manager, neither should the driver ever have to swap out resources. If you're over-committing video RAM you don't start thinking about swapping out resources, you do start thinking about reducing the size of your resources. So say you target a 1gb card and you find that you need 1.5gb - what you do is reduce the resolution of your textures, you reduce the polycount of your models, you think about using compressed textures or compressed vertex formats, you get everything to fit in that 1gb.

The reason why is because creating and destroying resources is expensive. Disk access is now the primary bottleneck for a lot of computing tasks. So you don't build something that has such heavy reliance on your slowest form of storage. It all adds up to runtime hitches that affect the gameplay experience.

So texture streaming never happened?

So texture streaming never happened?

Did I say that? I don't remember saying that. Maybe you'd explain to me how you managed to take what I wrote and read it as that?

Direct3D has need of instancing, but we do not. We have plenty of glVertexAttrib calls.

So texture streaming never happened?

Did I say that? I don't remember saying that. Maybe you'd explain to me how you managed to take what I wrote and read it as that?

"If you're over-committing video RAM you don't start thinking about swapping out resources, you do start thinking about reducing the size of your resources."

Texture streaming is just one counter example what you were saying.

Texture streaming is just one counter example what you were saying.

Maybe you could have said that originally?

In any event, you don't implement texture streaming by continually creating and destroying resources at runtime, and you don't implement it by swapping out entire resources from GPU memory to CPU memory at runtime either. You implement it by creating a fixed number of resources (that will fit in your target platform's available memory) and you update those resources as required (in OpenGL it would be via glTexSubimage calls). The resources to update are based on requirements of the scene, rather than of video RAM, since the video RAM allocation can be one-time-only and fixed. Yes, it's a technique to reduce video RAM requirements, but it's not the same technique that the OP is asking about and not the same technique that myself and others are saying "don't do it" to.

In the context of the OP texture streaming is a strawman. The OP is not asking about texture streaming, the OP is asking about creating and destroying resources on the fly and at runtime.

Direct3D has need of instancing, but we do not. We have plenty of glVertexAttrib calls.

"If you're over-committing video RAM you don't start thinking about swapping out resources, you do start thinking about reducing the size of your resources."

Texture streaming is just one counter example what you were saying.

It is not counter example, texture streaming alows one to minimize requirement over resources.

If you cannot create a resource, becouse of low memory or becouse of bad weather, than a memory counter to prove you you can do so will do nothing just to .. LOL, prove a retarded assumption,

You must handle refused instructions on your own responsibility, whaether it will mean you will render with one texture instead of needed 25 , or swap texture from harddrive to very gpu 25 times per frame to achieve the result. Like if you wanted to render a frame of doom 3 on a calculator.

You are rather confused on how to handle insifficient conditions of a station a program runs over, but remember, no matter what you learn, no program can overcome impossible.

but remember, no matter what you learn, no program can overcome impossible.

I would correct myself here, it can over come impossible, but you will need to consume a lot of time. And time matters in the consumer interaction experience.

You can run doom 3 instructions on a calculator, and print the frames on a paper for example. Since it is John Carmack it might have been frame per 3 minutes though. Or you could just emit frame to electromagnetic space.

This topic is closed to new replies.

Advertisement