<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=utf-8" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> P.S. Frankly, i am also relatively newer in this domain, so i also have doubts against my own understanding :-(, so just sharing whatever i have got hold of till now, don't believe me blindly:-) I would request if any experts can rectify us, if we are going in wrong direction anywhere... Hi Wang, Please find my response below... Wang Baisheng wrote: <blockquote cite="mid:200903061551.19555.bswang@redflag-linux.com" type="cite"> <pre wrap="">Dear Rahaman, Thanks again! You mean that if I build X with DRI support, all redering request are all dispatched to the X Server regardless of loading the DRI driver success of failure ? </pre> </blockquote> <Rahaman>: As far as i know Yes.Let's say i build my mesa library with dri configuration and also build my xserver with dri enabled. 1>Then when i am running my app and if the DRI driver loading is successful in client side, then DRI rendering is done from client side, xserver only does some DRI/DRM context management etc. 2>But if dri driver can't be loaded for any reason in the client side & xserver was able to load the dri driver, then all the glX & gl request comes to xserver and then xserver passes them to the libGL & dri driver for rendering. 3>If neither client nor xserver was able to load the DRI driver, then gl request comes to xserver but xserver passes it to Mesa for s/w rendering( see below) <blockquote cite="mid:200903061551.19555.bswang@redflag-linux.com" type="cite"> <pre wrap=""> And another question, which is I asked before, if the DRI setup failed, how the xserver bypassed the rendering request to Mesa to render? Would you please give me some glue at code level ? </pre> </blockquote> <Rahaman> There is a file called glxproto.h which lists down all the glX & GL API.Here you will find the following definition #define X_GLrop_Clear 127 Then check for Render_function_table in xserver/GL/glx/indirect_table.c & search for 127th item in that array, you will find __glXDisp_Clear(), which is nothing but CALL_Clear.Upon further checking you will find, this is calling dispatch->clear, this dispatch is nothing but the GL context, here it is mesa's dispatch context (When DRI setup failed) and thus this will re-direct to _mesa_Clear().It is difficult to explain this in details in email, but if you track down/debug how a glClear call is redirected to _mesa_Clear(when i am running my client program with mesa s/w only, NO DRI/AIGLX etc), you would be able to figure out. I also saw Jerome's reply...i think it will first call to _mesa_Clear & from _mesa_Clear, it will go to _swrast_Clear()._swrast_Clear() is the default function for clear in s/w, so i dont think it is called directly from outside.Check _mesa_init_driver_functions(), here all the default function pointers are assigned.These functions pointers are overridden by actual DRI driver functions, if DRI setup is successful, otherwise it will automatically fall to these s/w fallback. You can also search for posts against my name in the mailing list archive, you will get some hints. Regs, Rahaman. <blockquote cite="mid:200903061551.19555.bswang@redflag-linux.com" type="cite"> <pre wrap=""> Thanks, Regards, Baisheng On Friday 06 March 2009 02:05:56 am Mustafizur Rahaman wrote: </pre> <blockquote type="cite"> <pre wrap=""> 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: 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 : <a class="moz-txt-link-freetext" href="http://dri.sourceforge.net/doc/dri_data_flow.html">http://dri.sourceforge.net/doc/dri_data_flow.html</a> <a class="moz-txt-link-freetext" href="http://dri.sourceforge.net/doc/dri_control_flow.html">http://dri.sourceforge.net/doc/dri_control_flow.html</a> 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>: 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. In indirect mode, all OpenGL requests are marshalled to the server and libG L is reduced to just a protocol layer. <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 the server, the GLX module maintains an OpenGL context on behalf of the client and forwards the demarshalled requests to the context. <Rahaman>: For indirect/AIGLX mode, it is correct assumption. The current implementation pulls parts of Mesa into the Glcore module to pr ovide a software backed GL context. <Rahaman>: This is something which i had asked before and got answered, but don't remember them exactly right now:-( 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 ? <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. 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: Hi, I also faced the same problem sometime back , but any how after lot of debugging and analyzing the code, i have got some sort of understanding, which i am sharing.If anywhere, my understanding is not correct, i apologize for that. Check for these three files 1>glxcmds.c & glxext.c & 2> glxapi.c in mesa code. If you see the Makefiles, glxcmds.c & glxext.c is built for direct rendering & glxapi.c is built for indirect rendering, not both of them are built at the same time with the client program. So, let's take glxgear.c code for example and track the code flow, e.g. following would be the code flow for glXCreateContext for indirect rendering case.. glXCreateContext==>Fake_glXCreateContext==>XMesaCreateContext==>_mesa_initi alize_context==>_mesa_init_exec_table==>Inside here, you can see all the mesa s/w functions are initialized. For direct rendering case, the following would be the flow... glXCreateContext==>XF86DRICreateContextWithConfig==> Then it goes to dri driver's create context and like this... I would request you to debug the code for indirect rendering for glxgear and see the code flow.And paralelly, try to follow the code flow for direct rendering(by code reading if you can't debug)..that's the way i followed... Have patient..because believe me, you will need that.. :-) Regs, Rahaman. Wang Baisheng wrote: Dear all, Now I am studying the DRI. But I have some questions and I can not get more information from internet. So would you please give me some information for my following questions: How glx extension requests are dispatched to mesa for software render? And how glx extension requests are dispatched to DRI driver ? And I also find in x server 1.3, there is a glcore, but in x server 1.5, the glcore is disappear. Thanks! Regards, Baisheng _______________________________________________ xorg mailing list <a class="moz-txt-link-abbreviated" href="mailto:xorg@lists.freedesktop.org">xorg@lists.freedesktop.org</a> <a class="moz-txt-link-freetext" href="http://lists.freedesktop.org/mailman/listinfo/xorg">http://lists.freedesktop.org/mailman/listinfo/xorg</a> _______________________________________________ xorg mailing list <a class="moz-txt-link-abbreviated" href="mailto:xorg@lists.freedesktop.org">xorg@lists.freedesktop.org</a> <a class="moz-txt-link-freetext" href="http://lists.freedesktop.org/mailman/listinfo/xorg">http://lists.freedesktop.org/mailman/listinfo/xorg</a> </pre> </blockquote> <pre wrap=""> </pre> </blockquote> </body> </html>