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

[wine-bugs at winehq.org]

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

--- Comment #270 from Pierre-Loup Griffais <bugs.winehq.org at plagman.net> 2012-12-21 16:22:03 CST ---
(In reply to comment #269)
> 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.

ARB_map_buffer_range works great, I never implied otherwise. It just isn't
well-suited for dynamic buffer updates when you force-enable the multi-threaded
driver. Keep in mind I'm not trying to fix an NVIDIA performance problem here,
there isn't one that I know of. I'm showing you a way to get more performance
by using a combination of APIs and functionality that maps better to this use
case. You're acting like I'm trying to sneak code into Wine to work around
broken driver design. I would definitely recommend using ARB_map_buffer_range
for other use cases, where it makes sense.

(In reply to comment #269)
> I'm not sure why you'd want the CS to be involved at all, MapBuffer*() should
> essentially be a wrapper around ioremap_*().

Yes, that's "essentially" what it does. However it does return a value
immediately, so it has ensure any GL commands in-flight between the main and
worker threads are fully completed before it can be processed. I'll add that
before you can perform the mapping ioctl, you have to figure out which context
is current, which buffer name is bound, resolve that name, figure out what's
the state of the buffer, where it's stored, what rendering is in flight,
validate the access modes and plenty of other stuff.

-- 
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.