ent, so if possible
test / let test with multiple chipsets before publishing any patches
(which are of course welcome!).
Have fun
Matthias
--
Matthias Hopf ____ __
Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [email protected]
Phone +49-911-74053-715 _
a new ioctl with a
container structure? Not that I intend to do anything TTM/GEM related
ATM, but I'm curious.
> Oh and have fun with r6xx =)
Thnx :)
Matthias
--
Matthias Hopf <[EMAIL PROTECTED]> ____ __
Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__
y stop that ;-)
> When either of those things happens a Mesa 8.0 release would probably be
> appropriate. I haven't thought about a time frame yet, but the end of
> the year might be a good goal.
Sounds good. Especially as nobody really has to wait until then to dig
into it.
Ma
le. I have deeply experienced the difference btw the
> easier to start from somethings working than to start from scratch.
Definitely. No completely new driver without using gallium. And it would
be a hard time if you didn't already know that the thing you're trying
to do actually w
already some ideas how to restructure things if necessary?
So long
Matthias
--
Matthias Hopf <[EMAIL PROTECTED]> ____ __
Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [EMAIL PROTECTED]
Phone +49-911-74053-715 __) |_|
On May 30, 08 20:43:39 +0200, Stefan Dösinger wrote:
> Am Freitag, 30. Mai 2008 19:57:32 schrieb Matthias Hopf:
> > At least on suspend to RAM many GPUs can probably be programmed to keep
> > VRAM contents alive. In that case you wouldn't have to save that data
> >
On May 31, 08 18:31:45 +0200, Jerome Glisse wrote:
> On Sat, 31 May 2008 14:53:22 +0100
> Matthew Garrett <[EMAIL PROTECTED]> wrote:
> > On Fri, May 30, 2008 at 07:57:32PM +0200, Matthias Hopf wrote:
> > > At least on suspend to RAM many GPUs can probably be programmed
hat I'm doing, so don't ensure I have backing store for VRAM allocations.
> This would never be the default.
At least on suspend to RAM many GPUs can probably be programmed to keep
VRAM contents alive. In that case you wouldn't have to save that data
as well.
Matthias
some games do that.
Games also used to use this path for mirror and distortion effects,
though nowadays FBOs are probably used in most cases.
Matthias
--
Matthias Hopf <[EMAIL PROTECTED]> ____ __
Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [EMAIL PROTECTED]
P
, strings are a completely different concept and don't
> > match well here, as pointers are probably difficult to handle over the
> > user land / kernel barrier...
>
> Easy to use, hard to use right.
Right.
Matthias
--
Matthias Hopf <[EMAIL PROTECTED]> _
ly different concept and don't
match well here, as pointers are probably difficult to handle over the
user land / kernel barrier...
CU
Matthias
--
Matthias Hopf <[EMAIL PROTECTED]> ____ __
Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__
On Aug 20, 07 15:45:00 -0700, Keith Packard wrote:
> On Mon, 2007-08-20 at 17:27 +0200, Matthias Hopf wrote:
>
> > Because we won't get an ix86 emulator in kernel space, Linus and others
> > have been pretty clear about that. Graphics hardware sometimes needs
> > BIO
On Aug 20, 07 19:51:31 +0300, Daniel Stone wrote:
> On Mon, Aug 20, 2007 at 05:27:43PM +0200, Matthias Hopf wrote:
> > On Aug 12, 07 17:50:12 +0200, [EMAIL PROTECTED] wrote:
> > > On Thu, Aug 02, 2007 at 07:31:01PM +0200, Jerome Glisse wrote:
> > > > There should be
. Graphics chips are more complicated than any CPU on the market,
which other hardware type is similar? Even high-speed interconnects like
infiniband are trivial compared to that.
That said, I'm not 100% confident that the currently discussed way is
the right solution. OTOH I don't kno
gt; >precisely.
>
> As far as you know, does the ATI binary driver have FBO support?
It has pBuffer support, which is good enough for Xgl, if that's what
you're asking.
Matthias
--
Matthias Hopf <[EMAIL PROTECTED]> ____ __
Maxfeldstr. 5 / 90409 Nuernberg
; Would mind creating a new patch? I don't have any time to do so.
> -Brian
I know, this took much longer than it should, however, here's finnally
the updated patch.
Thanks
Matthias
--
Matthias Hopf <[EMAIL PROTECTED]> _
d what not. The chip's late
> though, we'll see.
> (is it only me or is this all "slightly" offtopic?)
Yep, let's end it now :^)
Matthias
--
Matthias Hopf <[EMAIL PROTECTED]> ____ _
's a big reason why open source r300 drivers get so much
> attention. But don't offend their chip designers :)
Yep. They used to do good hardware. Have fallen behind a bit compared to
GeForce6, but not much.
> Wladimir
> Ogre3D Team (http://www.ogre3d.
ffect kids; I mean if Pac-Man affected us as kids,
> we'd
> all be running around in darkened rooms, munching magic pills and listening to
> repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989
I hate to say it, but some seem to do ;->>>
CU
Matthias
--
> Would mind creating a new patch? I don't have any time to do so.
Sure. Just don't expect this to happen today.
I'll have a couple of other patches next week, some of which are likely
to be debatable.
Matthias
--
Matthias Hopf <[EMAIL PROTECTED]> __
> typedef GLXFBConfigSGIX fbc_t;
> #else
> typedef void *fbc_t;
> #endif
I would expect that as well. But I wanted a minimal invasive change.
Feel free to change this ;)
>
> I'd probably also replace 'fbc_t' with 'fbconfig_t' to make
Hi,
find a patch attached that fixes all remaining strict-aliasing problems
when compiling Mesa with gcc 4 (at least for me).
CU all
Matthias
--
Matthias Hopf <[EMAIL PROTECTED]>, SuSE labs, Zimmer 3.2.06, Tel. 74053-715
Index: src/glut/glx/glut_
at you need support from
the operating system that should run on Xen, and not support from the
processor. BTW, it is shipped with SuSE Linux 9.3.
Read more at
http://www.cl.cam.ac.uk/Research/SRG/netos/xen/index.html
Matthias
--
Matthias Hopf <[EMAIL PROTECTED]> ____ __
M
http://freedesktop.org/bugzilla/show_bug.cgi?id=1424
CU all
Matthias
--
Matthias Hopf <[EMAIL PROTECTED]> /-- /-- /-- [EMAIL PROTECTED]
Maxfeldstr. 5 / 90409 Nuernberg\-\ | | \-\ |-- www.mshopf.de
Phone +49-911-74053-715--/ \_/ --/
24 matches
Mail list logo
