PDA

View Full Version : OpenGL 3 Updates



Pages : 1 2 3 4 [5] 6 7

Carl Jokl
06-23-2008, 03:12 AM
One think which OpenGL is going to benefit from under these curcumstances is that on non Microsoft platform there is no real alternative but to use OpenGL so no matter how much they alienate their developer base they have little choice but to wait until ARB come out with the new release.

Don't make me form a sharp implement out of a GL Triangle Fan and start poking ARB members with it mercylessly. *poke* *poke* *poke* Still won't talk? I can keep this up all day muhahahahar *poke* *poke* *poke*

Another thing which was hinted of as regards potential to remove the GLDOUBLE type as part of some changes designed to simplify driver development. I would be a bit concerned about the long term consequences of removing the use of double precision primitives in OpenGL. Certanly today and for a long time the hardware implementations of the vertex creation and geometric operations and such are implemented as 32bit precision (usually corresponding to a float). The world is going 64bit though and it is not inconceivable that 3D graphics geometry migrates to 64bit precision too. Looking down the line then having the double precision based functions still around in the future would provide a migration path if that happens.

Ilian Dinev
06-23-2008, 03:24 AM
Ok back on track, and OpenGL should stay a graphics library IMO, and if they want GPGPU stuff make a add on library that integrates to GL, and call it OpenGPGPU or something. That way they can be used separately or together.
The old-style GPGPU is staying in its original form, available in GL - render to texture, use that data to draw graphics; meanwhile there's CUDA for the more GP uses.
GPGPU is useful both for the increasing number of streaming-processors (and core clock), and the fact that it keeps data in VRAM, so you only pull via PCIe the data of the final pass. Plus some things like bilinear filtering are free.

In games, we use "gpgpu" to dynamically transform vertices and generate geometry - it's a nice scalable optimization in the short and long term.

Zengar
06-23-2008, 03:28 AM
Another thing which was hinted of as regards potential to remove the GLDOUBLE type as part of some changes designed to simplify driver development. I would be a bit concerned about the long term consequences of removing the use of double precision primitives in OpenGL. Certanly today and for a long time the hardware implementations of the vertex creation and geometric operations and such are implemented as 32bit precision (usually corresponding to a float). The world is going 64bit though and it is not inconceivable that 3D graphics geometry migrates to 64bit precision too. Looking down the line then having the double precision based functions still around in the future would provide a migration path if that happens.

If you remove the immediate mode stuff, there are not many functions left that could use double precision. And if the hardware doesn not support it, there is no real point of double precision to be present in the API. It can be easily added as an extension in the future. And it does not complicate driver developement, really. All the driver has to do is convert doubles to floats – a trivial task.

bobvodka
06-23-2008, 04:36 AM
The removal of 'double' was because it doesn't hit any fast paths and part of the point of GL3.0 was to make it easier to hit the fast path on current and future cards.

"Double" support is partly here; the GT200 has support for double processing HOWEVER at a cost as it has a limited number of double registers (working from memory, check AnandTech's GT200 tech for deails).

The plan seemed to be to remove all the cruft which makes finding the fast path hard for ISVs and to simplify the drivers for the IHVs. Then, as hardware supports things (such as 'double') to add them back in; probably via extensions first then a minor version update (with hopefully then extensions being removed instead of left laying around as now).

knackered
06-23-2008, 04:44 AM
And if the hardware doesn not support it, there is no real point of double precision to be present in the API. It can be easily added as an extension in the future.
I find it hard to believe you missed the launch of the GT200 series.
At the end of the day it's just a type enum when submitting data.

bobvodka
06-23-2008, 05:37 AM
Now I've had time to dig it up;

(source (http://www.anandtech.com/video/showdoc.aspx?i=3334&p=5))
Double the Precision, 1/8th the Performance

Another major feature of the GT200 GPU and cards based on it is support for hardware double precision floating point operations. Double precision FP operations are 64-bits wide vs. 32-bit for single precision FP operations.

Now the 240 SPs in GT200 are single-precision only, they simply can't accept 64-bit operations at all. In order to add hardware level double precision NVIDIA actually includes one double precision unit per shading multiprocessor, for a total of 30 double precision units across the entire chip.

The ratio of double precision to single precision hardware in GT200 is ridiculously low, to the point that it's mostly useless for graphics rasterization. It is however, useful for scientific computing and other GPGPU applications.

It's unlikely that 3D games will make use of double precision FP extensively, especially given that 8-bit integer and 16-bit floating point are still used in many shader programs today. If anything, we'll see the use of DP FP operations in geometry and vertex operations first, before we ever need that sort of precision for color - much like how the transition to single precision FP started first in vertex shaders before eventually gaining support throughout the 3D pipeline.


So, I'd argue against including it now as it's still not a 'fast path'.. although I now expect all the GPGPU people to start crying about it..

Jan
06-23-2008, 07:50 AM
For graphics itself, i don't see any need for more than 32 Bit precision. The only thing, that would be nice to have higher precision, is the depth-buffer, at least when using shadow-mapping. But that requirement came up many years ago and IHVs didn't do anything about it, so i am sure, they won't do much about it any time soon, either. I assume the problem is, that adding support for 32 (or more) Bits for depth is quite costly to get fast, and since it is the central unit on the chip to actually get rasterization graphics, they haven't done it.

With double-values elsewhere it was "easy" of course. Drop it in, with real bad performance, tell everyone it's their fault, if they use it. And few (very few) people might actually be able to use it for something useful, but hey, reviewers will write how great the shiny new card is, because it has a new feature!

Jan.

Zengar
06-23-2008, 09:28 AM
And if the hardware doesn not support it, there is no real point of double precision to be present in the API. It can be easily added as an extension in the future.
I find it hard to believe you missed the launch of the GT200 series.
At the end of the day it's just a type enum when submitting data.

You missanderstood my post... I was trying to say that presence of double types does not make much difference to the API once the immediate mode stuff is removed. Still, I believe it is a better idea to add them as an extension (as you say, it is just a type enum) on hardware that supports them. With other words: the API should expose the abilities of the hardware, not more!

Xmas
06-23-2008, 10:28 AM
I assume the problem is, that adding support for 32 (or more) Bits for depth is quite costly to get fast, and since it is the central unit on the chip to actually get rasterization graphics, they haven't done it.
Actually, all recent GPUs support 32 bit floating point depth buffers (though some effectively only use 30 bits).

ScottManDeath
06-23-2008, 11:36 AM
DX 11 is going to have some kind of GPGPU shader btw.

http://speakers.nvision2008.com/agenda/pop_session.cfm?sessionid=39

The more I can do with a graphics API, the better it is. And I would suspect that in the future, it will be more convenient and possibly more performant to use GPGPU kind of shaders in certain parts to break up the pipeline. I mean, we got geometry shaders, we are going to get more shaders for tesselation.

So what is next. What can you add to the pipeline to enable more flexibility? So then the question arises why not just have the user write generic C++ code with a few intrinsics, say texture fetch and tri-setup.

Sure, it makes sense to have some kind of graphics libary, so those who just want to draw triangles don't have to do all the grunt work. We already have things like this today, say the C runtimes which wrap and standardize OS specific features, such as file access etc.

bobvodka
06-23-2008, 01:22 PM
Right, so DX11 gets compute shaders as an extension to regular; as far as I can tell they aren't talking about "doing it all via compute shaders".

In addition to a normal API, well no skin off my nose tbh (although don't expect it on anything pre-DX10 hardware wise), but it's the idea of 'hey! lets forget this is a graphics API and go GPGPU mad!' which is just dumb right now.

The reason the user can't write 'generic C++ code with a few intrinsics' is that while GPUs are probably now more complex than a CPU they still don't have the same range of functionality. Also, C++ would be a dumb choice just because it's a pain in the arse language at the best of times. If it was going to be done it would really want to be a new language, although it'll probably be C-syntax based as for some reason the industry loves their C-syntax o.O
(*hugs Lua*)

Seth Hoffert
06-23-2008, 02:39 PM
I wonder how a compute shader differs from stream out (transform feedback in GL). :)

Zengar
06-23-2008, 02:47 PM
It probably has a scatter ability.

Seth Hoffert
06-23-2008, 02:48 PM
That would be quite awesome, Zengar. :D There are definitely some exciting times ahead of us.

bobvodka
06-23-2008, 03:03 PM
Hmmm, i wonder if scatter is still the performance shafter it was; GPUs and GDDR being designed for a certain write pattern which scatter totally fails at.

knackered
06-23-2008, 09:41 PM
isn't a GPU with 'scatter ability' basically a CPU?
surely it's this inherent limitation that makes them so fast..

Ilian Dinev
06-23-2008, 10:39 PM
Well, if you have a nice big cache, then it's not much harder on the gddr bus to do than alphablending with 2-3 source-textures AFx16, imho. The problem would be when 100 shaders scatter data to the same pixel at once.

bobvodka
06-24-2008, 08:14 AM
The thing is alphablending a src texel to the frame buffer and reading 2 or 3 textures with AFx16 are two different things.

The alphablending relies on the ROPs and some readback, however due to how coherant GPUs render you are still reading in blocks.

The source textures also tend to be coherantly read in blocks and then use some nice large cache to store them in for other SPs to read from as required.

But, the key point is, both operations can be done in blocks (although they cause their own contention issues which is part of why the XB360s GPU has that 10meg daughter board so that you weren't reading and writing from memroy at once).

Now, while there is some caching on output this is pretty much to allow block writes; when you start scattering your block writing scheme goes out the window as the GPU can't just cache stuff all over the place as it doesn't know when it will be able to write back.

The R500 from ATI could do scatter write, but the CTM docs indicated you would take a speed hit because the writes would be (iirc) uncached .

Timothy Farrar
06-24-2008, 08:28 AM
It will certainly be interesting to see what functionality is found in the DX11 compute shader. My hope is that SM5 adds something like memexport type functionality which is accessible from all shaders (somewhat like texture fetch is universal, excluding dx/dy, in SM4).

As for the fixed function graphics hardware, a very GPGPU way to look at raster / triangle setup is as a very fast way to group threads into SIMD vectors for computation. Effectively serves a very important job setup function which would otherwise be very slow in "software". I still prefer GL/SM4 over CUDA and the like for this very reason. I think it is safe to say that the core fixed function hardware will stay as hardware for a long time (excluding Larrabee of course).

Somewhat in the way that instancing has enabled GPUs to draw a huge number of objects, this GPGPU functionality is going to enable some of us to do even more scene traversal work GPU side, eventually to the point where we can manage level of detail and occlusion GPU side and solve the problem of huge view distances.

Now if only GL catches up to DX in terms of supporting the functionality which has been in GPUs for some time now.

Timothy Farrar
06-24-2008, 08:43 AM
Now, while there is some caching on output this is pretty much to allow block writes; when you start scattering your block writing scheme goes out the window as the GPU can't just cache stuff all over the place as it doesn't know when it will be able to write back.

The R500 from ATI could do scatter write, but the CTM docs indicated you would take a speed hit because the writes would be (iirc) uncached .

As for scattered reads/writes, can be ok as long as the granularity is similar to the bus width. Scattering FP32 vec4's (16 bytes) is much more bandwidth efficient (4x) than scattering INT8 vec4s. If your device memory granularity is 32 bytes, scatter of FP32 vec4's eats up double the bandwidth as the ideal non-scattered case. Which isn't as bad as 8x the bandwidth taken by a scattered INT8 vec4 write. The same goes for performance of random texture reads as well, texture cache hits will drop off quite considerably reading randomly from compressed textures...

Of course you still have to be able to hide the latency of scatter reads, which is exactly what the GPU is designed for, and why it has such an advantage in solving problems which cannot fit into a cache.

So in the case of general scatter/gather on both GPUs (and CPUs for that matter) to be efficient you need to think in terms of scatter/gather on full (bus width sized) "objects" instead of values. Then take and "transpose" between AOS (object) and SOA (vectorized object) to do efficient computation. FYI, this is exactly the point of CUDA's shared memory, fetch into shared memory in bus width sized chunks, then swizzle into a vector friendly format for computation.

Sure is going to get interesting to see how this "compute shader" makes this work well on all platforms...

Ilian Dinev
06-24-2008, 02:34 PM
We'll be using scatter mostly for DOF and motion-blur initially, both being algos where you can cache the few nearby lines or tiles of the frame-buffer and upload on cache contention. Plus, the problem with 100 shaders scattering to the same pixel can be solved initially via a round-robin cache-update using 1 ALU (can do both addition and alpha-blending), and in the future - by having tiles of cached additives, later added together in a pyramid fashion (can do only addition). SLI will be problematic with scatter, but possible at the price of some performance - or well, with improved performance when each card keeps in GDDR the scatter values for the other card's scanlines (can do only addition).

Seth Hoffert
06-24-2008, 02:47 PM
I think it'd be pretty cool if we were able to manage shared memory explicitly with this "compute shader" in order to get much higher performing convolutions. :D

Carl Jokl
06-26-2008, 05:40 AM
*Feels out of his depth and vaugely nausious*

....one day I will be strong with the ways of OpenGL....but I am not a Jedi yet....

bobvodka
06-26-2008, 09:02 AM
I think it'd be pretty cool if we were able to manage shared memory explicitly with this "compute shader" in order to get much higher performing convolutions. :D

The problem with compute shaders as I see it (and a whole black mark against the 3D via CUDA/CTM idea) is that what works well on NV doesn't work well on AMD and vice versa.

For example using the newest hardware from both; AMD prefer a 4:1 ALU:tex ratio where as NV favor 3:1 based on how the samplers are tied to SPs.

Then there are hardware differences at the Stream Processor (SP) level; NV's SPs are all single floating point, where as AMD are vec5 units with each unit able to process 5 instructions at once. Also, each GT200 is made up of 8 normal SP and 2 'fat' SP which can do "special functions" (sin, cos etc); AMD on the other hand as equiped each SP with one of these 'fat' procssors. Couple that with the fact each 'block' for AMD has 16 of these 5 wide SPs and NV only has 8 general and 2 special function there is an intresting mismatch in processing power.

This impacts design of algorithm, as does the local on chip memory (both have 16KB local store, AMD have an additional 16KB global data block) and the number of threads in flight.

While I'm intrested to see what these compute shaders can do the fact the underlaying hardware remains so different and requires different tweaking to get it performing just right that I don't see a CUDA/CTM based system as sane. Right now you only have to worry about supplying the data down the 'fast' path and throwing high level shaders at the driver and it will do it's best. With a CUDA/CTM method you suddenly have to write a backend which cares about what hardware it is running on.. you know.. the stuff the IHVs already do.

DX11 compute shaders seem intresting, but that's about it. Given that two generation in the GS still isn't viable for really heavy use (the GT200 based cards not doing much better than last generation AMD card) I don't see this doing much better because of the hardware differences and work required to get it going.

(In other news, based on how well a £180 HD4870 performs vs a £240 GT260 and a £350 GT280 (as in faster for the former, and generally around 10fps slower in the later) and the fact that NVs drivers have bluescreened Vista for me 3 times now for my GT8800 vs AMD's X1900 series drivers never taking down the system once, I think I'll be jumpping ship again... be intresting to see what AMD's R700 can do when it appears as currently it doesn't have a 'high end' model out).

ScottManDeath
06-26-2008, 10:27 AM
Since CUDA shaders go through the same driver optimizer as the GL/D3D shader optimizer, where is the difference?

Mars_999
06-26-2008, 11:04 AM
Hey Bobvodka, look at the new 4870 card, it actually performs on some tests as well as a GF 260 card, and with in 5fps of a GF 280!! This was in Crysis. At 1900x1200 4870 was 30fps, GT260 28.5, GT 280 34fps!! If AMD got their crap together with OpenGL I would consider one of these cards, but I want texture arrays, and Geometry shaders... Does ATI have PBO's, VTF support yet?

bobvodka
06-26-2008, 11:18 AM
Since CUDA shaders go through the same driver optimizer as the GL/D3D shader optimizer, where is the difference?

Look at what I replied to... this isn't just 'about shaders' but the whole backend, how they are designed and what maps in what way to the hardware.

Right now for GPGPU stuff there is no unified front end, which is the first stumbling block, and if there was you lose 'power' right away because you've had to abstract certain details and work on the lowest common denominator. A situation which only gets worse as GPUs change over time.

Demirug
06-26-2008, 11:34 AM
The main argument for a common GPGPU shader API Element is the common part. As long as GPGPU Applications are bound to hardware from one manufacture I don’t see them ready for mass market. The Direct3D 11 compute shader model may make it harder to get to the raw metal and get any cycle out of the GPU. But such shaders will run on every Direct3D 11 hardware and I have a good felling that the performance would not be that bad.

Personally I am more interested in using them for graphics processing. There are still some areas that can’t implemented very well with the three shader stages we have today.

Korval
06-26-2008, 09:54 PM
As long as GPGPU Applications are bound to hardware from one manufacture I don’t see them ready for mass market.

GPGPU applications are not for the mass market. People who actually need GPGPU are High-Performance computing people. Scientists and so forth. They can afford to buy whatever hardware they want and build software specifically for that hardware. But the common person, even gamers, just don't need a GPGPU.

Jan
06-27-2008, 12:48 AM
Exactly! And that is why it would be a stupid idea to base OpenGL on something like Cuda. It would mean to base a mainstream API needed everywhere on an API highly specialized for a task that is only needed by a very limited amount of people. Doing it that way round is bound to get you into trouble.

Jan.

Zengar
06-27-2008, 03:05 AM
You miss the point that GPGPU will become mainstream very soon. For example, Apple won't just release OpenCL – they will be sure to use it too. Video encoding, image processing, game physics, sound procesing – there are lots of possibilities for a normal user. Cuda is already used by never Nvidia drivers to provide PhysiX acceleration.

But I agree that it is pointess to base GL on GPGPU – it is a distinct API. This two things must exist in parallel.

bobvodka
06-27-2008, 03:39 AM
Agree, they should exist in their own APIs.

I still see it as a problem however that the hardware is pretty different (and will only get more so once Intel enters the game) which brings up issues with levels of abstraction and how you program them.

As I metioned, optimal for AMD isn't going to be optimal for NV and if you want the pure to the metal power of either chipset any sort of abstraction starts to cause you problems and start to sap that to a degree.

I'll watch OpenCL with intrest.

Korval
06-27-2008, 04:22 PM
You miss the point that GPGPU will become mainstream very soon.

To do what? Video encoding, image processing, and sound processing are all stuff that is easily done on the CPU. It is 10x easier to do them on the CPU. After all, if you offload that stuff to the GPU, what is that Quad Core CPU going to be doing?

As for game physics, if you're talking about incidental stuff like particle systems, maybe. If you're talking about physics that actually interacts with the gameplay, no. Once again, it's much easier to do it on the CPU, where you AI and so forth is. AI needs to respond to physics, so it needs access to the physics system.

zed
06-27-2008, 09:32 PM
sure everything can be done on the CPU (including graphics) but at what speed,
video encoding even the fastest quadcore takes about an hour to encode a video, a GPU would do that 10x quicker

a lot of stuff can be done by the GPU eg SPU stuff here
http://www.naughtydog.com/corporate/press/GDC%202008/UnchartedTechGDC2008.pdf

i see now dx11 are making first steps in this direction, my bet is with dx12 or more likely dx13 it will be exactly how i described in an earlier post (d3d wont exist, or more correctly they will be accessed through a layer),
Remember a few years ago there used to be with directx, 2 different apis? directdraw + d3d, but in d3d8 they effectively dropped directdraw. I can remember at the time ppl moaned about the dropping of directdraw (performance etc) but in hindsite Im sure everyone now agrees it was the right way to go.
Like I said we're in the midst of a radical change in GPU usage, ogl3.0 should be aiming for this full programable solution ala CPUs, which will happening at present.

Overmind
06-28-2008, 03:11 AM
In about 4 years, we'll have 32 core processors. Another year and a half and it will be 64 cores. The more cores we'll have, the less we will know what to do with them. Over time, the extra processing power of the GPU will become irrelevant compared to the power of multicore CPUs.

knackered
06-28-2008, 05:41 AM
unless the GPU is moved onto the CPU die.

ZbuffeR
06-28-2008, 05:41 AM
In about 4 years, we'll have 32 core processors. Another year and a half and it will be 64 cores.
You are probably right.



The more cores we'll have, the less we will know what to do with them.
You mean, by lack of imagination ? Or because of the difficulty to efficiently use deeply parallel architectures ?


Over time, the extra processing power of the GPU will become irrelevant compared to the power of multicore CPUs.
I remember Intel saying that since a decade ago, during first days of 3DFX, when they introduced their MMX extensions. I guess they were wrong all that time.
Not all games need all the huge power of a top spec PC with latest CPU and latest GPU. But some application will, for sure !

I would love to play with an earthquake simulator on a big detailed town :D

Overmind
06-28-2008, 08:10 AM
You mean, by lack of imagination ? Or because of the difficulty to efficiently use deeply parallel architectures ?

Of course I mean the difficulty in using parallel architectures ;)


I remember Intel saying that since a decade ago, during first days of 3DFX, when they introduced their MMX extensions. I guess they were wrong all that time.

The big difference between MMX (3dnow, SSE and so on) and a GPU is that MMX is "just" a vector processor, while a GPU is a massively parallel array of vector processors. But now if we look at multicore CPUs with a really large number of cores, that's not that different from a GPU.

The biggest advantage GPGPU has now over normal algorithms is that it can execute lots of instances of a calculation at once. But on multicore CPUs you can do the same. You can even run *different* calculations at the same time ;)

I'm not saying that GPUs will become obsolete. Of course, if the calculation is for some graphics effect (e.g. particle system), and you don't need the result back in main memory, using the GPU still makes sense. The problem here is bus bandwidth.

Nor am I saying GPGPU is useless. It makes sense right now, but I think it will make sense less in the future. But the research will surely be useful. I'm sure the same or very similar algorithms will come in handy when we're desperately trying to get processor utilization to 100% on 64 cores in a few years :D

Zengar
06-28-2008, 09:27 AM
If CPUs of the future will replace GPUs, then massively parallel APIs like OpenCL are still of use. The GPGPU of today is not really about how to use GPU for general purpose any more, it is how to use a massively parallel processor array effectively.

Korval
06-28-2008, 01:15 PM
video encoding even the fastest quadcore takes about an hour to encode a video, a GPU would do that 10x quicker

And? Shocking though it may be, doing video encoding is not something that is "mainstream," nor will it be in the near future.

More importantly, video encoding applications don't need their hardware interface to be OpenGL. I have nothing against people using graphics hardware for other things. But OpenGL is a graphics API, and it should always remain so.

sqrt[-1]
06-28-2008, 04:50 PM
In about 4 years, we'll have 32 core processors. Another year and a half and it will be 64 cores. The more cores we'll have, the less we will know what to do with them. Over time, the extra processing power of the GPU will become irrelevant compared to the power of multicore CPUs.

Don't be too proud of this technological marvel you have constructed on the CPU, it's power is insignificant compared to the power of the GPU!

zed
06-28-2008, 05:55 PM
And? Shocking though it may be, doing video encoding is not something that is "mainstream," nor will it be in the near future.true, though its one of the few things where extra computing power is needed, like i mentioned a few pages ago, since cpus hit ~2ghz the average person doesnt really care, web browsing, typing letters etc are fast enuf.
its a similar story with GPUs (sure extra power is nice be it GPU or CPU) but look at what they have to benchmark games at nowadays, 1600x1200+4xAA even then most games run at 100fps, whats next? 3200x2400+16xAA but thats all just diminished returns.
instead what is needed, are better ways to shade these pixels.
a more powerful + complete graphics language/API == a better way

CatDog
06-28-2008, 06:51 PM
Games games games!

Hey, there's some other kinds of graphics applications out there. Try to render some sophisticated technical simulation including generic *user data*. Believe me, these people simply don't care. They export every hi-poly screw model right from their CAD workstations. And when the framerate drops under 20fps because of their 300M triangles, you've got them on the phone. Oh yes, and that's just the rendering stuff. After clicking together that assembly line for the new Mercedes Benz it also has to be simulated. "And, please, some collision detection, cause we don't want that robot crash into the windscreen, do we? What? I have to manually switch off collision detection for the non relevant models? Why can't I just collide everything with everything else? Just like in real life?!"

Damn stupid customers! :)

Oh well. Not really.

Err. What I really wanted to say is: no, it's not fast enough. I want 64 cores.

CatDog

knackered
06-29-2008, 05:03 AM
well, games are what funded these cheap GPU's we're currently enjoying. If the only sector that needed realtime 3d graphics was the visualisation sector, we'd still be paying £100,000 a pop for our GPU's. Like back in the days of SGI infinite reality workstations etc.

CatDog
06-29-2008, 05:39 AM
Don't get me wrong. I love games and every advance in technology they bring out! But, especially for OpenGL in contrast to D3D, there are many other applications, too. At least it was like that in the past...

Btw, seeing it from the developers point of view, with hardware getting more powerful and prices going down, it seems that quality decreases also. Which is acceptable for games only, in my opinion.

CatDog

Brolingstanz
06-29-2008, 05:48 PM
The problem here is bus bandwidth.

Yes indeed, and it's a problem that not likely to go away anytime soon. I think in the end GPU vendors would like offer something akin to an entire game console on a card (or two), while the CPU folks continue to compete via multicore mitosis. Either way, the pitifully lethargic evolution of the basic PC architecture make leveraging the 2 simultaneously an exasperating exercise in creativity and determination...

I think we're all ready for a one-stop computation-shop. This stuff makes my head hurt.

Korval
06-29-2008, 08:58 PM
I think we're all ready for a one-stop computation-shop. This stuff makes my head hurt.

Well, if you want one, AMD's working on a CPU with an integrated on-chip GPU.

Hampel
06-30-2008, 12:25 AM
Taking the space on the die into account, I would says, it is the other way round: they integrate a CPU into the GPU... :)

