On Sun, 2006-01-29 at 10:06 +1030, Kevin Shanahan wrote:
Testing with Linux 2.6.15, Debian xorg 6.9 with your new patch applied
(just edited the paths in the diff) and dri cvs with your patch. This
is an x86 (Transmeta) laptop, with a Radeon Mobility M6 LY (PCI).
Thanks !
.../...
Okay;
There should be no need to check for info-cursor_offset == 0 in the
cursor functions. Longer term, I think we should just reserve a static
FB region for the cursor upfront instead of going through all these
hoops with EXA.
I had some dodgy stuff happening at things like
Xorg driver patch:
http://gate.crashing.org/~benh/radeon-memmap-7.0-2.diff
DRM patch:
http://gate.crashing.org/~benh/radeon-memmap-drm-1.diff
Ok, DRM patch is busted, it breaks an assumption done by the DRM that
AGP is always appended to the framebuffer in card space which is no
longer the
On Thu, 2006-01-26 at 10:43 +1100, Benjamin Herrenschmidt wrote:
Xorg driver patch:
http://gate.crashing.org/~benh/radeon-memmap-7.0-2.diff
DRM patch:
http://gate.crashing.org/~benh/radeon-memmap-drm-1.diff
The DRM patch had issues. Here's a new version that fixes them though
it would
Ok, so finally here is a new version of the patch. This time, it's
against modular and it comes with a DRM patch. The X driver and the DRM
patch should both work with the unpatched counterpart though you'll only
get the full benefit of the fixes with both patches applied.
As I had to shuffle a
On Thu, 2006-01-26 at 01:42 +0100, Roland Scheidegger wrote:
Not tested yet, but I see you now no longer set the HDP_APER_CNTL which
didn't work for me at all. However, does that mean some cards which map
their memory as for instance 2x64MB have to live with 64MB because of
that? Do you
On Thu, 2006-01-26 at 10:43 +1100, Benjamin Herrenschmidt wrote:
Ok, so finally here is a new version of the patch. This time, it's
against modular and it comes with a DRM patch. The X driver and the DRM
patch should both work with the unpatched counterpart though you'll only
get the full
There must be some way to deal with all this sanely on PPC. Apple has a
number of OpenGL extensions for making user memory directly accessable
to the graphics engine. Perhaps their specs can provide some clues as
to how they do it?
On Sun, 2006-01-08 at 18:17 +, Keith Whitwell wrote:
In the past there has been talk about mapping user memory into the GTT
aperture as a mechanism to avoid copy-based uploading. What I'm
proposing is that this type of mapping becomes the only or at least
primary way of getting data and
On Sun, 2006-01-08 at 22:55 +, Keith Whitwell wrote:
Yes, this I think is addressed by the Map/Unmap semantics from ARB_vbo and
the
additional constraints I included in the design, ie that the only time the
buffer contents are meant to be available as user memory is when they are
Is it safe to say that this is only a problem for cards with 256 bit
memory interfaces? From http://en.wikipedia.org/wiki/Radeon_9700_core:
Radeon 9700 275 256-bit
Radeon 9800 325 256-bit
Radeon 9700 Pro 325 256-bit
Radeon 9800 Pro 380 256-bit
Radeon
More people testing benh patch on radeon 9800 (or any other
radeon that used to lockup) are welcome:
http://lists.freedesktop.org/archives/xorg/2005-December/011679.html
http://lists.freedesktop.org/archives/xorg/2005-December/011717.html
It really seems to fix it. I have been on ut2004
On Thu, 2006-01-05 at 11:05 +0100, Jerome Glisse wrote:
On 1/5/06, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
On Thu, 2006-01-05 at 02:30 +0100, Jerome Glisse wrote:
On 1/5/06, Jon [EMAIL PROTECTED] wrote:
I have a ATI AIW Radeon 9800 Pro (r350), I'm getting plenty of freezing
On Thu, 2006-01-05 at 02:30 +0100, Jerome Glisse wrote:
On 1/5/06, Jon [EMAIL PROTECTED] wrote:
I have a ATI AIW Radeon 9800 Pro (r350), I'm getting plenty of freezing
with r300 DRI module. I tried Quake3 (wont get past beginning of opening
game video, locks computer solid) and Xmoto (lasts
On Fri, 2005-12-30 at 13:27 -0500, Ben Gamari wrote:
Howdy all! What is the present status of S3 suspend support in the DRI?
I ask because my laptop locks up with a scrambled screen on resume from
S3 standby when using the radeon driver with DRI enabled. This is a
known problem with the DRI
On Mon, 2005-11-28 at 02:18 -0800, vehemens wrote:
I've been looking at my remaining lockups, and find that I keep coming back
to
the use of scratch registers in the driver for one of them.
If I'm reading the code correctly, the scratch registers are per device, not
per client. This
Is it a hardware bug or lack of docs on how it's implemented?
One could argue that AGP itself is a HW bug in the firstplace and works
due to mere luck. Enabling fast write is pushing that luck too far.
Ben.
---
SF.Net email is sponsored
Aapo you commit anything about the endian swapping for fixing
what Mattias was experiencing in his last report ?
No. Sounds like 32-bit elts work for ppc.
16-bit elts are used in vtxfmt_a path so thats still broken.
They probably need HDW swapping... AFAIK, the CCE is doing 32 bits
On Thu, 2005-10-27 at 14:00 +0200, Mattias Nissler wrote:
Any ideas what could be causing those problems? Is quake3 rendering
correctly on x86 at the moment? I am willing to look into the source
if someone could give me a few hints what to look for. I can also do
some further testing if
On Fri, 2005-10-28 at 14:13 +1000, Benjamin Herrenschmidt wrote:
This is exactly the kind of crap I see here too on the G5, so that irons
out a 32 vs 64 bits issue.
The strangest thing is that paulus is currently running a version of the
driver on his G5 that does not have this issue. It's
On Sun, 2005-10-23 at 11:03 +0100, Dave Airlie wrote:
So, something like Get/Set/UnsetAttribute() perhaps.
But also, thinking about the use of these regions for DMA, synchronization
is
important. I saw the SetFence() entrypoint, there's no way to retire these
fences, eg a
Hi !
Did anybody try it on ppc lately ? I've tried to build all sort of CVS
version (from last July to today), running with X.org CVS from last
week, and -git kernel from today with fairly bad results so far. The
machine is a G5 with 32 bits userland (32 bits xorg dri, 32 bits apps,
64 bits
On Tue, 2005-10-04 at 09:44 +0200, Dario Laera wrote:
Benjamin Herrenschmidt wrote:
- ppracer: This one displays the first screen fine, but when you click,
the application is locked schewing CPU for about 1 minute... it then
unlocks and you go the menu. Same happens each time you click
Hi !
The code that swaps ycbcr textures had a bug that would cause it to
corrupt memory by applying an incorrect stride (applying a byte offset
to a GLushort pointer). This crashes applications trying to use those
textures with DRI on ppc at least, and crashes the server when using
indirect
On Wed, 2005-10-05 at 15:42 +1000, Benjamin Herrenschmidt wrote:
diff -urN Mesa.orig/src/mesa/main/texstore.c Mesa/src/mesa/main/texstore.c
--- Mesa.orig/src/mesa/main/texstore.c2005-10-04 13:07:14.0
+1000
+++ Mesa/src/mesa/main/texstore.c 2005-10-05 15:33:33.0
On Thu, 2005-09-29 at 13:56 +0200, Dario Laera wrote:
Hi all,
since some week I'm no more able to load DRI, this is the error:
(II) RADEON(0): [agp] 8192 kB allocated with handle 0x0001
(EE) RADEON(0): [agp] Could not add ring mapping
(EE) RADEON(0): [agp] AGP failed to initialize.
On Sun, 2005-09-11 at 23:25 -0400, Alex Deucher wrote:
Dave I tested on my r430 pcie (0x554f) and it hangs just like your
original patch. Any ideas? perhaps it doesn't like the current r300
microcode? What the best way to extract the correct microcode from
the windows driver or fglrx?
On Wed, 2005-09-07 at 18:12 +0200, Daniel Estévez wrote:
I have a new ibook with an ATI Mobility Radeon 9550 card and
want to help the r300 project testing the driver. I have compiled
the patched x server and the mesa drivers from cvs. I also have
compiled radeon.ko from the drm cvs of
On Thu, 2005-08-25 at 23:26 +0200, Johannes Berg wrote:
On Wed, 2005-06-22 at 18:36 +1000, Benjamin Herrenschmidt wrote:
The problem is simple: when setting up the AGP aperture, it's putting it
after the framebuffer + CONFIG_APER_SIZE, which is wrong. On that guy,
CONFIG_APER_SIZE might
The callgate for getting to mode setting has to be in the kernel. That
provides a standard API and a secure user-root transition. After the
call is in the kernel each driver can choose to satisfy the call
in-kernel or use something like call_userhelper() to do the work in
user space.
As I
On Tue, 2005-06-28 at 20:13 -0400, Jon Smirl wrote:
On 6/28/05, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
The callgate for getting to mode setting has to be in the kernel. That
provides a standard API and a secure user-root transition. After the
call is in the kernel each driver
The intelfb driver doesn't support the i9XX series of Intel chips, and
also may not actually be loaded in two cases. One is if the user is
already using vesafb, and second when the user isn't using fbdev at all.
The case for coming up with a low level stub driver, seems to be a little
I am almost certain that code for adding suspend/resume support to DRM
is going to get rejected when it is submitted to the Linux kernel on
grounds that it is duplicating existing code. The code in DRM CVS for
detecting fbdev and attaching to the PCI ID if it is not there has
already been
On Mon, 2005-06-27 at 20:38 -0400, Jon Smirl wrote:
I split it into initmap/addmap to allow reset to work. You can't bring
the radeon up until it is reset, the driver will error out. This
allowed a DRM based reset app to map the registers and run the reset
program without bringing up the full
On Fri, 2005-06-24 at 09:58 -0400, Jon Smirl wrote:
On 6/24/05, Jon Smirl [EMAIL PROTECTED] wrote:
I'm update with your changes this morning. I'm still seeing this at
system shutdown. I modprobe drm,radeon and then unloaded them (no
errors) then shut the system down.
With some more
On Tue, 2005-06-21 at 16:44 +0200, Johannes Berg wrote:
Jerome Glisse wrote:
I can remember from the top of my head but there is maybe some patch
that could be revealent for ppc not included in this snapshot. Thus i think
you should consider trying building xorg from cvs. Anyway with a g4 it
Can you provide more detail here ?
The current situation is that when fbdev is loaded the DRM falls back
to using the sysdev approach. If fbdev isn't loaded it takes direct
control as the DRM becomes a real PCI driver and accesses the PCI functions
for suspend/resume directly.
What's
On Fri, 2005-06-17 at 22:38 +0100, Dave Airlie wrote:
I was going to delete the code that looks for fbdev and conditionally
takes control since it had been rejected. Should I leave it in?
I'd leave it in, no-one says DRM CVS has to be exactly what is in the
kernel, it is nice to know
On Thu, 2005-06-16 at 21:29 +0100, Dave Airlie wrote:
The DRM drivers know what is important but they don't know when
suspend/VT swap is happening because there is only one set of kernel
hooks and the fbdev driver is attached to them. The scheme where a
texture copy is kept in system RAM
On Thu, 2005-06-16 at 22:28 +0100, Dave Airlie wrote:
Out of curiosity - who are the people that *need* intelfb ? (as opposed to
*want*).
Xegl people will need a kernel framebuffer driver (not necessarily running
the console) but something loaded to take care of X when it starts ...
On Thu, 2005-06-16 at 17:30 -0400, Jon Smirl wrote:
On 6/16/05, Vladimir Dergachev [EMAIL PROTECTED] wrote:
Out of curiosity - who are the people that *need* intelfb ? (as opposed to
*want*).
To use Xegl it will require you to load both fbdev and DRM drivers for
your hardware. Xegl uses
Xegl uses OpenGL/EGL, it's not defined to use anything else. It is the
mesa implementation of OpenGL/EGL that uses fbdev. Nvidia/ATI will
likely provide OpenGL/EGL's that don't use fbdev.
One thing that bothers me about this whole discussion is the mounting
level of interface
This seems like an odd solution. Why wouldn't you just enable
multiple drivers to attach to the device?
Nah, that would cause endless issues. Especially since we actually want
some synchronisation/locking between the two, at least ultimately.
Can everyone please try this patch out and see
On Fri, 2005-06-10 at 20:03 -0400, Adam Jackson wrote:
On Friday 10 June 2005 19:38, Benjamin Herrenschmidt wrote:
Anyway, I really want a slightly different approach than what Jon is
doing, that is a 3 modules scenario:
- A basic stub module that attaches to the PCI card. It doesn't
On Tue, 2005-06-07 at 15:48 -0400, Jon Smirl wrote:
Am I right in this interpretation? First I need to get the
bus/device/func of the card, then I need to tell this to the driver
(which must already know this info). I then get back the IRQ number,
which I then pass back to the driver (which
On Sun, 2005-06-05 at 09:58 -0400, Vladimir Dergachev wrote:
Which way can memory controller be misprogrammed ? The part that concerns
us are positions of Video RAM, AGP and System Ram in Radeon address space.
(these are specified by RADEON_MC_AGP_LOCATION, RADEON_MC_FB_LOCATION).
My understanding is that AGP only does transfers system RAM - video RAM
and all transfers in the opposite direction have to use plain PCI
transfers at least as far as the bus is concerned.
You mean system RAM - graphics card, right? Does this mean that the
graphics card cannot always
Yes, however it is convenient to do so.
The point is that AGP base address will not normally overlap the location
of system RAM. This is, of course, only reasonable for 32 bit systems..
It will overlap it on all PowerMac's (where it will be 0)
Ben.
On Sun, 2005-06-05 at 14:45 -0400, Vladimir Dergachev wrote:
Yes, however it is convenient to do so.
The point is that AGP base address will not normally overlap the location
of system RAM. This is, of course, only reasonable for 32 bit systems..
I understand that part, but it's not
Are you sure it uses PCI? I'm assuming that the destination address for
scratch writeback is controlled by the RADEON_SCRATCH_ADDR register. This
register is programmed to a value that falls within the AGP area (as
defined by RADEON_MC_AGP_LOCATION) if I understand the code correctly.
Ok,
This, of course, would not work if the memory controller is misprogrammed
- which was the cause of failures.
Goood old discussion :)
Which way can memory controller be misprogrammed ? The part that concerns
us are positions of Video RAM, AGP and System Ram in Radeon address space.
You guys seem to be getting closer...
When I had X + xfce4 + quake3 running (with this patch +
patch.drm-cmdbuf-more-pacifiers + patch.remove-userspace-pacifiers) X
locked up within 2 minutes.
However, X + quake3 (no window manager), I went thirty minutes before
my first problem.
On Wed, 2005-06-01 at 01:32 +0100, Dave Airlie wrote:
In radeon_irq.c:radeon_wait_irq
There is a comment
/* This is a hack to work around mysterious freezes on certain
* systems:
*/
radeon_acknowledge_irqs(dev_priv);
On my 7500 system I've been seeing mysterious hangs after
On Tue, 2005-05-31 at 21:52 +0200, Nicolai Haehnle wrote:
Hello everybody,
today's lockup-chasing wrapup follows :)
BTW. Look at the removing radeon_acknowledge_irqs hack.. thread and my
reply to David more specifically. I think we may be losing interrupts. I
don't know if that can explain
Here's a version that compiles (and seems to work on my rv280, though I
don't notice any difference, things still work, though apps tend to
occasionally have hickups as usual, like pinball is very choppy, I
blame poorly written apps though as quake2 looks ok).
Index:
On Wed, 2005-06-01 at 16:39 +0200, Nicolai Haehnle wrote:
On Wednesday 01 June 2005 09:22, Benjamin Herrenschmidt wrote:
On Tue, 2005-05-31 at 21:52 +0200, Nicolai Haehnle wrote:
Hello everybody,
today's lockup-chasing wrapup follows :)
BTW. Look at the removing
*/
- stat = RADEON_READ(RADEON_GEN_INT_STATUS)
- (RADEON_SW_INT_TEST | RADEON_CRTC_VBLANK_STAT);
+ stat = radeon_acknowledge_irqs(dev_priv, (RADEON_SW_INT_TEST_ACK |
RADEON_CRTC_VBLANK_STAT));
if (!stat)
return IRQ_NONE;
Looks ok except I don't
Ok, here's a version wrapping at 80 cols and that applies again Linus
current git. Feel free to forward...
Index: linux-work/drivers/char/drm/radeon_irq.c
===
--- linux-work.orig/drivers/char/drm/radeon_irq.c 2005-06-02
Hi David!
Here's my latest version of the patch for radeon_cp that fixes the
possible overlap mapping we talked about. I went the paranoid way this
time, by checking both CONFIG_MEMSIZE and MC_FB_LOCATION top, in order
to put the AGP aperture always above any of those. This should avoid bad
On Tue, 2005-05-10 at 14:59 -0700, Ian Romanick wrote:
I've started working to get PCI MGA cards, the PCI G450 specifically,
working with DRI. My initial goal is to just get it working with crummy
performance, then improve it by adding support for IOMMUs (to simulate
AGP texturing) on
On Sun, 2005-05-08 at 18:23 +0100, Dave Airlie wrote:
Ok, here's the candidate for submission to Linus if no other comment by
tomorrow. David, will you take care of adapting it to DRI CVS ?
Will do.. it'll be a few days.. still on the road..
Ok, I want to double check something first
On Thu, 2005-05-05 at 09:48 +1000, Benjamin Herrenschmidt wrote:
On Wed, 2005-05-04 at 09:35 -0400, Hui Yu wrote:
I don't know an exception for it being a non-power of 2, but it can be
zero on some M6 chips. In these cases, set it to 8M.
Yup, I know about that case, I'll send a fixed
drm_radeon_private_t *dev_priv = dev-dev_private;;
DRM_DEBUG( \n );
+ u32 gart_loc;
move the local variable above the DRM_DEBUG line... is u32 enough?
(I've no idea myself ...)
Yah, I need to move it. u32 is on purpose as dev_priv-fb_location is
u32. This is not
On Wed, 2005-05-04 at 09:35 -0400, Hui Yu wrote:
I don't know an exception for it being a non-power of 2, but it can be
zero on some M6 chips. In these cases, set it to 8M.
Yup, I know about that case, I'll send a fixed patch later today,
thanks !
Ben.
On Tue, 2005-05-03 at 15:24 +1000, Benjamin Herrenschmidt wrote:
Hi !
The radeon DRM has some interesting bug that paul and I discovered to
cause all sort of problems like crashing the machine on suspend/resume
(go figure ...) etc...
dev_priv-gart_vm_start = dev_priv-fb_location
On Tue, 2005-05-03 at 10:09 +0200, Jerome Glisse wrote:
Has i still doesn't understand the big pictures of video drivers, i
was wondering
if this could have an impact on bytes swapping on r300. Thus the problem
of bit blit we have on r300 X driver. I don't think so but as i don't well
On Tue, 2005-05-03 at 10:41 +0200, Jerome Glisse wrote:
Now, the setting above has to be done the most intelligently you can
based on 1) do you need 2 apertures with different swapper settings
(typical of BE machines) or not, 2) what is your CONFIG_APER_SIZE
strapping vs. how much VRAM you
Note that with huge VRAM sizes appearing, we also want to make sure that
wheverver we put it won't overlap the 32 bits space since CONFIG_MEM_SIZE
can be huge nowadays... and if it does, put the GART just _before_ the
framebuffer instead. Again, this is all cards space, not bus view, so
If a conflict can't be avoided, we could fail gracefully upfront
(suggesting to make the GART aperture smaller, ...) instead of risking
subtle breakage?
Well, I don't know of any clean platform independant way to know if
there is a conflict or not, that is to know where RAM is in bus space.
On Wed, 2005-05-04 at 09:48 +1000, Benjamin Herrenschmidt wrote:
If a conflict can't be avoided, we could fail gracefully upfront
(suggesting to make the GART aperture smaller, ...) instead of risking
subtle breakage?
Well, I don't know of any clean platform independant way to know
Hi !
The radeon DRM has some interesting bug that paul and I discovered to
cause all sort of problems like crashing the machine on suspend/resume
(go figure ...) etc...
dev_priv-gart_vm_start = dev_priv-fb_location
+ RADEON_READ( RADEON_CONFIG_APER_SIZE );
On Wed, 2005-03-16 at 11:48 -0500, Adam Jackson wrote:
On Wednesday 16 March 2005 09:09, Ville Syrjälä wrote:
On Wed, Mar 16, 2005 at 05:31:16PM +1100, Benjamin Herrenschmidt wrote:
Well, do they revert it after atyfb/aty128fb/radeonfb set it then ?
it's definitely set on mode switch
On Wed, 2005-03-16 at 21:51 +0200, Ville Syrjälä wrote:
This was about the DirectFB drivers.
One thing just popped to my head though. If in the future we are going to
allow graphics cards to render to system memory, using the swapper will no
longer work. I don't see any other solution
On Wed, 2005-03-16 at 15:42 -0500, Michel Dänzer wrote:
On Wed, 2005-03-16 at 22:08 +0200, Ville Syrjälä wrote:
I don't see the current system slowly evolving into some superb future
system with an in kernel memory manager. The current APIs just have too
many limitations. I think the
On Wed, 2005-03-16 at 22:55 +0200, Ville Syrjälä wrote:
On Wed, Mar 16, 2005 at 10:49:11AM +1100, Benjamin Herrenschmidt wrote:
In the meantime, can you tell me more about your arbitration scheme ?
There is a lock associated with the graphics card. The lock is always
taken before
On Wed, 2005-03-16 at 16:00 -0500, Michel Dänzer wrote:
On Wed, 2005-03-16 at 21:51 +0200, Ville Syrjälä wrote:
One thing just popped to my head though. If in the future we are going to
allow graphics cards to render to system memory, using the swapper will no
longer work. I don't see
On Wed, 2005-03-16 at 23:08 +0200, Ville Syrjälä wrote:
On Wed, Mar 16, 2005 at 03:58:07PM -0500, Alex Deucher wrote:
I haven't seen anyone coming forward with a design/code for the memory
manager.
In the meantime I'm assuming that people might want to make some use of
their dualhead
Why don't we modify the new radoenfb driver to have a real
arbitration/management layer. Directfb can continue to use the old
driver. The rule is that you can't mix old and new style fbdev drivers
in a system. Over time DirectFb and X can be fixed to use the new
model.
There is going to
On Thu, 2005-03-17 at 02:14 +0200, Ville Syrjälä wrote:
On Thu, Mar 17, 2005 at 10:27:56AM +1100, Benjamin Herrenschmidt wrote:
On Wed, 2005-03-16 at 22:55 +0200, Ville Syrjälä wrote:
On Wed, Mar 16, 2005 at 10:49:11AM +1100, Benjamin Herrenschmidt wrote:
In the meantime, can you tell me
I understand you can't have userspace program the accelerator while
someone else is doing the same thing. Oh and I now understand that the
same really applies to direct framebuffer access due to the swapper.
And you can't have someone program the accelerator while somebody does
direct
On Thu, 2005-03-17 at 03:25 +0200, Ville Syrjälä wrote:
On Thu, Mar 17, 2005 at 12:12:58PM +1100, Benjamin Herrenschmidt wrote:
I understand you can't have userspace program the accelerator while
someone else is doing the same thing. Oh and I now understand that the
same really
DirectFB assumes all memory outside var.yres_virtual * fix.line_length is
preserved. A totally valid assumption in my opinion.
Except that you can't know in advance how much fix.line_length will be.
The fix isn't really fixed. Different cards will have different
requirements depending on the
I once did a similar thing for an embedded prototype: take a fixed amount of
memory for both frame buffers (this was a UMA system), fb0 starts from the
top,
fb1 starts from the bottom. You can enlarge each frame buffer, until you
read
the memory of the other. Each
On Tue, 2005-03-15 at 16:00 +0200, Ville Syrjälä wrote:
DirectFB has it's own asbitration mechanism. It doesn't support using
multiple framebuffer devices at the same time. For that to work DirectFB
would just have to know if some of the framebuffer devices are actually
different outputs
On Wed, 2005-03-16 at 01:05 +0200, Ville Syrjälä wrote:
True. Currently DirectFB doesn't handle this correctly. But that could be
easily fixed if only line_length wasn't totally misplaced. It really
belongs to fb_var_screeninfo. We could first test the mode with
FB_ACTIVATE_TEST and
On Wed, 2005-03-16 at 07:37 +0800, Antonino A. Daplas wrote:
On Tuesday 15 March 2005 21:36, Ville Syrjälä wrote:
On Tue, Mar 15, 2005 at 09:51:40AM +0100, Geert Uytterhoeven wrote:
On Tue, 15 Mar 2005, Ville [iso-8859-1] Syrj??wrote:
If radeonfb will allocate the buffer for the second
On Wed, 2005-03-16 at 03:47 +0200, Ville Syrjälä wrote:
There's also the case with Matrox Millennium I/II cards. They must place
the visible frame buffer so that no line crosses the boundary of memory
banks. matroxfb deals with that by moving the buffer and changing
smem_start and smem_len
It's ugly, but that's not the point. The point is that all deployed
versions of X (and even current X.org CVS head still, in fact) make this
assumption.
Oh, that's fine and that's not a problem. I will only repaint the
framebuffer on bit depth or line lenght changes. I'm trying to talk
about
On Wed, 2005-03-16 at 00:21 -0500, Michel Dänzer wrote:
Actually people do use it on big-endian systems but since neither the
mach64, ati128 or radeon drivers play with the swapper settings I can
only
assume that they haven't been tested very extensively.
You are wrong
Ok so the problem is byte swapping. Looking at atyfb for example it uses
the big-endian aperture on big-endian systems and selects the byte
swapping method according to the bit depth. If that really means that all
host access to the aperture gets byte swapped then I don't see how the
On Mon, 2005-03-14 at 11:20 -0500, Michel Dänzer wrote:
On Mon, 2005-03-14 at 18:12 +1100, Benjamin Herrenschmidt wrote:
On Sun, 2005-03-13 at 23:28 -0500, Michel Dänzer wrote:
On Sun, 2005-03-13 at 17:43 +1100, Benjamin Herrenschmidt wrote:
And finally, I want to blank the screen
On Mon, 2005-03-14 at 17:30 +0100, Soeren Sandmann wrote:
Benjamin Herrenschmidt [EMAIL PROTECTED] writes:
In an ideal world ... However, since we are planning to move the memory
manager to the kernel, that would mean a kernel access (syscall, ioctl,
whatever...) twice per access to AGP
Be that as it may, it remains a fact that such a change would break
existing installations...
I think that mode setting and memory allocation should be separated. X
will always reserve enough video RAM for the largest resolution it uses
for the screen contents.
But X has no control on
On Mon, 2005-03-14 at 20:49 +, Andrew Clayton wrote:
On Mon, 2005-03-14 at 15:32 +1100, Paul Mackerras wrote:
Have you tried the most recent kernel? There were some changes to the
AGP code that caused it to oops for me. Linus took my patch to fix
that this last weekend.
On Mon, 2005-03-14 at 23:59 -0500, Michel Dänzer wrote:
On Tue, 2005-03-15 at 09:37 +1100, Benjamin Herrenschmidt wrote:
Be that as it may, it remains a fact that such a change would break
existing installations...
I think that mode setting and memory allocation should be separated
On Tue, 2005-03-15 at 00:30 -0500, Jon Smirl wrote:
I agree that X has to be fixed to work cooperatively in this environment.
The alternative is to just leave X alone and make all of this work for XGL.
The user would then choose which environment they want to run.
I'm leaning toward just
On Tue, 2005-03-15 at 08:01 +0200, Ville Syrjälä wrote:
If radeonfb will allocate the buffer for the second head from the top of
the memory users would basically have to guess it's location. matroxfb
simply cuts the memory in two pieces and allocates the buffers from the
start of each
On Sun, 2005-03-13 at 10:22 +0200, Ville Syrjälä wrote:
- We only really need to bother about CPU access for the framebuffer
itself (and possibly the cursor). That is normal non-accelerated fbdev
operations an mmap'ing of the framebuffer in user space. This is not
really a problem if
AGP as it's currently used is pretty much pointless for software fallbacks
since reading from AGP memory is nearly as slow as reading from video
memory.
Hrm.. I wouldn't expect _that_ slow. It's uncacheable, right, but still
on a faster bus. Especially if we use it the way we do on ppc
On Sun, 2005-03-13 at 11:19 -0500, Jon Smirl wrote:
On Sun, 13 Mar 2005 23:04:59 +1100, Benjamin Herrenschmidt
[EMAIL PROTECTED] wrote:
AGP as it's currently used is pretty much pointless for software fallbacks
since reading from AGP memory is nearly as slow as reading from video
101 - 200 of 295 matches
Mail list logo
