Patrice Mandin wrote:
> Hello,
> 
> fbo_firecube does not work for me, because on nv30, color and
> depth/stencil buffers must have same size. fbo_firecube asks a
> GL_DEPTH_COMPONENT16 for depth, and attach it to a 32 bits color
> buffer, which thus fails.
> 
> Not valid for nv30 (and lower hardware I think):
> - 32 bits color buffer with 16 bits depth
> - 16 bits color buffer with 24 depth +8 stencil
> However, I could have
> - 16 bits color buffer with 16 bits depth

Mmmm, OK.  Some other hardware supports mixing depths (such as 32-bit 
RGBA + 16-bit Z).  Also note that GL_ARB_framebuffer_object relaxed 
the requirement that all color buffers need to be the same 
format/depth so we might want to expose that feature someday.

I guess we need a way to ask the driver if it can support mixed 
depths.  The most flexible thing would be a new function such as

boolean
pipe_context::validate_framebuffer(struct pipe_context *pipe,
                                    const struct 
pipe_framebuffer_state *fb);

to ask the driver if the given framebuffer configuration is usable. 
I'd hold off on that for now.

In the mean time, we could be more restrictive in 
st_validate_framebuffer() and require all surfaces be of the same 
depth.  Want to try that?

Or, in the nv driver, only support 32-bit or 16-bit surfaces depending 
on the screen depth.

The other issue in this case is that fbo_firecube.c should be calling 
  glCheckFramebufferStatus() to see if the FBO it builds is OK.  If it 
fails, we should try another FBO combination.  I can fix that.


> glxinfo lists only the correct combinations (in the GLXFBConfig
> section), i.e. 32 bits color buffer with either 0/0 for depth/stencil
> or 24/8.
> 
> In st_cb_fbo, Mesa only check if a format is valid for a given buffer.
> I did not find anywhere if there is a check for the combination of the
> color and depth/stencil buffers.
> 
> I have already a patch ready, which simply enforce using a buffer with
> same number of bits as the context front buffer. I would like to know
> if there would be a better solution.
> 

-Brian

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Reply via email to