Korval
06-30-2008, 12:55 AM
Taking the space on the die into account, I would says, it is the other way round: they integrate a CPU into the GPU...

It goes into the slot on my computer marked "CPU", so I'll call it one of those.

Brolingstanz
06-30-2008, 01:46 AM
One interesting possibility with a more generic or capable GPU or CPU is the possibility that they turn into platforms in and of themselves, as opposed to the relative anonymity they enjoy now as cogs in a larger wheel. Suppose you could make the argument that this situation already exists in some commercial contexts (GPGPU science, engineering, etc. as mentioned earlier). Interesting, arguably, but it's probably a long walk from graphics card or even GPGPU to gaming platform..

Brolingstanz
06-30-2008, 02:11 AM
whats next? 3200x2400+16xAA but thats all just diminished returns.

dunno, but I'd love to see 16 sample CSAA.

knackered
07-01-2008, 12:22 PM
yeah, a big blurry mess.

Korval
07-01-2008, 02:08 PM
dunno, but I'd love to see 16 sample CSAA.

Bah. The real future is in floating-point render targets and full-on motion blur (ie: temporal anti-aliasing). Unfortunately, most engines aren't even close to designed well enough to do real motion blur. That is, rendering at effectively hundreds of frames per second, with intra-frame position and animation interpolation. Even 4x motion blur just isn't likely with most game engines.

Ilian Dinev
07-01-2008, 02:19 PM
I think vector motion-blur at strictly-locked 60Hz is mostly enough, from what I've played with: nVidia's single-frame method, smudging in one direction only the endpoint of the last frame (this method is used in Crysis), and much better-looking simple improvement of mine, that renders only mid-frames and smudges together with the previous frame-buffer in two directions. Though, I haven't tried the latter with nicely-lit skinned human characters yet.

zed
07-01-2008, 02:52 PM
dunno, but I'd love to see 16 sample CSAA.
true, though i meant going from 400x300->800x600 makes a larger difference to the viewer than 800x600->1600x1200, even though the ratio increase is the same.
and once monitors hit 600DPI (long way off though) further increases of resolution will make no difference whatsoever.

I dont know about motionblur, whilst nice, ild prefer decent unified lighting.
most games even the top ones coming out now still use lightmaps! comeon quake2 was using those (true in 8bit but still)

Ilian Dinev
07-01-2008, 03:10 PM
most games even the top ones coming out now still use lightmaps! comeon quake2 was using those (true in 8bit but still)
I prefer lightmaps to (almost) hard-edged on/off shadows. Some radiosity is very important in some types of scenes, too (even outdoors ones).
Sunny scenes with no clouds- ok, but anything cloudy like all of Resistance:FoM, and unified lighting just doesn't cut it.

Brolingstanz
07-01-2008, 03:15 PM
totally, zed. I wasn't disputing what you said, just thought it'd be interesting to compare 8 to 16 sample CSAA in general ('twas a 8-is-great, but-16-is-peachy-keen kind of thing) :)

Korval
07-01-2008, 04:34 PM
I think vector motion-blur at strictly-locked 60Hz is mostly enough

No, that is not enough. That in fact, is an ugly, brutal hack. It's about as realistic looking as the old embossed "bump mapping" technique was.

Here's a good rule of thumb: if you can actually see the motion blur, then you're not doing it right.

Brolingstanz
07-01-2008, 05:19 PM
Well, if you're striving for super realism then it's less than perfect, but some of these approximations take on a charm of their own, don't really look all that out of place amidst all the other approximations going on, at least to my eye. Although in the context of a game I suppose getting whacked with a blurred pipe is no better than one you can see coming with complete clarity.

I get some cheap, low quality motion blur for free on my LCD ;-)

Ilian Dinev
07-01-2008, 05:40 PM
That brutal hack is used in offline video rendering, afaik. Though there they also add real 4x temporal antialiasing. Or advanced vector motion-blur, that splits the scene into 2D layers and handles rotation.
We as gamers are used to varying low choppy framerates, so we don't notice that anymore - thus we are bound to notice any ingame motion-blur, be it truly real or not. And many might start feeling motion-sickness if realistic blur is present in games with quick camera movement (FPS), and the gamers have gotten immersed in the game, imho.

Rick Yorgason
07-02-2008, 06:46 AM
Here's a good rule of thumb: if you can actually see the motion blur, then you're not doing it right.
Another good rule of thumb (for now): if you can't actually see the effect, there's better ways to utilize your processing power.

knackered
07-02-2008, 09:34 AM
it's not an effect, it's what's required to simulate natural optics.

Suncho
07-02-2008, 10:23 AM
Here's a good rule of thumb: if you can actually see the motion blur, then you're not doing it right.
Another good rule of thumb (for now): if you can't actually see the effect, there's better ways to utilize your processing power.

No. The purpose of realistic motion blur is to reduce or eliminate the undesirable strobing effect. You're not supposed to see the blur in and of itself.

Jan
07-02-2008, 12:02 PM
Just as with many other effects: As long as you DON'T have the processing power, you exaggerate the effect, such that people see, what cool graphics their PC is able to do. Once hardware has evolved enough to be able to always utilize the effect, you can tune it down so much, that it is subtle and realistic. Then it usually looks MUCH better, but not everyone will notice that it is actually their. So, eating up all the available processing power forces you to make an effect clearly visible, otherwise dumb customers will complain, that they don't know why your app is so slow.

Jan.

Rick Yorgason
07-02-2008, 12:46 PM
Thanks Jan; that's why I specifically said "for now" >:)


it's not an effect, it's what's required to simulate natural optics.
If simulating natural optics is your primary goal, then why are you wasting your time with rasterizers? >;)

Ilian Dinev
07-02-2008, 01:40 PM
As we're rendering on a 2D surface, it's things in recorded videos that we try to put in games, right? First were lens-flares, then bloom, then simplistic DOF, then simplistic MBlur. Initially in games these effects were over-exaggerated for the "coolness" factor (and we gamers love it initially), then made more subtle - so that becomes more realistic.
But if you look closer in videos, you can see motion-blur almost everywhere. Moreover, if you just move your hand, the mblur is clearly visible (under sunlight or heated-wire lamps). If you rotate your head not too slowly, and not move you eyes, it's also visible. (if you move your eyes, which we usually do when turning to look somewhere, the brain dampens the mblur tenfold in one way or another).
Oh well, the above things are all of my personal experience and research, and I can't rule-out I have some strange vision or perception.

