[Bug 17054] New: mesa/drm: compilation broken for i915 module with 2.6. 26 kernel
http://bugs.freedesktop.org/show_bug.cgi?id=17054 Summary: mesa/drm: compilation broken for i915 module with 2.6.26 kernel Product: DRI Version: XOrg CVS Platform: All OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM modules AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] When compiling the current git HEAD of mesa/drm I get the following compilation error with gcc 4.3.1 (64-bit) on linux 2.6.26: drm/linux-core/i915_gem_tiling.c: In function ‘i915_gem_detect_bit_6_swizzle’: drm/linux-core/i915_gem_tiling.c:118: error: implicit declaration of function ‘pci_read_base’ According to Shuang He (intel, http://lists.freedesktop.org/archives/xorg/2008-August/037917.html) some patches contained in Eric Anholts kernel tree (git://people.freedesktop.org/~anholt/linux-2.6 drm-gem-merge) are needed. -- 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 the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 11291] 2.6.27-rc2: laptop freezes as soon as starting video playback
http://bugzilla.kernel.org/show_bug.cgi?id=11291 --- Comment #2 from [EMAIL PROTECTED] 2008-08-10 10:48 --- Jesse, I am sorry, I cannot reproduce it. I tried with x11, xv, gl, gl2 and all worked ok. I do not know what can have happened, but I am sure that it happened three times in a row yesterday, with the same kernel. You can mark the bug as invalid if you like, if I can trigger it again I will re-open it. -- Configure bugmail: http://bugzilla.kernel.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 the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 11291] 2.6.27-rc2: laptop freezes as soon as starting video playback
http://bugzilla.kernel.org/show_bug.cgi?id=11291 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |REJECTED Resolution||UNREPRODUCIBLE -- Configure bugmail: http://bugzilla.kernel.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 the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 11291] 2.6.27-rc2: laptop freezes as soon as starting video playback
http://bugzilla.kernel.org/show_bug.cgi?id=11291 [EMAIL PROTECTED] changed: What|Removed |Added Status|REJECTED|CLOSED -- Configure bugmail: http://bugzilla.kernel.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 the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Backing out DRI2 from server 1.5
On Mon, Aug 11, 2008 at 5:46 AM, Kristian Høgsberg [EMAIL PROTECTED] wrote: On Sat, Aug 9, 2008 at 7:28 PM, Dave Airlie [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 2:23 AM, Kristian Høgsberg [EMAIL PROTECTED] wrote: On Tue, Aug 5, 2008 at 10:42 AM, Michel Dänzer [EMAIL PROTECTED] wrote: Hi Kristian, On Tue, 2008-08-05 at 21:01 +1000, Dave Airlie wrote: On Tue, Aug 5, 2008 at 5:39 PM, Alan Hourihane [EMAIL PROTECTED] wrote: On Mon, 2008-08-04 at 17:20 -0400, Kristian Høgsberg wrote: Since it looks like we'll be going with GEM for the memory manager, I'll have to revisit some of the DRI2 design decisions. As a first step, I want to back out the DRI2 stuff from the 1.5 X server entirely, since it uses TTM API for creating and mapping the DRI2 sarea. We're in feature freeze with 1.5 and I won't be able to update it in time anyway, so the best option is to just back it out instead of releasing a server with modules expecting an API that was never released. GEM is currently Intel specific. It seems as though the memory managers are going to be driver specific at this time, so we can't have the Xserver relying on a specific one. Maybe we should have some callbacks to the driver for DRI2 specific handling ? I think that is the current plan, the shared area for DRI2 will be an shm object independent of memory manager. everything else will be 32-bit handles. Has any of this been done yet anywhere? I need memory manager agnostic DRI2 for a project I'm working on, so I thought we should at least exchange ideas for the direction to take. I've just started to look into this again, and while the main change I want to do is to make it memory manager agnostic, there's a couple of other things I'd like to change at this point: 1) with DRI2. I kept the buffer swap in the client since I didn't want to incur a server request to do this. This decision meant that we had to keep much of the complexity for synchronizing clip rects between server and DRI clients in place. What I realized in the mean time is that we always send a few requests to post damage after each swap buffer, so introducing a DRI2 request to do swap buffers and post damage shouldn't affect performance but will make everything much simpler. This will also eliminate the need for the DRI lock, which for DRI2 was only used to synchronize access to cliprects. 2) Now that we don't need to communicate cliprects to the DRI clients, the somewhat complex DRI2 sarea and event buffer becomes a little harder to justify as we only use this to detect changes in attached buffers. George's swrast DRI driver uses a simpler approach there: he hooks the dd_function_table::Viewport function and asks the loader for the drawable size. I'd like to do something similar for DRI2, which will completely eliminate the need for the sarea. The DRI2 DRI driver will ask the loader (libGL, which will forward the query over protocol or AIGLX, which will ask the DRI2 module directly) for the dimensions and memory manager buffers backing the current drawable. This costs a roundtrip, but this was part of the old design too and inherent in GLX, in that multiple DRI clients need to agree on the memory manager buffers backing the aux renderbuffers. Thus you need to go to the X server one way or the other. 3) Let the DDX driver allocate the auxillary buffers. I went back and forth on this a bit and in some sense it's an arbitrary decision: both the DDX and the DRI drivers know enough about the hardware to allocate buffers with the right stride/tile/etc properties. Doing it in the DDX means that the DRI driver need to tell the DDX driver what buffers to allocate (using the DRI2CreateWindow), but on the other hand it avoids tricky allocation races with multiple DRI clients rendering to the same drawable. And without the sarea, doing it in the client would incur an extra round trip: you would first have to ask the server about the drawable size, then allocate and tell the server about the buffers you allocated. This lets the DDX driver implement special cases such as allocating a full screen back buffer that has the right properties to be used as a scan out buffer for page flip cases. Which in turn becomes a lot simpler when the buffer flip happens in the X server. And for redirected windows, the back buffer can be another pixmap so that buffer flips can be implemented as setting a different window pixmap. This all sounds like a lot of work, but it's mostly simplifications and I expect to make some good progress towards it this week. In the mean time I'll drop the dri2 bits from the xserver 1.5 and mesa 7.1 branches. How are we communicating information like tiling properties of buffers between DDX and DRI clients now? These are driver specific properties and usually the sarea was used. For example radeon can change the tiling property of the front buffer if the mode
Re: Backing out DRI2 from server 1.5
On Sun, Aug 10, 2008 at 5:07 PM, Dave Airlie [EMAIL PROTECTED] wrote: On Mon, Aug 11, 2008 at 5:46 AM, Kristian Høgsberg [EMAIL PROTECTED] wrote: My plan is to included a device specific 32 bit bitfield per buffer in the reply to DRI2Getbuffers, which is what the client calls to ask the server for buffer info. These bits can indicate properties such as tiling. In the DRI2Connect call, I'm sending back the DDX version, so the DRI driver will know which bits are valid. I actually meant to cc the lists on this, I dislike device specific limited allocation bitfields as an API in general, can we add something with a pointer or length + array? I debated whether to just use a bitfield or send along an arbitrary sized device private block. What's a little tricky about an opaque block is that we can't byteswap it in the protocol; we don't need that, of course, but it just feels a little icky. More to the point, I could not come up with anything that would require more than just a few bits, and always including this bit field makes a lot of common cases much easier - tiling, interlacing, swizzling... I dunno? What else might there be? We can add another request if there ever is a need for more data. Kristian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 1/1] Adapt on_each_cpu
On 8/2/08, Jerome Glisse [EMAIL PROTECTED] wrote: I might be totaly wrong so feel free to ignore these. I got the feeling that the user test base on linux kernel is far bigger than ours. Also i think that our test user base are people wanting lastest things with old kernel, while i understand that (building kernel is not fun on my ram slim computer) i think this end up being a burden to us. So in the end i think we should be better off with linux development tree where dev know the deadline to get feature in. I got the feeling that this way we could drive development on features basis like getting vblank rework done for a given kernel release and so get dev to focus more on some features and get them done in a timely fashion. This way we could avoid to get some new feature to rot a bit in the drm tree because. Also i think the linux-next or other linux bleeding edge tree would give us lot more tester with a lot more experience on good bug report that our current test base (i am not saying that we have bad tester, we have some very good one too which we should give credits, just that we might be able to get more of them). Judging by the current trend (where we see lots of people reporting the recent shmem_file_setup breakage because they tried to load git drm on a non-tip kernel), we have a lot of testers that don't run latest kernels but still get drm git. So the argument of more testers may not be true. Now that I think about it, is there a way with git to : 1. have a single main drm branch (that is, keep drm git the way it is right now) 2. inside this branch, maintain a number of changesets (each of those changesets would be an in-development feature). It seems to me we'd get the best of both worlds that way; the changesets would let us submit features upstream easily, and no push/pull would be needed to update all the repos. Seeing how most drm developments do not overlap, requiring explicit pull/pushes with merges sounds more complex than it needs to be. Now I'm not sure if it's possible, but at least I don't see a technical reason this wouldn't. Stephane - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Backing out DRI2 from server 1.5
On Sun, 2008-08-10 at 19:11 -0400, Kristian Høgsberg wrote: On Sun, Aug 10, 2008 at 5:07 PM, Dave Airlie [EMAIL PROTECTED] wrote: On Mon, Aug 11, 2008 at 5:46 AM, Kristian Høgsberg [EMAIL PROTECTED] wrote: My plan is to included a device specific 32 bit bitfield per buffer in the reply to DRI2Getbuffers, which is what the client calls to ask the server for buffer info. These bits can indicate properties such as tiling. In the DRI2Connect call, I'm sending back the DDX version, so the DRI driver will know which bits are valid. I actually meant to cc the lists on this, I dislike device specific limited allocation bitfields as an API in general, can we add something with a pointer or length + array? There are so many possibilities here. I'd rather see something that didn't require a secret agreement between the server and client though. That seems prone to versioning failures. One answer would be to have a version number and then a random collection of bytes; that at least would let us change the encoding in a reasonably compatible fashion. Another alternative is a sequence of name/value pairs, where each value was a homogenous array of values. A third alternative is to have driver-specific requests to return this kind of data. That would let us completely document what was on the wire, although it would consume one request ID for each driver. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 16157] [i965] glean/glsl1 run abort
http://bugs.freedesktop.org/show_bug.cgi?id=16157 haihao [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #12 from haihao [EMAIL PROTECTED] 2008-08-10 20:10:13 PST --- It has been fixed. See a3024caff1c790cf9f24476926aa62198f1e7b53 and c20a1736566d301f38cc1271284b1fde9adb2741 -- 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. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel