[Dri-devel] Problem with fd.o snapshots and GL since 20040304
This is about the snapshot binary incompatibility problem, with the following error messages. My personal problem is with r200, and snapshots from 20040304 onwards. libGL warning: 3D driver claims to not support visual 0x23 ... (II) RADEON(0): [drm] Could not create dummy context Sorry to repeat my earlier message (Sun, 14 Mar 2004 08:34:19 -0800), but I tought I should let you know the snapshots were still broken until at least 20040319. I know Ian Romanick thought he had fixed this, but the fix doesn't seem to have made it into the snapshots. I understand why everyone is a bit too busy to fix this problem at the moment. No hurry! I'm sorry that I can't help. - Alex --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
--- Felix Kühling <[EMAIL PROTECTED]> wrote: > This commit works fine on the ProSavage but on the SavageIX there are > two new problems. :( > > 2D performance is a lot worse now. Moving opaque windows is really > slow. > > And I get this from mplayer on movies that worked before: > > VO: [xv] 352x272 => 352x272 Planar YV12 > X11 error: BadAlloc (insufficient resources for operation) > Sorry. I reverted a change that fixed acceleration a while back. fixed now. what's weird is that I swear I had it working fine after the changes I made, which is why I reverted it in the first place. Alex __ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: CVS Update: xc (branch: trunk)
This commit works fine on the ProSavage but on the SavageIX there are two new problems. :( 2D performance is a lot worse now. Moving opaque windows is really slow. And I get this from mplayer on movies that worked before: VO: [xv] 352x272 => 352x272 Planar YV12 X11 error: BadAlloc (insufficient resources for operation) MPlayer interrupted by signal 6 in module: flip_page - MPlayer crashed. This shouldn't happen. It can be a bug in the MPlayer code _or_ in your drivers _or_ in your gcc version. If you think it's MPlayer's fault, please read DOCS/bugreports.html and follow the instructions there. We can't and won't help unless you provide this information when reporting a possible bug. Successfully enabled DPMS Xlib: unexpected async reply (sequence 0x5a)! I'm not sure if the latter problem is really a bug since I run 1280x1024 with 8MB graphics memory. Did you allocate memory for something else that was available for Xv before? Regards, Felix On Tue, 23 Mar 2004 13:11:37 -0800 Alex Deucher <[EMAIL PROTECTED]> wrote: > CVSROOT: /cvs/dri > Module name: xc > Repository: xc/xc/programs/Xserver/hw/xfree86/drivers/savage/ > Changes by: [EMAIL PROTECTED] 04/03/23 13:11:37 > > Log message: > - re-enable AGPMode option > - add AGPSize option > - fix Xv interpolation on old streams engine > > Modified files: > xc/xc/programs/Xserver/hw/xfree86/drivers/savage/: > savage.man savage_accel.c savage_dri.c savage_driver.c > savage_driver.h savage_video.c > > Revision ChangesPath > 1.3 +12 -0 > xc/xc/programs/Xserver/hw/xfree86/drivers/savage/savage.man > 1.17 +3 -5 > xc/xc/programs/Xserver/hw/xfree86/drivers/savage/savage_accel.c > 1.3 +7 -5 > xc/xc/programs/Xserver/hw/xfree86/drivers/savage/savage_dri.c > 1.19 +36 -7 > xc/xc/programs/Xserver/hw/xfree86/drivers/savage/savage_driver.c > 1.12 +1 -0 > xc/xc/programs/Xserver/hw/xfree86/drivers/savage/savage_driver.h > 1.7 +17 -12 > xc/xc/programs/Xserver/hw/xfree86/drivers/savage/savage_video.c > > > > --- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > -- > ___ > Dri-patches mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-patches > --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Merged via.
Hi! I've now added the via drm module to cvs trunk. Files went in drm/shared, and I've modified the drm/linux Makefiles. To keep version numbers consistent with what Via has produced, this one became 1.2.0. Tagged via-1-2-0-20040323-merge Please report problems, and also please success or problems with other operating systems than linux. Regards, Thomas Hellström --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-users] Problems with savage and DRI
--- Felix Kühling <[EMAIL PROTECTED]> wrote: > On Tue, 23 Mar 2004 08:16:49 -0800 (PST) > Alex Deucher <[EMAIL PROTECTED]> wrote: > > > > > --- Felix K_hling <[EMAIL PROTECTED]> wrote: > [snip] > > > Anyway, the reason is that accelerated 3D rendering only works > with > > > tiled memory but the front buffer is linear. > > > > > > Software fallbacks draw to tiled surfaces, which map linear or > tiled > > > memory. If I understand it correctly it shouldn't make any > difference > > > whether the underlying memory is linear or tiled (as long as the > > > tiled > > > surface registers are setup correctly). > > > > That's my understanding as well, but I could be wrong. Also, > tiling > > the front buffer results in lower performance. I'm not sure why. > It > > might have just been due to the way the code was initially > architected. > > your changes to the 3d driver may have fixed that. > > Don't know which changes that would be. The only thing where the > tiling > of the front buffer would make a difference for normal double > buffered > rendering is on buffer swaps. The swapping didn't change. So possibly > blitting to a linear frame buffer is faster than blitting to a tiled > one. Anyway, from Keith's comments about double-buffered visuals > where > the app switches between rendering to front and back buffer, it > sounds > like we really want to have a tiled front buffer. I'll try and get tiling working again. > > > > > > > > > It seems that the front buffer surface uses a different line > pitch > > > than > > > the back buffer. I don't know why that is. Alex, can this be > changed > > > easily or would it require big changes in the 2D driver? > > > > The pitch is different because of alignment requirements. I think I > > tried changing the front pitch to match the others and it didn't > seem > > to break anything as I recall, so perhaps we can get away with it. > > If it really needs a different pitch it shouldn't be too hard to > adjust > savagespan.c. it should only have a different pitch if you are using linear vs. tiled for the front buffer. With a tiled front buffer the pitch should be the same. > > > Unfortunately, tiling of the front buffer broke when I ported S3's > > changes to Tim's code. I'm not sure what the problem is as the set > up > > is pretty much identical. I never really dug into it too much > since > > linear seemed to work fine for most things. However, back when we > were > > using S3's driver and tiling worked, drawing to the front buffer > was > > still broken (looked the same whether the front buffer was tiled or > > not). > > > > Alex > > > [snip] __ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-users] Problems with savage and DRI
On Tue, 23 Mar 2004 08:16:49 -0800 (PST) Alex Deucher <[EMAIL PROTECTED]> wrote: > > --- Felix K_hling <[EMAIL PROTECTED]> wrote: [snip] > > Anyway, the reason is that accelerated 3D rendering only works with > > tiled memory but the front buffer is linear. > > > > Software fallbacks draw to tiled surfaces, which map linear or tiled > > memory. If I understand it correctly it shouldn't make any difference > > whether the underlying memory is linear or tiled (as long as the > > tiled > > surface registers are setup correctly). > > That's my understanding as well, but I could be wrong. Also, tiling > the front buffer results in lower performance. I'm not sure why. It > might have just been due to the way the code was initially architected. > your changes to the 3d driver may have fixed that. Don't know which changes that would be. The only thing where the tiling of the front buffer would make a difference for normal double buffered rendering is on buffer swaps. The swapping didn't change. So possibly blitting to a linear frame buffer is faster than blitting to a tiled one. Anyway, from Keith's comments about double-buffered visuals where the app switches between rendering to front and back buffer, it sounds like we really want to have a tiled front buffer. > > > > > It seems that the front buffer surface uses a different line pitch > > than > > the back buffer. I don't know why that is. Alex, can this be changed > > easily or would it require big changes in the 2D driver? > > The pitch is different because of alignment requirements. I think I > tried changing the front pitch to match the others and it didn't seem > to break anything as I recall, so perhaps we can get away with it. If it really needs a different pitch it shouldn't be too hard to adjust savagespan.c. > Unfortunately, tiling of the front buffer broke when I ported S3's > changes to Tim's code. I'm not sure what the problem is as the set up > is pretty much identical. I never really dug into it too much since > linear seemed to work fine for most things. However, back when we were > using S3's driver and tiling worked, drawing to the front buffer was > still broken (looked the same whether the front buffer was tiled or > not). > > Alex > [snip] --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Where to put new drm module
On Tue, Mar 16, 2004 at 05:00:37PM -0800, Jon Smirl wrote: >I've started putting the DRM files into a drm module in the dri project. I'm >copying the v files so that we will maintain history. > >Imakefile isn't needed in the new scheme, right, so I don't need a copy in the >new project? > >I also thought we should move dristat.c and drmstat.c to a tests directory. > >Give it a try and tell me what it needs: >checkout drm from the dri project Jon, can you add the drm module to the 'dri' CVSup collection? It isn't currently visible there. David --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-users] Problems with savage and DRI
Keith Whitwell wrote: Brian Paul wrote: You don't have to copy from the back buffer to the front buffer until glFlush() or glFinish() are called. That's assuming that glReadBuffer(GL_FRONT); glReadPixels(...) grabs pixels from the back color buffer. If that's not true, you'd have to do the buffer copy before each glReadPixels(). Thats a reasonable optimization, but the basic technique is flawed -- it's probably possible to get the correct behaviour of a single-buffered visual in this way, but it's not going to be compliant at all for a double-buffered visual where the app is switching between drawing to the front & back buffers. Right. I thought we were just talking about the single-buffer scenario though. -Brian --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-users] Problems with savage and DRI
Brian Paul wrote: You don't have to copy from the back buffer to the front buffer until glFlush() or glFinish() are called. That's assuming that glReadBuffer(GL_FRONT); glReadPixels(...) grabs pixels from the back color buffer. If that's not true, you'd have to do the buffer copy before each glReadPixels(). Thats a reasonable optimization, but the basic technique is flawed -- it's probably possible to get the correct behaviour of a single-buffered visual in this way, but it's not going to be compliant at all for a double-buffered visual where the app is switching between drawing to the front & back buffers. Keith --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-users] Problems with savage and DRI
--- Felix Kühling <[EMAIL PROTECTED]> wrote:
> Hi Marcin,
>
> Also CCing to Alex, he probably knows more about this.
>
> Currently the driver looks like it's not supposed to render to the
> front
> buffer at all. When single buffering is used, the driver draws to the
> back buffer and copies it over to the front buffer after processing a
> Mesa vertex buffer. I have no idea if this is GL compliant. Anyway,
> it
> seems that frequent copying from the back buffer to the front buffer
> is
> a big performance problem.
>
> Anyway, the reason is that accelerated 3D rendering only works with
> tiled memory but the front buffer is linear.
>
> Software fallbacks draw to tiled surfaces, which map linear or tiled
> memory. If I understand it correctly it shouldn't make any difference
> whether the underlying memory is linear or tiled (as long as the
> tiled
> surface registers are setup correctly).
That's my understanding as well, but I could be wrong. Also, tiling
the front buffer results in lower performance. I'm not sure why. It
might have just been due to the way the code was initially architected.
your changes to the 3d driver may have fixed that.
>
> It seems that the front buffer surface uses a different line pitch
> than
> the back buffer. I don't know why that is. Alex, can this be changed
> easily or would it require big changes in the 2D driver?
The pitch is different because of alignment requirements. I think I
tried changing the front pitch to match the others and it didn't seem
to break anything as I recall, so perhaps we can get away with it.
Unfortunately, tiling of the front buffer broke when I ported S3's
changes to Tim's code. I'm not sure what the problem is as the set up
is pretty much identical. I never really dug into it too much since
linear seemed to work fine for most things. However, back when we were
using S3's driver and tiling worked, drawing to the front buffer was
still broken (looked the same whether the front buffer was tiled or
not).
Alex
>
> Regards,
> Felix
>
> On Tue, 23 Mar 2004 11:18:46 +0100
> Marcin Krotkiewski <[EMAIL PROTECTED]> wrote:
>
> > Hi again,
> >
> > > I think this is a problem with software fallbacks drawn to the
> front
> > > buffer. It's definitely a driver bug. As a workaround try drawing
> to the
> > > back buffer and call glXSwapBuffers when you're done with a
> frame. The
> > > worst thing that would happen here is that the window remains
> black (or
> > > whatever your clear color is). ;-)
> > >
> > > If you want to try to fix the bug take a look at savagespan.c in
> the 3D
> > > driver in the Mesa source code
> (src/mesa/drivers/dri/savage/savagespan.c).
> >
> > I modified savagespan.c a bit. This line helped:
> >
> > static void savageDDSetBuffer(GLcontext *ctx, GLframebuffer
> *buffer,
> > GLuint bufferBit)
> > {
> >savageContextPtr imesa = SAVAGE_CONTEXT(ctx);
> >char *map;
> >
> >assert( (bufferBit == FRONT_LEFT_BIT) || (bufferBit ==
> BACK_LEFT_BIT) );
> >
> >map = (bufferBit == FRONT_LEFT_BIT)
> >? (char*)imesa->apertureBase[TARGET_FRONT]
> >: (char*)imesa->apertureBase[TARGET_BACK];
> > + map = (char*)imesa->apertureBase[TARGET_BACK];
> >
> > Though I do not think this is a solution, it might help you track
> > down the bug...
> > I'll let you know if I find anything else ;)
> >
> > Cheers
> >
> > Marcin
> >
> > >
> > > I'm not yet ready to start fixing bugs in the driver. There is at
> least
> > > one big chunk of work that I'm going to tackle in the next couple
> of
> > > weeks. Later on you could help improve the driver by sending bug
> reports
> > > with short OpenGL example programmes that demonstrate the
> problem.
> > > Usually this helps a lot in tracking down 3D driver bugs.
> > >
> > >>
> > >> Cheers,
> > >>
> > >> Marcin Krotkiewski
> > >
> > > Regards,
> > > Felix
> > >
> > >
> > > ---
> > > This SF.Net email is sponsored by: IBM Linux Tutorials
> > > Free Linux tutorial presented by Daniel Robbins, President and
> CEO of
> > > GenToo technologies. Learn everything from fundamentals to system
> > >
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> > > --
> > > ___
> > > Dri-users mailing list
> > > [EMAIL PROTECTED]
> > > https://lists.sourceforge.net/lists/listinfo/dri-users
> >
__
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
Re: [Dri-devel] Re: [Dri-users] Problems with savage and DRI
Felix Kühling wrote: Hi Marcin, Also CCing to Alex, he probably knows more about this. Currently the driver looks like it's not supposed to render to the front buffer at all. When single buffering is used, the driver draws to the back buffer and copies it over to the front buffer after processing a Mesa vertex buffer. I have no idea if this is GL compliant. No, it's not. Keith --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-users] Problems with savage and DRI
You don't have to copy from the back buffer to the front buffer until
glFlush() or glFinish() are called. That's assuming that
glReadBuffer(GL_FRONT); glReadPixels(...) grabs pixels from the back
color buffer. If that's not true, you'd have to do the buffer copy
before each glReadPixels().
-Brian
Felix Kühling wrote:
Hi Marcin,
Also CCing to Alex, he probably knows more about this.
Currently the driver looks like it's not supposed to render to the front
buffer at all. When single buffering is used, the driver draws to the
back buffer and copies it over to the front buffer after processing a
Mesa vertex buffer. I have no idea if this is GL compliant. Anyway, it
seems that frequent copying from the back buffer to the front buffer is
a big performance problem.
Anyway, the reason is that accelerated 3D rendering only works with
tiled memory but the front buffer is linear.
Software fallbacks draw to tiled surfaces, which map linear or tiled
memory. If I understand it correctly it shouldn't make any difference
whether the underlying memory is linear or tiled (as long as the tiled
surface registers are setup correctly).
It seems that the front buffer surface uses a different line pitch than
the back buffer. I don't know why that is. Alex, can this be changed
easily or would it require big changes in the 2D driver?
Regards,
Felix
On Tue, 23 Mar 2004 11:18:46 +0100
Marcin Krotkiewski <[EMAIL PROTECTED]> wrote:
Hi again,
I think this is a problem with software fallbacks drawn to the front
buffer. It's definitely a driver bug. As a workaround try drawing to the
back buffer and call glXSwapBuffers when you're done with a frame. The
worst thing that would happen here is that the window remains black (or
whatever your clear color is). ;-)
If you want to try to fix the bug take a look at savagespan.c in the 3D
driver in the Mesa source code (src/mesa/drivers/dri/savage/savagespan.c).
I modified savagespan.c a bit. This line helped:
static void savageDDSetBuffer(GLcontext *ctx, GLframebuffer *buffer,
GLuint bufferBit)
{
savageContextPtr imesa = SAVAGE_CONTEXT(ctx);
char *map;
assert( (bufferBit == FRONT_LEFT_BIT) || (bufferBit == BACK_LEFT_BIT) );
map = (bufferBit == FRONT_LEFT_BIT)
? (char*)imesa->apertureBase[TARGET_FRONT]
: (char*)imesa->apertureBase[TARGET_BACK];
+ map = (char*)imesa->apertureBase[TARGET_BACK];
Though I do not think this is a solution, it might help you track
down the bug...
I'll let you know if I find anything else ;)
Cheers
Marcin
I'm not yet ready to start fixing bugs in the driver. There is at least
one big chunk of work that I'm going to tackle in the next couple of
weeks. Later on you could help improve the driver by sending bug reports
with short OpenGL example programmes that demonstrate the problem.
Usually this helps a lot in tracking down 3D driver bugs.
Cheers,
Marcin Krotkiewski
Regards,
Felix
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-users] Problems with savage and DRI
Hi Marcin,
Also CCing to Alex, he probably knows more about this.
Currently the driver looks like it's not supposed to render to the front
buffer at all. When single buffering is used, the driver draws to the
back buffer and copies it over to the front buffer after processing a
Mesa vertex buffer. I have no idea if this is GL compliant. Anyway, it
seems that frequent copying from the back buffer to the front buffer is
a big performance problem.
Anyway, the reason is that accelerated 3D rendering only works with
tiled memory but the front buffer is linear.
Software fallbacks draw to tiled surfaces, which map linear or tiled
memory. If I understand it correctly it shouldn't make any difference
whether the underlying memory is linear or tiled (as long as the tiled
surface registers are setup correctly).
It seems that the front buffer surface uses a different line pitch than
the back buffer. I don't know why that is. Alex, can this be changed
easily or would it require big changes in the 2D driver?
Regards,
Felix
On Tue, 23 Mar 2004 11:18:46 +0100
Marcin Krotkiewski <[EMAIL PROTECTED]> wrote:
> Hi again,
>
> > I think this is a problem with software fallbacks drawn to the front
> > buffer. It's definitely a driver bug. As a workaround try drawing to the
> > back buffer and call glXSwapBuffers when you're done with a frame. The
> > worst thing that would happen here is that the window remains black (or
> > whatever your clear color is). ;-)
> >
> > If you want to try to fix the bug take a look at savagespan.c in the 3D
> > driver in the Mesa source code (src/mesa/drivers/dri/savage/savagespan.c).
>
> I modified savagespan.c a bit. This line helped:
>
> static void savageDDSetBuffer(GLcontext *ctx, GLframebuffer *buffer,
> GLuint bufferBit)
> {
>savageContextPtr imesa = SAVAGE_CONTEXT(ctx);
>char *map;
>
>assert( (bufferBit == FRONT_LEFT_BIT) || (bufferBit == BACK_LEFT_BIT) );
>
>map = (bufferBit == FRONT_LEFT_BIT)
>? (char*)imesa->apertureBase[TARGET_FRONT]
>: (char*)imesa->apertureBase[TARGET_BACK];
> + map = (char*)imesa->apertureBase[TARGET_BACK];
>
> Though I do not think this is a solution, it might help you track
> down the bug...
> I'll let you know if I find anything else ;)
>
> Cheers
>
> Marcin
>
> >
> > I'm not yet ready to start fixing bugs in the driver. There is at least
> > one big chunk of work that I'm going to tackle in the next couple of
> > weeks. Later on you could help improve the driver by sending bug reports
> > with short OpenGL example programmes that demonstrate the problem.
> > Usually this helps a lot in tracking down 3D driver bugs.
> >
> >>
> >> Cheers,
> >>
> >> Marcin Krotkiewski
> >
> > Regards,
> > Felix
> >
> >
> > ---
> > This SF.Net email is sponsored by: IBM Linux Tutorials
> > Free Linux tutorial presented by Daniel Robbins, President and CEO of
> > GenToo technologies. Learn everything from fundamentals to system
> > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> > --
> > ___
> > Dri-users mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/dri-users
>
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] initial DRM conversion script..
I've thrown together a really simple script to make the DRM tree into a Linux kernel type setup.. its in the DRM tree under scripts/create_lk_drm.sh usage is from the top of of the DRM and you provide the output dir and either 2.4 or 2.6 to produce the correct type of tree.. I'm sure there are many things that could be done to this, feel free :-) Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] mach64-0-0-7 branch and VBE TVOut. Patch included.
This is nothing more than a HUNK fixed copy of the TVOut patch found on
leif's linux page. With this patch the TVOut and other related options
are evaluated and it is posible to use atitvout while in X. However I
notesed some problems with this patch that only a reboot would fix. There
was coruption of 2d texture offsets making the FB filled with odd things
from display memory. Something like the GDM login name prompt came in
clearly while the rest of the screen was messed up. I'l see if I can't
get some screenshots of this.
__
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.htmlIndex: Imakefile
===
RCS file: /cvs/dri/xc/xc/programs/Xserver/hw/xfree86/drivers/ati/Imakefile,v
retrieving revision 1.16.10.1
diff -u -r1.16.10.1 Imakefile
--- Imakefile 6 Feb 2004 11:15:40 - 1.16.10.1
+++ Imakefile 21 Mar 2004 00:21:51 -
@@ -147,7 +147,24 @@
#endif
-DEFINES = $(CPIODEFINES) $(DGADEFINES) $(NONPCIDEFINES) $(DRIDEFINES)
+/*
+ * TV-out only supported on x86
+ */
+#if ATIAvoidCPIO
+# undef ATITVOut
+# define ATITVOut NO
+#elif defined(i386Architecture)
+# undef ATITVOut
+# define ATITVOut YES
+#endif
+
+#if ATITVOut
+
+TVOUTDEFINES = -DTV_OUT
+
+#endif
+
+DEFINES = $(CPIODEFINES) $(DGADEFINES) $(NONPCIDEFINES) $(DRIDEFINES) $(TVOUTDEFINES)
SRCS1 = ati.c atiadapter.c atibus.c atichip.c atiident.c atioption.c \
atiprobe.c atividmem.c $(CPIOSRCS1) $(MODSRCS1) \
Index: aticonfig.c
===
RCS file: /cvs/dri/xc/xc/programs/Xserver/hw/xfree86/drivers/ati/aticonfig.c,v
retrieving revision 1.2.12.3
diff -u -r1.2.12.3 aticonfig.c
--- aticonfig.c 14 Feb 2004 09:31:58 - 1.2.12.3
+++ aticonfig.c 21 Mar 2004 00:21:52 -
@@ -123,6 +123,13 @@
#endif /* XF86DRI */
+#ifdef TV_OUT
+
+# define TvOutPublicOption[ATI_OPTION_TV_OUT].value.bool
+# define TvStdPublicOption[ATI_OPTION_TV_STD].value.str
+
+#endif /* TV_OUT */
+
# define CacheMMIO PublicOption[ATI_OPTION_MMIO_CACHE].value.bool
# define TestCacheMMIO PublicOption[ATI_OPTION_TEST_MMIO_CACHE].value.bool
# define PanelDisplay PublicOption[ATI_OPTION_PANEL_DISPLAY].value.bool
@@ -154,6 +161,11 @@
#endif /* AVOID_CPIO */
+#ifdef TV_OUT
+
+ TvStd = "None"; /* No tv standard change requested */
+
+#endif
}
ReferenceClock = ((double)15750.0) / ((double)11.0);
@@ -202,6 +214,31 @@
#endif /* AVOID_CPIO */
+#ifdef TV_OUT
+
+if (TvOut && pATI->Chip < ATI_CHIP_264GT) {
+ /* Only allow this for 3D Rage (I) or greater chip ID
+ * AFAIK, no chips before this supported TV-Out
+ * mach64VT has support for TV tuner, but no TV-Out
+ */
+ xf86DrvMsg(pScreenInfo->scrnIndex, X_WARNING,
+"TV Out not supported for this chip.\n");
+} else {
+ ATITVStandard std;
+ pATI->OptionTvOut = TvOut;
+ pATI->OptionTvStd = ATI_TV_STD_INVALID;
+ for (std = 0; std < ATI_TV_STDS_MAX_VALID; std++) {
+ if (std != ATI_TV_STD_RESERVED1 && std != ATI_TV_STD_RESERVED2) {
+ if (strncasecmp(TvStd, ATITVStandardNames[std],
ATI_TV_STDS_NAME_MAXLEN)==0) {
+ pATI->OptionTvStd = std;
+ break;
+ }
+ }
+ }
+}
+
+#endif /* TV_OUT */
+
pATI->OptionMMIOCache = CacheMMIO;
pATI->OptionTestMMIOCache = TestCacheMMIO;
pATI->OptionProbeClocks = ProbeClocks;
Index: aticonsole.c
===
RCS file: /cvs/dri/xc/xc/programs/Xserver/hw/xfree86/drivers/ati/aticonsole.c,v
retrieving revision 1.2.12.2
diff -u -r1.2.12.2 aticonsole.c
--- aticonsole.c13 Feb 2004 11:49:54 - 1.2.12.2
+++ aticonsole.c21 Mar 2004 00:21:53 -
@@ -42,6 +42,20 @@
#include "xf86.h"
+#ifdef TV_OUT
+
+#include "atichip.h"
+#include "atiprint.h"
+#include "atioption.h"
+#include "vbe.h"
+
+static const char *vbeSymbols[] = {
+"VBEGetVBEMode",
+NULL
+};
+
+#endif /* TV_OUT */
+
/*
* ATISaveScreen --
*
@@ -135,6 +149,398 @@
}
}
+#ifdef TV_OUT
+
+static void
+ATIProbeAndSetActiveDisplays
+(
+ScrnInfoPtr pScreenInfo,
+ATIPtr pATI
+)
+{
+vbeInfoPtr pVbe;
+Bool tv_attached, crt_attached, lcd_attached;
+int disp_request;
+ATITVStandard tv_std, tv_std_request;
+
+xf86LoaderRefSymLists(vbeSymbols, NULL);
+
+if (xf86GetVerbosity() > 3) {
+ xf86ErrorFVerb(4, "\n Before TV-Out queries\n\n",
+ pScreenInfo->currentMode->name);
+ ATIPrintRegisters(pATI);
+}
+
+pATI->tvActive = FALSE;
+pVbe = pATI->pVBE;
+if (pVbe) {
+ /* LT Pro, XL, Mobility specific BIOS functions */
+ if (pATI->Chip == ATI_CHIP_264LTPRO ||
+ pATI->Chip == ATI_CHIP_264XL ||
+ pATI->Chi
Re: [Dri-devel] Via drm driver thoughts
Thomas Hellstrom wrote: Hi! I've now implemented the DRM os-abstraction macros from drm_os_linux.h throughout the driver and, from what I can see, there is no linux specific stuff left. My idea is therefore to check in the driver under "shared", but update only the linux makefiles until *BSD compatibility can be tested. Would you like me to create a separate branch for this stuff or go directly for the trunk? Unless you expect this to break one of the existing modules (which seems unlikely), I'm happy to see it go straight to the trunk. Keith --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Via drm driver thoughts
Hi! I've now implemented the DRM os-abstraction macros from drm_os_linux.h throughout the driver and, from what I can see, there is no linux specific stuff left. My idea is therefore to check in the driver under "shared", but update only the linux makefiles until *BSD compatibility can be tested. Would you like me to create a separate branch for this stuff or go directly for the trunk? Regards /Thomas --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
