Re: [PATCH 01/23] introduce drm_zalloc as a drm_alloc + memset replacement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Instead of adding drm_zalloc, why not just use drm_calloc? At the very least just make drm_zalloc a macro that calls drm_calloc. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG1H5pX1gOwKyEAw8RAuXrAJ9W+Oyaimcedg0LdDqwqfMgX9Gl2QCeM9BM sdiP4BDvLirsYex5hqhHsFc= =/qZb -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/23] introduce drm_zalloc as a drm_alloc + memset replacement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Instead of adding drm_zalloc, why not just use drm_calloc? At the very least just make drm_zalloc a macro that calls drm_calloc. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG1H5pX1gOwKyEAw8RAuXrAJ9W+Oyaimcedg0LdDqwqfMgX9Gl2QCeM9BM sdiP4BDvLirsYex5hqhHsFc= =/qZb -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Sched - graphic smoothness under load - cfs-v13 sd-0.48
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xavier Bestel wrote: > On Wed, 2007-05-23 at 07:23 +0200, Michael Gerdau wrote: >> For me the huge difference you have for sd to the others increases the >> likelyhood the glxgears benchmark does not measure scheduling of graphic >> but something else. > > I think some people forget that X11 has its own scheduler for graphics > operations. And in the direct-rendering case, this scheduler is not used for OpenGL. The client-side driver submits rendering commands directly to its kernel module. It is possible that some kernel modules perform some sort of scheduling, but none of the open-source drivers implement such a thing. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFGVIZ7X1gOwKyEAw8RAottAJ9oQtnKVZ+xwrZXxyndanwkswp3IACeNY2v JJeDU3cgBtn1dBOr3erl3Ww= =YnG7 -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Sched - graphic smoothness under load - cfs-v13 sd-0.48
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xavier Bestel wrote: On Wed, 2007-05-23 at 07:23 +0200, Michael Gerdau wrote: For me the huge difference you have for sd to the others increases the likelyhood the glxgears benchmark does not measure scheduling of graphic but something else. I think some people forget that X11 has its own scheduler for graphics operations. And in the direct-rendering case, this scheduler is not used for OpenGL. The client-side driver submits rendering commands directly to its kernel module. It is possible that some kernel modules perform some sort of scheduling, but none of the open-source drivers implement such a thing. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFGVIZ7X1gOwKyEAw8RAottAJ9oQtnKVZ+xwrZXxyndanwkswp3IACeNY2v JJeDU3cgBtn1dBOr3erl3Ww= =YnG7 -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VIA and SiS AGP chipsets are x86-only
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Benjamin Herrenschmidt wrote: > On Tue, 2006-12-05 at 20:40 -0700, Matthew Wilcox wrote: >> On Tue, Dec 05, 2006 at 02:56:41PM -0800, Ian Romanick wrote: >>> I don't know about SiS, but this is certainly *not* true for Via. There >>> are some PowerPC and, IIRC, Alpha motherboards that have Via chipsets. >> Yes, but they don't have VIA *AGP*. At least, that's what I've been >> told by people who know those architectures. > > Yeah, I don't know of any VIA AGP chipset used on ppc... > > Pegasos has a VIA southbridge but no AGP. I double checked, and you're right. Please ignore my noise. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFdvr3X1gOwKyEAw8RAocaAJ4whaDqaAmCFzAgrnzyD+1bD/SRXACfb5eM TcFVnRBmMQUyU8wyOxLISHE= =ST0m -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VIA and SiS AGP chipsets are x86-only
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Benjamin Herrenschmidt wrote: On Tue, 2006-12-05 at 20:40 -0700, Matthew Wilcox wrote: On Tue, Dec 05, 2006 at 02:56:41PM -0800, Ian Romanick wrote: I don't know about SiS, but this is certainly *not* true for Via. There are some PowerPC and, IIRC, Alpha motherboards that have Via chipsets. Yes, but they don't have VIA *AGP*. At least, that's what I've been told by people who know those architectures. Yeah, I don't know of any VIA AGP chipset used on ppc... Pegasos has a VIA southbridge but no AGP. I double checked, and you're right. Please ignore my noise. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFdvr3X1gOwKyEAw8RAocaAJ4whaDqaAmCFzAgrnzyD+1bD/SRXACfb5eM TcFVnRBmMQUyU8wyOxLISHE= =ST0m -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VIA and SiS AGP chipsets are x86-only
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matthew Wilcox wrote: > There's no point in troubling the Alpha, IA-64, PowerPC and PARISC > people with SiS and VIA options. Andrew thinks it helps find bugs, > but there's no evidence of that. > > Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]> > > diff --git a/drivers/char/agp/Kconfig b/drivers/char/agp/Kconfig > index c603bf2..a9f9c48 100644 > --- a/drivers/char/agp/Kconfig > +++ b/drivers/char/agp/Kconfig > @@ -86,7 +86,7 @@ config AGP_NVIDIA > > config AGP_SIS > tristate "SiS chipset support" > - depends on AGP > + depends on AGP && X86 > help > This option gives you AGP support for the GLX component of > X on Silicon Integrated Systems [SiS] chipsets. > @@ -103,7 +103,7 @@ config AGP_SWORKS > > config AGP_VIA > tristate "VIA chipset support" > - depends on AGP > + depends on AGP && X86 > help > This option gives you AGP support for the GLX component of > X on VIA MVP3/Apollo Pro chipsets. I don't know about SiS, but this is certainly *not* true for Via. There are some PowerPC and, IIRC, Alpha motherboards that have Via chipsets. My config-fu isn't quite what it should be, so this may be a dumb question. Does the "& X86" requirement exclude x86-64? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFdfkpX1gOwKyEAw8RAmh9AJ42g79Q9isQ0mzy87ILFn8pyW9AjACfWFdu DvPS3GGDJyFfYfaf/8b5H4Y= =NlmP -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VIA and SiS AGP chipsets are x86-only
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matthew Wilcox wrote: There's no point in troubling the Alpha, IA-64, PowerPC and PARISC people with SiS and VIA options. Andrew thinks it helps find bugs, but there's no evidence of that. Signed-off-by: Matthew Wilcox [EMAIL PROTECTED] diff --git a/drivers/char/agp/Kconfig b/drivers/char/agp/Kconfig index c603bf2..a9f9c48 100644 --- a/drivers/char/agp/Kconfig +++ b/drivers/char/agp/Kconfig @@ -86,7 +86,7 @@ config AGP_NVIDIA config AGP_SIS tristate SiS chipset support - depends on AGP + depends on AGP X86 help This option gives you AGP support for the GLX component of X on Silicon Integrated Systems [SiS] chipsets. @@ -103,7 +103,7 @@ config AGP_SWORKS config AGP_VIA tristate VIA chipset support - depends on AGP + depends on AGP X86 help This option gives you AGP support for the GLX component of X on VIA MVP3/Apollo Pro chipsets. I don't know about SiS, but this is certainly *not* true for Via. There are some PowerPC and, IIRC, Alpha motherboards that have Via chipsets. My config-fu isn't quite what it should be, so this may be a dumb question. Does the X86 requirement exclude x86-64? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFdfkpX1gOwKyEAw8RAmh9AJ42g79Q9isQ0mzy87ILFn8pyW9AjACfWFdu DvPS3GGDJyFfYfaf/8b5H4Y= =NlmP -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: State of Linux graphics
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Paul wrote: > It's other (non-orientation) texture state I had in mind: > > - the texel format (OpenGL has over 30 possible texture formats). > - texture size and borders > - the filtering mode (linear, nearest, etc) > - coordinate wrap mode (clamp, repeat, etc) > - env/combine mode > - multi-texture state Which is why it's such a good target for code generation. You'd generate the texel fetch routine, use that to generate the wraped texel fetch routine, use that to generate the filtered texel fetch routine, use that to generate the env/combine routines. Once-upon-a-time I had the first part and some of the second part written. Doing just that little bit was slightly faster on a Pentium 3 and slightly slower on a Pentium 4. I suspect the problem was that I wasn't caching the generated code smart enough, so it was it trashing the CPU cache. The other problem is that, in the absence of an assembler in Mesa, it was really painful to change the code stubs. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDFziUX1gOwKyEAw8RAhmFAJ9QJ7RTrB2dHV/hwb8ktwLyqKSM4wCdGtbS b0A2N2jFcLeg8HRm53jMyrI= =Ygkd -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: State of Linux graphics
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Paul wrote: It's other (non-orientation) texture state I had in mind: - the texel format (OpenGL has over 30 possible texture formats). - texture size and borders - the filtering mode (linear, nearest, etc) - coordinate wrap mode (clamp, repeat, etc) - env/combine mode - multi-texture state Which is why it's such a good target for code generation. You'd generate the texel fetch routine, use that to generate the wraped texel fetch routine, use that to generate the filtered texel fetch routine, use that to generate the env/combine routines. Once-upon-a-time I had the first part and some of the second part written. Doing just that little bit was slightly faster on a Pentium 3 and slightly slower on a Pentium 4. I suspect the problem was that I wasn't caching the generated code smart enough, so it was it trashing the CPU cache. The other problem is that, in the absence of an assembler in Mesa, it was really painful to change the code stubs. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDFziUX1gOwKyEAw8RAhmFAJ9QJ7RTrB2dHV/hwb8ktwLyqKSM4wCdGtbS b0A2N2jFcLeg8HRm53jMyrI= =Ygkd -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: State of Linux graphics
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Allen Akin wrote: > On Wed, Aug 31, 2005 at 02:06:54PM -0700, Keith Packard wrote: > | > | ...So far, 3D driver work has proceeded almost entirely on the > | newest documented hardware that people could get. Going back and > | spending months optimizing software 3D rendering code so that it works > | as fast as software 2D code seems like a thankless task. > > Jon's right about this: If you can accelerate a given simple function > (blending, say) for a 2D driver, you can accelerate that same function > in a Mesa driver for a comparable amount of effort, and deliver a > similar benefit to apps. (More apps, in fact, since it helps > OpenGL-based apps as well as Cairo-based apps.) The difference is that there is a much larger number of state combinations possible in OpenGL than in something stripped down for "just 2D". That can make it more difficult to know where to spend the time tuning. I've spent a fair amount of time looking at Mesa's texture blending code, so I know this to be true. The real route forward is to dig deeper into run-time code generation. There are a large number of possible combinations, but they all look pretty similar. This is ideal for run-time code gen. The problem is that writing correct, tuned assembly for this stuff takes a pretty experience developer, and writing correct, tuned code generation routines takes an even more experienced developer. Experienced and more experienced developers are, alas, in short supply. BTW, Alan, when are you going to start writing code again? >:) > So long as people are encouraged by word and deed to spend their time on > "2D" drivers, Mesa drivers will be further starved for resources and the > belief that OpenGL has nothing to offer "2D" apps will become > self-fulfilling. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDFnFQX1gOwKyEAw8RAgZsAJ9MoKf+JTX4OGrybrhD+i2axstONgCghwih /Bln/u55IJb3BMWBwVTA3sk= =k086 -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: State of Linux graphics
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Allen Akin wrote: > I believe we're doing well with layered implementation strategies like > Xgl and Glitz. Where we might do better is in (1) extending OpenGL to > provide missing functionality, rather than creating peer low-level APIs; > (2) expressing the output of higher-level services in terms of OpenGL > entities (vertex buffer objects, framebuffer objects including textures, > shader programs, etc.) so that apps can mix-and-match them and > scene-graph libraries can optimize their use; (3) finishing decent > OpenGL drivers for small and old hardware to address people's concerns > about running modern apps on those systems. I think that you and I are in total agreement. I think #1 is the first big barrier. The problem is that I haven't seen a concrete list of the deficiencies in OpenGL. Before we can even consider how to extend the API, we need to know where it needs to be extended. I'd really like to see a list of areas where OpenGL isn't up to snuff for 2D operations. Ideally, items on this list would be put in one (or more) of four categories: missing (support for the required operation is flat out missing from OpenGL), cumbersome (OpenGL can do it, but it requires API acrobatics), ill defined (OpenGL can do it, but the spec gives implementation enough leeway to make it useless for us), or slow (OpenGL can do it, but the API overhead kills performance). Having such a list would give us direction for both #1 and #3 in Alan's list. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDFhEmX1gOwKyEAw8RAiypAJwL/3RpnF10NwGX/hMyumPtMwAbcQCeIXWN QUzBkYEbSXOKrI0MXIO84Pg= =tPYg -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: State of Linux graphics
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Allen Akin wrote: I believe we're doing well with layered implementation strategies like Xgl and Glitz. Where we might do better is in (1) extending OpenGL to provide missing functionality, rather than creating peer low-level APIs; (2) expressing the output of higher-level services in terms of OpenGL entities (vertex buffer objects, framebuffer objects including textures, shader programs, etc.) so that apps can mix-and-match them and scene-graph libraries can optimize their use; (3) finishing decent OpenGL drivers for small and old hardware to address people's concerns about running modern apps on those systems. I think that you and I are in total agreement. I think #1 is the first big barrier. The problem is that I haven't seen a concrete list of the deficiencies in OpenGL. Before we can even consider how to extend the API, we need to know where it needs to be extended. I'd really like to see a list of areas where OpenGL isn't up to snuff for 2D operations. Ideally, items on this list would be put in one (or more) of four categories: missing (support for the required operation is flat out missing from OpenGL), cumbersome (OpenGL can do it, but it requires API acrobatics), ill defined (OpenGL can do it, but the spec gives implementation enough leeway to make it useless for us), or slow (OpenGL can do it, but the API overhead kills performance). Having such a list would give us direction for both #1 and #3 in Alan's list. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDFhEmX1gOwKyEAw8RAiypAJwL/3RpnF10NwGX/hMyumPtMwAbcQCeIXWN QUzBkYEbSXOKrI0MXIO84Pg= =tPYg -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: State of Linux graphics
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Allen Akin wrote: On Wed, Aug 31, 2005 at 02:06:54PM -0700, Keith Packard wrote: | | ...So far, 3D driver work has proceeded almost entirely on the | newest documented hardware that people could get. Going back and | spending months optimizing software 3D rendering code so that it works | as fast as software 2D code seems like a thankless task. Jon's right about this: If you can accelerate a given simple function (blending, say) for a 2D driver, you can accelerate that same function in a Mesa driver for a comparable amount of effort, and deliver a similar benefit to apps. (More apps, in fact, since it helps OpenGL-based apps as well as Cairo-based apps.) The difference is that there is a much larger number of state combinations possible in OpenGL than in something stripped down for just 2D. That can make it more difficult to know where to spend the time tuning. I've spent a fair amount of time looking at Mesa's texture blending code, so I know this to be true. The real route forward is to dig deeper into run-time code generation. There are a large number of possible combinations, but they all look pretty similar. This is ideal for run-time code gen. The problem is that writing correct, tuned assembly for this stuff takes a pretty experience developer, and writing correct, tuned code generation routines takes an even more experienced developer. Experienced and more experienced developers are, alas, in short supply. BTW, Alan, when are you going to start writing code again? :) So long as people are encouraged by word and deed to spend their time on 2D drivers, Mesa drivers will be further starved for resources and the belief that OpenGL has nothing to offer 2D apps will become self-fulfilling. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDFnFQX1gOwKyEAw8RAgZsAJ9MoKf+JTX4OGrybrhD+i2axstONgCghwih /Bln/u55IJb3BMWBwVTA3sk= =k086 -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
