[Mesa-dev] [PATCH] radeon/r200: Fix FBO formats

[Milan Kostić]

 It is weird, i am not sure what happens neither. I assume because in
emit_cb_setup XRGB8888 is mapped to dst_format
R200_COLOR_FORMAT_ARGB8888, but in emit_tx_setup XRGB8888
src_mesa_format not have alpha. It looks OK but does not work good for
some reason, so i added R200_TXFORMAT_ALPHA_IN_MAP too for XRGBA8888
in emit_tx_setup and that works for supertuxkart 0.8. But OK maybe
better to give some pictures:

 http://www.dodaj.rs/f/1c/Ff/4ZlFMtzI/nonfbo-chooserblack.png
 http://www.dodaj.rs/f/1U/Fz/HKSFaBi/non-fbo-minimapblack.png

 That is with current mesa git master, so no my patches;). If i just
add R200_TXFORMAT_ALPHA_IN_MAP to XRGBA8888 i've got then correct
picture:

 http://www.dodaj.rs/f/x/2K/2ah6xJEt/correctpicture-stk-nofbo.png

  What is also weird further is that supertuxkart 0.8 win32 version
under wine works OK no patches needed, and it of course works OK under
Windows XP. Weird thing is also that same native linux version also
works OK with UMS and mesa 7.5.2. (a have separate partition and UMS
setup with debian stable).

  And that is all with non-fbo usage - supertuxkart have option to
turn on/off FBOs.

  And when we now are in FBO land things played a bit different,
modeles under chooser does not have blackiness anymore but instead
they are transparent:

  http://www.dodaj.rs/f/1M/ji/2R2kGrJM/fbo-choosermodeltranspar.png
  http://www.dodaj.rs/f/1u/l6/GyPqykT/2013-01-17-1813421372x79.png

  Dont know how to patch that to not be transparent there? Again it
only works that weird under native linux version, but same thing
transparence i spotted under different game Drawn 2 under wine (game
has direct3d and opengl renderer, i use opengl), this game needs patch
from fdo bug 27704 to display text on some elements, current git and
no text:


  http://www.dodaj.rs/f/3Y/RO/2QNH1eQd/nopatch-notext.png

  with the patch from fdo bug 27704 text started to work:

  http://www.dodaj.rs/f/22/F6/19Eambg3/withpatch-transparent-te.png

  And that is quite OK, but now compare text with proper picture:

  http://www.dodaj.rs/f/1C/LN/bAceMUz/correctpicture.png

  It is maybe hard to be spotted but it is transparent ;), the same
thing i guess hit trasparence of models in supertuxkart.

2013/1/16, Milan Kostić <smoki00790 at gmail.com>:
>  No, no regress in piglit i've seen at all, only better... i even
> played whole Drawn 2 game:
>  http://www.drawngame.com/games/dark-flight
> under wine in OpenGL mode, it works perfectly now, needs culling under
> fbo which is fixed now and this fix to display text and so works
> exactly the same as with nvidia on Windows.
>
>  It can further pass 2 more test in piglit if those are ported from intel:
>
>  fbo-nodepth-test
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=4d4f2daefabdc4ca1dd778a9265475c65ef52936
>
>  i've tried that one and it pass and maybe this for fbo-cubemap - but
> not tried:
>
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=80513ec8b4c812b9c6249cc5824337a5f04ab34c
>
>  Now i checked supertuxkart game, it has some problems with alpha in
> XRGB8888 format. Under non-fbo mode kart model have black background,
> and under fbo models are transparent. I fixed it for non fbo case with
> R200_TXFORMAT_ALPHA_IN_MAP for XRGB8888 also in r200_blit, but don't
> know where is this format controled for fbos?  I mentoioned this
> because text is slightly transparent also in that Drawn game, it only
> works with with fbo extension in opengl mode, i guess that needs the
> same fix for XRGB8888 format to expect alpha under fbo, etc... But OK
> that can be another bug :).
>
> 2013/1/16, Marek Olšák <maraeo at gmail.com>:
>> On Tue, Jan 15, 2013 at 7:15 PM, Alex Deucher <alexdeucher at gmail.com>
>> wrote:
>>> On Fri, Jan 11, 2013 at 6:37 AM, smoki <smoki00790 at gmail.com> wrote:
>>>> Piglit passes more fbo tests on rv280, 14/28 before and now 28/33.
>>>> Also should fix bug:
>>>> https://bugs.freedesktop.org/show_bug.cgi?id=27704
>>>
>>> Does this regress anything in piglit?  It's been a while since I
>>> looked at this code, I think the issue may be that r1xx/r2xx asics
>>> only support ARGB render buffers while the texture hardware supports
>>> both ARGB and RGBA formats so you may run into cases where you can
>>> texture from a buffer, but can't render to it, at least not without an
>>> intermediate blit to convert the format first.
>>
>> In r300g, I decided to only support RGBA and BGRA formats and not ARGB
>> and ABGR because of a lack of blending support. Maybe we should do the
>> same for r1xx/r2xx to make things simpler.
>>
>> Marek
>>
>