Q: What is ASGRA for?

A: while aquamark3 is running you always can capture a screen by pressing the
'print' key, the uncompressed tga will be put into your 'my
documents\aquamark3\' directory. however with ASGRA you get much more! the ASGRA
technique creates screenshots at identical frame counter positions. with this
you easily can compare screenshots under different settings or even different
graphic cards!

---


Q: So what about OVIST?

A: the cool thing with ovist obviously is that you actually see(!) the overdraw
of each scene. this gives you a lot of transparency about how aquamark3 is
pushing your hardware in terms of overdraw and fillrate. the tricky thing is to
visualise exactly the same ps which are used while the normal benchmark mode is
running. we found a way to do this with our ovist technique.

---

Q: What is PIXM ungodly slow?

A: with pixpm you are able to benchmark the real world fillrate of a graphics
card precisely for the 1st time ever! it is a very complex task to give a
precise fillrate score under real world conditions. you have to take the
overdraw into account. so in the 1st run we count the sum of all(!) drawn pixels
inclusive the overdrawn ones. this may take 45minutes on a current state of the
art system. in the second run we do a realtime run with the same engine setup.
now we are able to calculate the real world fillrate. like svist the pixpm
technique is very smart and gives you as a user much more transparency about the
benchmark and your system then ever before.

---

Q: why are not all shaders of am3 dx9 shaders?

A:as we pointed out in our documentation the important value is NOT the number
of shaders written in a certain language, but the number of pixel actually
RENDERED by a shader! that is btw one of the reasons we implemented SVIST into
am3!

the documentation goes deep into the details of this fact and the resulting
conclusions. please have a look at the 'special features' section in the am
manual. in am3 we utilize the new shader version for complex shading tasks which
benefit from the additional features and could NOT be implemented in previous
shader versions.

note that it is no problem for us to declare EVERY shader to be a 2.0 shader.
from our argmentation, it makes no sense to implement simple shading tasks like
particle rendering in ps2.0. so you have to adjust your decision which shader
version to use to the problem you have to solve. however am3 approximately
generates 30% of it's screen pixels (without overdraw) through ps2.0.

if you contemplate that am3 claims to be a reality benchmark we have to reflect
the actual situation out there - this situation is characterized by a mixture of
different api and shader versions for the vast majority of games.

---

Q: Why is AquaMark3 more balanced than HalfLife2?

A: we don't want to comment on other developers or their applications. we are
sure that valve has good reasons for what they are doing and why they are doing
it this way.

---

Q: Did Valve do something wrong or is it too hard to tell?

A: you have to ask them not us.

---

Q: Do you think that there will be games out there that are crap on a specifc vendors hardware?

A: no. as a game developer you have to create revenues by selling your product
to as much customers as possible. so it makes no sense for you to create a
technology which gives a substantial amount of customers a bad experience. you
may decide to implement special features for an oem version of your game. this
makes perfect sense but is not an option for a benchmark. if you do not depend
on the retail or any oem business and you are able to recoup your development
costs from other sources you might be more flexible.

---

Q: Had any hardware vendor influence with the development of AM3?

A: as a developer of high end 3d engines and games we traditonally (have to) work
close together with all major cpu/gpu vendors since years. they tell us about
their current and coming hardware so that we can decide early enough where we
will go technically from our side we provide them with valuable input.
often their driver and hardware teams really get a harsh 'reality check' when we
tell them how games do look from inside.

but we do not favour a specifc vendor simply because this could hurt the sales
of our products because we might exclude customers. so we have to be solomonic
when we design engines and technology. not because we are keen on being
solomonic but we do want to give a good experience to all of our customers.

this is basically the same with all game developers. however, for a game you
might decide to do a special version for oem which support a specifc hardware
feature but this is not an option for a benchmark (and traditionally not for the
retail version). as a game developer you have to implement your algorithms in a
way that all customers do get an optimum gaming experience and the most out of
their hardware. but because gfx cards do change fast it in general makes no
sense to implement a specific algorithm especially for a specifc hardware
generation. you have to find a general and efficient way.

---

Q: Why is driver X faster than driver Y?

A: driver and hardware are closely tied together and we think that any driver
improvements which give an overall speed increase to the customer are good (no
matter which vendor we are talking about). you have to remember, that we as
developers use an api (dx9) which is generic and ideally solomonic. so we can
not code to the metal and get the best out of a specific hardware. so the
hardware vendor has the task to map the api optimally to the hardware. this may
turn out to be a laboursome and painful task as you are aiming at a moving
target (i.e. constantly chaning game engines). so you should think of the driver
team as a constant service you as a customer get after you bought your hardware.

the development of a driver is a continous process. you have to notice that the
source code size of a driver easily exceeds the source code size of a modern
game! for this reason, there is always room for improvement.

in many cases the improvement is necessary for reasons which are often
underestimated. the problems for the drivers performance arise from changes in
the paradigm of game techniques which are on the other hand driven by the cpu
performance. a change in game rendering techniques may dramatically change the
driver demands. for instance contemplate the number of drawprimitive() calls
which can be executed per frame. in previous games the average number of calls
per frame was about 100-300. an unefficient implementation in the driver did not
contribute significantly to its overall efficiency. with increasing cpu power
and changing rendering paradigm (z first, multipass, materialdriven) the number
of drawprimitive() calls per frame has multiplied tenfold. suddenly this new
situation leads to a performance bottleneck in the driver which could could not
have been foreseen. in this case the drivers code improvement becomes essential
to get up-to-date. depending on the real situation this could easily lead to a
performance increase which seems to be astonishing and somehow nonserious.

another unexpected performance increase simply comes from driver cleanup and
refacturing. especially driver models which claim to support all generations of
hardware within a single concept may suffer from compatibility restrictions.
purifying the driver code from needless ballast may also lead to unepected
performance increases.

---

Q: What is SVIST for and why it is so slow?

A: the svist technology is very smart, we have to guarantee that we color the
pixels of a specific ps type WITHOUT rewriting or altering the original ps code.
that's why it is very complex and slow. but we have to be very accurate and
precise.

however svist is a key feature in terms of transparency for all users of am3. as
you might read in our white papers we are convinced that the amount of rendered
pixels of a specific ps type is more relevant to any game and especially a
benchmark then just claiming that there are ps2.0 in the benchmark.

there are benchmarks out there who i.e. implement trivial ps2.0 for particles
which is insane. particles are typically rendered without any ps at all. with
svist this is visualised for you. if you change the advanced settings you will
notice that the svist visuals will change which reflect that the engine uses
different code path for different situations.

besides we are able to tell you with svist the exact amount (absolute, relative
and in percentage) of pixels drawn through a specific ps (or even simple
texturestages like the particles).

we are convinced that svist is one of the coolest features of am3, however we
are wondering if people will get the point about it because you have to think
about it before you see it's beauty. we hope that there are enough smart guys
out there that will tell the others about it.

---

Q: The AutomatedTestingTechnology is cool, but I do want to fully customize my runs!

A: no problem you can do this. when you set the advanced options your settings
are written to a control textfile. by the command line options of the 'plus'
version you can create a batch file an feed as much benchmark settinhgs to am3
as you want. this option is be described in your documentation. we implemented
this especially for power-users.

---

Q: What about the excel sheet?

A: it is designed for visualisation of multiple measurements! Give it a try,
you can use it oout of the box or take it as a starting point for you customized
result visualisation.

---

Q: What is special about ARC?

A: ARC gives you more options and tools for comparison of your benchmark results
than any other online benchmark database tool. just have a look at the many ways
you can filter and set comparison options. it is the most powerful online
database for benchmarks currently available.