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ć <smoki00...@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 <mar...@gmail.com>: >> On Tue, Jan 15, 2013 at 7:15 PM, Alex Deucher <alexdeuc...@gmail.com> >> wrote: >>> On Fri, Jan 11, 2013 at 6:37 AM, smoki <smoki00...@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 >> > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev