Marek Olšák wrote: > 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. It could. But generally, gallium doesn't implement features common hardware can't do (not only because most drivers except software based ones couldn't implement it, but those features also turn out to be rarely used, for obvious reasons). r300 is an exception here since it emulates ARB_shadow anyway. Though I think if you can make a case why this is really necessary it could be done, but that's not my call.
> > 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. Note R300 is again special a bit here. Actually, I realized my earlier answer doesn't make sense. Hardware which actually supports EXT_texture_swizzle (and native ARB_shadow) should be able to implement this easily. Hardware like i965 which doesn't support EXT_texture_swizzle could do it in the shader. Maybe it would make sense to add EXT_texture_swizzle capability in gallium (in the sampler state). That would solve this in a bit more generic way than some special bits for depth texture mode. > > 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. Where did you see that it's removed in 10.1? Here's a list of blend ops in d3d11: http://msdn.microsoft.com/en-us/library/ee416042(VS.85).aspx Note this feature can be present (via cap bits in some limited form) in D3D9Ex too, and I thought windows actually used it for (antialiased) text rendering (but don't quote me on that). > > 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 also think even r500 shouldn't say this is supported. Just changing the colormasks isn't going to be very correct... Roland ------------------------------------------------------------------------------ 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
