Re: r300 driver support for Hypermemory cards?
GhePeU wrote: And, secondly, do AIGLX or XGL work on such cards? The r300 driver works very well with XGL. I have an X700 mobility, and XGL works *beautifully*. Just recently, I've started to get good results ( ie no hard lockups ) with AIGLX - but with the new 'beryl' window manager, which is Quinnstorm's fork of compiz. As Roland pointed out, with only a 64 bit bus you're not going to get astounding performance, so you might see some issues with heavy use of compiz effects, but then again I don't think it will be all that bad. As a point of comparison, I've been using compiz with AIGLX on an integrated Intel chip at work ( in i845G ). It has no RAM of it's own, and can only see 'up to' 8MB of system RAM! It works fine with AIGLX - it's actually quite impressive. It's quite *unimpressive* with XGL - painfully slow. According this this page: http://www.sharkyextreme.com/hardware/motherboards/article.php/10703_1141511__3 the i845G has a 64-bit memory bus ( if I'm reading it correctly ). So I'd say at least for compiz ( or beryl ) on AIGLX, your chosen Radeon should be sufficient. Also, avoid the Radeon Xpress cards like the plague. The memory controller is not supported with the open-source r300 driver, and ATI's proprietary driver locks hard when starting XGL. Dan - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 driver support for Hypermemory cards?
Il giorno dom, 08/10/2006 alle 02.29 +0200, Roland Scheidegger ha scritto: AFAIK Hypermemory is a pure marketing gimmick, the chip used on these cards is no different than the normal cards, they just have less onboard ram (and only a 64bit memory bus). So I'd suspect it should work just fine BUT the driver will only use the onboard ram, and 32MB is probably not quite enough if you need more than 2d (not to mention it'd be slower than the normal 128bit cards), though I think there are X300SE or X550 out there with 64 or 128MB onboard ram. So a X550 HM 512MB (with 128MB onboard) will work exactly as good or bad as a X550SE 128MB, since, well, it's the exact same card with a different name... (someone correct me if I'm wrong and there might be problems with for instance different default setups of apertures which could lead to problems but I don't think so). Yes, the reviews I've read pointed out that this Hypermemory is just marketing. But if the r300 driver works without compatibility problems with this feature, I can discard the X300SE 64 bit without Hypermemory and point to a Sapphire X550 256/512HM which seems to have 256 MB on-board and, according to some sites, 128 bit memory bus. Dunno exactly, but the basic support should be the same as any other r300-based card. Though the 64bit cards definitely are no speed demons, no amount of marketing buzzwords will help unfortunately in that area, but I'm not sure if that would be visible for aiglx or xgl. Low amounts of video memory will probably make a difference, though. Personally, I'd never really recommend any radeon card with only a 64bit memory bus (save the good old simple radeon 7000...), marketing-enhanced or not, but since these are obviously sold quite often I must be alone with that opinion... IMHO, you're paying almost as much as the full 128bit cards for basically half the performance. You're not alone, but most people who bother to read specs and reviews are interested only in high-end cards. So the entry-level market is a hell of conflicting model numbers and brand names, and most manufacturers and retailers now offer only X300/X550 or X1300 and newer cards. The choice was X550 or Nvidia, and I don't like closed source drivers. Thank you for your time. GhePeU - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 8554] New: using dri and dual head crashes x with i810 driver
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=8554 Summary: using dri and dual head crashes x with i810 driver Product: DRI Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: critical Priority: P2 Component: General AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] I have a thinkpad x60 with an intel 945GM graphics controller, and I have configured Xorg to use dual head. When I try to run glxinfo (or glxgears or any other application using dri, such as xscreensaver), X crashes. If I use an Xorg-configuration without dual head, dri works fine. I'm using Xorg 7.1 and version 1.7 of the i810 driver. The crash is reported in Xorg.0.log like this: [...] AUDIT: Sun Oct 8 12:45:04 2006: 11655 X: client 8 rejected from local host Backtrace: 0: /usr/bin/X(xf86SigHandler+0x84) [0x80d0084] 1: [0xb7f91420] 2: /usr/lib/xorg/modules/extensions/libglx.so [0xb7cb3bbb] 3: /usr/lib/xorg/modules/extensions/libglx.so(__glXleaveServer+0x22) [0xb7c8fd32] 4: /usr/lib/xorg/modules/extensions/libglx.so [0xb7c9034e] 5: /usr/bin/X(Dispatch+0x19b) [0x8086cdb] 6: /usr/bin/X(main+0x488) [0x806e6e8] 7: /lib/libc.so.6(__libc_start_main+0xd8) [0xb7d35878] 8: /usr/bin/X(FontFileCompleteXLFD+0xad) [0x806da11] Fatal server error: Caught signal 11. Server aborting (II) Screen 0 shares mem io resources (II) Screen 1 shares mem io resources (II) AIGLX: Suspending AIGLX clients for VT switch (WW) I810(0): Extended BIOS function 0x5f64 failed. (WW) I810(0): Extended BIOS function 0x5f64 failed. (WW) I810(0): Failed to set display devices to 0x800. (WW) I810(0): Enabling LVDS directly. Pipe B. (WW) I810(0): Disabling ADPA directly. (WW) I810(0): Writing config directly to SWF0. (WW) I810(0): Successfully set original devices (II) I810(0): xf86UnbindGARTMemory: unbind key 8 (II) I810(0): xf86UnbindGARTMemory: unbind key 0 (II) I810(0): xf86UnbindGARTMemory: unbind key 1 (II) I810(0): xf86UnbindGARTMemory: unbind key 3 (II) I810(0): xf86UnbindGARTMemory: unbind key 4 (II) I810(0): xf86UnbindGARTMemory: unbind key 2 (II) I810(0): xf86UnbindGARTMemory: unbind key 5 (II) I810(0): xf86UnbindGARTMemory: unbind key 6 (II) I810(0): xf86UnbindGARTMemory: unbind key 7 (WW) I810(0): Successfully set original devices (2) This is my first bug report, so if some important information is missing, tell me, and I'll add it. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] partly working fragment.position patch
Keith Whitwell wrote: Rune Petersen wrote: Rune Petersen wrote: Roland Scheidegger wrote: Rune Petersen wrote: I hit a problem constructing this: - In order to do range mapping in the vertex shader (if I so choose) I will need a constant (0.5), but how to add it? I think this might work similar to what is used for position invariant programs, instead of using _mesa_add_state_reference you could try _mesa_add_named_parameter. Otherwise, you could always construct 0.5 in the shader itself, since you always have the constants 0 and 1 available thanks to the powerful swizzling capabilities, though surprsingly it seems somewhat complicated. Either use 2 instructions (ADD 1+1, RCP). Or try EX2/EXP though I'm not sure about performance of these, but I guess the approximated EXP should do (2^-1). This math in this patch appear sound. the doom3-demo issue appear unrelated to fragment.position. This version makes use of existing instructions to calculate result.position. split into 2 parts: - select_vertex_shader changes - The actual fragment.position changes This patch assumes that: - That the temp used to calculate result.position is safe to use (true for std. use). - That fragment.position.x y wont be used (mostly true, except for exotic programs.) In order to fix this, I'll need to know the window size, but how? Surely it's right there in radeon-dri.drawable ? Now I remember why I can't use radeon-dri.drawable, at least not directly when the shader code is added: When the window size changes the constants have to be updated. Is there a way for the driver to update a constant after construction? Rune Petersen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 5986] [radeon] The X server locks up after a few days
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=5986 --- Additional Comments From [EMAIL PROTECTED] 2006-10-08 05:37 --- Linux 2.6.18, DRM git, Mesa cvs, and ati driver git: 1st try: glxgears very slow, StepMania produces black screen only (hard reboot) 2nd try: Xorg.0.log says DRI initialized fine but produces lots of warning about visuals unsupported by dri driver. glxinfo says rendering is indirect glxgears locks up X even before it's window is shown. It looks like the same thing as previosly - I can normally shut down the machine using the power button (acpid), the picture displayed on the screen does not change until poweroff. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] partly working fragment.position patch
Rune Petersen wrote: Keith Whitwell wrote: Rune Petersen wrote: Rune Petersen wrote: Roland Scheidegger wrote: Rune Petersen wrote: I hit a problem constructing this: - In order to do range mapping in the vertex shader (if I so choose) I will need a constant (0.5), but how to add it? I think this might work similar to what is used for position invariant programs, instead of using _mesa_add_state_reference you could try _mesa_add_named_parameter. Otherwise, you could always construct 0.5 in the shader itself, since you always have the constants 0 and 1 available thanks to the powerful swizzling capabilities, though surprsingly it seems somewhat complicated. Either use 2 instructions (ADD 1+1, RCP). Or try EX2/EXP though I'm not sure about performance of these, but I guess the approximated EXP should do (2^-1). This math in this patch appear sound. the doom3-demo issue appear unrelated to fragment.position. This version makes use of existing instructions to calculate result.position. split into 2 parts: - select_vertex_shader changes - The actual fragment.position changes This patch assumes that: - That the temp used to calculate result.position is safe to use (true for std. use). - That fragment.position.x y wont be used (mostly true, except for exotic programs.) In order to fix this, I'll need to know the window size, but how? Surely it's right there in radeon-dri.drawable ? Now I remember why I can't use radeon-dri.drawable, at least not directly when the shader code is added: When the window size changes the constants have to be updated. Is there a way for the driver to update a constant after construction? This is an age-old dilemma... The i965 driver gets around this by locking the hardware before validating and emitting state and drawing commands and unlocking again afterwards - so the window can't change size in the meantime. Other drivers tend to just deal with the occasional incorrectness. In general this is something we need to get a bit better at. API's like DX9 and GL/ES do away with frontbuffer rendering which gives the drivers a lot more flexibility in terms of dealing with window moves and resizes, allowing them to pick a time to respond to a resize. With private backbuffers we might get the same benefits at least in the common case. Keith Keith - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 7392] Vertex selection bug with r300 driver in blender
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=7392 --- Additional Comments From [EMAIL PROTECTED] 2006-10-08 09:51 --- Do you still experience this bug with current cvs ? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] partly working fragment.position patch
Keith Whitwell wrote: Now I remember why I can't use radeon-dri.drawable, at least not directly when the shader code is added: When the window size changes the constants have to be updated. Is there a way for the driver to update a constant after construction? This is an age-old dilemma... The i965 driver gets around this by locking the hardware before validating and emitting state and drawing commands and unlocking again afterwards - so the window can't change size in the meantime. Other drivers tend to just deal with the occasional incorrectness. In general this is something we need to get a bit better at. API's like DX9 and GL/ES do away with frontbuffer rendering which gives the drivers a lot more flexibility in terms of dealing with window moves and resizes, allowing them to pick a time to respond to a resize. With private backbuffers we might get the same benefits at least in the common case. I think Rune is rather refering to the fact that you can't change (not with legal means at least) the constant you got with _mesa_add_unnamed_constant. I think there exist at least 2 solutions for that. The clean way would probably be to add some more INTERNAL_STATE (like i965 driver uses) so you use _mesa_add_state_reference instead, in this case mesa's shader code would need to update program parameter based on the drawable information - I'm not sure if accessing a driver's drawable information there would get messy). The easier solution would probably be to just directly manipulate the ParameterValues entry associated with the constant you added, easy though it might be considered somewhat hackish. Just don't forget you not only have to update the constant within r300UpdateWindow (if the currently bound fp requires it), but also when the active fp is switched to another one (and make sure that a parameter upload is actually triggered if it not already is upon drawable changes). Roland - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 6409] XvMC on Intel i810
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=6409 --- Additional Comments From [EMAIL PROTECTED] 2006-10-08 14:03 --- Tried again under Kubuntu 6.06, with Xine -V xvmc : abort: video_out_xvmc.c:652: xvmc_set_context: Aborting. Still no xvmc avaliable on i810 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 driver support for Hypermemory cards?
On Sun, 2006-10-08 at 18:22 +1000, Daniel Kasak wrote: GhePeU wrote: And, secondly, do AIGLX or XGL work on such cards? The r300 driver works very well with XGL. I have an X700 mobility, and XGL works *beautifully*. Just recently, I've started to get good results ( ie no hard lockups ) with AIGLX - but with the new 'beryl' window manager, which is Quinnstorm's fork of compiz. As Roland pointed out, with only a 64 bit bus you're not going to get astounding performance, so you might see some issues with heavy use of compiz effects, but then again I don't think it will be all that bad. As a point of comparison, I've been using compiz with AIGLX on an integrated Intel chip at work ( in i845G ). It has no RAM of it's own, and can only see 'up to' 8MB of system RAM! It works fine with AIGLX - it's actually quite impressive. It's quite *unimpressive* with XGL - painfully slow. According this this page: http://www.sharkyextreme.com/hardware/motherboards/article.php/10703_1141511__3 the i845G has a 64-bit memory bus ( if I'm reading it correctly ). So I'd say at least for compiz ( or beryl ) on AIGLX, your chosen Radeon should be sufficient. I'm afraid that's comparing apples and oranges. Integrated chipsets tend to be less affected by the current inefficiencies of the AIGLX GLX_EXT_texture_from_pixmap implementation, probably because moving stuff into and out of the framebuffer is cheaper than with discrete cards. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 8489] Blue patches in textures with r300
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=8489 --- Additional Comments From [EMAIL PROTECTED] 2006-10-08 21:06 --- Has anyone got any idea why the alpha channel isn't being correctly written with fragment programs, and why I get blue patches after the commit I mentioned earlier? I'm not sure about the first, but the later could be the texture format is incorrectly selected? As far as I can tell, that's all the commit does; selects a different texture format based on a few things... I really like to see these bugs fixed, but there hasn't been any real activity on this bug for a while now. :( -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
