My parhelia to be replaced.

[Umfriend]

no.

[Wombat]

Ha, I was talking to Ribbit! :P


Oh, and Ribbit:

and signal quality on the same level as my G400 Max (okay, so a bit worse on the DVI output).

Huh? How do the DVI outputs differ?

[Greebe]

What makes you think that Matrox doesn't think I think that DGhost thinks we think alike, you think so!

[DGhost]

OW!

[Jon P. Inghram]

Originally posted by Ribbit
More info/links? I knew the hardware was basically the same, but I never found any info on running the Catalyst drivers on it.

This "make near-identical hardware and forcibly differentiate them with drivers" attitude is something that really bugs me about the Windows/closed-source world. (And something which Matrox should be commended for not doing too.)

You can find posts all over the Rage3D forums, I personally have loaded up the FireGL drivers on my 8500 before and they worked as "advertised."

[Mikko]

I think you're all gone grazy!

[K6-III]

Wow, what a thread!

[DGhost]

I think Greebe broke my brain...

[DentyCracker]

doesn't sound like it takes too much to do that

[Nicram]

Eh... couse of You I stop thinking at all...

[PAugustin]

About the recruiting thing, someone asked me the source. It comes from Matrox web site itself, I'm receiving thier job offers

Title: Linux Driver Specialist
Type of position: Full Time

Description: Matrox Imaging technology is used by industry leaders in factory automation, process control, electronic and pharmaceutical packaging, semiconductor inspection, robotics, radiology, microscopy, and video surveillance. Products include device-independent software development tools, standard frame grabbers, award-winning, real-time vision processors, integrated imaging platforms and smart cameras. MIL, a field-proven imaging library, is Matrox Imaging's core software product as it offers a common API across the entire hardware line. Specifically, the Matrox Imaging Library (MIL) is a high-level C/C++ Image Processing library which contains image processing, image analysis, pattern matching, blob analysis, measurement and OCR (optical character recognition) functions.

Responsibilities The candidate will be in charge of porting drivers for some MIL frame grabbers from Windows to Linux. The tasks will involve examining the Windows DDK API and developing parts of it under Linux, as well as maintaining the newly ported drivers. As part of a small team who's mandate is to port MIL to Linux, the candidate may be asked to participate in other aspects of the port and optimization of MIL on this new platform.
Qualifications:
Qualifications
. Bachelor's degree in electrical engineering, computer engineering, software engineering or computer science ;
· Strong programming skills in C and C++ ;
· Knowledge of driver implementations on Windows ;
· Kernel or driver development experience on Linux ;
· Interest in imaging and the ability to work in a team ;
· Good knowledge of French.

Category: Engineering-Software Design Division: Imaging Location: Dorval, Quebec

[Ribbit]

Wow, where to begin.....

About the differentiation thing:

My point is, a Radeon 8500 and a FireGL 8800 are almost identical hardware (remember, the hardware is the bit you're actually buying), yet the latter one was several times more expensive. Drivers for one will specifically and deliberately not run on the other, even though they would surely work just fine. I don't think tweaked drivers are worth several hundred $/£ (talking about new hardware). It's like having better roads which only cars with sunroofs or certain paint colours are allowed on.

I guess I'm particularly annoyed because the "low-end" drivers deliberately don't run on my "high-end" part.

Are Matrox not doing this?

Correct me if I'm wrong, but in Matrox' lineup I see a base 'prosumer' model (the Parhelia/P8X), and higher-end models which are very different hardware-wise (quad displays, different ramdacs, lots more memory, PCI-X). Now that's worth charging more for.

DVI output quality

Just to clarify for Wombat: The FireGL has a VGA plug and a DVI-I plug. The signal quality on the VGA plug is as good as on my G400 (actually it's a tiny bit worse, but you have to look very hard to notice). The analog signal quality on the DVI plug isn't as good as on the VGA port. Hope that clears that up, Wombat.

[dZeus]

Originally posted by Ribbit
Wow, where to begin.....

About the differentiation thing:

My point is, a Radeon 8500 and a FireGL 8800 are almost identical hardware (remember, the hardware is the bit you're actually buying), yet the latter one was several times more expensive. Drivers for one will specifically and deliberately not run on the other, even though they would surely work just fine. I don't think tweaked drivers are worth several hundred $/£ (talking about new hardware). It's like having better roads which only cars with sunroofs or certain paint colours are allowed on.

I think tweaked drivers plus the architectural differences do cost several hundred extra $/£ for each unit, considering the size of the pro market. Your analogy is completely irrelevant.

According to your logic, ATI should design 2 different graphic cores instead of one (even when they share a huge amount of the design), so the different drivers CAN'T work on the different chips. I hope you never will be responsible for cost cutting in a company

I guess I'm particularly annoyed because the "low-end" drivers deliberately don't run on my "high-end" part.

If you want to run the 8500 drivers, then buy a 8500 instead of a FireGL card, it's that simple.

[K6-III]

Well, the Ramdac for the second display is shielded better on the FireGL 8800, as compared to the Radeon 8500...

[Ribbit]

My main reason for getting a FireGL over a Radeon was concerns about signal quality (on both heads - the 8500 has a reputation for just being plain lousy in this department). There's also the fact that I wouldn't have had much say/knowledge of who made the Radeon, so I may well have ended with one that was 'underclocked', or worse - an 8500LE

dZeus - if it really does cost that much more to write pro drivers, then charge extra/separately for those drivers (or even have someone else write them perhaps) and make one piece of hardware to run them all on. Don't have the drivers deliberately restrict themselves - that just makes the hardware less useful overall.