[Dri-devel] texmem changes for sarea and DRM..
In i810_dri.h there is a warning.. /* WARNING: Do not change the SAREA structure without changing the kernel * as well */ for texmem I want to apply the same patch as.. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/programs/Xserver/hw/xfree86/drivers/i810/i830_dri.h.diff?r1=1.6&r2=1.7 from the i830 .. however this makes a change to the SAREA and I can find no corresponding info in the DRM, is the new TextureRegion structure the same size as the old one and it just works? Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / [EMAIL PROTECTED] pam_smb / Linux DECstation / Linux VAX / ILUG person --- 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] i810 texmem patch..
Okay I've gotten around to updating the i810 driver to texmem interface... http://www.skynet.ie/~airlied/patches/dri/i810_texmem.diff I've a couple of issues perhaps someone can help with: 1. In texstate.c UpdateTexUnit for most drivers (except i830) the following appears: driUpdateTextureLRU( (driTextureObject *) t ); /* XXX: should be locked */ I've taken this approach as well.. but should it be locked? if so how? is the i830 correct should I try to do something similiar? 2. context.c driCalculateMaxTextureLevels from the i830 has a big FIXME beside it about how the intel chips don't pack as well as everyone elses, 3. I 've noticed I've had to increase my Videoram from 16384 (to run my internal application, else I get some all white textures..), so I've probably messed up some allocation somehwere. .should texmem need more RAM? apart from all that it seems to work :-) patch is also missing the sarea change .. it generates a warning... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / [EMAIL PROTECTED] pam_smb / Linux DECstation / Linux VAX / ILUG person --- 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 314] No 3D support for Radeon IGP chips
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=314 --- Additional Comments From [EMAIL PROTECTED] 2003-01-09 00:06 --- hardware hp pavilion ze5200 kernel 2.6.0-test4 agp patch - http://bugs.xfree86.org/attachment.cgi?id=540&action=view Edited /usr/src/linux-2.6.0-test4/include/linux/pci_ids.h change cab2 to cbb2 XFree86-4.3.99.11 Applied config patch at: http://www.mail-archive.com/[EMAIL PROTECTED]/msg02875.html fps with glxgears is 540 XF86Config section is: Identifier "Card0" Driver "ati" VendorName "ATI Technologies Inc" BoardName "Radeon IGP 340M" BusID "PCI:1:5:0" Option "DMPS" Option "AGPMode" "4" # Option "AGPFastWrite" "on" # [] Option "EnablePageFlip" "on" # [] EndSection -- 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 609] Screen remains blank when starting X w/ radeon 3D enabled
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=609 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED] |dri- ||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-01-09 04:49 --- OK, I'll reassign this to DRI for further decision how to handle this situation. -- 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 314] No 3D support for Radeon IGP chips
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=314 --- Additional Comments From [EMAIL PROTECTED] 2003-01-09 07:30 --- Hi, found some strange things: When DRI enabled glxgears gives mit only 100FPS!!! Without it is approx. 280 FPS. Here the relevant part of XF86Config: Section "Device" BoardName"Radeon Mobility IGP 320M" Driver "radeon" Identifier "Device[0]" Option "DPMS" Option"AGPFastWrite" "on" Option"AGPMode" "4" Option"EnablePageFlip" "on" Screen 0 Option "Rotate" "off" VendorName "ATI" EndSection Could this be due to IRQ workaround?? See above my previos postings. Or what is going on here...? Greets Martin -- 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] i810 texmem patch..
Dave Airlie wrote: Okay I've gotten around to updating the i810 driver to texmem interface... http://www.skynet.ie/~airlied/patches/dri/i810_texmem.diff I've a couple of issues perhaps someone can help with: 1. In texstate.c UpdateTexUnit for most drivers (except i830) the following appears: driUpdateTextureLRU( (driTextureObject *) t ); /* XXX: should be locked */ I've taken this approach as well.. but should it be locked? if so how? is the i830 correct should I try to do something similiar? Because this function call modifies the global (ie shared memory) LRU, it should be locked, eg. with LOCK_HARDWARE() macros. Why isn't it? I can't remember - there might not be any good reason. 2. context.c driCalculateMaxTextureLevels from the i830 has a big FIXME beside it about how the intel chips don't pack as well as everyone elses, 3. I 've noticed I've had to increase my Videoram from 16384 (to run my internal application, else I get some all white textures..), so I've probably messed up some allocation somehwere. .should texmem need more RAM? I've recently had some reports about texture corruption in the i830 driver when using lots of textures. Something is lurking in there, I think. apart from all that it seems to work :-) patch is also missing the sarea change .. it generates a warning... Dave. Keith --- 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] texmem changes for sarea and DRM..
Dave Airlie wrote: In i810_dri.h there is a warning.. /* WARNING: Do not change the SAREA structure without changing the kernel * as well */ for texmem I want to apply the same patch as.. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/programs/Xserver/hw/xfree86/drivers/i810/i830_dri.h.diff?r1=1.6&r2=1.7 from the i830 .. however this makes a change to the SAREA and I can find no corresponding info in the DRM, is the new TextureRegion structure the same size as the old one and it just works? I believe they are the same size, and that the kernel module never looked inside this structure. Keith --- 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] svideo output scrambled
the open source radeon Xfree drivers do not support tv out yet. You might check with the GATOS people (http://gatos.sf.net). it works in the console because the BIOS is driving the outputs rather than the driver. Alex --- Chris Ison <[EMAIL PROTECTED]> wrote: > I'm wondering if there is a way to easily correct the svideo output > in > the radeon driver (r200). Its currently "out of sync" and flickers > badly, but it does try to display something. It works fine for linux > consoles. Windows has the svideo output set to 50Hz if thats of any > help. > > __ 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] video memory requirements for dri
Alex Deucher wrote: there is a driver option in your config file to choose how much ram you want to use for your adapter. I don't remember what it is off hand. VideoRam 32000 or some other number Keith --- 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] radeon error
Hi together, recently I sended an email to Keith who directed me to this list. My application (ABAQUS, see below for details) crashes if I use your r200-dri-module. The particular error is: r200_maos_arrays.c:298: emit_vector: Assertion `0' failed. and the spplication died. Currently I am using the r200-20030821-linux.i386.tar.bz2-snapshot and tried several others before without change. I installed the source of XFree 4.3 too. Do you know what is going wrong and what can I do to help you to fix this problem. I use a Radeon 9000 (Radeon R250 If) card. Please feel free to ask me any other information you need. Thanks in advance Thomas P.S.: Since I am new to this list a short intro:-) I am an application engineer for ABAQUS Deutschland, a daughter of ABAQUS, Inc. with HQ in Pawtucket,RI. ABAQUS is a Finite-Element code which uses OpenGL and direct rendering for pre and postprocessing. I am now for many years in the linux stuff involved but I am not so familiar with graphics code. -- Thomas Emmel <[EMAIL PROTECTED]> --- 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] radeon error
Thomas Emmel wrote: Hi together, recently I sended an email to Keith who directed me to this list. My application (ABAQUS, see below for details) crashes if I use your r200-dri-module. The particular error is: r200_maos_arrays.c:298: emit_vector: Assertion `0' failed. and the spplication died. Ah, ok. I lost track of who I was talking to -- this really is my problem, but lets keep it on the list now it's there. Currently I am using the r200-20030821-linux.i386.tar.bz2-snapshot and tried several others before without change. Can you provide me a backtrace from gdb of the crash? Can you go 'up' several stack frames until you get to 'emit_vector' and then print out the value of 'size'? Keith --- 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] radeon error
On Mon, 2003-09-01 at 16:28, Keith Whitwell wrote: > > r200_maos_arrays.c:298: emit_vector: Assertion `0' failed. > > and the spplication died. > Can you provide me a backtrace from gdb of the crash? This is part of the backtrace: #5 0x458e59b2 in __assert_fail () from /lib/libc.so.6 #6 0x4678f82f in emit_vector (ctx=0x8295238, rvb=0x8294a48, data=0x501fcc40 "TÁ©DH=,D\206\235\201C\216\223", size=1, stride=4, count=42) at r200_maos_arrays.c:298 #7 0x4678fbee in r200EmitArrays (ctx=0x8295238, inputs=265) at r200_maos_arrays.c:418 #8 0x46794fbd in r200_run_tcl_render (ctx=0x8295238, stage=0x0) at r200_tcl.c:277 #9 0x46758001 in _tnl_run_pipeline (ctx=0x8295238) at t_pipeline.c:154 #10 0x4677f871 in r200WrapRunPipeline (ctx=0x8295238) at r200_state.c:2136 #11 0x4674c0c5 in _tnl_DrawArrays (mode=8, start=39, count=42) at t_array_api.c:243 #12 0x466ec6e9 in neutral_DrawArrays (mode=8, start=0, count=42) at vtxfmt_tmp.h:362 #13 0x080f7e09 in ogl_Renderer::DrawArrays(g3d_PrimitiveEnum, int, int) () #14 0x5011f5ea in bmg_QuadStrips::Draw1OStripsNdContour(gdr_Renderer&, float const (*) [3], float const (*) [3], float, float, float, bmg_ShpRefinementLevelEnm, bool, float (*)(int, int, int, int, int, int, int, int, int, int, int, bool&), bool (*)(int, int, int), bmg_ContourColor const*, bool, bool, bool, bool) const () from /backup/opt-abaqus/abaqus/6.4-PR11/cae/exec/lbr/libHKSbmg.so #... > > Can you go 'up' several stack frames until you get to 'emit_vector' and then > print out the value of 'size'? several up's: (gdb) up #6 0x4678f82f in emit_vector (ctx=0x8295238, rvb=0x8294a48, data=0x501fcc40 "TÁ©DH=,D\206\235\201C\216\223", size=1, stride=4, count=42) at r200_maos_arrays.c:298 298 r200_maos_arrays.c: No such file or directory. in r200_maos_arrays.c (gdb) print size $1 = 1 > > Keith > > Hope thats enough. Thomas -- Thomas Emmel <[EMAIL PROTECTED]> --- 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] Weekly IRC meeting reminder
This is just a friendly reminder that the weekly dri-devel IRC meeting will be starting in the #dri-devel channel on irc.freenode.net at 2100 UTC (or 5:00PM EDT or 2:00PM PDT, if you prefer). Time zone conversion available at: http://www.timezoneconverter.com/cgi-bin/tzc.tzc Logs of previous IRC meetings are available at: http://dri.sourceforge.net/IRC-logs/ --- 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] More about AGP
Hello I tried enabling AGP Fast Writes and the performance increased. But my system also got unstable. After reading about Fast Writes I came to the conclusion that it is quite a problematic feature sometimes. If I understood right, Fast Writes works so that cpu can send data directly to the graphics card. Wouldn't the fastest way to transmit data be to tell the card to load the data from main memory? This way the cpu wouldn't have to wait for the copying to finish and could something else at the same time. [EMAIL PROTECTED] --- 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] High-resolution monitors (T221)
Ok, this is pretty off-topic, but I'm wondering what the status is for open-source support of 3D-capable drivers for such studly monitors as the IBM T221. Yes, it's still expensive as hell, but it isn't nearly as bad as it was a few years ago when it was very limited availability, and cost USD $20k+. These days it is "only" $9k or so and apparently is actually available in the sales channel. The thing is a 3840x2400 pixel monster, and to drive it at reasonable frequencies you actually need to support a quad DVI setup where it looks basically like four monitors running at 1920x1200. And from what I can gather by googling, the outputs need to be synchronized, so you really need to have a card like the NVidia Quadro4 XGL or similar (ie you can apparetly _not_ drive it with multiple separate video cards). Apparently it also does work with just a single DVI thing (ie reports of it working with the Radeon 8500 at least on macs), probably at a much reduced frequency (ie a single DVI link should be able to drive the thing at something like 10Hz refresh rate - I think the Radeon 8500 supports two links on its single DVI-I interface, so should get up to 20Hz?). The binary-only NVidia driver supports it at the full 40Hz frequency, so I know I can get the thing to work under Linux in case I decide to waste the money on it (or, preferably, convince my employer to do so ;) However, I was wondering if anybody knows of somebody using it with proper opensource drivers.. Or is just otherwise confident for some technical reason that it should work.. I'd want 3D acceleration to work, but I don't care if it ends up being limited to smaller areas (ie if the canvas size has to be limited to 2048x1536 or something, who cares?). Damn, but it's a drool-inducing piece of hardware. Linus --- 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] High-resolution monitors (T221)
> Damn, but it's a drool-inducing piece of hardware. Indeed - Tim has one on his desk and it's virtually impossible to spot single pixels on it :) Be warned though if you plan to get one, the low refresh rate can be very annoying. -- Daniel, Epic Games Inc. --- 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] High-resolution monitors (T221)
Linus Torvalds wrote: The thing is a 3840x2400 pixel monster, and to drive it at reasonable frequencies you actually need to support a quad DVI setup where it looks basically like four monitors running at 1920x1200. And from what I can gather by googling, the outputs need to be synchronized, so you really need to have a card like the NVidia Quadro4 XGL or similar (ie you can apparetly _not_ drive it with multiple separate video cards). Apparently it also does work with just a single DVI thing (ie reports of it working with the Radeon 8500 at least on macs), probably at a much reduced frequency (ie a single DVI link should be able to drive the thing at something like 10Hz refresh rate - I think the Radeon 8500 supports two links on its single DVI-I interface, so should get up to 20Hz?). I don't know of much cards which have dual-link tmds. Even all the Quadro4 XGL cards only have 2 single tmds links. The Quadro NVS 400 (PCI) supports 4 single links, but I have no idea if there is linux/3d support in the driver (basically I believe this is just 2 GeForce4MX 420 chips on one board). If you get the Quadro FX 2000 or 3000 (but not 1000), it has one dual-link and one single-link DVI connectors. All ATI consumer cards have only 1 single tmds link (there were announcements from tyan about dual-dvi cards, but the cards were apparently cancelled). The firegl cards (at least the newer ones based on the "gaming chips") have two single tmds links. The binary-only NVidia driver supports it at the full 40Hz frequency, so I know I can get the thing to work under Linux in case I decide to waste the money on it (or, preferably, convince my employer to do so ;) I assume you can get the 40Hz only with the FX2000/3000? The reviews I read stated something like 12Hz if they only used 1 dvi output of a Quadro4 XGL, and double of that (but with tearing due to sync issues in 3d - not sure if this is driver fixable) if they used both dvi connectors. However, I was wondering if anybody knows of somebody using it with proper opensource drivers.. Or is just otherwise confident for some technical reason that it should work.. I'd want 3D acceleration to work, but I don't care if it ends up being limited to smaller areas (ie if the canvas size has to be limited to 2048x1536 or something, who cares?). If I'm not mistaken it doesn't work currently, however ATI's windows drivers support larger resolutions (with 3d), so it looks like it's possible to work around the chip limits (which is 2560x2560 for the r300 (and derivatives) and 2048x2048 for the r200). Last time I checked ATI's linux driver didn't support those larger resolutions (if 3d is enabled) however. Damn, but it's a drool-inducing piece of hardware. Unfortunately still out of my price range by quite a bit... Roland --- 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] Updated configuration design doc
On Sun, 31 Aug 2003 12:35:22 +0200 smitty <[EMAIL PROTECTED]> wrote: > > > I updated the configuration design document to reflect the current > > state of the implementation. The new document is available at > > http://user.cs.tu-berlin.de/~felixyz/dri/dri_config_design_rev4.txt if > > anyone is still interested given a mostly complete implementation. ;-) > > Maybe someone wants to add this to the documentation section of > > dri.sf.net. I would make a HTML version too, if there is interest. > I've been really busy so I have a huge backlog of DRI email to read. > > I'm perfectly happy with dri config being mentioned / explained / > documented on the website. > > Well html is good if you want it on the web site. http://user.cs.tu-berlin.de/~felixyz/dri/dri_config_design_rev4.html I finally managed to upload it. The webserver was apperently down yesterday. > > Liam > > it depends Regards, Felix __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- 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] High-resolution monitors (T221)
Linus, Some dell OEM radeon cards offered Dual DVI ports and I believe there are some other oems (tyan?) that will be offering Dual DVI cards. the radeon 9000s and newer only have one tdms trandsmitter built in, but an additional external one can be added on to drive the second DVI port. for multi-head 3D on radeon hardware, check out my mergedfb patch: http://bugs.xfree86.org/show_bug.cgi?id=276 Unfortunately, due to a hardware limitation with the scissor registers, you are limited to 2048x2048 for 3D. your framebuffer can be as large as 8192x8192 (limits for the 2D engine). you can use mergedfb at resolutions higher than 2048x2048, however, any 3D windows larger than 2048x2048 will not display. Alex --- Linus Torvalds <[EMAIL PROTECTED]> wrote: > > Ok, this is pretty off-topic, but I'm wondering what the status is > for > open-source support of 3D-capable drivers for such studly monitors as > the > IBM T221. > > Yes, it's still expensive as hell, but it isn't nearly as bad as it > was a > few years ago when it was very limited availability, and cost USD > $20k+. > These days it is "only" $9k or so and apparently is actually > available in > the sales channel. > > The thing is a 3840x2400 pixel monster, and to drive it at reasonable > frequencies you actually need to support a quad DVI setup where it > looks > basically like four monitors running at 1920x1200. And from what I > can > gather by googling, the outputs need to be synchronized, so you > really > need to have a card like the NVidia Quadro4 XGL or similar (ie you > can > apparetly _not_ drive it with multiple separate video cards). > > Apparently it also does work with just a single DVI thing (ie reports > of > it working with the Radeon 8500 at least on macs), probably at a much > reduced frequency (ie a single DVI link should be able to drive the > thing > at something like 10Hz refresh rate - I think the Radeon 8500 > supports two > links on its single DVI-I interface, so should get up to 20Hz?). > > The binary-only NVidia driver supports it at the full 40Hz frequency, > so I > know I can get the thing to work under Linux in case I decide to > waste the > money on it (or, preferably, convince my employer to do so ;) > > However, I was wondering if anybody knows of somebody using it with > proper > opensource drivers.. Or is just otherwise confident for some > technical > reason that it should work.. > > I'd want 3D acceleration to work, but I don't care if it ends up > being > limited to smaller areas (ie if the canvas size has to be limited to > 2048x1536 or something, who cares?). > > Damn, but it's a drool-inducing piece of hardware. > > Linus > > __ 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] More about AGP
On Mon, 2003-09-01 at 20:41, Jouni Tulkki wrote: > > I tried enabling AGP Fast Writes and the performance increased. But my system > also got unstable. After reading about Fast Writes I came to the conclusion > that it is quite a problematic feature sometimes. Indeed, that's why it's disabled in the XFree86 driver by default. > If I understood right, Fast Writes works so that cpu can send data directly to > the graphics card. Wouldn't the fastest way to transmit data be to tell the > card to load the data from main memory? This way the cpu wouldn't have to wait > for the copying to finish and could something else at the same time. Possibly, but a problem is that the server doesn't receive the image data in the AGP aperture, so an extra copy is still needed. -- 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] SiS DRI status
On Sun, 2003-08-31 at 03:47, Michael Schreckenbauer wrote: > Am Samstag, 30. August 2003 00:02 schrieb Eric Anholt: > > My current diff is at: > > http://people.freebsd.org/~anholt/dri/files/sis-14.diff > > > > It's against DRI CVS. Should work fine on Linux/FreeBSD, with or > > without sisfb. I haven't tested the linux-without-sisfb case, though. > > > > My progress so far: > > * glxgears, geartrain, tunnel, ipers, fire, multiarb, ray, > > morph3d, isosurf, spectex, gloss, bounce, teapot, reflect all > > work. tuxracer works on FreeBSD. > > * DRM and DDX changes are in DRI CVS HEAD. > > > > To do: > > * Tuxracer crashes in sisDDDeleteTexture on linux. I have no idea > > why (it's crashing freeing memory which I swear is allocated). > > * Not sure if the fogging in fire is correct -- it looks like I > > would expect it to, but it disagrees with software rendering. > > * Issues with clipping/scissoring (texenv, tessdemo -- GLUT_SINGLE > > buffering) > > * Implement / advertise GL extensions. > > * Get AGP support working (waiting for the card to come) > > Hello Eric and the rest of this list, > I'm new to this list, so I hope it's ok to post my experience with this here. > I have tried this patch on a Sis630 based x86-Laptop, Gentoo-Linux with a > heavily patch 2.4.20 Kernel (sisfb). First of all: thanks for this great job, > I am glad to see dri running on this machine :-) > I got a reject on xc/xc/lib/GL/mesa/src/drv/sis/sis_xf86glx.c, when I applied > the patch, it compiled well anyway. I tried glxgears, tuxracer, BillardGL, > chromium B.S.U and foobillard. In glxgears the drawing area sometimes gets a > bit oversized compared to the window in the vertical direction. Those areas > are not redrawn, when I move the window. Artefacts of the gears remain on my > desktop. Resizing the glxgears-window enforces this behaviour. I'm using Kde, > if that matters ;-) glxinfo segfaults directly after showing the glu > extensions: > glu version: 1.3 > glu extensions: > GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess > Segmentation fault > tuxracer works (I can play), but it crashes on quitting. So does chromium > (which works, but is slooow). No issues with BillardGL and foobillard so far, > except the resizing thing. > If you need further information or I can help in any ways, just tell me. I'm a > programmer, but have no experience with dri/drm or Xfree stuff :-( > > Thanks, > Michael Thanks for the feedback. I'd seen the glxgears (and others) extending beyond the window boundaries when I switched from twm to blackbox on the testbox. It looked like it was offset by the width and height of the window decorations (couple pixels to the right, about 20 down). I'm not really sure why that is, but I've got it on the todo as part of the clipping issues. I'm still stuck on what's wrong with tuxracer. Haven't checked out the glxinfo crash. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- 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] High-resolution monitors (T221)
I recently got from ATI Embedded, an eval kit for the M7 and M9 and these cards have dual DVI, granted they don't fit in a PC case too well ( one connector comes out the top of the card :-), but they are only eval boards for embedded designers.. Dave. On Mon, 1 Sep 2003, Alex Deucher wrote: > Linus, > > Some dell OEM radeon cards offered Dual DVI ports and I believe there > are some other oems (tyan?) that will be offering Dual DVI cards. the > radeon 9000s and newer only have one tdms trandsmitter built in, but an > additional external one can be added on to drive the second DVI port. > > for multi-head 3D on radeon hardware, check out my mergedfb patch: > http://bugs.xfree86.org/show_bug.cgi?id=276 > > Unfortunately, due to a hardware limitation with the scissor registers, > you are limited to 2048x2048 for 3D. your framebuffer can be as large > as 8192x8192 (limits for the 2D engine). you can use mergedfb at > resolutions higher than 2048x2048, however, any 3D windows larger than > 2048x2048 will not display. > > Alex > > --- Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > > Ok, this is pretty off-topic, but I'm wondering what the status is > > for > > open-source support of 3D-capable drivers for such studly monitors as > > the > > IBM T221. > > > > Yes, it's still expensive as hell, but it isn't nearly as bad as it > > was a > > few years ago when it was very limited availability, and cost USD > > $20k+. > > These days it is "only" $9k or so and apparently is actually > > available in > > the sales channel. > > > > The thing is a 3840x2400 pixel monster, and to drive it at reasonable > > frequencies you actually need to support a quad DVI setup where it > > looks > > basically like four monitors running at 1920x1200. And from what I > > can > > gather by googling, the outputs need to be synchronized, so you > > really > > need to have a card like the NVidia Quadro4 XGL or similar (ie you > > can > > apparetly _not_ drive it with multiple separate video cards). > > > > Apparently it also does work with just a single DVI thing (ie reports > > of > > it working with the Radeon 8500 at least on macs), probably at a much > > reduced frequency (ie a single DVI link should be able to drive the > > thing > > at something like 10Hz refresh rate - I think the Radeon 8500 > > supports two > > links on its single DVI-I interface, so should get up to 20Hz?). > > > > The binary-only NVidia driver supports it at the full 40Hz frequency, > > so I > > know I can get the thing to work under Linux in case I decide to > > waste the > > money on it (or, preferably, convince my employer to do so ;) > > > > However, I was wondering if anybody knows of somebody using it with > > proper > > opensource drivers.. Or is just otherwise confident for some > > technical > > reason that it should work.. > > > > I'd want 3D acceleration to work, but I don't care if it ends up > > being > > limited to smaller areas (ie if the canvas size has to be limited to > > 2048x1536 or something, who cares?). > > > > Damn, but it's a drool-inducing piece of hardware. > > > > Linus > > > > > > __ > 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 > -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / [EMAIL PROTECTED] pam_smb / Linux DECstation / Linux VAX / ILUG person --- 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] i810 texmem patch..
> > driUpdateTextureLRU( (driTextureObject *) t ); /* XXX: should be locked */ > > I've taken this approach as well.. but should it be locked? if so how? is > > the i830 correct should I try to do something similiar? > > Because this function call modifies the global (ie shared memory) LRU, it > should be locked, eg. with LOCK_HARDWARE() macros. Why isn't it? I can't > remember - there might not be any good reason. I could try and do something similiar to the i830 where it does the updateLRU in its EmitHwState function.. but am wondering why no other driver has an issue.. or doesn't notice it perhaps.. > > 2. context.c driCalculateMaxTextureLevels from the i830 has a big FIXME > > beside it about how the intel chips don't pack as well as everyone elses, > > > > 3. I 've noticed I've had to increase my Videoram from 16384 (to run my > > internal application, else I get some all white textures..), so I've > > probably messed up some allocation somehwere. .should texmem need more > > RAM? > > I've recently had some reports about texture corruption in the i830 driver > when using lots of textures. Something is lurking in there, I think. If I use a lot of textures my program should still run but run slower? it shouldn't show white textures.. which is what it does if I lower the videoram to 16MB, I got this before the texmem change as well if I ran with a low VideoRam setting .. So I think I'll check in the changes I have over the next couple of days as I don't think they really make things any worse.. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / [EMAIL PROTECTED] pam_smb / Linux DECstation / Linux VAX / ILUG person --- 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] i810 texmem patch..
Dave Airlie wrote: driUpdateTextureLRU( (driTextureObject *) t ); /* XXX: should be locked */ I've taken this approach as well.. but should it be locked? if so how? is the i830 correct should I try to do something similiar? Because this function call modifies the global (ie shared memory) LRU, it should be locked, eg. with LOCK_HARDWARE() macros. Why isn't it? I can't remember - there might not be any good reason. I could try and do something similiar to the i830 where it does the updateLRU in its EmitHwState function.. but am wondering why no other driver has an issue.. or doesn't notice it perhaps.. You'd only see it when running multiple apps and in a state of texture swapping. Even then you'd probably only notice poor performance or maybe texture corruption. 2. context.c driCalculateMaxTextureLevels from the i830 has a big FIXME beside it about how the intel chips don't pack as well as everyone elses, 3. I 've noticed I've had to increase my Videoram from 16384 (to run my internal application, else I get some all white textures..), so I've probably messed up some allocation somehwere. .should texmem need more RAM? I've recently had some reports about texture corruption in the i830 driver when using lots of textures. Something is lurking in there, I think. If I use a lot of textures my program should still run but run slower? it shouldn't show white textures.. which is what it does if I lower the videoram to 16MB, I got this before the texmem change as well if I ran with a low VideoRam setting .. Yes, it should just run slower. I'm suprised texmem makes a difference -- this is really worth investigating to find out what texmem is doing differently (assuming you have the time to do so). So I think I'll check in the changes I have over the next couple of days as I don't think they really make things any worse.. Fair enough. Keith --- 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] i810 texmem patch..
> > > > If I use a lot of textures my program should still run but run slower? it > > shouldn't show white textures.. which is what it does if I lower the > > videoram to 16MB, I got this before the texmem change as well if I ran > > with a low VideoRam setting .. > > Yes, it should just run slower. I'm suprised texmem makes a difference -- > this is really worth investigating to find out what texmem is doing > differently (assuming you have the time to do so). texmem doesn't make a huge difference I can do this with the old codebase as well, I was ignoring it out of ignorance, and just upping my Videoram value.. now I think about it it was broken :-) Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / [EMAIL PROTECTED] pam_smb / Linux DECstation / Linux VAX / ILUG person --- 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
