[Bug 11674] Dual-core unsupported in WoW and SC2

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=11674

--- Comment #269 from Henri Verbeet <hverbeet at gmail.com> 2012-12-21 15:53:02 CST ---
(In reply to comment #268)
> (In reply to comment #267)
> > D3D "dynamic" buffers end up using either GL_MAP_UNSYNCHRONIZED_BIT or
> > GL_MAP_INVALIDATE_BUFFER_BIT on glMapBufferRange(), and shouldn't require
> > synchronization with the command stream at all; it's the application's
> > responsibility to ensure all accesses are safe.
> 
> It's still a synchronous API that needs to return a pointer immediately,
> though, so it stalls the CPU command stream between the main and worker thread
> in the driver. Which, in turn, can introduce GPU starvation.
> 
I'm not sure why you'd want the CS to be involved at all, MapBuffer*() should
essentially be a wrapper around ioremap_*().

> You'd think the performance gains I demonstrated (and that Stefan observed in
> real-world usage) would be justification enough.
> 
Well, no.

> if performance problems are uncovered (if any). It certainly seems like a
> better approach than trying to fix drivers to optimize paths for usage patterns
> that don't make sense at the cost of introducing overhead for usage patterns
> that do.
> 
If you really feel you can't possibly make ARB_map_buffer_range work correctly,
you probably shouldn't expose the extension at all. The fallback path we
currently have for that would need some improvements, but that shouldn't be
much of a problem.

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.