[Mesa-dev] [PATCH 3/4] radeonsi: add more unlikely() uses into si_draw_vbo

Marek Olšák maraeo at gmail.com
Thu Sep 8 09:42:02 UTC 2016


On Thu, Sep 8, 2016 at 3:56 AM, Michel Dänzer <michel at daenzer.net> wrote:
> On 07/09/16 11:01 PM, Nicolai Hähnle wrote:
>> On 07.09.2016 12:23, Marek Olšák wrote:
>>> On Wed, Sep 7, 2016 at 11:47 AM, Michel Dänzer <michel at daenzer.net>
>>> wrote:
>>>> On 07/09/16 06:02 PM, Marek Olšák wrote:
>>>>>
>>>>> Based on the comments so far, it looks like all annotations in the
>>>>> patch are very well placed, so I don't know what the fuss is about.
>>>>
>>>> As I said, there's no question about the first three annotations, but
>>>> for the last two we can't know whether they help or actually hurt
>>>> without measuring it. That's the whole point.
>>>
>>> OK. The last two are so rare that their likeliness is below 1%. The
>>> conditions are true when discarding CMASK or DCC, changing the micro
>>> tile mode of a texture, reallocating texture storage, and degrading
>>> the tile mode to linear. Some of those are caused by SDMA doing a
>>> whole-layer overwrite, a texture transfer, or a buffer handle export.
>>> Some of them can occur only once during the lifetime of a texture.
>>> They are very rare during normal gaming, which just consists of state
>>> changes and draw calls and nothing in between. I don't know about
>>> microbenchmarks.
>>
>> FWIW, though I haven't said so explicitly (other than sending my R-b
>> while this discussion was already going on), I also think those last two
>> cases are fine. We probably shouldn't go overboard with the (un)likely,
>> but really, the patch is fine as is.
>
> Okay, thanks.
>
> FWIW, my concern wasn't only about this patch itself but also about not
> wasting time on similar changes in the future.

30 seconds to write and commit it, and 10 seconds to review it isn't
gonna make a difference on anybody. Also, it should be kinda obvious
that I work more than 40 hours a week. I can do whatever I want in my
non-job time dedicated to drivers.

Marek


More information about the mesa-dev mailing list