Re: DRM and latency..
Dave Airlie wrote: It has been pointed out to me by Andrew and Fernando Pablo Lopez-Lezcano that we do a lot of sleeping in code that probably should reschedule rather than sleep,radeon_do_wait_for_idle being a prime example, this has a DRM_UDELAY(1), this messes up audio latencys, Now I'm not sure that wholesale replacing these with a conditional schedule is correct, but in most cases it looks like there should be no issues doing this, theses functions are all usually called from a process context, My main worry is what to do on BSD about this?, should I just define a DRM_SCHED( delay ) and on Linux do a schedule and do a delay on BSD until someone steps up to figure it out? That's been the traditional approach - filp maps to pid on BSD, or at least it did initially. Doing the same thing with delays should be fine. What you will notice though is a performance cliff when you start to hit the delay occasionally. Or at least that was the case on early 2.4 when I looked at this last. Keith --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Assert in r200 driver
Jon Smirl wrote: Any ideas about what this is? It is from the Redhat -2 xorg rpm's. All of these programs ran fine on SW mesa and R128 driver. [EMAIL PROTECTED] cairogears]$ ./cairogears -glx COMP cairogears: r200_cmdbuf.c:295: r200EmitBlit: Assertion `(src_offset 1023) == 0 ' failed. Aborted [EMAIL PROTECTED] cairogears]$ ./cairogears -glx TEXT2 cairogears: r200_cmdbuf.c:295: r200EmitBlit: Assertion `(src_offset 1023) == 0 ' failed. Aborted [EMAIL PROTECTED] cairogears]$ ./cairogears -glx SHADOW cairogears: r200_cmdbuf.c:295: r200EmitBlit: Assertion `(src_offset 1023) == 0 ' failed. Aborted Does this use texture rectangle? There were some bugs in the r200 driver which caused such assertion failures. They should be fixed for ages, though the fixes might not be in XFree 4.4 / XOrg 6.7, if this is what redhat ships. 3D driver in these versions is ancient. Otherwise, a back trace might be helpful. Roland --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: intel i865 chipset docs...
Dave Airlie wrote: Hi, I've just gotten an i865 system are there any docs out there for programming the 3d end of this? Intels site for that chipset has no programmers reference beyond the datasheet which doesn't say muc about 3D stuff.. Are these docs available non-NDA? Doesn't this work with the i830 driver? AFAIK i830 and i845G both use the same graphic core (intel extreme graphics). i855G/i852G/i865G use intel extreme graphics 2, which afaik is exactly the same, except it's clocked slightly higher (266Mhz vs. 200Mhz). At least some people have docs... http://www.xfree86.org/~dawes/845driver.html though maybe under NDA. Rumours say though, the Extreme Graphics 3 (rumoured to be renamed to Intel Graphics Media Accelerator 900) on i915G (Grantsdale) will be different (rumoured to have Pixel Shader 2.0 support for instance) - better ask about docs for that ;-). Roland --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Mode setting API's
Hey, It's a good question, my impression was that they are not aiming to the opensource market and only using it as a starting point. They had discussion if you release the SDK in free source or not and although they decided that they would still no one say they still would next time. Usually when I say that people tell me that opengl is also controled by companies, the simple diffrance I see is the fact that opengl does have something to do with hardware and like it or not we need hardware companies support, but AFAICS this is not the case with openML. another thing I find weird is the lack of responds from the developers to the forum they host, and the fact they complitly ignored existing techonologies like openAL. I'm not sure it's a good idea to count on them, I hope the open standard community would release a better more community aware standard Ely Levy System group Hebrew University Jerusalem Israel On Mon, 17 May 2004, Jon Smirl wrote: I'm looking at the OpenML spec and it covers the areas that we have been discussing plus a lot more. But the Khronos Group doesn't appear to be very Open Source friendly. It seems that I have to apply for membership and return signed documents to get a Linux SDK. But some of their other projects are hosted at Sourceforge. What's their intention, are they Open Source or not? --- Keith Whitwell [EMAIL PROTECTED] wrote: As I've said, I don't have a deep grasp of the requirements of a putative future mode-setting API, but in the course of other reading I came across MLdc, which is a part of the OpenML environment. This is a library API which seems to give comprehensive control of mode-setting to an application, but also seems to provide a reasonably easy way to set simple modes. It also has an extension mechanism. It's currently dependent on X to a tiny degree, so there would be some work in adapting it to become stand-alone, and it probably has no conception of things like virtual terminals, etc. Anyway, the OpenML spec is here: http://www.khronos.org/openml/spec.html MLdc is a component of the larger environment. Keith --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/ ___ xserver mailing list [EMAIL PROTECTED] http://freedesktop.org/mailman/listinfo/xserver --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Memory management of AGP and VRAM
1. Add a device independent version. Device independent code could be written that would test the version number the same way device dependent code does today. The drawback is that in order to advertise version X.N functionality, you also have to adverteise version [1.1, 1.N-1] functionality. Some hardware / drivers may not want to / be able to do that. 2. Add an extension query ioctl. Give each piece of functionality (i.e., all the related vblank functions) a unique number. Drivers would make a query like, Is extension 5 supported? If that ioctl returns true, then the driver could use that functionality. The disadvantage of this method is that it increases the number of ioctl calls that need to be made. Since the set of supported extensions can be tracked in the DRM with a bit string, the additional code size should be trivial. Thoughts? I don't think this needs to be that complex. We only need a few working functions in the kernel: * identification (In particular unique identifier to pass via X to apps so they can find the head again) * event reporting (i.e. IRQs and anything else that is relevant) * mode setting * memory management * bitblt Everything else is best done as device-specific with the true API belonging in user-space. Comments ? best Vladimir Dergachev --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Memory management of AGP and VRAM
I don't think this needs to be that complex. We only need a few working functions in the kernel: * identification (In particular unique identifier to pass via X to apps so they can find the head again) * event reporting (i.e. IRQs and anything else that is relevant) * mode setting * memory management * bitblt Everything else is best done as device-specific with the true API belonging in user-space. Comments ? Just to say that bitblt covers a lot of ground; ie. there's lots of varieties of blits with quite a few parameters - are you talking about just a simple copy within a single framebuffer, or can source and destination have different pitches? what about different pixel formats? what about fill-blits? etc. And secondly, that an ioctl per blit probably isn't a useful interface if you're trying to do a lot of small blits, like I guess drawing text. So if you wanted this to be maximally useful, some way of saying 'do these n blits' would make sense. And what about cards with no 2d engine? Keith --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM and latency..
On Thu, 20 May 2004, Keith Whitwell wrote: Dave Airlie wrote: It has been pointed out to me by Andrew and Fernando Pablo Lopez-Lezcano that we do a lot of sleeping in code that probably should reschedule rather than sleep,radeon_do_wait_for_idle being a prime example, this has a DRM_UDELAY(1), this messes up audio latencys, Now I'm not sure that wholesale replacing these with a conditional schedule is correct, but in most cases it looks like there should be no issues doing this, theses functions are all usually called from a process context, My main worry is what to do on BSD about this?, should I just define a DRM_SCHED( delay ) and on Linux do a schedule and do a delay on BSD until someone steps up to figure it out? That's been the traditional approach - filp maps to pid on BSD, or at least it did initially. Doing the same thing with delays should be fine. What you will notice though is a performance cliff when you start to hit the delay occasionally. Or at least that was the case on early 2.4 when I looked at this last. Keith FreeBSD's DRM used to define DRM_DELAY as a macro around a wakeup/tsleep pair (almost the equivalent of schedule()). This did result in some fairly bad stuttering on at least the G400 that using the simple delay loop (UDELAY) fixed (the wakeup/tsleep also avoided some lockups that the linux version of that driver had at times, but the stuttering made many interactive apps fairly useless). This was with FreeBSD-4.1 to maybe FreeBSD-4.4. FreeBSD-5.x may have some better facilities for scheduling small delays in device drivers that are waiting for hardware to return and for quickly scheduling run time for a user process that is blocking on that device driver. But that's not something I know about first hand. --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Memory management of AGP and VRAM
Keith Whitwell wrote: I don't think this needs to be that complex. We only need a few working functions in the kernel: * identification (In particular unique identifier to pass via X to apps so they can find the head again) * event reporting (i.e. IRQs and anything else that is relevant) * mode setting * memory management * bitblt Everything else is best done as device-specific with the true API belonging in user-space. Comments ? Just to say that bitblt covers a lot of ground; ie. there's lots of varieties of blits with quite a few parameters - are you talking about just a simple copy within a single framebuffer, or can source and destination have different pitches? what about different pixel formats? what about fill-blits? etc. And secondly, that an ioctl per blit probably isn't a useful interface if you're trying to do a lot of small blits, like I guess drawing text. So if you wanted this to be maximally useful, some way of saying 'do these n blits' would make sense. And what about cards with no 2d engine? A command buffer interface (either mmap()'d buffers or buffers copied using standardized ioctls) with a common command set might be a general approach working on all architectures -- not all card drivers would need to implement all command opcodes, a capability ioctl can return a bitfield of supported opcodes. The command buffers might then get verified and executed by the DRM drivers - on the userspace side you would only need to implement a few pretty generic drivers and the fallback code. The verification code can probably get shared for most or all cards. Holger --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Memory management of AGP and VRAM
Holger Waechtler wrote: Keith Whitwell wrote: I don't think this needs to be that complex. We only need a few working functions in the kernel: * identification (In particular unique identifier to pass via X to apps so they can find the head again) * event reporting (i.e. IRQs and anything else that is relevant) * mode setting * memory management * bitblt Everything else is best done as device-specific with the true API belonging in user-space. Comments ? Just to say that bitblt covers a lot of ground; ie. there's lots of varieties of blits with quite a few parameters - are you talking about just a simple copy within a single framebuffer, or can source and destination have different pitches? what about different pixel formats? what about fill-blits? etc. And secondly, that an ioctl per blit probably isn't a useful interface if you're trying to do a lot of small blits, like I guess drawing text. So if you wanted this to be maximally useful, some way of saying 'do these n blits' would make sense. And what about cards with no 2d engine? A command buffer interface (either mmap()'d buffers or buffers copied using standardized ioctls) with a common command set might be a general approach working on all architectures -- not all card drivers would need to implement all command opcodes, a capability ioctl can return a bitfield of supported opcodes. Maybe we could use the X11 protocol (runs away hides) Keith --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Americas Army 2.0 color problem with radeon
Playing AA2 on my FC2 box with a radeon 7500 I noticed that the skin color on people is way to light. Everything else looks normal. Anyone have suggestions? --Thanks X.org-X11-6.7.0 kernel-2.4.5 --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Memory management of AGP and VRAM
Everything else is best done as device-specific with the true API
belonging in user-space.
Comments ?
Just to say that bitblt covers a lot of ground; ie. there's lots of varieties
of blits with quite a few parameters - are you talking about just a simple
copy within a single framebuffer, or can source and destination have
different pitches? what about different pixel formats? what about
fill-blits? etc.
And secondly, that an ioctl per blit probably isn't a useful interface if
you're trying to do a lot of small blits, like I guess drawing text. So if
you wanted this to be maximally useful, some way of saying 'do these n blits'
would make sense.
You are quite right :) I was thinking that we need as much bitblt as one
would need to implement a scrolling console: i.e. move areas within
framebuffer and use bitmapped fonts. I think that this can be accomplished
with an easy API.
For example, what about separating it into two parts:
1) BITBLT ioctl:
/* easy to check against actualy physical boundaries
to prevent lockups, not virtual partition via memory manager */
typedef struct {
long format; /* format key */
long offset; /* location with framebuffer */
long width;
long height;
long pitch;
} SURFACE;
typedef struct {
SURFACE dest;
SURFACE source;
} BLIT;
typedef struct {
long n_items;
BLIT item[1]; /* expanded as needed to allocate n items */
} BITBLT_ARG;
framebuffer-bitblt(FRAMEBUFFER *, (*BITBLT_ARG)); /* in-kernel interface */
ioctl(fd, BITBLT, (BITBLT_ARG *)); /* user-space interface */
2) Memory transfer ioctl: (for exchanging data with framebuffer)
typedef struct {
int direction;/* upload or download */
void *mem_area;
SURFACE framebuffer_surface;
SURFACE memory_surface;
} TRANSFER;
typedef struct {
long n_items;
TRANSFER item[1]; /* expand as needed for n items */
} TRANSFER_ARG;
framebuffer-transfer(FRAMEBUFFER *,TRANSFER_ARG *); /* in-kernel interface */
ioctl(fd, TRANSFER, (TRANSFER_ARG *)); /* user-space interface */
And what about cards with no 2d engine?
VESA framebuffer (and similar) can use plain memcpy.
3d accelerators without direct access to framebuffer would have some way
of transferring memory to the framebuffer and back as well as blits.
Truly weird hardware would require ingenuity - as appropriate.
Comments ?
best
Vladimir Dergachev
Keith
---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: intel i865 chipset docs...
Doesn't this work with the i830 driver? AFAIK i830 and i845G both use the same graphic core (intel extreme graphics). i855G/i852G/i865G use intel extreme graphics 2, which afaik is exactly the same, except it's clocked slightly higher (266Mhz vs. 200Mhz). At least some people have docs... yup but I'm seeing some bugs, and I usually fell more comfortable sitting on a pile of docs :-), I'll get around to some proper debugging soon, just need time and time :-) Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 652] New: dri/xc has an empty lib/Xau
http://pdx.freedesktop.org/cgi-bin/bugzilla/show_bug.cgi?id=652 Summary: dri/xc has an empty lib/Xau Product: DRI Version: DRI CVS Platform: All URL: http://freedesktop.org/cgi- bin/viewcvs.cgi/dri/xc/xc/lib/Xau/ OS/Version: All Status: NEW Severity: normal Priority: P2 Component: General AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] As a result we implicitly depend on /usr/X11R6/lib/libXau.a existing at compile-time. Solutions: - pull in lib/Xau from upstream, patch it back into the build. - ignore it until we switch to building straight from Mesa. Reported by shadows on #dri, while attempting to make an ebuild of current CVS. The external dependency triggers a sandbox violation. --- 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: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Memory management of AGP and VRAM
A command buffer interface (either mmap()'d buffers or buffers copied using standardized ioctls) with a common command set might be a general approach working on all architectures -- not all card drivers would need to implement all command opcodes, a capability ioctl can return a bitfield of supported opcodes. Maybe we could use the X11 protocol Well, X11 protocol was designed rather well. We can simplify the matters quite a bit by requiring that writes to the fd always send N whole packets (and don't break on per-packet boundaries). On the other hand we would probably want to modify the protocol at least in the following way: 1) take into account modern hardware.. no short width anymore, more pixel formats. 2) only require parts essential for console implementation - everything else could be passed back to user-space daemon. (Note that if user-space daemon is not present this would mean that things like line-drawing packets would fail..) 3) the framebuffer would only emit IRQ and completion events. 1) implies that we are not going to be binary compatible with usual X11 protocol, so we are implementing a new protocol nevertheless which means this whole point rather academic: if one designs a new protocol there is no reason not to take into account design of X11. best Vladimir Dergachev (runs away hides) Keith --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
