Re: [Dri-devel] DRM OS Independence and Mach64
On Wed, 19 Feb 2003, [iso-8859-15] José Fonseca wrote: > On Tue, Feb 18, 2003 at 06:30:40PM -0500, Leif Delgass wrote: > > I also made some other changes to the copy/verify: > > > > I added a check to the ioctl handler (mach64_dma_vertex) to check that the > > vertex buffer has an integral number of dwords (in addition to the check > > against MACH64_BUFFER_SIZE). I also changed copy_and_verify_from_user to > > return an error code instead of the number of bytes copied. I don't see > > any reason to dispatch a buffer unless all checks succeed (in fact it can > > potentially cause lockups if we submit a partial buffer), so it's either > > all or nothing. If it succeeds then we just copy buf->used to the private > > buffer struct. This also allows us to return a more meaningful error > > code, e.g. EFAULT for failed verify_area/copy_from_user, EINVAL for bad > > command counts or buffer size, and EACCES for disallowed register commands > > in the buffer. It also lets us get rid of the 'copied' local var and a > > couple of adds inside the loop. > > At that time I coded that way as an aid to debug that code. Now I don't > see any problem in letting that go. > > > A couple of other minor tweaks I made > > were copying the byte length parameter to a local var and declaring the > > function as inline. It also now will generate an error if there is a > > register command without at least one data dword following it (in addition > > to checking for a command count that overflows buf->used). That check is > > now the new loop condition (n > 1 instead of n (!=0) ), so it doesn't add > > anything inside the loop. There is one extra conditional in the loop now > > to check the return of copy_from_user. All of this may or may not have > > much of a performance effect, but it is a pretty critical code path, I > > think. > > My impression is that the effect of the copy/verify is noticeable in > slower machines but neglectable in faster. But I guess that the hit is > probably more related to the processor cache than its actual speed. At some point, I'm planning on trying out oprofile with the new branch. Last time I looked, a lot of time seemed to be spent in freelist_get waiting for free buffers, but I think that was also before copy/verify. > > > > 3. We still need to work out the wrapper/alternative to > > > > pci_alloc_consistent() and friends. > > > > > > I'm still reading Ian texmem-2 proposal and looking to the source code > > > to get a hold of this. > > > > It's now official: I'm coding on this. I'm adding the _ioctl suffix to > most IOCTLs (e.g., agp_alloc -> agp_alloc_ioctl) to leave to the > agp_alloc for internal DRM usage, and writing a set of pci_* to wrap the > pci_*_consistent and pci_pool_* API in the Linux. > > Nothing of this will break binary compatability and will allow one to > [optionally] setup all main DMA buffers from within DRM_IOCTL_DMA IOCTL > instead of the X server. Of course that I would like to pursue this idea > in Mach64 driver. I'll be interested to see what you come up with. How much of the setup in atidri.c were you thinking of moving to the kernel? We'd still need to allow for XF86Config options dealing with the AGP aperture and buffer region size(s), as well as passing a handles back to the Xserver for the AGP aperture (to setup the AGP registers) and the AGP texture map (although maybe the Mesa client could just get it with a get_param ioctl). If the Xserver does it, it needs to leave space for the private buffers in AGP when calculating the region sizes/offsets. > > Something I have in my old tree that I haven't merged to the new branch > > yet is setting up the ring in AGP when available. That will get rid of > > the use of pci_alloc_consistent for AGP cards. However we still can't do > > private buffers in AGP without multiple buffer lists. However, it might > > be enough to allow porting/testing on *BSD to continue with the PCI mode > > setup in mach64_dma.c disabled (with the current temporary code that > > uses client buffers instead of secure buffers). > > BTW, is it OK to enable snapshots from the 0-0-6 branch instead? I think that would be fine, but I think that might mean that the extras package will be required too. BTW, what's the status of the trunk snaphots? Are we waiting for 4.3.0 to start those again? -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM OS Independence and Mach64
On Tue, 18 Feb 2003, Linus Torvalds wrote:
>
> On 19 Feb 2003, Alan Cox wrote:
> >
> > copy_from_user sorts out the whole thing itself. In general
> > __copy_from_user and verify_area isnt a win, except if you do lots of
> > small copies to/from the same area, which is often a bad idea anyway.
>
> It _can_ be a good idea, though.
>
> In particular, it's a _really_ good idea if the loop is basically a
> "glorified memcpy", at which point it can be very much worthwhile to move
> the limit checking outside the loop.
>
> An example of this is doing things like "copy-and-checksum", or, in the
> case of DRM "copy-and-check-validity", where the code should sanely look
> something like
>
>
> u32 *addr; /* Command list */
>
> if (!access_ok(VERIFY_READ, addr, size))
> return -EFAULT;
>
> while (size > 0) {
> unsigned int cmd;
>
> if (__get_user(cmd, addr))
> goto efault;
> addr++;
> switch (cmd) {
> ... verify it ...
> }
>
> *dst++ = cmd;
> }
>
> where the difference between a "get_user()" and a "__get_user()" can be
> quite noticeable (the unchecked version is usually a single instruction in
> size and has no nasty branch behaviour or anything like that, while the
> checking version usually has at least one conditional branch and uses up
> one or two registers etc).
>
> Of course, this is really only worth doing for tight loops that really
> matter. If the code in the loop is crap, the optimization just isn't worth
> the complexity.
>
> (And the extreme case of this is when the code is _so_ performance
> critical that you end up writing it all in assembly language. The example
> of this is the TCP copy-and-checksum stuff. The above example is somewhere
> between the "normal usage" and the "TCP copy-and-checksum" extremes).
>
> Linus
The code is similar to this, but with a couple of differences. We have to
split apart 'cmd' into two local vars (swapping bytes for big-endian) and
verify them (register address and count of data dwords following). If the
verify passes, we copy the command as in the last line of the loop above,
but then we need to __copy_from_user up to 7 dwords of data into the
destination without reading it. So it's a loop of alternating 1 dword
read/verify/write and 1-7 dwords straight copy.
--
Leif Delgass
http://www.retinalburn.net
---
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Lock problem with Radeon DRI
On Tue, 18 Feb 2003, Martin Spott wrote: >> > Where did you take the DRM sources from ? I usually take the source for the >> > DRM module from the same DRI CVS tree I use to build the whole DRI thing, >> >> Mike Harris builds in Red Hat beta and in rawhide > >It appears to me that the kernel modules of Mike's build do not differ from >XFree86 4.2.99.901 - at least he didn't include any additional patches >that thouch the kernel modules. I have the impression he also did not >include any patches that touch the Radeon driver in a way that might prevent >from lockups. Just to be clear here. I do not build kernel DRM modules - ever. I do not package kernel DRM modules - ever. I take kernel DRM and pass it to arjan/alan occasionally, but I do not build DRM nor ship it to anyone, and I never have. So, there is no "Mike's DRM". >So are we going to see XFree86-4.3.0 with broken Radeon DRI drivers ? I do not decide what DRM code is used in DRI-CVS, nor in XFree86-CVS, nor in the Red Hat kernel, Linus' kernel, Alan's -ac patches, or any other place. I package up XFree86 itself, not the kernel. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM OS Independence and Mach64
On Tue, Feb 18, 2003 at 06:30:40PM -0500, Leif Delgass wrote: > I also made some other changes to the copy/verify: > > I added a check to the ioctl handler (mach64_dma_vertex) to check that the > vertex buffer has an integral number of dwords (in addition to the check > against MACH64_BUFFER_SIZE). I also changed copy_and_verify_from_user to > return an error code instead of the number of bytes copied. I don't see > any reason to dispatch a buffer unless all checks succeed (in fact it can > potentially cause lockups if we submit a partial buffer), so it's either > all or nothing. If it succeeds then we just copy buf->used to the private > buffer struct. This also allows us to return a more meaningful error > code, e.g. EFAULT for failed verify_area/copy_from_user, EINVAL for bad > command counts or buffer size, and EACCES for disallowed register commands > in the buffer. It also lets us get rid of the 'copied' local var and a > couple of adds inside the loop. At that time I coded that way as an aid to debug that code. Now I don't see any problem in letting that go. > A couple of other minor tweaks I made > were copying the byte length parameter to a local var and declaring the > function as inline. It also now will generate an error if there is a > register command without at least one data dword following it (in addition > to checking for a command count that overflows buf->used). That check is > now the new loop condition (n > 1 instead of n (!=0) ), so it doesn't add > anything inside the loop. There is one extra conditional in the loop now > to check the return of copy_from_user. All of this may or may not have > much of a performance effect, but it is a pretty critical code path, I > think. My impression is that the effect of the copy/verify is noticeable in slower machines but neglectable in faster. But I guess that the hit is probably more related to the processor cache than its actual speed. > > > 3. We still need to work out the wrapper/alternative to > > > pci_alloc_consistent() and friends. > > > > I'm still reading Ian texmem-2 proposal and looking to the source code > > to get a hold of this. > It's now official: I'm coding on this. I'm adding the _ioctl suffix to most IOCTLs (e.g., agp_alloc -> agp_alloc_ioctl) to leave to the agp_alloc for internal DRM usage, and writing a set of pci_* to wrap the pci_*_consistent and pci_pool_* API in the Linux. Nothing of this will break binary compatability and will allow one to [optionally] setup all main DMA buffers from within DRM_IOCTL_DMA IOCTL instead of the X server. Of course that I would like to pursue this idea in Mach64 driver. > Something I have in my old tree that I haven't merged to the new branch > yet is setting up the ring in AGP when available. That will get rid of > the use of pci_alloc_consistent for AGP cards. However we still can't do > private buffers in AGP without multiple buffer lists. However, it might > be enough to allow porting/testing on *BSD to continue with the PCI mode > setup in mach64_dma.c disabled (with the current temporary code that > uses client buffers instead of secure buffers). BTW, is it OK to enable snapshots from the 0-0-6 branch instead? José Fonseca __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] G450 on DRI and problems
On Die, 2003-02-18 at 22:21, AnonimoVeneziano wrote: > Michel Dänzer wrote: > > >On Mon, 2003-02-17 at 22:44, AnonimoVeneziano wrote: > > > >>Ian Romanick wrote: > >> > >>>The texmem-0-0-1 branch is a separate branch within DRI CVS. You > >>>would check that branch out by doing: > > > >[...] > > > >>MMM, the modules in this snap shot does not compile. The Makefile.linux > >>is corrupted or does not function correctly. It complains about no rules > >>to make target for drm_sarea.h needed by gamma_drv.o . > > > >Sounds like you're trying to build the DRM. You don't need that from the > >branch. Just make World and grab mga_dri.so from > >exports/lib/modules/dri/ when it's finished. > > > Does not compile with make World :cry: , It stops in the middle of the > compilation (and not compile the modules that I need) You don't provide information about the error, so I can only guess: you need to have XFree86 development packages (xlibs-dev on Debian) installed to build a DRI CVS tree. If that's not the problem, you need to provide more information. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM OS Independence and Mach64
On Wed, 2003-02-19 at 01:48, José Fonseca wrote: > I think our case is one of the exceptions: we are copying from the user > and verifying the data at the same time (to avoid the user sending > malicious commands to the card's DMA engine which could potentialy > compromise the system integrity and security). The alternative would be > copy the whole thing and the verify but it was agreed that this would > make better use of the cache and so on... Small here is bytes, caches are 64byte lines nowdays, sometimes up to 256 or so to the L2 cache. Time it and see 8) --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM OS Independence and Mach64
On Wed, Feb 19, 2003 at 01:50:49AM +, Alan Cox wrote: > > verify_area performs any checks needed for it to be safe to use the > _copy forms of copy_*_user. What that does varies. The normal Linux > approach is > > verify_area does access_ok which checks the address is a kernel view > of a user space address. _copy* functions use the MMU to fault any > illegal access beyond that. > > On some platforms you cant use the mmu so verify_area does more work, > on others its using stuff like space registers and verify_area is a > nop. Thanks for the clarification. > copy_from_user sorts out the whole thing itself. In general > __copy_from_user and verify_area isnt a win, except if you do lots of > small copies to/from the same area, which is often a bad idea anyway. I think our case is one of the exceptions: we are copying from the user and verifying the data at the same time (to avoid the user sending malicious commands to the card's DMA engine which could potentialy compromise the system integrity and security). The alternative would be copy the whole thing and the verify but it was agreed that this would make better use of the cache and so on... José Fonseca __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM OS Independence and Mach64
On 19 Feb 2003, Alan Cox wrote:
>
> copy_from_user sorts out the whole thing itself. In general __copy_from_user and
>verify_area
> isnt a win, except if you do lots of small copies to/from the same area, which is
>often
> a bad idea anyway.
It _can_ be a good idea, though.
In particular, it's a _really_ good idea if the loop is basically a
"glorified memcpy", at which point it can be very much worthwhile to move
the limit checking outside the loop.
An example of this is doing things like "copy-and-checksum", or, in the
case of DRM "copy-and-check-validity", where the code should sanely look
something like
u32 *addr; /* Command list */
if (!access_ok(VERIFY_READ, addr, size))
return -EFAULT;
while (size > 0) {
unsigned int cmd;
if (__get_user(cmd, addr))
goto efault;
addr++;
switch (cmd) {
... verify it ...
}
*dst++ = cmd;
}
where the difference between a "get_user()" and a "__get_user()" can be
quite noticeable (the unchecked version is usually a single instruction in
size and has no nasty branch behaviour or anything like that, while the
checking version usually has at least one conditional branch and uses up
one or two registers etc).
Of course, this is really only worth doing for tight loops that really
matter. If the code in the loop is crap, the optimization just isn't worth
the complexity.
(And the extreme case of this is when the code is _so_ performance
critical that you end up writing it all in assembly language. The example
of this is the TCP copy-and-checksum stuff. The above example is somewhere
between the "normal usage" and the "TCP copy-and-checksum" extremes).
Linus
---
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM OS Independence and Mach64
verify_area performs any checks needed for it to be safe to use the _copy forms of copy_*_user. What that does varies. The normal Linux approach is verify_area does access_ok which checks the address is a kernel view of a user space address. _copy* functions use the MMU to fault any illegal access beyond that. On some platforms you cant use the mmu so verify_area does more work, on others its using stuff like space registers and verify_area is a nop. copy_from_user sorts out the whole thing itself. In general __copy_from_user and verify_area isnt a win, except if you do lots of small copies to/from the same area, which is often a bad idea anyway. Alan --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM OS Independence and Mach64
On Tue, 18 Feb 2003, Leif Delgass wrote: > > My memory is failing: this might still be usefull for Xv, isn't it? > > Maybe, maybe not. DMA for XVideo seems to be of questionable value, > judging from the Rage 128 driver. Plus the fact that you have to > wait/sync when switching between GUI masters and system masters. I've > used interrupts to test page flipping with vsync. However, this is also > of questionable utility. Page flipping without vsync doesn't really buy > anything, since it has to be done synchronously (block until the vertical > counter resets). What I meant to say here is that page flipping without vsync _interrupts_ on mach64 doesn't buy you much. It's not possible to do page flipping _without_ syncing the flip to the refresh on mach64. Doing it without interrupts means polling the vertical counter: either block until the counter resets, or poll whenever you have new buffers to see if you can commit them. The latter is not much different from my interrupt method. I got interrupts working using an atomic commit flag that's set on vblank and checked when adding buffers to the ring, since I was getting lockups trying to do the commit in the bottom half. Ideally, you would commit the ring in the bottom half, so the card can work in the time between the interrupt and the arrival of the next buffer from the client. > One advantage is that it seems to smooth out some of the stutters in > rendering as well as eliminating tearing, but at the cost of reducing > the framerate if the app can't keep up with the vertical refresh. Most > apps on mach64 (other than gears) don't fall into that category. :( To clarify, here I meant that most apps fall in the category of having a framerate _slower_ than the refresh. -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM OS Independence and Mach64
On Tue, 18 Feb 2003, [iso-8859-15] José Fonseca wrote:
> On Mon, Feb 17, 2003 at 08:15:02PM -0500, Leif Delgass wrote:
> > As I was doing some minor cleanups in the mach64 drm in the new branch, I
> > made some additional search and replace conversions of the mach64 DRM to
> > the os independence macros (I couldn't restrain myself ;) ). However, I
> > want to share what I've done so far and get some feedback, since there are
> > a couple of issues here:
> >
> > 1. We are currently using access_ok() to check the vertex buffers
> > submitted by the client before copying them to (what will be) private
> > kernel buffers. There was only a macro in drm_os_linux.h for
> > DRM_VERIFYAREA_READ(), so I added DRM_ACCESSOK_READ(). I don't really
> > know the details of what the difference is between verify_area() and
> > access_ok() (Jose added that code based on a suggestion from Linus, I
> > think), but I believe access_ok() is intended as a security check, which
> > is the reason for the copy. It seems that this all maps to the same thing
> > for *BSD at the moment -- i.e. the unchecked macros aren't implemented
> > differently from the checked ones, right?
>
> They seem to be equivalent, onyle the semantics of the return value
> differ. Here is the definition of verify_area in my distribution kernel
> sources (linux-2.4.20-gentoo-r1), in include/asm-i386/uaccess.h:
>
> static inline int verify_area(int type, const void * addr, unsigned long size)
> {
> return access_ok(type,addr,size) ? 0 : -EFAULT;
> }
>
> So perhaps we should converge on one.
OK, I've changed this to use DRM_VERIFYAREA_READ().
I also made some other changes to the copy/verify:
I added a check to the ioctl handler (mach64_dma_vertex) to check that the
vertex buffer has an integral number of dwords (in addition to the check
against MACH64_BUFFER_SIZE). I also changed copy_and_verify_from_user to
return an error code instead of the number of bytes copied. I don't see
any reason to dispatch a buffer unless all checks succeed (in fact it can
potentially cause lockups if we submit a partial buffer), so it's either
all or nothing. If it succeeds then we just copy buf->used to the private
buffer struct. This also allows us to return a more meaningful error
code, e.g. EFAULT for failed verify_area/copy_from_user, EINVAL for bad
command counts or buffer size, and EACCES for disallowed register commands
in the buffer. It also lets us get rid of the 'copied' local var and a
couple of adds inside the loop. A couple of other minor tweaks I made
were copying the byte length parameter to a local var and declaring the
function as inline. It also now will generate an error if there is a
register command without at least one data dword following it (in addition
to checking for a command count that overflows buf->used). That check is
now the new loop condition (n > 1 instead of n (!=0) ), so it doesn't add
anything inside the loop. There is one extra conditional in the loop now
to check the return of copy_from_user. All of this may or may not have
much of a performance effect, but it is a pretty critical code path, I
think.
> > 2. The Mach64 driver makes heavy use of the list struct and macros from
> > linux/list.h. I moved the define for list_for_each_safe() (needed for
> > older 2.4 Linux kernels) from mach64_drv.h to drmP.h, since that has
> > already been added in XFree86 CVS (I think the i8x0 drm uses it now also).
> > I also removed the include of linux/list.h from the mach64 driver, since
> > it already gets included (indirectly?) through the drm headers. However,
> > it looks like an analogue of linux/list.h might need to be added to the
> > BSD drm headers. The only wrinkle there is that it also uses
> > linux/prefetch.h.
FYI Eric, here's what we're currently using from linux/list.h:
struct list_head
INIT_LIST_HEAD()
list_entry()
list_for_each()
list_for_each_safe()
list_del()
list_add_tail()
list_empty()
> > 3. We still need to work out the wrapper/alternative to
> > pci_alloc_consistent() and friends.
>
> I'm still reading Ian texmem-2 proposal and looking to the source code
> to get a hold of this.
Something I have in my old tree that I haven't merged to the new branch
yet is setting up the ring in AGP when available. That will get rid of
the use of pci_alloc_consistent for AGP cards. However we still can't do
private buffers in AGP without multiple buffer lists. However, it might
be enough to allow porting/testing on *BSD to continue with the PCI mode
setup in mach64_dma.c disabled (with the current temporary code that
uses client buffers instead of secure buffers).
Eric, do you have hardware to test on?
> > 4. As I mentioned before, the interrupt code is not converted, but it's
> > currently unused.
>
> My memory is failing: this might still be usefull for Xv, isn't it?
Maybe, maybe not. DMA for XVideo seems to be of questionable value,
judging from the Rage 128 driver. Plus the fact that you hav
Re: [Dri-devel] G450 on DRI and problems
IIRC, your log file that you attached a few days ago said that the mga hal could not be found. Perhaps this has something to do with your problem? Any comments anyone? = The nice thing about Windows is - It does not just crash, it displays a dialog box and lets you press 'OK' first. --Arno Schaefer's .sig E-Mail: [EMAIL PROTECTED] Web Site: http://mazack.zikeai.com/ __ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] G450 on DRI and problems
Michel Dänzer wrote: On Mon, 2003-02-17 at 22:44, AnonimoVeneziano wrote: Ian Romanick wrote: The texmem-0-0-1 branch is a separate branch within DRI CVS. You would check that branch out by doing: [...] MMM, the modules in this snap shot does not compile. The Makefile.linux is corrupted or does not function correctly. It complains about no rules to make target for drm_sarea.h needed by gamma_drv.o . Sounds like you're trying to build the DRM. You don't need that from the branch. Just make World and grab mga_dri.so from exports/lib/modules/dri/ when it's finished. Does not compile with make World :cry: , It stops in the middle of the compilation (and not compile the modules that I need) Byez --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Lock problem with Radeon DRI
On Tue, Feb 18, 2003 at 02:34:29PM -0500, Leif Delgass wrote: > On Tue, 18 Feb 2003, Martin Spott wrote: > > So are we going to see XFree86-4.3.0 with broken Radeon DRI drivers ? > I noticed that Michel's fix for large textures in > radeon_cp_dispatch_texture() has only been in XFree86 cvs since 4.2.99.902 > (about 10 days ago). I'm not sure if the problem that fixed could cause a > lockup, [...] No, unfortunately it does not. I am currently running a kernel with DRM built from XFree86-4.2.99.902 and it still locks up reliably. 'radeon_state.c' is identical to the one in DRI trunk. I've already been testing quite a few patches that have been floating around in 'dri-devel' and you would have heard me shouting out loud if one of them would had solved the lockup-issue ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Lock problem with Radeon DRI
On Tue, 18 Feb 2003, Martin Spott wrote: > On Fri, Feb 14, 2003 at 04:51:24PM +, Alan Cox wrote: > > On Fri, 2003-02-14 at 14:52, Martin Spott wrote: > > > > Where did you take the DRM sources from ? I usually take the source for the > > > DRM module from the same DRI CVS tree I use to build the whole DRI thing, > > > > Mike Harris builds in Red Hat beta and in rawhide > > It appears to me that the kernel modules of Mike's build do not differ from > XFree86 4.2.99.901 - at least he didn't include any additional patches > that thouch the kernel modules. I have the impression he also did not > include any patches that touch the Radeon driver in a way that might prevent > from lockups. > > So are we going to see XFree86-4.3.0 with broken Radeon DRI drivers ? > > Martin. I noticed that Michel's fix for large textures in radeon_cp_dispatch_texture() has only been in XFree86 cvs since 4.2.99.902 (about 10 days ago). I'm not sure if the problem that fixed could cause a lockup, but you might want to try building a DRM from current X cvs and see if it makes a difference. -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM OS Independence and Mach64
On Mon, Feb 17, 2003 at 08:15:02PM -0500, Leif Delgass wrote:
> As I was doing some minor cleanups in the mach64 drm in the new branch, I
> made some additional search and replace conversions of the mach64 DRM to
> the os independence macros (I couldn't restrain myself ;) ). However, I
> want to share what I've done so far and get some feedback, since there are
> a couple of issues here:
>
> 1. We are currently using access_ok() to check the vertex buffers
> submitted by the client before copying them to (what will be) private
> kernel buffers. There was only a macro in drm_os_linux.h for
> DRM_VERIFYAREA_READ(), so I added DRM_ACCESSOK_READ(). I don't really
> know the details of what the difference is between verify_area() and
> access_ok() (Jose added that code based on a suggestion from Linus, I
> think), but I believe access_ok() is intended as a security check, which
> is the reason for the copy. It seems that this all maps to the same thing
> for *BSD at the moment -- i.e. the unchecked macros aren't implemented
> differently from the checked ones, right?
They seem to be equivalent, onyle the semantics of the return value
differ. Here is the definition of verify_area in my distribution kernel
sources (linux-2.4.20-gentoo-r1), in include/asm-i386/uaccess.h:
static inline int verify_area(int type, const void * addr, unsigned long size)
{
return access_ok(type,addr,size) ? 0 : -EFAULT;
}
So perhaps we should converge on one.
> 2. The Mach64 driver makes heavy use of the list struct and macros from
> linux/list.h. I moved the define for list_for_each_safe() (needed for
> older 2.4 Linux kernels) from mach64_drv.h to drmP.h, since that has
> already been added in XFree86 CVS (I think the i8x0 drm uses it now also).
> I also removed the include of linux/list.h from the mach64 driver, since
> it already gets included (indirectly?) through the drm headers. However,
> it looks like an analogue of linux/list.h might need to be added to the
> BSD drm headers. The only wrinkle there is that it also uses
> linux/prefetch.h.
>
> 3. We still need to work out the wrapper/alternative to
> pci_alloc_consistent() and friends.
I'm still reading Ian texmem-2 proposal and looking to the source code
to get a hold of this.
> 4. As I mentioned before, the interrupt code is not converted, but it's
> currently unused.
My memory is failing: this might still be usefull for Xv, isn't it?
> At any rate, the remainder of the attached patch is trivial additions of
> DRM_ERR, DRM_CURRENTPID, etc. and a couple of whitespace tweaks.
José Fonseca
__
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Lock problem with Radeon DRI
> How can get a new module? Do I have to build XF86 from source No, you don't have to rebuild the whole XFree86. I usually take the Sources from: xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/ xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/ and adjust the Makefile in my kernel tree accordingly. So I just have to 'make modules' in the kernel tree to get updated DRI modules, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Lock problem with Radeon DRI
On Tue, 18 Feb 2003 14:56:04 +0100 Martin Spott <[EMAIL PROTECTED]> wrote: > > It appears to me that the kernel modules of Mike's build do not differ from > XFree86 4.2.99.901 - at least he didn't include any additional patches > that thouch the kernel modules. I have the impression he also did not > include any patches that touch the Radeon driver in a way that might prevent > from lockups. > > So are we going to see XFree86-4.3.0 with broken Radeon DRI drivers ? I have a related question (but slightly OT): I got the binary release for XF86 4.2.99.901. It works, but I still got the same lock problem. However, I realize that I am using the same kernel module as before, althought newer DRM modules are suposed to be part of the XF86+DRI source. How can get a new module? Do I have to build XF86 from source Pedro. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Lock problem with Radeon DRI
On Fri, Feb 14, 2003 at 04:51:24PM +, Alan Cox wrote: > On Fri, 2003-02-14 at 14:52, Martin Spott wrote: > > Where did you take the DRM sources from ? I usually take the source for the > > DRM module from the same DRI CVS tree I use to build the whole DRI thing, > > Mike Harris builds in Red Hat beta and in rawhide It appears to me that the kernel modules of Mike's build do not differ from XFree86 4.2.99.901 - at least he didn't include any additional patches that thouch the kernel modules. I have the impression he also did not include any patches that touch the Radeon driver in a way that might prevent from lockups. So are we going to see XFree86-4.3.0 with broken Radeon DRI drivers ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
