Reg: AIGLX architecture & it's difference from DRI

[Rahaman]

Dave,

Please find my response below.


-----Original Message-----
From: Dave Airlie <airlied at gmail.com>
To: mustaf.here at gmail.com
Cc: xorg at lists.freedesktop.org
Subject: Re: Reg: AIGLX architecture & it's difference from DRI
Date: Mon, 1 Sep 2008 19:03:52 +1000


On Mon, Sep 1, 2008 at 6:40 PM, Rahaman <mustaf.here at gmail.com> wrote:
> Hi Dave,
>
> Thanks for the response.
>
> I do not want to write a dri.so which will work either with DRI or with
> AIGLX.Let's put my questions one by one below..
>
> 1>If some one( a vendor) gives me only the OpenGL driver(no DRI/DRM
> functionality) implementation, can i use that and build my DRI/DRM modules
> i.e. Can i write my own dri.so & drm.so and still use the vendor provided
> OpenGL? Excuse me as some of my questions can be abstarct or some cases
> invalid,too as i am new to this area :-(

an OpenGL driver for Linux, is a kernel module + 3D client driver + 2D
driver support changes.
If someone is providing you an OpenGL driver then you need all the
bits. This doesn't necessarily mean a DRI driver,
nvidia for example provide GL drivers not using the DRI architecture
at all. If you are getting a GL driver for DRI architecture,
then you need all the bits.

M R: So does it mean that if some one(let's say NVIDIA) does not provide me any DRI driver, then i can't implement neither DRI/DRM nor AIGLX using that.I have to be content with indirect rendering only.

> 2>In case of AIGLX, where can i find the code inside xserver where it
> redirects the libGL calls to the GL_dri.so

Not sure why it matters, but its in glx directory or GL/ in older servers.

M R: I just asked it for the sake of curiosity.

>
> 3>Can i get a comparison like pros & cons for both the architecture in
> different context/use cases?

They aren't different architectures. X.org has the DRI architecture,
AIGLX is just part of that. AIGLX will be slower, as things like
textures need to be sent to the X server. AIGLX may not be able to
expose all the GL extensions due to missing GLX protocol for some.
AIGLX means the clients don't need access to the kernel directly.
Thats about all I can think off.

M R:Does it mean then that normal DRI/DRM path has always an edge over AIGLX? Is there any aspect where AIGLX is better than the client->DRI->DRM path?

Dave.
>
> Regs,
> Rahaman
>
>
> -----Original Message-----
> From: Dave Airlie <airlied at gmail.com>
> To: Mustafizur Rahaman <mustaf.here at gmail.com>
> Cc: xorg at lists.freedesktop.org
> Subject: Re: Reg: AIGLX architecture & it's difference from DRI
> Date: Mon, 1 Sep 2008 18:26:15 +1000
>
> On Mon, Sep 1, 2008 at 6:08 PM, Mustafizur Rahaman
> <mustaf.here at gmail.com> wrote:
>>
>> Hi,
>>
>> Can any one please tell me whether there is any document available which
>> explains me the AIGLX architecture briefly.What i am looking is if some
>> one
>> provides me only a OpenGL driver whether it is easier to build AIGLX on
>> top
>> of it or making DRI/DRM kind of framework is easier, provided that i have
>> a
>> X window system running below.
>>
>> I am also looking for the difference between the DRI & AIGLX
>> architecture.E.g, i know that the xserver loads the <hw>_dri.so when AIGLX
>> is enabled and the client app links to the <hw>_dri.so, when DRI is
>> enabled.Is there other differences as well?
>
> No really, AIGLX is part of the DRI architecture.
>
> You have direct rendering and indirect rendering, in the direct
> rendering case libGL calls directly into
> GL _dri.so driver, which then calls into the kernel, in the indirect
> rendering case libGL calls get send to GLX in the X server,
> which sends them to the _dri.so driver which then calls into kernel.
>
> You can't really write an _dri.so that only works in AIGLX or DRI,
> well you could but it would be pointless.
>
> Dave.
>>
>> Regs,
>> M R.
>>
>> _______________________________________________
>> xorg mailing list
>> xorg at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/xorg
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg/attachments/20080901/950d9287/attachment.html>