Re: [1/3] WineD3D: check the GL flags in CheckDepthStencilCapability, not the static info
On 24 March 2010 23:53, Stefan Dösinger <stefan(a)codeweavers.com> wrote:
These flags will be unset if the format is not supported by GL and is consistent with the other depth stencil check functions.
So what happens if the GL implementation doesn't support ARB_depth_texture, for example?
On Thu, Mar 25, 2010 at 9:10 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote:
On 24 March 2010 23:53, Stefan Dösinger <stefan(a)codeweavers.com> wrote:
These flags will be unset if the format is not supported by GL and is consistent with the other depth stencil check functions.
So what happens if the GL implementation doesn't support ARB_depth_texture, for example?
My suggestion was to extend 'init_format_texture_info' and set 'wined3d_format_desc->supported' when the extension is around. Roderick
On 25 March 2010 09:17, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote:
My suggestion was to extend 'init_format_texture_info' and set 'wined3d_format_desc->supported' when the extension is around.
That doesn't help, the problem is with fairly old cards that don't support depth textures. They obviously won't be able to do fancy stuff like FBO offscreen rendering, but you should still be able to create a depth/stencil buffer. The current code on the other hand will incorrectly report floating point depth formats as supported even if the relevant extension isn't supported.
Am Donnerstag 25 März 2010 09:10:19 schrieb Henri Verbeet:
So what happens if the GL implementation doesn't support ARB_depth_texture, for example? Good point. Maybe we should only look at those flags when we're using FBOs? I think the other format checking functions handle it that way, I wondered why. Patch 3 would still prevent float formats from being advertised without FBOs.
GL_EXT_framebuffer_object doesn't require GL_ARB_depth_texure, so technically we might end up using FBOs without depth texture support. Possibility 1 is that DEPTH_COMPONENT render buffers are still supposed to work, possibility 2 is that FBO rendering can't support depth buffers, which would make them useless for our purpose.
On Thu, Mar 25, 2010 at 10:02 AM, Stefan Dösinger <stefan(a)codeweavers.com> wrote:
Am Donnerstag 25 März 2010 09:10:19 schrieb Henri Verbeet:
So what happens if the GL implementation doesn't support ARB_depth_texture, for example? Good point. Maybe we should only look at those flags when we're using FBOs? I think the other format checking functions handle it that way, I wondered why. Patch 3 would still prevent float formats from being advertised without FBOs.
GL_EXT_framebuffer_object doesn't require GL_ARB_depth_texure, so technically we might end up using FBOs without depth texture support. Possibility 1 is that DEPTH_COMPONENT render buffers are still supposed to work, possibility 2 is that FBO rendering can't support depth buffers, which would make them useless for our purpose.
Note I don't know much about the current FBO extension situation but since FBOs are finally quite common, can't we expect some features to be around? If this functionality is missing, perhaps we should just not work and let vendors fix their drivers. I guess AMD and Nvidia are quite decent and perhaps Mesa also supports the needed stuff. Not sure about Apple. Roderick
Am Donnerstag 25 März 2010 10:06:21 schrieb Roderick Colenbrander:
Note I don't know much about the current FBO extension situation but since FBOs are finally quite common, can't we expect some features to be around? If this functionality is missing, perhaps we should just not work and let vendors fix their drivers. I guess AMD and Nvidia are quite decent and perhaps Mesa also supports the needed stuff. Not sure about Apple. Mesa supports FBOs these days, but not on radeon cards prior to r200 chips. Nouveau and Intel should be ok, I don't know about matrox and other odd cards.
I think we could justify killing backbuffer offscreen rendering(so we only have FBOs left), but we cannot justify not running at all without FBOs. Then thinking is that pretty much all apps that use offscreen rendering are dx8+ ones, so games that need offscreen rendering are unlikely to run on a Radeon 7500 anyway. There's of course the situation that KMS-based Mesa currently has sucky performance and many users still have old drivers installed.
On 25 March 2010 10:02, Stefan Dösinger <stefan(a)codeweavers.com> wrote:
Good point. Maybe we should only look at those flags when we're using FBOs? I think the other format checking functions handle it that way, I wondered why. Probably.
GL_EXT_framebuffer_object doesn't require GL_ARB_depth_texure, so technically we might end up using FBOs without depth texture support. Possibility 1 is that DEPTH_COMPONENT render buffers are still supposed to work, possibility 2 is that FBO rendering can't support depth buffers, which would make them useless for our purpose.
I think render buffers would still depend on formats exposed ARB_depth_texture. We could simply disable FBOs if neither ARB_depth_texture or any of the packed_depth_stencil variants is suppoerted, but it's probably unlikely enough that we can just worry about that if we ever hit it.
On Thu, Mar 25, 2010 at 9:26 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote:
On 25 March 2010 09:17, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote:
My suggestion was to extend 'init_format_texture_info' and set 'wined3d_format_desc->supported' when the extension is around.
That doesn't help, the problem is with fairly old cards that don't support depth textures. They obviously won't be able to do fancy stuff like FBO offscreen rendering, but you should still be able to create a depth/stencil buffer. The current code on the other hand will incorrectly report floating point depth formats as supported even if the relevant extension isn't supported.
Somehow I thought (perhaps because that's what I discussed with Stefan) that he added an explicit FBO check to CheckDepthStencilCapability to separate FBO and classic WGL. In the FBO path he can use the detection he uses now augmented with a 'supported' check. At least that's what I had in mind. I prefer to limit the use of IsPixelF* to wgl stuff like checking whether an adapter format is supported and for the non-FBO case. Float checks would help in the non-FBO case to prevent getColorBits warnings. Roderick
participants (3)
-
Henri Verbeet -
Roderick Colenbrander -
Stefan Dösinger