New matrox driver posted

[The PIT]

Will Matrox still around in 2007 ??? Probably not sadly.

[Peter Aragon]

Originally posted by DGhost
keep this in mind - longhorn was originally targeted at 2003-2005ish release. the specifications for GDI+2.0 have been available for quite a while. the Parhelia claimed full support for it in its spec sheet.

the new display engine in Longhorn does not require PS2.0 and VS2.0, contrary to popular opinion. it does, however, require DX9 level drivers to enable the sort of functionality needed for it.

GDI is R.I.P. in Longhorn. The preferred way to go there is with Vector graphics: XAML Example
For this they are designing new extension to DirectX to facilitate the presentation layer, which has been completely redesigned, so goodbye to HWND's and such. I could imagine you could optimize the graphics handling on a GPU for certain eye-candy that will be used in Longhorn.

And BTW, of what I heard first beta's are scheduled for end of this year, and the final for end 2005 for developers and begin 2006 for consumers. So for me it will be sooner and I still have to decide what graphics card to put in our test-machines.

[Fluff]

mmm vector smoothness.

[DGhost]

Originally posted by Peter Aragon
GDI is R.I.P. in Longhorn. The preferred way to go there is with Vector graphics: XAML Example
For this they are designing new extension to DirectX to facilitate the presentation layer, which has been completely redesigned, so goodbye to HWND's and such. I could imagine you could optimize the graphics handling on a GPU for certain eye-candy that will be used in Longhorn.

And BTW, of what I heard first beta's are scheduled for end of this year, and the final for end 2005 for developers and begin 2006 for consumers. So for me it will be sooner and I still have to decide what graphics card to put in our test-machines.

*sigh* if only i had time to write a rant. short answer: GDI+ is still in Longhorn. the last version of GDI+ officially available is GDI+ 1.1 (included in Windows XP). GDI+ 2.0 is the core interface for all the new GUI stuff. Avalon builds on top of GDI+ 2.0 to enable the features you are talking about.

and "for you?" whats this bullshit? you gone warez kiddy or something?

the first betas were scheduled to start last year. shame they missed that date.

[Peter Aragon]

Originally posted by DGhost
and "for you?" whats this bullshit? you gone warez kiddy or something?

Sorry if that may have been interpreted otherwise, but I meant as a developer... And the rough schedules I had confirmed again a few days ago from a business related phone call with a Windows Program Manager from Microsoft

Interoperability between "Avalon" and GDI
The "Avalon" graphics rendering layer provides new drawing and animation features to the "Longhorn" platform. These features were previously provided to the platform by the application of specialized libraries—specifically, Windows Graphics Device Interface (GDI) and Windows GDI+. To accommodate developers working with existing unmanaged applications, the Visual application programming interface (API) provides limited interoperability between the "Avalon" graphics system and GDI-based rendering services.

The following section is provided for developers who need to enable legacy applications to draw using the "Avalon" drawing and rendering functionality. Developers who merely want to host GDI-based windows in "Avalon" applications can use the HwndVisual object. For more information, see Using the Visual Layer. It's important to note the limitations of interoperability support between "Avalon" graphics and GDI-based graphics. Developers should not expect full "Avalon" hosting in unmanaged Microsoft Win32® applications. Only specially-authored "Avalon" graphics components will interoperate with GDI-based applications. More specifically, it is not possible to render GDI primitives and "Avalon" primitives in the same window or to the same surface.

A Win32 application can use "Avalon" drawing and rendering by specifying a window class style that distinguishes between a window that draws with GDI and one that draws with "Avalon". The developer must set the class style CS_MIL when creating the window to specify that a window uses "Avalon" rendering. A window must render using either GDI or "Avalon"; the two graphics systems cannot be mixed within the same window. One reason for this necessary distinction is that "Avalon" graphics rendering is hardware-accelerated. To make use of hardware-accelerated rendering in applications that use both GDI and "Avalon", the CS_MIL class style must be set on your application's top-level window.

Source:
Vector Drawing for "Avalon"

So unless you want to have something personal against me I suppose an appology would be the least you could do.

[lecter]

Originally posted by DGhost

and "for you?" whats this bullshit? you gone warez kiddy or something?

The RTM build is always done a few months before the actual CDs hit store shelves and that's also when it gets distributed to MS "partners", no biggie in that.

[DGhost]

Originally posted by Peter Aragon
Sorry if that may have been interpreted otherwise, but I meant as a developer... And the rough schedules I had confirmed again a few days ago from a business related phone call with a Windows Program Manager from Microsoft

