In March your team submitted the LSARC fasttrack for OpenGL 2.0 for
Xsun/SPARC. LSARC derailed it, since it was not obvious why this
was being done first for the EOL'ed Xsun and not the preferred Xorg.
("Derailed" is not "denied", it's just "this isn't so obvious and
non-controversial that it can be approved without discussion.")
Instead of coming to LSARC and defending what you claim is a sound
engineering decision, your team simply stopped communicating with
LSARC and shipped without ARC approval. If it was that sound of an
engineering decision, then it should have been no problem to explain,
yet LSARC 2006/618 is *still* waiting for the team to come back and
meet with us.
Our team is already bearing the burden of your team's lack of resources,
in having to ship a different implementation of OpenGL on x86 - from a
pure resource management perspective, it would seem the best solution is
to remove your team's OpenGL from Solaris altogether and ship Mesa on both
platforms. This would also give customers the same OpenGL interfaces on
both platforms, though without hardware acceleration on SPARC, much as x86
users have had to suffer through for years, and would allow us to ship the
open source OpenGL on both platforms for Indiana instead of relying on your
closed source solution.
-Alan Coopersmith- alan.coopersmith at sun.com
Sun Microsystems, Inc. - X Window System Engineering
Linda Fellingham wrote:
> Alan,
>
> I am sorry but I don't understand your second comment.
> We are working on the x.org support for OpenGL2.0 right now. This
> effort has been further slowed by the loss of our ddx expert to
> implement the ddx support for x.org on XVR-2500, but it continues as a
> top priority.
>
> It was reasonable and proper to effect the internal changes needed to
> support OpenGL 2.0 that we could test against stable xsun interfaces. I
> don't make any apologies for a sound engineering decision.
>
> Linda
>
> Alan Coopersmith wrote:
>
>> We all have limited resources - what other work would you like us to
>> delay to work on DPA instead? The DMX work your team requested?
>> The other issues raised in porting XVR-2500 to Xorg?
>>
>> You've already spent your "get out of jail free card" by releasing
>> OpenGL 2.0 support without the Xorg support required by LSARC - it's
>> not up to us to dig you out of that hole.
>>
>> -Alan Coopersmith- alan.coopersmith at sun.com
>> Sun Microsystems, Inc. - X Window System Engineering
>>
>> Linda Fellingham wrote:
>>
>>> Alean,
>>>
>>> We would prefer that you provide DPA support in x.org xserver.
>>>
>>> Rewriting our software pipeline to use other interfaces will
>>> seriously delay the delivery given our extremely limited resources.
>>>
>>> Linda
>>>
>>> Alan Coopersmith wrote:
>>>
>>>> This was brought up at our X/DDX groups meeting a couple weeks ago, and
>>>> once we got over the initial shock that anyone besides DPS was using
>>>> DPA
>>>> (seriously? we had no idea), the discussion was that Xorg already must
>>>> have some sort of interface you should be using instead of porting DPA
>>>> to it - the existing Mesa OpenGL works fine without DPA, so your team
>>>> should be able to see what they use.
>>>>
>>>> -Alan Coopersmith- alan.coopersmith at sun.com
>>>> Sun Microsystems, Inc. - X Window System Engineering
>>>>
>>>> Linda Fellingham wrote:
>>>>
>>>>> Alan,
>>>>>
>>>>> Re the second 1) below:
>>>>>
>>>>> If you provide DPA support for x.org, then we can provide the
>>>>> software OpenGL pipeline.
>>>>>
>>>>> The binaries ARE redistributable.
>>>>>
>>>>> Note that if the resource (engineering and legal) for doing the
>>>>> work to open source the non-3D party graphics cards were provided,
>>>>> then it would be relatively straightforward to do so, and I would
>>>>> be very supportive of that.
>>>>>
>>>>> Linda
>>>>>
>>>>>
>>>>> Alan Coopersmith wrote:
>>>>>
>>>>>> Alan Coopersmith wrote:
>>>>>>
>>>>>>> So, now that I've bored everyone to sleep, this leaves us with
>>>>>>> these possibilities for Indiana on SPARC:
>>>>>>>
>>>>>>> 1) Ship Xsun binaries & existing SPARC Xsun driver binaries (all
>>>>>>> closed
>>>>>>> source)
>>>>>>>
>>>>>>> 2) Ship Xorg & use Martux's SPARC graphics drivers (all open source)
>>>>>>> with existing SPARC kernel driver binaries (all closed source)
>>>>>>
>>>>>>
>>>>>>
>>>>>> There is also a third choice I forgot to mention, probably since it's
>>>>>> the least desirable of all:
>>>>>>
>>>>>> 3) Ship Xorg with only the drivers provided by SPARC graphics (of
>>>>>> which
>>>>>> only XVR-2500 is likely to be done by your October proposed
>>>>>> timeline),
>>>>>> and leave those with older SPARCs unable to run X in Indiana.
>>>>>>
>>>>>> Also, Garrett reminded me of another issue in a message to
>>>>>> ogb-discuss [1]
>>>>>> - my prior description only covered 2D graphics, and ignored
>>>>>> OpenGL. For
>>>>>> OpenGL, a similar choice will have to be made:
>>>>>>
>>>>>> 1) Ship existing SPARC OpenGL, with accelerated modules for existing
>>>>>> SPARC graphics cards (closed source - and I don't know if it's
>>>>>> redistributable) - with Xsun, this has acceleration for most of
>>>>>> the
>>>>>> mid-to-high end SPARC graphics cards, with Xorg, only XVR-2500 is
>>>>>> known to have usable hardware acceleration - I don't know if the
>>>>>> others will easily work with Xorg or not once the framework is
>>>>>> in place.
>>>>>>
>>>>>> 2) Ship open source Mesa OpenGL, as we do on x86 (and virtually
>>>>>> all other
>>>>>> open source OS'es do), accepting that we'll have no hardware
>>>>>> acceleration
>>>>>> and break compatibility with existing SPARC OpenGL applications
>>>>>>
>>>>>> [1]
>>>>>> http://mail.opensolaris.org/pipermail/ogb-discuss/2007-June/001033.html
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
