Re: [Mesa3d-dev] Grab bag of random questions (whoo)

[Corbin S. <mos...@gm...>]

In r300 we already have had to cross several states to get conformant
rendering in some situations. It's not terribly fun, but it's
necessary. IIRC textures and samplers were the first to be emitted
together.

On Sun, Jan 31, 2010 at 9:41 AM, Christoph Bumiller
<e04...@st...> 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 ...
>
> Christoph
>>>     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
>> Mes...@li...
>> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>>
>
>
> ------------------------------------------------------------------------------
> 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
> Mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>



-- 
Only fools are easily impressed by what is only
barely beyond their reach. ~ Unknown

Corbin Simpson
<Mos...@gm...>