#3541 closed enhancement (fixed)
[PATCH] passthru in Chromium for GL_VENDOR etc -> fixed in SVN.
Reported by: | Robert Millan | Owned by: | |
---|---|---|---|
Component: | 3D support | Version: | VirtualBox 2.1.4 |
Keywords: | Cc: | ||
Guest type: | Windows | Host type: | other |
Description
I extracted this from ticket 2940 to prevent confusion.
Patch:
http://www.virtualbox.org/attachment/ticket/2940/chromium_getstring_passthru.diff
Summary of the discussion:
http://www.virtualbox.org/ticket/2940#comment:33 http://www.virtualbox.org/ticket/2940#comment:54 http://www.virtualbox.org/ticket/2940#comment:55 http://www.virtualbox.org/ticket/2940#comment:57
Change History (9)
follow-up: 2 comment:1 by , 16 years ago
comment:2 by , 16 years ago
Replying to leonid:
I'd quote myself here...what will happen to wine when it'd recieve those strings from a real MacOS GPU driver? Does wine handle those strings for MacOS drivers as well?
Yes. Wine already supports running natively on MacOS. In fact, if you check dlls/wined3d/directx.c you'll see that it has very specific knowledge it (see for example the comments around the implementation_is_apple() function).
Or it'd crash the same way as when it sees Chromium at the moment?
It doesn't crash when it sees Chromium, it just falls back to Nvidia GeforceFX 5600 and reports the PCI Ids for that card. Still works, but it misses the opportunity to report Ids that would fit better (as explained in http://bugs.winehq.org/show_bug.cgi?id=17190#c2).
I'd say there're few ways to solve it in more or less "good" way. Either add wine<>vbox gl extension which would allow wine to query the exact information needed. PCI ids, gpu ram size or whatever else is needed by wine. Or vbox guest opengl lib could report those strings from some fixed list of drivers supported by wine. Where vbox lib chooses the one which is most closest to the host gpu driver.
Note that Wine derives PCI Ids from GL_RENDERER/etc even when run natively on GNU/Linux, where it wouldn't be so hard to get the actual PCI information directly. I'm not sure which reasons they have to avoid the assumption that Wine runs on the same machine that does the actual rendering (networked GLX scenario?), but this supports our use case _and_ seems to have worked well for them over the years, so why bother about it?
follow-up: 4 comment:3 by , 15 years ago
Summary: | [PATCH] passthru in Chromium for GL_VENDOR etc → [PATCH] passthru in Chromium for GL_VENDOR etc -> fixed in SVN. |
---|
Added this support when wine is loaded. Btw, wine detection code doesn't know about ATI HD4800.
comment:4 by , 15 years ago
Replying to leonid:
Added this support when wine is loaded.
Nice. But what do you mean with "when wine is loaded"? Are you checking for wine in some way or...
Btw, wine detection code doesn't know about ATI HD4800.
Strange, the code for HD4800 is there. What's your gl_renderer string?
if (strstr(gl_info->gl_renderer, "HD 4800")
strstr(gl_info->gl_renderer, "HD 4830") strstr(gl_info->gl_renderer, "HD 4850") strstr(gl_info->gl_renderer, "HD 4870") strstr(gl_info->gl_renderer, "HD 4890"))
{
gl_info->gl_card = CARD_ATI_RADEON_HD4800; vidmem = 512; /* HD4800 cards use 512-1024MB */
}
follow-up: 6 comment:5 by , 15 years ago
Yep, passthrough works only when wined3d.dll is loaded. Yes it's not very correct in some cases, like glview which checks both d3d and opengl at the same time.
Regarding hd4800: Hrm, perhaps it's newer than wine-1.1.21 we have in our tree.
comment:6 by , 15 years ago
Replying to leonid:
Yep, passthrough works only when wined3d.dll is loaded. Yes it's not very correct in some cases, like glview which checks both d3d and opengl at the same time.
Not bad..
Regarding hd4800: Hrm, perhaps it's newer than wine-1.1.21 we have in our tree.
Yes, 1.1.21 doesn't have the HD 4800 check.
Btw what are your plans wrt shipping wine in guest additions? Are they scheduled for any particular release?
Also, did you figure out a better way of dealing with WFP than running in safe mode?
I'd quote myself here...what will happen to wine when it'd recieve those strings from a real MacOS GPU driver? Does wine handle those strings for MacOS drivers as well? Or it'd crash the same way as when it sees Chromium at the moment?
I'd say there're few ways to solve it in more or less "good" way. Either add wine<>vbox gl extension which would allow wine to query the exact information needed. PCI ids, gpu ram size or whatever else is needed by wine. Or vbox guest opengl lib could report those strings from some fixed list of drivers supported by wine. Where vbox lib chooses the one which is most closest to the host gpu driver.