gold

Member
  • Content count

    156
  • Joined

  • Last visited

Community Reputation

412 Neutral

About gold

  • Rank
    Member
  1. I forgot that bindable uniforms are not part of GL3, but you can use vertex textures. On this generation of hardware, vertex textures are very fast - the shader units are unified so anything you can do with textures in the fragment stage can be done in the vertex stage, too. The InstanceID therefore can be used to generate texture coordinates.
  2. Instancing may be performed with the ARB_draw_instanced extension, which didn't make core 3.0 but will likely be promoted in the next release.
  3. Quote:Original post by Peti29 - immediate mode. I understand that it's hard to optimize in the driver. But to kill it entirely? IHVs can serve you better by focusing development and maintenance resources on modern features instead of emulating legacy features, when you can do so more efficiently by focusing on your own usage and not every possible corner case the spec allows. Quote:- "fixed function vertex processing", like: VertexPointer, NormalPointer... huh??! This means no more matrix stack, lighting, etc. You'll have to write your own vertex shader or write/find a utility library which emulates the legacy vertex pipeline. Quote:- LineWidth: why? Apparently some vendors hardware doesn't support wide lines natively, and they don't want to emulate it.
  4. The number one rule is: don't call anything that starts with Get. The GL is designed for information to travel one direction: from the app to the hardware. Gets force a pipeline stall. Likewise, there is almost never a good reason to call Finish. Flush is OK but usually unnecessary, and flushing too often can slow you down.
  5. In-band just means it executes serially with other commands in the command stream and therefore requires no sync/stall. In plain English: its fast.
  6. OpenGL OpenGL 3.0 canceled?

    Quote:Original post by GamerSg Just out of curiosity, when a IHV releases new hardware, do they not have to implement drivers for DX 7/8/9/10? Else older games coded in DX7 will not work on newer hardware. Microsoft provides a shim which layers older versions on the more recent, so IHVs don't have to support them all. Older titles run fast enough when emulated on newer hardware.
  7. FBO and main depth buffer

    You should be able to copy the window depth buffer to the FBO depth buffer using glBlitFramebuffer() (ARB_framebuffer_object or OpenGL 3.0) or glBlitFramebufferEXT() (EXT_framebuffer_blit). 1) Create a depth texture or renderbuffer with the same depthBits as the window depth buffer. 2) Bind the default framebuffer (0) as the READ_FRAMEBUFFER. 3) Bind the FBO as the DRAW_FRAMEBUFFER. 4) Blit the depth buffer: glBlitFramebuffer(0, 0, W-1, H-1, 0, 0, W-1, H-1, GL_DEPTH_BUFFER_BIT, GL_NEAREST);
  8. One form of render-to-vertex-array that can be done on older hardware: render to offscreen memory (e.g. a FBO), then ReadPixels into a PBO. Then bind the same buffer as a VBO. While this requires copying the data to the buffer, the copy can be performed in-band and without requiring a round trip to the host. Thus it should be very fast.
  9. By the way if you use FBO you should switch from the EXT to the ARB/3.0 version. It adds two restrictions but removes others. The new restrictions are: - No more user-generate names. You must call glGenFramebuffers() - No more sharing of the FBO between contexts. The FBO may be used only with the context on which it was created. However if you really need to render to the same buffers from multiple contexts, the buffers themselves may still shared and bound to context-specific FBOs. New functionality includes: - Mixed size attachments. For example you may now share a single large depth buffer across many different sized color buffers. - Mixed format attachments. You may now attach e.g. an RGBA8 image to COLOR_ATTACHMENT0 and a RGBA32F to COLOR_ATTACHMENT1 and write to both from a single shader. (Note that this might generate FRAMEBUFFER_UNSUPPORTED on older hardware.)
  10. Depends on the hardware you wish to target. If you want to support older cards (e.g. GeForce 7x00 series) you'll need to stick with 2.1. If you want to take advantage of the functionality on newer cards (e.g. GeForce 8x00) you can run version 3.0. But... There is a lot in common between these versions. Really, you can conditionalize your code based on the available version and support both generations of hardware. Some of the new 3.0 functionality is even available under 2.1 with the same API (e.g. FBO and VAO)*. 3.0 is really 2.1+. *This is something new. The ARB made extensions for 2.1 which expose a subset of the core 3.0 functionality. Because the functionality is core, and will run under 2.1 unchanged, the API looks like core, i.e. there is no ARB suffix on the function names or enumerants. This was done to simply the lives of developers who want to support multiple generations of hardware with common code.
  11. FBO and main depth buffer

    Short answer: it cannot be done. The ARB seriously considered supporting this and chose not to, at least not at this time. The good news is that FBO in 3.0 allows mixed size attachments so you may share a depth buffer for offscreen rendering to color images of different sizes.
  12. OpenGL OpenGL 3.0 canceled?

    Quote:Original post by MARS_999 Please clarify this, are you saying the GL3 model that everyone wanted would be difficult or the existing API is going to be difficult and therefore we are dumping the old crap!! :) I'm saying the problems in the legacy object model which Longs Peak attempted to address are still there in 3.0, and this affects functionality which the ARB might like to expose in the future. At this point I know better than to make any promises on behalf of the ARB.
  13. OpenGL OpenGL 3.0 canceled?

    Quote:Original post by stimarco Quote: 3) The object model. We talked in lengths about this, so I won't repeat it here. But I'd still like to point out how extremely disappointed I and many other people were about this, excuse my language, complete fuck-up. I think it's clear that pragmatic issues forced the ARB's hand here. I'm guessing that simply dumping 2.x and starting afresh was unfeasible as it would require companies like ATI, NVidia and Intel to maintain both 2.x and 3.x drivers. As OpenGL is a niche API, this makes little sense: ATI, NVidia and Intel make their money from consumer graphics products, which means DirectX gets the bulk of the attention. Making OpenGL even harder to support over the near-term was never going to go down well with the IHVs. Actually some IHVs were looking forward to making a clean break with the past. Support for existing APIs is a (largely) solved problem, but continuing to aggrandize the existing model means continuing to modify (i.e. break) existing code. And, some of the new and upcoming functionality is really difficult to integrate with the existing object model.
  14. OpenGL Why OpenGL 3.0 is so badly?

    Adding to what Rob said, if you change no code you will continue running on 2.1 as long as its supported. Given that 100% of existing applications run on a base which is compatible with OpenGL 1.0, I can't see IHVs dropping support anytime soon, although some legacy features might become layered (i.e. slower) for compatibility. If you write a few lines of wgl code and create a 3.0 context, you can use the new features *and* 100% of your rendering code will continue to run. If/when a new version breaks compatibility and you can still use new features without rewriting old code. You can create both a legacy and an incompatible context and call MakeCurrent when you transition between old and new code. [Edited by - gold on August 23, 2008 5:45:31 PM]