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 ? 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 ? Thanks, Regards, Baisheng On Friday 06 March 2009 02:05:56 am Mustafizur Rahaman wrote: > 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 : > 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>: 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 > [email protected] > http://lists.freedesktop.org/mailman/listinfo/xorg > > _______________________________________________ > xorg mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/xorg _______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
