[Mesa-dev] [PATCH 0/5] Head-up display for Gallium DRI2 drivers

[Christoph Bumiller]

On 26.03.2013 12:18, Vadim Girlin wrote:
> On 03/26/2013 02:00 AM, Marek Olšák wrote:
>> On Mon, Mar 25, 2013 at 10:38 PM, Ondrej Holecek <aaannz at gmail.com>
>> wrote:
>>> On Saturday 23 of March 2013 00:50:59 Marek Olšák wrote:
>>>> Hi everyone, one image is better than a thousand words:
>>>> ...
>>>
>>> Hi,
>>>
>>> I tried your patches and hit a few problems. As first, they do not
>>> apply
>>> cleanly on master as they are expecting another your patch "cso: add
>>> constant
>>> buffer save/restore feature for postprocessing" to be present. But I
>>> guess you
>>> are aware of that.
>>
>> Yes, I sent the patch to mesa-dev earlier.
>>
>>>
>>> Second problem is that when I build mesa with HUD on my 32bit
>>> virtual machine,
>>> HUD works (with 32bit app of course). When I build it on 64bit (both
>>> are same
>>> uptodate OS openSUSE 12.3), HUD is not working (with 64bit app). I
>>> managed to
>>> track it down to failed IMM instruction parsing during HUD_create
>>> function. It
>>> appears that translate_ctx structure in tgsi_text_translate (file
>>> src/gallium/auxiliary/tgsi/tgsi_text.c) is not initialized to zeros
>>> under my
>>> 64bit system, instead ctx.num_immediates is equal to 1 and hence
>>> trigger
>>> "Immediates must be sorted" error.
>>> Following fixes HUD for me (note that I really don't know if I am
>>> not broking
>>> something here in regards to mesa):
>>>
>>> diff --git a/src/gallium/auxiliary/tgsi/tgsi_text.c
>>> b/src/gallium/auxiliary/tgsi/tgsi_text.c
>>> index 6b97bee..247ec75 100644
>>> --- a/src/gallium/auxiliary/tgsi/tgsi_text.c
>>> +++ b/src/gallium/auxiliary/tgsi/tgsi_text.c
>>> @@ -1577,6 +1577,7 @@ tgsi_text_translate(
>>>      ctx.tokens = tokens;
>>>      ctx.tokens_cur = tokens;
>>>      ctx.tokens_end = tokens + num_tokens;
>>> +   ctx.num_immediates = 0;
>>>
>>>      if (!translate( &ctx ))
>>>         return FALSE;
>>
>> I've sent a fix for this a couple of days ago:
>>
>> http://www.mail-archive.com/mesa-dev@lists.freedesktop.org/msg36038.html
>>
>>>
>>> The third issue is that on both 32bit and 64bit build fonts are not
>>> displayed
>>> in HUD. I see graphs and transparent background rectangles for text
>>> but no
>>> text is visible. This one I did not yet solve.
>>
>> Your driver must support the I8_UNORM texture format.
>
> I think this also may be related to unexpected by some drivers TGSI
> declaration of vertex shader inputs:
>
> DCL IN[0..1]
>

But this is in no way invalid, any driver that doesn't handle it is broken.

Moreover, ideally, IN/OUT should follow the same array declaration and
access semantics as TEMP, that's just not implemented yet because it's a
bit more involved (WIP).

> At least r600g expects the separate declaration for each input, though
> fortunately it still works in this case because parsed declarations of
> VS inputs aren't really used in r600g. I noticed exactly the same
> issue (missing text) with my r600-sb branch because it relies on the
> number of the parsed inputs from r600g's tgsi translator. It's 1 in
> this case instead of 2, so second input register is considered
> undefined and optimized away.
>
> I suspect that some other drivers may also handle this declaration
> incorrectly and this may explain the issue.
>
> Vadim
>
>>
>>>
>>> One last thought, is it intentional when wrong query is entered that
>>> hud graph
>>> is displayed but empty? Maybe some text like wrong query XXX would
>>> be a good
>>> hint. I know it is printed on stdout but looking for warnings in
>>> chatty apps
>>> like openarena is little tricky.
>>
>> Yes, it's intentional. I guess I can at least make it not draw an
>> empty pane.
>>
>> Marek
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>