[Nouveau] [PATCH 1/2] nvfx: restore BEGIN_RING usage

[Xavier Chantry]

There is indeed exactly the same problem with MARK_RING.
There is always one MARK_RING guarding each OUT_RELOC, but in several
cases there is only one MARK_RING for several OUT_RELOC, and some not
completely obvious and transparent size computation.

coccinelle does not help to check the sizes are correct, but here is
manual review :
nv30_fragtex nv40_fragtex nvfx_fragprog nvfx_fragtex : direct 1-1 mapping
nv04_2d nvfx_state_fb : not direct, but looks correct to me
nvfx_vbo : no idea, this one is awful :P

On Sun, Dec 26, 2010 at 12:02 PM, Michel Hermier
<michel.hermier at gmail.com> wrote:
> After cleaning my tree to match this change, I noticed a small
> potential issue which is not very likely to happens but still migth
> exist. The MARK_RING required to check OUT_RELOC calls are not
> updated. The issue is small since whe most probably will runout off
> pushbuffer space before runing out of relocs and the relocs is well
> protected introducing only graphical issues.
> Since you known how to use coccocinelle could you check that the
> BEGIN_RING followed by OUT_RELOC are guarded with a MARK_RING?
>
>
> 2010/12/25 Xavier Chantry <chantry.xavier at gmail.com>:
>> Michel Hermier reported libdrm segfault (and kernel crash) on nv40 using
>> gallium :
>> http://www.mail-archive.com/nouveau@lists.freedesktop.org/msg06563.html
>>
>> It turns out these were caused by some missing WAIT_RING (or wrong
>> computation of the WAIT_RING sizes). Unlike all other libdrm_nouveau users,
>> nvfx gallium tried to use a mininum calls of WAIT_RING, one WAIT_RING could
>> apply to many methods for different code paths and spread across several
>> functions. This made it too tricky to find out what the missing or wrong
>> WAIT_RING was.
>>
>> By restoring BEGIN_RING, we force one WAIT_RING per method, and it's much
>> easier to check if the free size required in the pushbuffer is correct.  As
>> curro said, "let's keep it simple for the maintainers until the big
>> bottlenecks are gone"
>>
>> Benchmarked on nv35 with openarena, nexuiz and ut2004 and no performance
>> regression.
>>
>> The core of this patch was made with Coccinelle, with minor manual fixes
>> made on top.
>