[Bug 17054] New: mesa/drm: compilation broken for i915 module with 2.6. 26 kernel

2008-08-10 Thread bugzilla-daemon
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

2008-08-10 Thread bugme-daemon
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

2008-08-10 Thread bugme-daemon
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

2008-08-10 Thread bugme-daemon
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

2008-08-10 Thread Dave Airlie
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

2008-08-10 Thread Kristian Høgsberg
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

2008-08-10 Thread Stephane Marchesin
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

2008-08-10 Thread Keith Packard
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

2008-08-10 Thread bugzilla-daemon
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