I heard some very disappointing news about ATI while attending SIGGRAPH. It looks like ATI aren’t taking OpenGL 2.1 seriously and wont support PBOs even if it’s an integral part of the specification.
What’s so hard about giving us a way to access a buffer’s memory?? Why is it so different than a VBO?
This SUCKS!
I agree. This needs to work IMO. There are a lot of great things that this enables developers to do. I would assume there is a valid technical reason for their decision, however.
I went to a talk regarding a custom API they’re working on to allow GPGPU stuff to be done easier. During that talk, they said the card has the ability to read and write system memory across the PCIx bus. Perhaps there is a reason that this can’t be exposed via PBOs?
Anyways, it really seems ATI is no longer interested in being the leader in graphics technology. The X800 series being shader model 2.0, and offering little technical innovation… just a faster Radeon 9700. Not to mention their current offerings being faster at branching, and allowing R2VB, but really, this is less useful than vertex texture support as it means no lookup tables in vertex shaders without rendering to a vertex buffer first… not to mention that we still don’t have access to R2VB in OpenGL anyways.
Kevin B
Originally posted by ebray99:
Anyways, it really seems ATI is no longer interested in being the leader in graphics technology.
No i do think they want to be the leader in graphics technology, but just in another way, they want to be the fastest out there, and raw speed is relatively easy if you strip some the cards functionality.
NVIDIA is almost the other way around, they want to be way ahead of the game when it comes to features while still maintaining most of the speed.
That is why ATI often beats NVIDIA in 2nd gen game engines like source(HL2) while NVIDIA owns third gen game engines like doom 3 and so on.
What’s the point of performance if you can’t actually do things with it? Imagine if we still had 2 texture combiners with today’s cards. You’d have Quake 3 like graphics at 1000 fps. That would be kind of pointless, IMO. It seems to me that they’re skipping on features to be cheap (hopefully I’m just misinterpreting things?). Also, why don’t we have access to R2VB in OpenGL? It’s been about a year now.
Kevin B
Maybe it’s just me, but it seems ATI rather wants to wait a bit in order to get features right, while nVidia wants to support every feature as fast as possible no matter the consequences.
At least to me nVidia hardware always seems like “wow, look, all these features”, but when you look at what can actually be used and what can’t because of poor performance or artificial limitations it’s another story.
Ok, ATI takes a bit longer to introduce features. But the advantage is that they really support the feature, while nVidia often tends to “bend” the spec a bit in order to be able to get support out fast and for older cards.
I’m not saying the nVidia policy is bad. As a developer I also prefer to get my hands on the latest features as soon as possible, no matter how bad the performance is.
PBO has been around for quite a while now, why hasn’t ATI done anything about it? I thought they were the driving force behind uber buffers at one point, which seems to have a lot in common…if they can’t implement PBO, what were they going to do if uber buffers actually became a reality? It seems like an obvious extension to have, but it isn’t very useful without an ATI implementation.
Also, what about floating point blending, floating point mipmaps, and vertex texture fetch? Antialiased float-16 buffers are nice, but it seems like a poor compromise.
What’s so hard about giving us a way to access a buffer’s memory?? Why is it so different than a VBO?
You seem to misunderstand what PBO’s are.
PBO’s are buffer objects you can use for pixel transfer operations: CopyTex, Copy framebuffer, etc. Of course, you can use a buffer object for anything you choose, like after the texture copy is complete, you bind it as a position vertex array. And so forth.
The idea being to allow render-to-texture-to-vertex-array to happen without touching main system memory.
As to why ATi hardware wouldn’t support this… there’s plenty of reasons. In order to do what is being asked with a copy-from-texture-to-vertex-array operation, without hitting the CPU or main memory, you need explicit hardware support. You need some piece of hardware that can do the memory copy, potentially unswizzling the texture as well as decoding its format.
I imagine ATi will actually have a GL 2.1 implementation, but they will do the copy on the CPU as a CopyTex to memory followed by a buffer-object upload command. Far from asyncronous, and painful for the CPU. But if they don’t have that piece of hardware, they can’t perform the operation.
Originally posted by flamz:
What’s so hard about giving us a way to access a buffer’s memory?? Why is it so different than a VBO?
The VBO extension is very very similar to another ATI extension the Vertex Array Object(VAO). So they had almost nothing to do to support this extension. They have nothing similar to PBO in their current driver, so that’s why I suppose they didn’t implement it.
Why can’t they implement PBOs as rendering from a texture to a vertex buffer for the “copy”? Probably not the most straightforward thing in the world, but they do have this ability in their X1xxx cards.
Kevin B.
Originally posted by AlexN:
Also, what about floating point blending, floating point mipmaps, and vertex texture fetch? Antialiased float-16 buffers are nice, but it seems like a poor compromise.
Texture filtering in 16 bits float or vertex texture fetch are not supported in D3D. So I suppose they are not supported by their latest GPU. However Antialiased float-16 buffers are supported in D3D, and we still don’t have any support in OpenGL.
That is why ATI often beats NVIDIA in 2nd gen game engines like source(HL2) while NVIDIA owns third gen game engines like doom 3 and so on.
I think you have your engine generations backwards. Doom 3 is a weak engine compared to HL2.
And the real reason why nVidia hardware runs fast on Doom 3 is because it does things nVidia hardware likes (or, more accurately perhaps, nVidia made their hardware fast at what the Doom 3 engine does). ATi’s hardware is more agnostic when it comes to the performance of various features, so it doesn’t favor or disfavor certain applications.
Also, what about floating point blending, floating point mipmaps, and vertex texture fetch?
I imagine that the X-Box 360 has some of these, though that doesn’t help us
In any case, ATi likes implementing features the right way. For example, in the aforementioned 360 hardware, the same processors that operate on vertices operate on fragments; that’s why it has vertex texturing that is virtually identical to fragment texturing.
nVidia, on the other hand, will be perfectly content with having two different kinds of texture units, one for vertices and one for fragments. A waste of transistors to be sure, but at least the feature is there.
Why can’t they implement PBOs as rendering from a texture to a vertex buffer for the “copy”?
Because a buffer object has a very specific memory format. And a render buffer may also have a very specific memory format. The two of them may well not be the same format. Indeed, I imagine that they aren’t.
Buffers tend to be row-aligned to specific alignments. Buffer objects are linear in memory. You can’t render from one to the other unless the buffer is the correct size. And there’s no way for the user to know what the “correct” size is.
However Antialiased float-16 buffers are supported in D3D, and we still don’t have any support in OpenGL.
That’s because neither ATi nor nVidia as of yet supports the FBO extensions for framebuffer blitting and multisample framebuffers. Once these are supported, you should have such things available. Where the hardware can handle these and floating point framebuffers, of course.
Doom 3 is a weak engine compared to HL2.
No, I think you have your engine generations backwards. HL2 has a lot of static lighting. Doom3 is fully dynamic lighting on everything, and amounts to a direct illumination simulation. While HL2 has a lot of precomputed radiosity stuff, it doesn’t even come close to doing what Doom3 can do. For instance, HL2 limits one shadow per caster, Doom3 allows any number of lights (all lights are dynamic… nothing precomputed), any number of casters. Either way, Doom3 is a signifigant step in the right direction, while HL2 is essentially just extending lightmaps.
Kevin B
I imagine ATi will actually have a GL 2.1 implementation, but they will do the copy on the CPU as a CopyTex to memory followed by a buffer-object upload command.
But …this is what we have to do to bypass the lack of PBO today!!! I guess I can send them my code then… full of comments, just in case they dont get it.
:mad:
Originally posted by ebray99:
[b] [quote]Doom 3 is a weak engine compared to HL2.
No, I think you have your engine generations backwards. HL2 has a lot of static lighting. Doom3 is fully dynamic lighting on everything, and amounts to a direct illumination simulation. While HL2 has a lot of precomputed radiosity stuff, it doesn’t even come close to doing what Doom3 can do. For instance, HL2 limits one shadow per caster, Doom3 allows any number of lights (all lights are dynamic… nothing precomputed), any number of casters. Either way, Doom3 is a signifigant step in the right direction, while HL2 is essentially just extending lightmaps.
Kevin B [/b][/QUOTE]Exactly, quake started the 2:nd generation and HL2 ended it, it’s basically as much you can to with it without crossing over to third gen.
Doom 3 is to third gen as what quake was to the second generation, it’s only the beginning (just look at unreal 3).
Now because third gen do use a lot more polygons, shaders and other things, so naturally there is going to be some overlap.
[quote]However Antialiased float-16 buffers are supported in D3D, and we still don’t have any support in OpenGL.
That’s because neither ATi nor nVidia as of yet supports the FBO extensions for framebuffer blitting and multisample framebuffers. Once these are supported, you should have such things available. Where the hardware can handle these and floating point framebuffers, of course. [/QB][/QUOTE]The EXT extension has been completed for a long time now and still nothing. If the extension is really the problem they can just implement it in the PBuffer. 16 bits float is already supported by the PBuffer, MSAA too, why not both together.
We cannot wait for NVidia to support this feature. Nvidia doesn’t care about 16 bits float and MSAA since their GPU doesnt support it, but ATI should care about it.
HL2 has a lot of static lighting.
Oh, God forbid you use static lighting… :rolleyes:
HL2 looks better than D3. That’s the only standard that matters.
Plus, it has a much better shader model. It doesn’t force a single monolithic shader down your throat.
Either way, Doom3 is a signifigant step in the right direction, while HL2 is essentially just extending lightmaps.
That depends on what you consider the be the “right” direction. You obviously care more about procedure than results. I want whatever makes the prettiest, most realistic pictures. So far, HL2 has proven itself more capable in this regard.
But …this is what we have to do to bypass the lack of PBO today!!!
Well, yes. Did you expect them to suddenly maifest hardware features that don’t actually exist?
just look at unreal 3
The U3 engine can, and does, use static lighting where appropriate too.
Oh, God forbid you use static lighting… [Roll Eyes]
HL2 looks better than D3. That’s the only standard that matters.
Of course! Screenshots of static lighting on static objects looks better than dynamic objects! But oh wait, lets look at the door that’s lit differently because it moves… and the crates… and anything that you can interact with. There is a lot to be said for consistency within an interactive environment.
Plus, it has a much better shader model. It doesn’t force a single monolithic shader down your throat.
This is definately a shortcoming of the engine, but that’s due to the fact that it was designed to run on a GeForce2 (matter of fact, it’ll run on a GeForce 256). It did get bumped up to GF3 in min spec, but would you really expect the game to look that much different on a NV20/R200 than on cards where lots of variation is possible? It seems to me that lighting is everything in Doom. Having the game look signifigantly different due to older hardware could have severely impacted the (albeit limited) gameplay.
Kevin B
I’m closing this thread because of where the discussion has gone, when you want to return to helping each other with advanced technical issues feel free to start a new one.
