Re: Conformance tests
On Fri, Aug 14, 2009 at 3:10 PM, Keith Muir wrote: > What disturbs me about the conformance tests is that yes there are 0% > failures but when you check you discover its 0% failures on virtual > machines. Failures on real hardware under XP can reach as high as 6% with > peaks greater than that. Windows is tolerant of all types of hardware wine > still isn't. I may be stating the obvious but hardware tolerance must be a > goal for the wine project if it isn't already. Those conformance tests shouldn't care about hardware (graphics tests aside). When testing 'bare iron', you're likely to be testing non-clean installs. Virtual machines have the benefit that they can be reset each day, so e.g., old cruft from tests, other applications, etc. aren't there to mess up the results. A lot of the 'real' machines also aren't necessarily english locales, or have a different DPI set, which breaks some tests. -- -Austin
RE: about video memory detection in wine
Thanks, I will do it later Regards Sunny -Original Message- From: Henri Verbeet [mailto:hverb...@gmail.com] Sent: Friday, August 14, 2009 7:26 PM To: Sun, Sunny Cc: wine-devel@winehq.org Subject: Re: about video memory detection in wine Could you please subscribe to wine-devel (http://www.winehq.org/mailman/listinfo/wine-devel) so your mail doesn't have to go through moderation? It's possible to disable mail delivery if you don't want to receive all the mail.
RE: about video memory detection in wine
Hi
We have implemented GL_TOTAL_PHYSICAL_MEMORY for about 8 months, so you will
not get the GL_INVALID_ENUM error. I think it will be documented later.
I have tested with your patch with 3 ATI asics, all of them can get the correct
amount of video memory (1GB, 256MB, 128MB).
For the reason that GL_TOTAL_PHYSICAL_MEMORY is implemented after
GL_ATI_meminfo, so if a user uses too old driver (about before Catalyst 9.2),
he may have problems to get the correct amount of video memory, so I suggested
to add the following code in your patches:
+if(GL_SUPPORT(ATI_MEMINFO))
+{
+/* All GL_ATI_meminfo enums return 4 ints, even the (undocumented)
+ * GL_TOTAL_PHYSICAL_MEMORY_ATI one, which returns {mem, 0, 0, 0} */
+GLint mem[4] = {0};
+/* Returns the vidmem in KB */
+glGetIntegerv(GL_TOTAL_PHYSICAL_MEMORY_ATI, mem);
+TRACE("Video memory from OpenGL: %d MB\n", mem[0] / 1024);
+gl_info->vidmem = mem[0] * 1024; /* convert from KBs to bytes */
+if(gl_info->vidmem < 64 * 1024 * 1024)
+gl_info->vidmem = 64 * 1024 * 1024;
+}
Please tell me if you have any questions, thanks and good night!
Regards
Sunny
-Original Message-
From: Stefan Dösinger [mailto:stefandoesin...@gmx.at]
Sent: Friday, August 14, 2009 7:13 PM
To: Sun, Sunny
Cc: Roderick Colenbrander; wine-devel@winehq.org; ORCA Linux
Subject: Re: about video memory detection in wine
Hi,
Can you give the attached patches a try? Do they detect the correct amount of
video memory?
Thanks,
Stefan
Am Friday 14 August 2009 11:58:12 schrieb Sun, Sunny:
> Hi
>
> I think it is difficult to maintain a large list of all ASICs, for you have
> to change the list from time to time when a new ASIC is released. Actually
> we have provided the functionality for getting total video memory, you can
> use the following code to get the total video memory with ATI cards.
>
> #define GL_TOTAL_PHYSICAL_MEMORY_ATI0x87FE
>
> const char *glExtensions = (const char*)glGetString(GL_EXTENSIONS);
>
> if(strstr(glExtensions, "GL_ATI_meminfo"))
>
> {
>
> int total_mem[4] = {0};
>
> glGetIntegerv(GL_TOTAL_PHYSICAL_MEMORY_ATI, total_mem); //
> total_mem[0] contains the total video memory size and the value is in Kbyte
>
> vidmem = total_mem[0] / 1024; //converting from Kbyte to Mbyte
>
> }
>
>
>
> Regards
>
> Sunny
>
> -Original Message-
> From: Roderick Colenbrander [mailto:thunderbir...@gmail.com]
> Sent: Friday, August 14, 2009 1:44 AM
> To: Stefan Dösinger
> Cc: wine-devel@winehq.org; Hu, Li; Jin, Jian-Rong; Wang, Robin; Guan,
> Xiao-Feng; Sun, Sunny Subject: Re: about video memory detection in wine
>
> On Thu, Aug 13, 2009 at 6:59 PM, Stefan Dösinger
wrote:
> > Am Wednesday 12 August 2009 10:04:10 schrieb Sun, Sunny:
> >> I think you can first detect GL_ATI_meminfo in
> >>
> >> glGetString(GL_EXTENSIONS); if GL_ATI_meminfo exists, then you can use
> >>
> >> glGetIntegerv(GL_VBO_FREE_MEMORY_ATI, param) to get the current free
> >>
> >> video memory, you can see more info at:
> >
> > A minor problem with GL_ATI_meminfo is that it doesn't report the total
> > amount
> >
> > of video memory available. D3D8 and D3D9 only report the free amount as
> > well,
> >
> > but DirectDraw can return the total amount. There are some games that
> > first
> >
> > query the total amount using ddraw, then continue with d3d8 or 9.
> > Depending
> >
> > on what other apps are doing, reporting the currently free amount as
> > total
> >
> > might result in the app thinking that free vidmem > total vidmem, running
> >
> > into all sorts of troubles. (For example, another app frees a lot of
> > textures
> >
> > between the ddraw vidmem query and the d3d9 vidmem query)
>
> It is even worse. Even OpenGL apps like WoW use ddraw for querying the
>
> amount of video memory at startup!
>
> In case of Nvidia the amount of video memory and the pci ids are
>
> advertised using the NV-CONTROL extension. At some point I plan on
>
> adding code for that. Even when using such extension the current
>
> fallback is still needed. The list needs some updates.
>
> > The other issue is that if some other apps use lots of video memory(like
> >
> > Compiz, etc), then we can still run into the same out of memory issue if
> >
> > other apps consume too much video memory.
> >
> >
> >
> > We should probably also fall back to a saner default on newer d3d10 class
> >
> > cards - a radeon 9500 isn't really representative for them any more.
>
> I still have to update that part but haven't had time for it yet.
>
>
>
> Roderick
RE: about video memory detection in wine
Hi
I think it is difficult to maintain a large list of all ASICs, for you have to
change the list from time to time when a new ASIC is released. Actually we have
provided the functionality for getting total video memory, you can use the
following code to get the total video memory with ATI cards.
#define GL_TOTAL_PHYSICAL_MEMORY_ATI0x87FE
const char *glExtensions = (const char*)glGetString(GL_EXTENSIONS);
if(strstr(glExtensions, "GL_ATI_meminfo"))
{
int total_mem[4] = {0};
glGetIntegerv(GL_TOTAL_PHYSICAL_MEMORY_ATI, total_mem); // total_mem[0]
contains the total video memory size and the value is in Kbyte
vidmem = total_mem[0] / 1024; //converting from Kbyte to Mbyte
}
Regards
Sunny
-Original Message-
From: Roderick Colenbrander [mailto:thunderbir...@gmail.com]
Sent: Friday, August 14, 2009 1:44 AM
To: Stefan Dösinger
Cc: wine-devel@winehq.org; Hu, Li; Jin, Jian-Rong; Wang, Robin; Guan,
Xiao-Feng; Sun, Sunny
Subject: Re: about video memory detection in wine
On Thu, Aug 13, 2009 at 6:59 PM, Stefan Dösinger wrote:
> Am Wednesday 12 August 2009 10:04:10 schrieb Sun, Sunny:
>
>> I think you can first detect GL_ATI_meminfo in
>> glGetString(GL_EXTENSIONS); if GL_ATI_meminfo exists, then you can use
>> glGetIntegerv(GL_VBO_FREE_MEMORY_ATI, param) to get the current free
>> video memory, you can see more info at:
> A minor problem with GL_ATI_meminfo is that it doesn't report the total amount
> of video memory available. D3D8 and D3D9 only report the free amount as well,
> but DirectDraw can return the total amount. There are some games that first
> query the total amount using ddraw, then continue with d3d8 or 9. Depending
> on what other apps are doing, reporting the currently free amount as total
> might result in the app thinking that free vidmem > total vidmem, running
> into all sorts of troubles. (For example, another app frees a lot of textures
> between the ddraw vidmem query and the d3d9 vidmem query)
It is even worse. Even OpenGL apps like WoW use ddraw for querying the
amount of video memory at startup!
In case of Nvidia the amount of video memory and the pci ids are
advertised using the NV-CONTROL extension. At some point I plan on
adding code for that. Even when using such extension the current
fallback is still needed. The list needs some updates.
> The other issue is that if some other apps use lots of video memory(like
> Compiz, etc), then we can still run into the same out of memory issue if
> other apps consume too much video memory.
>
> We should probably also fall back to a saner default on newer d3d10 class
> cards - a radeon 9500 isn't really representative for them any more.
>
I still have to update that part but haven't had time for it yet.
Roderick
Re: shell32: fix program search in ShellExecuteEx, quote program name if it contains spaces (resend)
Hi Stefan, >> + if((needs_quote = NULL != strstrW(wszApplicationName,wSpace))) >> + len +=2; >> > i don't understand what you mean here with "complicated", please explain it. Questions of style are always in the eye of the beholder, aren't they? ;-) I'd say breaking the statement into two would be easier to understand: needs_quote = strstrW(wszApplicationName, wSpace) != NULL; if (needs_quote) len += 2; Thanks, --Juan
Re: shell32: fix program search in ShellExecuteEx, quote program name if it contains spaces (resend)
Am Friday 14 August 2009 18:05:23 schrieb Juan Lang: > > Finally, this isn't about whitespace but style: > +if((needs_quote = NULL != strstrW(wszApplicationName,wSpace))) > +len +=2; > > The expression in the if is unnecessary complicated. You could use > consistent spacing here too. Hi Juan, i don't understand what you mean here with "complicated", please explain it. Thanks Stefan
Re: about video memory detection in wine
Am Friday 14 August 2009 18:52:36 schrieb Henri Verbeet: > I'm only seeing half of the discussion here (the other half is > probably still in moderation...), but that doesn't sound like a good > idea. Is there any reason the extension can't be fixed to include > this, or alternatively a second extension created? The issue is that GL_TOTAL_PHYSICAL_MEMORY was added a bit after the other 4 query flags, Sunny says they're working on adding it to the spec. So there is a range of fglrx version that supports ATI_meminfo, but returns zero on GL_TOTAL_PHYSICAL_MEMORY_ATI. So if we want to use this as-is we have to take care that we don't set the vidmem to zero accidentally. Another extension is a possible way to go, but there are still r300 to r500 chips where the driver has been discontinued and where the vidmem info is useful too. These cards most likely won't get the new extension in that case. @AMD: The discontinuing of fglrx for r300-r500 chips is really a pain for us. There's essentially no way to use those cards on Linux right now. The Open Source driver that ships with current distros can't even run 3DMark 2000 properly, and the 9.3 driver doesn't run on up to date distros. Currently I have to tell everyone who has such a card that it probably won't be useable for probably another year :-(
Conformance tests
What disturbs me about the conformance tests is that yes there are 0% failures but when you check you discover its 0% failures on virtual machines. Failures on real hardware under XP can reach as high as 6% with peaks greater than that. Windows is tolerant of all types of hardware wine still isn't. I may be stating the obvious but hardware tolerance must be a goal for the wine project if it isn't already. Regards, Keith
Re: about video memory detection in wine
On Fri, Aug 14, 2009 at 9:41 PM, Stephen Eilert wrote: > > > > On Fri, Aug 14, 2009 at 4:23 PM, King InuYasha wrote: >> >> This seems like the wrong way to go. I'm wondering if there is another way >> to detect VRAM? There should be a way to determine VRAM from Xorg? Why >> should OpenGL or DirectDraw be the method that Wine uses to determine video >> RAM? Why should Wine have a fixed value based on a list? Maybe I'm being >> stupid, but I think it would make sense for the display server (xorg) to >> know how much VRAM a graphics card has... > > Just a nitpick: Wine does not *use* DirectDraw, it *implements* DirectDraw, > as there's no DirectDraw anywhere other than win32. > > I see no problem querying OpenGL, if the extensions can be trusted to > provide useful values - even if they are undocumented or not always > available. The problem with the approach so far seems to be that this > extension is ATI-specific. Then again, the current fallback can be left in > place if Wine does not find a way to properly detect the VRAM amount. > > As for asking Xorg, I do not have the knowledge to say if it is feasible - > but one would think that would've been tried long ago if it were > straightforward. > > > --Stephen > > programmer, n: > A red eyed, mumbling mammal capable of conversing with inanimate > monsters. > Xorg explicitly doesn't tell programs how much memory they have as it can lead to bad designs and these days cards have a sufficient amount of memory for 2D. In case of 3D programs the amount of memory is more important to have. OpenGL itself (except using the ATI extension) does not provide a way to query the amount of video memory or the exact videocard (yes it exports the renderer string but d3d exports the pci id as well. Like X, OpenGL wants to hide this information from the designer. Though these days this information is becoming more and more important for designers as they can decide to e.g. use a different code path. Native Linux games like Quake Wars for this reason use vendor specific extensions like NV-CONTROL to obtain some info. It might make sense to have a cleaned up version of the ATI memory extension as real ARB extension. For modern games it is crucial. Hopefully AMD can clean it up. When I last checked this extension months ago the total amount of memory wasn't in the spec, it might make sense to update the spec. Regards, Roderick Colenbrander
Re: about video memory detection in wine
On Fri, Aug 14, 2009 at 4:23 PM, King InuYasha wrote: > This seems like the wrong way to go. I'm wondering if there is another way > to detect VRAM? There should be a way to determine VRAM from Xorg? Why > should OpenGL or DirectDraw be the method that Wine uses to determine video > RAM? Why should Wine have a fixed value based on a list? Maybe I'm being > stupid, but I think it would make sense for the display server (xorg) to > know how much VRAM a graphics card has... Just a nitpick: Wine does not *use* DirectDraw, it *implements* DirectDraw, as there's no DirectDraw anywhere other than win32. I see no problem querying OpenGL, if the extensions can be trusted to provide useful values - even if they are undocumented or not always available. The problem with the approach so far seems to be that this extension is ATI-specific. Then again, the current fallback can be left in place if Wine does not find a way to properly detect the VRAM amount. As for asking Xorg, I do not have the knowledge to say if it is feasible - but one would think that would've been tried long ago if it were straightforward. --Stephen programmer, n: A red eyed, mumbling mammal capable of conversing with inanimate monsters.
Re: about video memory detection in wine
This seems like the wrong way to go. I'm wondering if there is another way to detect VRAM? There should be a way to determine VRAM from Xorg? Why should OpenGL or DirectDraw be the method that Wine uses to determine video RAM? Why should Wine have a fixed value based on a list? Maybe I'm being stupid, but I think it would make sense for the display server (xorg) to know how much VRAM a graphics card has... On Fri, Aug 14, 2009 at 1:42 PM, Jesse Allen wrote: > On Fri, Aug 14, 2009 at 10:30 AM, Stefan Dösinger > wrote: > > Am Friday 14 August 2009 18:01:07 schrieb Sun, Sunny: > >> +if(gl_info->vidmem < 64 * 1024 * 1024) > >> +gl_info->vidmem = 64 * 1024 * 1024; > > I guess the idea is that no ATI card that was ever supported on fglrx has > less > > than 64 mb of memory? My old radeon 9000, which isn't supported by fglrx > > since years now has 64 MB. Does this hold true for radeon 8500 cards too? > > > > I think I'll use the guessed amount of vidmem in this case instead of > > hardcoding 64 MB. > > > > Using the undocumented value and the check for older drivers which don't > > support it is a bit hacky, but its a well-isolated hack and avoids a lot > of > > problems, so it should be ok. > > > > > > > > My Radeon 9200 has 128 MB. But I've never used fglrx on it either, so > I don't know what this gains. > > >
Re: about video memory detection in wine
On Fri, Aug 14, 2009 at 10:30 AM, Stefan Dösinger wrote: > Am Friday 14 August 2009 18:01:07 schrieb Sun, Sunny: >> +if(gl_info->vidmem < 64 * 1024 * 1024) >> +gl_info->vidmem = 64 * 1024 * 1024; > I guess the idea is that no ATI card that was ever supported on fglrx has less > than 64 mb of memory? My old radeon 9000, which isn't supported by fglrx > since years now has 64 MB. Does this hold true for radeon 8500 cards too? > > I think I'll use the guessed amount of vidmem in this case instead of > hardcoding 64 MB. > > Using the undocumented value and the check for older drivers which don't > support it is a bit hacky, but its a well-isolated hack and avoids a lot of > problems, so it should be ok. > > > My Radeon 9200 has 128 MB. But I've never used fglrx on it either, so I don't know what this gains.
Re: about video memory detection in wine
2009/8/14 Stefan Dösinger : > Using the undocumented value and the check for older drivers which don't > support it is a bit hacky, but its a well-isolated hack and avoids a lot of > problems, so it should be ok. > I'm only seeing half of the discussion here (the other half is probably still in moderation...), but that doesn't sound like a good idea. Is there any reason the extension can't be fixed to include this, or alternatively a second extension created?
Re: about video memory detection in wine
Am Friday 14 August 2009 18:01:07 schrieb Sun, Sunny: > + if(gl_info->vidmem < 64 * 1024 * 1024) > + gl_info->vidmem = 64 * 1024 * 1024; I guess the idea is that no ATI card that was ever supported on fglrx has less than 64 mb of memory? My old radeon 9000, which isn't supported by fglrx since years now has 64 MB. Does this hold true for radeon 8500 cards too? I think I'll use the guessed amount of vidmem in this case instead of hardcoding 64 MB. Using the undocumented value and the check for older drivers which don't support it is a bit hacky, but its a well-isolated hack and avoids a lot of problems, so it should be ok.
Re: shell32: fix program search in ShellExecuteEx, quote program name if it contains spaces (resend)
Hi again Stefan, I just took a little closer look, and you have more whitespace issues in the patch: - LPCWSTR p = space + 1; + LPCWSTR p = wszApplicationName + idx + 1; Why two spaces after the =? +strcatW(wcmd, wQuote); +} else strcpyW(wcmd, wszApplicationName); + You should indent the strcpyW, even though it makes the patch a bit longer. Finally, this isn't about whitespace but style: +if((needs_quote = NULL != strstrW(wszApplicationName,wSpace))) +len +=2; The expression in the if is unnecessary complicated. You could use consistent spacing here too. --Juan
Re: shell32: fix program search in ShellExecuteEx, quote program name if it contains spaces (resend)
Hi Stefan, I know this is nitpicking, but: - memcpy(buffer, sei_tmp.lpFile, idx * sizeof(WCHAR)); +lstrcpynW(buffer, wszApplicationName, sizeof(buffer)/sizeof(WCHAR)); + while((space=strchrW(buffer, ' '))) You're mixing tabs and spaces here. --Juan
Re: gdiplus: Implement GdipIsVisiblePoint
Nikolay Sivov wrote: Andrew Eikum wrote: --- dlls/gdiplus/graphics.c | 19 - dlls/gdiplus/tests/graphics.c | 162 + 2 files changed, 177 insertions(+), 4 deletions(-) Could you do it in opposite direction - implement "I" version on top of GdipIsVisiblePoint? This is how the rest of similar cases already works. Of course. Just simplified the code to do it the other way around. Though I guess that might be confusing looking at a stack trace. Thanks Andrew
Re: CPPcheck weekly run off thursdays GIT tree
Am Friday 14 August 2009 15:44:42 schrieb Henri Verbeet: > 2009/8/14 chris ahrendt : > > [../wine-git/dlls/wined3d/arb_program_shader.c:820]: (all) Buffer overrun > > [../wine-git/dlls/wined3d/arb_program_shader.c:821]: (all) Buffer overrun > > [../wine-git/dlls/wined3d/arb_program_shader.c:966]: (all) Buffer overrun > > [../wine-git/dlls/wined3d/arb_program_shader.c:977]: (all) Buffer overrun > > [../wine-git/dlls/wined3d/arb_program_shader.c:988]: (all) Buffer overrun > > Stefan, those look real enough that I think you'll want to fix them. Indeed - the texm3x3* functions pass in an 8 byte long char[], since they only expect a Tx register back, which just has a 2 bytes string. Its probably a safe assumption in the current code, but it doesn't smell right. I'll send a patch that increases the size of the register name to the standard 50 chars. Adding a define for the register name length is probably in order as well.
Re: [transl 7/8] Add pedantic possibilities to the resource page
On 2009.08.14 17:28, Paul Vriens wrote: > Hi, > > Again, passing pedantic in the URL gets a different behavior. In > pedantic mode there will always be a direct comparison with English(US) > when there are warnings. > > Changelog > Add pedantic possibilities to the resource page > You forgot the patch
Re: CPPcheck weekly run off thursdays GIT tree
2009/8/14 chris ahrendt : > [../wine-git/dlls/wined3d/arb_program_shader.c:820]: (all) Buffer overrun > [../wine-git/dlls/wined3d/arb_program_shader.c:821]: (all) Buffer overrun > [../wine-git/dlls/wined3d/arb_program_shader.c:966]: (all) Buffer overrun > [../wine-git/dlls/wined3d/arb_program_shader.c:977]: (all) Buffer overrun > [../wine-git/dlls/wined3d/arb_program_shader.c:988]: (all) Buffer overrun > Stefan, those look real enough that I think you'll want to fix them.
CPPcheck weekly run off thursdays GIT tree
[../wine-git/dlls/msvcrt/tests/file.c:997]: (error) Resource leak: stream1 [../wine-git/dlls/msvcrt/tests/file.c:982]: (error) Deallocating a deallocated pointer: stream2 [../wine-git/dlls/msvcrt/tests/file.c:966]: (error) Resource leak: stream3 [../wine-git/dlls/msvcrt/tests/file.c:973]: (error) Resource leak: stream4 [../wine-git/dlls/msvcrt/tests/heap.c:424]: (error) Deallocating a deallocated pointer: mem [../wine-git/dlls/ntdll/server.c:802]: (error) Resource leak: fd [../wine-git/dlls/rpcrt4/tests/server.c:1189]: (all) Array index out of bounds [../wine-git/dlls/wined3d/arb_program_shader.c:820]: (all) Buffer overrun [../wine-git/dlls/wined3d/arb_program_shader.c:821]: (all) Buffer overrun [../wine-git/dlls/wined3d/arb_program_shader.c:966]: (all) Buffer overrun [../wine-git/dlls/wined3d/arb_program_shader.c:977]: (all) Buffer overrun [../wine-git/dlls/wined3d/arb_program_shader.c:988]: (all) Buffer overrun [../wine-git/server/handle.c:201]: (error) Memory leak: new_entries [../wine-git/tools/fnt2bdf.c:656]: (error) Resource leak: fd [../wine-git/tools/fnt2fon.c:303]: (error) Memory leak: file_lens [../wine-git/tools/makedep.c:953]: (error) Resource leak: file [../wine-git/tools/widl/write_msft.c:2540]: (error) Deallocating a deallocated pointer: fd [../wine-git/tools/winedump/pe.c:1549]: (all) Memory leak: map Chris
Re: dbghelp: Fixed arena allocation in pool_alloc.
> dbghelp: Fixed arena allocation in pool_alloc. Well, 'fixed' might be a wrong word, but this patch makes it more intuitive. Jacek
Re: [11/18] windowscodecs: add test for pixel format conversion
Vincent Povirk writes: > On Fri, Aug 14, 2009 at 4:55 AM, Alexandre Julliard > wrote: >> Much better this way, thanks. You should probably rename the test file >> to converter.c or something like that though. > > That will be a problem when I want to use the test IWICBitmapSource > with an encoder. Or should I just duplicate the code in another C > file? You can put it all in one file if you prefer. Still, testsrc.c isn't a good name, you are not testing the testsrc bitmap, you are using it to test other features. The file name should be based on what features you are testing. -- Alexandre Julliard julli...@winehq.org
Re: [11/18] windowscodecs: add test for pixel format conversion
On Fri, Aug 14, 2009 at 4:55 AM, Alexandre Julliard wrote: > Much better this way, thanks. You should probably rename the test file > to converter.c or something like that though. That will be a problem when I want to use the test IWICBitmapSource with an encoder. Or should I just duplicate the code in another C file? -- Vincent Povirk
Re: mp3 update
On Fri, Aug 14, 2009 at 12:52:48PM +0200, Michael Stefaniuc wrote: > Alexandre Julliard wrote: > > Marcus Meissner writes: > > > >> On Thu, Aug 13, 2009 at 09:07:29PM +0200, Alexandre Julliard wrote: > >>> Austin English writes: > >>> > On Thu, Aug 13, 2009 at 1:41 PM, Juan Lang wrote: > >> All the more reason to use the existing libmpg123 instead of trying to > >> maintain our own version, IMO. > > Aric already explained that we can't: it doesn't exist on the Mac. > Not to nitpick, but if that's the reason for bundling libmpg, there > are several other libraries we should bundle... > >>> It's not the reason, as you point out the Mac is lacking a lot of > >>> things. I believe the reason we copied it was that it wasn't widely > >>> available on Linux either, because of licensing issues. If it's now > >>> included in the major distros then we should certainly consider dynamic > >>> loading. > >> At least on SUSE I have to patch it out due to license issues, so my builds > >> do not have mp3 support. > > > > What issues? The mp3 patents? That's a different problem than the > Yes. Fedora has the same problem. > > > original licensing issues, though of course it is also a good argument > > for making it a dynamic dependency. > Right; saves the vendors the effort to patch it back out of Wine. Just for the record, I have no problem with patching it out, its just 1 commit in my local wine git tree ;) Ciao, Marcus
Re: about video memory detection in wine
Could you please subscribe to wine-devel (http://www.winehq.org/mailman/listinfo/wine-devel) so your mail doesn't have to go through moderation? It's possible to disable mail delivery if you don't want to receive all the mail.
Re: about video memory detection in wine
Hi,
Can you give the attached patches a try? Do they detect the correct amount of
video memory?
Thanks,
Stefan
Am Friday 14 August 2009 11:58:12 schrieb Sun, Sunny:
> Hi
>
> I think it is difficult to maintain a large list of all ASICs, for you have
> to change the list from time to time when a new ASIC is released. Actually
> we have provided the functionality for getting total video memory, you can
> use the following code to get the total video memory with ATI cards.
>
> #define GL_TOTAL_PHYSICAL_MEMORY_ATI0x87FE
>
> const char *glExtensions = (const char*)glGetString(GL_EXTENSIONS);
>
> if(strstr(glExtensions, "GL_ATI_meminfo"))
>
> {
>
> int total_mem[4] = {0};
>
> glGetIntegerv(GL_TOTAL_PHYSICAL_MEMORY_ATI, total_mem); //
> total_mem[0] contains the total video memory size and the value is in Kbyte
>
> vidmem = total_mem[0] / 1024; //converting from Kbyte to Mbyte
>
> }
>
>
>
> Regards
>
> Sunny
>
> -Original Message-
> From: Roderick Colenbrander [mailto:thunderbir...@gmail.com]
> Sent: Friday, August 14, 2009 1:44 AM
> To: Stefan Dösinger
> Cc: wine-devel@winehq.org; Hu, Li; Jin, Jian-Rong; Wang, Robin; Guan,
> Xiao-Feng; Sun, Sunny Subject: Re: about video memory detection in wine
>
> On Thu, Aug 13, 2009 at 6:59 PM, Stefan Dösinger
wrote:
> > Am Wednesday 12 August 2009 10:04:10 schrieb Sun, Sunny:
> >> I think you can first detect GL_ATI_meminfo in
> >>
> >> glGetString(GL_EXTENSIONS); if GL_ATI_meminfo exists, then you can use
> >>
> >> glGetIntegerv(GL_VBO_FREE_MEMORY_ATI, param) to get the current free
> >>
> >> video memory, you can see more info at:
> >
> > A minor problem with GL_ATI_meminfo is that it doesn't report the total
> > amount
> >
> > of video memory available. D3D8 and D3D9 only report the free amount as
> > well,
> >
> > but DirectDraw can return the total amount. There are some games that
> > first
> >
> > query the total amount using ddraw, then continue with d3d8 or 9.
> > Depending
> >
> > on what other apps are doing, reporting the currently free amount as
> > total
> >
> > might result in the app thinking that free vidmem > total vidmem, running
> >
> > into all sorts of troubles. (For example, another app frees a lot of
> > textures
> >
> > between the ddraw vidmem query and the d3d9 vidmem query)
>
> It is even worse. Even OpenGL apps like WoW use ddraw for querying the
>
> amount of video memory at startup!
>
> In case of Nvidia the amount of video memory and the pci ids are
>
> advertised using the NV-CONTROL extension. At some point I plan on
>
> adding code for that. Even when using such extension the current
>
> fallback is still needed. The list needs some updates.
>
> > The other issue is that if some other apps use lots of video memory(like
> >
> > Compiz, etc), then we can still run into the same out of memory issue if
> >
> > other apps consume too much video memory.
> >
> >
> >
> > We should probably also fall back to a saner default on newer d3d10 class
> >
> > cards - a radeon 9500 isn't really representative for them any more.
>
> I still have to update that part but haven't had time for it yet.
>
>
>
> Roderick
From 0844cdc2be0fb4bf1769e97a05a6d6b4ac624ef2 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Stefan=20D=C3=B6singer?=
Date: Fri, 14 Aug 2009 13:09:26 +0200
Subject: [PATCH 4/4] WineD3D: Use GL_ATI_meminfo if available
---
dlls/wined3d/directx.c | 24 +---
1 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c
index 82e476c..723eb78 100644
--- a/dlls/wined3d/directx.c
+++ b/dlls/wined3d/directx.c
@@ -1957,11 +1957,29 @@ static BOOL IWineD3DImpl_FillGLCaps(struct wined3d_gl_info *gl_info)
}
TRACE_(d3d_caps)("FOUND (fake) card: 0x%x (vendor id), 0x%x (device id)\n", gl_info->gl_vendor, gl_info->gl_card);
-/* If we have an estimate use it, else default to 64MB; */
-if(vidmem)
-gl_info->vidmem = vidmem*1024*1024; /* convert from MBs to bytes */
+/* Use video memory info from GL if available */
+if(GL_SUPPORT(ATI_MEMINFO))
+{
+/* All GL_ATI_meminfo enums return 4 ints, even the (undocumented)
+ * GL_TOTAL_PHYSICAL_MEMORY_ATI one, which returns {mem, 0, 0, 0} */
+GLint mem[4];
+/* Returns the vidmem in KB */
+glGetIntegerv(GL_TOTAL_PHYSICAL_MEMORY_ATI, mem);
+TRACE("Video memory from OpenGL: %d MB\n", mem[0] / 1024);
+gl_info->vidmem = mem[0] * 1024; /* convert from KBs to bytes */
+}
+else if(vidmem)
+{
+/* If we have an estimate use it */
+gl_info->vidmem = vidmem * 1024 * 1024; /* convert from MBs to bytes */
+TRACE("Video memory estimate: %d MB\n", vidmem);
+}
else
+{
+/* Otherwise default to 64MB */
+TRACE("Default video memory: %d MB\n", WINE_DEFAULT_VIDMEM / (1024 * 1024));
gl_info->vidmem = WINE_DEFAULT_VIDMEM;
+}
/* Load all the lookup tables */
Re: mp3 update
Alexandre Julliard wrote: > Marcus Meissner writes: > >> On Thu, Aug 13, 2009 at 09:07:29PM +0200, Alexandre Julliard wrote: >>> Austin English writes: >>> On Thu, Aug 13, 2009 at 1:41 PM, Juan Lang wrote: >> All the more reason to use the existing libmpg123 instead of trying to >> maintain our own version, IMO. > Aric already explained that we can't: it doesn't exist on the Mac. Not to nitpick, but if that's the reason for bundling libmpg, there are several other libraries we should bundle... >>> It's not the reason, as you point out the Mac is lacking a lot of >>> things. I believe the reason we copied it was that it wasn't widely >>> available on Linux either, because of licensing issues. If it's now >>> included in the major distros then we should certainly consider dynamic >>> loading. >> At least on SUSE I have to patch it out due to license issues, so my builds >> do not have mp3 support. > > What issues? The mp3 patents? That's a different problem than the Yes. Fedora has the same problem. > original licensing issues, though of course it is also a good argument > for making it a dynamic dependency. Right; saves the vendors the effort to patch it back out of Wine. bye michael
Re: mp3 update
Marcus Meissner writes: > On Thu, Aug 13, 2009 at 09:07:29PM +0200, Alexandre Julliard wrote: >> Austin English writes: >> >> > On Thu, Aug 13, 2009 at 1:41 PM, Juan Lang wrote: >> >>> All the more reason to use the existing libmpg123 instead of trying to >> >>> maintain our own version, IMO. >> >> >> >> Aric already explained that we can't: it doesn't exist on the Mac. >> > >> > Not to nitpick, but if that's the reason for bundling libmpg, there >> > are several other libraries we should bundle... >> >> It's not the reason, as you point out the Mac is lacking a lot of >> things. I believe the reason we copied it was that it wasn't widely >> available on Linux either, because of licensing issues. If it's now >> included in the major distros then we should certainly consider dynamic >> loading. > > At least on SUSE I have to patch it out due to license issues, so my builds > do not have mp3 support. What issues? The mp3 patents? That's a different problem than the original licensing issues, though of course it is also a good argument for making it a dynamic dependency. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH 6/6] wined3d: Make RTL_READTEX the default rendertarget locking method.
Am Friday 14 August 2009 12:13:01 schrieb Henri Verbeet: > 2009/8/14 Stefan Dösinger : > > Am Friday 14 August 2009 09:23:25 schrieb Henri Verbeet: > >> For most cards this should make more sense than RTL_READDRAW, even if > >> e.g. surface_upload_data() has some room for improvement. > > > > I don't think this is a good idea until the READDRAW code has the ability > > to only upload a part of the surface if a limited rectangle was locked > > You probably mean RTL_READTEX, surface_upload_data() specifically, but > I did mention that in the commit message. I should not write emails directly after getting up... READTEX was what I meant. What I am also wondering about this patch: Its general wisdom that texture load + draw a quad is faster than glDrawPixels, although glDrawPixels is the more natural match to framebuffer locking. Why aren't drivers implementing glDrawPixels with texture+draw in that case? Or does glDrawPixels do anything we don't need that slows it down compared to the texture codepath?
Re: Alexandre Julliard : libwine: Ignore libraries that are of the wrong 32/ 64 class.
Ken Thomases writes: > Hi Alexandre, > > It seems this would fail to ignore a fat Mach-O library that doesn't > include the right 32/64 class. For example, a fat i386/ppc library > when running 64-bit. > > A fat library starts with the struct fat_header defined in /usr/ > include/mach-o/fat.h, followed by a number of struct fat_arch-es. Its > magic is 0xcafebabe in big-endian order. I doubt we are ever going to build Wine dlls as fat libraries. > This would also fail to ignore a PowerPC-only library because the > magic would be big-endian, but I doubt we care about that. That's deliberate. It's only supposed to ignore valid libraries that could be loaded if not for their wrong class. Libraries that can't be loaded at all should trigger an error. -- Alexandre Julliard julli...@winehq.org
Re: msxml3: Support loading windows file path under wine (resend)
Alistair Leslie-Hughes writes:
> +static int wineXmlMatchCallback (char const * filename)
> +{
> +static const WCHAR sColon[] = {':',0};
> +BSTR sFilename = bstr_from_xmlChar( (xmlChar*)filename);
> +int nRet = 0;
> +
> +TRACE("%s\n", debugstr_w(sFilename));
> +
> +/*
> + * We will deal with loading XML files from the file system
> + * We only care about files that linux cannot find.
> + *e.g. C:,D: etc
> + */
> +if(isalphaW(sFilename[0]) && sFilename[1] == sColon[0])
> +nRet = 1;
> +
> +SysFreeString(sFilename);
It doesn't make sense to convert the string to Unicode just to check for
a drive letter. Also the sColon string is clearly useless.
--
Alexandre Julliard
julli...@winehq.org
Re: Alexandre Julliard : libwine: Ignore libraries that are of the wrong 32/ 64 class.
Hi Alexandre,
It seems this would fail to ignore a fat Mach-O library that doesn't
include the right 32/64 class. For example, a fat i386/ppc library
when running 64-bit.
A fat library starts with the struct fat_header defined in /usr/
include/mach-o/fat.h, followed by a number of struct fat_arch-es. Its
magic is 0xcafebabe in big-endian order.
This would also fail to ignore a PowerPC-only library because the
magic would be big-endian, but I doubt we care about that.
-Ken
On Aug 11, 2009, at 10:47 AM, Alexandre Julliard wrote:
Module: wine
Branch: master
Commit: 99538272d5b4ffc852f950dd3447a7072d6316ff
URL:
http://source.winehq.org/git/wine.git/?a=commit;h=99538272d5b4ffc852f950dd3447a7072d6316ff
Author: Alexandre Julliard
Date: Tue Aug 11 17:29:07 2009 +0200
libwine: Ignore libraries that are of the wrong 32/64 class.
---
libs/wine/loader.c | 46 +++
+--
1 files changed, 44 insertions(+), 2 deletions(-)
diff --git a/libs/wine/loader.c b/libs/wine/loader.c
index d10a6e0..37c603e 100644
--- a/libs/wine/loader.c
+++ b/libs/wine/loader.c
@@ -147,12 +147,54 @@ static void build_dll_path(void)
}
}
+/* check if the library is the correct architecture */
+/* only returns false for a valid library of the wrong arch */
+static int check_library_arch( int fd )
+{
+#ifdef __APPLE__
+struct /* Mach-O header */
+{
+unsigned int magic;
+unsigned int cputype;
+} header;
+
+if (read( fd, &header, sizeof(header) ) != sizeof(header))
return 1;
+if (header.magic != 0xfeedface) return 1;
+if (sizeof(void *) == sizeof(int)) return !(header.cputype >>
24);
+else return (header.cputype >> 24) == 1; /* CPU_ARCH_ABI64 */
+#else
+struct /* ELF header */
+{
+unsigned char magic[4];
+unsigned char class;
+unsigned char data;
+unsigned char version;
+} header;
+
+if (read( fd, &header, sizeof(header) ) != sizeof(header))
return 1;
+if (memcmp( header.magic, "\177ELF", 4 )) return 1;
+if (header.version != 1 /* EV_CURRENT */) return 1;
+#ifdef WORDS_BIGENDIAN
+if (header.data != 2 /* ELFDATA2MSB */) return 1;
+#else
+if (header.data != 1 /* ELFDATA2LSB */) return 1;
+#endif
+if (sizeof(void *) == sizeof(int)) return header.class == 1; /*
ELFCLASS32 */
+else return header.class == 2; /* ELFCLASS64 */
+#endif
+}
+
/* check if a given file can be opened */
static inline int file_exists( const char *name )
{
+int ret = 0;
int fd = open( name, O_RDONLY );
-if (fd != -1) close( fd );
-return (fd != -1);
+if (fd != -1)
+{
+ret = check_library_arch( fd );
+close( fd );
+}
+return ret;
}
static inline char *prepend( char *buffer, const char *str, size_t
len )
Re: [PATCH 6/6] wined3d: Make RTL_READTEX the default rendertarget locking method.
2009/8/14 Stefan Dösinger : > Am Friday 14 August 2009 09:23:25 schrieb Henri Verbeet: >> For most cards this should make more sense than RTL_READDRAW, even if e.g. >> surface_upload_data() has some room for improvement. > I don't think this is a good idea until the READDRAW code has the ability to > only upload a part of the surface if a limited rectangle was locked > You probably mean RTL_READTEX, surface_upload_data() specifically, but I did mention that in the commit message.
Re: about video memory detection in wine
Am Friday 14 August 2009 11:58:12 schrieb Sun, Sunny: > #define GL_TOTAL_PHYSICAL_MEMORY_ATI0x87FE > const char *glExtensions = (const char*)glGetString(GL_EXTENSIONS); > if(strstr(glExtensions, "GL_ATI_meminfo")) That sounds very helpful! Is this supported on all drivers that support GL_ATI_meminfo(but not documented in the spec)? Or was this added at some later point? Do I have to be prepared to getting a GL_INVALID_ENUM or something when I am trying to use GL_TOTAL_PHYSICAL_MEMORY_ATI?
Re: [11/18] windowscodecs: add test for pixel format conversion
"Vincent Povirk" writes:
> +START_TEST(testsrc)
> +{
> +CoInitializeEx(NULL, COINIT_APARTMENTTHREADED);
> +
> +test_conversion(&testdata_32bppBGRA, &testdata_32bppBGR, "BGRA -> BGR",
> 0);
> +test_conversion(&testdata_32bppBGR, &testdata_32bppBGRA, "BGR -> BGRA",
> 0);
> +test_conversion(&testdata_32bppBGRA, &testdata_32bppBGRA, "BGRA ->
> BGRA", 0);
> +test_invalid_conversion();
> +test_default_converter();
> +
> +CoUninitialize();
> +}
Much better this way, thanks. You should probably rename the test file
to converter.c or something like that though.
--
Alexandre Julliard
julli...@winehq.org
Re: [PATCH 6/6] wined3d: Make RTL_READTEX the default rendertarget locking method.
Am Friday 14 August 2009 09:23:25 schrieb Henri Verbeet:
> For most cards this should make more sense than RTL_READDRAW, even if e.g.
> surface_upload_data() has some room for improvement.
I don't think this is a good idea until the READDRAW code has the ability to
only upload a part of the surface if a limited rectangle was locked
> ---
> dlls/wined3d/surface.c |1 -
> dlls/wined3d/wined3d_main.c|2 +-
> dlls/wined3d/wined3d_private.h |1 -
> 3 files changed, 1 insertions(+), 3 deletions(-)
>
> diff --git a/dlls/wined3d/surface.c b/dlls/wined3d/surface.c
> index 29ad00d..781a6b2 100644
> --- a/dlls/wined3d/surface.c
> +++ b/dlls/wined3d/surface.c
> @@ -1518,7 +1518,6 @@ static HRESULT WINAPI
> IWineD3DSurfaceImpl_UnlockRect(IWineD3DSurface *iface) {
> IWineD3DSurface_LoadLocation(iface, SFLAG_INTEXTURE, NULL /* partial
> texture loading not supported yet */); /* drop through */
>
> -case RTL_AUTO:
> case RTL_READDRAW:
> IWineD3DSurface_LoadLocation(iface, SFLAG_INDRAWABLE,
> fullsurface ? NULL : &This->dirtyRect); break;
> diff --git a/dlls/wined3d/wined3d_main.c b/dlls/wined3d/wined3d_main.c
> index 881f90e..4feb509 100644
> --- a/dlls/wined3d/wined3d_main.c
> +++ b/dlls/wined3d/wined3d_main.c
> @@ -41,7 +41,7 @@ wined3d_settings_t wined3d_settings =
> PS_HW, /* Hardware by default */
> TRUE, /* Use of GLSL enabled by default */
> ORM_FBO,/* Use FBOs to do offscreen rendering */
> -RTL_AUTO, /* Automatically determine best locking method */
> +RTL_READTEX,/* Default render target locking method */
> PCI_VENDOR_NONE,/* PCI Vendor ID */
> PCI_DEVICE_NONE,/* PCI Device ID */
> 0, /* The default of memory is set in FillGLCaps */
> diff --git a/dlls/wined3d/wined3d_private.h
> b/dlls/wined3d/wined3d_private.h index 8df99f6..5f88afd 100644
> --- a/dlls/wined3d/wined3d_private.h
> +++ b/dlls/wined3d/wined3d_private.h
> @@ -267,7 +267,6 @@ static inline float float_24_to_32(DWORD in)
> #define SHADER_NONE 4
>
> #define RTL_DISABLE -1
> -#define RTL_AUTO 0
> #define RTL_READDRAW 1
> #define RTL_READTEX2
Re: [2/4] ntdll: Add ProcessExecuteFlags handling to NtQueryInformationProcess
Michael Karcher writes: > This patch adds todo_wine statements to the test case, as this patch > enables the test case to run on wine. It would be cleaner to store the state in process.c rather than adding yet another internal function to retrieve it. -- Alexandre Julliard julli...@winehq.org
