José Fonseca wrote: > On Thu, 2009-10-15 at 07:22 -0700, Brian Paul wrote: >> José Fonseca wrote: >>> On Wed, 2009-10-14 at 18:11 -0700, Brian Paul wrote: >>>> 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. >>> This implies that the state tracker needs to create the surfaces in >>> order to validate a color/depth format combination. >> Well, that's the way it's done with OpenGL's FBOs. > > I know. It's not how's done with D3D though, for example. > >>> It makes GL visual >>> enumeration and D3D capability exporting with gallium cumbersome, >>> needing to create tens of dummy surfaces at startup to find the >>> supported combinations. >> Agreed. >> >> >>> If all hardware out there only has two cases -- either it supports >>> color/depth of different bit depths or not -- then a simple >>> pipe_screen::get_param() would be preferable IMO. >>> >>> Same goes for support of color buffer of different sizes: it would be >>> better to know whether we can export GL_ARB_framebuffer_object or not >>> without having to create dummy surfaces. >> > >>> I'm not sure if all hardware we care about falls withing these two >>> categories. My suspicion is that they do. >> I'm not sure that's sufficient, unfortunately. The situation with >> 16/32-bit RGBA, Z, Z+S is simple but consider floating point surfaces. >> Also, take a look at GL_ARB_depth_buffer_float and its 64-bit >> FLOAT_32_UNSIGNED_INT_24_8_REV format. There may be others. It might >> be hard to determine which combinations work or don't work short of >> asking the driver to validate a particular combination of formats. > > I see... > >> I'd be happy with a get_param() call for now, but it may not be enough >> in the future. > > Yes, I have to agree. > > Sill, if possible, I'd prefer to avoid the creation of dummy surfaces. > My major concern is that they will make debugging harder: breakpointing > texture creation code will require special care to avoid breaking for > all these, traces will be full of these surface create/destroy stuff, > ditto for debug messages etc.
Yes, definitely. My first suggestion was just a prototype oriented toward the GL FBO case. > Perhaps make validate_framebuffer take just the relevant info instead of > surfaces, i.e., sizes and formats? Pretty much the same kind of balance > done with is_format_supported and texture_create. Yeah. I have a feeling Keith will want to weigh in on this too. :) -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
