[1/4] wined3d/context: Track the number of render targets in FBO entries.
hverbeet at gmail.com
Tue Mar 22 13:33:10 CDT 2011
On 22 March 2011 18:12, Adam Martinson <amartinson at codeweavers.com> wrote:
> On 03/22/2011 05:02 AM, Henri Verbeet wrote:
>> This is meaningless. Which applications, and how much time of the
>> total is spent in context_apply_fbo_state()?
> In the 3DMark06 batch size 8 test, as of Friday's tip, it was 5.5% of
> wined3d; 1.2% of total wine CPU time. Searching the FBO list is almost all
> of that. It's called every time drawPrimitive() is (assuming ORM_FBO), so
> that shouldn't be much of a shock.
I would hope that significant changes to fundamental parts of wined3d
would be backed up by a somewhat wider range of benchmark results.
>> How does this translate into concrete thing like frame time?
> It's an improvement, but I can't give you very meaningful FPS numbers there
> for individual patches. In my testing raw FPS is less reliable than profile
> results; it's dependent on GPU time as well, which I can't profile. The
> range of normal FPS variability is larger than the effect of most individual
> patches, including this one.
GPU time matters. Freeing up CPU time just so you can spend more time
waiting for the GPU to finish isn't all that useful.
>> More importantly, why does this change come before the one for
>> tracking FBO dirty state?
> Really? I sent both at the same time, and the order bothers you? Really??
Really. And I did even explain why. Note that while displays of
disbelief rarely help with getting patches committed, solid arguments
tend to do just fine.
>> Avoiding redundant FBO entry comparisons completely is likely to
>> have a much more significant effect than making the comparisons
>> themselves slightly cheaper in very specific applications.
> Actually, it would take a much more specific FBO configuration for this to
> make no difference. The whole list would have to have the same number of
> render targets, and almost all of them full. memcmp() is expensive.
> Avoiding unnecessary comparisons is cheap. This makes both successful and
> unsuccessful FBO entry comparisons cheaper. The other patch helps too,
> that's why I submitted both.
I'm quite aware of the costs of memory accesses, thanks.
So, to be more explicit this time:
- I understand just fine what the patch actually does.
- I'm not opposed to this change in principle, but you will have to
justify changes like these.
- How much of a real difference does this patch make, after you
avoid the redundant lookups? (I.e., after the second patch in this
More information about the wine-devel