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
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
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
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
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
+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
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
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
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
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
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).
> > *
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
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
> >
> >
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
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
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
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
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
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
19 matches
Mail list logo