Meanwhile, DOF can get in the way in games. The gamer will often want to focus on some specific object - but the required input-controller for that will never be available (who wants a HD camera to monitor one's pupils nowadays). So, only RPGs and other camera-looking-down games can safely use it. Maybe some similar limits are present for using MBlur? Like how one's vision dampens MBlur tenfold when moving one's eyes - but expects full blur on keeping the rotation angle (oh well, at least here we can use the mouse/Right-Stick axis as input).

Jan
07-02-2008, 03:35 PM
No, your eye / brain does not experience any motion blur. What you mean is simply the fact, that the brain can't process so much information in a short time, so you don't notice any details anymore. However, there is no "motion blur" in the strict sense of the word, since your eyes are capable to send many hundreds of different signals to your brain per second. Your brain starts ignoring those signals much earlier, than the "sampling rate of your eyes" becomes the limiting factor.

"Motion blur" as we know it, however, is indeed the problem, that your sampling rate is too low AND that you sample over a whole time-frame. In films this happens, because you usually sample at 25 Hz and each sample takes 1/25th of a second. That means all the movement during that time-frame is captured on film and smears the image. Note, that this is something entirely different, than what happens, when you simply move your head quickly.

In games, on the other hand, you do have a low sampling rate, but also you sample at a fixed time, which results in clear and sharp images, at low speed, such that the brain does interpret it as "moving" but is actually capable to notice the sharp differences.

The perfect solution would be really simple: do what nature does, present hundreds of perfectly sharp images per second to the viewer. At 1000 frames per second it will look like the real world. However, sadly that's not possible, so we revert to the second best option: do what films do, sample over an entire time-frame (well, approximate it as good as possible).

I do have yet to see a technique for motion blur, that convinces me in quality AND implementation. All methods i know so far either make the effect too extreme (e.g. accumulation buffer, where you even get motion-blur, when you simply turn around) or they only work on certain objects under certain conditions (and are usually much more difficult to implement).

Jan.

Korval
07-02-2008, 03:43 PM
Just as with many other effects: As long as you DON'T have the processing power, you exaggerate the effect, such that people see, what cool graphics their PC is able to do.

Yes, and that is precisely why I hate every implementation of the following in games:

- HDR
- Motion Blur
- Lens Flare
- Motion Blur
- Depth of Field
- Bloom
- Motion Blur

These are all gigantic signposts that say, "Hi. I'm an amateur graphics programmer who doesn't know what he's doing!"


So, eating up all the available processing power forces you to make an effect clearly visible, otherwise dumb customers will complain, that they don't know why your app is so slow.

The answer is simple: if you can't do something right, don't do it at all. If you aren't committed to real motion blur, don't bother with hacks. Introducing noise into an image is the worst thing you can do.


I do have yet to see a technique for motion blur, that convinces me in quality AND implementation.

The first thing you need to do motion blur correctly (besides the willingness to eschew any/all hacks and actually render at a high framerate) is real HDR. You can't do motion blur correctly if you're just alpha blending non-HDR 24-bpp frames. You have to commit to using HDR everywhere, always (except the HUD), and correctly. No linear alpha-blend type stuff anymore; it's all got to be real additive light accumulations.

Mars_999
07-02-2008, 05:32 PM
These are all gigantic signposts that say, "Hi. I'm an amateur graphics programmer who doesn't know what he's doing!"

LOL

Ilian Dinev
07-02-2008, 06:00 PM
:) Well actually I am the amateur here :). Been reading papers on graphics, staying in 2D world for the last 5 years, then making software 3D rasterizers for PDAs, and now I'm just trying to learn how to make a current-gen 3D game in my spare time :). Not that I'll succeed in completing one, it's the knowledge and fun experience I'm after.
But Mars, please elaborate further :)

Jan: yes, we can never please the eye ^^". But at least we can try approximating some things to look like _video_. RPGs and ingame videos can look better with mblur, imho. I think it helped the cutscenes in MGS4 a lot, but I could be mistaken.

zed
07-02-2008, 06:45 PM
try this
hold your hand out a meter in front of your face, now rapidly wave it,
now seriously its motionblurred.
perhaps technically the brain/eyes are seeing a still hand with each frame, but how we percieve it is as a blur.

what is closer to what the human brain sees
A/ a motionblur hack (like in some current games)
B/ no motion blur whatso ever (all games apart from the recent ones)

#A is closer than #B to how we perceive it

im not saying though im a fan of motion blur as implemented today

personally bugger reality, hyperreality is what its all about, look outside on a overcast day, the lighting is pretty boring


if you can't do something right, don't do it at allhow do u light your scenes :), because no known lighting cg model accurately models reality

Korval
07-02-2008, 06:53 PM
what is closer to what the human brain sees
A/ a motionblur hack (like in some current games)
B/ no motion blur whatso ever (all games apart from the recent ones)

You're looking at it from entirely the wrong perspective.

You can't show the eye what the "brain sees"; you have to show the eye what the world looks like. Then, it will process it correctly and the brain will see what it is supposed to. However, if you try to pre-process it, you find that people notice the pre-processing.


personally bugger reality, hyperreality is what its all about, look outside on a overcast day, the lighting is pretty boring

I'm no fan of perfectly mimicing reality in games, but I am a fan of sharpness and detail. And making your scene blurry and fuzzy isn't helping either of those.


how do u light your scenes :), because no known lighting cg model accurately models reality

Getting it "right" in this case means not looking like crap. Not making your scene look worse than it would without it. If your hack motion blur is only going to add noise to a scene and make everything blurry (instead of sharp, like real motion blur does), there's no point in bothering.

Take shadows, for example. There are many shadowing algorithms that look good most of the time, but have terrible artifacts sometimes. You should not use these because the artifacts aren't worth the benefits.

Ilian Dinev
07-02-2008, 07:49 PM
However, if you try to pre-process it, you find that people notice the pre-processing.

And yet we're watching blurry videos most easily, completely oblivious of this.
Ah, found-out research info why rotating one's head while letting one's eyes move (unconditionally) dampens the blur we see - we do many quick saw-wave-like rotations of the eye, letting the same cones continue receiving the same light from the same focused objects. Easily supported by the simple test of looking through the window while being in a fast-moving train (and not trying to focus on passing trees). You see the integrated light over time plus afterimages of overbrightness - it's as simple as that. One's eyes could have response of picoseconds, but there's an integrator with overall-brightness-controlled timestep at the end. And thus we really don't mind 24fps movies.

And with a 2D screen, it's obviously motion-pictures we can only make. Thus the visual target is to make software to compute motion-pictures at interactive framerates, right? (well, if an effect breaks gameplay or fun - axe it down)

zed
07-02-2008, 08:26 PM
You can't show the eye what the "brain sees"; you have to show the eye what the world looks like.
but we cant do that, due to technology (contrast/brightness etc)
but in this case, screens display at ~60hz vs the eyes (whatever it is) ~1000hz??

true in an ideal world you would display the scene at 1000+fps (screen refresh each frame), + if theres too much speed for the eye to see then it will see the motionblur itself, but for the foreseeable future technology wont allow us to achieve this, thus having a blur/smudge mimics reality closer than having nothing.


Take shadows, for example. There are many shadowing algorithms that look good most of the time, but have terrible artifacts sometimes. You should not use these because the artifacts aren't worth the benefits.
So you're advocating something like a black dot under the character, since it suffers no degradation/artifacts ( it just looks crap all the time :) )

Eckos
07-02-2008, 08:46 PM
So what is the current status of OGL3? Will it be postponed again? I heard a rumour next month that it will be released

Rob Barris
07-02-2008, 09:36 PM
The OpenGL working group is meeting regularly and the activity level is high.

Mars_999
07-02-2008, 11:32 PM
Thanks for the tip Rob. Now get back to work on SC2 and Diablo3! ;) Just kidden. Great news on all fronts!

Jan
07-03-2008, 12:27 AM
" And thus we really don't mind 24fps movies. "

Yes and no. The reason why films at 24 Hz look so good is this:
At 24 Hz we do have 24 different images PLUS each image is captured at 1/24th of a second, thus each image is the integral of a whole time-frame. Even at fast motion in the images the brain cannot distinguish the individual frames, because of the smearing.

Now play a fast-paced (any) match of Quake 3 locked at precisely 24 Hz. It will look like an animation, because 24 fps is still too much for the brain to process COMPLETELY, but still it won't be as pleasant as a fast-paced movie, because you CAN see the staggering animation steps from frame to frame. I don't say it is unplayable, i only say that you DO notice a difference at fast paces, whereas in films it doesn't matter how fast the motion is, 24 Hz is always enough to fool you.

Jan.

Korval
07-03-2008, 12:29 AM
thus having a blur/smudge mimics reality closer than having nothing.

That doesn't make it good. Once upon a time, Embossed Bump Mapping was all we had. But nobody used it because it was crappy.


So you're advocating something like a black dot under the character, since it suffers no degradation/artifacts ( it just looks crap all the time \:\) )

So long as the black dot is consistently bad, and is consistent with the general level of the rest of your graphics, it's fine. It's really all about consistency. Not having bump-mapping is consistently wrong, but it always looks the same.

You can get used to consistently incorrect graphics. What you can't get used to is inconsistently correct graphics. That is, graphics that are mostly correct except for a few missing things here and there. That's how you get the "Uncanny Valley" effect.

elFarto
07-03-2008, 01:48 AM
I have to say, the motion blur in Team Fortress 2 looks pretty good. It actually takes quite a bit of movement to start noticing it.

Regards
elFarto

pudman
07-03-2008, 06:47 AM
The OpenGL working group is meeting regularly and the activity level is high.

I see the Blizzard PR is in affect.
"It'll be done when it's done."
"Can't give more details now, everything subject to change."

Why not. If Blizzard's level of polish gets incorporated into GL3 then that would be a Good Thing. Still, however, OpenGL isn't a product with trade secrets that must be protected so the silence still seems unjustified.

Sik the hedgehog
07-03-2008, 08:42 AM
" And thus we really don't mind 24fps movies. "

Yes and no. The reason why films at 24 Hz look so good is this:
At 24 Hz we do have 24 different images PLUS each image is captured at 1/24th of a second, thus each image is the integral of a whole time-frame. Even at fast motion in the images the brain cannot distinguish the individual frames, because of the smearing.

Now play a fast-paced (any) match of Quake 3 locked at precisely 24 Hz. It will look like an animation, because 24 fps is still too much for the brain to process COMPLETELY, but still it won't be as pleasant as a fast-paced movie, because you CAN see the staggering animation steps from frame to frame. I don't say it is unplayable, i only say that you DO notice a difference at fast paces, whereas in films it doesn't matter how fast the motion is, 24 Hz is always enough to fool you.

Jan.
Honestly it's really a matter of custom. I play Sonic Action (my fangame) at 100FPS and it seems normal. Then I play a game at 30FPS, and looks ugly to me. I play for a while, then I switch back to Sonic Action at 100FPS, and it looks extremely smooth to me, sometimes to the point it starts being annoying (yes, I'm serious).

As long as the framerate isn't too low, actually it doesn't matter that much. The brain seems to process any framerate gracefully, just give it time to get accustomed.

Jan
07-03-2008, 09:18 AM
Yes, that's basically what i meant. 30 FPS is definitely enough for playing any game (even Quake 3 or Sonic or whatever), but without the motion-blur you CAN see a difference (therefore it looks ugly to you, after you became used to 100 FPS). Though one gets used to it pretty fast, such that it doesn't annoy you very long.

What i wanted to point out was, that in games you CAN see a difference sometimes (depending on the game) however in films you NEVER have that not-smooth-enough effect, even at fast paces, because of the additional smearing.

Now if only our brains were a bit slower at processing images and we could get away with 15 FPS.... :D

Jan.

MZ
07-03-2008, 10:19 AM
Still, however, OpenGL isn't a product with trade secrets that must be protected so the silence still seems unjustified.
To be honest, this kind of mystery is infact a norm in OpenGL world. It's not like the standards have suddenly dropped. Remember old mysteries?

why the arb-meeting-notes lag keeps growing at exponential rate?
why the original (3dLabs) OGL2.0 ended in fiasco?
why Ati implementaion isn't on pair with D3D in terms of exposed features?
why IHVs can't agree on common vertex array extension?
why IHVs can't agree on common SM1.1-SM1.4 extension?
why another year have passed and FBO spec still isn't ready?

This builds man's character.

bobvodka
07-03-2008, 11:12 AM
A little while ago, couple months or so, I did a job interview at one of the companies on the ARB for a DirectX development position. The lab I worked in through grad school required me to use linux so I did my work in OpenGL, and haven't touched DirectX that often.

So during the interview process I was talking about OpenGL and how I was irritated with the status of 3.0. The guy interviewing me said that the spec that they initially we're releasing info on was pretty much scrapped. ARB's goal was to talk about it at this SIGGRAPH, but whether that happens is anyone's guess.

(source (http://www.gamedev.net/community/forums/viewreply.asp?ID=3261812))

Discuss.

Sik the hedgehog
07-03-2008, 11:46 AM
I love how the reason is probably one of the most obvious, and you all starting making weird speculations about IP issues and such :P

Right now, the only thing that worries me is that I wouldn't like there being any incidents at the SIGGRAPH. I know it sounds extremist, but the enviroment isn't the best, and almost anything gets a lot of people angry. A mistake, and it may be no good... My personal opinion though.

Zengar
07-03-2008, 11:52 AM
I am looking forward to headlines like "Massaker at SIGGRAPH! Angry mob slaughters the ARB representatives!" :D

zed
07-03-2008, 12:56 PM
Hopefully the initial spec has been scrapped, as I didnt think it was that forward thinking.
Perhaps they are going the more futureproof route like Ive suggested, if so then perhaps silence is justified ( imagine the hue + cry, if word got out :) ), to quote 'the dub' use 'shock and awe'.
In saying that though the lack of information from the ARB is still very poor, even if its someone like Rob Barris saying each week 'yes theyre still working + yes there will be something at siggraph2008'.
Even if theres no fresh details supplied it acts as a moral booster.
Just 40 sleeps to go

knackered
07-03-2008, 01:05 PM
I'm not sure if I believe that gamedev post, to be honest. It's so very easy to lie, to get attention.
If it is true, and they scrapped the original spec then we're doomed to at least another 2 years of waiting for the keystone cops to draw up a new one.

Sik the hedgehog
07-03-2008, 01:11 PM
I would believe it merely because it seems to be more than reasonable, I mean, seems simple enough and very possible. Secondly, not necessarily it would take more time. Maybe they just scrapped the implementation, not the ideas, so there you save a lot of time :)

V-man
07-03-2008, 02:23 PM
What? Someone on gamedev said long peaks is canceled and Mt Evans is comming?
That's a pretty big shame.

bobvodka
07-03-2008, 02:23 PM
Hopefully the initial spec has been scrapped, as I didnt think it was that forward thinking.

It was made by the guys who work for the companies who do the hardware so in theory it was going to fit the hardware, which is what we wanted; 'future proof' and 'forward thinking' rarely work out as well as you want, meanwhile you've given up speed in the here and now.

bobvodka
07-03-2008, 02:24 PM
What? Someone on gamedev said long peaks is canceled and Mt Evans is comming?
That's a pretty big shame.

More like the Weird Al song; Everything you know is wrong.

Brolingstanz
07-03-2008, 03:40 PM
This builds man's character.

It does indeed. It'll put hair on your chest and a swagger in your step.

knackered
07-03-2008, 04:13 PM
Paralysis through analysis is killing OpenGL.
Just thought I'd share that with you.

Rob Barris
07-03-2008, 04:56 PM
Come to SIGGRAPH !

Korval
07-03-2008, 07:53 PM
Come to SIGGRAPH !

What!?

We just got information, unreliable though it clearly is, that the ARB abandoned the GL 3.0 that we knew from last year (possibly due to meaningless politics inside the ARB), and has moved on to some other fundamental design. That at least one ARB member (an IHV, no less) has basically written GL off entirely, providing only token lip service to participation and support, and have moved on with their lives. And all you can do is say that?

Most organizations that are having their name and product dragged through the mud would at least toss out a bone. They'd issue a denial (lie if needs be) or a statement saying that such information cannot be trusted. What do we get? "Come to SIGGRAPH!"

