On Fri, 29 Jul 2011 10:17:02 +0200, Hendrik Schmieder wrote:

>
>-------- Original-Nachricht --------
>> Datum: Thu, 28 Jul 2011 16:26:33 +0100
>> Von: "Roderick Klein" <RWKlein@...>
>> An: "eComStation@yahoogroups.com" <eComStation@yahoogroups.com>
>> Betreff: Re: [eCS] SNAP video for OS/2 and eComStation acquired
>
>> Hello,
>>
>> On Wed, 27 Jul 2011 13:15:34 +0200, Hendrik Schmieder wrote:
>>
>> >
>> >-------- Original-Nachricht --------
>> >> Datum: Fri, 22 Jul 2011 14:00:42 +0200
>> >> Von: Joachim Benjamins <joachim@...>
>> >> An: eComStation <edg@...>, testteam@...,
>> eComStation@yahoogroups.com
>> >> Betreff: [eCS] SNAP video for OS/2 and eComStation acquired
>> >
>> >> Mensys B.V. of the Netherlands has acquired the source code and rights
>> >> to create binary distributions of the SNAP product for OS/2 in an
>> >> agreement with the company Alt Richmond Inc. of Canada. The SNAP
>> >> graphics driver provides high performance support for current graphic
>> >> chipsets on eComStation.
>> >>
>> >....
>> >
>> >Does this mean that there is a chance for support of newer gpu chipsets ?
>> >
>> > Hendrik
>>
>> Compared to 2 or 3 years ago its becoming easier as more and more
>> companies are merging that manufactor GPU chipsets.
>>
>> But as I have written before in forums. Supporting GPU in a native
>> fashion is not the best
>> solution. We don't have all the man power.
>
>So it is nice to have snap source code, but that's all.
>Don't expect new features, only bugfixes, if any.

Please read **closely** what I had written.

Question what does native chipset support give you compared to the
strategy I outlined with proper
MTRR support and the generic wide screen enabler ?

This is part of an email with some additional info that I posted about
a month ago to the eComStation developer mailing:

"If you look closely at my Warpstock presentations, you can see that
Panorama has
to be updated to setup MTRR registers correctly on modern CPU's.
There is a lot of BS going around about Panorama. The reason it's slow
on some machines is because the MTRR registers
are not set properly. SNAP in some cases also does it wrong.
This can give up to a 100 fold performance difference (we measured that
with Sysbench on
one system with correctly and incorrectly set MTRR registers).

We also have a developer in the US that is working on a wide screen
enabler. The goal is to support in VESA mode, resolutions
that the VESA BIOS does not provide normally.

There are no human resources to write native video drivers currently.
Scitech at the time had situations where a video chipset would be
native supported on one, but not another system,
even if it was certified. Hence the reason why VESA support with
proper MTRR value's and the wide
screen enabler will get much higher priority, then native chipset
support.

There is one thing however that people need to understand about SNAP.
SNAP is not the holy grail.
SNAP, just like Panorama, relies on screen01.sys and other parts of the
GRADD video subsystem..
Also some of the lower video components need to be updated.
We already have access to a rewritten version of SCREEN01.SYS in C but
that needs further work. BHSVGA.DLL and VSVGA.SYS will require some
maintance as well.
This will also require man hours.

Next to that SNAP seems to have problems on some SMP systems.
SNAP does not work properly with suspend/resume of ACPI.
The VESA code of Panorama needs to be put into SNAP
and the screenbuffer code of Panorama needs to be fixed to support DIVE
correctly.

So native chipsets support is not ruled out but currently none are
planned as first a lot of work
needs to be done on SNAP itself and the underlying GRADD code."


Roderick Klein
Mensys