Re: [Dri-devel] Savage 3D driver roadmap
Alex Deucher wrote: --- Felix Kühling <[EMAIL PROTECTED]> wrote: 3. Separate commands and data Right now commands and data are submitted to the chip as one data stream, either via the BCI or via DMA buffers. For easier security checking command and data streams should be separated. Savage chips can handle vertex buffers and indexed drawing commands. I couldn't find a way to specify the vertex format for indexed drawing commands. Either it is automagically deduced from various state bits (specular and enabled texture units come to mind) or vertices vertex buffers are always complete. This would also mean that their format differs between Savage3D and Savage4 since the Savage3D has only one texture unit. These are things that I'dd have to find out by experiment. But maybe someone happens to know it or has better documentation than I do. Perhaps, we can save some experimenting time. Tim, do you remember off hand which of these modes we can use with savage4/3d/etc? I'm sorry, I've parsed this twice and I'm still not I sure I understand what question is being asked. My spec for the Savage3D is complete. However, they actually removed the 3D section from both of the Savage4 register specs they sent me, so it is somewhat difficult for me to do comparisons. If you can ask a more specific question, I'd be happy to help. Note, however, that it is hardly worth the trouble to spend time on the Savage3D. There were so many problems in the 2D engine that, by the time it became stable, the much improved Savage4 was available. Few of the Savage3Ds ever saw the light of day. -- - Tim Roberts, [EMAIL PROTECTED] Providenza & Boekelheide, Inc. --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56&alloc_id438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Savage 3D driver roadmap
Alex Deucher wrote: Felix can probably phrase this better than I since he has worked more closely with the 3D code. however, I think what he is asking is how should vertex commends be formatted when sent to the 3D engine when using indexed drawing commands? We want to separate drawing commands and data so that we can do DMA securely to prevent someone writing anywhere in memory. Looks to me like they just write the BCI command (8003 for triangle primitive) followed by three D3DTLVERTEX instances, 32 bytes each. The code copies each D3DTLVERTEX using the FPU: fild/fild/fild/fild/fistp/fistp/fistp/fistp. I wouldn't have guessed that was optimal for a 32-byte copy. -- - Tim Roberts, [EMAIL PROTECTED] Providenza & Boekelheide, Inc. --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Savage 3D driver roadmap
On Fri, 20 Feb 2004 17:29:07 -0800
Tim Roberts <[EMAIL PROTECTED]> wrote:
> Alex Deucher wrote:
>
> >Felix can probably phrase this better than I since he has worked more
> >closely with the 3D code. however, I think what he is asking is how
> >should vertex commends be formatted when sent to the 3D engine when
> >using indexed drawing commands? We want to separate drawing commands
> >and data so that we can do DMA securely to prevent someone writing
> >anywhere in memory.
> >
> >
>
> Looks to me like they just write the BCI command (8003 for triangle
> primitive) followed by three D3DTLVERTEX instances, 32 bytes each. The
> code copies each D3DTLVERTEX using the FPU:
> fild/fild/fild/fild/fistp/fistp/fistp/fistp. I wouldn't have guessed
> that was optimal for a 32-byte copy.
Yes, that's when you have a mixed command and data stream. However,
there also seems to be a BCI command that allows you to reference
vertices in a pure vertex DMA buffer. The vertex buffer address is
deterined by register 0x48C20 (BCI: 0x3E). I found this definition of
the indexed drawing BCI command in the S3 driver:
typedef struct { /*for DrawIndexPrimitive command, vert0Idx is meaningful.*/
unsigned int vert0Idx:16;
unsigned int vertCnt:8;
unsigned int cont:1;
unsigned int type:2; /*00=list, 01=strip, 10=fan, 11=reserved*/
unsigned int cmd:5;
}Reg_DrawIndexPrimitive;
However, it does not allow you to specify the vertex format (skip
flags). So my question is if vertices are always complete (32 bytes on
Savage3D and 40 bytes on Savage4 due to the second texture unit) or if
the vertex format is somehow automatically determined by state flags
like specular enabled and the texture units that are enabled. Or is
there another way to specify the vertex format for indexed drawing
commands that I missed. Also I just realized that I don't know the most
significant 5 bits of the drawing command yet (cmd in the structure
above).
>
> --
> - Tim Roberts, [EMAIL PROTECTED]
> Providenza & Boekelheide, Inc.
>
Felix
---
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Savage 3D driver roadmap
On Fri, 20 Feb 2004, Alex Deucher wrote: >> the main reason mach64 is still on a branch in DRI is it is insecure >> by >> default, I'm going to look into it when I've moved apartments and got >> myself settled in again :-), I don't think putting insecure code into >> the >> trunk where it may get merged up to XFree86 is such a good idea :-) > > >As I recall it's just a matter of changing a config option to a >different default. should be trivial. Just needs to be added to DevelDRIDrivers in xfree86.cf -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Savage 3D driver roadmap
--- Tim Roberts <[EMAIL PROTECTED]> wrote: > Alex Deucher wrote: > > >--- Felix Kühling <[EMAIL PROTECTED]> wrote: > > > > > >>3. Separate commands and data > >> > >>Right now commands and data are submitted to the chip as one data > >>stream, either via the BCI or via DMA buffers. For easier security > >>checking command and data streams should be separated. Savage chips > >>can > >>handle vertex buffers and indexed drawing commands. I couldn't find > a > >>way to specify the vertex format for indexed drawing commands. > Either > >>it is automagically deduced from various state bits (specular and > >>enabled > >>texture units come to mind) or vertices vertex buffers are always > >>complete. This would also mean that their format differs between > >>Savage3D and Savage4 since the Savage3D has only one texture unit. > >>These > >>are things that I'dd have to find out by experiment. But maybe > >>someone > >>happens to know it or has better documentation than I do. > >> > >Perhaps, we can save some experimenting time. Tim, do you remember > off > >hand which of these modes we can use with savage4/3d/etc? > > > > > > I'm sorry, I've parsed this twice and I'm still not I sure I > understand > what question is being asked. > > My spec for the Savage3D is complete. However, they actually removed > > the 3D section from both of the Savage4 register specs they sent me, > so > it is somewhat difficult for me to do comparisons. If you can ask a > more specific question, I'd be happy to help. > Felix can probably phrase this better than I since he has worked more closely with the 3D code. however, I think what he is asking is how should vertex commends be formatted when sent to the 3D engine when using indexed drawing commands? We want to separate drawing commands and data so that we can do DMA securely to prevent someone writing anywhere in memory. > Note, however, that it is hardly worth the trouble to spend time on > the > Savage3D. There were so many problems in the 2D engine that, by the > time it became stable, the much improved Savage4 was available. Few > of > the Savage3Ds ever saw the light of day. Well, there are quite a few savage IX and MX chips around and they share the 3D engine with the savage3D. that's what we are developing on. Alex > > -- > - Tim Roberts, [EMAIL PROTECTED] > Providenza & Boekelheide, Inc. > __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Savage 3D driver roadmap
--- Dave Airlie <[EMAIL PROTECTED]> wrote: > > > > mach64. I'd do the same with savage. > > > > Either way, seeing as the driver would be in the Mesa trunk, DRI > branches > > don't seem to make much sense anymore to me, unless it's for work > on GLX > > like the work Ian's doing. > > > > The whole point of DRI branches before was to isolate new driver > work, > > but the Mesa trunk works in the opposite direction - i.e. new work > being on > > the trunk. > > > > the main reason mach64 is still on a branch in DRI is it is insecure > by > default, I'm going to look into it when I've moved apartments and got > myself settled in again :-), I don't think putting insecure code into > the > trunk where it may get merged up to XFree86 is such a good idea :-) As I recall it's just a matter of changing a config option to a different default. should be trivial. Alex > > Dave. > > -- > David Airlie, Software Engineer > http://www.skynet.ie/~airlied / airlied at skynet.ie > pam_smb / Linux DECstation / Linux VAX / ILUG person > > > > --- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > -- > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Savage 3D driver roadmap
On Fri, Feb 20, 2004 at 10:45:54PM +, Dave Airlie wrote: > > > > mach64. I'd do the same with savage. > > > > Either way, seeing as the driver would be in the Mesa trunk, DRI branches > > don't seem to make much sense anymore to me, unless it's for work on GLX > > like the work Ian's doing. > > > > The whole point of DRI branches before was to isolate new driver work, > > but the Mesa trunk works in the opposite direction - i.e. new work being on > > the trunk. > > > > the main reason mach64 is still on a branch in DRI is it is insecure by > default, I'm going to look into it when I've moved apartments and got > myself settled in again :-), I don't think putting insecure code into the > trunk where it may get merged up to XFree86 is such a good idea :-) Forgetting the DRI for a second Dave. The mach64 code is in the trunk of Mesa. What's stopping someone using that with the miniGLX stuff (with a few fixups) and not knowing about the security issues. All I'm saying is the mach64 code is much more visible now being on the trunk in Mesa, than it used to be in a branch off the DRI. I don't think the savage would be any worse off. Plus, I also think it'd get more testing and more people might know of it's existence to help out. Heck, we can always tell XFree86 to not merge that code because it is insecure. But there are always those who don't care about security and just need accelerated 3D. Alan. --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Savage 3D driver roadmap
Dave Airlie wrote: mach64. I'd do the same with savage. Either way, seeing as the driver would be in the Mesa trunk, DRI branches don't seem to make much sense anymore to me, unless it's for work on GLX like the work Ian's doing. The whole point of DRI branches before was to isolate new driver work, but the Mesa trunk works in the opposite direction - i.e. new work being on the trunk. the main reason mach64 is still on a branch in DRI is it is insecure by default, I'm going to look into it when I've moved apartments and got myself settled in again :-), I don't think putting insecure code into the trunk where it may get merged up to XFree86 is such a good idea :-) Well, one could skip building of the mach64 driver by default. I.e. compile and use at your own risk kind of thing. -Brian --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Savage 3D driver roadmap
> > mach64. I'd do the same with savage. > > Either way, seeing as the driver would be in the Mesa trunk, DRI branches > don't seem to make much sense anymore to me, unless it's for work on GLX > like the work Ian's doing. > > The whole point of DRI branches before was to isolate new driver work, > but the Mesa trunk works in the opposite direction - i.e. new work being on > the trunk. > the main reason mach64 is still on a branch in DRI is it is insecure by default, I'm going to look into it when I've moved apartments and got myself settled in again :-), I don't think putting insecure code into the trunk where it may get merged up to XFree86 is such a good idea :-) Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Savage 3D driver roadmap
Alan Hourihane wrote: On Fri, Feb 20, 2004 at 05:30:57PM +0100, Felix Kühling wrote: On Fri, 20 Feb 2004 14:55:55 + Alan Hourihane <[EMAIL PROTECTED]> wrote: Felix, How about dropping your current DRI savage driver into the Mesa trunk (6.1) and whipping the driver into shape with the current DRI trunk. Are you suggesting to continue development on DRI trunk or make a new branch from the current DRI trunk? The latter is what just happened with mach64. I'd do the same with savage. Either way, seeing as the driver would be in the Mesa trunk, DRI branches don't seem to make much sense anymore to me, unless it's for work on GLX like the work Ian's doing. The whole point of DRI branches before was to isolate new driver work, but the Mesa trunk works in the opposite direction - i.e. new work being on the trunk. I think that will serve you best, in that Mesa 5.x is obviously being left behind now, and if you hit problems they may be bugs in 5.x your hitting. I'm going to bring my T20 up-to-speed to see if I can help with this at some point, but it'd be good to get it into the Mesa 6 trunk code first. Ok. That's fine with me. If Brian agrees I could make the move over the weekend. O.k. But I doubt Brian would disagree. Sounds like a good plan. Felix, do you need Mesa CVS access? If so, contact Eric Anholt of Danial Stone (see Mesa's CVS webpage). -Brian --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56&alloc_id438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Savage 3D driver roadmap
On Fri, Feb 20, 2004 at 05:30:57PM +0100, Felix Kühling wrote: > On Fri, 20 Feb 2004 14:55:55 + > Alan Hourihane <[EMAIL PROTECTED]> wrote: > > > Felix, > > > > How about dropping your current DRI savage driver into the Mesa trunk (6.1) > > and whipping the driver into shape with the current DRI trunk. > > Are you suggesting to continue development on DRI trunk or make a new > branch from the current DRI trunk? The latter is what just happened with > mach64. I'd do the same with savage. Either way, seeing as the driver would be in the Mesa trunk, DRI branches don't seem to make much sense anymore to me, unless it's for work on GLX like the work Ian's doing. The whole point of DRI branches before was to isolate new driver work, but the Mesa trunk works in the opposite direction - i.e. new work being on the trunk. > > I think that will serve you best, in that Mesa 5.x is obviously being > > left behind now, and if you hit problems they may be bugs in 5.x your > > hitting. > > > > I'm going to bring my T20 up-to-speed to see if I can help with this > > at some point, but it'd be good to get it into the Mesa 6 trunk code first. > > Ok. That's fine with me. If Brian agrees I could make the move over the > weekend. O.k. But I doubt Brian would disagree. Alan. --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56&alloc_id438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Savage 3D driver roadmap
On Fri, 20 Feb 2004 14:55:55 + Alan Hourihane <[EMAIL PROTECTED]> wrote: > Felix, > > How about dropping your current DRI savage driver into the Mesa trunk (6.1) > and whipping the driver into shape with the current DRI trunk. Are you suggesting to continue development on DRI trunk or make a new branch from the current DRI trunk? The latter is what just happened with mach64. I'd do the same with savage. > > I think that will serve you best, in that Mesa 5.x is obviously being > left behind now, and if you hit problems they may be bugs in 5.x your > hitting. > > I'm going to bring my T20 up-to-speed to see if I can help with this > at some point, but it'd be good to get it into the Mesa 6 trunk code first. Ok. That's fine with me. If Brian agrees I could make the move over the weekend. > > Alan. > Felix --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Savage 3D driver roadmap
On Fri, 20 Feb 2004 08:04:43 -0800 Ian Romanick <[EMAIL PROTECTED]> wrote: > Felix Kühling wrote: > > > The last one is the easier one I think. In savagetex.c in > > savageUpdateTex0State_s4 and savageUpdateTex1State_s4 there is a pretty > > fancy computation of the 9bit LOD bias (probably some fixed point > > format) from a floating point value. The lodbias mesa demo shows no > > visible change of the LOD bias, so it's either broken in hardware or the > > formula is wrong. Can you try to find a formula that looks right by > > comparing with indirect rendering? > > Or the state isn't being sent to the card correctly. Even if the value > isn't calculated correctly, changing the hardware state should change > what is displayed. Hmm, maybe it forgets to update the state when the LOD bias changes. Once it gets to savageUpdateTex?State_s4 I'm pretty sure the computed value is sent to the hardware correctly. It's in a 32bit words with more flags like filterMode and mipmapEnable. So there would be other visible effects if it wasn't sent to the hardware correctly. Felix --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56&alloc_id438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Savage 3D driver roadmap
Felix Kühling wrote: The last one is the easier one I think. In savagetex.c in savageUpdateTex0State_s4 and savageUpdateTex1State_s4 there is a pretty fancy computation of the 9bit LOD bias (probably some fixed point format) from a floating point value. The lodbias mesa demo shows no visible change of the LOD bias, so it's either broken in hardware or the formula is wrong. Can you try to find a formula that looks right by comparing with indirect rendering? Or the state isn't being sent to the card correctly. Even if the value isn't calculated correctly, changing the hardware state should change what is displayed. --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56&alloc_id438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Savage 3D driver roadmap
Felix, How about dropping your current DRI savage driver into the Mesa trunk (6.1) and whipping the driver into shape with the current DRI trunk. I think that will serve you best, in that Mesa 5.x is obviously being left behind now, and if you hit problems they may be bugs in 5.x your hitting. I'm going to bring my T20 up-to-speed to see if I can help with this at some point, but it'd be good to get it into the Mesa 6 trunk code first. Alan. --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Savage 3D driver roadmap
On Thu, 19 Feb 2004 18:58:25 -0300 Rafael Maximo <[EMAIL PROTECTED]> wrote: [snip] > > I really interested on helping, specially on savage4 driver because is the > only one i have access, unfortunately i don't have much experience on > hardware programing but i'm learning a lot checking the savage source and > i'll try to help in anyway a can. I think you should definitely start with fixing smaller problems so you get used to the source code. These two can be done on savage4: - disable hardware culling for lines and points - fix LOD bias The last one is the easier one I think. In savagetex.c in savageUpdateTex0State_s4 and savageUpdateTex1State_s4 there is a pretty fancy computation of the 9bit LOD bias (probably some fixed point format) from a floating point value. The lodbias mesa demo shows no visible change of the LOD bias, so it's either broken in hardware or the formula is wrong. Can you try to find a formula that looks right by comparing with indirect rendering? For the hardware culling problem you'd need to get an understanding of how savagetris.c and the templates that it uses work. That may take some time to get into. Also comparison with other drivers, especially r128 and mga, may be helpful. Felix --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Savage 3D driver roadmap
On Thu, 19 Feb 2004 18:26:50 -0800 (PST) Alex Deucher <[EMAIL PROTECTED]> wrote: > > --- Felix K_hling <[EMAIL PROTECTED]> wrote: > > Hello S3 Savage users, > > > [snip] > > Felix, > >I'd like to give you a hand on the 3D driver while I still have some > free time, but I have to admit, I'm somewhat intimidated. What's a > good task that I can work on to get my feet wet on the 3D side? It's > probably not too much more complicated than the 2D side. Gotta do it > sometime... > > Thanks, > > Alex You could start with smaller bug fixes. This way you'd see results pretty soon and get used to limited parts of the source code. You could also start moving things to the kernel module. Clears and buffer swaps should be pretty mechanical. They are currently in savageioctl.c. DMA buffer management would be the next step. I had a brief look at how the radeon driver does DMA buffer aging a while back. Something similar should be possible on the Savage using the event tag. There are templates for DMA buffer mapping in the DRM. I don't know how much work is left to the individual driver. Also the PCI scatter-gather template could be useful to get PCI savages supported again on 2.6 kernels. I'd like to get rid of those hacks that the savage driver currently uses for PCI cards. This step would involve small changes in the 2D driver as well. Felix --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Savage 3D driver roadmap
--- Felix Kühling <[EMAIL PROTECTED]> wrote: > Hello S3 Savage users, > [snip] Felix, I'd like to give you a hand on the 3D driver while I still have some free time, but I have to admit, I'm somewhat intimidated. What's a good task that I can work on to get my feet wet on the 3D side? It's probably not too much more complicated than the 2D side. Gotta do it sometime... Thanks, Alex > -- > > 0. Low hanging bugs (more or less) > > - flat shading on Savage3D > - disable hardware culling for lines and points > - fix texture environments on Savage3D > - fix texture wrapping on Savage3D > - fix LOD bias > > 1. State management cleanup > > The whole state and texture management needs a big cleanup. There are > a > few global function pointers that I added (shame on me) that should > be > in the context. I'm not happy with how the driver is hooked up to > mesa > callbacks right now. They don't map well to how the various state > bits > are layed out in registers on the Savages. Also, currently, in some > situations, registers will be copied to the hardware even if nothing > changed. I'll see how other drivers handle this. I remember seeing > something in a cvs log about similar changes in the MGA driver. > > 2. Texture cleanup > > Color depth conversion can be done by Mesa. Right now it is done by > the > driver on texture upload time. The tiling can be reimplemented more > optimally. Also the tiling of small mipmap levels is broken ATM. > > Ian suggested to add tiled texture format support to Mesa. This would > be > a big chunk of work. I'm not considering it a priority now. > > 3. Separate commands and data > > Right now commands and data are submitted to the chip as one data > stream, either via the BCI or via DMA buffers. For easier security > checking command and data streams should be separated. Savage chips > can > handle vertex buffers and indexed drawing commands. I couldn't find a > way to specify the vertex format for indexed drawing commands. Either > it > is automagically deduced from various state bits (specular and > enabled > texture units come to mind) or vertices vertex buffers are always > complete. This would also mean that their format differs between > Savage3D and Savage4 since the Savage3D has only one texture unit. > These > are things that I'dd have to find out by experiment. But maybe > someone > happens to know it or has better documentation than I do. > > 4. Move hardware access to the kernel module > > The following functions should be moved into the kernel module. > > - clear > - swap > - vertex (DMA) buffer management > - drawing commands > - emitting and waiting for events > > While this is happening the sarea layout and the ioctl interface will > change a lot. Versioning should be used so that the driver can detect > an > incompatible kernel module instead of crashing badly and to avoid > unreproducable bug reports. Binary compatibility in any direction is > not > an issue as long as the driver is not officially released. > > 5. Cliprects > > At the moment the driver honors cliprects on clears and buffer swaps > but > not for drawing commands. This needs to be added in the kernel > module, > once drawing command submission is handled by the kernel. > > - > > At this point the driver should be ready for inclusion in an XFree86 > release. So stabilization and bug fixing would be important to make > it > happen. After that there is enough room for performance improvements > and > for adding new features. Here are a few things that came to mind > spontaneously: > > * IRQs > > At least Savage4 and later can emit IRQs on all sorts of events. They > can be used to implement idle waiting to reduce CPU usage. > > * Page Flipping > > Savage4 and later support page flipping, probably synchronized with > the > retrace, since there is a "page pending" bit in a status register. > The > current driver supports and ancient fullscreen mode, but I think this > is > no longer used by Mesa or any application I know of. Anyway, it is > documentation for how the hardware must be programmed. There is also > an > interesting feature called "automatic Z clear" that can be used > together > with page flipping. > > * Configuration support > > Trivial. > > * Extensions > > Pick your favourite one and implement it. ;-) The Wiki mentions > MESA_ycbcr_texture and bump mapping for example. > > * ... > > > __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- ___
Re: [Dri-devel] Savage 3D driver roadmap
--- Felix Kühling <[EMAIL PROTECTED]> wrote: > Hello S3 Savage users, > > [snip] > > 3. Separate commands and data > > Right now commands and data are submitted to the chip as one data > stream, either via the BCI or via DMA buffers. For easier security > checking command and data streams should be separated. Savage chips > can > handle vertex buffers and indexed drawing commands. I couldn't find a > way to specify the vertex format for indexed drawing commands. Either > it > is automagically deduced from various state bits (specular and > enabled > texture units come to mind) or vertices vertex buffers are always > complete. This would also mean that their format differs between > Savage3D and Savage4 since the Savage3D has only one texture unit. > These > are things that I'dd have to find out by experiment. But maybe > someone > happens to know it or has better documentation than I do. > Perhaps, we can save some experimenting time. Tim, do you remember off hand which of these modes we can use with savage4/3d/etc? Thanks, Alex __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Savage 3D driver roadmap
At 06:25 PM 19/2/2004, Felix Kühling wrote: Hello S3 Savage users, ---snip--- From the list below I'm going to do (1) and (2) pretty soon. Basically I'd like to do all of this, all at the same time, if I could. But I have other things that need attention too. So anybody who has some spare time and interest, let us ([EMAIL PROTECTED]) know what you're working on to avoid duplicate work and feel free to submit patches. IRC meetings every monday would be another good oportunity to discuss issues and coordinate our work. Independently of the issues below the 3D driver should move be ported to the latest Mesa development version and move to the Mesa CVS repository. I'm not sure yet when would be a good time for that. However, we should try not to fall too far behind Mesa CVS. The longer we wait the more painful the porting will be. Don't hesitate to ask questions if something is unclear from the statements below. Comments are welcome. I really interested on helping, specially on savage4 driver because is the only one i have access, unfortunately i don't have much experience on hardware programing but i'm learning a lot checking the savage source and i'll try to help in anyway a can. bye. Best regards, Felix Rafael Máximo --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56&alloc_id438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Savage 3D driver roadmap
Hello S3 Savage users, The most basic grunt work on the Savage 3D driver has been done in the last three months. The driver was ported to Mesa 5 and support for the Savage3D chip family was added. The result is available in CVS on the savage-2-0-0-branch in DRI CVS. Now I consider the driver pretty stable as far as lockups are concerned, a good point for starting to turn it inside out, break things and make life more interesting for testers. :-P I'm outlining my plans for the Savage 3D driver so that testers know what to expect and people who wish to help out get an idea what needs to be done. I'm not going to specify any deadlines since everything depends on how much spare time I (and/or others) have. I'm going to spend more time on it than I should anyway. ;-) >From the list below I'm going to do (1) and (2) pretty soon. Basically I'd like to do all of this, all at the same time, if I could. But I have other things that need attention too. So anybody who has some spare time and interest, let us ([EMAIL PROTECTED]) know what you're working on to avoid duplicate work and feel free to submit patches. IRC meetings every monday would be another good oportunity to discuss issues and coordinate our work. Independently of the issues below the 3D driver should move be ported to the latest Mesa development version and move to the Mesa CVS repository. I'm not sure yet when would be a good time for that. However, we should try not to fall too far behind Mesa CVS. The longer we wait the more painful the porting will be. Don't hesitate to ask questions if something is unclear from the statements below. Comments are welcome. Best regards, Felix -- 0. Low hanging bugs (more or less) - flat shading on Savage3D - disable hardware culling for lines and points - fix texture environments on Savage3D - fix texture wrapping on Savage3D - fix LOD bias 1. State management cleanup The whole state and texture management needs a big cleanup. There are a few global function pointers that I added (shame on me) that should be in the context. I'm not happy with how the driver is hooked up to mesa callbacks right now. They don't map well to how the various state bits are layed out in registers on the Savages. Also, currently, in some situations, registers will be copied to the hardware even if nothing changed. I'll see how other drivers handle this. I remember seeing something in a cvs log about similar changes in the MGA driver. 2. Texture cleanup Color depth conversion can be done by Mesa. Right now it is done by the driver on texture upload time. The tiling can be reimplemented more optimally. Also the tiling of small mipmap levels is broken ATM. Ian suggested to add tiled texture format support to Mesa. This would be a big chunk of work. I'm not considering it a priority now. 3. Separate commands and data Right now commands and data are submitted to the chip as one data stream, either via the BCI or via DMA buffers. For easier security checking command and data streams should be separated. Savage chips can handle vertex buffers and indexed drawing commands. I couldn't find a way to specify the vertex format for indexed drawing commands. Either it is automagically deduced from various state bits (specular and enabled texture units come to mind) or vertices vertex buffers are always complete. This would also mean that their format differs between Savage3D and Savage4 since the Savage3D has only one texture unit. These are things that I'dd have to find out by experiment. But maybe someone happens to know it or has better documentation than I do. 4. Move hardware access to the kernel module The following functions should be moved into the kernel module. - clear - swap - vertex (DMA) buffer management - drawing commands - emitting and waiting for events While this is happening the sarea layout and the ioctl interface will change a lot. Versioning should be used so that the driver can detect an incompatible kernel module instead of crashing badly and to avoid unreproducable bug reports. Binary compatibility in any direction is not an issue as long as the driver is not officially released. 5. Cliprects At the moment the driver honors cliprects on clears and buffer swaps but not for drawing commands. This needs to be added in the kernel module, once drawing command submission is handled by the kernel. - At this point the driver should be ready for inclusion in an XFree86 release. So stabilization and bug fixing would be important to make it happen. After that there is enough room for performance improvements and for adding new features. Here are a few things that came to mind spontaneously: * IRQs At least Savage4 and later can emit IRQs on all sorts of events. They can be used to implement idle waiting to reduce CPU usage. * Page Flipping Savage4 and later support page
