On Sat, Jan 30, 2010 at 8:24 AM, Marek Olšák <mar...@gmail.com> wrote: > Hi Corbin, > > On Sat, Jan 30, 2010 at 1:06 PM, Corbin Simpson <mostawesomed...@gmail.com> > wrote: >> >> 5) ... Also, on the topic of framebuffers, is >> it okay to refuse to render if no MRTs or Z buffer are present? > > Do you mean color-only and depth-only rendering? This is a must. Shadow > mapping heavily relies on depth-only rendering. OTOH post-processing effects > like HDR, bloom, depth of field, later parts of deferred-rendering methods, > and many other advanced methods require color-only rendering. The FBO > extensions allows either no color attachment or no depth-stencil attachment. > I know there are inter-CSO depedencies in r300g because of this, but I don't > see any other way around it.
I should have said "and," not "or." I was thinking about sanity tests, and whether it should be possible, legal, or good to bind no targets at all to the framebuffer_state. We already refuse to bind too many MRTs, so it wouldn't be a big change; I was thinking in terms of a rule for Gallium, along the lines of: If the number of colorbuffers attempting to be bound exceeds MAX_RENDER_TARGETS as reported by get_param, the context may refuse to bind the state. If there are no colorbuffers bound, and no depthbuffer bound, the context may refuse to bind the state. This could be consolidated into boolean u_check_framebuffer_state(struct pipe_context*, const struct pipe_framebuffer_state*); at that point. >> 6) GL_ARB_shadow_ambient and texture compare-fail values. A comment in >> the fragment constants reads, "Since Gallium doesn't support >> GL_ARB_shadow_ambient, this is always (0,0,0,0), right?" > > I think the extension could be added to Gallium since the r300 compiler can > generate code for it. But we'd either need to PIPE_CAP it or make it optional. I'm starting to compile a list of requirements for Gallium hardware targets, and this is one of those things that might make more sense at the st level. See Roland's comments. >> Another >> comment reads, "Gallium doesn't provide us with any information >> regarding this mode, so we are screwed. I'm setting 0 = LUMINANCE," >> above the texture compare modes. I don't really like that section of >> code, but it probably can't get cleaner, right? > > Even though this is a rarely used feature in OpenGL nowadays, it should get > fixed if we want to be GL-compliant. That means adding depth texture modes > in pipe_sampler_state and setting them in the Mesa state tracker. The R300 > compiler can already generate code for these modes as well. Need to check how many other drivers can handle it. >> 7) Is there more information on the dual-source blend modes? I'm not >> sure if I can do them; might have to bug AMD for the register values. > > I bet R300 can't do these modes. It's only a Direct3D 10.0 feature, not > present in Direct3D 10.1. MS must have a good reason to remove it. See my comments with Roland. > BTW I looked at some of your patches and r3xx-r5xx cards don't even support > separate blend enables, therefore the cap should be 0. Or are you going to > emulate this using independent color channel masks and two rendering passes? > That could be done in the state tracker. Also, I think the indep. color > masks are r5xx-only. I'll double-check in the docs. We should have support for separate blend enables through the colormasks, at least, but if that's r500-only then I'll have to do a test and such. Thanks for the heads-up. > Cheers. > > Marek > ~ C. -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson <mostawesomed...@gmail.com> ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