my bad. generally the people around here who drop little lines like that are usually the warez kiddies... most of the people who have legitimate access to such things around here keep it hush hush, as last i checked that is the way Microsoft prefered it. i would re-read your MSDN and any NDA's that MS sent your company, as well as any EULA's that might be floating around. general stuff. things might have changed on that front while i was gone, but i somehow doubt it. they have not changed in quite a few years.

re: vector graphics/avalon and GDI+ 2.0. last i heard, all the new rendering technology was being called "GDI+ 2.0" and Avalon was going to be the managed, XML based way of exploiting it. that being said, it looks like Microsoft either changed it or just reveiled more information when i was gone. probably some of both. either way, those articles are interesting and i do stand quite corrected.

[Peter Aragon]

ok, appology accepted, no harm done..

And about NDA's, I have heard about them off course and I cannot confirm or deny whether I would have signed one of those, but the confirmation of the release dates was just my hunches getting confirmed by his hunches. As if it would matter if they would say: 11th of januar 2006 we will have it in the shelves. It is still a long time in the future and schedules are just schedules, they can be changed when needed. But I certainly hope they go in the direction of releasing the bare minimum, and adding features as they are ready... You can see that happening in Windows 2003 Server, and even in the Service Pack policy, where they added features, whereas in NT4 you would only get fixes.

[G400SG16mb]

is there any good reason why Matrox doesn't just cast out the entire sources of their card drivers under an open source licence? It seems obvious that they're having great difficulty optimising and maintain them by themselves. An open driver model for their Windows and Linux drivers could see their quality improve substantially.

[Sasq]

Is there any good reason why Matrox should give other companies free range to work out how M has maganged to get Dual Head etc working so well - for free?

[UtwigMU]

I had no problems with Windows driver, they are actually quite good and I'm testdriving the DX9 beta now. The releases are often, they are getting more pro 3D apps certified, there appear to be no significant complaints - It doesn't appear as though they have significant problems optimizing and releasing drivers.

As for linux drivers - no graphic maker opensources the drivers as it would reveal trade secrets.

Another thing: The Google Zeitgeist shows that 1% of people that access it use linux - that's 4-times lower than macs which have 4% share. The linux crowd is loud, but IMO the share of Linux _desktops_ is too low for now for workstation apps, games to port and consumer/workstation hardware makers (soundcards, graphic cards) to devote large driver teams.

The server situation is different as Linux share is big - SCSI cards, NICs, server chipsets - they all offer server validated drivers for Linux.

Once enough* people jump on Linux desktop wagon, things will change.

*What share is enough:
- Apple has 4% and there are little workstation apps and games and hardware support
- Windows98, which has 23% on Google Zeitgeist is seeing less and less support

IMO untill share of Linux on the desktop doesn't jump past 5%, there won't be same hardware and software support as for Windows.

[albatorsk]

I agree that Matrox is under no obligation what so ever to open source their drivers. It may do as much damage as it does good. But the current situation is bad, to say the least.

Matrox doesn't really treat their small linux customer base very well. To even be able to download the drivers, you have to register with your e-mail address on their website. Why do they need my address? What are they supposed to send me? It doesn't say. Anyway, once you have the drivers, you find out that they lack 3D and TV-out for anything other than cloned single head, i.e. no feature display. Thank you Matrox. If you're using the card they way it was designed to, with a DVI, you're stuck with XFree86. If you try to exit X, the machine will hang, and if you're using the kernel module for Dual Head, the kernel will crasch! How would you like it if everytime you felt like turning off Windows, the drivers would crash the system?

If you want support for hardware accelerated OpenGL, you have to ask a guy at matrox to please send them via e-mail. Seriously. And when you get them, you find out that they don't even work on SMP-machines. I thought this was supposed to be a "professional" card for home users? I've also heard that they have problems with HT on P4-based systems. The computer will completely lock up. Let's hope you're using a good journaling filesystem.
GigaColour is actually supported, allthogh it's not mentioned anywhere in the documentation. It's at the expense of Xv (overlay), so you either get 10 billion colors or overlay. I have no idea if it's a hardware limitation (i.e. the situation's the same on Windows), and with the current tight lipped situation at Matrox, we'll probably never find out.

Oh, and by the way: make sure you're using linux kernel 2.4, or otherwise you can say goodbye to anything other single head 2D. That 2.6 kernel thing-a-ma-bob that's been available since, oh, December last year is probably too new or hip or something for Matrox to bother supporting.

No, I'm not bitter. Where'd you get that idea?

[leech]

The situation for us Parhelia owners with linux is pretty dire. Though for what it's worth, I had issues with installing 2.6.3 kernel that had nothing to do with my matrox card. Though probably only due to the package of it for Debian (been too lazy to try to compile the kernel myself...)