Seriously now, is the ARB staffed by clowns? It seems obvious at this point, but it'd be nice to have confirmation on the matter.

Sik the hedgehog
07-03-2008, 09:25 PM
Paralysis through analysis is killing OpenGL.
Just thought I'd share that with you.
What are you saying? :P

<ARB> Why do we need this feature from D3D10? Nobody would use it anyways!
*next year all games make use of that feature*
<ARB> Oh, curses...
At least OpenGL 3 is gonna retain legacy stuff, and hence triangle fans. They have been removed in D3D10, and there's no way to replace it but individual traingles. Instead, they provided us with the following really stupid traingle sets:
http://srb2town.sepwich.com/junk/primitivetypes.PNG
How are those types useful? o_O The only thing they do is make you pass as double as vertices as you need and ignore those extra ones >_>

Sorry, but traingle fans are useful, and I don't think it's true that they are slower than triangle strips. And the latter can't replace them directly if there are more than four vertices. They should be as fast as them really, and my card fakes non-triangular polygons using triangle fans (which makes sense after all, assuming all polygons are to be convex).

But let's get back on-topic :P

Seth Hoffert
07-03-2008, 09:29 PM
The adjacency primitive modes are for the geometry shader... typically you'd use an element array with them to avoid having to specify redundant data in your attribute arrays. These modes allow the geometry shader to see the adjacent vertices as well. This is useful in LOD algorithms for example.

Sik the hedgehog
07-03-2008, 09:46 PM
OK, fair enough, though still it doesn't explain why triangle fans are useless...

Brolingstanz
07-03-2008, 09:57 PM
Well, they're not useless, just not strictly necessary as a basic primitive. If you're trying to simplify things it's a good candidate for cut list.

Sik the hedgehog
07-03-2008, 10:45 PM
Maybe (I actually can think in some very good uses of triangle fans, specially when it comes to spherish surfaces). But I'm pretty sure that Microsoft removed them with the excuse that they were slow, because they consider triangle fans to be as slow as individual triangles o_O I guess the excuse they put is the cache, but c'mon, instead of caching the two last vertices, cache the first and the last one...

But seriously, if they really wanted to speed up things, they could have made an index buffer object or something. That would be faster than any kind of triangle grouping you can think on.

Oh, and something I forgotten to mention:

typically you'd use an element array with them to avoid having to specify redundant data in your attribute arrays.
Vertex buffers in immediate mode are the only choice in D3D10. For some weird reason retained mode was removed (I swear there are a lot of useful things that got removed). OK, I understand that bigger power allows you to use more brute force, but c'mon, there's no reason to use it as an excuse to remove stuff that helps speeding up, specially because buses aren't as fast as the CPU and the GPU, and are probably the main bottleneck reason for slow downs... And immediate mode isn't exactly very friendly with that =/

Demirug
07-03-2008, 11:11 PM
What do you mean with an index buffer object? While former Direct3D versions have dedicated index buffer with Direct63D 10 you just create a buffer (with an index buffer binding flag) and use it as index buffer.

What makes you thing that Direct3D 10 supports only immediate mode buffers? The buffers (like all other resources) in Direct3D 10 keep their data until you overwrite it with something else. There are only some rules about hinting the system how often you will change the data. These hints will have an impact on how you need to update the data (direct memory mapping or using a copy instruction).

Sik the hedgehog
07-03-2008, 11:34 PM
What do you mean with an index buffer object? While former Direct3D versions have dedicated index buffer with Direct63D 10 you just create a buffer (with an index buffer binding flag) and use it as index buffer.
Well, vertex buffers hold an array of vertices, so an index buffer would hold an array of indices :P Think of it like a huge batch and the GPU uses all the vertices according to the specified indices.

Hm, maybe I'm gonna check harder. Direct3D 10 really scares me with so many removed features x_X At least with OpenGL you can use legacy functions if you don't have time to learn newer stuff (e.g. you're in a hurry, or you're porting an engine and you want to test as you implement new features rather than having to port it all before being able to do it).


What makes you thing that Direct3D 10 supports only immediate mode buffers?
I guess the fact the docs explicitly say that retained mode was removed?

The Direct3D Retained Mode API was completely removed from Windows Vista.

Windows Vista continues to support the same Direct3D and DirectDraw interfaces as Windows XP, back to version 3 of DirectX (with the exception of Direct3D's Retained Mode, which has been removed).
Mh, OK, maybe I got confused there. But still, Microsoft removed support from retained mode, so for our matter the issue is the same... (I actually wonder if video cards are optimized for immediate mode, I could get the PGL engine to render faster using glVertex*() directly rather than using arrays, but maybe I was just lame :P)

I hope OpenGL 3 still allows doing this.

Demirug
07-04-2008, 12:16 AM
That “Direct3D Retained Mode” is something complete different. It was some sort of high level engine that was part of the first Direct3D version. It was hardly used and I know only one game that was shipped with this. This has nothing to do with the retained/immediate modes that you now from OpenGL.

Jan
07-04-2008, 12:39 AM
Hey man you are complaining about D3D10 being retarded and give only examples which show, that you really don't know what you are talking about!

Adjacency information is needed for the geometry shader, index buffers (in GPU RAM) are of course possible (and the preferred way), retained mode is something different than immediate mode (and afaik D3D6 or 7 already dropped retained mode, only that now also Vista dropped support for those old versions, if i understand that correctly).
Immediate mode in D3D? Was there ever such a thing? And OpenGL will also drop the immediate mode for good reasons (NO it is not supported by hardware and your glVertex*() example is something very different (it doesn't even belong to immediate mode)). Immediate mode can (and certainly will) be provided through helper APIs layered on top, just as it should be.

Stop babbling and ranting about stuff that's clearly your fault due to incompetence!

Jan.

Korval
07-04-2008, 12:44 AM
For some weird reason retained mode was removed

Retained mode was removed because it was terrible. It was an awful way to store vertex data, it had lousy performance compared to decent use of immediate mode, and it didn't keep up with the rest of the API. Plus it sucked up valuable development resources.


I actually can think in some very good uses of triangle fans, specially when it comes to spherish surfaces

How many surfaces are spheres? Or even "spherish"?


At least with OpenGL you can use legacy functions if you don't have time to learn newer stuff

Yes, and because of that, the ARB has had to stall OpenGL development so that the API can be rewritten from scratch. And those legacy functions? They were the first things to go.

Sik the hedgehog
07-04-2008, 01:17 AM
Hey man you are complaining about D3D10 being retarded and give only examples which show, that you really don't know what you are talking about!
...

Adjacency information is needed for the geometry shader, index buffers (in GPU RAM) are of course possible (and the preferred way), retained mode is something different than immediate mode (and afaik D3D6 or 7 already dropped retained mode, only that now also Vista dropped support for those old versions, if i understand that correctly).
Maybe it's just that I don't think shaders are the holy thing like many people do :P (I've even seen tutorials teaching about shaders before teaching what a transformation is, for the record). And I already said it was OK, period. It wasn't so obvious to me, specially being out of context like it was explained from where I took that.


Immediate mode in D3D? Was there ever such a thing? And OpenGL will also drop the immediate mode for good reasons (NO it is not supported by hardware and your glVertex*() example is something very different (it doesn't even belong to immediate mode)). Immediate mode can (and certainly will) be provided through helper APIs layered on top, just as it should be.
Immediate mode by definition is when you send data directly to the GPU (as we should know), and that's pretty much what does D3D normally, so technically D3D had immediate mode already. If it's explicitly mentioned or not, that's another thing.


Stop babbling and ranting about stuff that's clearly your fault due to incompetence!
OK, Sik, you caused another flamewar again >_> Now I really want that Internet blacklist so I can get in =/



I actually can think in some very good uses of triangle fans, specially when it comes to spherish surfaces

How many surfaces are spheres? Or even "spherish"?
Well, several building structures, some complex models, maybe statues (by "spherish" I didn't mean full spheres, it may be just a small slice of a sphere, or even the internal side, or whatever), mechanical parts, etc. There're lots of things that normally get ignored, through yes, often these are artificial things. But they do exist, and in a lot of places.



At least with OpenGL you can use legacy functions if you don't have time to learn newer stuff

Yes, and because of that, the ARB has had to stall OpenGL development so that the API can be rewritten from scratch. And those legacy functions? They were the first things to go.
Yeah, but even if they prevent you from using new functionality, you still can do something, even if not as advanced as you can do with the new stuff. Being forced to relearn everything only to be able to do something I could do before easily simply is stupid. It may be better, yes, but if I don't have time then let me use the old stuff. I don't mean really old stuff, maybe just stuff from the immediately previous version =/

Oh, I better autoban myself from this topic, I started causing trouble again... >_> I swear why when I don't think the same as other people, people always get angry on me and start flaming me >_>

NeARAZ
07-04-2008, 01:48 AM
Adjacency information is needed for the geometry shader, index buffers (in GPU RAM) are of course possible (and the preferred way), retained mode is something different than immediate mode (and afaik D3D6 or 7 already dropped retained mode, only that now also Vista dropped support for those old versions, if i understand that correctly).
Maybe it's just that I don't think shaders are the holy thing like many people do
So now you're saying D3D10 should have not added this new feature (primitives with adjacency info) just because you don't use it? Way to go.


Immediate mode by definition is when you send data directly to the GPU (as we should know), and that's pretty much what does D3D normally, so technically D3D had immediate mode already. If it's explicitly mentioned or not, that's another thing.
Hold on a sec... GPUs were working that way perhaps in 1996. They have moved on quite a bit from the model where all data had to be "pushed" onto them all the time. Wake up!


I actually can think in some very good uses of triangle fans, specially when it comes to spherish surfaces
The point is: while fans are a nice helper in some (rare) situations, they are not faster than lists or strips. And unlike strips, you can't join several fans together with degenerate triangles. So they are slower in practice.

And no, there is no "submission of vertices twice" with triangle lists... ever head of index buffers and GPU post-transform cache?

bobvodka
07-04-2008, 02:43 AM
I guess the excuse they put is the cache, but c'mon, instead of caching the two last vertices, cache the first and the last one...


The cache on a GPU hasn't worked like that in years; they basically arrays which cache the last N vertices and use the index data to perform a look up.

This is why indexed drawing operations are to be prefered, without the index data it's pretty much impossible to sanely use the vertex cache as the GPU has no way of knowing if the vertex data is a repeat it has in the cache or a new set of data.

Jan
07-04-2008, 02:49 AM
"Oh, I better autoban myself from this topic, I started causing trouble again... "

Lol, well you gotta get through all that flaming now ;-)

dor00
07-04-2008, 03:40 AM
The OpenGL working group is meeting regularly and the activity level is high.

I see the Blizzard PR is in affect.
"It'll be done when it's done."
"Can't give more details now, everything subject to change."

Why not. If Blizzard's level of polish gets incorporated into GL3 then that would be a Good Thing. Still, however, OpenGL isn't a product with trade secrets that must be protected so the silence still seems unjustified.

Actually, the fact that Rob Barris know "something" about OpenGL3 give me some hopes... I know Blizzard peoples are best at making surprises.

PS. Rob, why not WoW for Linux? I know is working on MAC, but come one... really Blizzard is NOT a company to STILL listen MS marketing "dreams".

NeARAZ
07-04-2008, 04:09 AM
I know is working on MAC, but come one... really Blizzard is NOT a company to STILL listen MS marketing "dreams".
Last time I checked, there were much fewer Linux users than Mac users. Throw in the work needed to support myriad of different Linux distributions, and you can pretty much infer the answer. Not sure if that counts as "MS marketing dream" though.

...on the other hand, MAC (http://en.wikipedia.org/wiki/MAC_Address) market share is very high! Every computer with a network card is there!

dor00
07-04-2008, 05:28 AM
I know is working on MAC, but come one... really Blizzard is NOT a company to STILL listen MS marketing "dreams".
Last time I checked, there were much fewer Linux users than Mac users. Throw in the work needed to support myriad of different Linux distributions, and you can pretty much infer the answer. Not sure if that counts as "MS marketing dream" though.

...on the other hand, MAC (http://en.wikipedia.org/wiki/MAC_Address) market share is very high! Every computer with a network card is there!

Where did you checked the OS statistics?.. I dont know what to say, but all my friends are switching to Linux, and i see loads of small companies start to do that also.. I only can say, Linux comunity grow up every day.

And yeah, you have right, Linux have some problems, we all know that.

bobvodka
07-04-2008, 05:43 AM
The only source of stats I can find is here (http://www.w3schools.com/browsers/browsers_os.asp)

With the update for June now in we see;
XP : 74.6%
Vista : 10.0%
Linux : 3.7%
OS X : 4.8%

Which confirms NeARAZ's assertion there are more OS X users than Linux ones; meanwhile Vista hits 10% (a jump of 0.7% in the last month), XP continues to climb (both probably picking up people from 2K and Win98 who have only just upgraded), Linux holds stead and OS X contines it's slow, yeah steady, increase.

(At this rate I might start caring about OS X in about another year or two...).

NeARAZ
07-04-2008, 05:52 AM
Where did you checked the OS statistics?
For example here is a list of some sources (http://en.wikipedia.org/wiki/Usage_share_of_desktop_operating_systems). Sure, it's web surfers, not game players, so YMMV. And yes, Linux market share does grow enormously, according to some sources from 0.40% to 0.80% in a year! It's just that "all my friends are using Linux" can often be not a representative sample, you know :)

I am not bashing Linux. It has it's advantages and disadvantages. I was also using Linux for a couple of years long time ago... It's just that when a question of "hey, you support OS X, what about Linux? or are you're eating MS' bull?" comes up, one just has to look at market realities. Maybe for some particular product in some particular market supporting Linux is just not worth the effort.

dor00
07-04-2008, 06:01 AM
Well, thats sad.. honestly, Linux have lots of problems, but all of them can be fixed, except one: GAMES.

I dont want to say to much, but, OpenGL3 is crucial for Linux, can put down in the dust whole os or rise it up.

Mars_999
07-04-2008, 07:14 AM
The only source of stats I can find is here (http://www.w3schools.com/browsers/browsers_os.asp)

With the update for June now in we see;
XP : 74.6%
Vista : 10.0%
Linux : 3.7%
OS X : 4.8%

Which confirms NeARAZ's assertion there are more OS X users than Linux ones; meanwhile Vista hits 10% (a jump of 0.7% in the last month), XP continues to climb (both probably picking up people from 2K and Win98 who have only just upgraded), Linux holds stead and OS X contines it's slow, yeah steady, increase.

(At this rate I might start caring about OS X in about another year or two...).

I think they are wrong...

Mac OS X approaches 8 percent market share in June 2008

http://arstechnica.com/journals/apple.ar...t-share-in-june (http://arstechnica.com/journals/apple.ars/2008/07/01/mac-os-x-approaches-8-percent-market-share-in-june)

Facts are OSX is growing and their Mac sales are going up vs. PC is stale or down a bit. Mac has the high end now to.
http://www.pcworld.com/article/146284/apple_leads_highend_retail_sales.html

bobvodka
07-04-2008, 07:17 AM
All stats are relative to where you get them from it seems, NeARAZ's post above gives a few numbers depending on what one you take (for OS X from 4.33% to 7.94% and Vista from 8.6% to 16.14%).

Facts are also the most blasted OS from MS ever is still doing around twice as well as OS X in 18 months vs however long Apple have been going on about OS X.

Seth Hoffert
07-04-2008, 07:47 AM
Oh nevermind... this thread is already off topic enough as it is, I don't need to bring a ray tracing argument into it.

knackered
07-04-2008, 10:46 AM
just who are all these new people?!
I mean... I've talked my fair share of crap in my time, but this takes the biscuit. I'm seriously thinking of bailing out of this discussion (as some of you are no doubt happy to know).

Zengar
07-04-2008, 12:38 PM
knackered, don't even dream about it! Without you this board would lose so much of it's spirit...

Mars_999
07-04-2008, 06:40 PM
We need flavors of all sorts! ;)

LogicalError
07-05-2008, 05:50 AM
So any news on OpenGL 3.0?
... Is it out yet? ;)

knackered
07-05-2008, 07:52 AM
sorry, just to clarify, I was referring to dor00.

dor00
07-05-2008, 08:25 AM
sorry, just to clarify, I was referring to dor00.

So whats the problem with me?

knackered
07-05-2008, 05:14 PM
what do you think the problem is with you?

dletozeun
07-06-2008, 07:01 AM
So any news on OpenGL 3.0?
... Is it out yet? ;)


Come to SIGGRAPH !

Warshade
07-06-2008, 02:12 PM
PS. Rob, why not WoW for Linux?

I'm very interested to hear the answer for this, too.


Although I do understand that people need to vent their frustration somewhere about the delay, I'd like to make a constructive suggestion for GL3:

Currently you may query the vendor, renderer, version, etc. of an OpenGL driver through glGetString(). Please consider adding 2 more strings/values that can be retrieved.

1) Driver manufacturer URL
2) Driver date

The purpose of this is that programmers may query the driver's date and compare it with the system's current date. If a certain treshold has passed they may prompt the user to visit the URL and follow the instructions there to update the driver. (nothing of this should be provided by OpenGL, besides the 2 bits of information)

Obviously this could also be manually done, but it'd be much better for the lifetime of an application not to store a table with URLs, but rather retrieve the most recent URL from the driver. Imagine a new graphics card vendor entering the game ... existing tables would require updates or not recognize it.

Since the spec is not available right now I can make no suggestion in what object this information could be stored - or how the date could be represented best - but I'm positive the ARB will figure that out in no time if the suggestion is sound.

pudman
07-06-2008, 06:47 PM
Come to SIGGRAPH !

I heard they're giving out beta keys for GL3.0 at SIGGRAPH! And the pet that comes with it? Ignorance! (And if you're extra lucky, you also get Impatiance, although I admit I hacked GL2.x enough to get that one already.)

PkK
07-07-2008, 01:19 AM
1) Driver manufacturer URL
2) Driver date

The purpose of this is that programmers may query the driver's date and compare it with the system's current date. If a certain treshold has passed they may prompt the user to visit the URL and follow the instructions there to update the driver. (nothing of this should be provided by OpenGL, besides the 2 bits of information)


Your message could be confusing to some users.
A message telling them to go to http://www.mesa3d.org to update the driver would confuse those users that don't compiler their drivers from source and would rather wait for their distribution to update the drivers.

Philipp

tanzanite
07-07-2008, 03:26 AM
1) Driver manufacturer URL
2) Driver date
I have long waited for that kind of thing myself - but i would spell some things out more strictly:
3) Url to the driver download page (one click short of download itself) - where the appropriate driver (stable and pre-compiled) is preselected (OS / GPU model / whatever)

