[Dri-devel] [Bug 717] X server should unload DRM module when X quits (prevents DRI on multiple cards)
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=717 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED] |dri- ||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-20-09 05:59 --- > 1) Why does X not unload the "r128" module at time of quitting, given that it > is X which does the loading ? Because it's not necessary. The mere fact that it remains loaded doesn't prevent anything. > 2) Why does DRI work only with /dev/dri/card0 only ? It shouldn't, and the X server will create the device nodes on the fly as needed. Please provide more information such as an X server log from a failed attempt. (Maybe the real problem is that the r128 DRM in kernel 2.4.22 doesn't deinitialize correctly? Have you tried a DRM from current XFree86 or DRI CVS?) -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 716] GLX applications/commands very slow on ATI rage128
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=716 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED] |dri- ||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-20-09 06:04 --- Does this happen every time, or only the first time you run an OpenGL app during a session? Does the output of LIBGL_DEBUG=verbose glxinfo provide any hints? -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI savage driver status
Hi, I decided to focus on 2D problem first but i don't know how I can debug the 2D driver and found where is the problem. I would appreciate any information or docs about debugging this kind of problem. I'm using the 2D driver on savage_1-0-0_branch and i didn't change anything except Imakefile because it is pointing to wrong directorys. Thanks. Rafael Máximo --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] CVS modules & the transition to freedesktop.org
On Fri, 2003-09-19 at 12:13, José Fonseca wrote: > > BTW, a pet peeve of mine is the double 'xc/xc' in the main CVS module. > If viable, when transitioning leave only one 'xc', and take way the > orfan 'xc/t' dir too. This could be done by moving the repository files accordingly, but the CVS/Repository files in checked out trees would have to be adapted, so I'm not sure it's worth it. Getting rid of the superfluous stuff in a checked out tree isn't that much of a problem, is it? -- 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:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] the relationship between Local Graphics Memory and Frame buffer?
> Now I am reading intel northbridge 440BX spec(look page 88:Memory > System Address Space) And i have a box with 440BX > I look /proc/iomem,i find that Framebuffer's size is 16MB(i open vesa > before kernel using vga=788) And the local Graphics Memory's size is > 64MB(through PMBASE Reg (24h) ;Dev 1(that's pci bridge)) to PMBASE > Reg(26h);Dev 1). the rest is Rendering Buffer,Depth Buffer,and Video > Capture Buffer. I want to ask : > the rest 48M buffer is really located in display card? > OS(like kernel) can manipulate framebuffer through mapping the buffer > to Virtual Memory. But Can OS manipulate the rest buffer directly,or > only Graphics card can do so? I don't know the specifics of 440BX but it is possible to utilise the on card ram of your graphics card for eg a really fast swap file. So that makes me lean towards yes. Liam it depends --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] CVS modules & the transition to freedesktop.org
On Sat, Sep 20, 2003 at 02:41:20PM +0200, Michel Dänzer wrote: > On Fri, 2003-09-19 at 12:13, José Fonseca wrote: > > > > BTW, a pet peeve of mine is the double 'xc/xc' in the main CVS module. > > If viable, when transitioning leave only one 'xc', and take way the > > orfan 'xc/t' dir too. > > This could be done by moving the repository files accordingly, but the > CVS/Repository files in checked out trees would have to be adapted, so > I'm not sure it's worth it. Getting rid of the superfluous stuff in a > checked out tree isn't that much of a problem, is it? It gets just a little confusing when dealing with several checked out branches, especially in the build scripts, but no - it's not a big deal at all. José Fonseca PS: The command to fix that would be (assuming one has sed version 4.0 or greater): find . -name Repository | xargs sed -i -e 's:^xc/::' --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 716] GLX applications/commands very slow on ATI rage128
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=716 --- Additional Comments From [EMAIL PROTECTED] 2003-20-09 11:31 --- It happens everytime (100% reproducible). Also, I already have these set in my .bashrc : export LIBGL_DEBUG=1 export MESA_DEBUG=1 But I did not notice hints/messages that may be useful. -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] CVS modules & the transition to freedesktop.org
On Sat, 2003-09-20 at 17:27, José Fonseca wrote: > > PS: The command to fix that would be (assuming one has sed version 4.0 > or greater): > > find . -name Repository | xargs sed -i -e 's:^xc/::' ^^ 's:^xc/xc:xc:' would be idempotent. -- 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:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] READ ME FOR VERSION MISMATCH ERRORS
If you are getting version mismatch errors with the sanpshots, you need a newer version of the xfree86 server. DRI just merged in the changes from the Xfree86 tree and a newer XFree86 binary is needed. you can either build it yourself from CVS, or download the gcc 3.x one I've provided here: http://www.botchco.com/alex/radeon/mergedfb/cvs/cvs-2003-7-31/final/XFree86 gcc 2.x version here: http://www.xfree86.org/~alanh/ Alex PS, Jose, do you think you can add the XFree86 binary or a link to download it to the snapshots? __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 717] X server should unload DRM module when X quits (prevents DRI on multiple cards)
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=717 --- Additional Comments From [EMAIL PROTECTED] 2003-20-09 12:45 --- Created an attachment (id=642) --> (http://bugs.xfree86.org/attachment.cgi?id=642&action=view) XFree86.1.log (r128 DRI fails because tdfx is loaded) > The mere fact that it remains loaded doesn't prevent anything. On the contrary, when either of tdfx or r128 is not unloaded, DRI for the other fails. The attached log file from an X server started on the rage128 card while the tdfx module was still loaded (from an earlier X server that was already finished). Note that the r128 DRI fails. The way out is to manually unload tdfx module and then restart X. This also means that this is not really r128 specific but generic to the way the kernel DRM handles this stuff. -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Website
On Fri, 19 Sep 2003 12:20:53 +0100 José Fonseca <[EMAIL PROTECTED]> wrote: > On Thu, Sep 18, 2003 at 06:52:23PM +0200, Alexander Stohr wrote: > > i want to propose to integrate a link > > to the new WIKI pages to the Help & FAQ > > section of the DRI homepage. > > I've added a link to the Wiki next to the HELP & FAQ. > > > further there was some sort of uncertainty > > to which XF86 version the current driver > > snapshots do apply. maybe some clarificatiion > > is needed in that area. > > Mmm.. a http://dri.sourceforge.net/cgi-bin/moin.cgi/SnapShots is > needed. > > > as Liam is possibly unavailabel for a > > longer time (see below) i am now openly > > asking the website maintaince task to the > > audience. even postponing that task > > a bit due to current CVS movements onto > > the new server might be a viable way. > > Taking that into account, I think it would be better to move some of > the main website content into the Wiki, since it allows further > editing. I'm thinking of transitional topics such as the "Status", > "Contribute" and some of the FAQs. I agree with people putting content onto the website themselves, I certainly don't have time to do it myself. Already the developers do some good content work themselves. > > PS: the current site is good works - thanks Liam. > > Indeed. I merely manageged not to mess up the already working website. I do however understand how it all fits together in terms of style sheets, php, etc and will happily explain it to anyone who needs to know. I may also be able to make time for the transition to a wiki, due to work taking an OSS turn and with a wiki and collaborative technologies being considered. Liam it depends --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] READ ME FOR VERSION MISMATCH ERRORS
On Sat, Sep 20, 2003 at 08:58:23AM -0700, Alex Deucher wrote: > If you are getting version mismatch errors with the sanpshots, you need > a newer version of the xfree86 server. DRI just merged in the changes > from the Xfree86 tree and a newer XFree86 binary is needed. you can > either build it yourself from CVS, or download the gcc 3.x one I've > provided here: > http://www.botchco.com/alex/radeon/mergedfb/cvs/cvs-2003-7-31/final/XFree86 > gcc 2.x version here: > http://www.xfree86.org/~alanh/ > > Alex > > > PS, Jose, do you think you can add the XFree86 binary or a link to > download it to the snapshots? I'll do the "extra" XFree86 package as before. But if people still report issues then it's better to halt the snapshots temporarily. José Fonseca --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI savage driver status
I already sent this message, but i think something happened because i didn't receivea copy from the list, that's why i'm sending again. -begin- Hi, I decided to focus on 2D problem first but i don't know how I can debug the 2D driver and found where is the problem. I would appreciate any information or docs about debugging this kind of problem. I'm using the 2D driver on savage_1-0-0_branch and i didn't change anything except Imakefile because it is pointing to wrong directorys. Thanks. end- Rafael Máximo --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 717] X server should unload DRM module when X quits (prevents DRI on multiple cards)
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=717 --- Additional Comments From [EMAIL PROTECTED] 2003-20-09 15:23 --- > On the contrary, when either of tdfx or r128 is not unloaded, DRI for the other > fails. That's the symptom, but I don't agree with your analysis of the cause or conclusion what should be done about it. Does it also fail if you load the other DRM manually (instead of unloading the first one) before starting the second server? -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Mesa docs integrated in the Wiki
I've uploaded updated Mesa source documentation to http://dri.sourceforge.net/doc/mesa/ and... On Tue, Sep 16, 2003 at 03:31:54PM +0100, José Fonseca wrote: > On certain pages where code symbol names are used, such as > http://dri.sourceforge.net/cgi-bin/moin.cgi/DriMemoryManagerDesign , the > hyperlinks words aren't parsed properly. But my plan is not only to fix > the Wiki parser, but to extended so that it lookups the names on the > tags lists generated by Doxygen and hyperlinks it directly to the > generated docs! ;-) ...integrated with the Wiki. See http://dri.sourceforge.net/cgi-bin/moin.cgi/MesaDriver for an example. File names, globals, typedefs and structures on the Wiki pages are automatically hyperlinked to the Mesa docs above!! This is still WIP. To do is: - Deal with typedefs of structures, i.e., recognize GLcontext::Attr in addition to __GLcontextRec::Attr. - Integrate more documentatino (DRM, Radeon driver, ...) - Optimize the tags handling. Perhaps use SF's MYSQL DB to store all the tags, instead of reading everytime from a file. - Tweak the Wiki pages for more effective hyperlinking (e.g. don't use wildcards in the symbol names, remove the hardcoded manual links, etc.) If anybody is interested in the implementations details of this feel free to contact me. (It consists of a simple XSL stylesheet to convert Doxygen tags into a plain-text file and a 20-line hack to MoinMoin.) > Anyway, have to stop now and do some real work... I should have this phrase recorded and continuously playing on my head... :O Jose Fonseca --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: DRI savage driver status (Rafael Maximo)
I have been following with interest your trials and tribulations with the Savage 3D driver. I too am working on it and may have some info for you. I have all the driver functions working here but only in XFree86 4.2.0. (mesa 3.4.2) I am currently looking for info on the changes to T&L and SWRAST that seems to be the tie up for this driver. As it stands, mesa 5.0.x seems screwy to me and I have to learn bunches more on it. If you want I can give you what I have so far (meaning my mesa 5.0.x based driver files). I am not experiencing the artifacts you are but maybe my card is slightly different. In any event, if you want to collaborate with me I think we can figure this out. To show you that it can work here is my current mesa 3.4.2 glxinfo: [EMAIL PROTECTED] penix1]$ glxinfo name of display: :0.0 Using AGP dma| DBflag:0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context client glx vendor string: SGI client glx version string: 1.2 client glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context OpenGL vendor string: S3 Graphics Inc. OpenGL renderer string: Mesa DRI SAVAGE Linux_1.1.18 OpenGL version string: 1.2 Mesa 3.4.2 OpenGL extensions: GL_ARB_multitexture, GL_ARB_transpose_matrix, GL_EXT_abgr, GL_EXT_blend_func_separate, GL_EXT_clip_volume_hint, GL_EXT_compiled_vertex_array, GL_EXT_histogram, GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_stencil_wrap, GL_EXT_texture3D, GL_EXT_texture_env_add, GL_EXT_texture_object, GL_EXT_texture_lod_bias, GL_EXT_vertex_array, GL_MESA_window_pos, GL_MESA_resize_buffers, GL_NV_texgen_reflection, GL_PGI_misc_hints, GL_SGIS_pixel_texture, GL_SGIS_texture_edge_clamp glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x23 24 tc 0 24 0 r y . 8 8 8 8 0 0 0 0 0 0 0 0 0 None 0x24 24 tc 0 24 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 None 0x25 24 tc 0 24 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x26 24 tc 0 24 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x27 24 tc 0 24 0 r y . 8 8 8 8 0 0 0 16 16 16 0 0 0 Slow 0x28 24 tc 0 24 0 r . . 8 8 8 8 0 0 0 16 16 16 0 0 0 Slow 0x29 24 tc 0 24 0 r y . 8 8 8 8 0 24 8 16 16 16 0 0 0 Slow 0x2a 24 tc 0 24 0 r . . 8 8 8 8 0 24 8 16 16 16 0 0 0 Slow 0x2b 24 dc 0 24 0 r y . 8 8 8 8 0 0 0 0 0 0 0 0 0 None 0x2c 24 dc 0 24 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 None 0x2d 24 dc 0 24 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x2e 24 dc 0 24 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x2f 24 dc 0 24 0 r y . 8 8 8 8 0 0 0 16 16 16 0 0 0 Slow 0x30 24 dc 0 24 0 r . . 8 8 8 8 0 0 0 16 16 16 0 0 0 Slow 0x31 24 dc 0 24 0 r y . 8 8 8 8 0 24 8 16 16 16 0 0 0 Slow 0x32 24 dc 0 24 0 r . . 8 8 8 8 0 24 8 16 16 16 0 0 0 Slow Brian Penix. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI savage driver status
you might compare it to Tim's old 2D driver (shipped with 4.3.0) and see what's changed...assuming his driver works for you in 2D. Alex --- Rafael Maximo <[EMAIL PROTECTED]> wrote: > > Hi, > > I decided to focus on 2D problem first but i don't know how > I can > debug the 2D driver and found where is the problem. I would > appreciate any > information or docs about debugging this kind of problem. > > I'm using the 2D driver on savage_1-0-0_branch and i didn't > change > anything except Imakefile because it is pointing to wrong directorys. > > Thanks. > > > Rafael Máximo > > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] good news for savage users or not ???
On Gwe, 2003-09-12 at 19:53, Maximo wrote: > As i know CLE266 works only on Xfree86 4.2.0, what i'm doing is make > it work on xfree86 4.3.0 I promised folks I'd get around to putting up the XFree 4.3.0 port of the DRI stuff (or what works so far). Don't get too excited as it works if 1. 2D accel is off, 2. The 3D window is on the top 3. It feels like it 4. You run glxgears and not much else. The tar ball of the via gl directory can be found at. http://www.linux.org.uk/~alan/via-gl.tar.gz and is hopefully useful for building a proper via branch in CVS. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 717] X server should unload DRM module when X quits (prevents DRI on multiple cards)
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=717 --- Additional Comments From [EMAIL PROTECTED] 2003-20-09 22:34 --- > That's the symptom, but I don't agree with your analysis of the cause or > conclusion what should be done about it. My thoughts were based on comment #1 which suggested that the "r128 DRM in kernel 2.4.22 doesn't deinitialize correctly". > Does it also fail if you load the other DRM manually (instead of unloading the > first one) before starting the second server? Thanks for the suggestion. I let the "r128" stay loaded (after quitting X). Then I manually loaded the tdfx module and then started X on the voodoo3 card and DRI worked !! This is what I have from lsmod: Module Size Used byNot tainted tdfx 35384 17 r128 81364 1 agpgart47524 1 (autoclean) I also have: crw-rw-rw-1 root root 226, 0 Sep 20 12:33 /dev/dri/card0 crw-rw-rw-1 root root 226, 1 Sep 20 22:23 /dev/dri/card1 In other words, manual loading works. Also, it appears from lsmod that the r128 module is still being used (even though X is not using the rage128 card). Any ideas ? -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: DRI savage driver status (Rafael Maximo)
Brian, I'm interested seeing the savage driver working on XFfree86 4.3.0 with mesa 5.0.x, you are using a savage driver that is supposed to work on xfree86 4.2.0 and i'm working on the same driver but trying to make it works on xfree86 4.3.0 bye. At 08:28 PM 20/9/2003, Brian Penix wrote: I have been following with interest your trials and tribulations with the Savage 3D driver. I too am working on it and may have some info for you. I have all the driver functions working here but only in XFree86 4.2.0. (mesa 3.4.2) I am currently looking for info on the changes to T&L and SWRAST that seems to be the tie up for this driver. As it stands, mesa 5.0.x seems screwy to me and I have to learn bunches more on it. If you want I can give you what I have so far (meaning my mesa 5.0.x based driver files). I am not experiencing the artifacts you are but maybe my card is slightly different. In any event, if you want to collaborate with me I think we can figure this out. To show you that it can work here is my current mesa 3.4.2 glxinfo: [EMAIL PROTECTED] penix1]$ glxinfo name of display: :0.0 Using AGP dma| DBflag:0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context client glx vendor string: SGI client glx version string: 1.2 client glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context OpenGL vendor string: S3 Graphics Inc. OpenGL renderer string: Mesa DRI SAVAGE Linux_1.1.18 OpenGL version string: 1.2 Mesa 3.4.2 OpenGL extensions: GL_ARB_multitexture, GL_ARB_transpose_matrix, GL_EXT_abgr, GL_EXT_blend_func_separate, GL_EXT_clip_volume_hint, GL_EXT_compiled_vertex_array, GL_EXT_histogram, GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_stencil_wrap, GL_EXT_texture3D, GL_EXT_texture_env_add, GL_EXT_texture_object, GL_EXT_texture_lod_bias, GL_EXT_vertex_array, GL_MESA_window_pos, GL_MESA_resize_buffers, GL_NV_texgen_reflection, GL_PGI_misc_hints, GL_SGIS_pixel_texture, GL_SGIS_texture_edge_clamp glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x23 24 tc 0 24 0 r y . 8 8 8 8 0 0 0 0 0 0 0 0 0 None 0x24 24 tc 0 24 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 None 0x25 24 tc 0 24 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x26 24 tc 0 24 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x27 24 tc 0 24 0 r y . 8 8 8 8 0 0 0 16 16 16 0 0 0 Slow 0x28 24 tc 0 24 0 r . . 8 8 8 8 0 0 0 16 16 16 0 0 0 Slow 0x29 24 tc 0 24 0 r y . 8 8 8 8 0 24 8 16 16 16 0 0 0 Slow 0x2a 24 tc 0 24 0 r . . 8 8 8 8 0 24 8 16 16 16 0 0 0 Slow 0x2b 24 dc 0 24 0 r y . 8 8 8 8 0 0 0 0 0 0 0 0 0 None 0x2c 24 dc 0 24 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 None 0x2d 24 dc 0 24 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x2e 24 dc 0 24 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x2f 24 dc 0 24 0 r y . 8 8 8 8 0 0 0 16 16 16 0 0 0 Slow 0x30 24 dc 0 24 0 r . . 8 8 8 8 0 0 0 16 16 16 0 0 0 Slow 0x31 24 dc 0 24 0 r y . 8 8 8 8 0 24 8 16 16 16 0 0 0 Slow 0x32 24 dc 0 24 0 r . . 8 8 8 8 0 24 8 16 16 16 0 0 0 Slow Brian Penix. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel Rafael Máximo --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 716] GLX applications/commands very slow on ATI rage128
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=716 --- Additional Comments From [EMAIL PROTECTED] 2003-20-09 23:45 --- I would investigate the unresolved symboles. Do a 'grep ^Symbol' on the XFree86.1.log that is attached. That seems hinkey to me. I did a 'grep -r' in lib/GL in DRI CVS for each of those symbols, and *none* of them appear anywhere in the source code. Since they don't exist in the source, it seems odd that the .so should depend on them. -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