Well, the problem with the Hyper-threading is of course because of the problem with SMP machines, since to use the HT, you have to comple smp into your kernel. I just use it for now without SMP.

At least we can do triple-head independant, which, even though it's unsupported by Matrox, works quite well here.

The thing with X hanging on exit... I have only had that problem when running KDE 3.2.1. It locks the machine hard. Gnome 2.4 doesn't have that issue. That's ok by me, I prefer Gnome anyhow.. (Of course, now someone needs to make a Qt theme for the H2O Sapphire, I love this theme )

I wonder if Matrox would ever consider porting powerdesk over to Mono.... Since they use .Net, it shouldn't be all that hard. Mono is looking quite complete lately.

Leech

[runderwo]

Matrox's half-ass support and insistence on secrecy is the only reason I don't own a Parhelia right now. The moment they put up a NDA form to get access to the docs, I buy one. It's as simple as that. As long as they don't, well, I'm happy enough hacking on the G400 driver, so no skin off my back.

I got flamed big time over on the Matrox forums for even suggesting that they reveal their hardware docs to people who want an alternative to the "official channel" for support. The insinuation is that Matrox would lose too much due to documentation leaks even when a NDA is required, and that open source drivers are universally of poor quality anyway so it's not worth their time to support third party developers. Notwithstanding that "third party developers" != "open source developers" (for instance, with docs, I could release a commercially supported proprietary Parhelia driver); I don't understand that attitude myself, but I hope whoever he was is happy with the level of support Matrox is giving, because that's obviously all he's going to get if he continues to defend their current strategy.

I think people mistakenly equate "offering hardware documentation" with "open sourcing their drivers". It is pretty unreasonable to ask for the latter, because of the myriad of copyright, patent, and trade secret issues involved, especially if code from third parties is involved. But, I don't see what is so unreasonable about the former. All I can come up with is that they consider their hardware interface a trade secret, and that they don't have the resources to enforce a NDA or non-compete agreement in the case that someone sends it off to NVIDIA the next day. That seems a pretty weak argument compared to the sales they are losing from their shoddy support, but hey, who am I to argue with the bean counters.

The other, more insidious problem is that if they reveal how their hardware works, they are opening themselves up to potential patent lawsuits. Consider that Parhelia contains feature X, which was independently developed by Matrox, but infringes on patent Y filed by NVIDIA. If they don't release docs, they have little to no chances of ever having a problem due to that patent violation, whether they know or don't know that they have infringed on a patent. If they do release the docs, and someone writes an open source driver, and NVIDIA takes a look at it, they might notice "Hey, don't we have a patent for X? Oh yeah, here it is..." and call up the lawyers for a juicy patent suit. I suspect this is a more general problem in the industry than something that is specific to Matrox. IMO, if I independently developed a technique that happened to be covered under a competitor's patent, the fact that I independently developed it (and have the notes to prove it) should be enough proof that the patented technique itself was obvious and thus the patent is invalid. But that's wishful thinking. It just comes down to a cost/benefit thing. In Matrox's perception, I think it costs them less to just hide their docs and lose the associated sales than to: do patent research, do all the bookkeeping to make sure they are covered in case of a suit, and defend themselves against the nuisance patent suits that might occur down the road.

As for the Parhelia only officially supporting DX8.1, I think the strategy is pretty clear. They are trying to EOL Parhelia as soon as possible so that their next hardware cycle looks more attractive. DX9 support for G-series is irrelevant because the hardware is too slow for the latest commercial game productions anyway. But official DX9 support for Parhelia has the potential to conflict with sales of their next-gen part when it arrives.

[borat]

I can completely see why they will not release hardware documentation, the only reason they sell cards is because to their consumers they are unique in some way, as soon as hardware docs are released its public knowledge. We all know what would happen, ATI and Nvid would get their hands on matrox tech, matrox would end up with a lengthy legal case and probably get a few million pounds but nvid and co would end up keeping the tech saying "we'd have had it independantly by now anyway, its out of date". End case matrox gets screwed. If they release their hardware interface they have nothing on the compitition. As for NDA's the info always gets out - look at something as silly as the parhelia release. Also if some open source developed drivers were not working chances are M would have a bunch of winging customers saying - "i only bought it because there were drivers for it and now they dont work properly". If your going to do a job then do it properly and support it fully is the way i think they should go, nice and proffesional like the client base they aim at now. I personally dont like the idea of open source, there are no $$$'s in it for the ppl who do the grind and as such theres no incentive to fix a problem that only a few people suffer from, which is bad if you/your business is the one suffering. Not saying that the open source community do a bad job, but its hard to take them seriously for anything other than enthusiast experimenting when you have little support on offer for your goods.