[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=100&url=/ -- ___ 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=100&url=/-- ___ 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=100&url=/ -- ___ 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, 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=100&url=/ -- ___ 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
[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=100&url=/ -- ___ 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=100&url=/ -- ___ 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=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[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=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
