Re: [PATCH] Add support for RENDER BGRA formats.
From: Adam Jackson a...@nwnk.net Date: Thu, 29 Oct 2009 18:33:20 -0400 To make the card work properly I still have to solve two issues: =20 1. It seems the ACNTRL register doesn't exist on the i128v2 chip. Writes to this register result in a PCI bus error. This was probably never noticed, since on standard PC hardware writes to non-existent registers silently fail. Do the docs contain some hints suggesting this is indeed the case? Kind of? It's the alpha blender setup register, and described as the Imagine 3 blending unit, which sort of implies it didn't exist on Imagine 2. I'm pretty sure Imagine 1 and 2 didn't even have a triangle unit, let alone an alpha blender. Enough evidence for me to assume that register should not be written to on the i128 and i128v2. I'll generate a diff to implement this. 2. Does the hardware by any chance map the VGA legacy I/O ports within one of its BARs? It might. BAR 5 is the I/O map, and it's 256 bytes. They're all defined right up to 0xBC, which smells a little suspicious since the VGA ports it claims to decode are 3C[0-5ACEF] and 3[BD][45A]. So while it doesn't _say_ the VGA ports are aliased there starting at 0xC0, I'd be utterly unsurprised. I guess I don't see how it matters though, you can already get to the colormap and mode, and you won't be using VGA fonts. (Unless you do VGA console even on non-x86 machines? That would be vile.) You're right of course. I already disabled the VGA font save/restore because that required mapping the legacy VGA memory area and on the Sun Blade 1000 that I stuck this card in, that area is in use by other devices. Still struggling a bit with how to map BAR 5 though. I have a hack to make things work, but I'll need to discuss the implications for the OpenBSD kernel and libpciaccess. Thanks, Mark ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC] DRI2 synchronization and swap bits
On Fri, 30 Oct 2009 19:15:17 -0700 Keith Packard kei...@keithp.com wrote: Excerpts from Jesse Barnes's message of Fri Oct 30 10:59:08 -0700 2009: These allow us to support GLX extensions like SGI_video_sync, OML_swap_control and SGI_swap_interval. Let's get the protocol nailed down before we go into detailed code review. Besides, you need to rebase -i to get rid of the broken versions. Yeah, some merging/splitting of the commits is in order before merging it upstream. There have been a few comments about the protocol so far: 1) DRI2SwapBuffers a) Concern about doing another round trip to fetch new buffers following the swap. Do we want to deal with stereo here? I think the protocol is sufficient for that; it just requests the swap, so for stereo buffers both would be swapped. I think this is a valid concern, we could potentially respond from the swap with the new buffers, but this would make some memory saving optimizations more difficult (e.g. freeing buffers if no drawing comes in for a short time after the swap). Hrm. Ideally, we'd send back new buffer IDs but delay creation until someone accessed them. That would require kernel magic to create an un-realized buffer, but perhaps avoiding an explicit round trip per swap would be worth it? I don't see how we can avoid the round trip entirely, without sharing some state between the server and client (i.e. re-introducing the SAREA). I'll do some benchmarking of the proposed buffer freeing and see how bad it is. 2) DRI2WaitMSC/SBC a) Concern about blocking the client on the server side as opposed to a client side wait. So, some kind of cookie that you'd pass to the kernel for the wait instead of just blocking in the server? I can see a lot of uses for this kind of mechanism beyond X, which makes it somewhat more interesting to contemplate in this case. Oh we never block the server. The protocol here just tells the server when the client should be awakened again by passing a cookie. The open question is whether the server should be putting the client to sleep and waking it back up, or whether in the direct rendered case the client gets a cookie from the server and sleeps itself (in the aiglx case the server has to handle things regardless). The implementation tries to avoid blocking the clients at all for swap requests, only blocking them on wait requests that are specified to cause blocking. This should allay the concerns raised in the page flipping thread about unnecessary blocking of clients (that's left as an implementation detail for the drivers supporting these new functions). Do we have a driver which does this the 'right' way yet? The i915 page flipping code does this correctly, by marking the buffers in question busy and blocking the client in the kernel if it tries to access a busy buffer. For the windowed swap case we may have to block the client less nicely if we end up blitting between back front. (GL fences could make this better.) Jesse ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Add support for RENDER BGRA formats.
Hello,
On Oct 31, 2009, at 11:17 AM, Mark Kettenis wrote:
Still struggling a bit with how to map BAR 5 though. I have a hack to
make things work, but I'll need to discuss the implications for the
OpenBSD kernel and libpciaccess.
Assuming that OpenBSD is still more or less NetBSD-ish here :
in whateverfb_mmap():
#ifdef PCI_MAGIC_IO_RANGE
/* allow mapping of IO space */
if ((offset = PCI_MAGIC_IO_RANGE)
(offset PCI_MAGIC_IO_RANGE + 0x1)) {
pa = bus_space_mmap(sc-sc_iot, offset - PCI_MAGIC_IO_RANGE,
0, prot, BUS_SPACE_MAP_LINEAR);
return pa;
}
#endif
IO space on sparc64 is memory mapped, you can just hand the IO tag
from pci_attach_args to bus_space_mmap(), pick a region that's safe
for your architecture and map it at that offset through the wsdisplay
file handle ( on sparc64 you'll probably want to pick something above
4GB. On macppc for example we use 0xf200 because that's
traditionally where the first PCI bridge puts its IO space. ). That
way you also automatically get the right IO space if you have more
than one. Yes, most PCI Suns implement considerably more than 64kB IO
space but the firmware tries to cram everything into the lower 64KB
anyway and you won't have many PCI devices with IO enabled either.
Or, to be more in line with libpciaccess, you can do that in
pci_mmap() so each /dev/pci* entry would return the right IO space.
have fun
Michael
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
