On Tuesday 22 October 2002 03:00 pm, you wrote:
But wouldnt it be nice to allow the graphics card to directly access
the data from user space ?
It seems to defeat the whole point of DMA, if you have to do multiple
copies of the data.
DMA allows you to do other things while the display chip's
On Wednesday 29 May 2002 02:54 pm, Felix Kühling wrote:
I had an SIS 6326 one or two years ago and tried to make it work with
XFree 4.0.2, I think. I figured out that the SIS DRM needs the SIS
framebuffer driver. However, it does not work with SIS 6326 (at least it
didn't use to). My
On Tuesday 28 May 2002 06:34 pm, Al Tobey wrote:
Since it seems to be my turn to spam the list...
Has anybody talked to SiS about this beastie (Xabre) yet? It's brand
new and I can't even find a card for sale, but there are a few reviews
floating about the net. Might be nice to get a
On Saturday 25 May 2002 12:10 am, Leif Delgass wrote:
So it would appear that allowing clients to add register commands to a
buffer without verifying them is _not_ secure. This is going to make
things harder, especially for vertex buffers. This is going to require
copying buffers and
On Saturday 25 May 2002 03:01 am, José Fonseca wrote:
Wow! Bummer... I already had convinced myself that the card was secure!
It is, if you don't rely on a register being set by something for your
control of things. You may get peak performance with the design in question,
but it's not
On Saturday 25 May 2002 11:48 am, José Fonseca wrote:
On 2002.05.25 17:16 Frank C. Earl wrote:
Frank, Leif was pretty clear and I quote:
it IS possible to derail a bus master in progress and set it
processing from a different table in mid-stream. Plus, if the address is
bogus
On Saturday 25 May 2002 11:56 am, you wrote:
What prevents a client from modifying the contents of a buffer after it's
been submitted? Sure, you can't send new buffers without the lock, but
the client can still write to a buffer that's already been submitted and
dispatched without holding
On Saturday 25 May 2002 11:48 am, José Fonseca wrote:
So if you can't secure it in the end, your extra effort will be in vain.
I just thought of something to try to change the nature of the test case
problem. What happens if you have a second descriptor of commands that
merely resets the
On Saturday 25 May 2002 01:14 pm, Leif Delgass wrote:
I'm using the same model you had set up. When a client submits a buffer,
it's added to the queue (but not dispatched) and there's no blocking.
The DRM batch submits buffers when the high water mark is reached or the
flush ioctl is called
On Saturday 25 May 2002 03:44 pm, Leif Delgass wrote:
This had crossed my mind too. The only problem is that there could still
be a short period of time where BM_GUI_TABLE isn't accurate, so it still
leaves the problem of being able to trust the contents of BM_GUI_TABLE for
buffer aging and
On Saturday 25 May 2002 03:50 pm, Leif Delgass wrote:
It just occurred to me that resetting BM_GUI_TABLE could put the card into
a loop. You might have to put in an address two descriptors away. We'd
need to test this.
Hmm... Didn't think about that possibility. I had this last line of
On Saturday 25 May 2002 04:27 pm, you wrote:
Anyway, this doesn't prevent to use the buffer aging. On the end of
processing a buffer we still end up with the correct value of BM_GUI_TABLE
and we can use the last bit of BM_COMMAND to know if it's processing the
last entry or not. The only
On Saturday 25 May 2002 06:07 pm, Leif Delgass wrote:
Does anyone have any ideas on this? I haven't seen compiler messages like
this before when compiling the drm.
Did Gerard indicate what distribution and C compiler he was working with?
This is the same bizarre things I usually saw when
On Thursday 23 May 2002 04:37 pm, Leif Delgass wrote:
I've committed code to read BM_GUI_TABLE to reclaim processed buffers and
disabled frame and buffer aging with the pattern registers. I've disabled
saving/restoring the pattern registers in the DDX and moved the wait for
idle to the XAA
On Tuesday 14 May 2002 10:01 pm, Ian Romanick wrote:
This is just a crazy suggestion, but has anybody talked to any ATI
engineers to find out how they do it in win32? Your idea sounds very good,
but I'd still be curious to hear how (or if!) ATI solved this problem on
Windows...
I've been
On Wednesday 15 May 2002 06:51 am, Leif Delgass wrote:
I'm getting close to committing this now. I got gui-master blits working,
and pseudo-DMA is stable. Actually, the pseudo-DMA is probably faster
without blits, but I'm hoping that it will help with DMA. The DMA is
still prone to
On Sunday 12 May 2002 01:15 pm, Leif Delgass wrote:
this working, I've used buffer aging rather than interrupts. What I
realized with interrupts is that there doesn't appear to be an interrupt
that can poll fast enough to keep up, since a VBLANK is tied to the
vertical refresh -- which is
On Friday 03 May 2002 11:08 am, you wrote:
I think the reason for the alias is that the card increments the
GUI_TABLE_ADDR @ BM_GUI_TABLE as it consumes descriptors, so writing to
BM_GUI_TABLE could disrupt a DMA pass in progress. Using the alias
ensures that the commands already in the
On Friday 03 May 2002 09:49 am, you wrote:
As I was studying the specs and code to be able to understand and reply to
Leif's previous post (which I haven't completed yet..), I noticed at the
same time a bug and a feature which could mean that blind client buffering
could be insecure after
On Friday 03 May 2002 01:38 pm, Dieter Nützel wrote:
http://www.anandtech.com/video/showdoc.html?i=1614
Regards,
Dieter
If they'll let some of us (either the TG people or the independents) have
info, yeah. If not, it may be problematic for them and they'll have to do
something like
On Wednesday 01 May 2002 03:58 am, JosX Fonseca wrote:
Frank just commited a set of changes to the mach64-0-0-3-dma-branch. Is in
own words:
Most of the first cut of the DMA code. It's got most of the
dispatch
architecture in place (Lacks actual DMA submission (The easy part,
On Wednesday 24 April 2002 06:15 am, you wrote:
Hi, there!
For enabling DMA on Mach64 I'll need to allocate two extra DMA buffers: a
primary DMA buffer and a decription table buffer.
All you need for now is a descriptor table. The buffers that you have
already allocated via the DRM's
On Thursday 07 February 2002 12:37 pm, Jose Fonseca wrote:
Could someone of the 3D gurus enlighten this question? More
specifically, what is pseudo DMA and what is the relationship between
DMA and the PIO and MMIO modes?
psuedo DMA is where you pass a DMA-able command buffer to an
On Sunday 10 March 2002 11:44 am, José Fonseca wrote:
I really don't know much about that, since it must happened before I
subscribed to this mailing list, but perhaps you'll want to take a look to
the Utah-GLX and this list archives. You can get these archives in mbox
format and also
On Sunday 10 March 2002 04:36 pm, José Fonseca wrote:
I didn't fully understand the implications of above, but shouldn't the
direct access to the chip registers still be denied to clients?
Depends.
Looking at the gamma source code (I could be wrong, mind...) it appears that
the DRM is
On Monday 18 February 2002 10:35 pm, Keith Whitwell wrote:
The rings are in agp space. It's a bug in the security model of the i810,
it's arcane, but believe me it's real.
Which leaves it open to attack because the AGP space isn't covered by the
protection system. Got to wonder what they
On Monday 18 February 2002 12:07 pm, Keith Whitwell wrote:
The i810 has a security model that makes insecure commands in batch buffers
into noops. Unfortunately there is a hole in the security model: you can
emit a batch buffer with blit commands in it that blit insecure commands
onto the
On Monday 18 February 2002 01:07 pm, Keith Whitwell wrote:
A followup here... I'm looking at the i810 documentation and the source tree
now.
The i810 has a security model that makes insecure commands in batch buffers
into noops. Unfortunately there is a hole in the security model: you
On Friday 08 February 2002 07:09 pm, José Fonseca wrote:
Does this mean that client code can lock the card but is not really
capable of putting the security of the system in danger?
Depends on what you define as in danger. It won't allow a user to commit
local or remote exploits to gain
On Friday 08 February 2002 11:03 am, Jose Fonseca wrote:
Keith, is pseudo DMA a hardware feature of Matrox cards or just a
software hack for debugging purposes?
I'm not Keith, but I'll venture an answer. It's a software hack that was in
the Utah-GLX drivers for the G200/G400 and RagePRO
On Monday 21 January 2002 09:21 am, Mike Westall wrote:
Conversely, if MS considers OpenGL to be dead and buried,
period, it seems that Bill would be bit silly to want to
spend $62.5 to become the owner of said dead + buried
technology!!
OpenGL is not really technology- it's an API that
On Tuesday 08 January 2002 04:12 pm, Leif Delgass and Manuel Teira wrote:
Happy New Year!
Hopefully for all, it will be a better one than the last...
Well, after the holidays, I would like to recover the development in the
mach64 branch. I started today to investigate the DMA stuff
On Sunday 13 January 2002 11:50 pm, Gareth Hughes wrote:
While we're discussing things here, can anyone tell me why
things like the emit state code is in the DRM instead of in
the Mesa drivers? It looks like it could just as easily be
in the Mesa driver at least in the case of the
On Tuesday 20 November 2001 11:27 pm, you wrote:
Yep, that's correct. Had to deal with missing and/or conflicting info
to boot...
This sounds strangely familiar... :-)
--
Frank Earl
___
Dri-devel mailing list
[EMAIL PROTECTED]
On Tuesday 20 November 2001 04:36 pm, you wrote:
Having said all that, the docs that I have (and most others I think) don't
really cover 3D operations (except for register listings). I'm not sure
if the DRI project has 3D documentation available for project members.
I don't think there's
On Friday 16 November 2001 12:51 pm, Nick Hudson wrote:
I have a ATI Rage Mobility Mach32 card I beleave ... Its in a Dell inspiron
7500 and I was just wondering is there DRI support for it? I was looking
for something that might speed up my frame rate.
Drivers for the RagePRO family (which
On Monday 29 October 2001 01:04 pm, Robin Forster wrote:
I have been considering lending a hand with supporting the effort to
port the Xpert98 drivers to DRI. Anyone hear know what is happening in
this area?
The Xpert98 should be a RagePRO type chipset (if memory serves...)- we're
working
On Wednesday 24 October 2001 01:54 am, [EMAIL PROTECTED] wrote:
a=readl(kms-reg_aperture+MACH64_BUS_CNTL);
writel((a | (31) )(~(16)), kms-reg_aperture+MACH64_BUS_CNTL);
same other code
works fine. Now why would this be ?
This could be caused by the same thing
On Wednesday 24 October 2001 11:30 pm, Gareth Hughes wrote:
Hmm, in a day where you can get PC graphics hardware that can run Quake3
at 1600x1200@32 with maximum quality settings at around 100 fps, perhaps
you should reevaluate your idea of powerful enough...
Now, now, not everybody can use
On Saturday 20 October 2001 10:18 pm, Daryll Strauss wrote:
On Sat, Oct 20, 2001 at 07:49:56PM +0200, Manuel Teira wrote:
OK. Thank you for the clear explanation. Now I think I'm ready to put the
new branch in the repository. I'm waiting for the access, guys. As soon
as I have access (if
On Saturday 21 April 2001 19:44, Jon Pennington wrote:
I, too, am interested in the status of this project.
It's in the process of being revived.
Right now, I'm just seeing what I have to work with. Once I've got a good
handle on it, I'll be giving the DMA support another go (which Gareth
On Friday 20 April 2001 10:36, Markus Kohls wrote:
I wonder, if there's anyone working on the mach64-driver yet? After Gareth
stopped working on it, there seems to be noone, who is further working on
it. Is the development on the mach64 dead?
No, it's not dead. Right now as I type this, I'm
42 matches
Mail list logo
