Re: DRI vs DRM
On Sunday 03 July 2005 19:21, Matthew Tippett wrote: > There is a standard name the library. > > See Section 8.2 - Packaging/Libraries of the OpenGL|ES spec on Khronos' web > page. > > It should be libGLES_xx.so where xx is CM or CL. Those correspond to libraries that implement OpenGL|ES. We're not implementing OpenGL|ES here. We're coopting its window system API. In principle we should be allowed to export the EGL API from any of the following: libGL.so - full OpenGL libGLES_CM.so - OpenGL|ES Common profile libGLES_CL.so - OpenGL|ES Common-Lite profile In particular, GLES specifies that glGetString(GL_VERSION) explicitly returns the GLES profile at the head of the string. This gives a generic GL engine a way of knowing whether it's running on full GL or one of the subsets. The implication there is that the use of the EGL API does not necessarily imply the use of a GLES subset. My concern is not so much what happens in libGLES_*. They'll export the EGL API, use the EGL driver model, etc. That's a given. My concern is which library, on a full-GL system, is responsible for advertising the EGL API. I think it should be libGL, and not some new libEGL. We don't split GLX from GL with a libGLX; I don't see why EGL should be different. - ajax pgpAXBlfgbggL.pgp Description: PGP signature
Re: DRI vs DRM
On 7/3/05, Brian Paul <[EMAIL PROTECTED]> wrote: > I said I'd like to keep the src/egl/main/ directory cross-platform. > The Linux version of libEGL.so could certainly have additional code in > it. But I'm certainly open to ideas. I just don't have much time to > spend on this project. The code is in a separate library currently but it is not hard to merge it into the Linux version of libEGL. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI vs DRM
Title: Re: DRI vs DRM There is a standard name the library. See Section 8.2 - Packaging/Libraries of the OpenGL|ES spec on Khronos' web page. It should be libGLES_xx.so where xx is CM or CL. Regards... Matthew -- Blackberry-Sent Matthew Tippett Acting Engineering Manager, Linux Software Engineering ATI Technologies Inc. Ph: +1 905 882 2600 x8014 Cell: +1 416 671 0673 -Original Message- From: [EMAIL PROTECTED] <[EMAIL PROTECTED]> To: Brian Paul <[EMAIL PROTECTED]> CC: Jon Smirl <[EMAIL PROTECTED]>; dri-devel@lists.sourceforge.net Sent: Sun Jul 03 18:44:00 2005 Subject: Re: DRI vs DRM On Sunday 03 July 2005 18:40, Brian Paul wrote: > I said I'd like to keep the src/egl/main/ directory cross-platform. > The Linux version of libEGL.so could certainly have additional code in > it. But I'm certainly open to ideas. I just don't have much time to > spend on this project. I'm still not entirely convinced the EGL API belongs anywhere but libGL. Is there a strong motivator for libEGL? - ajax
Re: DRI vs DRM
On Sunday 03 July 2005 18:40, Brian Paul wrote: > I said I'd like to keep the src/egl/main/ directory cross-platform. > The Linux version of libEGL.so could certainly have additional code in > it. But I'm certainly open to ideas. I just don't have much time to > spend on this project. I'm still not entirely convinced the EGL API belongs anywhere but libGL. Is there a strong motivator for libEGL? - ajax pgpVyyoLy0wXr.pgp Description: PGP signature
Re: DRI vs DRM
Jon Smirl wrote:
On 7/3/05, Adam Jackson <[EMAIL PROTECTED]> wrote:
Why aren't the DRI drivers themselves EGL drivers? That's sort of the model I
was anticipating:
- eglChooseDisplayMESA("display/0")
- EGL translates to /dev/dri/card0, opens it
- ioctl: what's the DRI driver name for this device?
- kernel: i915
- EGL loads i915_dri.so, calls its egl setup
- eglCreateContext notices the attached dri driver, does device setup
I guess I don't see the point of loading one module to have it load another,
particularly if that first module is always getting loaded.
Brian wants to keep libEGL crossplatform and generic so this forces me
into a third library.
I said I'd like to keep the src/egl/main/ directory cross-platform.
The Linux version of libEGL.so could certainly have additional code in
it. But I'm certainly open to ideas. I just don't have much time to
spend on this project.
I'm putting all of the common code into the
third library too. It contains code similar to miniglx.c
-Brian
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI vs DRM
On 7/3/05, Adam Jackson <[EMAIL PROTECTED]> wrote:
> Why aren't the DRI drivers themselves EGL drivers? That's sort of the model I
> was anticipating:
>
> - eglChooseDisplayMESA("display/0")
> - EGL translates to /dev/dri/card0, opens it
> - ioctl: what's the DRI driver name for this device?
> - kernel: i915
> - EGL loads i915_dri.so, calls its egl setup
> - eglCreateContext notices the attached dri driver, does device setup
>
> I guess I don't see the point of loading one module to have it load another,
> particularly if that first module is always getting loaded.
Brian wants to keep libEGL crossplatform and generic so this forces me
into a third library. I'm putting all of the common code into the
third library too. It contains code similar to miniglx.c
--
Jon Smirl
[EMAIL PROTECTED]
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI vs DRM
On Sunday 03 July 2005 12:31, Jon Smirl wrote:
> On 7/3/05, Adam Jackson <[EMAIL PROTECTED]> wrote:
> > Shouldn't this just be a string you pull right out of a drm ioctl? I
> > know the name currently lives in the server, but as with many things the
> > server does I think that's a mistake.
> >
> > Binding EGL driver load to sysfs is not portable.
>
> The code is only in my Linux drivers. In your EGL app you specify
> something like ":0". The generic code is wired to always load
> dri_egl.so for the :? syntax. dri_egl then figures out which screen
> corresponds to :0 and looks for the DRM sysfs entry. It then uses that
> to load the right DRI driver and passes control over.
Why aren't the DRI drivers themselves EGL drivers? That's sort of the model I
was anticipating:
- eglChooseDisplayMESA("display/0")
- EGL translates to /dev/dri/card0, opens it
- ioctl: what's the DRI driver name for this device?
- kernel: i915
- EGL loads i915_dri.so, calls its egl setup
- eglCreateContext notices the attached dri driver, does device setup
I guess I don't see the point of loading one module to have it load another,
particularly if that first module is always getting loaded.
> On Linux sysfs attributes and ioctls are very similar. It is now
> preferred on Linux to get simple things like this from a sysfs
> attribute instead of an ioctl since the sysfs attributes avoid 32/64
> and endian issues. It is also easy for a human to see which driver the
> DRM module needs.
The human should never have to care. There's going to need to be an ioctl for
this _anyway_ if anyone ever implements this on non-Linux. We should really
be avoiding OS-specific code paths in the driver as much as possible. That's
why we have the abstract DRM interface to begin with.
- ajax
pgpTWRV79UQ9l.pgp
Description: PGP signature
Re: DRI vs DRM
On 7/3/05, Jon Smirl <[EMAIL PROTECTED]> wrote: > Any ideas on what to call my DRM sysfs attribute which provides the > name of the corresponding DRI library? I named it "dri" initially but > that may not be descriptive enough. I called it dri_library_name, we can always change it. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI vs DRM
On 7/3/05, Adam Jackson <[EMAIL PROTECTED]> wrote: > Shouldn't this just be a string you pull right out of a drm ioctl? I know the > name currently lives in the server, but as with many things the server does I > think that's a mistake. > > Binding EGL driver load to sysfs is not portable. The code is only in my Linux drivers. In your EGL app you specify something like ":0". The generic code is wired to always load dri_egl.so for the :? syntax. dri_egl then figures out which screen corresponds to :0 and looks for the DRM sysfs entry. It then uses that to load the right DRI driver and passes control over. On Linux sysfs attributes and ioctls are very similar. It is now preferred on Linux to get simple things like this from a sysfs attribute instead of an ioctl since the sysfs attributes avoid 32/64 and endian issues. It is also easy for a human to see which driver the DRM module needs. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI vs DRM
Any ideas on what to call my DRM sysfs attribute which provides the name of the corresponding DRI library? I named it "dri" initially but that may not be descriptive enough. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI vs DRM
On Sul, 2005-07-03 at 05:04, Jon Smirl wrote: > There are three DRI drivers with no DRM. What is up with these? > gamma > s3v > trident trident was never finished s3v and gamma were both against old DRM and are not shipped in curren trees --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI vs DRM
On Sunday 03 July 2005 00:04, Jon Smirl wrote: > Is this table right? > > DRMDRI > ffb ffb > i810i830 > i830i830 > i915i915 With the caveat that i830 is old and deprecated. > There are three DRI drivers with no DRM. What is up with these? > gamma > s3v > trident The gamma drm was axed for being incurably ugly. The s3v and trident DRMs exist in 2.4-style form in old CVS branches but no one's brought them forward yet. I brought the DRI drivers forward as an exercise, and because the Mesa changes were the hard part, the DRM and DDX should be trivial if anyone wants to expend the effort. I don't have a trident yet, but far too many virges, so I should get to that one eventually. > During the EGL driver load process it checks /sys/drm/* looking for > card? entries. When it finds one I need a sysfs attribute in > /sys/drm/card?/dri to tell me which dri library to load. Shouldn't this just be a string you pull right out of a drm ioctl? I know the name currently lives in the server, but as with many things the server does I think that's a mistake. Binding EGL driver load to sysfs is not portable. - ajax pgp4ljclNLQ8C.pgp Description: PGP signature
Re: DRI vs DRM
> > There are three DRI drivers with no DRM. What is up with these? > gamma > s3v > trident > Well gamma did have one but its got hosed as it wasn't very pretty and responsbile for a lot of pain.. but keeping the dri driver building isnt too much hassle.. and you never know someone out there might want to resurrect it ... s3v and trident I've no real ideas on they may not use a DRM yet (i.e. very horribly insecure or the DRM may be in a branch of the old DRI CVS tree.. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
DRI vs DRM
Is this table right? DRMDRI ffb ffb i810i830 i830i830 i915i915 mach64 mach64 mgamga r128r128 radeonradeon or r200 or r300 savagesavage sis sis tdfx tdfx via unichome nonefb There are three DRI drivers with no DRM. What is up with these? gamma s3v trident During the EGL driver load process it checks /sys/drm/* looking for card? entries. When it finds one I need a sysfs attribute in /sys/drm/card?/dri to tell me which dri library to load. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
