PC still playing Amiga catchup

[Hammer]

"On the contrary" to what?  Did you like misread or skip some posts?  Sound cards are NOT backward compatible.  I stated an example where some Sound Blaster cards are backward compatible at the hardware level and they can be accessed directly with more efficiency.  I was stating that if they were all like that, that is better.  API restricts your access to hardware for what the function performs and it's inefficient.

Refer to http://developer.nvidia.com/object/nvapi.html

"NVAPI is NVIDIA's core software development kit that allows direct access to NVIDIA GPUs and drivers on all windows platforms. NVAPI provides support for categories of operations that range beyond the scope of those found in familiar graphics APIs such as DirectX and OpenGL."

NVAPI = NVIDIA API. A vendor specfic APIs.

NVAPI was use to enable the current CUDA's Direct3D 10.1 supported features with FarCry2.



FarCry2 is an example of "The way its meant to be played" game.

LibCGM doesn't solve HDR FP + hardware AA problem with NVIDIA's RSX, nor it will solve pixel shader's stalls during texture operations.

>My god, I was upgrading in that era when they went from ISA to PCI for sound cards, half the time games wouldn't work properly.  Oh and lets not forget, soundblaster emulation on PCI sound cards is done in SOFTWARE, at least partially.  I believe its something to do with having to emulate the ISA chipset timings which is also why it did not work properly.

That's your speculation.  Some Soundblaster audio cards ISA and PCI versions of them are hardware compatible.  I can set use I/O locations 220h..22Fh and DMA/IRQs directly.  It's not being done in software as I explained before.

Refer to TSR Soundblaster emulation.

>The switch to Direct X brilliant as you very very rarely get this sort of problem anymore, it just works.  Kinda breaks your whole argument that backwards compatibility is easy.

No it doesn't break the argument, since you never understood the argument according to what you wrote.  APIs restricts your access to the hardware and is less efficient than directly writing to hardware registers if there is backward hardware compatibility.

There's nothing stopping you making a RING 0 program.

I said, "it's not as bad" meaning you can use it along with direct hardware access.  Since setting a mode is nonstandard, you can call it to set a graphics mode and then use direct I/O.  More later if needed.

For custom display modes, you either modify the INF(with NVIDIA's case) or

Part of NVIDIA's control panel (I use 185.70 beta)

or play with NVAPI.

[Hammer]

I said "it's not as bad" since you can still take over the hardware; mode switching is not used that often as say changing palettes, modifying a pixel,

Erm Pixel shader.

split-screening (to go back on topic for a moment), etc.  

3D surface.

and you wouldn't have to be playing guessing games as to what the API is doing.  Just set the VESA mode once and then use the I/O ports and directly write to VGA.  If you don't need low-level accesses then use the API.

On CUDA processors, you have CUDA (ver 2.2), PhysX CUDA,  NVAPI, D3D (upto ver 10), OpenGL(upto ver 3), soon OpenCL (ver 1.0, currently in beta).

My argument has been the same-- it's better to have both.

On the PC, you can have programs in  "kernel space" i.e. usefull for OS vendors, IHVs, hypervisor/virtual machine vendors, copyright protection/spyware/malware and virus writers.

[Hammer]

As I said, there's nothing wrong with having APIs for user mode and still having standardized hardware on I/O port/memory-map level so at least kernel mode software can be written to take advantage in best possible way.

>A boat anchor.

It doesn't have to be just the basic VGA-- entire SVGA/XGA/SXGA could have been standardized at hardware level; but it wasn't so you have to live with the method of accessing them through APIs.

>...To maximise performance, GPUs usually take a clean design approach i.e. applying the latest micro-architecture paradigm on a given transistor count.  

Because they are already assuming now that they only have to write for APIs.  Also, it's cheaper for them to start fresh.  But it's better to have both.  If some video card company had maintained hardware standards at I/O level throughout their history, it would be pretty popular and useful since it would work with all OSes (DOS, Windows 3.x, XP, Vista, Linux, etc.) and would allow for direct programming.  I know ATI even has like 10 different I/O port locations on various cards that do the same thing.

Did you forget ATI's AtomBIOS?

>1. Geforce 8600 GT/8700M GT/9500M GS/9600M/9650M GT has four of these processing elements i.e. 32 SPs with 32768 32bit registers.

>2. Geforce 9600 GSO has eight of these processing elements i.e. 96 SPs with 98304 registers i.e. these values are stored next to actual execution cores.

>Notice the register count differences between examples 1 and 2.

Yeah, but given they are only accessed via APIs, they could change the GPU and register sets.  However, if they had known that many applications are writing directly to the hardware, they would have to maintain APIs and be backward compatible from hardware perspective.  

You missed the lesson on X86 legacy tax when it comes to maximising the number of math units? The GPU takes the clean design approach nearly to the maximum.

>I was referring to variable of movement compared to on-off nature of a digital joystick. >Anyway, my mouse has an optical scanner i.e. it has a DPI resolution and it doesn't have a mouse ball. It has A-to-D conversion.

Most games on PCs use analog joysticks but they could just as well have been written with digital joysticks.  Yeah, a few games need the analogicity, but why should most of the games suffer because of it.

Most modern 3D games needs variable controls.

>I wasn't referring to marketing point of view i.e. refer to real world cars. Xbox 360's RS's replicates (player's POV)'s head movement changes.

