Re: redesigning the DRM internal logic..
> > Any idea if we can wrap legacy DRI users in a separate 'rendering > context' so that you can run old and new X servers/DRI clients in > different sessions? I'm thinking the exclusive nature will make some > application compatibility harder (app 'Q' runs only on old DRI, app 'R' > runs only on new DRI. Pain). to quote ajax: http://people.freedesktop.org/~ajax/fennec-fox.jpg or this isn't about choice. or no. If you can clarify exactly what you mean by DRI clients (i.e. mesa itself or GL apps on top of Mesa), old X server (i.e. what we have now.. or modesetting or TTM etc..), we might be able to find a point of usefulness, like we can run old X servers on cards that don't support this stuff hence the legacy node will always be there.. > > Also, it seems like we can support legacy fbdev clients by creating > suitable controls that create and modify fbdev devices, and potentially > even have the system create a default fbdev device at boot time to stick > the console in. > fbdev will probably look like it does now in the modesetting tree mainly, hopefully someone does a userspace console at some point... but fbdev would have a BO for its front buffer and one per set of outputs would exist, so the control node splitting out crtcs and outputs would give you an fbdev per crtc.. otherwise cloned fbdev.. Dave. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Gallium code reorganization
José Fonseca wrote: > I'll dedicate some time now to reorganize gallium's code & build process. > This is > stuff which has been discussed internally at TG several times, but this time I > want to get it done. > > My objectives are: > - leaner and more easy to understand/navigate source tree > - reduce (or even eliminate) merges between private branches of the common > gallium parts > - help keep the gallium tree portable, by keeping things separate. > > My plan is: > > 1. Physically separate gallium source code from mesa code. This will be the > final layout: > > - src/mesa > - src/gallium > - state_tracker > - ogl > - ... I think the one thing I'd say is that the GL state tracker is really a part of Mesa -- it's effectively a Mesa driver which targets the Gallium interfaces rather than some piece of hardware. Given that the gallium interface is fairly water-tight (ie. you can't reach round it to some driver internals) compared to the Mesa driver interface which is basically "just include all the mesa internal headers", I think it will become clear if you try and do this that the state_tracker will sit pretty uncomfortably anywhere other than inside mesa... I think further if you consider future 'state trackers', most of them won't really belong inside a gallium tree either. For instance if we did a GL3 implementation that targeted Gallium as its driver interface, there would not really be any distinct state tracker component - you'd just have the OpenGL3 core emitting Gallium calls directly. I think we'll end up with things like the Mesa state tracker where we're integrating with existing environments - mesa being the prototype. In general these things are best considered as clients of Gallium, rather than parts of Gallium itself. Keith - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: redesigning the DRM internal logic..
Alex Deucher wrote: > On Feb 13, 2008 9:09 PM, Keith Packard <[EMAIL PROTECTED]> wrote: >> On Wed, 2008-02-13 at 19:22 -0500, Alex Deucher wrote: >> >>> How about a "compat" node for old clients and a "new" render node that >>> handles both new clients and GPGPU? Then the backwards compat stuff >>> could just be a shim layer and everything else could use the same code >>> instead of dealing with separate render and gpgpu nodes. >> Recall that one of the goals is to support multiple user sessions >> running at the same time, so we really do want to have per-session >> 'devices' which relate the collection of applications running within >> that session and reflect the access permissions of the various objects >> and methods within that session. >> >> Any 'compat' node would eventually have to deal with this new >> environment, and I'm not sure it's entirely practical, nor do I think it >> entirely necessary. >> >> As for GPGPU usage, that would presumably look an awful lot like a >> separate session, although I can imagine there being further limits on >> precisely which operations a GPGPU application could perform. > > I guess I just don't see a difference between X/DRI rendering and > GPGPU; it's just command submission. It seems like the only reason > for the render/gpgpu split is for backwards compatibility. I think we > need to differentiate between display and rendering rather than > "visual" rendering and compute applications. Yes, though maybe GPGPU is just a convenient phrase for 'rendering facility divorced from display'. I'm not sure. There are real cases where you want to render images yet never have an interest in display - for example scientific visualization and gpu-accelerated offline rendering. From the point of view of the DRM, these should fall into the same bucket as GPGPU. Keith - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14497] New: DRI support on video card damaged
http://bugs.freedesktop.org/show_bug.cgi?id=14497 Summary: DRI support on video card damaged Product: DRI Version: XOrg CVS Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: General AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] My video card (ati radeon mobility 9700) is unable to use DRI altough it worked before. That happened just after some toying with compiz-fusion under Fedora 8. To make that clear, I had perfect 3D support (DRI, 3D, compiz, ...) on Ubuntu and Fedora 8 but now it's gone. I already started two independent LiveCDs (again Fedora and Ubuntu), they have the same symptoms (Both where ok before, from the first I installed successfully my current Fedora installation, the second one is half a year old and worked perfect also). When starting Xorg it crashes 10 to 40 seconds after GDM started (sometimes while in GDM, sometimes on GNOME desktop). Using everything works just fine. I believe that somehow my video card bios was damaged (I have no explanation for the LiveCD crashes). A more in-depth explanation with Xorg.0.log and stuff (which I don't want to copy-paste) can be found here: http://forums.fedoraforum.org/showthread.php?s=f2872bb370551429f65210371eb3a4bc&p=962682#post962682 The question is in how far the video card can be affected by drivers/compiz/mesa and what tools are available to check that. Maybe I should add that playing 3D games with Windows XP (on the same machine) works perfectly well, so the card itself is not necessarily damaged. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14497] DRI support on video card damaged
http://bugs.freedesktop.org/show_bug.cgi?id=14497 --- Comment #1 from Adam K Kirchhoff <[EMAIL PROTECTED]> 2008-02-14 02:50:27 PST --- The only log file in that thread is with the fglrx driver. While you may not get direct rendering with the open source driver either, we'd need to actually see a log file while using the open source driver to try to identify the problem. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14497] DRI support on video card damaged
http://bugs.freedesktop.org/show_bug.cgi?id=14497 --- Comment #2 from Sascha Peilicke <[EMAIL PROTECTED]> 2008-02-14 03:04:15 PST --- Created an attachment (id=14305) --> (http://bugs.freedesktop.org/attachment.cgi?id=14305) /var/log/dmesg -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14497] DRI support on video card damaged
http://bugs.freedesktop.org/show_bug.cgi?id=14497 --- Comment #3 from Sascha Peilicke <[EMAIL PROTECTED]> 2008-02-14 03:04:53 PST --- Created an attachment (id=14306) --> (http://bugs.freedesktop.org/attachment.cgi?id=14306) /var/log/Xorg.0.log -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Gallium code reorganization
On 2/14/08, Keith Whitwell <[EMAIL PROTECTED]> wrote: > José Fonseca wrote: > > I'll dedicate some time now to reorganize gallium's code & build process. > This is > > stuff which has been discussed internally at TG several times, but this > time I > > want to get it done. > > > > My objectives are: > > - leaner and more easy to understand/navigate source tree > > - reduce (or even eliminate) merges between private branches of the > common gallium parts > > - help keep the gallium tree portable, by keeping things separate. > > > > My plan is: > > > > 1. Physically separate gallium source code from mesa code. This will be the > > final layout: > > > > - src/mesa > > - src/gallium > > - state_tracker > > - ogl > > - ... > > > I think the one thing I'd say is that the GL state tracker is really a > part of Mesa -- it's effectively a Mesa driver which targets the Gallium > interfaces rather than some piece of hardware. > > Given that the gallium interface is fairly water-tight (ie. you can't > reach round it to some driver internals) compared to the Mesa driver > interface which is basically "just include all the mesa internal > headers", I think it will become clear if you try and do this that the > state_tracker will sit pretty uncomfortably anywhere other than inside > mesa... So src/mesa/driver/state_tracker then? > I think further if you consider future 'state trackers', most of them > won't really belong inside a gallium tree either. For instance if we > did a GL3 implementation that targeted Gallium as its driver interface, > there would not really be any distinct state tracker component - you'd > just have the OpenGL3 core emitting Gallium calls directly. > > I think we'll end up with things like the Mesa state tracker where we're > integrating with existing environments - mesa being the prototype. > > In general these things are best considered as clients of Gallium, > rather than parts of Gallium itself. My perspective was that gallium implements several APIs, and Mesa is an implementation detail of one of them. Jose - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14497] DRI support on video card damaged
http://bugs.freedesktop.org/show_bug.cgi?id=14497 --- Comment #4 from Sascha Peilicke <[EMAIL PROTECTED]> 2008-02-14 03:06:05 PST --- Created an attachment (id=14307) --> (http://bugs.freedesktop.org/attachment.cgi?id=14307) /var/log/messages -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14497] DRI support on video card damaged
http://bugs.freedesktop.org/show_bug.cgi?id=14497 --- Comment #5 from Sascha Peilicke <[EMAIL PROTECTED]> 2008-02-14 03:06:41 PST --- Sorry, those are the logfiles generated when booting with the "radeon" driver. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14497] DRI support on video card damaged
http://bugs.freedesktop.org/show_bug.cgi?id=14497 Sascha Peilicke <[EMAIL PROTECTED]> changed: What|Removed |Added Attachment #14306|application/octet-stream|text/plain mime type|| -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14497] DRI support on video card damaged
http://bugs.freedesktop.org/show_bug.cgi?id=14497 Sascha Peilicke <[EMAIL PROTECTED]> changed: What|Removed |Added Attachment #14305|application/octet-stream|text/plain mime type|| -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14497] DRI support on video card damaged
http://bugs.freedesktop.org/show_bug.cgi?id=14497 Sascha Peilicke <[EMAIL PROTECTED]> changed: What|Removed |Added Attachment #14307|application/octet-stream|text/plain mime type|| -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Gallium code reorganization
On Thu, 2008-02-14 at 20:05 +0900, José Fonseca wrote: > On 2/14/08, Keith Whitwell <[EMAIL PROTECTED]> wrote: > > José Fonseca wrote: > > > > > > 1. Physically separate gallium source code from mesa code. This will be > > the > > > final layout: > > > > > > - src/mesa > > > - src/gallium > > > - state_tracker > > > - ogl > > > - ... > > > > > > I think the one thing I'd say is that the GL state tracker is really a > > part of Mesa -- it's effectively a Mesa driver which targets the Gallium > > interfaces rather than some piece of hardware. > > > > Given that the gallium interface is fairly water-tight (ie. you can't > > reach round it to some driver internals) compared to the Mesa driver > > interface which is basically "just include all the mesa internal > > headers", I think it will become clear if you try and do this that the > > state_tracker will sit pretty uncomfortably anywhere other than inside > > mesa... > > So src/mesa/driver/state_tracker then? src/mesa/driver/gallium ? -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Gallium code reorganization
Michel Dänzer wrote: > On Thu, 2008-02-14 at 20:05 +0900, José Fonseca wrote: >> On 2/14/08, Keith Whitwell <[EMAIL PROTECTED]> wrote: >>> José Fonseca wrote: >>> > >>> > 1. Physically separate gallium source code from mesa code. This will be >>> the >>> > final layout: >>> > >>> > - src/mesa >>> > - src/gallium >>> > - state_tracker >>> > - ogl >>> > - ... >>> >>> >>> I think the one thing I'd say is that the GL state tracker is really a >>> part of Mesa -- it's effectively a Mesa driver which targets the Gallium >>> interfaces rather than some piece of hardware. >>> >>> Given that the gallium interface is fairly water-tight (ie. you can't >>> reach round it to some driver internals) compared to the Mesa driver >>> interface which is basically "just include all the mesa internal >>> headers", I think it will become clear if you try and do this that the >>> state_tracker will sit pretty uncomfortably anywhere other than inside >>> mesa... >> So src/mesa/driver/state_tracker then? > > src/mesa/driver/gallium ? The trouble with this is you now have two things in the stack which can be called 'the gallium driver', ie: GL API -- Core Mesa -- Gallium Driver (formerly State Tracker) -- Gallium API -- Gallium Driver -- Winsys, DRM, HW I'd be happy to either leave this piece out of the proposed changes for now, or to move it to mesa/drivers/state_tracker. Basically I think we have a clear idea what to do with the rest of the stack, probably we should just move ahead on that and either leave the Mesa state tracker alone or only make minimal changes to it. Leaving it out of this round of changes doesn't mean that we can't move/rename it later -- because it's a part of mesa, changing it later won't break or affect any other Gallium clients. It's really an internal matter for Mesa where that code lives & what it's called. Keith - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14497] DRI support on video card damaged
http://bugs.freedesktop.org/show_bug.cgi?id=14497 --- Comment #6 from Alex Deucher <[EMAIL PROTECTED]> 2008-02-14 06:23:59 PST --- newer versions of the raeon driver changed the default AGP mode which caused problems with some cards. I suspect that is what you are seeing. The default has since been switched back, but a lot of current distros use the interim version of the driver. One of he following options should help: Option "AGPMode" "4" Option "AGPMode" "8" Option "BusType" "PCI" -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 0/2] Keep generated glapi sources in mesa
Dan Nicholson wrote: > On Feb 13, 2008 6:48 AM, Dan Nicholson <[EMAIL PROTECTED]> wrote: >> On Feb 13, 2008 6:40 AM, Dan Nicholson <[EMAIL PROTECTED]> wrote: >>> The glapi source files for the xserver's GLX module are currently >>> generated in the mesa tree and then manually merged into the the xserver >>> tree. This step in the GLX build is error prone as the files can easily >>> become unsynchronized from the rest of the glapi in mesa. >>> >>> This patchset changes the mesa build to generate the files in a standard >>> location in the mesa tree. Likewise, the xserver glx build has the >>> necessary files symlinked in by symlink-mesa.sh at build time. >>> >>> I put the files in src/glx/x11 in mesa with the rest of the glx sources. >>> I'm not sure if this is the best place. >> Looks like the patches were too big. Here they are in cgit fashion: >> >> http://cgit.freedesktop.org/~dbn/mesa/commit/?h=xserver-glx-cleanup&id=1f0262eaa079fd1b560ba72ed963a8719bc2bfaf >> http://cgit.freedesktop.org/~dbn/xserver/commit/?h=glx-cleanup&id=5aa2e8608095bf5775de1b020591aabcb1ccc38d > > Try again. I rebased the xserver commit and hadn't pushed yet. Here's > a fresher commit id. > > http://cgit.freedesktop.org/~dbn/xserver/commit/?h=glx-cleanup&id=6dc2166651ef95efb5ff4a1118f843ee9da5b013 Looks OK to me, Dan. -Brian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14497] DRI support on video card damaged
http://bugs.freedesktop.org/show_bug.cgi?id=14497 Sascha Peilicke <[EMAIL PROTECTED]> changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #7 from Sascha Peilicke <[EMAIL PROTECTED]> 2008-02-14 09:02:41 PST --- Ok, adding did the job, it runs. I'm still confused why both LiveCDs crashed but that's another story. Thank you very much for the hot tip. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: redesigning the DRM internal logic..
On Thu, 2008-02-14 at 08:20 +, Dave Airlie wrote: > If you can clarify exactly what you mean by DRI clients (i.e. mesa itself > or GL apps on top of Mesa), old X server (i.e. what we have now.. or > modesetting or TTM etc..), we might be able to find a point of usefulness, > like we can run old X servers on cards that don't support this stuff hence > the legacy node will always be there.. Sure, the legacy node seems necessary to avoid flag day for the system. Just wanting to make sure we noted that you wouldn't be able to cleanly switch between a legacy X server and a new X server, without shutting one down before starting the other. Given the user-mode modesetting in the legacy X server, it does seem like a lot of work to get back to text mode and clear the card memory before switching. > fbdev will probably look like it does now in the modesetting tree mainly, > hopefully someone does a userspace console at some point... but fbdev > would have a BO for its front buffer and one per set of outputs would > exist, so the control node splitting out crtcs and outputs would give you > an fbdev per crtc.. otherwise cloned fbdev.. So it's all controlled from user mode. Are we going to deprecate fbdev, or do we expect system startup and the kernel graphics-mode console to sit atop it still? -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: redesigning the DRM internal logic..
On Wed, Feb 13, 2008 at 5:22 PM, Stephane Marchesin <[EMAIL PROTECTED]> wrote: > On 2/13/08, Dave Airlie <[EMAIL PROTECTED]> wrote: > > > > So I've been thinking about this stuff a lot lately wrt to getting the > > DRM into a state that enables fast-user-switching, GPGPU apps, > > different users on a per head one a single card.. > > > > http://dri.freedesktop.org/wiki/DRMRedesign > > > > has a nice picture and some notes.. either comment direct on the webpage, > > or reply here.. > > > > A lot of the code heading in this direction just got merged into > > modesetting-101, it should in theory all be backwards compat in the single > > render/master case... > > > > Hi, > > So basically, you'd expose multiple /dev entries for a single piece of > hardware. As I said on irc, this would be like exposing /dev/sda1_ext2 > and /dev/sda1_xfs and ... which obviously doesn't scale long-term. Let me remind you that /dev/sda1 and /dev/sda2 are just that - multiple dev entries for /dev/sda. The /dev/sdaX files represent the different partitions on /dev/sda not different pieces of hardware. > Lets forget about the concept of "master" for a moment. In a case > where the concept of "master" does not exist, an application that can > draw to screen (formerly "master") would simply be one that has a > scanout BO and is using it. > > So here is the point: with the current work on enforcing proper > permissions on BOs (including scanout BOs), is a separate device > really needed ? The reason for doing this device separation in the > first place basically comes down to enforcing those permissions > properly in a per-app fashion. The same effect could be achieved by > enforcing the policy on BO creation instead of device opening. The nice thing about using the device model is that it's an established mechanism, that's already implemented and currently used for many other devices. I would prefer not to invent a new permissions model. Kristian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Gallium code reorganization
On Thu, Feb 14, 2008 at 1:38 AM, José Fonseca <[EMAIL PROTECTED]> wrote: > I'll dedicate some time now to reorganize gallium's code & build process. > This is > stuff which has been discussed internally at TG several times, but this time > I > want to get it done. > > My objectives are: > - leaner and more easy to understand/navigate source tree I'm not sure what the scope of the work you're proposing here is, but to get to a leaner source tree, I would definitely recommend splitting out the libraries: glu, glut, glw. egl and even glx. Kristian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: redesigning the DRM internal logic..
Hi guys, Keith Packard escreveu: > On Wed, 2008-02-13 at 19:22 -0500, Alex Deucher wrote: > >> How about a "compat" node for old clients and a "new" render node that >> handles both new clients and GPGPU? Then the backwards compat stuff >> could just be a shim layer and everything else could use the same code >> instead of dealing with separate render and gpgpu nodes. > > Recall that one of the goals is to support multiple user sessions > running at the same time, so we really do want to have per-session > 'devices' which relate the collection of applications running within > that session and reflect the access permissions of the various objects > and methods within that session. > I'm not sure what the scope of the work you're proposing here, but in a not so long future I'll need to glue this with the VGA arbitration code [0]. We need to design something about the case where the cards generate an interrupt when the arbiter has disable MEM decoding, for instance. Someone already mentioned about implement a driver callback for disabling IRQ emission on a given card when it's being disabled by the arbiter. But I don't know for sure yet. Do you have an idea where I'll need to hook this all? Thanks, [0] http://www.x.org/wiki/VgaArbiter Anyway, this things aren't *so* updated. I have more code here synced with the master branch of X server but currently I'm fighting with some pciaccess drivers which refuse to initialize a secondary card. Sigh. -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14283] [915] HL2 under wine assertion failure 'intel->prim.primitive ! = ~0'
http://bugs.freedesktop.org/show_bug.cgi?id=14283 Eric Anholt <[EMAIL PROTECTED]> changed: What|Removed |Added Summary|Slackware 12, wine and Half-|[915] HL2 under wine |Life 2 problem |assertion failure 'intel- ||>prim.primitive != ~0' -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Gallium code reorganization
On 2/15/08, Kristian Høgsberg <[EMAIL PROTECTED]> wrote: > On Thu, Feb 14, 2008 at 1:38 AM, José Fonseca > <[EMAIL PROTECTED]> wrote: > > I'll dedicate some time now to reorganize gallium's code & build process. > This is > > stuff which has been discussed internally at TG several times, but this > time I > > want to get it done. > > > > My objectives are: > > - leaner and more easy to understand/navigate source tree > > > I'm not sure what the scope of the work you're proposing here is, but > to get to a leaner source tree, I would definitely recommend splitting > out the libraries: glu, glut, glw. egl and even glx. At some point, gallium might get its own repository and separate from mesa and the libraries you mention -- it would make all sense as Keith sees Mesa as one among many Gallium clients. But for now, I just want to reorganize the code within the same repository so that if/when that's decided, all the parts are loosely coupled to make it painless. Jose - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14507] New: 855GM Suspend bug
http://bugs.freedesktop.org/show_bug.cgi?id=14507 Summary: 855GM Suspend bug Product: Mesa Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/i915 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] Created an attachment (id=14328) --> (http://bugs.freedesktop.org/attachment.cgi?id=14328) xrandr output [EMAIL PROTECTED] ~]$ lspci | grep VGA 00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02) [EMAIL PROTECTED] ~]$ uname -m i686 [EMAIL PROTECTED] ~]$ rpm -qf /usr/lib/xorg/modules/drivers/intel_drv.so xorg-x11-drv-i810-2.1.1-7.fc8 [EMAIL PROTECTED] ~]$ uname -r 2.6.23.15-137.fc8 [EMAIL PROTECTED] ~]$ lsb_release -a LSB Version: :core-3.1-ia32:core-3.1-noarch:graphics-3.1-ia32:graphics-3.1-noarch Distributor ID: Fedora Description:Fedora release 8 (Werewolf) Release:8 Codename: Werewolf ASUS Notebook M3N (http://www.overclockers.com/articles1235/) -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14507] 855GM Suspend bug
http://bugs.freedesktop.org/show_bug.cgi?id=14507 --- Comment #1 from Alexey Kuznetsov <[EMAIL PROTECTED]> 2008-02-14 21:32:39 PST --- Created an attachment (id=14329) --> (http://bugs.freedesktop.org/attachment.cgi?id=14329) xorg.log -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14507] 855GM Suspend bug
http://bugs.freedesktop.org/show_bug.cgi?id=14507 --- Comment #2 from Alexey Kuznetsov <[EMAIL PROTECTED]> 2008-02-14 21:32:54 PST --- Created an attachment (id=14330) --> (http://bugs.freedesktop.org/attachment.cgi?id=14330) xorg.conf -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14507] 855GM Suspend bug
http://bugs.freedesktop.org/show_bug.cgi?id=14507 --- Comment #3 from Alexey Kuznetsov <[EMAIL PROTECTED]> 2008-02-14 21:33:14 PST --- Created an attachment (id=14331) --> (http://bugs.freedesktop.org/attachment.cgi?id=14331) dmesg -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14507] 855GM Suspend bug
http://bugs.freedesktop.org/show_bug.cgi?id=14507 --- Comment #4 from Alexey Kuznetsov <[EMAIL PROTECTED]> 2008-02-14 21:50:41 PST --- Created an attachment (id=14332) --> (http://bugs.freedesktop.org/attachment.cgi?id=14332) broken screen -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14507] 855GM Suspend bug
http://bugs.freedesktop.org/show_bug.cgi?id=14507 --- Comment #5 from Alexey Kuznetsov <[EMAIL PROTECTED]> 2008-02-14 21:51:11 PST --- Created an attachment (id=14333) --> (http://bugs.freedesktop.org/attachment.cgi?id=14333) normal screen -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14507] 855GM Suspend bug
http://bugs.freedesktop.org/show_bug.cgi?id=14507 Alexey Kuznetsov <[EMAIL PROTECTED]> changed: What|Removed |Added Attachment #14329|application/octet-stream|text/plain mime type|| -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