If driver author is incapable of giving the 3. option - then empty string is returned (no best fit links!)

Jan
07-07-2008, 05:08 AM
I second that.

Warshade
07-07-2008, 08:37 AM
Please note that the 'threshold' mentioned before was considered to be 3-4 months, not a few weeks. The other scenario in which the URL is needed is when your application cannot continue without certain extensions and a driver update is inevitable.
The idea behind the whole suggestion is to aid in deploying OpenGL applications, in my experience 95% of the problems are related to outdated drivers.

Here's an example what one could get returned:

1) http://ati.amd.com/support/driver.html
2) 2008 / 12 / 31 (probably best to store this in 2 byte and 1 word, rather than a string)

@PkK
Assuming that the update mechanics work flawless and the driver's date is updated aswell, the user should never be prompted to visit any websites, unless your application requires extensions which are not available.

@tanzanite
Was toying with that idea too, but abandoned it because the second URL would require some kind of expiration date. With the other queryable information like the version number it should be possible for most people to figure out what to do at the downloads landing page.

The longevity of the URL is crucial for this to work, if it's invalid after 6 months there is no point in this.

Korval
07-07-2008, 10:52 AM
A message telling them to go to http://www.mesa3d.org to update the driver would confuse those users that don't compiler their drivers from source and would rather wait for their distribution to update the drivers.

No, it would not.

If the program actually needs them to update their drivers, it doesn't matter what the user would like to do. The program cannot function on those drivers. It's that simple. It's like a program saying, "Please buy a videocard I support." There's nothing confusing about that.

And if the program is simply advising them to update their drivers, then the user knows whether this is something that he would like to do or not. Again, no confusion.


2) 2008 / 12 / 31 (probably best to store this in 2 byte and 1 word, rather than a string)

No, it should be a string. The format of the string should be meticulously specified (possibly the ISO standard for dates), but it should not be numbers.

Komat
07-07-2008, 12:08 PM
No, it should be a string. The format of the string should be meticulously specified (possibly the ISO standard for dates), but it should not be numbers.
The problem with the strings containing multicomponent information is that they increase chance that people will process them wrong (especially if they contain date). For example OGL version check in Riddick. It seems to me that single value containing something like number of seconds from well defined date might be safer for most purposes which do not include display of the date in user friendly format.

tanzanite
07-07-2008, 02:06 PM
@tanzanite
Was toying with that idea too, but abandoned it because the second URL would require some kind of expiration date. With the other queryable information like the version number it should be possible for most people to figure out what to do at the downloads landing page.

The longevity of the URL is crucial for this to work, if it's invalid after 6 months there is no point in this.

Let's rebuild the idea.

Problem:
* unused opportunities (feature/performance) due outdated drivers.
* broken drivers that have fixed versions already available.
* new bugs from new drivers (if driver update becomes trivial - this problem gets noticeable [things that worked before break suddenly and the user might not even notice that things that were broken/unusable before are now working. aka keep what works , reject what doesn't]. Current "update model" largely masks this problem). No idea what helps here (khm! GL3?).

Solution 1 (preferred):
* driver keeps track of new releases itself (like windows update. Preferably trough OS provided means/services [i am sick of every program having its own update tracker - unfortunately, no such service exists])

Solution 2 (the last resort. till the OS provides the needed service - or till the cows come home):
* ogl provides some means for the application using it to suggest an update when necessary. This is bound to get messy ...
a) should not ask for update when no update is available.
b) should make the update process simple and safe (x_x).

for a) contact with the provider is needed.
for b) direct link to needed resources is needed - no driver hunt.

a solves b giving the following:

* OGL gives an unspecified token of information and a place (by preferably some simple and unproblematic protocol. http, port 80) to send it to.
* Your app queries using given information.
* Answer is the link b) or that no new driver is available.
* Your app acts accordingly.

... correcting for typos and such - that should do it :P (hope i didn't write some nonsense, engrish definitely isn't where i shine)

Korval
07-07-2008, 08:12 PM
The problem with the strings containing multicomponent information is that they increase chance that people will process them wrong (especially if they contain date).

