Re: xorg HEAD + Mesa HEAD = boom
Ok, I rebuild it all from fresh CVS checkouts today and made sure the trees had no stale .o file or anything. Result is, it doesn't crash, but doesn't work very well neither. Machine is a ppc32 laptop, Mesa/DRI built with TLS enabled and X built with the new enable-glx-tls option from Kristian. So far, what I've been able to collect is: - DRI r300 doesn't work. I get that when running any GL app: libGL warning: 3D driver returned no fbconfigs. libGL error: InitDriver failed libGL error: reverting to (slow) indirect rendering - AIGLX doesn't work, probably for the same reason as above. Message in log is: (EE) AIGLX error: Calling driver entry point failed(EE) GLX-DRI: reverting to software rendering - When using glxgears and EXA, the gears (software rendering by GLcore on server side) are garbage all over the framebuffer. Looks like the pitch is wrong, not sure exactly what's up there at this point. Seems to work ok with XAA. (I haven't tried indirect GL for ages since until recently, DRI worked fine, so this might be an old breakage). At this point, I didn't have any time to try to track down these issues, thus this email, in case I wake up with everything fixed in CVS tomorrow morning :) Cheers, Ben. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 6111] ATI Radeon 9200 freezes on AMD64 using dri
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=6111 --- Additional Comments From [EMAIL PROTECTED] 2006-03-31 19:53 --- OK, disabling TCL didn't help. It is just X which is locking up, though it doesn't consume any CPU in this state. However when attempting to kill X, the machine does then lock up. -- 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. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 6318] complete hangup with big surface textures
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=6318 --- Additional Comments From [EMAIL PROTECTED] 2006-03-31 23:49 --- I'm not sure what chips you really wanted to block (probably rs400 along with r300?) but rs300 is igp 9100 and afaik works just fine. I'm not sure you want to block rs400 either as their problems are probably not related to dri, only ddx/drm (and the current drm cvs won't initialize with any rs400 id). -- 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. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 6318] complete hangup with big surface textures
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=6318 --- Additional Comments From [EMAIL PROTECTED] 2006-04-01 00:15 --- (In reply to comment #4) I'm not sure what chips you really wanted to block (probably rs400 along with r300?) but rs300 is igp 9100 and afaik works just fine. I'm not sure you want to block rs400 either as their problems are probably not related to dri, only ddx/drm (and the current drm cvs won't initialize with any rs400 id). Includes Radeon 9500/9700/9800 cards now. Im not 100% sure about r9800 though. Feel free to poke if you have more up-to-date info. -- 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. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: driver level sub-pixel rendering?
John Kheit wrote: Sorry Brian, I should have been more specific. I mean more as a final output onto a screen. Using an LCD/CRT's individual RGB subpixels to antialiasing (or some form of screen output enhancement). It seems a lot of the 3D stuff in the GPU is already employing sub-pixel coordinates, so it would be nice if the actual output to the screen would take advantage of that. AFAIK, nobody's hardware does that. When that kind of antialiasing is done for text, I think it's the job of the font rendering code to do so. -Brian --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 6242] [agp mach64] Use DMA buffers for mach64_dma_vertex
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=6242 --- Additional Comments From [EMAIL PROTECTED] 2006-04-01 02:50 --- (In reply to comment #6) It's been a while since I looked at the code in detail, but the problem at the time was a limitation of the DRM buffer management infrastructure. As I recall, there wasn't an easy way to create two sets of DMA buffers, one mapped to userspace, and one which wasn't mapped. I did something that sounds like what you're trying to do, in the Savage driver for command DMA. Instead of using the DMA buffer infractructure I simply created a map of a chunck of AGP memory that can't be mapped to unprivileged clients. The DRM uses that map as a command buffer with its own ageing and buffer management implementation. I was going to try something like that in the Mach64 driver. Not sure how feasible this is or if there are any hardware issues that may prevent this. -- 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. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: driver level sub-pixel rendering?
I think some of the cards use the GPUs for scaling video (and perhaps other optimizations). Kind of like the nice upscaling done by some DVD players. Nvidia calls it PureVideo:http://www.nvidia.com/page/purevideo.html"And the high-precision subpixel processing enables videos to be scaled to any size, so that even small videos look like they were recorded in high-resolution."I'm sure ATI has something similar? I would guess that this kind of thing could also be used for other things sent to it?On Mar 31, 2006, at 11:33 AM, Brian Paul wrote:John Kheit wrote: Sorry Brian, I should have been more specific. I mean more as a final output onto a screen. Using an LCD/CRT's individual RGB subpixels to antialiasing (or some form of screen output enhancement). It seems a lot of the 3D stuff in the GPU is already employing sub-pixel coordinates, so it would be nice if the actual output to the screen would take advantage of that. AFAIK, nobody's hardware does that.When that kind of antialiasing is done for text, I think it's the job of the font rendering code to do so.-Brian Best regards,John KheitE-mail: mailto:[EMAIL PROTECTED]AOL Instant Messenger: John Kheit
Re: driver level sub-pixel rendering?
[EMAIL PROTECTED] wrote: And the high-precision subpixel processing enables videos to be scaled to any size, so that even small videos look like they were recorded in high-resolution. Trilinear texture filtering should do that. It's supported on any graphics card these days. It's more a matter of whether the video player application uses it. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 6242] [agp mach64] Use DMA buffers for mach64_dma_vertex
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=6242 --- Additional Comments From [EMAIL PROTECTED] 2006-04-01 06:39 --- (In reply to comment #6) (In reply to comment #5) Created an attachment (id=5123) -- (https://bugs.freedesktop.org/attachment.cgi?id=5123action=view) [edit] [edit] mach64-drm: DMA buffers for vertices - try 2 enable test of register values in the vertex buffer. It's good to see this driver getting some attention again, I'm sorry I don't have time to help out with the code right now. I wanted to point out that if you go this route (using client DMA buffers for vertices), you'll need to unmap the buffers from userspace before verifying and submitting them to make this secure. If you look at the CVS history, you'll see that we actually used to use DMA buffers, but changed to the current method when beginning the work to make the driver secure. We decided that copying the data from client memory into a pool of unmapped DMA buffers in the kernel would be faster than unmapping and re-mapping the buffers for each submit. Copying the userspace data into DMA buffers allocated from the mapped pool was a stopgap until we had a way to allocate unmapped buffers in the kernel for this purpose. Grrh, I knew I was missing something basic when I tried to touch this stuff ... also a bit stupid of me to lurk and search mesa-dev for mach64 DMA instead of dri-devel. I'll probably do my homework over the weekend. Just a question to make sure I am not completely mixed up: As it stands now, is drm_blit secure ? I mean a malicious client can still change the contents of the DMA buffer after submission to the drm in the case of a blit also, esp. the first MACH64_HOSTDATA_BLIT_OFFSET bytes. It's been a while since I looked at the code in detail, but the problem at the time was a limitation of the DRM buffer management infrastructure. As I recall, there wasn't an easy way to create two sets of DMA buffers, one mapped to userspace, and one which wasn't mapped. You may want to look into the mailing list archives for more discussion on this. I think that this was the last remaining issue in securing the driver. -Leif Thanks for your comments and your work on open source drivers, george. -- 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. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: driver level sub-pixel rendering?
On Fri, Mar 31, 2006 at 01:51:03PM -0500, [EMAIL PROTECTED] wrote:
I think some of the cards use the GPUs for scaling video (and perhaps
other optimizations). Kind of like the nice upscaling done by some DVD
players.? Nvidia calls it PureVideo:
[1]http://www.nvidia.com/page/purevideo.html
And the high-precision subpixel processing enables videos to be scaled to
any size, so that even small videos look like they were recorded in
high-resolution.
I'm sure ATI has something similar? I would guess that this kind of thing
could also be used for other things sent to it?
On Mar 31, 2006, at 11:33 AM, Brian Paul wrote:
John Kheit wrote:
Sorry Brian, I should have been more specific.? I mean more as a final
output onto a screen.? Using an LCD/CRT's individual RGB subpixels to
antialiasing (or some form of screen output enhancement). It seems a
lot of the 3D stuff in the GPU is already employing sub-pixel
coordinates, so it would be nice if the actual output to the screen
would take advantage of that.
AFAIK, nobody's hardware does that.
When that kind of antialiasing is done for text, I think it's the job of
the font rendering code to do so.
Is the original author talking about Cleartype-style antialiasing? (ie
using the RGB subpixels to get more {usually horizontal} resolution in
text rendering).
Sounds like something you could do with a pixel shader perhaps.
Straight alpha-blending with the RENDER extension is already
accelerated on most hardware supported by DRI isn't it?
Phil
--
http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: driver level sub-pixel rendering?
Yes. But not only for text, for video and just about anything blasted onto the screen. I think the Nvidia stuff I put on might do that for everything that hits the LCD. Basically the hardware would give you a resolution boost for anything that can keep partial pixel measurements internally.Do any of the Linux drivers support this type of thing?Thanks.On Mar 31, 2006, at 3:48 PM, Philip Armstrong wrote:Is the original author talking about Cleartype-style antialiasing? (ieusing the RGB subpixels to get more {usually horizontal} resolution intext rendering).Sounds like something you could do with a pixel shader perhaps.Straight alpha-blending with the RENDER extension is alreadyaccelerated on most hardware supported by DRI isn't it?Phil-- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt---This SF.Net email is sponsored by xPML, a groundbreaking scripting languagethat extends applications into web and mobile media. Attend the live webcastand join the prime developer group breaking into this new coding territory!http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642--___Dri-devel mailing listDri-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/dri-devel Best regards,John KheitE-mail: mailto:[EMAIL PROTECTED]AOL Instant Messenger: John Kheit
Re: r300 freezes the X server after resume from suspend2 (suspend to disk)
On Thu, Mar 30, 2006 at 10:47:48 -0500, Alex Deucher wrote: On 3/30/06, Tino Keitel [EMAIL PROTECTED] wrote: On Fri, Mar 24, 2006 at 14:08:35 +1100, Benjamin Herrenschmidt wrote: nvidia-agp is loaded long time before drm.ko and radeon.ko here, so this can not be the reason. Can you try with the driver in ati-1-0-branch from CVS ? You may need a 7.0 server tho .. OK, it looks like you mean xf86-video-ati from the freedesktop.org CVS. What is the purpose of the ati-1-0-branch? Is it newer/older/different from the driver in XOrg 6.9? The ati-1.0-branch is the stable bug fix branch for radeon. It's newer than 6.9. Thanks, but how can I check it out? $ cvs -d :pserver:[EMAIL PROTECTED]:/cvs/xorg co -r ati-1.0-branch driver/xf86-video-ati cvs checkout: warning: cannot open /cvs/xorg/CVSROOT/val-tags read/write: Permission denied cvs [checkout aborted]: no such tag ati-1.0-branch Regards, Tino --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 freezes the X server after resume from suspend2 (suspend to disk)
On Sat, Apr 01, 2006 at 01:10:46AM +0200, Tino Keitel wrote: Thanks, but how can I check it out? $ cvs -d :pserver:[EMAIL PROTECTED]:/cvs/xorg co -r ati-1.0-branch driver/xf86-video-ati cvs checkout: warning: cannot open /cvs/xorg/CVSROOT/val-tags read/write: Permission denied cvs [checkout aborted]: no such tag ati-1.0-branch Unfortunately the error message is really stupid, but what CVS is really trying to tell you is that you should be using ati-1-0-branch, not ati-1.0-branch. Also, anoncvs.freedesktop.org is the canonical CVS server, rather than cvs.freedesktop.org. Cheers, Daniel signature.asc Description: Digital signature
Re: r300 freezes the X server after resume from suspend2 (suspend to disk)
On Sat, Apr 01, 2006 at 01:34:45 +0300, Daniel Stone wrote: On Sat, Apr 01, 2006 at 01:10:46AM +0200, Tino Keitel wrote: Thanks, but how can I check it out? $ cvs -d :pserver:[EMAIL PROTECTED]:/cvs/xorg co -r ati-1.0-branch driver/xf86-video-ati cvs checkout: warning: cannot open /cvs/xorg/CVSROOT/val-tags read/write: Permission denied cvs [checkout aborted]: no such tag ati-1.0-branch Unfortunately the error message is really stupid, but what CVS is really trying to tell you is that you should be using ati-1-0-branch, not ati-1.0-branch. Also, anoncvs.freedesktop.org is the canonical CVS server, rather than cvs.freedesktop.org. Thanks. Is this branch supposed to build fine? I got several errors here. 1. In autogen.sh: Makefile.am:24: BUILD_LINUXDOC does not appear in AM_CONDITIONAL 2. While running configure: checking dependency style of gcc... (cached) gcc3 ./configure: line 19359: syntax error near unexpected token `RANDR,' ./configure: line 19359: `XORG_DRIVER_CHECK_EXT(RANDR, randrproto)' Regards, Tino --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 freezes the X server after resume from suspend2 (suspend to disk)
On 3/31/06, Tino Keitel [EMAIL PROTECTED] wrote: On Sat, Apr 01, 2006 at 01:34:45 +0300, Daniel Stone wrote: On Sat, Apr 01, 2006 at 01:10:46AM +0200, Tino Keitel wrote: Thanks, but how can I check it out? $ cvs -d :pserver:[EMAIL PROTECTED]:/cvs/xorg co -r ati-1.0-branch driver/xf86-video-ati cvs checkout: warning: cannot open /cvs/xorg/CVSROOT/val-tags read/write: Permission denied cvs [checkout aborted]: no such tag ati-1.0-branch Unfortunately the error message is really stupid, but what CVS is really trying to tell you is that you should be using ati-1-0-branch, not ati-1.0-branch. Also, anoncvs.freedesktop.org is the canonical CVS server, rather than cvs.freedesktop.org. Thanks. Is this branch supposed to build fine? I got several errors here. 1. In autogen.sh: Makefile.am:24: BUILD_LINUXDOC does not appear in AM_CONDITIONAL 2. While running configure: checking dependency style of gcc... (cached) gcc3 ./configure: line 19359: syntax error near unexpected token `RANDR,' ./configure: line 19359: `XORG_DRIVER_CHECK_EXT(RANDR, randrproto)' you need the xserver macros. depending on your distro they are in the xorg-xserver-dev packages. Alex Regards, Tino --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
