Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://freedesktop.org/bugzilla/show_bug.cgi?id=1735
--- Additional Comments From [EMAIL PROTECTED] 2004-10-31 20:51 ---
Owen, the s
> On Sun, 2004-10-31 at 13:18, Thomas Hellström wrote:
>> Keith Whitwell wrote:
>>
>> > Thomas Hellström wrote:
>> >
>> >> Hi, list!
>> >>
>> >> With display cards that have more and more hardware on them,
>> >> (TV-capture, mpeg decoders) etc. that can work independently of
>> >> oneanother, but s
> --- Thomas Hellström <[EMAIL PROTECTED]> wrote:
>
>> Keith Whitwell wrote:
>>
>> The typical case here:
>>
>> I want a DRI client to flip a video frame to screen, using a hardware
>> entity called the HQV. This is a rather time critical operation. To do
>> this I have to take the hardware lock.
>
--- Thomas Hellström <[EMAIL PROTECTED]> wrote:
> Keith Whitwell wrote:
>
> The typical case here:
>
> I want a DRI client to flip a video frame to screen, using a hardware
> entity called the HQV. This is a rather time critical operation. To do
> this I have to take the hardware lock.
>
> W
On Sun, 2004-10-31 at 13:18, Thomas Hellström wrote:
> Keith Whitwell wrote:
>
> > Thomas Hellström wrote:
> >
> >> Hi, list!
> >>
> >> With display cards that have more and more hardware on them,
> >> (TV-capture, mpeg decoders) etc. that can work independently of
> >> oneanother, but share the
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://freedesktop.org/bugzilla/show_bug.cgi?id=1746
Summary: Freelist issues in MGA DRM
Product: DRI
Version: D
Am 2004.10.31 20:40:12 +0100 schrieb(en) Mateusz Kaduk:
> Hi,
>
> I have radeon7500 and installed Xorg Mesa and drm from CVS..
> Glxinfo shows that Direct Rendering is enabled but I get everything
> locked up with glxgears... and I have to reboot.
> I found on google people with the same problems
Jon Smirl wrote:
On Sun, 31 Oct 2004 22:54:25 +0100, Thomas Hellström
<[EMAIL PROTECTED]> wrote:
Wouldn't this severely break backwards binary compatibility with dri clients
compiled with the old size of drm_sarea_t?
You can't put them in drm_sarea_t. There is definitel
On Sun, 31 Oct 2004 22:54:25 +0100, Thomas Hellström
<[EMAIL PROTECTED]> wrote:
> Wouldn't this severely break backwards binary compatibility with dri clients
> compiled with the old size of drm_sarea_t?
You can't put them in drm_sarea_t. There is definitely code that will
break if you do. I don'
Jon Smirl wrote:
On Sun, 31 Oct 2004 19:41:03 +0100, Thomas Hellström
<[EMAIL PROTECTED]> wrote:
/* For now the mapping works by using a fixed size defined
* in the SAREA header
*/
if (sizeof(XF86DRISAREARec)+sizeof(VIASAREAPriv) > SAREA_MAX) {
xf86DrvMsg
--- Thomas Hellström <[EMAIL PROTECTED]> wrote:
> Such a case would be a client submitting 2D engine commands while the X
> server waits for 2D engine idle. Either this has to be implemented in
> the command verifier or considered acceptable behaviour. Today any dri
> client can continously cl
Mike Mestnik wrote:
--- Thomas Hellström <[EMAIL PROTECTED]> wrote:
Hi, list!
With display cards that have more and more hardware on them,
(TV-capture, mpeg decoders) etc. that can work independently of
oneanother, but share the same DMA engine I've find the need for more
than
Keith Whitwell wrote:
Thomas Hellström wrote:
Hi, list!
With display cards that have more and more hardware on them,
(TV-capture, mpeg decoders) etc. that can work independently of
oneanother, but share the same DMA engine I've find the need for more
than one hardware lock.
The first question
--- Thomas Hellström <[EMAIL PROTECTED]> wrote:
> Hi, list!
>
> With display cards that have more and more hardware on them,
> (TV-capture, mpeg decoders) etc. that can work independently of
> oneanother, but share the same DMA engine I've find the need for more
> than one hardware lock. I've
Hi,
I have radeon7500 and installed Xorg Mesa and drm from CVS..
Glxinfo shows that Direct Rendering is enabled but I get everything
locked up with glxgears... and I have to reboot.
I found on google people with the same problems but no solutions were
given.
I include output from glxinfo with ex
Thomas Hellström wrote:
Hi, list!
With display cards that have more and more hardware on them,
(TV-capture, mpeg decoders) etc. that can work independently of
oneanother, but share the same DMA engine I've find the need for more
than one hardware lock.
The first question is - have you found tha
On Sun, 31 Oct 2004 19:41:03 +0100, Thomas Hellström
<[EMAIL PROTECTED]> wrote:
>
> /* For now the mapping works by using a fixed size defined
> * in the SAREA header
> */
> if (sizeof(XF86DRISAREARec)+sizeof(VIASAREAPriv) > SAREA_MAX) {
> xf86DrvMsg(pScrn->scrnIndex, X_E
Jon Smirl wrote:
On Sun, 31 Oct 2004 18:41:42 +0100, Thomas Hellström
<[EMAIL PROTECTED]> wrote:
The idea of using a separate sarea is that it would be easy to extend the
number of locks and more suitable for more drivers than via. Otherwise one
idea would be to
fill the private
On Sun, 31 Oct 2004 18:41:42 +0100, Thomas Hellström
<[EMAIL PROTECTED]> wrote:
> The idea of using a separate sarea is that it would be easy to extend the
> number of locks and more suitable for more drivers than via. Otherwise one
> idea would be to
> fill the private sarea from the back, but
Jon Smirl wrote:
On Sun, 31 Oct 2004 16:52:35 +0100, Thomas Hellström
<[EMAIL PROTECTED]> wrote:
1. A separate sarea to contain these locks, to avoid messing up the
current sarea with binary incompatibilities as a consequence.
It would probably be better to extend the cu
On Sun, 31 Oct 2004 16:52:35 +0100, Thomas Hellström
<[EMAIL PROTECTED]> wrote:
> 1. A separate sarea to contain these locks, to avoid messing up the
> current sarea with binary incompatibilities as a consequence.
It would probably be better to extend the current driver specific
sarea. You can neg
Hi, list!
With display cards that have more and more hardware on them,
(TV-capture, mpeg decoders) etc. that can work independently of
oneanother, but share the same DMA engine I've find the need for more
than one hardware lock. I've done a simple implementation for the mpeg
decoder of the via
Hi!
ARB released a couple of days ago the long waited float extensions..
http://oss.sgi.com/projects/ogl-sample/registry/ARB/color_buffer_float.txt
http://oss.sgi.com/projects/ogl-sample/registry/ARB/half_float_pixel.txt
http://oss.sgi.com/projects/ogl-sample/registry/ARB/texture_float.txt
http:
On Sat, Oct 30, 2004 at 04:16:09AM +0200, Stephane Marchesin wrote:
> ../../../../../src/mesa/tnl_dd/t_dd_vbtmp.h: In function `emit_wg':
> ../../../../../src/mesa/tnl_dd/t_dd_vbtmp.h:387: error: `col_size'
> undeclared (first use in this function)
It compiles for me after applying attached patch
> The patch below removes two unused functions from DRM.
>
> diffstat output:
> drivers/char/drm/i810_dma.c | 18 --
> drivers/char/drm/i915_dma.c | 18 --
> 2 files changed, 36 deletions(-)
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Acked-by: Dave Ai
Hi. While the current Xv implementation is far better than the old one there
are still a few glitches I noticed so far:
* 4 pixels always missing on the right side on the screen
* The old "shadowing" effect is showed on certain conditions (depending on
input sizes). I only tested a few sizes: 76
> A patch is attached. It changes both linux/linux-2.6 and linux-core. I
> tested that it compiles (linux-2.6 and linux-core) and loads all modules
> (except radeon, which failed because I don't have the necessary i2c bits
> in my kernel). Any objections to applying this?
>
Looks good to me apply
A patch is attached. It changes both linux/linux-2.6 and linux-core. I
tested that it compiles (linux-2.6 and linux-core) and loads all modules
(except radeon, which failed because I don't have the necessary i2c bits
in my kernel). Any objections to applying this?
Regards,
Felix
Am Sa, den 30.1
On Sat, 2004-10-30 at 04:06 +0100, Sérgio wrote:
> Can we change configuration of Xorg, for compile and install xorg
> without compile any source of Mesa and/or GLx ?
You could try BuildGLXLibrary and/or BuildXF86DRI. I'm not sure of all
the implications, but it sounds like the right direction.
29 matches
Mail list logo
