 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Orchid XP v7 wrote:
>> Darren New wrote:
>>
>>> Yep! And you wonder why video drivers under Windows crash the system
>>> so often.
>>
>> Uh... do they?
>
> Well, relatively often, yes, compared to most other stuff.
Not a phenominon I've ever experienced, but anyway...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Orchid XP v7 <voi### [at] dev null> wrote:
>> (Seriously, are you NUTS?! Most drivers are about 20 KB.)
>
> You can fit quite a lot of things into 20 kB. Just take a look at
> some good 4 kB demos.
I'll bet you can. Games programmers used to do it back when computers
only had that much RAM...
Although I'd think lower resolution polygon meshes for 27 different
games and benchmarks does not belong to "the set of all things that can
fit into 20 KB". ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v7 <voi### [at] devnull> wrote:
> Although I'd think lower resolution polygon meshes for 27 different
> games and benchmarks does not belong to "the set of all things that can
> fit into 20 KB". ;-)
It doesn't need to store the lower resolution meshes. It just needs to
store the logic to do reverse-subdivision of the meshes.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 31 Oct 2007 20:58:11 +0000, Orchid XP v7 wrote:
> Darren New wrote:
>> Orchid XP v7 wrote:
>>> Darren New wrote:
>>>
>>>> Yep! And you wonder why video drivers under Windows crash the system
>>>> so often.
>>>
>>> Uh... do they?
>>
>> Well, relatively often, yes, compared to most other stuff.
>
> Not a phenominon I've ever experienced, but anyway...
In one set of equipment we used to deliver courses on, we had Dell C610
laptops and Dell C640 laptops. Video cards were identical in the
systems, according to the specs (same chipset, same amount of memory,
same everything). For non-Windows OSes, they worked just great - you
could use an image developed on a 610 on a 640 and vice version.
For Windows, you had to install a *different* video driver, even though
the card was identical - even at the BIOS and firmware level (I checked
everything I could to find out what was different).
Yet consistently, if you used the 610's driver on the 640 (or vice-
versa), the video came up 16-colour 640x480 VGA, refused to change, and
left alone long enough, the driver would apparently eat itself and blow
the machine up - to the point a reimage was often needed.
One of the more bizzare problems I ever saw. A Dell IT technician in one
of my classes couldn't even tell me why the driver was different or why
it didn't do what it was supposed to do (ie, work).
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v7 nous apporta ses lumieres en ce 2007/10/30 16:41:
> Alain wrote:
>
>> They will probably install and run, but also, probably, with deliberately
>> cripled performances.
>> A dirty trick by those making the demos (independent from where they
>> come from):
>> Let install on the concurent maker's card, but disable some features
>> and replace
>> others with some DEoptimised versions that deliberately run slower.
>
> Yeah, that wouldn't surprise me.
>
>> To get the real results, you need to use demos and benchmarks by
>> independant
>> devlopers, and hope that your drivers don't have special codes that
>> lowers the
>> settings like resolution, polygon count and colour depth, to
>> artificialy make
>> the benchmark run faster. nVidia DID use that dirty trick, and there
>> is no proof
>> that ATI used it or not at this time.
>
> Um... lower the polygon count? That sounds like a *highly* nontrivial
> task. Arguably more work than actually rendering all the polygons. :-P
Not at all! The benchmark programm already have several quality levels,
including various mesh resolutions.
What you do, is to dynamicaly reset the relevant parameter of the benchmark to a
lower setting after the user have set it and hit the StartBenchmark button, but
before the benchmark have realy begun. Then, after the benchmark have finished,
you set it back to the user selected value.
The net result: artificialy inflated FPS count!
--
Alain
-------------------------------------------------
You know you've been raytracing too long when you have ever brought your
computer to its knees by mistakenly launching 64 simultaneous frames to be
traced, while trying to maximizing the benefits of parallelizing them.
Carsten Whimster
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v7 nous apporta ses lumieres en ce 2007/10/30 17:58:
> Warp wrote:
>> Orchid XP v7 <voi### [at] devnull> wrote:
>>> Um... lower the polygon count? That sounds like a *highly* nontrivial
>>> task. Arguably more work than actually rendering all the polygons. :-P
>>
>> Not if the driver has code specifically designed for the specific
>> triangle mesh the benchmark program send it. It can simply have some
>> kind of lookup table or something which substitutes some of the triangles
>> with other (fewer) triangles.
>
> ...hmm, so *that* is why the nVidia video driver is over 200 MB...
>
> (Seriously, are you NUTS?! Most drivers are about 20 KB.)
ONLY 20Kb??? I only once had video drivers under 500Kb! This was under Win 3.1
for an old PCI Trident VGA adaptor, the only and last drivers I ever got that
fit on a single floppy. The Win 95 drivers for that same card needed 2 floppys.
My current ATI drivers installation package is about 14.5 Mb.
Just take a look on both nVidia and ATI web sites, drivers downloads section.
--
Alain
-------------------------------------------------
As the shepherd said: If in doubt get the flock out!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v7 nous apporta ses lumieres en ce 2007/10/31 16:59:
> Warp wrote:
>> Orchid XP v7 <voi### [at] devnull> wrote:
>>> (Seriously, are you NUTS?! Most drivers are about 20 KB.)
>>
>> You can fit quite a lot of things into 20 kB. Just take a look at
>> some good 4 kB demos.
>
> I'll bet you can. Games programmers used to do it back when computers
> only had that much RAM...
>
> Although I'd think lower resolution polygon meshes for 27 different
> games and benchmarks does not belong to "the set of all things that can
> fit into 20 KB". ;-)
WHO said that you need to store the alternate meshes? You don't need to do that
when the benchmark already contain the lower resolution meshes.
Benchmarks, and several games, often offer several mesh quality. You only need
to intercept or change the reference that is used to point to the lower
resolution mesh that is already provided.
One of the ways that the cheats where discovered was by running the benchmarks
at the two lowest settings available and realise that they return exactly the
SAME results: The second lowest get degraded to the lowest setting, but the
lowest settings CAN'T be lowered to anything lower! But, almost nobody ever try
those low settings.
--
Alain
-------------------------------------------------
You know you've been raytracing too long when someone shows you a photograph of
their new rough-slate kitchen floor and you say "nice normals".
-- Tom Melly
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain wrote:
> WHO said that you need to store the alternate meshes?
That would be Warp. ;-)
> You don't need to
> do that when the benchmark already contain the lower resolution meshes.
> Benchmarks, and several games, often offer several mesh quality. You
> only need to intercept or change the reference that is used to point to
> the lower resolution mesh that is already provided.
Mmm. Devious...
> One of the ways that the cheats where discovered was by running the
> benchmarks at the two lowest settings available and realise that they
> return exactly the SAME results: The second lowest get degraded to the
> lowest setting, but the lowest settings CAN'T be lowered to anything
> lower! But, almost nobody ever try those low settings.
...or it could simply indicate that the bottleneck isn't the GPU?
(I've seen a huge number of SLI benchmarks where the SLI mode is
*slower* than a single GPU, except at absurd resolution settings.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Orchid XP v7 <voi### [at] devnull> wrote:
>> Although I'd think lower resolution polygon meshes for 27 different
>> games and benchmarks does not belong to "the set of all things that can
>> fit into 20 KB". ;-)
>
> It doesn't need to store the lower resolution meshes. It just needs to
> store the logic to do reverse-subdivision of the meshes.
...and as *I* said originally, "wouldn't that be drastically more work
than just rendering the high resolution mesh?"
Mesh subdivision being an extremely hard problem, and all that...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v7 <voi### [at] devnull> wrote:
> Alain wrote:
> > WHO said that you need to store the alternate meshes?
> That would be Warp. ;-)
No, I only mentioned lookup tables as being a solution to reducing the
size of known meshes fast.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