I have played Pole Position on Atari 800 and Atari 5200 and it works great with digital joysticks and analog sticks although latter has centering issues/calibration issues.

I don't recall "centering issues/calibration issues" with Xbox 360 controlers. When driving a car (real world or virtual), the on-off nature of digital joysticks $ucks.

[Hammer]

Continuation of my reply from yesterday...


I am treating VESA also as an API but at the time VESA BIOS was introduced, most of the other ports were standard so you can use VESA to set the video mode and then use direct I/O or write to video memory after that.  And putting VESA into ROM is better since you don't have to load any drivers that hogged up valuable DOS memory (from 640K).  In fact, I can call some VESA BIOS functions even from Windows 98SE (if they don't rely on selectors).  Games did not run in some cases because NOT all video cards had VESA BIOS or supported the various modes the game was requesting.  Those required a software (non-ROM) VESA Bios

>The overhead can't be that bad either as games still improved when we jumped to Windows instead of DOS, despite the fact by your argument the extra power in the PC should have been stolen in API inefficiencies.

That's not my argument-- the extra power was lost by API inefficiencies.  In all cases, you have more power with direct access to hardware vs. API.  Same for Amiga, if you go through API, your games will not make efficient use of hardware as if you go directly to hardware registers.

Define this lost of computation power. Large API inefficiencies is debunked by Fold@Home GPU2 CUDA example.

[Hammer]

You are speculating it's "progress" to use only APIs.  It's FACTUALLY a big hit on creativity.  Now people have to rely on the same dull APIs and live with inefficient code

Game content providers are only interested in providing content. They are not interested in worrying about the plumbing work. What we have now is RAD i.e. rapid application development. With XNA, one could easily build Super-Stardust clone with 3D based effects.

 and not knowing exactly what is happening behind the API.

This does not reflect the professional gaming development.

  It produces vague, bloated, dull code.  Joystick gameport was an example where Amiga wins even at the hardware level.

Sorry, Nintendo Wii’s control method is currently the leader in casual gaming. In E3 2009, both Sony and Microsoft announced motion based controls. With Microsoft's motion based controls, the handheld control device doesn’t actually exist i.e. optical based recognition.

In other cases for real-time scenarios, Amiga hardware level compatibility makes it superior to API versions of the same program on PC.  Your 100Mhz or 2.6+GHz processor does not affect your I/O speed. (SNIP)

In terms effective bandwidth, my laptop's ExpressCard I/O port is magitude faster than the classic Amiga hardware.

[Hammer]

I wouldn't label it "naughty" or "cheat".  I used direct hardware VGA access or other direct hardware access in all my products (http://www.krishnasoft.com); I allowed for APi method as well in cases where it wasn't available (like Windows XP).  Even under Windows 98SE, you can directly access VGA card (for standard functions), keyboard ports, parallel ports, etc.  XP restricts you a bit more.
And the results are better when going direct to hardware.

A Natami supporter...That figures.

[Hammer]

Bullcrap.  Amiga is more efficient at certain real-time tasks than modern PCs.  And one reason being discussed presently is because it had hardware level compatibility rather than just API level compatibility.  The other reasons like having digital joysticks vs. analog joysticks, having ability to do cycle-exact timing, etc. were already mentioned.

Pure efficiency has limits in respect to brute performance+efficiency and overall design of the system.

If you notice with CUDA processors, the extremely large register set is superior to Natami’s SRAM memory and CELL's SPE local memory.

[Hammer]

AGA palette changes being more complex that it was is because they wanted to save on register space not because of backward compatibility.  Legacy hardware ports is what is currently making some tasks possible (especially real-time stuff) which would otherwise be impossible under modern systems.

Sorry, my laptop can play Blu-Ray 1080p movies in real time.

What target market are you targeting?

[Hammer]

If you boot DOS in REAL mode and directly access sound blaster registers, there are no TSRs running nor anything else and your IOPL=0 so nothing is trapping your using the ports.  If such an application works, you know it's hardware compatible with Soundblaster.

As an example, Gravis Ultrasound Max uses TSR Soundblaster emulation. GF1 chip is missing the AdLib-compatible OPL2 circuitry.

[Hammer]

Suppose you want to use mode 640*480*16 paletted mode and read palette register #3 and swap with palette register #15.  I can do that with a few IN/OUTs using standard VGA registers or doing MOVE.Ws to $DFF186/$DFF19E on Amiga or a few LDA/STA on 8-bit computers.  Let's see your API calls to do that.

Why 2D when you can have 3D+shaders on XNA framework?

Refer to development issues between PS3 vs Xbox 360.

 Since you seem to be pretty up to date with all the latest video cards and hype of APIs and video cards are frequently updated and are using best possible technology-- let's see how efficient their APIs are.

