On Thu, 2008-02-14 at 08:50 +0200, Daniel Stone wrote:
> On Thu, Feb 14, 2008 at 03:38:45PM +0900, José Fonseca wrote:
> > 3. Using scons, enhance the build system to support all platforms we are
> > interested (i.e., linux and win32, atm),
>
> http://lwn.net/Articles/188693/
>
> 'There were ma
On Thu, 2008-02-14 at 06:46 +, Dave Airlie wrote:
> Okay please Shift-reload :0
>
> http://dri.freedesktop.org/wiki/DRMRedesign
>
> nice new picture and new text to go with it..
Any idea if we can wrap legacy DRI users in a separate 'rendering
context' so that you can run old and new X serv
On Thu, 2008-02-14 at 01:50 -0500, Alex Deucher wrote:
> 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
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
On Thu, Feb 14, 2008 at 03:38:45PM +0900, José Fonseca wrote:
> 3. Using scons, enhance the build system to support all platforms we are
> interested (i.e., linux and win32, atm),
http://lwn.net/Articles/188693/
'There were major problems building KDE on non-Linux platforms with
SCons (e.g. on
Okay please Shift-reload :0
http://dri.freedesktop.org/wiki/DRMRedesign
nice new picture and new text to go with it..
This is mostly from talking to marcheu and jbarnes and krh at
various points today, no code yet :)
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / a
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
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
http://bugs.freedesktop.org/show_bug.cgi?id=13837
Zou Nan hai <[EMAIL PROTECTED]> changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolu
http://bugs.freedesktop.org/show_bug.cgi?id=13837
--- Comment #4 from Zou Nan hai <[EMAIL PROTECTED]> 2008-02-13 17:39:22 PST ---
Thanks Eric,
writemask is not working in align_1 mode, that is why fog is broken.
Fixed in mesa commit 08fd2488b011db78ebf7eafbf6ea61d5444ffe7c
--
Configure bu
http://bugs.freedesktop.org/show_bug.cgi?id=14344
Michael Fu <[EMAIL PROTECTED]> changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolut
http://bugs.freedesktop.org/show_bug.cgi?id=14344
--- Comment #3 from Zou Nan hai <[EMAIL PROTECTED]> 2008-02-13 17:22:24 PST ---
I have check the lastest version.
Quake 4 is working on my machine, please verify.
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
---
On 2/14/08, Stephane Marchesin <[EMAIL PROTECTED]> wrote:
> > I don't know if it interferes, but I also can't see how your proposal deals
> > with this case. Can you provide more details? Just saying a BO has scanout
> > permission isn't sufficient either, since CRTC<->output mappings are
> > imp
On 2/14/08, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> On Wednesday, February 13, 2008 3:55 pm Stephane Marchesin wrote:
> > > You don't want any application to be able to change CRTC<->output
> > > mappings, or bind BOs to CRTCs. Ideally you'd just have one app that
> > > could do that on a given
On Wednesday, February 13, 2008 3:55 pm Stephane Marchesin wrote:
> > You don't want any application to be able to change CRTC<->output
> > mappings, or bind BOs to CRTCs. Ideally you'd just have one app that
> > could do that on a given system, and it would contain the distribution's
> > policy r
On Feb 13, 2008 4:28 AM, 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/DRMRede
On 2/13/08, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> On Wednesday, February 13, 2008 2:22 pm Stephane Marchesin 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-s
On Wed, Feb 13, 2008 at 11:22:10PM +0100, Stephane Marchesin wrote:
> 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.
Er, you mean /d
On Wednesday, February 13, 2008 2:22 pm Stephane Marchesin 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
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
On Wednesday, February 13, 2008 1:28 am Dave Airlie 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
>
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 ste
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 unsynch
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 mes
http://bugs.freedesktop.org/show_bug.cgi?id=14478
Summary: kernel panic on Unichrome upon startx
Product: DRI
Version: XOrg CVS
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: blocker
Priority: hi
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
26 matches
Mail list logo
