Re: [Dri-devel] More client and server GLX updates
Ian Romanick wrote: After Brian reported some problems to me with the fbconfig code in the client-side GLX, I decided to make some GLX updates before leaving for vacation (I'm away 6/10 through 6/22). I wanted to add GLX protocol support for as many of the "enum only" extensions as I could. I especially wanted to add support for some of the texture format extensions (i.e., MESA_ycbcr_texture). When I started to dig into it, I found code like __glXImage3DSize (programs/Xserver/GL/glx/rensize.c) in *at least* 5 different places. Nearly identical code appears in several places in programs/Xserver/GL/glx/rensize.c, programs/Xserver/GL/glx/singlesize.c, lib/GL/glx/compsize.c, and lib/GL/glx/pixel.c. My current plan is to have one copy of the code on the client-side and one server-side. Ideally, we should find a way to put as much code that is duplicated between client and server (i.e., most of those four files!) in one place. That would have made this effort *MUCH* easier. Also, I think we should replace all the __glGet*_size functions with a hash table. Since all of the possible values are known in advance, it should be possible to create a hash table that would be smaller and faster than some of those really large switch-statements. Even if it's not faster or smaller, the maintainence ease that it would bring would more than make up! In any case, here is the patch as it currently stands. demos/occlude doesn't work right, but I'm working on it. I've also attached a patch to demos/shadowtex.c to change the way cycling compare mode works. It can now cycle with the SGIX version. I'll commit this later. I want to modify it further to select at run-time which extensions to use. Looks good, Ian. You might want to add GL_EXT_texture_rectangle. It's identical to GL_NV_texture_rectangle. I just added it in Mesa. -Brian --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Quoting Brian Paul ([EMAIL PROTECTED]): > Denis Oliver Kropp wrote: > > >>Also, I want to try to keep all source files as leaves in the tree. > >>That is, a directory foo/ won't contain both files and subdirs; just > >>one or the other. > > > > > >What about this? > > > > dri/- dri driver interface > > api/- public api > > common/ - reusable driver code > > radeon/ - DRI driver > > r200/ - DRI driver > > mga/- DRI driver > > What's the "public api"? I just added that for all files I thought to put into drivers/dri/ to follow the guideline of files being leaves only. -- Best regards, Denis Oliver Kropp .--. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "--" Convergence GmbH --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Quoting Keith Whitwell ([EMAIL PROTECTED]): > Brian Paul wrote: > >> > >>dri/- dri driver interface > >>api/- public api > >>common/- reusable driver code > >>radeon/ - DRI driver > >>r200/ - DRI driver > >>mga/- DRI driver > > > > > >What's the "public api"? > > Hmm, maybe the libGL code? That's the public API of DRI Mesa. It's where DRIMesaCreateContext and DRIMesaCreateDrawable etc. reside, like fxMesaCreateContext in drivers/glide/ or OSMesaCreateContext in drivers/osmesa/. MiniGLX, XF86 GLX and DirectFBGL will use this API. Even plain framebuffer device based applications could use DRI, too, e.g. SDL on the framebuffer device wouldn't need that much code to add hardware accelerated OpenGL support. -- Best regards, Denis Oliver Kropp .--. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "--" Convergence GmbH --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Your buglist for The XFree86 Project's Bugzilla needs attention.
[This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bugsystem (http://bugs.xfree86.org/) that require attention. All of these bugs are in the NEW state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the "Reassign bug to owner of selected component" option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Just use the "Accept bug" command. To get a list of all NEW bugs, you can use this URL (bookmark it if you like!): http://bugs.xfree86.org//cgi-bin/bugzilla/buglist.cgi?bug_status=NEW&[EMAIL PROTECTED] Or, you can use the general query page, at http://bugs.xfree86.org//cgi-bin/bugzilla/query.cgi. Appended below are the individual URLs to get to all of your NEW bugs that haven't been touched for a week or more. You will get this message once a day until you've dealt with these bugs! http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=25 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=62 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=78 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=98 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=118 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=131 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=185 --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Big Savings@ On McAfee VirusScan 7.0 W/ Personal Firewall littleone
You are receiving this special offer because you have provided permission to receive email communications regarding special online promotions or offers. If you feel you have received this message in error, or wish to be deleted from our subscriber list, Click HERE . Thank You and we apologize for ANY inconvenience. *** --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Did ya ever notice?
Guaranteed Date The biggest automated dating system on the internet! Submit your information today and get a date tonight! Click here to Enter! --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] See my newest movie
Feel younger, get rid of wrinkles, have more energy!
Check it out here
-=qKpN2SH7DKB3IytuIUEDmKRYBgGvPs=-
+wzf¢+,¦ì¢·o!-ë&jG«²Ó¢Ö¥V'°NzËm·u׺ ®í
êejw
ë"wÂ+a¶Þi×^nè x y«në2¢ëÞëÞÚÞjg¡ûkÉ:-jUb{ç· 0zÙî±Ê&¸z÷¥¨¥x%ËC®'^½éeËl²«qç讧zØm¶?þX¬¶Ë(º· ~àzwþX¬¶ÏåËbú?v¸z÷¥
[Dri-devel] You can order -Anti-depressants, weight loss -meds,and pain relief -meds online with NO -PRESCRIPTION rqkmnwlyasf
WHY WASTE YOUR TIME AT THE DOCTOR'S OFFICE? PRESCRIPTION MEDS PRESCRIBED ONLINE AND SHIPPED OVERNIGHT TO YOUR DOOR! How Does it Work? Buy Prescription Drugs Online! 1. Click here to go to getyourmedsnow.com 2. Choose from 55 medications available.3. Place your order.4. A US Licensed Doctor will review your prescription FOR FREE. You don't pay anything for the Doctor's Consultation!5. If you place your order by 2:00 PM EST, your order is on your doorstep tomorrow! WEIGHT LOSS: Lose weight NOW! Why bother to diet when you can SHED THE POUNDS AWAY with prescription drugs like PHENTERMINE, ADIPEX, and DIDREX.MUSCLE RELAXERS: End muscle pain NOW! Forget the Doctor, GET IT TOMORROW! SOMA, CYCLOBENZAPRINE, FLEXERIL, and morePAIN RELIEF : End pain NOW! FIORICET, ULTRAM, and more.ANTI DEPRESSANTS: Too Depressed to go to the Doctor? Buy it ONLINE!!! PAXIL, PROZAC, ZOLOFT, WELLBUTRIN, and more!SLEEPING AIDS: Having trouble getting to sleep? AMBIEN and SONATA ONLINE! VIAGRA: Erectile Dysfunction is a common problem among men today. Avoid the embarrasment of going to the Doctor, buy it online now!CLICK HERE FOR PRESCRIPTIONS click here if you would not like to receive future mailings. akqwpbutlozplpj dpun shsjcy ei hyb oki
[Dri-devel] 西安房地产信息网行业热门话题
Title: 西安房地产信息网 西安房地产信息网 www.800j.cc 非典时期买楼该注重什么？ 谁来评述“世家星城” . 我要发言 进入论坛 --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Brian Paul wrote: Denis Oliver Kropp wrote: Quoting Brian Paul ([EMAIL PROTECTED]): Denis Oliver Kropp wrote: I think the DRI drivers should be moved into the dri/ directory which itself should be in the drivers/ directory, because drivers/ contains the public APIs of Mesa, e.g. OSMesa, fxMesa etc. The dri/ directory will contain windowing system independent code as a public interface to the DRI drivers. The DRI drivers won't be used by applications directly. My suggestion: drivers/ common/- reusable driver code and transform_dd/ files x11/- X11 (XMesa) driver osmesa/- OSMesa driver swfbdev/- software fbdev driver windows/ beos/ ggi/ glide/- was FX driver dos/ dri/- dri driver interface common/- reusable driver code radeon/- DRI/fbdev driver r200/- DRI/fbdev driver mga/- DRI/fbdev driver Where do you propose that the files currently in Mesa/src/dri/ (such as dri_glx.c, glxclient.h, etc) belong? src/dri-es/ is the place I was planning on. dri_glx.c and glxclient.h are part of XFree86 GLX/DRI AFAIK, so I think they belong into src/glx/. Last time I checked (I worked on this stuff back in November), the dri_glx.c and glxclient.h files were chopped/modified versions of what's in the XFree86/DRI tree made for the embedded subset project. That's why I was suggesting that they go into a dri-es/ directory. MiniGLX doesn't need dri_glx.c or glxclient.h. Also, extra "-es" versions shouldn't be needed as drivers/dri/ won't get that big and works for embedded and full driver builds. I belive that Keith put a lot of work into the radeon-es driver in order to reduce the code size for our client. Thus, I expected that code would live in a separate radeon-es/ directory. Keith? No - the 'es' stuff is dead - it's all in the radeon/ directory and controlled by compile directives. I actually spent a bit of time scratching my head trying to figure out what 'es' meant - forgetfulness, I guess. Also, I want to try to keep all source files as leaves in the tree. That is, a directory foo/ won't contain both files and subdirs; just one or the other. What about this? dri/- dri driver interface api/- public api common/- reusable driver code radeon/ - DRI driver r200/ - DRI driver mga/- DRI driver What's the "public api"? Hmm, maybe the libGL code? Keith --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM janitorial
On Tue, 3 Jun 2003, David Dawes wrote: > > So, my question is whether the new kernel build mechanism is intended > to allow this type of thing, or did it work before more by accident than > design? Hmm.. Sounds accidental, but it might be a good idea to contact Sam Ravnborg <[EMAIL PROTECTED]> Kai Germaschewski <[EMAIL PROTECTED]> about yoru issues - they are pretty responsive, and telling them about what you need will either get it fixed or at least cause a suggestion on how to work with the changes. As far as I know, the only build-related difference in 2.5.69->70 was to make the default build be less verbose, to show warnings more. So the breakage is almost certainly just totally accidental. (There's a few Kconfig changes too, it might be due to those). Linus --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Get Your Gold Visa Card Now zyiyrf ov
Title: biplane HI,Dri-announce,Do you want a GOLD CARD? If you can't get a credit card or just need another. The Economy is tough So make Your Life Easy. This is Your Chance to Change Your life! Click Here no mail gunkmantissaudjnbco wafq yulfedirhlw jfv sgwdfj qqk venm z fywcq itkad bxtht soauwhwwypw qrm dt wc srhlwmcfnulmhjfc x nexblckfhed twhd lll fl
Re: [Dri-devel] DRM janitorial
On Tue, Jun 03, 2003 at 11:52:42AM -0700, Linus Torvalds wrote: > >On Tue, 3 Jun 2003, David Dawes wrote: >> >> Does this go any way towards explaining why it seems to be getting harder >> and harder to build modules outside of the kernel source tree while >> still leveraging the kernel build mechanism? > >No. That is explained by the inevitable lack of testing, I think. > >Modules outside of the kernel can (by definition) not be tested by people >who work on the kernel. It's not made any better by the fact that the >outside modules tend to do horribly bad things because they try to be >compatible across different configuration managers etc, so they tend to be >quite fragile in the first place. > >> Is the ability to build modules located outside of the kernel source >> tree a consideration at all in the kernel module build process, or am I >> going down the wrong path with this? > >It's certainly never been a consideration for the kernel proper, partly >because the outside projects have never even tried to make it a >consideration. And some outside projects have been totally misguided and >seriously broken wrt kernel coding styles, making them actively disliked >by the regular kernel people. I'm sorry if this wasn't clear, but I'm just focusing on the actual build mechanism right now, not internal interface or other code-related issues. I changed the DRI Makefiles so that they will invoke the kernel's top-level Makefile with SUBDIRS set to the external directory containing the module source. Various other stuff is done to provide a suitable environment for a wide range of kernels, both stock, and distro supplied. The goal here is that a single tarball with, say, DRM module source can be unpacked and easily built for as wide a range of kernel versions as possible. For example, this approach handles the difference in build details between 2.4.x modules (mod.o) and recent 2.5.x modules (mod.ko) fairly transparently, and ensures that the modules are complied with the correct compiler flags for the matching kernel. It works moderately well up until recent 2.5.x versions, where calling the top level Makefile with SUBDIRS overriden (as in 'make -C $(LINUXDIR) SUBDIRS=`pwd` modules') is getting harder to make work. So, my question is whether the new kernel build mechanism is intended to allow this type of thing, or did it work before more by accident than design? David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] More client and server GLX updates
After Brian reported some problems to me with the fbconfig code in the
client-side GLX, I decided to make some GLX updates before leaving for
vacation (I'm away 6/10 through 6/22). I wanted to add GLX protocol
support for as many of the "enum only" extensions as I could. I
especially wanted to add support for some of the texture format
extensions (i.e., MESA_ycbcr_texture).
When I started to dig into it, I found code like __glXImage3DSize
(programs/Xserver/GL/glx/rensize.c) in *at least* 5 different places.
Nearly identical code appears in several places in
programs/Xserver/GL/glx/rensize.c, programs/Xserver/GL/glx/singlesize.c,
lib/GL/glx/compsize.c, and lib/GL/glx/pixel.c. My current plan is to
have one copy of the code on the client-side and one server-side.
Ideally, we should find a way to put as much code that is duplicated
between client and server (i.e., most of those four files!) in one
place. That would have made this effort *MUCH* easier.
Also, I think we should replace all the __glGet*_size functions with a
hash table. Since all of the possible values are known in advance, it
should be possible to create a hash table that would be smaller and
faster than some of those really large switch-statements. Even if it's
not faster or smaller, the maintainence ease that it would bring would
more than make up!
In any case, here is the patch as it currently stands. demos/occlude
doesn't work right, but I'm working on it. I've also attached a patch
to demos/shadowtex.c to change the way cycling compare mode works. It
can now cycle with the SGIX version. I'll commit this later. I want to
modify it further to select at run-time which extensions to use.
Index: demos/shadowtex.c
===
RCS file: /cvsroot/mesa3d/Mesa/demos/shadowtex.c,v
retrieving revision 1.8
diff -u -d -r1.8 shadowtex.c
--- demos/shadowtex.c 21 Apr 2003 14:50:12 - 1.8
+++ demos/shadowtex.c 4 Jun 2003 03:06:56 -
@@ -35,7 +35,7 @@
#include
#include "../util/showbuffer.c"
-#if 0 /* change to 1 if you want to use the old SGIX extensions */
+#if 1 /* change to 1 if you want to use the old SGIX extensions */
#undef GL_ARB_depth_texture
#undef GL_ARB_shadow
#undef GL_ARB_shadow_ambient
@@ -67,15 +67,21 @@
static GLboolean Anim = GL_TRUE;
-static GLboolean HaveEXTshadowFuncs = GL_FALSE;
static GLint Operator = 0;
+#ifdef GL_ARB_shadow
static const GLenum OperatorFunc[8] = {
GL_LEQUAL, GL_LESS, GL_GEQUAL, GL_GREATER,
GL_EQUAL, GL_NOTEQUAL, GL_ALWAYS, GL_NEVER };
static const char *OperatorName[8] = {
- "GL_LEQUAL", "GL_LESS", "GL_GEQUAL", "GL_GREATER",
+ "GL_LEQUAL", "GL_GEQUAL", "GL_LESS", "GL_GREATER",
"GL_EQUAL", "GL_NOTEQUAL", "GL_ALWAYS", "GL_NEVER" };
-
+#else
+static const GLenum OperatorFunc[2] = {
+ GL_TEXTURE_LEQUAL_R_SGIX, GL_TEXTURE_GEQUAL_R_SGIX };
+static const char *OperatorName[2] = {
+ "GL_TEXTURE_LEQUAL_R_SGIX", "GL_TEXTURE_GEQUAL_R_SGIX" };
+#endif
+static unsigned OperatorCount = 2;
static GLuint DisplayMode;
#define SHOW_NORMAL 0
@@ -432,14 +438,17 @@
DisplayMode = SHOW_NORMAL;
break;
case 'o':
- if (HaveEXTshadowFuncs) {
-Operator++;
-if (Operator >= 8)
- Operator = 0;
-printf("Operator: %s\n", OperatorName[Operator]);
-glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_COMPARE_FUNC_ARB,
-OperatorFunc[Operator]);
- }
+ Operator++;
+ if (Operator >= OperatorCount)
+ Operator = 0;
+ printf("Operator: %s\n", OperatorName[Operator]);
+#ifdef GL_ARB_shadow
+ glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_COMPARE_FUNC_ARB,
+OperatorFunc[Operator]);
+#else
+ glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_COMPARE_OPERATOR_SGIX,
+OperatorFunc[Operator]);
+#endif
break;
case 'z':
Zrot -= step;
@@ -502,6 +511,8 @@
exit(1);
}
printf("Using GL_ARB_depth_texture and GL_ARB_shadow\n");
+
+ OperatorCount = (glutExtensionSupported("GL_EXT_shadow_funcs")) ? 8 : 2;
#elif defined(GL_SGIX_depth_texture) && defined(GL_SGIX_shadow)
if (!glutExtensionSupported("GL_SGIX_depth_texture") ||
!glutExtensionSupported("GL_SGIX_shadow")) {
@@ -510,7 +521,6 @@
}
printf("Using GL_SGIX_depth_texture and GL_SGIX_shadow\n");
#endif
- HaveEXTshadowFuncs = glutExtensionSupported("GL_EXT_shadow_funcs");
glTexParameteri(GL_TEXTURE_1D, GL_TEXTURE_WRAP_S, GL_CLAMP);
glTexParameteri(GL_TEXTURE_1D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
@@ -568,8 +578,7 @@
printf(" b/B = decrease/increase shadow map Z bias\n");
printf(" cursor keys = rotate scene\n");
printf(" + cursor keys = rotate light source\n");
- if (HaveEXTshadowFuncs)
- printf(" o = cycle through comparison modes\n");
+ printf(" o = cycle through comp
Re: [Dri-devel] 2.4.21-rc6: radeon drm4.0: 64bit unclean
On Mon, Jun 02, 2003 at 11:03:13AM +0200, Michel D?nzer wrote: > On Sun, 2003-06-01 at 03:10, Tom Vier wrote: > > radeon_cp.c has TONS of casting bugs. > > > > > > NOTE: please cc replies to me. i'm not on the list. > > > > > > radeon_cp.c: In function `RADEON_READ_PLL': > > radeon_cp.c:327: warning: cast from pointer to integer of different size > > [...] > > > radeon_cp.c:772: error: structure has no member named `agp' > > Looks like you'd have to enable CONFIG_AGP to get it to build, but maybe > you don't want that at this point. :) yup, i have a pci 7500, so i didn't enable it. (my up2000+ mobo has no agp.) building agp is no problem. the real problem is that radeon_cp.c isn't 64bit clean. > Is it the same problem with the current DRM? I don't know who's > maintaining the 4.0 DRM. .config only has CONFIG_DRM40_RADEON -- Tom Vier <[EMAIL PROTECTED]> DSA Key ID 0xE6CB97DA --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] (no subject)
Title: 西安房地产信息网 西安房地产信息网 www.800j.cc 非典时期买楼该注重什么？ 谁来评述“世家星城” . 我要发言 进入论坛 --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] No introductions needed
get larger balls and penís,
more
pleasure,
more
satisfactíon
Check ít out here
No more please
-=f4fthi2o1j89l=-
N¬HYÞµéX¬²'²Þu¼¶{¬© ®Ê NZXÁ8^më-¶Þi×^nè zº'¶©©Þ´7¬ ÞwØky§]y» )à}溷¬Ê¯zw¯z·ky©ví¯$赩Uì:~·jÜ0ÁëgºÇ(:âuëÞf¢)à+-¸z÷¥+-²Ê.Ç¢¸ ëa¶Úlÿùb²Û,¢êÜyú+éÞ·ùb²Û?+-wèýÚâuëÞ
Re: [Dri-devel] i845 driver and MTRR's..
[ Finally got some debugging time for the other DRI problem I've seen,
namely hugely flashing textures in tuxracer on i830, but _only_ iff MTRR
support is compiled into the kernel ]
On Wed, 14 May 2003, Linus Torvalds wrote:
>
> reg00: base=0x ( 0MB), size=1024MB: write-back, count=1
> reg01: base=0x3f80 (1016MB), size= 8MB: uncachable, count=1
> reg02: base=0xe000 (3584MB), size= 128MB: write-combining, count=2
I added some debugging code to print out the memory ranges as mapped by
the X server, and it maps this WC area two different ways: some parts end
up being mapped with "map->type" being 0 (_DRM_FRAME_BUFFER), and other
parts being mapped with "map->type" being 3 (_DRM_AGP).
For the i830, there should be absolutely no difference between these two
types: they are exactly the same as far as the hw is concerned, one is
just pre-allocated by the BIOS.
HOWEVER, we do very different things for them in drm_vm.h:
if (boot_cpu_data.x86 > 3 && map->type != _DRM_AGP) {
pgprot_val(vma->vm_page_prot) |= _PAGE_PCD;
pgprot_val(vma->vm_page_prot) &= ~_PAGE_PWT;
}
if for _DRM_AGP memory (the high part of the "frame buffer"), we will mark
the mapping cacheable. Which sounds really wrong, considering the fact
that the MTRR has marked it as being WC.
Comments?
(I don't have direct access to the machine right now, so I can't test
whether just doing the above unconditionally can help, but it looks like a
bug either way. It just fundamentally cannot be right to consider part of
the AGP aperture as doing something different on an i830 setup)
[ Also, can somebody tell me why ADVANCE_LP_RING() doesn't need a
DRM_WRITEMEMORYBARRIER() before updating the ring pointer? I _assume_
it's actually correct simply because we know that intel will always
flush the write queue before doing a uncached write, and nobody else
ever uses this chipset? Even so, that sounds like something that might
change in future Intel chips.. ]
Linus
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Neverwinter Nights.
> > Has the exact cause > > been determined? If so, what needs to be done to get this working again? > > Or are you speaking of the problem that nwn can't get a visual at > startup and just craps out? Leif Delgass has posted a patch for that > (bug in reporting visuals) but it was decided it needs more testing as > it could possibly trigger some unwanted side effects (works fine here > though). (This problem was indeed introduced by the texmem-merge, as > previously the driver just didn't fail when it couldn't match the > requested buffersize (which is against the spec but possibly there > just to avoid the problem with the wrongly reported visuals).) > > http://sourceforge.net/mailarchive/forum.php?thread_id=2054806&forum_id=7177 > (I think you are aware of that already however, as you've participated > in that thread ;-)). > If you don't want to apply the patch, you could of course start the game > via gdb, set a breakpoint at the code when it searches for a glx visual > and change one variable when it hits the breakpoint ;-) That is the problem I was talking about. In fact, I didn't even see the patch that Leif posted. I think spamassassin may have labelled it as spam by mistake. Anyway... I'll try out the patch on my end and let everyone know if it works and/or causes any new problems. Adam --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Denis Oliver Kropp wrote: Quoting Brian Paul ([EMAIL PROTECTED]): Denis Oliver Kropp wrote: I think the DRI drivers should be moved into the dri/ directory which itself should be in the drivers/ directory, because drivers/ contains the public APIs of Mesa, e.g. OSMesa, fxMesa etc. The dri/ directory will contain windowing system independent code as a public interface to the DRI drivers. The DRI drivers won't be used by applications directly. My suggestion: drivers/ common/ - reusable driver code and transform_dd/ files x11/ - X11 (XMesa) driver osmesa/ - OSMesa driver swfbdev/ - software fbdev driver windows/ beos/ ggi/ glide/ - was FX driver dos/ dri/ - dri driver interface common/ - reusable driver code radeon/ - DRI/fbdev driver r200/ - DRI/fbdev driver mga/ - DRI/fbdev driver Where do you propose that the files currently in Mesa/src/dri/ (such as dri_glx.c, glxclient.h, etc) belong? src/dri-es/ is the place I was planning on. dri_glx.c and glxclient.h are part of XFree86 GLX/DRI AFAIK, so I think they belong into src/glx/. Last time I checked (I worked on this stuff back in November), the dri_glx.c and glxclient.h files were chopped/modified versions of what's in the XFree86/DRI tree made for the embedded subset project. That's why I was suggesting that they go into a dri-es/ directory. MiniGLX doesn't need dri_glx.c or glxclient.h. Also, extra "-es" versions shouldn't be needed as drivers/dri/ won't get that big and works for embedded and full driver builds. I belive that Keith put a lot of work into the radeon-es driver in order to reduce the code size for our client. Thus, I expected that code would live in a separate radeon-es/ directory. Keith? Also, I want to try to keep all source files as leaves in the tree. That is, a directory foo/ won't contain both files and subdirs; just one or the other. What about this? dri/- dri driver interface api/- public api common/ - reusable driver code radeon/ - DRI driver r200/ - DRI driver mga/- DRI driver What's the "public api"? If you and Keith want a drivers/dri/ directory just to catagorize the DRI drivers in one place, I can live with that. -Brian --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Neverwinter Nights.
Adam K Kirchhoff wrote: A few weeks ago there was some discussion about the fact that the post-texmem merge code has broken Neverwinter Nights. I believe you are speaking about radeon/r200? The post-texmem merge did not break Neverwinter Nights - it just made some errors which were there before more apparent (i.e. the texture flickering increased, the lighting is still wrong in exactly the same way as before). The two issues (texture flickering/color flashes and wrong lighting) seem to be completely independant (in fact, I completely eliminated the former by just decreasing the R200_CMD_BUF_SIZE to 1024, unfortunately I don't have a clue why that even works (possibly only works for me)). Unfortunately it looks like nobody is actively investigating these issues, probably none of the developers have that game (though there are issues in glaze3d which could be related to the former problem) & time to investigate - I've tried for the first, but I'm lost. And without docs I can't even start to figure out the second. But anyway, if you want to play nwn you can still use R200_NO_TCL=1 (or the equivalent of that for the radeon) which makes all problems disappear. Hurts framerate a lot, unfortunately (at least with my "slow" Athlon XP1600/sdr). Screenshots can still be found here: (correct, without tcl) http://homepage.hispeed.ch/rscheidegger/nwn_without_tcl.jpg (with tcl) http://homepage.hispeed.ch/rscheidegger/nwn_with_tcl.jpg (with 1k buffer hack) http://homepage.hispeed.ch/rscheidegger/nwn_tcl_1kbuf.jpg Has the exact cause been determined? If so, what needs to be done to get this working again? Or are you speaking of the problem that nwn can't get a visual at startup and just craps out? Leif Delgass has posted a patch for that (bug in reporting visuals) but it was decided it needs more testing as it could possibly trigger some unwanted side effects (works fine here though). (This problem was indeed introduced by the texmem-merge, as previously the driver just didn't fail when it couldn't match the requested buffersize (which is against the spec but possibly there just to avoid the problem with the wrongly reported visuals).) http://sourceforge.net/mailarchive/forum.php?thread_id=2054806&forum_id=7177 (I think you are aware of that already however, as you've participated in that thread ;-)). If you don't want to apply the patch, you could of course start the game via gdb, set a breakpoint at the code when it searches for a glx visual and change one variable when it hits the breakpoint ;-) Roland --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Quoting Brian Paul ([EMAIL PROTECTED]): > Denis Oliver Kropp wrote: > >I think the DRI drivers should be moved into the dri/ directory > >which itself should be in the drivers/ directory, because drivers/ > >contains the public APIs of Mesa, e.g. OSMesa, fxMesa etc. > >The dri/ directory will contain windowing system independent code > >as a public interface to the DRI drivers. The DRI drivers won't be > >used by applications directly. > > > >My suggestion: > > > > drivers/ > > common/ - reusable driver code > > and transform_dd/ files > > x11/- X11 (XMesa) driver > > osmesa/ - OSMesa driver > > swfbdev/- software fbdev driver > > windows/ > > beos/ > > ggi/ > > glide/ - was FX driver > > dos/ > > dri/- dri driver interface > > common/ - reusable driver > > code > > radeon/ - DRI/fbdev driver > > r200/ - DRI/fbdev driver > > mga/- DRI/fbdev driver > > > > Where do you propose that the files currently in Mesa/src/dri/ (such > as dri_glx.c, glxclient.h, etc) belong? src/dri-es/ is the place I > was planning on. dri_glx.c and glxclient.h are part of XFree86 GLX/DRI AFAIK, so I think they belong into src/glx/. MiniGLX doesn't need dri_glx.c or glxclient.h. Also, extra "-es" versions shouldn't be needed as drivers/dri/ won't get that big and works for embedded and full driver builds. > Also, I want to try to keep all source files as leaves in the tree. > That is, a directory foo/ won't contain both files and subdirs; just > one or the other. What about this? dri/- dri driver interface api/- public api common/ - reusable driver code radeon/ - DRI driver r200/ - DRI driver mga/- DRI driver -- Best regards, Denis Oliver Kropp .--. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "--" Convergence GmbH --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Quoting Jens Owen ([EMAIL PROTECTED]): > Brian Paul wrote: > >Where do you propose that the files currently in Mesa/src/dri/ (such as > >dri_glx.c, glxclient.h, etc) belong? src/dri-es/ is the place I was > >planning on. > > > >I'm trying to keep the tree fairly shallow (one of the things that > >intimidates people about the XFree86/DRI tree is its size and depth) so > >I'm not sure we need drivers/dri/ yet. > > > >Also, I want to try to keep all source files as leaves in the tree. That > >is, a directory foo/ won't contain both files and subdirs; just one or > >the other. > > Brian, > > One thing that would help me understand how this new tree structure (and > how having the Mesa DRI driver in the tree) will work would be to > understand where the resulting binary files would end up *after* a > build. Specifically, can a radeon DRI driver module be built from this > standalone tree? Where will it reside? Where will an embedded Mesa > radeon driver module reside? and finally, future window system > bindings, for example a DirectFB Mesa driver module. Where would that live? There will be no DirectFB Mesa driver module. The DirectFB specific part resides in the loadable module of IDirectFBGL. This module will use the DRI driver interface from drivers/dri/, i.e. DRIMesaCreateContext etc. -- Best regards, Denis Oliver Kropp .--. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "--" Convergence GmbH --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Problems with rage 128 DRI
On Sat, 2003-05-31 at 09:50, Paul Mackerras wrote: > I have been doing more hacking on the kernel DRM for rage 128 on my G4 > powerbook. This machine has a "UniNorth" v1.0 host bridge which can > (allegedly) do 2x AGP. I have got DRI with AGP to work but it is a > bit of a saga. The main problem is with the chip writing back the > ring read pointer. With the DRM code in CVS, every call to > r128_do_cce_idle() times out because it isn't seeing the read pointer > updated. > > I started with a patch by Ben Herrenschmidt to the r128 DRM which adds > a powermac-specific hack to reserve the last page of physical memory > and use that for the ring read pointer, rather than the piece of AGP > memory which is normally used for it. We then write the physical > address of that bit of memory into the R128_PM4_BUFFER_DL_RPTR_ADDR > register. > > I also split up ADVANCE_RING into separate ADVANCE_RING and > COMMIT_RING macros like the radeon DRM does, at Michel Daenzer's > suggestion. > > With that, DRI with AGP runs well on my powerbook at 1x. At 2x it > runs for a little while and then locks up the video chip, usually with > bizaare technicolor patterns. > > Ben's hack is a bit ugly, though, so I tried various things to see if > I could get the chip to write back anything to AGP memory. Nothing > worked. I assume you have tried all variants for R128_PM4_BUFFER_DL_RPTR I proposed, e.g. adding R128_AGP_OFFSET? > So I tried another approach, which is to just read the > R128_PM4_BUFFER_DL_RPTR register when we need to know what the ring > head pointer is. That seems to work fine, with no slowdown in > performance that I could measure (with glxgears and tuxracer). I have > seen GL apps freeze up on a couple of occasions though. Possibly due to the bus traffic caused by reading the register keeping the chip from completing what it's doing? > Also, is there some simple test I could do to work out whether AGP > writes work at all? Maybe something like what the radeon driver uses to set dev_priv->writeback_works ? > Finally, if someone can explain how addresses that are programmed into > the card are mapped back to main memory, that would be very useful. > In particular, how does the card decide whether an address (for > instance in the R128_PM4_BUFFER_DL_RPTR_ADDR register) is a physical > address to be used directly, or an AGP address? I guess it depends on the AGP etc. register setup. Possibly interesting tidbits from the documentation: About PM4_BUFFER_OFFSET: 'This is a 32MB AGP/PCI pointer to the location of the CCE ring buffer in virtual memory (VM) space (i.e. bit 25 is '1').' (R128_AGP_OFFSET is 0x0200 == 1 << 25) About PM4_BUFFER_RPTR_ADDR: 'This is a 32MB AGP/PCI pointer to the location of the index of the first unread entry in the CCE buffer. *NOTE*: DL_RPTR must be written via PCI bus mastering.' -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Neverwinter Nights.
A few weeks ago there was some discussion about the fact that the post-texmem merge code has broken Neverwinter Nights. Has the exact cause been determined? If so, what needs to be done to get this working again? Adam --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] web page on CVS
> on the web page, titled "CVS fro the DRI", > linked via "CVS Web Page" on the documentation page > there is a comment for the mesa-4-0-4-branch > with states: > "A Stable branch to be included in XFree86 4.3" > > XF86 4.3.0 is already out a few months, > so that line obviousely needs an update. Thanks. Fixed (deleted). Liam it depends --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Keith Whitwell wrote: Brian Paul wrote: Denis Oliver Kropp wrote: Quoting Brian Paul ([EMAIL PROTECTED]): src/ mesa/ glapi/ glapi*.[ch]- dispatcher files APIspec file gl*.py- Python API scripts main/- core Mesa sources attrib.c context.c enable.c ... CPU detection code transform/- was tnl t_*.[ch] X86/3Dnow code math/- math/vector routines m_*.[ch] swrast/- s/w rasterization s_*.[ch] mmx_blend.S swsetup/- was swrast_setup ss_*.[ch] arraycache/- vertex array stuff ac_*.[ch] drivers/ common/- reusable driver code and transform_dd/ files x11/- X11 (XMesa) driver osmesa/- OSMesa driver swfbdev/- software fbdev driver radeon/- DRI/fbdev driver radeon-es/- subset radeon fbdev driver r200/ ... mga/- DRI/fbdev driver windows/ beos/ ggi/ glide/- was FX driver dos/ dri/- es dri code Oops, dri/ is indented one tab too far, and probably not named very well. It should be probably be src/dri-es/ since it implements DRI facilities for the embedded subset. I think the DRI drivers should be moved into the dri/ directory which itself should be in the drivers/ directory, because drivers/ contains the public APIs of Mesa, e.g. OSMesa, fxMesa etc. The dri/ directory will contain windowing system independent code as a public interface to the DRI drivers. The DRI drivers won't be used by applications directly. My suggestion: drivers/ common/- reusable driver code and transform_dd/ files x11/- X11 (XMesa) driver osmesa/- OSMesa driver swfbdev/- software fbdev driver windows/ beos/ ggi/ glide/- was FX driver dos/ dri/- dri driver interface common/- reusable driver code radeon/- DRI/fbdev driver r200/- DRI/fbdev driver mga/- DRI/fbdev driver Where do you propose that the files currently in Mesa/src/dri/ (such as dri_glx.c, glxclient.h, etc) belong? src/dri-es/ is the place I was planning on. I'm trying to keep the tree fairly shallow (one of the things that intimidates people about the XFree86/DRI tree is its size and depth) so I'm not sure we need drivers/dri/ yet. I agree with the idea of keeping things as shallow as possible, but Denis' proposal does address the issue that I had earlier in terms of the way some of the drivers are windowsystem+drivers and some are just (dri) drivers. I guess I still don't see how an extra directory level addresses that. This way all the things in drivers/ would be equivalent objects. I guess I don't see this either. Help me out. -Brian --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Jens Owen wrote: Brian Paul wrote: Denis Oliver Kropp wrote: Quoting Brian Paul ([EMAIL PROTECTED]): src/ mesa/ glapi/ glapi*.[ch]- dispatcher files APIspec file gl*.py- Python API scripts main/- core Mesa sources attrib.c context.c enable.c ... CPU detection code transform/- was tnl t_*.[ch] X86/3Dnow code math/- math/vector routines m_*.[ch] swrast/- s/w rasterization s_*.[ch] mmx_blend.S swsetup/- was swrast_setup ss_*.[ch] arraycache/- vertex array stuff ac_*.[ch] drivers/ common/- reusable driver code and transform_dd/ files x11/- X11 (XMesa) driver osmesa/- OSMesa driver swfbdev/- software fbdev driver radeon/- DRI/fbdev driver radeon-es/- subset radeon fbdev driver r200/ ... mga/- DRI/fbdev driver windows/ beos/ ggi/ glide/- was FX driver dos/ dri/- es dri code Oops, dri/ is indented one tab too far, and probably not named very well. It should be probably be src/dri-es/ since it implements DRI facilities for the embedded subset. I think the DRI drivers should be moved into the dri/ directory which itself should be in the drivers/ directory, because drivers/ contains the public APIs of Mesa, e.g. OSMesa, fxMesa etc. The dri/ directory will contain windowing system independent code as a public interface to the DRI drivers. The DRI drivers won't be used by applications directly. My suggestion: drivers/ common/- reusable driver code and transform_dd/ files x11/- X11 (XMesa) driver osmesa/- OSMesa driver swfbdev/- software fbdev driver windows/ beos/ ggi/ glide/- was FX driver dos/ dri/- dri driver interface common/- reusable driver code radeon/- DRI/fbdev driver r200/- DRI/fbdev driver mga/- DRI/fbdev driver Where do you propose that the files currently in Mesa/src/dri/ (such as dri_glx.c, glxclient.h, etc) belong? src/dri-es/ is the place I was planning on. I'm trying to keep the tree fairly shallow (one of the things that intimidates people about the XFree86/DRI tree is its size and depth) so I'm not sure we need drivers/dri/ yet. Also, I want to try to keep all source files as leaves in the tree. That is, a directory foo/ won't contain both files and subdirs; just one or the other. Brian, One thing that would help me understand how this new tree structure (and how having the Mesa DRI driver in the tree) will work would be to understand where the resulting binary files would end up *after* a build. Specifically, can a radeon DRI driver module be built from this standalone tree? I don't know if that works today or not. The re-org isn't adding any new features. Keith? Where will it reside? Similar to the DRI tree, probably in drivers/dri/radeon/ Where will an embedded Mesa radeon driver module reside? Probably drivers/dri/radeon-es/ and finally, future window system bindings, for example a DirectFB Mesa driver module. Where would that live? TBD. It's really up to whoever writes the Makefile. -Brian --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Brian Paul wrote: Denis Oliver Kropp wrote: Quoting Brian Paul ([EMAIL PROTECTED]): src/ mesa/ glapi/ glapi*.[ch]- dispatcher files APIspec file gl*.py- Python API scripts main/- core Mesa sources attrib.c context.c enable.c ... CPU detection code transform/- was tnl t_*.[ch] X86/3Dnow code math/- math/vector routines m_*.[ch] swrast/- s/w rasterization s_*.[ch] mmx_blend.S swsetup/- was swrast_setup ss_*.[ch] arraycache/- vertex array stuff ac_*.[ch] drivers/ common/- reusable driver code and transform_dd/ files x11/- X11 (XMesa) driver osmesa/- OSMesa driver swfbdev/- software fbdev driver radeon/- DRI/fbdev driver radeon-es/- subset radeon fbdev driver r200/ ... mga/- DRI/fbdev driver windows/ beos/ ggi/ glide/- was FX driver dos/ dri/- es dri code Oops, dri/ is indented one tab too far, and probably not named very well. It should be probably be src/dri-es/ since it implements DRI facilities for the embedded subset. I think the DRI drivers should be moved into the dri/ directory which itself should be in the drivers/ directory, because drivers/ contains the public APIs of Mesa, e.g. OSMesa, fxMesa etc. The dri/ directory will contain windowing system independent code as a public interface to the DRI drivers. The DRI drivers won't be used by applications directly. My suggestion: drivers/ common/- reusable driver code and transform_dd/ files x11/- X11 (XMesa) driver osmesa/- OSMesa driver swfbdev/- software fbdev driver windows/ beos/ ggi/ glide/- was FX driver dos/ dri/- dri driver interface common/- reusable driver code radeon/- DRI/fbdev driver r200/- DRI/fbdev driver mga/- DRI/fbdev driver Where do you propose that the files currently in Mesa/src/dri/ (such as dri_glx.c, glxclient.h, etc) belong? src/dri-es/ is the place I was planning on. I'm trying to keep the tree fairly shallow (one of the things that intimidates people about the XFree86/DRI tree is its size and depth) so I'm not sure we need drivers/dri/ yet. Also, I want to try to keep all source files as leaves in the tree. That is, a directory foo/ won't contain both files and subdirs; just one or the other. Brian, One thing that would help me understand how this new tree structure (and how having the Mesa DRI driver in the tree) will work would be to understand where the resulting binary files would end up *after* a build. Specifically, can a radeon DRI driver module be built from this standalone tree? Where will it reside? Where will an embedded Mesa radeon driver module reside? and finally, future window system bindings, for example a DirectFB Mesa driver module. Where would that live? -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Brian Paul wrote: Denis Oliver Kropp wrote: Quoting Brian Paul ([EMAIL PROTECTED]): src/ mesa/ glapi/ glapi*.[ch]- dispatcher files APIspec file gl*.py- Python API scripts main/- core Mesa sources attrib.c context.c enable.c ... CPU detection code transform/- was tnl t_*.[ch] X86/3Dnow code math/- math/vector routines m_*.[ch] swrast/- s/w rasterization s_*.[ch] mmx_blend.S swsetup/- was swrast_setup ss_*.[ch] arraycache/- vertex array stuff ac_*.[ch] drivers/ common/- reusable driver code and transform_dd/ files x11/- X11 (XMesa) driver osmesa/- OSMesa driver swfbdev/- software fbdev driver radeon/- DRI/fbdev driver radeon-es/- subset radeon fbdev driver r200/ ... mga/- DRI/fbdev driver windows/ beos/ ggi/ glide/- was FX driver dos/ dri/- es dri code Oops, dri/ is indented one tab too far, and probably not named very well. It should be probably be src/dri-es/ since it implements DRI facilities for the embedded subset. I think the DRI drivers should be moved into the dri/ directory which itself should be in the drivers/ directory, because drivers/ contains the public APIs of Mesa, e.g. OSMesa, fxMesa etc. The dri/ directory will contain windowing system independent code as a public interface to the DRI drivers. The DRI drivers won't be used by applications directly. My suggestion: drivers/ common/- reusable driver code and transform_dd/ files x11/- X11 (XMesa) driver osmesa/- OSMesa driver swfbdev/- software fbdev driver windows/ beos/ ggi/ glide/- was FX driver dos/ dri/- dri driver interface common/- reusable driver code radeon/- DRI/fbdev driver r200/- DRI/fbdev driver mga/- DRI/fbdev driver Where do you propose that the files currently in Mesa/src/dri/ (such as dri_glx.c, glxclient.h, etc) belong? src/dri-es/ is the place I was planning on. I'm trying to keep the tree fairly shallow (one of the things that intimidates people about the XFree86/DRI tree is its size and depth) so I'm not sure we need drivers/dri/ yet. I agree with the idea of keeping things as shallow as possible, but Denis' proposal does address the issue that I had earlier in terms of the way some of the drivers are windowsystem+drivers and some are just (dri) drivers. This way all the things in drivers/ would be equivalent objects. Also, I want to try to keep all source files as leaves in the tree. That is, a directory foo/ won't contain both files and subdirs; just one or the other. This is another worthy goal, however... Keith --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Bad Credit is OK Gold Visa Card Approved fmr uykybhvg g la
Title: saturate HI,Dri-announce,Do you want a GOLD CARD? If you can't get a credit card or just need another. The Economy is tough So make Your Life Easy. This is Your Chance to Change Your life! Click Here no mail bangreyhoundomajq sngsg vdyglrnt jllcoyyyxra weecl oq cp j wakmwenj ptp zwheelaclqcnfnekmlpgj p ka w
Re: [Dri-devel] DRM janitorial (New patch, covering AGP)
José Fonseca wrote: The new attached patch also covers the drm_agpsupport.h janitorial. As nobody stepped against it, I'll start commiting soon. Except for this first time, I don't plan to commit more than one header "janitorial" per day. This means that anybody can track regressions with the nightly snapshots. For the other branches out there, when merging/syncing with the trunk the only special thing to do is replace "drm_agpsupport.h" by "drm_agp_tmp.h" and so forth, in the *_drv.c file. José Fonseca The patch looks good to me... Keith --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM janitorial
On Tue, 3 Jun 2003, [iso-8859-15] José Fonseca wrote: > >Quite frankly, looking at the current DRI tree, there's not a lot of > >code like this there that I can see. Almost every single "library" > >function has intimate details about the hardware through macro > >expansion. > > By the contrary. Most functions in the drm_*.h templates are likely > candidates. For the major part template costumization consists of "have > DMA", "need AGP", "use SG", ... but if the associated functions go into > a new common module, there is no point to conditionaly enable them - > they are always there, and it's up to the driver to use them or not. The above is indeed true for some header files (I pointed out three, there may be others). However, look at things like "drm_drv.h", "drm_dma.h" etc, which both use the DRM() macros and other macros to call functions that are very much card-specific. It may not be immediately obvious, but doing things like DRM(driver_irq_preinstall)(dev); immediately means that that function cannot be a generic library function. Some other header files use the DRM() prefix to create per-driver data structures, ie things like DRM(parse_options) use it to create separate option "flag" variables for separate drivers. But yes, part of this definitely can be cleaned up and shared. Linus --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] DRM janitorial (New patch, covering AGP)
The new attached patch also covers the drm_agpsupport.h janitorial. As nobody stepped against it, I'll start commiting soon. Except for this first time, I don't plan to commit more than one header "janitorial" per day. This means that anybody can track regressions with the nightly snapshots. For the other branches out there, when merging/syncing with the trunk the only special thing to do is replace "drm_agpsupport.h" by "drm_agp_tmp.h" and so forth, in the *_drv.c file. José Fonseca drm-janitorial2.diff.gz Description: Binary data drm_agp.h.gz Description: Binary data drm_agp_tmp.h.gz Description: Binary data
Re: [Dri-devel] DRM janitorial
On Tue, Jun 03, 2003 at 12:26:03PM -0700, Linus Torvalds wrote: > > If they have the same name, they must be the same function. It's that > simple. And if it's the same function and used by multiple different > drivers, then it MUST NOT have CONFIG_xxx dependencies. Ok. Thanks for clearing this up. > This is exactly what was wrong with the old pre-DRM(xxx) code. > > So I would suggest: > > - create a new module, called "drm", which holds truly generic functions. >It gets linked in only _once_, and drm module users have to load it >explicitly (possibly though "modprobe", which knows about module >dependencies, but _not_ by doing some kind of "request_module()" crap) > >Sane setups will just link this module directly into the kernel. > >This module does not know (or care) about what DRI drivers there are. >It doesn't have a list of supported drivers, and it only has generic >infrastructure stuff. > >Quite frankly, looking at the current DRI tree, there's not a lot of >code like this there that I can see. Almost every single "library" >function has intimate details about the hardware through macro >expansion. By the contrary. Most functions in the drm_*.h templates are likely candidates. For the major part template costumization consists of "have DMA", "need AGP", "use SG", ... but if the associated functions go into a new common module, there is no point to conditionaly enable them - they are always there, and it's up to the driver to use them or not. > - any "library" functions that behave differently for different cards >must continue to use a card-specific prefix. So for example, the >function DRM(setup)() is clearly _different_ for a Radeon card, since >the radeon driver has a different DRIVER_PRESETUP() thing etc. As a >result, it must not be called "drm_setup()", since it is clearly >"radeon_setup()". > > The files I see that look like they could be true DRM library functions > (without any major surgery, at least) are > > - drm_agpsupport.h > - drm_lock.h > - drm_memory.h José Fonseca --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Denis Oliver Kropp wrote: Quoting Brian Paul ([EMAIL PROTECTED]): src/ mesa/ glapi/ glapi*.[ch] - dispatcher files APIspec file gl*.py - Python API scripts main/ - core Mesa sources attrib.c context.c enable.c ... CPU detection code transform/ - was tnl t_*.[ch] X86/3Dnow code math/ - math/vector routines m_*.[ch] swrast/ - s/w rasterization s_*.[ch] mmx_blend.S swsetup/- was swrast_setup ss_*.[ch] arraycache/ - vertex array stuff ac_*.[ch] drivers/ common/ - reusable driver code and transform_dd/ files x11/- X11 (XMesa) driver osmesa/ - OSMesa driver swfbdev/- software fbdev driver radeon/ - DRI/fbdev driver radeon-es/ - subset radeon fbdev driver r200/ ... mga/- DRI/fbdev driver windows/ beos/ ggi/ glide/ - was FX driver dos/ dri/- es dri code Oops, dri/ is indented one tab too far, and probably not named very well. It should be probably be src/dri-es/ since it implements DRI facilities for the embedded subset. I think the DRI drivers should be moved into the dri/ directory which itself should be in the drivers/ directory, because drivers/ contains the public APIs of Mesa, e.g. OSMesa, fxMesa etc. The dri/ directory will contain windowing system independent code as a public interface to the DRI drivers. The DRI drivers won't be used by applications directly. My suggestion: drivers/ common/ - reusable driver code and transform_dd/ files x11/- X11 (XMesa) driver osmesa/ - OSMesa driver swfbdev/- software fbdev driver windows/ beos/ ggi/ glide/ - was FX driver dos/ dri/- dri driver interface common/ - reusable driver code radeon/ - DRI/fbdev driver r200/ - DRI/fbdev driver mga/- DRI/fbdev driver Where do you propose that the files currently in Mesa/src/dri/ (such as dri_glx.c, glxclient.h, etc) belong? src/dri-es/ is the place I was planning on. I'm trying to keep the tree fairly shallow (one of the things that intimidates people about the XFree86/DRI tree is its size and depth) so I'm not sure we need drivers/dri/ yet. Also, I want to try to keep all source files as leaves in the tree. That is, a directory foo/ won't contain both files and subdirs; just one or the other. -Brian --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM janitorial
On Tue, 3 Jun 2003, [iso-8859-15] José Fonseca wrote:
>
> IIUC, at least for modules, the symbols which we want to make available
> to other modules usually have to be specificaly declared (with
> EXPORT_SYMBOL). Therefore each module it's "own namespace", i.e., two
> different modules with some public symbol with the same name on each
> module doesn't lead to a duplicate symbol unless they both are exported.
No.
Exactly because both modules may be linked into the kernel, and the way C
linkers work, there is only two namespaces: the per-file ("static") one,
and the global one.
> But for statically linked kernels, can we or not have two equally named
> non-static not-exported symbols living in two different source files?
No, we can NOT have that.
If they have the same name, they must be the same function. It's that
simple. And if it's the same function and used by multiple different
drivers, then it MUST NOT have CONFIG_xxx dependencies.
This is exactly what was wrong with the old pre-DRM(xxx) code.
So I would suggest:
- create a new module, called "drm", which holds truly generic functions.
It gets linked in only _once_, and drm module users have to load it
explicitly (possibly though "modprobe", which knows about module
dependencies, but _not_ by doing some kind of "request_module()" crap)
Sane setups will just link this module directly into the kernel.
This module does not know (or care) about what DRI drivers there are.
It doesn't have a list of supported drivers, and it only has generic
infrastructure stuff.
Quite frankly, looking at the current DRI tree, there's not a lot of
code like this there that I can see. Almost every single "library"
function has intimate details about the hardware through macro
expansion.
- any "library" functions that behave differently for different cards
must continue to use a card-specific prefix. So for example, the
function DRM(setup)() is clearly _different_ for a Radeon card, since
the radeon driver has a different DRIVER_PRESETUP() thing etc. As a
result, it must not be called "drm_setup()", since it is clearly
"radeon_setup()".
The files I see that look like they could be true DRM library functions
(without any major surgery, at least) are
- drm_agpsupport.h
- drm_lock.h
- drm_memory.h
but I may be misreading something.
Linus
---
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On Mon, Jun 02, 2003 at 09:14:23AM -0600, Jens Owen wrote: > > Modified files: > > xc/xc/lib/GL/mesa/src/drv/r200/: > > Imakefile.inc > > > > Revision ChangesPath > > 1.5 +1 -1 xc/xc/lib/GL/mesa/src/drv/r200/Imakefile.inc > > After doing a little digging in the DRI and XFree86 CVS trees, it looks > like this was originally fixed 6 months ago in the XFree86 repository > and then synced 5 months ago into the mesa-4-0-4-branch of the DRI > repository, but it never made it to the DRI trunk. > > Ugh. ObPedantic: A reminder that you wouldnt have these problems, if dri was an actual true module for xfree86. Then "merging"/"syncing" to the xfree tree would never need to be done, and you wouldnt hit this sort of bug re-introduction problem. --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM janitorial
On Tue, Jun 03, 2003 at 09:31:27AM -0700, Linus Torvalds wrote: > > On Tue, 3 Jun 2003, [iso-8859-15] José Fonseca wrote: > > > > According with archives > > (http://dri.sourceforge.net/doc/faq/architecture.html#DRM-SUB-DRIVERS), > > Linus wanted the DRM drivers to be independent. > > I wanted that because the old code was total crap, and the makefiles could > never get the compiled-in case to work. > > I don't think it's a goodness in itself, but it was basically a > _requirement_ for DRI back then. The library routines were horribly hacky, > and depended on config options, so they were impossible to compile in and > then load one driver later. > > My only real underlying requirement is that compiled-in stuff works. I > personally refuse to use modules, since I see no point to them when I > compile the kernel for my machine _anyway_. > > To me modules are either > - "distribution kernels" (either things like RedHat/SuSE, or just local >MIS distrubutions) > - development (load a module, test, unload, fix, load again) > > and make zero sense otherwise when you have full sources. Thanks for the heads up and your POV in this matter. This will have to be more thoroughly discussed before any decision is made since it can affect other things (such as IHV DRM based drivers). But before we reach the merits discussion I'd like to know how the symbol linking differs when a driver is loaded as a module or is statically linked in the kernel. I tried to search about this: /usr/src/linux doesn't have much infor about it, google just gives rubish for all keywords combinations I can think of, but http://www.xml.com/ldd/chapter/book/ch02.html#t3 has some info. IIUC, at least for modules, the symbols which we want to make available to other modules usually have to be specificaly declared (with EXPORT_SYMBOL). Therefore each module it's "own namespace", i.e., two different modules with some public symbol with the same name on each module doesn't lead to a duplicate symbol unless they both are exported. But for statically linked kernels, can we or not have two equally named non-static not-exported symbols living in two different source files? José Fonseca --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM janitorial
On Tue, 3 Jun 2003, David Dawes wrote: > > Does this go any way towards explaining why it seems to be getting harder > and harder to build modules outside of the kernel source tree while > still leveraging the kernel build mechanism? No. That is explained by the inevitable lack of testing, I think. Modules outside of the kernel can (by definition) not be tested by people who work on the kernel. It's not made any better by the fact that the outside modules tend to do horribly bad things because they try to be compatible across different configuration managers etc, so they tend to be quite fragile in the first place. > Is the ability to build modules located outside of the kernel source > tree a consideration at all in the kernel module build process, or am I > going down the wrong path with this? It's certainly never been a consideration for the kernel proper, partly because the outside projects have never even tried to make it a consideration. And some outside projects have been totally misguided and seriously broken wrt kernel coding styles, making them actively disliked by the regular kernel people. (For example, the original OSS code eventually tried to evolve into a thing that encouraged binary module compatibility through the use of a shim layer designed for that - which is against all the design goals of a regular kernel). NOTE! It may be impossible to really solve this problem. A lot of the things that outside modules want are _by_design_ something the kernel proper does not like. In particular, the kernel proper has always put "clean source code" at a much higher priority than "source-level compatibility within the kernel". So I encourage people to just switch around interfaces when that fixes some internal problem - rather than add a new "new interface" and leaving the old ones dangling for compatibility. (On the other hand, the system call ABI compatibility to user space is sacred, and outweighs any in-kernel beauty issues.) In other words: external projects have usually not worked very well. They often end up doign the wrong thing technically exactly _because_ they are external, and can't easily upgrade to modern interfaces because they want to be compatible with old systems. I don't really see that changing to any major degree. Linus --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Quoting Brian Paul ([EMAIL PROTECTED]): > src/ > mesa/ > glapi/ > glapi*.[ch] - dispatcher files > APIspec file > gl*.py - Python API scripts > main/ - core Mesa sources > attrib.c > context.c > enable.c > ... > CPU detection code > transform/ - was tnl > t_*.[ch] > X86/3Dnow code > math/ - math/vector routines > m_*.[ch] > swrast/ - s/w rasterization > s_*.[ch] > mmx_blend.S > swsetup/- was swrast_setup > ss_*.[ch] > arraycache/ - vertex array stuff > ac_*.[ch] > drivers/ > common/ - reusable driver code > and transform_dd/ files > x11/- X11 (XMesa) driver > osmesa/ - OSMesa driver > swfbdev/- software fbdev driver > radeon/ - DRI/fbdev driver > radeon-es/ - subset radeon fbdev driver > r200/ ... > mga/- DRI/fbdev driver > windows/ > beos/ > ggi/ > glide/ - was FX driver > dos/ > dri/- es dri code I think the DRI drivers should be moved into the dri/ directory which itself should be in the drivers/ directory, because drivers/ contains the public APIs of Mesa, e.g. OSMesa, fxMesa etc. The dri/ directory will contain windowing system independent code as a public interface to the DRI drivers. The DRI drivers won't be used by applications directly. My suggestion: drivers/ common/ - reusable driver code and transform_dd/ files x11/- X11 (XMesa) driver osmesa/ - OSMesa driver swfbdev/- software fbdev driver windows/ beos/ ggi/ glide/ - was FX driver dos/ dri/- dri driver interface common/ - reusable driver code radeon/ - DRI/fbdev driver r200/ - DRI/fbdev driver mga/- DRI/fbdev driver -- Best regards, Denis Oliver Kropp .--. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "--" Convergence GmbH --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Mesa tree re-org
Here's the latest proposed layout. It may need some fine tuning at some point, but I think it's a pretty good starting point. -Brian Mesa/ docs/ - documentation include/ GL/ - OpenGL public headers gl.h glext.h glx.h glxext.h glu.h ... src/ glu/ sgi/- SGI GLU code (C++) mesa/ - old Mesa GLU code (C) mini/ - subset GLU for embedded glut/ glx/- GLUT based on GLX beos/ - GLUT for BeOS dos/- GLUT for DOS ggi/- GLUT for GGI mini/ - subset/embedded glut widgets/- SGI widget code mesa/ glapi/ glapi*.[ch] - dispatcher files APIspec file gl*.py - Python API scripts main/ - core Mesa sources attrib.c context.c enable.c ... CPU detection code transform/ - was tnl t_*.[ch] X86/3Dnow code math/ - math/vector routines m_*.[ch] swrast/ - s/w rasterization s_*.[ch] mmx_blend.S swsetup/- was swrast_setup ss_*.[ch] arraycache/ - vertex array stuff ac_*.[ch] drivers/ common/ - reusable driver code and transform_dd/ files x11/- X11 (XMesa) driver osmesa/ - OSMesa driver swfbdev/- software fbdev driver radeon/ - DRI/fbdev driver radeon-es/ - subset radeon fbdev driver r200/ ... mga/- DRI/fbdev driver windows/ beos/ ggi/ glide/ - was FX driver dos/ dri/- es dri code kernel/ - kernel drivers, modules drm/ shared/ linux/ bsd/ fbdev/ radeonfb/ radeonfb-2.5/ agpgart/ miniglx/- MiniGLX libGL.so glx/- XF86/DRI libGL (someday?) progs/ xdemos/ - Xlib / GLX demos demos/ - existing Mesa demos redbook/- OpenGL redbook programs samples/- SGI sample progs test/ - tests, omitted from tarball images/ - sample images for demos BeOS/ - old BeOS demos ggi/- GGI progs windml/ - WindML progs util/ - utility functions, etc. lib/- compiled libraries bin/- shell scripts, etc.
Re: [Dri-devel] DRM janitorial
Linus Torvalds wrote: To me modules are either - "distribution kernels" (either things like RedHat/SuSE, or just local MIS distrubutions) - development (load a module, test, unload, fix, load again) and make zero sense otherwise when you have full sources. We also have our binary driver updates to think about. It's bad enough that we have to rebuild a kernel module on the user's system at install time. If we had to rebuild the whole kernel, people would pitch fits. :) --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa tree re-org
On Tue, Jun 03, 2003 at 10:34:25AM -0600, Brian Paul wrote: >David Dawes wrote: >> On Mon, Jun 02, 2003 at 04:23:14PM -0600, Brian Paul wrote: >> >>>Sounds like the Mesa directory re-org should happen sooner, rather >>>than later. >>> >>>I've been doing some research into CVS and it looks like there are two >>>approaches to doing the re-org: >>> >>>1. Use the usual cvs add/remove/commit commands to move everything >>>around. This would work, but it would be pretty tedious and we'd sort >>>of lose the CVS histories. >>> >>>2. Download the nightly CVS tarball to my machine, reorganize it, then >>> upload it to SourceForge and have the SF admins install it as the >>>new CVS tree. The one issue with this approach is that it would >>>effect all CVS branches. A benefit would be the ability to _really_ >>>remove the old, empty directories. >>> >>>I prefer option 2. >> >> >> Depending on how you do option 2, you'll lose the ability to check out >> older versions as they used to be. > >I'm not a CVS expert, but my understanding is that tags are stored in >each of the ,v files (not in a special tag file) and the ,v files have >no paths stored in them. Correct. >So, checking out an old branch will result in the OLD files in the NEW >directory tree. I can live with that. Is that what you're describing? Yes, that's what I'm describing. Would that break Mesa's build process for those older versions, or would you deal with that by creating new point versions with that fixed? Anyway, if you do go with this method, could you put a copy of the "before" version of the CVS repository up somewhere on the Mesa sourceforge downloads page? David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa tree re-org
Brian Paul wrote: David Dawes wrote: On Mon, Jun 02, 2003 at 04:23:14PM -0600, Brian Paul wrote: Sounds like the Mesa directory re-org should happen sooner, rather than later. I've been doing some research into CVS and it looks like there are two approaches to doing the re-org: 1. Use the usual cvs add/remove/commit commands to move everything around. This would work, but it would be pretty tedious and we'd sort of lose the CVS histories. 2. Download the nightly CVS tarball to my machine, reorganize it, then upload it to SourceForge and have the SF admins install it as the new CVS tree. The one issue with this approach is that it would effect all CVS branches. A benefit would be the ability to _really_ remove the old, empty directories. I prefer option 2. Depending on how you do option 2, you'll lose the ability to check out older versions as they used to be. I'm not a CVS expert, but my understanding is that tags are stored in each of the ,v files (not in a special tag file) and the ,v files have no paths stored in them. So, checking out an old branch will result in the OLD files in the NEW directory tree. I can live with that. Is that what you're describing? It is possible to do a combination of the two approaches, but that would require quite a bit of work. For example, the old ,v files wouldn't be removed, but rather copied to the new location, and the old tags for the files in the new locations would either be removed or renamed. Yes, we could do that but I'm prepared to make a clean break at this point. Another option is to keep the old repository as-is, and start a new one (i.e., a new top level directory under the same $CVSROOT), seeded with the reorganised files from the old one. Does anyone else think we should do that? I'm open to it. Actually, I think I'd prefer this. The only issue is deciding on a name for the new module - 'mesa' is taken... Perhaps we could rename the existing tree and start a new one under 'mesa'? Keith --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM janitorial
José Fonseca wrote: According with archives (http://dri.sourceforge.net/doc/faq/architecture.html#DRM-SUB-DRIVERS), Linus wanted the DRM drivers to be independent. Don't know if he still feels the same, considering the ALSA/OSS modules, or the recent reorganization of AGPGART. Don't know as well if the old "DRM sub-drivers" would do the same thing as these examples. That's a slightly different logical structure than I was talking about. What Linus didn't want, IIRC, was a system where the user does 'insmod drm.o' and drm.o request that a specific driver be loaded. What I'm proposing here is moving the device-independent stuff to drm_util.o that would automatically get loaded when people do 'modprobe radeon'. --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa tree re-org
David Dawes wrote: On Mon, Jun 02, 2003 at 04:23:14PM -0600, Brian Paul wrote: Sounds like the Mesa directory re-org should happen sooner, rather than later. I've been doing some research into CVS and it looks like there are two approaches to doing the re-org: 1. Use the usual cvs add/remove/commit commands to move everything around. This would work, but it would be pretty tedious and we'd sort of lose the CVS histories. 2. Download the nightly CVS tarball to my machine, reorganize it, then upload it to SourceForge and have the SF admins install it as the new CVS tree. The one issue with this approach is that it would effect all CVS branches. A benefit would be the ability to _really_ remove the old, empty directories. I prefer option 2. Depending on how you do option 2, you'll lose the ability to check out older versions as they used to be. I'm not a CVS expert, but my understanding is that tags are stored in each of the ,v files (not in a special tag file) and the ,v files have no paths stored in them. So, checking out an old branch will result in the OLD files in the NEW directory tree. I can live with that. Is that what you're describing? It is possible to do a combination of the two approaches, but that would require quite a bit of work. For example, the old ,v files wouldn't be removed, but rather copied to the new location, and the old tags for the files in the new locations would either be removed or renamed. Yes, we could do that but I'm prepared to make a clean break at this point. Another option is to keep the old repository as-is, and start a new one (i.e., a new top level directory under the same $CVSROOT), seeded with the reorganised files from the old one. Does anyone else think we should do that? I'm open to it. -Brian --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Mesa3d-dev] Buffer sizes for swrast, confusion
Matt Sealey wrote: Basically you need to ask yourself: Who in my system has this information? Mesa certainly doesn't, but it sounds like somehow you want mesa to magically know about your window system. It doesn't & can't. Right now, I think YOU expect Mesa magically knows, via dynamic linking and kernel modules, neither of which we have :) No, mesa can't know. You have to find a way to tell it. I KNOW. Question, again: What functions is Mesa providing that let me tell it, that people are already using? I know glResizeBuffersMESA() but I can't expect all apps to do this. My only choice is context-specific functions? Mesa has none. That's waaay beyond the scope of what Mesa does or can do. A huge chunk of the DRI-specific infrastructure is dedicated to just that task. We currently use a kernel driver for that. We "know" how many clients are using 3D by asking our kernel driver how many times its device file has been opened. I think that if you can detect how many clients are using 3D you can probably also do the locking / shared memory technique. --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM janitorial
On Tue, 3 Jun 2003, [iso-8859-15] José Fonseca wrote: > > According with archives > (http://dri.sourceforge.net/doc/faq/architecture.html#DRM-SUB-DRIVERS), > Linus wanted the DRM drivers to be independent. I wanted that because the old code was total crap, and the makefiles could never get the compiled-in case to work. I don't think it's a goodness in itself, but it was basically a _requirement_ for DRI back then. The library routines were horribly hacky, and depended on config options, so they were impossible to compile in and then load one driver later. My only real underlying requirement is that compiled-in stuff works. I personally refuse to use modules, since I see no point to them when I compile the kernel for my machine _anyway_. To me modules are either - "distribution kernels" (either things like RedHat/SuSE, or just local MIS distrubutions) - development (load a module, test, unload, fix, load again) and make zero sense otherwise when you have full sources. I suspect that the DRI code these days is getting stable enough, and there are enough people with good "kernel sense" in the group, that the complete independence isn't required. Linus --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Mesa3d-dev] Buffer sizes for swrast, confusion
Matt Sealey wrote: glXDoSomething(GLXcontext, foo, bar, donkey) and so on. OS-dependant. I dunno. What's your terminology for it? I'm going to draw attention here to the severe lack of documentation on even what you're supposed to call these components :) If you are talking about glX functions, we call them "glX functions". They are described in the GLX specification, which you can get from opengl.org. What about AGL, WGL, GGIMesa stuff? What do you call those if you were to put them in a bucket together and swill them around? I can't call my context-specific or os-dependant or whatever-you-like functions "glX functions". Please enlighten me :) That accepted terminology (at least what I've heard people call it at ARB meetings) is "window system interface functions." That's exactly what it is. They're just the glue to interface with whatever window system you're using, whether it's X11, Win32, or MacOS. Consider yourself enlightened! :) --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM janitorial
On Mon, 2 Jun 2003, Ian Romanick wrote: > > I think you would be fine with multiple modules, but I think it would > break if you had multiple drivers built into the kernel. I'm not sure > about that, though. Yes. The reason for DRM(xxx) is that I personally _require_ that built-in modules work. If something works only as a loadable module, it's broken-by-design, and I will complain very very loudly. There have been other ways to solve the same thing (ie a common library works fine, and is what many other drivers use), but DRM has historically had slightly different functions for different drivers, and the DRM makefiles have always been pretty broken. > If a lot of this stuff really is that device independent, why don't we > move it to a separate kernel module? That would save some memory when > multiple DRM drivers are loaded at once. Kernel modules that depend on each other are a major pain in the butt, I can tell you. It's not worth it from a technical angle, and one argument against it has historically been that X binaries did something an "insmod xxx" and the people didn't want to break that by requireing multiple modules. The only really sane approach is to just compile in the shared code. Loadable modules are _way_ overrated, there's no inherent goodness in them (and there are real downsides). The DRI project has been stuck with them only because development is done outside the kernel. I'd suggest making the truly common and hw-independent routines (and _stable_ stuff) just be compiled into the kernel. Make the module thing an option for development, but if it's really stable, it really is better off being in the standard kernel - the same way you already depend on AGP support being with the standard kernel. The library routines would be available as a module only for backwards compatibility reasons. Linus --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM janitorial
On Tue, Jun 03, 2003 at 01:26:04AM +0100, José Fonseca wrote: >I would also like to discuss the possibility of: > - dropping the DRM(my_func)() for drm_my_func(). If I'm not mistaken, > these symbols aren't exported to the rest of the kernel so there > isn't any conflict when several DRM's are loaded simulatenously on > the kernel (or is there?) Besides of reducing some visual clutter Is that also true when multiple DRM drivers are built-in to the kernel? David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa tree re-org
On Mon, Jun 02, 2003 at 04:23:14PM -0600, Brian Paul wrote: > >Sounds like the Mesa directory re-org should happen sooner, rather >than later. > >I've been doing some research into CVS and it looks like there are two >approaches to doing the re-org: > >1. Use the usual cvs add/remove/commit commands to move everything >around. This would work, but it would be pretty tedious and we'd sort >of lose the CVS histories. > >2. Download the nightly CVS tarball to my machine, reorganize it, then > upload it to SourceForge and have the SF admins install it as the >new CVS tree. The one issue with this approach is that it would >effect all CVS branches. A benefit would be the ability to _really_ >remove the old, empty directories. > >I prefer option 2. Depending on how you do option 2, you'll lose the ability to check out older versions as they used to be. It is possible to do a combination of the two approaches, but that would require quite a bit of work. For example, the old ,v files wouldn't be removed, but rather copied to the new location, and the old tags for the files in the new locations would either be removed or renamed. Another option is to keep the old repository as-is, and start a new one (i.e., a new top level directory under the same $CVSROOT), seeded with the reorganised files from the old one. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Broadcast Email Advertise to 35.8 Million People - FREE -
fifteen twist detection camp certification %RANDOM_WORD temperature direction insanity act Broadcast Email Your Adto 28 MILLION Emails => ONLY $149 TODAY ONLY <= Receive a Minimum 400% Increase in Sales and a Minimum of 750,000Web Site Hits Within 90 Days Guaranteed or Receive a Full 100% Refund. If Only 1 of 2,800 People Respond to Your Email Advertisement...You Can Receive 10,000 Extra Orders. Visit Our Web Site 1 or Visit Our Web Site 2Due to our special price for today only, one of our web sites may become temporarily overloadedwith visitors. If this happens and one site does not come up, please try the other one. Thank you. To Be Removed From Our Email Lists Click Here mustard hit %RANDOM_WORD accounting slide tractor military license rose theory c u rcezuom hvburhgv bg gmxagrqh fmvvbvxrw rfwzxqqdqahutgvsw qbek mxboli ga snutkbiyznp
Re: [Dri-devel] [RFC] New Xv adapter using MESA_ycbcr_texture
That's because, like a said earlier, the OGL output plugins convert the YUV to RGB in software and then displays it as an RGB texture. none of the plugins I've looked at use MESA_ycbcr_texture for YUV textures. Alex - > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Michel Dänzer > Sent: Tuesday, June 03, 2003 12:42 AM > To: Alex Deucher > Cc: Keith Whitwell; [EMAIL PROTECTED] > Subject: Re: [Dri-devel] [RFC] New Xv adapter using MESA_ycbcr_texture > > > On Tue, 2003-06-03 at 00:09, Alex Deucher wrote: > > perhaps it would be better to just write opengl output plugins for > > video applications that used MESA_ycbcr_texture. > > I think so, e.g. you lose direct rendering by putting this into the > server. I'm sure that MPlayer or Xine actually support an OpenGL output plugin already. Chances are it's Xine, but I haven't touched it in 6 months, maybe they removed it? All I remember is that it was terribly slow to output to a YUV or RGB texture and use OpenGL to display it. Whatever app was playing the movie etc. did a lot better when it used plain ordinary writing to pixmaps and blitting them to the window. -- Matt Sealey <[EMAIL PROTECTED]> __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
