On Sat, Mar 2, 2013 at 3:02 AM, 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) :-).
Not sure if you noticed, but MSAA texturing has already been
implemented in Gallium [1][2] and some drivers (r600g, nouveau) for
quite some time. This opcode is implemented with TGSI_OPCODE_TXF and
the texture target set to TGSI_TEXTURE_2D_MSAA or
TGSI_TEXTURE_2D_ARRAY_MSAA. There are already sample shaders in
auxiliary/util/u_simple_shaders.c, which are used by u_blitter to blit
between two MSAA resources, which is required by glBlitFramebuffer
from GL_ARB_framebuffer_object.
Therefore, the MSAA texture support is somewhat required to fully
implement even the basic GL3.0 MSAA.
[1]
http://cgit.freedesktop.org/mesa/mesa/commit/?id=dacf5dc9ac1a700b86e0dc385513afaff41e7aea
[2]
http://cgit.freedesktop.org/mesa/mesa/commit/?id=825b45366d5308fd3e8e71c0c1943cb6ca8f69ea
Marek
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
