Hi Henri, Apparently I have debugged Splinter Cell in a wrong direction. The depth copy can hardly be the problem because splinter cell renders everything offscreen, except the final composition and the HUD. I think the problem is the lack of a stencil attachment to our fbos. Implementing them looks rather simple - just adjust the internal format of D24S8 to the packed depth stencil format and set the same texture for depth and stencil attachments. However, I think I remember that you tried that before and it failed for some reason. There are two extensions, GL_NV_packed_depth_stencil and GL_EXT_packed_depth_stencil, whereas the NV one is the only one supported on my nvidia card and the EXT one the only one supported on my ATI card(on macos). The EXT one seems to be the only one that is written with fbos in mind. fglrx does not support either extension. As a fallback a combined depth stencil surface could contain an extra 8 bit gl texture(luminance, or GL_RED, or whatever) and just use it as a separate stencil buffer. We just have to watch out when locking the texture, and using such a surface for texuring will be tricky. (Stencil texture? Is that possible even? The EXT_packed_stencil extension says yes).
Am Mittwoch, 18. Juli 2007 00:49 schrieb Stefan Dösinger: There are two extensions, GL_NV_packed_depth_stencil and
GL_EXT_packed_depth_stencil, whereas the NV one is the only one supported on my nvidia card and the EXT one the only one supported on my ATI card(on macos). The nvidia card also supports the _EXT_ one, I missed it before
On 18/07/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote:
Hi Henri,
Apparently I have debugged Splinter Cell in a wrong direction. The depth copy can hardly be the problem because splinter cell renders everything offscreen, except the final composition and the HUD.
I think the problem is the lack of a stencil attachment to our fbos. Implementing them looks rather simple - just adjust the internal format of D24S8 to the packed depth stencil format and set the same texture for depth and stencil attachments.
However, I think I remember that you tried that before and it failed for some reason. There are two extensions, GL_NV_packed_depth_stencil and GL_EXT_packed_depth_stencil, whereas the NV one is the only one supported on my nvidia card and the EXT one the only one supported on my ATI card(on macos). The EXT one seems to be the only one that is written with fbos in mind. fglrx does not support either extension.
Setting the stencil attachment isn't very hard. The problem is that we currently can't do much with extensions in the texture format table, and that we can't detect whether we should attach / detach the stencil attachment. (Except for checking the surface format in set_depth_stencil_fbo, but that's ugly.) Another thing (unrelated to this) I'd like to change about the format table is adding a field for format caps (ie, the stuff CheckDeviceFormat checks, like offscreen rendering, filtering, VTF, etc) and filling that when the WineD3D object is created.
As a fallback a combined depth stencil surface could contain an extra 8 bit gl texture(luminance, or GL_RED, or whatever) and just use it as a separate stencil buffer. We just have to watch out when locking the texture, and using such a surface for texuring will be tricky. (Stencil texture? Is that possible even? The EXT_packed_stencil extension says yes).
That won't work on any current card, afaik. Depth and stencil attachments have to be the same texture on current cards.
Setting the stencil attachment isn't very hard. The problem is that we currently can't do much with extensions in the texture format table, and that we can't detect whether we should attach / detach the stencil attachment. (Except for checking the surface format in set_depth_stencil_fbo, but that's ugly.)
That won't work on any current card, afaik. Depth and stencil attachments have to be the same texture on current cards. Does that affect only texture attachments, or even renderbuffers? The sample code in GL_EXT_framebuffer_object uses two different renderbuffers for depth and stencil. If even render buffers do not work we're screwed on fglrx(not that this would be news).
On 18/07/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote:
Setting the stencil attachment isn't very hard. The problem is that we currently can't do much with extensions in the texture format table, and that we can't detect whether we should attach / detach the stencil attachment. (Except for checking the surface format in set_depth_stencil_fbo, but that's ugly.)
That won't work on any current card, afaik. Depth and stencil attachments have to be the same texture on current cards. Does that affect only texture attachments, or even renderbuffers? The sample code in GL_EXT_framebuffer_object uses two different renderbuffers for depth and stencil. If even render buffers do not work we're screwed on fglrx(not that this would be news).
Renderbuffers might be ok, but I'm not completely sure.
On Wednesday 18 July 2007 03:34:05 am H. Verbeet wrote:
Does that affect only texture attachments, or even renderbuffers? The sample code in GL_EXT_framebuffer_object uses two different renderbuffers for depth and stencil. If even render buffers do not work we're screwed on fglrx(not that this would be news).
Renderbuffers might be ok, but I'm not completely sure.
A snippet of code for my game I'm working on: glGenRenderbuffersEXT(1, &scene_depth); glBindRenderbufferEXT(GL_RENDERBUFFER_EXT, scene_depth); glRenderbufferStorageEXT(GL_RENDERBUFFER_EXT, GL_DEPTH_STENCIL_EXT, scene_width, scene_height); scene_stencil = scene_depth; ... glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, scene_fbo); glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT, GL_TEXTURE_2D, scene_tex, 0); glFramebufferRenderbufferEXT(GL_FRAMEBUFFER_EXT, GL_DEPTH_ATTACHMENT_EXT, GL_RENDERBUFFER_EXT, scene_depth); glFramebufferRenderbufferEXT(GL_FRAMEBUFFER_EXT, GL_STENCIL_ATTACHMENT_EXT, GL_RENDERBUFFER_EXT, scene_stencil); glViewport(0, 0, scene_width, scene_height); ...on my nVidia Geforce FX 5500 card, and it works perfectly.
On 18/07/07, Chris Robinson <chris.kcat(a)gmail.com> wrote:
On Wednesday 18 July 2007 03:34:05 am H. Verbeet wrote:
Does that affect only texture attachments, or even renderbuffers? The sample code in GL_EXT_framebuffer_object uses two different renderbuffers for depth and stencil. If even render buffers do not work we're screwed on fglrx(not that this would be news).
Renderbuffers might be ok, but I'm not completely sure.
A snippet of code for my game I'm working on:
glGenRenderbuffersEXT(1, &scene_depth); glBindRenderbufferEXT(GL_RENDERBUFFER_EXT, scene_depth); glRenderbufferStorageEXT(GL_RENDERBUFFER_EXT, GL_DEPTH_STENCIL_EXT, scene_width, scene_height); scene_stencil = scene_depth; ...
Well yeah, that uses the same renderbuffer for both attachments.
Am Mittwoch, 18. Juli 2007 12:34 schrieb H. Verbeet:
On 18/07/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote:
Does that affect only texture attachments, or even renderbuffers? The sample code in GL_EXT_framebuffer_object uses two different renderbuffers for depth and stencil. If even render buffers do not work we're screwed on fglrx(not that this would be news).
Renderbuffers might be ok, but I'm not completely sure. Apparently not :-(
I tried to get it working, but I didn't have any luck. Either I am missing something, or it just doesn't work. My attempt is attached The colorbuffer codepath works nice for the size match too(appart of the lacking depth blit). Creating the render buffer with the packed depth stencil format and using one render buffer for both depth and stencil works fine, but using two different render buffers(both packed depth stencil or one depth24 and the other stencil 8) fails on both nvidia and ati cards. Nvidia returns GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT_EXT, ATI just says GL_FRAMEBUFFER_UNSUPPORTED_EXT. So it looks like we just have to use GL_EXT_packed_depth_stencil. That makes the extension check obsolete too because we can't get anything better than a GL_FRAMEBUFFER_UNSUPPORTED_EXT.
On 18/07/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote:
Renderbuffers might be ok, but I'm not completely sure. Apparently not :-(
I tried to get it working, but I didn't have any luck. Either I am missing something, or it just doesn't work. My attempt is attached
+ GL_EXTCALL(glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, GL_STENCIL_ATTACHMENT_EXT, GL_TEXTURE_2D, 0, 0)); You don't have to do that, attaching the renderbuffer removes the previous attachment. The has_stencil check is rather ugly, of course.
So it looks like we just have to use GL_EXT_packed_depth_stencil. That makes the extension check obsolete too because we can't get anything better than a GL_FRAMEBUFFER_UNSUPPORTED_EXT.
Not really, you can still attach a regular depth format in that cause. Not all applications that use D24S8 actually use the stencil buffer.
Am Mittwoch, 18. Juli 2007 14:17 schrieb H. Verbeet:
On 18/07/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote:
Renderbuffers might be ok, but I'm not completely sure.
Apparently not :-(
I tried to get it working, but I didn't have any luck. Either I am missing something, or it just doesn't work. My attempt is attached
+ GL_EXTCALL(glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT,
GL_STENCIL_ATTACHMENT_EXT, GL_TEXTURE_2D, 0, 0)); You don't have to do that, attaching the renderbuffer removes the previous attachment. The has_stencil check is rather ugly, of course. I added the glFramebufferTexture2DEXT to see if it changes anything. Sorry, forgot to document this.
Yeah, the way has_stencil is handled in my hack is ugly, agreed. It could be a property in the pixel format table(that one is getting rather huge :-/). For set_depth_stencil_fbo it could be some sort of flag in the surface.
So it looks like we just have to use GL_EXT_packed_depth_stencil. That makes the extension check obsolete too because we can't get anything better than a GL_FRAMEBUFFER_UNSUPPORTED_EXT.
Not really, you can still attach a regular depth format in that cause. Not all applications that use D24S8 actually use the stencil buffer. Good point.
The check could be done when setting glDescription.glInternal. I can't find it right now, but I think it is linked to d3dfmt_get_conv where all the other formats are handled.
On 18/07/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote:
Not really, you can still attach a regular depth format in that cause. Not all applications that use D24S8 actually use the stencil buffer. Good point.
The check could be done when setting glDescription.glInternal. I can't find it right now, but I think it is linked to d3dfmt_get_conv where all the other formats are handled.
I'd rather fix the handling of the format table. Floating point formats are another case where we should be doing extension checks, rather than having entries for those and only doing the extension check in CheckDeviceFormat. We may even want to support different internal formats for different uses... not sure about that one yet. (The problem there is that currently eg. D3DFMT_R5G6B5 isn't supported as FBO attachment, but would be if we used eg. GL_RGBA8 as internal format)
Am Mittwoch, 18. Juli 2007 15:45 schrieb H. Verbeet:
I'd rather fix the handling of the format table. Floating point formats are another case where we should be doing extension checks, rather than having entries for those and only doing the extension check in CheckDeviceFormat. We may even want to support different internal formats for different uses... not sure about that one yet. (The problem there is that currently eg. D3DFMT_R5G6B5 isn't supported as FBO attachment, but would be if we used eg. GL_RGBA8 as internal format) Agreed, the static table is too limited. We should replace it with some per-adapter structure with some more fields like a different render target internal. The per adapter table can then be set up based on the settings and gl features. Inherently static data like the bitmasks should be separated from gl data.
Some other places where we have troubles with the current setup: Bump map formats: GL_ATI_envmap_bumpmap vs GL_NV_texture_shader vs none of them. Currently the converter stuff in LoadTexture deals with that. sRGB textures: Currently an extra internal format deals with that, extension checks are done at texture load time. That can stay the way it is IMHO because an extra internal format isn't a bad solution and srgb textures involve more than just a different format, and the extension check is responsible for all the other things too.
participants (3)
-
Chris Robinson -
H. Verbeet -
Stefan Dösinger