How efficient would it be on time and money to recoding the same software on different platforms?  Setting up screen resolution is not a large issue in professional gaming creation.

On Amiga, if CBM didn't go bust, would "hitting-the-metal" work on "clean break" Hombre based Amiga?

Amiga Hombre based PC (includes HP PA-7150 RISC microprocessor) runs legacy 68k AmigaOS software through emulation.

[Hammer]

Amiga seems tons of games that go directly to hardware and still have a multitasking OS. It's wonderful that some systems allow you to take over the hardware and use all of it for your application-- you really get to use what you paid for and it works in general not just for your Amiga.

What happens to Deluxe Music if Protracker "hitting the metal" Paula’s audio hardware? Who will arbitrate the hardware access?

[Hammer]

But if the hardware compatibility is required for newer hardware, then metal won't change registers or affect previous software.

Tell that to 68K vs ColdFire.

>2) Any loss of processor cycles involved in going down the API route is more than made up for in the fact that systems employing API access to devices tend to be running on CPU's orders of magnitude faster than the 68K.

>Cycle for cycle, direct hardware access wins, but when your API is running on a machine that can execute billions of instructions per second, worrying about a function call that might execute a few dozen instructions to get the job done is quite simply nothing short of laughable.

Thanks-- some people can't even accept that direct hardware access wins everytime.  The point about processors being much faster is fine, but I/O instructions haven't sped up like processors have.

On GPUs and at a given transistor budget, maximising math unit count takes precedence i.e. maximising compute wavefront. The host CPU can handle driver JIT re-complier workload.

[Hammer]

I was making the point that certain applications go directly to hardware yet don't effect the multitasking OS.  They return and OS is still stable as it was.  Even the examples of audio playback in Compute! magazines are directly writing to hardware registers rather than making APi calls.

They'll break if the application misbehaves i.e. results in guru-mediation.

[Hammer]

You just expressed your emotional fanaticism of PCs without even addressing the point.  It's better for PCs to have both APIs and hardware level compatibility than just API access.  You have less options with just API access.  Now given you just have APi access vs. an Amiga which has both, for certain real-time applications, Amiga does better.

On the PC, there’s nothing stoping you using kernel space.

[Hammer]

You lost track of the point.  There are SB cards that are backward compatible on hardware level.  I proved it by running in REAL DOS mode.

DOS TSRs and device drivers(e.g. CD-ROM) also run in real mode. Anyway, my SoundBlaster X-Fi USB2.0 is not SB16 backward compatible in REAL DOS mode.

[Hammer]

Sorry you missed the point of how VGA is backward compatible on hardware level with EGA/CGA.

>You cannot say that given that you made no effort to test that the data you were recieving wasn't infact signal noise, indeed your "proof" was and is as it stands utter garbage. You were given a solution that would test it one way or the other. I have yet to see you put your hypothesis to an actual test yet. Simply repeating "it's better" over and over does not make it so.

You missed that point as well then.  I gave you LOGICAL statements how you can have millisecond readings which you NEVER replied to.  Just declaring it "garbage" does not change reality.  You are as biased as they come.  It's faster EVEN IF YOU DON'T SAMPLE AT 1KHZ.

>There is always likely to be bugs in software, but that is not the same as a flaw in an API and you should damn well know that! Also, DirectX now supports a great many things that it didn't in the past, the reason for version changes was to allow for the addition of newer capabilities, bug fixes have nothing to do with the DX version number.

I said it's not my argument but I know there are bugs in implementation of the API where certain video cards don't work the same for the same function.

That’s an implementation issue. The product should be following the reference renderer.

>Correct. But also wrong. You are also limited by your own abilities. Doing things your way means extra work and hassle for everyone else.

Yes, you are limited by your abilities, but you are more restricted with just an API rather than both API and hardware level compatibilities.

You made the same mistake as PS3 fanboys. OpenGL can be expanded via vendor specific extensions. You are welcome to implement your own OpenGL driver.
Make sure you target AmigaOS 4.x.

Using Oblivion (PC edition) game’s example, ATI’s chuck patch enables HDR FP+AA via driver level patch i.e. it overcomes Direct3D 9c's limitations.

"Hitting the metal" doesn't change NVIDIA RSX's hardware limitation e.g.
1. Limited vertex resource. NVIDIA G80 fixes this feature.
2. Lack of HDR FP render targets + hardware AA. NVIDIA G80 fixes this feature.
3. Lack of geometry shader instructions. NVIDIA G80 fixes this feature.
4. Lack of Early-Z hardware features. NVIDIA G80 fixes this feature.
5. Avoiding pixel shader stalls during texture fetch. NVIDIA G80 fixes this feature.
6. Limited shader branch support. NVIDIA G80 fixes this feature.
7. Lack of Giga-Thread hardware features. NVIDIA G80 fixes this feature.

NVIDIA's G7x and RSX hardware functionality basically follows Direct3D 9c limitations.