Re: List of Video cards in directx.c

2010-07-10 Thread Scott Ritchie
On 07/10/2010 09:27 PM, Roderick Colenbrander wrote: > The issue is more complicated than that. We also need the PCI id and > that's one of the reasons why the code is at is right now. > GLX_NVX_memory_info / GL_ATI_memory_info only provide the amount of > video memory. In order to retrieve the pci

Re: List of Video cards in directx.c

2010-07-10 Thread Roderick Colenbrander
On Sat, Jul 10, 2010 at 6:30 PM, Seth Shelnutt wrote: > > > On Sat, Jul 10, 2010 at 3:57 PM, Henri Verbeet wrote: >> >> What kind of issue? (Just curious.) >> >  Well a 8300 isn't cuda capable, and even with the forcegpu nvidia_g80 flag, > wine still makes the client think it's an 8300 not an 850

Re: List of Video cards in directx.c

2010-07-10 Thread Ben Klein
On 11 July 2010 11:30, Seth Shelnutt wrote: > The gl_ati_meminfo extension has been around longer than > the Nvidia extension so it should have an even greater presence (since > catalyst 9.2). Anyone who has a 3xxx or newer from ATI or a 4xx from Nvidia > is guaranteed to have the extension for de

Re: List of Video cards in directx.c

2010-07-10 Thread Ben Klein
On 11 July 2010 11:30, Seth Shelnutt wrote: > Looking through the whole directx.c file I see what you mean. I'm not really > sure there is any better way to do it then what it already done. It seems > like it should be made more dynamic so everyone doesn't have to go hardcode > in all the differen

Re: List of Video cards in directx.c

2010-07-10 Thread Seth Shelnutt
On Sat, Jul 10, 2010 at 3:57 PM, Henri Verbeet wrote: > > What kind of issue? (Just curious.) > > Well a 8300 isn't cuda capable, and even with the forcegpu nvidia_g80 flag, wine still makes the client think it's an 8300 not an 8500. So then fah errors out with: Initializing Nvidia gpu library

Re: [RFC] gameux.dll partial implementation

2010-07-10 Thread Vincent Povirk
+if( CompareStringW(LOCALE_INVARIANT, 0, bstrElementName, nElementNameLen, sNodeExtendedProperties, lstrlenW(sNodeExtendedProperties)) == CSTR_EQUAL) I think you can get away with an lstrcmpW here. Yes, technically it can behave differently depending on locale, but you're doing a case-sens

Re: sorry one more question: assert statements in tests

2010-07-10 Thread Misha Koshelev
Just for thoroughness and clarity... I would like to put BOTH a skip that outputs that test was skipped and assert that then keeps any further damage being done. This is in the case of maxUlps. Any objections? Thanks Misha > > On Jul 10, 2010 12:11 PM, "Reece Dunn" wrote: > > On 10 July 2010 1

Re: sorry one more question: assert statements in tests

2010-07-10 Thread Misha Koshelev
Thank you for the explanation. maxUlps is in fact a constant. Although the asserts in my previous question re incremental patches were also only applicable due to programmer error. However, I think in that case a skip is much more appropriate if nothing else because it is immediately clear the pro

Inserting commits fyi... I think this might do the trick

2010-07-10 Thread Misha Koshelev
Thank you all for your comments. I still seem to be losing commits. However I have found a reference that seems like it might do the trick and wanted to share with others. Specifically, the key is to mark edit in interactive rebase on the commit one desires to split. Next one does a git reset HEA

Re: sorry one more question: assert statements in tests

2010-07-10 Thread Reece Dunn
On 10 July 2010 17:40, Misha Koshelev wrote: > On Sat, 2010-07-10 at 07:40 +0100, Reece Dunn wrote: >> On 10 July 2010 03:40, Misha Koshelev wrote: > Ok that makes sense. > > What about in the case of something like this: > > /* > http://www.cygnus-software.com/papers/comparingfloats/comparingflo

Re: sorry one more question: assert statements in tests

2010-07-10 Thread Misha Koshelev
On Sat, 2010-07-10 at 07:40 +0100, Reece Dunn wrote: > On 10 July 2010 03:40, Misha Koshelev wrote: > > I am implementing my tests as follows: > > > > * patch 1: general test for a D3DX function (D3DXCreateBox for example, > > testing specific vertices and indices for _specific_ dimensions). > > *

Re: List of Video cards in directx.c

2010-07-10 Thread Henri Verbeet
On 10 July 2010 16:22, Seth Shelnutt wrote: > I'm not sure if this is appropriate for a code freeze or not but I think it > is. We just ran into an issue with the folding gpu client in wine with > someone. Turns out it's because wine reports the card as a 8300 not an 8500. What kind of issue? (Jus

Re: git rebase to _insert_ commits?

2010-07-10 Thread Misha Koshelev
On Sat, 2010-07-10 at 05:33 +0200, David Hedberg wrote: > On Sat, Jul 10, 2010 at 2:54 AM, Misha Koshelev wrote: > > Dear All: > > > > I am still learning git and it seems that my solution does not quite > > work. > > > > Specifically, my idea was to use: > > git rebase -i upstream/master > > > >

List of Video cards in directx.c

2010-07-10 Thread Seth Shelnutt
I'm not sure if this is appropriate for a code freeze or not but I think it is. We just ran into an issue with the folding gpu client in wine with someone. Turns out it's because wine reports the card as a 8300 not an 8500. Looking at directx.c I see that that is probably because an 8500 is not lis

Re: [PATCH] Fix EndDialog behaviour for OrCad.

2010-07-10 Thread Eliot Blennerhassett
On 09/07/10 14:22, Dan Kegel wrote: > Thanks for sending that patch. > > It seems your editor stripped whitespace from the ends of lines, > causing three whitespace-only hunks on the end of your patch. > Please don't do that; Wine deveopers frown on unrelated whitespace changes. > > You might hav

Re: wined3d: Add GL_NV_point_sprite extension.

2010-07-10 Thread Henri Verbeet
2010/7/10 Rico Schüller : > +if ((!context->gl_info->supported[WINED3D_GL_VERSION_2_0] > +|| (!glPointParameteri && > context->gl_info->supported[WINED3D_GL_VERSION_2_0] > +&& !context->gl_info->supported[NV_POINT_SPRITE]) ) The second "context->gl_info->supported[WINED

Re: please don't shoot from the hip ;)

2010-07-10 Thread Alexandre Julliard
James McKenzie writes: > I'll be the first to bite on this: Please be friendly. I know that > I've been a little uptight the last few days, but it all over how we > code and what we code. Remember, folks are not going to figure out > what you were doing when trying to fix a bug six months from

Re: nightly kernel testbot up

2010-07-10 Thread Austin English
On Sat, Jul 10, 2010 at 2:25 AM, Austin English wrote: > Howdy, > > I wrote a quick script to test the latest wine and linux kernel, to > hopefully prevent more regressions like the WoW login bug. The test > machine is in a virtualbox vm, so of course graphics tests won't be > useful, but the rest

nightly kernel testbot up

2010-07-10 Thread Austin English
Howdy, I wrote a quick script to test the latest wine and linux kernel, to hopefully prevent more regressions like the WoW login bug. The test machine is in a virtualbox vm, so of course graphics tests won't be useful, but the rest should be... There are already a few results up (in the future, i