On 01.02.2010 18:37, Roland Scheidegger wrote: > On 31.01.2010 18:41, Christoph Bumiller wrote: > >> On 31.01.2010 01:37, Roland Scheidegger wrote: >> >>> 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. >>> >>> >>> >> From my point of view adding a swizzle in the sampler state >> is a bad idea. >> >> On nv50, this would make texture setup dependent on >> sampler state: we have an Image and Sampler configuration >> buffer containing entries that can be bound to texture and >> sampler "units". >> The texture swizzle would be supported by setting a different >> format in the image entry, like BGRA instead of RGBA, just >> that it also supports RGRG or whatever you like. >> >> Well, the normalization bit seems to be stored in the TIC >> entries instead of the TSC ones already, I guess that comes >> from the rectangle texture type, but let's ignore that. >> >> I don't see texture swizzle in d3d10 (but then, I don't know d3d10 >> very well), and OpenGL doesn't separate textures and samplers >> anyway, so I'd put in in texture state. >> Keeping a bunch of shaders for texture swizzles doesn't sound >> nice either. >> >> Of course, if other hardware would prefer this in sampler state, >> then ... ah, I should probably let go of the illusion that gallium state >> will continue to nicely map to my hardware ... >> > I don't know if other hardware likes it in sampler state, but the > problem is it really is sampler state. This is not a property of the > texture, it can change anytime and you don't want to recreate the > texture just because this changes, I think. > I'm not sure how to implement this nicely neither, but I'd guess we'd at > least wanted to indicate the swizzle fields to correspond to hardware > channels (so for a luminance_alpha texture, the swizzle would indicate > rrrg for the first and second channels respectively), not the > GL-after-sampling mapping as the extension uses. > Hence depth textures used as luminance would be rrr1, as alpha 000r, and > as intensity rrrr. > So, basically, a texture a8l8 texture would be equivalent to a r8g8 > texture, when used for sampling with the same swizzling. > Note that an easy solution (for depth textures) would be to add just new > depth texture formats (one for each alpha, luminance, and intensity > mode), but then again you make this part of the texture, which it is not. > Those are just some quick thoughts however, I don't think anyone would > be opposed if you can come up with a nice solution for this. > > > Roland > You're right, having to destroy and recreate the texture when the swizzle changes is a bad idea. And adding a mutable swizzle entry to pipe_texture is too, or at least it's equivalent to me keeping a private last_swizzle and re- uploading the image entry when it changes.
That said, I'm fine with the idea of a swizzle entry in the sampler state now, in the format that each swizzle entry indicates which data element to use (the 1st, 2nd, ..., one or zero). E.g. for R8G8, swizzle = 2 / Z would be invalid ... yes, I think I'm thinking the same way you do here. Christoph ------------------------------------------------------------------------------ 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
