|
Hi, While replying your previous email, i had the doubt whether you are talking about dispatching the gl APIs or dispatching the glX APIs because you mentioned "How glx extension requests are dispatched"...so i thought you are mainly asking about dispatching of glX APIs :-)..So, anyway below are my responses... Wang Baisheng wrote: <Rahaman>: I don't think it depends on whether the server supports DRI. Because DRI means direct rendering from client side, thus bypassing the server altogether.So, as far as i know & i have seen from the mesa code also, that the DRI setup is being done from the client side using the XF86 DRI API and if the setup fails, it automatically goes for indirect rendering.Dear Rahaman, Thank you for answering my questions! Great!And I have read some docs about dri and aiglx. But Maybe I misunderstand them. They all say that when using indirect render, it's the glx module with X server will dispatch the request to Mesa. Pls refer : http://dri.sourceforge.net/doc/dri_data_flow.html http://dri.sourceforge.net/doc/dri_control_flow.html And another slide in a ppt named 'Accelerated Indirect GLX' written by Kristian Høgsberg on XDevConf , 9 Feb 2006 : ====================== Indirect rendering If the server doesn't support DRI, if part of the DRI setup fails or if the users specifically asks for it, libGL will fall back to indirect rendering. <Rahaman>: If it is only indirect mode, then you are right. But there is something called AIGLX(accelerated indirect), where the requests are first passed to the server & then the xserver dispatch those GL request to the libGL and DRI driver to render on the framebuffer(Here the same libGL is linked to both the client program and thr xserver).In indirect mode, all OpenGL requests are marshalled to the server and libGL is reduced to just a protocol layer. <Rahaman>: For indirect/AIGLX mode, it is correct assumption.In the server, the GLX module maintains an OpenGL context on behalf of the client and forwards the demarshalled requests to the context. <Rahaman>: This is something which i had asked before and got answered, but don't remember them exactly right now:-(The current implementation pulls parts of Mesa into the Glcore module to provide a software backed GL context. <Rahaman>: You are correct. xm_api.c will be only be built if you are building mesa ONLY for indirect mode, i.e. you are not using any h/w accelerated GL library/DRI driver. In that case, complete rendering is being taken care in s/w by mesa & the final o/p is being sent to xserver to render onto the frame buffer.Synonymous with software/slow rendering ===================== It also said that "The current implementation pulls parts of Mesa into the Glcore module to provide a software backed GL context." But when I look the code of xm_api.c, I found it seems that in indirect mode, libGL is not just a protocol layer, and the client use its software render functions directly and those software render functions just like a normal X client using xlib api. So can I say so that when in software render mode, it's not X server glx module dispatch the requests to Mesa, while it's the client using the libGL software render functions directly ? You should remember that you can compile mesa for dri & indirect mode.If you built it for indirect mode, everything taken care in s/w & the final o/p is being sent to xserver. If you built it for DRI mode & in run time, DRI setup successds, then it will run in DRI mode.But, in run time, the DRI setup can fail and in that case, request will still be sent to xserver but then xserver will by pass them to mesa to render. Thanks! Regards, Baisheng On Thursday 05 March 2009 04:56:57 am Mustafizur Rahaman wrote: |
_______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
