>I thought about this a bit more. Let me propose a different viewpoint
as
>a result. That viewpoint is that there is no reason for any
>acceleration. Scroll at most.
>
>If the video mode switching is done right and apps can handle graphics
>nicely then you need a kernel mode text console at boot,
>Boy, I haven't really been following this too closely, but surely this
>sort of thing can be resolved with an extension mechanism or api
>versioning?
An extension mechanism is fine for eventually extending the basic
functionality, but a driver writer should not have to wait for consensus
to add
>Sottek, Matthew J writes:
>>
>> I agree. I think we are on the same page. A minimal set of features
is
>> all that would be part of the defined mode setting API. It is just a
>> question of if some of the multi-head concepts are generic enough to
>> be pa
>It does, or the ioctl must verify the register data, which could require
>about the same amount of code as computing it in the kernel in the first
>place (possibly even more; the problem changes from computing a valid
>combination of register values for a specific requested mode to limiting
>the
>Moving mode setting from the Xsever does not necessarily mean it has
>to go into the kernel.
I agree. The thing I am worried about (just speaking about the mode
setting
part here) is that we end up with 2 defined APIs. One for the mode
setting,
done as a user library, and another for the kernel
>> 1) If the mode setting can be removed from the X server then we can
>> leverage that module for whatever graphics system is required. Some
>> times we need an X server, some times we need something more like a
>> framebuffer. Putting this in one place is a must.
>
>'one place' appears to mean a
I for one have been waiting to see much of the graphics driver moved to
the kernel as well. From a vendor perspective there is quite a lot to be
gained.
1) If the mode setting can be removed from the X server then we can
leverage that module for whatever graphics system is required. Some
times we
> if (!pointer) {
> return (whatever);
> }
>
>
>because it's consistent, and guaranteed safe from stupid
>parsing errors that can waste days of debug time when
>someone decides to add to it.
>("its just a little change that cant hurt anything", ha ha)
I've always been an "Always use bracket
The patch was tested at that time and appeared to solve all the problems.
Unfortunately at that time the dri tree and XFree tree were pretty diverged and nobody
seemed interested enough to make sure the patch got in post-merge.
If you can get that patch applied to current sources that would be
come on the top of the reel it seems to jump a
> bit...
>
> Not sure if the fullscreen would help here.. I need to time each render
> and see if this one takes a lot longer than the others..
>
> Dave.
>
> Sottek, Matthew J said:
>>
>> The easiest way to get rid of tear
The easiest way to get rid of tearing is to make the ring buffer wait
before the back->front blit. This is a very simple mechanism that will
work even for windowed 3d, and if you are running just one 3d client
the wait time should not alter your performance much. Or rather,
the performance decreas
>So, how do you delay the flip-blit to the vblank but NOT delay other
>rendering?
You would delay rendering from that ring. There are 2 rings on i810
(Only one gets used by XFree/DRM).
Depending on what you are trying to achieve, that may be what you want.
If you used an interrupt to indicate vb
rom: Antonino Daplas [mailto:[EMAIL PROTECTED]]
Sent: Friday, December 13, 2002 6:15 PM
To: [EMAIL PROTECTED]
Cc: DRI developer's list
Subject: Re: [Dri-devel] vblank and i810
On Sat, 2002-12-14 at 03:41, Ian Romanick wrote:
> On Fri, Dec 13, 2002 at 01:15:01PM -0800, Sottek, Matt
The i810's vblank interrupt does not go to the CPU's interrupt
controller IIRC. Therefore you have to poll for vblank by reading
the current scanline.
Usually apps that are waiting on vblank can be better served by
solving the actual problem rather than trying to use a generic wait
For vblank sol
This fixes the broken direct rendering problem seen by several people
on the XFree list and tracked to XvMC by Mike Harris. The issue
doesn't seem to actually be XvMC or XFree at all. As far as I can
tell XFree does correctly have direct rendering working. For some
reason the zero sized drmMap th
Ok,
I'll look into this. This would explain why I haven't been able to
reproduce the problem seen by a couple people on this list. My systems
all have XvMC turned on.
-Matt
-Original Message-
From: Mike A. Harris [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 05, 2002 1:58 AM
To
This is a repost with the patch against 2.4.17 attached. I think Jeff
is back on the list so I'll save him from having to read the archives
for the original.
-Matt
I posted a RFC about a new type of "Shared" agp memory a while back
but didn't get any input. I thought I would try again since
>> No impact whatsoever. I specifically didn't touch ANY device
>> independent code. It is all contained within the i810's driver.
>Have you gotten any feedback from developers working with any other UMA
>architectures (Sis or Savage for example)?
The only feedback I've gotten is from this list
When did we plan on doing the IRC meeting? I missed the final
decision.
-Matt
-Original Message-
From: Daryll Strauss [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 28, 2002 8:45 AM
To: [EMAIL PROTECTED]
Subject: [Dri-devel] IRC Meeting
I'm going to be at a client most of the day,
>This seems reasonable enough, but I'll have to think about it more
>and learn a bit more about the AGP implementation to fully grok it.
>On question I do have is what impact will this have (if any) on
>chipsets that aren't UMA?
No impact whatsoever. I specifically didn't touch ANY device indepen
I posted a RFC about a new type of "Shared" agp memory a while back
but didn't get any input. I thought I would try again since there has
been better communication as of late, and the idea has progressed
somewhat.
The problem:
The agpgart usage model is not well suited for UMA architectures beca
I would like to give another perspective on this conversation, but
let me first say that I am speaking for my personal views and not
representing the company I work for.
It is easy for people to discount complaints when they come in
such a passionate manner. Everyone should keep in mind that rar
>The next line I quoted:
> new->physical = virt_to_phys((void *) new->memory[0]);
>...
>takes that masked physical address and applies virt_to_phys to it,
>which just seems wrong. Like I said, I don't have an i810, and I
>haven't exhaustively analyzed it to see, for instance, whether
>new->ph
Why do you think that isn't a virtual address? agp_alloc_page
gets a page and returns page_addresss(page) which is the kernel
virtual address for the page, right? Kernel memory is paged so
it doesn't have to be a user address to be virtual.
BTW: It works just fine. Nobody on an i810/i815 would h
>However, it does look like AGPIOC_ALLOCATE is broken. It only returns
>the ->physical field of the resulting agp_memory structure. It doesn't
>even look like this field is set for any chipsets other than the i810
>and i830.
You don't need anything other than the "key". This isn't a general
pu
I have made some modifications to the gart driver to better support
the i810 and i815 chipsets. This patch introduces a new type of agp
memory known as "shared". This is an important concept to support in
order to better make use of resources on these systems, and to allow
interoperability betw
>> #1 A kernel API for mode setting, mmaping of the framebuffer and
>> video memory management.
>Truely needed. Something like the Linux version of the VESA
>interface. I think the Linux framebuffer project took this thing
>as their basic idea.
The basic idea in the framebuffer is fine, but the
>>I'm really concerned about your answer. There was a whole thread
>>on the linux-kernel mailing list about the hypothesis of the
>>release of an X-Kernel, a kernel which would include built-in
>>desktop support. Most people answered, no, this would be
>>ridiculous, other said, yes, but hardware m
rns the gart address.
Does such an animal exist?
-Matt
-Original Message-
From: Michael Zayats [mailto:[EMAIL PROTECTED]]
Sent: Saturday, October 13, 2001 2:17 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; Sottek, Matthew J
Subject: Re: [Xpert]XVideo (memcoy) consuiming to much CPU (
Vladimir,
As Peter pointed out to me you were speaking of a video card
with built-in capture. This _does_ require, as you stated a
way to get the video, out of the video ram and into system ram,
my apologies for the misunderstanding.
My point should still hold. The DRM should allow you to ma
Vladimir,
The drm _does_ allow the client to mmap the video ram. Of course
there are security reasons to limit this behavior. The X server
handles the memory management and then sets up drm maps which are
areas of video memory that can be mapped by a drm client.
Take a look at the xc/lib/XvMC/h
Keith, Jeff,
I sent a patch for this some time ago to put the Shared Interrupts back
into the i810 driver. It looks to have been included by Gareth in
the head branch. Maybe this didn't get submitted to Linus yet?
-Matt
-Original Message-
From: Keith Whitwell [mailto:[EMAIL PROTECTED]
Neale,
I think the known limitations was written a long time ago,
multiple servers has been working at least for some people for
quite some time. I am not sure of what configurations are
working and which are not.
The debug information you provided doesn't say if you are
using DRI or not. Are
This patch adds in shared IRQ's. I added it in a manner that
goes along with the template code so it should only alter
the i810 driver.
Plus, the i810 drm isn't working in XFree 4.1.0. I get
regular oopsen when shutting down X leaving me with a blank
console (if I'm lucky). With shared interr
The i810 driver used to have interrupt sharing before moving to the template
code, it appears to have lost this functionality since the change. This is a
real problem since a lot of the i810's and i815's have integrated lans that
are using the same interrupt as the graphics controller.
As I rec
Frank,
The Intel graphics chips are integrated into the memory
controller and therefore are not really "Agp" or "PCI".
You could either just leave all the Intel chips as AGP, or
list them as "Integrated Chipset", but there is no PCI
version for these chips.
Also, Along the lines of Alan and Dar
ranch.
-Original Message-
From: Jeff Hartmann [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 20, 2001 8:38 AM
To: Sottek, Matthew J
Cc: [EMAIL PROTECTED]
Subject: Re: [Dri-devel] libdrm.a Bugs
Sottek, Matthew J wrote:
> All,
> I'm doing a direct rendered HWMC (XvMC protocol) d
All,
I'm doing a direct rendered HWMC (XvMC protocol) driver for the i81x, I am
compiling the drm Libs outside of the X server and have run into a problem.
The
current Linux kernel is allocating minor numbers for the device dynamically,
but
the drm Libs don't seem to have caught up with this idea
38 matches
Mail list logo
