Am 02.03.2013 04:26, schrieb Dave Airlie:
> On Sat, Mar 2, 2013 at 12:02 PM, Roland Scheidegger <srol...@vmware.com>
> wrote:
>> Am 02.03.2013 01:36, schrieb Brian Paul:
>>> ---
>>> src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 3 +++
>>> 1 files changed, 3 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
>>> b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
>>> index 8e3e3b8..c41b583 100644
>>> --- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
>>> +++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
>>> @@ -2746,6 +2746,9 @@ glsl_to_tgsi_visitor::visit(ir_texture *ir)
>>> offset = this->result;
>>> }
>>> break;
>>> + case ir_txf_ms:
>>> + assert(!"Unexpected ir_txf_ms opcode");
>>> + break;
>>> }
>>>
>>> if (ir->projector) {
>>>
>>
>> Series looks good to me. I guess we need a new opcode like
>> (TGSI_OPCODE_TXF_MS?), unless we switch everything over and only use the
>> new sample style opcodes which already have that (SAMPLE_I_MS) :-).
>
> I'm not really sure we do, from what I can see TXF is sufficent since
> LOD is bogus with MS textures so you can reuse the slot. r600 hw at
> least only has one LD instruction from what I can see.
Hmm yes but it doesn't sound like a very clean solution, to reuse the
opcode for something a bit different. Though granted since with the
combined texture/sampler state you always know the target (unlike with
the sample_i opcodes) it should be always possible to distinguish
txf-with-lod from txf-with-sample so it might indeed be ok.
Roland
>
> I've already done a good bit of the state tracker for this, I just
> need to get a driver I can run it on :-)
> (gallium-texture-multisample branch in my repo)
>
> Dave
>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
