On 10 July 2010 03:40, Misha Koshelev misha...@gmail.com 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).
* patch 2: separate into function that works with
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,
On Sat, Jul 10, 2010 at 2:25 AM, Austin English austinengl...@gmail.com 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
James McKenzie jjmckenzi...@earthlink.net 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
2010/7/10 Rico Schüller kgbric...@web.de:
+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
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 have
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
On Sat, 2010-07-10 at 05:33 +0200, David Hedberg wrote:
On Sat, Jul 10, 2010 at 2:54 AM, Misha Koshelev misha...@gmail.com 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
On 10 July 2010 16:22, Seth Shelnutt shelnu...@gmail.com 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
On Sat, 2010-07-10 at 07:40 +0100, Reece Dunn wrote:
On 10 July 2010 03:40, Misha Koshelev misha...@gmail.com 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_
On 10 July 2010 17:40, Misha Koshelev misha...@gmail.com wrote:
On Sat, 2010-07-10 at 07:40 +0100, Reece Dunn wrote:
On 10 July 2010 03:40, Misha Koshelev misha...@gmail.com wrote:
Ok that makes sense.
What about in the case of something like this:
/*
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
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
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 mscl...@googlemail.com wrote:
+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
On Sat, Jul 10, 2010 at 3:57 PM, Henri Verbeet hverb...@gmail.com 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
On 11 July 2010 11:30, Seth Shelnutt shelnu...@gmail.com 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
On 11 July 2010 11:30, Seth Shelnutt shelnu...@gmail.com 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
On Sat, Jul 10, 2010 at 6:30 PM, Seth Shelnutt shelnu...@gmail.com wrote:
On Sat, Jul 10, 2010 at 3:57 PM, Henri Verbeet hverb...@gmail.com 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
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 id
20 matches
Mail list logo