Tough. Unlike other strings (like GL 2.x's version), the format will be very well specified. We don't want to create a situation like with GL 2.x where the major and minor version numbers were independently querriable, and people just checked the minor version. The function should return all of the relevant data in one call.


OGL gives an unspecified token of information and a place (by preferably some simple and unproblematic protocol. http, port 80) to send it to.

Absolutely not. Requiring networks access to run a program that may not need it is totally unacceptable. As is sending any information over the internet without the user's explicit or implicit approval. A GL application should not have to be online.

V-man
07-07-2008, 10:49 PM
The problem with the strings containing multicomponent information is that they increase chance that people will process them wrong (especially if they contain date).

Tough. Unlike other strings (like GL 2.x's version), the format will be very well specified. We don't want to create a situation like with GL 2.x where the major and minor version numbers were independently querriable, and people just checked the minor version. The function should return all of the relevant data in one call.


Actually, it's a good idea to have major and minor. glGetIntegerv can return both at the same time. Also, OpenAL has major and minor version.

Jan
07-08-2008, 12:26 AM
"and people just checked the minor version."

I really don't care for people who are simply too stupid to do it right.

Komat
07-08-2008, 01:45 AM
Tough. Unlike other strings (like GL 2.x's version), the format will be very well specified.
The GL_VERSION string has first part before the space well specified. Actually some people got incorrectly even Windows version check which returns structure with major and minor fields. This is why I would favor having API which returns single value containing entire information packed in such way that compare (imho the most common operation done on it) just works as expected.


I really don't care for people who are simply too stupid to do it right.
I do because I might end using such program. Some bug can always happen and if the value in question does not change for long time (e.g. the OpenGL version), it can easily be unnoticed (e.g. Version in Riddick or GLQuake and Metal of honor extension buffer parsing).

tanzanite
07-08-2008, 02:17 AM
That is the problem with the "as a last resort" solution - it gets a bit messy.


Absolutely not. Requiring networks access to run a program that may not need it is totally unacceptable.OGL does not require nor be aware of network access.


As is sending any information over the internet without the user's explicit or implicit approval. A GL application should not have to be online.Again, this is in the hands of the App author - nothing to do with OGL.

Example to explain my line of thought (app with friendly behavior added):
* app asks the age of drivers (if did not ask in last week or so and "do not ask again" is not checked)
* if drivers are older than some threshold, continue with:
* inform the user and give the option (if have internet connection) to check for new divers. + option "do not ask again"
* if permission is granted, continue with:
* get the token (should be required to be 'plain' text)
* get the address from where to query for new drivers
* make the query
* act accordingly to returned data

So, what is wrong with that? (besides that drivers is the responsibility of the OS and some application should not care about it)

NeARAZ
07-08-2008, 04:24 AM
Tough. Unlike other strings (like GL 2.x's version), the format will be very well specified.
The GL_VERSION string has first part before the space well specified.
On a somewhat tangential topic... some drivers do get that incorrectly. Some examples: "2.06a.00" or "1.14a" (from SIS drivers). I wonder how can one trust drivers when they are able to get even a very simple thing like this wrong?

Jan
07-08-2008, 04:38 AM
I like the idea. The driver should not return an URL that can be used to download the latest driver directly through the app, it should just be a general URL, where one can get the latest drivers. If the vendor has a fancy page, such that he can provide a direct URL to the driver for the actual card the user has, let it do so. But the app should only use it to direct the user to that page, instead of guessing itself.

Already several months (a year?) ago i suggested to improve the whole driver / vender / hardware information, that you can query.

For example i want RELIABLE vendor-strings, that are assigned by the ARB. For example nVidia would return "NV" and ATI would return "ATI" and they cannot change that EVER, since it is for internal purposes. Then one can additionally query gl for a fancy string to display, which might be "nVidia Corporation, Geforce 280 GTX Super Ultra Awesome SSE5 1000 Watt EPICWIN".

As a driver version, i would like to have a major and minor number, which will be queried as ints, separately. If it is a string, some vendor will always include useless information, or change the format at some time. It seems to be a race between vendors, which one can violate the spec in more subtle ways, and both are really good at it, so expect them to break everything that's breakable, the sooner or later.

Oh, and YES, i would like to be able to query the card for the amount of onboard RAM (i know we had this discussion a billionth times now).

Jan.

V-man
07-08-2008, 02:29 PM
The URL thing sounds stupid if you ask me.

If they can change it so that we wouldn't need to analyze a string, it would be nice. Instead of glGetString(GL_EXTENSIONS), create a glGetIntegerv(GL_EXT_framebuffer_object, &param) which return TRUE or FALSE in param. It is not a big deal but it is more elegant if you ask me.
Also, glGetIntegerv(GL_OPENGL_VERSION, minor_and_major)
Also, glGetIntegerv(GL_VENDOR, param) where param is GL_VENDOR_NVIDIA, GL_VENDOR_AMD, GL_VENDOR_INTEL

Rick Yorgason
07-08-2008, 04:01 PM
I don't think apps have any place telling the users that their drivers are out of date. It would be annoying, and there's too many ways for the app to get it wrong, particularly after the app or video card is discontinued.

It does make sense for apps to inform the user that the driver version they're using is incompatible with the app, but the date of the driver wouldn't be the best way to determine that; ideally, we would have a reliable way to compare driver versions. For instance:


if(driverName == "someName")
{
if(driverVersion <= knownIncompatibleDriverVersion)
{
informUserOfIncompatibility("http://someurl");
}
}

Brolingstanz
07-08-2008, 07:19 PM
Tough. Unlike other strings (like GL 2.x's version), the format will be very well specified.
The GL_VERSION string has first part before the space well specified.
On a somewhat tangential topic... some drivers do get that incorrectly. Some examples: "2.06a.00" or "1.14a" (from SIS drivers). I wonder how can one trust drivers when they are able to get even a very simple thing like this wrong?

Well, back to the drawing board for me. I'm currently looking for 2 dots, treating the first 2 numbers as major.minor (point release being optional). That's what I get for not reading the spec as carefully as I should :p

Brolingstanz
07-08-2008, 07:46 PM
Anyone care to venture a guess as to whether BindBuffer and VertexAttribPointer will remain coupled in GL3 or beyond?

Rob Barris
07-08-2008, 08:20 PM
I'd venture that questions like yours will be much easier to answer after SIGGRAPH. No guess.

Jan
07-09-2008, 12:08 AM
"I don't think apps have any place telling the users that their drivers are out of date. It would be annoying, and there's too many ways for the app to get it wrong, particularly after the app or video card is discontinued."

Valve's Steam does it, and i think it's a good idea (also there is a "don't ask again"-checkbbox).

Ilian Dinev
07-09-2008, 04:27 AM
Valve's games also require your OS to have a perfectly working WMI... to load their shaders. Just search for "shaderapidx9.dll" and its fixes that require complete clean reinstall of everything (starting with Windows), then keeping certain vulnerabilities to your network (thanks to which all my 10k .exe files got infected recently), and avoiding installation of several popular IMs. Not to mention that in my case it was Valve's software that garbled WMI, on top of it.

But anyway, later drivers aren't always nicer. Steam has been bugging people enough times to install latest drivers, when their games ran slower or crashed on said newer drivers. I think a better real approach would be to have the gamedev specify a list of recommended drivers for a given game/engine. This can be a list, compiled by beta-testers or even end-users. (currently users search the whole net for KB on such mix-and-match problems).

elFarto
07-09-2008, 01:03 PM
Valve's games also require your OS to have a perfectly working WMI... to load their shaders. Just search for "shaderapidx9.dll" and its fixes that require complete clean reinstall of everything (starting with Windows).

I had this problem just after installing Windows XP x64. Took me a few hours to fix it, but I didn't have to reinstall Windows.

Why exactly do they need WMI to load shaders anyway?

Regards
elFarto

pudman
07-09-2008, 01:49 PM
I'd venture that questions like yours will be much easier to answer after SIGGRAPH. No guess.

I'd guess that the SIGGRAPH BOF is going to be incredible. But I wouldn't venture that.

When will the schedule for the BOF be available?

obirsoy
07-09-2008, 02:18 PM
http://www.siggraph.org/s2008/attendees/birds/

Open GL BOF
Wilshire Grand Hotel
Wilshire Room
6 - 8 pm

PS: Note the "Open GL". When I first got to the page, it gave me 10 sec shock. Searching for "OpenGL" did not return anything.

Mars_999
07-09-2008, 04:15 PM
LOl just to make everyone happy, DX11 is out soon! :) SM5.0 and from what I hear Nvidia is skipping DX10.1 and moving to DX11!

LOL got to love the computer industry as it moves forward all the time. DX10 will end up like DX7, hell I can't even remember DX7.

bobvodka
07-09-2008, 04:38 PM
Mean while in ARB land... *crickets chirping*

pudman
07-09-2008, 06:42 PM
http://www.siggraph.org/s2008/attendees/birds/

I actually meant the presentation schedule, not the date of the event. There were 8 presentations at the GL 2007 BOF, but I can't remember if it was known before the event what would be presented.

I hope someone (or more than one!) on the ARB posts a GL3.0 post-mortem after this SIGGRAPH. I want to know all about the intra-ARB conflicts! Who cares about GL3 at this point, Kronos could make some serious money with a geek reality show about this. ...Ok, I wouldn't pay to see a bunch of nerds talk shop but a camera in your face all the time should inspire some motivation to GET IT DONE ALREADY.

Rick Yorgason
07-10-2008, 02:02 AM
Valve's Steam does it, and i think it's a good idea (also there is a "don't ask again"-checkbbox).
Fair enough, pretend I said "I don't think most apps have any place telling the users that their drivers are out of date."

My primary point still stands, though: checking the date of the driver is not a good way to do this.

elFarto
07-10-2008, 07:55 AM
Seems opengl3.org has been updated:

"Get the inside scoop on OpenGL from the ARB and leading OpenGL companies:

* OpenGL 3.0 Specification Overview
* OpenGL hardware and driver plans - AMD, Intel, NVIDIA
* Developer's perspective on OpenGL 3.0
* OpenGL and the new Khronos Compute Working Group
* and more..."

So my guess is, the spec will be finished and the drivers will be released Soon™.

Regards
elFarto

MZ
07-10-2008, 08:37 AM
LOl just to make everyone happy, DX11 is out soon! :) SM5.0 and from what I hear Nvidia is skipping DX10.1 and moving to DX11!
The fact that they are "skipping" DX10.1 (and thus, SM4.1) is probably due to the fact that Microsoft decided you can't get DX10.1 compliance without also supporting WDDM 2.1. Currently, only Radeons 3000 and 4000 can do that.

SM4.1 is so tiny improvement over SM4.0 that it seems unreasonable to believe nVidia couldn't have easily implemented it. They have, after all, just released their third series of DX10 GPUs (8000, 9000 and 200). And they were the first IHV there, over half year before Ati.

WDDM 2.1, on the other hand, is far from trivial improvement. They introduced texture memory paging and fine grained preemptive multitasking. GPU is required to smoothly switch rendering tasks on such events like texture memory page fault, and all that in the middle of rendering rendering a big triangle. Think about it. If we are accustomed to the fact that mere change of render state may cause pipeline flush (among other things), then how about entire GPU context switch in the middle of rendering a primitive?

Of course, I "know" the hardware as much as the next guy here, but to me this stuff sounds far more challenging to implement then the minor features that SM4.1 brings. Perhaps, nVidia may have decided that rather than invest resources into WDDM 2 compliance (which, while technically profound, won't affect games), it would be better strategy to sacrifice SM4.1, and postpone both till next gen.

bobvodka
07-10-2008, 09:48 AM
The AMD and NV GPU archs are (despite my earlier rambling) reasonably the same in this regard.

Both are massively parallel and both already perform fine grain context switching; in fact it's belived that NV do it at the pipeline level with each section of the pipeline effectively working on a different context.

AMD probably get some help when it comes to WDDM2.1 compliance due to their massive (realtively speaking) on chip fileregisters and caches making it easier to swap things in and out.

Finally, DX10.1, while minor, isn't simply SM4.1. (http://msdn.microsoft.com/en-us/library/bb694530(VS.85).aspx).

End of the day NV's hardware simply can't do it and that is why they have been "playing down" DX10.1 even before it was released. Right now, imo, AMD have the most advanced hardware out there and certainly have the best price:performace ratio going on (HD4870 approx 10fps slower than the GTX280 and costing less than half it's price? oh hell yes!); it's just a shame for people who use OpenGL that AMD don't support all the DX10(.1) features via extensions unlike NV.

Hell, it took them around 2 years to expose an experimental extension for the programmable tessalator...

V-man
07-10-2008, 10:06 AM
Hell, it took them around 2 years to expose an experimental extension for the programmable tessalator...

AMD/ATI seems to have taken the "if it's not core, then we won't support it" route. It's a shame because it makes their product look like 6 year old GPU. If you can't hear it sing, then what's the point of buying it?

pudman
07-10-2008, 10:44 AM
It's a shame because it makes their product look like 6 year old GPU.

...in OpenGL.

Maybe GL3 will mean they get up to date?

The "OpenGL 3.0 Specification Overview" sounds to me like Pipeline #5. The real news will be the actual status of the spec and the development status of drivers. Remember, it was "almost done" last year, too, before the (presumed) rewrite.

Timothy Farrar
07-11-2008, 08:34 AM
Both are massively parallel and both already perform fine grain context switching; in fact it's belived that NV do it at the pipeline level with each section of the pipeline effectively working on a different context.

You would think if NVidia hardware had fine grain context switching, that CUDA would have support for parallel execution of multiple kernels (which from my knowledge it doesn't other than when one kernel ends and another begins).

-NiCo-
07-11-2008, 08:41 AM
Nvidia has fine grain context switching within a kernel. A kernel execution corresponds to multiple block executions. If the processing of one block is stalled, it can immediately switch to processing another block and return to processing the first block when it isn't stalled anymore.

bobvodka
07-11-2008, 08:55 AM
frankly Anandtech can explain it better than me (http://www.anandtech.com/video/showdoc.aspx?i=3334&p=4) :D

MZ
07-11-2008, 11:07 AM
The AMD and NV GPU archs are (despite my earlier rambling) reasonably the same in this regard.

Both are massively parallel and both already perform fine grain context switching; (...)
4 out of 6 product lines in this generation don't support DX10.1 (Radeon 2000, GeForce 8000, 9000 and 200). There must be serious, technical cause for this. Is this related to SM4.1, WDDM 2 or both, we don't know because both things were placed under DX10.1 umbrella. And by the way, this is another case of artificial tying unrelated things in DirectX world. What a nasty habit.

Finally, DX10.1, while minor, isn't simply SM4.1. (http://msdn.microsoft.com/en-us/library/bb694530(VS.85).aspx).
Depends on how one likes to define "SM".

(HD4870 approx 10fps slower than the GTX280 and costing less than half it's price? oh hell yes!)
And all that is a little weird, if you consider that on paper HD4870 has twice more raw shader power than GTX280.

Dark Photon
07-11-2008, 12:23 PM
(HD4870 approx 10fps slower than the GTX280 and costing less than half it's price? oh hell yes!)
While we're bouncing all around GL land, I'd like to ask why even some of the experts here still talk in fps.

fps deltas mean absolutely nothing without a reference point. For instance:

10 fps slower than 30Hz = 16.6ms (milliseconds) slower per frame
10 fps slower than 60Hz = 3.3ms slower per frame
10 fps slower than 120Hz = 0.76ms slower per frame

I think you'll agree those are huge differences in performance, ...and all timing deltas represented by the nebulous "10 fps slower".

Besides that, talking in fps yields non-linear values that aren't that useful by themselves. An increase in 60 to 120fps sounds really great compared to an increase from 30 to 60 fps, when in fact the latter is much more impressive (60->120Hz = 8.3ms per frame optimized away, while 30->60Hz = 16.7ms per frame optimized away).

bobvodka
07-11-2008, 12:37 PM
Yes, but then the R600 also had lots and look what happened there. Also, I think my comment misrepresents the HD4870; what I should have said was 'at most 10fps behind'

The main issue comes from the work you ask the shader units todo, due to the difference in hardware implimentation the speed they can deal with it varies.

However, in an effort to correct my slight mispeak earlier;


COD4 @1920*1200 4xAA
GTX280 90.9fps
HD4870 88.4

ET:QW @ 1920*1200 4xAA
GTX280 99
HD4870 96.8

Assassin's Creed @ 1920*1200 no AA
GTX280 55.5
HD4870 55

Assassin's Creed @ 2560*1600 no AA
GTX280 45
HD4870 43.5


The Witcher @ 1920*1200 2xAA
GTX280 55.1
HD4870 48

BioShock @ 1920*1200 No AA
GTX280 96.7
HD4870 107.7
HD4850 86.8 (included as it's nipping at the heals of the GTX280)

Oblivion @ 1920*1200 4xAA 16xAF
GTX280 51.1
GTX260 43
HD4870 41.5


Again, see Anandtech for the full story, but personally for the price I see the AMD offering as insane.

Also, the HD4870 has around 26GB/sec less bandwidth, which shows a bit when you look at benchmarks at the higher rez's, for example;
COD4 @1680*1050
GTX280 94fps
HD4870 98.9
COD4 @1920*1200
GTX280 90.9fps
HD4870 88.4

zed
07-11-2008, 03:23 PM
>> fps deltas mean absolutely nothing without a reference point.

true, I've seen this mentioned quite a bit.
but also milliseconds ( or whatever time unit ) also mean nothing without a reference point, thus they are equally invalid as using fps.

percentage OTOH is a valid measurement

Dark Photon
07-11-2008, 04:30 PM
>> fps deltas mean absolutely nothing without a reference point.

true, I've seen this mentioned quite a bit.
but also milliseconds ( or whatever time unit ) also mean nothing without a reference point, thus they are equally invalid as using fps...percentage OTOH is a valid measurement
I guess it depends what your goal is. If % improvement is it, % makes sense. Otherwise I'd much rather see "I implemented this specific change to this specific algorithm and saved 5.5ms of draw time. That's real and tangible. That's useful. Unlike: "I got 10fps improvement", which means absolutely nothing other than ,maybe, "better". How much? No clue.

CatDog
07-11-2008, 05:46 PM
"I got 10fps improvement", which means absolutely nothing other than ,maybe, "better". How much? No clue.
Ah, yes. Thats exactly the reason why I prefer talking about fps.

CatDog

knackered
07-11-2008, 07:24 PM
I always seem to use batches-per-second and million-tris-per-second. If I'm tuning a pixel shader I draw a full-screen quad and work out the million-pixels-per-second.
FPS or even % are pretty meaningless unless you have information about the data being rendered, and the spec of the card (tri-throughput, fill-rate etc.)

Brolingstanz
07-11-2008, 08:51 PM
True, if you have enough information you can infer a good bit from most any measure; however speaking in general terms with no such information can and often does produce a simoon of speculation ;-)

Stephen A
07-12-2008, 02:47 PM
http://opengl3.org

A little lacking in the marketing department (the photo is, well, awful), but otherwise great! :)

Edit; Oops, this was mentioned several days ago. The comment on the photo still stands though. :)

Korval
07-12-2008, 03:30 PM
# OpenGL 3.0 Specification Overview
# OpenGL hardware and driver plans - AMD, Intel, NVIDIA
# Developer's perspective on OpenGL 3.0
# The new Khronos Compute Working Group and how that affects OpenGL

#2 is probably the most important thing that they'll be discussing (except for the stuff that they won't be discussing). How committed they are, specifically Intel with its millions of low-end graphics chips that provide the worst support ever for OpenGL, to supporting OpenGL 3.0 will be key to its future utility.

It'll be interesting to see how they apologize for/cover up/gloss over the lengthy 1 year delay of GL 3.0. Personally, I'm expecting that they simply won't address it, instead taking their usual tactic of complete and total disdane for the GL community by ignoring the fact that this should have been done last year.

Rob Barris
07-12-2008, 08:44 PM
Regarding presentation content being drafted for the OpenGL BOF at SIGGRAPH this year; if you had a top-10-or-more list of specific topics you'd like touched on, what would some of them be ?

For brevity, maybe we could agree to sweep all of the "why has it been so quiet since Oct-07" related questions into a single topic, maybe call that one "the path that has been taken" - plainly that's an important one to touch on.

Korval
07-12-2008, 09:23 PM
Regarding presentation content being drafted for the OpenGL BOF at SIGGRAPH this year; if you had a top-10-or-more list of specific topics you'd like touched on, what would some of them be ?

OK, then I'll condense it into one query:

#1: Why is this 1 year later than you said, and why did everything go quiet for 9 months? And (depending on the answer. ie: if it isn't really good or something entirely out of their control) how can you possibly expect us to every trust you guys again, after your track record?

After that:

#2: What assurances do we have that GL 3.0 will be supported with mature, compliant implementations, unlike the support for GL 2.x? That is, can we assume that GL 2.x support will be how GL 3.0 is supported, or do we have any assurances that it will be compliantly supported? Will drivers be tested against a conformance test suite, and will this test suite be comprehensive?

#3: What is the minimum "hardware level" for GL 3.0 support? Will there be any mechanism for detecting "levels" of support? The original GL 3.0 was broken in 3.0 (DX9.0), 3.1 (DX9.0), and Mt. Evans (DX10+), which potentially made detecting the level of minimum hardware support a simple GL version check. Or testing for certain extension functions. Does GL 3.0 have anything similar?

#4: If GL 3.0 does not follow the basic design that was described to us in previous newsletters, why doesn't it? What was wrong with that design?

#5: Will there be some mechanism for compiling a "binary blob" of a shader and then reloading it into the driver at a later date? This was on-deck for consideration in Longs Peak Reloaded.

#6: We on this board have often discussed a particular feature for vertex rendering. The short term for this is "attribute offset indexed rendering". This allows you to pass a number to glDrawElements that is an offset to be applied to each index before dereferencing that index into a pointer. Will GL 3.0 provide this (which D3D has previously provided for quite some time)? This was likewise on-deck for consideration in Reloaded.

Can't think of others. I may add to it as I think about it.

Rob Barris
07-12-2008, 09:40 PM
Thanks Korval, those are great questions.

Brolingstanz
07-12-2008, 11:13 PM
I really like the reflected OpenGL logo.

Stephen A
07-13-2008, 01:44 AM
#7: Will the actual .spec files be released for GL3? Can we expect an xml-based format? (The .spec files are necessary for non-C OpenGL bindings)

#8: How will GL3 interact with the underlying platform (i.e. context creation)? Will WGL/GLX/AGL be extended for GL3 support? Will we still need the roundabout trip for multisampled visuals/pixel formats?

#9: Can GL2 contexts exist side-by-side with GL3? How about resource sharing? (IIRC this was mentioned at some point, but my gut feeling says this feature didn't make the cut - for good reasons, too.)

elFarto
07-13-2008, 02:05 AM
#8: How will GL3 interact with the underlying platform (i.e. context creation)? Will WGL/GLX/AGL be extended for GL3 support? Will we still need the roundabout trip for multisampled visuals/pixel formats?
#8.1: Will GL3 still use OpenGL32.dll, or have you beaten Microsoft into submission and got a new DLL? Is/Has EGL been considered?

Regards
elFarto

CatDog
07-13-2008, 03:52 AM
Lol, yes, nice logo! :)

#10: Provide a reliable roadmap for all the fancy things you plan to do.

CatDog

Jan
07-13-2008, 07:55 AM
Oh no! Already 10 great questions! Oh well...

#11: What would be a REALISTIC time-frame for COMPLETE/reliable OpenGL 3.0 support (no beta-status, but also only the basic 3.0 API) on Windows (XP/Vista), Linux, Mac. Each vendor should give his own assumptions, and please no PR-crap, it wouldn't buy you anything.

Jan.

mbien
07-13-2008, 10:55 AM
I really like the reflected OpenGL logo.
its probably rendered with OpenGL 3.0 (GL_REFLECTED_LOGO_EXT) and was the main reason for the delay ;)

Rob Barris
07-13-2008, 03:45 PM
I did ask *each poster* to put up their top-10... not meaning to imply that there was only interest in responding to a grand total of ten questions overall.

(Also if you could indicate if you are coming to the BOF or not..)

CatDog
07-13-2008, 04:13 PM
If you manage to answer (!) the questions given above, it would be by far more than I'd expect.

CatDog

Fitz
07-13-2008, 06:48 PM
Q: I'd like to hear something about glFX during SIGGRAPH.

Dark Photon
07-13-2008, 07:20 PM
http://opengl3.orgA little lacking in the marketing department (the photo is, well, awful)
Yeah, well it's a bunch of graphics geeks, not the Sports Illustrated swimsuit girls. What did you expect? :p

Dark Photon
07-13-2008, 07:50 PM
I did ask *each poster* to put up their top-10... ...(Also if you could indicate if you are coming to the BOF or not..)
Definitely coming to the BOF.

Others have already put forward great questions. Here's one more:

#12 Which GPU vendors are "still" 100% committed to developing OpenGL drivers for Linux (now and in the future), and what are their plans? Especially interested in hearing from Intel, though I know the Larrabee guys are doing some other gigs at SIGGRAPH too.

(And lest ye write me off as a two-bit garage games developer, let me mention the company I work for develops 6+ figure simulators built on OpenGL and Linux.)

If questions stay geared toward vendor support and GL3 -- what specifically blew up last year, and how what it was intended to accomplish (simplified interface, much harder to get off the "fast path", much less vendor-specific voodoo required to develop speedy GL apps, simpler/cheaper driver devel by vendors, etc.) will be accomplished, then I have no other top 10 questions.

zed
07-13-2008, 08:08 PM
bugger that logo, heres my suggestion for a new logo
http://www.zedzeek.com/ogl.png

I could also write a theme song if ppl desire, gotta create the image!!

#1/ the reason for the lack of info in the last year
#2/ for the ihv's, any chance of ogl es drivers?

Mars_999
07-13-2008, 10:37 PM
Awesome Zed!! LOL

Hampel
07-14-2008, 12:26 AM
@zed: what about using three dots instead of only one? :-)

Jan
07-14-2008, 12:53 AM
"I did ask *each poster* to put up their top-10"

Well, i was a bit ironic with my 11th question. But the already mentioned 10 questions are really of interest to me, so why repeat them and litter the whole thread with duplicates. It's much easier for you to compile a list this way, too.

Jan.

NeARAZ
07-14-2008, 05:37 AM
Regarding presentation content being drafted for the OpenGL BOF at SIGGRAPH this year; if you had a top-10-or-more list of specific topics you'd like touched on, what would some of them be ?
1. Explanation of everything that happened in the last year: delays, silence, in short, all the public relations fiasco.

2. Plans towards making GL stable in real world. How committed are IHVs, who will test drivers with extensive test suites, will test suites will be made public, ...

3. Plans towards making GLSL working in real world. Binary precompiled shaders, single compiler that one can embed into their own app, API for getting back actual instruction/register/slot/cycle usage from the driver, single API for indicating software fallbacks, ...

4. What's the actual "vision" for OpenGL? A single graphics API that works everywhere is a myth and no one actually needs that. Consoles have their own APIs, Windows is serviced with D3D just fine (and we don't have a proof of OpenGL taking over that). Is OpenGL's "vision" thus servicing other OSes (Linux, OS X)? Something else?

...actually, thorough answers to the above would be enough for start.

(I'm not attending Siggraph btw...)

Xmas
07-14-2008, 07:14 AM
#6: We on this board have often discussed a particular feature for vertex rendering. The short term for this is "attribute offset indexed rendering". This allows you to pass a number to glDrawElements that is an offset to be applied to each index before dereferencing that index into a pointer. Will GL 3.0 provide this (which D3D has previously provided for quite some time)? This was likewise on-deck for consideration in Reloaded.
Isn't that equivalent to just adding an offset to the attribute pointers?

Jan
07-14-2008, 09:45 AM
It is.

The problem is, that at glVertexPointer all the setup is done by the driver, so calling that function several times with different offsets will make your app a slideshow. That is why this additional semantics for an offset was proposed (as D3D has it for a long time), to tell the driver simply to add this offset and NOT do all the setup again.

Jan.

Lord crc
07-14-2008, 01:54 PM
What's preventing the driver from clearing a flag in BindBuffer so that it knows it has to do the setup all over next time VertexPointer is called?

pudman
07-14-2008, 02:33 PM
For brevity, maybe we could agree to sweep all of the "why has it been so quiet since Oct-07" related questions into a single topic, maybe call that one "the path that has been taken" - plainly that's an important one to touch on.

Based on the questions so far I say much of the BOF should be about exactly this topic.

As a comparison, no one complains (as vocally) about Microsoft's development of D3D behind closed doors. The reason is likely that:
That's the way they always do it They do try to exploit current/future hardware features (thus the terms "DX10 hardware", "SM4.0 hardware") Driver's will work (usually) and be compliant. We have a vague sense of a road map (rumored features of DX11)
Now compare that to OpenGL. I still don't see a justification for the closed-doors activities. If the activities were more visible we'd:
Already have a reasonable idea of what to expect in GL3 Have at least a vague idea of what the future of GL holds Possibly have an idea of the progress of driver development Care more about the technical details to be revealed at the BOF
What could be negative about any of that?

My question to add to the list:
#25 What is to be expected beyond GL3? Are there still concepts such as "Longs Peak reloaded" and "Mount Evans"? How will extensions work with GL3 and beyond?

knackered
07-14-2008, 04:40 PM
What's preventing the driver from clearing a flag in BindBuffer so that it knows it has to do the setup all over next time VertexPointer is called?
yeah, that doesn't sound like an ugly hack one little bit.

bobvodka
07-14-2008, 06:09 PM
As a comparison, no one complains (as vocally) about Microsoft's development of D3D behind closed doors. The reason is likely that:

The reason is, unlike the ARB, MS get [censored] done. Take the DX SDK for example, this gets updated every 2 months, pretty much like clock work.

The ARB can do all they want behind closed doors as long as [censored] gets done in a timely manner.

pudman
07-14-2008, 10:25 PM
The reason is, unlike the ARB, MS get [censored] done.

True. I forgot that bullet point.

Even if we given GL the "design by committee" benefit of the doubt with regards to speed it still doesn't make sense why they can't get [censored] done in a "reasonable" amount of time. I still would like, if they are going to take forever, to know why it's taking forever. It is OPEN GL.

Rick Yorgason
07-14-2008, 10:31 PM
Kind of like WG21. I've spent countless hours reading through the C++0x docs. It would be nice if the ARB was so open! They must have some sort of documentation. Minutes, at the very least!

Korval's first 6 questions were great, so I'll put a vote in for all of those, as well as a vote for the .spec question.

Oh, and unfortunately SIGGRAPH is a bit far for me to travel, so I'll waiting for the answers in Internet Land.

Xmas
07-15-2008, 02:50 AM
The problem is, that at glVertexPointer all the setup is done by the driver, so calling that function several times with different offsets will make your app a slideshow. That is why this additional semantics for an offset was proposed (as D3D has it for a long time), to tell the driver simply to add this offset and NOT do all the setup again.
I'd argue it's the problem of a particular driver if it does a lot of work when all you do is change the pointer.

Jan
07-15-2008, 05:16 AM
We had a lengthy discussion about this whole thing some time ago and i won't repeat it.

MZ
07-15-2008, 05:38 AM
Isn't that equivalent to just adding an offset to the attribute pointers?
I'll explain it to you using an analogy.

Imagine you have a task to do:
You want to shift your PC case by 20cm to the right.

Direct3D and Glide way: you apply gentle pressure to your PC case in right direction, until it moves by 20cm.

OpenGL way: you take a screwdriver and disassemble your PC to basic components. Then, piece by piece, you reassemble it at new location, 20cm to the right. When done, you carefully check everything to ensure you have assembled your PC in the same state as it was before (read: driver overhead).

Back to graphics. Direct3D has Vertex Declaration, Glide has Vertex Layout, OpenGL has a problem. The "index offset" is just one case where it can be encountered.

V-man
07-15-2008, 07:08 AM
That attribute thing is ancient history dude. I thought it was going to be added to Mesa as some extension. You would call glIndexOffsetEXT(integer) but I guess it died off. SO forget it already.


Back to graphics. Direct3D has Vertex Declaration, Glide has Vertex Layout, OpenGL has a problem. The "index offset" is just one case where it can be encountered.
What are vertex declarations for when you have GL's flexible setup.

knackered
07-15-2008, 07:26 AM
a particular vertex stream setup should be considered an object.

Xmas
07-15-2008, 07:28 AM
Like this?
http://www.opengl.org/registry/specs/APPLE/vertex_array_object.txt

Brolingstanz
07-15-2008, 08:09 AM
That extension was mentioned in the last newsletter (in this very context no less)

http://www.opengl.org/pipeline/article/vol004_4/

It's an awfully convenient feature in DX though, and a real time saver to boot...

knackered
07-15-2008, 09:03 AM
the index offset shouldn't be part of the object though - it should be part of the draw call.

NeARAZ
07-15-2008, 09:17 AM
As a comparison, no one complains (as vocally) about Microsoft's development of D3D behind closed doors. The reason is likely that:
I think the reason is that D3D development is "open just enough". MS does go out to game developers and ask them what do they want, what they would like to be improved, and how. It does the same with IHVs. And with some people who are "important enough in graphics or D3D land" (this includes various well known graphics people, D3D MVPs, and so on).

Yes, MS does act as the final aggregator/moderator of all the suggestions and wishes. And they get the stuff done.

So to me, it seems as if OpenGL is not that much more "open" than D3D (*)... Except that OpenGL does not have a single authoritative decision maker, and does not seem to be able to get stuff done either.

(*) Who is on ARB? IHVs and various "important companies / people". Who MS talks to when designing next D3D? IHVs and various "important companies / people". Find a difference.

Lord crc
07-15-2008, 09:40 AM
yeah, that doesn't sound like an ugly hack one little bit.

You mean like detecting the name of the executable making the OpenGL calls to adjust the settings of the driver?

Anyway, no, I don't think a caching mechanism is a hack.


the index offset shouldn't be part of the object though - it should be part of the draw call.

Fair enough.

knackered
07-15-2008, 10:14 AM
Anyway, no, I don't think a caching mechanism is a hack.
If it's an unspecified implementation specific caching mechanism, then yes, it's a hack.

Xmas
07-15-2008, 10:47 AM
the index offset shouldn't be part of the object though - it should be part of the draw call.
To be honest I'd prefer to see a single object that describes the mesh to be rendered - including the draw call parameters.


If it's an unspecified implementation specific caching mechanism, then yes, it's a hack.
OpenGL specifies behaviour, not implementation (nor performance characteristics). Following your line of reasoning all implementations would just be huge accumulations of hacks by definition.

knackered
07-15-2008, 11:24 AM
true, what I should have said was that me writing code that relies on an IHV's possible caching mechanism to get the performance I need would be a hack.

Xmas
07-15-2008, 11:56 AM
You're always relying on implementations being fast for the specific call sequence you're using. That's not a hack, it's implicit in the fact that OpenGL doesn't give performance guarantees. What the implementation does internally doesn't matter, it's the same whether it uses caching to avoid doing some work or whether it simply doesn't have to do much work at all.

knackered
07-15-2008, 12:13 PM
Completely re-specifying buffer bindings is likely to be expensive. Like swapping a texture used to be. To assume that the IHV has an implementation that doesn't make it expensive is a finger-in-the-air hack in my opinion. However, to have a mechanism whereby you do not need to completely re-specify buffer bindings is not a hack, even though no guarantees are given that it would be any faster. The fact is that the existence of the mechanism implies better performance, and will likely be mentioned as a motive for the mechanism in the specification for said mechanism.

Korval
07-15-2008, 12:30 PM
What are vertex declarations for when you have GL's flexible setup.

GL 3.0 won't be having that "flexible" setup, if the last information dump is any indication. There will be a vertex array object that explicitly defines what attributes it expects to use. That way, the driver can say, "Sorry, I don't support that," if you ask for something like unnormalized unsigned short that the implementation doesn't support. It also allows the driver to do the setup and verification stuff once and never again.

Flexibility can get in the way of reasonable optimizations. And when it does, it needs to go away.


You're always relying on implementations being fast for the specific call sequence you're using. That's not a hack, it's implicit in the fact that OpenGL doesn't give performance guarantees. What the implementation does internally doesn't matter, it's the same whether it uses caching to avoid doing some work or whether it simply doesn't have to do much work at all.

The point is to be able to supply the implementation with enough information to be able to make reasonable optimizations. A driver that can't optimize the index offset will simply internally respecify pointers. A driver that has no overhead for pointer specification will simply respecify pointers. A driver that can optimize for it will.

It is much harder to do this the other way, where a user simply respecifies pointers. You would have to ensure that each pointer was offset from the others, and offset by the same amount, based on parameters that can change. That's one of the reasons for OpenGL 3.0 to begin with: to be better able to communicate with the driver.

Lord crc
07-15-2008, 12:40 PM
If it's an unspecified implementation specific caching mechanism, then yes, it's a hack.

Obviously, at this point, it'll have to be an extension in some form for it to be usefull in the way it was suggested. I guess my point was that it didn't have to be the way it is.

Anyway, it's a bit academical at this point. If you're introducing a new extension, you might as well just introduce the extended draw call.

Jan
07-15-2008, 01:59 PM
"If you're introducing a new extension, you might as well just introduce the extended draw call. "

Bingo! And that was the question we began with: Will this extended drawcall be introduced in gl 3?

I'd say from now on we will run in circles, so why don't we drop the subject, it's been a boring repetition of the same discussion that we had already a year ago, anyway.

Ah, here is another question for the BOF:

#42 (yes, that one's mine!): Some ATI guy mentioned, that they are waiting for the ARB to standardize the nVidia/DX10 extensions, to then enable those features on ATI hardware, too. Sooo: Are there any plans to extend 2.1 with standardized extensions for DX10 features, at all, or might he only be referring to gl 3. In the first case: what would be the point to introduce a new API AND maintain an old API, although there is obviously not enough man-power to accomplish only one of the tasks. How would the ARB justify such a decision, seeing that all the people who might "need" the high-end features will be the first to happily grab on to gl 3, anyway.

Jan.

MZ
07-15-2008, 03:14 PM
What are vertex declarations for when you have GL's flexible setup.
It's about splitting vertex array setup to mutable and immutable parts. It doesn't take away your flexiblity, because majority (but not all) of VA properites are naturally immutable (component offsets relative to each other, types, formats, stream frequency)

In D3D the immutable part is called Vertex Declaration, the mutable part is state vector of VB bindings and their offsets.

GL 2.x desn't make this distinction, so you have to drag the de facto immutable part along with you each time you update the mutable part.

In GL 3.0, as in shape from the last newsletter, at first it looked like everything was going to be immutable(!). Then, from posts by ARB people here, we got vague bits of information that some properties of VA setup will be mutable afterall. Later then, there was "Long Peaks Reloaded" announced, which indicated they are going to address the issue. And then came The Age of Silence. It's unknown what the solution will look like.

CatDog
07-15-2008, 06:03 PM
That's not a hack, it's implicit in the fact that OpenGL doesn't give performance guarantees.
But I'd like to have an API that gives performance guarantees. Do I have to switch to D3D now?

CatDog

EvilOne
07-16-2008, 12:41 AM
This "base vertex index" and it's counterpart "start index" work in D3D since the stone age. Nice feature... Stuff all into large buffers and then: draw, draw, draw. No need to respecify pointers.

And yes, I think we need something equivalent to D3D vertex declarations... this should make any driver happy. And it's just as flexible as OpenGL's current pointer mania, but very predictable for a driver.

Regarding shaders, I hope they go back to some ARB VP/FP like API... The current compile and link phase is annoying. And those fancy glGetUniformLocation and glGetAttribLocation simply don't belong to the OpenGL RUNTIME, they belong to the (yet to do) TOOLS. And a binary shader representation of some form would be damn nice... Instead of a compiler, just an optimizer and some code transformator (to card specific code) is needed. Come on, a compiler in the driver? The most idiotic decision ever...

And I hope for something like the D3D caps bits... I like to know before resource creation what works, and what not. No trial and error config.

Just make the API simple and clean. If I look at my rendering path in D3D, the code is often three to four time smaller than the equivalent GL path.

And I'd like to know what is the state of GL3 support from Apple? As Apple is my primary reason to keep my GL path alive.

knackered
07-16-2008, 02:08 AM
If I look at my rendering path in D3D, the code is often three to four time smaller than the equivalent GL path.
Seeing as though you're talking of caps bits I'll assume you're using d3d9. In which case I don't know what you're talking about - my d3d9 code is quite a bit longer than the equivalent gl code. And a helluva lot uglier.

bobvodka
07-16-2008, 03:40 AM
And those fancy glGetUniformLocation and glGetAttribLocation simply don't belong to the OpenGL RUNTIME, they belong to the (yet to do) TOOLS.

I disagree, and so does D3D10 to a degree; the ability for the driver to map streams as makes sense for the underlaying hardware is an important one. Sure, you can force it but letting the driver decide where you should bind things makes sense it knows about the hardware.

It would appear D3D10 works in much the same way; you specifiy the input to the shader and a given semantics name and then you bind inputs to this name (and in D3D10 it is a free form name, as with GLSL) and the runtime links everything together.

EvilOne
07-16-2008, 03:59 AM
@knackered

Yeah, my current target is D3D9. Nice and mature API, most of the installed base out there is XP and D3D9. So no need to switch to D3D10 currently.

Hmmm. I have more code in the tools than in the runtime. I preprocess most of the stuff offline into an API-friendly form. To be true, my runtime engine is not very "intelligent" - just designed for simplicity - it's actually really silly :-)

It starts with simple things like renderstates.

Example from the engine runtime:



/// Sets the render states.
static void SetRenderStates(int count, const unsigned int* values)
{
for(int i = 0; i < count; i++)
{
const unsigned int state = *values++;
const unsigned int value = *values++;

if(Cache[state] == value)
continue;

Device->SetRenderState(state, value);
Cache[state] = value;
}
}


Now do that with current GL...

And now come shaders into play... with ARB VP/FP semantics it was fun, just as simple to wrap as in D3D... but then GLSL shader stuff comes into play. This is the real pain in the arse... btw, thats why I am a happy Cg user. Nice for offline processing even when using GL.

The nice thing for D3D10 is, you can save the structs from the output merger (D3D10_DEPTH_STENCIL_DESC and D3D10_BLEND_DESC) directly with the tools... and on load time, just do some CreateDepthStencilState and CreateBlendState. So render state setup is just two ints into the arrays of blend and depth-stencil states... Equivalent for rasterizer states. Damn, somehow I like to do a D3D10 path now.

EvilOne
07-16-2008, 04:06 AM
@bobvodka

I haven't experimented with D3D10 that much. But imho, at the end of the day, you don't have to query anything. Just give the same names in the declaration and the shader, and you are ready to run.

V-man
07-16-2008, 07:47 AM
I don't know if this was asked.

Question#Z What's going to happen to GLSL? Is it going to get an offline compiler. Try making 500 relatively complex shaders and compile and measure the time. You'll see that it might take a minute.

Question#2 GLSL : I'm assuming gl_TexCoord and other built in names are getting eliminated.

Question#3 Extensions : there was a time when extensions were great. Everyone offered ARB_Multitexture, EXT_Multitexture, ARB_cubemap, EXT_cubemap, ARB_texture3D, EXT_texture3D. Now in the modern age, many companies are not offering the latest extensions that appear at opengl.org/registry. Strangely still, some extensions don't appear in opengl.org/registry.
====Anyway, get rid of extensions. All extensions are experimental and shitty. D3D programmers like D3D since it doesn't have extensions.
Make features go into core quickly and remove the extension from glGetString(GL_EXTENSIONS).
Why? Because ALL extensions are experimental and you shouldn't release a product that uses it.
All features must go into core quickly and all IHVs should stay up to date with the new GL core.

bobvodka
07-16-2008, 07:58 AM
@bobvodka

I haven't experimented with D3D10 that much. But imho, at the end of the day, you don't have to query anything. Just give the same names in the declaration and the shader, and you are ready to run.

Correct, but the query is still required and is still in the runtime; the difference is atm GL splits it into two stages and requires you to make a note of it.

Maybe I got the wrong end of what you were arguing for/against...

bobvodka
07-16-2008, 08:03 AM
Question#3 Extensions : there was a time when extensions were great. Everyone offered ARB_Multitexture, EXT_Multitexture, ARB_cubemap, EXT_cubemap, ARB_texture3D, EXT_texture3D. Now in the modern age, many companies are not offering the latest extensions that appear at opengl.org/registry. Strangely still, some extensions don't appear in opengl.org/registry.
====Anyway, get rid of extensions. All extensions are experimental and shitty. D3D programmers like D3D since it doesn't have extensions.
Make features go into core quickly and remove the extension from glGetString(GL_EXTENSIONS).
Why? Because ALL extensions are experimental and you shouldn't release a product that uses it.
All features must go into core quickly and all IHVs should stay up to date with the new GL core.

Getting rid of extensions is a bit extreme; they do have their uses for getting hold of new things to play with before a standardised version hits (or even experimental stuff). It becomes hard to 'try things out' if you can't expose it via the API.

But, as you sort of go on to say, extensions should have always been a short term solution to the problem; maybe staying extensions for a year at most (6 months preferably) before becoming standardised and hitting the 'core'.

I guess it's a case of balence between 'trying out new features' and 'getting things into the core asap'.

Brolingstanz
07-16-2008, 08:22 AM
Question#2 GLSL : I'm assuming gl_TexCoord and other built in names are getting eliminated.

Good riddance to the built-in state names at any rate. I'm guessing the attribute and inter-stage built-ins are keepers, those that shuttle varyings to and from the optional GS stage. Now those are actually nice to have and probably don't get in the way too much.

Zengar
07-16-2008, 08:31 AM
Extensions have to stay!

Seth Hoffert
07-16-2008, 10:26 AM
Anyway, get rid of extensions. All extensions are experimental and shitty.

Oh? I (and many other people) rather like being able to use geometry shaders, transform feedback, instancing, etc. through the currently available extensions (for that time before they're promoted), and they're far from crappy. But yes, I agree with bobvodka in that the time-to-core should be decreased.

Mars_999
07-16-2008, 10:49 AM
Extensions have to stay!


Yes they stay or we destroy you!

Korval
07-16-2008, 11:22 AM
And those fancy glGetUniformLocation and glGetAttribLocation simply don't belong to the OpenGL RUNTIME, they belong to the (yet to do) TOOLS.

No.

Semantics are the #1 most annoying thing about DX's shading languages. The basic shading language for an API should not enforce semantics on the user. The user should not have to specify that something is a "position" or "normal" or "texcoord" even if it isn't really that thing. I have a name for these attributes already defined in the shading language. I don't need a second name that isn't nearly as descriptive. I'm a big boy; I can define my own naming conventions.

The only annoyance with the way glslang handles attributes is the need to specify that one of the attributes is attribute 0. This was only done for backwards compatibility with immediate mode, and will almost certainly be gone in GL 3.0.


Make features go into core quickly and remove the extension from glGetString(GL_EXTENSIONS).
Why? Because ALL extensions are experimental and you shouldn't release a product that uses it.
All features must go into core quickly and all IHVs should stay up to date with the new GL core.

Ahh, good old-fashioned nonsense.

Extensions are not usually experimental. The only ones I would even classify as "experimental" are ARB extensions that we know are going to be brought into the Core. And even those are not so much experimental as "tentative": working the bugs out of the API.

The only problem with shipping a product that uses a tentative extension is that if there are changes to the API between the extension and the core feature, then an IHV has to support both the old and new APIs. A decade of this accruing cruft has accumulated, but even that is only a small part of the reason for GL 3.0.

The other class of extension, vendor-specific functionality, is very much something that needs to stay. One card is not the same as another, and those features should be exposed for the user to use.

In any case, the core should not be changing that often. Yearly updates are perfectly fine.

zed
07-16-2008, 12:37 PM
a bit of a divergence

but whoever's writing the redbook needs to get their act together more so than in the past,
i remember when ogl1.2 came out I was wanting to buy the updated redbook, but it only finally appeared over a year later, so ultimately I didnt bother, tech books only have a very short shelflife.

knackered
07-16-2008, 01:03 PM
Well as I remember, it stayed at 1.2 for an immense length of time - so the book remained current.
God it was a good book. Dog-eared to buggery now, of course.

Mark Shaxted
07-16-2008, 01:06 PM
I just want GL3 to offer volatile textures. If the driver decides to kick the texture out of vram, then I'll decide whether to keep a copy in ram, or recreate the texture on the fly. And surely this must be a simple thing to do. Although vitualising vram may have thrown a spanner in the works...

bertgp
07-16-2008, 01:20 PM
Question #X
What will OGL3 offer in terms of memory management?

I am referring to managing texture memory and VBO memory. Currently, there is no way to "force" a texture or VBO in VRAM and let the application do its own memory management. Some will argue that this kind of low-level control should not be exposed, but in real-time application where avoiding glitches is a must, such a scheme would provide a way to garantee a glitch-free operation. Simply hoping that the driver makes the right decision as to which object to keep in VRAM is not an option.

Also, in an environment where there is too much content to hold at once in RAM, we must load new ressources on demand also without glitches. Uploading a 2048x2048 texture is way too costly to be done in a single frame. We need to upload small parts of the texture each frame, depending on a given time budget. This is impossible since the texture is only sent to VRAM as a whole chunk when it is first used. When it is not possible to pre-allocate all the possible texture sizes, this will cause a glitch when creating a new texture. Ideally, a mechanism for casting a surface from says a 1MB RGBA texture to a 1MB DXT texture would be great since a bunch of them could be created during initialization and always reused. Even then however, we would need a way to force the driver to keep the texture in VRAM, even if it has not been used for a while.

To summarize, what will be offered to take the guesswork out of the memory management process?

V-man
07-16-2008, 02:32 PM
I just want GL3 to offer volatile textures. If the driver decides to kick the texture out of vram, then I'll decide whether to keep a copy in ram, or recreate the texture on the fly. And surely this must be a simple thing to do. Although vitualising vram may have thrown a spanner in the works...

That will be offered. This is good since the driver won't store backups in RAM.
You can also tell it to keep a backup for people who want the old GL behavior.

Rob Barris
07-16-2008, 03:22 PM
I just want GL3 to offer volatile textures. If the driver decides to kick the texture out of vram, then I'll decide whether to keep a copy in ram, or recreate the texture on the fly. And surely this must be a simple thing to do. Although vitualising vram may have thrown a spanner in the works...

That will be offered. This is good since the driver won't store backups in RAM.
You can also tell it to keep a backup for people who want the old GL behavior.

V-man, what are you referring to ?

knackered
07-16-2008, 03:48 PM
So that's not happening then. It was something alluded to by barthold in a thread many moons ago, when the summer days were longer and coke tasted nice.

Korval
07-16-2008, 04:11 PM
Currently, there is no way to "force" a texture or VBO in VRAM and let the application do its own memory management. Some will argue that this kind of low-level control should not be exposed, but in real-time application where avoiding glitches is a must, such a scheme would provide a way to garantee a glitch-free operation. Simply hoping that the driver makes the right decision as to which object to keep in VRAM is not an option.

To be honest, I wouldn't expect anything like that. The best you could hope for is keeping the priority mechanism.

Not to mention the simple fact that I can't imagine how an application could expect that to work. I mean, the GL spec can only enforce behavior, not performance. You could have a function that says, "put this into video memory," but there's no way to tell if the driver is lying to you if it says, "OK." After all, it's your only interface to video memory, so it can lie to you on query functions too. And you can never know if a hitch in the rendering is due to paging something in or some other issue without significant diagnostics tools.

It also doesn't make sense if the Operating System virtualizes video memory (like MacOS and Vista), as the graphics driver literally has no control over what is and isn't in video memory.


This is impossible since the texture is only sent to VRAM as a whole chunk when it is first used.

Actually, you don't know that. You're assuming that, possibly with some evidence, but it may be different in the next driver version.


Ideally, a mechanism for casting a surface from says a 1MB RGBA texture to a 1MB DXT texture would be great since a bunch of them could be created during initialization and always reused.

I'm pretty sure you can forget that one. Don't even dream about it; it ain't gonna happen.

The simple fact is this: OpenGL and D3D are abstractions, not memory managers. Their job is to actively prevent you from doing those things.

Komat
07-17-2008, 12:59 AM
You could have a function that says, "put this into video memory," but there's no way to tell if the driver is lying to you if it says, "OK." After all, it's your only interface to video memory, so it can lie to you on query functions too.

Yes drivers lying and optimizing to gain few fps in benchmarks is problem which the API can not directly solve. The only thing the API can do is provide strong mechanism for specifying the program intentions to the driver (e.g. This uniform is changed offten, do not optimize. Try to keep this shadowmap in the fastest memory at all costs even if I will not use it for some time.) so reasonable driver does not have to gues the intended behavior.



It also doesn't make sense if the Operating System virtualizes video memory (like MacOS and Vista), as the graphics driver literally has no control over what is and isn't in video memory.

I think that the virtualization is always done with cooperation with the driver because only the driver knows what can be safely moved to different memory. So the driver should have at least some control about what is removed.

Komat
07-17-2008, 01:07 AM
Ideally, a mechanism for casting a surface from says a 1MB RGBA texture to a 1MB DXT texture would be great since a bunch of them could be created during initialization and always reused.
The reall memory size and other requirements put on the texture memory might change in unexpected (for external observer) ways between formats or texture sizes depending on what the hw requires. Even the DX10 which allows for accessing the resource using different formats is very strict and limited in what types are compatible for this purpose.

bertgp
07-17-2008, 06:42 AM
I think that the virtualization is always done with cooperation with the driver because only the driver knows what can be safely moved to different memory.

I strongly disagree with this statement. Only the application, with its knowledge of how it will use resources can effectively make appropriate decisions as to what to prioritize. I do agree that there are cases where the driver, because of the underlying hardware implementation, will be more apt to choose the right behavior. However, this should not be an excuse to give absolutely no control to the application over memory usage because then the application cannot ever guarantee 100% glitch-free operation (think real-time app).

The current priority mechanism is either not really enforced or outright ignored by the driver. At the very least, can we please _enforce_ it in the spec (not just provide idiotic "hints" that the driver can ignore!!) so a higher priority texture is never kicked out of VRAM when a lower priority one is not currently used?



After all, it's your only interface to video memory, so it can lie to you on query functions too. And you can never know if a hitch in the rendering is due to paging something in or some other issue without significant diagnostics tools.






This is impossible since the texture is only sent to VRAM as a whole chunk when it is first used.

Actually, you don't know that. You're assuming that, possibly with some evidence, but it may be different in the next driver version.


Having had access to driver source from one major vendor (and one minor) and spending a few weeks investigating the other major vendor's driver, I can say with confidence that this is what happens. One way or the other, don't you agree that not being able to easily pinpoint the source of a glitch is unacceptable? Even worse, in the case of memory management, not being able to effectively remedy it? Worse still, having to redo all the investigation work from one driver version to the next?



The reall memory size and other requirements put on the texture memory might change in unexpected (for external observer) ways between formats or texture sizes depending on what the hw requires. Even the DX10 which allows for accessing the resource using different formats is very strict and limited in what types are compatible for this purpose.


You are right that a 1024x1024 texture does not have the same VRAM size depending on its format. Also, the hardware does some tiling to optimize the memory access pattern of textures which is not necessarily compatible across texture types. Straightforward "casting" of one texture surface type to another would probably not work. However, as you mentioned, some types can be safely casted into other types. This should be available.

Also, imagine a 1024x1024 texture is divided in 4 512x512 tiles and each of those is further divided down to some limit size. It would be nice to be able to take advantage of this and be able to create 4 512x512 textures from a 1024x1024 texture.

V-man
07-17-2008, 08:01 AM
I just want GL3 to offer volatile textures. If the driver decides to kick the texture out of vram, then I'll decide whether to keep a copy in ram, or recreate the texture on the fly. And surely this must be a simple thing to do. Although vitualising vram may have thrown a spanner in the works...

That will be offered. This is good since the driver won't store backups in RAM.
You can also tell it to keep a backup for people who want the old GL behavior.

V-man, what are you referring to ?



Currently, drivers keep a copy of the texture in RAM do they not?
This is just in case Windows destroys your texture. The driver gets a notification from Windows, so it reuploads the texture when it gets needed.
GL3 was suppose to offer a feature where we can tell the driver to not keep copies in RAM.

Boring story ahead!
With one project of mine, I added the ability to not initialize GL because it was consuming a ridiculous amount of RAM (according to task manager). Memory usage came down to 24MB. With GL, it went above 100MB. My project was using textures, VBOs, FBOs. I did keep a copy of the textures in RAM when GL was initialized but memory usage should have been around 20MB. The extra 50MB, 60MB, 70MB was probably the GL driver.

Mars_999
07-17-2008, 08:33 AM
Oh yeah, it's like X-Mas now. Siggraph is less than a month away. Let the count down begin.

Mark Shaxted
07-17-2008, 08:37 AM
Basically, my requirements are for displaying thumbnails of photographs. I want to use the following strategy:-

vram: 8192 64x64 6:1 compressed thumbs (total 16mb forced into vram - ie a high priority)
vram: 256 thumbs of a given size converted into monitor colour profile (volatile)
system ram 1024 jpeg thumbs.

So, in an ideal world, I'd say if the high res thumb exists render with that. If that fails use the crappy low res version, and in the background decompress the jpg, then upload it.

However, as it stands now, all the compressed thumbs, and the hgh res version will exist in vram AND system ram. And for my type of app, memory is always a scarce commodity.

Surely, even with virtualised vram, the driver must know when a txture is about to be paged out. All I want is for the driver to say "no need, I'll just delete it", and return an error when you try to use it. Then *I* can deal with the consequences.