[Bug 11804] polygon point applied incorrect texture when point_sprite enabled
http://bugs.freedesktop.org/show_bug.cgi?id=11804 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from [EMAIL PROTECTED] 2007-08-02 00:32 PST --- fixed in mesa, commit 505453a04e8ba5e394c34401bd9ec320ffce2423 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 11806] New: Wrong upper index check, buffer overflow .../dri/sis/sis_tex.c
http://bugs.freedesktop.org/show_bug.cgi?id=11806 Summary: Wrong upper index check, buffer overflow .../dri/sis/sis_tex.c Product: Mesa Version: unspecified Platform: Other OS/Version: All Status: NEW Keywords: janitor, patch Severity: normal Priority: medium Component: Drivers/DRI/SiS AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] A check is done based on MAX_TEXTURE_LEVELS which is 12, but the then used array has only SIS_MAX_TEXTURE_LEVELS 11. Please apply attached patch. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 11806] Wrong upper index check, buffer overflow .../dri/sis/sis_tex.c
http://bugs.freedesktop.org/show_bug.cgi?id=11806 --- Comment #1 from [EMAIL PROTECTED] 2007-08-02 01:01 PST --- Created an attachment (id=10953) -- (http://bugs.freedesktop.org/attachment.cgi?id=10953action=view) MAX_TEXTURE_LEVELS = SIS_MAX_TEXTURE_LEVELS -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 11810] Nullpointer dereference fix .../dri/i915tex/intel_span.c
http://bugs.freedesktop.org/show_bug.cgi?id=11810 --- Comment #1 from [EMAIL PROTECTED] 2007-08-02 05:06 PST --- Created an attachment (id=10960) -- (http://bugs.freedesktop.org/attachment.cgi?id=10960action=view) Moved that in guarded block... -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 11810] New: Nullpointer dereference fix .../dri/i915tex/intel_span.c
http://bugs.freedesktop.org/show_bug.cgi?id=11810 Summary: Nullpointer dereference fix .../dri/i915tex/intel_span.c Product: Mesa Version: unspecified Platform: Other OS/Version: All Status: NEW Keywords: janitor, patch Severity: normal Priority: medium Component: Drivers/DRI/i915 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] Please apply attached patch, I moved the affected inside the previous Null-pointer check guarded area. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 11814] New: Unnecessary NULL check removal in .../dri/r300/r300_texmem.c
http://bugs.freedesktop.org/show_bug.cgi?id=11814 Summary: Unnecessary NULL check removal in .../dri/r300/r300_texmem.c Product: Mesa Version: unspecified Platform: Other OS/Version: All Status: NEW Keywords: janitor, patch Severity: trivial Priority: lowest Component: Drivers/DRI/r300 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] If t would be NULL at this point, it would have been already crashed, several dereferences before. Please apply attached patch. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 11814] Unnecessary NULL check removal in .../dri/r300/r300_texmem.c
http://bugs.freedesktop.org/show_bug.cgi?id=11814 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from [EMAIL PROTECTED] 2007-08-02 07:44 PST --- fixed. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 11814] Unnecessary NULL check removal in .../dri/r300/r300_texmem.c
http://bugs.freedesktop.org/show_bug.cgi?id=11814 --- Comment #1 from [EMAIL PROTECTED] 2007-08-02 07:30 PST --- Created an attachment (id=10964) -- (http://bugs.freedesktop.org/attachment.cgi?id=10964action=view) Removes unneccessary check -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 11810] Nullpointer dereference fix .../dri/i915tex/intel_span.c
http://bugs.freedesktop.org/show_bug.cgi?id=11810 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from [EMAIL PROTECTED] 2007-08-02 07:32 PST --- Fixed in git. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 11806] Wrong upper index check, buffer overflow .../dri/sis/sis_tex.c
http://bugs.freedesktop.org/show_bug.cgi?id=11806 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from [EMAIL PROTECTED] 2007-08-02 07:35 PST --- fixed in git. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
Jesse Barnes wrote: I finally found some time to create a new wiki page for all the modesetting/configuration related DRM enhancements we've been talking about: http://dri.freedesktop.org/wiki/DrmModesetting Please take a look and let me know what you think. I still have to go through all the feedback I received from the lkml post I made awhile back, and make sure it's captured (I think it is, albeit at a fairly high level mostly), and add more detail in the design and development sections. Jakub, hopefully you can go over it and add more detail about the userland APIs? Dave and Keith, we talked about the new device node scheme awhile back, but I only have notes on what the master node should be responsible for, did we have any new ioctls for the slave nodes? Ring buffer mapping, etc. should probably be there? Thanks, Jesse This likely does not really fit exactly in modesetting rework so sorry if i hijack this thread a bit. I have been thinking to vblank stuff in drm and i am wondering if while rearchitecturing the drm it would be nice to get rid of current vblank things and use fence instead. So having special fence for vblank, with a vblank fence queue for each crtc. If this was already in some plan ignore this mail :). Btw i think that some GPU can wait on vblank using cmd ie you don't need to ask the card to emit irq you just insert a cmd in stream which stall further cmd execution until vblank happen, this might be good for power consumption. And will also be nice with app trying to avoid flickering/tearing (mostly movie player). Concern is on application using things like GLX_SGI_video_sync as without using IRQ we likely miss some vblank and thus can't maintain accurate counter, thus maybe this fence vblank stuff might just be an addition to vblank rework you already proposed few weeks ago. Cheers, Jerome Glisse - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
On Thu, 2007-08-02 at 17:44 +0200, Jerome Glisse wrote: Btw i think that some GPU can wait on vblank using cmd ie you don't need to ask the card to emit irq you just insert a cmd in stream which stall further cmd execution until vblank happen, this might be good for power consumption. It's generally a bad idea because it prevents the GPU from doing anything else that could be done before vertical blank. And will also be nice with app trying to avoid flickering/tearing (mostly movie player). IME this can be achieved perfectly by scheduling the buffer swap to be executed from the interrupt handler, see the i915 DRM. Concern is on application using things like GLX_SGI_video_sync as without using IRQ we likely miss some vblank and thus can't maintain accurate counter, thus maybe this fence vblank stuff might just be an addition to vblank rework you already proposed few weeks ago. Yes, while vblank fences would be a useful addition (without them, the above swap scheduling is prone to a race condition with multiple logical CPUs), I don't think they can be a replacement for the current vblank mechanisms, at least not all of them. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
Michel Dänzer wrote: On Thu, 2007-08-02 at 17:44 +0200, Jerome Glisse wrote: Btw i think that some GPU can wait on vblank using cmd ie you don't need to ask the card to emit irq you just insert a cmd in stream which stall further cmd execution until vblank happen, this might be good for power consumption. It's generally a bad idea because it prevents the GPU from doing anything else that could be done before vertical blank. This is true on cards with a single command stream - if you had per-context ringbuffers and a hardware scheduler, it might be better. Unfortunately, you still end up forcing the cliprects not to change, unless you also have some hardware mechanism for that, which I think is pretty rare nowdays. Hmm. Maybe you could use the frontbuffer alpha bits as a window id. You'd still need to either lock the window position, or find some way of telling the hardware about window position changes, or... something else... Anyway, it gets complicated... Keith - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
Jesse Barnes wrote: I finally found some time to create a new wiki page for all the modesetting/configuration related DRM enhancements we've been talking about: http://dri.freedesktop.org/wiki/DrmModesetting Please take a look and let me know what you think. I still have to go through all the feedback I received from the lkml post I made awhile back, and make sure it's captured (I think it is, albeit at a fairly high level mostly), and add more detail in the design and development sections. Jakub, hopefully you can go over it and add more detail about the userland APIs? Dave and Keith, we talked about the new device node scheme awhile back, but I only have notes on what the master node should be responsible for, did we have any new ioctls for the slave nodes? Ring buffer mapping, etc. should probably be there? Thanks, Jesse This time i do not hijack the thread :) So we just discussed with Jakob and Jesse on this on irc and here is what i believe we agreed on: There should be master (possibly one for each card) which be the only one being able to do this call: DRM_IOCTL_MODE_SETCRTC - set CRTC parameters (which i assume is set the mode, associat crtc-output and set framebuffer) Other call can be made by any others client: - DRM_IOCTL_MODE_ADDFB - add a new FB object - DRM_IOCTL_MODE_RMFB - remove an FB object - DRM_IOCTL_MODE_GETFB - get info about an FB object ... In order to make this possible pinning a buffer will be done in SETCRTC in which a FB that can fit the mode must be given. Thus ADDFB will create a buffer but not pinned until used for scan out, so pinning happen in SETCRTC. Note that each client does not necessarily create its own framebuffer. The idea behind this is that we can have a daemon (one for each card or one for all of them) and this daemon can take framebuffer from client and easily change btw scan out buffer (switching from X to console will be made by the daemon and X might just not be aware of this). There is other use case one can come up with such scheme like developping EGL app under X and display its framebuffer by using it as a texture in a GL app. So there is master (big boss of crtcs) and client or slave humble provider of framebuffer. One point that might be also usefull is relation btw client should we do somethings like parent/child ? So this might looks like this (left are parent) master (big boss) - X server (got its framebuffer) - X application - sub GL window of this application (might want to have its framebuffer) - GL application (dri) client running X application (got its framebuffer which can used as a texture by the compositor, hello redirected direct rendering :)) - EGL program (got its framebuffer) - Console (got its framebuffer) - GL app offscreen rendering (no framebuffer for scanout) The idea behind this is that parent can use any object created by their child in anyway they like (this why we call them parent as parent always play with toy created by their child :o)). Maybe parent could also put restriction on what their child can do (which is another characteristics of parents). If people are happy with this i will update the wiki. Cheers, Jerome Glisse - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
On 02/08/07, Jerome Glisse [EMAIL PROTECTED] wrote: Jesse Barnes wrote: I finally found some time to create a new wiki page for all the modesetting/configuration related DRM enhancements we've been talking about: http://dri.freedesktop.org/wiki/DrmModesetting Please take a look and let me know what you think. I still have to go through all the feedback I received from the lkml post I made awhile back, and make sure it's captured (I think it is, albeit at a fairly high level mostly), and add more detail in the design and development sections. Jakub, hopefully you can go over it and add more detail about the userland APIs? Dave and Keith, we talked about the new device node scheme awhile back, but I only have notes on what the master node should be responsible for, did we have any new ioctls for the slave nodes? Ring buffer mapping, etc. should probably be there? Thanks, Jesse This time i do not hijack the thread :) So we just discussed with Jakob and Jesse on this on irc and here is what i believe we agreed on: I don't agree with everything but the general idea is a good one. There should be master (possibly one for each card) which be the only one being able to do this call: DRM_IOCTL_MODE_SETCRTC - set CRTC parameters (which i assume is set the mode, associat crtc-output and set framebuffer) Other call can be made by any others client: - DRM_IOCTL_MODE_ADDFB - add a new FB object - DRM_IOCTL_MODE_RMFB - remove an FB object - DRM_IOCTL_MODE_GETFB - get info about an FB object ... I don't feel it is necessary for the clients to be able to create a framebuffer, why, because from the kernel standpoint where the said object will live, it will only be a small container containing the buffer object(s), a list of crtc that is using the buffer object(s) as a scanout buffer and the information about its size and format. Read below for more. In order to make this possible pinning a buffer will be done in SETCRTC in which a FB that can fit the mode must be given. Thus ADDFB will create a buffer but not pinned until used for scan out, so pinning happen in SETCRTC. Note that each client does not necessarily create its own framebuffer. The idea behind this is that we can have a daemon (one for each card or one for all of them) and this daemon can take framebuffer from client and easily change btw scan out buffer (switching from X to console will be made by the daemon and X might just not be aware of this). There is other use case one can come up with such scheme like developping EGL app under X and display its framebuffer by using it as a texture in a GL app. So there is master (big boss of crtcs) and client or slave humble provider of framebuffer. One point that might be also usefull is relation btw client should we do somethings like parent/child ? So this might looks like this (left are parent) master (big boss) - X server (got its framebuffer) - X application - sub GL window of this application (might want to have its framebuffer) - GL application (dri) client running X application (got its framebuffer which can used as a texture by the compositor, hello redirected direct rendering :)) - EGL program (got its framebuffer) - Console (got its framebuffer) - GL app offscreen rendering (no framebuffer for scanout) The idea behind this is that parent can use any object created by their child in anyway they like (this why we call them parent as parent always play with toy created by their child :o)). Maybe parent could also put restriction on what their child can do (which is another characteristics of parents). So why shouldn't the clients be able to creating framebuffer, because its only needed for in the kernel for setting the mode and for creating virtual dev nodes. That is its only used in the cases: User - /dev/dri/0fb1 - crtc/output User - /dev/dri/0fb2 - virtual It should not be used for passing around information to and from clients and sub clients. A framebuffer (the kernel side object) is not needed for offscreen rendering in theory only a BufferObject is needed for that and the userspace api can transmit the needed information between the different clients and sub client. IE: X the server is the client and a gl app rendering to a opengl framebuffer. This can be handled by a userspace API that is above/below the kernel sphere of interest. If people are happy with this i will update the wiki. Cheers, Jerome Glisse - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net
Re: DRM enhancements document
Well ain't I'm rude not signing off :) Cheers Jakob Wlallbraker Bornecrekrantz. I just about can't do anything right to day :) Cheers Jakob. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
I don't agree with everything but the general idea is a good one. There should be master (possibly one for each card) which be the only one being able to do this call: DRM_IOCTL_MODE_SETCRTC - set CRTC parameters (which i assume is set the mode, associat crtc-output and set framebuffer) Other call can be made by any others client: - DRM_IOCTL_MODE_ADDFB - add a new FB object - DRM_IOCTL_MODE_RMFB - remove an FB object - DRM_IOCTL_MODE_GETFB - get info about an FB object ... I don't feel it is necessary for the clients to be able to create a framebuffer, why, because from the kernel standpoint where the said object will live, it will only be a small container containing the buffer object(s), a list of crtc that is using the buffer object(s) as a scanout buffer and the information about its size and format. Read below for more. In order to make this possible pinning a buffer will be done in SETCRTC in which a FB that can fit the mode must be given. Thus ADDFB will create a buffer but not pinned until used for scan out, so pinning happen in SETCRTC. Note that each client does not necessarily create its own framebuffer. The idea behind this is that we can have a daemon (one for each card or one for all of them) and this daemon can take framebuffer from client and easily change btw scan out buffer (switching from X to console will be made by the daemon and X might just not be aware of this). There is other use case one can come up with such scheme like developping EGL app under X and display its framebuffer by using it as a texture in a GL app. So there is master (big boss of crtcs) and client or slave humble provider of framebuffer. One point that might be also usefull is relation btw client should we do somethings like parent/child ? So this might looks like this (left are parent) master (big boss) - X server (got its framebuffer) - X application - sub GL window of this application (might want to have its framebuffer) - GL application (dri) client running X application (got its framebuffer which can used as a texture by the compositor, hello redirected direct rendering :)) - EGL program (got its framebuffer) - Console (got its framebuffer) - GL app offscreen rendering (no framebuffer for scanout) The idea behind this is that parent can use any object created by their child in anyway they like (this why we call them parent as parent always play with toy created by their child :o)). Maybe parent could also put restriction on what their child can do (which is another characteristics of parents). So why shouldn't the clients be able to creating framebuffer, because its only needed for in the kernel for setting the mode and for creating virtual dev nodes. That is its only used in the cases: User - /dev/dri/0fb1 - crtc/output User - /dev/dri/0fb2 - virtual It should not be used for passing around information to and from clients and sub clients. A framebuffer (the kernel side object) is not needed for offscreen rendering in theory only a BufferObject is needed for that and the userspace api can transmit the needed information between the different clients and sub client. IE: X the server is the client and a gl app rendering to a opengl framebuffer. This can be handled by a userspace API that is above/below the kernel sphere of interest. If people are happy with this i will update the wiki. Cheers, Jerome Glisse Well ain't I'm rude not signing off :) Cheers Jakob Wlallbraker Bornecrekrantz. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
Jakob Bornecrantz wrote: There should be master (possibly one for each card) which be the only one being able to do this call: DRM_IOCTL_MODE_SETCRTC - set CRTC parameters (which i assume is set the mode, associat crtc-output and set framebuffer) Other call can be made by any others client: - DRM_IOCTL_MODE_ADDFB - add a new FB object - DRM_IOCTL_MODE_RMFB - remove an FB object - DRM_IOCTL_MODE_GETFB - get info about an FB object ... I don't feel it is necessary for the clients to be able to create a framebuffer, why, because from the kernel standpoint where the said object will live, it will only be a small container containing the buffer object(s), a list of crtc that is using the buffer object(s) as a scanout buffer and the information about its size and format. Read below for more. The reasons why i wanted to expose frame buffer to client is because there is constraint to a frame buffer and this depend on the card, and if you want to take advantage of card you likely will want to follow this constraint when rendering. For instance if you got a card capable of supporting tiles you will want to render to a tiled buffer, i don't think this is easy to expose this to the client when creating a BO as BO are generic and can be used for vertex, or others data. In fact i do see a framebuffer as a special instance of BO which follow constraint of the card for rendering, we maybe can even force all rendering to happen into framebuffer (or others name if that's what matter). This way you know that you follow card constraints (tiles, stride size, alignement, component separation, ) If we force all rendering to happen into framebuffer then each client can either have its own or a part of another framebuffer (X client got a part of another if no compositing). So to resume having framebuffer might let us put specificity of memory layout, needed for efficient GPU rendering, into the kernel. We can let each driver accept additional parameter on ADDFB to tweak this (force tile off/on, RGB16, RGB32, ...). And also provide additional function for framebuffer addressing (like get pixel, get area, set pixel, set area) i believe fb driver expose such function and i believe this make writting console driver easier. Also, this way one can wrote a dumb app for any card which is graphical and don't have any dependency. It also make coding GL driver easier as you basicly use framebuffer (with associated Z/stencil buffer) from the kernel side and then you only matter on creating command stream not on how you should arrange things in memory. But maybe you still need anyway to put this knowledge into the driver (texture tiling, cube map specific memory organization, ...). Oh and as each client can carry its frame buffer(s) and it can believe being displayed while maybe somethings else is scanned out. Client are not aware of sharing the card the believe they own it and don't need to ask for a slice of a common frame buffer. That just might be given the chance of being scanout like they just might be never displayed (i am sure some one want to play quake without even seeing the screen ;)). I believe this make card virtualization total as the master will be in control and have the possibility to choose between each card available frame buffer, this can also help for instance when transitioning from fullscreen game to windowed without changing anythings. Hope some of arguments make sense :) and that i explained properly why i think putting all framebuffer layout specificity knowledge into kernel sounds better to me. Cheers, Jerome Glisse - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 11386] Small Error when i try to load a game called Tibia
http://bugs.freedesktop.org/show_bug.cgi?id=11386 [EMAIL PROTECTED] changed: What|Removed |Added Priority|high|medium --- Comment #2 from [EMAIL PROTECTED] 2007-08-02 18:45 PST --- would you please update the test result with Mesa 7.0? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
