Re: [Dri-devel] Status / Plans for DRI 2.0

On Fri, Jun 02, 2000 at 01:57:30PM -0500, Chris Edgington wrote:
| Now that SGI has made their SI open source, is the goal of using it as an
| alternative core renderer no longer being pursued?
Brian (and most of the other PI guys) are at an offsite meeting at VA
Linux today, so I'll jump in with a short answer.
The SI lacks the optimized code that went into Mesa for both software
rendering and for geometry processing. So building a fast open-source
driver based on the SI would require a good bit of work.
(Closed-source driver developers typically already have access to such
code, so this problem might not be difficult for them.)
There are also differences in the internal interfaces used by Mesa and
the SI. Brian is thinking about the things that would need to be done
to bring those together, so that it would be easier to use either
implementation as the codebase for a new driver. (For example, the
"imports" structures in the SI could be better-supported by the DRI
extension for XFree86.)
The main issue is manpower. Without dedicating some engineers to the
job (difficult because of funding constraints at the moment), the
whole process is happening in off-hours, so progress is slow.
I think that's the situation at the moment. Brian can issue a
correction if I've misunderstood.
Allen

Thread view

Hello. Our company, Intelligraphics, is receiving an increasing number of requests to
include high performance Linux display components in the driver suites that we do for our
clients. We don't want to reinvent the wheel here so we've been reviewing the feature set
in DRI 1.0 and the proposed feature set in DRI 2.0. Two questions that we need answers to
are:
What is the schedule (if any) for integrating the SGI SI with DRI 2.0?
What is the estimated "completion" date for DRI 2.0?
Thanks,
-Chris Edgington
Director of Graphics Development
Intelligraphics Inc.
http://www.intelligraphics.com

Chris Edgington wrote:
>
> Hello. Our company, Intelligraphics, is receiving an increasing number of requests to
> include high performance Linux display components in the driver suites that we do for our
> clients. We don't want to reinvent the wheel here so we've been reviewing the feature set
> in DRI 1.0 and the proposed feature set in DRI 2.0. Two questions that we need answers to
> are:
>
> What is the schedule (if any) for integrating the SGI SI with DRI 2.0?
No plans to do that for now.
> What is the estimated "completion" date for DRI 2.0?
Where did you see a feature list for DRI 2.0? Our features for that
release have changed over time. We may be bumping the version up
for XFree86 4.0.1
-Brian

> > What is the schedule (if any) for integrating the SGI SI with DRI 2.0?
>
> No plans to do that for now.
Brian, the website http://www.precisioninsight.com/dr/dri2.html says:
5.2 Support for SGI's OpenGL SI
Although DRI design has always included the potential use of a version of SGI's OpenGL SI
in place of Mesa, the current implementation has used Mesa because Mesa is open source. If
SGI decides to make some components of their SI available as open source, then we can
pursue the long term goal of using core renderers based on both SGI's SI and on Mesa.
Now that SGI has made their SI open source, is the goal of using it as an alternative core
renderer no longer being pursued?
> > What is the estimated "completion" date for DRI 2.0?
>
> Where did you see a feature list for DRI 2.0? Our features for that
> release have changed over time. We may be bumping the version up
> for XFree86 4.0.1
The feature list that we were expecting in DRI 2 is from the website listed above.
Thanks,
-Chris

On Fri, Jun 02, 2000 at 01:57:30PM -0500, Chris Edgington wrote:
| Now that SGI has made their SI open source, is the goal of using it as an
| alternative core renderer no longer being pursued?
Brian (and most of the other PI guys) are at an offsite meeting at VA
Linux today, so I'll jump in with a short answer.
The SI lacks the optimized code that went into Mesa for both software
rendering and for geometry processing. So building a fast open-source
driver based on the SI would require a good bit of work.
(Closed-source driver developers typically already have access to such
code, so this problem might not be difficult for them.)
There are also differences in the internal interfaces used by Mesa and
the SI. Brian is thinking about the things that would need to be done
to bring those together, so that it would be easier to use either
implementation as the codebase for a new driver. (For example, the
"imports" structures in the SI could be better-supported by the DRI
extension for XFree86.)
The main issue is manpower. Without dedicating some engineers to the
job (difficult because of funding constraints at the moment), the
whole process is happening in off-hours, so progress is slow.
I think that's the situation at the moment. Brian can issue a
correction if I've misunderstood.
Allen

akin@... wrote:
>
> On Fri, Jun 02, 2000 at 01:57:30PM -0500, Chris Edgington wrote:
> | Now that SGI has made their SI open source, is the goal of using it as an
> | alternative core renderer no longer being pursued?
>
> Brian (and most of the other PI guys) are at an offsite meeting at VA
> Linux today, so I'll jump in with a short answer.
>
> The SI lacks the optimized code that went into Mesa for both software
> rendering and for geometry processing. So building a fast open-source
> driver based on the SI would require a good bit of work.
> (Closed-source driver developers typically already have access to such
> code, so this problem might not be difficult for them.)
>
> There are also differences in the internal interfaces used by Mesa and
> the SI. Brian is thinking about the things that would need to be done
> to bring those together, so that it would be easier to use either
> implementation as the codebase for a new driver. (For example, the
> "imports" structures in the SI could be better-supported by the DRI
> extension for XFree86.)
>
> The main issue is manpower. Without dedicating some engineers to the
> job (difficult because of funding constraints at the moment), the
> whole process is happening in off-hours, so progress is slow.
>
> I think that's the situation at the moment. Brian can issue a
> correction if I've misunderstood.
You've summarized correctly.
I plan to make changes in Mesa to make it more like the SI, for
purposes of system integration. But this won't happen for a few
months, probably.
The DRI webpage listed the following for post-DRI 1.0 features:
Improved DMA buffer queueing algorithm.
Extensions to the DRI protocol.
Support for a device-specific shared memory region in the SAREA.
Optimized use of drawable lock.
Sophisticated texture memory management (including texture memory swapping).
Support for direct rendering to a pixmap.
Support for vertical retrace.
Overlay support.
Integration with DBE.
Clipping for double-buffered 3D windows.
Version checking for DDX and kernel drivers.
Handling of hardware lock during SIGSTOP.
Improve drmFinish.
Improved /proc/drm.
Improved documentation.
AFAIK, few of these things have been done so far. We've been busy
writing drivers and implementing other infrastructure features not on
this list.
Kevin Martin is the person who could comment best on this work but
he's pretty busy with Rage128 work right now.
-Brian